There are security fixes in multiple packages /cc #32117,
so I'm merging a little earlier, with a few thousand jobs
still not finished on Hydra for x86_64-darwin and aarch64-linux.
For some reason, the GNOME 3.26 update broke the overrides. It turns
out the overrides now need to come before the overridden schemas in the
XDG_DATA_DIRS variable. This is not possible in general due to applications
prefixing the variable (e.g. in wrapGAppsHook).
To fix this, a new environment variable NIX_GSETTINGS_OVERRIDES_DIR
was introduced. It has greater priority than XDG_DATA_DIRS but lower
than GSETTINGS_SCHEMA_DIR. A separate variable was chosen in order not
to block the built-in one for users.
With libinput used for keyboard, base rules produce incorrect keyboard
layouts. We are removing the option as recommended in the XKB configuration
guide [1] to let X server choose the ruleset. It looks like it chooses
evdev rules which seem to work for some reason
[1]: https://www.x.org/releases/X11R7.6/doc/xorg-docs/input/XKB-Config.html#id2521360
For some reason, the GNOME 3.26 update broke the overrides. It turns
out the overrides now need to come before the overriden schemas in the
XDG_DATA_DIRS variable. This is not possible in general due to applications
prefixing the variable (e.g. in wrapGAppsHook).
To fix this, a new environment variable NIX_GSETTINGS_OVERRIDES_DIR
was introduced. It has greater priority than XDG_DATA_DIRS but lower
than GSETTINGS_SCHEMA_DIR. A separate variable was chosen in order not
to block the built-in one for users.
This reverts commit 93c54acf97.
This reopens#30517 @nbp @Ma27
Breaking people's config for this is hardly reasonable as is. If it
absolutely cannot be avoided, at the very least, we need to provide
clear instructions on what people need to upgrade in their config. I
actually had to bisect to the commit, to even find out what property I
should change or define, as the error message was useless. It didn't
even mention a property name.
Discussion on the PR seems to be ongoing, so I'm reverting this, so we
don't break people's systems on unstable.
* gnome3: only maintain single GNOME 3 package set
GNOME 3 was split into 3.10 and 3.12 in #2694. Unfortunately, we barely have the resources
to update a single version of GNOME. Maintaining multiple versions just does not make sense.
Additionally, it makes viewing history using most Git tools bothersome.
This commit renames `pkgs/desktops/gnome-3/3.24` to `pkgs/desktops/gnome-3`, removes
the config variable for choosing packageset (`environment.gnome3.packageSet`), updates
the hint in maintainer script, and removes the `gnome3_24` derivation from `all-packages.nix`.
Closes: #29329
* maintainers/scripts/gnome: Use fixed GNOME 3 directory
Since we now allow only a single GNOME 3 package set, specifying
the working directory is not necessary.
This commit sets the directory to `pkgs/desktops/gnome-3`.
This is a squash commit of the joint work from:
* Jan Tojnar (@jtojnar)
* Linus Heckemann (@lheckemann)
* Ryan Mulligan (@ryantm)
* romildo (@romildo)
* Tom Hunger (@teh)
Checking the keyboard layout has been a long set of hurdles so far, with
several attempts. Originally, the checking was introduced by @lheckemann
in #23709.
The initial implementation just was trying to check whether the symbols/
directory contained the layout name.
Unfortunately, that wasn't enough and keyboard variants weren't
recognized, so if you set layout to eg. "dvorak" it will fail with an
error (#25526).
So my improvement on that was to use sed to filter rules/base.lst and
match the layout against that. I fucked up twice with this, first
because layout can be a comma-separated list which I didn't account for
and second because I ran into a Nix issue (NixOS/nix#1426).
After fixing this, it still wasn't enough (and this is btw. what
localectl also does), because we were *only* matching rules but not
symbols, so using "eu" as a layout won't work either.
I decided now it's the time to actually use libxkbcommon to try
compiling the keyboard options and see whether it succeeds. This comes
in the form of a helper tool called xkbvalidate.
IMHO this approach is a lot less error-prone and we can be sure that we
don't forget about anything because that's what the X server itself uses
to compile the keymap.
Another advantage of this is that we now validate the full set of XKB
options rather than just the layout.
Tested this against a variety of wrong and correct keyboard
configurations and against the "keymap" NixOS VM tests.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @lheckemann, @peti, @7c6f434c, @tohl, @vcunat, @lluchs
Fixes: #27597
* lib: introduce imap0, imap1
For historical reasons, imap starts counting at 1 and it's not
consistent with the rest of the lib.
So for now we split imap into imap0 that starts counting at zero and
imap1 that starts counting at 1. And imap is marked as deprecated.
See c71e2d4235 (commitcomment-21873221)
* replace uses of lib.imap
* lib: move imap to deprecated.nix
Regression introduced by 44c64fef16.
The services.xserver.layout option allows to specify more than one
layout separated by comma, which the commit above didn't take into
account.
This is very similar to @lheckemann's pull request (#26984) but differs
in the following ways:
* Print out the full list available layouts (as suggested by @0xABAB
in [1]).
* Loop over $layout using the default IFS (and thus no need for
escaping ${cfg.layout}), because the layouts won't contain white
spaces.
* Re-do the error message, which now uses multiple echos instead of a
heredoc, so the line is wrapped according to the viewers terminal
width.
I've tested this with several good and bad layouts and also against the
keymap NixOS VM subtests.
[1]: https://github.com/NixOS/nixpkgs/pull/26984#discussion_r125146700
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Fixes: #26961Closes: #26984
- Update to version 1.3.0
- Remove dependency on `oxygen-icons5`, as Lumina desktop now distributes
it’s own "material-design-[light/dark]" icon themes and uses them as the
default icon sets.
First of all, thanks to @pbogdan for getting this problem reproduced:
https://github.com/NixOS/nixpkgs/commit/2014db3efcd2a#commitcomment-22815396
Also thanks to @vcunat for bringing this to my attention:
https://github.com/NixOS/nixpkgs/commit/44c64fef16ed5#commitcomment-22813503
Although it is not entirely clear why Nix has killed the build prior to
finishing, it seems to be related to the process substition I was using.
So instead of using "exec touch", let's wrap this inside an if so we
don't exit too early.
Tested this against all sub-tests in nixos/tests/keymap.nix and also a
few configurations with wrong keyboard layout definitions.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Enumerating the symbols directory doesn't include variants, so we're now
basically doing what "localectl list-x11-keymap-layouts" does but we use
sed instead.
The reason I'm not using localectl directly is because the path to
rules/base.lst is hardcoded in the systemd source.
Of course, the XKB specification allows for much more complicated rules,
but at least this should cover the most basic ones including variants.
So the sed expression itself is just for listing the available layouts
and variants and we use a grep with -xF to match only full lines without
interpreting regular expressions.
This should again allow to set "dvorak" as the layout option.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @lheckemann
Fixes: #25526
Plugin and QML import paths were previously determined by NIX_PROFILES. Using
PATH instead allows Qt applications to work under nix-shell without further
modification.
- Reduce environment pollution with a separate $bin output containing programs,
plugins, and shared data. Libraries remain in $out and are not installed into
the environment.
- Only propagate build inputs as required.
Restructure the nixos-artwork to make it easy to selectively
incorporate other components from upstream without needing to download
the full package.
Until now only the Gnome_Dark wallpaper was included. Add other
wallpapers available in the package repository.
While systemd suggests using the pre-defined graphical-session user
target, I found that this interface is difficult to use. Additionally,
no other major distribution, even in their unstable versions, currently
use this mechanism.
The window or desktop manager is supposed to run in a systemd user service
which activates graphical-session.target and the user services that are
binding to this target. The issue is that we can't elegantly pass the
xsession environment to the window manager session, in particular
whereas the PassEnvironment option does work for DISPLAY, it for some
mysterious reason won't for PATH.
This commit implements a new graphical user target that works just like
default.target. Services which should be run in a graphical session just
need to declare wantedBy graphical.target. The graphical target will be
activated in the xsession before executing the window or display manager.
Fixes#17858.
Without this change there will be silent errors when enabling screen
sharing. The GUI thinks it enables the service when it in fact does not
(errors are seen in the system journal).
vino is already in the closure of gnome-control-center, so this is
basically free.
Configuration of screen sharing is done in GNOME control center.
When you have a setup consisting of multiple monitors, the default is
that the first monitor detected by xrandr is set to the primary monitor.
However this may not be the monitor you need to be set as primary. In
fact this monitor set to primary may in fact be disconnected.
This has happened for the original submitter of the pull request and it
affected these programs:
* XMonad: Gets confused with Super + {w,e,r}
* SDDM: Puts the login screen on the wrong monitor, and does not
currently duplicate the login screen on all monitors
* XMobar: Puts the XMobar on the wrong monitor, as it only puts the
taskbar on the primary monitor
These changes should fix that not only by setting a primary monitor in
xrandrHeads but also make it possible to make a different monitor the
primary one.
The changes are also backwards-compatible.
