Patchwork [12/20] zlib: Upgrade 1.2.5 -> 1.2.6

login
register
mail settings
Submitter Khem Raj
Date Feb. 6, 2012, 6:40 a.m.
Message ID <c68f6de298c35c25638ea3a5adeb06c97cd74036.1328510189.git.raj.khem@gmail.com>
Download mbox | patch
Permalink /patch/20741/
State New
Headers show

Comments

Khem Raj - Feb. 6, 2012, 6:40 a.m.
Dont use autotools, it really not so autoconf like.
the configure script gets updated with every release of zlib
and we overwrite that. Instead use the upstream provided
configure

copyright year was changed in zlib.h which caused change in
LIC_FILE_CHECKSUM

fix.inverted.LFS.logic.patch is already applied upstream so drop it

Drop the configure.ac and Makefile.am scripts since we do not
autoreconf anymore and do not inherit autotools anymore

Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
 meta/recipes-core/zlib/files/Makefile.am           |    9 ----
 meta/recipes-core/zlib/files/configure.ac          |   48 --------------------
 .../zlib/zlib-1.2.5/fix.inverted.LFS.logic.patch   |   20 --------
 meta/recipes-core/zlib/zlib_1.2.5.bb               |   41 -----------------
 meta/recipes-core/zlib/zlib_1.2.6.bb               |   26 +++++++++++
 5 files changed, 26 insertions(+), 118 deletions(-)
 delete mode 100644 meta/recipes-core/zlib/files/Makefile.am
 delete mode 100644 meta/recipes-core/zlib/files/configure.ac
 delete mode 100644 meta/recipes-core/zlib/zlib-1.2.5/fix.inverted.LFS.logic.patch
 delete mode 100644 meta/recipes-core/zlib/zlib_1.2.5.bb
 create mode 100644 meta/recipes-core/zlib/zlib_1.2.6.bb
Saul Wold - Feb. 7, 2012, 8:08 a.m.
On 02/05/2012 10:40 PM, Khem Raj wrote:
> Dont use autotools, it really not so autoconf like.
> the configure script gets updated with every release of zlib
> and we overwrite that. Instead use the upstream provided
> configure
>
> copyright year was changed in zlib.h which caused change in
> LIC_FILE_CHECKSUM
>
> fix.inverted.LFS.logic.patch is already applied upstream so drop it
>
> Drop the configure.ac and Makefile.am scripts since we do not
> autoreconf anymore and do not inherit autotools anymore
>
Not sure what's up with this patch, but it is causing failures in other 
recipes that depend on libz, it seems like the libz.la is not getting 
installed correctly.

