Re: LSB status for sid and etch?
On Mon, 2005-10-17 at 19:17 +0200, Petter Reinholdtsen wrote:
> Is there a web page listing the remaining issues to fix before sid and
> etch are LSB compliant? I would like to help out (and I hope I do by
> working on the dependency based init.d system), but do not know how to
> find out what is left to do.
The closest thing we have at present is this:
There may already be a user tag in the BTS for lsb; I'm not sure. I'm
working on something better, but it's not quite ready for prime time
In the meantime, the best way to find out how etch/sid are doing is to
download, install, and run the tests yourself. The above page has
instructions, but they're a bit out of date. Basically, the quick
- Install the distribution you want to test. It's best to do a minimal
install. Don't install any of the X stuff yet if you can avoid it, but
if you're testing a system in use, don't worry about removing it.
QEMU/VMWare/etc. are OK; chroots are not.
- aptitude install lsb
- Download the tests. Go to http://www.linuxbase.org/test, then click
on the download page. You want the LSB Runtime tests. Yes, they are
RPMs; that's OK. The qm and lsb-tet3 packages aren't tests themselves,
but are runtime components for the other tests, so you need them too.
- For the C++ tests, also get the lsb-python RPM from the application
- Install the RPMs on your system: alien -ick <test rpm>
- To run lsblibchk: /opt/lsb/bin/lsblibchk
- To run lsbcmdchk: /opt/lsb/bin/lsbcmdchk
- To run lsb-runtime-test: modprobe loop (if you're using udev), set
passwords for the users "vsx0", "vsx1", and "vsx2", log in as vsx0, and
run "run_tests". You must log in; if you su or sudo, you will fail some
tests. Most of the config questions asked have good defaults or can be
answered sanely; the exception is the block device question. If you're
using udev, set the block device to "/home/tet/test_sets/nonexistb" and
tell the test suite to create the fake devices. You'll have to type the
root password repeatedly, I'm afraid, to set up some of the components
of the test. If you're concerned about security on your test box, then
you must consider the passwords to the vsx? users to be compromised
during/after test runs, as they are stored in several locations in plain
sight. (Including in the runtime journal!)
- To run qmtest_libstdcpp: Add /usr/opt/lsb/appbat/bin to your PATH,
run "gcc -dumpmachine" to get your machine triplet, and
- To run vsw4: aptitude install x-window-system-core xvfb;
cd /opt/lsb/test/vsw4; ./run_vsw4.sh.
Most of the tests are quick, taking less than 15 minutes usually per
test. The runtime test takes somewhere in the neighborhood of six
hours, and often looks like it has hung. Don't assume the runtime test
has hung until it's run overnight. If you're using an emulator, don't
give up on runtime until it's run for 24 hours.
Each of these creates journal files. Where you ran the tests, look for
files named "journal.foo" in the current directory or for paths like
"results/0001e/journal". The C++ tests create a directory called
"qmtest_libstdcpp_<version>". There's a handy utility called "tjreport"
in /opt/lsb/bin; run that on the journal to get a quick summary of the
results. If you want to post results, use tjreport.
Also look at the official runtime report,
in /home/tet/test_sets/results; specifically, look for the list of FIP
(Further Information Provided) results which require some manual
explanation. Make sure there is one.
If you're motivated, look at http://www.linuxbase.org/appbat. Follow
the instructions for running the Application Battery.
And before you go hunting down a problem, make sure it hasn't been
waived. There's a link to the waivers list on the main test page.