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.

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)
• 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

Locales related issues

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

or

export LC_ALL=C
rpm -e glibc-common --nodeps
yumdownloader glibc-common
rpm -i --define "_install_langs all" 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.

ref: http://bugs.linuxbase.org/show_bug.cgi?id=2632

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

Test results:

/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