no known regressions
ppc stable
ppc64 stable
Stable on alpha.
amd64 stable
(In reply to comment #4) > amd64 stable > upgrading today, after reboot, I stumbled into an US layout on my german keyboard; my previously working setting to --> /usr/share/keymaps/i386/qwertz/de-latin1.map.gz seemed to be ignored: --- /cite --- # /etc/conf.d/keymaps # Use KEYMAP to specify the default console keymap. There is a complete tree # of keymaps in /usr/share/keymaps to choose from. # --> /usr/share/keymaps/i386/qwertz/de-latin1.map.gz - mkn. # KEYMAP="us" KEYMAP="de-latin1" --- /cite --- Masking sys-apps/kbd-1.15 and downgrading to sys-apps/kbd-1.13-r1, my kbd worked perfectly like a charme again ;(
init scripts also use old symlinked versions of setfont / loadkeys i edit the init to use /usr/bin was before just /bin in the path after this no errors in my setup
(In reply to comment #6) > init scripts also use old symlinked versions of setfont / loadkeys > > i edit the init to use /usr/bin was before just /bin in the path > > after this no errors in my setup > I have the same issue too.I modified the initscript and all works fine now.
kbd-1.15 is incompatible with the latest stable baselayout-1.12.11.1, so I guess this stable request is too fast. The problem is in /etc/init.d/keymaps script, which depends on /bin/loadkeys, but kbd-1.15 provides /usr/bin/loadkeys. Please fix this, otherwise you will see a lot of duplicated bug reports soon. BR, /Adam
Was just about to file one :)
(In reply to comment #8) > kbd-1.15 is incompatible with the latest stable baselayout-1.12.11.1 ... Perhaps you might consider sometimes putting this release back to "~" until this has been sorted out? Lots of people begin to stumble into it, unnecessarily. There seems to be need for a kbd-1.15-r1 anyway ... Kind regards Manfred
(In reply to comments #5, #6, #7, #8, #9) The same thing happened to me and tanderson; /etc/init.d/keymaps is hardcoded to look for /bin/loadkeys. Interestingly, /etc/runlevels/boot/keymaps looks for /usr/bin/loadkeys, so it's properly set up. Only the init.d script isn't. And because it can't find loadkeys at boot, consolefont and a couple of other initscripts aren't run, either, as they depend on /etc/init.d/keymaps working correctly. I'd like to get an -r1 version stabled that includes the necessary init.d config fix, please.
I've reverted the amd64 stable keyword until this issue is sorted out. I fail. :(
Mike, I might be missing something here but don't we need loadkeys to exist in /bin for the people that have encrypted volumes that use passwords for example. Otherwise their /usr might be encrypted or might mount after an encrypted volume and then they would have to type their password in using the "default" keymap instead of their native keymap? So then this would be a regression for the kbd package. I've been away for some time now so I might be missing something. Let me know.
(In reply to comment #12) > I've reverted the amd64 stable keyword until this issue is sorted out. Thomas, thanks a lot ! > I fail. :( Hey ... 'Ash Wednesday' was yesterday ;) , so keep your head up in the sky !! (In reply to comment #13) > ... don't we need loadkeys to exist in /bin ... Would like to encourage this: Not seldom, esp. on (remote) (virtual) server machines, I still define multiple separated partitions, "/usr" defenitely being one of them, and expect to be able to get the very core system ( "/boot" and "/" , the latter including /etc) up working even without /usr being mounted, e.g. because its fs might have become corrupted in any way. > ... this would be a regression ... I wholeheartedly agree upon this.
newer baselayout-1 is stabilizing which has the path issue fixed Doug: loadkeys is useless if you cant get at the keymaps which are already in /usr/share/
x86 stable
Stable for HPPA.
This stabilization is breaking es keymap: http://bugs.gentoo.org/show_bug.cgi?id=293228
arm stable
ia64/m68k/s390/sh/sparc stable, closing
