Sample Implementation, Application Battery and LSB Build Status

Week of August 25, 2003

1. lsbdev 1.3.4 is not yet ready for beta. There is still a pending header change to curses; and some architectures need to complete resolving variances shown with devchk. chroot issues are still open as well: doesn't map lsbdev-c++ libraries, doesn't always get sshd privilege separation dir right, compiler-private (fixincluded) headers chosen over lsbdev headers, should map in appchk by default if available, should start up even if lsb-rpm is not available, fhs violation using /etc/lsbdev-chroot, possible dangling bind-mount on shutdown.
2. There's a desire to work on lsbdev and tests for LSB 2.0; the ongoing lsbdev 1.3 work is kind of keeping the tree from moving forward. Probably need to fork and continue to maintain a 1.3 tree, as maintenance is likely to need to be ongoing for another 12+ months.
3. lsbdev-chroot policy question: as special cases get more complex, is it worth continuing to patch it? Does the chroot have real usefulness beyond building the test suite, for which it seems to be working okay?
4. One more chroot question: we're no longer maintaining lsb-rpm, but the chroot still seems to expect it. Do we still need to produce an lsb-rpm package?
5. The package format requirement was raised on lsb-confcall; a resolution is still pending: is using rpm a strict requirement, or a suggestion?
6. A sample download page was floated (see http://www.linuxbase.org/~cyeoh/download.php). Also need maintainers to update their HEADER.txt files to provide useful non-version-specific descriptions - don't want the descriptions to go out of date.
7. (Old) The 'lsb' packages for other architectures still need to be released. The package has no contents, just supplies a couple of dependencies and basically initializes the rpm database in the lsbsi. It's already autobuilding successfully, all that's needed is for someone with access to the build environments to build packages that look released, rather than like snapshots.
8. A question was raised, but not answered, on whether the teams should be releasing .deb packages or not. This hasn't been done consistently. It's a convenience, but Debian systems are required to be able to install .rpm packages so it should not strictly be required.
9. Sample Implementation design is being finalized for the dual-architecture platforms. At the moment it looks like AMD64 will be a pure 64-bit platform similar to Itanium; powerpc64 will be a 32-bit platform (should be able to be a copy of powerpc32) with 64-bit libraries.
10. (Old). The lsbsi is still missing install_initd and remove_initd (it provides empty dummies). These are really failures to conform to the spec, but as there's no test they aren't flagged as such by the testing procedure. Still looking for volunteers to work on both a sample implementation and a test suite - there was a thought that Novell might be interested, to be explored further. An idea raised in the past might be worth considering: the sample could perhaps work on a non-standard location so that "cheaters" who try to install a startup script directly instead of using the required tool to install them could get detected by installing in the lsbsi.
11. Discussion on future directions for appbat. A table of packages with new upstream versions is included below. A proposal was floated earlier to start building a libbat: static versions of key libraries that are LSB candidates, but not yet in the specification. This might smooth over some current build issues, and also might enable building some more complex applications, such as gnumeric, mysql, etc. The current model of lsbdev-c++ has indicated this can be useful. At the very least, when a library is "ported", the instructions should be captured so others don't have to reproduce the work. E.g., openssl was worked on as part of an experiement with openssh; libxml2 was worked on as part of an LSB conforming nALFS.
12. Discussion on future directions for lsbsi. A table of packages with new upstream versions is included below.
13. A suggestion was raised to have the appbat packages indexed by rpmfind. This is under discussion. One thought was that maybe the upstream maintainers ought to give permission. A second question was whether we should continue the build-with-nALFS, package-with-rpm policy, or whether we should try to return to building with rpm.
14. Debian seems to be taking lsb requirements quite seriously; some discussion of including lsb testing in the process. This would potentially require modifying the lsb-runtime-test build process, which might in turn have some impacts on lsbdev packages.

Appbat Packages with upgraded base

LSB-si Packages with upgraded base

LSB-si Variances

This section documents the known variances of the lsbsi from LSB version 1.3.

The lsbsi does not provide required tools install_initd and remove_initd.

The following are the 44 known internationalization failures in the LSB-si running the 1.3.3 test suites. They show non compliance in the upstream packages diffutils (1), grep (3) and textutils (40). The choice is made to leave these unpatched, although the li18nux website, does have patches available, to highlight the status of the upstream packages.

/tset/LI18NUX2K.L1/utils/diff/diff 2 FAIL
/tset/LI18NUX2K.L1/utils/egrep-tp/egrep-tp 5 FAIL
/tset/LI18NUX2K.L1/utils/fgrep/fgrep 5 FAIL
/tset/LI18NUX2K.L1/utils/fold/fold 1 FAIL
/tset/LI18NUX2K.L1/utils/fold/fold 2 FAIL
/tset/LI18NUX2K.L1/utils/fold/fold 3 FAIL
/tset/LI18NUX2K.L1/utils/grep-tp/grep-tp 5 FAIL
/tset/LI18NUX2K.L1/utils/join/join 3 FAIL
/tset/LI18NUX2K.L1/utils/join/join 4 FAIL
/tset/LI18NUX2K.L1/utils/pr/pr 1 FAIL
/tset/LI18NUX2K.L1/utils/pr/pr 3 FAIL
/tset/LI18NUX2K.L1/utils/pr/pr 4 FAIL
/tset/LI18NUX2K.L1/utils/pr/pr 5 FAIL
/tset/LI18NUX2K.L1/utils/pr/pr 6 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 8 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 9 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 10 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 11 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 12 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 13 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 14 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 15 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 16 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 24 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 25 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 26 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 27 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 28 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 29 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 30 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 31 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 32 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 40 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 41 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 42 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 43 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 44 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 45 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 46 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 47 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 48 FAIL
/tset/LI18NUX2K.L1/utils/unexpand/unexpand 1 FAIL
/tset/LI18NUX2K.L1/utils/uniq/uniq 2 FAIL
/tset/LI18NUX2K.L1/utils/uniq/uniq 3 FAIL

There is an additional failure that occurs in beta runtime test 1.3.5, which adds some new tests. This failure is listed separately since it is not yet part of an official certification release. The program is part of the gettext package, and the issue is the subject of LSB bug 703372.

/tset/LI18NUX2K.L1/utils/msgfmt/msgfmt 9 FAIL