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
