Debian Bug report logs - #819779
gdk-pixbuf: libgdk-pixbuf2.0-dev depends on libpng-dev but gdk-pixbuf2.0.pc requires libpng12-dev

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Tanguy Ortolo <tanguy+debian@ortolo.eu>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: gdk-pixbuf: libgdk-pixbuf2.0-dev depends on libpng-dev but gdk-pixbuf2.0.pc requires libpng12-dev

Date: Sat, 02 Apr 2016 10:41:16 +0200

Package: libgdk-pixbuf2.0-dev
Version: 2.32.3-1.2
Severity: grave
Justification: renders package unusable

Hello,


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;
  - 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.


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.


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:

>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.


Regards,

-- 
Tanguy

Message #10 received at 819779-done@bugs.debian.org (full text, mbox, reply):

From: Andreas Henriksson <andreas@fatal.se>

To: 819779-done@bugs.debian.org

Subject: libgdk-pixbuf2.0-dev -> libpng-dev vs pbuilder

Date: Sat, 2 Apr 2016 12:37:23 +0200

Hello Tanguy!

As discussed on IRC the problem you're experiencing is a pbuilder
bug and not an issue in the package itself.

Also, whatever is being prepared w.r.t. libpng in experimental
is not something we can use in unstable (which the version
of the package you reported this bug against is in).


Regards,
Andreas Henriksson

Message #15 received at 819779@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: 819779@bugs.debian.org, walters@verbum.org

Subject: Re: Bug#819779: marked as done (gdk-pixbuf: libgdk-pixbuf2.0-dev depends on libpng-dev but gdk-pixbuf2.0.pc requires libpng12-dev)

Date: Sat, 2 Apr 2016 13:55:34 +0200

[Message part 1 (text/plain, inline)]

Am 02.04.2016 um 12:39 schrieb Debian Bug Tracking System:
> As discussed on IRC the problem you're experiencing is a pbuilder
> bug and not an issue in the package itself.

I don't think this is the case and there is a genuine bug.
The libpng version gdk-pixbuf was compiled against, is encoded in the
pkg-config file.
If libgdk-pixbuf2.0-dev want's to depend on an unversioned libpng-dev,
this should be achieved by making gdk-pixbuf compile against libpng.pc,
not libpngXXX.pc

See https://bugzilla.gnome.org/show_bug.cgi?id=667068

gdk-pixbuf seems to explicitly supports version 1.10, 1.12-1.16
Maybe we could turn that into something like

PKG_CHECK_MODULES([LIBPNG], [libpng >= 1.12], [libpng << 1.17])

CCing Colin, who raised the concern about versionless libpng. Maybe he
can elaborate in more detail, what exactly the problems were when using
an unversioned libpng.pc

In any case, I think we should reopen this bug report and fix this for good.

Regards,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #20 received at 819779@bugs.debian.org (full text, mbox, reply):

From: Gianfranco Costamagna <locutusofborg@debian.org>

To: Tanguy Ortolo <tanguy+debian@ortolo.eu>, 819779@bugs.debian.org, tobi@debian.org, jcristau@debian.org

Subject: Re: Bug#819779: gdk-pixbuf: libgdk-pixbuf2.0-dev depends on libpng-dev but gdk-pixbuf2.0.pc requires libpng12-dev

Date: Sun, 3 Apr 2016 09:49:43 +0200

[Message part 1 (text/plain, inline)]

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 (application/pgp-signature, attachment)]

Message #27 received at 819779@bugs.debian.org (full text, mbox, reply):

From: Gianfranco Costamagna <locutusofborg@debian.org>

To: Tanguy Ortolo <tanguy+debian@ortolo.eu>, 819779@bugs.debian.org

Subject: Re: Bug#819779: gdk-pixbuf: libgdk-pixbuf2.0-dev depends on libpng-dev but gdk-pixbuf2.0.pc requires libpng12-dev

Date: Sun, 3 Apr 2016 09:57:34 +0200

[Message part 1 (text/plain, inline)]

> That way, it would not even need to be adapted for future versions of
> libpng.
> 

Hi again, BTW I did a no change rebuild on debomatic-amd64.debian.net to really check the libpng status on experimental

http://debomatic-amd64.debian.net/distribution#experimental/gdk-pixbuf/2.33.2-1/buildlog
http://debomatic-amd64.debian.net/distribution#experimental/gdk-pixbuf/2.33.2-1/contents

