On Sun, Oct 23, 2005 at 01:12:11AM -0400, Nathanael Nerode wrote: > * penguin-command needs a new upload with fixed build-depends (bug 303705, > which justifies removal of the version in testing if necessary) > * matanza should be removed from testing (#328352, #335274) and probably > even from unstable (given the copyright issues in #335274). > Actually, all of the "maintainer"'s other packages, shc, should be > removed from unstable for copyright reasons as well (#335278, and the > same totally-wrong-copyright bug applies to bandersnatch -- I just > filed it, and #332610). > (How did this guy become a DD? He can't possibly have passed Policy & > Procedures or Tasks & Skills.) He didn't. His NMUs are being sponsored. By multiple sponsors, who don't seem to do much quality checking. :/ > * pgplot5 (non-free) needs an upload to build against libpng12-dev (328345) > * printbill likewise (bug 328333) > * tuxpuck likewise (bug 328335) > * xnecview likewise (bug 328334) The maintainers of all the above packages have had plenty of warning by now. I'm going to go ahead and hint them all for removal. NMUs and whatnot are fine, but I don't think there's any sense in holding up the transition for them. > * zvbi needs a sourceful binNMU for sparc, or a new upload (it's small, so > maybe a new upload is reasonable, but make sure grieg is fixed first so > ARM won't need a binNMU) [aside: there's no such thing as a sourceful *bin*NMU...] What zvbi needs is an outright sourceful upload, because apparently this package is not safely binNMUable. Bug filed. > * gdk-pixbuf has ended up with a dependency on libpng12-0 (>=1.2.8rel-4) > on ARM. Despite being recently binNMUed. > * Same problem on gif2png. > * Similarly, fvwm has acquired the same dependency on ARM. > * I tracked this down to a problem with the ARM buildd 'grieg', which > built both of them. It has an old version of libpng stuck on it. > Yep, checked, it does. Emailed arm@buildd.debian.org, but if you > know a faster way to get results, *please* do so. > * koffice appears to be waiting for imagemagick, which is waiting for... > wait for it... libpng. > Mostly there's a long list of packages which need to go in ahead of > new libpng, which aren't ready. > * dillo needs a binNMU on sparc; then it can go in. > * The ARM buildd (grieg) needs to get rid of the old libpng12-dev, > and then gif2png needs a binNMU on ARM (alternatively, a hand-built binNMU > would work) > * gif2png needs an 'urgent' hint > -- after those two, it can go in > * libgtk-perl has to go in ahead of libpng (or be removed), but it depends > on new perl and new imlib, and so on the whole gnome 1 tangle. Meaning, > GNOME 1 tangle in before lipng in. ;-) Right, so, there are a bunch of packages that can't go in before libpng without binNMUs, and there are a bunch of packages that need to be updated before libpng can go in... but if we merge the existing imlib and wxwindows2.4 hints and kick out the packages whose maintainers still haven't acted on their RC bugs, we're darn close. So it probably makes more sense to just push forward to get all the packages ready to go at the same time, instead of worrying about binNMUs. The biggest blocker then is perl, which is needed in order to update both subversion (for rapidsvn) and libgtk-perl. How nice it would be if dh_perl were less aggressive in setting dependencies. :/ (bug #129034... follow-up sent.) That leaves no reason to remove rapidsvn, since it will be a candidate the same time that libgtk-perl is. > Once it's verified that the ARM buildd has got rid of the old libpng12-dev, > many or all of the ARM binNMUs have to be rerun. > * kdegraphics is now waiting for libgphoto2 (5 days old). It's also not > being tried in the master hint (for unclear reasons, perhaps that). > libgphoto2 is in good shape and should probably be put through 'urgent'. Yes, packages aren't tried when they wait on other packages that aren't candidates. Added an urgent hint for libgphoto2, thanks. > * kdebindings is waiting for ruby1.8, which is stalled primarily because of > an m68k FTBFS (that's the serious bug). Actually, ruby1.8 has been pushed in. > * xastir is FTBFS on hppa because gpsmanship fails to install: > Setting up gpsmanshp (1.2-2) ... > /var/lib/dpkg/info/gpsmanshp.postinst: line 5: 3480 Done echo "pkg_mkIndex -lazy -verbose . gpsmanshp.so" > 3481 Segmentation fault | tclsh$TCLVERSION 2>&1 >/dev/null > dpkg: error processing gpsmanshp (--configure): > subprocess post-installation script returned error exit status 139 > Segfault in tclsh ?!? I'm not sure what package to report this against. > I sent a message to the probably-related bug 334898. well, looks like a tcl bug to me... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. vorlon@debian.org http://www.debian.org/
Attachment:
signature.asc
Description: Digital signature