Hide Forgot
Description of problem: To test lsb-vsw4, an external Xvfb has to be used. Unfortunately, the binary hardcoded the path to the xserver SecurityPolicy to /usr/X11R6/lib/X11/xserver/SecurityPolicy when our is located at /etc/X11/xserver/SecurityPolicy. I was hoping redhat-lsb can set up the symlink to ease the burden of testing lsb-vsw4 in EL4 especially via external vendors. Version-Release number of selected component (if applicable): redhat-lsb-3.0-8.EL How reproducible: always Steps to Reproduce: 1. rpm -Uvh lsb-tet3-3.6b-8.lsb3.x86_64.rpm lsb-test-vsw4-3.0.0-4.x86_64.rpm 2. Download lsbsi-test (sample implementation) from the LSB site. <http://www.linuxbase.org/download/#impl> 3. opy the new Xvfb from lsbsi to the /usr/X11R6/bin/ 4. cd /opt/lsb/test/vsw4; ./run_vsw4.sh Actual results: Starting X Virtual Frame Buffer error opening security policy file /usr/X11R6/lib/X11/xserver/SecurityPolicy Expected results: Test able to run from start to finish Additional info:
What does the X team think about this symlink for redhat-lsb?
In response to Comment #2, No the LSB does not have a formal requirement to have the symlink present. The new directory structure in X11R7 will only impact the next LSB release and not the current LSB 3.0 which EL4 will certify till the end of product life cycle. For LSB 3.0, Xvfb was used as a tool to test the Xlib in our system. As the Xvfb included in EL4-U2 does not have backing store enabled, we were using the Xvfb binaries from LSB Sample Implementation which have the path to the Security Policy set to /usr/X11R6/lib/X11/xserver/SecurityPolicy rather than /etc/X11/xserver/SecurityPolicy. Hence, I created this bug to request for the symlink to be included in so that our distro is more 'test friendly' for us and vendors.
I believe that would lead down a very slippery slope that could drag in a lot of extra "compatibility" junk, which is not really necessary. Our Xvfb should work just fine AFAIK. Enable backingstore from the commandline using: +bs "Xvfb --help" for details. The real problem seems to not be a missing symlink, but backingstore availability in the Xvfb server. I've shown how to turn that on now. Can you confirm this solves your real underlying problem?
I understand your concern. Unfortunately, Xvfb is called within the Test Suite binary rather than running from command line. I dont think modifying the Test Suite to add in the option is 'legal', if not it would make life so much easier. :-)
How does it turn on backingstore in the non-Red Hat Xvfb server? If it isn't passing the +bs option, how is it enabling backingstore at all on any server it? IMHO this is a bug/limitation in the test suite, and the test suite itself should be fixed to work properly. Another hack you could do, is to use a shellscript wrapper for Xvfb that adds the +bs option, but I don't see how any local hacks should be necessary on the Red Hat side. Get the test suite fixed and the problem is solved upstream where it should be IMHO.
Fixed in rawhide.