The configuration { services.openssh.enable = true;
services.openssh.forwardX11 = false; } caused
programs.ssh.setXAuthLocation to be set to false, which was not the
intent. The intent is that programs.ssh.setXAuthLocation should be
automatically enabled if needed or if xauth is already available.
riak-cs: added to all-packages
Added Riak CS nix file to pkgs
Added service file for Riak CS
Removed Erlang_basho specific bindings from the Riak CS repo
riak-cs: changed description
riak-cs: added license
riak-cs: added maintainer
riak_cs: chgned indentations
riak-cs: removed overly complex srcs mechanism
riak-cs: added systemd module
riak-cs: changed Erlang module to Basho-specific version
riak-cs: made modular form
riak-cs: Added a default package in service options
riak-cs: Fixed default package in service options
riak-cs: Patched Makefile
riak_cs: added to module-list
riak_cs: changed from string to actual package in modules
riak-cs: changed example
riak-cs: removed default
riak-cs: changed to defaultText
stanchion: changed default option to defaultText
riak-cs: added defaults; changed types to str
riak-cs: added to all-packages
Added Riak CS nix file to pkgs
Added service file for Riak CS
Removed Erlang_basho specific bindings from the Riak CS repo
riak-cs: changed description
riak-cs: added license
riak-cs: added maintainer
riak_cs: chgned indentations
riak-cs: removed overly complex srcs mechanism
riak-cs: added systemd module
riak-cs: changed Erlang module to Basho-specific version
riak-cs: made modular form
riak-cs: Added a default package in service options
riak-cs: Fixed default package in service options
riak-cs: Patched Makefile
riak_cs: added to module-list
riak_cs: changed from string to actual package in modules
Using a custom package set with the NixOS module is no longer
something I wish to support. It's still *possible* but not
advertised. Secondly, the requiredKernelConfig didn't really
do anything (setting kernelPackages to a non-grsec kernel would
just silently let the user boot into a non-grsec setup ...).
Network Manager calls dhclient on container interfaces and fails
which locks you out of the container after a few seconds, unless
you tell it not to manage these interfaces.
Fix automatic mouse grabbing/releasing when running as a vmware guest.
1. The xf86inputvmmouse is not loaded by default. Add it.
2. InptutDevice sections for which specify a driver are ignored if
AutoAddDevices is enabled (which it is by default). See [1]. Instead use
an InputClass to load the vmmouse driver.
[1] https://www.x.org/archive/X11R7.7/doc/man/man5/xorg.conf.5.xhtml#heading8
It was lacking the dbus configuration to bind to
org.freedesktop.DisplayManager, and it was passing fixed TTY/display
numbers to the X server (see 9be012f0d4).
