Bug 552397 - gnome-keyboard-properties fails to save keyboard preferences
Summary: gnome-keyboard-properties fails to save keyboard preferences
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: control-center
Version: 14
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Control Center Maintainer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
: 667700 (view as bug list)
Depends On:
Blocks: 693843 797213
TreeView+ depends on / blocked
 
Reported: 2010-01-04 21:48 UTC by cam
Modified: 2018-11-28 21:12 UTC (History)
14 users (show)

(edit)
Clone Of:
: 693843 797213 (view as bug list)
(edit)
Last Closed: 2012-08-16 17:43:55 UTC


Attachments (Terms of Use)

Description cam 2010-01-04 21:48:14 UTC
Description of problem:
I find the keyboard layout is incorrect so open System->Preferences->Keyboard and remove the USA mapping and select the United Kingdom one. I close gnome-keyboard-properties and use the keyboard mapping successfully. But when I log out, and log in again, the layout is incorrect once more, it is reverted to the USA setting. I have to repeat this every time I log in.


Version-Release number of selected component (if applicable):
control-center-2.28.1-8.fc12.i686


How reproducible:
100% on my system

Steps to Reproduce:
1.log in and change keyboard layout from USA to UK
2.remove USA layout, select United Kingdom layout
3.log out and log in again
  
Actual results:
USA layout is in effect again

Expected results:
USA layout nowhere to be seen, UK layout remains selected.

Additional info:
I tried gnome-session-save after changing the setting and it didn't make any difference.

Comment 1 Dirk Götz 2010-06-02 17:36:05 UTC
Description of problem:
Running in the same bug after upgrading from F12 to F13 using the install DVD. My setup is nearly the same, I want to use "German eliminate dead keys" and always get "USA". I can easily switch to my wanted layout by using the switch utility in the panel. But after the next login it is switched back to "USA".

Version-Release number of selected component (if applicable):
control-center-2.30.1-2.fc13.x86_64

Additional info:
I tried to get all information that can be helpful from files I know keyboard could be affected by. If someone has an idea what else I can provide please tell me.

$ cat /etc/sysconfig/keyboard 
KEYBOARDTYPE="pc"
KEYTABLE="de-latin1-nodeadkeys"
MODEL="pc105"
LAYOUT="de"
VARIANT="nodeadkeys"

$ gconftool-2 -R /desktop/gnome/peripherals/keyboard/kbd
 layouts = [de	nodeadkeys,us]
 options = [terminate	terminate:ctrl_alt_bksp,caps	caps:none,grp	grp:shift_caps_toggle]
 model = 

$ cat /etc/X11/xorg.conf
...
	InputDevice    "Keyboard0" "CoreKeyboard"
...
Section "InputDevice"

    # generated from data in "/etc/sysconfig/keyboard"
	Identifier  "Keyboard0"
	Driver      "kbd"
	Option	    "XkbLayout" "de"
	Option	    "XkbModel" "pc105"
	Option	    "XkbVariant" "nodeadkeys"
EndSection
...

