We were pulling in 44 MiB of fonts in the default configuration, which
is a bit excessive for headless configurations like EC2
instances. Note that dejavu_minimal ensures that remote X11-forwarded
applications still have a basic font regardless.
Before commit 54fa0cfe4e, the `redshift`
service was run with the environment variable `DISPLAY` set to `:0`.
Commit 54fa0cfe4e changed this to
instead use the value of the `services.xserver.display` configuration
option in the value of the `DISPLAY` variable. In so doing, no default
value was provided for the case where `services.xserver.display` is
`null`.
While the default value of `services.xserver.display` is `0`, use of
which by the `redshift` module would result in `DISPLAY` again being
set to `:0`, `services.xserver.display` may also be `null`, to which
value it is set by, e.g., the `lightdm` module.
In the case that `services.xserver.display` is `null`, with the change
made in commit 54fa0cfe4e, the `DISPLAY`
variable in the environment of the `redshift` service would be set to
`:` (a single colon), which, according to my personal experience,
would result in —
- the `redshift` service failing to start; and
- systemd repeatedly attempting to restart the `redshift` service,
looping indefinitely, while the hapless `redshift` spews error
messages into the journal.
It can be observed that the malformed value of `DISPLAY` is likely at
fault for this issue by executing the following commands in an
ordinary shell, with a suitable `redshift` executable, and the X11
display not already tinted:
- `redshift -O 2500` — This command should reduce the color
temperature of the display (making it more reddish).
- `DISPLAY=':' redshift -O 6500` — This command should raise the
color temperature back up, were it not for the `DISPLAY`
environment variable being set to `:` for it, which should cause
it to, instead, fail with several error messages.
This commit attempts to fix this issue by having the `DISPLAY`
environment variable for the `redshift` service default to its old
value of `:0` in the case that `services.xserver.display` is `null`.
I have tested this solution on NixOS, albeit without the benefit of a
system with multiple displays.
Instead of one package `extra-cmake-modules`, there is now `ecm` and
`ecmNoHooks`. The latter is used when one does not want to incur a Qt 5
dependency; it is also available as a top-level package
`extra-cmake-modules`.
KDM and LightDM (at least with autologin) call the xsession-script with
two arguments: the first is the path of the xsession script itself,
while the second one are the actual arguments. The line to re-exec the
script under systemd-cat only forwarded a single argument, therefore
breaking LightDM and KDM login. This commit fixes the issue by always
forwarding all the arguments.
We need to pass certain environment variables through the wrapper, but I
don't know how to do that yet. The setuid-root feature serves only to
hide kdeinit from the OOM killer, so this is not critical.
- init gnome-software for gnome3 at 3.18.3
- list gnome-software as an "optional package" for gnome3
- enable packagekit service when gnome3 is enabled
Fixes this (line wrapped):
$ gnome-control-center
[... click on the "Color" item ...]
(gnome-control-center:3977): color-cc-panel-WARNING **: \
The name org.freedesktop.ColorManager was not provided by any .service files
With this patch applied, the above warnings are not printed and the GUI
shows some devices that can be managed (my printer and display). Without
this patch the GUI is empty (non-functional).
(cups will also complain in the journal with a similar message when
doing print jobs, without this patch.)
...by adding system-config-printer to services.dbus.packages (if
services.printing.enable is true).
Without this patch, trying to add a printer will result in a little dialog
saying "Failed to add new printer" and gnome-control-center will print this to
the terminal (line wrapped):
(gnome-control-center:3546): printers-cc-panel-WARNING **: \
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: \
The name org.fedoraproject.Config.Printing was not provided by any .service files
system-config-printer supplies the "org.fedoraproject.Config.Printing" dbus
service, thus fixing the problem.
