Hi guys, The trivial little sideshow to the grand machinations of the Debian Project Leader campaign sometimes known as the release is still moving ahead. According to the RC bug list, for example, we've dropped below 200 outstanding release-critical bugs, which is nice, and compared to a couple of weeks ago, something of a half way point. Tomorrow, or in the very near future, most of the following packages will be dropped from testing due to release-critical bugs of one type or another. addressbook gtk-engines-flat scid bnetd guitar sfs cdebconf gwenview libpam-sfs cxref heartbeat timidity doc-rfc inform tkdesk doc-rfc-std zmailer wu-ftpd festival latte xpacman gem noteedit configlet gnome-sudo rscheme arbortext-catalog gri rscheme-modules If you haven't already guessed, you should be interpreting release critical bugs filed against your package as a notice that it'll probably be removed soon. For people who're interested in keeping some handle on this, there are currently two "release-critical bug lists" in use that have slightly different properties. There's the traditional one, at http://bugs.debian.org/~wakkerma/bugs/ which lists open release-critical bugs against all packages in unstable (and thus also counts bugs against packages that are no longer in testing). It's accurate, and informative and helpful, and should be the main place you look. There's also the one the testing scripts generate which give an indication of how buggy the versions of the packages in testing are, at: http://ftp-master.debian.org/testing/testing_probs.html This list, unfortunately, is generated heuristically rather than directly from information in the bug tracking system. So you only get an approximate number of bugs against each package, and you *don't* get a list of which bugs they were exactly, and it can be difficult or impossible to find out. There are other problems with it too -- notably that it doesn't take into account bugs that have been fixed today by moving a package from unstable into testing. It's useful as a general guide to packages that I'm probably considering removing, not as a sole source. People interested in making sure packages they're interested in don't get thrown out are encouraged to peruse both lists if they have spare time. As long as your package isn't in one list or the other (ideally both), there's a reasonable chance I can do something other than throw it out. If it's listed in both, there's little else I can do, and you can probably expect to see it mentioned in one of these posts. For those of you having a first look at the "cannot be installed" packages on the testing_probs.html page mentioned above, you'll notice a few things: one is that i386 is doing incredibly well, with only caudium-php4 (which will be fixed in a couple of days when php4 and caudium get tidied up), and roxen-ssl (which depends on the non-existant pike-crypto package, which users are expected to build themselves). Another is that many of the problems on non-i386 architectures are due to arch:all packages that really aren't applicable to all architectures. Exactly what should be done about those is an open question, and one that's being ignored for woody. Those packages that were marked to be removed from testing last time round have (generally) been unmarked now, so those that have been fixed in the meantime will probably start reappearing in testing. Hopefully the one place they won't start reappearing is in either of the above lists. :) Some difficult problems still need sorting out: * sparc and alpha boot-floppies aren't up to date, and seem to be having problems of one sort or another. Ben Collins is working on the sparc boot-floppies; I'm not aware of anyone working on them for alpha. * ld.so has disappeared from non-i386, but the old package was marked Essential: yes, so can't be removed. A dummy package for the non-i386 arches that had ldso that does nothing but allow you to remove it should be created. It probably needs to Conflict: with libc5 to ensure it's not used to satisfy dependencies. There may be other pitfalls to be taken care of. * New installs of tetex don't work. Patches are available, but fixed packages aren't. Cheers, aj -- Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/> We came. We Saw. We Conferenced. http://linux.conf.au/ ``Debian: giving you the power to shoot yourself in each toe individually.'' -- with kudos to Greg Lehey
Attachment:
pgppLXqtg1Y8C.pgp
Description: PGP signature