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):
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.
(#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
(#1) XNESTSIZE should be used correctly
(#2) Repeat runs should work
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
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.
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.