x11, if you agree please CC archteams. marked amd64 stable.
I disagree heavily for personal reasons (I'm not part of x11 team). xkeyboard-config has two issues for me: a) It has completely broken layout switching with shortcuts for me (on two different machines as soon as I upgraded xkeyboard-config it broke). If I'm in secondary layout then both alts at once switches to primary, but if I'm using primary layout, then both alts at once do absolutely nothing - I have to grab a mouse, which doesn't really lend to the way I'm using USA layout 90% of the time and switch to estonian only for the words that contain estonian letters; I haven't had time to do any sort of debugging yet, which is why I unfortunately didn't get around to making sure a filed bug exists on this. b) xkeyboard-config-1.2 changes the translation domain handling in a way that libxklavier lower than 3.4 won't work with it. The last version in portage of libxklavier that has been in the tree for a while is version 3.3. I just added 3.5 to the tree 1-2 days ago, it's not ripe for stabilization alongside xkeyboard-config yet. However if xkeyboard-config-1.2 is going stable now, i will have to make an exception and ask that for libxklavier-3.5 already as well.
To clarify: "in a way that libxklavier lower than 3.4 won't work with it" means that libxklavier will not have any translations for the keyboard layout and other strings - it otherwise works but is out of place in an otherwise localized desktop, as that affects anything using libxklavier and showing strings from it, which includes libgnomekbd users, gnome-applets (keyboard indicator), gnome-screensaver, control-center (keyboard preferences) and KDE4 similar places (KDE4 starts making use of libxklavier)
Reverted to ~amd64, thanks for clarifying. Now there is no rush, take your time.
As a follow-up: upstream (Sergey V. Udaltsov) tracked this down after we chatted a bit, and this is http://bugs.freedesktop.org/show_bug.cgi?id=4927 biting hard now with xkeyboard-config-1.2 <svu> the thing is that in 1.2 we fixed some issue in xk-c <svu> but that fix exposed the old bug in xkb
Converting the bug to tracking that particular xkeyboard-config bug - I think that makes sense by now. These are supposed to give the same result and behaviour: <svu> 1. setxkbmap <your xkb configuration> <svu> 2. setxkbmap <your xkb configuration> -print | xkbcomp - :0 But 1) behaves like in GNOME - switching from keyboard does not work, but with 2) the problem disappears. CCing GNOME as this affects GNOME the most right now, and in the end might involve changes in libxklavier - svu is maybe going to investigate for a workaround soon for that xkm bug..
libxklavier-3.6 is going stable same time with GNOME 2.22, and as for the Comment #4 issue, upstream bug, it seems very quiet. x11, can we stable xkeyboard-config 1.2 or 1.3? current timebased release in stable is getting old, but i don't have a strong opinion about it.. so..
(In reply to comment #6) > libxklavier-3.6 is going stable same time with GNOME 2.22, and as for the > Comment #4 issue, upstream bug, it seems very quiet. > > x11, can we stable xkeyboard-config 1.2 or 1.3? current timebased release in > stable is getting old, but i don't have a strong opinion about it.. so.. > Sure, feel free to file a stable bug for 1.3 and CC archs.
1.2 was never stable, and we have 1.3 and 1.4 in ~arch now.. so closing
1.2 and EVERYTHING above that up to now is broken in this regard still.
That said, yes, we can't wait anymore with stabilization >=1.2 probably
