Misc patch set
cover Misc patch set
The following is a set of patches that I've been merging forward for a while now. Almost all of these items have been sent up previously to the oe-core list, but they have not yet been integrated.
As far as I'm aware, all comments to previous submissions have been addressed.
PATCH 1/21 libxpm: inherit gettext
From: Jesse Zhang <[email protected]>
libxpm requires the xgettext command to build.
--- meta/recipes-graphics/xorg-lib/libxpm_3.5.10.bb | 3 +++ 1 file changed, 3 insertions(+)
meta/recipes-graphics/xorg-lib/libxpm_3.5.10.bb +3 -0
@@ -1,5 +1,8 @@ require xorg-lib-common.inc +# libxpm requires xgettext to build +inherit gettext + SUMMARY = "Xpm: X Pixmap extension library" DESCRIPTION = "libXpm provides support and common operation for the XPM \
Signature · 1 line
1.8.1.2.545.g2f19ada
PATCH 2/21 Add directory information to the pkgdata files
In reply to Mark HatleAdd S(ource) and B(uild) directory information to the recipe pkgdata files. This allows external tools to find the appropriate information, and be able to easily access the corresponding sources and build directories.
--- meta/classes/package.bbclass | 2 ++ 1 file changed, 2 insertions(+)
meta/classes/package.bbclass +2 -0
@@ -1124,6 +1124,8 @@ python emit_pkgdata() { data_file = pkgdatadir + d.expand("/${PN}" ) f = open(data_file, 'w') + f.write("S: %s\n" % d.expand("${S}")) + f.write("B: %s\n" % d.expand("${B}")) f.write("PACKAGES: %s\n" % packages) f.close()
Signature · 1 line
1.8.1.2.545.g2f19ada
Re: [PATCH 2/21] Add directory information to the pkgdata files
Quoted 14 lines · On Wednesday 29 May 2013 10:09:44 Mark Hatle wrote:
Add S(ource) and B(uild) directory information to the recipe pkgdata files. This allows external tools to find the appropriate information, and be able to easily access the corresponding sources and build directories.
Signed-off-by Mark Hatle <[email protected]>--- meta/classes/package.bbclass | 2 ++ 1 file changed, 2 insertions(+)meta/classes/package.bbclass +0
-0
meta/classes/package.bbclass python emit_pkgdata() { · line 1130
Quoted 7 lines
meta/classes/package.bbclass +2
-0@@ -1124,6 +1124,8 @@ python emit_pkgdata() { data_file = pkgdatadir + d.expand("/${PN}" ) f = open(data_file, 'w') + f.write("S: %s\n" % d.expand("${S}")) + f.write("B: %s\n" % d.expand("${B}")) f.write("PACKAGES: %s\n" % packages) f.close()
I'm not sure I'm totally comfortable with this idea. External tools shouldn't necessarily expect to be able to poke into the source after packaging occurs - rm_work (if enabled) will remove the work directory, and separately sstate may restore the pkgdata and not the workdir. In both situations these values will be invalid.
If tools need to be able to find out the values of S and B then I think they ought to be querying them via bitbake.
Cheers,
Paul
Signature · 2 lines
Paul Eggleton Intel Open Source Technology Centre
Re: [PATCH 2/21] Add directory information to the pkgdata files
Quoted 29 lines · Paul Eggleton
Quoted 14 lines · On Wednesday 29 May 2013 10:09:44 Mark Hatle wrote:
Add S(ource) and B(uild) directory information to the recipe pkgdata files. This allows external tools to find the appropriate information, and be able to easily access the corresponding sources and build directories.
Signed-off-by Mark Hatle <[email protected]>--- meta/classes/package.bbclass | 2 ++ 1 file changed, 2 insertions(+)meta/classes/package.bbclass +0
-0meta/classes/package.bbclass python emit_pkgdata() { · line 1130
Quoted 7 lines
meta/classes/package.bbclass +2
-0@@ -1124,6 +1124,8 @@ python emit_pkgdata() { data_file = pkgdatadir + d.expand("/${PN}" ) f = open(data_file, 'w') + f.write("S: %s\n" % d.expand("${S}")) + f.write("B: %s\n" % d.expand("${B}")) f.write("PACKAGES: %s\n" % packages) f.close()I'm not sure I'm totally comfortable with this idea. External tools shouldn't necessarily expect to be able to poke into the source after packaging occurs -
rm_work(if enabled) will remove the work directory, and separately sstate may restore the pkgdata and not the workdir. In both situations these values will be invalid.
Quoted 2 lines
If tools need to be able to find out the values of S and B then I think they ought to be querying them via bitbake.
When discussing this in the past, via IRC, it was mentioned that the pkgdata has all of the necessary data to figure out what has been built and much of the data that external (think eclipse based UI tools) need to figure out.
This particular case allows our tooling to not only list what was built, but allows the tools to go into the directory (B or S) and explore the sources, logs, etc.
If this is rejected, I'm fine, we'll just carry it forward on our own.. but I think it does have some generic value.
(Actually querying bitbake is what we started with, but when you query it 1000 times.. it's pretty obvious this doesn't work, the time alone to query it for the 'B' and 'S' of each recipe is significant to the point of being unusable for external tools.)
--Mark
Quoted 3 lines
Cheers,
Paul
Re: [PATCH 2/21] Add directory information to the pkgdata files
In reply to Mark HatleQuoted 14 lines · Mark Hatle
Add S(ource) and B(uild) directory information to the recipe pkgdata files. This allows external tools to find the appropriate information, and be able to easily access the corresponding sources and build directories.
Signed-off-by Mark Hatle <[email protected]>--- meta/classes/package.bbclass | 2 ++ 1 file changed, 2 insertions(+)meta/classes/package.bbclass +0
-0
meta/classes/package.bbclass python emit_pkgdata() { · line 1130
Quoted 7 lines
meta/classes/package.bbclass +2
-0@@ -1124,6 +1124,8 @@ python emit_pkgdata() { data_file = pkgdatadir + d.expand("/${PN}" ) f = open(data_file, 'w') + f.write("S: %s\n" % d.expand("${S}")) + f.write("B: %s\n" % d.expand("${B}")) f.write("PACKAGES: %s\n" % packages) f.close()
how does this interact with sstate? does setscene task create pkgdata with right paths?
Signature · 1 line
Martin 'JaMa' Jansa jabber: [email protected]
Re: [PATCH 2/21] Add directory information to the pkgdata files
Quoted 16 lines · Martin Jansa
Quoted 15 lines · Mark Hatle
Add S(ource) and B(uild) directory information to the recipe pkgdata files. This allows external tools to find the appropriate information, and be able to easily access the corresponding sources and build directories.
Signed-off-by Mark Hatle <[email protected]>--- meta/classes/package.bbclass | 2 ++ 1 file changed, 2 insertions(+)meta/classes/package.bbclass +0
-0@@ -1124,6 +1124,8 @@ python emit_pkgdata() {
Quoted 10 lines
meta/classes/package.bbclass python emit_pkgdata() { · line 1130
Quoted 6 lines
meta/classes/package.bbclass +2
-0data_file = pkgdatadir + d.expand("/${PN}" ) f = open(data_file, 'w') + f.write("S: %s\n" % d.expand("${S}")) + f.write("B: %s\n" % d.expand("${B}")) f.write("PACKAGES: %s\n" % packages) f.close()how does this interact with sstate? does setscene task create pkgdata with right paths?
The pkgdata is always current to the current build/work directory. When the sstate-cache runs, and the associated pkgdata is dumped to the disk the S and B for the current directory is written. But when sstate-cache is used, there is no extracted source (or build) components so those directories remain unresolved.
It's up to the tooling that are using these files to check if the directory exists, if it does not -- then using bitbake -c patch <recipe> will create it. (even in the sstate-cache case.)
--Mark
Re: [PATCH 2/21] Add directory information to the pkgdata files
Quoted 5 lines · Mark Hatle
Quoted 4 lines · Martin Jansa
Quoted 2 lines · Mark Hatle
Add S(ource) and B(uild) directory information to the recipe pkgdata
files.
Quoted 1 line
Quoted 1 line
Quoted 1 line
This allows external tools to find the appropriate information, and be
able
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
to easily access the corresponding sources and build directories.
Signed-off-by Mark Hatle <[email protected]>
Hi Mark
This won't work well when package is populated from sstate is there a way for it to work seamlessly across sstate it might be useful
Quoted 21 lines
Quoted 10 lines
Quoted 10 lines
--- meta/classes/package.bbclass | 2 ++ 1 file changed, 2 insertions(+)meta/classes/package.bbclass +0
-0@@ -1124,6 +1124,8 @@ python emit_pkgdata() {Quoted 10 lines
meta/classes/package.bbclass python emit_pkgdata() { · line 1130
Quoted 6 lines
meta/classes/package.bbclass +2
-0data_file = pkgdatadir + d.expand("/${PN}" ) f = open(data_file, 'w') + f.write("S: %s\n" % d.expand("${S}")) + f.write("B: %s\n" % d.expand("${B}")) f.write("PACKAGES: %s\n" % packages) f.close()how does this interact with sstate? does setscene task create pkgdata with right paths?
Quoted 1 line
The pkgdata is always current to the current build/work directory. When
the sstate-cache runs, and the associated pkgdata is dumped to the disk the S and B for the current directory is written. But when sstate-cache is used, there is no extracted source (or build) components so those directories remain unresolved.
Quoted 2 lines
It's up to the tooling that are using these files to check if the
directory exists, if it does not -- then using bitbake -c patch <recipe> will create it. (even in the sstate-cache case.)
Quoted 7 lines
--Mark
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [PATCH 2/21] Add directory information to the pkgdata files
In reply to Mark HatleQuoted 3 lines · Mark Hatle
It's up to the tooling that are using these files to check if the directory exists, if it does not -- then using bitbake -c patch <recipe> will create it. (even in the sstate-cache case.)
I'm not sure whether checking that the directory exists is all that safe; in the shared-sstate scenario I think it's conceivable that the directory might exist but contain something else, or be unreadable due to permissions, or disappear underneath you while you're using it.
And, of course, "bitbake -c patch ..." won't necessarily create the same ${S} that you got from pkgdata in that case, it will create it in your local TMPDIR.
Also, the subject line for this patch (and several others from the batch you just sent) is not in the right format. Please see the guidelines on the wiki.
p.
Re: [PATCH 2/21] Add directory information to the pkgdata files
Quoted 13 lines · Phil Blundell
Quoted 3 lines · Mark Hatle
It's up to the tooling that are using these files to check if the directory exists, if it does not -- then using bitbake -c patch <recipe> will create it. (even in the sstate-cache case.)
I'm not sure whether checking that the directory exists is all that safe; in the shared-sstate scenario I think it's conceivable that the directory might exist but contain something else, or be unreadable due to permissions, or disappear underneath you while you're using it.
And, of course, "bitbake -c patch ..." won't necessarily create the same ${S} that you got from pkgdata in that case, it will create it in your local TMPDIR.
Quoted 4 lines · Khem Raj
Hi Mark
This won't work well when package is populated from sstate is there a way for it to work seamlessly across sstate it might be useful
I was looking at this again. I thought the pkgdata was reconstructed each time in the current TMPDIR. I didn't realize it was just restored from the sstate-cache. (We've got other patches in layers that trigger pkgdata-like files to be generated as well.. and I must have gotten the two confused.)
So yes, I understand now that this won't work properly as the embedded path is outside of the TMPDIR. The intention was that the path would change to match the current build directories TMPDIR. And due to the magic of the sstate-cache checksumming, running the do_patch should result in the same sources...
So -if- others thought this was useful, I'll fix the patch to change the S/B on the sstate setup to the proper TMPDIR locations. But so far I'm not hearing anyone who wants this -- so I'll just keep it local.
Quoted 3 lines
Also, the subject line for this patch (and several others from the batch you just sent) is not in the right format. Please see the guidelines on the wiki.
I missed that, I'll correct the commits summary lines and resubmit them.
Drop 2/21
Fixup 9, 15, & 18
Did I miss any?
--Mark
Quoted 3 lines
p.
Re: [PATCH 2/21] Add directory information to the pkgdata files
Quoted 19 lines · On Wednesday 29 May 2013 15:44:58 Mark Hatle wrote:
Quoted 14 lines · Phil Blundell
Quoted 4 lines · Mark Hatle
It's up to the tooling that are using these files to check if the directory
exists, if it does not -- then using bitbake -c patch <recipe> will create it. (even in the sstate-cache case.)I'm not sure whether checking that the directory exists is all that safe; in the shared-sstate scenario I think it's conceivable that the directory might exist but contain something else, or be unreadable due to permissions, or disappear underneath you while you're using it.
And, of course, "bitbake -c patch ..." won't necessarily create the same ${S} that you got from pkgdata in that case, it will create it in your local TMPDIR.
Quoted 2 lines · Khem Raj
Hi Mark
Quoted 7 lines
Quoted 2 lines
This won't work well when package is populated from sstate is there a way for it to work seamlessly across sstate it might be useful
I was looking at this again. I thought the pkgdata was reconstructed each time in the current TMPDIR. I didn't realize it was just restored from the sstate-cache. (We've got other patches in layers that trigger pkgdata-like files to be generated as well.. and I must have gotten the two confused.)
I think this is new behaviour for 1.4, so that might explain some of the confusion. Previously the pkgdata generation happened in do_package, but now that do_rootfs and other places rely upon the presence of pkgdata, it is now a separate task so it can be accelerated by sstate and do_package doesn't need to be re-run.
Cheers,
Paul
Signature · 2 lines
Paul Eggleton Intel Open Source Technology Centre
Re: [PATCH 2/21] Add directory information to the pkgdata files
Quoted 28 lines · Paul Eggleton
Quoted 19 lines · On Wednesday 29 May 2013 15:44:58 Mark Hatle wrote:
Quoted 14 lines · Phil Blundell
Quoted 4 lines · Mark Hatle
It's up to the tooling that are using these files to check if the directory
exists, if it does not -- then using bitbake -c patch <recipe> will create it. (even in the sstate-cache case.)I'm not sure whether checking that the directory exists is all that safe; in the shared-sstate scenario I think it's conceivable that the directory might exist but contain something else, or be unreadable due to permissions, or disappear underneath you while you're using it.
And, of course, "bitbake -c patch ..." won't necessarily create the same ${S} that you got from pkgdata in that case, it will create it in your local TMPDIR.
Quoted 2 lines · Khem Raj
Hi Mark
Quoted 7 lines
Quoted 2 lines
This won't work well when package is populated from sstate is there a way for it to work seamlessly across sstate it might be useful
I was looking at this again. I thought the pkgdata was reconstructed each time in the current TMPDIR. I didn't realize it was just restored from the sstate-cache. (We've got other patches in layers that trigger pkgdata-like files to be generated as well.. and I must have gotten the two confused.)
Quoted 5 lines
I think this is new behaviour for 1.4, so that might explain some of the confusion. Previously the pkgdata generation happened in
do_package, but now thatdo_rootfsand other places rely upon the presence of pkgdata, it is now a separate task so it can be accelerated by sstate anddo_packagedoesn't need to be re-run.
It moved from do_package to do_packagedata (or whatever its called) in 1.4 for performance reasons but it has always been installed from the sstate cache since the beginning of sstate.
Cheers,
Richard
PATCH 3/21 cmake.bbclass: modify construction of compiler flags
In reply to Mark HatleFrom: Joe Slater <[email protected]>
Use CFLAGS instead of CPPFLAGS for C_FLAGS variants.
When debug optimization is enabled in the local.conf, the debug (-O0) vs production (-O2) does not change in the builds. As the CPPFLAGS do not contain the optimization settings.
Also the CXX_FLAGS are based on CXXFLAGS, so it makes sense to similarly set the C_FLAGS based on CFLAGS.
--- meta/classes/cmake.bbclass | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
meta/classes/cmake.bbclass +2 -2
@@ -20,9 +20,9 @@ OECMAKE_C_COMPILER ?= "`echo ${CC} | sed 's/^\([^ ]*\).*/\1/'`" OECMAKE_CXX_COMPILER ?= "`echo ${CXX} | sed 's/^\([^ ]*\).*/\1/'`" # Compiler flags -OECMAKE_C_FLAGS ?= "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS} ${CPPFLAGS}" +OECMAKE_C_FLAGS ?= "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS} ${CFLAGS}" OECMAKE_CXX_FLAGS ?= "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS} ${CXXFLAGS} -fpermissive" -OECMAKE_C_FLAGS_RELEASE ?= "${SELECTED_OPTIMIZATION} ${CPPFLAGS} -DNDEBUG" +OECMAKE_C_FLAGS_RELEASE ?= "${SELECTED_OPTIMIZATION} ${CFLAGS} -DNDEBUG" OECMAKE_CXX_FLAGS_RELEASE ?= "${SELECTED_OPTIMIZATION} ${CXXFLAGS} -DNDEBUG" OECMAKE_C_LINK_FLAGS ?= "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS} ${CPPFLAGS} ${LDFLAGS}" OECMAKE_CXX_LINK_FLAGS ?= "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS} ${CXXFLAGS} ${LDFLAGS}"
Signature · 1 line
1.8.1.2.545.g2f19ada
PATCH 4/21 acpid: modify CFLAGS
In reply to Mark HatleFrom: Joe Slater <[email protected]>
Override the hard-coded CFLAGS used in Makefile to reference our CFLAGS.
Without this patch if the DEBUG_OPTIMIZATION is enabled (using -O0) the compile log shows acpid still using -O2 because the Makefile has various hard coded CFLAGS defined. Instead of using the hard coded CFLAGS, we simply define the proper set within the recipe itself.
--- meta/recipes-bsp/acpid/acpid.inc | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
meta/recipes-bsp/acpid/acpid.inc +3 -1
@@ -13,7 +13,9 @@ inherit update-rc.d INITSCRIPT_NAME = "acpid" INITSCRIPT_PARAMS = "defaults" -EXTRA_OEMAKE = "" +# Makefile ignores our CFLAGS, so override it. +# +EXTRA_OEMAKE = "CFLAGS='-W -Wall -Werror -Wundef -Wshadow ${CFLAGS} $(DEFS)'" do_compile () { oe_runmake 'CC=${CC} -D_GNU_SOURCE' 'CROSS=${HOST_PREFIX}'
Signature · 1 line
1.8.1.2.545.g2f19ada
PATCH 5/21 libpam: Avoid wildcards in the SRC_URI
In reply to Mark HatleRemove the wildcard from the SRC_URI. This causes problems when you .bbappend and add a FILESEXTRAPATHS entry. The unpack task may be unable to find the files to unpack leading to an error.
Avoid wildcards at all costs...
--- meta/recipes-extended/pam/libpam_1.1.6.bb | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
meta/recipes-extended/pam/libpam_1.1.6.bb +6 -1
@@ -11,7 +11,12 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=7eb5c1bf854e8881005d673599ee74d3" SRC_URI = "http://linux-pam.org/library/Linux-PAM-${PV}.tar.bz2 \ file://99_pam \ - file://pam.d/* \ + file://pam.d/common-account \ + file://pam.d/common-auth \ + file://pam.d/common-password \ + file://pam.d/common-session \ + file://pam.d/common-session-noninteractive \ + file://pam.d/other \ file://libpam-xtests.patch \ file://destdirfix.patch \ file://fixsepbuild.patch \
Signature · 1 line
1.8.1.2.545.g2f19ada
PATCH 6/21 util-linux: Add ability to compile with nativesdk
In reply to Mark HatleFrom: Jason Wessel <[email protected]>
Some of the tools in the util-linux are used for disk and text file operations in the nativesdk so as to get around different versions that may exist on the host system.
--- meta/recipes-core/util-linux/util-linux.inc | 5 ++++- meta/recipes-core/util-linux/util-linux_2.23.bb | 1 + 2 files changed, 5 insertions(+), 1 deletion(-)
meta/recipes-core/util-linux/util-linux.inc +4 -1
@@ -20,6 +20,7 @@ LIC_FILES_CHKSUM = "file://README.licensing;md5=679af3e410ee112a5ec94de6501bf5c3 inherit autotools gettext pkgconfig systemd DEPENDS = "zlib ncurses" DEPENDS_append_class-native = " lzo-native" +DEPENDS_append_class-nativesdk = " lzo-native" SRC_URI = "${KERNELORG_MIRROR}/linux/utils/util-linux/v${MAJOR_VERSION}/util-linux-${PV}.tar.bz2 \ file://MCONFIG \
@@ -94,7 +95,9 @@ RDEPENDS_${PN} = "util-linux-umount util-linux-swaponoff util-linux-losetup" RRECOMMENDS_${PN} = "util-linux-fdisk util-linux-cfdisk util-linux-sfdisk util-linux-mount util-linux-readprofile util-linux-mkfs " RRECOMMENDS_${PN}_class-native = "" +RRECOMMENDS_${PN}_class-nativesdk = "" RDEPENDS_${PN}_class-native = "" +RDEPENDS_${PN}_class-nativesdk = "" SYSTEMD_PACKAGES = "${PN}-uuidd" SYSTEMD_SERVICE_${PN}-uuidd = "uuidd.service"
@@ -214,4 +217,4 @@ ALTERNATIVE_util-linux-reset = "reset" ALTERNATIVE_LINK_NAME[reset] = "${bindir}/reset" ALTERNATIVE_TARGET[reset] = "${base_bindir}/reset" -BBCLASSEXTEND = "native" +BBCLASSEXTEND = "native nativesdk"
meta/recipes-core/util-linux/util-linux_2.23.bb +1 -0
@@ -16,3 +16,4 @@ SRC_URI[sha256sum] = "19ee024b4c6678eaa928d38edc011c332b088e0ff06239575f6b7e00a1 CACHED_CONFIGUREVARS += "scanf_cv_alloc_modifier=as" EXTRA_OECONF_class-native += "--disable-fallocate --disable-use-tty-group" +EXTRA_OECONF_class-nativesdk += "--disable-fallocate --disable-use-tty-group"
Signature · 1 line
1.8.1.2.545.g2f19ada
PATCH 7/21 dbus-glib: use BPN instead of PN
In reply to Mark HatleFrom: Jesse Zhang <[email protected]>
Fix warnings in multilib build:
WARNING: For recipe lib32-dbus-glib, the following files/directories were installed but not shipped in any package:
WARNING: /usr/share/dbus-glib
WARNING: /usr/share/dbus-glib/tests
--- meta/recipes-core/dbus/dbus-glib.inc | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
meta/recipes-core/dbus/dbus-glib.inc +4 -4
@@ -36,9 +36,9 @@ FILES_${PN}-dev += "${libdir}/dbus-1.0/include ${bindir}/dbus-glib-tool" FILES_${PN}-dev += "${bindir}/dbus-binding-tool" RDEPENDS_${PN}-tests += "dbus-x11" -FILES_${PN}-tests = "${datadir}/${PN}/tests" -FILES_${PN}-tests-dbg = "${datadir}/${PN}/tests/.debug/* \ - ${datadir}/${PN}/tests/core/.debug/* \ - ${datadir}/${PN}/tests/interfaces/.debug/*" +FILES_${PN}-tests = "${datadir}/${BPN}/tests" +FILES_${PN}-tests-dbg = "${datadir}/${BPN}/tests/.debug/* \ + ${datadir}/${BPN}/tests/core/.debug/* \ + ${datadir}/${BPN}/tests/interfaces/.debug/*" BBCLASSEXTEND = "native"
Signature · 1 line
1.8.1.2.545.g2f19ada
PATCH 8/21 initscripts: let status return 0 when proc is running well
In reply to Mark HatleFrom: Jesse Zhang <[email protected]>
Ensure that the status returns 0 instead of the last shell command result, otherwise the calling script can not properly detect the status of pid.
--- meta/recipes-core/initscripts/initscripts-1.0/functions | 1 + 1 file changed, 1 insertion(+)
meta/recipes-core/initscripts/initscripts-1.0/functions +1 -0
@@ -52,6 +52,7 @@ status() { pid=`pidofproc $1` if [ -n "$pid" ]; then echo "$1 (pid $pid) is running..." + return 0 else echo "$1 is stopped" fi
Signature · 1 line
1.8.1.2.545.g2f19ada
PATCH 9/21 pull ldlinux.sys and isolinux.bin from correct places
In reply to Mark HatleFrom: Joe Slater <[email protected]>
ldlinux.sys is used when building an hdd image, and isolinux.bin when building an iso bootimage. In both cases, we want to look in the sysroot for MACHINE, not in the one for the multilib we might be using.
--- meta/classes/syslinux.bbclass | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
meta/classes/syslinux.bbclass +6 -4
@@ -38,11 +38,13 @@ syslinux_populate() { install -m 0644 ${SYSLINUXCFG} ${DEST}${BOOTDIR}/${CFGNAME} } +# we want to pull isolinux.bin and ldlinux.sys from the MACHINE sysroot +# syslinux_iso_populate() { syslinux_populate ${ISODIR} ${ISOLINUXDIR} isolinux.cfg - install -m 0644 ${STAGING_DATADIR}/syslinux/isolinux.bin ${ISODIR}${ISOLINUXDIR} + install -m 0644 ${STAGING_DIR}/${MACHINE}/${libdir}/syslinux/isolinux.bin ${ISODIR}${ISOLINUXDIR} if [ "${AUTO_SYSLINUXMENU}" = 1 ] ; then - install -m 0644 ${STAGING_DATADIR}/syslinux/vesamenu.c32 ${ISODIR}${ISOLINUXDIR}/vesamenu.c32 + install -m 0644 ${STAGING_DIR}/${MACHINE}/${libdir}/syslinux/vesamenu.c32 ${ISODIR}${ISOLINUXDIR}/vesamenu.c32 if [ "${SYSLINUX_SPLASH}" != "" ] ; then install -m 0644 ${SYSLINUX_SPLASH} ${ISODIR}${ISOLINUXDIR}/splash.lss fi
@@ -51,9 +53,9 @@ syslinux_iso_populate() { syslinux_hddimg_populate() { syslinux_populate ${HDDDIR} ${SYSLINUXDIR} syslinux.cfg - install -m 0444 ${STAGING_DATADIR}/syslinux/ldlinux.sys ${HDDDIR}${SYSLINUXDIR}/ldlinux.sys + install -m 0444 ${STAGING_DIR}/${MACHINE}/${libdir}/syslinux/ldlinux.sys ${HDDDIR}${SYSLINUXDIR}/ldlinux.sys if [ "${AUTO_SYSLINUXMENU}" = 1 ] ; then - install -m 0644 ${STAGING_DATADIR}/syslinux/vesamenu.c32 ${HDDDIR}${SYSLINUXDIR}/vesamenu.c32 + install -m 0644 ${STAGING_DIR}/${MACHINE}/${libdir}/syslinux/vesamenu.c32 ${ISODIR}${ISOLINUXDIR}/vesamenu.c32 if [ "${SYSLINUX_SPLASH}" != "" ] ; then install -m 0644 ${SYSLINUX_SPLASH} ${HDDDIR}${SYSLINUXDIR}/splash.lss fi
Signature · 1 line
1.8.1.2.545.g2f19ada
PATCH 10/21 ncurses, busybox, cml1.bbclass: Fix menuconfig display corruption
In reply to Mark HatleFrom: Jason Wessel <[email protected]>
Previously there was a change to the ncurses compile to make it more like the typical way it was compiled on a host system. This fixed a whole class of host machines, but masked the real underlying problem with the display corruption issues and menuconfig.
The corner case that led to the discovery that the wrong curses.h file was getting used was when there was no curses libraries at all on one of the development hosts. What had happened before was that /usr/include/curses.h on the host system had to match closely enough to the curses.h in the sysroot and then linking against the sysroot version of curses.so was ok (meaning no display corruption). But on some systems with ncurses.h vs curses.h such as SuSE hosts, there were still issues.
If we fix the root of the problem and force the mconf and lxdialog to use the correct headers and libraries from the sysroot there is no further issues and the menuconfig target works properly. It also means we can back out the custom compilation flags to the ncurses recipe because they are no longer needed.
For the kernel part of the menuconfig / nconfig changes it will be merged separately and this is all based on:
https://lkml.org/lkml/2013/3/3/103
--- meta/classes/cml1.bbclass | 5 +- .../busybox-1.20.2/busybox-cross-menuconfig.patch | 69 ++++++++++++++++++++++ meta/recipes-core/busybox/busybox_1.20.2.bb | 3 +- meta/recipes-core/ncurses/ncurses.inc | 14 ----- 4 files changed, 74 insertions(+), 17 deletions(-) create mode 100644 meta/recipes-core/busybox/busybox-1.20.2/busybox-cross-menuconfig.patch
meta/classes/cml1.bbclass +3 -2
@@ -9,10 +9,11 @@ addtask configure after do_unpack do_patch before do_compile inherit terminal -OE_TERMINAL_EXPORTS += "HOST_EXTRACFLAGS HOSTLDFLAGS HOST_LOADLIBES TERMINFO" +OE_TERMINAL_EXPORTS += "HOST_EXTRACFLAGS HOSTLDFLAGS TERMINFO CROSS_CURSES_LIB CROSS_CURSES_INC" HOST_EXTRACFLAGS = "${BUILD_CFLAGS} ${BUILD_LDFLAGS}" HOSTLDFLAGS = "${BUILD_LDFLAGS}" -HOST_LOADLIBES = "-lncurses" +CROSS_CURSES_LIB = "-lncurses -ltinfo" +CROSS_CURSES_INC = '-DCURSES_LOC="<curses.h>"' TERMINFO = "${STAGING_DATADIR_NATIVE}/terminfo" python do_menuconfig() {
meta/recipes-core/busybox/busybox-1.20.2/busybox-cross-menuconfig.patch new file +69 -0
69 lines not on this page · raw message
meta/recipes-core/busybox/busybox_1.20.2.bb +2 -1
@@ -35,7 +35,8 @@ SRC_URI = "http://www.busybox.net/downloads/busybox-${PV}.tar.bz2;name=tarball \ file://fail_on_no_media.patch \ file://busybox-sulogin-empty-root-password.patch \ file://inetd.conf \ - file://inetd" + file://inetd \ + file://busybox-cross-menuconfig.patch" SRC_URI[tarball.md5sum] = "e025414bc6cd79579cc7a32a45d3ae1c" SRC_URI[tarball.sha256sum] = "eb13ff01dae5618ead2ef6f92ba879e9e0390f9583bd545d8789d27cf39b6882"
meta/recipes-core/ncurses/ncurses.inc +0 -14
@@ -29,19 +29,6 @@ BUILD_CPPFLAGS += "-D_GNU_SOURCE" # natives don't generally look in base_libdir base_libdir_class-native = "${libdir}" -# Display corruption occurs on 64 bit hosts without these settings -# This was derrived from the upstream debian ncurses which uses -# these settings for 32 and 64 bit hosts. -EXCONFIG_ARGS = "" -EXCONFIG_ARGS_virtclass-native = " \ - --disable-lp64 \ - --with-chtype='long' \ - --with-mmask-t='long'" -EXCONFIG_ARGS_virtclass-nativesdk = " \ - --disable-lp64 \ - --with-chtype='long' \ - --with-mmask-t='long'" - # Fall back to the host termcap / terminfo for -nativesdk and -native # The reality is a work around for strange problems with things like # "bitbake -c menuconfig busybox" where it cannot find the terminfo
@@ -79,7 +66,6 @@ ncurses_configure() { --enable-sigwinch \ --enable-pc-files \ --disable-rpath-hack \ - ${EXCONFIG_ARGS} \ --with-manpage-format=normal \ "$@" || return 1 cd ..
Signature · 1 line
1.8.1.2.545.g2f19ada
Re: [PATCH 10/21] ncurses, busybox, cml1.bbclass: Fix menuconfig display corruption
Quoted 27 lines · Mark Hatle
From: Jason Wessel <[email protected]>
Previously there was a change to the ncurses compile to make it more like the typical way it was compiled on a host system. This fixed a whole class of host machines, but masked the real underlying problem with the display corruption issues and menuconfig.
The corner case that led to the discovery that the wrong
curses.hfile was getting used was when there was no curses libraries at all on one of the development hosts. What had happened before was that/usr/include/curses.hon the host system had to match closely enough to thecurses.hin the sysroot and then linking against the sysroot version of curses.so was ok (meaning no display corruption). But on some systems withncurses.hvscurses.hsuch as SuSE hosts, there were still issues.If we fix the root of the problem and force the mconf and lxdialog to use the correct headers and libraries from the sysroot there is no further issues and the menuconfig target works properly. It also means we can back out the custom compilation flags to the ncurses recipe because they are no longer needed.
For the kernel part of the menuconfig / nconfig changes it will be merged separately and this is all based on:
Quoted 8 lines
Signed-off-by Jason Wessel <[email protected]>--- meta/classes/cml1.bbclass | 5 +- .../busybox-1.20.2/busybox-cross-menuconfig.patch | 69 ++++++++++++++++++++++ meta/recipes-core/busybox/busybox_1.20.2.bb | 3 +- meta/recipes-core/ncurses/ncurses.inc | 14 ----- 4 files changed, 74 insertions(+), 17 deletions(-) create mode 100644 meta/recipes-core/busybox/busybox-1.20.2/busybox-cross-menuconfig.patch
Jason asked us to hold off merging this until things were sorted out in the mainline kernel. Has that happened?
Cheers,
Richard
PATCH 11/21 guile: don't search for libreadline in host libdir
In reply to Mark HatleFrom: Jackie Huang <[email protected]>
Fix the QA warning:
WARNING: guile: The compile log indicates that host include and/or library paths were used.
--- meta/recipes-devtools/guile/guile_2.0.9.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
meta/recipes-devtools/guile/guile_2.0.9.bb +1 -1
@@ -36,7 +36,7 @@ DEPENDS = "libunistring bdwgc gmp libtool libffi" # add guile-native only to the target recipe's DEPENDS DEPENDS += "${@['guile-native libatomics-ops', ''][d.getVar('PN', True) != 'guile']}" -EXTRA_OECONF += "${@['--without-libltdl-prefix --without-libgmp-prefix', ''][bb.data.inherits_class('native',d)]}" +EXTRA_OECONF += "${@['--without-libltdl-prefix --without-libgmp-prefix --without-libreadline-prefix', ''][bb.data.inherits_class('native',d)]}" do_configure_prepend() { mkdir -p po
Signature · 1 line
1.8.1.2.545.g2f19ada
PATCH 12/21 dpkg-native: Fix native perl path
In reply to Mark HatleFrom: Ming Liu <[email protected]>
The path to the native perl was incorrect leading to rootfs failures. This patch corrects that problem, it's a complementary fix for commit:04432446.
--- meta/recipes-devtools/dpkg/dpkg.inc | 3 +++ 1 file changed, 3 insertions(+)
meta/recipes-devtools/dpkg/dpkg.inc +3 -0
@@ -18,6 +18,9 @@ PARALLEL_MAKE = "" inherit autotools gettext perlnative pkgconfig +export PERL = "${bindir}/perl" +PERL_class-native = "${STAGING_BINDIR_NATIVE}/perl-native/perl" + export PERL_LIBDIR = "${libdir}/perl" PERL_LIBDIR_class-native = "${libdir}/perl-native/perl"
Signature · 1 line
1.8.1.2.545.g2f19ada
PATCH 13/21 qmake_base.bbclass:add linux-gnun32-oe-g++ to QMAKESPEC
In reply to Mark HatleFrom: Xin Ouyang <[email protected]>
For some mips targets, TARGET_OS is set to linux-gnun32, while linux-gnun32-oe-g++ is not listed in the default QMAKESPEC list of qmake in oe-core/wrlinux. This would cause build failures for qt apps, so add a matching rule to fix this.
--- meta/classes/qmake_base.bbclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
meta/classes/qmake_base.bbclass +1 -1
@@ -48,7 +48,7 @@ addtask generate_qt_config_file after do_patch before do_configure qmake_base_do_configure() { case ${QMAKESPEC} in - *linux-oe-g++|*linux-uclibc-oe-g++|*linux-gnueabi-oe-g++|*linux-uclibceabi-oe-g++|*linux-gnuspe-oe-g++|*linux-uclibcspe-oe-g++) + *linux-oe-g++|*linux-uclibc-oe-g++|*linux-gnueabi-oe-g++|*linux-uclibceabi-oe-g++|*linux-gnuspe-oe-g++|*linux-uclibcspe-oe-g++|*linux-gnun32-oe-g++) ;; *-oe-g++) die Unsupported target ${TARGET_OS} for oe-g++ qmake spec
Signature · 1 line
1.8.1.2.545.g2f19ada
PATCH 14/21 portmap: /etc/init.d/portmap restart complains "command not found"
In reply to Mark HatleFrom: Amy Fong <[email protected]>
portmap splits pmap_dump and pmap_set into a different package:portmap_utils. Since this package might not be installed, I introduce another init file that tests for the existance of these apps before trying to run the pmap_* commands.
--- meta/recipes-connectivity/portmap/portmap/portmap.init | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-)
meta/recipes-connectivity/portmap/portmap/portmap.init +13 -5
@@ -40,14 +40,22 @@ case "$1" in $0 restart ;; restart) - pmap_dump >/var/run/portmap.state + # pmap_dump and pmap_set may be in a different package and not installed... + if [ -f /sbin/pmap_dump -a -f /sbin/pmap_set ]; then + do_state=1 + else + do_state=0 + fi + [ $do_state -eq 1 ] && pmap_dump >/var/run/portmap.state $0 stop $0 start - if [ ! -f /var/run/portmap.upgrade-state ]; then - sleep 1 - pmap_set </var/run/portmap.state + if [ $do_state -eq 1 ]; then + if [ ! -f /var/run/portmap.upgrade-state ]; then + sleep 1 + pmap_set </var/run/portmap.state + fi + rm -f /var/run/portmap.state fi - rm -f /var/run/portmap.state ;; *) echo "Usage: /etc/init.d/portmap {start|stop|reload|restart}"
Signature · 1 line
1.8.1.2.545.g2f19ada
PATCH 15/21 fix libnl two parentheses bugs in lib/cache_mngr.c file
In reply to Mark HatleFrom: "Song.Li" <[email protected]>
there are two parentheses bugs in libnl /lib/cache_mngr.c file. The parentheses doesn't make any sense,
This will cause the variable err get a bool value, the correct value of variable err should be the return value of the function which can be any integer value.
--- ...fix-lib-cache_mngr.c-two-parentheses-bugs.patch | 37 ++++++++++++++++++++++ meta/recipes-support/libnl/libnl_3.2.22.bb | 3 +- 2 files changed, 39 insertions(+), 1 deletion(-) create mode 100644 meta/recipes-support/libnl/libnl/fix-lib-cache_mngr.c-two-parentheses-bugs.patch
meta/recipes-support/libnl/libnl/fix-lib-cache_mngr.c-two-parentheses-bugs.patch new file +37 -0
@@ -0,0 +1,37 @@ +From 82fdf49c185fd5f3810781af9ef52aa6a52bf2df Mon Sep 17 00:00:00 2001 +From: "Song.Li" <[email protected]> +Date: Thu, 28 Jun 2012 20:03:17 +0800 +Subject: [PATCH] fix lib/cache_mngr.c two parentheses bugs + +there are two parentheses bugs in libnl /lib/cache_mngr.c file. +The parentheses doesn't make any sense, +This will cause the variable err get a bool value, +the correct value of variable err should be the return value +of the function which can be any integer value. + +--- + lib/cache_mngr.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +Upstream-status: Pending + +diff --git a/lib/cache_mngr.c b/lib/cache_mngr.c +index dae8768..57cc1f9 100644 +--- a/lib/cache_mngr.c ++++ b/lib/cache_mngr.c +@@ -150,10 +150,10 @@ int nl_cache_mngr_alloc(struct nl_sock *sk, int protocol, int flags, + /* Required to receive async event notifications */ + nl_socket_disable_seq_check(mngr->cm_sock); + +- if ((err = nl_connect(mngr->cm_sock, protocol) < 0)) ++ if ((err = nl_connect(mngr->cm_sock, protocol)) < 0) + goto errout; + +- if ((err = nl_socket_set_nonblocking(mngr->cm_sock) < 0)) ++ if ((err = nl_socket_set_nonblocking(mngr->cm_sock)) < 0) + goto errout; + + NL_DBG(1, "Allocated cache manager %p, protocol %d, %d caches\n", +-- +1.7.9.5 +
meta/recipes-support/libnl/libnl_3.2.22.bb +2 -1
@@ -11,7 +11,8 @@ DEPENDS = "flex-native bison-native" SRC_URI = "http://www.infradead.org/~tgr/${BPN}/files/${BP}.tar.gz \ file://fix-pktloc_syntax_h-race.patch \ - file://fix-pc-file.patch " + file://fix-pc-file.patch \ + file://fix-lib-cache_mngr.c-two-parentheses-bugs.patch" SRC_URI[md5sum] = "2e1c889494d274aca24ce5f6a748e66e" SRC_URI[sha256sum] = "c7c5f267dfeae0c1a530bf96b71fb7c8dbbb07d54beef49b6712d8d6166f629b"
Signature · 1 line
1.8.1.2.545.g2f19ada
PATCH 16/21 bind: add ipv6 support
In reply to Mark HatleFrom: Li Wang <[email protected]>
Make ipv6 configure dependent on DISTRO_FEATURES.
--- meta/recipes-connectivity/bind/bind_9.8.1.bb | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
meta/recipes-connectivity/bind/bind_9.8.1.bb +2 -1
@@ -18,7 +18,8 @@ SRC_URI[md5sum] = "cf31117c5d35af34d4c0702970ad9fb7" SRC_URI[sha256sum] = "02285dc429cb2a6687a1b2446e9ee22c1df27f2577225b05be5092395ee7c92c" # --enable-exportlib is necessary for building dhcp -EXTRA_OECONF = " --enable-ipv6=no --with-randomdev=/dev/random --disable-threads \ +ENABLE_IPV6 = "--enable-ipv6=${@base_contains('DISTRO_FEATURES', 'ipv6', 'yes', 'no', d)}" +EXTRA_OECONF = " ${ENABLE_IPV6} --with-randomdev=/dev/random --disable-threads \ --disable-devpoll --disable-epoll --with-gost=no \ --with-gssapi=no \ --sysconfdir=${sysconfdir}/bind \
Signature · 1 line
1.8.1.2.545.g2f19ada
PATCH 17/21 grep: fix for CVE-2012-5667
In reply to Mark HatleFrom: Ming Liu <[email protected]>
Multiple integer overflows in GNU Grep before 2.11 might allow context-dependent attackers to execute arbitrary code via vectors involving a long input line that triggers a heap-based buffer overflow.
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-5667
--- .../grep/grep-2.5.1a/grep-CVE-2012-5667.patch | 28 ++++++++++++++++++++++ meta/recipes-extended/grep/grep_2.5.1a.bb | 3 ++- 2 files changed, 30 insertions(+), 1 deletion(-) create mode 100644 meta/recipes-extended/grep/grep-2.5.1a/grep-CVE-2012-5667.patch
meta/recipes-extended/grep/grep-2.5.1a/grep-CVE-2012-5667.patch new file +28 -0
@@ -0,0 +1,28 @@ +The patch to fix CVE-2012-5667 +Reference: https://bugzilla.redhat.com/attachment.cgi?id=686605&action=diff + +Multiple integer overflows in GNU Grep before 2.11 might allow +context-dependent attackers to execute arbitrary code via vectors +involving a long input line that triggers a heap-based buffer overflow. + +http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-5667 + +Signed-off-by Ming Liu <[email protected]> +--- + grep.c | 7 +++---- + 1 file changed, 3 insertions(+), 4 deletions(-) + +--- a/src/grep.c 2013-05-15 13:39:33.359191769 +0800 ++++ a/src/grep.c 2013-05-15 13:50:22.609191882 +0800 +@@ -306,6 +306,11 @@ fillbuf (size_t save, struct stats const + int cc = 1; + char *readbuf; + size_t readsize; ++ const size_t max_save = INT_MAX / 2; ++ ++ /* Limit the amount of saved data to INT_MAX to fix CVE-2012-5667 */ ++ if (save > max_save) ++ error (2, 0, _("line too long")); + + /* Offset from start of buffer to start of old stuff + that we want to save. */
meta/recipes-extended/grep/grep_2.5.1a.bb +2 -1
@@ -13,7 +13,8 @@ SRC_URI = "${GNU_MIRROR}/grep/grep-${PV}.tar.bz2 \ file://gettext.patch \ file://fix64-int-to-pointer.patch \ file://Makevars \ - " + file://grep-CVE-2012-5667.patch \ + " SRC_URI[md5sum] = "52202fe462770fa6be1bb667bd6cf30c" SRC_URI[sha256sum] = "38c8a2bb9223d1fb1b10bdd607cf44830afc92fd451ac4cd07619bf92bdd3132"
Signature · 1 line
1.8.1.2.545.g2f19ada
Re: [PATCH 17/21] grep: fix for CVE-2012-5667
Quoted 24 lines · Mark Hatle
From: Ming Liu <[email protected]>
Multiple integer overflows in GNU Grep before 2.11 might allow context-dependent attackers to execute arbitrary code via vectors involving a long input line that triggers a heap-based buffer overflow.
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-5667
Signed-off-by Ming Liu <[email protected]>--- .../grep/grep-2.5.1a/grep-CVE-2012-5667.patch | 28 ++++++++++++++++++++++ meta/recipes-extended/grep/grep_2.5.1a.bb | 3 ++- 2 files changed, 30 insertions(+), 1 deletion(-) create mode 100644 meta/recipes-extended/grep/grep-2.5.1a/grep-CVE-2012-5667.patchmeta/recipes-extended/grep/grep-2.5.1a/grep-CVE-2012-5667.patch new file +3
-0@@ -0,0 +1,28 @@ +The patch to fix CVE-2012-5667 +Reference: https://bugzilla.redhat.com/attachment.cgi?id=686605&action=diff +
meta/recipes-extended/grep/grep-2.5.1a/grep-CVE-2012-5667.patch line 13
Quoted 10 lines
meta/recipes-extended/grep/grep-2.5.1a/grep-CVE-2012-5667.patch new file +10
-0+Multiple integer overflows in GNU Grep before 2.11 might allow +context-dependent attackers to execute arbitrary code via vectors +involving a long input line that triggers a heap-based buffer overflow. + +http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-5667 + +Signed-off-by Ming Liu <[email protected]> +--- + grep.c | 7 +++---- + 1 file changed, 3 insertions(+), 4 deletions(-)
This needs an Upstream-Status field (I know its clear when you read it but the scripts can't do that).
Cheers,
Richard
Quoted 28 lines
meta/recipes-extended/grep/grep-2.5.1a/grep-CVE-2012-5667.patch new file +14
-0+--- a/src/grep.c 2013-05-15 13:39:33.359191769 +0800 ++++ a/src/grep.c 2013-05-15 13:50:22.609191882 +0800 +@@ -306,6 +306,11 @@ fillbuf (size_t save, struct stats const + int cc = 1; + char *readbuf; + size_t readsize; ++ const size_t max_save = INT_MAX / 2; ++ ++ /* Limit the amount of saved data to INT_MAX to fix CVE-2012-5667 */ ++ if (save > max_save) ++ error (2, 0, _("line too long")); + + /* Offset from start of buffer to start of old stuff + that we want to save. */meta/recipes-extended/grep/grep_2.5.1a.bb +2
-1@@ -13,7 +13,8 @@ SRC_URI = "${GNU_MIRROR}/grep/grep-${PV}.tar.bz2 \ file://gettext.patch \ file://fix64-int-to-pointer.patch \ file://Makevars \ - " + file://grep-CVE-2012-5667.patch \ + " SRC_URI[md5sum] = "52202fe462770fa6be1bb667bd6cf30c" SRC_URI[sha256sum] = "38c8a2bb9223d1fb1b10bdd607cf44830afc92fd451ac4cd07619bf92bdd3132"
PATCH 18/21 Fix problems expanding the IMAGE_INSTALL package groups
In reply to Mark HatleFrom: Jason Wessel <[email protected]>
The ncurses package was generating the following error as a result of not specifing the PACKAGES_DYNAMIC correctly. This error only appear when using the IMAGE_INSTALL list that has been expanded by the hob or from the pkgdata.
ERROR: Nothing RPROVIDES 'ncurses-libtinfo'
--- meta/recipes-core/ncurses/ncurses.inc | 2 ++ 1 file changed, 2 insertions(+)
meta/recipes-core/ncurses/ncurses.inc +2 -0
@@ -29,6 +29,8 @@ BUILD_CPPFLAGS += "-D_GNU_SOURCE" # natives don't generally look in base_libdir base_libdir_class-native = "${libdir}" +PACKAGES_DYNAMIC = "^${PN}-.*" + # Fall back to the host termcap / terminfo for -nativesdk and -native # The reality is a work around for strange problems with things like # "bitbake -c menuconfig busybox" where it cannot find the terminfo
Signature · 1 line
1.8.1.2.545.g2f19ada
Re: [PATCH 18/21] Fix problems expanding the IMAGE_INSTALL package groups
Quoted 20 lines · Mark Hatle
From: Jason Wessel <[email protected]>
The ncurses package was generating the following error as a result of not specifing the
PACKAGES_DYNAMICcorrectly. This error only appear when using theIMAGE_INSTALLlist that has been expanded by the hob or from the pkgdata.ERROR: Nothing RPROVIDES 'ncurses-libtinfo'
Signed-off-by Jason Wessel <[email protected]>Signed-off-by Mark Hatle <[email protected]>--- meta/recipes-core/ncurses/ncurses.inc | 2 ++ 1 file changed, 2 insertions(+)meta/recipes-core/ncurses/ncurses.inc +0
-0
meta/recipes-core/ncurses/ncurses.inc BUILD_CPPFLAGS += "-D_GNU_SOURCE" · line 36
Quoted 8 lines
meta/recipes-core/ncurses/ncurses.inc +2
-0@@ -29,6 +29,8 @@ BUILD_CPPFLAGS += "-D_GNU_SOURCE" # natives don't generally look in base_libdir base_libdir_class-native = "${libdir}" +PACKAGES_DYNAMIC = "^${PN}-.*" + # Fall back to the host termcap / terminfo for -nativesdk and -native # The reality is a work around for strange problems with things like # "bitbake -c menuconfig busybox" where it cannot find the terminfo
I'm pretty sure I talked to Jason about this and we concluded this was fixed with some other change in master. Certainly this fix as it stands doesn't sound right.
Cheers,
Richard
Re: [PATCH 18/21] Fix problems expanding the IMAGE_INSTALL package groups
Quoted 24 lines · Richard Purdie
Quoted 23 lines · Mark Hatle
From: Jason Wessel <[email protected]>
The ncurses package was generating the following error as a result of not specifing the
PACKAGES_DYNAMICcorrectly. This error only appear when using theIMAGE_INSTALLlist that has been expanded by the hob or from the pkgdata.ERROR: Nothing RPROVIDES 'ncurses-libtinfo'
Signed-off-by Jason Wessel <[email protected]>Signed-off-by Mark Hatle <[email protected]>--- meta/recipes-core/ncurses/ncurses.inc | 2 ++ 1 file changed, 2 insertions(+)meta/recipes-core/ncurses/ncurses.inc +0
-0@@ -29,6 +29,8 @@ BUILD_CPPFLAGS += "-D_GNU_SOURCE" # natives don't generally look in base_libdir base_libdir_class-native = "${libdir}"
Quoted 9 lines
meta/recipes-core/ncurses/ncurses.inc BUILD_CPPFLAGS += "-D_GNU_SOURCE" · line 36
Quoted 5 lines
meta/recipes-core/ncurses/ncurses.inc +2
-0+PACKAGES_DYNAMIC = "^${PN}-.*" + # Fall back to the host termcap / terminfo for -nativesdk and -native # The reality is a work around for strange problems with things like # "bitbake -c menuconfig busybox" where it cannot find the terminfoI'm pretty sure I talked to Jason about this and we concluded this was fixed with some other change in master. Certainly this fix as it stands doesn't sound right.
The original thread included libpcre, it was libpcre side was in fact fixed prior to the initial patch being submitted. ncurses however is still broken.
If I revert this commit in my tree, and add to IMAGE_INSTALL "ncurses-libtinfo", I get the following failure:
NOTE: Resolving any missing task queue dependencies
ERROR: Nothing RPROVIDES 'ncurses-libtinfo' (but /msp-lpggp21/lmhatle/build-1/layers/oe-core/meta/recipes-core/images/core-image-minimal.bb RDEPENDS on or otherwise requires it)
NOTE: Runtime target 'ncurses-libtinfo' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['ncurses-libtinfo']
ERROR: Required build target 'core-image-minimal' has no buildable providers.
Missing or unbuildable dependency chain was: ['core-image-minimal', 'ncurses-libtinfo']
with the patch applied it completes successfully.
Reproducer:
Add to conf/local.conf
IMAGE_INSTALL_append = " ncurses-libtinfo"
bitbake core-image-minimal
Quoted 4 lines
Cheers,
Richard
Re: [PATCH 18/21] Fix problems expanding the IMAGE_INSTALL package groups
Quoted 53 lines · Mark Hatle
Quoted 24 lines · Richard Purdie
Quoted 23 lines · Mark Hatle
From: Jason Wessel <[email protected]>
The ncurses package was generating the following error as a result of not specifing the
PACKAGES_DYNAMICcorrectly. This error only appear when using theIMAGE_INSTALLlist that has been expanded by the hob or from the pkgdata.ERROR: Nothing RPROVIDES 'ncurses-libtinfo'
Signed-off-by Jason Wessel <[email protected]>Signed-off-by Mark Hatle <[email protected]>--- meta/recipes-core/ncurses/ncurses.inc | 2 ++ 1 file changed, 2 insertions(+)meta/recipes-core/ncurses/ncurses.inc +0
-0@@ -29,6 +29,8 @@ BUILD_CPPFLAGS += "-D_GNU_SOURCE" # natives don't generally look in base_libdir base_libdir_class-native = "${libdir}"Quoted 9 lines
meta/recipes-core/ncurses/ncurses.inc BUILD_CPPFLAGS += "-D_GNU_SOURCE" · line 36
Quoted 5 lines
meta/recipes-core/ncurses/ncurses.inc +2
-0+PACKAGES_DYNAMIC = "^${PN}-.*" + # Fall back to the host termcap / terminfo for -nativesdk and -native # The reality is a work around for strange problems with things like # "bitbake -c menuconfig busybox" where it cannot find the terminfoI'm pretty sure I talked to Jason about this and we concluded this was fixed with some other change in master. Certainly this fix as it stands doesn't sound right.
The original thread included libpcre, it was libpcre side was in fact fixed prior to the initial patch being submitted. ncurses however is still broken.
If I revert this commit in my tree, and add to
IMAGE_INSTALL"ncurses-libtinfo", I get the following failure:NOTE: Resolving any missing task queue dependencies
ERROR: Nothing RPROVIDES 'ncurses-libtinfo' (but /msp-lpggp21/lmhatle/build-1/layers/oe-core/meta/recipes-core/images/core-image-minimal.bb RDEPENDS on or otherwise requires it)
NOTE: Runtime target 'ncurses-libtinfo' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['ncurses-libtinfo']
ERROR: Required build target 'core-image-minimal' has no buildable providers. Missing or unbuildable dependency chain was: ['core-image-minimal', 'ncurses-libtinfo']with the patch applied it completes successfully.
Quoted 7 lines
Reproducer:
Add to
conf/local.conf
IMAGE_INSTALL_append= " ncurses-libtinfo"bitbake core-image-minimal
Fair enough. Can we at least match the pattern do_split_packages uses, i.e.:
PACKAGES_DYNAMIC = "^${PN}-lib.*"
I'm a little paranoid about adding wildcards like ${PN}-* as the potential for namespace problems is not insignificant, particularly if you know the horrible things bitbake does with this behind the scenes :/.
Cheers,
Richard
Re: [PATCH 18/21] Fix problems expanding the IMAGE_INSTALL package groups
Quoted 9 lines · Richard Purdie
Fair enough. Can we at least match the pattern
do_split_packagesuses, i.e.:
PACKAGES_DYNAMIC= "^${PN}-lib.*"I'm a little paranoid about adding wildcards like ${PN}-* as the potential for namespace problems is not insignificant, particularly if you know the horrible things bitbake does with this behind the scenes :/.
Does it really need to be dynamic at all? I don't think the list of libraries installed by ncurses varies all that much (apart from WIDEC on/off), and nor is it overwhelmingly large. It doesn't seem like it would be all that hard to arrange for the right stuff to be added to PACKAGES at parse time, in which case this whole problem would just go away.
p.
Re: [PATCH 18/21] Fix problems expanding the IMAGE_INSTALL package groups
Quoted 11 lines · Phil Blundell
Quoted 9 lines · Richard Purdie
Fair enough. Can we at least match the pattern
do_split_packagesuses, i.e.:
PACKAGES_DYNAMIC= "^${PN}-lib.*"I'm a little paranoid about adding wildcards like ${PN}-* as the potential for namespace problems is not insignificant, particularly if you know the horrible things bitbake does with this behind the scenes :/.
Quoted 6 lines
Does it really need to be dynamic at all? I don't think the list of libraries installed by ncurses varies all that much (apart from WIDEC on/off), and nor is it overwhelmingly large. It doesn't seem like it would be all that hard to arrange for the right stuff to be added to PACKAGES at parse time, in which case this whole problem would just go away.
Certainly possible. That's not the tactic we took on resolving the issue. One line change vs significantly modifying the package. The following is the chunk that handles the dynamic generation (from ncurses.inc)
python populate_packages_prepend () {
libdir = d.expand("${libdir}")
base_libdir = d.expand("${base_libdir}")
pnbase = d.expand("${PN}-lib%s")
do_split_packages(d, libdir, '^lib(.*)\.so\..*', pnbase, 'ncurses %s library', prepend=True, extra_depends = '', allow_links=True)
if libdir is not base_libdir:
do_split_packages(d, base_libdir, '^lib(.*)\.so\..*', pnbase, 'ncurses
%s library', prepend=True, extra_depends = '', allow_links=True) }
Beyond this even, the package has a number of dynamic configurations that should probably be done based on libc and/or distro flags as well.
So this is probably a job for a janitor task.
I still think as a minimal change the PACKAGES_DYNAMIC is the correct change, but as you said -- during a cleanup -- the need for PACKAGES_DYNAMIC can be diminished or removed.
--Mark
Quoted 3 lines
p.
Re: [PATCH 18/21] Fix problems expanding the IMAGE_INSTALL package groups
Quoted 34 lines · Mark Hatle
Quoted 11 lines · Phil Blundell
Quoted 9 lines · Richard Purdie
Fair enough. Can we at least match the pattern
do_split_packagesuses, i.e.:
PACKAGES_DYNAMIC= "^${PN}-lib.*"I'm a little paranoid about adding wildcards like ${PN}-* as the potential for namespace problems is not insignificant, particularly if you know the horrible things bitbake does with this behind the scenes :/.
Quoted 6 lines
Does it really need to be dynamic at all? I don't think the list of libraries installed by ncurses varies all that much (apart from WIDEC on/off), and nor is it overwhelmingly large. It doesn't seem like it would be all that hard to arrange for the right stuff to be added to PACKAGES at parse time, in which case this whole problem would just go away.
Certainly possible. That's not the tactic we took on resolving the issue. One
line change vs significantly modifying the package. The following is the chunk
that handles the dynamic generation (from ncurses.inc)python populate_packages_prepend () { libdir = d.expand("${libdir}") base_libdir = d.expand("${base_libdir}") pnbase = d.expand("${PN}-lib%s") do_split_packages(d, libdir, '^lib(.*)\.so\..*', pnbase, 'ncurses %slibrary', prepend=True,
extra_depends= '', allow_links=True)
if libdir is notbase_libdir:
do_split_packages(d,base_libdir, '^lib(.*)\.so\..*', pnbase, 'ncurses
%s library', prepend=True,extra_depends= '', allow_links=True)
}
Quoted 8 lines
Beyond this even, the package has a number of dynamic configurations that should probably be done based on libc and/or distro flags as well.
So this is probably a job for a janitor task.
I still think as a minimal change the
PACKAGES_DYNAMICis the correct change, but as you said -- during a cleanup -- the need forPACKAGES_DYNAMICcan be diminished or removed.
I've mixed feelings on this. For now I've taken the PACKAGES_DYNAMIC change since its simple and I'm happier now the "lib" is in there and it matches the package split. Any other patches will be considered on their own merit, as usual...
Cheers,
Richard
PATCH 19/21 siteinfo.bbclass: Add mips64 common siteinfo
In reply to Mark HatleThere is no mips64-common file, replace the definition with mips-common.
--- meta/classes/siteinfo.bbclass | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
meta/classes/siteinfo.bbclass +2 -2
@@ -31,8 +31,8 @@ def siteinfo_data(d): "microblaze": "endian-big bit-32 microblaze-common", "microblazeel": "endian-little bit-32 microblaze-common", "mips": "endian-big bit-32 mips-common", - "mips64": "endian-big bit-64 mips64-common", - "mips64el": "endian-little bit-64 mips64-common", + "mips64": "endian-big bit-64 mips-common", + "mips64el": "endian-little bit-64 mips-common", "mipsel": "endian-little bit-32 mips-common", "powerpc": "endian-big bit-32 powerpc-common", "nios2": "endian-little bit-32 nios2-common",
Signature · 1 line
1.8.1.2.545.g2f19ada
PATCH 20/21 cracklib: Allow byte order patch to work on older Linux hosts
In reply to Mark HatleOlder hosts don't have the htobe* and be*toh functions defined. Instead we fall back to checking the endian and calling bswap_* directly. This works on both old and new hosts.
--- ...c-support-dictionary-byte-order-dependent.patch | 120 +++++++++++---------- 1 file changed, 65 insertions(+), 55 deletions(-)
meta/recipes-extended/cracklib/cracklib/0001-packlib.c-support-dictionary-byte-order-dependent.patch +65 -55
@@ -10,25 +10,38 @@ load them. This could fix the endian issue on multiple platform. Signed-off-by: Hongxu Jia <[email protected]> Upstream-Status: Pending + +We can't use the endian.h, htobe* and be*toh functions because they are +not available on older versions of glibc, such as that found in RHEL +5.9. + +Change to checking endian and directly calling bswap_* as defined in +byteswap.h. + +Signed-off-by: Mark Hatle <[email protected]> + --- lib/packlib.c | 208 +++++++++++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 204 insertions(+), 4 deletions(-) -diff --git a/lib/packlib.c b/lib/packlib.c -index 8f32d14..323ee83 100644 ---- a/lib/packlib.c -+++ b/lib/packlib.c -@@ -16,6 +16,9 @@ +Index: cracklib-2.8.22/lib/packlib.c +=================================================================== +--- cracklib-2.8.22.orig/lib/packlib.c ++++ cracklib-2.8.22/lib/packlib.c +@@ -16,6 +16,12 @@ #ifdef HAVE_STDINT_H #include <stdint.h> #endif + ++#ifndef _BSD_SOURCE +#define _BSD_SOURCE /* See feature_test_macros(7) */ ++#endif +#include <endian.h> ++#include <byteswap.h> #include "packer.h" static const char vers_id[] = "packlib.c : v2.3p2 Alec Muffett 18 May 1993"; -@@ -45,6 +48,182 @@ typedef struct +@@ -45,6 +51,182 @@ typedef struct char data_get[NUMWORDS][MAXWORDLEN]; } PWDICT64;
@@ -40,14 +53,14 @@ index 8f32d14..323ee83 100644 +static int +IheaderHostToBigEndian(char *pHeader, int nBitType) +{ -+ if (nBitType == en_is64) ++ if (nBitType == en_is64 && __BYTE_ORDER == __LITTLE_ENDIAN) + { + struct pi_header64 *pHeader64 = (struct pi_header64*)pHeader; + -+ pHeader64->pih_magic = htobe64(pHeader64->pih_magic); -+ pHeader64->pih_numwords = htobe64(pHeader64->pih_numwords); -+ pHeader64->pih_blocklen = htobe16(pHeader64->pih_blocklen); -+ pHeader64->pih_pad = htobe16(pHeader64->pih_pad); ++ pHeader64->pih_magic = bswap_64(pHeader64->pih_magic); ++ pHeader64->pih_numwords = bswap_64(pHeader64->pih_numwords); ++ pHeader64->pih_blocklen = bswap_16(pHeader64->pih_blocklen); ++ pHeader64->pih_pad = bswap_16(pHeader64->pih_pad); + +#if DEBUG + printf("Header64: magic %x, numwords %x, blocklen %x, pad %x\n",
@@ -55,14 +68,14 @@ index 8f32d14..323ee83 100644 + pHeader64->pih_blocklen, pHeader64->pih_pad); +#endif + } -+ else if (nBitType == en_is32) ++ else if (nBitType == en_is32 && __BYTE_ORDER == __LITTLE_ENDIAN) + { + struct pi_header *pHeader32 = (struct pi_header*)pHeader; + -+ pHeader32->pih_magic = htobe32(pHeader32->pih_magic); -+ pHeader32->pih_numwords = htobe32(pHeader32->pih_numwords); -+ pHeader32->pih_blocklen = htobe16(pHeader32->pih_blocklen); -+ pHeader32->pih_pad = htobe16(pHeader32->pih_pad); ++ pHeader32->pih_magic = bswap_32(pHeader32->pih_magic); ++ pHeader32->pih_numwords = bswap_32(pHeader32->pih_numwords); ++ pHeader32->pih_blocklen = bswap_16(pHeader32->pih_blocklen); ++ pHeader32->pih_pad = bswap_16(pHeader32->pih_pad); + +#if DEBUG + printf("Header32: magic %x, numwords %x, blocklen %x, pad %x\n",
@@ -70,7 +83,7 @@ index 8f32d14..323ee83 100644 + pHeader32->pih_blocklen, pHeader32->pih_pad); +#endif + } -+ else ++ else if (__BYTE_ORDER == __LITTLE_ENDIAN) + { + fprintf(stderr, "Neither 32 or 64: %d\n", nBitType); + return (-1);
@@ -82,14 +95,14 @@ index 8f32d14..323ee83 100644 +static int +IheaderBigEndianToHost(char *pHeader, int nBitType) +{ -+ if (nBitType == en_is64) ++ if (nBitType == en_is64 && __BYTE_ORDER == __LITTLE_ENDIAN) + { + struct pi_header64 *pHeader64 = (struct pi_header64*)pHeader; + -+ pHeader64->pih_magic = be64toh(pHeader64->pih_magic); -+ pHeader64->pih_numwords = be64toh(pHeader64->pih_numwords); -+ pHeader64->pih_blocklen = be16toh(pHeader64->pih_blocklen); -+ pHeader64->pih_pad = be16toh(pHeader64->pih_pad); ++ pHeader64->pih_magic = bswap_64(pHeader64->pih_magic); ++ pHeader64->pih_numwords = bswap_64(pHeader64->pih_numwords); ++ pHeader64->pih_blocklen = bswap_16(pHeader64->pih_blocklen); ++ pHeader64->pih_pad = bswap_16(pHeader64->pih_pad); + +#if DEBUG + printf("Header64: magic %x, numwords %x, blocklen %x, pad %x\n",
@@ -97,14 +110,14 @@ index 8f32d14..323ee83 100644 + pHeader64->pih_blocklen, pHeader64->pih_pad); +#endif + } -+ else if (nBitType == en_is32) ++ else if (nBitType == en_is32 && __BYTE_ORDER == __LITTLE_ENDIAN) + { + struct pi_header *pHeader32 = (struct pi_header*)pHeader; + -+ pHeader32->pih_magic = be32toh(pHeader32->pih_magic); -+ pHeader32->pih_numwords = be32toh(pHeader32->pih_numwords); -+ pHeader32->pih_blocklen = be16toh(pHeader32->pih_blocklen); -+ pHeader32->pih_pad = be16toh(pHeader32->pih_pad); ++ pHeader32->pih_magic = bswap_32(pHeader32->pih_magic); ++ pHeader32->pih_numwords = bswap_32(pHeader32->pih_numwords); ++ pHeader32->pih_blocklen = bswap_16(pHeader32->pih_blocklen); ++ pHeader32->pih_pad = bswap_16(pHeader32->pih_pad); + +#if DEBUG + printf("Header32: magic %x, numwords %x, blocklen %x, pad %x\n",
@@ -112,7 +125,7 @@ index 8f32d14..323ee83 100644 + pHeader32->pih_blocklen, pHeader32->pih_pad); +#endif + } -+ else ++ else if (__BYTE_ORDER == __LITTLE_ENDIAN) + { + fprintf(stderr, "Neither 32 or 64: %d\n", nBitType); + return (-1);
@@ -126,27 +139,27 @@ index 8f32d14..323ee83 100644 +{ + int i = 0; + -+ if (nBitType == en_is64) ++ if (nBitType == en_is64 && __BYTE_ORDER == __LITTLE_ENDIAN) + { + uint64_t *pHwms64 = (uint64_t*)pHwms; + + for (i = 0; i < nLen / sizeof(uint64_t); i++) + { -+ *pHwms64++ = htobe64(*pHwms64); ++ *pHwms64++ = bswap_64(*pHwms64); + } + + } -+ else if (nBitType == en_is32) ++ else if (nBitType == en_is32 && __BYTE_ORDER == __LITTLE_ENDIAN) + { + uint32_t *pHwms32 = (uint32_t*)pHwms; + + for (i = 0; i < nLen / sizeof(uint32_t); i++) + { -+ *pHwms32++ = htobe32(*pHwms32); ++ *pHwms32++ = bswap_32(*pHwms32); + } + + } -+ else ++ else if (__BYTE_ORDER == __LITTLE_ENDIAN) + { + fprintf(stderr, "Neither 32 or 64: %d\n", nBitType); + return (-1);
@@ -170,27 +183,27 @@ index 8f32d14..323ee83 100644 +{ + int i = 0; + -+ if (nBitType == en_is64) ++ if (nBitType == en_is64 && __BYTE_ORDER == __LITTLE_ENDIAN) + { + uint64_t *pHwms64 = (uint64_t*)pHwms; + + for (i = 0; i < nLen / sizeof(uint64_t); i++) + { -+ *pHwms64++ = be64toh(*pHwms64); ++ *pHwms64++ = bswap_64(*pHwms64); + } + + } -+ else if (nBitType == en_is32) ++ else if (nBitType == en_is32 && __BYTE_ORDER == __LITTLE_ENDIAN) + { + uint32_t *pHwms32 = (uint32_t*)pHwms; + + for (i = 0; i < nLen / sizeof(uint32_t); i++) + { -+ *pHwms32++ = be32toh(*pHwms32); ++ *pHwms32++ = bswap_32(*pHwms32); + } + + } -+ else ++ else if (__BYTE_ORDER == __LITTLE_ENDIAN) + { + fprintf(stderr, "Neither 32 or 64: %d\n", nBitType); + return (-1);
@@ -211,7 +224,7 @@ index 8f32d14..323ee83 100644 static int _PWIsBroken64(FILE *ifp) -@@ -57,6 +236,7 @@ _PWIsBroken64(FILE *ifp) +@@ -57,6 +239,7 @@ _PWIsBroken64(FILE *ifp) return 0; }
@@ -219,7 +232,7 @@ index 8f32d14..323ee83 100644 return (pdesc64.header.pih_magic == PIH_MAGIC); } -@@ -149,7 +329,11 @@ PWOpen(prefix, mode) +@@ -149,7 +332,11 @@ PWOpen(prefix, mode) pdesc.header.pih_blocklen = NUMWORDS; pdesc.header.pih_numwords = 0;
@@ -232,7 +245,7 @@ index 8f32d14..323ee83 100644 } else { pdesc.flags &= ~PFOR_WRITE; -@@ -173,6 +357,7 @@ PWOpen(prefix, mode) +@@ -173,6 +360,7 @@ PWOpen(prefix, mode) return ((PWDICT *) 0); }
@@ -240,7 +253,7 @@ index 8f32d14..323ee83 100644 if ((pdesc.header.pih_magic == 0) || (pdesc.header.pih_numwords == 0)) { /* uh-oh. either a broken "64-bit" file or a garbage file. */ -@@ -195,6 +380,7 @@ PWOpen(prefix, mode) +@@ -195,6 +383,7 @@ PWOpen(prefix, mode) } return ((PWDICT *) 0); }
@@ -248,7 +261,7 @@ index 8f32d14..323ee83 100644 if (pdesc64.header.pih_magic != PIH_MAGIC) { /* nope, not "64-bit" after all */ -@@ -290,6 +476,7 @@ PWOpen(prefix, mode) +@@ -290,6 +479,7 @@ PWOpen(prefix, mode) { pdesc.flags &= ~PFOR_USEHWMS; }
@@ -256,7 +269,7 @@ index 8f32d14..323ee83 100644 for (i = 0; i < sizeof(pdesc.hwms) / sizeof(pdesc.hwms[0]); i++) { pdesc.hwms[i] = pdesc64.hwms[i]; -@@ -299,6 +486,7 @@ PWOpen(prefix, mode) +@@ -299,6 +489,7 @@ PWOpen(prefix, mode) { pdesc.flags &= ~PFOR_USEHWMS; }
@@ -264,7 +277,7 @@ index 8f32d14..323ee83 100644 #if DEBUG for (i=1; i<=0xff; i++) { -@@ -332,7 +520,11 @@ PWClose(pwp) +@@ -332,7 +523,11 @@ PWClose(pwp) return (-1); }
@@ -277,7 +290,7 @@ index 8f32d14..323ee83 100644 { fprintf(stderr, "index magic fwrite failed\n"); return (-1); -@@ -351,7 +543,12 @@ PWClose(pwp) +@@ -351,7 +546,12 @@ PWClose(pwp) printf("hwm[%02x] = %d\n", i, pwp->hwms[i]); #endif }
@@ -291,32 +304,29 @@ index 8f32d14..323ee83 100644 } } -@@ -405,7 +602,8 @@ PutPW(pwp, string) +@@ -405,7 +605,8 @@ PutPW(pwp, string) datum = (uint32_t) ftell(pwp->dfp); - fwrite((char *) &datum, sizeof(datum), 1, pwp->ifp); -+ uint32_t tmpdatum = htobe32(datum); ++ uint32_t tmpdatum = (__BYTE_ORDER == __LITTLE_ENDIAN) ? bswap_32(datum) : datum; + fwrite((char *) &tmpdatum, sizeof(tmpdatum), 1, pwp->ifp); fputs(pwp->data_put[0], pwp->dfp); putc(0, pwp->dfp); -@@ -473,6 +671,7 @@ GetPW(pwp, number) +@@ -473,6 +674,7 @@ GetPW(pwp, number) perror("(index fread failed)"); return ((char *) 0); } -+ datum64 = be64toh(datum64); ++ datum64 = (__BYTE_ORDER == __LITTLE_ENDIAN) ? bswap_64(datum64) : datum64; datum = datum64; } else { if (fseek(pwp->ifp, sizeof(struct pi_header) + (thisblock * sizeof(uint32_t)), 0)) -@@ -486,6 +685,7 @@ GetPW(pwp, number) +@@ -486,6 +688,7 @@ GetPW(pwp, number) perror("(index fread failed)"); return ((char *) 0); } -+ datum = be32toh(datum); ++ datum = (__BYTE_ORDER == __LITTLE_ENDIAN) ? bswap_32(datum) : datum; } int r = 1; --- -1.7.10.4 -
Signature · 1 line
1.8.1.2.545.g2f19ada
PATCH 21/21 libarchive: Fix build dependencies
In reply to Mark HatleMove to using the PACKAGECONFIG mechanism to select configure options and dependencies. Without this the system will attempt to discover various dependencies, and usually does so incorrectly.
We also ensure that the nativesdk version does not inherit any of the DISTRO_FEATURES. We shouldn't need acl or xattr support for nativesdk.
--- meta/recipes-extended/libarchive/libarchive_2.8.5.bb | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-)
meta/recipes-extended/libarchive/libarchive_2.8.5.bb +19 -1
@@ -5,7 +5,25 @@ LICENSE = "BSD" LIC_FILES_CHKSUM = "file://COPYING;md5=4255e2e6f0349a4ac8fbd68459296e46" PR = "r0" -DEPENDS = "libxml2" +PACKAGECONFIG ?= "libxml2 zlib bz2" + +PACKAGECONFIG_class-target += "\ + ${@base_contains('DISTRO_FEATURES', 'acl', 'acl', '', d)} \ + ${@base_contains('DISTRO_FEATURES', 'xattr', 'xattr', '', d)} \ + ${@base_contains('DISTRO_FEATURES', 'largefile', 'largefile', '', d)} \ +" + +PACKAGECONFIG_class-nativesdk += "largefile" + +PACKAGECONFIG[acl] = "--enable-acl,--disable-acl,acl," +PACKAGECONFIG[xattr] = "--enable-xattr,--disable-xattr,attr," +PACKAGECONFIG[largefile] = "--enable-largefile,--disable-largefile,," +PACKAGECONFIG[zlib] = "--with-zlib,--without-zlib,zlib," +PACKAGECONFIG[bz2] = "--with-bz2lib,--without-bz2lib,bzip2," +PACKAGECONFIG[xz] = "--with-lzmadec --with-lzma,--without-lzmadec --without-lzma,xz," +PACKAGECONFIG[openssl] = "--with-openssl,--without-openssl,openssl," +PACKAGECONFIG[libxml2] = "--with-xml2,--without-xml2,libxml2," +PACKAGECONFIG[expat] = "--with-expat,--without-expat,expat," SRC_URI = "http://libarchive.googlecode.com/files/libarchive-${PV}.tar.gz \ file://0001-Patch-from-upstream-revision-1990.patch \
Signature · 1 line
1.8.1.2.545.g2f19ada
Quoted 6 lines · Mark Hatle
The following is a set of patches that I've been merging forward for a while now. Almost all of these items have been sent up previously to the oe-core list, but they have not yet been integrated.
As far as I'm aware, all comments to previous submissions have been addressed.
Mark,
Do you have a branch someplace that has all the updates and patch removals in it? With a large set like this having an updated branch would be very helpful.
Thanks
Sau!
Quoted 5 lines
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Quoted 5 lines · Saul Wold
Quoted 4 lines · Mark Hatle
The following is a set of patches that I've been merging forward for a while now. Almost all of these items have been sent up previously to the oe-core list, but they have not yet been integrated.
Quoted 8 lines
Quoted 2 lines
As far as I'm aware, all comments to previous submissions have been addressed.
Mark,
Do you have a branch someplace that has all the updates and patch removals in it? With a large set like this having an updated branch would be very helpful.
I rebased and pushed the changes to the poky-contrib. It's down to 11 patches now.
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=mhatle/misc
Quoted 8 lines
Thanks
Sau!Quoted 5 lines
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core