| /bin/grep: 
/intel/poky/builds/world/tmp/sysroots/qemux86/usr/lib/libz.la: No such 
file or directory
| /bin/sed: can't read 
/intel/poky/builds/world/tmp/sysroots/qemux86/usr/lib/libz.la: No such 
file or directory
| i586-poky-linux-libtool: link: 
`/intel/poky/builds/world/tmp/sysroots/qemux86/usr/lib/libz.la' is not a 
valid libtool archive


Sau!

> Signed-off-by: Khem Raj<raj.khem@gmail.com>
> ---
>   meta/recipes-core/zlib/files/Makefile.am           |    9 ----
>   meta/recipes-core/zlib/files/configure.ac          |   48 --------------------
>   .../zlib/zlib-1.2.5/fix.inverted.LFS.logic.patch   |   20 --------
>   meta/recipes-core/zlib/zlib_1.2.5.bb               |   41 -----------------
>   meta/recipes-core/zlib/zlib_1.2.6.bb               |   26 +++++++++++
>   5 files changed, 26 insertions(+), 118 deletions(-)
>   delete mode 100644 meta/recipes-core/zlib/files/Makefile.am
>   delete mode 100644 meta/recipes-core/zlib/files/configure.ac
>   delete mode 100644 meta/recipes-core/zlib/zlib-1.2.5/fix.inverted.LFS.logic.patch
>   delete mode 100644 meta/recipes-core/zlib/zlib_1.2.5.bb
>   create mode 100644 meta/recipes-core/zlib/zlib_1.2.6.bb
>
> diff --git a/meta/recipes-core/zlib/files/Makefile.am b/meta/recipes-core/zlib/files/Makefile.am
> deleted file mode 100644
> index b66d299..0000000
> --- a/meta/recipes-core/zlib/files/Makefile.am
> +++ /dev/null
> @@ -1,9 +0,0 @@
> -lib_LTLIBRARIES = libz.la
> -
> -libz_la_SOURCES = adler32.c compress.c crc32.c gzlib.c gzclose.c gzread.c \
> -                  gzwrite.c uncompr.c deflate.c trees.c zutil.c inflate.c \
> -                  infback.c inftrees.c inffast.c
> -
> -libz_la_LDFLAGS = -version-number 1:2:5 --version-script zlib.map
> -
> -include_HEADERS = zconf.h zlib.h zlibdefs.h
> diff --git a/meta/recipes-core/zlib/files/configure.ac b/meta/recipes-core/zlib/files/configure.ac
> deleted file mode 100644
> index 4761b7e..0000000
> --- a/meta/recipes-core/zlib/files/configure.ac
> +++ /dev/null
> @@ -1,48 +0,0 @@
> -AC_INIT(zlib,1.2.5)
> -AC_CONFIG_SRCDIR(adler32.c)
> -AM_INIT_AUTOMAKE(zlibs,1.2.5)
> -
> -AC_PREREQ([2.59])
> -
> -AC_PROG_CC([gcc])
> -AC_PROG_LIBTOOL
> -
> -AC_HEADER_STDC
> -
> -zlib_save_CPPFLAGS=$CPPFLAGS
> -CPPFLAGS="$CPPFLAGS -D_LARGEFILE64_SOURCE"
> -AC_CHECK_TYPES(off64_t)
> -CPPFLAGS=$zlib_save_CPPFLAGS
> -
> -AC_CACHE_CHECK([whether to enable -D_LARGEFILE64_SOURCE], [zlib_cv_use_lfs64], [
> -    zlib_cv_use_lfs64=no
> -    if test "$ac_cv_type_off64_t" = "yes"; then
> -        zlib_cv_use_lfs64=yes
> -    fi
> -])
> -
> -if test "$zlib_cv_use_lfs64" = "yes"; then
> -    CPPFLAGS="$CPPFLAGS -D_LARGEFILE64_SOURCE"
> -
> -    #APR_ADDTO(CPPFLAGS, [-D_LARGEFILE64_SOURCE])
> -fi
> -
> -cat>  zlibdefs.h<<  EOF
> -/* zlibdefs.h -- compile-time definitions for the zlib compression library
> - * Copyright (C) 1995-2006 Jean-loup Gailly.
> - * For conditions of distribution and use, see copyright notice in zlib.h
> - */
> -
> -#include<sys/types.h>	/* for off_t */
> -#include<unistd.h>	/* for SEEK_* and off_t */
> -#ifdef VMS
> -#  include<unixio.h>	/* for off_t */
> -#endif
> -#ifndef z_off_t
> -#  define z_off_t off_t
> -#endif
> -EOF
> -
> -AC_CONFIG_FILES([Makefile])
> -
> -AC_OUTPUT
> diff --git a/meta/recipes-core/zlib/zlib-1.2.5/fix.inverted.LFS.logic.patch b/meta/recipes-core/zlib/zlib-1.2.5/fix.inverted.LFS.logic.patch
> deleted file mode 100644
> index 038c1a2..0000000
> --- a/meta/recipes-core/zlib/zlib-1.2.5/fix.inverted.LFS.logic.patch
> +++ /dev/null
> @@ -1,20 +0,0 @@
> -Upstream-Status: Pending
> -
> -see
> -https://bugs.gentoo.org/316377?id=316377
> -https://bugs.freedesktop.org/show_bug.cgi?id=33710
> -http://lists.freedesktop.org/archives/poppler-bugs/2011-January/006014.html
> -for details
> -
> -diff -up zlib-1.2.5/zlib.h.pom zlib-1.2.5/zlib.h
> ---- zlib-1.2.5/zlib.h.pom	2010-04-20 06:12:48.000000000 +0200
> -+++ zlib-1.2.5/zlib.h	2010-06-16 13:08:59.000000000 +0200
> -@@ -1578,7 +1578,7 @@ ZEXTERN int ZEXPORT inflateBackInit_ OF(
> - #  define gzoffset gzoffset64
> - #  define adler32_combine adler32_combine64
> - #  define crc32_combine crc32_combine64
> --#  ifdef _LARGEFILE64_SOURCE
> -+#  ifndef _LARGEFILE64_SOURCE
> -      ZEXTERN gzFile ZEXPORT gzopen64 OF((const char *, const char *));
> -      ZEXTERN z_off_t ZEXPORT gzseek64 OF((gzFile, z_off_t, int));
> -      ZEXTERN z_off_t ZEXPORT gztell64 OF((gzFile));
> diff --git a/meta/recipes-core/zlib/zlib_1.2.5.bb b/meta/recipes-core/zlib/zlib_1.2.5.bb
> deleted file mode 100644
> index b5756d9..0000000
> --- a/meta/recipes-core/zlib/zlib_1.2.5.bb
> +++ /dev/null
> @@ -1,41 +0,0 @@
> -SUMMARY = "Zlib Compression Library"
> -DESCRIPTION = "Zlib is a general-purpose, patent-free, lossless data compression \
> -library which is used by many different programs."
> -HOMEPAGE = "http://zlib.net/"
> -SECTION = "libs"
> -LICENSE = "Zlib"
> -LIC_FILES_CHKSUM = "file://zlib.h;beginline=4;endline=23;md5=084e9c30e4e6272c3b057b13c6467f3d"
> -
> -DEPENDS = "libtool-cross"
> -PR = "r3"
> -
> -SRC_URI = "http://www.zlib.net/${BPN}-${PV}.tar.bz2 \
> -           file://configure.ac \
> -           file://Makefile.am \
> -           file://fix.inverted.LFS.logic.patch"
> -
> -SRC_URI[md5sum] = "be1e89810e66150f5b0327984d8625a0"
> -SRC_URI[sha256sum] = "239aead2f22f16bfcfa6a6a5150dcbd6d6f2e4d1eaa8727b5769ea014120b307"
> -
> -inherit autotools
> -
> -do_configure_prepend () {
> -	cp ${WORKDIR}/configure.ac ${S}/
> -	cp ${WORKDIR}/Makefile.am ${S}/
> -}
> -
> -do_install_append () {
> -	sed \
> -		-e 's:@prefix@:${prefix}:' \
> -		-e 's:@exec_prefix@:${exec_prefix}:' \
> -		-e 's:@libdir@:${libdir}:' \
> -		-e 's:@sharedlibdir@:${libdir}:' \
> -		-e 's:@includedir@:${includedir}:' \
> -		-e 's:@VERSION@:${PV}:' \
> -		zlib.pc.in>  zlib.pc
> -
> -	install -d ${D}${libdir}/pkgconfig
> -	install -m 0644 zlib.pc ${D}${libdir}/pkgconfig/
> -}
> -
> -BBCLASSEXTEND = "native nativesdk"
> diff --git a/meta/recipes-core/zlib/zlib_1.2.6.bb b/meta/recipes-core/zlib/zlib_1.2.6.bb
> new file mode 100644
> index 0000000..a220773
> --- /dev/null
> +++ b/meta/recipes-core/zlib/zlib_1.2.6.bb
> @@ -0,0 +1,26 @@
> +SUMMARY = "Zlib Compression Library"
> +DESCRIPTION = "Zlib is a general-purpose, patent-free, lossless data compression \
> +library which is used by many different programs."
> +HOMEPAGE = "http://zlib.net/"
> +SECTION = "libs"
> +LICENSE = "Zlib"
> +LIC_FILES_CHKSUM = "file://zlib.h;beginline=4;endline=23;md5=94d1b5a40dadd127f3351471727e66a9"
> +
> +SRC_URI = "http://www.zlib.net/${BPN}-${PV}.tar.bz2 \
> +           "
> +SRC_URI[md5sum] = "dc2cfa0d2313ca77224b4d932b2911e9"
> +SRC_URI[sha256sum] = "fa3e3e4881fa5810b8903f2c7e0dcd5a0a673535f0438021c4bbb5db1b918c8e"
> +
> +do_configure (){
> +	./configure --prefix=${prefix} --shared --libdir=${libdir}
> +}
> +
> +do_compile (){
> +	oe_runmake
> +}
> +
> +do_install() {
> +	oe_runmake DESTDIR=${D} install
> +}
> +
> +BBCLASSEXTEND = "native nativesdk"
Khem Raj - Feb. 7, 2012, 3:31 p.m.
On Tue, Feb 7, 2012 at 12:08 AM, Saul Wold <sgw@linux.intel.com> wrote:
> | /bin/grep: /intel/poky/builds/world/tmp/sysroots/qemux86/usr/lib/libz.la:
> No such file or directory

thanks ok I did not catch it with sato image build. which package is
failing with this
error.
Saul Wold - Feb. 7, 2012, 3:59 p.m.
On 02/07/2012 07:31 AM, Khem Raj wrote:
> On Tue, Feb 7, 2012 at 12:08 AM, Saul Wold<sgw@linux.intel.com>  wrote:
>> | /bin/grep: /intel/poky/builds/world/tmp/sysroots/qemux86/usr/lib/libz.la:
>> No such file or directory
>
> thanks ok I did not catch it with sato image build. which package is
> failing with this
> error.
>
pixman, gconf, polkit are the 3 I saw doing a world build.

Sau!
Khem Raj - Feb. 7, 2012, 11:12 p.m.
On (07/02/12 07:59), Saul Wold wrote:
> On 02/07/2012 07:31 AM, Khem Raj wrote:
> >On Tue, Feb 7, 2012 at 12:08 AM, Saul Wold<sgw@linux.intel.com>  wrote:
> >>| /bin/grep: /intel/poky/builds/world/tmp/sysroots/qemux86/usr/lib/libz.la:
> >>No such file or directory
> >
> >thanks ok I did not catch it with sato image build. which package is
> >failing with this
> >error.
> >
> pixman, gconf, polkit are the 3 I saw doing a world build.

I havent been able to reproduce it with eglibc I tried bitbake gconf
pixman polkit it all liked well. Might be my machine is just nice to me
but that said when I get to the culprit it mostly will be the package
who is using .la in weird way since zlib already ships a .pc file it
should have used that one instead

> 
> Sau!
Saul Wold - Feb. 8, 2012, 12:19 a.m.
On 02/07/2012 03:12 PM, Khem Raj wrote:
> On (07/02/12 07:59), Saul Wold wrote:
>> On 02/07/2012 07:31 AM, Khem Raj wrote:
>>> On Tue, Feb 7, 2012 at 12:08 AM, Saul Wold<sgw@linux.intel.com>   wrote:
>>>> | /bin/grep: /intel/poky/builds/world/tmp/sysroots/qemux86/usr/lib/libz.la:
>>>> No such file or directory
>>>
>>> thanks ok I did not catch it with sato image build. which package is
>>> failing with this
>>> error.
>>>
>> pixman, gconf, polkit are the 3 I saw doing a world build.
>
> I havent been able to reproduce it with eglibc I tried bitbake gconf
> pixman polkit it all liked well. Might be my machine is just nice to me
> but that said when I get to the culprit it mostly will be the package
> who is using .la in weird way since zlib already ships a .pc file it
> should have used that one instead
>
Khem,

Can you verify if you have a .la file in you sysroot?

tmp/work/i586-poky-linux/zlib-1.2.5-r3/package/usr/lib:
libz.a  libz.la  libz.so  libz.so.1  libz.so.1.2.5  pkgconfig

tmp/work/i586-poky-linux/zlib-1.2.6-r0/package/usr/lib:
libz.a  libz.so  libz.so.1  libz.so.1.2.6  pkgconfig

Very reproducible on my machine:

| i586-poky-linux-libtool: link: cannot find the library 
`/intel/poky/builds/world/tmp/sysroots/qemux86/usr/lib/libz.la' or 
unhandled argument `=/usr/lib/libz.la'
| make[2]: *** [trap-crasher] Error 1
| make[2]: *** Waiting for unfinished jobs....
| i586-poky-linux-libtool: link: cannot find the library 
`/intel/poky/builds/world/tmp/sysroots/qemux86/usr/lib/libz.la' or 
unhandled argument `=/usr/lib/libz.la'
| make[2]: *** [fetch-test] Error 1
| i586-poky-linux-libtool: link: cannot find the library 
`/intel/poky/builds/world/tmp/sysroots/qemux86/usr/lib/libz.la' or 
unhandled argument `=/usr/lib/libz.la'
| make[2]: *** [region-test] Error 1
| i586-poky-linux-libtool: link: cannot find the library 
`/intel/poky/builds/world/tmp/sysroots/qemux86/usr/lib/libz.la' or 
unhandled argument `=/usr/lib/libz.la'
| make[2]: *** [pdf-op-test] Error 1
| i586-poky-linux-libtool: link: cannot find the library 
`/intel/poky/builds/world/tmp/sysroots/qemux86/usr/lib/libz.la' or 
unhERROR: Function failed: do_compile (see 
/intel/poky/builds/world/tmp/work/i586-poky-linux/pixman-1_0.24.2-r0/temp/log.do_compile.13548 
for further information)
| andled argument `=/usr/lib/libz.la'
| make[2]: *** [oob-test] Error 1
| i586-poky-linux-libtool: link: cannot find the library 
`/intel/poky/builds/world/tmp/sysroots/qemux86/usr/lib/libz.la' or 
unhandled argument `=/usr/lib/libz.la'
| make[2]: *** [alpha-loop] Error 1
| i586-poky-linux-libtool: link: cannot find the library 
`/intel/poky/builds/world/tmp/sysroots/qemux86/usr/lib/libz.la' or 
unhandled argument `=/usr/lib/libz.la'
| make[2]: *** [a1-trap-test] Error 1
| i586-poky-linux-libtool: link: cannot find the library 
`/intel/poky/builds/world/tmp/sysroots/qemux86/usr/lib/libz.la' or 
unhandled argument `=/usr/lib/libz.la'
| make[2]: *** [region-translate-test] Error 1
| i586-poky-linux-libtool: link: cannot find the library 
`/intel/poky/builds/world/tmp/sysroots/qemux86/usr/lib/libz.la' or 
unhandled argument `=/usr/lib/libz.la'
| make[2]: *** [scaling-helpers-test] Error 1
| i586-poky-linux-libtool: link: cannot find the library 
`/intel/poky/builds/world/tmp/sysroots/qemux86/usr/lib/libz.la' or 
unhandled argument `=/usr/lib/libz.la'
| make[2]: *** [scaling-crash-test] Error 1
| i586-poky-linux-libtool: link: cannot find the library 
`/intel/poky/builds/world/tmp/sysroots/qemux86/usr/lib/libz.la' or 
unhandled argument `=/usr/lib/libz.la'
| make[2]: *** [gradient-crash-test] Error 1
| i586-poky-linux-libtool: link: cannot find the library 
`/intel/poky/builds/world/tmp/sysroots/qemux86/usr/lib/libz.la' or 
unhandled argument `=/usr/lib/libz.la'
| make[2]: *** [region-contains-test] Error 1
| make[2]: Leaving directory 
`/intel/poky/builds/world/tmp/work/i586-poky-linux/pixman-1_0.24.2-r0/pixman-0.24.2/test'
| make[1]: *** [all-recursive] Error 1
| make[1]: Leaving directory 
`/intel/poky/builds/world/tmp/work/i586-poky-linux/pixman-1_0.24.2-r0/pixman-0.24.2'
| make: *** [all] Error 2
| ERROR: oe_runmake failed
NOTE: package pixman-1_0.24.2-r0: task do_compile: Failed


Sau!



>>
>> Sau!
>
Khem Raj - Feb. 8, 2012, 2:06 a.m.
On Tue, Feb 7, 2012 at 4:19 PM, Saul Wold <sgw@linux.intel.com> wrote:
>
> Can you verify if you have a .la file in you sysroot?


No its not there and thats the point we probably should learn to live
with out it
actually one of radical ideas I have is to get rid of all .la files in
OE completely
right now python modules e.g.  have them and thats wrong since they never use it
and there are other packages like that.
Steve Sakoman - Feb. 11, 2012, 5:05 a.m.
On Tue, Feb 7, 2012 at 6:06 PM, Khem Raj <raj.khem@gmail.com> wrote:
> On Tue, Feb 7, 2012 at 4:19 PM, Saul Wold <sgw@linux.intel.com> wrote:
>>
>> Can you verify if you have a .la file in you sysroot?
>
>
> No its not there and thats the point we probably should learn to live
> with out it
> actually one of radical ideas I have is to get rid of all .la files in
> OE completely
> right now python modules e.g.  have them and thats wrong since they never use it
> and there are other packages like that.

FWIW, after a pull of oe-core today that included the zlib update I am
getting similar failures on meta/recipes-gnome/gtk+/gtk+_2.24.8.bb:

| /bin/grep: /media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la:
No such file or directory
| /bin/sed: can't read
/media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la: No such
file or directory
| arm-poky-linux-gnueabi-libtool: link:
`/media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la' is not a
valid libtool archive
| make[4]: *** [libgdk-x11-2.0.la] Error 1