$ egrep "(keyboard|xkb)" /var/log/Xorg.0.log
[  1399.327] (**) Power Button: Applying InputClass "evdev keyboard catchall"
[  1399.327] (**) Power Button: Applying InputClass "system-setup-keyboard"
[  1399.331] (II) Power Button: Configuring as keyboard
[  1399.331] (**) Option "xkb_rules" "evdev"
[  1399.331] (**) Option "xkb_model" "pc105"
[  1399.331] (**) Option "xkb_layout" "de"
[  1399.331] (**) Option "xkb_variant" "nodeadkeys"
[  1399.331] (**) Option "xkb_options" "terminate:ctrl_alt_bksp,"
[  1399.359] (**) Power Button: Applying InputClass "evdev keyboard catchall"
[  1399.359] (**) Power Button: Applying InputClass "system-setup-keyboard"
[  1399.362] (II) Power Button: Configuring as keyboard
[  1399.362] (**) Option "xkb_rules" "evdev"
[  1399.362] (**) Option "xkb_model" "pc105"
[  1399.362] (**) Option "xkb_layout" "de"
[  1399.362] (**) Option "xkb_variant" "nodeadkeys"
[  1399.362] (**) Option "xkb_options" "terminate:ctrl_alt_bksp,"
[  1399.377] (II) config/udev: Adding input device AT Translated Set 2 keyboard (/dev/input/event3)
[  1399.377] (**) AT Translated Set 2 keyboard: Applying InputClass "evdev keyboard catchall"
[  1399.377] (**) AT Translated Set 2 keyboard: Applying InputClass "system-setup-keyboard"
[  1399.377] (**) AT Translated Set 2 keyboard: always reports core events
[  1399.377] (**) AT Translated Set 2 keyboard: Device: "/dev/input/event3"
[  1399.381] (II) AT Translated Set 2 keyboard: Found keys
[  1399.381] (II) AT Translated Set 2 keyboard: Configuring as keyboard
[  1399.381] (II) XINPUT: Adding extended input device "AT Translated Set 2 keyboard" (type: KEYBOARD)
[  1399.381] (**) Option "xkb_rules" "evdev"
[  1399.381] (**) Option "xkb_model" "pc105"
[  1399.381] (**) Option "xkb_layout" "de"
[  1399.381] (**) Option "xkb_variant" "nodeadkeys"
[  1399.381] (**) Option "xkb_options" "terminate:ctrl_alt_bksp,"

Comment 2 Dirk Götz 2010-06-10 13:56:16 UTC
I found a solution for me. 

The gdm-greeter's default is USA-keyboard after update with anaconda, so if I don't change my keyboard settings also to German here it will switch it to USA. After I have done it one time the default after login is German. 

Problem is that you don't recognize that after choosing your user at the buttom an option menu appears where you have to choose. ;-)

If this also works for F12 I think it can be closed!

Comment 3 cam 2010-06-11 21:04:47 UTC
I think Dirk has shed some light on the mechanism of this problem, I just checked and what he says is true. However the behaviour has changed.

Now looking at F13, I have:

control-center-2.30.1-2.fc13.i686

I set the keyboard at login time to USA (once, the default) and logged in. Then although control center remembered I had the UK setting, it showed that as selected even though the USA layout was still in force. No matter what I did with the control center I could not change the keyboard layout to UK. 

This behaviour is much worse than the original problem!

To fix the whole problem I suggest:

1. Anaconda should default to the previous keyboard setting when upgrading

2. Login window should not reveal settings at the last moment, or if it does it should make them more obvious

3. Control center should not be silently overridden by the system setting, it should allow you to change the system default or change it just for your user.

Comment 4 Mike C 2010-08-15 21:58:10 UTC
I have this problem also - I don't know if listing two separate symptoms will help identifying where the problem lies. However I see:

After install of f13 with a UK keyboard set when I go to gdm greeter to login then despite the language and keyboard set to UK the mapping is clearly US still.

I have gone through the selection of the UK keyboard within the gnome preferences also as per the initial report in this bz.

However once logged in then the UK keyboard mapping is honoured.

If the screensaver kicks in then to unlock the screensaver the keyboard mapping reverts to needing the US location of non alphameric characters but once out of the screensaver then the gnome session honours the UK keyboard again!

I am up to date running 2.6.33.6-147.2.4.fc13.i686.PAE and gdm version is gdm-2.30.2-1.fc13.i686

However I don't know if gdm is responsible for the screensaver keyboard error. But this appears to be linked to the original bug.

Can anyone else confirm that the keyboard is no longer honoured when the screensaver kicks in on their machines??

Comment 5 Mike C 2010-08-15 22:16:45 UTC
One additional strange behaviour - in GDM if I switch to the USA selection before logging in then it uses the UK keyboard mapping!  This implies that there may be a pair of lines or filenames swapped to the opposite of what is required somewhere?

Comment 6 Mike C 2010-08-16 06:36:35 UTC
I think I have figured out what is going on - and that the bug is not in dgm or gnome but in the installer.

What appears to have happened is that during the install anaconda decided that the keyboard was US.  This makes no difference until a password containing non alphameric characters is entered such as the normal user password at firstboot.

Then when the user selects the UK keyboard the password has characters that did not match for any of the non alphameric characters with the UK selected keyboard.