every bit seems in place, so I think a simple binNMU is really enough now.

You might use them in the meanwhile, and ask for a binNMU in experimental if you want to fix it!

thanks a lot,

Gianfranco

[signature.asc (application/pgp-signature, attachment)]

Message #36 received at 819779@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: Gianfranco Costamagna <locutusofborg@debian.org>, 819779@bugs.debian.org

Subject: Re: Bug#819779: gdk-pixbuf: libgdk-pixbuf2.0-dev depends on libpng-dev but gdk-pixbuf2.0.pc requires libpng12-dev

Date: Sun, 3 Apr 2016 12:15:27 +0200

[Message part 1 (text/plain, inline)]

Am 03.04.2016 um 09:49 schrieb Gianfranco Costamagna:
> 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.

It's an RC bug, just not grave but serious, because the package declares
a dependency which doesn't actually satisfy its dependencies.

I'll revert the upload and we will have to fix that properly, by making
gdk-pixbuf not encode the version it was built against in the .pc file.

Regards,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #41 received at 819779@bugs.debian.org (full text, mbox, reply):

From: Gianfranco Costamagna <locutusofborg@debian.org>

To: Michael Biebl <biebl@debian.org>, "819779@bugs.debian.org" <819779@bugs.debian.org>

Subject: Re: Bug#819779: gdk-pixbuf: libgdk-pixbuf2.0-dev depends on libpng-dev but gdk-pixbuf2.0.pc requires libpng12-dev

Date: Sun, 3 Apr 2016 14:18:52 +0000 (UTC)

Hi Michael


>It's an RC bug, just not grave but serious, because the package declares

>a dependency which doesn't actually satisfy its dependencies.


indeed, but this is just a matter of a binNMU, and it affects only experimental, right?

>I'll revert the upload and we will have to fix that properly, by making
>gdk-pixbuf not encode the version it was built against in the .pc file.


I'm not sure I follow your "I'll revert the upload", please try to be a little more
verbose.
If you want to hardcode libpng12-dev as dependency, I'm sure it won't help, because libpng12
and libpng16 should conflict each others in some way, so hardcoding that dependency in experimental
will move the uninstallability to the next layer in the dependency chain.
(I'm not sure about the above, but with a real libpng-dev in experimental forcing libpng12-dev will be
counter productive).

Without knowing the above statement, I'll fully trust your upload and judgement, just one note:
in case the transition starts in the next few days, just please be prepared to an eventual NMU to 

set a libpng-dev dependency, because your one is a key package for many others, and I/we would
like to avoid having long delays/blocks in this transition.

That said, sorry if I misunderstood your mail and the target suite of the revert :)

cheers,

Gianfranco

Message #52 received at 819779@bugs.debian.org (full text, mbox, reply):

From: peter green <plugwash@p10link.net>

To: 819779@bugs.debian.org, libpng1.6@packages.debian.org

Subject: Re: Bug#819779: gdk-pixbuf: libgdk-pixbuf2.0-dev depends on libpng-dev but gdk-pixbuf2.0.pc requires libpng12-dev

Date: Thu, 14 Apr 2016 13:16:04 +0100

>
> * 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;
>    - 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.
The situation has now changed but we still have a problem.

gdk-pixbuf2.0.pc now requires libpng16.pc but the dependency is still on 
libpng-dev which is available both as a real package and as a provides 
from libpng12-dev. So depending on which option is selected in 
satisfying the dependencies the system can end up with a broken 
gdk-pixbuf2.0.pc

I belive the correct thing to do is to depend on libpng-dev (>=  1.6), 
libpng-dev (<<  1.7).

libpng developers, any thoughts on this?

Message #57 received at 819779@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: peter green <plugwash@p10link.net>, 819779@bugs.debian.org

Subject: Re: Bug#819779: gdk-pixbuf: libgdk-pixbuf2.0-dev depends on libpng-dev but gdk-pixbuf2.0.pc requires libpng12-dev

Date: Thu, 14 Apr 2016 14:45:59 +0200

[Message part 1 (text/plain, inline)]

Am 14.04.2016 um 14:16 schrieb peter green:
>>
>> * 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;
>>    - 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.
> The situation has now changed but we still have a problem.
> 
> gdk-pixbuf2.0.pc now requires libpng16.pc but the dependency is still on
> libpng-dev which is available both as a real package and as a provides
> from libpng12-dev. So depending on which option is selected in
> satisfying the dependencies the system can end up with a broken
> gdk-pixbuf2.0.pc
> 
> I belive the correct thing to do is to depend on libpng-dev (>=  1.6),
> libpng-dev (<<  1.7).

