Re: MBF Announcement: Transition libpng12 -> libpng16

[Tobias Frost]

Hallo -devel,

Note that libpng1.6 is now in sid, so the libpng 1.6 transition has
finally started. 

To keep the transition short, please keep an eye on packages; of course
we will also do NMUs when neeeded.

The transistion tracker is here:
https://release.debian.org/transitions/html/libpng1.6.html


As announced, I will now raise the remaining bugs to RC level, none of
the affected packages are in testing right now:

#814879: timidity: FTBFS with libpng16 / does not specify libpng-dev B-
D,
 
#809874: root-system: FTBFS with libpng16, 

#810209: yt: Please update dependency on libpng-dev

#741894: libtk-img: FTBFS with libpng16,

#809935: fw4spl: FTBFS with libpng16,
 
#816115: openvrml-dev: Please depend on libpng-dev instead of libpng12-
dev

--
tobi

Re: MBF Announcement: Transition libpng12 -> libpng16

[Tobias Frost]

> On Mon, Jan 04, 2016 at 12:02:00PM +0100, Tobias Frost wrote:
>> we are currently planning to start the transition of libpng.
>
> Is there a repository with packages rebuilt against libpng16?  Some
> dependency chains are massive, such as the gtk/gdk/... which makes
> testing fixes not possible without large amounts of work.
>

I just setup one, manually feeded from my pbuilder's output directory.

I only pushed a few packages, all of them rebuilt against libpng16. Basically
all with lib, gtk and cairo in the source-package name.
Let me know if you miss any package, I'll add it on request.

It should work with:

deb http://libpng.sviech.de/libpng16 sid main

I generated a dedicated signing key for the archive, the pubkey is here.
They key is signed with my Debian key; it is NOT published to any keyserver
(and please do not so)

https://libpng.sviech.de/libpng16/pubkey.txt

$ gpg --fingerprint
/home/tobi/.gnupg/pubring.gpg
-
pub   4096R/93989C3F 2016-01-12 [expires: 2017-01-11]
  Key fingerprint = 4F0C 1B12 77F4 C66A 2416  2160 8FAB E7B0 9398 9C3F
uid  Tobias Frost (libpng 1.6 transition archive signing key)

sub   4096R/891A417C 2016-01-12 [expires: 2017-01-11]

-- 
tobi

Re: MBF Announcement: Transition libpng12 -> libpng16

[Adam Borowski]

On Mon, Jan 04, 2016 at 12:02:00PM +0100, Tobias Frost wrote:
> we are currently planning to start the transition of libpng.

Is there a repository with packages rebuilt against libpng16?  Some
dependency chains are massive, such as the gtk/gdk/... which makes
testing fixes not possible without large amounts of work.

-- 
A tit a day keeps the vet away.

Re: MBF Announcement: Transition libpng12 -> libpng16

[Tobias Frost]

Dear Debian-devel,

The preparation for the transition are going pretty much good.
In the meantime the bugs have been filed and there are already many
fixes uploaded. MANY THANKS for all of you.

I'm also rebuilding newly uploaded packages to keep libpng.sviech.de
somehow up to date.  

Of course, I take any help in NMUing the remaining cases, especially
the FTBFS ones: The bugs Nobuhiro filed years ago usually have patches
in them, so it is normally quite straight-forward. 

One reminder, as I saw this at now already in a few packages:

For uploads to sid, DO NOT USE 

 libpng16-dev | libpng-dev

The buildds will *always* take the first alternative, libpng16-dev in
this case. So this will FTBFS on the buildds.
In the (unlikely) case you can only be compatible with libpng16, upload
to experimental for now.

Thanks!

-- 
tobi

Re: MBF Announcement: Transition libpng12 -> libpng16

[Tobias Frost]

