It's been a long trip, and as usual not everything has gone according to
plan; but we are now nearing the point of being able to get the bulk of
the C++ ABI transition pushed into testing. At this point, most of the
packages waiting to be updated in testing are tied to this transition in
one way or another; including all of these libraries that are undergoing
ABI transitions:
arts
coin2
cppunit
dbus
dynamite
geos
flac
freetds
gdal
heartbeat
icu
imagemagick
jack-audio-connection-kit
kdelibs
kdemultimedia
kdepim
libfwbuilder
libkexif
libkipi
libmodplug
libmusicbrainz-2.1
libpqxx
libsidplay
libtunepimp
libxbase
openexr
orange
net-snmp
qscintilla
qt-x11-free
sablotron
sidplay-libs
taglib
unixodbc
vdk2
vdkxdb2
vtk
wv2
xbsql
xerces25
xerces26
As a result, any packages that have versions in testing and depend on
one of these libraries must be updated at the same time. For the first
time over the past months, we are now able to get a comprehensive look
at just which packages are involved in this transition -- around 300
source packages that need to be updated! As a result, the release
team asks that the maintainers refrain from uploads of these packages for
any reason without coordination with the release team, until this
transition completes; uncoordinated uploads will most likely lead to your
package being removed from testing to let the transition complete. For your
reference, a list of source packages known to be involved, grouped by
maintainer, is attached.
In addition, this transition is in danger of being tied to a very
untimely shlibs bump in libstdc++6, and the release team is working out
whether certain affected packages should be removed temporarily from
testing in order to avoid further delays. The list of those packages is
included as the second attachment to this mail.
If all goes well, we are very close to being able to get this monster
transition through, putting us over the hump on the C++ ABI change for
etch. Please continue coordinating with the release team before
starting any new library transitions, though, so that we don't find
testing wedged behind *another* such clump of libraries. :)
One other library transition that bears commenting at this point is the
libssl0.9.7->libssl0.9.8 transition, about which there has already been
a fair amount of discussion on debian-devel. This transition was not
anticipated by the release team, but libssl0.9.8 has reached testing so
there is no reason to worry about your package being rebuilt against
libssl0.9.8 instead of libssl.0.9.7. However, this does *not* mean that
you should do a sourceful upload of your package just for the libssl
transition -- least of all if your package is already tied up in another
lib transition. First, we are finding some problems with packages built
against the new libssl which appear to be bugs in the openssl package
itself, such that if you don't have another reason to upload, your users
are probably better served with libssl0.9.7 for the moment. Second,
thanks to some enhancements Ryan Murray has recently made to
buildd/wanna-build, it is now possible for the release team to request
automated buildd binNMUs of a package across all architectures for
library transitions, sparing maintainers the trouble of doing
rebuild-only sourceful uploads. As some of you have already discovered,
this is turning up bugs in packages that can't be binNMUed because of
arch: any packages which depend on (= ${Source-Version}) of an arch: all
package. Please help make future library transitions easier by making
sure your packages are binNMU-safe; the best way to do this currently is by
relaxing dependencies between arch: any and arch: all packages.
That's all the news for now; look forward to hearing more about the end
of the KDE transition and the first d-i beta for etch in the near
future!