Steve
Koen Kooi - Feb. 11, 2012, 5:09 a.m.
Op 11 feb. 2012, om 06:05 heeft Steve Sakoman het volgende geschreven:

> On Tue, Feb 7, 2012 at 6:06 PM, Khem Raj <raj.khem@gmail.com> wrote:
>> On Tue, Feb 7, 2012 at 4:19 PM, Saul Wold <sgw@linux.intel.com> wrote:
>>> 
>>> Can you verify if you have a .la file in you sysroot?
>> 
>> 
>> No its not there and thats the point we probably should learn to live
>> with out it
>> actually one of radical ideas I have is to get rid of all .la files in
>> OE completely
>> right now python modules e.g.  have them and thats wrong since they never use it
>> and there are other packages like that.
> 
> FWIW, after a pull of oe-core today that included the zlib update I am
> getting similar failures on meta/recipes-gnome/gtk+/gtk+_2.24.8.bb:
> 
> | /bin/grep: /media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la:
> No such file or directory
> | /bin/sed: can't read
> /media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la: No such
> file or directory
> | arm-poky-linux-gnueabi-libtool: link:
> `/media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la' is not a
> valid libtool archive
> | make[4]: *** [libgdk-x11-2.0.la] Error 1


It works if you -c cleansstate on a bunch of recipes, pango, cairo, fontconfig, gtk+, etc
Khem Raj - Feb. 11, 2012, 8:15 a.m.
On Fri, Feb 10, 2012 at 9:09 PM, Koen Kooi <koen@dominion.thruhere.net> wrote:
>
> Op 11 feb. 2012, om 06:05 heeft Steve Sakoman het volgende geschreven:
>
>> On Tue, Feb 7, 2012 at 6:06 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>> On Tue, Feb 7, 2012 at 4:19 PM, Saul Wold <sgw@linux.intel.com> wrote:
>>>>
>>>> Can you verify if you have a .la file in you sysroot?
>>>
>>>
>>> No its not there and thats the point we probably should learn to live
>>> with out it
>>> actually one of radical ideas I have is to get rid of all .la files in
>>> OE completely
>>> right now python modules e.g.  have them and thats wrong since they never use it
>>> and there are other packages like that.
>>
>> FWIW, after a pull of oe-core today that included the zlib update I am
>> getting similar failures on meta/recipes-gnome/gtk+/gtk+_2.24.8.bb:
>>
>> | /bin/grep: /media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la:
>> No such file or directory
>> | /bin/sed: can't read
>> /media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la: No such
>> file or directory
>> | arm-poky-linux-gnueabi-libtool: link:
>> `/media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la' is not a
>> valid libtool archive
>> | make[4]: *** [libgdk-x11-2.0.la] Error 1
>
>
> It works if you -c cleansstate on a bunch of recipes, pango, cairo, fontconfig, gtk+, etc

