• Re: [gentoo-user] xkeyboard-config overwrote files in CONFIG_PROTECT-ed

    From Michael@21:1/5 to All on Sun Jul 27 14:02:14 2025
    On Sunday, 27 July 2025 13:18:34 British Summer Time gevisz wrote:
    On July 25, 2025 my custom keyboard layout files located
    in /usr/share/X11/xkb/symbols/ were unexpectedly overwritten
    during system despite the fact that they were config-protected:
    # emerge --info | grep CONFIG_PROTECT
    CONFIG_PROTECT="/etc /usr/share/X11/xkb/symbols/ /usr/share/config /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release
    /etc/revdep-rebuild /etc/sandbox.d /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c"

    ChatGPT says to me that it was done when
    x11-misc/xkeyboard-config-2.45-r1 was updated.

    I do not use etc-update or dispatch-conf, and there were no ._cfg*
    files left behind — the overwrite happened silently.

    After examining the ebuild, ChatGPT noticed that src_install() uses meson_src_install,
    and then moves the entire installed /usr/share/X11/xkb tree to /usr/share/X11/xkb.workaround/
    as a workaround for bug #957712. In pkg_preinst(), that tree is then
    forcibly moved back to /usr/share/X11/xkb, overwriting any existing
    files.

    This manual move bypasses Portage’s CONFIG_PROTECT mechanism entirely,
    as pkg_preinst()
    runs before Portage has a chance to apply config file protection.

    While I understand the intention behind the workaround, the result was
    a total loss of my custom layout files,
    despite explicitly protecting the directory. I’ve been using Gentoo
    for 12 years, and I have never been so
    disappointed by the Gentoo as I was when this happened to say the least.

    Is there a Gentoo-compliant way to preserve customized layouts that
    replace system-provided ones under such circumstances?

    Thanks in advance for any suggestions or guidance.

    The offending lines in /var/db/repos/gentoo/x11-misc/xkeyboard-config/ xkeyboard-config-2.45-r1.ebuild are:
    ====================================
    ...
    68 src_install() {
    69 meson_src_install
    70
    71 # Workaround for portage's collision checks, see pkg_preinst (bug #957712)
    72 mv "${ED}"/usr/share/X11/xkb{,.workaround} || die
    73 }
    74
    75 pkg_preinst() { 76 # Avoid touching EROOT if not needed, and use -f just-in-case anyway
    77 if [[ -d ${EROOT}/usr/share/X11/xkb && ! -L ${EROOT}/usr/share/ X11/xkb ]]; then
    78 rm -rf "${EROOT}"/usr/share/X11/xkb || die
    79 fi
    80 mv "${ED}"/usr/share/X11/xkb{.workaround,} || die
    81 }
    ==============

    I suggest you re-open this bug[1], because its workaround may have been somewhat inconsiderate as to potential impacts.

    However, unlike files in /etc/ subdirectories, files under /usr/share/ are generally expected to be overwritten by package updates. I see the wiki[2] suggests to create/edit files in place for custom keyboard layouts, but I wonder if it would have been safer for a symlink pointing to /etc where custom xkb config files could be stored more safely.

    [1] https://bugs.gentoo.org/957712
    [2] https://wiki.gentoo.org/wiki/Keyboard_layout_switching
    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCAAdFiEEXqhvaVh2ERicA8Ceseqq9sKVZxkFAmiGI1YACgkQseqq9sKV ZxnavA//XlaYins+gt/93s+qKyx5C3j0mrC+h5dfTDsriUyPaioWsatlGHFOoovG o3yUTmMS4zV/VV6Qgk0+siFLAu0dq6UrmT604YGxryuTToMU2zq78oT0FoBCM52U Q6+P/6ZLRZZx4gKblWYIJJ84t3CWE/3JuMAk7xRlOV8Y63z+NEEJJHGcnZy6knWa 3XFZm+mPus5uliUlj7R6g3YA3rHM3i9BkySrM+zvMI0rjlUTV62WAi6EMaxJZ6en an2dwzIJnOqUQt9iTrkod+ktEGvuMO+1sqEiS3aiyKKbDA84iqb5iO4gPFYpkvwM qMib11olMDvLaGgjuUPAqPFPbmECiLKoenDnK7VUxfjdOzP8w5X1J3sNBSqtI+fJ yl2bM2hvr/InJB3SEFUSiVz2MhE/1xNyQvtymm3+TfZPwFhcvaGxiTa1gB2p7W0b PV5oGlFceLQPGX5DlQv8q+oyQMMrm+yO9ww72Qbtfs+BiMtRalH30QI6nD1O77wR eXl5yWwADAeOoycWp6gSKQxhqUMHpvj3F/9ZsZ4eIryKq0NqK2K9E9iT7kw/zXlB TZNUu/o76Ks8+ZgiZgDkeAayGwOKmlmpLAdYHS4t2SEo87ytYLbOmr4QeiSPu0Yd qg1KcDRO70OMsC7UoKVz7jWCOdBEhdwfGuq51OPYANGR0RbtLE0=
    =Ro/O
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From James Cloos@21:1/5 to All on Mon Jul 28 02:50:01 2025
    And this is also illustrative:

    xkbcli how-to-type --layout oo �
    xkbcommon: ERROR: [XKB-338] Couldn't find file "symbols/oo" in include paths xkbcommon: ERROR: [XKB-338] 1 include paths searched:
    xkbcommon: ERROR: [XKB-338] /usr/share/X11/xkb
    xkbcommon: ERROR: [XKB-338] 3 include paths could not be added:
    xkbcommon: ERROR: [XKB-338] /home/cloos/.config/xkb
    xkbcommon: ERROR: [XKB-338] /home/cloos/.xkb
    xkbcommon: ERROR: [XKB-338] /etc/xkb
    xkbcommon: ERROR: [XKB-769] Abandoning symbols file "(unnamed map)"
    xkbcommon: ERROR: Failed to compile xkb_symbols
    xkbcommon: ERROR: [XKB-822] Failed to compile keymap
    ERROR: Failed to create XKB keymap

    (oo chosen to be an intentional error, just to see what is reports.)

    the 3 paths which could not be added are not extant here. if they were
    they should get used.

    -JimC
    --
    James Cloos <[email protected]>
    OpenPGP: https://jhcloos.com/0x997A9F17ED7DAEA6.asc

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From James Cloos@21:1/5 to All on Mon Jul 28 03:00:01 2025
    I just thought:

    is it not working in somethnig like a gnome or kde application?

    those so-called "desktop" environments might be doing their own thing
    and ignoring the xkb library code. Even gtk or qt might do so.

    it that is the case, one'd need to look in the src of such projects to
    see what they support.

    i'm only really up on the xorg stuff myself.

    -JimC
    --
    James Cloos <[email protected]>
    OpenPGP: https://jhcloos.com/0x997A9F17ED7DAEA6.asc

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From James Cloos@21:1/5 to All on Mon Jul 28 02:40:01 2025
    I just looked at the file /usr/lib64/libxkbcommon.so with strings(1).

    (The src is better, but this was quicker.)

    It includes these strings in succession:

    ,----
    | Include path added: %s
    | Include path failed: %s (%s)
    | /etc/xkb
    | XKB_CONFIG_EXTRA_PATH
    | /usr/share/X11/xkb
    | XKB_CONFIG_ROOT
    | %s/xkb
    | %s/.config/xkb
    | %s/.xkb
    | XKB_LOG_LEVEL
    `----

    So /etc/xkb ought to work. As ought ~/.xkb and ~/.config/xkb.

    Ang you should be able to use the environmental variables (set them
    before starting Xorg) XKB_CONFIG_EXTRA_PATH to add another path, or XKB_CONFIG_ROOT to completely replace /usr/share/X11/xkb.

    I also tried running:

    ,----
    | strace xkbcli how-to-type --layout us U+0229|&fgrep /etc
    `----

    which invluded the line:

    ,----
    | newfstatat(AT_FDCWD, "/etc/xkb", 0x7ffdcd70b0d0, 0) = -1 ENOENT (No such file or directory)
    `----

    which strongly suggests /etc/xkb is supported. At least by default.

    Did anything show up in your /var/log/Xorg.0.log when you tried /etc/xkb?

    -JimC
    --
    James Cloos <[email protected]>
    OpenPGP: https://jhcloos.com/0x997A9F17ED7DAEA6.asc

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)