Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1919483
Summary: | kbd-legacy missing from installs which need keyboard layouts from it (switched layouts) | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Adam Williamson <awilliam> |
Component: | anaconda | Assignee: | Vendula Poncova <vponcova> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | high | Docs Contact: | |
Priority: | unspecified | ||
Version: | 34 | CC: | anaconda-maint-list, bugzilla, jonathan, kellin, mfabian, pbrobinson, petersen, robatino, vanmeeuwen+fedora, vcrhonek, vponcova, wwoods |
Target Milestone: | --- | Keywords: | i18n |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | openqa AcceptedBlocker | ||
Fixed In Version: | anaconda-34.24.1-1 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2021-03-22 15:05:10 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 1829024 |
Description
Adam Williamson
2021-01-23 00:49:07 UTC
> 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. |