Am Mittwoch, den 06.01.2016, 01:27 +0100 schrieb Samuel Thibault:
> Rene Engelhard, on Tue 05 Jan 2016 22:15:31 +0100, wrote:
> > On Tue, Jan 05, 2016 at 09:58:03PM +0100, Rene Engelhard wrote:
> > > On Tue, Jan 05, 2016 at 09:50:58PM +0100, Samuel Thibault wrote:
> > > > Rene Engelhard, on Tue 05 Jan 2016 21:43:33 +0100, wrote:
> > > > > So that it will immediately fail when something eventually
> > > > > picks
> > > > > up the experimental packages (as experimental buildds right
> > > > > now do in some
> > > > > situations)?
> > > > 
> > > > ? No, experimental buildds only pick from experimental what is
> > > > not
> > > > available from sid. If something is available from sid, they
> > > > will pick
> > > > it up from there, even if experimental has a newer version.
> > > 
> > > That is demonstrateable untrue since the resolver switch a few
> > > times ago.
> > 
> > See e.g.
> > 
> > https://buildd.debian.org/status/fetch.php?pkg=libreoffice=i38
> > 6=1%3A5.1.0~alpha1-3=1446915107
> > 
> > firebird-dev in sid satifies the build-dep and still it was
> > installed from
> > experimental.
> 
> Uh, I'm surprised, that's not what I thought was supposed to
> happen...
> 
> Samuel
> 

My observation during the mass-rebuild was to be really careful with
Provided packages (here the libpng-dev Package): If another B-D
requests explictly libpng12-dev, for example, the resolver WILL install
this as it thinks it will make everyone happy. That's why I have a hook
in my pbulder setup to *really ensure* that libpng16-dev is installed
before starting the real build. 

Howver, I leave the exact layout of the new package up to the libpng
maintainers: They should decide how they want to do it...
(IMHO I'd love to have a real libpng-dev package which depends on the
real thing; this would enable to version B-Ds on libpng-dev..)

-- 
tobi

Re: MBF Announcement: Transition libpng12 -> libpng16

[Andreas Metzler]

In gmane.linux.debian.devel.general Tobias Frost  wrote:
[...]
> (IMHO I'd love to have a real libpng-dev package which depends on the
> real thing; this would enable to version B-Ds on libpng-dev..)

The other option would be versioned provides.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: MBF Announcement: Transition libpng12 -> libpng16

[Cyril Brulebois]

Hi,

(adding debian-boot@, debian-release@ to Cc)

