On Sat, Sep 6, 2008 at 5:09 PM, Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote: > xpra.scripts.main.nox() explicitly deletes the DISPLAY from the > environment, and it appears that gtk won't import without a valid > display. This suggests that xpra needs to be careful to defer importing > gtk until the Xvfb server has been set up.
Thanks for the report! The underlying problem is... special. xpra works just fine with upstream pygtk, which only gives a warning in this case (and we have a hack in nox() to suppress that warning). Fedora has a local hack in their pygtk package to make it throw an exception instead, and that's what is breaking things: http://cvs.fedora.redhat.com/viewvc/devel/pygtk2/pygtk-nodisplay-exception.patch The only reason given for this change in behavior is a reference to bug #208608: https://bugzilla.redhat.com/show_bug.cgi?id=208608 but I'm not authorized to view it. (Maybe it's a security issue? If so, why have fedora been carrying this patch for 2 years without telling anyone else? If not, why is it a secret? Sigh.) The problem is that given this behavior: 1) we can't import gtk until Xvfb has fully started 1a) in particular, it used to be that when one attempted to connect to a server, xlib (and thus gtk) would retry for a few seconds, exactly to avoid this race condition, but that got removed: http://partiwm.org/ticket/30 So the server really has to be *fully* started. 2) the only way to tell if Xvfb has started is to attempt to connect to it 3) our connection attempt code uses... gtk. (Well, gdk, but pygtk doesn't let us import gdk without first importing gtk). And we can't wrap the import statement in a retry loop, because Python Doesn't Work That Way. I guess we have to write a special "is it safe to import fedora pygtk?" guard that wraps the C level XOpenDisplay calls directly. -- Nathaniel _______________________________________________ Parti-discuss mailing list [email protected] http://lists.partiwm.org/cgi-bin/mailman/listinfo/parti-discuss
