Re: (e)glibc plans for the squeeze cycle
On Sun, Aug 16, 2009 at 02:41:36PM +0200, Marc Brockschmidt wrote:
> Heya,
Hi,
> As announced on dda [RT1], we want to get an impression when releasing
> Squeeze is feasible. We have proposed a (quite ambitious) freeze in December
> 2009, and some developers have noted that their planned changes wouldn't be
> possible in this time frame. So, to find out when releasing would work for
> most people, it would be great if you could answer the following questions:
>
> * Which major upstream releases of eglibc are expected in the next two
> years? Which of those are material for Debian stable, which might be a bit
> flaky?
Upstream glibc is released twice a year, in May and November (that can
be late in the month), and eglibc the same day, or a few days after.
For squeeze it would be nice to have eglibc 2.11.
> * How much time do you usually need from a new upstream release of eglibc
> to a stable Debian package in unstable?
While getting a new upstream version of eglibc in a good shape for
unstable takes usually a few weeks for main architecture, it can take up
to one to two months for other architectures, depending on the porters
and upstream support in solving issues. Usually non-i386/amd64
architectures comes with regressions in the testsuite...
We can probably anticipate that by uploading snapshots to experimental
a few weeks before the release, but some manpower is needs for that,
which may be already used for other tasks (see below).
> * How many "big" transitions will the upcoming changes cause? When should those
> happen? Can we do something to make them easier?
>
This should not trigger any transition, but it may block package in
unstable until the eglibc package is moved to testing, though with
symbols support it concerns less packages.
This means we should upload eglibc to unstable when it is really ready,
and possibly synchronised with the release team so that it does not come
in the middle of a big transition.
Apart from that we also need some time to
- Do the multiarch transition. Work is currently in progress (libc6 and
libc6-dev has been splitted already), the remaining big part is to
install the glibc in the multiarch paths. This may delay work on other
tasks. (This is a release goal)
- Switch glibc to use the default compiler, as it usually trigger
regressions in the testsuite on some architectures. For squeeze
(gcc-4.4 seems to be the default compiler for squeeze), this work has
already been done for some architectures, but some regression have
been found on at least armel and mips that needs investigation and
debugging. (This is a release goal)
- Rework the locales* package to avoid either compiling the locales or
installing a pre-compiled version of all of them. This will mainly
benefit embedded systems. This will require some time, especially to
ensure a transition path from the current packages.
Cheers,
Aurelien
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net
Reply to: