Bug#650601: Update on libpng's transition status
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
Reply to: