Thanks for the report, I'll take a look.

This bug is present for all layouts.

I was going to file this, but I see it has already been filed. This is what it gives in my case:

$ system-config-keyboard
Loading /lib/kbd/keymaps/i386/qwerty/fi-latin1.map.gz
Traceback (most recent call last):
File "/usr/share/system-config-keyboard/keyboard_gui.py", line 232, in _okClicked
return self.apply(None, False)
File "/usr/share/system-config-keyboard/keyboard_gui.py", line 123, in apply
keyboardBackend.modifyXconfig(fullname, layout, model, variant, options)
File "/usr/share/system-config-keyboard/keyboard_backend.py", line 47, in modifyXconfig
xconfig.layout[0].inputs.insert (xf86config.XF86ConfInputref ("Keyboard0", "CoreKeyboard"));
IndexError: index out-of-bounds

I'm having a much serious bug also. The day before yesterday after package updates (there was e.g. Xorg updated) the system doesn't set the keyboard anymore - at least for Xorg. The gdm login screen uses US keymap (the default when any specific keymap isn't loaded) and also it doesn't matter what the user selects from gdm to be used as keyboard. The bug is that even though settings are there in /etc/sysconfig/keyboard, the system doesn't apply them - doesn't change the keymap (and also keyboard selection from gdm doesn't work). Running system-config-keyboard after logged into X session works - changes the keyboard (and gives this traceback).

The computer where this happens uses nvidia driver from livna/rpmfusion. That migt be related. Also the computer uses hso driver for USB attached HSDPA modem. Could udev be messing the keyboard changing somehow..? I have no clue, but the bug is that keyboard doesn't set up on bootup / on gdm load / on X session login, but running system-config-keyboard works (although I get the traceback and the window must be closed manually).

I'm not sure if the bug is related to system-config-keyboard, but perhaps you have a clue what could be messing things up. :)

I guess I should I file this as a new bug... Unless this is a known issue in which case I shouldn't...

Same for me on Fedora 10 with normal install + all updates and rpmfusion's nvidia.

$ system-config-keyboard

(system-config-keyboard.py:3492): Gdk-WARNING **: DESKTOP_STARTUP_ID contains invalid UTF-8
Loading /lib/kbd/keymaps/i386/qwerty/uk.map.gz
Traceback (most recent call last):
  File "/usr/share/system-config-keyboard/keyboard_gui.py", line 232, in _okClicked
    return self.apply(None, False)
  File "/usr/share/system-config-keyboard/keyboard_gui.py", line 123, in apply
    keyboardBackend.modifyXconfig(fullname, layout, model, variant, options)
  File "/usr/share/system-config-keyboard/keyboard_backend.py", line 47, in modifyXconfig
    xconfig.layout[0].inputs.insert (xf86config.XF86ConfInputref ("Keyboard0", "CoreKeyboard"));
IndexError: index out-of-bounds

We also see have comment #3's problem (on a number of F10 PCs after an update) of switching back from UK to US layout as default.  Have to "system->regional&language->keyboard_layout->enable keyboard layouts" in KDE and remove US and leave only UK. That works around the problem.

Okay. The other more serious bug I told you about is definitely not related to nvidia or the hso driver I mentioned. It is definitely a pure Fedora bug.

Now I have it on my other computer as well. This one doesn't have any non-free packages which could affect this. So it's definitely a generic bug.

I just got it after I rebooted the computer to the new kernel-2.6.27.19-170.2.35.fc10.x86_64 (previously I ran kernel-2.6.27.15-170.2.24.fc10.x86_64).

It's not about the kernel. The same issue happens with kernel-2.6.27.15-170.2.24.fc10.x86_64.

It's related to Xorg because the console has correct keymap set.

Okay. Now I know it's Xorg itself. I just downgraded xorg-x11-server-* packages to previous versions and now my keyboard works correctly in X session too.

So now it's clear that xorg-x11-server-* has the other bug I've been commenting about. Now I can file a bug against it if there isn't one already...

This my final comment about the second issue as it's definitely not related to this bug.

There seems to be a bug about it already (although it has gdm as component instead of xorg-x11-server): bug 484488.

I have a similar problem. It was after a recent update and every time I boot the computer it automatically boots up in English US layout. When I run system-config-keyboard it fires up but when I choose Turkish layout I get a traceback as shown below


[root@linuxbox ~]# Loading /lib/kbd/keymaps/i386/qwerty/trq.map.gz
assuming iso-8859-15 euro
Traceback (most recent call last):
  File "/usr/share/system-config-keyboard/keyboard_gui.py", line 232, in _okClicked
    return self.apply(None, False)
  File "/usr/share/system-config-keyboard/keyboard_gui.py", line 123, in apply
    keyboardBackend.modifyXconfig(fullname, layout, model, variant, options)
  File "/usr/share/system-config-keyboard/keyboard_backend.py", line 47, in modifyXconfig
    xconfig.layout[0].inputs.insert (xf86config.XF86ConfInputref ("Keyboard0", "CoreKeyboard"));
IndexError: index out-of-bounds



The key beboard then correctly chnages to Turkish but I have to repeat this procedure everytime I turn on the computer. I am running Fedora 10 on an HP laptop

(In reply to comment #9)
> I have a similar problem. It was after a recent update and every time I boot
> the computer it automatically boots up in English US layout. 

> The key beboard then correctly chnages to Turkish but I have to repeat this
> procedure everytime I turn on the computer.

I think you are experiencing bug 484488 which is closed/fixed now. You just need to apply the latest updates.

The issue with system-config-keyboard you described is probably the same issue as this bug (e.g. line 47 etc. is mentioned there).

This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  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 '10'.

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 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 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 please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

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.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 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.

Thank you for reporting this bug and we are sorry it could not be fixed.