Text form of meeting summary/status

... and here's the summary in text format:


Document's Title: LSB-si/LSB-appbat Status

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.
            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.
          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