Sample Implementation and Application Battery Status

Week of June 2, 2003

  1. Regular conference calls were held June 3 and 5, after the calls last week were cancelled.
    2. Note: ostensibly, the Tuesday call is for the Sample Implementation and the Thursday call for the Application Battery. In practice, if the "regular suspects" are the only ones in attendance, both calls tend to cover both topics as well as lsbdev topics, since all three seem to tie together.
  2. The header file problems caused by the addition of powerpc64 (incorrectly listed as s390 last time) changes are now resolved.signal.h and ucontext.h had become circularly dependent, resolution was to move some things around to break the former/s need for the latter. The headers are believed to be clean now.
  3. Since the next deliverable is to spin new appbat packages which are "reproducible" (i.e., built from tagged sources using released lsbdev packages - the latter was not the case last time around), the lsbdev packages need to be released. The pending header changes were preventing the beta from progressing to released.
  4. Mats noted that the issue of the Python curses module not building is still open. There are actually two fails here, one on the curses module and one on the curses_panel module; since the latter requires features not described by the LSB it will be ignored. The Python patch also needs to be regenerated as one addition is no longer needed, now being described by the lsbdev headers. The new appbat packages will have to be released as version 1.3.1 to help distinguish them from the previous ones. Currently, the rpm packages encode the base package version (e.g. Python 2.2.2) but not the LSB release version. The package naming scheme will have to be revamped to account for this. Open to proposals for what this should look like.
  5. lsbdev-c++ also needs to be moved towards released status. Currently it is in "snapshot" state for a few platforms, needs to move to beta at least for ia32, ia64 and ppc32. Builds can be done once the lsbdev packages are built. lsbdev-c++ is not a current candidate for autobuilding, it's built from a stable base (gcc-3.2.3 tarballs) and also requires lsbdev - the autobuilding doesn't currently have the ability to build a package, install it, and then use it to build other packages. Maybe later, maybe not at all (doesn't seem high priority).
  6. The 'lsb' packages for other architectures can now be built. 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 snapshots.
  7. The lsbsi for ppc32 has received considerable analysis. After some fixes were applied (to the kernel?), only two "unknown" failures remain, a SEGV in glob and a failure in tcgetattr. The *context routines are also a remaining issue, but as they're a kernel problem, it's not indicative of an lsb-si problem. If it's otherwise possible to avoid rebuilding the lsbsi, the MAKDEV permission question will be resolved by instructing those running the test suite on an lsb-si to answer "no" to the test setup question of whether users can create devices. If it's necessary to rebuild the si, a fix will be applied to change the permissions on /dev/MAKDEV to 0755 (from 0754) to match what most distributions do. It's now believed that this question isn't "can ordinary users create devices" but rather, does this system allow the admin to make devices, as opposed to running something like devfs where they're created automatically.
  8. The glibc symbol versioning issue raised last time seems to only be a concern for powerpc64. The "official" glibc base version for powerpc64 is GLIBC_2.3, but at least one distribution is working towards a release that will have GLIBC_2.2.5 symbols. The archLSB for powerpc64 says 2.2.5 as the symbol versions were presumably drawn from an early version of that distribution. IBM will try to mediate this issue; for now, the LSB is not proposing a change to 1.3 since powerpc64 certification is not targeted for LSB 1.3. It's felt that it wouldn't be to hard to work around this issue.
  9. The patch file for gcc that sets up the correct dynamic linker name was modified for s390 and s390x. With this change, the s390 lsb-si has now built cleanly and the problem with gcc bootstrapping itself is resolved. Next step is to begin running the test suites against the new lsbsi.
  10. It was noted that the lsbsi is still missing install_initd/remove_initd. These are really failures to conform to the spec, but as there's no test, even an existence 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.


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 45 known internationalization failures in the LSB-si running the 1.3.x test suites.. They show non compliance in the upstream packages diffutils (1), grep (3), gettext (1) 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/msgfmt/msgfmt 9 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