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
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):
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.
3. opy the new Xvfb from lsbsi to the /usr/X11R6/bin/
4. cd /opt/lsb/test/vsw4; ./run_vsw4.sh
Starting X Virtual Frame Buffer
error opening security policy file /usr/X11R6/lib/X11/xserver/SecurityPolicy
Test able to run from start to finish
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
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
"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.