Yes, I think this is the correct fix, for both the Build-Depends and the
actual Depends in libgdk-pixbuf2.0-dev.

This ensures, that the version we build against and is encoded in the
.pc file is the version that is later pulled in by libgdk-pixbuf2.0-dev


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #62 received at 819779@bugs.debian.org (full text, mbox, reply):

From: Santiago Vila <sanvila@unex.es>

To: Debian BTS <control@bugs.debian.org>

Cc: 819779@bugs.debian.org

Subject: Bug#819779 affects several packages

Date: Thu, 14 Apr 2016 17:57:10 +0200 (CEST)

affects 819779 + appstream-glib
affects 819779 + boinc
affects 819779 + gthumb
affects 819779 + mypaint
thanks

The above packages currently FTBFS in stretch
because of this bug.

Message #75 received at 819779@bugs.debian.org (full text, mbox, reply):

From: Rene Engelhard <rene@debian.org>

To: Michael Biebl <biebl@debian.org>, 819779@bugs.debian.org

Cc: peter green <plugwash@p10link.net>

Subject: Re: Bug#819779: gdk-pixbuf: libgdk-pixbuf2.0-dev depends on libpng-dev but gdk-pixbuf2.0.pc requires libpng12-dev

Date: Thu, 14 Apr 2016 22:55:56 +0200

On Thu, Apr 14, 2016 at 02:45:59PM +0200, Michael Biebl wrote:
> This ensures, that the version we build against and is encoded in the
> .pc file is the version that is later pulled in by libgdk-pixbuf2.0-dev

I still have to see an argument except some "maybe something undefined will
break" (did I miss that one?) and to not just use libpng.pc (and be it patching
the stuff to not use the versioned one..) and be done with it forever.

Regards,

Rene

Message #80 received at 819779@bugs.debian.org (full text, mbox, reply):

From: Rene Engelhard <rene@debian.org>

To: Santiago Vila <sanvila@unex.es>, 819779@bugs.debian.org

Subject: Re: Bug#819779: affects several packages

Date: Thu, 14 Apr 2016 22:56:29 +0200

Hi,

On Thu, Apr 14, 2016 at 05:57:10PM +0200, Santiago Vila wrote:
> affects 819779 + appstream-glib
> affects 819779 + boinc
> affects 819779 + gthumb
> affects 819779 + mypaint
> thanks
> 
> The above packages currently FTBFS in stretch
> because of this bug.

AFAICS *anything* gdk-pixbuf directly or indirectly via pkg-config does.
(Well, did, the rebuilt package migrated, but the root cause is not solved.).

It does not make sense to mark anything using that as affected. :)

Regards,

Rene

Message #89 received at 819779-close@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: 819779-close@bugs.debian.org

Subject: Bug#819779: fixed in gdk-pixbuf 2.34.0-1

Date: Sat, 16 Apr 2016 13:50:07 +0000

Source: gdk-pixbuf
Source-Version: 2.34.0-1

