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

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
* 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

Nathanael Nerode  <neroden at gcc.gnu.org>

Reply to: