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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
