Hi, As promised, here’s an update from the Release Team. After we spoke with several teams recently, we have tried to come up with a plan for the upcoming transitions, freeze and release of Debian Squeeze.
The situation of the release is not as good as we had hoped, but it
looks like we can do the release in a few months if we all work
together. Below is a list of bigger transitions and issues we are
currently aware of. If you think we’ve missed something, send a mail to
firstname.lastname@example.org as soon as possible.
The good news is that the imagemagick and liblo transitions have
recently been completed. We are also working hard on transitioning to a
new parted version, bringing many new features to Squeeze. Together with
the recent efforts for an X.org-based graphical installer, this will
allow a release of a debian-installer version quite near to what we will
use for Squeeze in the near future.
We are also working towards the last really enormous transition for the
Squeeze cycle: making Python 2.6 the default python version. In the past
few months, packages supporting multiple python versions have been
rebuilt to also support python2.6. The remaining work is to transition
all packages that can only support one python version at a time. There
are still some bugs needing to be resolved for that to happen , but
we consider it doable in the near future.
There are some other transitions that we are aware of that are currently
prepared and/or already going on:
An SONAME bump for directfb; this transition has started.
* eglibc 2.11
This is currently pending because of a problem on hppa. There also
have been some unexpected test failures on mips*, but work on this
ruby1.9 will be replaced by ruby1.9.1. This is half-done at this
A new system will be put in place to allow switching between
different, optimized versions of these linear algebra libraries.
* Tcl/Tk 8.4/8.5
Tcl 8.3 will be replaced by newer versions. This transition is
currently staged in experimental.
Transitioning away from MPICH and LAM/MPI is currently prepared.
They will be replaced by MPICH2 and OpenMPI.
* linux-2.6/linux-base libata transition
New drivers using ‘libata’ are about to replace the old IDE
drivers. linux-base will prompt you on x86 to upgrade your
configuration files (fstab, bootloader) to refer to stable UUIDs
instead of unpredictable device names.
Some other big transitions have been planned, but not yet started:
* Qt4.6 and KDE 4.4
The new upstream versions of these packages have been prepared by
their maintainers, but due to the complex situation in unstable
weren’t uploaded yet. Nonetheless, they are planned to be included
* GNOME 2.30 and Evolution
Likewise, we are expecting to ship with Gnome 2.30. This will
involve some smaller transitions.
We are also aware of planned updates to icu, boost1.42 and icedove3.
After the directfb transition is finished, we plan on moving on to the
Qt4.6 and KDE 4.4 transitions.
We expect to need two to four weeks for the Python transition, blocking
most of the testing transition. Afterwards, we will need to get
everything done that couldn’t move due to python2.6.
A freeze in late May/June seems to be possible, if people work hard on
getting these transitions done.
* Full IPv6 support
Sadly it looks like this goal won’t be achieved in time; there are
currently over 100 bugs open, and many applications still lack proper
IPv6 support. But it looks far better than with previous releases.
* Large File Support
Is almost done. We currently know of only nine bugs (some of them
minor) affecting this release goal.
* New source package format support
As our infrastructure is now capable of handling the new
dpkg-source formats, having all packages be compatible with the new
“3.0 (quilt)” source format is about 80 bugs away.
Some of these bugs are very easy to fix by adding a proper
* Removal of OSS
Only three bugs remain to be resolved to get this release goal
* Removal of unneeded .la files
Please continue to drop la-files which are not referenced. We don’t
expect to fully meet this goal prior to the release of Squeeze but would
like to continue making progress towards it.
See http://wiki.debian.org/ReleaseGoals/LAFileRemoval for details.
dpkg lacks support for it, so it sadly looks like this release goal
won’t be achieved either.
See http://wiki.debian.org/ReleaseGoals/MultiArch for details.
The release of these two new architectures looks promising, but they
are still far away from full archive coverage. It seems that much
could be gained by fixing some key packages.
Please contact the BSD porter list if you would like to join their
* Removing obsolete GNOME libraries
While there has been quite an improvement compared to previous
releases, we are still ~40 bugs away from achieving this release goal.
Please see http://wiki.debian.org/ReleaseGoals/RemoveOldLibs and
How to Help
Since there are an enormous amount of RC bugs, you can help facilitate
the release by fixing RC bugs in your own packages. Other maintainers
might not be able to do this for their packages, so you might check if
things you use are not in a release stable and help out, if needed.
We would be happy if you would only upload software that you believe to
be stable at this point. Packaging a new, unstable version might lead to
unexpected problems and could delay the release, so consider using
experimental for any new hot features you want to bring into Debian.
Further help is needed in triaging RC bugs and bugs concerning our
release goals. To that end, it might be enough to give the relevant
people a nudge to include existing fixes.
You might also be interested in working on the release notes:
We currently have no explicit Release Manager. All tasks are being
handled by the team together and all members have full authority.
We are also looking for new members of the Release Team. If you don’t
know what needs to be done, here’s a short overview:
* Transitions waiting to happen could profit from someone checking if
everything is all right. This means finding out which packages are
affected, which of these need sourceful uploads and coordination with
the maintainers of these packages.
If the transition is meant to go smoothly into testing, care needs to
be taken to not entangle it with any of the other ongoing transitions.
When all of that is checked and prepared, the transitioning package
should be uploaded and binNMUs scheduled.
* We also need to get the number of RC bugs down if we want to release
Squeeze this year. To this end, it would be great if one or more
BSPs could be organized, possibly focussed at a specific type
Besides the number of RC bugs, we also have some widely used packages
where maintainers are overwhelmed by the number of bugs filed against
their packages (KDE, Gnome, Iceweasel, …) While not strictly a release
issue, triaging (and possibly fixing) bugs can be integrated into a BSP
to give people something easier (but nonetheless tedious :-/) to do.
If you’re interested in joining the team, please contact us at
email@example.com. We will respond to expressions of
interest after April 15th.
for the Release Team