startx display the following error: ===============%<=============== syntax error: line 1 of pc The XKEYBOARD keymap compiler (xkbcomp) reports: > Error: Error interpreting include file "pc" > Exiting > Abandoning symbols file "default" Errors from xkbcomp are not fatal to the X server ===============%<=============== the commands setxkbmap -model pc105 -layout ... relies on xkbcomp. This last one report the problem above due to the presence of (old ?) /usr/X11R6/lib/X11/xkb After removing /usr/X11R6/lib/X11/xkb and /usr/share/X11/xkb and re-emerging xkeyboard-config everything is working again! This bug has been reported (by someone else) upstream in Xorg's bugzilla here: https://bugs.freedesktop.org/show_bug.cgi?id=6124
Note that I previously emerged xkbdata to replace xkeyboard-config. And after I re-emerged xkeyboard-config in place of xkbdata. Maybe my other bug #129793 is also related to the presence of /usr/X11R6/lib/X11/xkb ?
See comment #4 in the upstream bug. We have no way to force deletion of protected configuration files, so we need to rely on users to do that.
For me, this *could* and *should* be fixed... Removing the protected directory /usr/share/X11/xkb was an additional check against potential old invalid files... But I really doubt it was the cause as I unmerged/emerged xkbdata/xkeyboard-config WHITOUT /usr/share/X11/xkb in CONFIG_PROTECT to be sure everything is clean and it didn't solve my problem when I did it. For me, /usr/X11R6/lib/X11/xkb is the problematic directory and as far as I know, this one is not protected and must be removed! In case it is better to ask the user to do so manually, why not using something similar as in /var/cvsroot/gentoo-x86/sys-apps/slocate/slocate-2.7-r8.ebuild where the ebuild force the user to take a manual action. For example: ===============%<=============== pkg_setup() { if [[ -d /usr/X11R6/lib/X11/xkb ]] ; then eerror "Directory /usr/X11R6/lib/X11/xkb should be" eerror "manually deleted/renamed/relocated before!" die "Manually remove /usr/X11R6/lib/X11/xkb" fi } ===============%<===============
The xorg-x11 ebuild enforces that /usr/X11R6 is just a symlink, so the xkb directory would have to exist at /usr/lib/X11/xkb. Is this what you mean?
(In reply to comment #4) > The xorg-x11 ebuild enforces that /usr/X11R6 is just a symlink, so the xkb > directory would have to exist at /usr/lib/X11/xkb. Is this what you mean? Yes, /usr/X11R6 is a symlink to ../usr as it should be, the problem is not there. I had to remove /usr/X11R6/lib/X11/xkb which is thus: /usr/lib/X11/xkb for xkbcomp to work correctly because it conflicted in some way (in fact, this is probably the bug) with /usr/share/X11/xkb/ that is installed by: $ qfile /usr/share/X11/xkb/ x11-base/xorg-server (/usr/share/X11/xkb) x11-misc/xkeyboard-config (/usr/share/X11/xkb) I don't really know if the bug is that /usr(/X11R6)/lib/X11/xkb have to be removed for xkbcomp to work or if xkbcomp should correctly compile the keymap using exclusively the correct directory: /usr/share/X11/xkb/ For me, the two should be fixed as /usr(/X11R6)/lib/X11/xkb seems to be completely useless and $ qfile /usr/X11R6/lib/X11/xkb and $ qfile /usr/lib/X11/xkb returns no package! I suppose it was installed by Xorg v6 (non modular) and that it was not removed by unmerging the non-modular version. (CONFIG_PROTECT'ed at this time ??) Maybe it is the role to virtual/x11 or x11-misc/xkeyboard-config or x11-misc/xkbdata to remove it ?
Fixed using your suggestion, Patrick!
Not fixed after deleting /usr/X11R6/lib/X11/xkb, emerge --unmerge xkbdata and emerge xkeyboard-config. (i understood that this is what you suggested as solution). Latin-be1 keyboard layout is however OK. My only problem is the error announcement at boot.
(In reply to comment #7) > Not fixed after deleting /usr/X11R6/lib/X11/xkb, emerge --unmerge xkbdata and > emerge xkeyboard-config. (i understood that this is what you suggested as > solution). > Latin-be1 keyboard layout is however OK. My only problem is the error > announcement at boot. > If you still have this issue, it is likely that you've encountered something different. Feel free to file a new bug.
