control: severity -1 important Hi Tanguy, sorry for the late reply
On 02/04/2016 10:41, Tanguy Ortoo wrote: > Package: libgdk-pixbuf2.0-dev > Version: 2.32.3-1.2 > Severity: grave > Justification: renders package unusable > ^^ nonsense to me. if with "unusable" you mean experimental, well, it is there to be broken, and in case of transition it usually *is* broken, specially because release team almost never did a binNMU there. > While trying to build a new version of my package latexila for > experimental, I noticed it was failing because of libgtk-pixbuf2.0-dev. > Indeed, that package, in unstable and in experimental as well: > > * ships a gdk-pixbuf2.0.pc that requires libpng12.pc; > * depends on libpng-dev which: > - on experimental, is a real package that does not ship libpng12.pc > but only libpng16.pc and libpng.pc; this is a known issue, and you should just binNMU gdk-pixbuf (I did an NMU with a special libpng16-dev build dependency, but with the new libpng1.6 that provides a real libpng-dev and no libpng16-dev a new binNMU has to be performed). > - on unstable, is provided by libpng12-dev which does provide > libpng12.pc, but that situation should change to that of > experimental whenever the new libpng-dev real package is uploaded to > it. that is going to change soon (TM) > > > Basically, when requiring libpng12.pc, it does not seem right to depend > on a package, either virtual or real, that is not guaranteed to provide > it. In my opinion, in its current state, libgdk-pixbuf2.0-dev should > depend on libpng12-dev as this is what it uses, and not on libpng-dev > which may or may not provide what it currently needs. > where? unstable or experimental? you say both unstable and experimental are broken. experimental is broken by definition of transition, while unstable should be fixed, simple as is. in experimental libpng-dev is provided by libpng12-dev so the current transition shoulnd't be an issue. and I don't even see your point. "unstable is broken, so I want to upload to experimental which is by definition even more broken" that sound really strange to me. > > Since there is a transition to make to libpng-dev, one solution would be > to rebuild gdk-pixbuf for experimental, but doing it in an environment > with libpng12-dev not installed and libpng-dev installed from > experimental. That way, its configure script (l. 18507) would just pick > libpng16 and the resulting gdk-pixbuf2.0.pc would require the > libpng16.pc it provides: > conflicts is a good choice here (I didn't test, but it has never given us troubles building it on experimental with a forced libpng-dev, because real packages has higer priority than Provides packages, so the png16 toolchain should be choosen with a simple binNMU) >> for l in libpng16 libpng15 libpng14 libpng12 libpng13 libpng10; do >> […] > > > In the longer term, it could be better to have the configure script > check for libpng before libpng16 or libpng12: > >> for l in libpng libpng16 libpng15 libpng14 libpng12 libpng13 libpng10; do >> […] > > > That way, it would not even need to be adapted for future versions of > libpng. > that is something I leave to the current maintainers :) and now answering to some irc chats: >mbiebl_ it only depends on libpng-dev though 23:20 >mbiebl_ why am I not surprised that something regarding the libpng >transition is broken well, it was uploaded *before* libpng-dev became a real package, so it is not surprising that I broke experimental, specially because -release team asked us to do so. "please push on experimental your solution for unstable", and that obviously meant to break in particular gdk-pixbuf. I hope that will be fixed with the unstable upload and a binNMU. >mbiebl_ the libpng transition is a never ending story of fail 23:27 I guess not anymore, now I have refactored a real part of the package, and I became to provide real packages, fixing multiarch and much more. We got a "please go on" by the maintainers, and this is what we will do. >Tanguy By the way, do you know why is the libpng16 dev package named >libpng-dev and not libpng16-dev? That library is >libpng16, not just libpng, >is it? 23:34 we did ~100 NMUs just to change that bits, is this a good answer? :) the better answer is to not provide a libpng16-dev *at all*, so people will be forced to use the main -dev package. nobody can support more than one libpng implementation at the same time, so there is *no* real need of that number as part of the development package (in fact I removed it also from the other binaries, except for the real library of course) >With unversioned build-deps, the release team can just smack a big "binNMU the >world" button, and if there are no drastic >API breaks, it all Just Works. > 23:35 >Tanguy Assuming the API does not change, right. in that case, test rebuilds (as they have been done in 650601), and NMUs as needed. >mbiebl_ _rene_: ask the ones which NMUed gdk-pixbuf for the libpng >transition > mbiebl_ _rene_: I wouldn't be surprised if something was broken along > the way before we had to force libpng16-dev in the NMU, now it isn't required anymore. If you want to fix it, just binNMU it. (that should make the future smooth in terms of next transitions) >mbiebl_ Tanguy: the breakage comes from turning the virtual libpng-dev >package into a real one 00:27 >mbiebl_ we could work around that by reverting the NMU and changing the >libpng-dev depends to libpng12-dev again 00:27 why? unstable has to have libpng-dev, the problem right now is for people mixing unstable and experimental, and will be over as soon as the transition starts. >Tanguy mapreri, jcristau: Possibly, the fact is I have a package that cannot >build with libgdk-pixbuf2.0-dev/experimental, >and I suspect all packages that >use GTK+ will be in the same situation, and if a similar libgdk-pixbuf2.0-dev >is uploaded to >unstable, it will result in similar breakage. Now, I think a >simple binNMU of gdk-pixbuf in experimental may be just enough >to fix that, >but I really do not feel c 09:21 >Tanguy onfident in doing that myself, as it could very well just break more >things. >Tanguy You can update my bug report if you want, as you certainly know better >than me! 09:22 thanks for the bug report in first place, but you should be right there. a simple binNMU should be enough. >mapreri well, there have been 2 NMU of gdk-pixbuf in experimental >exactly to have it built against libpng1.6 09:23 >Tanguy Well, not sure of what happens but it seems to still require libpng12. >09:23 >Tanguy Let me check again. 09:24 yes, because a maintainer upload overridden the NMU, and in the meanwhile libpng16-dev has stopped to be provided in experimental. So that breakage was somewhat expected. >mapreri there has been a maintainer upload on top of those 2 and now it >is built against libpng12 again 09:24 >mapreri let me check with one of the NMUers if he plans to nmu it >again. 09:24 >Tanguy Okay, that is why. Thanks. 09:25 >mapreri Tanguy: Gianfranco said he will a look later and maybe follow >up on the bug Here I am >Tanguy Okay, thanks. 09:38 >Tanguy While speaking of libpng, I noticed the library has soname >libpng16.so.16, which would suggest it is really libpng16, >not just libpng, >and that API stability is not supposed to be maintained whenever there is a >libpng16 or so. that would be a pain for the next transition, so big no here :) for the later parts many people on -devel answered in a more appropriate way, so thanks jcristau and everybody else for the great replies. Sorry for quoting irc, but it was really easier to do. (I hope I didn't sound too rude, but we are really near the start of the transition, just waiting for -release ack, and we spent already a lot of time on this, so I prefer to leave stuff like asking binNMUs or fixing experimental to other people, with a ~500 packages to check my priorities are somewhere else). have many thanks, and sorry for the experimental breakage :) cheers! Gianfranco
signature.asc
Description: OpenPGP digital signature
