gdk-pixbuf: Fix libpng determinism issues
PATCH 1/1 gdk-pixbuf: Fix libpng determinism issues
We now have libpng 1.6. If we build libpng12 as well as libpng 1.6, the 1.2 version gets preferred which is not desirable and does not give deterministic builds.
We really do want to use libpng since the item in DEPENDS will provide this so manipulate the search list so the one we DEPEND on gets chosen. This was the cause of a recent autobuilder failure.
---
meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf-2.26.5/pngversion.patch new file +23 -0
@@ -0,0 +1,23 @@ +We now have libpng 1.6. If we build libpng12 as well as libpng 1.6, the 1.2 version gets +preferred which is not desirable and does not give deterministic builds. + +We really do want to use libpng since the item in DEPENDS will provide this so +manipulate the search list so the one we DEPEND on gets chosen. + +RP 2013/4/13 + +Upstream-Status: Pending [worth discussing at least] + +Index: gdk-pixbuf-2.26.5/configure.ac +=================================================================== +--- gdk-pixbuf-2.26.5.orig/configure.ac 2013-03-26 15:45:16.594820303 +0000 ++++ gdk-pixbuf-2.26.5/configure.ac 2013-04-13 10:15:19.241433789 +0000 +@@ -588,7 +588,7 @@ + + dnl Test for libpng + if test x$with_libpng != xno && test -z "$LIBPNG"; then +- for l in libpng15 libpng14 libpng12 libpng13 libpng10 libpng ; do ++ for l in libpng libpng15 libpng14 libpng12 libpng13 libpng10 ; do + AC_MSG_CHECKING(for $l) + if $PKG_CONFIG --exists $l ; then + AC_MSG_RESULT(yes)
meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.26.5.bb +1 -0
@@ -15,6 +15,7 @@ SRC_URI = "http://ftp.acc.umu.se/pub/GNOME/sources/gdk-pixbuf/2.26/gdk-pixbuf-${ file://hardcoded_libtool.patch \ file://configure_fix.patch \ file://extending-libinstall-dependencies.patch \ + file://pngversion.patch \ " SRC_URI[md5sum] = "339329e6d619ee3e1cb93979111b04c0"
Is "libpng" the new canonical name for 1.6? I assume there was a reason it was listed last. It looks like the current logic came from:
https://git.gnome.org/browse/gdk-pixbuf/commit/?id=ddedf5a2c2c63bfe8d6f04376cf2bba215a5eb19
Which is a not very enlightening commit message. It looks like the Fedora 18 "libpng" package provides both libpng.pc and libpng15.pc. RHEL6 has the same except it's libpng12.pc too. My Ubuntu 12.10 VM has libpng12 with just libpng12.pc, no libpng.pc.
My main concern with this patch was ensuring that people aren't getting a suddenly ancient and deprecated libpng, but that seems unlikely, so unless there are other comments I can take care of turning this into "git format-patch" style and pushing upstream.
Quoted 52 lines · Richard Purdie
We now have libpng 1.6. If we build libpng12 as well as libpng 1.6, the 1.2 version gets preferred which is not desirable and does not give deterministic builds.
We really do want to use libpng since the item in DEPENDS will provide this so manipulate the search list so the one we DEPEND on gets chosen. This was the cause of a recent autobuilder failure.
Signed-off-by Richard Purdie <[email protected]>---
meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf-2.26.5/pngversion.patch new file +23
-0@@ -0,0 +1,23 @@ +We now have libpng 1.6. If we build libpng12 as well as libpng 1.6, the 1.2 version gets +preferred which is not desirable and does not give deterministic builds. + +We really do want to use libpng since the item in DEPENDS will provide this so +manipulate the search list so the one we DEPEND on gets chosen. + +RP 2013/4/13 + +Upstream-Status: Pending [worth discussing at least] + +Index: gdk-pixbuf-2.26.5/configure.ac +=================================================================== +--- gdk-pixbuf-2.26.5.orig/configure.ac 2013-03-26 15:45:16.594820303 +0000 ++++ gdk-pixbuf-2.26.5/configure.ac 2013-04-13 10:15:19.241433789 +0000 +@@ -588,7 +588,7 @@ + + dnl Test for libpng + if test x$with_libpng != xno && test -z "$LIBPNG"; then +- for l in libpng15 libpng14 libpng12 libpng13 libpng10 libpng ; do ++ for l in libpng libpng15 libpng14 libpng12 libpng13 libpng10 ; do + AC_MSG_CHECKING(for $l) + if $PKG_CONFIG --exists $l ; then + AC_MSG_RESULT(yes)meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.26.5.bb +1
-0@@ -15,6 +15,7 @@ SRC_URI = "http://ftp.acc.umu.se/pub/GNOME/sources/gdk-pixbuf/2.26/gdk-pixbuf-${ file://hardcoded_libtool.patch \ file://configure_fix.patch \ file://extending-libinstall-dependencies.patch \ + file://pngversion.patch \ " SRC_URI[md5sum] = "339329e6d619ee3e1cb93979111b04c0"
Quoted 1 line · Colin Walters
Is "libpng" the new canonical name for 1.6?
Its a symlink to libpng16.pc which is something libpng upstream's "make install" provides.
Quoted 9 lines
I assume there was a reason
it was listed last. It looks like the current logic came from:https://git.gnome.org/browse/gdk-pixbuf/commit/?id=ddedf5a2c2c63bfe8d6f04376cf2bba215a5eb19
Which is a not very enlightening commit message. It looks like the Fedora 18 "libpng" package provides both libpng.pc and libpng15.pc. RHEL6 has the same except it's libpng12.pc too. My Ubuntu 12.10 VM has libpng12 with just libpng12.pc, no libpng.pc.
The more interesting change is:
and following that to the bugzilla 'For this to make sense, I changed the order so that a version specific dep, such as libpng15 or libpng12, is found before just "libpng".'
I'm not sure I entirely follow that logic.
Quoted 4 lines
My main concern with this patch was ensuring that people aren't getting a suddenly ancient and deprecated libpng, but that seems unlikely, so unless there are other comments I can take care of turning this into "git format-patch" style and pushing upstream.
I think the intent of the symlink is to provide the system with a default libpng to use in the absence of a specific version requirement. As the code stands today, each time a new libpng comes out, gdk-pixbuf will need changes before it will be able to use it. In the meantime, it will potentially link against something old, e.g. 1.2, since 1.2 is in the LSB 4.X spec so most LSB like systems would have 1.6 and 1.2.
If we can justify changing this upstream, that would be great :). It may be worth adding libpng16 into the list too so everything is covered too.
Cheers,
Richard
Quoted 11 lines · Richard Purdie
On Sun, 2013-04-14 at 09:02 -0400, Colin Walters wrote:
The more interesting change is:and following that to the bugzilla 'For this to make sense, I changed the order so that a version specific dep, such as libpng15 or libpng12,
is found before just "libpng".'I'm not sure I entirely follow that logic.
I added Matthias to CC as he touched this last then.
Quoted 4 lines
I think the intent of the symlink is to provide the system with a default libpng to use in the absence of a specific version requirement. As the code stands today, each time a new libpng comes out, gdk-pixbuf will need changes before it will be able to use it.
Right, we need configure.ac changes, but the rationale behind that is that we'd also need *code* changes for each new major version of libpng. But it sounds like what you're saying is that gdk-pixbuf compiles and operates correctly with 1.6? If that's the case, then the least invasive change here is to simply add 1.6.
Blah, I tried changing the gnome-ostree build to fetch libpng's v1.6.1 git tag to test, but it hard requires Automake 1.13.
Anyways, if it works (looks like the latest oe-core has it), then what about the attached?
Quoted 6 lines
In the meantime, it
will potentially link against something old, e.g. 1.2, since 1.2 is in the LSB 4.X spec so most LSB like systems would have 1.6 and 1.2.If we can justify changing this upstream, that would be great :). It may be worth adding libpng16 into the list too so everything is covered too.
At this point I'm hoping the parade of libpng versions will settle down, so hopefully no further tweaking of the configure script or code will be required...
From 829379cfa2b48e966125df2d070d2af40cb3f990 Mon Sep 17 00:00:00 2001
From: Colin Walters <[email protected]>
Date: Mon, 15 Apr 2013 05:59:09 -0400
Subject: [PATCH] build: We also support libpng16
See http://lists.linuxtogo.org/pipermail/openembedded-core/2013-April/038321.html
--- configure.ac | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
configure.ac +1 -1
@@ -586,7 +586,7 @@ fi dnl Test for libpng if test x$with_libpng != xno && test -z "$LIBPNG"; then - for l in libpng15 libpng14 libpng12 libpng13 libpng10 libpng ; do + for l in libpng16 libpng15 libpng14 libpng12 libpng13 libpng10 libpng; do AC_MSG_CHECKING(for $l) if $PKG_CONFIG --exists $l ; then AC_MSG_RESULT(yes)
Signature · 1 line
1.7.1
Op 15 apr. 2013, om 12:08 heeft Colin Walters <[email protected]> het volgende geschreven:
Quoted 20 lines · Richard Purdie
Quoted 11 lines · Colin Walters
The more interesting change is:
and following that to the bugzilla 'For this to make sense, I changed the order so that a version specific dep, such as libpng15 or libpng12,
is found before just "libpng".'I'm not sure I entirely follow that logic.
I added Matthias to CC as he touched this last then.
Quoted 4 lines
I think the intent of the symlink is to provide the system with a default libpng to use in the absence of a specific version requirement. As the code stands today, each time a new libpng comes out, gdk-pixbuf will need changes before it will be able to use it.
Quoted 8 lines
Right, we need configure.ac changes, but the rationale behind that is that we'd also need *code* changes for each new major version of libpng. But it sounds like what you're saying is that gdk-pixbuf compiles and operates correctly with 1.6? If that's the case, then the least invasive change here is to simply add 1.6.
Blah, I tried changing the gnome-ostree build to fetch libpng's v1.6.1 git tag to test, but it hard requires Automake 1.13.
Only for parallel unit tests, I just sent a patch to update libpng to v1.6.1 to oe-core. It doesn't fix the problems I'm having with PNGs in weston, so please test it and see if it fixed any of your problems.
regards,
Koen
Quoted 20 lines
Anyways, if it works (looks like the latest oe-core has it), then what about the attached?
Quoted 6 lines
In the meantime, it
will potentially link against something old, e.g. 1.2, since 1.2 is in the LSB 4.X spec so most LSB like systems would have 1.6 and 1.2.If we can justify changing this upstream, that would be great :). It may be worth adding libpng16 into the list too so everything is covered too.
At this point I'm hoping the parade of libpng versions will settle down, so hopefully no further tweaking of the configure script or code will be required...
<0001-build-We-also-support-libpng16.patch>_______________________________________________ Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Quoted 20 lines · Colin Walters
Quoted 11 lines · Richard Purdie
On Sun, 2013-04-14 at 09:02 -0400, Colin Walters wrote:
The more interesting change is:and following that to the bugzilla 'For this to make sense, I changed the order so that a version specific dep, such as libpng15 or libpng12,
is found before just "libpng".'I'm not sure I entirely follow that logic.
I added Matthias to CC as he touched this last then.
Quoted 4 lines
I think the intent of the symlink is to provide the system with a default libpng to use in the absence of a specific version requirement. As the code stands today, each time a new libpng comes out, gdk-pixbuf will need changes before it will be able to use it.
Quoted 5 lines
Right, we need configure.ac changes, but the rationale behind that is that we'd also need *code* changes for each new major version of libpng. But it sounds like what you're saying is that gdk-pixbuf compiles and operates correctly with 1.6? If that's the case, then the least invasive change here is to simply add 1.6.
It compiles and operates correctly as far as we can tell, yes.
Given that rationale, I'd suggest "libpng" should be dropped from the list.
Quoted 5 lines
Blah, I tried changing the gnome-ostree build to fetch libpng's v1.6.1 git tag to test, but it hard requires Automake 1.13.
Anyways, if it works (looks like the latest oe-core has it), then what about the attached?
It will make our builds work again for now until the next time someone upgrades libpng and and then it will potentially silently start using an old version in some builds :(.
We're therefore probably going to get stuck carrying a patch for this :/.
Quoted 10 lines
Quoted 6 lines
In the meantime, it
will potentially link against something old, e.g. 1.2, since 1.2 is in the LSB 4.X spec so most LSB like systems would have 1.6 and 1.2.If we can justify changing this upstream, that would be great :). It may be worth adding libpng16 into the list too so everything is covered too.
At this point I'm hoping the parade of libpng versions will settle down, so hopefully no further tweaking of the configure script or code will be required...
Its the case things silently break that really worry me.
Cheers,
Richard
Quoted 3 lines · Richard Purdie
It will make our builds work again for now until the next time someone upgrades libpng and and then it will potentially silently start using an old version in some builds :(.
So something like the attached on top of the previous patch?
If this looks good I'll push both to master.
From 91074d01a0e2b4508f7f253f1e0a7669363cb128 Mon Sep 17 00:00:00 2001
From: Richard Purdie <[email protected]>
Date: Mon, 15 Apr 2013 08:06:45 -0400
Subject: [PATCH] build: drop "libpng" from detected list
This gives us an arbitrary version depending on the build root, and we may not be upwards compatible with future versions. Or it's possible that the ancient (but LSB mandated) 1.2 claims the "libpng.pc" name.
--- configure.ac | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
configure.ac +1 -1
@@ -586,7 +586,7 @@ fi dnl Test for libpng if test x$with_libpng != xno && test -z "$LIBPNG"; then - for l in libpng16 libpng15 libpng14 libpng12 libpng13 libpng10 libpng; do + for l in libpng16 libpng15 libpng14 libpng12 libpng13 libpng10; do AC_MSG_CHECKING(for $l) if $PKG_CONFIG --exists $l ; then AC_MSG_RESULT(yes)
Signature · 1 line
1.7.1
Quoted 9 lines · Colin Walters
Quoted 3 lines · Richard Purdie
It will make our builds work again for now until the next time someone upgrades libpng and and then it will potentially silently start using an old version in some builds :(.
So something like the attached on top of the previous patch?
If this looks good I'll push both to master.
Looks good to me, thanks!
Richard
Quoted 7 lines · Richard Purdie
Quoted 6 lines · Colin Walters
Quoted 3 lines · Richard Purdie
It will make our builds work again for now until the next time someone upgrades libpng and and then it will potentially silently start using an old version in some builds :(.
Quoted 5 lines
Quoted 3 lines
So something like the attached on top of the previous patch?
If this looks good I'll push both to master.
Looks good to me, thanks!
Both pushed to git, thanks.
<nag>
If OE was building from git as it should, your original patch could have been a ready-to-upstream "git format-patch" style instead of the default "Upstream-Status: inappropriate" non-git patches =/
</nag>
Quoted 8 lines · Colin Walters
Quoted 7 lines · Richard Purdie
Quoted 6 lines · Colin Walters
Quoted 3 lines · Richard Purdie
It will make our builds work again for now until the next time someone upgrades libpng and and then it will potentially silently start using an old version in some builds :(.
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
So something like the attached on top of the previous patch?
If this looks good I'll push both to master.
Looks good to me, thanks!
Both pushed to git, thanks.
Much appreciated!
Quoted 5 lines
<nag>
If OE was building from git as it should, your original patch could have been a ready-to-upstream "git format-patch" style instead of the default "Upstream-Status: inappropriate" non-git patches =/
</nag>
Noted, although I doubt we'll be using git SRC_URIs for everything any time soon for a variety of reasons. I would love to see the option of building most things from bleeding source but that would require a lot of work which we don't have the bandwidth for.
Cheers,
Richard
Op 19 apr. 2013, om 14:59 heeft Richard Purdie <[email protected]> het volgende geschreven:
Quoted 25 lines · Colin Walters
Quoted 8 lines · Richard Purdie
Quoted 7 lines · Colin Walters
Quoted 6 lines · Richard Purdie
Quoted 4 lines
It will make our builds work again for now until the next time someone upgrades libpng and and then it will potentially silently start using an old version in some builds :(.
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
So something like the attached on top of the previous patch?
If this looks good I'll push both to master.
Looks good to me, thanks!
Both pushed to git, thanks.
Much appreciated!
Quoted 5 lines
<nag>
If OE was building from git as it should, your original patch could have been a ready-to-upstream "git format-patch" style instead of the default "Upstream-Status: inappropriate" non-git patches =/
</nag>
Quoted 4 lines
Noted, although I doubt we'll be using git
SRC_URIsfor everything any time soon for a variety of reasons. I would love to see the option of building most things from bleeding source but that would require a lot of work which we don't have the bandwidth for.
And would introduce some dependency hell (gtk-doc-native needed for every little gnome thing *and* udev) but more importantly it will expose us to that stupid, stupid, stupid practice of using git submodules to drag in autoconf stuff. Gstreamer is the worst offender, but there are a lot of others.
I try to have recipe build from a git tag instead of a tarball whenever possible, but it hurts a lot if it's one of that gtk-doc users, you can't disable that completely.
regards,
Koen
Quoted 1 line · Koen Kooi
And would introduce some dependency hell (gtk-doc-native needed for every little gnome thing *and* udev)
Nope, that's why gtk-doc-stub exists, and it's already used in OE:
http://git.gnome.org/browse/gtk-doc-stub
Quoted 1 line
but more importantly it will expose us to that stupid, stupid, stupid practice of using git submodules to drag in autoconf stuff.
Correct handling of git submodules is definitely nontrivial.