yeah libtool is very hard to get rid of see how many of files in your
sysroot has zlib.la added to other .la files. You need to clean all
those

I wrote a small script which grepped oe-core for occurrence of all
zlib.la in *.la files in sysroot
and then dumps the ipks content to figure out which package provided
that .la then bumped PRs of those recipes which were providing those
ipks.
unfortunately this script was in tmdir and got deleted.
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Khem Raj - Feb. 11, 2012, 8:19 a.m.
On Sat, Feb 11, 2012 at 12:15 AM, Khem Raj <raj.khem@gmail.com> wrote:
> On Fri, Feb 10, 2012 at 9:09 PM, Koen Kooi <koen@dominion.thruhere.net> wrote:
>>
>> Op 11 feb. 2012, om 06:05 heeft Steve Sakoman het volgende geschreven:
>>
>>> On Tue, Feb 7, 2012 at 6:06 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>>> On Tue, Feb 7, 2012 at 4:19 PM, Saul Wold <sgw@linux.intel.com> wrote:
>>>>>
>>>>> Can you verify if you have a .la file in you sysroot?
>>>>
>>>>
>>>> No its not there and thats the point we probably should learn to live
>>>> with out it
>>>> actually one of radical ideas I have is to get rid of all .la files in
>>>> OE completely
>>>> right now python modules e.g.  have them and thats wrong since they never use it
>>>> and there are other packages like that.
>>>
>>> FWIW, after a pull of oe-core today that included the zlib update I am
>>> getting similar failures on meta/recipes-gnome/gtk+/gtk+_2.24.8.bb:
>>>
>>> | /bin/grep: /media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la:
>>> No such file or directory
>>> | /bin/sed: can't read
>>> /media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la: No such
>>> file or directory
>>> | arm-poky-linux-gnueabi-libtool: link:
>>> `/media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la' is not a
>>> valid libtool archive
>>> | make[4]: *** [libgdk-x11-2.0.la] Error 1
>>
>>
>> It works if you -c cleansstate on a bunch of recipes, pango, cairo, fontconfig, gtk+, etc
>
> yeah libtool is very hard to get rid of see how many of files in your
> sysroot has zlib.la added to other .la files. You need to clean all
> those
>
> I wrote a small script which grepped oe-core for occurrence of all
> zlib.la in *.la files in sysroot
> and then dumps the ipks content to figure out which package provided
> that .la then bumped PRs of those recipes which were providing those
> ipks.
> unfortunately this script was in tmdir and got deleted.

ah screen saved a snapshot here is the script

sysroot=/home/kraj/work/angstrom/sources/openembedded-core/build/tmp-eglibc/sysroots/qemux86
deploy="/home/kraj/work/angstrom/sources/openembedded-core/build/tmp-eglibc/deploy/ipk/i586
/home/kraj/work/angstrom/sources/
openembedded-core/build/tmp-eglibc/deploy/ipk/qemux86"

las=$(find $sysroot -name *.la|xargs grep -Hns libz.la | cut -d':' -f 1)
for f in $las
do
    ff=`basename $f`
        for fff in $(find $deploy -name '*.ipk')
        do
            dpkg-deb -c $fff | grep $ff >& /dev/null
            if [ $? = 0 ]
            then
                ls $fff
                break
            fi
        done
done
Koen Kooi - Feb. 11, 2012, 8:26 a.m.
Op 11 feb. 2012 om 09:15 heeft Khem Raj <raj.khem@gmail.com> het volgende geschreven:

> On Fri, Feb 10, 2012 at 9:09 PM, Koen Kooi <koen@dominion.thruhere.net> wrote:
>> 
>> Op 11 feb. 2012, om 06:05 heeft Steve Sakoman het volgende geschreven:
>> 
>>> On Tue, Feb 7, 2012 at 6:06 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>>> On Tue, Feb 7, 2012 at 4:19 PM, Saul Wold <sgw@linux.intel.com> wrote:
>>>>> 
>>>>> Can you verify if you have a .la file in you sysroot?
>>>> 
>>>> 
>>>> No its not there and thats the point we probably should learn to live
>>>> with out it
>>>> actually one of radical ideas I have is to get rid of all .la files in
>>>> OE completely
>>>> right now python modules e.g.  have them and thats wrong since they never use it
>>>> and there are other packages like that.
>>> 
>>> FWIW, after a pull of oe-core today that included the zlib update I am
>>> getting similar failures on meta/recipes-gnome/gtk+/gtk+_2.24.8.bb:
>>> 
>>> | /bin/grep: /media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la:
>>> No such file or directory
>>> | /bin/sed: can't read
>>> /media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la: No such
>>> file or directory
>>> | arm-poky-linux-gnueabi-libtool: link:
>>> `/media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la' is not a
>>> valid libtool archive
>>> | make[4]: *** [libgdk-x11-2.0.la] Error 1
>> 
>> 
>> It works if you -c cleansstate on a bunch of recipes, pango, cairo, fontconfig, gtk+, etc
> 
> yeah libtool is very hard to get rid of see how many of files in your
> sysroot has zlib.la added to other .la files. You need to clean all
> those
> 
> I wrote a small script which grepped oe-core for occurrence of all
> zlib.la in *.la files in sysroot
> and then dumps the ipks content to figure out which package provided
> that .la then bumped PRs of those recipes which were providing those
> ipks.
> unfortunately this script was in tmdir and got deleted.

rpmdebs Will break during do_rootfs, no time to look into that, ipk works



>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Martin Jansa - Feb. 13, 2012, 7:48 a.m.
On Sat, Feb 11, 2012 at 06:09:52AM +0100, Koen Kooi wrote:
> 
> Op 11 feb. 2012, om 06:05 heeft Steve Sakoman het volgende geschreven:
> 
> > On Tue, Feb 7, 2012 at 6:06 PM, Khem Raj <raj.khem@gmail.com> wrote:
> >> On Tue, Feb 7, 2012 at 4:19 PM, Saul Wold <sgw@linux.intel.com> wrote:
> >>> 
> >>> Can you verify if you have a .la file in you sysroot?
> >> 
> >> 
> >> No its not there and thats the point we probably should learn to live
> >> with out it
> >> actually one of radical ideas I have is to get rid of all .la files in
> >> OE completely
> >> right now python modules e.g.  have them and thats wrong since they never use it
> >> and there are other packages like that.
> > 
> > FWIW, after a pull of oe-core today that included the zlib update I am
> > getting similar failures on meta/recipes-gnome/gtk+/gtk+_2.24.8.bb:
> > 
> > | /bin/grep: /media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la:
> > No such file or directory
> > | /bin/sed: can't read
> > /media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la: No such
> > file or directory
> > | arm-poky-linux-gnueabi-libtool: link:
> > `/media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la' is not a
> > valid libtool archive
> > | make[4]: *** [libgdk-x11-2.0.la] Error 1
> 
> 
> It works if you -c cleansstate on a bunch of recipes, pango, cairo, fontconfig, gtk+, etc

list for me

evas ecore fsogsmd pidgin elementary fsodeviced fsoaudiod subversion
python-evas libsoup-2.4 libeflvala efreet fsotdld poppler fsosystemd 
fsousaged fsonetworkd gtk+ python-gst emotion mysql5 libfsotransport
libfsobasics gd libgsm0710mux gst-plugins-base iksemel fsodatad
webkit-gtk fsodatad epdf librsvg curl libsexy libfsosystem orbit2
libfso-glib pango eeze libshr-glib farsight2 id3lib gst-plugins-good 
gst-plugins-ugly libnice libgpewidget matchbox-panel-2 edbus vte ethumb
glib-networking libgisi libfsoresource edje libfsoframework gconf file
libglade json-glib ethumb libcroco gnome-keyring libsdl-image neon
qt4-x11-free python-pygobject msmcomm-specs gnome-keyring libphone-ui
shr-wizard matchbox-keyboard matchbox-panel-2

And this isn't even on fully built feed :/.
Steve Sakoman - Feb. 13, 2012, 1:23 p.m.
On Sun, Feb 12, 2012 at 11:48 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
> On Sat, Feb 11, 2012 at 06:09:52AM +0100, Koen Kooi wrote:
>>
>> Op 11 feb. 2012, om 06:05 heeft Steve Sakoman het volgende geschreven:
>>
>> > On Tue, Feb 7, 2012 at 6:06 PM, Khem Raj <raj.khem@gmail.com> wrote:
>> >> On Tue, Feb 7, 2012 at 4:19 PM, Saul Wold <sgw@linux.intel.com> wrote:
>> >>>
>> >>> Can you verify if you have a .la file in you sysroot?
>> >>
>> >>
>> >> No its not there and thats the point we probably should learn to live
>> >> with out it
>> >> actually one of radical ideas I have is to get rid of all .la files in
>> >> OE completely
>> >> right now python modules e.g.  have them and thats wrong since they never use it
>> >> and there are other packages like that.
>> >
>> > FWIW, after a pull of oe-core today that included the zlib update I am
>> > getting similar failures on meta/recipes-gnome/gtk+/gtk+_2.24.8.bb:
>> >
>> > | /bin/grep: /media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la:
>> > No such file or directory
>> > | /bin/sed: can't read
>> > /media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la: No such
>> > file or directory
>> > | arm-poky-linux-gnueabi-libtool: link:
>> > `/media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la' is not a
>> > valid libtool archive
>> > | make[4]: *** [libgdk-x11-2.0.la] Error 1
>>
>>
>> It works if you -c cleansstate on a bunch of recipes, pango, cairo, fontconfig, gtk+, etc
>
> list for me
>
> evas ecore fsogsmd pidgin elementary fsodeviced fsoaudiod subversion
> python-evas libsoup-2.4 libeflvala efreet fsotdld poppler fsosystemd
> fsousaged fsonetworkd gtk+ python-gst emotion mysql5 libfsotransport
> libfsobasics gd libgsm0710mux gst-plugins-base iksemel fsodatad
> webkit-gtk fsodatad epdf librsvg curl libsexy libfsosystem orbit2
> libfso-glib pango eeze libshr-glib farsight2 id3lib gst-plugins-good
> gst-plugins-ugly libnice libgpewidget matchbox-panel-2 edbus vte ethumb
> glib-networking libgisi libfsoresource edje libfsoframework gconf file
> libglade json-glib ethumb libcroco gnome-keyring libsdl-image neon
> qt4-x11-free python-pygobject msmcomm-specs gnome-keyring libphone-ui
> shr-wizard matchbox-keyboard matchbox-panel-2
>
> And this isn't even on fully built feed :/.

