Attempted "testing propagation status" report
So, things look pretty good actually.
KDE 3: Frustratingly slow.
* Still waiting for kdebase 3.1.4 upload which is fully installable (including
kdebase-dev, and therefore ksysguard). This is probably keeping other kde
packages out indirectly; when their -dev Build-Dependencies are uninstallable,
they can't build.
* Also, kdemultimedia needs 3.1.4 uploaded (and will then wait for various
other things).
GNOME 2: All the libraries need to pass their 10-day wait times, and then
most of it should go in at once, probably leaving only a couple of packages
to fix.
perl: Just waiting for its wait time to go.
jack-audio-connection-kit & friends:
* Waiting for gem, which is waiting for a glibc headers fix.
* Also breaks pd-externals, which has the newest version in 'testing'.
This is probably not a real issue (pd-externals depends on pd, which depends
on jack-audio-connection-kit). (Also, pd Replaces: pd-externals.)
pd-externals also FTBFS on hppa. Anyway, pd-externals might need a new
upload; I don't know.
mozilla: All the old RC bugs are stamped out, and now it's FTBFS on m68k and
mipsel.
* On mipsel this is due to a bug in nut.
* On m68k it looks like it's just waiting for a bunch of other things to build.
So it should hopefully go in soon (yay).
postgresql: Waiting for perl.
pilot-link: Waiting for perl.
cyrus-sasl2, krb4, arla, heimdal: I still find these very hard to decipher.
I still can't believe that they really break 56 packages when going in
*together*. Supposedly they're waiting for postgresql, presumably because
'old' postgresql depends on something which is going away (although I cannot
actually figure out what). But are they waiting for anything else?
Is it possible to suggest that the testing scripts do a recur with this combo
in order to see what still breaks when they go in together? Or does the
Release Manager already know? ;-)
After the above things get dealt with, it will probably be time to make
a reassessment and see what (if anything) else involving complicated
dependencies and version transitions really "ought" to go into
sarge. I suspect that there won't be much more and it will become appropriate
to try to figure out how to fix all the "uninstallable in sarge" bugs at that
time.
--
Nathanael Nerode <neroden at gcc.gnu.org>
http://home.twcny.rr.com/nerode/neroden/fdl.html
Reply to: