Red Hat Bugzilla – Bug 130247
gdmthemetester doesn't iterate well
Last modified: 2007-11-30 17:10:47 EST
Description of problem: Problem 1: The gdmthemetester bash script, used to check appearance of gdm themes by running gdmXnest, doesn't work well if you call it more than once on a single machine. It will always launch Xnest, but the gdmgreeter won't start within that display, citing an Xlib "protocol error." Occasionally it will work again, but not usually. Problem 2: Beyond that, no matter what the user sets XNESTSIZE to, the resulting gdm always runs as 640x480, anchored to the upper left corner of an $XNESTSIZE-sized Xnest root window. This appears to be because (Prob #1) the X lock file /tmp/.X*-lock isn't removed for the display opened by Xnest; and (Prob #2) the eval being run doesn't correctly allows gdmXnest to catch the geometry (set through $XNESTSIZE) the user wants. Version-Release number of selected component (if applicable): 2.6.0.0-3 How reproducible: Every time for the XNESTSIZE problem; almost every time for the Steps to Reproduce: 1. Open a standard X session (I am using a default GNOME), and a terminal. 2. Run: export XNESTSIZE="1024x768" 3. Run: gdmthemetester console <dir-with-greeter-files> 3. Notice that gdmgreeter is not using requested geometry. 4. Repeat several times; notice only sporadic success on repeat tries. Actual results: (#1) Xnest does not use the requested geometry set through XNESTSIZE as noted in both the script and the syntax help for gdmthemetester (#2) Repeat runs are often broken Expected results: (#1) XNESTSIZE should be used correctly (#2) Repeat runs should work Additional info: I'll attach a patch which makes this work correctly.
Created attachment 102838 [details] Patch for bash script, fixes XNESTSIZE and removes X lock file I'm not sure whether my fix for the X lock file is strictly "legal." It does seem to vastly improve the situation with running the script repeatedly.
Created attachment 102844 [details] WAY better patch to do the same thing, only cleaner Sorry about the last one. This patch is a big improvement, avoids bash-ism, and makes script less repetitive.
Fedora Core 2 is now maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC3 updates or in the FC4 test release, reopen and change the version to match.
This problem still exists in FC3, with all updates-released applied. Moving version to FC3. Please remove NEEDINFO status if applicable. I will try to test this on FC4t2 if possible. Please keep in mind I did create a patch for this problem, which was just a few bash script lines. Could you look at it and see if it works for you?
Whoops, I also realize I underthought the use of $DISPLAY/$PARDISPLAY remotely in the patch... those cut statements may need to use "-d ':' -f2" instead of "-c2-" for options. Sorry for the stupidity.
Oh, hey, this is something that bugs me personally all the time. Tested on FC3. There's still a problem with the geometry -- if you don't set XNESTSIZE at all, the theme doesn't fill the default window. But now at least if you *do*, it does the right thing. It might be most productive to move all of this upstream and get it fixed in gnome itself....
Fedora Core 3 is now maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC5 updates or in the FC6 test release, reopen and change the version to match. Thank you!
Works in current FC5 (gdm-2.14.9-1). Closing WORKSFORME, since I'm not sure at what point this was taken care of -- bad tracking on my part, sorry.