Bug#1038762: [src:systemd]: login (gnome) uses wrong keyboard layout

2023-06-21 Thread Lyndon Brown
On Wed, 2023-06-21 at 03:06 +0200, Michael Biebl wrote:
> As a quick/temporary workaround, you can run
> 
> ln -s /etc/default/keyboard /etc/vconsole.conf

Indeed removing the the latter file and creating the suggested symlink
works. Thanks.

Should it be of interest to you, the `localectl` output before doing
this was as follows:

System Locale: LANG=en_GB.UTF-8
VC Keymap: uk
   X11 Layout: (unset)

And after:

System Locale: LANG=en_GB.UTF-8
VC Keymap: (unset)
   X11 Layout: gb
X11 Model: pc105



Bug#1038762: [src:systemd]: login (gnome) uses wrong keyboard layout

2023-06-20 Thread Michael Biebl

Am 21.06.23 um 03:02 schrieb Michael Biebl:

Am 21.06.23 um 02:34 schrieb Lyndon Brown:

The latest package update (to unstable) has broken login keyboard-
layout support. I'm marking this as critical due to the chaotic
potential for locking many users out of their accounts / systems, some
of whom unlike myself may have no clue what's wrong and how to get
around it, if they can.


Afaics, this only affects gdm, which directly queries localed, which no 
longer reports the keymap state:



$ localectl
System Locale: LANG=C.UTF-8
     VC Keymap: (unset)
    X11 Layout: (unset)

This is a result of
https://salsa.debian.org/systemd-team/systemd/-/commit/8d0405b0cfb9c84791da5b8f7288453e23624acf


Hm, actually, it seems to be the result of dropping
debian/patches/debian/Use-Debian-specific-config-files.patch

See the discussion in 
https://salsa.debian.org/systemd-team/systemd/-/merge_requests/189


As a quick/temporary workaround, you can run

ln -s /etc/default/keyboard /etc/vconsole.conf




OpenPGP_signature
Description: OpenPGP digital signature


Bug#1038762: [src:systemd]: login (gnome) uses wrong keyboard layout

2023-06-20 Thread Michael Biebl

Am 21.06.23 um 02:34 schrieb Lyndon Brown:

The latest package update (to unstable) has broken login keyboard-
layout support. I'm marking this as critical due to the chaotic
potential for locking many users out of their accounts / systems, some
of whom unlike myself may have no clue what's wrong and how to get
around it, if they can.


Afaics, this only affects gdm, which directly queries localed, which no 
longer reports the keymap state:



$ localectl
System Locale: LANG=C.UTF-8
VC Keymap: (unset)
   X11 Layout: (unset)

This is a result of
https://salsa.debian.org/systemd-team/systemd/-/commit/8d0405b0cfb9c84791da5b8f7288453e23624acf

See the discussion in 
https://salsa.debian.org/systemd-team/systemd/-/merge_requests/189






OpenPGP_signature
Description: OpenPGP digital signature


Bug#1038762: [src:systemd]: login (gnome) uses wrong keyboard layout

2023-06-20 Thread Lyndon Brown
package: src:systemd
version: 253-3
severity: critical

The latest package update (to unstable) has broken login keyboard-
layout support. I'm marking this as critical due to the chaotic
potential for locking many users out of their accounts / systems, some
of whom unlike myself may have no clue what's wrong and how to get
around it, if they can.

I'm from the UK and my locale / keyboard-layout is setup accordingly.

Systemd packages were updated from 252.11-1 to 253-3 today on my
unstable/sid system. I happened to hit an OOM condition that killed my
user session a little while after having installed these updates,
kicking me back to the Gnome login screen. I tried to log back in but I
couldn't. After many tries, confident I was typing in my password
correctly, and rebooting having made no difference, I toggled the
feature to see what I was typing and discovered that a certain special
character was not matching what I typed. I was able to find a key with
which to enter the correct symbol and thus was able to get back in. I
presume it's defaulting to US layout for some reason.

I checked out the updates that had been installed today and I then
tried downgrading all of the systemd packages (listed below) to those
from testing (252.11-1). This solves the problem.

With 253-3 installed, if I lock my account it seems to be using the
correct layout, but if I logout or reboot then it's using the wrong
one. With the 252.11-1 downgrade everything uses the correct layout
again. Reinstating 253-3 the problem is back, confirming that the
problem relates to the upgrade of systemd packages.