This also explains why the screensaver requires the same characters taken from keys for the US key positions to unlock the screensaver.

To test this I switched to the UK keyboard in gnome and then reset the password using the UK normal keyboard keys.  Then after logging out and selecting the UK keyboard in gdm, login works correctly for the password.  Within gnome the UK keyboard is now retained, and the screensaver password works with the UK keys.

Hence this is definitely a bug in anaconda and not in gdm or gnome, nor in control-center I believe.

Comment 7 Mike C 2010-08-16 06:54:20 UTC
I also checked the anaconda-ks.cfg file in root and it shows that the install keyboard was selected as "keyboard us".  This is definitely an anaconda bug and the component should be reassigned to anaconda.

Comment 8 Mike C 2010-08-16 08:36:01 UTC
I just did another install on a different machine and I had no keyboard
problems - so I am now not sure if I perhaps did not select the UK keyboard on
the initial install - unless I reinstalled on the machine where I had the
problem I now can't reproduce the problem I had!  However the system I had uses
a usb keyboard and the others were laptops where there was no problem. If it is
my clumsiness then apologies for the noise!

Comment 9 Mads Kiilerich 2010-09-05 23:14:33 UTC
I see this on a friends system, but not on any of my systems. There must be some setting somewhere that makes the difference - but I haven't been able to find it. Any hints where to look?

Comment 10 Tomasz Torcz 2010-09-06 06:19:01 UTC
For me, issue appear on systems using autologin in GDM.  As such, there's no way to select different keyboard layout on GDM screen, because there is none.

Comment 11 Mads Kiilerich 2010-09-06 09:00:02 UTC
I'm not sure what the pattern is, but I see the problem without autologin, so if it is the same problem then we can rule out autologin.

It mostly seems like the gdm keyboard choice overrules the default layout from gnome-keyboard-properties.

Comment 12 Mads Kiilerich 2010-09-06 22:16:22 UTC
The complexity of this problem can be seen on
https://bugzilla.gnome.org/show_bug.cgi?id=572765
https://bugzilla.gnome.org/show_bug.cgi?id=585290
https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/460328

See also bug 467699 and bug 532212 .

My attempt of summarizing what is going on:

gdm defaults to use the default X keyboard layout which is configured with system-config-keyboard and stored in /etc/sysconfig/keyboard - see https://fedoraproject.org/wiki/Input_device_configuration#system-setup-keyboard

gdm stores the list of recent keyboard layouts in gconf /apps/gdm/simple-greeter/recent-layouts, but that is just a global recent list - see http://library.gnome.org/admin/gdm/stable/configuration.html.en#greeterconfiguration

If the user makes any keyboard layout choice in gdm then it is stored in ~/.dmrc (or always?) and overrides whatever has been configured in gnome-keyboard-properties.

Please correct me if I'm wrong, but this might explain what I see.

