Bug 882159 - system-config-keyboard should read and write configuration via localed (at present it is completely broken)
Summary: system-config-keyboard should read and write configuration via localed (at pr...
Alias: None
Product: Fedora
Classification: Fedora
Component: system-config-keyboard
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Vratislav Podzimek
QA Contact: Fedora Extras Quality Assurance
: 871542 (view as bug list)
Depends On:
Blocks: 881785
TreeView+ depends on / blocked
Reported: 2012-11-30 10:01 UTC by Kay Sievers
Modified: 2013-08-15 02:40 UTC (History)
8 users (show)

Clone Of:
Last Closed: 2013-08-15 02:40:00 UTC

Attachments (Terms of Use)

Description Kay Sievers 2012-11-30 10:01:22 UTC
Fedora is migrating away from:
 /etc/sysconfig/network (the HOSTNAME=... setting)

See the tracker bug 881785 for details.

We found:
 keyboard.py:	file = open(instPath + "/etc/sysconfig/keyboard", "w")

Please update the package for the new config files.

The old files are converted and deleted from the system at update time.
If reading the old files is still supported, please make sure they are
never created again.


Comment 1 Jan Vcelak 2012-11-30 11:11:05 UTC
I can confirm that the keyboard layout change using system-config-keyboard does not survive reboot.

Comment 2 Nicola Soranzo 2012-11-30 14:28:14 UTC
*** Bug 871542 has been marked as a duplicate of this bug. ***

Comment 3 Adam Williamson 2013-01-05 06:35:40 UTC
Proposing as an F18 Blocker. Unfortunately.


Between F18 Beta and F18 Final TC1, anaconda stopped writing /etc/sysconfig/keyboard , in line with the migration away from that file.

Unfortunately, here's how firstboot gets its keyboard layout:

from system_config_keyboard import keyboard
             kbd = keyboard.Keyboard()

and as per this bug, system-config-keyboard tries to read the layout from /etc/sysconfig/keyboard . Which does not exist.

To fix this we either need to migrate s-c-k to the new filenames, or change how firstboot gets its keyboard layout (why is it not using Xkb?), or as a very ugly stopgap, go back to writing /etc/sysconfig/keyboard from anaconda.

The result of this bug is that firstboot always runs with US English as its keymap, no matter what you chose during install and what /etc/vconsole.conf says. So if your username doesn't include any characters that differ between your keymap and U.S. English, but your password does, you are going to wind up entering a different password than you think you're entering, and being very angry and confused. This affects all keymaps other than U.S. English.

Also, once firstboot is complete but until you reboot, VTs use the U.S. English keymap, it seems (firstboot setting it somehow 'hangs on' after firstboot is done). After a reboot, consoles seem to behave correctly.

Tested by doing a fresh install, booting to runlevel 3, and creating /etc/sysconfig/keyboard , before firstboot has a chance to run: after doing that and then booting to runlevel 5, firstboot uses the specified keymap, not U.S. English.

Comment 4 Adam Williamson 2013-01-05 08:06:49 UTC
Actually: I think we can avoid this by just ditching the code in firstboot. See 892097 .

Comment 5 Adam Williamson 2013-05-29 02:25:57 UTC
current s-c-k only writes a console layout to /etc/sysconfig/keyboard and changes the runtime xkb config.

I think possibly the sensible thing to do with it is to make it call localed to set the systemwide configuration, and dump the runtime configuration. GNOME and KDE both override the systemwide config with their own settings, so it makes sense for s-c-k to be a tool for setting the systemwide config but probably not for it to change the runtime config.

GNOME is capable of pushing a user's config out systemwide, so there is no use case for s-c-k on GNOME any more, basically. KDE AFAIK is not, so s-c-k is still useful for setting the systemwide configuration there. I have not looked at Xfce or LXDE or other desktops.

I'm going to see if I can come up with a quick hack to make s-c-k call localed to set the systemwide config.

Comment 6 Adam Williamson 2013-05-29 02:38:50 UTC
yeah, no, I can't. well, I could, but it'd be horribly painful for my poor python skills and I'd likely do it badly.

if someone could *please* take ten minutes to fix this up it'd really help users of non-main desktops, I think. it really should be straightforward for anyone who can write python. just change lib/keyboard.py to use localed to read and write the 'current' configuration. Re-thinking comment #5, it's probably fine for it to change the runtime config too, but it'd be nice if we could have s-c-k pop up a big box if you try to run it in GNOME saying 'don't use me, use gnome control center'.

Comment 7 Fedora Update System 2013-06-06 19:10:06 UTC
system-config-keyboard-1.3.1-14.fc18 has been submitted as an update for Fedora 18.

Comment 8 Fedora Update System 2013-06-06 19:11:19 UTC
system-config-keyboard-1.3.1-14.fc19 has been submitted as an update for Fedora 19.

Comment 9 Fedora Update System 2013-06-07 23:51:47 UTC
Package system-config-keyboard-1.3.1-14.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing system-config-keyboard-1.3.1-14.fc18'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).

Comment 10 Fedora Update System 2013-06-15 03:05:38 UTC
system-config-keyboard-1.3.1-14.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 11 Adam Williamson 2013-06-19 15:13:14 UTC
vpodzime: 1.3.1-14 still seems fine for this, I'll probably push it to f18 at some point soon but might want to co-ordinate a backport of the livecd-tools fix with bcl.

Comment 12 Fedora Update System 2013-08-15 02:40:00 UTC
system-config-keyboard-1.3.1-14.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

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