Re: libpng prognosis
Thomas Bushnell BSG wrote: > Nathanael Nerode <[EMAIL PROTECTED]> writes: > >> Mostly there's a long list of packages which need to go in ahead of >> new libpng, which aren't ready. > > Are zero-day NMUs appropriate for any of these: > >> * penguin-command needs a new upload with fixed build-depends (bug >> 303705, >> which justifies removal of the version in testing if necessary) >> * printbill likewise (bug 328333) >> * tuxpuck likewise (bug 328335) >> * xnecview likewise (bug 328334) Well, printbill and penguin-command have very recently elevated severities (as in, an hour ago), so maybe the maintainers should be given a day or two. Zero-day NMUs certainly seem appropriate for tuxpuck and xnecview. >> * 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. ;-) > > The gnome-1 tangle is the png tangle. Well, we've done a little detangling by avoiding the libpng shlibs bump; the hope was to put the things 'broken by' new libpng through *before* new libpng rather than having to do it simultaneously -- hence my describing them as different tangles, even though they have the same original cause. > But why does the new libpng > fail with the old libgtk-perl? The old libgtkxmhtml-perl depended on libpng10-0 directly, and libpng10-0 goes away when new libpng gets in. -- ksig --random| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libpng prognosis
On Sun, Oct 23, 2005 at 12:15:08AM -0700, Thomas Bushnell BSG wrote: > Nathanael Nerode <[EMAIL PROTECTED]> writes: > > Mostly there's a long list of packages which need to go in ahead of > > new libpng, which aren't ready. > Are zero-day NMUs appropriate for any of these: > > * penguin-command needs a new upload with fixed build-depends (bug 303705, > > which justifies removal of the version in testing if necessary) > > * printbill likewise (bug 328333) > > * tuxpuck likewise (bug 328335) > > * xnecview likewise (bug 328334) NMUs are warranted for any of them; please use the delayed queues when uploading, pending resolution of our discussion on debian-devel of what an appropriate NMU policy should look like for etch. > > * 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. ;-) > The gnome-1 tangle is the png tangle. But why does the new libpng > fail with the old libgtk-perl? libgtk-perl builds a package which depends on the old libpng, so libpng can't be updated until libgtk-perl is updated first. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: libpng prognosis
Nathanael Nerode <[EMAIL PROTECTED]> writes: > Mostly there's a long list of packages which need to go in ahead of > new libpng, which aren't ready. Are zero-day NMUs appropriate for any of these: > * penguin-command needs a new upload with fixed build-depends (bug 303705, > which justifies removal of the version in testing if necessary) > * printbill likewise (bug 328333) > * tuxpuck likewise (bug 328335) > * xnecview likewise (bug 328334) > * 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. ;-) The gnome-1 tangle is the png tangle. But why does the new libpng fail with the old libgtk-perl? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
libpng prognosis
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 * penguin-command needs a new upload with fixed build-depends (bug 303705, which justifies removal of the version in testing if necessary) * 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) * 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.) * pgplot5 (non-free) needs an upload to build against libpng12-dev (328345) * printbill likewise (bug 328333) * tuxpuck likewise (bug 328335) * xnecview likewise (bug 328334) * 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. ;-) * if rapidsvn and pysvn are removed, or subversion gets in, wxwindows should go in. * That's the lot. Everything else broken by new libpng depends on wxwindows or dillo. -- Nathanael Nerode <[EMAIL PROTECTED]> "(Instead, we front-load the flamewars and grudges in the interest of efficiency.)" --Steve Lanagasek, http://lists.debian.org/debian-devel/2005/09/msg01056.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
