Hide Forgot
Through Fedora 33, kbd had a dependency on kbd-legacy, so it got pulled into basically all installs. In Fedora 34, that dependency was removed, per https://bugzilla.redhat.com/show_bug.cgi?id=1891811 . There's no other mechanism anywhere I can find to install kbd-legacy in any circumstance, so now it's basically *never* installed. This is a problem, because in some installs, we *do* need it. Specifically, we need it for languages that need "switched" keyboard layouts to enter both Latin characters and characters from a different alphabet...e.g. Russian, so this is not a niche thing. For those languages, the layouts in kbd-legacy are not really "legacy", they are the only usable layouts. We actually throw away the xkb-converted layouts for these languages at package build time: # wipe converted layouts which cannot input ASCII (#1031848) zgrep -L "U+0041" $RPM_BUILD_ROOT%{kbd_datadir}/keymaps/xkb/* | xargs rm -f because they are useless. We entirely rely on the "legacy" layouts to be available in this case. Since kbd-legacy is no longer installed, right now if you install in Russian or run "loadkeys ru", you get the xkb-converted xkb/ru-cv_latin.map.gz layout, which can only input Latin characters. It cannot input Cyrillic at all. What you're supposed to get is legacy/i386/qwerty/ru.map.gz , which is the correct normal Russian layout that inputs Latin characters by default and switches to Cyrillic characters if you hit ctrl-shift. The easiest and safest way to fix this really is just to put the dep back. Other choices would be to try and create a refined subpackage that only contains the "useful" legacy layouts (perhaps all the counterparts to the xkb-converted ones we throw away?), or make anaconda install kbd-legacy when needed (though that doesn't help someone who installs in another language but wants "loadkeys ru" to do the expected thing). Proposing as a Final blocker as a violation of https://fedoraproject.org/wiki/Fedora_34_Final_Release_Criteria#Keyboard_layout_configuration - "If a particular keyboard layout has been configured for the system, that keyboard layout must be used: ... When unlocking encrypted storage volumes during boot (but see footnotes) ... When logging in at a console". We're clearly violating the intent of that criterion here.
> The easiest and safest way to fix this really is just to put the dep back. > Other choices would be to try and create a refined subpackage that only > contains the "useful" legacy layouts (perhaps all the counterparts to the > xkb-converted ones we throw away?), or make anaconda install kbd-legacy when > needed (though that doesn't help someone who installs in another language > but wants "loadkeys ru" to do the expected thing). If we put it back can we do it via comps or at the very least a weak dependency.
> For those languages, the layouts in kbd-legacy are not really "legacy", they > are the only usable layouts. We actually throw away the xkb-converted > layouts for these languages at package build time: Is Russian the only affected language layout? What's the non legacy way the other languages do this?
Russian is the most common, but there are other 'switched' layouts. Other languages don't have the problem because they don't need to switch between multiple layouts - any language which is mostly typed using Latin characters (plus maybe a few extra or accented ones, but these are just accessed via modifiers on the fly), or where you can't *type* the other alphabet but use an input method (because those just don't have console equivalents and it's normal to only be able to type Latin characters at the console). The reason there's an issue is that "switching" works differently between kbd and xkb. xkb has the concept of conveniently switching between *multiple* layouts using a key combo, so in xkb, the "ru" layout *only* has mappings for Cyrillic characters (and commas and so on) - no Latin characters - and you switch to the "us" layout to input Latin characters. But kbd layouts don't have this concept; you can't conveniently switch kbd layouts on the fly. So the 'legacy' "ru" layout has mappings for both Cyrillic *and* Latin characters, on different 'levels', and also maps a key combo to switch between the levels. What would really be great, and avoid all the pain that comes from this (it's a constant source of problems), is if the console and X/Wayland input systems were more similar; there've been moves in the past to make something for console input that works like xkb does, but AFAIK it's never quite come to anything. Others are Macedonian, Ukrainian, Bulgarian, Czech (though apparently lots of Czech people don't bother and just use US layout), Greek, Bielorussian (by), Kazakh and Khmer.
> > The easiest and safest way to fix this really is just to put the dep back. > > Other choices would be to try and create a refined subpackage that only > > contains the "useful" legacy layouts (perhaps all the counterparts to the > > xkb-converted ones we throw away?) I don't like idea of splitting it even more much. Currently -legacy matches kbd upstream released keymaps and it's not a dead set - still new keymaps are requested by users and added there. > > , or make anaconda install kbd-legacy when > > needed (though that doesn't help someone who installs in another language > > but wants "loadkeys ru" to do the expected thing). I lean towards this solution. If one wants "loadkeys ru" to do expected thing, he could install -legacy manually then. > > > > If we put it back can we do it via comps or at the very least a weak > > dependency. Fine by me too. > > What would really be great, and avoid all the pain that comes from this (it's > > a constant source of problems), is if the console and X/Wayland input systems > > were more similar; there've been moves in the past to make something for console > > input that works like xkb does, but AFAIK it's never quite come to anything. Yeah, but I'm afraid that we cannot expect any improvements here:(
(In reply to Vitezslav Crhonek from comment #4) > > > The easiest and safest way to fix this really is just to put the dep back. > > > Other choices would be to try and create a refined subpackage that only > > > contains the "useful" legacy layouts (perhaps all the counterparts to the > > > xkb-converted ones we throw away?) > > I don't like idea of splitting it even more much. Currently -legacy matches > kbd upstream released keymaps and it's not a dead set - still new keymaps > are requested by users and added there. Could we work with the russian community to get a non legacy keymap added upstream then?
(In reply to Peter Robinson from comment #5) > (In reply to Vitezslav Crhonek from comment #4) > > > > The easiest and safest way to fix this really is just to put the dep back. > > > > Other choices would be to try and create a refined subpackage that only > > > > contains the "useful" legacy layouts (perhaps all the counterparts to the > > > > xkb-converted ones we throw away?) > > > > I don't like idea of splitting it even more much. Currently -legacy matches > > kbd upstream released keymaps and it's not a dead set - still new keymaps > > are requested by users and added there. > > Could we work with the russian community to get a non legacy keymap added > upstream then? It's the opposite - non legacy keymap (generated during kbd build from xkb layout) is unusable in console for a group of languages and thus original upstream keymap shipped in -legacy is needed. But in my opinion removing the dependency was correct - we just need a mechanism that ensures that -legacy is installed for languages that needs it for proper functioning in console.
Right, don't fixate on the term "legacy", it's a bit misleading. Though I don't know what better to call them :) It sounds as if we're leaning towards a solution like "make anaconda install legacy if it looks like we're going to need it", so I'm reassigning the bug to anaconda - if we decide on something else we can change it.
Hi, Anaconda doesn't install kbd (directly, I guess it is installed as part of the core group), so it will be a little weird to install something called kbd-legacy. Also, how can Anaconda detect that "it looks like we're going to need it"? Anyway, Anaconda installs langpacks. Couldn't the langpacks require the kbd-legacy package?
"Also, how can Anaconda detect that "it looks like we're going to need it"?" That part we're already doing since the last bug in this area: https://github.com/rhinstaller/anaconda/commit/40a604afb9b2573c8f9bd93d5a35f34d29dd245e that's pretty much detecting this case.
+3 votes in https://pagure.io/fedora-qa/blocker-review/issue/213 , marking as accepted Final blocker.
Fixed in a pull request: https://github.com/rhinstaller/anaconda/pull/3152
This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle. Changing version to 34.
Oh, yeah, this has been fixed for a while I believe.
Apparently it didn't get fixed, or something else went wrong. https://bugzilla.redhat.com/show_bug.cgi?id=1955162
It's definitely fixed, or the openQA Russian install test would fail. It tests this.
agh, I see the problem. Updated the other bug. It's not actually the same as this bug, but the result is similar.