LSB Workgroup conference call notes from 13 April

On the call:
Nick Stoughton, Marvin Heffler, Stuart Anderson,
Gordon McFadden, Arthur Tyde, Scott Collins,
Rajesh Banginwar, Andrew Josey, Elena Zannoni,
Karen Bennet, Mats Wichmann

Topic: LSB 3.0 Preview -> ?? 

Currently we don't meet the exit criteria for the Preview, there
are still open bugs that need to be fixed against 3.0pre (and
the incoming rate has not really dropped off, so there may be
more). There are still some decisions that need  to be ratified
as well.

Decision is to refresh the Preview on Friday and give it another
week.  The refresh will contain some changes that have gone in
(most of these already appear in the daily-build snapshots,
but not the designated 3.0pre copy): bugfixes, a rewrite of the
system initialization chapter (in response to several bugs),
librt, and the Xevi and DPMS interfaces in the X extension library.

Per request at the call, a new tracker bug (831) has been created
to hold the bugs that affect only the lsb-graphics module,
and those have been moved off the blocker list for the core/c++
specs (611). Both of these rollup bugs still have to be satisfied
for the full LSB 3 release, this was intended to provide better
insight into what areas the bugs affect.

The technical decisions we're still looking for input on, and
will push to get feedback from distros on during the next week
are the following (I've  excluded a few changes that should be
noncontroversial, see the release notes for the full list):

1. Currently, there are just a few glibc symbols higher than
GLIBC_2.3.2.  We've heard that at least one platform would
have trouble meeting a requirement that included GLIBC_2.3.3
or GLIBC_2.3.4 symbolversions. As listed in the release notes,
the current symobls are:

(a) _sys_siglist (2.3.3, but older version exists)
(b) pthread_setschedprio (new, only exists as 2.3.4)
The latter could be excluded from the spec

Also, nftw and nftw64 have a 2.3.3 version and regexec has a
2.3.4 version, older ones still exist and were used in LSB 2.
These were changed only on ppc64, but that was an oversight:
we'll either change all, or change none, to the newer versions.

2. As a special case, ppc and ppc64 have had changes to routines
that are affected by a change to the mcontext structure (all
getting 2.3.4 versions), and there's been some sentiment expressed
that those changes are needed,  even if the other >2.3.2 symbols
are not taken, so that should be considered as a separate topic.

3. The tls-aware locale routines, duplocale freelocale newlocale
and uselocale were added; in particular it seemed to be a problem
for g++ if these did not exist. Okay?

4. getgrouplist was added to meet requests from several opensource
apps, notably samba.

5. some additional pthread routines were added in response
to application claims they were important, these are in the
realtime area.  These have been in glibc since 2.0, excepting
pthread_setchedprio (see 1b above). The others are:

pthread_attr_getinheritsched, pthread_attr_getschedpolicy,
pthread_attr_getscope, pthread_attr_setinheritsched, 
pthread_attr_setschedpolicy, pthread_attr_setscope, 
pthread_getschedparam, pthread_setschedparam

6. librt was added back, containing those routines which have
been in it "forever", but excluding async I/O -

clock_getcpuclockid, clock_getres, clock_gettime, clock_nanosleep,
clock_settime, shm_open, shm_unlink, timer_create, timer_delete,
timer_getoverrun, timer_gettime, timer_settime. These interfaces
align with the POSIX Timers and Shared Memory Objects features.

7. Commands added to align with POSIX: ed, logger, lp, mailx, pax

Note that lp as a command does not imply the "System V lp"
subsystem, and for example, the "lp" that cups already provides
should be quite sufficient Note also that most distros appear to
have a package called mailx, but they install the binary as Mail,
we believe a simply symlink would meet the requirement.

8. Command added to meet various problem reports about package
installation: lsbinstall.  A sample implementation and tests
for this are being developed.

9. Last, but not least, the libstdc++ portion of the C++ ABI
needs to have the "highest symbol version" question answered.
Since gcc 3.4.0 was released, each of the point releases has added
a few exported symbols to the library, with versions matching
the release: GLIBCXX_3.4.1, 3.4.2 and 3.4.2 (apparently GCC
4.0 will continue this with GLIBCXX_3.4.4 based on current cvs
and 4.0 snapshots). Since 3.4.1, the added symbols appear to be
GNU extensions, not ISO-standard routines.  Is there a reason
to push this beyond 3.4.1?  That would seem to have the widest
applicability across implementations, unless it's really clear
there will never be an LSB 3 implementation using anything less
than, say, gcc 3.4.3.  The downside is that _native_ C++ builds
with a higher compiler version (not recommended for LSB code) may
pick up some of the newer stuff from headers without meanining to,
and have problems.

The tests and the lsb-build-c++ headers need to match the symbol
version choice so everything plays together nicely.