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: http://people.debian.org/~taggart/lsb/ 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 yet. 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 version is: - 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 battery. - 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 run /opt/lsb/share/test/qmtest_libstdcpp_<version>/run_tests. - 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