Apt package log (systemd only):
Install: systemd-dev:amd64 (253-3, automatic)
Upgrade: udev:amd64 (252.11-1, 253-3), systemd-container:amd64 (252.11-
1, 253-3), libnss-myhostname:amd64 (252.11-1, 253-3), libpam-
systemd:amd64 (252.11-1, 253-3), libsystemd0:amd64 (252.11-1, 253-3),
libudev-dev:amd64 (252.11-1, 253-3), systemd:amd64 (252.11-1, 253-3),
libudev1:amd64 (252.11-1, 253-3), libnss-mymachines:amd64 (252.11-1,
253-3), libsystemd-shared:amd64 (252.11-1, 253-3), systemd-sysv:amd64
(252.11-1, 253-3), libsystemd-dev:amd64 (252.11-1, 253-3)

Apt term log (systemd only):
Preparing to unpack .../0-libnss-mymachines_253-3_amd64.deb ...
Unpacking libnss-mymachines:amd64 (253-3) over (252.11-1) ...
Preparing to unpack .../1-systemd-container_253-3_amd64.deb ...
Unpacking systemd-container (253-3) over (252.11-1) ...
Preparing to unpack .../2-systemd-oomd_253-3_amd64.deb ...
Unpacking systemd-oomd (253-3) over (252.11-1) ...
Preparing to unpack .../3-libpam-systemd_253-3_amd64.deb ...
Unpacking libpam-systemd:amd64 (253-3) over (252.11-1) ...
Preparing to unpack .../4-systemd_253-3_amd64.deb ...
Unpacking systemd (253-3) over (252.11-1) ...
Preparing to unpack .../5-libsystemd-shared_253-3_amd64.deb ...
Unpacking libsystemd-shared:amd64 (253-3) over (252.11-1) ...
Preparing to unpack .../6-libsystemd0_253-3_amd64.deb ...
Unpacking libsystemd0:amd64 (253-3) over (252.11-1) ...
Setting up libsystemd0:amd64 (253-3) ...
Preparing to unpack .../archives/udev_253-3_amd64.deb ...
Unpacking udev (253-3) over (252.11-1) ...
Selecting previously unselected package systemd-dev.
Preparing to unpack .../systemd-dev_253-3_all.deb ...
Unpacking systemd-dev (253-3) ...
Setting up systemd-dev (253-3) ...
Setting up libsystemd-shared:amd64 (253-3) ...
Setting up systemd (253-3) ...
Installing new version of config file /etc/systemd/journald.conf ...
Installing new version of config file /etc/systemd/system.conf ...
Installing new version of config file /etc/systemd/user.conf ...
Preparing to unpack .../systemd-sysv_253-3_amd64.deb ...
Unpacking systemd-sysv (253-3) over (252.11-1) ...
Preparing to unpack .../libsystemd-dev_253-3_amd64.deb ...
Unpacking libsystemd-dev:amd64 (253-3) over (252.11-1) ...
Preparing to unpack .../libudev-dev_253-3_amd64.deb ...
Unpacking libudev-dev:amd64 (253-3) over (252.11-1) ...
Preparing to unpack .../libudev1_253-3_amd64.deb ...
Unpacking libudev1:amd64 (253-3) over (252.11-1) ...
Setting up libudev1:amd64 (253-3) ...
Preparing to unpack .../libnss-myhostname_253-3_amd64.deb ...
Unpacking libnss-myhostname:amd64 (253-3) over (252.11-1) ...
Setting up systemd-sysv (253-3) ...
Setting up udev (253-3) ...
Setting up libnss-myhostname:amd64 (253-3) ...
Setting up libudev-dev:amd64 (253-3) ...
Setting up systemd-container (253-3) ...
Setting up libpam-systemd:amd64 (253-3) ...
Setting up systemd-oomd (253-3) ...
Setting up libsystemd-dev:amd64 (253-3) ...
Setting up libnss-mymachines:amd64 (253-3) ...
Processing triggers for initramfs-tools (0.142) ...
update-initramfs: Generating /boot/initrd.img-6.3.0-1-amd64
Processing triggers for libc-bin (2.36-9) ...
Processing triggers for man-db (2.11.2-2) ...
Processing triggers for dbus (1.14.8-1) ...

I noticed that the systemd changelog for 253-rc2-1 states "make
/etc/default/locale a symlink to /etc/locale.conf". With 253-3
installed I indeed have this symlink (with owner