Friday lsbsi status

I'll update this into the report that will
be found at http://www.linuxbase.org/impl/records.html,
but in the meantime here's a short summary
purely for the lsbsi:


Package uplifiting (match current upstream
versions were possible):

Mostly done.  Remaining: 
- shadow 4.0.4.1 is available, try this to see 
if it fixes the one newgrp failure that was
present in 4.0.3
- bison 1.875
- X11: currently on 4.2, 4.3 appears to require
a more complicated build so this was put off.
/May/ be needed for newer platforms (amd64,
ppc64, etc.).  There's also an alternate source
for xlibs, now released by freedesktop.org,
state unknown.

Notable: rpm was uplifted to 4.1.  There seems
no reason to stay with 3.0.6, and 4.x is 
needed for support of x86_64.  We were able
to drop the build of db3 as it is now built
locally to rpm.

=====================================

Known problems:
- on x86, builds all the way to completion,
but in the final steps, when rpm is run to
initialize an empty database, it fails because
it uses a library (libbz2) which is not
installed. libbz2 was installed in phase2,
so it's picked up by the build there.  

- ppc built correctly before the last round
of changes. At the least it now has the same
problem as x86 above. There was a report of
poor test results; it's not verified whether
this was a setup problem.

- on s390/s390x, there seems to be a toolchain
mismatch, some header file problems appear
building glibc at the start of phase2. This
probably means something incorrect was
installed during the bootstrap, a likely guess
is it's the kernel-headers package.

- on ia64, dies with a strange toolchain problem:
  malloc: jobs.c:725: assertion botched
  free: called with already freed block argument
Is  this familiar to anyone?

- on ppc64, there are questions whether the
toolchain will build 64-bit native all the
way through.  That's the current design of
the lsbsi build; ppc64, on the other hand,
normally ships as a 32-bit environment with
64-bit libraries.

- on amd64, the build goes through to the end
of phase2, where it fails on xfree86. See
note above.

- generic /lib64:  a number of packages
are still putting libraries in /lib
or /usr/lib instead of /lib64 or /usr/lib64.
This will need a cleanup pass.  Sometimes
this is package configuration; sometimes
this is the install-phase "manual"
fiddling that is done in our xml files.

- generic bi-arch:  current glibc/gcc/binutils
have biarch capability. We are not enabling
(and sometmes explicitly disabling) this.
Should we turn this on eventually?