[PATCH 0/21] Misc patch set

[PATCH 0/21] Misc patch set

[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.

[PATCH 1/21] libxpm: inherit gettext

[Mark Hatle]

From: Jesse Zhang <sen.zhang@windriver.com>

libxpm requires the xgettext command to build.

Signed-off-by: Jesse Zhang <sen.zhang@windriver.com>

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
---
 meta/recipes-graphics/xorg-lib/libxpm_3.5.10.bb | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-graphics/xorg-lib/libxpm_3.5.10.bb b/meta/recipes-graphics/xorg-lib/libxpm_3.5.10.bb
index 9eaa212..17b1ef5 100644
--- a/meta/recipes-graphics/xorg-lib/libxpm_3.5.10.bb
+++ b/meta/recipes-graphics/xorg-lib/libxpm_3.5.10.bb
@@ -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 \
-- 
1.8.1.2.545.g2f19ada

[PATCH 2/21] Add directory information to the pkgdata files

[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 <mark.hatle@windriver.com>
---
 meta/classes/package.bbclass | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index 02a1460..19b2b4c 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -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()
 
-- 
1.8.1.2.545.g2f19ada

[PATCH 3/21] cmake.bbclass: modify construction of compiler flags

[Mark Hatle]

From: Joe Slater <jslater@windriver.com>

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.

Signed-off-by: Joe Slater <jslater@windriver.com>
Signed-off-by: Jeff Polk <jeff.polk@windriver.com>
---
 meta/classes/cmake.bbclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index e64c30c..310242e 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -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}"
-- 
1.8.1.2.545.g2f19ada

[PATCH 4/21] acpid: modify CFLAGS

[Mark Hatle]

From: Joe Slater <jslater@windriver.com>

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.

Signed-off-by: Joe Slater <jslater@windriver.com>
Signed-off-by: Jeff Polk <jeff.polk@windriver.com>
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
---
 meta/recipes-bsp/acpid/acpid.inc | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-bsp/acpid/acpid.inc b/meta/recipes-bsp/acpid/acpid.inc
index 3c0219f..1ffe6ff 100644
--- a/meta/recipes-bsp/acpid/acpid.inc
+++ b/meta/recipes-bsp/acpid/acpid.inc
@@ -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}'
-- 
1.8.1.2.545.g2f19ada

[PATCH 5/21] libpam: Avoid wildcards in the SRC_URI

[Mark Hatle]

Remove 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...

Signed-off-by: Jackie Huang <jackie.huang@windriver.com>
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
---
 meta/recipes-extended/pam/libpam_1.1.6.bb | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-extended/pam/libpam_1.1.6.bb b/meta/recipes-extended/pam/libpam_1.1.6.bb
index c355634..73a8f88 100644
--- a/meta/recipes-extended/pam/libpam_1.1.6.bb
+++ b/meta/recipes-extended/pam/libpam_1.1.6.bb
@@ -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 \
-- 
1.8.1.2.545.g2f19ada

[PATCH 6/21] util-linux: Add ability to compile with nativesdk

[Mark Hatle]

From: Jason Wessel <jason.wessel@windriver.com>

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.

Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
---
 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(-)

diff --git a/meta/recipes-core/util-linux/util-linux.inc b/meta/recipes-core/util-linux/util-linux.inc
index b4e64b5..0ada1a5 100644
--- a/meta/recipes-core/util-linux/util-linux.inc
+++ b/meta/recipes-core/util-linux/util-linux.inc
@@ -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"
diff --git a/meta/recipes-core/util-linux/util-linux_2.23.bb b/meta/recipes-core/util-linux/util-linux_2.23.bb
index d80b382..5d9a8dc 100644
--- a/meta/recipes-core/util-linux/util-linux_2.23.bb
+++ b/meta/recipes-core/util-linux/util-linux_2.23.bb
@@ -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"
-- 
1.8.1.2.545.g2f19ada

[PATCH 7/21] dbus-glib: use BPN instead of PN

[Mark Hatle]

From: Jesse Zhang <sen.zhang@windriver.com>

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

Signed-off-by: Jesse Zhang <sen.zhang@windriver.com>
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
---
 meta/recipes-core/dbus/dbus-glib.inc | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta/recipes-core/dbus/dbus-glib.inc b/meta/recipes-core/dbus/dbus-glib.inc
