From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030206 Description of problem: Okay, this one is really hard to reproduce. Nevertheless, I encountered it twice on Phoebe 8.0.94. The first time I thought I made some mistake somewhere in testing the redhat-config-* tools and fixed my screen configuration (with the --reconfig option of "redhat-config-xfree86") so everything was all right again. 2 days later I was using "redhat-config-keyboard" to test some differences with different keyboard setups for my system and triggered the bug and captured it. It all comes down to this, start "redhat-config-keyboard" and try out different settings for the keyboard. It can take a while before the bug is triggered, though. After the bug is triggered, "redhat-config-keyboard" barfs out some text to the xterm (see additional information) and corrupts "/etc/X11/XF86Config". Here is the diff with a valid XFConfig file and the corrupted one by "redhat-config-keyboard" : [root@powermate X11]# diff XF86Config.bak XF86Config.crap 0a1 > 10a12 > 14d15 < 18d18 < 33a34 > 36d36 < 39d38 < 64c63 < Option "XkbLayout" "us" --- > Option "XkbLayout" "us_intl" 76a76 > 92,93c92,109 < HorizSync 31.0 - 96.0 < VertRefresh 55.0 - 160.0 --- > HorizSync 31.0 - 31.0 > HorizSync 0.0 - 31.0 > HorizSync 0.0 - 0.0 > HorizSync 0.0 - 0.0 > HorizSync 0.0 - 96.0 > HorizSync 0.0 - 0.0 > HorizSync 0.0 - 0.0 > HorizSync 0.0 - 0.0 > HorizSync 55.0 - 0.0 > VertRefresh 55.0 - 55.0 > VertRefresh 0.0 - 55.0 > VertRefresh 0.0 - 0.0 > VertRefresh 0.0 - 0.0 > VertRefresh 0.0 - 160.0 > VertRefresh 0.0 - 0.0 > VertRefresh 0.0 - 0.0 > VertRefresh 0.0 - 0.0 > VertRefresh 0.0 - 0.0 Version-Release number of selected component (if applicable): How reproducible: Sometimes Steps to Reproduce: 1. start "redhat-config-keyboard" 2. select different keyboard setups, switch from one to another, e.g. "United States" -> "United States International" -> "United States". 3. exit "redhat-config-keyboard. 4. repeat until bug is triggered. Actual Results: "redhat-config-keyboard" corrupts "/etc/X11/XFConfig" Expected Results: Hmm... this should not happen. Additional info: (This problem has been found on Phoebe 8.0.94 with package "redhat-config-keyboard-1.0.3-4"). Here everything is all right (normal output from redhat-config-keyboard): [root@powermate root]# redhat-config-keyboard Loading //lib/kbd/keymaps/i386/qwerty/us-acentos.map.gz * running ['/usr/X11R6/bin/setxkbmap', '-layout', 'us_intl', '-model', 'pc105', '-option', ''] And here is the bug output (about 2 seconds after the above output, with no modifications on my machine other than messing around with "redhat-config-keyboard") which corrupts "/etc/X11/XF86Config" : [root@powermate root]# redhat-config-keyboard Loading //lib/kbd/keymaps/i386/qwerty/us.map.gz * running ['/usr/X11R6/bin/setxkbmap', '-layout', 'us', '-model', 'pc105', '-option', ''] Parse error on line 100 of section Monitor in file /etc/X11/XF86Config The HorizSync keyword must be followed by a list of numbers or ranges. Traceback (most recent call last): File "/usr/lib/python2.2/site-packages/rhpl/firstboot_gui_window.py", line 83, in okClicked if self.apply(): File "/usr/share/redhat-config-keyboard/keyboard_gui.py", line 188, in apply keyboardBackend.modifyXconfig(fullname, layout, model, variant, options) File "/usr/share/redhat-config-keyboard/keyboard_backend.py", line 35, in modifyXconfig keyboard = xf86config.getCoreKeyboard(xconfig) File "/usr/lib/python2.2/site-packages/xf86config.py", line 155, in getCoreKeyboard for i in xconfig.layout[0].inputs: AttributeError: 'NoneType' object has no attribute 'layout'
I've seen the corrupted XF86Config too. I din't examine it enough to point at specific package, but I'll check.
Although not with "redhat-config-keyboard", I can also 100% reproduce this bug (or a very similar one) with starting the program "setup" as root, and choosing the text-version of "redhat-config-mouse" (Mouse configuration as presented by the menu by "setup"). After starting "setup" as root and choosing 'Mouse configuration' - and not selecting anything to change, just [tab] -> [tab] -> [tab] -> [cancel], makes XF86Config invalid. Doing a diff between a backup of of XF86Config and the new XF86Config (apparently generated by redhat-config-mouse) results in this : root@powermate X11]# diff XF86Config.bak XF86Config 69c69 < Option "Protocol" "GlidePointPS/2" --- > Option "Protocol" "IMPS/2" 92,93c92,93 < HorizSync 31.0 - 96.0 < VertRefresh 55.0 - 160.0 --- > HorizSync 31,0 - 96,0 > VertRefresh 55,0 - 160,0 (notice the "," instead of the "." characters). Running the tool ("# setup" and again doing a Mouse configuration, followed by <tab>, <tab>, <tab>, [cancel]) again makes a mess out of the XF86Config file, this time worse : root@powermate X11]# diff XF86Config.bak XF86Config 69c69 < Option "Protocol" "GlidePointPS/2" --- > Option "Protocol" "IMPS/2" 92,93c92,97 < HorizSync 31.0 - 96.0 < VertRefresh 55.0 - 160.0 --- > HorizSync 31,0 - 31,0 > HorizSync 0,0 - 96,0 > HorizSync 0,0 - 0,0 > VertRefresh 55,0 - 55,0 > VertRefresh 0,0 - 160,0 > VertRefresh 0,0 - 0,0 Okay, corrupting XF86Config is very easy to trigger with Mouse configuration run from "setup". I haven't succeeded in reproducing the problem with redhat-config-keyboard. The origin of the bug is probably very much the same as with Mouse configuration running from "setup". I'll change component to "redhat-config-mouse" instead because it's easier to track and reproduce.
Described problem still occurs running "redhat-config-mouse" in text mode with "redhat-config-mouse-1.0.5-1" on Phoebe 8.0.94.
I think that this is really a bug with pyxf86config running in non-us locales. Nothing in redhat-config-mouse or redhat-config-keyboard tries to modify that particular section of XF86Config, yet something in pyxf86config is converting the decimals into commas. Alex, can you take a look at this?
Here are the contents of the file "/etc/sysconfig/i18n" on my Phoebe 8.0.94 setup: LANG="nl_NL.UTF-8" SUPPORTED="nl_NL.UTF-8:nl_NL:nl:en_US.UTF-8:en_US:en" SYSFONT="latarcyrheb-sun16"
libxf86config seems to be using fprintf("%f") to generate the config file. This will use ',' instead of '.' in some locales. I don't think this will hit the x-based configuration tools though. Since python doesn't support locales that behave like this pygtk sets LC_NUMERIC to "C" automatically on initialization. Maybe the redhat-config-* tools should do that too?
This is fixed in pyxf86config 0.3.9.
*** Bug 90272 has been marked as a duplicate of this bug. ***