[meta-oe] libjpeg-turbo: update 1.2.1 / use version 8d to follow oe-core libjpeg update

[meta-oe] libjpeg-turbo: update 1.2.1 / use version 8d to follow oe-core libjpeg update

[Andreas Müller]

without following oe-core's version PREFERRED_PROVIDER_jpeg does not work and
libjpeg is build.

Signed-off-by: Andreas Müller <schnitzeltony@googlemail.com>
---
 meta-oe/recipes-core/jpeg/libjpeg-turbo_svn.bb |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta-oe/recipes-core/jpeg/libjpeg-turbo_svn.bb b/meta-oe/recipes-core/jpeg/libjpeg-turbo_svn.bb
index 76e2da4..16fb2c7 100644
--- a/meta-oe/recipes-core/jpeg/libjpeg-turbo_svn.bb
+++ b/meta-oe/recipes-core/jpeg/libjpeg-turbo_svn.bb
@@ -6,8 +6,8 @@ LIC_FILES_CHKSUM = "file://cdjpeg.h;endline=12;md5=78fa8dbac547bb5b2a0e6457a6cfe
                     file://jpeglib.h;endline=14;md5=7bb9a39828a1b1e84acd4e8aec1e5532 \
                     file://djpeg.c;endline=13;md5=e85613b52f2906c5dfc0e21ec902cb33 \
 "
-PV = "8c+1.2.0"
-SRCREV = "733"
+PV = "8d+1.2.1"
+SRCREV = "837"
 SRC_URI = "svn://libjpeg-turbo.svn.sourceforge.net/svnroot/libjpeg-turbo;proto=https;module=trunk"
 
 S = "${WORKDIR}/trunk"
-- 
1.7.6.5

Re: [meta-oe] libjpeg-turbo: update 1.2.1 / use version 8d to follow oe-core libjpeg update

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 2848 bytes --]

On Mon, Jun 18, 2012 at 03:17:51PM +0200, Andreas Müller wrote:
> without following oe-core's version PREFERRED_PROVIDER_jpeg does not work and
> libjpeg is build.

Hi,

this upgrade is causing many runtime dep issues, because
libjpeg-turbo package now has not only:
/usr/lib/libjpeg.so.8 /usr/lib/libjpeg.so.8.0.2
but also:
/usr/lib/libturbojpeg.so.0 /usr/lib/libturbojpeg.so.0.0.0

http://git.shr-project.org/git/?p=buildhistory.git;a=blobdiff;f=packages/armv4t-oe-linux-gnueabi/libjpeg-turbo/libjpeg-turbo/latest;h=e449fd892c297995bf2f6a856eb875f7b5df42c0;hp=fdc1ae08fa4dbbf180b8d1e0b7ed54acb5a6743a;hb=9fe63f73e65260b6c8a3dfa5c488dac046667bba;hpb=10a01924024d30e90c9663c1317472830395f486

so packages got renamed from 
./067/ipk/armv7a-vfp-neon/libjpeg8_8c+1.2.0-r0_armv7a-vfp-neon.ipk
./067/ipk/armv7a-vfp-neon/libturbojpeg_8c+1.2.0-r0_armv7a-vfp-neon.ipk
to packages
./068/ipk/armv7a-vfp-neon/libjpeg-turbo_8d+1.2.1-r0_armv7a-vfp-neon.ipk
./068/ipk/armv7a-vfp-neon/libturbojpeg_8d+1.2.1-r0_armv7a-vfp-neon.ipk

and runtime deps like "libjpeg8 (>= 8c+1.2.0)" are not satisfied anymore
(e.g. do_rootfs fails).

Don't know why packaging is not showing warning about multiple .sonames
and asking for LEAD_SONAME :/.

Will send patch for it in few minutes.

Paul: is there some way to record "runtime" names of packages in
buildhistory? From this diff:
http://git.shr-project.org/git/?p=buildhistory.git;a=commitdiff;h=a2b23ff61e9b1baeb64bbbd01f115c8dc71a86a3
it's not possible to see that libjpeg-turbo_8d+1.2.1-r0 was renamed to
libjpeg8_8d+1.2.1-r1.

Cheers,


