GNOME in particular just breaks if plymouth isn't disabled, because
GDM takes on the role of quitting plymouth in a GNOME
configuration. But if we're disabling the DM, we should disable
plymouth too anyway.
By enabling this module, the jlink system group is created and udev
rules from the libjaylink package are enabled. Read-/Write access is
granted to the members of the jlink group and to seat sessions.
Signed-off-by: Felix Singer <felixsinger@posteo.net>
It's unusual to use the plugdev group in NixOS. So instead, give access
to users in the jlink group. It does not conflict with the uaccess tag,
which grants access to seat sessions.
Signed-off-by: Felix Singer <felixsinger@posteo.net>
This warning is based on a misconception: xss-lock, as most user
services, just require access to the shell environment variables,
which for `startx` have to be imported manually.
There are some common pitfalls and no documentation around how to write
the .xinitrc to correctly start the window manager, the systemd
graphical session and, ideally, cleaning up afterwards.
To improve the user experience around startx this change:
1. Adds two options to generate a sane default script and extend
it declaratively from NixOS.
2. Adds assertions to graphical-session.target so that it will fail
clearly and immediately when users writing their own script forget to
import the necessary environment variables.
This reverts commit d64a233e4c.
A stdenv bug breaks emacs.pkgs.withPackages wrapper. A fix PR[1] will
take a few weeks to reach users because it has to go through a staging
cycle. Revert this for now to unbreak emacs.pkgs.withPackages
wrapper.
[1]: https://github.com/NixOS/nixpkgs/pull/388908
The LibreNMS cache may contain paths to the old package and may break
when the old package is removed. So it is not enough to clear the cache
only on version updates, as the package will also change when build
inputs change.
This commit updates the setup script to regenerate the cache on every
package change. In addition, it now only performs migrations when the
package version has changed, since the migrations only change on version
updates and don't need to be applied on every package change.
