Description of problem:
gdmXnest and gdmXnestchooser don't work; They call Xnest and Xnest produces an
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. run gdmXnest or gdmXnestchooser.
Xnest usage error.
Running Xnest session, with login prompt.
$ strace -ofoo -v gdmflexiserver -n
$ grep -i xnest foo
sendto(5, "FLEXI_XNEST :0 500 aac1966a15510"..., 68, MSG_NOSIGNAL, NULL, 0) = 68
Looks like a define isn't getting substituted.
I think it does send the literal string over the wire...
P Jones, would you mind attaching /etc/gdm/custom.conf?
I can reproduce this on my system, the custom.conf looks hopelessly empty:
$ cat /etc/gdm/custom.conf | grep -v ^# | grep -v "^$"
okay that's fine, empty entries get pulled from /usr/share/gdm/defaults.conf
What's the output of
grep Xnest /usr/share/gdm/defaults.conf ?
It could be we're setting Xnest wrong by default (I have some vague notion of
running across this bug before. It could be I fixed it in rawhide, but not F-7)
Never mind, it seems to work for me in gdm-2.20.1-5.fc8
The information we've requested above is required in order
to review this problem report further and diagnose/fix the
issue if it is still present. Since there have not been any
updates to the report since thirty (30) days or more since we
requested additional information, we're assuming the problem
is either no longer present in the current Fedora release, or
that there is no longer any interest in tracking the problem.
Setting status to "CLOSED INSUFFICIENT_DATA". If you still
experience this problem after updating to our latest Fedora
release and can provide the information previously requested,
please feel free to reopen the bug report.
Thank you in advance.
Note that maintenance for Fedora 7 will end 30 days after the GA of Fedora 9.