Preparing debian glibc-snapshot for experimental package to accelerate glibc stability
Hi,
I plan to upload glibc-snapshot package for Debian experimental
distribution. It's similar to gcc-snapshot package. This package has
been requested by various reasons:
- The current debian-glibc package is a bit obsolete. Glibc package
has been frozen until sarge release - but the current one is based
on 2003-09-20 upstream cvs with debian local ~100 patches. You can
see over 50 bug entries tagged as fixed-upstream on BTS[1].
- It's safe to test new glibc package to experimental before putting
unstable. Think of hppa FTBFS in 2.3.2-1.
- We can test upstream cvs frequently. FTP-masters and release
managers enable us to use experimental buildd. Roland McGrath
said[2] fedora is near up to date status. It's nice to keep step
with them and to check repeatedly debian various architecture that
are more than 10.
As I wrote above, this package is intended to fix those various
problems. You can check glibc bugs until sarge release. We can
follow the upstream activity and we can also know FTBFS in advance.
We can support new architecture (ex: ppc64) quickly, too.
If you want to test experimental glibc (-snapshot) package, fetch
packages until I dupload to experimental:
http://www.gotom.jp/~gotom/debian/glibc/snapshot/2.3.4_0.3.snapshot20041220.1/
alpha, amd64, i386, ppc are already prepared. When you install
-snapshot package, you see libc.preinst warning message. Please
ignore it and hit y. This message is intended to prevent installation
for normal experimental users. Be careful that you must not build any
packages in order to upload when you install -snapshot package because
shlib version is bumped up. I recommend you to install it to chroot
environment instead of your system root. If no one objects, I'll
start to put it to experimental. Any comments are welcome. Enjoy.
Note:
- I'll make 2.3.4-0.4.snapshot200503xx.1 or 2.3.90-0.1 as soon as
possible, but that version will not be compiled on various arches
due to the recent audit modification. I plan to keep maintain
2.3.4 series for a while using svn branch.
- I tried to build ppc-nptl, alpha-nptl, arm. arm encountered
gcc-3.3 bug. alpha-nptl did not work when linuxthreads and nptl
are mixed (it may be the problem as David Mosberger pointed out).
ppc-nptl needs gcc-3.4 due to TLS lacking. I'm still trying to
build them. Plus ppc64 (as soon as I setup), mips/mipsel/s390
(under building), and so on.
Note for debian developers:
- I updated various patches. Check debian/changelog in -snapshot.
The following patches are not well tested:
* glibc23-sse-oldkernel.dpatch
* glibc23-cmov.dpatch
The following patches are not updated yet:
* 50_glibc232-hppa-full-nptl-2003-10-22.dpatch
* hurd-enable-ldconfig.dpatch
- Once glibc-snapshot package in experimental is confirmed as
FTBFS-free and stable, we update unstable's glibc package based on
-snapshot package. (If you're one of release managers, you can
consider to use this package as tool of "testing freeze" for
binary packages. Once glibc is moved into unstable, many binary
packages in unstable cannot be moved into testing.)
Note for debian-glibc package maintainers:
- I plan to put this package into the current debian-glibc svn with
all snapshot related parts which are pushed into debian/snapshot
directory. I possibly use svn branch for 2.3.4, and 2.3.90 for
snapshot.
- When you create snapshot package from svn repository, pull svn,
and just execute debian/snapshot/convert-snapshot.sh. It converts
the current svn (for unstable) to experimental package. I use
this hack because almost all script files in unstable and
experimental are same - the maintenance cost could be reduced. To
override any files, put files into debian/snapshot directory, then
invoke convert-snapshot.sh so that they're replaced.
Regards,
-- gotom
[1] http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=src&data=glibc&archive=no&include=fixed-upstream
[2] http://sourceware.org/ml/libc-alpha/2004-12/msg00063.html
Reply to: