look at the patch below and you will know. the xhost command doesn't return !0 if failed. So, even if DISPLAY is set and xhost is successful, virtualx.eclass tries to spawn Xvfb. Without the patch, it works on linux but not on solaris. ----------------------------PATCH CUT BELOW THIS LINE------------------ --- virtualx.eclass.ORG 2004-06-23 09:08:29.200639510 -0700 +++ virtualx.eclass 2004-06-23 09:09:00.177314130 -0700 @@ -20,7 +20,7 @@ #If $DISPLAY is not set, or xhost cannot connect to an X #display, then do the Xvfb hack. - if [ -z "$DISPLAY" ] || ! (/usr/X11R6/bin/xhost &>/dev/null) + if [ -z "$DISPLAY" ] || (/usr/X11R6/bin/xhost &>/dev/null) then export XAUTHORITY= # The following is derived from Mandrake's hack to allow ---------------------PATCH ENDS ABOVE THIS LINE-------------------- Reproducible: Always Steps to Reproduce: 1. emerge evolution 2. 3. Actual Results: It fails to start a display server Expected Results: It should connect to the existing X display.
Ignore the patch specified in comment 1, use the attached patch. Actually, the problem is that virtualmake looks for started server in /tmp/.X<DISPLAY>-lock when that file is not created. Only file created on linux and solaris is "/tmp/.X11-unix/X<DISPLAY>=". The patch fixes this as well.
Created attachment 33964 [details, diff] The patch for fixing issues with Xvfb and virtualmake
the xhost test is wrong...the return value of xhost is 0 if it can connect to an existing X server and 1 if it can't. So, please remove that '!' from the test.
Can you just attach an updated patch, please?
*** Bug 78899 has been marked as a duplicate of this bug. ***
Az this is kinda your baby .. if you don't want it, send it back.
Is this still a problem?
This eclass has changed a bit since this bug was filed. Please re-open it if the problem still exists with the current eclass.
Doh, I was looking at the wrong bug and didn't realize this was assigned to you Martin. Re-open it if you'd like.
