Nixpkgs: Dvorak keyboard layout disappeared from NixOS/Xorg

[peti]

I have configured my keyboard layout via

services.xserver.layout = "dvorak";

in configuration.nix for ages, but todays nixos-rebuild complained that this layout no longer exists:

~~~
building path(s) ‘/nix/store/p4na6ps7zd3agf8hc4rrl55h94msdh44-xkb-layouts-exist’

Some of the selected keyboard layouts do not exist:

dvorak

Set services.xserver.layout to the name of an existing keyboard
layout (check /nix/store/dvxdqdsg8z9mfppam4drvhxpgy1vk8ir-xkeyboard-config-2.20/etc/X11/xkb/symbols for options).

builder for ‘/nix/store/5n01hrkp2hfb5mm1r5jmmn1j37fp86n2-xkb-layouts-exist.drv’ failed with exit code 255
~~~~

Alas, /nix/store/dvxdqdsg8z9mfppam4drvhxpgy1vk8ir-xkeyboard-config-2.20/etc/X11/xkb/symbols does not offer anything like "dvorak", so I now wonder what happened to this layout, why it is no longer available, and what I can do to get it back?

P.S.: I was trying to build nixos-unstable at c5badb123a.

[tohl]

services.xserver.layout has been broken since 17.03 for me. I think
somebody already created an issue for this/something similar.

[7c6f434c]

Hm, didn't know that would work… I thought that dvorak has to be specified as

  services.xserver = {
    layout = "us";
    xkbVariant = "dvorak";
  };

when I was merging #23709 … Should it be reverted then?

The layout didn't really go away, but the check added assumes one specific way of choosing the layout (the one that is usually documented in relation to X).

@lheckemann

[lheckemann]

Sorry about that!

I'll have a look at getting the checker to work precisely like xkb does it. In the meantime, it could be reverted if it's acutely causing major issues, but given that at least for the dvorak case there's a workaround I don't think it's that bad? In any case, I'll have a look at fixing it this weekend.

[peti]

I've changed my configuration file to the style from https://github.com/NixOS/nixpkgs/issues/25526#issuecomment-299402708 and that works fine for the time being.

[aszlig]

This was broken since c5c0459a60c1e64afc66c3b76434b88961d67abb (#5638), so that check introduced there should probably be expanded to account for this.

[aszlig]

Oh, never mind, that's the commit @7c6f434c was already mentioning.

[aszlig]

Also, we should probably add the keymap VM tests to the tested jobset after this is fixed, to ensure something like this would block a channel update.

[aszlig]

Hm, this check is a bit harder to achieve, because the layout is actually parsed from the rules file rather than from the files in the symbols directory:

$ strace -f -e trace=file setxkbmap dvorak
...ld blurb...
access("/home/aszlig/.Xauthority", R_OK) = 0
open("/home/aszlig/.Xauthority", O_RDONLY) = 4
open("./rules/evdev-C.lst", O_RDONLY)   = -1 ENOENT (No such file or directory)
open("./rules/evdev.lst", O_RDONLY)     = -1 ENOENT (No such file or directory)
open("/nix/store/45p7lzf7ha1ax8wlxhl31v63k8k8hq5b-setxkbmap-1.3.1/share/X11/xkb/rules/evdev-C.lst", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/nix/store/45p7lzf7ha1ax8wlxhl31v63k8k8hq5b-setxkbmap-1.3.1/share/X11/xkb/rules/evdev.lst", O_RDONLY) = 4
open("/nix/store/45p7lzf7ha1ax8wlxhl31v63k8k8hq5b-setxkbmap-1.3.1/share/X11/xkb/rules/evdev-C", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/nix/store/45p7lzf7ha1ax8wlxhl31v63k8k8hq5b-setxkbmap-1.3.1/share/X11/xkb/rules/evdev", O_RDONLY) = 4

So in theory the most reliable way is to use setxkbmap, like this:

setxkbmap -print "$layout" | xkbcomp - - 3>&1 1>&2 2>&3 > /dev/null | sed -n -e '/^Error:/,/^[^\t ]/p'

If there are any errors this would print it to stdout, so checking for validity would be a matter of [ -z "$output" ].

Unfortunately, this will require an X display and thus would only work if we'd run it inside an XVFB, which I think is a bit too much for a small check.

Related: https://unix.stackexchange.com/a/43984

So in theory we could also parse the rule files, not sure which one is the better option.

Maybe @lheckemann or @7c6f434c has a better idea?

Also note from the above strace: Users can have their own rules which are not necessarily available at the time we're checking this.

[7c6f434c]

Re: user rules — given that the check is for the service, these are supposed to not be available.

Re: tests — that would also serve as the documentation for the parameter…

Maybe the check should just be dropped; the breakage it prevents is not that hard to recover from (X.org should stay in us layout and a single xkbmap is enough)

[lheckemann]

I'd say we have to reopen #5638 if we do remove it completely. The reason that this was added in the first place is that the naming is a bit confusing for some countries — e.g. it being uk in one place and gb in another for the United Kingdom layout (and I always forget which one!). Not having a clear message as to why it fails is a pain.

I think parsing the rules files would be better, and I wanted to look into that but haven't got very far yet. Could it be as simple as grep -E "$layout"'\s*=' ${cfg.xkbDir}/rules/evdev in addition to checking the symbols directory?

https://www.x.org/docs/XKB/XKBlib.pdf may also be relevant

[7c6f434c]

Well, there is also us(dvorak) notation that also works in principle.

[lheckemann]

Thanks @aszlig, sorry I never got around to fixing this.

[vcunat]

See https://github.com/NixOS/nixpkgs/commit/44c64fef16ed5#commitcomment-22813503 . /cc @aszlig and @lheckemann for the blocker.