Tobias Frost  (2016-01-04):
> Dear debian-devel,
> 
> we are currently planning to start the transition of libpng.
> The transition bug can be found here:
> https://bugs.debian.org/650601.
> 
> Out of the 463 rebuilt packages 117 FTBFS with the new libpng, however
> not every failure can be attributed to the library.
> 
> Logs from the rebuild can be found here: http://libpng.sviech.de, as
> well as a scratchpad with a short analysis: 
> https://titanpad.com/libpng16-transistion
> 
> Out of those results, mass bug filings will be conducted:
> - Packages that fail to build with the new libpng
> - Packages that B-D on ancient libpng3-dev, libpng12-0-dev and (the
> soon-obsolete) libpng12-dev, asking to update their B-Ds to libpng-dev
> 
> There are already bugs filed earlier against certain packages:
> https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=libpng15-transition
> =libpng%40packages.debian.org
> Those bugs will be updated with the new usertag to avoid filing
> duplicate bugs.
> 
> The bugs will be non-RC for the time being, when the transition starts
> the severity will be raised appropriately. 
> 
> The current plan is drafted as:
> 
> 0. Assess situation (rebuild) -- done
> 1. Announce MBF (this mail) and execute it.
> (1a. I'll also try to patches and attach them to the bugs)
> 2. Nobuhiro to upload to libpng1.6 to unstable. (after "GO" from the
> release team)
> 3. Raise severity to RC
> 4. binNMU / NMUing packgages 
> 5. fix remaining issues to finish transition
> 6. Remove libpng12 from unstable

Please make sure to coordinate this transition's start with the d-i team
through debian-boot@ since this transition will likely impact d-i's
releasability through libpng's udeb (mostly through libcairo, libfreetype).

Speaking of this particular udeb, I've just spotted libpng16-16-udeb has
a Conflicts against libpng12-0-udeb. I'm not sure why, and the changelog
doesn't seem to explain either. libpng16-16 and libpng12-0 seems to be
co-installable, so I'm not sure why their respective udebs shouldn't be.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: MBF Announcement: Transition libpng12 -> libpng16

[Paul Wise]

On Mon, Jan 4, 2016 at 9:06 PM, Simon McVittie wrote:

> https://lintian.debian.org/tags/embedded-library.html and
> https://anonscm.debian.org/viewvc/secure-testing/data/embedded-code-copies?view=co
> might be useful, although the latter seems to be outdated (it says
> libtk-img embeds libpng, which is no longer true). Is there a newer
> security team list somewhere?

I would suggest using Debian codesearch to find more code copies. The
embedded-code-copies file in the secure-testing repo is manually
updated, so often gets out of date.

https://wiki.debian.org/EmbeddedCodeCopies

> chromium and ice* might be able to move from their embedded copies to a
> newer system copy, or not, depending whether they've patched them.

secure-testing e-c-c doesn't mention chromium and doesn't say if ice*
use forks or embeds.

> I think eagle contains forks of its various libraries, but I could be
> wrong. It probably needs adding to the embedded code copies list
> multiple times?

https://security-tracker.debian.org/tracker/data/report

> syslinux (and the copy of it in d-i) runs at a level below Linux, so the
> system copy of libpng is not useful. If syslinux is parsing anything
> untrusted then you have much larger problems than libpng, so an outdated
> libpng is presumably not really a problem.

It would be nice if this used artifacts built from src:libpng instead
of embedding a copy of the code though.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: MBF Announcement: Transition libpng12 -> libpng16

[Andreas Metzler]

Tobias Frost  wrote:
> For those want to test against libpng1.6: 
> Note that the libpn16 package in experimental does NOT Provide libpng-
> dev at the moment. As I've hacked something together for my rebuild,
> you can grab the dsc here: 
> https://libpng.sviech.de/libpng_package_used/libpng1.6_1.6.19-1.dsc

Hello,

is there a reason why the experimental packages do not provide
libpng-dev? It seems unnecessarily cumbersome to require maintainers to
make and install a local rebuild of png (or use equivs) to test the
transition.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: MBF Announcement: Transition libpng12 -> libpng16

[Rene Engelhard]

On Tue, Jan 05, 2016 at 08:04:53PM +0100, Andreas Metzler wrote:
> Tobias Frost  wrote:
> > For those want to test against libpng1.6: 
> > Note that the libpn16 package in experimental does NOT Provide libpng-
> > dev at the moment. As I've hacked something together for my rebuild,
> > you can grab the dsc here: 
> > https://libpng.sviech.de/libpng_package_used/libpng1.6_1.6.19-1.dsc
[...]
> is there a reason why the experimental packages do not provide
> libpng-dev? It seems unnecessarily cumbersome to require maintainers to
> make and install a local rebuild of png (or use equivs) to test the
> transition.

So that it will immediately fail when something eventually picks
up the experimental packages (as experimental buildds right now do in some
situations)? Thank you, please not.

Been there, done that at the last round it was attempted, after which
I reverted it back then.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662411#37.

And I still see libpng12 refererences in some relevant pkg-config files,
which most probably will then still fail when libpng16-dev gets picked up
(unless it started to provide libpng12.pc, which I didn't check but doubt.)

Regards,

Rene

Re: MBF Announcement: Transition libpng12 -> libpng16

[Samuel Thibault]

Rene Engelhard, on Tue 05 Jan 2016 21:43:33 +0100, wrote:
> So that it will immediately fail when something eventually picks
> up the experimental packages (as experimental buildds right now do in some
> situations)?

? No, experimental buildds only pick from experimental what is not
available from sid. If something is available from sid, they will pick
it up from there, even if experimental has a newer version.

> Been there, done that at the last round it was attempted, after which
> I reverted it back then.
> 
> See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662411#37.

This is a different thing: buildds install real packages, yes, and don't
want to install virtual packages. But this is completely independent
from sid vs unstable.

Samuel

Re: MBF Announcement: Transition libpng12 -> libpng16

[Rene Engelhard]

On Tue, Jan 05, 2016 at 09:50:58PM +0100, Samuel Thibault wrote:
> Rene Engelhard, on Tue 05 Jan 2016 21:43:33 +0100, wrote:
> > So that it will immediately fail when something eventually picks
> > up the experimental packages (as experimental buildds right now do in some
> > situations)?
> 
> ? No, experimental buildds only pick from experimental what is not
> available from sid. If something is available from sid, they will pick
> it up from there, even if experimental has a newer version.

That is demonstrateable untrue since the resolver switch a few times ago.

And yes, the respective people know and a fix is in the works.

> This is a different thing: buildds install real packages, yes, and don't
> want to install virtual packages. But this is completely independent
> from sid vs unstable.

OK, true, I misremembered. My bad.

Regards,

Rene

Re: MBF Announcement: Transition libpng12 -> libpng16

[Rene Engelhard]

On Tue, Jan 05, 2016 at 09:58:03PM +0100, Rene Engelhard wrote:
> On Tue, Jan 05, 2016 at 09:50:58PM +0100, Samuel Thibault wrote:
> > Rene Engelhard, on Tue 05 Jan 2016 21:43:33 +0100, wrote:
> > > So that it will immediately fail when something eventually picks
> > > up the experimental packages (as experimental buildds right now do in some
> > > situations)?
> > 
> > ? No, experimental buildds only pick from experimental what is not
> > available from sid. If something is available from sid, they will pick
> > it up from there, even if experimental has a newer version.
> 
> That is demonstrateable untrue since the resolver switch a few times ago.

See e.g.

https://buildd.debian.org/status/fetch.php?pkg=libreoffice=i386=1%3A5.1.0~alpha1-3=1446915107

firebird-dev in sid satifies the build-dep and still it was installed from
experimental.

(Also OpenJDK 8 was installed (LO only build-deps on default-jdk, which was
and is 7 in sid, just 8 in experimental)

(yes, I added a build-conflicts against firebird 3 later to work around that.)

https://buildd.debian.org/status/fetch.php?pkg=libreoffice=hppa=1%3A5.1.0~rc1-1=1450594629

libmdds-dev in unstable satifies the build-dep, still the experimental one was
installed.

(Build-Conflicts will be added in the next upload as a workaround.)

Regards,
 
Rene

Re: MBF Announcement: Transition libpng12 -> libpng16

[Samuel Thibault]

Rene Engelhard, on Tue 05 Jan 2016 22:15:31 +0100, wrote:
> On Tue, Jan 05, 2016 at 09:58:03PM +0100, Rene Engelhard wrote:
> > On Tue, Jan 05, 2016 at 09:50:58PM +0100, Samuel Thibault wrote:
> > > Rene Engelhard, on Tue 05 Jan 2016 21:43:33 +0100, wrote:
> > > > So that it will immediately fail when something eventually picks
> > > > up the experimental packages (as experimental buildds right now do in 
> > > > some
> > > > situations)?
> > > 
> > > ? No, experimental buildds only pick from experimental what is not
> > > available from sid. If something is available from sid, they will pick
> > > it up from there, even if experimental has a newer version.
> > 
> > That is demonstrateable untrue since the resolver switch a few times ago.
> 
> See e.g.
> 
> https://buildd.debian.org/status/fetch.php?pkg=libreoffice=i386=1%3A5.1.0~alpha1-3=1446915107
> 
> firebird-dev in sid satifies the build-dep and still it was installed from
> experimental.

Uh, I'm surprised, that's not what I thought was supposed to happen...

Samuel

MBF Announcement: Transition libpng12 -> libpng16

[Tobias Frost]

Dear debian-devel,

we are currently planning to start the transition of libpng.
The transition bug can be found here:
https://bugs.debian.org/650601.

Out of the 463 rebuilt packages 117 FTBFS with the new libpng, however
not every failure can be attributed to the library.

Logs from the rebuild can be found here: http://libpng.sviech.de, as
well as a scratchpad with a short analysis: 
https://titanpad.com/libpng16-transistion

Out of those results, mass bug filings will be conducted:
- Packages that fail to build with the new libpng
- Packages that B-D on ancient libpng3-dev, libpng12-0-dev and (the
soon-obsolete) libpng12-dev, asking to update their B-Ds to libpng-dev

There are already bugs filed earlier against certain packages:
https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=libpng15-transition
=libpng%40packages.debian.org
Those bugs will be updated with the new usertag to avoid filing
duplicate bugs.

The bugs will be non-RC for the time being, when the transition starts
the severity will be raised appropriately. 

The current plan is drafted as:

0. Assess situation (rebuild) -- done
1. Announce MBF (this mail) and execute it.
(1a. I'll also try to patches and attach them to the bugs)
2. Nobuhiro to upload to libpng1.6 to unstable. (after "GO" from the
release team)
3. Raise severity to RC
4. binNMU / NMUing packgages 
5. fix remaining issues to finish transition
6. Remove libpng12 from unstable

Those two MBFs are planned:

1. FTBFS 
2. B-D on old dev package

Templates:

Subject: $PACKAGE: FTBFS with new libpng16
Severity: important
User: lib...@packages.debian.org
Usertags: libpng16-transition

Dear maintainer of $PACKAGE,

Currently we are preparing the transistion of libpng1.2 to libpng1.6.
The transistion bug is #650601.

A rebuilt of all packages depending on libpng-dev and libpng12-dev has
been done. The result with buildlogs can be found here: https://libpng.
sviech.de/

$PACKAGE FTBFS during this rebuild. The buildlog is available at 
https://libpng.sviech.de/$PACKAGE.build
 
The Titanpad at https://titanpad.com/libpng16-transistion might gives y
ou clues about what went wrong as well as contains some
recipes/pointers how to fix them.  

Please try to make $PACKAGE compatible with libpng16 and then make sure
to B-D on libpng-dev only, if the fix makes it possible to compile it
against libdev12 and libdev16. If you can only make in a non-backward
compatible way, please B-D on libpng16-dev. 

This bug will become RC as soon as the transistion starts.

Best regards,
-- 
tobi

# Case 2: B-D not libpng-dev

Subject: $PACKAGE: Please update dependency on libpng-dev
Severity: important
User: lib...@packages.debian.org
Usertags: libpng16-transition

Dear maintainer of $PACKAGES,

Currently we are preparing the transistion of libpng1.2 to libpng1.6.
The transistion bug is #650601.

A rebuild of all packages depending on libpng-dev and libpng(3,12,12-
0)-dev has been done.
The result with buildlogs can be found here: http://libpng.sviech.de/ 

$PACKAGE (build-)depends an versioned  development package
(libpng-??.dev), however it seems to build fine also with the new
libpng-1.6. Therefore please update your (build-)depends to libpng-dev
to help in the transition.

This bug will become RC as soon as the transistion starts, 
as it is planned to remove libpng12.  

Thanks!

-- 
tobiChristian T. Steigies 
   hp2xx

Debian QA Group 
   mgp

Debichem Team 
   pymol

Michael Banck 
   pymol (U)

Ansgar Burchardt 
   xaos (U)

Debian FlightGear Crew 
   flightgear

Debian Games Team 
   xaos

Kari Pahula 
   crossfire-client

Markus Wanner 
   flightgear (U)

Ove Kaaven 
   flightgear (U)

Adam Majer 
   mrtg (U)

Alan Bain 
   xnecview

Alastair McKinstry 
   cdo
   emoslib
   ncl

Alessio Treglia 
   camorama (U)
   harvid (U)

Alexander Reichle-Schmehl 
   netpanzer (U)

Alexander Wirt 
   icinga (U)

Andreas Barth 
   netpbm-free

Andreas Henriksson 
   gdk-pixbuf (U)

Andreas Metzler 
   enblend-enfuse (U)
   hugin (U)
   libpano13 (U)

Andreas Rönnquist 
   allegro5 (U)

Andrei Karas 
   manaplus

Android tools Maintainer 
   android-platform-frameworks-base

Ansgar Burchardt 
   simutrans (U)

Aurelien Jarno 
   qemu (U)

Axel Beckert 
   dillo

Balint Reczey 
   kodi (U)

Barry deFreese 
   netpanzer (U)

Barry deFreese 
   clanlib (U)

Bret Curtis 

Re: MBF Announcement: Transition libpng12 -> libpng16

[Jakub Wilk]

* Tobias Frost , 2016-01-04, 12:02:
Logs from the rebuild can be found here: http://libpng.sviech.de, as 
well as a scratchpad with a short analysis: 

https://titanpad.com/libpng16-transistion


Plain-text version for people who don't enjoy running non-free JS code:
https://titanpad.com/ep/pad/export/libpng16-transistion/latest


Currently we are preparing the transistion of libpng1.2 to libpng1.6.


s/transistion/transition/ (here and in other places)


been done. The result with buildlogs can be found here: https://libpng.
sviech.de/


URLs work better when they're not line-wrapped. :)


The Titanpad at https://titanpad.com/libpng16-transistion might gives y
ou clues about what went wrong as well as contains some


s/gives/give/
s/y\nou/you/

--
Jakub Wilk

Re: MBF Announcement: Transition libpng12 -> libpng16

[Tobias Frost]

Am Montag, den 04.01.2016, 12:02 +0100 schrieb Tobias Frost:

For those want to test against libpng1.6: 
Note that the libpn16 package in experimental does NOT Provide libpng-
dev at the moment. As I've hacked something together for my rebuild,
you can grab the dsc here: 
https://libpng.sviech.de/libpng_package_used/libpng1.6_1.6.19-1.dsc

--
tobi

signature.asc
Description: This is a digitally signed message part

Re: MBF Announcement: Transition libpng12 -> libpng16

[Bastien Roucaries]

Le 4 janvier 2016 12:02:00 GMT+01:00, Tobias Frost  a écrit :
>Dear debian-devel,
>
>we are currently planning to start the transition of libpng.
>The transition bug can be found here:
>https://bugs.debian.org/650601.
>
>Out of the 463 rebuilt packages 117 FTBFS with the new libpng, however
>not every failure can be attributed to the library.
>
>Logs from the rebuild can be found here: http://libpng.sviech.de, as
>well as a scratchpad with a short analysis: 
>https://titanpad.com/libpng16-transistion
>
>Out of those results, mass bug filings will be conducted:
>- Packages that fail to build with the new libpng
>- Packages that B-D on ancient libpng3-dev, libpng12-0-dev and (the
>soon-obsolete) libpng12-dev, asking to update their B-Ds to libpng-dev
>
>There are already bugs filed earlier against certain packages:
>https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=libpng15-transition
>=libpng%40packages.debian.org
>Those bugs will be updated with the new usertag to avoid filing
>duplicate bugs.
>
>The bugs will be non-RC for the time being, when the transition starts
>the severity will be raised appropriately. 
>
>The current plan is drafted as:
>
>0. Assess situation (rebuild) -- done
>1. Announce MBF (this mail) and execute it.
>(1a. I'll also try to patches and attach them to the bugs)
>2. Nobuhiro to upload to libpng1.6 to unstable. (after "GO" from the
>release team)
>3. Raise severity to RC
>4. binNMU / NMUing packgages 
>5. fix remaining issues to finish transition
>6. Remove libpng12 from unstable
>
>Those two MBFs are planned:
>
>1. FTBFS 
>2. B-D on old dev package


Add also bug to package using embeded libpng 1.6 like texlive ?
>
>Templates:
>
>Subject: $PACKAGE: FTBFS with new libpng16
>Severity: important
>User: lib...@packages.debian.org
>Usertags: libpng16-transition
>
>Dear maintainer of $PACKAGE,
>
>Currently we are preparing the transistion of libpng1.2 to libpng1.6.
>The transistion bug is #650601.
>
>A rebuilt of all packages depending on libpng-dev and libpng12-dev has
>been done. The result with buildlogs can be found here: https://libpng.
>sviech.de/
>
>$PACKAGE FTBFS during this rebuild. The buildlog is available at 
>https://libpng.sviech.de/$PACKAGE.build
> 
>The Titanpad at https://titanpad.com/libpng16-transistion might gives y
>ou clues about what went wrong as well as contains some
>recipes/pointers how to fix them.  
>
>Please try to make $PACKAGE compatible with libpng16 and then make sure
>to B-D on libpng-dev only, if the fix makes it possible to compile it
>against libdev12 and libdev16. If you can only make in a non-backward
>compatible way, please B-D on libpng16-dev. 
>
>This bug will become RC as soon as the transistion starts.
>
>Best regards,
>-- 
>tobi
>
># Case 2: B-D not libpng-dev
>
>Subject: $PACKAGE: Please update dependency on libpng-dev
>Severity: important
>User: lib...@packages.debian.org
>Usertags: libpng16-transition
>
>Dear maintainer of $PACKAGES,
>
>Currently we are preparing the transistion of libpng1.2 to libpng1.6.
>The transistion bug is #650601.
>
>A rebuild of all packages depending on libpng-dev and libpng(3,12,12-
>0)-dev has been done.
>The result with buildlogs can be found here: http://libpng.sviech.de/ 
>
>$PACKAGE (build-)depends an versioned  development package
>(libpng-??.dev), however it seems to build fine also with the new
>libpng-1.6. Therefore please update your (build-)depends to libpng-dev
>to help in the transition.
>
>This bug will become RC as soon as the transistion starts, 
>as it is planned to remove libpng12.  
>
>Thanks!
>
>-- 
>tobi

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.

Re: MBF Announcement: Transition libpng12 -> libpng16

[Norbert Preining]

Hi Tobias,

> I guess I'll drop Norbert a line for now to make him aware 
> of the libpng transistion... (CC'ed)

Oh, I would be more than happy to have libpng16 in unstable!!!

I can rebuild texlive-bin at any time with system-libpng, just
need a working copy. But first I need the other libs being
rebuilt (freetype, poppler, libgs at least is my guess)

Please send a bug report on src:texlive-bin, if possible.

Thanks

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13

Re: MBF Announcement: Transition libpng12 -> libpng16

[Simon McVittie]

On 04/01/16 12:50, Tobias Frost wrote:
> Am Montag, den 04.01.2016, 12:00 + schrieb Bastien Roucaries:
>> Add also bug to package using embeded libpng 1.6 like texlive ?
> 
> Thanks for the hint, I frankly forgot to check for code copies.

https://lintian.debian.org/tags/embedded-library.html and
https://anonscm.debian.org/viewvc/secure-testing/data/embedded-code-copies?view=co
might be useful, although the latter seems to be outdated (it says
libtk-img embeds libpng, which is no longer true). Is there a newer
security team list somewhere?

In addition to texlive:

chromium and ice* might be able to move from their embedded copies to a
newer system copy, or not, depending whether they've patched them.

I think eagle contains forks of its various libraries, but I could be
wrong. It probably needs adding to the embedded code copies list
multiple times?

syslinux (and the copy of it in d-i) runs at a level below Linux, so the
system copy of libpng is not useful. If syslinux is parsing anything
untrusted then you have much larger problems than libpng, so an outdated
libpng is presumably not really a problem.

xserver-xorg-video-nvidia* are presumably unfixable (proprietary binaries).

S

Re: MBF Announcement: Transition libpng12 -> libpng16

[Carsten Schoenert]

Am 04.01.2016 um 14:06 schrieb Simon McVittie:
> In addition to texlive:
> 
> chromium and ice* might be able to move from their embedded copies to a
> newer system copy, or not, depending whether they've patched them.

Happily Icedove isn't using here a embedded version of libpng, that's a
little bit surprising. :-)

The configure check simply searches for two functions:

> 3636 if test -z "$PNG_DIR" -o "$PNG_DIR" = no; then
> 3637 MOZ_NATIVE_PNG=
> 3638 else
> 3639 AC_CHECK_LIB(png, png_get_valid, [MOZ_NATIVE_PNG=1 
> MOZ_PNG_LIBS="-lpng"],
> 3640  AC_MSG_ERROR([--with-system-png requested but no 
> working libpng found]))
> 3641 AC_CHECK_LIB(png, png_get_acTL, ,
> 3642  AC_MSG_ERROR([--with-system-png won't work because the 
> system's libpng doesn't have APNG support]))
> 3643 fi

I guess that shouldn't provoke errors with the new libpng version.

-- 
Regards
Carsten Schoenert

Re: MBF Announcement: Transition libpng12 -> libpng16

[Tobias Frost]

Hi Sebastien,

Am Montag, den 04.01.2016, 12:00 + schrieb Bastien Roucaries:
> 
> 
> Add also bug to package using embeded libpng 1.6 like texlive ?

Thanks for the hint, I frankly forgot to check for code copies.
Yes, I guess the security team would be happy to drop embedded code
copies or at upgrade also to a newer version.

I guess I'll drop Norbert a line for now to make him aware 
of the libpng transistion... (CC'ed)

-- 
tobi