xpra, part of x11-wm/parti <http://code.google.com/p/partiwm/wiki/xpra> will crash on launch if Xvfb is not installed on the system. Reproducible: Always Steps to Reproduce: 1. Install xpra, part of x11-wm/parti 2. Don't install Xvfb (x11-base/xorg-server) 3. Start xpra Actual Results: xpra crashes: $ xpra start :7 Entering daemon mode; any further errors will be reported to: /home/stroller/.xpra/:7.log $ tail -n 20 /home/stroller/.xpra/\:7.log Error starting Xvfb: [Errno 2] No such file or directory Traceback (most recent call last): File "/usr/bin/xpra", line 6, in <module> xpra.scripts.main.main(__file__, sys.argv) File "/usr/lib/python2.6/site-packages/xpra/scripts/main.py", line 82, in main run_server(parser, options, mode, script_file, args) File "/usr/lib/python2.6/site-packages/xpra/scripts/server.py", line 256, in run_server wait_for_x_server(display_name, 3) # 3s timeout File "xpra.wait_for_x_server.pyx", line 33, in xpra.wait_for_x_server.wait_for_x_serverRuntimeError: could not connect to X server after 3 seconds $ which xpra /usr/bin/xpra $ equery b `!!` equery b `which xpra` [ Searching for file(s) /usr/bin/xpra in *... ] x11-wm/parti-0.0.6 (/usr/bin/xpra) $ Expected Results: xpra starts The issue can be resolved by installing Xvfb (x11-base/xorg-server) $ xpra start :8 Entering daemon mode; any further errors will be reported to: /home/stroller/.xpra/:8.log $ tail -n 20 /home/stroller/.xpra/\:8.log PIXMAP: 1 objects of 8 bytes = 8 total bytes 0 private allocs GC: 0 objects of 44 bytes = 0 total bytes 0 private allocsCURSOR: 0 objects of 4 bytes = 0 total bytes 0 private allocs CURSOR_BITS: 0 objects of 4 bytes = 0 total bytes 0 private allocs DBE_WINDOW: 0 objects of 12 bytes = 0 total bytes 0 private allocs TOTAL: 1 objects, 8 bytes, 0 allocs [dix] Could not init font path element /usr/share/fonts/misc/, removing from list![dix] Could not init font path element /usr/share/fonts/TTF/, removing from list![dix] Could not init font path element /usr/share/fonts/OTF/, removing from list! [dix] Could not init font path element /usr/share/fonts/Type1/, removing from list! [dix] Could not init font path element /usr/share/fonts/100dpi/, removing from list! [dix] Could not init font path element /usr/share/fonts/75dpi/, removing from list! Xlib: extension "RANDR" missing on display ":8". Xlib: extension "RANDR" missing on display ":8". Xlib: extension "RANDR" missing on display ":8". X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 118 (X_SetModifierMapping) Value in failed request: 0x17 Serial number of failed request: 21 Current serial number in output stream: 21 $ xpra list Found the following xpra sessions: LIVE session at :8 $ equery b /usr/bin/Xvfb [ Searching for file(s) /usr/bin/Xvfb in *... ] x11-base/xorg-server-1.9.2 (/usr/bin/Xvfb) $ Note that the xorg-server must be built with USE="-minimal" to install Xvfb
And if you run a remote X server instead of local? Adding xorg-server to dependencies is out of question.
Ideally, IMO, x11-base/xorg-server should add Xvfb to the list of IUSE_SERVERS. This would allow a USE="minimal xvfb" and thus a smaller install. I have requested this separately of the x11-base/xorg-server team at Bug 352975. I hope I have acted correctly in filing these separate bugs and apologise for the inconvenience if I have made an error. However I believe these to be separate issues: - This bug is that xpra (x11-wm/parti) should depend on "-minimal" for current versions of xorg-server and that is a bug that should be fixed. - Bug 352975 is an enhancement request which would allow a smaller install and affect future versions of these packages.
> And if you run a remote X server instead of local? Adding xorg-server to dependencies is out of question. I'm sorry I'm not 100% sure I understand the question. I *think* my updated comment addresses it. However, I believe that xpra is broken without Xvfb. See my crash report. Of course I am trying to run xpra on a headless server, and I want as little X11 as possible. I think that if this package does not have x11-base/xorg-server as a dependency then the ebuild should prevent xpra from being built. Ideally xpra should be split off into a separate package, but I'm not sure if upstream is ready to do that - see the last paragraph of xpra's FAQ <http://code.google.com/p/partiwm/source/browse/README.xpra> More ideally the enhanced winswitch.org version should perhaps be adopted.
Michael, any progress here?
I ran into this recently. To summarize the state for people not familiar with xpra: - xpra is one program in x11-wm/parti. xpra is useful in its own right, but is not necessary for people who want to run the window manager supplied in the same package. - xpra, like screen, is a single program that runs in two different modes. One mode is a server for X11 clients. The other mode is a viewer that displays the clients managed by the server mode. The server mode requires Xvfb. - The xpra client can be run on a different machine than the xpra server, so a viewer-only use of xpra can work without Xvfb installed. There are a few possible solutions to this bug report. All are easy to implement, so the question is which solution is the best compromise between user configurability and configuration simplicity. Possible solutions include: - Add "x11-base/xorg-server[xvfb]" to RDEPEND. As Samuli pointed out in comment #1, this forces an X server on people who may not need one. Though this could be mitigated for headless users by x11-base/xorg-server[minimal,xvfb], some users may not need to run an xpra server at all, so building any x11-base/xorg-server is unnecessary for such users. - Add "server? ( x11-base/xorg-server[xvfb] )" to RDEPEND. This allows people who want a viewer-only mode to avoid the X server, and leaves people who choose USE=-server in exactly the same situation as now. They can manually emerge x11-base/xorg-server[xvfb] later if they decide they want to run xpra in server mode. - Add an einfo/elog message stating that server mode requires x11-base/xorg-server[xvfb]. This is less helpful than solution #2, but is still nicer than the current behavior of xpra daemonizing, then dying after a few seconds when it fails to find Xvfb. I like solution #2 best, since it gives users a heads-up before they build the package.
Pleae switch to the new fork x11-wm/xpra[parti] , which includes mentioned xvfb dep. I'm gonna treeclean this package in 30days.
