Am Sonntag, den 31.01.2016, 17:52 +0000 schrieb Mattia Rizzolo: > On Sun, Jan 31, 2016 at 05:46:07PM +0100, Tobias Frost wrote: > > Still FTBFS are, I've put an analysis why so on the titanpad [1], > > but > > those are all _not_ libpng related and many of those packages are > > not > > in testing. > > Analysis of what is in testing atm: > > > > blender > > notice that blender should be ready for libpng1.6 once the ilmbase > and > openexr transition start, so that the experimental version can be > used > (which should be fine). > Actually, Those 2 transitions are way smaller than libpng, and I > would > have expected them to be already started... #810568
I just scheduled a build of the experimental version on my server, and it looks good so far. (It needs experimental B-Ds as well) > > criticalmass > > I was able to build this just fine here. > I also tested it against libpng16 and built a binary depending on it > just fine. > I believe there is something fishy on your part here :) Yes, you're right: It has been building fine also on my server already.[1], it was an left over from my list; (I had lately problems with somepackage in conjunction with parallel build and pbuilder -- criticalmass is one of those) [1] http://libpng.sviech.de/!summary.txt > > gmsh > > vtk6 > > These 2 at the moment are not buildable because they are several > levels > down of the openmpi transition and need other libs to be built first. > I just believe openmpi needs to be done first before of this. vtk6 built fine previously with libpn1.6, as well as gmsh. (For gmsh I still have the old buildlog: https://libpng.sviech.de/old/gmsh.build, for vtk6 they've got overwritten but there are still the resulting packages at https://libpng.sviech.de/libpng16/pool/main/v/vtk6/ ) So, I guess we could ignore this collision? > > yt > > yt is going to be autoremoved soon (Feb 9) so this can be ignored. > > > [1] https://titanpad.com/libpng16-transistion > > > So if I'm not blind or anything, I belive this transition has no > actual > blocker (but other transitions to be done first, though). > > Of course in something so big something will come out during the > transition, but hey ^^ It would be a miracle, as we see with openmpi.. Knocking wood, though. But I have the feeling we are in a good position, and at least the next few weeks I'm able to commit some time to this. For the procedure, does it help the case / would it make sense to upload a libpng16 *without* provding libconfig-dev to sid, to have it in testing already, when we pull the trigger? (As you know, said trigger is the Provides: libpng-dev line; without it all the packages will use libpng12-dev..) -- tobi
