LSB 3.1 status for etch
First of all, I apologize for the lateness of my report. I had intended
to evaluate some of the results I had found, but did not find time to do
so.
I have seen two questions asked about the LSB and Debian. First:
- Policy currently references LSB 1.3, while 3.1 is the current
version. What are the differences between the two?
There are two sets of changes. First of all, the ABIs covered by LSB
1.3 have been updated to reflect their latest versions. In particular,
LSB 3.1 now approximately reflects the ABIs of glibc 2.3.4.
The LSB now also covers the standard C++ library, OpenGL, the PNG and
JPEG graphics libraries, fontconfig, GTK+, Qt 3, and libxml2. An
optional module covers Qt 4; this can be interpreted as a
"standards-track" module.
Second:
- What changes need to be made to Debian etch to make it LSB-compliant?
The best way to answer that question is to look at the results from the
official runtime tests, to see what changes the FSG will require to
certify etch. The test results below were run on etch as of July 16.
Most of the current tests pass. Of those that don't, most are
recognized deficiencies. In sum, there are two potential issues with
Debian and the LSB: a possible bug in cpio, and an issue with the libX11
ABI that is common to X.org distributions.
>From "lsb-runtime-test":
/tset/LI18NUX2K.L1/utils/cpio-fh/T.cpio-fh 5 FAIL
/tset/LI18NUX2K.L1/utils/cpio-fh/T.cpio-fh 6 FAIL
/tset/LI18NUX2K.L1/utils/cpio-fh/T.cpio-fh 7 FAIL
These tests are the only new test results that may cause concern. These
were the results I wanted to analyze. It appears that cpio in etch does
not preserve i18n content under certain circumstances. The cpio in
sarge passes this test.
/tset/LI18NUX2K.L1/utils/diff/T.diff 2 FAIL
/tset/LI18NUX2K.L1/utils/fold/T.fold 1 FAIL
/tset/LI18NUX2K.L1/utils/fold/T.fold 2 FAIL
/tset/LI18NUX2K.L1/utils/fold/T.fold 3 FAIL
/tset/LI18NUX2K.L1/utils/join/T.join 3 FAIL
/tset/LI18NUX2K.L1/utils/join/T.join 4 FAIL
/tset/LI18NUX2K.L1/utils/pr/T.pr 1 FAIL
/tset/LI18NUX2K.L1/utils/pr/T.pr 3 FAIL
/tset/LI18NUX2K.L1/utils/pr/T.pr 4 FAIL
/tset/LI18NUX2K.L1/utils/pr/T.pr 5 FAIL
/tset/LI18NUX2K.L1/utils/pr/T.pr 6 FAIL
/tset/LI18NUX2K.L1/utils/sort/T.sort 8 FAIL
/tset/LI18NUX2K.L1/utils/sort/T.sort 9 FAIL
/tset/LI18NUX2K.L1/utils/sort/T.sort 10 FAIL
/tset/LI18NUX2K.L1/utils/sort/T.sort 11 FAIL
/tset/LI18NUX2K.L1/utils/sort/T.sort 12 FAIL
/tset/LI18NUX2K.L1/utils/sort/T.sort 13 FAIL
/tset/LI18NUX2K.L1/utils/sort/T.sort 14 FAIL
/tset/LI18NUX2K.L1/utils/sort/T.sort 15 FAIL
/tset/LI18NUX2K.L1/utils/sort/T.sort 16 FAIL
/tset/LI18NUX2K.L1/utils/sort/T.sort 24 FAIL
/tset/LI18NUX2K.L1/utils/sort/T.sort 25 FAIL
/tset/LI18NUX2K.L1/utils/sort/T.sort 26 FAIL
/tset/LI18NUX2K.L1/utils/sort/T.sort 27 FAIL
/tset/LI18NUX2K.L1/utils/sort/T.sort 28 FAIL
/tset/LI18NUX2K.L1/utils/sort/T.sort 29 FAIL
/tset/LI18NUX2K.L1/utils/sort/T.sort 30 FAIL
/tset/LI18NUX2K.L1/utils/sort/T.sort 31 FAIL
/tset/LI18NUX2K.L1/utils/sort/T.sort 32 FAIL
/tset/LI18NUX2K.L1/utils/sort/T.sort 40 FAIL
/tset/LI18NUX2K.L1/utils/sort/T.sort 41 FAIL
/tset/LI18NUX2K.L1/utils/sort/T.sort 42 FAIL
/tset/LI18NUX2K.L1/utils/sort/T.sort 43 FAIL
/tset/LI18NUX2K.L1/utils/sort/T.sort 44 FAIL
/tset/LI18NUX2K.L1/utils/sort/T.sort 45 FAIL
/tset/LI18NUX2K.L1/utils/sort/T.sort 46 FAIL
/tset/LI18NUX2K.L1/utils/sort/T.sort 47 FAIL
/tset/LI18NUX2K.L1/utils/sort/T.sort 48 FAIL
/tset/LI18NUX2K.L1/utils/unexpand/T.unexpand 1 FAIL
/tset/LI18NUX2K.L1/utils/uniq/T.uniq 2 FAIL
/tset/LI18NUX2K.L1/utils/uniq/T.uniq 3 FAIL
These failures are the result of some i18n patches to the mentioned
utilities not being in etch. They are not there because upstream has
not accepted those patches for various reasons, and the LSB has agreed
to waive the tests until upstream has accepted patches to fix the bugs.
>From "libchk":
libX11.so.6 478 FAIL
libX11.so.6 479 FAIL
libX11.so.6 480 FAIL
libX11.so.6 481 FAIL
These failures are common to all distributions using X.org 7. Several
symbols have moved from one library to another. This has generated some
discussion within the LSB; see bug 1330 in LSB Bugzilla
(http://bugs.linuxbase.org/show_bug.cgi?id=1330) for details. It's also
worth noting that this issue may be a problem for Debian even outside of
the LSB, as some applications built on older systems may still look for
the symbols in their old libraries.
libstdc++.so.6 3401 FAIL
libstdc++.so.6 3414 FAIL
These failures are due to a weakness in the test suite; it does a poor
job of handling changes to the C++ inheritance hierarchy that are
otherwise legal. They have been waived.
>From the vsw4 (X Window System) test:
/tset/CH02/vndrrls/mvndrrls 1 FAIL
/tset/CH02/vndrrls/vndrrls 1 FAIL
These are also related to X.org 7; the VendorRelease() and
XVendorRelease() calls return a value that is unrecognized. This will
almost certainly be waived; current thought is that the X.org 7 results
will be added to the list of recognized values, and unrecognized return
values will be marked as FIP results rather than FAIL results, meaning
that the value will have to be checked manually.
Reply to: