[OE-core] [PATCH] insane.bbclass: Updated MicroBlaze machine definitions
* Removed existing definition with machine 47787, this
definition is outdated, a sanity error should occur if an ELF uses this
value.
* Added new definition with machine 189. This value replaces the existing
value since August 2009. See binutils thread for more information.
(http://sourceware.org/ml/binutils/2009-08/msg00127.html)
Signed-off-by: Nathan Rossi nathan.ro...@xilinx.com
---
meta/classes/insane.bbclass |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 2f10688..75db7a2 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -60,6 +60,8 @@ def package_qa_get_machine_dict():
s390: (22, 0,0, False,
32),
sh4:(42, 0,0, True,
32),
sparc: ( 2, 0,0, False,
32),
+microblaze: (189, 0,0, False,
32),
+microblazeel:(189, 0,0, True,
32),
},
linux-uclibc : {
arm : ( 40,97,0, True,
32),
@@ -97,8 +99,6 @@ def package_qa_get_machine_dict():
},
linux-gnu : {
powerpc:(20, 0,0, False,
32),
-microblaze: (47787, 0,0, False,
32),
-microblazeel: (47787, 0,0, True,
32),
sh4:(42, 0,0, True,
32),
},
linux-gnux32 : {
--
1.7.5.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] systemd: Set the default firmware path to enable firmware loading in udev
Op 7 apr. 2013, om 11:20 heeft Holger Hans Peter Freyther hol...@moiji-mobile.com het volgende geschreven: From: Holger Hans Peter Freyther ze...@selfish.org After some breakage in udev the kernel gained direct firmware loading. For older kernels (e.g. 3.2 in my case) udev still needs to load the firmware. Firmware loading is enabled once a default firmware path is set. Apply a compile fix from the upstream project. --- .../systemd/systemd/199-firmware.patch | 97 meta/recipes-core/systemd/systemd_199.bb |3 + 2 files changed, 100 insertions(+) create mode 100644 meta/recipes-core/systemd/systemd/199-firmware.patch diff --git a/meta/recipes-core/systemd/systemd/199-firmware.patch b/meta/recipes-core/systemd/systemd/199-firmware.patch new file mode 100644 index 000..1f4540f --- /dev/null +++ b/meta/recipes-core/systemd/systemd/199-firmware.patch @@ -0,0 +1,97 @@ +http://cgit.freedesktop.org/systemd/systemd/patch/?id=d8d4bee76cf3b40ea923bc57d44aa0815ca9b5ff + +From d8d4bee76cf3b40ea923bc57d44aa0815ca9b5ff Mon Sep 17 00:00:00 2001 +From: Kay Sievers k...@vrfy.org +Date: Thu, 28 Mar 2013 14:28:10 + +Subject: build-sys: fix HAVE/ENABLE_FIRMWARE The above makes it clear that it's a backport, but I'd still like to see a Upstream-status: Backport in there :) regards, Koen ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] ptest bugfix: Make all ptest files go into -ptest package
Richard Purdie wrote: Why are we putting all the debug files into the -ptest package now? Does that make sense? (Sorry, I missed this comment.) My reasoning is that we want all ptest data to be contained in -ptest packages and not leak into other packages. If we keep debug data in the normal -dbg packages, you will always get ptest debug data installed in your image when defining distro-feature ptest, even if it doesn't include any -ptest packages. That feels wrong to me. -- Björn ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] gcc-cross-initial Failure
On 05/04/13 18:03, Khem Raj wrote: On Apr 5, 2013, at 9:36 AM, Jack Mitchell m...@communistcode.co.uk wrote: I build for the beaglebone and I changed them in line with your default beaglebone build patch you posted a week or so ago. I think it moved it form soft to hard float possibly... yes do a clean build if possible Hi Khem, Clean build results in the same failure. Host GCC: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /build/src/gcc-4.8.0/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --enable-gnu-unique-object --enable-linker-build-id --enable-cloog-backend=isl --disable-cloog-version-check --enable-lto --enable-gold --enable-ld=default --enable-plugin --with-plugin-ld=ld.gold --with-linker-hash-style=gnu --disable-install-libiberty --disable-multilib --disable-libssp --disable-werror --enable-checking=release Thread model: posix gcc version 4.8.0 (GCC) Tune: DEFAULTTUNE_beaglebone = cortexa8hf-neon Cheers, -- Jack Mitchell (j...@embed.me.uk) Embedded Systems Engineer http://www.embed.me.uk -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/2] rename libpng_1.2.50 to libpng12
Rename libpng_1.2.50 to libpng12 that multi-versions libpng could coexist.
The following changes since commit 6d4d42d63db4c3fcffd831ce359599f3ee1d710e:
qemuimage-tests/sanity/boot: Increase timeout (2013-04-06 17:22:21 +0100)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib kangkai/libpng12
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=kangkai/libpng12
Kang Kai (2):
libpng12: rename libpng_1.2.50 to libpng12
libpng12: remove prefer version and add it to lsb packagegroup
meta/conf/distro/include/default-versions.inc |3 ---
.../packagegroups/packagegroup-core-lsb.bb |1 +
.../{libpng_1.2.50.bb = libpng12_1.2.50.bb} | 18 +++---
3 files changed, 16 insertions(+), 6 deletions(-)
rename meta/recipes-lsb4/libpng/{libpng_1.2.50.bb = libpng12_1.2.50.bb} (62%)
--
1.7.5.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] libpng12: rename libpng_1.2.50 to libpng12
As Mark's suggestion, rename libpng_1.2.50 to libpng12 that
multi-versions libpng could coexist. And drop files that conflict with
higher version.
We want to make sure we have both the old and new versions to meet LSB
compliance (for people who have that enabled) as well as the new version
for newer applications.
CC: Mark Hatle mark.ha...@windriver.com
Signed-off-by: Kang Kai kai.k...@windriver.com
---
.../{libpng_1.2.50.bb = libpng12_1.2.50.bb} | 18 +++---
1 files changed, 15 insertions(+), 3 deletions(-)
rename meta/recipes-lsb4/libpng/{libpng_1.2.50.bb = libpng12_1.2.50.bb} (62%)
diff --git a/meta/recipes-lsb4/libpng/libpng_1.2.50.bb
b/meta/recipes-lsb4/libpng/libpng12_1.2.50.bb
similarity index 62%
rename from meta/recipes-lsb4/libpng/libpng_1.2.50.bb
rename to meta/recipes-lsb4/libpng/libpng12_1.2.50.bb
index 8fdc41b..43ff75a 100644
--- a/meta/recipes-lsb4/libpng/libpng_1.2.50.bb
+++ b/meta/recipes-lsb4/libpng/libpng12_1.2.50.bb
@@ -8,14 +8,26 @@ LIC_FILES_CHKSUM =
file://LICENSE;md5=c3d807a85c09ebdff087f18b4969ff96 \
DEPENDS = zlib
PR = r0
+PN = libpng12
+S = ${WORKDIR}/libpng-${PV}
+
SRC_URI =
${SOURCEFORGE_MIRROR}/project/libpng/libpng12/${PV}/libpng-${PV}.tar.xz
SRC_URI[md5sum] = a3e00fccbfe356174ab515b5c00641c7
SRC_URI[sha256sum] =
4724f81f8c92ac7f360ad1fbf173396ea7c535923424db9fbaff07bfd9d8e8e7
+BINCONFIG_GLOB = ${PN}-config
+
inherit autotools binconfig pkgconfig
-PACKAGES =+ ${PN}12
+do_install_append() {
+ unlink ${D}/${includedir}/png.h
+ unlink ${D}/${includedir}/pngconf.h
+
+ unlink ${D}/${libdir}/libpng.la
+ unlink ${D}/${libdir}/libpng.so
+ unlink ${D}/${libdir}/libpng.a
+ unlink ${D}/${libdir}/pkgconfig/libpng.pc
-FILES_${PN}12 = ${libdir}/libpng12${SOLIBS}
-RPROVIDES_${PN}-dev += ${PN}12-dev
+ unlink ${D}/${bindir}/libpng-config
+}
--
1.7.5.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] libpng12: remove prefer version and add it to lsb packagegroup
Because rename libpng_1.2.50 to libpng, remove the perfer verion from default-versions.inc and add libpng12 to lsb packagegroup. Signed-off-by: Kang Kai kai.k...@windriver.com --- meta/conf/distro/include/default-versions.inc |3 --- .../packagegroups/packagegroup-core-lsb.bb |1 + 2 files changed, 1 insertions(+), 3 deletions(-) diff --git a/meta/conf/distro/include/default-versions.inc b/meta/conf/distro/include/default-versions.inc index 0a5b2f4..53ec2e7 100644 --- a/meta/conf/distro/include/default-versions.inc +++ b/meta/conf/distro/include/default-versions.inc @@ -9,6 +9,3 @@ PREFERRED_VERSION_python-native ?= 2.7.3 # Force the older version of liberation-fonts until we fix the fontforge issue PREFERRED_VERSION_liberation-fonts ?= 1.04 - -# Set libpng default version for linuxstdbase -PREFERRED_VERSION_libpng_linuxstdbase ?= 1.2.50 diff --git a/meta/recipes-extended/packagegroups/packagegroup-core-lsb.bb b/meta/recipes-extended/packagegroups/packagegroup-core-lsb.bb index d692a26..cf04f0f 100644 --- a/meta/recipes-extended/packagegroups/packagegroup-core-lsb.bb +++ b/meta/recipes-extended/packagegroups/packagegroup-core-lsb.bb @@ -161,6 +161,7 @@ RDEPENDS_packagegroup-core-lsb-core = \ ncurses \ zlib \ nspr \ +libpng12 \ SUMMARY_packagegroup-core-lsb-perl = LSB Runtime Languages (Perl) -- 1.7.5.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: gstreamer 1.0 recipes
Op 8 apr. 2013, om 01:38 heeft Carlos Rafael Giani d...@pseudoterminal.org het volgende geschreven: to start working with GStreamer 1.0 on several embedded platforms, I decided to adapt the existing GStreamer recipes from danny for 1.0. Out of this I created a layer, which is hosted at https://github.com/dv1/meta-gstreamer1.0 . I write this RFC, because I figure that GStreamer 1.0 support is already on TODO lists of several people, and will eventually end up in OE-Core, just like GStreamer 0.10 did. Excellent! I'd love to see this merged into oe-core as soon as we've branched for 1.4. I built the packages for several platforms (cubox, beagleboard, imx6), and they worked well. Since 1.0 has been designed to be able to coexist with 0.10 in the same rootfs, I changed the naming convention for the packages: they all start with gstreamer1.0- . Perfect. * gstreamer: check_fix.patch (I could not reproduce the documented problem), and gstregistrybin.c/.h (why are these present?) The binary registry stuff is upstream now I think. * gst-plugins-base: configure.ac-fix-subparse-plugin.patch (not sure what this is trying to fix, and this line does not exist in 1.0), and gst-plugins-base-tremor.patch (again, works well without it) Fine, is there are problems we'll soon find them again. :) I am also considering some kind of autodetection for when yasm and liborc are available (for example, because meta-oe was added to bblayers.conf), and then switches on Orc and enables yasm in gst-libav. Or better yet, if libav is available as a recipe, it lets gst-libav use it instead of its internal copy. These autodetections would improve performance significantly. Build-time autodetection has to also be deterministic, i.e. it examines the MACHINE and layers instead of poking at the sysroot. So... On 8 April 2013 08:57, Koen Kooi k...@dominion.thruhere.net wrote: I've been meaning to ask the same questions, since I need both orc and external libav to make gstreamer (0.10, but still) useable on my platforms. I came up with the following ideas: 1) Make every external dep a PACKAGECONFIG option in OE-core gstreamer 2) Add bbappends with extra PACKAGECONFIG options for gstreamer in the layer that has the external dep 3) add bbappens in the DISTRO layer that enables extra external dependencies. Angstrom is currently using 3) and I absolutely hate it. 2) is scales a lot better, but apparently is verboten judging from the patches sent that remove the qt bbappends that do the same. Which leaves 1), which will cause problems for most users, since they will spot the PACKAGECONFIG options but not bother to read the comments saying they need to enable extra layers. I favour 1) since that has all the knowledge in a single place, looked after by the OE gst maintainer (which we don't have yet, but still). (1) definitely needs to happen in my opinion I'm not a massive fan of (2) in general as it leads to stuff changing simply by adding a layer - you may pull in meta-oe for some other packages but suddenly the GStreamer package is pulling in more dependencies. I guess for things like GStreamer where the dependencies are generally isolated into separate packages this is less of an issue though. Ross ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: gstreamer 1.0 recipes
On Monday 08 April 2013 12:47:51 Koen Kooi wrote: Op 8 apr. 2013, om 11:35 heeft Burton, Ross ross.bur...@intel.com het volgende geschreven: On 8 April 2013 08:57, Koen Kooi k...@dominion.thruhere.net wrote: I've been meaning to ask the same questions, since I need both orc and external libav to make gstreamer (0.10, but still) useable on my platforms. I came up with the following ideas: 1) Make every external dep a PACKAGECONFIG option in OE-core gstreamer 2) Add bbappends with extra PACKAGECONFIG options for gstreamer in the layer that has the external dep 3) add bbappens in the DISTRO layer that enables extra external dependencies. Angstrom is currently using 3) and I absolutely hate it. 2) is scales a lot better, but apparently is verboten judging from the patches sent that remove the qt bbappends that do the same. Which leaves 1), which will cause problems for most users, since they will spot the PACKAGECONFIG options but not bother to read the comments saying they need to enable extra layers. I favour 1) since that has all the knowledge in a single place, looked after by the OE gst maintainer (which we don't have yet, but still). (1) definitely needs to happen in my opinion I'm not a massive fan of (2) in general as it leads to stuff changing simply by adding a layer - you may pull in meta-oe for some other packages but suddenly the GStreamer package is pulling in more dependencies. I guess for things like GStreamer where the dependencies are generally isolated into separate packages this is less of an issue though. Same thing is true to Qt, the *sql plugins are all subpackages. I realize 2) is unclear on wether the extra PACKAGECONFIG default to on or off. Both Qt and gstreamer have nice automated packaging of their plugins, so bbappends are generally safe to use, but both of them also have configure options that enable/disable complete libraries (e.g. QtOpenGL) that might trigger missing symbols in other libraries in Qt/gstreamer (again, QtOpenGL). So were do we as OE(-core) community draw the line for bbappends in layers? Let's be clear, we're talking about bbappends in meta-oe and other software layers. For Qt it seems to be at No bbappends allowed, but should we consider drawing it at safe plugins only? For generic layers like the ones in meta-oe I sure as hell don't want the unsafe libraries bbappends. Apart from not having its configuration changed, given how huge Qt is I want it to *not* be rebuilt just as a consequence of adding meta-oe to my bblayers.conf. (Of course I can't have that yet because the bbappends have to at least have PRINC set in them still, but as soon as PV gets bumped...). Honestly I think solution 1 is fine; in fact we already have that for some recipes. We would have had PACKAGECONFIG for these Qt SQL plugins except that as I've mentioned numbers of times, PACKAGECONFIG can't work for these three- state options. One alternative would be to auto-add DEPENDS / CFLAGS based on QT_SQL_DRIVER_FLAGS. Returning to the original topic, a case could be made for just bringing orc and libav into OE-Core. That's not going to work for every situation but we ought to be looking at these kind of things on a case-by-case basis. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: gstreamer 1.0 recipes
On 2013-04-08 13:09, Paul Eggleton wrote: Returning to the original topic, a case could be made for just bringing orc and libav into OE-Core. That's not going to work for every situation but we ought to be looking at these kind of things on a case-by-case basis. Cheers, Paul You should add yasm to that list. libav isn't happy without it ;) Carlos ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCHv2 1/2][for-danny] linux-dtb: Add simple DTB symlinks for devicetree
Ping on this set
-Original Message-
From: Maupin, Chase
Sent: Thursday, April 04, 2013 8:26 AM
To: openembedded-core@lists.openembedded.org
Cc: Maupin, Chase
Subject: [PATCHv2 1/2][for-danny] linux-dtb: Add simple DTB
symlinks for devicetree
* This is similar to the symlinks provided for the kernel image
in the /boot directory of a file system. The goal is to have
simply named symlinks in /boot that mirror the device tree
name in the kernel sources. This is so that programs like
U-Boot can easily find the default device tree binary in the
/boot directory and use that when booting the kernel.
* Use update-alternatives to handle proper creation and removal
of the symlinks.
* This patch has already been accepted into the master branch
http://cgit.openembedded.org/openembedded-
core/commit/?id=750a9554e1b85d9bd23d18e0630723c3c193c604
Signed-off-by: Chase Maupin chase.mau...@ti.com
---
* Updated in version 2
* Changed the variable names to use variables that match the
do_install and do_deploy more closely for consistency.
i.e.
using DTB_SYMLINK_NAME instead of DTB_NAME.
* The above changes were based on input from:
* Darren Hart dvh...@linux.intel.com
* Bruce Ashfield bruce.ashfi...@windriver.com
---
meta/recipes-kernel/linux/linux-dtb.inc | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-dtb.inc
b/meta/recipes-kernel/linux/linux-dtb.inc
index d39f49d..36852b5 100644
--- a/meta/recipes-kernel/linux/linux-dtb.inc
+++ b/meta/recipes-kernel/linux/linux-dtb.inc
@@ -45,3 +45,23 @@ do_deploy_append() {
done
fi
}
+
+pkg_postinst_kernel-devicetree () {
+cd /${KERNEL_IMAGEDEST}
+for DTS_FILE in ${KERNEL_DEVICETREE}
+do
+DTS_BASE_NAME=`basename ${DTS_FILE} | awk -F . '{print
$1}'`
+DTB_SYMLINK_NAME=`echo ${KERNEL_IMAGE_SYMLINK_NAME} |
sed s/${MACHINE}/${DTS_BASE_NAME}/g`
+update-alternatives --install
/${KERNEL_IMAGEDEST}/${DTS_BASE_NAME}.dtb ${DTS_BASE_NAME}.dtb
devicetree-${DTB_SYMLINK_NAME}.dtb ${KERNEL_PRIORITY} || true
+done
+}
+
+pkg_postrm_kernel-devicetree () {
+cd /${KERNEL_IMAGEDEST}
+for DTS_FILE in ${KERNEL_DEVICETREE}
+do
+DTS_BASE_NAME=`basename ${DTS_FILE} | awk -F . '{print
$1}'`
+DTB_SYMLINK_NAME=`echo ${KERNEL_IMAGE_SYMLINK_NAME} |
sed s/${MACHINE}/${DTS_BASE_NAME}/g`
+update-alternatives --remove ${DTS_BASE_NAME}.dtb
devicetree-${DTB_SYMLINK_NAME}.dtb ${KERNEL_PRIORITY} || true
+done
+}
--
1.7.0.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] tcf-agent: Use kill instead of killproc to stop agent
From: Ioana Grigoropol ioanax.grigoro...@intel.com
[Yocto #3928]
Signed-off-by: Ioana Grigoropol ioanax.grigoro...@intel.com
Signed-off-by: Bogdan Marinescu bogdan.a.marine...@intel.com
---
.../tcf-agent/tcf-agent/fix_tcf-agent.init.patch |6 --
meta/recipes-devtools/tcf-agent/tcf-agent_git.bb |2 +-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-devtools/tcf-agent/tcf-agent/fix_tcf-agent.init.patch
b/meta/recipes-devtools/tcf-agent/tcf-agent/fix_tcf-agent.init.patch
index fefaf04..8ea5b43 100644
--- a/meta/recipes-devtools/tcf-agent/tcf-agent/fix_tcf-agent.init.patch
+++ b/meta/recipes-devtools/tcf-agent/tcf-agent/fix_tcf-agent.init.patch
@@ -13,7 +13,7 @@ Upstream-Status: Inappropriate [poky-specific script]
install -c -t $(INSTALLROOT)$(INCLUDE)/tcf/services -m 644 services/*.h
--- /dev/null
+++ b/tcf-agent.init
-@@ -0,0 +1,78 @@
+@@ -0,0 +1,80 @@
+#!/bin/sh
+### BEGIN INIT INFO
+# Provides: tcf-agent
@@ -50,14 +50,16 @@ Upstream-Status: Inappropriate [poky-specific script]
+stop)
+echo -n Stopping $DAEMON_NAME:
+count=0
++pid=$(/bin/pidof $DAEMON_PATH)
+while [ -n `/bin/pidof $DAEMON_PATH` -a $count -lt 10 ] ; do
-+killproc $DAEMON_PATH /dev/null
++kill $pid /dev/null 21
+sleep 1
+RETVAL=$?
+if [ $RETVAL != 0 -o -n `/bin/pidof $DAEMON_PATH` ] ; then
+sleep 3
+fi
+count=`expr $count + 1`
++pid=$(/bin/pidof $DAEMON_PATH)
+done
+rm -f /var/lock/subsys/$DAEMON_NAME
+if [ -n `/bin/pidof $DAEMON_PATH` ] ; then
diff --git a/meta/recipes-devtools/tcf-agent/tcf-agent_git.bb
b/meta/recipes-devtools/tcf-agent/tcf-agent_git.bb
index 4d43c62..ced2b41 100644
--- a/meta/recipes-devtools/tcf-agent/tcf-agent_git.bb
+++ b/meta/recipes-devtools/tcf-agent/tcf-agent_git.bb
@@ -7,7 +7,7 @@ LIC_FILES_CHKSUM =
file://edl-v10.html;md5=522a390a83dc186513f0500543ad3679
SRCREV = 4ef94ecb927a8912c3d79ce137182247786cff8f
PV = 0.4.0+git${SRCPV}
-PR = r0
+PR = r1
SRC_URI =
git://git.eclipse.org/gitroot/tcf/org.eclipse.tcf.agent.git;protocol=git \
file://fix_ranlib.patch \
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] tcf-agent: Use kill instead of killproc to stop agent
On Mon, 2013-04-08 at 14:58 +0300, Bogdan Marinescu wrote:
From: Ioana Grigoropol ioanax.grigoro...@intel.com
Why?
[Yocto #3928]
I could read this but I shouldn't have to...
Cheers,
Richard
Signed-off-by: Ioana Grigoropol ioanax.grigoro...@intel.com
Signed-off-by: Bogdan Marinescu bogdan.a.marine...@intel.com
---
.../tcf-agent/tcf-agent/fix_tcf-agent.init.patch |6 --
meta/recipes-devtools/tcf-agent/tcf-agent_git.bb |2 +-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git
a/meta/recipes-devtools/tcf-agent/tcf-agent/fix_tcf-agent.init.patch
b/meta/recipes-devtools/tcf-agent/tcf-agent/fix_tcf-agent.init.patch
index fefaf04..8ea5b43 100644
--- a/meta/recipes-devtools/tcf-agent/tcf-agent/fix_tcf-agent.init.patch
+++ b/meta/recipes-devtools/tcf-agent/tcf-agent/fix_tcf-agent.init.patch
@@ -13,7 +13,7 @@ Upstream-Status: Inappropriate [poky-specific script]
install -c -t $(INSTALLROOT)$(INCLUDE)/tcf/services -m 644 services/*.h
--- /dev/null
+++ b/tcf-agent.init
-@@ -0,0 +1,78 @@
+@@ -0,0 +1,80 @@
+#!/bin/sh
+### BEGIN INIT INFO
+# Provides: tcf-agent
@@ -50,14 +50,16 @@ Upstream-Status: Inappropriate [poky-specific script]
+stop)
+echo -n Stopping $DAEMON_NAME:
+count=0
++pid=$(/bin/pidof $DAEMON_PATH)
+while [ -n `/bin/pidof $DAEMON_PATH` -a $count -lt 10 ] ; do
-+killproc $DAEMON_PATH /dev/null
++kill $pid /dev/null 21
+sleep 1
+RETVAL=$?
+if [ $RETVAL != 0 -o -n `/bin/pidof $DAEMON_PATH` ] ; then
+sleep 3
+fi
+count=`expr $count + 1`
++pid=$(/bin/pidof $DAEMON_PATH)
+done
+rm -f /var/lock/subsys/$DAEMON_NAME
+if [ -n `/bin/pidof $DAEMON_PATH` ] ; then
diff --git a/meta/recipes-devtools/tcf-agent/tcf-agent_git.bb
b/meta/recipes-devtools/tcf-agent/tcf-agent_git.bb
index 4d43c62..ced2b41 100644
--- a/meta/recipes-devtools/tcf-agent/tcf-agent_git.bb
+++ b/meta/recipes-devtools/tcf-agent/tcf-agent_git.bb
@@ -7,7 +7,7 @@ LIC_FILES_CHKSUM =
file://edl-v10.html;md5=522a390a83dc186513f0500543ad3679
SRCREV = 4ef94ecb927a8912c3d79ce137182247786cff8f
PV = 0.4.0+git${SRCPV}
-PR = r0
+PR = r1
SRC_URI =
git://git.eclipse.org/gitroot/tcf/org.eclipse.tcf.agent.git;protocol=git \
file://fix_ranlib.patch \
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] systemd: Set the default firmware path to enable firmware loading in udev
From: Holger Hans Peter Freyther ze...@selfish.org
After some breakage in udev the kernel gained direct firmware loading.
For older kernels (e.g. 3.2 in my case) udev still needs to load the
firmware. Firmware loading is enabled once a default firmware path is
set. Apply a compile fix from the upstream project.
---
.../systemd/systemd/199-firmware.patch | 98
meta/recipes-core/systemd/systemd_199.bb |3 +
2 files changed, 101 insertions(+)
create mode 100644 meta/recipes-core/systemd/systemd/199-firmware.patch
diff --git a/meta/recipes-core/systemd/systemd/199-firmware.patch
b/meta/recipes-core/systemd/systemd/199-firmware.patch
new file mode 100644
index 000..aaab59b
--- /dev/null
+++ b/meta/recipes-core/systemd/systemd/199-firmware.patch
@@ -0,0 +1,98 @@
+Upstream-Status: Backport
+http://cgit.freedesktop.org/systemd/systemd/patch/?id=d8d4bee76cf3b40ea923bc57d44aa0815ca9b5ff
+
+From d8d4bee76cf3b40ea923bc57d44aa0815ca9b5ff Mon Sep 17 00:00:00 2001
+From: Kay Sievers k...@vrfy.org
+Date: Thu, 28 Mar 2013 14:28:10 +
+Subject: build-sys: fix HAVE/ENABLE_FIRMWARE
+
+https://bugs.freedesktop.org/show_bug.cgi?id=62864
+---
+diff --git a/configure.ac b/configure.ac
+index 5b88bcf..e73cd5c 100644
+--- a/configure.ac
b/configure.ac
+@@ -728,6 +728,7 @@ for i in $with_firmware_path; do
+ done
+ IFS=$OLD_IFS
+ AC_SUBST(FIRMWARE_PATH)
++AS_IF([test x${FIRMWARE_PATH} != x], [ AC_DEFINE(HAVE_FIRMWARE, 1,
[Define if FIRMWARE is available]) ])
+ AM_CONDITIONAL(ENABLE_FIRMWARE, [test x${FIRMWARE_PATH} != x])
+
+ #
--
+@@ -736,7 +737,6 @@ AC_ARG_ENABLE([gudev],
+[], [enable_gudev=yes])
+ AS_IF([test x$enable_gudev = xyes], [ PKG_CHECK_MODULES([GLIB], [glib-2.0
= 2.22.0 gobject-2.0 = 2.22.0 gio-2.0]) ])
+ AM_CONDITIONAL([ENABLE_GUDEV], [test x$enable_gudev = xyes])
+-
+ AS_IF([test x$enable_gudev = xyes], [ AC_DEFINE(HAVE_GLIB, 1, [Define if
glib is available]) ])
+
+ #
--
+diff --git a/src/udev/udev-builtin.c b/src/udev/udev-builtin.c
+index 13922d3..c7d4319 100644
+--- a/src/udev/udev-builtin.c
b/src/udev/udev-builtin.c
+@@ -34,7 +34,7 @@ static const struct udev_builtin *builtins[] = {
+ [UDEV_BUILTIN_BLKID] = udev_builtin_blkid,
+ #endif
+ [UDEV_BUILTIN_BTRFS] = udev_builtin_btrfs,
+-#ifdef ENABLE_FIRMWARE
++#ifdef HAVE_FIRMWARE
+ [UDEV_BUILTIN_FIRMWARE] = udev_builtin_firmware,
+ #endif
+ [UDEV_BUILTIN_HWDB] = udev_builtin_hwdb,
+diff --git a/src/udev/udev.h b/src/udev/udev.h
+index aa2edbe..906dfba 100644
+--- a/src/udev/udev.h
b/src/udev/udev.h
+@@ -140,7 +140,7 @@ enum udev_builtin_cmd {
+ UDEV_BUILTIN_BLKID,
+ #endif
+ UDEV_BUILTIN_BTRFS,
+-#ifdef ENABLE_FIRMWARE
++#ifdef HAVE_FIRMWARE
+ UDEV_BUILTIN_FIRMWARE,
+ #endif
+ UDEV_BUILTIN_HWDB,
+@@ -169,7 +169,7 @@ struct udev_builtin {
+ extern const struct udev_builtin udev_builtin_blkid;
+ #endif
+ extern const struct udev_builtin udev_builtin_btrfs;
+-#ifdef ENABLE_FIRMWARE
++#ifdef HAVE_FIRMWARE
+ extern const struct udev_builtin udev_builtin_firmware;
+ #endif
+ extern const struct udev_builtin udev_builtin_hwdb;
+diff --git a/src/udev/udevd.c b/src/udev/udevd.c
+index b30bedf..2ad7388 100644
+--- a/src/udev/udevd.c
b/src/udev/udevd.c
+@@ -98,7 +98,7 @@ struct event {
+ dev_t devnum;
+ int ifindex;
+ bool is_block;
+-#ifdef ENABLE_FIRMWARE
++#ifdef HAVE_FIRMWARE
+ bool nodelay;
+ #endif
+ };
+@@ -444,7 +444,7 @@ static int event_queue_insert(struct udev_device *dev)
+ event-devnum = udev_device_get_devnum(dev);
+ event-is_block = streq(block, udev_device_get_subsystem(dev));
+ event-ifindex = udev_device_get_ifindex(dev);
+-#ifdef ENABLE_FIRMWARE
++#ifdef HAVE_FIRMWARE
+ if (streq(udev_device_get_subsystem(dev), firmware))
+ event-nodelay = true;
+ #endif
+@@ -527,7 +527,7 @@ static bool is_devpath_busy(struct event *event)
+ return true;
+ }
+
+-#ifdef ENABLE_FIRMWARE
++#ifdef HAVE_FIRMWARE
+ /* allow to bypass the dependency tracking */
+ if (event-nodelay)
+ continue;
+--
+cgit v0.9.0.2-2-gbebe
diff --git a/meta/recipes-core/systemd/systemd_199.bb
b/meta/recipes-core/systemd/systemd_199.bb
index e574548..2464b83 100644
--- a/meta/recipes-core/systemd/systemd_199.bb
+++ b/meta/recipes-core/systemd/systemd_199.bb
@@ -9,6 +9,7 @@ LIC_FILES_CHKSUM =
file://LICENSE.GPL2;md5=751419260aa954499f7abaabaa882bbe \
PROVIDES = udev
PE = 1
+PR = r2
DEPENDS = kmod docbook-sgml-dtd-4.1-native intltool-native gperf-native acl
readline dbus libcap libcgroup tcp-wrappers glib-2.0
DEPENDS += ${@base_contains('DISTRO_FEATURES', 'pam', 'libpam', '', d)}
@@ -26,6 +27,7 @@ SRC_URI =
[OE-core] [PATCH v2] tcf-agent: Use kill instead of killproc to stop agent
From: Ioana Grigoropol ioanax.grigoro...@intel.com
When shutting down a core-image-lsb-sdk image, there is a lot of time spend
stopping tcf-agent,
which slows down the whole process. The reason for this slowdown is the fact
that it tries in a
loop to kill tcf-agent service by using killproc with the path of the
executable and killproc
does not seem to available in lsb images. This patch fixes the issue by using
kill instead of
killproc.
[Yocto #3928]
Signed-off-by: Ioana Grigoropol ioanax.grigoro...@intel.com
Signed-off-by: Bogdan Marinescu bogdan.a.marine...@intel.com
---
.../tcf-agent/tcf-agent/fix_tcf-agent.init.patch |6 --
meta/recipes-devtools/tcf-agent/tcf-agent_git.bb |2 +-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-devtools/tcf-agent/tcf-agent/fix_tcf-agent.init.patch
b/meta/recipes-devtools/tcf-agent/tcf-agent/fix_tcf-agent.init.patch
index fefaf04..8ea5b43 100644
--- a/meta/recipes-devtools/tcf-agent/tcf-agent/fix_tcf-agent.init.patch
+++ b/meta/recipes-devtools/tcf-agent/tcf-agent/fix_tcf-agent.init.patch
@@ -13,7 +13,7 @@ Upstream-Status: Inappropriate [poky-specific script]
install -c -t $(INSTALLROOT)$(INCLUDE)/tcf/services -m 644 services/*.h
--- /dev/null
+++ b/tcf-agent.init
-@@ -0,0 +1,78 @@
+@@ -0,0 +1,80 @@
+#!/bin/sh
+### BEGIN INIT INFO
+# Provides: tcf-agent
@@ -50,14 +50,16 @@ Upstream-Status: Inappropriate [poky-specific script]
+stop)
+echo -n Stopping $DAEMON_NAME:
+count=0
++pid=$(/bin/pidof $DAEMON_PATH)
+while [ -n `/bin/pidof $DAEMON_PATH` -a $count -lt 10 ] ; do
-+killproc $DAEMON_PATH /dev/null
++kill $pid /dev/null 21
+sleep 1
+RETVAL=$?
+if [ $RETVAL != 0 -o -n `/bin/pidof $DAEMON_PATH` ] ; then
+sleep 3
+fi
+count=`expr $count + 1`
++pid=$(/bin/pidof $DAEMON_PATH)
+done
+rm -f /var/lock/subsys/$DAEMON_NAME
+if [ -n `/bin/pidof $DAEMON_PATH` ] ; then
diff --git a/meta/recipes-devtools/tcf-agent/tcf-agent_git.bb
b/meta/recipes-devtools/tcf-agent/tcf-agent_git.bb
index 4d43c62..ced2b41 100644
--- a/meta/recipes-devtools/tcf-agent/tcf-agent_git.bb
+++ b/meta/recipes-devtools/tcf-agent/tcf-agent_git.bb
@@ -7,7 +7,7 @@ LIC_FILES_CHKSUM =
file://edl-v10.html;md5=522a390a83dc186513f0500543ad3679
SRCREV = 4ef94ecb927a8912c3d79ce137182247786cff8f
PV = 0.4.0+git${SRCPV}
-PR = r0
+PR = r1
SRC_URI =
git://git.eclipse.org/gitroot/tcf/org.eclipse.tcf.agent.git;protocol=git \
file://fix_ranlib.patch \
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] tcf-agent: Use kill instead of killproc to stop agent
On Mon, Apr 8, 2013 at 3:16 PM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
On Mon, 2013-04-08 at 14:58 +0300, Bogdan Marinescu wrote:
From: Ioana Grigoropol ioanax.grigoro...@intel.com
Why?
Because she is the author of the patch, I've just added a signed-off-by
line.
[Yocto #3928]
I could read this but I shouldn't have to...
I've sent the second version of the patch to address this issue.
Thanks,
Bogdan
Cheers,
Richard
Signed-off-by: Ioana Grigoropol ioanax.grigoro...@intel.com
Signed-off-by: Bogdan Marinescu bogdan.a.marine...@intel.com
---
.../tcf-agent/tcf-agent/fix_tcf-agent.init.patch |6 --
meta/recipes-devtools/tcf-agent/tcf-agent_git.bb |2 +-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git
a/meta/recipes-devtools/tcf-agent/tcf-agent/fix_tcf-agent.init.patch
b/meta/recipes-devtools/tcf-agent/tcf-agent/fix_tcf-agent.init.patch
index fefaf04..8ea5b43 100644
--- a/meta/recipes-devtools/tcf-agent/tcf-agent/fix_tcf-agent.init.patch
+++ b/meta/recipes-devtools/tcf-agent/tcf-agent/fix_tcf-agent.init.patch
@@ -13,7 +13,7 @@ Upstream-Status: Inappropriate [poky-specific script]
install -c -t $(INSTALLROOT)$(INCLUDE)/tcf/services -m 644
services/*.h
--- /dev/null
+++ b/tcf-agent.init
-@@ -0,0 +1,78 @@
+@@ -0,0 +1,80 @@
+#!/bin/sh
+### BEGIN INIT INFO
+# Provides: tcf-agent
@@ -50,14 +50,16 @@ Upstream-Status: Inappropriate [poky-specific script]
+stop)
+echo -n Stopping $DAEMON_NAME:
+count=0
++pid=$(/bin/pidof $DAEMON_PATH)
+while [ -n `/bin/pidof $DAEMON_PATH` -a $count -lt 10 ] ; do
-+killproc $DAEMON_PATH /dev/null
++kill $pid /dev/null 21
+sleep 1
+RETVAL=$?
+if [ $RETVAL != 0 -o -n `/bin/pidof $DAEMON_PATH` ] ;
then
+sleep 3
+fi
+count=`expr $count + 1`
++pid=$(/bin/pidof $DAEMON_PATH)
+done
+rm -f /var/lock/subsys/$DAEMON_NAME
+if [ -n `/bin/pidof $DAEMON_PATH` ] ; then
diff --git
a/meta/recipes-devtools/tcf-agent/tcf-agent_git.bbb/meta/recipes-devtools/tcf-agent/
tcf-agent_git.bb
index 4d43c62..ced2b41 100644
--- a/meta/recipes-devtools/tcf-agent/tcf-agent_git.bb
+++ b/meta/recipes-devtools/tcf-agent/tcf-agent_git.bb
@@ -7,7 +7,7 @@ LIC_FILES_CHKSUM =
file://edl-v10.html;md5=522a390a83dc186513f0500543ad3679
SRCREV = 4ef94ecb927a8912c3d79ce137182247786cff8f
PV = 0.4.0+git${SRCPV}
-PR = r0
+PR = r1
SRC_URI = git://
git.eclipse.org/gitroot/tcf/org.eclipse.tcf.agent.git;protocol=git \
file://fix_ranlib.patch \
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] bluez4: add readline dependency
From: Alexandru DAMIAN alexandru.dam...@intel.com
bluez4 uses readline to be build, but the dependency is not listed
This is listed in the configuration log.
So we add it.
Signed-off-by: Alexandru DAMIAN alexandru.dam...@intel.com
---
meta/recipes-connectivity/bluez/bluez4.inc |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-connectivity/bluez/bluez4.inc
b/meta/recipes-connectivity/bluez/bluez4.inc
index bff24d3..42d82b0 100644
--- a/meta/recipes-connectivity/bluez/bluez4.inc
+++ b/meta/recipes-connectivity/bluez/bluez4.inc
@@ -7,7 +7,7 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=12f884d2ae1ff87c09e5b7ccc2c4ca7e \
file://COPYING.LIB;md5=fb504b67c50331fc78734fed90fb0e09 \
file://src/main.c;beginline=1;endline=24;md5=9bc54b93cd7e17bf03f52513f39f926e \
file://sbc/sbc.c;beginline=1;endline=25;md5=1a40781ed30d50d8639323a184aeb191
-DEPENDS = udev libusb dbus-glib glib-2.0 libcheck
+DEPENDS = udev libusb dbus-glib glib-2.0 libcheck readline
RDEPENDS_${PN}-dev = bluez-hcidump
PACKAGECONFIG ??= \
--
1.7.10.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] base.bbclass: Fix matching of SOC_FAMILY in COMPATIBLE_MACHINE
On Sun, Apr 7, 2013 at 2:37 AM, Eric Bénard e...@eukrea.com wrote:
Le Sat, 6 Apr 2013 17:58:30 -0300,
Otavio Salvador ota...@ossystems.com.br a écrit :
On Sat, Apr 6, 2013 at 3:02 PM, Eric Bénard e...@eukrea.com wrote:
Hi Otavio,
Le Sat, 6 Apr 2013 14:17:48 -0300,
Otavio Salvador ota...@ossystems.com.br a écrit :
When a SOC_FAMILY has more than one value, split by ':' as usual
OVERRIDES, this were not being properly checked in COMPATIBLE_MACHINE
matching as we need to iterate over each SoC family and check if it is
compatible or not.
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
meta/classes/base.bbclass | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index abd6a52..6f24064 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -515,11 +515,13 @@ python () {
need_machine = d.getVar('COMPATIBLE_MACHINE', True)
if need_machine:
import re
-this_machine = d.getVar('MACHINE', True)
-if this_machine and not re.match(need_machine, this_machine):
-this_soc_family = d.getVar('SOC_FAMILY', True)
-if (this_soc_family and not re.match(need_machine,
this_soc_family)) or not this_soc_family:
-raise bb.parse.SkipPackage(incompatible with
machine %s (not in COMPATIBLE_MACHINE) % this_machine)
+compat_machines = [d.getVar('MACHINE', True)]
+compat_machines.extend((d.getVar('SOC_FAMILY', True) or
).split(:))
+for this_machine in compat_machines:
+if re.match(need_machine, this_machine):
+break
+else:
+raise bb.parse.SkipPackage(incompatible with machine %s
(not in COMPATIBLE_MACHINE) % this_machine)
aren't you breaking this log here vs what is was supposed to
print before ?
The 'else' is used when no 'break' is done inside of for loop.
but will this_machine contain the value of the MACHINE variable ?
Yes, check:
...
+compat_machines = [d.getVar('MACHINE', True)]
+compat_machines.extend((d.getVar('SOC_FAMILY', True) or
).split(:))
...
--
Otavio Salvador O.S. Systems
E-mail: ota...@ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] alsa-tools: fix build when x11 and gtk+ not available
With a rather recent HEAD Build Configuration: BB_VERSION= 1.17.1 BUILD_SYS = x86_64-linux NATIVELSBSTRING = openSUSE-project-12.3 TARGET_SYS= x86_64-poky-linux MACHINE = qemux86-64 DISTRO= poky DISTRO_VERSION= 1.3+snapshot-20130407 TUNE_FEATURES = m64 TARGET_FPU= meta meta-yocto meta-yocto-bsp= master:813127247a1100b1abe179dfba25795560eac864 I am able to successfully perform a bitbake world on a number of different targets: - qemux86 - qemuarm - qemumips - qemux86-64 Unfortunately qemuppc fails when building alsa-tools. Is anyone else seeing the same thing? | make[1]: Entering directory `/home/trevor/build/yocto/fullbuild/qemuppc/work/ppc603e-poky-linux/alsa-tools/1.0.26.1-r1/alsa-tools-1.0.26.1/hda-verb' | make[1]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule. | powerpc-poky-linux-gcc -m32 -mhard-float -mcpu=603e --sysroot=/home/trevor/build/yocto/fullbuild/qemuppc/sysroots/qemuppc -DPACKAGE_NAME=\\ -DPACKAGE_TARNAME=\\ -DPACKAGE_VERSION=\\ -DPACKAGE_STRING=\\ -DPACKAGE_BUGREPORT=\\ -DPACKAGE_URL=\\ -DPACKAGE=\hda-verb\ -DVERSION=\0.4\ -DSTDC_HEADERS=1 -I. -O2 -Wall -pipe -g -MT hda-verb.o -MD -MP -MF .deps/hda-verb.Tpo -c -o hda-verb.o hda-verb.c | hda-verb.c:17:20: fatal error: sys/io.h: No such file or directory | compilation terminated. | make[1]: *** [hda-verb.o] Error 1 | make[1]: Leaving directory `/home/trevor/build/yocto/fullbuild/qemuppc/work/ppc603e-poky-linux/alsa-tools/1.0.26.1-r1/alsa-tools-1.0.26.1/hda-verb' | make: *** [all] Error 1 | ERROR: oe_runmake failed ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] base.bbclass: Fix matching of SOC_FAMILY in COMPATIBLE_MACHINE
Hi Otavio,
Le Mon, 8 Apr 2013 10:31:17 -0300,
Otavio Salvador ota...@ossystems.com.br a écrit :
On Sun, Apr 7, 2013 at 2:37 AM, Eric Bénard e...@eukrea.com wrote:
Le Sat, 6 Apr 2013 17:58:30 -0300,
Otavio Salvador ota...@ossystems.com.br a écrit :
On Sat, Apr 6, 2013 at 3:02 PM, Eric Bénard e...@eukrea.com wrote:
Hi Otavio,
Le Sat, 6 Apr 2013 14:17:48 -0300,
Otavio Salvador ota...@ossystems.com.br a écrit :
+compat_machines = [d.getVar('MACHINE', True)]
+compat_machines.extend((d.getVar('SOC_FAMILY', True) or
).split(:))
+for this_machine in compat_machines:
+if re.match(need_machine, this_machine):
+break
+else:
+raise bb.parse.SkipPackage(incompatible with machine
%s (not in COMPATIBLE_MACHINE) % this_machine)
aren't you breaking this log here vs what is was supposed to
print before ?
The 'else' is used when no 'break' is done inside of for loop.
but will this_machine contain the value of the MACHINE variable ?
Yes, check:
...
+compat_machines = [d.getVar('MACHINE', True)]
+compat_machines.extend((d.getVar('SOC_FAMILY', True) or
).split(:))
...
I'm not very experienced in python so sorry is that's a stupid
remark but after these lines you are using this_machine to go
through the content of compat_machines so in the end, when it reach the
log message it will contain the last value in compat_machine (and thus
the last one in SOC_FAMILY instead of the machine name) ?
Eric
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] base.bbclass: Fix matching of SOC_FAMILY in COMPATIBLE_MACHINE
On Mon, Apr 8, 2013 at 10:37 AM, Eric Bénard e...@eukrea.com wrote:
Hi Otavio,
Le Mon, 8 Apr 2013 10:31:17 -0300,
Otavio Salvador ota...@ossystems.com.br a écrit :
On Sun, Apr 7, 2013 at 2:37 AM, Eric Bénard e...@eukrea.com wrote:
Le Sat, 6 Apr 2013 17:58:30 -0300,
Otavio Salvador ota...@ossystems.com.br a écrit :
On Sat, Apr 6, 2013 at 3:02 PM, Eric Bénard e...@eukrea.com wrote:
Hi Otavio,
Le Sat, 6 Apr 2013 14:17:48 -0300,
Otavio Salvador ota...@ossystems.com.br a écrit :
+compat_machines = [d.getVar('MACHINE', True)]
+compat_machines.extend((d.getVar('SOC_FAMILY', True) or
).split(:))
+for this_machine in compat_machines:
+if re.match(need_machine, this_machine):
+break
+else:
+raise bb.parse.SkipPackage(incompatible with machine
%s (not in COMPATIBLE_MACHINE) % this_machine)
aren't you breaking this log here vs what is was supposed to
print before ?
The 'else' is used when no 'break' is done inside of for loop.
but will this_machine contain the value of the MACHINE variable ?
Yes, check:
...
+compat_machines = [d.getVar('MACHINE', True)]
+compat_machines.extend((d.getVar('SOC_FAMILY', True) or
).split(:))
...
I'm not very experienced in python so sorry is that's a stupid
remark but after these lines you are using this_machine to go
through the content of compat_machines so in the end, when it reach the
log message it will contain the last value in compat_machine (and thus
the last one in SOC_FAMILY instead of the machine name) ?
Indeed this is indeed a bug. I will follow-up with a proper fix for it.
--
Otavio Salvador O.S. Systems
E-mail: ota...@ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] base.bbclass: Fix matching of SOC_FAMILY in COMPATIBLE_MACHINE
When a SOC_FAMILY has more than one value, split by ':' as usual
OVERRIDES, this were not being properly checked in COMPATIBLE_MACHINE
matching as we need to iterate over each SoC family and check if it is
compatible or not.
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
Changes for v2:
- Properly handle machine so the error message clearly cite the right
machine name (Eric)
meta/classes/base.bbclass | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index abd6a52..080caa8 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -516,10 +516,13 @@ python () {
if need_machine:
import re
this_machine = d.getVar('MACHINE', True)
-if this_machine and not re.match(need_machine, this_machine):
-this_soc_family = d.getVar('SOC_FAMILY', True)
-if (this_soc_family and not re.match(need_machine,
this_soc_family)) or not this_soc_family:
-raise bb.parse.SkipPackage(incompatible with machine %s
(not in COMPATIBLE_MACHINE) % this_machine)
+compat_machines = [this_machine]
+compat_machines.extend((d.getVar('SOC_FAMILY', True) or
).split(:))
+for m in compat_machines:
+if re.match(need_machine, m):
+break
+else:
+raise bb.parse.SkipPackage(incompatible with machine %s (not
in COMPATIBLE_MACHINE) % this_machine)
bad_licenses = (d.getVar('INCOMPATIBLE_LICENSE', True) or ).split()
--
1.8.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] udev: Move udevd back to /sbin
Fixes [Yocto #4046]
Signed-off-by: Radu Moisan radu.moi...@intel.com
---
meta/recipes-core/udev/udev.inc|3 ++-
meta/recipes-core/udev/udev_182.bb |2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/udev/udev.inc b/meta/recipes-core/udev/udev.inc
index e358d2d..c4d2ce4 100644
--- a/meta/recipes-core/udev/udev.inc
+++ b/meta/recipes-core/udev/udev.inc
@@ -40,7 +40,7 @@ EXTRA_OECONF = --disable-introspection \
ac_cv_file__usr_share_hwdata_pci_ids=no \
ac_cv_file__usr_share_misc_pci_ids=yes \
--sbindir=${base_sbindir} \
---libexecdir=${base_libdir} \
+--libexecdir=${base_sbindir} \
--with-rootlibdir=${base_libdir} \
--with-rootprefix= \
@@ -61,6 +61,7 @@ RRECOMMENDS_${PN} += udev-utils
FILES_${PN}-dbg += ${libexecdir}/.debug
FILES_${PN}-dbg += ${base_libdir}/udev/.debug/
FILES_${PN}-dbg += ${base_libdir}/udev/.debug/*
+FILES_${PN}-dbg += ${base_sbindir}/udev/.debug/*
FILES_${PN}-dev = ${datadir}/pkgconfig/udev.pc
FILES_libudev = ${base_libdir}/libudev.so.*
FILES_libudev-dbg = ${base_libdir}/.debug/libudev.so.*
diff --git a/meta/recipes-core/udev/udev_182.bb
b/meta/recipes-core/udev/udev_182.bb
index 42b4d08..d66292e 100644
--- a/meta/recipes-core/udev/udev_182.bb
+++ b/meta/recipes-core/udev/udev_182.bb
@@ -1,6 +1,6 @@
include udev.inc
-PR = r6
+PR = r7
# module-init-tools from kmod_git will provide libkmod runtime
DEPENDS += module-init-tools
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] smart: disable CHANNELSDIR
Make CHANNELSDIR in smart empty, since this causes host contamination issues on some RPM-based hosts on which smart is already installed. [YOCTO #3881] Signed-off-by: Bogdan Marinescu bogdan.a.marine...@intel.com --- .../python/python-smartpm/smart-channelsdir.patch | 24 ++ .../python/python-smartpm_1.4.1.bb | 3 ++- 2 files changed, 26 insertions(+), 1 deletion(-) create mode 100644 meta/recipes-devtools/python/python-smartpm/smart-channelsdir.patch diff --git a/meta/recipes-devtools/python/python-smartpm/smart-channelsdir.patch b/meta/recipes-devtools/python/python-smartpm/smart-channelsdir.patch new file mode 100644 index 000..e621b33 --- /dev/null +++ b/meta/recipes-devtools/python/python-smartpm/smart-channelsdir.patch @@ -0,0 +1,24 @@ +Make CHANNELSDIR in smart empty, since this causes host contamination issues +on some RPM-based hosts on which smart is already installed. + +[YOCTO #3881] + +Upstream-Status: Inappropriate [embedded specific] + +diff --git a/smart/plugins/channelsync.py b/smart/plugins/channelsync.py +index 3ba95ff..646d696 100644 +--- a/smart/plugins/channelsync.py b/smart/plugins/channelsync.py +@@ -23,7 +23,11 @@ from smart.channel import * + from smart import * + import os + +-CHANNELSDIR = /etc/smart/channels/ ++# For now, we leave the definition of CHANNELSDIR empty. This prevents smart ++# from erroneously consider the build host's channels while setting up its ++# channels [YOCTO #3881]. If this feature will be used in the future, CHANNELSDIR ++# should be set to a proper value. ++CHANNELSDIR = + + def syncChannels(channelsdir, force=None): + diff --git a/meta/recipes-devtools/python/python-smartpm_1.4.1.bb b/meta/recipes-devtools/python/python-smartpm_1.4.1.bb index d92933f..001d9e4 100644 --- a/meta/recipes-devtools/python/python-smartpm_1.4.1.bb +++ b/meta/recipes-devtools/python/python-smartpm_1.4.1.bb @@ -11,7 +11,7 @@ LICENSE = GPLv2 LIC_FILES_CHKSUM = file://LICENSE;md5=393a5ca445f6965873eca0259a17f833 DEPENDS = python rpm -PR = r8 +PR = r9 SRCNAME = smart SRC_URI = \ @@ -27,6 +27,7 @@ SRC_URI = \ file://smart-improve-error-reporting.patch \ file://smart-multilib-fixes.patch \ file://smart-yaml-error.patch \ + file://smart-channelsdir.patch \ SRC_URI[md5sum] = 573ef32ba177a6b3c4bf7ef04873fcb6 -- 1.8.1.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] libpng12: rename libpng_1.2.50 to libpng12
On 4/8/13 4:12 AM, Kang Kai wrote:
As Mark's suggestion, rename libpng_1.2.50 to libpng12 that
multi-versions libpng could coexist. And drop files that conflict with
higher version.
We want to make sure we have both the old and new versions to meet LSB
compliance (for people who have that enabled) as well as the new version
for newer applications.
CC: Mark Hatle mark.ha...@windriver.com
Signed-off-by: Kang Kai kai.k...@windriver.com
---
.../{libpng_1.2.50.bb = libpng12_1.2.50.bb} | 18 +++---
1 files changed, 15 insertions(+), 3 deletions(-)
rename meta/recipes-lsb4/libpng/{libpng_1.2.50.bb = libpng12_1.2.50.bb} (62%)
diff --git a/meta/recipes-lsb4/libpng/libpng_1.2.50.bb
b/meta/recipes-lsb4/libpng/libpng12_1.2.50.bb
similarity index 62%
rename from meta/recipes-lsb4/libpng/libpng_1.2.50.bb
rename to meta/recipes-lsb4/libpng/libpng12_1.2.50.bb
index 8fdc41b..43ff75a 100644
--- a/meta/recipes-lsb4/libpng/libpng_1.2.50.bb
+++ b/meta/recipes-lsb4/libpng/libpng12_1.2.50.bb
@@ -8,14 +8,26 @@ LIC_FILES_CHKSUM =
file://LICENSE;md5=c3d807a85c09ebdff087f18b4969ff96 \
DEPENDS = zlib
PR = r0
+PN = libpng12
+S = ${WORKDIR}/libpng-${PV}
+
SRC_URI =
${SOURCEFORGE_MIRROR}/project/libpng/libpng12/${PV}/libpng-${PV}.tar.xz
SRC_URI[md5sum] = a3e00fccbfe356174ab515b5c00641c7
SRC_URI[sha256sum] =
4724f81f8c92ac7f360ad1fbf173396ea7c535923424db9fbaff07bfd9d8e8e7
+BINCONFIG_GLOB = ${PN}-config
+
inherit autotools binconfig pkgconfig
-PACKAGES =+ ${PN}12
+do_install_append() {
+ unlink ${D}/${includedir}/png.h
+ unlink ${D}/${includedir}/pngconf.h
You should move those two into a subdirectory called
${D}/${includedir}/libpng12/
That way they will still be available for anyone who needs them.
+
+ unlink ${D}/${libdir}/libpng.la
+ unlink ${D}/${libdir}/libpng.so
+ unlink ${D}/${libdir}/libpng.a
The .la, .a seen above should be similarly renamed to be libpng12... The .so
should be dropped, as anyone who needs the alternative version would need to
directly specify it.
+ unlink ${D}/${libdir}/pkgconfig/libpng.pc
Should be renamed to be libpng12.pc.
(Note both the .la and .pc files will likely need to be modified to reference
the correct header and library paths.)
-FILES_${PN}12 = ${libdir}/libpng12${SOLIBS}
-RPROVIDES_${PN}-dev += ${PN}12-dev
+ unlink ${D}/${bindir}/libpng-config
+}
The above should be renamed to be libpng12-config.
(Again, make sure that the results of it match the renamed .a/.so and include
paths.)
--Mark
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/2] Fix postinstall fallback and create gtk-update-icon-cache wrapper script
Laurentiu Palcu (2): image.bbclass: fix postinstall intercepts fallback gtk-update-icon-cache-native: create wrapper script meta/classes/image.bbclass |2 +- .../gtk+/gtk-update-icon-cache-native_3.4.4.bb |4 2 files changed, 5 insertions(+), 1 deletion(-) -- 1.7.9.5 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] gtk-update-icon-cache-native: create wrapper script
When using the sstate from another build machine, the path to the pixbuf
loader's cache points to a path on the remote machine. Hence, the update
of the icon cache fails on host.
Signed-off-by: Laurentiu Palcu laurentiu.pa...@intel.com
---
.../gtk+/gtk-update-icon-cache-native_3.4.4.bb |4
1 file changed, 4 insertions(+)
diff --git a/meta/recipes-gnome/gtk+/gtk-update-icon-cache-native_3.4.4.bb
b/meta/recipes-gnome/gtk+/gtk-update-icon-cache-native_3.4.4.bb
index 93c30a7..73b7644 100644
--- a/meta/recipes-gnome/gtk+/gtk-update-icon-cache-native_3.4.4.bb
+++ b/meta/recipes-gnome/gtk+/gtk-update-icon-cache-native_3.4.4.bb
@@ -40,4 +40,8 @@ do_compile() {
do_install() {
install -d ${D}${bindir}
install -m 0755 ${B}/gtk-update-icon-cache ${D}${bindir}
+
+ create_wrapper ${D}/${bindir}/gtk-update-icon-cache \
+
GDK_PIXBUF_MODULE_FILE=${STAGING_LIBDIR_NATIVE}/gdk-pixbuf-2.0/2.10.0/loaders.cache
+
}
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] gst-ffmpeg: fix --disable-yasm
From: Tom Zanussi tom.zanu...@linux.intel.com The gst-ffmpeg build shows the following warning: configure: WARNING: unrecognized options: --disable-yasm which means that the following test in configure always fails and --disable-yasm never gets passed to the embedded ffmpeg build: 'if test x$disable_yasm = xyes; then' embffmpeg_configure_args=$embffmpeg_configure_args --disable-yasm commit 4d309730 ['gst-ffmpeg: configure-fix patch used wrong test'] actually fixed the obviously backwards syntax by reversing the test - prior to that, --disable-yasm would always unconditionally be passed into the embedded ffmpeg config. This fixes things so that the variable actually exists and makes the test meaningful. Signed-off-by: Tom Zanussi tom.zanu...@linux.intel.com --- .../gstreamer/gst-ffmpeg-0.10.13/configure-fix.patch| 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/meta/recipes-multimedia/gstreamer/gst-ffmpeg-0.10.13/configure-fix.patch b/meta/recipes-multimedia/gstreamer/gst-ffmpeg-0.10.13/configure-fix.patch index 2bb124b..9ef6f7c 100644 --- a/meta/recipes-multimedia/gstreamer/gst-ffmpeg-0.10.13/configure-fix.patch +++ b/meta/recipes-multimedia/gstreamer/gst-ffmpeg-0.10.13/configure-fix.patch @@ -7,11 +7,13 @@ Signed-off-by: Shane Wang shane.w...@intel.com diff -r f2f8f74c6e30 configure.ac --- a/configure.ac Thu Dec 22 23:56:09 2011 +0800 +++ b/configure.ac Thu Dec 22 23:57:37 2011 +0800 -@@ -325,6 +325,10 @@ +@@ -325,6 +325,12 @@ --enable-gpl fi -+ if test x$disable_yasm = xyes; then ++ AC_ARG_ENABLE(yasm, ++ [AC_HELP_STRING([--disable-yasm], [disable use of yasm assembler])]) ++ if test x$enable_yasm = xno; then +embffmpeg_configure_args=$embffmpeg_configure_args --disable-yasm + fi + -- 1.7.11.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] gst-ffmpeg yasm check fix
From: Tom Zanussi tom.zanu...@linux.intel.com Builds started failing here, tracked it down to commit: 4d309730 ['gst-ffmpeg: configure-fix patch used wrong test'] which essentially just has the effect of never disabling yasm instead of always disabling it as before. With this patch it can be conditionally enabled or disabled as perhaps intended. The following changes since commit 6d4d42d63db4c3fcffd831ce359599f3ee1d710e: qemuimage-tests/sanity/boot: Increase timeout (2013-04-06 17:22:21 +0100) are available in the git repository at: git://git.yoctoproject.org/poky-contrib.git tzanussi/gst-ffmpeg-yasm-check-fix http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=tzanussi/gst-ffmpeg-yasm-check-fix Tom Zanussi (1): gst-ffmpeg: fix --disable-yasm .../gstreamer/gst-ffmpeg-0.10.13/configure-fix.patch| 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) -- 1.7.11.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] udev: Move udevd back to /sbin
Op 8 apr. 2013, om 16:39 heeft Radu Moisan radu.moi...@intel.com het volgende geschreven: Fixes [Yocto #4046] Can you eloborate a bit in the commit message? ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Sanity Failures - Segfaults in qemu images
On Sun, 2013-04-07 at 15:32 -0700, Khem Raj wrote: On Sun, Apr 7, 2013 at 1:23 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: http://autobuilder.yoctoproject.org:8011/builders/nightly-x86-64-lsb/builds/87/steps/Running%20Sanity%20Tests/logs/stdio what does complete dmesg output looks like ? I have seen ld.so segfaults on real x86_64 hardware but havent narrowed it down since it does not seem to bother my testing. I don't have the full dmesg output however I have put a wealth of info about this into: https://bugzilla.yoctoproject.org/show_bug.cgi?id=4216 Basically these do look like random segfaults happening any point on the system and having a variety of effects. The double fault is particularly worrying as it suggests the problem is kernel or qemu. I've put a script which tends to reproduce the issue into the bugzilla. When you say you've seen ld.so faults on real hardware, have you any more details? Are they happening often? Just ld.so? I need to know if this is a qemu issue or on real hardware too since the latter is a release blocker and extremely serious. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] smart: disable CHANNELSDIR
On 4/8/13 10:02 AM, Bogdan Marinescu wrote: Make CHANNELSDIR in smart empty, since this causes host contamination issues on some RPM-based hosts on which smart is already installed. [YOCTO #3881] Signed-off-by: Bogdan Marinescu bogdan.a.marine...@intel.com --- .../python/python-smartpm/smart-channelsdir.patch | 24 ++ .../python/python-smartpm_1.4.1.bb | 3 ++- 2 files changed, 26 insertions(+), 1 deletion(-) create mode 100644 meta/recipes-devtools/python/python-smartpm/smart-channelsdir.patch diff --git a/meta/recipes-devtools/python/python-smartpm/smart-channelsdir.patch b/meta/recipes-devtools/python/python-smartpm/smart-channelsdir.patch new file mode 100644 index 000..e621b33 --- /dev/null +++ b/meta/recipes-devtools/python/python-smartpm/smart-channelsdir.patch @@ -0,0 +1,24 @@ +Make CHANNELSDIR in smart empty, since this causes host contamination issues +on some RPM-based hosts on which smart is already installed. + +[YOCTO #3881] + +Upstream-Status: Inappropriate [embedded specific] + +diff --git a/smart/plugins/channelsync.py b/smart/plugins/channelsync.py +index 3ba95ff..646d696 100644 +--- a/smart/plugins/channelsync.py b/smart/plugins/channelsync.py +@@ -23,7 +23,11 @@ from smart.channel import * + from smart import * + import os + +-CHANNELSDIR = /etc/smart/channels/ ++# For now, we leave the definition of CHANNELSDIR empty. This prevents smart ++# from erroneously consider the build host's channels while setting up its ++# channels [YOCTO #3881]. If this feature will be used in the future, CHANNELSDIR ++# should be set to a proper value. ++CHANNELSDIR = I don't remember if the channelsdir is used by default on the target or if there is a different directory. Did you check if (on the target) you can still add channels and do a remove install/update of a package? + + def syncChannels(channelsdir, force=None): + diff --git a/meta/recipes-devtools/python/python-smartpm_1.4.1.bb b/meta/recipes-devtools/python/python-smartpm_1.4.1.bb index d92933f..001d9e4 100644 --- a/meta/recipes-devtools/python/python-smartpm_1.4.1.bb +++ b/meta/recipes-devtools/python/python-smartpm_1.4.1.bb @@ -11,7 +11,7 @@ LICENSE = GPLv2 LIC_FILES_CHKSUM = file://LICENSE;md5=393a5ca445f6965873eca0259a17f833 DEPENDS = python rpm -PR = r8 +PR = r9 SRCNAME = smart SRC_URI = \ @@ -27,6 +27,7 @@ SRC_URI = \ file://smart-improve-error-reporting.patch \ file://smart-multilib-fixes.patch \ file://smart-yaml-error.patch \ + file://smart-channelsdir.patch \ SRC_URI[md5sum] = 573ef32ba177a6b3c4bf7ef04873fcb6 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] udev: Move udevd back to /sbin
On 04/08/2013 06:42 PM, Koen Kooi wrote: Op 8 apr. 2013, om 16:39 heeft Radu Moisan radu.moi...@intel.com het volgende geschreven: Fixes [Yocto #4046] Can you eloborate a bit in the commit message? Yes, will follow up with a v2 Radu ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] scripts/oe-pkgdata-util: find complementary packages for split packages
Check after getting the original package name (e.g. undoing Debian renaming) if there is a complementary package for that name, e.g. if the glob is *-dev, then libudev0 - libudev - libudev-dev. Fixes [YOCTO #4136]. Signed-off-by: Paul Eggleton paul.eggle...@linux.intel.com --- scripts/oe-pkgdata-util | 13 ++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/scripts/oe-pkgdata-util b/scripts/oe-pkgdata-util index 900c27a..629b2d5 100755 --- a/scripts/oe-pkgdata-util +++ b/scripts/oe-pkgdata-util @@ -115,14 +115,21 @@ def glob(args): if not os.path.exists(fwdfile + .packaged): mappedpkg = else: -# That didn't work, so now get the PN, substitute that, then map in the other direction revlink = revpkgdata(pkg) if os.path.exists(revlink): -pn = readpn(revlink) -newpkg = g.replace(*, pn) +# Check if we can map after undoing the package renaming (by resolving the symlink) +origpkg = os.path.basename(os.readlink(revlink)) +newpkg = g.replace(*, origpkg) fwdfile = fwdpkgdata(newpkg) if os.path.exists(fwdfile): mappedpkg = readrenamed(fwdfile) +else: +# That didn't work, so now get the PN, substitute that, then map in the other direction +pn = readpn(revlink) +newpkg = g.replace(*, pn) +fwdfile = fwdpkgdata(newpkg) +if os.path.exists(fwdfile): +mappedpkg = readrenamed(fwdfile) if not os.path.exists(fwdfile + .packaged): mappedpkg = else: -- 1.7.10.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] gtk-update-icon-cache-native: create wrapper script
On Mon, Apr 08, 2013 at 06:06:41PM +0300, Laurentiu Palcu wrote:
When using the sstate from another build machine, the path to the pixbuf
loader's cache points to a path on the remote machine. Hence, the update
of the icon cache fails on host.
Signed-off-by: Laurentiu Palcu laurentiu.pa...@intel.com
---
.../gtk+/gtk-update-icon-cache-native_3.4.4.bb |4
1 file changed, 4 insertions(+)
diff --git a/meta/recipes-gnome/gtk+/gtk-update-icon-cache-native_3.4.4.bb
b/meta/recipes-gnome/gtk+/gtk-update-icon-cache-native_3.4.4.bb
index 93c30a7..73b7644 100644
--- a/meta/recipes-gnome/gtk+/gtk-update-icon-cache-native_3.4.4.bb
+++ b/meta/recipes-gnome/gtk+/gtk-update-icon-cache-native_3.4.4.bb
@@ -40,4 +40,8 @@ do_compile() {
do_install() {
install -d ${D}${bindir}
install -m 0755 ${B}/gtk-update-icon-cache ${D}${bindir}
^ can you fix indentation in this line, when you're changing this file?
Thanks
JaMa (who proposed to use consistent white-space for shell/python tasks
long time ago)
+
+ create_wrapper ${D}/${bindir}/gtk-update-icon-cache \
+
GDK_PIXBUF_MODULE_FILE=${STAGING_LIBDIR_NATIVE}/gdk-pixbuf-2.0/2.10.0/loaders.cache
+
}
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] udev: Move udevd back to /sbin
Along with v182 upgrade udevd was moved to ${base_libdir}
making scripts like init-live.sh to fail in finding udevd
Fixes [Yocto #4046]
Signed-off-by: Radu Moisan radu.moi...@intel.com
---
meta/recipes-core/udev/udev.inc|3 ++-
meta/recipes-core/udev/udev_182.bb |2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/udev/udev.inc b/meta/recipes-core/udev/udev.inc
index e358d2d..c4d2ce4 100644
--- a/meta/recipes-core/udev/udev.inc
+++ b/meta/recipes-core/udev/udev.inc
@@ -40,7 +40,7 @@ EXTRA_OECONF = --disable-introspection \
ac_cv_file__usr_share_hwdata_pci_ids=no \
ac_cv_file__usr_share_misc_pci_ids=yes \
--sbindir=${base_sbindir} \
---libexecdir=${base_libdir} \
+--libexecdir=${base_sbindir} \
--with-rootlibdir=${base_libdir} \
--with-rootprefix= \
@@ -61,6 +61,7 @@ RRECOMMENDS_${PN} += udev-utils
FILES_${PN}-dbg += ${libexecdir}/.debug
FILES_${PN}-dbg += ${base_libdir}/udev/.debug/
FILES_${PN}-dbg += ${base_libdir}/udev/.debug/*
+FILES_${PN}-dbg += ${base_sbindir}/udev/.debug/*
FILES_${PN}-dev = ${datadir}/pkgconfig/udev.pc
FILES_libudev = ${base_libdir}/libudev.so.*
FILES_libudev-dbg = ${base_libdir}/.debug/libudev.so.*
diff --git a/meta/recipes-core/udev/udev_182.bb
b/meta/recipes-core/udev/udev_182.bb
index 42b4d08..d66292e 100644
--- a/meta/recipes-core/udev/udev_182.bb
+++ b/meta/recipes-core/udev/udev_182.bb
@@ -1,6 +1,6 @@
include udev.inc
-PR = r6
+PR = r7
# module-init-tools from kmod_git will provide libkmod runtime
DEPENDS += module-init-tools
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] local.conf.sample: Add info about -ptest package group
On Fri, Apr 5, 2013 at 11:35 AM, maxin.j...@enea.com wrote: +# ptest-pkgs - add -ptest packages for all ptest-enabled packages +# (useful if you want to run the package test suites) Is there a simple way to discover which packages are ptest-enabled? ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] openssl: Upgrade to v1.0.1e
On Mon, 2013-04-08 at 19:47 +0300, Radu Moisan wrote: Dropped obolete patches and pulled updates for debian patches Isn't there some CVE this upgrade fixes which would be worth a mention in here? Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] openssl: Upgrade to v1.0.1e
On 04/08/2013 07:54 PM, Richard Purdie wrote: On Mon, 2013-04-08 at 19:47 +0300, Radu Moisan wrote: Dropped obolete patches and pulled updates for debian patches Isn't there some CVE this upgrade fixes which would be worth a mention in here? With respect to what we had (1.0.0j) Scott pointed out the following http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-2686 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0166 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0169 Yocto #3965 https://bugzilla.yoctoproject.org/show_bug.cgi?id=3965 Radu ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/3] oe-buildenv-internal: Only add to $PATH if needed
On Fri, Apr 5, 2013 at 12:59 PM, Peter Kjellerstedt
peter.kjellerst...@axis.com wrote:
+[ ${PATH#$NEWPATHS} != $PATH ] || PATH=$NEWPATHS$PATH
This is certainly a welcome addition in functionality, but it relies
on the pattern remaining at the start of the PATH (i.e. the user
hasn't played with PATH in any way). Could we not use the
${parameter/pattern/string} parameter expansion instead (e.g.
${PATH/$NEWPATHS/}) so it doesn't matter whether the user has
further modified the PATH?
Best regards,
Trevor
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/3] oe-buildenv-internal: Only add to $PATH if needed
On Monday 08 April 2013 13:31:50 Trevor Woerner wrote:
On Fri, Apr 5, 2013 at 12:59 PM, Peter Kjellerstedt
peter.kjellerst...@axis.com wrote:
+[ ${PATH#$NEWPATHS} != $PATH ] || PATH=$NEWPATHS$PATH
This is certainly a welcome addition in functionality, but it relies
on the pattern remaining at the start of the PATH (i.e. the user
hasn't played with PATH in any way). Could we not use the
${parameter/pattern/string} parameter expansion instead (e.g.
${PATH/$NEWPATHS/}) so it doesn't matter whether the user has
further modified the PATH?
Unfortunately I think this is specific to bash, so it may not be portable.
Maybe the equivalent can be achieved with sed however.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] bluez4: add readline dependency
On 04/08/2013 05:56 AM, Alex DAMIAN wrote:
From: Alexandru DAMIAN alexandru.dam...@intel.com
bluez4 uses readline to be build, but the dependency is not listed
This is listed in the configuration log.
So we add it.
As far as I can tell it's needed only for gatttool, is this a tool that
we need / want to provide for bluez?
This seems to be a tools for viewing the Generic Attribute Profile (GATT).
It can be disabled by setting ac_cv_lib_readline_main=no
Sau!
Signed-off-by: Alexandru DAMIAN alexandru.dam...@intel.com
---
meta/recipes-connectivity/bluez/bluez4.inc |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-connectivity/bluez/bluez4.inc
b/meta/recipes-connectivity/bluez/bluez4.inc
index bff24d3..42d82b0 100644
--- a/meta/recipes-connectivity/bluez/bluez4.inc
+++ b/meta/recipes-connectivity/bluez/bluez4.inc
@@ -7,7 +7,7 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=12f884d2ae1ff87c09e5b7ccc2c4ca7e \
file://COPYING.LIB;md5=fb504b67c50331fc78734fed90fb0e09 \
file://src/main.c;beginline=1;endline=24;md5=9bc54b93cd7e17bf03f52513f39f926e \
file://sbc/sbc.c;beginline=1;endline=25;md5=1a40781ed30d50d8639323a184aeb191
-DEPENDS = udev libusb dbus-glib glib-2.0 libcheck
+DEPENDS = udev libusb dbus-glib glib-2.0 libcheck readline
RDEPENDS_${PN}-dev = bluez-hcidump
PACKAGECONFIG ??= \
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] openssl: Upgrade to v1.0.1e
On 04/08/2013 10:00 AM, Radu Moisan wrote: On 04/08/2013 07:54 PM, Richard Purdie wrote: On Mon, 2013-04-08 at 19:47 +0300, Radu Moisan wrote: Dropped obolete patches and pulled updates for debian patches Isn't there some CVE this upgrade fixes which would be worth a mention in here? With respect to what we had (1.0.0j) Scott pointed out the following http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-2686 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0166 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0169 Yocto #3965 https://bugzilla.yoctoproject.org/show_bug.cgi?id=3965 Please put this in the commit message is what RP is getting after here. Thanks Sau! Radu ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] bluez4: add readline dependency
On 4/8/13 12:57 PM, Saul Wold wrote:
On 04/08/2013 05:56 AM, Alex DAMIAN wrote:
From: Alexandru DAMIAN alexandru.dam...@intel.com
bluez4 uses readline to be build, but the dependency is not listed
This is listed in the configuration log.
So we add it.
As far as I can tell it's needed only for gatttool, is this a tool that
we need / want to provide for bluez?
This seems to be a tools for viewing the Generic Attribute Profile (GATT).
It can be disabled by setting ac_cv_lib_readline_main=no
We -really- want to avoid readline if possible, as it brings in GPLv3
dependencies into the system.
If that tool is generically useful, I'd suggest a PACKAGECONFIG setting then.
--Mark
Sau!
Signed-off-by: Alexandru DAMIAN alexandru.dam...@intel.com
---
meta/recipes-connectivity/bluez/bluez4.inc |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-connectivity/bluez/bluez4.inc
b/meta/recipes-connectivity/bluez/bluez4.inc
index bff24d3..42d82b0 100644
--- a/meta/recipes-connectivity/bluez/bluez4.inc
+++ b/meta/recipes-connectivity/bluez/bluez4.inc
@@ -7,7 +7,7 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=12f884d2ae1ff87c09e5b7ccc2c4ca7e \
file://COPYING.LIB;md5=fb504b67c50331fc78734fed90fb0e09 \
file://src/main.c;beginline=1;endline=24;md5=9bc54b93cd7e17bf03f52513f39f926e \
file://sbc/sbc.c;beginline=1;endline=25;md5=1a40781ed30d50d8639323a184aeb191
-DEPENDS = udev libusb dbus-glib glib-2.0 libcheck
+DEPENDS = udev libusb dbus-glib glib-2.0 libcheck readline
RDEPENDS_${PN}-dev = bluez-hcidump
PACKAGECONFIG ??= \
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] alsa-tools: fix build when x11 and gtk+ not available
On 04/08/2013 06:33 AM, Trevor Woerner wrote: With a rather recent HEAD Build Configuration: BB_VERSION= 1.17.1 BUILD_SYS = x86_64-linux NATIVELSBSTRING = openSUSE-project-12.3 TARGET_SYS= x86_64-poky-linux MACHINE = qemux86-64 DISTRO= poky DISTRO_VERSION= 1.3+snapshot-20130407 TUNE_FEATURES = m64 TARGET_FPU= meta meta-yocto meta-yocto-bsp= master:813127247a1100b1abe179dfba25795560eac864 I am able to successfully perform a bitbake world on a number of different targets: - qemux86 - qemuarm - qemumips - qemux86-64 Unfortunately qemuppcfails when building alsa-tools. Is anyone else seeing the same thing? | make[1]: Entering directory `/home/trevor/build/yocto/fullbuild/qemuppc/work/ppc603e-poky-linux/alsa-tools/1.0.26.1-r1/alsa-tools-1.0.26.1/hda-verb' | make[1]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule. | powerpc-poky-linux-gcc -m32 -mhard-float -mcpu=603e --sysroot=/home/trevor/build/yocto/fullbuild/qemuppc/sysroots/qemuppc -DPACKAGE_NAME=\\ -DPACKAGE_TARNAME=\\ -DPACKAGE_VERSION=\\ -DPACKAGE_STRING=\\ -DPACKAGE_BUGREPORT=\\ -DPACKAGE_URL=\\ -DPACKAGE=\hda-verb\ -DVERSION=\0.4\ -DSTDC_HEADERS=1 -I. -O2 -Wall -pipe -g -MT hda-verb.o -MD -MP -MF .deps/hda-verb.Tpo -c -o hda-verb.o hda-verb.c | hda-verb.c:17:20: fatal error: sys/io.h: No such file or directory | compilation terminated. | make[1]: *** [hda-verb.o] Error 1 | make[1]: Leaving directory `/home/trevor/build/yocto/fullbuild/qemuppc/work/ppc603e-poky-linux/alsa-tools/1.0.26.1-r1/alsa-tools-1.0.26.1/hda-verb' | make: *** [all] Error 1 | ERROR: oe_runmake failed I recall doing a patch for this, I just reviewed it and it seems I did not do the right #if directive. I was fixing the mips build which had the same problem and did not correctly retest. Patch out shortly. Sau! ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] systemd: set INHIBIT_UPDATERCD_BBCLASS without sysvinit in features
On Thu, Apr 04, 2013 at 11:38:41PM +0100, Richard Purdie wrote:
On Thu, 2013-04-04 at 18:55 +0200, Martin Jansa wrote:
On Thu, Apr 04, 2013 at 05:46:48PM +0100, Richard Purdie wrote:
On Thu, 2013-04-04 at 18:42 +0200, Martin Jansa wrote:
* fixes udev configure in run-postinsts failing with:
update-rc.d: /etc/init.d/systemd-udev: file does not exist
because systemd-udev is installed only with sysvinit in features
but update-rc.d was always called from PN postinst
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
meta/recipes-core/systemd/systemd_199.bb | 6 ++
1 file changed, 6 insertions(+)
diff --git a/meta/recipes-core/systemd/systemd_199.bb
b/meta/recipes-core/systemd/systemd_199.bb
index ba1d133..e574548 100644
--- a/meta/recipes-core/systemd/systemd_199.bb
+++ b/meta/recipes-core/systemd/systemd_199.bb
@@ -239,6 +239,12 @@ INITSCRIPT_PACKAGES = udev
INITSCRIPT_NAME_udev = systemd-udevd
INITSCRIPT_PARAMS_udev = start 03 S .
+python __anonymous() {
+features = d.getVar(DISTRO_FEATURES, True).split()
+if sysvinit not in features:
+d.setVar(INHIBIT_UPDATERCD_BBCLASS, 1)
+}
+
# TODO:
# u-a for runlevel and telinit
Would this make sense to be in systemd.bbclass?
Similar logic is in systemd.bbclass already, but systemd is not inherited
from
systemd and dbus recipes.
Ok, fair enough. I hadn't realised that.
Also the version from systemd.bbclass does check also for systemd in
DISTRO_FEATURES, but that's not wanted here, because decision to install
init.d
script is based only on sysvinit in DISTRO_FEATURES.
Lot's of fun with all init systems sharing the same PN :/.
There is also error from prerm :/
//var/lib/opkg/info/dbus-1.prerm: line 3: /etc/init.d/dbus-1: No such file or
directory
updatercd_prerm() {
if test x$D = x; then
${INIT_D_DIR}/${INITSCRIPT_NAME} stop
fi
}
not sure if testing update-rc.d existence like in postinst/postrm
if type update-rc.d /dev/null 2/dev/null; then
is right way, checking ${INIT_D_DIR}/${INITSCRIPT_NAME}
existence will possibly hide some real issues...
sigh
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [RFC] [PATCH 0/2] Routerstation Pro: kernel.bbclass: do_sizecheck, do_strip
Hi Richard, Here is request for comment, v2 of fixes to kernel.bbclass for 3514 and 3514 bugs (and now bug 4220). For the first patch you had asked that KERNEL_OUTPUT be used consistently for the kernel. The second patch is new, and what I'm especially looking for comments on. It is to get back to what 3515 original said, to strip the elf image, and what Bruce said: finding the right place to strip the image. Commit 9cd3816e4db97c8fd093a120a75a2b5d193afcdd didn't quite work, which made vmlinux.bin (binary format) the default kernel image. See also bug 4220. FYI, the binary vmlinux.bin does boot when you know how. 0x806a5430 comes from copying the entry address of the elf. RedBoot load -v -m tftp -h 128.224.149.6 -b 0x8006 -r mthebeau/vmlinux.bin RedBoot exec -b 0x8006 -c console=ttyS0,115200 root=/dev/sda1 rw rootdelay=2 board=UBNT-RSPRO 0x806a5430 I have a version of this patch that strips the kernel in place instead of carrying a copy. One reason to carry a seperate copy could be the following build warning, which is issued when stripping the image in place: WARNING: File '/usr/src/kernel/arch/mips/boot/vmlinux.stripped' from linux-yocto was already stripped, this will prevent future debugging! A third patch here for your reference only; will resend it to the poky list if you like this approach. Thanks, M ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] kernel.bbclass: do_strip: allow recipes to strip the kernel
From: Michel Thebeau michel.theb...@windriver.com
Allow recipes to specify sections to be stripped from the kernel output
using KERNEL_IMAGE_STRIP_EXTRA_SECTIONS. For example:
KERNEL_IMAGE_STRIP_EXTRA_SECTIONS = .comment .unwanted
The file to be stripped is a copy of ${KERNEL_OUTPUT} and will be given
the same name with an additional .stripped suffix. The suffix can be
overridden using KERNEL_STRIP_SUFFIX.
Since the toolchain does not give indication when the specified sections
are absent, we read the sections first and make this report by issuing a
warning to the developer.
The toolchain by default strips the image with the -s option (even
when -s is not specified):
-s --strip-all Remove all symbol and relocation information
For example, these sections are always removed:
.debug_aranges
.debug_info
.debug_abbrev
.debug_line
.debug_frame
.debug_str
.debug_loc
.debug_ranges
.symtab
.strtab
In addition to these, the sections listed in
KERNEL_IMAGE_STRIP_EXTRA_SECTIONS will also be removed.
Only stripping of vmlinux (elf) is supported at this time. A warning
will be given if the image type is not vmlinux.
Stripping the image could also be done in the kernel, but that would
only work for linux-yocto based kernels, so it's not the route we
decided to go.
[YOCTO 3515]
Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com
Signed-off-by: Michel Thebeau michel.theb...@windriver.com
---
meta/classes/kernel.bbclass | 65 +--
1 file changed, 63 insertions(+), 2 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index af58887..60da4e2 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -41,6 +41,10 @@ KERNEL_RELEASE ?= ${KERNEL_VERSION}
KERNEL_OUTPUT ?= arch/${ARCH}/boot/${KERNEL_IMAGETYPE}
KERNEL_IMAGEDEST = boot
+# When we strip the output, it is here
+KERNEL_STRIPPED_SUFFIX ?= .stripped
+KERNEL_OUTPUT_STRIPPED ?= ${KERNEL_OUTPUT}${KERNEL_STRIPPED_SUFFIX}
+
#
# configuration
#
@@ -109,6 +113,12 @@ kernel_do_install() {
install -d ${D}/${KERNEL_IMAGEDEST}
install -d ${D}/boot
install -m 0644 ${KERNEL_OUTPUT}
${D}/${KERNEL_IMAGEDEST}/${KERNEL_IMAGETYPE}-${KERNEL_VERSION}
+
+ if [ -n ${KERNEL_IMAGE_STRIP_EXTRA_SECTIONS} ]; then
+ install -m 0644 ${KERNEL_OUTPUT_STRIPPED} \
+
${D}/${KERNEL_IMAGEDEST}/${KERNEL_IMAGETYPE}-${KERNEL_VERSION}${KERNEL_STRIPPED_SUFFIX}
+ fi;
+
install -m 0644 System.map ${D}/boot/System.map-${KERNEL_VERSION}
install -m 0644 .config ${D}/boot/config-${KERNEL_VERSION}
install -m 0644 vmlinux ${D}/boot/vmlinux-${KERNEL_VERSION}
@@ -153,6 +163,12 @@ kernel_do_install() {
cd $pwd
fi
install -m 0644 ${KERNEL_OUTPUT} $kerneldir/${KERNEL_IMAGETYPE}
+
+ if [ -n ${KERNEL_IMAGE_STRIP_EXTRA_SECTIONS} ]; then
+ install -m 0644 ${KERNEL_OUTPUT_STRIPPED} \
+ $kerneldir/${KERNEL_IMAGETYPE}${KERNEL_STRIPPED_SUFFIX}
+ fi
+
install -m 0644 System.map $kerneldir/System.map-${KERNEL_VERSION}
#
@@ -289,12 +305,46 @@ python split_kernel_packages () {
do_split_packages(d, root='/lib/firmware', file_regex='^(.*)\.cis$',
output_pattern='kernel-firmware-%s', description='Firmware for %s',
recursive=True, extra_depends='')
}
+do_strip() {
+ if [ -n ${KERNEL_IMAGE_STRIP_EXTRA_SECTIONS} ]; then
+ if [[ ${KERNEL_IMAGETYPE} != vmlinux ]]; then
+ bbwarn image type will not be stripped (not
supported): ${KERNEL_IMAGETYPE}
+ return
+ fi
+
+ cd ${B}
+ cp ${KERNEL_OUTPUT} ${KERNEL_OUTPUT_STRIPPED}
+
+ headers=`$CROSS_COMPILEreadelf -S ${KERNEL_OUTPUT_STRIPPED} |
\
+ grep ^ \{1,\}\[[0-9 ]\{1,\}\] [^ ] | \
+ sed s/^ \{1,\}\[[0-9 ]\{1,\}\] // | \
+ gawk '{print $1}'`
+
+ for str in ${KERNEL_IMAGE_STRIP_EXTRA_SECTIONS}; do {
+ if [[ $headers != *$str* ]]; then
+ bbwarn Section not found: $str;
+ fi
+
+ $CROSS_COMPILEstrip -s -R $str
${KERNEL_OUTPUT_STRIPPED}
+ }; done
+ fi;
+}
+do_strip[dirs] = ${B}
+
+addtask do_strip before do_sizecheck after do_kernel_link_vmlinux
+
# Support checking the kernel size since some kernels need to reside in
partitions
# with a fixed length or there is a limit in transferring the kernel to memory
do_sizecheck() {
+ if [ -n ${KERNEL_IMAGE_STRIP_EXTRA_SECTIONS} ]; then
+ koutf=${KERNEL_OUTPUT_STRIPPED}
+ else
+ koutf=${KERNEL_OUTPUT}
+ fi
+
if [ ! -z ${KERNEL_IMAGE_MAXSIZE} ]; then
cd ${B}
- size=`ls -lL ${KERNEL_OUTPUT} | awk '{ print $5}'`
+
[OE-core] [PATCH 1/2] kernel.bbclass: do_sizecheck: update path to build image and do not delete
From: Michel Thebeau michel.theb...@windriver.com
do_sizecheck has a few issues especially with vmlinux image type.
It breaks because KERNEL_OUTPUT is a path relative to ${B}. When
do_sizecheck runs it does not find the file (because the working
directory is elsewhere) and does not fail.
Also, the image file referenced by KERNEL_OUTPUT may be a link.
Finally, when do_sizecheck deletes the oversized kernel image it leaves
the previously run do_compile task with inaccurate status.
So, do the following:
- specify that the working directory should be ${B}
- use ls -L to reference to the real file, and ensure that the link
file is created
- keep the oversized image file so the status of do_compile is valid
[YOCTO #3514]
Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com
Signed-off-by: Michel Thebeau michel.theb...@windriver.com
---
meta/classes/kernel.bbclass |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index d57d1f5..af58887 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -293,15 +293,16 @@ python split_kernel_packages () {
# with a fixed length or there is a limit in transferring the kernel to memory
do_sizecheck() {
if [ ! -z ${KERNEL_IMAGE_MAXSIZE} ]; then
- size=`ls -l ${KERNEL_OUTPUT} | awk '{ print $5}'`
+ cd ${B}
+ size=`ls -lL ${KERNEL_OUTPUT} | awk '{ print $5}'`
if [ $size -ge ${KERNEL_IMAGE_MAXSIZE} ]; then
- rm ${KERNEL_OUTPUT}
die This kernel (size=$size ${KERNEL_IMAGE_MAXSIZE})
is too big for your device. Please reduce the size of the kernel by making more
of it modular.
fi
fi
}
+do_sizecheck[dirs] = ${B}
-addtask sizecheck before do_install after do_compile
+addtask sizecheck before do_install after do_kernel_link_vmlinux
KERNEL_IMAGE_BASE_NAME ?=
${KERNEL_IMAGETYPE}-${PE}-${PV}-${PR}-${MACHINE}-${DATETIME}
# Don't include the DATETIME variable in the sstate package signatures
--
1.7.9.7
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [poky] [PATCH 1/1] routerstationpro: strip the output kernel of .comment section
From: Michel Thebeau michel.theb...@windriver.com The routerstationpro has a 16mb flash which the kernel image should fit into. The default build type for vmlinux then should be a stripped vmlinux. Use KERNEL_IMAGE_STRIP_EXTRA_SECTIONS to do this. Reverts commit 9cd3816e4db97c8fd093a120a75a2b5d193afcdd, which causes: RedBoot load -v vlm-boards/19256/kernel Using default protocol (TFTP) Unrecognized image type: 0x0 [YOCTO 3515] [YOCTO 4220] Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com Signed-off-by: Michel Thebeau michel.theb...@windriver.com --- meta-yocto-bsp/conf/machine/routerstationpro.conf |5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/meta-yocto-bsp/conf/machine/routerstationpro.conf b/meta-yocto-bsp/conf/machine/routerstationpro.conf index a727e2a..723625b 100644 --- a/meta-yocto-bsp/conf/machine/routerstationpro.conf +++ b/meta-yocto-bsp/conf/machine/routerstationpro.conf @@ -6,8 +6,9 @@ require conf/machine/include/tune-mips32.inc MACHINE_FEATURES = screen keyboard pci usbhost ext2 ext3 serial -KERNEL_ALT_IMAGETYPE = vmlinux -KERNEL_IMAGETYPE = vmlinux.bin +KERNEL_IMAGETYPE = vmlinux +KERNEL_ALT_IMAGETYPE = vmlinux.bin +KERNEL_IMAGE_STRIP_EXTRA_SECTIONS = .comment PREFERRED_PROVIDER_virtual/kernel ?= linux-yocto PREFERRED_VERSION_linux-yocto ?= 3.4% -- 1.7.9.7 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] udev: Move udevd back to /sbin
Op 8 apr. 2013, om 18:29 heeft Radu Moisan radu.moi...@intel.com het volgende
geschreven:
Along with v182 upgrade udevd was moved to ${base_libdir}
By upstream, yes
making scripts like init-live.sh to fail in finding udevd
So you should fix those scripts, not mess around with udev.
Fixes [Yocto #4046]
Signed-off-by: Radu Moisan radu.moi...@intel.com
---
meta/recipes-core/udev/udev.inc|3 ++-
meta/recipes-core/udev/udev_182.bb |2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/udev/udev.inc b/meta/recipes-core/udev/udev.inc
index e358d2d..c4d2ce4 100644
--- a/meta/recipes-core/udev/udev.inc
+++ b/meta/recipes-core/udev/udev.inc
@@ -40,7 +40,7 @@ EXTRA_OECONF = --disable-introspection \
ac_cv_file__usr_share_hwdata_pci_ids=no \
ac_cv_file__usr_share_misc_pci_ids=yes \
--sbindir=${base_sbindir} \
---libexecdir=${base_libdir} \
+--libexecdir=${base_sbindir} \
--with-rootlibdir=${base_libdir} \
--with-rootprefix= \
@@ -61,6 +61,7 @@ RRECOMMENDS_${PN} += udev-utils
FILES_${PN}-dbg += ${libexecdir}/.debug
FILES_${PN}-dbg += ${base_libdir}/udev/.debug/
FILES_${PN}-dbg += ${base_libdir}/udev/.debug/*
+FILES_${PN}-dbg += ${base_sbindir}/udev/.debug/*
FILES_${PN}-dev = ${datadir}/pkgconfig/udev.pc
FILES_libudev = ${base_libdir}/libudev.so.*
FILES_libudev-dbg = ${base_libdir}/.debug/libudev.so.*
diff --git a/meta/recipes-core/udev/udev_182.bb
b/meta/recipes-core/udev/udev_182.bb
index 42b4d08..d66292e 100644
--- a/meta/recipes-core/udev/udev_182.bb
+++ b/meta/recipes-core/udev/udev_182.bb
@@ -1,6 +1,6 @@
include udev.inc
-PR = r6
+PR = r7
# module-init-tools from kmod_git will provide libkmod runtime
DEPENDS += module-init-tools
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] alsa-tools: Fix sys/io.h patch
I blew my #if expression! Signed-off-by: Saul Wold s...@linux.intel.com --- meta/recipes-multimedia/alsa/alsa-tools/mips_has_no_io_h.patch | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/meta/recipes-multimedia/alsa/alsa-tools/mips_has_no_io_h.patch b/meta/recipes-multimedia/alsa/alsa-tools/mips_has_no_io_h.patch index 7083cb2..09b10f1 100644 --- a/meta/recipes-multimedia/alsa/alsa-tools/mips_has_no_io_h.patch +++ b/meta/recipes-multimedia/alsa/alsa-tools/mips_has_no_io_h.patch @@ -1,3 +1,6 @@ +Upstream-Status: Pending +Signed-off-by: Saul Wold s...@linux.intel.com + Index: alsa-tools-1.0.26.1/hda-verb/hda-verb.c === --- alsa-tools-1.0.26.1.orig/hda-verb/hda-verb.c @@ -7,7 +10,7 @@ Index: alsa-tools-1.0.26.1/hda-verb/hda-verb.c #include unistd.h #include sys/ioctl.h -#ifndef __PPC__ -+#if __PPC__ || __MIPS__ ++#if !(__PPC__ || __mips__) #include sys/io.h #endif #include sys/types.h -- 1.8.0.2 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] udev: Move udevd back to /sbin
On Mon, Apr 8, 2013 at 5:32 PM, Koen Kooi k...@dominion.thruhere.net wrote:
Op 8 apr. 2013, om 18:29 heeft Radu Moisan radu.moi...@intel.com het
volgende geschreven:
Along with v182 upgrade udevd was moved to ${base_libdir}
By upstream, yes
making scripts like init-live.sh to fail in finding udevd
So you should fix those scripts, not mess around with udev.
Fixes [Yocto #4046]
Signed-off-by: Radu Moisan radu.moi...@intel.com
This move has been done long time ago so I agree with Koen here: the
scripts needs to be fixed. Another thing, it should also be tested
with systemd feature enabled as udev will be called systemd-udevd in
this case, IIRC.
--
Otavio Salvador O.S. Systems
E-mail: ota...@ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] kernel.bbclass: do_strip: allow recipes to strip the kernel
On Mon, 2013-04-08 at 16:15 -0400, michel.theb...@windriver.com wrote:
From: Michel Thebeau michel.theb...@windriver.com
Allow recipes to specify sections to be stripped from the kernel output
using KERNEL_IMAGE_STRIP_EXTRA_SECTIONS. For example:
KERNEL_IMAGE_STRIP_EXTRA_SECTIONS = .comment .unwanted
The file to be stripped is a copy of ${KERNEL_OUTPUT} and will be given
the same name with an additional .stripped suffix. The suffix can be
overridden using KERNEL_STRIP_SUFFIX.
Since the toolchain does not give indication when the specified sections
are absent, we read the sections first and make this report by issuing a
warning to the developer.
The toolchain by default strips the image with the -s option (even
when -s is not specified):
-s --strip-all Remove all symbol and relocation information
For example, these sections are always removed:
.debug_aranges
.debug_info
.debug_abbrev
.debug_line
.debug_frame
.debug_str
.debug_loc
.debug_ranges
.symtab
.strtab
In addition to these, the sections listed in
KERNEL_IMAGE_STRIP_EXTRA_SECTIONS will also be removed.
Only stripping of vmlinux (elf) is supported at this time. A warning
will be given if the image type is not vmlinux.
Stripping the image could also be done in the kernel, but that would
only work for linux-yocto based kernels, so it's not the route we
decided to go.
[YOCTO 3515]
Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com
Signed-off-by: Michel Thebeau michel.theb...@windriver.com
Can we please just have one output kernel, not two. Is the unstripped
version useful anywhere?
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3] base.bbclass: Fix matching of MACHINEOVERRIDES in COMPATIBLE_MACHINE
When a MACHINEOVERRIDES has more than one value, split by ':' as usual
OVERRIDES, this were not being properly checked in COMPATIBLE_MACHINE
matching as we need to iterate over each SoC family and check if it is
compatible or not.
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
Changes for v3:
- Stop checking for SOC_FAMILY as it is just for compatibility with
old BSPs; we move to MACHINEOVERRIDES for this case (RP)
meta/classes/base.bbclass | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index abd6a52..313359c 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -515,11 +515,12 @@ python () {
need_machine = d.getVar('COMPATIBLE_MACHINE', True)
if need_machine:
import re
-this_machine = d.getVar('MACHINE', True)
-if this_machine and not re.match(need_machine, this_machine):
-this_soc_family = d.getVar('SOC_FAMILY', True)
-if (this_soc_family and not re.match(need_machine,
this_soc_family)) or not this_soc_family:
-raise bb.parse.SkipPackage(incompatible with machine %s
(not in COMPATIBLE_MACHINE) % this_machine)
+compat_machines.extend((d.getVar('MACHINEOVERRIDES', True) or
).split(:))
+for m in compat_machines:
+if re.match(need_machine, m):
+break
+else:
+raise bb.parse.SkipPackage(incompatible with machine %s (not
in COMPATIBLE_MACHINE) % d.getVar('MACHINE', True))
bad_licenses = (d.getVar('INCOMPATIBLE_LICENSE', True) or ).split()
--
1.8.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] udev: Move udevd back to /sbin
On Mon, 2013-04-08 at 17:40 -0300, Otavio Salvador wrote:
On Mon, Apr 8, 2013 at 5:32 PM, Koen Kooi k...@dominion.thruhere.net wrote:
Op 8 apr. 2013, om 18:29 heeft Radu Moisan radu.moi...@intel.com het
volgende geschreven:
Along with v182 upgrade udevd was moved to ${base_libdir}
By upstream, yes
making scripts like init-live.sh to fail in finding udevd
So you should fix those scripts, not mess around with udev.
Fixes [Yocto #4046]
Signed-off-by: Radu Moisan radu.moi...@intel.com
This move has been done long time ago so I agree with Koen here: the
scripts needs to be fixed. Another thing, it should also be tested
with systemd feature enabled as udev will be called systemd-udevd in
this case, IIRC.
It is not the scripts, see the previous discussion that was sent out and
Koen at least replied to. The scripts are the least of the problems.
Yes, the commit message here could be more accurate but that doesn't
change the problem of the issue reported in #4046 and previously
discussed.
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] kernel.bbclass: do_strip: allow recipes to strip the kernel
On 13-04-08 04:54 PM, Richard Purdie wrote:
On Mon, 2013-04-08 at 16:15 -0400, michel.theb...@windriver.com wrote:
From: Michel Thebeau michel.theb...@windriver.com
Allow recipes to specify sections to be stripped from the kernel output
using KERNEL_IMAGE_STRIP_EXTRA_SECTIONS. For example:
KERNEL_IMAGE_STRIP_EXTRA_SECTIONS = .comment .unwanted
The file to be stripped is a copy of ${KERNEL_OUTPUT} and will be given
the same name with an additional .stripped suffix. The suffix can be
overridden using KERNEL_STRIP_SUFFIX.
Since the toolchain does not give indication when the specified sections
are absent, we read the sections first and make this report by issuing a
warning to the developer.
The toolchain by default strips the image with the -s option (even
when -s is not specified):
-s --strip-all Remove all symbol and relocation information
For example, these sections are always removed:
.debug_aranges
.debug_info
.debug_abbrev
.debug_line
.debug_frame
.debug_str
.debug_loc
.debug_ranges
.symtab
.strtab
In addition to these, the sections listed in
KERNEL_IMAGE_STRIP_EXTRA_SECTIONS will also be removed.
Only stripping of vmlinux (elf) is supported at this time. A warning
will be given if the image type is not vmlinux.
Stripping the image could also be done in the kernel, but that would
only work for linux-yocto based kernels, so it's not the route we
decided to go.
[YOCTO 3515]
Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com
Signed-off-by: Michel Thebeau michel.theb...@windriver.com
Can we please just have one output kernel, not two. Is the unstripped
version useful anywhere?
The unstripped image is bootable, and it is conceivable that someone may
even want to do load -m tftp from the boot script.
But, if a single image is desirable then I'd go with the image stripped
in place. Here is that other patch... I'll make sure to add text to
the log so it is clear about what happened to the image.
M
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] kernel.bbclass: do_strip: allow recipes to strip the kernel
From: Michel Thebeau michel.theb...@windriver.com
Allow recipes to specify sections to be stripped from the kernel output
using KERNEL_IMAGE_STRIP. For example:
KERNEL_IMAGE_STRIP = .comment .unwanted
The kernel output is stripped in place.
Since the toolchain does not give indication when the specified sections
are absent, we read the sections first and make this report by issuing a
warning to the developer.
The toolchain by default strips the image with the -s option (even
when -s is not specified):
-s --strip-all Remove all symbol and relocation information
For example, these sections are always removed:
.debug_aranges
.debug_info
.debug_abbrev
.debug_line
.debug_frame
.debug_str
.debug_loc
.debug_ranges
.symtab
.strtab
In addition to these, the sections listed in KERNEL_IMAGE_STRIP will
also be removed.
Only stripping of vmlinux (elf) is supported at this time. A warning
will be given if the image type is not vmlinux.
Stripping the image could also be done in the kernel, but that would
only work for linux-yocto based kernels, so it's not the route we
decided to go.
[YOCTO 3515]
Signed-off-by: Michel Thebeau michel.theb...@windriver.com
---
meta/classes/kernel.bbclass | 30 --
1 file changed, 28 insertions(+), 2 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index af58887..4c2c9b9 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -88,7 +88,7 @@ do_compile_kernelmodules() {
bbnote no modules to compile
fi
}
-addtask compile_kernelmodules after do_compile before do_install
+addtask compile_kernelmodules after do_compile before do_strip
kernel_do_install() {
#
@@ -289,6 +289,32 @@ python split_kernel_packages () {
do_split_packages(d, root='/lib/firmware', file_regex='^(.*)\.cis$',
output_pattern='kernel-firmware-%s', description='Firmware for %s',
recursive=True, extra_depends='')
}
+do_strip() {
+ if [ -n ${KERNEL_IMAGE_STRIP} ]; then
+ if [[ ${KERNEL_IMAGETYPE} != vmlinux ]]; then
+ bbwarn image type will not be stripped (not
supported): ${KERNEL_IMAGETYPE}
+ return
+ fi
+
+ cd ${B}
+ headers=`$CROSS_COMPILEreadelf -S ${KERNEL_OUTPUT} | \
+ grep ^ \{1,\}\[[0-9 ]\{1,\}\] [^ ] | \
+ sed s/^ \{1,\}\[[0-9 ]\{1,\}\] // | \
+ gawk '{print $1}'`
+
+ for str in ${KERNEL_IMAGE_STRIP}; do {
+ if [[ $headers != *$str* ]]; then
+ bbwarn Section not found: $str;
+ fi
+
+ $CROSS_COMPILEstrip -s -R $str ${KERNEL_OUTPUT}
+ }; done
+ fi;
+}
+do_strip[dirs] = ${B}
+
+addtask do_strip before do_sizecheck after do_kernel_link_vmlinux
+
# Support checking the kernel size since some kernels need to reside in
partitions
# with a fixed length or there is a limit in transferring the kernel to memory
do_sizecheck() {
@@ -302,7 +328,7 @@ do_sizecheck() {
}
do_sizecheck[dirs] = ${B}
-addtask sizecheck before do_install after do_kernel_link_vmlinux
+addtask sizecheck before do_install after do_strip
KERNEL_IMAGE_BASE_NAME ?=
${KERNEL_IMAGETYPE}-${PE}-${PV}-${PR}-${MACHINE}-${DATETIME}
# Don't include the DATETIME variable in the sstate package signatures
--
1.7.9.7
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] kernel.bbclass: do_strip: allow recipes to strip the kernel
On 13-04-08 05:24 PM, michel.theb...@windriver.com wrote:
From: Michel Thebeau michel.theb...@windriver.com
Allow recipes to specify sections to be stripped from the kernel output
using KERNEL_IMAGE_STRIP. For example:
KERNEL_IMAGE_STRIP = .comment .unwanted
s/KERNEL_IMAGE_STRIP/KERNEL_IMAGE_STRIP_EXTRA_SECTIONS
Throughout
The kernel output is stripped in place.
The subject was supposed to say v2
Since the toolchain does not give indication when the specified sections
are absent, we read the sections first and make this report by issuing a
warning to the developer.
The toolchain by default strips the image with the -s option (even
when -s is not specified):
-s --strip-all Remove all symbol and relocation information
For example, these sections are always removed:
.debug_aranges
.debug_info
.debug_abbrev
.debug_line
.debug_frame
.debug_str
.debug_loc
.debug_ranges
.symtab
.strtab
In addition to these, the sections listed in KERNEL_IMAGE_STRIP will
also be removed.
Only stripping of vmlinux (elf) is supported at this time. A warning
will be given if the image type is not vmlinux.
Stripping the image could also be done in the kernel, but that would
only work for linux-yocto based kernels, so it's not the route we
decided to go.
[YOCTO 3515]
Signed-off-by: Michel Thebeau michel.theb...@windriver.com
---
meta/classes/kernel.bbclass | 30 --
1 file changed, 28 insertions(+), 2 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index af58887..4c2c9b9 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -88,7 +88,7 @@ do_compile_kernelmodules() {
bbnote no modules to compile
fi
}
-addtask compile_kernelmodules after do_compile before do_install
+addtask compile_kernelmodules after do_compile before do_strip
kernel_do_install() {
#
@@ -289,6 +289,32 @@ python split_kernel_packages () {
do_split_packages(d, root='/lib/firmware', file_regex='^(.*)\.cis$',
output_pattern='kernel-firmware-%s', description='Firmware for %s',
recursive=True, extra_depends='')
}
+do_strip() {
+ if [ -n ${KERNEL_IMAGE_STRIP} ]; then
+ if [[ ${KERNEL_IMAGETYPE} != vmlinux ]]; then
+ bbwarn image type will not be stripped (not
supported): ${KERNEL_IMAGETYPE}
+ return
+ fi
+
+ cd ${B}
+ headers=`$CROSS_COMPILEreadelf -S ${KERNEL_OUTPUT} | \
+ grep ^ \{1,\}\[[0-9 ]\{1,\}\] [^ ] | \
+ sed s/^ \{1,\}\[[0-9 ]\{1,\}\] // | \
+ gawk '{print $1}'`
+
+ for str in ${KERNEL_IMAGE_STRIP}; do {
+ if [[ $headers != *$str* ]]; then
+ bbwarn Section not found: $str;
+ fi
+
+ $CROSS_COMPILEstrip -s -R $str ${KERNEL_OUTPUT}
+ }; done
And I'll add a comment here
bbnote KERNEL_IMAGE_STRIP_EXTRA_SECTIONS is set, stripping sections: \
${KERNEL_IMAGE_STRIP_EXTRA_SECTIONS}
Michel
+ fi;
+}
+do_strip[dirs] = ${B}
+
+addtask do_strip before do_sizecheck after do_kernel_link_vmlinux
+
# Support checking the kernel size since some kernels need to reside in
partitions
# with a fixed length or there is a limit in transferring the kernel to
memory
do_sizecheck() {
@@ -302,7 +328,7 @@ do_sizecheck() {
}
do_sizecheck[dirs] = ${B}
-addtask sizecheck before do_install after do_kernel_link_vmlinux
+addtask sizecheck before do_install after do_strip
KERNEL_IMAGE_BASE_NAME ?=
${KERNEL_IMAGETYPE}-${PE}-${PV}-${PR}-${MACHINE}-${DATETIME}
# Don't include the DATETIME variable in the sstate package signatures
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v3] base.bbclass: Fix matching of MACHINEOVERRIDES in COMPATIBLE_MACHINE
On Mon, Apr 8, 2013 at 5:58 PM, Otavio Salvador ota...@ossystems.com.br wrote:
When a MACHINEOVERRIDES has more than one value, split by ':' as usual
OVERRIDES, this were not being properly checked in COMPATIBLE_MACHINE
matching as we need to iterate over each SoC family and check if it is
compatible or not.
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
...
+compat_machines.extend((d.getVar('MACHINEOVERRIDES', True) or
).split(:))
...
I did run it and it fails. I am fixing it and will send a new version
well tested.
--
Otavio Salvador O.S. Systems
E-mail: ota...@ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v3] base.bbclass: Fix matching of MACHINEOVERRIDES in COMPATIBLE_MACHINE
On Mon, 2013-04-08 at 17:58 -0300, Otavio Salvador wrote:
When a MACHINEOVERRIDES has more than one value, split by ':' as usual
OVERRIDES, this were not being properly checked in COMPATIBLE_MACHINE
matching as we need to iterate over each SoC family and check if it is
compatible or not.
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
Changes for v3:
- Stop checking for SOC_FAMILY as it is just for compatibility with
old BSPs; we move to MACHINEOVERRIDES for this case (RP)
meta/classes/base.bbclass | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index abd6a52..313359c 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -515,11 +515,12 @@ python () {
need_machine = d.getVar('COMPATIBLE_MACHINE', True)
if need_machine:
import re
-this_machine = d.getVar('MACHINE', True)
-if this_machine and not re.match(need_machine, this_machine):
-this_soc_family = d.getVar('SOC_FAMILY', True)
-if (this_soc_family and not re.match(need_machine,
this_soc_family)) or not this_soc_family:
-raise bb.parse.SkipPackage(incompatible with machine %s
(not in COMPATIBLE_MACHINE) % this_machine)
+compat_machines.extend((d.getVar('MACHINEOVERRIDES', True) or
).split(:))
No variable compat_machines exists before this line so this patch
cannot possibly work. What did you test?
We're close to release and I'm getting pushed hard in places like IRC to
take patches like this which clearly don't work :(
I'm not happy.
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v3] base.bbclass: Fix matching of MACHINEOVERRIDES in COMPATIBLE_MACHINE
On Mon, Apr 8, 2013 at 6:31 PM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
On Mon, 2013-04-08 at 17:58 -0300, Otavio Salvador wrote:
When a MACHINEOVERRIDES has more than one value, split by ':' as usual
OVERRIDES, this were not being properly checked in COMPATIBLE_MACHINE
matching as we need to iterate over each SoC family and check if it is
compatible or not.
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
Changes for v3:
- Stop checking for SOC_FAMILY as it is just for compatibility with
old BSPs; we move to MACHINEOVERRIDES for this case (RP)
meta/classes/base.bbclass | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index abd6a52..313359c 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -515,11 +515,12 @@ python () {
need_machine = d.getVar('COMPATIBLE_MACHINE', True)
if need_machine:
import re
-this_machine = d.getVar('MACHINE', True)
-if this_machine and not re.match(need_machine, this_machine):
-this_soc_family = d.getVar('SOC_FAMILY', True)
-if (this_soc_family and not re.match(need_machine,
this_soc_family)) or not this_soc_family:
-raise bb.parse.SkipPackage(incompatible with machine
%s (not in COMPATIBLE_MACHINE) % this_machine)
+compat_machines.extend((d.getVar('MACHINEOVERRIDES', True) or
).split(:))
No variable compat_machines exists before this line so this patch
cannot possibly work. What did you test?
I got it when testing, hence my previous e-mail saying I found a problem.
--
Otavio Salvador O.S. Systems
E-mail: ota...@ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v4] base.bbclass: Fix matching of MACHINEOVERRIDES in COMPATIBLE_MACHINE
When a MACHINEOVERRIDES has more than one value, split by ':' as usual
OVERRIDES, this were not being properly checked in COMPATIBLE_MACHINE
matching as we need to iterate over each SoC family and check if it is
compatible or not.
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
Changes for v4:
- Fix wrong assignment of compat_machines
meta/classes/base.bbclass | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index abd6a52..641316d 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -515,11 +515,12 @@ python () {
need_machine = d.getVar('COMPATIBLE_MACHINE', True)
if need_machine:
import re
-this_machine = d.getVar('MACHINE', True)
-if this_machine and not re.match(need_machine, this_machine):
-this_soc_family = d.getVar('SOC_FAMILY', True)
-if (this_soc_family and not re.match(need_machine,
this_soc_family)) or not this_soc_family:
-raise bb.parse.SkipPackage(incompatible with machine %s
(not in COMPATIBLE_MACHINE) % this_machine)
+compat_machines = (d.getVar('MACHINEOVERRIDES', True) or
).split(:)
+for m in compat_machines:
+if re.match(need_machine, m):
+break
+else:
+raise bb.parse.SkipPackage(incompatible with machine %s (not
in COMPATIBLE_MACHINE) % d.getVar('MACHINE', True))
bad_licenses = (d.getVar('INCOMPATIBLE_LICENSE', True) or ).split()
--
1.8.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] kernel.bbclass: do_strip: allow recipes to strip the kernel
On Mon, 2013-04-08 at 17:28 -0400, Michel Thebeau wrote: On 13-04-08 05:24 PM, michel.theb...@windriver.com wrote: From: Michel Thebeau michel.theb...@windriver.com Allow recipes to specify sections to be stripped from the kernel output using KERNEL_IMAGE_STRIP. For example: KERNEL_IMAGE_STRIP = .comment .unwanted s/KERNEL_IMAGE_STRIP/KERNEL_IMAGE_STRIP_EXTRA_SECTIONS Throughout So are you resending this with the appropriate changes, tested? It looks much better this way to me than the first version anyway, thanks. Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/3] oe-buildenv-internal: Only add to $PATH if needed
On Mon, Apr 8, 2013 at 10:48 AM, Paul Eggleton
paul.eggle...@linux.intel.com wrote:
On Monday 08 April 2013 13:31:50 Trevor Woerner wrote:
On Fri, Apr 5, 2013 at 12:59 PM, Peter Kjellerstedt
peter.kjellerst...@axis.com wrote:
+[ ${PATH#$NEWPATHS} != $PATH ] || PATH=$NEWPATHS$PATH
This is certainly a welcome addition in functionality, but it relies
on the pattern remaining at the start of the PATH (i.e. the user
hasn't played with PATH in any way). Could we not use the
${parameter/pattern/string} parameter expansion instead (e.g.
${PATH/$NEWPATHS/}) so it doesn't matter whether the user has
further modified the PATH?
Unfortunately I think this is specific to bash, so it may not be portable.
Maybe the equivalent can be achieved with sed however.
Also, neither version matches the : separator, which means we could in
theory get false positive matches.
--
Christopher Larson
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: gstreamer 1.0 recipes
Hello, thinking about this whole issue I began to wonder: why is gstreamer in oe-core and not in meta-multimedia? wouldnt it be easier then to move liborc into meta-multimedia as well? Or is gstreamer considered an essential component for many installations, thus justifying its presence in oe-core? regards, carlos ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] libpng12: rename libpng_1.2.50 to libpng12
On 2013年04月08日 23:01, Mark Hatle wrote:
On 4/8/13 4:12 AM, Kang Kai wrote:
As Mark's suggestion, rename libpng_1.2.50 to libpng12 that
multi-versions libpng could coexist. And drop files that conflict with
higher version.
We want to make sure we have both the old and new versions to meet LSB
compliance (for people who have that enabled) as well as the new version
for newer applications.
CC: Mark Hatle mark.ha...@windriver.com
Signed-off-by: Kang Kai kai.k...@windriver.com
---
.../{libpng_1.2.50.bb = libpng12_1.2.50.bb} | 18 +++---
1 files changed, 15 insertions(+), 3 deletions(-)
rename meta/recipes-lsb4/libpng/{libpng_1.2.50.bb =
libpng12_1.2.50.bb} (62%)
diff --git a/meta/recipes-lsb4/libpng/libpng_1.2.50.bb
b/meta/recipes-lsb4/libpng/libpng12_1.2.50.bb
similarity index 62%
rename from meta/recipes-lsb4/libpng/libpng_1.2.50.bb
rename to meta/recipes-lsb4/libpng/libpng12_1.2.50.bb
index 8fdc41b..43ff75a 100644
--- a/meta/recipes-lsb4/libpng/libpng_1.2.50.bb
+++ b/meta/recipes-lsb4/libpng/libpng12_1.2.50.bb
@@ -8,14 +8,26 @@ LIC_FILES_CHKSUM =
file://LICENSE;md5=c3d807a85c09ebdff087f18b4969ff96 \
DEPENDS = zlib
PR = r0
+PN = libpng12
+S = ${WORKDIR}/libpng-${PV}
+
SRC_URI =
${SOURCEFORGE_MIRROR}/project/libpng/libpng12/${PV}/libpng-${PV}.tar.xz
SRC_URI[md5sum] = a3e00fccbfe356174ab515b5c00641c7
SRC_URI[sha256sum] =
4724f81f8c92ac7f360ad1fbf173396ea7c535923424db9fbaff07bfd9d8e8e7
+BINCONFIG_GLOB = ${PN}-config
+
inherit autotools binconfig pkgconfig
-PACKAGES =+ ${PN}12
+do_install_append() {
+ unlink ${D}/${includedir}/png.h
+ unlink ${D}/${includedir}/pngconf.h
Hi Mark,
You should move those two into a subdirectory called
${D}/${includedir}/libpng12/
That way they will still be available for anyone who needs them.
Files
/usr/include/libpng12/png.h
/usr/include/libpng12/pngconf.h
already exist. Those two files unlinked link to them and conflict with
libpng16.
+
+ unlink ${D}/${libdir}/libpng.la
+ unlink ${D}/${libdir}/libpng.so
+ unlink ${D}/${libdir}/libpng.a
The .la, .a seen above should be similarly renamed to be libpng12...
The .so should be dropped, as anyone who needs the alternative version
would need to directly specify it.
Same reason. They are links to libpng12.*.
+ unlink ${D}/${libdir}/pkgconfig/libpng.pc
Should be renamed to be libpng12.pc.
(Note both the .la and .pc files will likely need to be modified to
reference the correct header and library paths.)
libpng12.pc exists too, and the patch I checked that are right.
-FILES_${PN}12 = ${libdir}/libpng12${SOLIBS}
-RPROVIDES_${PN}-dev += ${PN}12-dev
+ unlink ${D}/${bindir}/libpng-config
+}
The above should be renamed to be libpng12-config.
Link file too.
(Again, make sure that the results of it match the renamed .a/.so and
include paths.)
--Mark
Thanks for detailed review, I'll add some comment to make it clear.
--
Regards,
Neil | Kai Kang
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/2] V2: rename libpng_1.2.50 to libpng12
V2: add comments to explain why drop some link files
The following changes since commit e57284abca76fe7e6c29484104ae4349459c63dc:
kernel.bbclass: do_sizecheck: update path to build image and do not delete
(2013-04-08 22:26:24 +0100)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib kangkai/libpng12
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=kangkai/libpng12
Kang Kai (2):
libpng12: rename libpng_1.2.50 to libpng12
libpng12: remove prefer version and add it to lsb packagegroup
meta/conf/distro/include/default-versions.inc |3 ---
.../packagegroups/packagegroup-core-lsb.bb |1 +
.../{libpng_1.2.50.bb = libpng12_1.2.50.bb} | 20 +---
3 files changed, 18 insertions(+), 6 deletions(-)
rename meta/recipes-lsb4/libpng/{libpng_1.2.50.bb = libpng12_1.2.50.bb} (55%)
--
1.7.5.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] libpng12: remove prefer version and add it to lsb packagegroup
Because rename libpng_1.2.50 to libpng, remove the perfer verion from default-versions.inc and add libpng12 to lsb packagegroup. Signed-off-by: Kang Kai kai.k...@windriver.com --- meta/conf/distro/include/default-versions.inc |3 --- .../packagegroups/packagegroup-core-lsb.bb |1 + 2 files changed, 1 insertions(+), 3 deletions(-) diff --git a/meta/conf/distro/include/default-versions.inc b/meta/conf/distro/include/default-versions.inc index 0a5b2f4..53ec2e7 100644 --- a/meta/conf/distro/include/default-versions.inc +++ b/meta/conf/distro/include/default-versions.inc @@ -9,6 +9,3 @@ PREFERRED_VERSION_python-native ?= 2.7.3 # Force the older version of liberation-fonts until we fix the fontforge issue PREFERRED_VERSION_liberation-fonts ?= 1.04 - -# Set libpng default version for linuxstdbase -PREFERRED_VERSION_libpng_linuxstdbase ?= 1.2.50 diff --git a/meta/recipes-extended/packagegroups/packagegroup-core-lsb.bb b/meta/recipes-extended/packagegroups/packagegroup-core-lsb.bb index d692a26..cf04f0f 100644 --- a/meta/recipes-extended/packagegroups/packagegroup-core-lsb.bb +++ b/meta/recipes-extended/packagegroups/packagegroup-core-lsb.bb @@ -161,6 +161,7 @@ RDEPENDS_packagegroup-core-lsb-core = \ ncurses \ zlib \ nspr \ +libpng12 \ SUMMARY_packagegroup-core-lsb-perl = LSB Runtime Languages (Perl) -- 1.7.5.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] libpng12: rename libpng_1.2.50 to libpng12
As Mark's suggestion, rename libpng_1.2.50 to libpng12 that
multi-versions libpng could coexist.
We want to make sure we have both the old and new versions to meet LSB
compliance (for people who have that enabled) as well as the new version
for newer applications.
And drop link files that conflict with higher version.
[YOCTO #4221]
Signed-off-by: Kang Kai kai.k...@windriver.com
CC: Mark Hatle mark.ha...@windriver.com
---
.../{libpng_1.2.50.bb = libpng12_1.2.50.bb} | 20 +---
1 files changed, 17 insertions(+), 3 deletions(-)
rename meta/recipes-lsb4/libpng/{libpng_1.2.50.bb = libpng12_1.2.50.bb} (55%)
diff --git a/meta/recipes-lsb4/libpng/libpng_1.2.50.bb
b/meta/recipes-lsb4/libpng/libpng12_1.2.50.bb
similarity index 55%
rename from meta/recipes-lsb4/libpng/libpng_1.2.50.bb
rename to meta/recipes-lsb4/libpng/libpng12_1.2.50.bb
index 8fdc41b..cfefd41 100644
--- a/meta/recipes-lsb4/libpng/libpng_1.2.50.bb
+++ b/meta/recipes-lsb4/libpng/libpng12_1.2.50.bb
@@ -8,14 +8,28 @@ LIC_FILES_CHKSUM =
file://LICENSE;md5=c3d807a85c09ebdff087f18b4969ff96 \
DEPENDS = zlib
PR = r0
+PN = libpng12
+S = ${WORKDIR}/libpng-${PV}
+
SRC_URI =
${SOURCEFORGE_MIRROR}/project/libpng/libpng12/${PV}/libpng-${PV}.tar.xz
SRC_URI[md5sum] = a3e00fccbfe356174ab515b5c00641c7
SRC_URI[sha256sum] =
4724f81f8c92ac7f360ad1fbf173396ea7c535923424db9fbaff07bfd9d8e8e7
+BINCONFIG_GLOB = ${PN}-config
+
inherit autotools binconfig pkgconfig
-PACKAGES =+ ${PN}12
+do_install_append() {
+ # The follow link files link to corresponding png12*.h and libpng12*
files
+ # They conflict with higher verison, so drop them
+ unlink ${D}/${includedir}/png.h
+ unlink ${D}/${includedir}/pngconf.h
+
+ unlink ${D}/${libdir}/libpng.la
+ unlink ${D}/${libdir}/libpng.so
+ unlink ${D}/${libdir}/libpng.a
+ unlink ${D}/${libdir}/pkgconfig/libpng.pc
-FILES_${PN}12 = ${libdir}/libpng12${SOLIBS}
-RPROVIDES_${PN}-dev += ${PN}12-dev
+ unlink ${D}/${bindir}/libpng-config
+}
--
1.7.5.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