index 973c995..6c60d9e 100644
--- a/meta/recipes-core/dbus/dbus-glib.inc
+++ b/meta/recipes-core/dbus/dbus-glib.inc
@@ -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"
-- 
1.8.1.2.545.g2f19ada

[PATCH 8/21] initscripts: let status return 0 when proc is running well

[Mark Hatle]

From: Jesse Zhang <sen.zhang@windriver.com>

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.

Signed-off-by: Jesse Zhang <sen.zhang@windriver.com>
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
---
 meta/recipes-core/initscripts/initscripts-1.0/functions | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-core/initscripts/initscripts-1.0/functions b/meta/recipes-core/initscripts/initscripts-1.0/functions
index 944e3a5..8e15762 100644
--- a/meta/recipes-core/initscripts/initscripts-1.0/functions
+++ b/meta/recipes-core/initscripts/initscripts-1.0/functions
@@ -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
-- 
1.8.1.2.545.g2f19ada

[PATCH 9/21] pull ldlinux.sys and isolinux.bin from correct places

[Mark Hatle]

From: Joe Slater <jslater@windriver.com>

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.

Signed-off-by: Joe Slater <jslater@windriver.com>
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
---
 meta/classes/syslinux.bbclass | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/meta/classes/syslinux.bbclass b/meta/classes/syslinux.bbclass
index 501bc6d..2c7ecf6 100644
--- a/meta/classes/syslinux.bbclass
+++ b/meta/classes/syslinux.bbclass
@@ -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
-- 
1.8.1.2.545.g2f19ada

[PATCH 10/21] ncurses, busybox, cml1.bbclass: Fix menuconfig display corruption

[Mark Hatle]

From: Jason Wessel <jason.wessel@windriver.com>

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

Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
---
 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

