---
Using the configure option relieves us of the patch and passing the path
via the env var in many places. Also the env var may not be inherited
when components like gdm spawn new sessions.
The following changes are included:
1) install user unit files from upstream dbus
2) use absolute paths to config for --system and --session instances
3) make socket activation of user units configurable
There has been a number of PRs to address this, so this one does the
bare minimum, which is to make the functionality available and
configurable but defaults to off.
Related PRs:
- #18382
- #18222
(cherry picked from commit f7215c9b5b47dfb0a6dbe87ff33d7730729a32e5)
Signed-off-by: Domen Kožar <domen@dev.si>
Regression introduced by bccd75094f.
The mentioned commit removed the pkgs.gtk attribute, but forgot to
change this within the xfce module.
Tested using the xfce NixOS test and it has passed on my machine.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
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.
When displaying a warning about a removed Option we should always
include reasoning why it was removed and how to get the same
functionality without it.
Introduces such a description argument and patches occurences (mostly
with an empty string).
startGnuPGAgent: further notes on replacement
... rather than ~/.xsession-errors. It might make sense to make this
the default, in order to eliminate ad hoc, uncentralised, poorly
discoverable log files.
This ensures that "journalctl -u display-manager" does what you would
expect in 2016. However, the main reason is to ensure that our VM
tests show the output of the X server.
A slight problem is that with KDE user switching, messages from the
various X servers end up in the same place. However, that's an
improvement over the previous situation, where the second X server
would overwrite the /var/log/X.0.log of the first. (This was caused by
the fact that we were passing a hard-coded value for -logfile.)
`dbus-launch` is executed early in the script, before desktop managers
had a chance to setup the environment. If DBus activation is used,
applications launched by this may therefore lack necessary environment
variables. This patch sends the complete environment to DBus after
launching the desktop manager.
Commit 98d9bba introduced this option as a nullOr type and it actually
checks whether null has been set and only appends -dpi if that's the
case. So let's actually set the default to null instead of 0.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
GnuPG 2.1.x changed the way the gpg-agent works, and that new approach no
longer requires (or even supports) the "start everything as a child of the
agent" scheme we've implemented in NixOS for older versions.
To configure the gpg-agent for your X session, add the following code to
~/.xsession or some other appropriate place that's sourced at start-up:
gpg-connect-agent /bye
GPG_TTY=$(tty)
export GPG_TTY
If you want to use gpg-agent for SSH, too, also add the settings
unset SSH_AGENT_PID
export SSH_AUTH_SOCK="${HOME}/.gnupg/S.gpg-agent.ssh"
and make sure that
enable-ssh-support
is included in your ~/.gnupg/gpg-agent.conf.
The gpg-agent(1) man page has more details about this subject, i.e. in the
"EXAMPLES" section.
Add ability to do a more traditional bspwm startup (using the bspwm-session
script provided by nixpkgs.bspwm) as an alternative to directly starting
sxhkd & bspwm
Also added the ability to specify a custom startup script, instead of
relying on the provided bspwm-session
add '-f 100' as an argument to sxhkd to keep it from flooding bspwm
add SXHKD_SHELL=/bin/sh to help default to a faster shell than what may
be set in $SHELL (example: with zsh)
- Enforce that an option declaration has a "defaultText" if and only if the
type of the option derives from "package", "packageSet" or "nixpkgsConfig"
and if a "default" attribute is defined.
- Enforce that the value of the "example" attribute is wrapped with "literalExample"
if the type of the option derives from "package", "packageSet" or "nixpkgsConfig".
- Warn if a "defaultText" is defined in an option declaration if the type of
the option does not derive from "package", "packageSet" or "nixpkgsConfig".
- Warn if no "type" is defined in an option declaration.
This reverts most of 89e983786a, as those references are sanitized now.
Fixes#10039, at least most of it.
The `sane` case wasn't fixed, as it calls a *function* in pkgs to get
the default value.
Before the error if the wrong default desktop was chosen would be:
/nixpkgs-channels/lib/modules.nix:282:11:
Default desktop manager ($(defaultDM)) not found.
which has the string interpolation done incorreclty. Now that is fixed
and it is more user-friendly as:
/nixpkgs-channels/lib/modules.nix:282:11:
Default desktop manager (gnome) not found.
Probably you want to change
services.xserver.desktopManager.default = "gnome";
to one of
services.xserver.desktopManager.default = "gnome3";
services.xserver.desktopManager.default = "none";
- added numlock on boot switch
- simply add :
services.xserver.displayManager.sddm.autoNumlock = true;
to configuration.nix and sddm will start
with numlock enabled.
- add missing types in module definitions
- add missing 'defaultText' in module definitions
- wrap example with 'literalExample' where necessary in module definitions
This reverts most of 89e983786a, as those references are sanitized now.
Fixes#10039, at least most of it.
The `sane` case wasn't fixed, as it calls a *function* in pkgs to get
the default value.
The three KDE package sets now have circular dependencies between them,
so they can only be built if they are merged into a single package set
during evaluation.
- if xserver.tty and/or display are set to null, then don't specify
them, or the -logfile argument in the xserverArgs
- For lightdm, we set default tty and display to null and we determine
those at runtime based on arguments passed. This is necessary because
we run multiple X servers so they can't all be on the same display
These options allow setting the start and stop scripts for the display
manager. Making these configurable is necessary to allow some hardware
configurations. Upstream ships empty scripts by default, anyway.
Now the default way to define NixOS window manager modules is to use
mkEnableOption to describe the module itself.
In this commit, all files on nixos/modules/services/x11/window-managers
are changed.
Add the possibility to specify plugin set to
be used as overridable `thunar` derivation argument.
New nixos config attribute:
`services.xserver.desktopManager.xfce.thunarPlugins`
that allows user to specify plugins in the context
of nixos.
Tests:
- With and without plugins.
- Using the nixos attributes.
Ctrl+Alt+Backspace is usually enabled by default under X, and is a
keyboard shortcut that forcefully kills the current X server. This can
lead to data loss by users if accidentally pressed. This commit
introduces a new option, services.xserver.enableCtrlAltBackspace, that
is *disabled* by default. If set to true, the previous behavior can be
restored.
A similar decision was made by the Ubuntu team, and is documented here:
https://wiki.ubuntu.com/XorgCtrlAltBackspace
The most complex problems were from dealing with switches reverted in
the meantime (gcc5, gmp6, ncurses6).
It's likely that darwin is (still) broken nontrivially.
The default synaptics functionality (without this file) is limited for
clickpads: the right soft button area in the bottom right isn't active by
default, so the entire pad generates left-clicks. There is no way to
right-drag.
This file defines soft button areas and provides some matching rules.
These settings don't conflict with the synaptics options that NixOS
provides.
This seems to have been confusing people, using both xlibs and xorg, etc.
- Avoided renaming local (and different) xlibs binding in gcc*.
- Fixed cases where both xorg and xlibs were used.
Hopefully everything still works as before.
As discussed on https://github.com/NixOS/nixpkgs/pull/9642, the option
is not necessary because all desktop managers already stopped handling
it (and delegated to systemd).
Or else users may see this unfriendly message:
error: cannot coerce null to a string, at .../nixos/modules/services/x11/display-managers/gdm.nix:107:49
Changes the option and explicitely sets it for each desktopManager.
Reasoning: Currently,
services.xserver.displayManager.desktopManagerHandlesLidAndPower is set
to true by default. This creates a problem for users without desktop
environments activated, since lid management simply doesn't work
(and they have to be lucky to find this option).
See issue #9671
