Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 85230 - Program messes with XF86Config resulting in invalid configuration file
Summary: Program messes with XF86Config resulting in invalid configuration file
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: pyxf86config
Version: 9
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Alexander Larsson
QA Contact:
URL:
Whiteboard:
: 90272 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-02-26 20:34 UTC by Peter van Egdom
Modified: 2007-04-18 16:51 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-05-28 15:11:02 UTC


Attachments (Terms of Use)

Description Peter van Egdom 2003-02-26 20:34:33 UTC
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'

Comment 1 Miloslav Trmac 2003-02-27 17:50:11 UTC
I've seen the corrupted XF86Config too. I din't examine it enough
to point at specific package, but I'll check.

Comment 2 Peter van Egdom 2003-02-27 20:06:51 UTC
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.



Comment 3 Peter van Egdom 2003-03-15 10:31:47 UTC
Described problem still occurs running "redhat-config-mouse" in text mode with
"redhat-config-mouse-1.0.5-1" on Phoebe 8.0.94.


Comment 4 Brent Fox 2003-03-21 20:46:08 UTC
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?  

Comment 5 Peter van Egdom 2003-03-22 16:45:14 UTC
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"


Comment 6 Alexander Larsson 2003-03-24 14:20:20 UTC
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?

Comment 7 Alexander Larsson 2003-05-28 15:11:02 UTC
This is fixed in pyxf86config 0.3.9.

Comment 8 Brent Fox 2003-05-30 14:01:56 UTC
*** Bug 90272 has been marked as a duplicate of this bug. ***


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