Indeed!  I gave up on trying to determine an exhaustive list and just
blew away tmp and sstate and rebuilt everything -- including package
repositories :-(

We need to find a way to prevent or warn of disruptive changes like
this zlib patch.  For those of us trying to make a living using Yocto,
losing a day of productivity to things like this really stings.

Steve
Martin Jansa - Feb. 13, 2012, 1:33 p.m.
On Mon, Feb 13, 2012 at 05:23:18AM -0800, Steve Sakoman wrote:
> On Sun, Feb 12, 2012 at 11:48 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
> > On Sat, Feb 11, 2012 at 06:09:52AM +0100, Koen Kooi wrote:
> >>
> >> Op 11 feb. 2012, om 06:05 heeft Steve Sakoman het volgende geschreven:
> >>
> >> > On Tue, Feb 7, 2012 at 6:06 PM, Khem Raj <raj.khem@gmail.com> wrote:
> >> >> On Tue, Feb 7, 2012 at 4:19 PM, Saul Wold <sgw@linux.intel.com> wrote:
> >> >>>
> >> >>> Can you verify if you have a .la file in you sysroot?
> >> >>
> >> >>
> >> >> No its not there and thats the point we probably should learn to live
> >> >> with out it
> >> >> actually one of radical ideas I have is to get rid of all .la files in
> >> >> OE completely
> >> >> right now python modules e.g.  have them and thats wrong since they never use it
> >> >> and there are other packages like that.
> >> >
> >> > FWIW, after a pull of oe-core today that included the zlib update I am
> >> > getting similar failures on meta/recipes-gnome/gtk+/gtk+_2.24.8.bb:
> >> >
> >> > | /bin/grep: /media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la:
> >> > No such file or directory
> >> > | /bin/sed: can't read
> >> > /media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la: No such
> >> > file or directory
> >> > | arm-poky-linux-gnueabi-libtool: link:
> >> > `/media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la' is not a
> >> > valid libtool archive
> >> > | make[4]: *** [libgdk-x11-2.0.la] Error 1
> >>
> >>
> >> It works if you -c cleansstate on a bunch of recipes, pango, cairo, fontconfig, gtk+, etc
> >
> > list for me
> >
> > evas ecore fsogsmd pidgin elementary fsodeviced fsoaudiod subversion
> > python-evas libsoup-2.4 libeflvala efreet fsotdld poppler fsosystemd
> > fsousaged fsonetworkd gtk+ python-gst emotion mysql5 libfsotransport
> > libfsobasics gd libgsm0710mux gst-plugins-base iksemel fsodatad
> > webkit-gtk fsodatad epdf librsvg curl libsexy libfsosystem orbit2
> > libfso-glib pango eeze libshr-glib farsight2 id3lib gst-plugins-good
> > gst-plugins-ugly libnice libgpewidget matchbox-panel-2 edbus vte ethumb
> > glib-networking libgisi libfsoresource edje libfsoframework gconf file
> > libglade json-glib ethumb libcroco gnome-keyring libsdl-image neon
> > qt4-x11-free python-pygobject msmcomm-specs gnome-keyring libphone-ui
> > shr-wizard matchbox-keyboard matchbox-panel-2
> >
> > And this isn't even on fully built feed :/.
> 
> Indeed!  I gave up on trying to determine an exhaustive list and just
> blew away tmp and sstate and rebuilt everything -- including package
> repositories :-(
> 
> We need to find a way to prevent or warn of disruptive changes like
> this zlib patch.  For those of us trying to make a living using Yocto,
> losing a day of productivity to things like this really stings.

I have 131 items in my list now, will send PR bumps today.

> Steve
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Koen Kooi - Feb. 13, 2012, 1:42 p.m.
Op 13 feb. 2012, om 05:23 heeft Steve Sakoman het volgende geschreven:

> On Sun, Feb 12, 2012 at 11:48 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
>> On Sat, Feb 11, 2012 at 06:09:52AM +0100, Koen Kooi wrote:
>>> 
>>> Op 11 feb. 2012, om 06:05 heeft Steve Sakoman het volgende geschreven:
>>> 
>>>> On Tue, Feb 7, 2012 at 6:06 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>>>> On Tue, Feb 7, 2012 at 4:19 PM, Saul Wold <sgw@linux.intel.com> wrote:
>>>>>> 
>>>>>> Can you verify if you have a .la file in you sysroot?
>>>>> 
>>>>> 
>>>>> No its not there and thats the point we probably should learn to live
>>>>> with out it
>>>>> actually one of radical ideas I have is to get rid of all .la files in
>>>>> OE completely
>>>>> right now python modules e.g.  have them and thats wrong since they never use it
>>>>> and there are other packages like that.
>>>> 
>>>> FWIW, after a pull of oe-core today that included the zlib update I am
>>>> getting similar failures on meta/recipes-gnome/gtk+/gtk+_2.24.8.bb:
>>>> 
>>>> | /bin/grep: /media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la:
>>>> No such file or directory
>>>> | /bin/sed: can't read
>>>> /media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la: No such
>>>> file or directory
>>>> | arm-poky-linux-gnueabi-libtool: link:
>>>> `/media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la' is not a
>>>> valid libtool archive
>>>> | make[4]: *** [libgdk-x11-2.0.la] Error 1
>>> 
>>> 
>>> It works if you -c cleansstate on a bunch of recipes, pango, cairo, fontconfig, gtk+, etc
>> 
>> list for me
>> 
>> evas ecore fsogsmd pidgin elementary fsodeviced fsoaudiod subversion
>> python-evas libsoup-2.4 libeflvala efreet fsotdld poppler fsosystemd
>> fsousaged fsonetworkd gtk+ python-gst emotion mysql5 libfsotransport
>> libfsobasics gd libgsm0710mux gst-plugins-base iksemel fsodatad
>> webkit-gtk fsodatad epdf librsvg curl libsexy libfsosystem orbit2
>> libfso-glib pango eeze libshr-glib farsight2 id3lib gst-plugins-good
>> gst-plugins-ugly libnice libgpewidget matchbox-panel-2 edbus vte ethumb
>> glib-networking libgisi libfsoresource edje libfsoframework gconf file
>> libglade json-glib ethumb libcroco gnome-keyring libsdl-image neon
>> qt4-x11-free python-pygobject msmcomm-specs gnome-keyring libphone-ui
>> shr-wizard matchbox-keyboard matchbox-panel-2
>> 
>> And this isn't even on fully built feed :/.
> 
> Indeed!  I gave up on trying to determine an exhaustive list and just
> blew away tmp and sstate and rebuilt everything -- including package
> repositories :-(
> 
> We need to find a way to prevent or warn of disruptive changes like
> this zlib patch.  For those of us trying to make a living using Yocto,
> losing a day of productivity to things like this really stings.

A while ago there were 2 weeks with absolutely no breakage which I really liked. Then people can back from their xmas holidays....
Phil Blundell - Feb. 13, 2012, 3:39 p.m.
On Mon, 2012-02-13 at 05:23 -0800, Steve Sakoman wrote:
> We need to find a way to prevent or warn of disruptive changes like
> this zlib patch.

Aren't these sorts of things meant to get tested on the Yocto
autobuilder before being merged?  I thought that was how it was supposed
to work.

p.
Khem Raj - Feb. 13, 2012, 5:09 p.m.
On Mon, Feb 13, 2012 at 7:39 AM, Phil Blundell <philb@gnu.org> wrote:
> On Mon, 2012-02-13 at 05:23 -0800, Steve Sakoman wrote:
>> We need to find a way to prevent or warn of disruptive changes like
>> this zlib patch.
>
> Aren't these sorts of things meant to get tested on the Yocto
> autobuilder before being merged?  I thought that was how it was supposed
> to work.
>

The patch takes care of packages in oe-core but essentially
relied upon layers to consider the update and I also posted a script
that would help in identifying
recipes which need updates.
Lianhao Lu - Feb. 14, 2012, 4:52 a.m.
>>>> 
>>>> It works if you -c cleansstate on a bunch of recipes, pango, cairo, fontconfig, gtk+, etc
>>> 

I tried rpm-native after "-c cleansstate", but it still asks for libz.la? Anyone has the clue?

Best Regards,
Lianhao
Khem Raj - Feb. 14, 2012, 6:24 a.m.
On Mon, Feb 13, 2012 at 8:52 PM, Lu, Lianhao <lianhao.lu@intel.com> wrote:
>>>>>
>>>>> It works if you -c cleansstate on a bunch of recipes, pango, cairo, fontconfig, gtk+, etc
>>>>
>
> I tried rpm-native after "-c cleansstate", but it still asks for libz.la? Anyone has the clue?

try to find which native .la files have libz,la in deps
and rebuild them too

>
> Best Regards,
> Lianhao
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Martin Jansa - Feb. 14, 2012, 6:53 a.m.
On Tue, Feb 14, 2012 at 04:52:30AM +0000, Lu, Lianhao wrote:
> >>>> 
> >>>> It works if you -c cleansstate on a bunch of recipes, pango, cairo, fontconfig, gtk+, etc
> >>> 
> 
> I tried rpm-native after "-c cleansstate", but it still asks for libz.la? Anyone has the clue?

one .la still with libz.la in dependency tree is enough to pollute all
.la files even when they get rebuild thanks to PR bump.

That's why I sent another wider round of PR bumps to oe-core and also to
all layers (oe-core, meta-openembedded/*, meta-smartphone/*) I'm using at once, 
because ie libsoup-2.4 from meta-efl wasn't PR bumped and was still pulling 
libz.la to all .la files depending on libsoup :/.

And even my wider PR bump round isn't 100% complete for everybody,
because it's based on sysroot popultated by my builds and you can have
different .la files there (from different recipe versions or different
layers).

Cheers,
Phil Blundell - Feb. 14, 2012, 9:26 a.m.
On Mon, 2012-02-13 at 22:24 -0800, Khem Raj wrote:
> On Mon, Feb 13, 2012 at 8:52 PM, Lu, Lianhao <lianhao.lu@intel.com> wrote:
> >>>>>
> >>>>> It works if you -c cleansstate on a bunch of recipes, pango, cairo, fontconfig, gtk+, etc
> >>>>
> >
> > I tried rpm-native after "-c cleansstate", but it still asks for libz.la? Anyone has the clue?
> 
> try to find which native .la files have libz,la in deps
> and rebuild them too

Can we not just put libz.la back in zlib?  Having to spend hours hunting
out and rebuilding things, and/or bumping PR on half the .bb files in
the repository, seems like an unsatisfactory state of affairs.  As far
as I know the presence of libz.la wasn't previously causing us any
trouble so I'm not entirely clear why heroic measures are justified in
trying to get rid of it.

p.
Koen Kooi - Feb. 14, 2012, 2:24 p.m.
Op 13 feb. 2012, om 22:53 heeft Martin Jansa het volgende geschreven:

> On Tue, Feb 14, 2012 at 04:52:30AM +0000, Lu, Lianhao wrote:
>>>>>> 
>>>>>> It works if you -c cleansstate on a bunch of recipes, pango, cairo, fontconfig, gtk+, etc
>>>>> 
>> 
>> I tried rpm-native after "-c cleansstate", but it still asks for libz.la? Anyone has the clue?
> 
> one .la still with libz.la in dependency tree is enough to pollute all
> .la files even when they get rebuild thanks to PR bump.
> 
> That's why I sent another wider round of PR bumps to oe-core and also to
> all layers (oe-core, meta-openembedded/*, meta-smartphone/*) I'm using at once, 
> because ie libsoup-2.4 from meta-efl wasn't PR bumped and was still pulling 
> libz.la to all .la files depending on libsoup :/.
> 
> And even my wider PR bump round isn't 100% complete for everybody,
> because it's based on sysroot popultated by my builds and you can have
> different .la files there (from different recipe versions or different
> layers).


Saul and I discussed this yesterday and we also suspect using --as-needed in LDFLAGS limits the impact of this problem. But still, PR bumps are needed to keep the -dev packages in the feeds working.

regards,

Koen
Richard Purdie - Feb. 21, 2012, 11:01 p.m.
On Mon, 2012-02-13 at 05:23 -0800, Steve Sakoman wrote:
> Indeed!  I gave up on trying to determine an exhaustive list and just
> blew away tmp and sstate and rebuilt everything -- including package
> repositories :-(
> 
> We need to find a way to prevent or warn of disruptive changes like
> this zlib patch.  For those of us trying to make a living using Yocto,
> losing a day of productivity to things like this really stings.

I agree this change sucked and showed us we have some real issues. I
will point out that if we had been using the basichash signature
generator, it would likely have picked up this change and rebuild all
the appropriate pieces.

This illustrates why we do really need to switch to the basichash
dependency model even if some things are going to rebuild a bit more
often as humans make bad judges of what needs rebuilding...

Cheers,

Richard
Richard Purdie - Feb. 21, 2012, 11:04 p.m.
On Mon, 2012-02-13 at 15:39 +0000, Phil Blundell wrote:
> On Mon, 2012-02-13 at 05:23 -0800, Steve Sakoman wrote:
> > We need to find a way to prevent or warn of disruptive changes like
> > this zlib patch.
> 
> Aren't these sorts of things meant to get tested on the Yocto
> autobuilder before being merged?  I thought that was how it was supposed
> to work.

It was tested, there were some issues, it was thought they were
relatively easily resolved, that turned out not to be the case.

I get put under immense pressure to merge patches 'yesterday'. Please
keep this kind of issue in mind next time you ask me to hurry up and
merge something ;-). We've been able to catch a lot of things but its
the ones that slip through that people notice :/.

Cheers,

Richard
Koen Kooi - Feb. 22, 2012, 8:03 a.m.
Op 22 feb. 2012, om 00:01 heeft Richard Purdie het volgende geschreven:

> On Mon, 2012-02-13 at 05:23 -0800, Steve Sakoman wrote:
>> Indeed!  I gave up on trying to determine an exhaustive list and just
>> blew away tmp and sstate and rebuilt everything -- including package
>> repositories :-(
>> 
>> We need to find a way to prevent or warn of disruptive changes like
>> this zlib patch.  For those of us trying to make a living using Yocto,
>> losing a day of productivity to things like this really stings.
> 
> I agree this change sucked and showed us we have some real issues. I
> will point out that if we had been using the basichash signature
> generator, it would likely have picked up this change and rebuild all
> the appropriate pieces.

Rebuild yes, but not fix all the -dev packages in the feeds.

regards,

Koen
Richard Purdie - Feb. 22, 2012, 11:08 a.m.
On Wed, 2012-02-22 at 09:03 +0100, Koen Kooi wrote:
> Op 22 feb. 2012, om 00:01 heeft Richard Purdie het volgende geschreven:
> 
> > On Mon, 2012-02-13 at 05:23 -0800, Steve Sakoman wrote:
> >> Indeed!  I gave up on trying to determine an exhaustive list and just
> >> blew away tmp and sstate and rebuilt everything -- including package
> >> repositories :-(
> >> 
> >> We need to find a way to prevent or warn of disruptive changes like
> >> this zlib patch.  For those of us trying to make a living using Yocto,
> >> losing a day of productivity to things like this really stings.
> > 
> > I agree this change sucked and showed us we have some real issues. I
> > will point out that if we had been using the basichash signature
> > generator, it would likely have picked up this change and rebuild all
> > the appropriate pieces.
> 
> Rebuild yes, but not fix all the -dev packages in the feeds.

The PR service using the hash changes would have allowed that though...

Cheers,

Richard

Patch

diff --git a/meta/recipes-core/zlib/files/Makefile.am b/meta/recipes-core/zlib/files/Makefile.am
deleted file mode 100644
index b66d299..0000000
--- a/meta/recipes-core/zlib/files/Makefile.am
+++ /dev/null
@@ -1,9 +0,0 @@ 
-lib_LTLIBRARIES = libz.la
-
-libz_la_SOURCES = adler32.c compress.c crc32.c gzlib.c gzclose.c gzread.c \
-                  gzwrite.c uncompr.c deflate.c trees.c zutil.c inflate.c \
-                  infback.c inftrees.c inffast.c
-
-libz_la_LDFLAGS = -version-number 1:2:5 --version-script zlib.map
-
-include_HEADERS = zconf.h zlib.h zlibdefs.h
diff --git a/meta/recipes-core/zlib/files/configure.ac b/meta/recipes-core/zlib/files/configure.ac
deleted file mode 100644
index 4761b7e..0000000
--- a/meta/recipes-core/zlib/files/configure.ac
+++ /dev/null
@@ -1,48 +0,0 @@ 
-AC_INIT(zlib,1.2.5)
-AC_CONFIG_SRCDIR(adler32.c)
-AM_INIT_AUTOMAKE(zlibs,1.2.5)
-
-AC_PREREQ([2.59])
-
-AC_PROG_CC([gcc])
-AC_PROG_LIBTOOL
-
-AC_HEADER_STDC
-
-zlib_save_CPPFLAGS=$CPPFLAGS
-CPPFLAGS="$CPPFLAGS -D_LARGEFILE64_SOURCE"
-AC_CHECK_TYPES(off64_t)
-CPPFLAGS=$zlib_save_CPPFLAGS
-
-AC_CACHE_CHECK([whether to enable -D_LARGEFILE64_SOURCE], [zlib_cv_use_lfs64], [
-    zlib_cv_use_lfs64=no
-    if test "$ac_cv_type_off64_t" = "yes"; then
-        zlib_cv_use_lfs64=yes
-    fi
-])
-
-if test "$zlib_cv_use_lfs64" = "yes"; then
-    CPPFLAGS="$CPPFLAGS -D_LARGEFILE64_SOURCE"
-
-    #APR_ADDTO(CPPFLAGS, [-D_LARGEFILE64_SOURCE])
-fi
-
-cat > zlibdefs.h << EOF
-/* zlibdefs.h -- compile-time definitions for the zlib compression library
- * Copyright (C) 1995-2006 Jean-loup Gailly.
- * For conditions of distribution and use, see copyright notice in zlib.h
- */
-
-#include <sys/types.h>	/* for off_t */
-#include <unistd.h>	/* for SEEK_* and off_t */
-#ifdef VMS
-#  include <unixio.h>	/* for off_t */
-#endif
-#ifndef z_off_t
-#  define z_off_t off_t
-#endif
-EOF
-
-AC_CONFIG_FILES([Makefile])
-
-AC_OUTPUT
diff --git a/meta/recipes-core/zlib/zlib-1.2.5/fix.inverted.LFS.logic.patch b/meta/recipes-core/zlib/zlib-1.2.5/fix.inverted.LFS.logic.patch
deleted file mode 100644
index 038c1a2..0000000
--- a/meta/recipes-core/zlib/zlib-1.2.5/fix.inverted.LFS.logic.patch
+++ /dev/null
@@ -1,20 +0,0 @@ 
-Upstream-Status: Pending
-
-see
-https://bugs.gentoo.org/316377?id=316377
-https://bugs.freedesktop.org/show_bug.cgi?id=33710
-http://lists.freedesktop.org/archives/poppler-bugs/2011-January/006014.html
-for details
-
-diff -up zlib-1.2.5/zlib.h.pom zlib-1.2.5/zlib.h
---- zlib-1.2.5/zlib.h.pom	2010-04-20 06:12:48.000000000 +0200
-+++ zlib-1.2.5/zlib.h	2010-06-16 13:08:59.000000000 +0200
-@@ -1578,7 +1578,7 @@ ZEXTERN int ZEXPORT inflateBackInit_ OF(
- #  define gzoffset gzoffset64
- #  define adler32_combine adler32_combine64
- #  define crc32_combine crc32_combine64
--#  ifdef _LARGEFILE64_SOURCE
-+#  ifndef _LARGEFILE64_SOURCE
-      ZEXTERN gzFile ZEXPORT gzopen64 OF((const char *, const char *));
-      ZEXTERN z_off_t ZEXPORT gzseek64 OF((gzFile, z_off_t, int));
-      ZEXTERN z_off_t ZEXPORT gztell64 OF((gzFile));
diff --git a/meta/recipes-core/zlib/zlib_1.2.5.bb b/meta/recipes-core/zlib/zlib_1.2.5.bb
deleted file mode 100644
index b5756d9..0000000
--- a/meta/recipes-core/zlib/zlib_1.2.5.bb
+++ /dev/null
@@ -1,41 +0,0 @@ 
-SUMMARY = "Zlib Compression Library"
-DESCRIPTION = "Zlib is a general-purpose, patent-free, lossless data compression \
-library which is used by many different programs."
-HOMEPAGE = "http://zlib.net/"
-SECTION = "libs"
-LICENSE = "Zlib"
-LIC_FILES_CHKSUM = "file://zlib.h;beginline=4;endline=23;md5=084e9c30e4e6272c3b057b13c6467f3d"
-
-DEPENDS = "libtool-cross"
-PR = "r3"
-
-SRC_URI = "http://www.zlib.net/${BPN}-${PV}.tar.bz2 \
-           file://configure.ac \
-           file://Makefile.am \
-           file://fix.inverted.LFS.logic.patch"
-
-SRC_URI[md5sum] = "be1e89810e66150f5b0327984d8625a0"
-SRC_URI[sha256sum] = "239aead2f22f16bfcfa6a6a5150dcbd6d6f2e4d1eaa8727b5769ea014120b307"
-
-inherit autotools
-
-do_configure_prepend () {
-	cp ${WORKDIR}/configure.ac ${S}/
-	cp ${WORKDIR}/Makefile.am ${S}/
-}
-
-do_install_append () {
-	sed \
-		-e 's:@prefix@:${prefix}:' \
-		-e 's:@exec_prefix@:${exec_prefix}:' \
-		-e 's:@libdir@:${libdir}:' \
-		-e 's:@sharedlibdir@:${libdir}:' \
-		-e 's:@includedir@:${includedir}:' \
-		-e 's:@VERSION@:${PV}:' \
-		zlib.pc.in > zlib.pc
-
-	install -d ${D}${libdir}/pkgconfig
-	install -m 0644 zlib.pc ${D}${libdir}/pkgconfig/
-}
-
-BBCLASSEXTEND = "native nativesdk"
diff --git a/meta/recipes-core/zlib/zlib_1.2.6.bb b/meta/recipes-core/zlib/zlib_1.2.6.bb
new file mode 100644
index 0000000..a220773
--- /dev/null
+++ b/meta/recipes-core/zlib/zlib_1.2.6.bb
@@ -0,0 +1,26 @@ 
+SUMMARY = "Zlib Compression Library"
+DESCRIPTION = "Zlib is a general-purpose, patent-free, lossless data compression \
+library which is used by many different programs."
+HOMEPAGE = "http://zlib.net/"
+SECTION = "libs"
+LICENSE = "Zlib"
+LIC_FILES_CHKSUM = "file://zlib.h;beginline=4;endline=23;md5=94d1b5a40dadd127f3351471727e66a9"
+
+SRC_URI = "http://www.zlib.net/${BPN}-${PV}.tar.bz2 \
+           "
+SRC_URI[md5sum] = "dc2cfa0d2313ca77224b4d932b2911e9"
+SRC_URI[sha256sum] = "fa3e3e4881fa5810b8903f2c7e0dcd5a0a673535f0438021c4bbb5db1b918c8e"
+
+do_configure (){
+	./configure --prefix=${prefix} --shared --libdir=${libdir}
+}
+
+do_compile (){
+	oe_runmake
+}
+
+do_install() {
+	oe_runmake DESTDIR=${D} install
+}
+
+BBCLASSEXTEND = "native nativesdk"