There are various system setup requirements for testing a distribution, which are not LSB requirements. While we try to keep such additional requirements to a minimum, we do still require a few things to be able to thoroughly test the LSB required interfaces in a meaningful fashion.
For instructions on installing and running the tests, please see these instructions from ISPRAS.
System resource requirements
The distribution test suite has grown in size considerably since LSB 3.1. Currently, a full install of the distribution tests under /opt/lsb/test takes about 1.2Gb. Application battery packages will add to this, and multiple runs under dtk-manager will accumulate test data rather quickly. Free space of 3-5Gb is probably a reasonable expectation for the system under test before starting LSB testing.
In addition, at this time, lsb-test-olver-core may require about 512Mb of system memory (with an X server and a contemporary desktop running), as well as 2Gb of free disk space to complete a test run.
Starting distribution checker from rc.local
Some distributions (particularly those running systemd) need to have the TERM environment variable defined if you want to start dist-checker from rc.local.
Distribution packages that may be required for successful testing
- wget is used to retrieve packages and test code, it should be installed on the system under test
- lsb-test-perl - perl-devel (libperl-dev, provides libperls.so), perl-Test-Harness, perl-Test-Simple (may also include Test::More, Test::Builder), perl-ExtUtils-MakeMaker (Fedora seems to split these off)
- lsb-test-olver-core - perl-XML-Parser, perl-XML-SAX (aka libxml-parser-perl, libxml-sax-perl)
- Note: on one platform I found I specifically need to remove perl-XML-Parser and install only perl-XML-SAX (and it's deps).
- lsb-test-desktop - qt4-database-plugin-sqlite-lib or libqt4-sql-sqlite or equivalent (provides libqsqlite.so)
- lsb-test-azov-qt3 - libqt3-mt-sqlite or qt3-sqlite or equivalent (provides libqsqlite.so)
- lsb-test-azov-qt4 - libqt4-sql or equivalent, abattis-cantarell-fonts (Fedora, see bug 3423)
The system should have a network subsystem enabled and at least be able to resolve it's own hostname and localhost.
Some tests use specific ports (5000 for example). You should have a minumum of network services running on the system under test. Sshd on the standard port should not cause any conflicts.
If the system under test is running a security system such as selinux, it is quite possible that several tests may fail, attempting operations that the security system blocks. LSB currently does not directly address such addons and it is recommended that you disable or relax the security settings for the purpose of testing.
One might see a large number of locale related failures, particularly with lsb-test-libstdcpp (also xts5). The tests need a number of locales setup that may not be part of a standard install.
We have also discovered that certain tests are sensitive to the system locale setting. Until these issues in the tests are corrected, we suggest running the tests on a system setup for a en_US locale.
- Ubuntu: locale-gen de_DE de_DE@euro en_HK en_PH en_US en_US.ISO-8859-15 en_US.UTF-8 es_ES es_MX fr_FR fr_FR@euro is_IS is_IS.UTF-8 it_IT ja_JP.EUC-JP se_NO ta_IN zh_TW (does not seem to accept en_US.ISO-8859-1?)
- Note: this does not seem to work for me on 9.04 (jaunty). If I run locale-gen with the list, it returns immediately, apparently doing nothing. If I append the list suggested for locale.gen in Debian from the gcc url below to /var/lib/locales/supported.d/local and run locale-gen with no arguments, then things seem to work, reducing libstdcpp-test failures to only 4.
- Debian: dpkg-reconfigure locales (select all-locales or it_IT en_US de_DE en_HK de_DE@euro es_MX fr_FR en_PH fr_FR@euro...(all of the above list under Ubuntu))
- Many rpm based systems: install locales-de, locales-en, locales-es, locales-fr, locales-is, locales-it, locales-ja, locales-se, locales-ta, locales-zh
- Note: On Mandriva, even with the above locales installed, I still had to (which dropped me to 2 FAILS for lsb-test-libstdcpp):
localedef -i en_US -f ISO-8859-15 en_US.ISO-8859-15
- Red Hat derivatives:
- Make sure you have a copy of the glibc-common rpm available (2.5-34 in this example).
export LC_ALL=C rpm -e glibc-common --nodeps rpm -i --define "_install_langs all" /home/stew/glibc-common-2.5-34.i386.rpm
See also: http://gcc.gnu.org/onlinedocs/libstdc++/manual/build.html#build.prereq for other suggestions in setting up locales.
You may also need whatever distribution package that provides the X11 locales (for instance /usr/share/X11/locales/*). Chances are it's installed, but I have run into an install where it wasn't an got unusual failures.
File System Mounting Issues
Some tests may be susceptible to mount options of the / or /opt filesystems. There have been issues in the past with "noatime" or "relatime", but as this has become fairly standard practice, tests that check for atime changes have been disabled. Some runs on recent distributions have exposed a new issue with the "user_xattr" option though. System under test had "/" mounted as"
UUID=9ca46236-5776-11de-a1dd-1f59e14669e7 / ext3 relatime,user_xattr,acl 1 1
/tset/POSIX.os/procenv/times/T.times 3 FAIL tms_utime (as returned by times()) does not seem to change observed current time: 0, observed past time: 0
Changing the mount options to:
UUID=9ca46236-5776-11de-a1dd-1f59e14669e7 / ext3 relatime,nouser_xattr,acl 1 1
Allowed the test to pass. This issue is in bugzilla as bug 2688