diff --git a/meta/classes/cml1.bbclass b/meta/classes/cml1.bbclass
index bb95639..cd8e599 100644
--- a/meta/classes/cml1.bbclass
+++ b/meta/classes/cml1.bbclass
@@ -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() {
diff --git a/meta/recipes-core/busybox/busybox-1.20.2/busybox-cross-menuconfig.patch b/meta/recipes-core/busybox/busybox-1.20.2/busybox-cross-menuconfig.patch
new file mode 100644
index 0000000..c0784d5
--- /dev/null
+++ b/meta/recipes-core/busybox/busybox-1.20.2/busybox-cross-menuconfig.patch
@@ -0,0 +1,69 @@
+From: Jason Wessel <jason.wessel@windriver.com>
+Date: Sun, 3 Mar 2013 12:31:40 -0600
+Subject: [PATCH] menuconfig,check-lxdiaglog.sh: Allow specification of ncurses location
+
+[ based on: https://lkml.org/lkml/2013/3/3/103 ]
+
+This patch syncs up with the way the menuconfig ncurses / curses
+is detected and the HOST_EXTRACFLAGS works in the Linux kernel
+and it allows the menuconfig to work with a sysroot version
+of the curses libraries.
+
+---
+
+In some cross build environments such as the Yocto Project build
+environment it provides an ncurses library that is compiled
+differently than the host's version.  This causes display corruption
+problems when the host's curses includes are used instead of the
+includes from the provided compiler are overridden.  There is a second
+case where there is no curses libraries at all on the host system and
+menuconfig will just fail entirely.
+
+The solution is simply to allow an override variable in
+check-lxdialog.sh for environments such as the Yocto Project.  Adding
+a CROSS_CURSES_LIB and CROSS_CURSES_INC solves the issue and allowing
+compiling and linking against the right headers and libraries.
+
+Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
+cc: Michal Marek <mmarek@suse.cz>
+cc: linux-kbuild@vger.kernel.org
+---
+ scripts/kconfig/lxdialog/Makefile          |    2 +-
+ scripts/kconfig/lxdialog/check-lxdialog.sh |    8 ++++++++
+ 2 files changed, 9 insertions(+), 1 deletion(-)
+
+--- a/scripts/kconfig/lxdialog/check-lxdialog.sh
++++ b/scripts/kconfig/lxdialog/check-lxdialog.sh
+@@ -4,6 +4,10 @@
+ # What library to link
+ ldflags()
+ {
++	if [ x"$CROSS_CURSES_LIB" != x ]; then
++		echo "$CROSS_CURSES_LIB"
++		exit
++	fi
+ 	for ext in so a dylib ; do
+ 		for lib in ncursesw ncurses curses ; do
+ 			$cc -print-file-name=lib${lib}.${ext} | grep -q /
+@@ -19,6 +23,10 @@ ldflags()
+ # Where is ncurses.h?
+ ccflags()
+ {
++	if [ x"$CROSS_CURSES_INC" != x ]; then
++		echo "$CROSS_CURSES_INC"
++		exit
++	fi
+ 	if [ -f /usr/include/ncursesw/ncurses.h ]; then
+ 		echo '-I/usr/include/ncursesw -DCURSES_LOC="<ncurses.h>"'
+ 	elif [ -f /usr/include/ncursesw/curses.h ]; then
+--- a/scripts/kconfig/lxdialog/Makefile
++++ b/scripts/kconfig/lxdialog/Makefile
+@@ -5,7 +5,7 @@ check-lxdialog  := $(srctree)/$(src)/che
+ 
+ # Use reursively expanded variables so we do not call gcc unless
+ # we really need to do so. (Do not call gcc as part of make mrproper)
+-HOST_EXTRACFLAGS = $(shell $(CONFIG_SHELL) $(check-lxdialog) -ccflags)
++HOST_EXTRACFLAGS += $(shell $(CONFIG_SHELL) $(check-lxdialog) -ccflags)
+ HOST_LOADLIBES   = $(shell $(CONFIG_SHELL) $(check-lxdialog) -ldflags $(HOSTCC))
+ 
+ HOST_EXTRACFLAGS += -DLOCALE
diff --git a/meta/recipes-core/busybox/busybox_1.20.2.bb b/meta/recipes-core/busybox/busybox_1.20.2.bb
index 07d722d..410c701 100644
--- a/meta/recipes-core/busybox/busybox_1.20.2.bb
+++ b/meta/recipes-core/busybox/busybox_1.20.2.bb
@@ -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"
diff --git a/meta/recipes-core/ncurses/ncurses.inc b/meta/recipes-core/ncurses/ncurses.inc
index bcb9c94..8a81381 100644
--- a/meta/recipes-core/ncurses/ncurses.inc
+++ b/meta/recipes-core/ncurses/ncurses.inc
@@ -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 ..
-- 
1.8.1.2.545.g2f19ada

[PATCH 11/21] guile: don't search for libreadline in host libdir

[Mark Hatle]

From: Jackie Huang <jackie.huang@windriver.com>

Fix the QA warning:
WARNING: guile: The compile log indicates that host include and/or library paths were used.

Signed-off-by: Jackie Huang <jackie.huang@windriver.com>
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
---
 meta/recipes-devtools/guile/guile_2.0.9.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/guile/guile_2.0.9.bb b/meta/recipes-devtools/guile/guile_2.0.9.bb
index 617f7ce..058f243 100644
--- a/meta/recipes-devtools/guile/guile_2.0.9.bb
+++ b/meta/recipes-devtools/guile/guile_2.0.9.bb
@@ -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
-- 
1.8.1.2.545.g2f19ada

[PATCH 12/21] dpkg-native: Fix native perl path

[Mark Hatle]

From: Ming Liu <ming.liu@windriver.com>

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.

Signed-off-by: Ming Liu <ming.liu@windriver.com>
---
 meta/recipes-devtools/dpkg/dpkg.inc | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-devtools/dpkg/dpkg.inc b/meta/recipes-devtools/dpkg/dpkg.inc
index 6197777..5fcf9bc 100644
--- a/meta/recipes-devtools/dpkg/dpkg.inc
+++ b/meta/recipes-devtools/dpkg/dpkg.inc
@@ -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"
 
-- 
1.8.1.2.545.g2f19ada

[PATCH 13/21] qmake_base.bbclass:add linux-gnun32-oe-g++ to QMAKESPEC

[Mark Hatle]

From: Xin Ouyang <Xin.Ouyang@windriver.com>

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.

Signed-off-by: Xin Ouyang <Xin.Ouyang@windriver.com>
Signed-off-by: Randy MacLeod <Randy.MacLeod@windriver.com>
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
---
 meta/classes/qmake_base.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/qmake_base.bbclass b/meta/classes/qmake_base.bbclass
index fa1b5f0..52e7fb0 100644
--- a/meta/classes/qmake_base.bbclass
+++ b/meta/classes/qmake_base.bbclass
@@ -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
-- 
1.8.1.2.545.g2f19ada

[PATCH 14/21] portmap: /etc/init.d/portmap restart complains "command not found"

[Mark Hatle]

From: Amy Fong <amy.fong@windriver.com>

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.

Signed-off-by: Amy Fong <amy.fong@windriver.com>
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
---
 meta/recipes-connectivity/portmap/portmap/portmap.init | 18 +++++++++++++-----
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/meta/recipes-connectivity/portmap/portmap/portmap.init b/meta/recipes-connectivity/portmap/portmap/portmap.init
index e46513e..e7031af 100755
--- a/meta/recipes-connectivity/portmap/portmap/portmap.init
+++ b/meta/recipes-connectivity/portmap/portmap/portmap.init
@@ -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}"
-- 
1.8.1.2.545.g2f19ada

[PATCH 15/21] fix libnl two parentheses bugs in lib/cache_mngr.c file

[Mark Hatle]

From: "Song.Li" <Song.Li@windriver.com>

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.

Signed-off-by: Song Li <Song.Li@windriver.com>
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
---
 ...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

diff --git a/meta/recipes-support/libnl/libnl/fix-lib-cache_mngr.c-two-parentheses-bugs.patch b/meta/recipes-support/libnl/libnl/fix-lib-cache_mngr.c-two-parentheses-bugs.patch
new file mode 100644
index 0000000..6b8fa10
--- /dev/null
+++ b/meta/recipes-support/libnl/libnl/fix-lib-cache_mngr.c-two-parentheses-bugs.patch
@@ -0,0 +1,37 @@
+From 82fdf49c185fd5f3810781af9ef52aa6a52bf2df Mon Sep 17 00:00:00 2001
+From: "Song.Li" <Song.Li@windriver.com>
+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
+
diff --git a/meta/recipes-support/libnl/libnl_3.2.22.bb b/meta/recipes-support/libnl/libnl_3.2.22.bb
index 36e98e1..30f85b2 100644
--- a/meta/recipes-support/libnl/libnl_3.2.22.bb
+++ b/meta/recipes-support/libnl/libnl_3.2.22.bb
@@ -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"
-- 
1.8.1.2.545.g2f19ada

[PATCH 16/21] bind: add ipv6 support

[Mark Hatle]

From: Li Wang <li.wang@windriver.com>

Make ipv6 configure dependent on DISTRO_FEATURES.

Signed-off-by: Li Wang <li.wang@windriver.com>
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
---
 meta/recipes-connectivity/bind/bind_9.8.1.bb | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-connectivity/bind/bind_9.8.1.bb b/meta/recipes-connectivity/bind/bind_9.8.1.bb
index 18cbb99..7d37b92 100644
--- a/meta/recipes-connectivity/bind/bind_9.8.1.bb
+++ b/meta/recipes-connectivity/bind/bind_9.8.1.bb
@@ -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 \
-- 
1.8.1.2.545.g2f19ada

[PATCH 17/21] grep: fix for CVE-2012-5667

[Mark Hatle]

From: Ming Liu <ming.liu@windriver.com>

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 <ming.liu@windriver.com>
---
 .../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

diff --git a/meta/recipes-extended/grep/grep-2.5.1a/grep-CVE-2012-5667.patch b/meta/recipes-extended/grep/grep-2.5.1a/grep-CVE-2012-5667.patch
new file mode 100644
index 0000000..e163736
--- /dev/null
+++ b/meta/recipes-extended/grep/grep-2.5.1a/grep-CVE-2012-5667.patch
@@ -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 <ming.liu@windriver.com>
+---
+ 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.  */
diff --git a/meta/recipes-extended/grep/grep_2.5.1a.bb b/meta/recipes-extended/grep/grep_2.5.1a.bb
index d6386ed..247c837 100644
--- a/meta/recipes-extended/grep/grep_2.5.1a.bb
+++ b/meta/recipes-extended/grep/grep_2.5.1a.bb
@@ -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"
-- 
1.8.1.2.545.g2f19ada

[PATCH 18/21] Fix problems expanding the IMAGE_INSTALL package groups

[Mark Hatle]

From: Jason Wessel <jason.wessel@windriver.com>

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'

Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
---
 meta/recipes-core/ncurses/ncurses.inc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-core/ncurses/ncurses.inc b/meta/recipes-core/ncurses/ncurses.inc
index 8a81381..584ad46 100644
--- a/meta/recipes-core/ncurses/ncurses.inc
+++ b/meta/recipes-core/ncurses/ncurses.inc
@@ -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
-- 
1.8.1.2.545.g2f19ada

[PATCH 19/21] siteinfo.bbclass: Add mips64 common siteinfo

[Mark Hatle]

There is no mips64-common file, replace the definition with mips-common.

Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
---
 meta/classes/siteinfo.bbclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/classes/siteinfo.bbclass b/meta/classes/siteinfo.bbclass
index 09f88c6..8705eaa 100644
--- a/meta/classes/siteinfo.bbclass
+++ b/meta/classes/siteinfo.bbclass
@@ -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",
-- 
1.8.1.2.545.g2f19ada

[PATCH 20/21] cracklib: Allow byte order patch to work on older Linux hosts

[Mark Hatle]

Older 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.

Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
---
 ...c-support-dictionary-byte-order-dependent.patch | 120 +++++++++++----------
 1 file changed, 65 insertions(+), 55 deletions(-)

diff --git a/meta/recipes-extended/cracklib/cracklib/0001-packlib.c-support-dictionary-byte-order-dependent.patch b/meta/recipes-extended/cracklib/cracklib/0001-packlib.c-support-dictionary-byte-order-dependent.patch
index fc402ee..8e0f406 100644
--- a/meta/recipes-extended/cracklib/cracklib/0001-packlib.c-support-dictionary-byte-order-dependent.patch
+++ b/meta/recipes-extended/cracklib/cracklib/0001-packlib.c-support-dictionary-byte-order-dependent.patch
@@ -10,25 +10,38 @@ load them. This could fix the endian issue on multiple platform.
 
 Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
 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 <mark.hatle@windriver.com>
+
 ---
  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
-
-- 
1.8.1.2.545.g2f19ada

[PATCH 21/21] libarchive: Fix build dependencies

[Mark Hatle]

Move 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.

Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
---
 meta/recipes-extended/libarchive/libarchive_2.8.5.bb | 20 +++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-extended/libarchive/libarchive_2.8.5.bb b/meta/recipes-extended/libarchive/libarchive_2.8.5.bb
index 5cf13e6..06989d3 100644
--- a/meta/recipes-extended/libarchive/libarchive_2.8.5.bb
+++ b/meta/recipes-extended/libarchive/libarchive_2.8.5.bb
@@ -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 \
-- 
1.8.1.2.545.g2f19ada

Re: [PATCH 2/21] Add directory information to the pkgdata files

[Paul Eggleton]

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 <mark.hatle@windriver.com>
> ---
>  meta/classes/package.bbclass | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
> index 02a1460..19b2b4c 100644
> --- a/meta/classes/package.bbclass
> +++ b/meta/classes/package.bbclass
> @@ -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

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [PATCH 2/21] Add directory information to the pkgdata files

[Mark Hatle]

On 5/29/13 10:11 AM, Paul Eggleton wrote:
> 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 <mark.hatle@windriver.com>
>> ---
>>   meta/classes/package.bbclass | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
>> index 02a1460..19b2b4c 100644
>> --- a/meta/classes/package.bbclass
>> +++ b/meta/classes/package.bbclass
>> @@ -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.

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

> Cheers,
> Paul
>

Re: [PATCH 2/21] Add directory information to the pkgdata files

[Martin Jansa]

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

On Wed, May 29, 2013 at 10:09:44AM -0500, 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 <mark.hatle@windriver.com>
> ---
>  meta/classes/package.bbclass | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
> index 02a1460..19b2b4c 100644
> --- a/meta/classes/package.bbclass
> +++ b/meta/classes/package.bbclass
> @@ -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?

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

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

Re: [PATCH 2/21] Add directory information to the pkgdata files

[Mark Hatle]

On 5/29/13 10:59 AM, Martin Jansa wrote:
> On Wed, May 29, 2013 at 10:09:44AM -0500, 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 <mark.hatle@windriver.com>
>> ---
>>   meta/classes/package.bbclass | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
>> index 02a1460..19b2b4c 100644
>> --- a/meta/classes/package.bbclass
>> +++ b/meta/classes/package.bbclass
>> @@ -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?
>

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

[Khem Raj]

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

On Wednesday, May 29, 2013, Mark Hatle <mark.hatle@windriver.com> wrote:
> On 5/29/13 10:59 AM, Martin Jansa wrote:
>>
>> On Wed, May 29, 2013 at 10:09:44AM -0500, 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 <mark.hatle@windriver.com>

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


>>> ---
>>>   meta/classes/package.bbclass | 2 ++
>>>   1 file changed, 2 insertions(+)
>>>
>>> diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
>>> index 02a1460..19b2b4c 100644
>>> --- a/meta/classes/package.bbclass
>>> +++ b/meta/classes/package.bbclass
>>> @@ -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?
>>
>
> 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
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

[-- Attachment #2: Type: text/html, Size: 2812 bytes --]

Re: [PATCH 2/21] Add directory information to the pkgdata files

[Phil Blundell]

On Wed, 2013-05-29 at 11:30 -0500, Mark Hatle wrote:
> 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

[Mark Hatle]

On 5/29/13 2:59 PM, Phil Blundell wrote:
> On Wed, 2013-05-29 at 11:30 -0500, Mark Hatle wrote:
>> 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.

On 5/29/13 12:36 PM, Khem Raj wrote:
 > 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.

> 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

> p.
>
>

Re: [PATCH 18/21] Fix problems expanding the IMAGE_INSTALL package groups

[Richard Purdie]

On Wed, 2013-05-29 at 10:10 -0500, Mark Hatle wrote:
> From: Jason Wessel <jason.wessel@windriver.com>
> 
> 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'
> 
> Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
> Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
> ---
>  meta/recipes-core/ncurses/ncurses.inc | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/meta/recipes-core/ncurses/ncurses.inc b/meta/recipes-core/ncurses/ncurses.inc
> index 8a81381..584ad46 100644
> --- a/meta/recipes-core/ncurses/ncurses.inc
> +++ b/meta/recipes-core/ncurses/ncurses.inc
> @@ -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 10/21] ncurses, busybox, cml1.bbclass: Fix menuconfig display corruption

[Richard Purdie]

On Wed, 2013-05-29 at 10:09 -0500, Mark Hatle wrote:
> From: Jason Wessel <jason.wessel@windriver.com>
> 
> 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
> 
> Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
> ---
>  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

Re: [PATCH 17/21] grep: fix for CVE-2012-5667

[Richard Purdie]

On Wed, 2013-05-29 at 10:09 -0500, Mark Hatle wrote:
> From: Ming Liu <ming.liu@windriver.com>
> 
> 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 <ming.liu@windriver.com>
> ---
>  .../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
> 
> diff --git a/meta/recipes-extended/grep/grep-2.5.1a/grep-CVE-2012-5667.patch b/meta/recipes-extended/grep/grep-2.5.1a/grep-CVE-2012-5667.patch
> new file mode 100644
> index 0000000..e163736
> --- /dev/null
> +++ b/meta/recipes-extended/grep/grep-2.5.1a/grep-CVE-2012-5667.patch
> @@ -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 <ming.liu@windriver.com>
> +---
> + 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

> +--- 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.  */
> diff --git a/meta/recipes-extended/grep/grep_2.5.1a.bb b/meta/recipes-extended/grep/grep_2.5.1a.bb
> index d6386ed..247c837 100644
> --- a/meta/recipes-extended/grep/grep_2.5.1a.bb
> +++ b/meta/recipes-extended/grep/grep_2.5.1a.bb
> @@ -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"

Re: [PATCH 18/21] Fix problems expanding the IMAGE_INSTALL package groups

[Mark Hatle]

On 5/29/13 4:10 PM, Richard Purdie wrote:
> On Wed, 2013-05-29 at 10:10 -0500, Mark Hatle wrote:
>> From: Jason Wessel <jason.wessel@windriver.com>
>>
>> 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'
>>
>> Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
>> Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
>> ---
>>   meta/recipes-core/ncurses/ncurses.inc | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/meta/recipes-core/ncurses/ncurses.inc b/meta/recipes-core/ncurses/ncurses.inc
>> index 8a81381..584ad46 100644
>> --- a/meta/recipes-core/ncurses/ncurses.inc
>> +++ b/meta/recipes-core/ncurses/ncurses.inc
>> @@ -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.

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

> Cheers,
>
> Richard
>

Re: [PATCH 18/21] Fix problems expanding the IMAGE_INSTALL package groups

[Richard Purdie]

On Wed, 2013-05-29 at 16:28 -0500, Mark Hatle wrote:
> On 5/29/13 4:10 PM, Richard Purdie wrote:
> > On Wed, 2013-05-29 at 10:10 -0500, Mark Hatle wrote:
> >> From: Jason Wessel <jason.wessel@windriver.com>
> >>
> >> 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'
> >>
> >> Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
> >> Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
> >> ---
> >>   meta/recipes-core/ncurses/ncurses.inc | 2 ++
> >>   1 file changed, 2 insertions(+)
> >>
> >> diff --git a/meta/recipes-core/ncurses/ncurses.inc b/meta/recipes-core/ncurses/ncurses.inc
> >> index 8a81381..584ad46 100644
> >> --- a/meta/recipes-core/ncurses/ncurses.inc
> >> +++ b/meta/recipes-core/ncurses/ncurses.inc
> >> @@ -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.
> 
> 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


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 0/21] Misc patch set

[Saul Wold]

On 05/30/2013 12:09 AM, Mark Hatle wrote:
> 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!

> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

Re: [PATCH 0/21] Misc patch set

[Mark Hatle]

On 5/29/13 7:53 PM, Saul Wold wrote:
> On 05/30/2013 12:09 AM, Mark Hatle wrote:
>> 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.

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

> Thanks
> 	Sau!
>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>

Re: [PATCH 2/21] Add directory information to the pkgdata files

[Paul Eggleton]

On Wednesday 29 May 2013 15:44:58 Mark Hatle wrote:
> On 5/29/13 2:59 PM, Phil Blundell wrote:
> > On Wed, 2013-05-29 at 11:30 -0500, Mark Hatle wrote:
> >> 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.
> 
> On 5/29/13 12:36 PM, Khem Raj wrote:
>  > 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.)

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

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [PATCH 2/21] Add directory information to the pkgdata files

[Richard Purdie]

On Thu, 2013-05-30 at 09:29 +0100, Paul Eggleton wrote:
> On Wednesday 29 May 2013 15:44:58 Mark Hatle wrote:
> > On 5/29/13 2:59 PM, Phil Blundell wrote:
> > > On Wed, 2013-05-29 at 11:30 -0500, Mark Hatle wrote:
> > >> 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.
> > 
> > On 5/29/13 12:36 PM, Khem Raj wrote:
> >  > 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.)
> 
> 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.

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

Re: [PATCH 18/21] Fix problems expanding the IMAGE_INSTALL package groups

[Phil Blundell]

On Wed, 2013-05-29 at 22:59 +0100, Richard Purdie wrote:
> 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 :/.

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

[Mark Hatle]

On 5/30/13 5:46 AM, Phil Blundell wrote:
> On Wed, 2013-05-29 at 22:59 +0100, Richard Purdie wrote:
>> 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 :/.
>
> 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

> p.
>
>

Re: [PATCH 18/21] Fix problems expanding the IMAGE_INSTALL package groups

[Richard Purdie]

On Thu, 2013-05-30 at 07:22 -0500, Mark Hatle wrote:
> On 5/30/13 5:46 AM, Phil Blundell wrote:
> > On Wed, 2013-05-29 at 22:59 +0100, Richard Purdie wrote:
> >> 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 :/.
> >
> > 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.

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