[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Release update: lib transitions, toolchain fixes, buildd backlog

It's been a few weeks since the last update from the release team[1], at
which time the projected schedule had us freezing testing and releasing
d-i RC2 today, so we're overdue for another update.

First, let's take a look at what we have and haven't accomplished since
August 7.

Things we've achieved:

 - Library transitions.  Over the past week or so, we've seen new
   soversions of tiff, imagemagick, and libexif make their way into
   testing, bringing with them gimp 2.0 (among other things) and
   bringing the GNOME packages up to date.  Those familiar with
   http://bjorn.haxx.se/debian/stalls.html may recognize these libs as
   being some of the main blockers of late.
 - Toolchain fixes.  A misbuilt gcc-3.3 package on alpha left us with a
   broken compiler in sarge -- which aside from being release-critical,
   made it rather hard to build packages uploaded to the
   testing-proposed-updates queue.  This is being addressed as we speak,
   though with a little more pain than we'd like; by dinstall on the 29th,
   we should have a working gcc on all architectures in sarge.
 - RC bug fixes.  Though certainly higher than we'd hoped it would be at
   this point, after a surge in new bug reports the release-critical bug
   count for sarge now ranges between 180 and 200, which is a definite
   improvement.  If you haven't taken the time yet to help fix the RC
   bugs in your neighbor's package, please consider it, though; we still
   have a way to go before release by this metric.
 - The debian-installer.  d-i RC1 has been released, and feedback
   suggests that we are very close now to having an installer we can
   consider final for sarge.

Though the above shows that there has been clear progress towards
releasing, the next list shows that we're unfortunately not nearly as
close as we wanted to be at this point:

 - The testing-security autobuilder network is not yet operational.
   Until this is resolved, there can be no official security support for
   testing.  Well, what can I say?  We had hopes that this could be up
   and running by the 12th, but this was too optimistic.  There has been
   progress on tracking security problems for sarge, but all updates
   still come via unstable and testing-proposed-updates, making upgrade
   testing from woody a risky proposition.
 - The other end of the toolchain.  gcc is fixed, but binutils is not.
   There are a number of outstanding issues with binutils in both sarge
   and sid that make it harder than necessary to build packages on some
   architectures right now.  Fixing binutils is still most likely a
   precondition for testing-security and testing-proposed-updates
   support that we can depend on 100%.
 - Updates for other packages.  Following the last announcements, we
   fully expected a flurry of last-minute uploads to unstable.  What we
   got was more like a snowstorm.  Coupled with a bit of Debian's
   legendary bad timing where mishaps are concerned (i.e., James Troup's
   stolen laptop), there is a tremendous backlog of unbuilt packages on
   arm, as many have already noticed.  Even without the previous two
   problems, this alone is enough to keep us from freezing right now;
   a lot of those last-minute uploads are in fact needed, and need to be
   allowed into sarge before we can close the gate.

We are not going to freeze while there are this many fixes waiting on
arm.  While it's theoretically possible to ignore arm for the freeze and
let it catch up when it can, right now the best strategy is still to
hold out and keep the architectures in sync.  In any case, if you
maintain packages whose updates are only held out of sarge by arm, you
don't need to worry; the freeze isn't going to happen until we have arm
sorted out, although we don't yet know how soon that will be.

OTOH, if you're looking at the above "we're not freezing" and thinking
"good, I still have a chance to sneak one more update in"... don't.  We
already have a hard time predicting when arm will be ready to freeze,
without having more non-RC uploads competing for buildd time.  We need
to work on drawing the distinction between fixes we'd *like* to have for
the release, and fixes we *must* have for the release (by definition,
"release-critical" fixes).  As part of this, please remember that you
can set the urgency of your uploads to reflect the severity of the
problems being fixed: high-urgency uploads are given higher priority by
the build daemons, so please don't be shy about setting the urgency
field when uploading fixes for RC bugs.

While we all continue working on these last few release-critical
problems for sarge, here are a few other recent changes I'd like to make
you aware of:

 - KDE 3.3 has been uploaded to unstable; however, at this time it does
   not look like the packages will have stabilized in time for sarge's
   release.  This means that if you have a package that depends on KDE,
   you will need to upload any sarge fixes to testing-proposed-updates
   instead of to unstable.  Please remember to build and test these
   packages against sarge, not sid!
 - The KDE partial upgrade problems are not known to affect qt-x11-free
   and arts (the top two blockers in unstable, now that GNOME is fixed).
   The Qt updates in particular are important for sarge, so you should
   not worry about t-p-u uploads for packages only blocked by Qt or
 - Kernels 2.4.27 and have been released, with a strong
   committment from the debian-kernel team to make these the default for
   sarge.  Packages are already available in unstable for many
   architectures, which are in need of testing to help ensure that
   updating is the right decision.  There's not much sense in releasing
   a second debian-installer release candidate until this decision has
   been finalized.

As always, please address any concerns about the release to

Steve Langasek                                     [vorlon@debian.org]
Debian Release Team

[1] http://lists.debian.org/debian-devel-announce/2004/08/msg00003.html

Attachment: signature.asc
Description: Digital signature

Reply to: