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 - kbd-legacy missing from installs which need keyboard layouts from it (switched layouts)
Summary: kbd-legacy missing from installs which need keyboard layouts from it (switche...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 34
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Vendula Poncova
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: openqa AcceptedBlocker
Depends On:
Blocks: F34FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2021-01-23 00:49 UTC by Adam Williamson
Modified: 2021-05-04 06:35 UTC (History)
12 users (show)

Fixed In Version: anaconda-34.24.1-1
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-03-22 15:05:10 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Adam Williamson 2021-01-23 00:49:07 UTC
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.

Comment 1 Peter Robinson 2021-01-23 10:13:10 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.

Comment 2 Peter Robinson 2021-01-23 10:14:30 UTC
> 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?

Comment 3 Adam Williamson 2021-01-23 18:14:29 UTC
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.

Comment 4 Vitezslav Crhonek 2021-01-25 08:07:28 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?)

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:(

Comment 5 Peter Robinson 2021-01-27 23:35:37 UTC
(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?

Comment 6 Vitezslav Crhonek 2021-01-28 07:02:07 UTC
(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.

Comment 7 Adam Williamson 2021-01-28 17:37:06 UTC
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.

Comment 8 Vendula Poncova 2021-02-03 16:50:36 UTC
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?

Comment 9 Adam Williamson 2021-02-03 20:51:18 UTC
"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.

Comment 10 Adam Williamson 2021-02-05 00:06:47 UTC
+3 votes in https://pagure.io/fedora-qa/blocker-review/issue/213 , marking as accepted Final blocker.

Comment 11 Vendula Poncova 2021-02-08 11:47:27 UTC
Fixed in a pull request: https://github.com/rhinstaller/anaconda/pull/3152

Comment 12 Ben Cotton 2021-02-09 16:13:31 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle.
Changing version to 34.

Comment 13 Adam Williamson 2021-03-22 15:05:10 UTC
Oh, yeah, this has been fixed for a while I believe.

Comment 14 Chris Murphy 2021-05-04 01:48:21 UTC
Apparently it didn't get fixed, or something else went wrong.
https://bugzilla.redhat.com/show_bug.cgi?id=1955162

Comment 15 Adam Williamson 2021-05-04 06:20:43 UTC
It's definitely fixed, or the openQA Russian install test would fail. It tests this.

Comment 16 Adam Williamson 2021-05-04 06:35:41 UTC
agh, I see the problem. Updated the other bug. It's not actually the same as this bug, but the result is similar.


Note You need to log in before you can comment on or make changes to this bug.