Bug#650601: libpng is going to be NMUed soon
Hi Emilio wrote: > binary-NEW shouldn't be a big deal. Just make sure to upload to experimental. I triple checked, in 8 hours or so it will finish the deferred queue time. https://ftp-master.debian.org/deferred/libpng1.6_1.6.20-3_amd64.changes the changes file looks fine to me: Distribution: experimental libpng1.6 (1.6.20-3) experimental; urgency=medium (no answers from maintainers is sad) Tobias, I did some uploads in new queue, everything was accepted in a matter of a few hours. for binNEW I think this will be even faster, I got casablanca accepted in a matters of minutes IIRC :) (I think this won't be the case, but I can ping on -ftp if it takes longer times maybe). After the accept... we will be ready for the ack! (I think the unstable upload will follow with no delay after the ack). cheers, G.
Bug#650601: libpng is going to be NMUed soon.
On Sat, 26 Mar 2016 00:50:58 +0100 Emilio Pozuelo Monfort binary-NEW shouldn't be a big deal. Just make sure to upload to experimental. OK, then let's follow Gianfrancos proposoal! Beside that, here's a last report on the rebuilding on my server: (I need to free up space on the server for other purposes, so I need to cease the continous rebuilding) Those are the packages that still fails on my server: calligra(2.8.5+dfsg-1.3~libpng16) caret (5.6.4~dfsg.1-3.1~libpng16) fw4spl (0.9.2-3.1~libpng16) gnubg (1.05.000-7.1~libpng16) libtk-img (1.4.2+dfsg-2.1~libpng16) odin(1.8.8-2.1~libpng16) openvrml(0.18.9-7.1~libpng16) png++ (0.2.5-1.1~libpng16) root-system (5.34.19+dfsg-1.3~libpng16) timidity(2.13.2-40.4~libpng16) xemacs21(21.4.22-14.1~libpng16) Those are currently in testing: - gnubg, FTBFS seems to be #818889, has patch - libtk-img needs libpng1.6 in sid to be fixed (#741894) - png++, NMU in DELAYED/5 #819283 - timidity, RC-Buggy #814879, removal on March 31 -- tobi
Bug#650601: libpng is going to be NMUed soon.
On 26/03/16 00:02, Tobias Frost wrote: > On Wed, 23 Mar 2016 21:58:56 +0100 Gianfranco Costamagna @debian.org> wrote: >> >> 1) provide a real libpng-dev and upload on experimental in 7 days > starting now. >> (I'm going to upload on deferred/7 in a few minutes/hours) >> > > Hi Gianfranco, > > what bothers me is that having a real libpng-dev package requires us to > go through NEW. > I'd avoid NEW-processing at this point of time, as its processing is > non-deterministic and might eat up significant amount of time left > until the freeze... And time is running fast. > > At the moment no package requires a versioned dependency on libpng-dev > anyway, so IMHI that can be deferred to a later time. > (I believe having a real libpng-dev package is a good idea, so lets go > for it, cleared from NEW via experimental *once* libpng16 is is sid) > > At this point of time, I think we're in better control when manually > uploading libpng12 and libpng16 in a coordinated way. > > > Gianfranco, Emilio: Thoughts? binary-NEW shouldn't be a big deal. Just make sure to upload to experimental. Emilio
Bug#650601: libpng is going to be NMUed soon.
On Wed, 23 Mar 2016 21:58:56 +0100 Gianfranco Costamagna wrote: > > 1) provide a real libpng-dev and upload on experimental in 7 days starting now. > (I'm going to upload on deferred/7 in a few minutes/hours) > Hi Gianfranco, what bothers me is that having a real libpng-dev package requires us to go through NEW. I'd avoid NEW-processing at this point of time, as its processing is non-deterministic and might eat up significant amount of time left until the freeze... And time is running fast. At the moment no package requires a versioned dependency on libpng-dev anyway, so IMHI that can be deferred to a later time. (I believe having a real libpng-dev package is a good idea, so lets go for it, cleared from NEW via experimental *once* libpng16 is is sid) At this point of time, I think we're in better control when manually uploading libpng12 and libpng16 in a coordinated way. Gianfranco, Emilio: Thoughts? -- tobi
Bug#650601: libpng is going to be NMUed soon.
On 23/03/16 22:42, Gianfranco Costamagna wrote: > Hi, > >> So what is it that you're talking about? Adding a real libpng-dev package? > > > > exactly. > This was one of the open points, and my opinion is to have a real libpng-dev > package. > > I can of course revert if you don't like it, but as explained before, we might > have less troubles with it, if I understand correctly. OK. I don't have a strong preference, so feel free to go that way. Just wanted to make sure I understood what you were doing. Cheers, Emilio
Bug#650601: libpng is going to be NMUed soon.
Hi, >So what is it that you're talking about? Adding a real libpng-dev package? exactly. This was one of the open points, and my opinion is to have a real libpng-dev package. I can of course revert if you don't like it, but as explained before, we might have less troubles with it, if I understand correctly. sorry for not being clear, Gianfranco
Bug#650601: libpng is going to be NMUed soon.
On 23/03/16 22:23, Gianfranco Costamagna wrote: > Hi, > >> WDYM with versioned depends? > > > as said above: > "a/ virtual provides can't safisfy versioned dependencies" > > maintainers might be able to do something like "Depends: libpng-dev (>=1.6)". > This might help future transitions (not from 12 to 16 probably). > > Always if I understand correctly what maintainers might want to do. > And makes easier to pull the trigger, avoding two uploads at the same time > and some rebuilds > possibly. So what is it that you're talking about? Adding a real libpng-dev package? Cheers, Emilio
Bug#650601: libpng is going to be NMUed soon.
Hi, >WDYM with versioned depends? as said above: "a/ virtual provides can't safisfy versioned dependencies" maintainers might be able to do something like "Depends: libpng-dev (>=1.6)". This might help future transitions (not from 12 to 16 probably). Always if I understand correctly what maintainers might want to do. And makes easier to pull the trigger, avoding two uploads at the same time and some rebuilds possibly. cheers, G.
Bug#650601: libpng is going to be NMUed soon.
Just one comment. On 23/03/16 21:58, Gianfranco Costamagna wrote: > I did some little rework of the package, in bug #813027 > (fixing lintian errors, and some rules refactoring). > I would like to NMU it for experimental, with providing a *real* libpng-dev > package. > > this will ensure next transition will be handled better, and should make this > transition even faster. > (and versioned depends are a good thing for libpng). WDYM with versioned depends? Cheers, Emilio
Bug#650601: libpng is going to be NMUed soon.
Hi, as said by -release team, the open transition are ending, and this opens a slot for libPNG. the work is already done, we just need to upload on experimental, wait some little time, and pull the trigger (yes, after an ack :) ) I did some little rework of the package, in bug #813027 (fixing lintian errors, and some rules refactoring). I would like to NMU it for experimental, with providing a *real* libpng-dev package. this will ensure next transition will be handled better, and should make this transition even faster. (and versioned depends are a good thing for libpng). So, timeframe is: 1) provide a real libpng-dev and upload on experimental in 7 days starting now. (I'm going to upload on deferred/7 in a few minutes/hours) 2) do some testing and fix possible issues. 3) wait for -release team 4) go for unstable. If I understand correctly, a real package will avoid an upload of the old libpng12 that has a simple "Provides". Let me know if it sounds good to you! Stretch is going to freeze in some months, and I don't want to be in a hurry, or have the next stable with libpng12. the work is done, doing it again will be a waste of everybody's time. cheers, G. signature.asc Description: OpenPGP digital signature