There is however also /var/cache/gdm/*/dmrc . I would expect gdm to update that whenever the user changes the layout - and to restore user X's layout after the the login name X has been specified and thus usually put the same layout in .dmrc - or not do anything. That is apparently not what happens? I would also expect gnome-keyboard-properties to put the configured default layout where gdm can see it, and to give a warning/prompt whenever it sees that gdm specified a layout different from the default - a layout which perhaps not even was one of the choices.

Comment 13 Gareth 2010-09-09 05:29:19 UTC
Accidentally upgraded to F14, and can confirm that the problem 'Fails to save keyboard preferences' still exists.

My experience:
Prior to upgrade process, UK was selected as default keyboard laybout. During upgrade process, uk was selected.
When logged in to gnome, USA is displayed by the notification applet. Selecting this and clicking Keyboard Preferences starts gnome-keyboard-properties
Adding United Kingdom to the layouts list allows one to click the USA and it changes to GBR.
At this point, the GBR can be clicked to toggle between USA and GBR
Removing USA from the list will cause the notification panel to disappear.
Logging out and logging back in again, will add USA back to the layout list, above UK.
Leaving USA in the list, and logging out/in moves USA to the top of the list.
Clicking the icon changes it to GBR and everything else it AOK

Comment 14 Mads Kiilerich 2010-09-09 09:31:17 UTC
(In reply to comment #13)
> Accidentally upgraded to F14, and can confirm that the problem 'Fails to save
> keyboard preferences' still exists.

What keyboard layout is used for entering the password in GDM?

Isn't it just that the keyboard layout used/chosen in GDM gets higher priority than what has been configured (and correctly saved) in keyboard preferences?

Will it work as expected after you have used system-config-keyboard to change the global default to UK (and restarted the system)?

Comment 15 Gareth 2010-09-09 11:25:27 UTC
I have run system-config-keyboard, and it is "United Kingdom"
I appear to have no settings for GDM
But, GDM is definitely using the US layout (| where ~ should be, so maybe not US, but definitely not UK)

Running
system-setup-keyboard however, has created a new file in /etc/X11/xorg.conf.d 
The applicable setting that is different in this file, as apposed to the old one, is that XKBLayout now reads "gb" and previously is was "gbr"

Perhaps system-setup-keyboard is missing from a 'firstboot' script (maybe only when upgrades performed)?

Comment 16 Gareth 2010-09-09 11:27:54 UTC
Spoke too soon, no, even now the system is set to USA, but GDM now uses a UK keyboard correctly.
To clarify, even now that gdm is using a UK keyboard, the notification applet still states US, and gnome-terminal etc. still defaults to USA. The system-keyboard-preferences has re-created a US item, and is shown below the UK layout.

Comment 17 Mads Kiilerich 2010-09-09 11:46:52 UTC
(In reply to comment #15)
> I appear to have no settings for GDM

I see a keyboard selection field in the bottom bar once I get to the password prompt. You don't see that?

> Perhaps system-setup-keyboard is missing from a 'firstboot' script (maybe only
> when upgrades performed)?

Perhaps. But I think our primary focus right now must be to understand what is going on and causes the problem, secondary how we can work around, and finally how we can get it solved so nobody else sees this problem.

(In reply to comment #16)
> To clarify, even now that gdm is using a UK keyboard, the notification applet
> still states US, and gnome-terminal etc. still defaults to USA. The
> system-keyboard-preferences has re-created a US item, and is shown below the UK
> layout.

My guess would be that a configuration where UK is default but US is second has been saved, but for some reason the configured default is overruled.

Do you have a ~/.dmrc file? What happens if you remove it? Is it created again? With which content?

Comment 18 Gareth 2010-09-13 10:11:38 UTC
Sorry, been away from an internet connection.

(In reply to comment #17)
> (In reply to comment #15)
> > I appear to have no settings for GDM
> I see a keyboard selection field in the bottom bar once I get to the password
> prompt. You don't see that?

Nope, I didn't.

However, this morning my system updated ~140 packages (including system-config-keyboard I believe). Now I do get two more relevant options at the bottom of the screen when logging in. 
Language, now I have set to English (UK), and keyboard from USA to GBr. 
These settings appear to be saved now, and the symptoms are no longer present. 
However, I suspect that the issue is not entirely resolved. GBr still showed as being in the top of the list (assuming that the ordering on the list is for order of preference, otherwise why would there be an up and down ability). USA was selected, even though it was the lowest in the list (and had been removed previously).


My .dmrc appears to be correct (but cannot say that this is not due to having changed the settings from the login screen).

---

[Desktop]
Layout=gb
Language=en_GB.utf8
---

I will be out of contact again for a while, but if there is anything else I can do to help diagnose I will attempt it when I can. However for me, my symptoms are currently invisible.

Comment 19 Mads Kiilerich 2010-09-13 12:24:51 UTC
So to summarize:
* an updated f13 system (updates, not updates-testing)
* ran system-config-keyboard and selected United Kingdom
* select United Kingdom keyboard layout in GDM (if not already selected)
* get a new .dmrc with Layout=gb (which will overrule gnome configuration)
* but you get US layout, even though GBr is on the top of the list as default
* removing everything but United Kingdom from the list and starting over (rebooting) makes no difference

Can you confirm that?

When I try that I get GBr/United Kingdom layout as expected.

I notice that it makes some difference if you are using xorg-x11-server-Xorg 1.8.0 and system-setup-keyboard 0.8.4 from updates or 1.8.2/0.8.5 from updates-testing. The latter introduces /etc/X11/xorg.conf.d with 00-system-setup-keyboard.conf. With a new version coming soon I suggest that users not running updates-testing should wait and see instead of testing/reporting the "old" version. Reports and comments from users running updates-testing would however be very interesting.

Comment 20 Mads Kiilerich 2010-09-15 13:57:25 UTC
(My comments above on updates and updates-testing was completely bogus and based on a misconfigured test system.)

Comment 21 Deshi Xiao 2010-10-14 01:47:15 UTC
i have came cross this problem. +1.

Comment 22 Mads Kiilerich 2010-10-14 02:16:08 UTC
dxiao: Exactly what have you experienced? Something that looks like a bug, or is it "just" a usability problem?

Comment 23 Jiri Moskovcak 2010-12-06 11:49:41 UTC
I just tried F14 with GNOME and run into a problem which I think fits this bugzilla:

1. installed F14 with Czech(qwerty) keyboard
2. in the gnome keyboard applet added USA and Czech(qwertz) keyboard
3. removed the Czech(qwerty) keyboard
4. logged off and on and now I have all three keyboards in the applet and Czech(qwerty) is default

so to sum it up, it saves the additional layouts, but forgot the default and didn't remove the CZE(qwerty). I'll check the gdm settings when I get to that computer and will send some updates...

Comment 24 Mads Kiilerich 2010-12-06 12:05:07 UTC
(In reply to comment #23)

From this description it seems to me like it behaves as designed and expected: The layout used for installation is used as default in gdm, and the layout used in gdm will trump all gnome keyboard settings.

That behavior is however confusing for everybody, so I think it would be great if the design could be changed.

For example:

1. there should be a message box or notification explaining what is going on whenever the gnome keyboard settings is trumped by the gdm layout.

2. gnome keyboard settings should know how to update /var/cache/gdm/$USER/dmrc whenever the default layout is changed. That would be a minor information leak, but I think that is acceptable.

alternatively
3. gdm should learn to read the gnome keyboard settings rather than /var/cache/gdm

Comment 25 Jiri Moskovcak 2010-12-06 12:31:52 UTC
(In reply to comment #24)

I'm not sure if we understand each other - I don't care about the keyboard layout in GDM, but what bothers me is when I log into the gnome (so I'm pass GDM) I expect only my settings to be used and the settings from GDM should be overridden  by what I've configured... 

The first login might be an exception when GDM settings actually sets the default, but once I configure the keyboard I would expect only the new settings to be used...

Comment 26 Mads Kiilerich 2010-12-06 14:30:07 UTC
(In reply to comment #25)

FWIW I guess something like what you expects could be implemented, but the links from comment #12 convinced me that it deliberate and for good reasons has been designed and implemented the way it is.

Others _do_ care about the GDM layout. It has been considered important that the user only has to choose/change keyboard layout once in a session, and it is essential that the "right" layout (the users preferred layout) is available when entering the password (ie before the user has been authenticated). I think that special first time magic behaviour could be confusing.

The changes I proposed in comment #24 are minor tweaks that helps us understand what is going on - and would give the end result you want (by ensuring that the GDM layout (which you don't care about) is the same as what you selected in gnome keyboard settings).

Comment 27 Jiri Moskovcak 2010-12-06 15:07:07 UTC
the misunderstanding probably continues... :)

To clear the thinks out I should explain the situation a bit. This was actually the first time a had to deal with keyboard in GNOME I use XFCE...
> (In reply to comment #25)
> 
> FWIW I guess something like what you expects could be implemented, but the
> links from comment #12 convinced me that it deliberate and for good reasons has
> been designed and implemented the way it is.

- XFCE does it - it doesn't care what I choose in the GDM, it obeys what I configured in it's keyboard applet and if I didn't configured anything (like the first time login) it uses the layout which I choose in GDM...

> Others _do_ care about the GDM layout. It has been considered important that
> the user only has to choose/change keyboard layout once in a session, and it is
> essential that the "right" layout (the users preferred layout) is available
> when entering the password (ie before the user has been authenticated). I think
> that special first time magic behaviour could be confusing.
> 

- reading this again sounds a bit rude from me when saying "I don't care about the GDM layout" - I didn't mean to... I just want to stress that my bug report isn't about layout in GDM but about layout after login...

> The changes I proposed in comment #24 are minor tweaks that helps us understand
> what is going on - and would give the end result you want (by ensuring that the
> GDM layout (which you don't care about) is the same as what you selected in
> gnome keyboard settings).

This concerns the GDM part, which I have neutral opinion for, as I have no problem how the layout in GDM screen is handled ...but I don't want the UI to try to be smarter than me by changing the layout according what I have set in GDM even when I configured it in the session. 

So the question is - if I setup the keyboard layout in the gnome center, why it's trying to be smarter and adds the layout I used in GDM?

and please don't take it like I'm saying GNOME should act like XFCE, it's only this particular case...

Comment 28 Peter Verthez 2010-12-29 20:10:26 UTC
My 2 eurocents, since I also see weird behaviour...   Here are the full details of what I see:

I've configured my fedora 14 desktop from the start (at installation) with a "United Kingdom" keyboard, because my keyboard has a QWERTY layout.  In Gnome I saw that there was an applet that could allow to switch the keyboard layout simply via the applet, so I tried that out by adding a "Belgium" (AZERTY) keyboard.

At that moment I had enabled "Separate layout for each window" accidentally, and afterwards I disabled it, because I wanted to have the same behaviour for all windows.   And then I switched back to "United Kingdom" for my normal work.  However, from then onwards, all new programs that I started automatically changed the keyboard layout to "Belgium" (and not only for that program, but for the entire desktop).   Once I manually set it back to "United Kingdom" for that program, it stayed that way, also when I closed and reopened the program.

After some experimenting, I found that when I changed the order of the keyboard definitions in the keyboard applet (first "Belgium", then "United Kingdom") I didn't have that problem.   But when the order is "United Kingdom", "Belgium" (which I originally had), the problem appears again.

Also, after switching the order to "Belgium", "United Kingdom", selecting the last one first doesn't register: you have to select the first one again and then the last one.   After that first time, the selection is ok.

Maybe this experience will help pinpointing this bug, because there is definitely something weird going on...

Comment 29 Mads Kiilerich 2010-12-29 20:32:34 UTC
(In reply to comment #28)

Peter, as far as I can see the issue originally discussed here is which layout is used initially after login.

What you are describing seems to be a different issue, and I suggest you file a new issue for it.

Comment 30 Peter Verthez 2010-12-29 20:40:46 UTC
OK, I've submitted https://bugzilla.redhat.com/show_bug.cgi?id=666247, but it sounds awfully related to what is happening in this bug.

Comment 31 David Juran 2011-01-12 07:03:53 UTC
*** Bug 667700 has been marked as a duplicate of this bug. ***

Comment 32 Paul B Schroeder 2011-05-07 03:17:10 UTC
I have run into this issue on a live system where you don't get the option of interacting with GDM.

GDM always sets the GDM_KEYBOARD_LAYOUT environment variable with the layout it wants to use.  You can override it's setting by setting GDM_KEYBOARD_LAYOUT in ~/.bash_profile.  You will get that keyboard layout when you log in.  It will even add that layout to the gconf settings if it was never added with gnome-keyboard-properties.  This doesn't fix the problem, but it's an okay workaround.

You could also add this quick hack to your .bash_profile to set GDM_KEYBOARD_LAYOUT dynamically (i.e. have it read the layouts from gconf):
layout=$(gconftool-2 --get /desktop/gnome/peripherals/keyboard/kbd/layouts | sed -e 's/\[//' | sed -e 's/\]//' | awk -F, '{ print $1 }')
[ -n "$layout" ] && export GDM_KEYBOARD_LAYOUT="$layout"

It would be nice if it were possible to configure GDM to use the gconf settings for setting GDM_KEYBOARD_LAYOUT if the default behaviour is not desired.

Comment 33 Fedora End Of Life 2012-08-16 17:44:01 UTC
This message is a notice that Fedora 14 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 14. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained.  At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this 
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen 
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we were unable to fix it before Fedora 14 reached 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 to click on 
"Clone This Bug" (top right of this page) and open it against that 
version of Fedora.

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


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