We believe that the bug you reported is fixed in the latest version of
gdk-pixbuf, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 819779@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Michael Biebl <biebl@debian.org> (supplier of updated gdk-pixbuf package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Sat, 16 Apr 2016 15:39:05 +0200
Source: gdk-pixbuf
Binary: libgdk-pixbuf2.0-0 libgdk-pixbuf2.0-common libgdk-pixbuf2.0-dev libgdk-pixbuf2.0-doc libgdk-pixbuf2.0-0-udeb gir1.2-gdkpixbuf-2.0
Architecture: source
Version: 2.34.0-1
Distribution: unstable
Urgency: medium
Maintainer: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Changed-By: Michael Biebl <biebl@debian.org>
Description:
 gir1.2-gdkpixbuf-2.0 - GDK Pixbuf library - GObject-Introspection
 libgdk-pixbuf2.0-0 - GDK Pixbuf library
 libgdk-pixbuf2.0-0-udeb - GDK Pixbuf library - minimal runtime (udeb)
 libgdk-pixbuf2.0-common - GDK Pixbuf library - data files
 libgdk-pixbuf2.0-dev - GDK Pixbuf library (development files)
 libgdk-pixbuf2.0-doc - GDK Pixbuf library (documentation)
Closes: 818233 819779
Changes:
 gdk-pixbuf (2.34.0-1) unstable; urgency=medium
 .
   [ Emilio Pozuelo Monfort ]
   * debian/patches/01-disable-oom-test.patch:
     + Disable a test on kfreebsd that fails because it runs out of
       memory on those buildds. Closes: #818233.
 .
   [ Michael Biebl ]
   * New upstream release.
   * Drop libgdk-pixbuf2.0-0-dbg package now that we have automatic dbgsym
     packages.
   * Ensure proper upgrade from libgdk-pixbuf2.0-0-dbg to new dbgsym packages
     by using dh_strip --dbgsym-migration. Bump Build-Depends on debhelper
     accordingly.
   * Tighten dependency on libpng-dev. We need to ensure that
     libgdk-pixbuf2.0-dev pulls in the correct version of libpng-dev as it
     encodes the libpng API version it was built against in gdk-pixbuf2.0.pc.
     (Closes: #819779)
   * Upload to unstable.
Checksums-Sha1:
 1768a9593c444ec99c108e01a72c7535426a84f3 2783 gdk-pixbuf_2.34.0-1.dsc
 240018b35da047500e43caac7e32a4482edd3852 2709320 gdk-pixbuf_2.34.0.orig.tar.xz
 3ff22e320e4678eaf161216605f0d0bbe8c9eaf9 12980 gdk-pixbuf_2.34.0-1.debian.tar.xz
Checksums-Sha256:
 8a649f1d1ca7078e1af161862536e39d4b15ad138edcc4c1f71a03c00ee53093 2783 gdk-pixbuf_2.34.0-1.dsc
 d55e5b383ee219bd0e23bf6ed4427d56a7db5379729a6e3e0a0e0eba9a8d8879 2709320 gdk-pixbuf_2.34.0.orig.tar.xz
 0e538d8b99ad9f9b1a9699d09e6cf7c83340c762ecbd146bc9642ec143f18017 12980 gdk-pixbuf_2.34.0-1.debian.tar.xz
Files:
 0ebb90611432a200f5a2c4afb0f4d406 2783 libs optional gdk-pixbuf_2.34.0-1.dsc
 63cb19f92cf7709ccf44bbb6fe1ff70c 2709320 libs optional gdk-pixbuf_2.34.0.orig.tar.xz
 ff9ad1a8ceb42322d26df2f08f6db8e6 12980 libs optional gdk-pixbuf_2.34.0-1.debian.tar.xz

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJXEkCtAAoJEGrh3w1gjyLcVxoP/3y6Zoolyif+041s+FEovFUN
3GmENx2dTgNbBHUgsqOiFo6b7R6PpBbUZ/uFhpXsm9IMIc8eHL/zAG/ORxXWi7e/
YBzmQt2LyBEPGsE6ob5cpqqscM4NIML6GGM7pAGqeJkQmgZ5A6S/rUmm3IBGfExM
aPr0HKKgU2iovn5h8T8pRxJ+BLt/3t2KcXkGzkqhEo4rHTwmQiXgWj+fXbxF+1Re
ip6J9drn8F4aMN1P5o6L9KIfonvZOKRNhzhLli3WfE20tRnRKjs3rTW5ZONDj4HV
3er9Hh66UtrlRILXUdnqVs4Mj0HbwwzRUXH8bbjkMxduT9iP/yJ+dtS9BIVSfGQz
Alqapg3SNC4nvzlx5+aYnX3ZtRTaENIPEN9kzCjg5VJ+OT7dA9kGyIFOXsGGCEZb
fWrrJqUjJorMLr7eZ1LJuvhmI3w4QWPL6a7OdPhQvw2luyecctJbAwqTQa5e+jM9
BBEAJdE8UQgg937ICqXgZGZCsH4sKyQ2+92Y5Io6oCnvT5v2uZjitW/LRqxi8cx1
/cUnu4b0hUQWcmdBI1Ww7V9l0KPRPoXfmdW51fOdNqbRRBU7bYp0FT24RMbZYs8r
cBy4Sz6BUnkGs5yCku5BSmhzwebf8sU8hrY2nJ/fUpvt79n1Lo3cxLyvD8kmiGFH
b6/jxFUzVMl3w3g8MGUh
=ZS1M
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.