From: Colin Walters <walters@verbum.org>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: openembedded-core <openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] gdk-pixbuf: Fix libpng determinism issues
Date: Sun, 14 Apr 2013 09:02:12 -0400 [thread overview]
Message-ID: <1365944532.5651.12.camel@localhost> (raw)
In-Reply-To: <1365848719.16702.74.camel@ted>
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.
On Sat, 2013-04-13 at 11:25 +0100, Richard Purdie wrote:
> 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 <richard.purdie@linuxfoundation.org>
> ---
> diff --git a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf-2.26.5/pngversion.patch b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf-2.26.5/pngversion.patch
> new file mode 100644
> index 0000000..81a3d06
> --- /dev/null
> +++ b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf-2.26.5/pngversion.patch
> @@ -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)
> diff --git a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.26.5.bb b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.26.5.bb
> index cc2ea50..b35f7c6 100644
> --- a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.26.5.bb
> +++ b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.26.5.bb
> @@ -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"
>
>
next prev parent reply other threads:[~2013-04-14 13:27 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-13 10:25 [PATCH] gdk-pixbuf: Fix libpng determinism issues Richard Purdie
2013-04-14 13:02 ` Colin Walters [this message]
2013-04-14 15:33 ` Richard Purdie
2013-04-15 10:08 ` Colin Walters
2013-04-15 10:14 ` Koen Kooi
2013-04-15 11:31 ` Richard Purdie
2013-04-15 12:12 ` Colin Walters
2013-04-15 12:22 ` Richard Purdie
2013-04-15 12:59 ` Colin Walters
2013-04-19 12:59 ` Richard Purdie
2013-04-19 13:41 ` Koen Kooi
2013-04-19 17:17 ` Colin Walters
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1365944532.5651.12.camel@localhost \
--to=walters@verbum.org \
--cc=openembedded-core@lists.openembedded.org \
--cc=richard.purdie@linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox