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

[DRAFT] Another update on transition statuses

Release team -- please take this, edit it as you see fit, and post it 
to d-d-a if deemed appropriate.  I made some fairly strong recommendations 
regarding the libssl fiasco, but I think they're correct -- and people 
probably ought to be warned about this immediately.

We currently still have quite a lot of transitions going on.

*Please don't* upload shlib bumps or lib renamings unless required by one of 
these transitions.  This has not changed since 
but some people seem to have forgotten.

Of the transitions listed in Andreas Barth's previous message, glibc 2.3.5, 
X.org, and GNOME 2.10 have entered etch.  Yay!  Since my previous message to 
gcc-release, so have gcc-4.0 and gmp.  Double yay, and congrats to everyone 

libssl 0.9.8
The libssl maintainer went and uploaded a new version.   Its symbols aren't 
versioned yet, and it doesn't have proper Conflicts: with libssl0.9.7, so 
it's likely to cause random breakage on installation if anything gets linked 
to both versions.  We don't want this transition to be happening right now.

We also want to keep this away from the other transitions.  It's already in 
the top 15 stallers.  If libssl0.9.8 gets tied up with the KDE transition, 
people will scream -- and it already is, thanks to openssh-krb5, tellico, and 
php4 (all of which should be reuploaded with built against libssl0.9.7-dev 

Please don't make *any* upload depending on libssl0.9.8.  If your package 
depends on libssl, make it depend on and build against libssl0.9.7, and 
libssl0.9.7-dev.  If your package already depends on libssl0.9.8, please 
upload to *revert* the change, particularly if you want your package to enter 
'testing' in the near future.

To repeat: currently libssl0.9.8 breaks things.  Avoid it.

libpng, imlib, and GNOME 1
The removal of libpng10 from the archive has created some unfortunate 
shockwaves.  libpng itself should make it into etch with no trouble in 3
days, so most of its dependencies should not worry.

Packages which link against any GNOME1 core libraries or gdk-imlib1 should 
rebuild with new versioned dependencies.  See the message from the new 
Since then changes have been made so that you don't *need* to rebuild.  On 
your next upload, however, you will need to fix your build dependencies.

If you were planning to change your package from a GNOME 1 package to a GNOME 
2 package, please just do that instead.  GNOME 2 is already in etch, making 
life a lot easier.

A lot of things are waiting for a RC-bug-free perl to build on all 
architectures.  No estimate for when that will happen yet, but hopefully 

The C++ ABI transition
This is the main ongoing transition. However, it has several "sub-transitions" 
which have dragged in apparently 
unrelated packages, which are described individually below.

Please see 
http://lists.debian.org/debian-devel-announce/2005/07/msg00001.html for 
details about it.  The page at
http://people.debian.org/~mfurr/gxx/ gives some information as to the status 
of particular packages.

If you haven't transitioned your C++-using package, now is most likely the 
time to do so. (The exception is if your package depends on a C++ library 
which has not been transitioned for all architectures yet; this appears to be 
a very short list, but do check before uploading.)

This is going in in a couple of days, and is only awaiting manual action by 
the release team.
It's going to involve breaking the openexr binary in testing (but not the 
library), because otherwise it would have to go in at the same time as JACK & 

libsigc++-1.2 and APT
This is waiting for the removal of obsolete packages and attendant 
cleanup, for a new upload of libapt-front, and for an 
RC-bug-free version of perl which builds everywhere.

Packages which depend on libsigc++-1.2 and are caught up in the KDE/JACK 
transition will be removed from unstable temporarily.

JACK made a major interface change a while back from libjack0.80.0-0 to 
libjack0.100.0-0.  This change is essentially complete in unstable.  (If your 
package hasn't undergone it, it should do so now, unless it depends on an 
untransitioned C++ library, which I think isn't the case for any such 
package.) Unfortunately, this has gotten caught up in the C++ transition, 
because ARTS depends on JACK, and all of KDE depends on ARTS.

KDE is going from 3.3 to 3.4 in parallel with its C++ ABI transition.  We do 
not yet have an estimate for when transitioned KDE will be ready to enter 
etch.  It will almost certainly be after all of the others listed above 
(except openssl0.9.8, which we are trying to avoid).

If your package is one of the hundreds listed as stalled by 
jack-audio-connection-kit, qt-x11-free, arts, openexr, kdelibs, flac, 
unixodbc, taglib, or id3lib3.8.3 at http://bjorn.haxx.se/debian/stalls.html, 
you've been caught up in this transition.  As you can imagine, we would 
really, really like to get this transition done.

Other transitions
Please, please don't.  We really hope we can finish the KDE transition soon, 
and then there should be a period when you can start doing other transitions.  
Any other transition which would delay any of the packages involved in the 
KDE/JACK transition could set us back weeks.

Nathanael Nerode  <neroden@twcny.rr.com>

"(Instead, we front-load the flamewars and grudges in
the interest of efficiency.)" --Steve Lanagasek,

Reply to: