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 891487 - Anaconda keyboard layout list is missing many offered by GNOME, including some associated with languages for which we offer a translation
Summary: Anaconda keyboard layout list is missing many offered by GNOME, including som...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 18
Hardware: All
OS: All
unspecified
high
Target Milestone: ---
Assignee: Vratislav Podzimek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedNTH
Depends On:
Blocks: F18-accepted, F18FinalFreezeExcept
TreeView+ depends on / blocked
 
Reported: 2013-01-03 06:27 UTC by Adam Williamson
Modified: 2014-02-05 23:18 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-02-05 23:18:39 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)

Description Adam Williamson 2013-01-03 06:27:37 UTC 
In the course of testing https://bugzilla.redhat.com/show_bug.cgi?id=889562 , it became apparent that, while both GNOME and anaconda are deriving their list of available keyboard layouts from xkb in some way, they're not really doing it the same - and GNOME appears to be doing it better.

The ordering is somewhat different, the displayed name is slightly different, but most obviously, GNOME offers quite a lot of layouts anaconda does not.

I went through every language offered on the very first page of the installer, checking the 'Set keyboard to default layout for selected language.' checkbox each time and proceeding to the main hub to see what keyboard would be selected. Here are the three languages I found appeared to have a 'matching' layout listed in GNOME, but no matching layout available to anaconda.

Assamese (India)
Croatian (Croatia)
Marathi (India)

For all of these, if you search in the GNOME keyboard layout tool, you will find what appear to be matching layouts. These layouts do not appear in anaconda's list. The Indian ones both have (m17n) in the name and result in some kind of ibus configuration, so that could be why anaconda is not picking them up. But Croatian seems to be just the XkbLayout 'hr', so I have no idea why anaconda is missing that.

These are just the tip of the iceberg, though, there are lots of other layouts GNOME has that anaconda is missing. It's easy enough to side-by-side the lists, with anaconda running in a VM and GNOME on the host system, and compare. Could be to do with restricted package set available to the installer environment somehow, I suppose.

The Assamese and Marathi translations are complete or close to it, so it's a shame we're not setting their keyboard layouts correctly. Nominating as NTH.
Comment 1 Vratislav Podzimek 2013-01-03 14:06:30 UTC 
We are just using libxklavier's foreach_language_variant [1]. I have no idea why those layouts are missing.

[1] http://xlibs.freedesktop.org/xkbdesc/doc/XklConfigRegistry.html#xkl-config-registry-foreach-language-variant
Comment 2 Adam Williamson 2013-01-03 18:55:41 UTC 
I'm guessing the ibus-based ones may be missing as we don't actually have ibus in the anaconda environment, but that's a pure guess. I have no idea about Croatian.
Comment 3 Adam Williamson 2013-01-03 19:50:25 UTC 
Discussed at 2012-01-03 go/no-go meeting: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-01-03/f18_final_gono-go_meeting.2013-01-03-17.01.log.txt . Accepted as NTH: this should be a safe fix and improves keyboard mapping during install which is obviously desirable and not fixable with an update.
Comment 4 Vratislav Podzimek 2013-01-07 11:55:23 UTC 
Thanks to Rui Matos I now know where the problem lies here. The thing is that for the Croatian layout (and probably also the others) its XML definition doesn't include the language specification and is therefore not listed by the foreach_language_variant. It can be gotten by the foreach_layout and foreach_layout_variant, but this way we still don't get the information that Croatian layout is for the Croatian language (unless doing some "substring magic").

So while I can add the code that would add the Croatian layout to the list of available layouts I cannot make it selecting that layout for the Croatian language by default. (without some "substring magic")
Comment 5 Adam Williamson 2013-01-07 20:47:48 UTC 
It sounds like it would be better just to fix the Croatian layout in xkb, maybe? Can we get a list of layouts which are missing this information, and then re-assign the bug to xkb and possibly send it upstream? Would that be do-able?
Comment 6 Vratislav Podzimek 2013-01-08 09:38:28 UTC 
(In reply to comment #5)
> It sounds like it would be better just to fix the Croatian layout in xkb,
> maybe? Can we get a list of layouts which are missing this information, and
> then re-assign the bug to xkb and possibly send it upstream? Would that be
> do-able?
Yeah, I believe it should be fixed in xkb because that way also the other projects could make use of corrected data. Rui is now dived in xkb files and their processing so he could be the right person to help here. Adding him to CC list and setting needinfo.
Comment 7 Adam Williamson 2013-05-08 18:37:19 UTC 
Ping? Rui, did you get anywhere with trying to fix Xkb for the Croatian problem?
Comment 8 Rui Matos 2013-05-08 20:56:29 UTC 
No, sorry. The best way to fix this "defaults" issue once and for all is going to be https://github.com/mike-fabian/langtable which Mike Fabian started recently.
Comment 9 Jens Petersen 2013-10-22 09:47:45 UTC 
Anaconda is using langtable now (thanks!) - perhaps we could move this
to modified for f20.
Comment 10 Adam Williamson 2013-10-22 16:26:49 UTC 
Sounds reasonable. I'll try and find a minute to check that the list looks comprehensive.
Comment 11 Fedora End Of Life 2013-12-21 15:43:27 UTC 
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 12 Fedora End Of Life 2014-02-05 23:18:39 UTC 
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.
Note You need to log in before you can comment on or make changes to this bug.