> 
> Signed-off-by: Andreas Müller <schnitzeltony@googlemail.com>
> ---
>  meta-oe/recipes-core/jpeg/libjpeg-turbo_svn.bb |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/meta-oe/recipes-core/jpeg/libjpeg-turbo_svn.bb b/meta-oe/recipes-core/jpeg/libjpeg-turbo_svn.bb
> index 76e2da4..16fb2c7 100644
> --- a/meta-oe/recipes-core/jpeg/libjpeg-turbo_svn.bb
> +++ b/meta-oe/recipes-core/jpeg/libjpeg-turbo_svn.bb
> @@ -6,8 +6,8 @@ LIC_FILES_CHKSUM = "file://cdjpeg.h;endline=12;md5=78fa8dbac547bb5b2a0e6457a6cfe
>                      file://jpeglib.h;endline=14;md5=7bb9a39828a1b1e84acd4e8aec1e5532 \
>                      file://djpeg.c;endline=13;md5=e85613b52f2906c5dfc0e21ec902cb33 \
>  "
> -PV = "8c+1.2.0"
> -SRCREV = "733"
> +PV = "8d+1.2.1"
> +SRCREV = "837"
>  SRC_URI = "svn://libjpeg-turbo.svn.sourceforge.net/svnroot/libjpeg-turbo;proto=https;module=trunk"
>  
>  S = "${WORKDIR}/trunk"
> -- 
> 1.7.6.5
> 
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: [meta-oe] libjpeg-turbo: update 1.2.1 / use version 8d to follow oe-core libjpeg update

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Op 21-06-12 09:30, Martin Jansa schreef:
> On Mon, Jun 18, 2012 at 03:17:51PM +0200, Andreas Müller wrote:
>> without following oe-core's version PREFERRED_PROVIDER_jpeg does not
>> work and libjpeg is build.
> 
> Hi,
> 
> this upgrade is causing many runtime dep issues, because libjpeg-turbo
> package now has not only: /usr/lib/libjpeg.so.8
> /usr/lib/libjpeg.so.8.0.2 but also: /usr/lib/libturbojpeg.so.0
> /usr/lib/libturbojpeg.so.0.0.0
> 
> http://git.shr-project.org/git/?p=buildhistory.git;a=blobdiff;f=packages/armv4t-oe-linux-gnueabi/libjpeg-turbo/libjpeg-turbo/latest;h=e449fd892c297995bf2f6a856eb875f7b5df42c0;hp=fdc1ae08fa4dbbf180b8d1e0b7ed54acb5a6743a;hb=9fe63f73e65260b6c8a3dfa5c488dac046667bba;hpb=10a01924024d30e90c9663c1317472830395f486
>
>  so packages got renamed from 
> ./067/ipk/armv7a-vfp-neon/libjpeg8_8c+1.2.0-r0_armv7a-vfp-neon.ipk 
> ./067/ipk/armv7a-vfp-neon/libturbojpeg_8c+1.2.0-r0_armv7a-vfp-neon.ipk to
> packages 
> ./068/ipk/armv7a-vfp-neon/libjpeg-turbo_8d+1.2.1-r0_armv7a-vfp-neon.ipk 
> ./068/ipk/armv7a-vfp-neon/libturbojpeg_8d+1.2.1-r0_armv7a-vfp-neon.ipk
> 
> and runtime deps like "libjpeg8 (>= 8c+1.2.0)" are not satisfied anymore 
> (e.g. do_rootfs fails).
> 
> Don't know why packaging is not showing warning about multiple .sonames 
> and asking for LEAD_SONAME :/.
> 
> Will send patch for it in few minutes.

crap,I had the same problem with the version I did and didn't check if this
patch also suffered from that problem.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQIcBAEBAgAGBQJP42EfAAoJEHZqAkdh1vT6oB4P/2dYmyOwiRdfqBWH/TL2a1+B
JpyATgj8YzBy7k4v6np8ZTmU9u14QWTQetjMrNp2jVSWK9J5Up41CsTilSk4cGej
sKfhciaR5aTtmjGQ7U3uKl5q4Jp+UCmuZEccHkXBRtEVsAz1DeOXXnlcPzzwwE+v
z5MS8GQmrpga3Q4Lqx6NGXgJvjLwXtJqjBY4g5P+9EAqPOSR0/3DvDljYTsyvWp0
7CQhzRkr1D+Tv05n/QctQoaMNgIuWxNYQWOt90SSIOE7qkmm0VM6OZy5Np/pGiHh
egp+lqnptDHDdfwZz7boRZzZr//GlxsoT0D2PtLYSMRbbEwsZWdT9fXKY+q1cKx8
T8X3Gx/Hq/uyHK7FE5Cy72XegLbzRTH49/AbuHJBKVns+AL1+ZyBWkgHhP/eyHfW
RkCwaoYq8mEhlRUUZeMRXzfdN5LQ/KNMPo841gvo3TwRiSJsTf185isYek5UE2UU
i0CcgBh+lX+42/zKM7MVeqfF0npgqyTE0dk6QODjupL3WDBWjOCuQTzl4xAsRQib
+zCMSodgRhhUEYfvC3HQUhi2iZkuZ7L0Ks44xlw79lW1BK0MLWLmKWSJl0DTTZp7
XrMpuKb9PYGj32tf2Ce0GhRngq2HzAtgPnvzgVMzdUDqdgwoRmQWNVarBi0V18Yh
7JhWxRRInETznzbXAhLR
=PDS5
-----END PGP SIGNATURE-----