[OE-core] [PATCH 0/1] LSB_Test.sh: update rpm platform file
LSB_Test.sh: update rpm platform file to enable install i486 packages on x86-64 bsps when multlib is enabled. The following changes since commit e15893adf9268b2920b24c52d5c2bb777c6f778e: bitbake: serv.py: Give pr-server up to 5 seconds to commit data (2013-11-18 17:19:11 +) are available in the git repository at: git://git.yoctoproject.org/poky-contrib kangkai/lsb_test http://git.yoctoproject.org/cgit.cgi//log/?h=kangkai/lsb_test Kai Kang (1): LSB_Test.sh: update rpm platform file when enable multilib meta/recipes-extended/lsb/lsbtest/LSB_Test.sh | 8 1 file changed, 8 insertions(+) -- 1.8.1.2 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] LSB_Test.sh: update rpm platform file when enable multilib
When enable multilib for x86_64, lsb rpm packages both for archs x86_64
and i486 will be installed. But i486 target packages could not be
installed that no such pattern in rpm platform file. Update platform
file to enable install i486 rpm packages.
Signed-off-by: Kai Kang kai.k...@windriver.com
---
meta/recipes-extended/lsb/lsbtest/LSB_Test.sh | 8
1 file changed, 8 insertions(+)
diff --git a/meta/recipes-extended/lsb/lsbtest/LSB_Test.sh
b/meta/recipes-extended/lsb/lsbtest/LSB_Test.sh
index af1d61c..19116e2 100644
--- a/meta/recipes-extended/lsb/lsbtest/LSB_Test.sh
+++ b/meta/recipes-extended/lsb/lsbtest/LSB_Test.sh
@@ -277,6 +277,14 @@ if ! `grep -F -q noarch-suse ${PLATFORM_FILE}`; then
echo i486-noarch ${PLATFORM_FILE}
echo i486-pc ${PLATFORM_FILE}
echo noarch-suse ${PLATFORM_FILE}
+ elif [ ${ARCH} == x86_64 ]; then
+ echo i486-suse ${PLATFORM_FILE}
+ echo i486-noarch ${PLATFORM_FILE}
+ echo i486-pc ${PLATFORM_FILE}
+ echo noarch-suse ${PLATFORM_FILE}
+ echo ${ARCH}-suse ${PLATFORM_FILE}
+ echo ${ARCH}-noarch ${PLATFORM_FILE}
+ echo ${ARCH}-pc ${PLATFORM_FILE}
else
echo ${ARCH}-suse ${PLATFORM_FILE}
echo ${ARCH}-noarch ${PLATFORM_FILE}
--
1.8.1.2
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] kernel build fail after update
On Tue, 2013-11-19 at 07:21 +0800, Yi Qingliang wrote: The stack trace of python calls that resulted in this exception/failure was: File: 'sysroot_stage_all', lineno: 6, function: module 0002:def sysroot_stage_all(d): 0003:oe.path.copyhardlinktree(d.expand(/mnt/src/kl360- build/tmp/work/kl360-jilong-linux-gnueabi/linux-jilong/3.9.4- gitAUTOINC+5dbff4f559/image/usr/src/kernel), d.expand(/mnt/src/kl360- build/tmp/work/kl360-jilong-linux-gnueabi/linux-jilong/3.9.4- gitAUTOINC+5dbff4f559/sysroot-destdir//usr/src/kernel)) I've been seeing this too (sporadically) and Martin also reported that it afflicts one of his jenkinses. What seems to be happening is that, for unknown reasons, bitbake is omitting to run do_install() on the kernel before calling do_populate_sysroot(), despite the fact that there clearly is a declared dependency between these two tasks. I found one patch 'Use hardlinks for do_populate_sysroot for speed' may be related with this error. The failure only seems to occur with the kernel, whereas I think that patch applies to all recipes. But that's not to say it isn't related, of course. What makes you think that this is the problem? p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] pr-util: insert appropriate parameter to adapt libtool
On 11/18/2013 08:20 PM, Richard Purdie wrote:
On Mon, 2013-11-18 at 18:31 +0800, yanjun.zhu wrote:
When ccache is enabled, a parameter ccache is inserted.
libtool can not handle this parameter correctly. So --tag=CC
is introduced to help libtool handle it.
---
meta/recipes-support/apr/apr-util_1.5.2.bb |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/meta/recipes-support/apr/apr-util_1.5.2.bb
b/meta/recipes-support/apr/apr-util_1.5.2.bb
index ea0f7fb..d6ae394 100644
--- a/meta/recipes-support/apr/apr-util_1.5.2.bb
+++ b/meta/recipes-support/apr/apr-util_1.5.2.bb
@@ -34,6 +34,11 @@ do_configure_append() {
if [ ${CLASSOVERRIDE} = class-target ]; then
cp ${STAGING_DATADIR}/apr/apr_rules.mk ${S}/build/rules.mk
fi
+
+ # When ccache is enabled, libtool needs --tag=CC to choose correct
handle methods.
+ if [ -f ${S}/build/rules.mk ]; then
+ sed -i s,^LTFLAGS,LTFLAGS = --silent
--tag=CC\n#LTFLAGS,g ${S}/build/rules.mk
+ fi
}
do_configure_prepend_class-native() {
cp ${STAGING_DATADIR_NATIVE}/apr/apr_rules.mk ${S}/build/rules.mk
This looks like something better done with a specific patch along with
an explanation in the patch header. Is there any reason upstream
wouldn't do this?
By using a patch we ensure that when things are upgraded, the right
thing still gets done. You may need to update the apr recipe itself to
get the patch right.
Cheers,
Richard
Hi, Richard
rules.mk is copied from apr_rules.mk. apr_rules.mk is generated by
configure task.
The configure task is after patch. So it is difficult to make a patch
for this defect.
Best Regards!
Zhu Yanjun
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] boot-directdisk: add the support of vmdk
add the support of vmdk.
---
meta/classes/boot-directdisk.bbclass | 21 ++---
1 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/meta/classes/boot-directdisk.bbclass
b/meta/classes/boot-directdisk.bbclass
index 5535728..3277666 100644
--- a/meta/classes/boot-directdisk.bbclass
+++ b/meta/classes/boot-directdisk.bbclass
@@ -88,6 +88,15 @@ build_boot_dd() {
grubefi_hddimg_populate $HDDDIR
fi
+ if [ ${IMAGE_FSTYPE} = vmdk ]; then
+ if [ x${AUTO_SYSLINUXMENU} = x1 ] ; then
+ install -m 0644
${STAGING_DIR}/${MACHINE}/usr/share/syslinux/vesamenu.c32
${HDDDIR}${SYSLINUXDIR}/vesamenu.c32
+ if [ x${SYSLINUX_SPLASH} != x ] ; then
+ install -m 0644 ${SYSLINUX_SPLASH}
${HDDDIR}${SYSLINUXDIR}/splash.lss
+ fi
+ fi
+ fi
+
BLOCKS=`du -bks $HDDDIR | cut -f 1`
BLOCKS=`expr $BLOCKS + ${BOOTDD_EXTRA_SPACE}`
@@ -119,7 +128,10 @@ build_boot_dd() {
parted $IMAGE mkpart primary fat16 0 ${END1}B
parted $IMAGE unit B mkpart primary ext2 ${END2}B ${END3}B
parted $IMAGE set 1 boot on
- parted $IMAGE print
+
+ if [ ${IMAGE_FSTYPE} != vmdk ]; then
+ parted $IMAGE print
+ fi
awk BEGIN { printf \$(echo ${DISK_SIGNATURE} | fold -w 2 | tac |
paste -sd '' | sed 's/\(..\)/\\x/g')\ } | \
dd of=$IMAGE bs=1 seek=440 conv=notrunc
@@ -128,8 +140,11 @@ build_boot_dd() {
if [ ${PCBIOS} = 1 ]; then
dd if=${STAGING_DATADIR}/syslinux/mbr.bin of=$IMAGE conv=notrunc
fi
- dd if=$HDDIMG of=$IMAGE conv=notrunc seek=1 bs=512
- dd if=${ROOTFS} of=$IMAGE conv=notrunc seek=$OFFSET bs=512
+
+ if [ ${IMAGE_FSTYPE} != vmdk ]; then
+ dd if=$HDDIMG of=$IMAGE conv=notrunc seek=1 bs=512
+ dd if=${ROOTFS} of=$IMAGE conv=notrunc seek=$OFFSET bs=512
+ fi
cd ${DEPLOY_DIR_IMAGE}
rm -f ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.hdddirect
--
1.7.3.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] RPROVIDES not package specific with native and added package
Hi Phil,
On Monday, November 18, 2013 7:28 PM, Phil Blundell wrote:
On Mon, 2013-11-18 at 13:28 +, Mats Kärrman wrote:
On Monday, November 18, 2013 2:15 PM, Phil Blundell wrote:
Subject: Re: [OE-core] RPROVIDES not package specific with native and
added package
Oh, right, I see. Does it help if you use PACKAGES =+ .. rather than
PACKAGES_prepend = ?
Yes it does!!
Could you tell me why?
Er... better could you tell me where's the best place to read so I don't
have to make these mistakes again?
The code in insane.bbclass will give you a diagnostic if ${RPROVIDES} is
set and PACKAGES isn't blank. (The actual check that it uses for
PACKAGES is slightly obscure and involves split(), but the net effect
seems to be that it's testing for the variable being set to something
other than .)
native.bbclass sets PACKAGES= and RPROVIDES=${PN}. This violates
insane.bbclass's usual idea of what RPROVIDES should be, but since
PACKAGES is blank the check is inhibited and you don't get an error.
However, your recipe is defeating this by prepending to PACKAGES and
causing it to end up not blank. This turns the insane.bbclass check
back on and the error reappears.
p.
Thanks a lot for the explanation, it explains how the warnings came to be but
it's still a bit unclear to me why =+ works while _prepend doesn't.
My guess is it's a question about order of evaluation; inherit native.bbclass
takes
precedence over recipe assignment to PACKAGES, but PACKAGES_prepend is
another variable and that is prepended to PACKAGES later, but still before
insane.bbclass gets to do it's work, right?
Something that adds to the confusion is that it's not clear where in the chain
the -e option gets its output. Would it be possible to draw some kind of
picture
that shows the basic steps of processing or is it all too complicated?
Are there any good sources of documentation apart from the Yocto project
documents and http://docs.openembedded.org or is it only the source code
itself that goes further in detail?
BR // Mats
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [V3 1/2] bluez4: Install the test script
From: Zhong Hongbo hongbo.zh...@windriver.com
Signed-off-by: Zhong Hongbo hongbo.zh...@windriver.com
---
.../bluez/bluez4-4.101/install-test-script.patch | 26
meta/recipes-connectivity/bluez/bluez4_4.101.bb|6 -
2 files changed, 31 insertions(+), 1 deletion(-)
create mode 100644
meta/recipes-connectivity/bluez/bluez4-4.101/install-test-script.patch
diff --git
a/meta/recipes-connectivity/bluez/bluez4-4.101/install-test-script.patch
b/meta/recipes-connectivity/bluez/bluez4-4.101/install-test-script.patch
new file mode 100644
index 000..23f7d99
--- /dev/null
+++ b/meta/recipes-connectivity/bluez/bluez4-4.101/install-test-script.patch
@@ -0,0 +1,26 @@
+Upstream-Status: Inappropriate
+
+Install the bluez's test scripts
+
+Signed-off-by: Zhong Hongbo hongbo.zh...@windriver.com
+diff -Nurd bluez-4.101.orig/Makefile.tools bluez-4.101/Makefile.tools
+--- bluez-4.101.orig/Makefile.tools2013-11-19 15:49:07.688838000 +0800
bluez-4.101/Makefile.tools 2013-11-19 15:50:09.256837848 +0800
+@@ -227,6 +227,17 @@
+ test/service-spp.xml test/service-opp.xml test/service-ftp.xml \
+ test/simple-player test/test-nap
+
++bluez4_testdir = $(libdir)/bluez4/test/
++dist_bluez4_test_SCRIPTS = test/sap-client test/hsplay test/hsmicro \
++ test/monitor-bluetooth test/list-devices \
++ test/test-discovery test/test-manager test/test-adapter \
++ test/test-device test/test-service test/test-serial \
++ test/test-telephony test/test-network test/simple-agent \
++ test/simple-service test/simple-endpoint test/test-audio \
++ test/test-input test/test-sap-server test/test-oob \
++ test/test-attrib test/test-proximity test/test-thermometer \
++ test/test-serial-proxy test/test-health test/test-health-sink \
++ test/simple-player test/test-nap
+ if HIDD
+ bin_PROGRAMS += compat/hidd
+
diff --git a/meta/recipes-connectivity/bluez/bluez4_4.101.bb
b/meta/recipes-connectivity/bluez/bluez4_4.101.bb
index d6c3e26..7127619 100644
--- a/meta/recipes-connectivity/bluez/bluez4_4.101.bb
+++ b/meta/recipes-connectivity/bluez/bluez4_4.101.bb
@@ -7,6 +7,7 @@ SRC_URI += file://bluetooth.conf \
file://fix-udev-paths.patch \
file://obsolete_automake_macros.patch \
file://network-fix-network-Connect-method-parameters.patch \
+file://install-test-script.patch \
SRC_URI[md5sum] = fb42cb7038c380eb0e2fa208987c96ad
@@ -23,9 +24,10 @@ do_install_append() {
}
RDEPENDS_${PN}-dev = bluez-hcidump
+RDEPENDS_${PN}-testtools += python python-dbus python-pygobject
ALLOW_EMPTY_libasound-module-bluez = 1
-PACKAGES =+ libasound-module-bluez
+PACKAGES =+ libasound-module-bluez ${PN}-testtools
FILES_libasound-module-bluez = ${libdir}/alsa-lib/lib*.so ${datadir}/alsa
FILES_${PN} += ${libdir}/bluetooth/plugins ${libdir}/bluetooth/plugins/*.so
${base_libdir}/udev/ ${nonarch_base_libdir}/udev/ ${systemd_unitdir}/
${datadir}/dbus-1
@@ -34,6 +36,8 @@ FILES_${PN}-dev += \
${libdir}/alsa-lib/*.la \
+FILES_${PN}-testtools = ${libdir}/bluez4/test/*
+
FILES_${PN}-dbg += \
${libdir}/bluetooth/plugins/.debug \
${libdir}/*/.debug \
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [V3 2/2] bluez4: use legacy pygobject instead of gobject-introspection
From: Zhong Hongbo hongbo.zh...@windriver.com pygobject-3.0 use GObject from gi.repository instead of gobject modules. Since oe-core use pygobject-2.x, change all of from gi.repository import GObject to import gobject for bluez4. Signed-off-by: Zhong Hongbo hongbo.zh...@windriver.com --- ...pygobject-instead-ofgobject-introspection.patch | 27 meta/recipes-connectivity/bluez/bluez4_4.101.bb|1 + 2 files changed, 28 insertions(+) create mode 100644 meta/recipes-connectivity/bluez/bluez4-4.101/use-legacy-pygobject-instead-ofgobject-introspection.patch diff --git a/meta/recipes-connectivity/bluez/bluez4-4.101/use-legacy-pygobject-instead-ofgobject-introspection.patch b/meta/recipes-connectivity/bluez/bluez4-4.101/use-legacy-pygobject-instead-ofgobject-introspection.patch new file mode 100644 index 000..37037f5 --- /dev/null +++ b/meta/recipes-connectivity/bluez/bluez4-4.101/use-legacy-pygobject-instead-ofgobject-introspection.patch @@ -0,0 +1,27 @@ +Upstream-Status: Inappropriate + +use legacy pygobject instead of gobject-introspection + +Signed-off-by: Zhong Hongbo hongbo.zh...@windriver.com +--- +diff -Nurd bluez-4.101.orig/test/simple-agent bluez-4.101/test/simple-agent +--- bluez-4.101.orig/test/simple-agent 2013-11-13 17:14:08.138118159 +0800 bluez-4.101/test/simple-agent 2013-11-13 17:14:29.034118107 +0800 +@@ -2,7 +2,7 @@ + + from __future__ import absolute_import, print_function, unicode_literals + +-from gi.repository import GObject ++import gobject + + import sys + import dbus +@@ -122,7 +122,7 @@ + path = /test/agent + agent = Agent(bus, path) + +- mainloop = GObject.MainLoop() ++ mainloop = gobject.MainLoop() + + if len(args) 1: + if len(args) 2: diff --git a/meta/recipes-connectivity/bluez/bluez4_4.101.bb b/meta/recipes-connectivity/bluez/bluez4_4.101.bb index 7127619..543f854 100644 --- a/meta/recipes-connectivity/bluez/bluez4_4.101.bb +++ b/meta/recipes-connectivity/bluez/bluez4_4.101.bb @@ -8,6 +8,7 @@ SRC_URI += file://bluetooth.conf \ file://obsolete_automake_macros.patch \ file://network-fix-network-Connect-method-parameters.patch \ file://install-test-script.patch \ +file://use-legacy-pygobject-instead-ofgobject-introspection.patch \ SRC_URI[md5sum] = fb42cb7038c380eb0e2fa208987c96ad -- 1.7.9.5 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] grub: add explicit dependency on bison-native
From: Jackie Huang jackie.hu...@windriver.com
grub requires bison and it will fail to configure on
the host without bison installed, add the dependency
to fix it.
Signed-off-by: Jackie Huang jackie.hu...@windriver.com
---
meta/recipes-bsp/grub/grub_2.00.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-bsp/grub/grub_2.00.bb
b/meta/recipes-bsp/grub/grub_2.00.bb
index e82996d..47cad0b 100644
--- a/meta/recipes-bsp/grub/grub_2.00.bb
+++ b/meta/recipes-bsp/grub/grub_2.00.bb
@@ -11,7 +11,7 @@ SECTION = bootloaders
LICENSE = GPLv3
LIC_FILES_CHKSUM = file://COPYING;md5=d32239bcb673463ab874e80d47fae504
-DEPENDS = autogen-native flex-native
+DEPENDS = autogen-native flex-native bison-native
RDEPENDS_${PN} = diffutils freetype
PR = r1
--
1.8.3
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] kernel build fail after update
On Tue, 2013-11-19 at 09:24 +, Phil Blundell wrote: On Tue, 2013-11-19 at 07:21 +0800, Yi Qingliang wrote: I found one patch 'Use hardlinks for do_populate_sysroot for speed' may be related with this error. The failure only seems to occur with the kernel, whereas I think that patch applies to all recipes. I realise now that this isn't true; assuming you meant 13259459e200a237ca486cbe1123a0b0a4d1eebf then this is indeed specific to kernel.bbclass. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH V2] dbus: Don't depend on dbus-ptest-ptest for the nativesdk-dbus package
Hi,
can anyone comment on my patch or push it into the master branch ?
Dominik
On 11/14/2013 05:15 PM, Dominik Holland wrote:
I also changed RDEPENDS_class-native to RDEPENDS_dbus_class-native now
---
meta/recipes-core/dbus/dbus.inc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-core/dbus/dbus.inc b/meta/recipes-core/dbus/dbus.inc
index 5864643..6612184 100644
--- a/meta/recipes-core/dbus/dbus.inc
+++ b/meta/recipes-core/dbus/dbus.inc
@@ -10,7 +10,8 @@ DEPENDS = expat virtual/libintl
${@base_contains('DISTRO_FEATURES', 'x11', '${X
DEPENDS_class-native = expat-native virtual/libintl-native
DEPENDS_class-nativesdk = nativesdk-expat virtual/nativesdk-libintl
RDEPENDS_dbus = ${@base_contains('DISTRO_FEATURES', 'ptest', 'dbus-ptest-ptest',
'', d)}
-RDEPENDS_class-native =
+RDEPENDS_dbus_class-native =
+RDEPENDS_dbus_class-nativesdk =
INC_PR = r6
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 00/14] Improvements to pybootchartgui
-Original Message- From: Burton, Ross [mailto:ross.bur...@intel.com] Sent: den 16 november 2013 00:25 To: Peter Kjellerstedt Cc: OE-core Subject: Re: [OE-core] [PATCH 00/14] Improvements to pybootchartgui Hi, On 15 November 2013 17:08, Peter Kjellerstedt peter.kjellerst...@axis.com wrote: This corrects and improves pybootchartgui. It starts by importing the relevant parts for pybootchartgui from the latest version (0.14.5) of bootchart2 from https://github.com/mmeeks/bootchart;. It then corrects a couple of problems (e.g., X scaling, X offset of the chart, and header height), and finally adds a couple of improvements (e.g., disable irrelevant options, draw a lot less ticks, and use Show more to show all processes). Excellent stuff, thanks for working on this. Some time ago I spoke to the bootchart2 maintainers and they were open to generalising their code and merging our codebases - is this something you'd be interesting in looking at? Ross Unfortunately I do not think so at this time. //Peter ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [RFC PATCH 2/4] meta-selftest: create a new test layer to be used by oe-selftest script
From: Corneliu Stoicescu corneliux.stoice...@intel.com
Everything in this layer is meant to be used by tests.
Signed-off-by: Corneliu Stoicescu corneliux.stoice...@intel.com
Signed-off-by: Stefan Stanacar stefanx.stana...@intel.com
---
.gitignore | 1 +
meta-selftest/COPYING.MIT | 17 +
meta-selftest/README | 2 ++
meta-selftest/classes/test_events.bbclass | 16 +
meta-selftest/conf/layer.conf | 10
.../recipes-test/aspell/aspell_0.0.0.1.bb | 28 ++
.../recipes-test/man/man/man-1.5h1-make.patch | 16 +
meta-selftest/recipes-test/man/man_1.6g.bbappend | 2 ++
.../xcursor-transparent-theme_0.1.1.bbappend | 3 +++
9 files changed, 95 insertions(+)
create mode 100644 meta-selftest/COPYING.MIT
create mode 100644 meta-selftest/README
create mode 100644 meta-selftest/classes/test_events.bbclass
create mode 100644 meta-selftest/conf/layer.conf
create mode 100644 meta-selftest/recipes-test/aspell/aspell_0.0.0.1.bb
create mode 100644 meta-selftest/recipes-test/man/man/man-1.5h1-make.patch
create mode 100644 meta-selftest/recipes-test/man/man_1.6g.bbappend
create mode 100644
meta-selftest/recipes-test/xcursor-transparent-theme/xcursor-transparent-theme_0.1.1.bbappend
diff --git a/.gitignore b/.gitignore
index 0171597..b6755fe 100644
--- a/.gitignore
+++ b/.gitignore
@@ -21,3 +21,4 @@ bitbake/doc/manual/pdf/
bitbake/doc/manual/txt/
bitbake/doc/manual/xhtml/
pull-*/
+!meta-selftest
diff --git a/meta-selftest/COPYING.MIT b/meta-selftest/COPYING.MIT
new file mode 100644
index 000..89de354
--- /dev/null
+++ b/meta-selftest/COPYING.MIT
@@ -0,0 +1,17 @@
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the Software), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in
+all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+THE SOFTWARE.
diff --git a/meta-selftest/README b/meta-selftest/README
new file mode 100644
index 000..e0f803d
--- /dev/null
+++ b/meta-selftest/README
@@ -0,0 +1,2 @@
+This layer is intended as test layer, used by scripts/oe-selftest
+and it's probably a mistake to include it in your builds.
diff --git a/meta-selftest/classes/test_events.bbclass
b/meta-selftest/classes/test_events.bbclass
new file mode 100644
index 000..35324eb
--- /dev/null
+++ b/meta-selftest/classes/test_events.bbclass
@@ -0,0 +1,16 @@
+python test1_eventhandler() {
+bb.note(Test for bb.event.BuildStarted)
+}
+python test2_eventhandler() {
+bb.note(Test for bb.event.BuildCompleted)
+}
+python test3_eventhandler() {
+bb.note(Test for bb.event.InvalidEvent)
+}
+
+addhandler test1_eventhandler
+test1_eventhandler[eventmask] = bb.event.BuildStarted
+addhandler test2_eventhandler
+test2_eventhandler[eventmask] = bb.event.BuildCompleted
+addhandler test3_eventhandler
+test3_eventhandler[eventmask] = bb.event.InvalidEvent
diff --git a/meta-selftest/conf/layer.conf b/meta-selftest/conf/layer.conf
new file mode 100644
index 000..e3322f6
--- /dev/null
+++ b/meta-selftest/conf/layer.conf
@@ -0,0 +1,10 @@
+# We have a conf and classes directory, add to BBPATH
+BBPATH .= :${LAYERDIR}
+
+# We have recipes-* directories, add to BBFILES
+BBFILES += ${LAYERDIR}/recipes-*/*/*.bb \
+ ${LAYERDIR}/recipes-*/*/*.bbappend
+
+BBFILE_COLLECTIONS += selftest
+BBFILE_PATTERN_selftest = ^${LAYERDIR}/
+BBFILE_PRIORITY_selftest = 6
diff --git a/meta-selftest/recipes-test/aspell/aspell_0.0.0.1.bb
b/meta-selftest/recipes-test/aspell/aspell_0.0.0.1.bb
new file mode 100644
index 000..79eb06b
--- /dev/null
+++ b/meta-selftest/recipes-test/aspell/aspell_0.0.0.1.bb
@@ -0,0 +1,28 @@
+# This recipe is a copy from the oe-core one.
+# It has a lower and invalid version number in order not to be accidentally
used by bitbake.
+# It is used for tests that require duplicate recipe files.
+
+DESCRIPTION = GNU Aspell spell-checker
+SECTION = console/utils
+LICENSE=LGPLv2 | LGPLv2.1
+LIC_FILES_CHKSUM = file://COPYING;md5=7fbc338309ac38fefcd64b04bb903e34
+PR = r1
+
+SRC_URI =
[OE-core] [RFC PATCH 3/4] scripts/lib/selftest: add a new module for bitbake output tests
From: Corneliu Stoicescu corneliux.stoice...@intel.com
Tests for bitbake-layers and expected output for some bitbake options.
Signed-off-by: Corneliu Stoicescu corneliux.stoice...@intel.com
Signed-off-by: Stefan Stanacar stefanx.stana...@intel.com
---
scripts/lib/selftest/tests/__init__.py | 1 +
scripts/lib/selftest/tests/bboutput.py | 86 ++
2 files changed, 87 insertions(+)
create mode 100644 scripts/lib/selftest/tests/bboutput.py
diff --git a/scripts/lib/selftest/tests/__init__.py
b/scripts/lib/selftest/tests/__init__.py
index e69de29..3acc480 100644
--- a/scripts/lib/selftest/tests/__init__.py
+++ b/scripts/lib/selftest/tests/__init__.py
@@ -0,0 +1 @@
+from selftest.tests.bboutput import *
diff --git a/scripts/lib/selftest/tests/bboutput.py
b/scripts/lib/selftest/tests/bboutput.py
new file mode 100644
index 000..386572f
--- /dev/null
+++ b/scripts/lib/selftest/tests/bboutput.py
@@ -0,0 +1,86 @@
+import unittest
+import os
+import logging
+import re
+import shutil
+from selftest.base import oeSelfTest
+from selftest.utils.commands import runCmd, bitbake, get_bb_var, get_test_layer
+import selftest.utils.ftools as ftools
+
+class BitbakeTests(oeSelfTest):
+
+def test_run_bitbake_from_1(self):
+os.chdir(os.path.join(self.builddir, 'conf'))
+bitbake('-e')
+
+def test_run_bitbake_from_2(self):
+my_env = os.environ.copy()
+my_env['BBPATH'] = my_env['BUILDDIR']
+os.chdir(os.path.dirname(os.environ['BUILDDIR']))
+bitbake('-e', env=my_env)
+
+def test_event_handler(self):
+self.write_config(INHERIT += \test_events\)
+result = bitbake('m4-native')
+find_build_started = re.search(NOTE: Test for
bb\.event\.BuildStarted(\n.*)*NOTE: Preparing runqueue, result.output)
+find_build_completed = re.search(Tasks Summary:.*(\n.*)*NOTE: Test
for bb\.event\.BuildCompleted, result.output)
+self.assertTrue(find_build_started, msg = Match failed in:\n%s %
result.output)
+self.assertTrue(find_build_completed, msg = Match failed in:\n%s %
result.output)
+self.assertFalse('Test for bb.event.InvalidEvent' in result.output)
+
+def test_local_sstate(self):
+bitbake('m4-native -ccleansstate')
+bitbake('m4-native')
+bitbake('m4-native -cclean')
+result = bitbake('m4-native')
+find_setscene = re.search(m4-native.*do_.*_setscene, result.output)
+self.assertTrue(find_setscene)
+
+def test_bitbake_invalid_recipe(self):
+result = bitbake('-b asdf', ignore_status=True)
+self.assertTrue(ERROR: Unable to find any recipe file matching
'asdf' in result.output)
+
+def test_bitbake_invalid_target(self):
+result = bitbake('asdf', ignore_status=True)
+self.assertTrue(ERROR: Nothing PROVIDES 'asdf' in result.output)
+
+def test_warnings_errors(self):
+result = bitbake('-b asdf', ignore_status=True)
+find_warnings = re.search(Summary: There was [1-9][0-9]* WARNING
message shown., result.output)
+find_errors = re.search(Summary: There was [1-9][0-9]* ERROR message
shown., result.output)
+self.assertTrue(find_warnings)
+self.assertTrue(find_errors)
+
+def test_invalid_patch(self):
+inc_file = os.path.join(get_test_layer(),
'recipes-test/man/test_recipe.inc')
+ftools.write_file(inc_file, 'SRC_URI += file://man-1.5h1-make.patch')
+result = bitbake('man -c patch', ignore_status=True)
+os.remove(inc_file)
+bitbake('-cclean man')
+self.assertTrue(ERROR: Function failed: patch_do_patch in
result.output)
+
+
+class BitbakeLayers(oeSelfTest):
+
+def test_bitbakelayers_showlayers(self):
+result = runCmd('bitbake-layers show_layers')
+self.assertTrue('meta-selftest' in result.output)
+
+def test_bitbakelayers_showappends(self):
+result = runCmd('bitbake-layers show_appends')
+self.assertTrue('xcursor-transparent-theme_0.1.1.bbappend' in
result.output, msg='xcursor-transparent-theme_0.1.1.bbappend file was not
recognised')
+
+def test_bitbakelayers_showoverlayed(self):
+result = runCmd('bitbake-layers show_overlayed')
+self.assertTrue('aspell' in result.output,
msg='xcursor-transparent-theme_0.1.1.bbappend file was not recognised')
+
+def test_bitbakelayers_flatten(self):
+if os.path.isdir(os.path.join(self.builddir, 'test')):
+shutil.rmtree(os.path.join(self.builddir, 'test'))
+result = runCmd('bitbake-layers flatten test')
+bb_file = os.path.join(self.builddir,
'test/recipes-graphics/xcursor-transparent-theme/xcursor-transparent-theme_0.1.1.bb')
+self.assertTrue(os.path.isfile(bb_file))
+contents = ftools.read_file(bb_file)
+find_in_contents = re.search(# bbappended from meta-selftest
#\nTEST_VAR = \\, contents)
+shutil.rmtree(os.path.join(self.builddir, 'test'))
+
[OE-core] [RFC PATCH 0/4] Script and layer for running tests
Hello, This series adds an oe-selftest script, some modules and a new layer meta-selftest. which are meant to help in writing tests (using python unittest) for various bitbake tools/scripts as well as simple output checks or do complete builds with different options (with the emphasis that everything checked is done outside of bitbake context, just like a human would do.) For more details, please see YOCTO #4740. Cheers, Stefan The following changes since commit e15893adf9268b2920b24c52d5c2bb777c6f778e: bitbake: serv.py: Give pr-server up to 5 seconds to commit data (2013-11-18 17:19:11 +) are available in the git repository at: git://git.yoctoproject.org/poky-contrib stefans/testme4 http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=stefans/testme4 Alexandru Palalau (1): scripts/lib/selftest: add more simple build tests Corneliu Stoicescu (2): meta-selftest: create a new test layer to be used by oe-selftest script scripts/lib/selftest: add a new module for bitbake output tests Stefan Stanacar (1): scripts/oe-selftest: script to run builds as unitests against bitbake or various scripts .gitignore | 1 + meta-selftest/COPYING.MIT | 17 +++ meta-selftest/README | 2 + meta-selftest/classes/test_events.bbclass | 16 +++ meta-selftest/conf/layer.conf | 10 ++ .../recipes-test/aspell/aspell_0.0.0.1.bb | 28 .../recipes-test/man/man/man-1.5h1-make.patch | 16 +++ meta-selftest/recipes-test/man/man_1.6g.bbappend | 2 + .../xcursor-transparent-theme_0.1.1.bbappend | 3 + scripts/lib/selftest/__init__.py | 0 scripts/lib/selftest/base.py | 54 scripts/lib/selftest/tests/__init__.py | 2 + scripts/lib/selftest/tests/bboptions.py| 39 ++ scripts/lib/selftest/tests/bboutput.py | 86 scripts/lib/selftest/utils/__init__.py | 0 scripts/lib/selftest/utils/commands.py | 146 + scripts/lib/selftest/utils/ftools.py | 27 scripts/oe-selftest| 130 ++ 18 files changed, 579 insertions(+) create mode 100644 meta-selftest/COPYING.MIT create mode 100644 meta-selftest/README create mode 100644 meta-selftest/classes/test_events.bbclass create mode 100644 meta-selftest/conf/layer.conf create mode 100644 meta-selftest/recipes-test/aspell/aspell_0.0.0.1.bb create mode 100644 meta-selftest/recipes-test/man/man/man-1.5h1-make.patch create mode 100644 meta-selftest/recipes-test/man/man_1.6g.bbappend create mode 100644 meta-selftest/recipes-test/xcursor-transparent-theme/xcursor-transparent-theme_0.1.1.bbappend create mode 100644 scripts/lib/selftest/__init__.py create mode 100644 scripts/lib/selftest/base.py create mode 100644 scripts/lib/selftest/tests/__init__.py create mode 100644 scripts/lib/selftest/tests/bboptions.py create mode 100644 scripts/lib/selftest/tests/bboutput.py create mode 100644 scripts/lib/selftest/utils/__init__.py create mode 100644 scripts/lib/selftest/utils/commands.py create mode 100644 scripts/lib/selftest/utils/ftools.py create mode 100755 scripts/oe-selftest -- 1.8.3.1 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [RFC PATCH 4/4] scripts/lib/selftest: add more simple build tests
From: Alexandru Palalau alexandrux.pala...@intel.com
Tests for RM_OLD_IMAGE and for WARN_QA/ERROR_QA behaviour.
Signed-off-by: Alexandru Palalau alexandrux.pala...@intel.com
Signed-off-by: Stefan Stanacar stefanx.stana...@intel.com
---
scripts/lib/selftest/tests/__init__.py | 1 +
scripts/lib/selftest/tests/bboptions.py | 39 +
2 files changed, 40 insertions(+)
create mode 100644 scripts/lib/selftest/tests/bboptions.py
diff --git a/scripts/lib/selftest/tests/__init__.py
b/scripts/lib/selftest/tests/__init__.py
index 3acc480..7826054 100644
--- a/scripts/lib/selftest/tests/__init__.py
+++ b/scripts/lib/selftest/tests/__init__.py
@@ -1 +1,2 @@
from selftest.tests.bboutput import *
+from selftest.tests.bboptions import *
diff --git a/scripts/lib/selftest/tests/bboptions.py
b/scripts/lib/selftest/tests/bboptions.py
new file mode 100644
index 000..ad35386
--- /dev/null
+++ b/scripts/lib/selftest/tests/bboptions.py
@@ -0,0 +1,39 @@
+import unittest
+import os
+import logging
+
+from selftest.base import oeSelfTest
+from selftest.utils.commands import runCmd, bitbake, get_bb_var, get_test_layer
+import selftest.utils.ftools as ftools
+
+class OptionsTests(oeSelfTest):
+
+def test_options_warnqa_errorqa_switch(self):
+bitbake(xcursor-transparent-theme -ccleansstate)
+
+if packages-list not in get_bb_var(ERROR_QA):
+self.write_config(ERROR_QA_append = \ packages-list\)
+
+xcursor_path = os.path.join(get_test_layer(),
recipes-test/xcursor-transparent-theme/test_recipe.inc)
+ftools.write_file(xcursor_path, 'PACKAGES += \${PN}-dbg\')
+
+res = bitbake(xcursor-transparent-theme, ignore_status=True)
+self.assertTrue(ERROR: QA Issue in res.output)
+self.assertEqual(res.status, 1)
+
+self.append_config(ERROR_QA_remove = \packages-list\)
+self.append_config(WARN_QA_append = \ packages-list\)
+bitbake(xcursor-transparent-theme)
+bitbake(xcursor-transparent-theme -ccleansstate)
+os.remove(xcursor_path)
+
+def test_options_rm_old_image(self):
+bitbake(core-image-minimal)
+
+deploydir = get_bb_var(DEPLOY_DIR_IMAGE, target=core-image-minimal)
+imagename = get_bb_var(IMAGE_LINK_NAME, target=core-image-minimal)
+oldimgpath = os.path.realpath(os.path.join(deploydir, imagename +
.ext3))
+
+self.append_config(RM_OLD_IMAGE = \1\)
+bitbake(core-image-minimal)
+self.assertFalse(os.path.exists(oldimgpath), msg=Old image path still
exists: %s % oldimgpath)
--
1.8.3.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [RFC PATCH 1/4] scripts/oe-selftest: script to run builds as unitests against bitbake or various scripts
The purpose of oe-selftest is to run unittest modules added in scripts/lib/selftest/tests, which are tests against bitbake tools. The scripts/lib/selftest/tests path for tests is only temporary. Tests probably will be moved to meta/lib/oeqa/something once we've worked out how that can work. (the reason to have them there is to allow layers to add their own tests). Right now the script it's useful for simple tests like: - bitbake --someoption, change some metadata, bitbake X, check something type scenarios (PR service, error output, etc) - or bitbake-layers ... type scripts and yocto-bsp tools. This commit also adds some helper methods that the tests will use (which are currently used by the script itself, and those also need to move if the tests move). Also, most of the tests will have a dependency on a meta-selftest layer which contains specially modified recipes/bbappends/include files for the purpose of the tests. It's a simple matter or sourcing the enviroment, adding the meta-selftest layer and running: oe-selftest to get some results. [ YOCTO #4740 ] Signed-off-by: Stefan Stanacar stefanx.stana...@intel.com --- scripts/lib/selftest/__init__.py | 0 scripts/lib/selftest/base.py | 54 scripts/lib/selftest/tests/__init__.py | 0 scripts/lib/selftest/utils/__init__.py | 0 scripts/lib/selftest/utils/commands.py | 146 + scripts/lib/selftest/utils/ftools.py | 27 ++ scripts/oe-selftest| 130 + 7 files changed, 357 insertions(+) create mode 100644 scripts/lib/selftest/__init__.py create mode 100644 scripts/lib/selftest/base.py create mode 100644 scripts/lib/selftest/tests/__init__.py create mode 100644 scripts/lib/selftest/utils/__init__.py create mode 100644 scripts/lib/selftest/utils/commands.py create mode 100644 scripts/lib/selftest/utils/ftools.py create mode 100755 scripts/oe-selftest diff --git a/scripts/lib/selftest/__init__.py b/scripts/lib/selftest/__init__.py new file mode 100644 index 000..e69de29 diff --git a/scripts/lib/selftest/base.py b/scripts/lib/selftest/base.py new file mode 100644 index 000..4d90828 --- /dev/null +++ b/scripts/lib/selftest/base.py @@ -0,0 +1,54 @@ +# Copyright (c) 2013 Intel Corporation +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License version 2 as +# published by the Free Software Foundation. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License along +# with this program; if not, write to the Free Software Foundation, Inc., +# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. + +# DESCRIPTION +# Base class inherited by test classes in scripts/lib/selftest/tests + +import unittest +import os +import sys +import logging + +import selftest.utils.ftools as ftools + + +class oeSelfTest(unittest.TestCase): + +log = logging.getLogger(selftest.base) +longMessage = True + +def __init__(self, methodName=runTest): +self.builddir = os.environ.get(BUILDDIR) +self.localconf_path = os.path.join(self.builddir, conf/local.conf) +self.testinc_path = os.path.join(self.builddir, conf/selftest.inc) +super(oeSelfTest, self).__init__(methodName) + +def setUp(self): +os.chdir(self.builddir) +# we don't know what the previous test set in here, we need a fresh start +if os.path.isfile(self.testinc_path): +os.remove(self.testinc_path) + +def write_config(self, data): +self.log.debug(Writing to: %s\n%s\n % (self.testinc_path, data)) +ftools.write_file(self.testinc_path, data) + +def append_config(self, data): +self.log.debug(Appending to: %s\n%s\n % (self.testinc_path, data)) +ftools.append_file(self.testinc_path, data) + +def remove_config(self, data): +self.log.debug(Removing from: %s\n\%s\n % (self.testinc_path, data)) +ftools.remove_from_file(self.testinc_path, data) diff --git a/scripts/lib/selftest/tests/__init__.py b/scripts/lib/selftest/tests/__init__.py new file mode 100644 index 000..e69de29 diff --git a/scripts/lib/selftest/utils/__init__.py b/scripts/lib/selftest/utils/__init__.py new file mode 100644 index 000..e69de29 diff --git a/scripts/lib/selftest/utils/commands.py b/scripts/lib/selftest/utils/commands.py new file mode 100644 index 000..c808927 --- /dev/null +++ b/scripts/lib/selftest/utils/commands.py @@ -0,0 +1,146 @@ +# Copyright (c) 2013 Intel Corporation +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License version 2 as +# published by
Re: [OE-core] State of bitbake world
On Thu, Oct 31, 2013 at 12:08:25AM +0100, Martin Jansa wrote: Starting now I'll use http://openembedded.org/wiki/Bitbake_World_Status to post results from my bitbake world buils. It was updated few times since this e-mail and I've received no feedback. Should I continue to post them or nobody except me is really interested? The stats also show that nobody is interested in fixing them, some issues are there for 6+ months. Date Failed tasksQA QA-w/o-unrecognized qemuarm qemux86 qemux86_64 qemuarm qemux86 qemux86_64 qemuarm qemux86 qemux86_64 2013-11-19 12 17 19 141 142 131 29 27 18 2013-11-03 11 18 19 96 127 123 22 21 16 2013-10-31 9 17 19 74 114 107 23 21 14 2013-10-30 11 16 18 224 191 184 28 23 16 -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] State of bitbake world
[Re: [OE-core] State of bitbake world] On 13.11.19 (Tue 16:50) Martin Jansa wrote: On Thu, Oct 31, 2013 at 12:08:25AM +0100, Martin Jansa wrote: Starting now I'll use http://openembedded.org/wiki/Bitbake_World_Status to post results from my bitbake world buils. It was updated few times since this e-mail and I've received no feedback. Should I continue to post them or nobody except me is really interested? I'm interested. I've not had nearly as much time to hunt down the ones I own as I'd like, but I do appreciate the mail and I flag them in my mailboxes for easy reference later. -J. The stats also show that nobody is interested in fixing them, some issues are there for 6+ months. Date Failed tasksQA QA-w/o-unrecognized qemuarm qemux86 qemux86_64 qemuarm qemux86 qemux86_64 qemuarm qemux86 qemux86_64 2013-11-1912 17 19 141 142 131 29 27 18 2013-11-0311 18 19 96 127 123 22 21 16 2013-10-319 17 19 74 114 107 23 21 14 2013-10-3011 16 18 224 191 184 28 23 16 -- -Joe MacDonald. :wq signature.asc Description: Digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] State of bitbake world
On Tue, Nov 19, 2013 at 4:50 PM, Martin Jansa martin.ja...@gmail.com wrote: On Thu, Oct 31, 2013 at 12:08:25AM +0100, Martin Jansa wrote: Starting now I'll use http://openembedded.org/wiki/Bitbake_World_Status to post results from my bitbake world buils. It was updated few times since this e-mail and I've received no feedback. Should I continue to post them or nobody except me is really interested? I am interested but would prefer some short information as mail like in the past because prefer events more than polling. Andreas ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe] State of bitbake world
On Tue, Nov 19, 2013 at 4:56 PM, Joe MacDonald j...@deserted.net wrote: [Re: [OE-core] State of bitbake world] On 13.11.19 (Tue 16:50) Martin Jansa wrote: On Thu, Oct 31, 2013 at 12:08:25AM +0100, Martin Jansa wrote: Starting now I'll use http://openembedded.org/wiki/Bitbake_World_Status to post results from my bitbake world buils. It was updated few times since this e-mail and I've received no feedback. Should I continue to post them or nobody except me is really interested? I'm interested. I've not had nearly as much time to hunt down the ones I own as I'd like, but I do appreciate the mail and I flag them in my mailboxes for easy reference later. -J. The stats also show that nobody is interested in fixing them, some issues are there for 6+ months. Martin, thanks for the time you're spending on it. About the failure concerning my maintainance fields, I see: | Logfile is clean | makedevs: No entry for root in search list | WARNING: exit code 1 from a shell command. | ERROR: Function failed: do_rootfs (log file is located at /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/qemux86-oe-linux/initramfs-kexecboot-klibc-image/1.0-r0/temp/log.do_rootfs.5623) So I grep in oe-core for makedevs: No entry for root in search list and find a serie of commits touching it... Most probable origin of the issue. Starnge that itfails only on x86, though. Cheers Andrea Date Failed tasksQA QA-w/o-unrecognized qemuarm qemux86 qemux86_64 qemuarm qemux86 qemux86_64 qemuarm qemux86 qemux86_64 2013-11-1912 17 19 141 142 131 29 27 18 2013-11-0311 18 19 96 127 123 22 21 16 2013-10-319 17 19 74 114 107 23 21 14 2013-10-3011 16 18 224 191 184 28 23 16 -- -Joe MacDonald. :wq ___ Openembedded-devel mailing list openembedded-de...@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe] State of bitbake world
Hi Martin, On Tuesday 19 November 2013 16:50:40 Martin Jansa wrote: On Thu, Oct 31, 2013 at 12:08:25AM +0100, Martin Jansa wrote: Starting now I'll use http://openembedded.org/wiki/Bitbake_World_Status to post results from my bitbake world buils. It was updated few times since this e-mail and I've received no feedback. Should I continue to post them or nobody except me is really interested? I'm interested in this; I haven't contributed much to the fixing though. I hope that most of the production of the reporting can be automated if it isn't already...? FWIW however I did just send a patch to fix the lowpan-tools do_install failure. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] kernel: restore scripts in the sysroot
On Tuesday 08 October 2013 at 17:12:54 -0400, Bruce Ashfield wrote:
When building against the sysroot, out of tree modules can require modpost
and other utilities normally found in the kernel's scripts directory. For
the kernel source in the staging dir, these scripts have been removed to
avoid mixing archiectures when packaging kernel-dev (among other things).
Rather than further complicate the kernel's install rule, or its packaging,
we can restore the scripts by building them in the kernel staging directory
after the sstate is installed, making them available to packages that need
them.
Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com
---
meta/classes/kernel.bbclass | 11 +++
1 file changed, 11 insertions(+)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 4acfb7e..d5fa801 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -292,6 +292,17 @@ kernel_do_install() {
}
do_install[prefuncs] += package_get_auto_pr
+
+SSTATEPOSTINSTFUNCS += kernelscripts_sstate_postinst
+kernelscripts_sstate_postinst () {
+ if [ ${BB_CURRENTTASK} = populate_sysroot -o ${BB_CURRENTTASK} =
populate_sysroot_setscene ]; then
+ (
+ cd ${STAGING_KERNEL_DIR}
+ oe_runmake scripts
+ )
+ fi
+}
+
sysroot_stage_all_append() {
sysroot_stage_dir ${D}${KERNEL_SRC_PATH}
${SYSROOT_DESTDIR}${KERNEL_SRC_PATH}
}
This sstate_postinst fails for me when the compiler isn't already present
in the sysroot.
Also, I notice that the environment and parameters passed to oe_runmake are
not the same as those used by kernel_do_compile etc.
Patches to follow.
Mike.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] kernel.bbclass: Call make with correct variables in kernelscripts_sstate_postinst
Ensure that the environment variable and command line arguments that are
used when calling make in kernel_do_compile are used in
kernelscripts_sstate_postinst.
Signed-off-by: Mike Crowe m...@mcrowe.com
---
meta/classes/kernel.bbclass |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 2fad6e0..9d922d6 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -304,10 +304,11 @@ do_install[prefuncs] += package_get_auto_pr
SSTATEPOSTINSTFUNCS += kernelscripts_sstate_postinst
kernelscripts_sstate_postinst () {
+ unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
if [ ${BB_CURRENTTASK} = populate_sysroot -o ${BB_CURRENTTASK} =
populate_sysroot_setscene ]; then
(
cd ${STAGING_KERNEL_DIR}
- oe_runmake scripts
+ oe_runmake scripts CC=${KERNEL_CC} LD=${KERNEL_LD}
${KERNEL_EXTRA_ARGS}
)
fi
}
--
1.7.10.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] kernel.bbclass: Ensure compiler is available for do_populate_sysroot_setscene
kernelscripts_sstate_postinst uses the compiler (and therefore binutils) to
generate the kernel scripts so it must declare a dependency on them. The
ones in DEPENDS don't apply to do_populate_sysroot_setscene.
Signed-off-by: Mike Crowe m...@mcrowe.com
---
meta/classes/kernel.bbclass |2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 6959aa1..2fad6e0 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -312,6 +312,8 @@ kernelscripts_sstate_postinst () {
fi
}
+do_populate_sysroot_setscene[depends] +=
virtual/${TARGET_PREFIX}gcc:do_populate_sysroot
virtual/${TARGET_PREFIX}binutils:do_populate_sysroot
+
python sysroot_stage_all () {
oe.path.copyhardlinktree(d.expand(${D}${KERNEL_SRC_PATH}),
d.expand(${SYSROOT_DESTDIR}${KERNEL_SRC_PATH}))
}
--
1.7.10.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] kernel.bbclass: Call make with correct variables in kernelscripts_sstate_postinst
On Tue, Nov 19, 2013 at 12:37 PM, Mike Crowe m...@mcrowe.com wrote:
Ensure that the environment variable and command line arguments that are
used when calling make in kernel_do_compile are used in
kernelscripts_sstate_postinst.
What issue was this causing for you ? The scripts are native, and hence
should just be using the build machines compiler, linker and don't need
the kernel args.
So I'm not convinced that we need this patch, without seeing a tangible
issue that was triggered.
Bruce
Signed-off-by: Mike Crowe m...@mcrowe.com
---
meta/classes/kernel.bbclass |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 2fad6e0..9d922d6 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -304,10 +304,11 @@ do_install[prefuncs] += package_get_auto_pr
SSTATEPOSTINSTFUNCS += kernelscripts_sstate_postinst
kernelscripts_sstate_postinst () {
+ unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
if [ ${BB_CURRENTTASK} = populate_sysroot -o ${BB_CURRENTTASK}
= populate_sysroot_setscene ]; then
(
cd ${STAGING_KERNEL_DIR}
- oe_runmake scripts
+ oe_runmake scripts CC=${KERNEL_CC} LD=${KERNEL_LD}
${KERNEL_EXTRA_ARGS}
)
fi
}
--
1.7.10.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] kernel.bbclass: Call make with correct variables in kernelscripts_sstate_postinst
On Tue, 2013-11-19 at 12:41 -0500, Bruce Ashfield wrote: On Tue, Nov 19, 2013 at 12:37 PM, Mike Crowe m...@mcrowe.com wrote: Ensure that the environment variable and command line arguments that are used when calling make in kernel_do_compile are used in kernelscripts_sstate_postinst. What issue was this causing for you ? The scripts are native, and hence should just be using the build machines compiler, linker and don't need the kernel args. So I'm not convinced that we need this patch, without seeing a tangible issue that was triggered. I think for some arches at least, something targetish is being cleaned and then needing to be rebuilt. I don't want to have to add dependencies for the toolchain so we need to look into this further. Mike: which arch was this on and do you have the compile error? Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] kernel.bbclass: Ensure compiler is available for do_populate_sysroot_setscene
On Tue, Nov 19, 2013 at 12:37 PM, Mike Crowe m...@mcrowe.com wrote:
kernelscripts_sstate_postinst uses the compiler (and therefore binutils) to
generate the kernel scripts so it must declare a dependency on them. The
ones in DEPENDS don't apply to do_populate_sysroot_setscene.
Signed-off-by: Mike Crowe m...@mcrowe.com
---
meta/classes/kernel.bbclass |2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 6959aa1..2fad6e0 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -312,6 +312,8 @@ kernelscripts_sstate_postinst () {
fi
}
+do_populate_sysroot_setscene[depends] +=
virtual/${TARGET_PREFIX}gcc:do_populate_sysroot
virtual/${TARGET_PREFIX}binutils:do_populate_sysroot
This makes sense, we have a bug about this that I was never able to
reproduce:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=5390
Bruce
+
python sysroot_stage_all () {
oe.path.copyhardlinktree(d.expand(${D}${KERNEL_SRC_PATH}),
d.expand(${SYSROOT_DESTDIR}${KERNEL_SRC_PATH}))
}
--
1.7.10.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] kernel: restore scripts in the sysroot
On Tue, 2013-11-19 at 17:37 +, Mike Crowe wrote:
On Tuesday 08 October 2013 at 17:12:54 -0400, Bruce Ashfield wrote:
When building against the sysroot, out of tree modules can require modpost
and other utilities normally found in the kernel's scripts directory. For
the kernel source in the staging dir, these scripts have been removed to
avoid mixing archiectures when packaging kernel-dev (among other things).
Rather than further complicate the kernel's install rule, or its packaging,
we can restore the scripts by building them in the kernel staging directory
after the sstate is installed, making them available to packages that need
them.
Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com
---
meta/classes/kernel.bbclass | 11 +++
1 file changed, 11 insertions(+)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 4acfb7e..d5fa801 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -292,6 +292,17 @@ kernel_do_install() {
}
do_install[prefuncs] += package_get_auto_pr
+
+SSTATEPOSTINSTFUNCS += kernelscripts_sstate_postinst
+kernelscripts_sstate_postinst () {
+ if [ ${BB_CURRENTTASK} = populate_sysroot -o ${BB_CURRENTTASK} =
populate_sysroot_setscene ]; then
+ (
+ cd ${STAGING_KERNEL_DIR}
+ oe_runmake scripts
+ )
+ fi
+}
+
sysroot_stage_all_append() {
sysroot_stage_dir ${D}${KERNEL_SRC_PATH}
${SYSROOT_DESTDIR}${KERNEL_SRC_PATH}
}
This sstate_postinst fails for me when the compiler isn't already present
in the sysroot.
Also, I notice that the environment and parameters passed to oe_runmake are
not the same as those used by kernel_do_compile etc.
Also note that module.bbclass already does make scripts before
do_compile() so out-of-tree modules should already have access to all
the files that they need.
If we're going to make a policy decision that the kernel is responsible
for making scripts then I guess that's fine (modulo the implementation
problems that Mike describes) but in that case the code in
module{-base}.bbclass is redundant and ought to be removed.
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] kernel.bbclass: Call make with correct variables in kernelscripts_sstate_postinst
On Tuesday 19 November 2013 at 12:41:40 -0500, Bruce Ashfield wrote: On Tue, Nov 19, 2013 at 12:37 PM, Mike Crowe m...@mcrowe.com wrote: Ensure that the environment variable and command line arguments that are used when calling make in kernel_do_compile are used in kernelscripts_sstate_postinst. What issue was this causing for you ? The scripts are native, and hence should just be using the build machines compiler, linker and don't need the kernel args. So I'm not convinced that we need this patch, without seeing a tangible issue that was triggered. Well, for us v2.6.39 appears to be using the target compiler for something. At least, I get a lot of: DEBUG: Executing shell function kernelscripts_sstate_postinst NOTE: make scripts /bin/sh: mipsel-oe-linux-gcc: command not found /bin/sh: mipsel-oe-linux-gcc: command not found /bin/sh: mipsel-oe-linux-gcc: command not found /bin/sh: mipsel-oe-linux-gcc: command not found make: mipsel-oe-linux-gcc: Command not found /bin/sh: mipsel-oe-linux-gcc: command not found /bin/sh: mipsel-oe-linux-gcc: command not found which led me to the previous patch to ensure that the compiler is available. Thanks. Mike. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] kernel: restore scripts in the sysroot
On Tue, Nov 19, 2013 at 12:46 PM, Phil Blundell p...@pbcl.net wrote:
On Tue, 2013-11-19 at 17:37 +, Mike Crowe wrote:
On Tuesday 08 October 2013 at 17:12:54 -0400, Bruce Ashfield wrote:
When building against the sysroot, out of tree modules can require modpost
and other utilities normally found in the kernel's scripts directory. For
the kernel source in the staging dir, these scripts have been removed to
avoid mixing archiectures when packaging kernel-dev (among other things).
Rather than further complicate the kernel's install rule, or its packaging,
we can restore the scripts by building them in the kernel staging directory
after the sstate is installed, making them available to packages that need
them.
Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com
---
meta/classes/kernel.bbclass | 11 +++
1 file changed, 11 insertions(+)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 4acfb7e..d5fa801 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -292,6 +292,17 @@ kernel_do_install() {
}
do_install[prefuncs] += package_get_auto_pr
+
+SSTATEPOSTINSTFUNCS += kernelscripts_sstate_postinst
+kernelscripts_sstate_postinst () {
+ if [ ${BB_CURRENTTASK} = populate_sysroot -o ${BB_CURRENTTASK} =
populate_sysroot_setscene ]; then
+ (
+ cd ${STAGING_KERNEL_DIR}
+ oe_runmake scripts
+ )
+ fi
+}
+
sysroot_stage_all_append() {
sysroot_stage_dir ${D}${KERNEL_SRC_PATH}
${SYSROOT_DESTDIR}${KERNEL_SRC_PATH}
}
This sstate_postinst fails for me when the compiler isn't already present
in the sysroot.
Also, I notice that the environment and parameters passed to oe_runmake are
not the same as those used by kernel_do_compile etc.
Also note that module.bbclass already does make scripts before
do_compile() so out-of-tree modules should already have access to all
the files that they need.
Ah, but they didn't. Otherwise we wouldn't have mucked about in the routines.
Khem was building out of the sysroot and the support scripts weren't present,
something which we were able to consistently reproduce.
Perhaps the whole problem was just a misordering of the tasks. I'll take another
look.
But yes, we need one way or the other .. not both. I'd prefer to not fiddle with
sstate, so I'll go back and see why the module.bbclass code wasn't working
for the reported error.
Bruce
If we're going to make a policy decision that the kernel is responsible
for making scripts then I guess that's fine (modulo the implementation
problems that Mike describes) but in that case the code in
module{-base}.bbclass is redundant and ought to be removed.
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] kernel.bbclass: Call make with correct variables in kernelscripts_sstate_postinst
On Tue, Nov 19, 2013 at 12:46 PM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Tue, 2013-11-19 at 12:41 -0500, Bruce Ashfield wrote: On Tue, Nov 19, 2013 at 12:37 PM, Mike Crowe m...@mcrowe.com wrote: Ensure that the environment variable and command line arguments that are used when calling make in kernel_do_compile are used in kernelscripts_sstate_postinst. What issue was this causing for you ? The scripts are native, and hence should just be using the build machines compiler, linker and don't need the kernel args. So I'm not convinced that we need this patch, without seeing a tangible issue that was triggered. I think for some arches at least, something targetish is being cleaned and then needing to be rebuilt. Right. I suppose that if you are installing a mips-mips compiler, then the target toolchain is required. That really wasn't the intention of this change, so it likely isn't properly restricted to the native build case (Where native is a x86 development machine). But with Phil pointing out the module.bbclass 'make scripts' code again, I'd like to figure out why it wasn't working for the original bug report and try to drop all of this mess. Bruce I don't want to have to add dependencies for the toolchain so we need to look into this further. Mike: which arch was this on and do you have the compile error? Cheers, Richard -- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] kernel: restore scripts in the sysroot
Adding Khem.
Khem .. see below.
On Tue, Nov 19, 2013 at 12:54 PM, Bruce Ashfield
bruce.ashfi...@gmail.com wrote:
On Tue, Nov 19, 2013 at 12:46 PM, Phil Blundell p...@pbcl.net wrote:
On Tue, 2013-11-19 at 17:37 +, Mike Crowe wrote:
On Tuesday 08 October 2013 at 17:12:54 -0400, Bruce Ashfield wrote:
When building against the sysroot, out of tree modules can require modpost
and other utilities normally found in the kernel's scripts directory. For
the kernel source in the staging dir, these scripts have been removed to
avoid mixing archiectures when packaging kernel-dev (among other things).
Rather than further complicate the kernel's install rule, or its
packaging,
we can restore the scripts by building them in the kernel staging
directory
after the sstate is installed, making them available to packages that
need them.
Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com
---
meta/classes/kernel.bbclass | 11 +++
1 file changed, 11 insertions(+)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 4acfb7e..d5fa801 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -292,6 +292,17 @@ kernel_do_install() {
}
do_install[prefuncs] += package_get_auto_pr
+
+SSTATEPOSTINSTFUNCS += kernelscripts_sstate_postinst
+kernelscripts_sstate_postinst () {
+ if [ ${BB_CURRENTTASK} = populate_sysroot -o ${BB_CURRENTTASK}
= populate_sysroot_setscene ]; then
+ (
+ cd ${STAGING_KERNEL_DIR}
+ oe_runmake scripts
+ )
+ fi
+}
+
sysroot_stage_all_append() {
sysroot_stage_dir ${D}${KERNEL_SRC_PATH}
${SYSROOT_DESTDIR}${KERNEL_SRC_PATH}
}
This sstate_postinst fails for me when the compiler isn't already present
in the sysroot.
Also, I notice that the environment and parameters passed to oe_runmake are
not the same as those used by kernel_do_compile etc.
Also note that module.bbclass already does make scripts before
do_compile() so out-of-tree modules should already have access to all
the files that they need.
Ah, but they didn't. Otherwise we wouldn't have mucked about in the routines.
Khem was building out of the sysroot and the support scripts weren't present,
something which we were able to consistently reproduce.
Perhaps the whole problem was just a misordering of the tasks. I'll take
another
look.
But yes, we need one way or the other .. not both. I'd prefer to not fiddle
with
sstate, so I'll go back and see why the module.bbclass code wasn't working
for the reported error.
Khem: I wasn't working from a bugzilla when making these changes, so I
can't find your original reproducer for the missing recordmcount script.
Do you recall what it was ? I'm revisiting this and would like to understand
why the make scripts in module-base.bbclass wasn't properly restoring
the support scripts for your build.
I'm leaning towards reverting the whole mess, but without the reproducing
case, I can't be sure that I'm not breaking you again.
Bruce
Bruce
If we're going to make a policy decision that the kernel is responsible
for making scripts then I guess that's fine (modulo the implementation
problems that Mike describes) but in that case the code in
module{-base}.bbclass is redundant and ought to be removed.
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
--
Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] State of bitbake world
On Tue, Nov 19, 2013 at 04:59:19PM +0100, Andreas Müller wrote: On Tue, Nov 19, 2013 at 4:50 PM, Martin Jansa martin.ja...@gmail.com wrote: On Thu, Oct 31, 2013 at 12:08:25AM +0100, Martin Jansa wrote: Starting now I'll use http://openembedded.org/wiki/Bitbake_World_Status to post results from my bitbake world buils. It was updated few times since this e-mail and I've received no feedback. Should I continue to post them or nobody except me is really interested? I am interested but would prefer some short information as mail like in the past because prefer events more than polling. OK, I'll continue to send summary to list as well. Thanks for feedback. -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe] State of bitbake world
On Tue, Nov 19, 2013 at 05:01:06PM +0100, Andrea Adami wrote: On Tue, Nov 19, 2013 at 4:56 PM, Joe MacDonald j...@deserted.net wrote: [Re: [OE-core] State of bitbake world] On 13.11.19 (Tue 16:50) Martin Jansa wrote: On Thu, Oct 31, 2013 at 12:08:25AM +0100, Martin Jansa wrote: Starting now I'll use http://openembedded.org/wiki/Bitbake_World_Status to post results from my bitbake world buils. It was updated few times since this e-mail and I've received no feedback. Should I continue to post them or nobody except me is really interested? I'm interested. I've not had nearly as much time to hunt down the ones I own as I'd like, but I do appreciate the mail and I flag them in my mailboxes for easy reference later. -J. The stats also show that nobody is interested in fixing them, some issues are there for 6+ months. Martin, thanks for the time you're spending on it. About the failure concerning my maintainance fields, I see: | Logfile is clean | makedevs: No entry for root in search list | WARNING: exit code 1 from a shell command. | ERROR: Function failed: do_rootfs (log file is located at /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/qemux86-oe-linux/initramfs-kexecboot-klibc-image/1.0-r0/temp/log.do_rootfs.5623) So I grep in oe-core for makedevs: No entry for root in search list and find a serie of commits touching it... Most probable origin of the issue. Starnge that itfails only on x86, though. I believe this root is meant as username, I had couple of issues like this for usernames which didn't exist in /etc/passwd included in the image. For initramfs-kexecboot-klibc-image I guess you're not installing base-passwd at all, so maybe the check is failing incorrectly for initramfs. Date Failed tasksQA QA-w/o-unrecognized qemuarm qemux86 qemux86_64 qemuarm qemux86 qemux86_64 qemuarm qemux86 qemux86_64 2013-11-1912 17 19 141 142 131 29 27 18 2013-11-0311 18 19 96 127 123 22 21 16 2013-10-319 17 19 74 114 107 23 21 14 2013-10-3011 16 18 224 191 184 28 23 16 -- -Joe MacDonald. :wq ___ Openembedded-devel mailing list openembedded-de...@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe] State of bitbake world
On Tue, Nov 19, 2013 at 04:30:09PM +, Paul Eggleton wrote: Hi Martin, On Tuesday 19 November 2013 16:50:40 Martin Jansa wrote: On Thu, Oct 31, 2013 at 12:08:25AM +0100, Martin Jansa wrote: Starting now I'll use http://openembedded.org/wiki/Bitbake_World_Status to post results from my bitbake world buils. It was updated few times since this e-mail and I've received no feedback. Should I continue to post them or nobody except me is really interested? I'm interested in this; I haven't contributed much to the fixing though. I hope that most of the production of the reporting can be automated if it isn't already...? Good, thanks for feedback. Generating report is automated since I've started adding it to wiki, but still needs me to select best world builds (where most issues weren't hidden by some greater temporary problem) and update it on wiki + e-mail. I wonder if I should automate that as well :). FWIW however I did just send a patch to fix the lowpan-tools do_install failure. Great, thank you. -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] State of bitbake world
On Tuesday 19 November 2013 19:20:12 Martin Jansa wrote: On Tue, Nov 19, 2013 at 04:59:19PM +0100, Andreas Müller wrote: On Tue, Nov 19, 2013 at 4:50 PM, Martin Jansa martin.ja...@gmail.com wrote: On Thu, Oct 31, 2013 at 12:08:25AM +0100, Martin Jansa wrote: Starting now I'll use http://openembedded.org/wiki/Bitbake_World_Status to post results from my bitbake world buils. It was updated few times since this e-mail and I've received no feedback. Should I continue to post them or nobody except me is really interested? I am interested but would prefer some short information as mail like in the past because prefer events more than polling. OK, I'll continue to send summary to list as well. Would it be possible to send the summary as a new email e.g. state of bitbake world for date instead of attaching to the existing thread? It might be a bit selfish, but surely I can't be the only one whose mail client will dredge up the entire thread under today's date... Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] State of bitbake world
On Tue, Nov 19, 2013 at 06:36:41PM +, Paul Eggleton wrote: On Tuesday 19 November 2013 19:20:12 Martin Jansa wrote: On Tue, Nov 19, 2013 at 04:59:19PM +0100, Andreas Müller wrote: On Tue, Nov 19, 2013 at 4:50 PM, Martin Jansa martin.ja...@gmail.com wrote: On Thu, Oct 31, 2013 at 12:08:25AM +0100, Martin Jansa wrote: Starting now I'll use http://openembedded.org/wiki/Bitbake_World_Status to post results from my bitbake world buils. It was updated few times since this e-mail and I've received no feedback. Should I continue to post them or nobody except me is really interested? I am interested but would prefer some short information as mail like in the past because prefer events more than polling. OK, I'll continue to send summary to list as well. Would it be possible to send the summary as a new email e.g. state of bitbake world for date instead of attaching to the existing thread? It might be a bit selfish, but surely I can't be the only one whose mail client will dredge up the entire thread under today's date... Sure, it will be easier for me as well. I was trying to always reply on previous report to see if we're improving or not, now with history in wiki it doesn't help much, so I'll be starting new threads now. -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] kernel: restore scripts in the sysroot
On Nov 19, 2013, at 10:17 AM, Bruce Ashfield bruce.ashfi...@gmail.com wrote:
Adding Khem.
Khem .. see below.
On Tue, Nov 19, 2013 at 12:54 PM, Bruce Ashfield
bruce.ashfi...@gmail.com wrote:
On Tue, Nov 19, 2013 at 12:46 PM, Phil Blundell p...@pbcl.net wrote:
On Tue, 2013-11-19 at 17:37 +, Mike Crowe wrote:
On Tuesday 08 October 2013 at 17:12:54 -0400, Bruce Ashfield wrote:
When building against the sysroot, out of tree modules can require modpost
and other utilities normally found in the kernel's scripts directory. For
the kernel source in the staging dir, these scripts have been removed to
avoid mixing archiectures when packaging kernel-dev (among other things).
Rather than further complicate the kernel's install rule, or its
packaging,
we can restore the scripts by building them in the kernel staging
directory
after the sstate is installed, making them available to packages that
need them.
Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com
---
meta/classes/kernel.bbclass | 11 +++
1 file changed, 11 insertions(+)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 4acfb7e..d5fa801 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -292,6 +292,17 @@ kernel_do_install() {
}
do_install[prefuncs] += package_get_auto_pr
+
+SSTATEPOSTINSTFUNCS += kernelscripts_sstate_postinst
+kernelscripts_sstate_postinst () {
+ if [ ${BB_CURRENTTASK} = populate_sysroot -o ${BB_CURRENTTASK}
= populate_sysroot_setscene ]; then
+ (
+ cd ${STAGING_KERNEL_DIR}
+ oe_runmake scripts
+ )
+ fi
+}
+
sysroot_stage_all_append() {
sysroot_stage_dir ${D}${KERNEL_SRC_PATH}
${SYSROOT_DESTDIR}${KERNEL_SRC_PATH}
}
This sstate_postinst fails for me when the compiler isn't already present
in the sysroot.
Also, I notice that the environment and parameters passed to oe_runmake are
not the same as those used by kernel_do_compile etc.
Also note that module.bbclass already does make scripts before
do_compile() so out-of-tree modules should already have access to all
the files that they need.
Ah, but they didn't. Otherwise we wouldn't have mucked about in the routines.
Khem was building out of the sysroot and the support scripts weren't present,
something which we were able to consistently reproduce.
Perhaps the whole problem was just a misordering of the tasks. I'll take
another
look.
But yes, we need one way or the other .. not both. I'd prefer to not fiddle
with
sstate, so I'll go back and see why the module.bbclass code wasn't working
for the reported error.
Khem: I wasn't working from a bugzilla when making these changes, so I
can't find your original reproducer for the missing recordmcount script.
Do you recall what it was ? I'm revisiting this and would like to understand
why the make scripts in module-base.bbclass wasn't properly restoring
the support scripts for your build.
I'm leaning towards reverting the whole mess, but without the reproducing
case, I can't be sure that I'm not breaking you again.
Well reproducer case is that build from sstate but such that an external module
needs to be rebuilt
if external module also comes from sstate then it all is fine. Its only when
everything is coming from
sstate except this external module which needs to be rebuilt then you see this
problem.
now, I see the code in module-base.class
#
# Ensure the hostprogs are available for module compilation. Modules that
# inherit this recipe and override do_compile() should be sure to call
# do_make_scripts() or ensure the scripts are built independently.
#
do_make_scripts() {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
make CC=${KERNEL_CC} LD=${KERNEL_LD} AR=${KERNEL_AR} \
-C ${STAGING_KERNEL_DIR} scripts
}
so it expects that, do_make_scripts is explicitly called by external module
recipes
and my recipes did override module_do_compile task but not do_compile like below
module_do_compile() {
oe_runmake
}
so, is comment wrong there should it say module_do_compile instead ?
will it work with sstate always ?
it will be OK to revert it if thats the case.
Bruce
Bruce
If we're going to make a policy decision that the kernel is responsible
for making scripts then I guess that's fine (modulo the implementation
problems that Mike describes) but in that case the code in
module{-base}.bbclass is redundant and ought to be removed.
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
--
Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
___
Re: [OE-core] [PATCH 1/1] kernel: restore scripts in the sysroot
On Tue, 2013-11-19 at 14:29 -0800, Khem Raj wrote:
Well reproducer case is that build from sstate but such that an external
module needs to be rebuilt
if external module also comes from sstate then it all is fine. Its only when
everything is coming from
sstate except this external module which needs to be rebuilt then you see
this problem.
now, I see the code in module-base.class
#
# Ensure the hostprogs are available for module compilation. Modules that
# inherit this recipe and override do_compile() should be sure to call
# do_make_scripts() or ensure the scripts are built independently.
#
do_make_scripts() {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
make CC=${KERNEL_CC} LD=${KERNEL_LD} AR=${KERNEL_AR} \
-C ${STAGING_KERNEL_DIR} scripts
}
so it expects that, do_make_scripts is explicitly called by external module
recipes
and my recipes did override module_do_compile task but not do_compile like
below
module_do_compile() {
oe_runmake
}
so, is comment wrong there should it say module_do_compile instead ?
will it work with sstate always ?
it will be OK to revert it if thats the case.
Did you inherit module-base or module? I think the wording applies to
module and not module-base. I think the function used to be in module
and was moved along with the comment which is now incorrect.
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] kernel: restore scripts in the sysroot
On Tue, Nov 19, 2013 at 5:29 PM, Khem Raj raj.k...@gmail.com wrote:
On Nov 19, 2013, at 10:17 AM, Bruce Ashfield bruce.ashfi...@gmail.com wrote:
Adding Khem.
Khem .. see below.
On Tue, Nov 19, 2013 at 12:54 PM, Bruce Ashfield
bruce.ashfi...@gmail.com wrote:
On Tue, Nov 19, 2013 at 12:46 PM, Phil Blundell p...@pbcl.net wrote:
On Tue, 2013-11-19 at 17:37 +, Mike Crowe wrote:
On Tuesday 08 October 2013 at 17:12:54 -0400, Bruce Ashfield wrote:
When building against the sysroot, out of tree modules can require
modpost
and other utilities normally found in the kernel's scripts directory. For
the kernel source in the staging dir, these scripts have been removed to
avoid mixing archiectures when packaging kernel-dev (among other things).
Rather than further complicate the kernel's install rule, or its
packaging,
we can restore the scripts by building them in the kernel staging
directory
after the sstate is installed, making them available to packages that
need them.
Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com
---
meta/classes/kernel.bbclass | 11 +++
1 file changed, 11 insertions(+)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 4acfb7e..d5fa801 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -292,6 +292,17 @@ kernel_do_install() {
}
do_install[prefuncs] += package_get_auto_pr
+
+SSTATEPOSTINSTFUNCS += kernelscripts_sstate_postinst
+kernelscripts_sstate_postinst () {
+ if [ ${BB_CURRENTTASK} = populate_sysroot -o ${BB_CURRENTTASK}
= populate_sysroot_setscene ]; then
+ (
+ cd ${STAGING_KERNEL_DIR}
+ oe_runmake scripts
+ )
+ fi
+}
+
sysroot_stage_all_append() {
sysroot_stage_dir ${D}${KERNEL_SRC_PATH}
${SYSROOT_DESTDIR}${KERNEL_SRC_PATH}
}
This sstate_postinst fails for me when the compiler isn't already present
in the sysroot.
Also, I notice that the environment and parameters passed to oe_runmake
are
not the same as those used by kernel_do_compile etc.
Also note that module.bbclass already does make scripts before
do_compile() so out-of-tree modules should already have access to all
the files that they need.
Ah, but they didn't. Otherwise we wouldn't have mucked about in the
routines.
Khem was building out of the sysroot and the support scripts weren't
present,
something which we were able to consistently reproduce.
Perhaps the whole problem was just a misordering of the tasks. I'll take
another
look.
But yes, we need one way or the other .. not both. I'd prefer to not fiddle
with
sstate, so I'll go back and see why the module.bbclass code wasn't working
for the reported error.
Khem: I wasn't working from a bugzilla when making these changes, so I
can't find your original reproducer for the missing recordmcount script.
Do you recall what it was ? I'm revisiting this and would like to understand
why the make scripts in module-base.bbclass wasn't properly restoring
the support scripts for your build.
I'm leaning towards reverting the whole mess, but without the reproducing
case, I can't be sure that I'm not breaking you again.
Well reproducer case is that build from sstate but such that an external
module needs to be rebuilt
if external module also comes from sstate then it all is fine. Its only when
everything is coming from
sstate except this external module which needs to be rebuilt then you see
this problem.
Right.
now, I see the code in module-base.class
#
# Ensure the hostprogs are available for module compilation. Modules that
# inherit this recipe and override do_compile() should be sure to call
# do_make_scripts() or ensure the scripts are built independently.
#
do_make_scripts() {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
make CC=${KERNEL_CC} LD=${KERNEL_LD} AR=${KERNEL_AR} \
-C ${STAGING_KERNEL_DIR} scripts
}
so it expects that, do_make_scripts is explicitly called by external module
recipes
Exactly. And I had windriver bug with the same symptoms as yours. It
was a package
that built its own modules, and hence never called this either.
and my recipes did override module_do_compile task but not do_compile like
below
module_do_compile() {
oe_runmake
}
so, is comment wrong there should it say module_do_compile instead ?
will it work with sstate always ?
it will be OK to revert it if thats the case.
I'll come up with something that works in all cases. The sstate fix is
better from the point
of view that it is transparent to the recipes, and they don't need to
do anything special
for the support.
So my proposal is this:
- fix the new bug at hand by making the sstate change depend on the
toolchain (I agree
that patching the scripts to not reference the target toolchain
isn't a good idea since not
all kernels get the rix).
- remove the modules-base.bbclass scripts recreation, so we
Re: [OE-core] [PATCH 1/1] kernel: restore scripts in the sysroot
On Nov 19, 2013, at 2:36 PM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
On Tue, 2013-11-19 at 14:29 -0800, Khem Raj wrote:
Well reproducer case is that build from sstate but such that an external
module needs to be rebuilt
if external module also comes from sstate then it all is fine. Its only when
everything is coming from
sstate except this external module which needs to be rebuilt then you see
this problem.
now, I see the code in module-base.class
#
# Ensure the hostprogs are available for module compilation. Modules that
# inherit this recipe and override do_compile() should be sure to call
# do_make_scripts() or ensure the scripts are built independently.
#
do_make_scripts() {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
make CC=${KERNEL_CC} LD=${KERNEL_LD} AR=${KERNEL_AR} \
-C ${STAGING_KERNEL_DIR} scripts
}
so it expects that, do_make_scripts is explicitly called by external module
recipes
and my recipes did override module_do_compile task but not do_compile like
below
module_do_compile() {
oe_runmake
}
so, is comment wrong there should it say module_do_compile instead ?
will it work with sstate always ?
it will be OK to revert it if thats the case.
Did you inherit module-base or module? I think the wording applies to
module and not module-base. I think the function used to be in module
and was moved along with the comment which is now incorrect.
inherit module
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] kernel: restore scripts in the sysroot
On Tue, 2013-11-19 at 14:29 -0800, Khem Raj wrote:
Well reproducer case is that build from sstate but such that an external
module needs to be rebuilt
if external module also comes from sstate then it all is fine. Its only when
everything is coming from
sstate except this external module which needs to be rebuilt then you see
this problem.
now, I see the code in module-base.class
#
# Ensure the hostprogs are available for module compilation. Modules that
# inherit this recipe and override do_compile() should be sure to call
# do_make_scripts() or ensure the scripts are built independently.
#
do_make_scripts() {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
make CC=${KERNEL_CC} LD=${KERNEL_LD} AR=${KERNEL_AR} \
-C ${STAGING_KERNEL_DIR} scripts
}
so it expects that, do_make_scripts is explicitly called by external module
recipes
and my recipes did override module_do_compile task but not do_compile like
below
module_do_compile() {
oe_runmake
}
so, is comment wrong there should it say module_do_compile instead ?
The comment is slightly wrong, yes. For correct results you need to
either:
1. inherit module (not module-base), which does:
addtask make_scripts after do_patch before do_compile
and will ensure that the scripts are built before your module is
compiled without you needing to do anything else. Or...
2. inherit module-base and arrange to call do_make_scripts() explicitly
from your own recipe.
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] kernel: restore scripts in the sysroot
On Tue, 2013-11-19 at 17:37 -0500, Bruce Ashfield wrote:
Exactly. And I had windriver bug with the same symptoms as yours. It
was a package
that built its own modules, and hence never called this either.
and my recipes did override module_do_compile task but not do_compile like
below
module_do_compile() {
oe_runmake
}
so, is comment wrong there should it say module_do_compile instead ?
will it work with sstate always ?
it will be OK to revert it if thats the case.
I'll come up with something that works in all cases. The sstate fix is
better from the point
of view that it is transparent to the recipes, and they don't need to
do anything special
for the support.
So my proposal is this:
- fix the new bug at hand by making the sstate change depend on the
toolchain (I agree
that patching the scripts to not reference the target toolchain
isn't a good idea since not
all kernels get the rix).
Can we please not do this? Adding in toolchain dependencies into the
sstate code whilst possible, is going to massively complicate the
dependency chains and is a last possible resort. I bought that argument
in the useradd case since there are horrible issues there. We don't have
that issue here.
In kernel terms, its safer/easier to hack the kernel makefiles than
expecting sstate to work well with dependencies like that embedded in
it.
- remove the modules-base.bbclass scripts recreation, so we only have
one scripts
restore in the tree.
Alternatively, recipes need to be fixed to call the
modules-base.bbclass routine to restore
scripts, and I think it is obvious that won't work in all cases.
Which cases won't that work in?
As far as I'm concerned, people using module-base are taking a loaded
gun and are expected to use it safely (which means calling
do_make_scripts somehow). People wanting a safer ride can use module
which adds the appropriate task for them.
The comments in the bbclass files do need fixing but that is trivial to
sort out.
I'll wait for comments/concensus before sending a new patch (which
needs to be tested
on all the cases), but in the meantime, the patches to the list to fix
the sstate solution are good to be applied.
I will respectfully disagree ;-).
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] kernel: restore scripts in the sysroot
On Tue, 2013-11-19 at 17:37 -0500, Bruce Ashfield wrote: Alternatively, recipes need to be fixed to call the modules-base.bbclass routine to restore scripts, and I think it is obvious that won't work in all cases. Admittedly I'm no expert, but this is not obvious to me. Why can't those recipes just be fixed to do the right thing? p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] kernel: restore scripts in the sysroot
On Tue, Nov 19, 2013 at 5:42 PM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
On Tue, 2013-11-19 at 17:37 -0500, Bruce Ashfield wrote:
Exactly. And I had windriver bug with the same symptoms as yours. It
was a package
that built its own modules, and hence never called this either.
and my recipes did override module_do_compile task but not do_compile like
below
module_do_compile() {
oe_runmake
}
so, is comment wrong there should it say module_do_compile instead ?
will it work with sstate always ?
it will be OK to revert it if thats the case.
I'll come up with something that works in all cases. The sstate fix is
better from the point
of view that it is transparent to the recipes, and they don't need to
do anything special
for the support.
So my proposal is this:
- fix the new bug at hand by making the sstate change depend on the
toolchain (I agree
that patching the scripts to not reference the target toolchain
isn't a good idea since not
all kernels get the rix).
Can we please not do this? Adding in toolchain dependencies into the
sstate code whilst possible, is going to massively complicate the
dependency chains and is a last possible resort. I bought that argument
in the useradd case since there are horrible issues there. We don't have
that issue here.
Works for me. I just wonder if there's another way to handle things
more gracefully ? i.e. somehow check if the toolchain isn't available
and warn, otherwise continue making the scripts ?
In kernel terms, its safer/easier to hack the kernel makefiles than
expecting sstate to work well with dependencies like that embedded in
it.
It is pretty simple to make the change. Just making it available everywhere
is the trick.
- remove the modules-base.bbclass scripts recreation, so we only have
one scripts
restore in the tree.
Alternatively, recipes need to be fixed to call the
modules-base.bbclass routine to restore
scripts, and I think it is obvious that won't work in all cases.
Which cases won't that work in?
As far as I'm concerned, people using module-base are taking a loaded
gun and are expected to use it safely (which means calling
do_make_scripts somehow). People wanting a safer ride can use module
which adds the appropriate task for them.
I've got people not using any of the above .. yes, I know they are evil
too :)
The comments in the bbclass files do need fixing but that is trivial to
sort out.
I'll wait for comments/concensus before sending a new patch (which
needs to be tested
on all the cases), but in the meantime, the patches to the list to fix
the sstate solution are good to be applied.
I will respectfully disagree ;-).
No patch from me for this then. That's why i waited, I figured it wouldn't
be immediate agreement.
Bruce
Cheers,
Richard
--
Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] kernel: restore scripts in the sysroot
On Tue, 2013-11-19 at 14:39 -0800, Khem Raj wrote:
On Nov 19, 2013, at 2:36 PM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
On Tue, 2013-11-19 at 14:29 -0800, Khem Raj wrote:
Well reproducer case is that build from sstate but such that an external
module needs to be rebuilt
if external module also comes from sstate then it all is fine. Its only
when everything is coming from
sstate except this external module which needs to be rebuilt then you see
this problem.
now, I see the code in module-base.class
#
# Ensure the hostprogs are available for module compilation. Modules that
# inherit this recipe and override do_compile() should be sure to call
# do_make_scripts() or ensure the scripts are built independently.
#
do_make_scripts() {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
make CC=${KERNEL_CC} LD=${KERNEL_LD} AR=${KERNEL_AR} \
-C ${STAGING_KERNEL_DIR} scripts
}
so it expects that, do_make_scripts is explicitly called by external
module recipes
and my recipes did override module_do_compile task but not do_compile like
below
module_do_compile() {
oe_runmake
}
so, is comment wrong there should it say module_do_compile instead ?
will it work with sstate always ?
it will be OK to revert it if thats the case.
Did you inherit module-base or module? I think the wording applies to
module and not module-base. I think the function used to be in module
and was moved along with the comment which is now incorrect.
inherit module
So in that case there is:
addtask make_scripts after do_patch before do_compile
do_make_scripts[lockfiles] = ${TMPDIR}/kernel-scripts.lock
do_make_scripts[deptask] = do_populate_sysroot
which forces the make_scripts task to run before compile. I don't see
how that could therefore fail? :/
Do you have a copy of the exact log? I'm wondering if this is another
variant of the bitbake dependency bug I just tracked down
(http://git.yoctoproject.org/cgit.cgi/poky-contrib/patch/?id=7b49d336c4672f3dfa78e1c3f1f5c7384264a118)
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] kernel: restore scripts in the sysroot
On Tue, Nov 19, 2013 at 6:44 PM, Phil Blundell p...@pbcl.net wrote: On Tue, 2013-11-19 at 17:37 -0500, Bruce Ashfield wrote: Alternatively, recipes need to be fixed to call the modules-base.bbclass routine to restore scripts, and I think it is obvious that won't work in all cases. Admittedly I'm no expert, but this is not obvious to me. Why can't those recipes just be fixed to do the right thing? Alas, people with legacy build environments that they've wrapped and ported to bitbake .. they either can't or won't change, so I'm stuck at least trying to detect them. That wasn't the primary driver for this though, if that case breaks, they'll live and so will i :) I think we are converging to removing the sstate scripts restore, which is fine with me a this point, as long as Khem isn't broken. Bruce p. -- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] sanity.bbclass: Don't fatal() when trying to dump environment.
It is distressing when bitbake -e can't run due to sanity check failures, because the solution often involves figuring out what configuration file are being read and what values they are setting. Solution: Don't do that. If the datasmart object reports that tracking is enabled, emit an error() but not a fatal(), and also warn the user that things may be badly broken. This depends on a change to bitbake (adding the isTracking() method). Signed-off-by: Peter Seebach peter.seeb...@windriver.com --- meta/classes/sanity.bbclass |8 +++- 1 files changed, 7 insertions(+), 1 deletions(-) diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass index 6807a23..1ef811d 100644 --- a/meta/classes/sanity.bbclass +++ b/meta/classes/sanity.bbclass @@ -82,11 +82,17 @@ def raise_sanity_error(msg, d, network_error=False): bb.event.fire(bb.event.SanityCheckFailed(msg), d) return -bb.fatal( OE-core's config sanity checker detected a potential misconfiguration. +msg = ( OE-core's config sanity checker detected a potential misconfiguration. Either fix the cause of this error or at your own risk disable the checker (see sanity.conf). Following is the list of potential problems / advisories: %s % msg) +if d.isTracking(): + bb.warn(Environment tracking enabled: NOT exiting on sanity check failures.) + bb.warn(Results may be inconsistent or meaningless; proceed at your own risk.) +bb.error(msg) +else: +bb.fatal(msg) # Check a single tune for validity. def check_toolchain_tune(data, tune, multilib): -- 1.7.1 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] Make sanity check failures nonfatal for bitbake -e
This patch depends on a separate patch to bitbake providing an isTracking() in DataSmart. The goal here is that if you run bitbake -e, you can get variable values and include history even if something is horribly wrong, because something is horribly wrong is precisely when bitbake -e is most useful. The following changes since commit 0eb947454e1c92467283e6f1adeca67c7c57698b: python: Fix ptest not working problems (2013-11-18 13:04:13 +) are available in the git repository at: git://git.yoctoproject.org/poky-contrib seebs/nonfatal_insanity http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=seebs/nonfatal_insanity Peter Seebach (1): sanity.bbclass: Don't fatal() when trying to dump environment. meta/classes/sanity.bbclass |8 +++- 1 files changed, 7 insertions(+), 1 deletions(-) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] sanity.bbclass: Don't fatal() when trying to dump environment.
On Tue, Nov 19, 2013 at 06:31:57PM -0600, Peter Seebach wrote: It is distressing when bitbake -e can't run due to sanity check failures, because the solution often involves figuring out what configuration file are being read and what values they are setting. Solution: Don't do that. If the datasmart object reports that tracking is enabled, emit an error() but not a fatal(), and also warn the user that things may be badly broken. This depends on a change to bitbake (adding the isTracking() method). Signed-off-by: Peter Seebach peter.seeb...@windriver.com --- meta/classes/sanity.bbclass |8 +++- 1 files changed, 7 insertions(+), 1 deletions(-) diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass index 6807a23..1ef811d 100644 --- a/meta/classes/sanity.bbclass +++ b/meta/classes/sanity.bbclass @@ -82,11 +82,17 @@ def raise_sanity_error(msg, d, network_error=False): bb.event.fire(bb.event.SanityCheckFailed(msg), d) return -bb.fatal( OE-core's config sanity checker detected a potential misconfiguration. +msg = ( OE-core's config sanity checker detected a potential misconfiguration. Either fix the cause of this error or at your own risk disable the checker (see sanity.conf). Following is the list of potential problems / advisories: %s % msg) +if d.isTracking(): + bb.warn(Environment tracking enabled: NOT exiting on sanity check failures.) + bb.warn(Results may be inconsistent or meaningless; proceed at your own risk.) Inconsistent whitespace +bb.error(msg) +else: +bb.fatal(msg) # Check a single tune for validity. def check_toolchain_tune(data, tune, multilib): -- 1.7.1 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/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.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] kernel build fail after update
On Tuesday, November 19, 2013 11:35:14 AM Phil Blundell wrote: On Tue, 2013-11-19 at 09:24 +, Phil Blundell wrote: On Tue, 2013-11-19 at 07:21 +0800, Yi Qingliang wrote: I found one patch 'Use hardlinks for do_populate_sysroot for speed' may be related with this error. The failure only seems to occur with the kernel, whereas I think that patch applies to all recipes. I realise now that this isn't true; assuming you meant 13259459e200a237ca486cbe1123a0b0a4d1eebf then this is indeed specific to kernel.bbclass. p. Yes, that is it. -- Nanjing Jilong Yi Qingliang niqingliang2...@gmail.com ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] sanity.bbclass: Don't fatal() when trying to dump environment.
On Wed, 20 Nov 2013 01:35:32 +0100 Martin Jansa martin.ja...@gmail.com wrote: Inconsistent whitespace argh. I totally thought I'd fixed those all. Fixed that one too, updated the branch on contrib. -s -- Listen, get this. Nobody with a good compiler needs to be justified. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] grub-efi: change to generate EFI image in target package
From: Jackie Huang jackie.hu...@windriver.com
It's not a good idea to generate the target EFI image in
a native packge, it would be a problem when build a 64bit
target on 32bit host. In fact, all we need from grub-efi-native
is the grub-mkimage binary, so change the solution to:
* grub-efi-native only install grub-mkimage
* grub-efi compiles target modules, generates EFI image
with grub-mkimage and deploy, but install nothing.
Signed-off-by: Jackie Huang jackie.hu...@windriver.com
---
meta/classes/grub-efi.bbclass | 4 +-
.../{grub-efi-native_2.00.bb = grub-efi_2.00.bb} | 43 --
2 files changed, 26 insertions(+), 21 deletions(-)
rename meta/recipes-bsp/grub/{grub-efi-native_2.00.bb = grub-efi_2.00.bb}
(77%)
diff --git a/meta/classes/grub-efi.bbclass b/meta/classes/grub-efi.bbclass
index 2f00901..71bd00f 100644
--- a/meta/classes/grub-efi.bbclass
+++ b/meta/classes/grub-efi.bbclass
@@ -15,8 +15,8 @@
# ${GRUB_OPTS} - additional options to add to the config, ';' delimited #
(optional)
# ${GRUB_TIMEOUT} - timeout before executing the deault label (optional)
-do_bootimg[depends] += grub-efi-${TRANSLATED_TARGET_ARCH}-native:do_deploy
-do_bootdirectdisk[depends] +=
grub-efi-${TRANSLATED_TARGET_ARCH}-native:do_deploy
+do_bootimg[depends] += grub-efi:do_deploy
+do_bootdirectdisk[depends] += grub-efi:do_deploy
GRUB_SERIAL ?= console=ttyS0,115200
GRUBCFG = ${S}/grub.cfg
diff --git a/meta/recipes-bsp/grub/grub-efi-native_2.00.bb
b/meta/recipes-bsp/grub/grub-efi_2.00.bb
similarity index 77%
rename from meta/recipes-bsp/grub/grub-efi-native_2.00.bb
rename to meta/recipes-bsp/grub/grub-efi_2.00.bb
index 04973b5..2fe688c 100644
--- a/meta/recipes-bsp/grub/grub-efi-native_2.00.bb
+++ b/meta/recipes-bsp/grub/grub-efi_2.00.bb
@@ -14,14 +14,10 @@ LICENSE = GPLv3
LIC_FILES_CHKSUM = file://COPYING;md5=d32239bcb673463ab874e80d47fae504
# FIXME: We should be able to optionally drop freetype as a dependency
-DEPENDS = autogen-native
-RDEPENDS_${PN} = diffutils freetype
+DEPENDS = autogen-native flex-native bison-native
+DEPENDS_class-target = grub-efi-native
PR = r2
-# Native packages do not normally rebuild when the target changes.
-# Ensure this is built once per HOST-TARGET pair.
-PN := grub-efi-${TRANSLATED_TARGET_ARCH}-native
-
SRC_URI = ftp://ftp.gnu.org/gnu/grub/grub-${PV}.tar.gz \
file://cfg \
file://grub-2.00-fpmath-sse-387-fix.patch \
@@ -39,12 +35,10 @@ COMPATIBLE_HOST = '(x86_64.*|i.86.*)-(linux|freebsd.*)'
S = ${WORKDIR}/grub-${PV}
-# Determine the target arch for the grub modules before the native class
-# clobbers TARGET_ARCH.
-ORIG_TARGET_ARCH := ${TARGET_ARCH}
+# Determine the target arch for the grub modules
python __anonymous () {
import re
-target = d.getVar('ORIG_TARGET_ARCH', True)
+target = d.getVar('TARGET_ARCH', True)
if target == x86_64:
grubtarget = 'x86_64'
grubimage = bootx64.efi
@@ -59,26 +53,37 @@ python __anonymous () {
inherit autotools
inherit gettext
-inherit native
inherit deploy
EXTRA_OECONF = --with-platform=efi --disable-grub-mkfont \
---target=${GRUB_TARGET} --enable-efiemu=no --program-prefix=''
\
+--enable-efiemu=no --program-prefix='' \
--enable-liblzma=no --enable-device-mapper=no
--enable-libzfs=no
-do_mkimage() {
+do_install_class-target() {
+ :
+}
+
+do_install_class-native() {
+ install -d ${D}${bindir}
+ install -m 755 grub-mkimage ${D}${bindir}
+}
+
+do_deploy() {
# Search for the grub.cfg on the local boot media by using the
# built in cfg file provided via this recipe
- ./grub-mkimage -c ../cfg -p /EFI/BOOT -d ./grub-core/ \
+ grub-mkimage -c ../cfg -p /EFI/BOOT -d ./grub-core/ \
-O ${GRUB_TARGET}-efi -o ./${GRUB_IMAGE} \
boot linux ext2 fat serial part_msdos part_gpt normal
efi_gop iso9660 search
+ install -m 644 ${B}/${GRUB_IMAGE} ${DEPLOYDIR}
}
-addtask mkimage after do_compile before do_install
-do_deploy() {
- install -m 644 ${B}/${GRUB_IMAGE} ${DEPLOYDIR}
+do_deploy_class-native() {
+ :
}
+
addtask deploy after do_install before do_build
-do_install[noexec] = 1
-do_populate_sysroot[noexec] = 1
+FILES_${PN}-dbg += ${libdir}/${BPN}/${GRUB_TARGET}-efi/.debug
+
+BBCLASSEXTEND = native
+ALLOW_EMPTY_${PN} = 1
--
1.8.3
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] grub-efi: allow compilation without large model support
From: Jackie Huang jackie.hu...@windriver.com
-mcmodel=large is not supported by gcc with version lower
than 4.4, but we don't need to use memory over 4GiB, so add
a patch to allow compilation without large model support.
Signed-off-by: Jackie Huang jackie.hu...@windriver.com
---
...allow-a-compilation-without-mcmodel-large.patch | 69 ++
meta/recipes-bsp/grub/grub-efi_2.00.bb | 1 +
2 files changed, 70 insertions(+)
create mode 100644
meta/recipes-bsp/grub/files/grub-efi-allow-a-compilation-without-mcmodel-large.patch
diff --git
a/meta/recipes-bsp/grub/files/grub-efi-allow-a-compilation-without-mcmodel-large.patch
b/meta/recipes-bsp/grub/files/grub-efi-allow-a-compilation-without-mcmodel-large.patch
new file mode 100644
index 000..b2be74a
--- /dev/null
+++
b/meta/recipes-bsp/grub/files/grub-efi-allow-a-compilation-without-mcmodel-large.patch
@@ -0,0 +1,69 @@
+From 0cea0e4266214da1f11e812834f5d5c47a6e04e6 Mon Sep 17 00:00:00 2001
+From: Jackie Huang jackie.hu...@windriver.com
+Date: Tue, 5 Nov 2013 07:23:32 -0500
+Subject: [PATCH] Allow a compilation without -mcmodel=large
+
+* kern/efi/mm.c (grub_efi_allocate_pages): don't allocate 4GiB
+ when compiled without -mcmodel=large
+ (filter_memory_map): remove memory post 4 GiB when compiled
+ without -mcmodel=large
+* configure.ac: add -DMCMODEL_SMALL=1 to TARGET_CFLAGS when
+ -mcmodel=large isn't supported
+
+Upstream-Status: Inappropriate [configuration]
+
+Signed-off-by: Jackie Huang jackie.hu...@windriver.com
+---
+ configure.ac|4 +++-
+ grub-core/kern/efi/mm.c |6 +++---
+ 2 files changed, 6 insertions(+), 4 deletions(-)
+
+diff --git a/configure.ac b/configure.ac
+index 319d063..ee72fee 100644
+--- a/configure.ac
b/configure.ac
+@@ -567,7 +567,9 @@ if test $target_cpu-$platform = x86_64-efi; then
+ [grub_cv_cc_mcmodel=no])
+ ])
+ if test x$grub_cv_cc_mcmodel = xno; then
+-AC_MSG_ERROR([-mcmodel=large not supported. Upgrade your gcc.])
++CFLAGS=$SAVED_CFLAGS -m64 -DMCMODEL_SMALL=1
++TARGET_CFLAGS=$TARGET_CFLAGS -DMCMODEL_SMALL=1
++AC_MSG_WARN([-mcmodel=large not supported. You won't be able to use the
memory over 4GiB. Upgrade your gcc.])
+ else
+ TARGET_CFLAGS=$TARGET_CFLAGS -mcmodel=large
+ fi
+diff --git a/grub-core/kern/efi/mm.c b/grub-core/kern/efi/mm.c
+index a2edc84..c67dd13 100644
+--- a/grub-core/kern/efi/mm.c
b/grub-core/kern/efi/mm.c
+@@ -62,7 +62,7 @@ grub_efi_allocate_pages (grub_efi_physical_address_t address,
+ return 0;
+ #endif
+
+-#if 1
++#if defined (MCMODEL_SMALL)
+ if (address == 0)
+ {
+ type = GRUB_EFI_ALLOCATE_MAX_ADDRESS;
+@@ -305,7 +305,7 @@ filter_memory_map (grub_efi_memory_descriptor_t
*memory_map,
+desc = NEXT_MEMORY_DESCRIPTOR (desc, desc_size))
+ {
+ if (desc-type == GRUB_EFI_CONVENTIONAL_MEMORY
+-#if 1
++#if defined (MCMODEL_SMALL)
+ desc-physical_start = 0x
+ #endif
+ desc-physical_start + PAGES_TO_BYTES (desc-num_pages) 0x10
+@@ -321,7 +321,7 @@ filter_memory_map (grub_efi_memory_descriptor_t
*memory_map,
+ desc-physical_start = 0x10;
+ }
+
+-#if 1
++#if defined (MCMODEL_SMALL)
+ if (BYTES_TO_PAGES (filtered_desc-physical_start)
+ + filtered_desc-num_pages
+ BYTES_TO_PAGES (0x1LL))
+--
+1.7.1
+
diff --git a/meta/recipes-bsp/grub/grub-efi_2.00.bb
b/meta/recipes-bsp/grub/grub-efi_2.00.bb
index 2fe688c..deb9514 100644
--- a/meta/recipes-bsp/grub/grub-efi_2.00.bb
+++ b/meta/recipes-bsp/grub/grub-efi_2.00.bb
@@ -27,6 +27,7 @@ SRC_URI = ftp://ftp.gnu.org/gnu/grub/grub-${PV}.tar.gz \
file://grub-no-unused-result.patch \
file://grub-2.00-ignore-gnulib-gets-stupidity.patch \
file://fix-issue-with-flex-2.5.37.patch \
+ file://grub-efi-allow-a-compilation-without-mcmodel-large.patch \
SRC_URI[md5sum] = e927540b6eda8b024fb0391eeaa4091c
SRC_URI[sha256sum] =
65b39a0558f8c802209c574f4d02ca263a804e8a564bc6caf1cd0fd3b3cc11e3
--
1.8.3
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/2 v3] grub-efi: change to generate EFI image in target package
From: Jackie Huang jackie.hu...@windriver.com
v3 comments:
Drop the original solution to generate and deploy EFI image in the -native
packae and change to do that in taret package, and the -native one only
provides the grub-mkimage binary. No need 3 files anymore, make them in
one bb.
--
The following changes since commit 0eb947454e1c92467283e6f1adeca67c7c57698b:
python: Fix ptest not working problems (2013-11-18 13:04:13 +)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib jhuang0/d_grub-efi_1119_0
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=jhuang0/d_grub-efi_1119_0
Jackie Huang (2):
grub-efi: change to generate EFI image in target package
grub-efi: allow compilation without large model support
meta/classes/grub-efi.bbclass | 4 +-
...allow-a-compilation-without-mcmodel-large.patch | 69 ++
.../{grub-efi-native_2.00.bb = grub-efi_2.00.bb} | 44 --
3 files changed, 96 insertions(+), 21 deletions(-)
create mode 100644
meta/recipes-bsp/grub/files/grub-efi-allow-a-compilation-without-mcmodel-large.patch
rename meta/recipes-bsp/grub/{grub-efi-native_2.00.bb = grub-efi_2.00.bb}
(77%)
--
1.8.3
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] kernel: restore scripts in the sysroot
On Nov 19, 2013, at 2:45 PM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
On Tue, 2013-11-19 at 14:39 -0800, Khem Raj wrote:
On Nov 19, 2013, at 2:36 PM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
On Tue, 2013-11-19 at 14:29 -0800, Khem Raj wrote:
Well reproducer case is that build from sstate but such that an external
module needs to be rebuilt
if external module also comes from sstate then it all is fine. Its only
when everything is coming from
sstate except this external module which needs to be rebuilt then you see
this problem.
now, I see the code in module-base.class
#
# Ensure the hostprogs are available for module compilation. Modules that
# inherit this recipe and override do_compile() should be sure to call
# do_make_scripts() or ensure the scripts are built independently.
#
do_make_scripts() {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
make CC=${KERNEL_CC} LD=${KERNEL_LD} AR=${KERNEL_AR} \
-C ${STAGING_KERNEL_DIR} scripts
}
so it expects that, do_make_scripts is explicitly called by external
module recipes
and my recipes did override module_do_compile task but not do_compile like
below
module_do_compile() {
oe_runmake
}
so, is comment wrong there should it say module_do_compile instead ?
will it work with sstate always ?
it will be OK to revert it if thats the case.
Did you inherit module-base or module? I think the wording applies to
module and not module-base. I think the function used to be in module
and was moved along with the comment which is now incorrect.
inherit module
So in that case there is:
addtask make_scripts after do_patch before do_compile
do_make_scripts[lockfiles] = ${TMPDIR}/kernel-scripts.lock
do_make_scripts[deptask] = “do_populate_sysroot”
yes I see.
which forces the make_scripts task to run before compile. I don't see
how that could therefore fail? :/
Do you have a copy of the exact log?
Not anymore, it was sometime ago, the logs are unfortunately recycled.
I'm wondering if this is another
variant of the bitbake dependency bug I just tracked down
(http://git.yoctoproject.org/cgit.cgi/poky-contrib/patch/?id=7b49d336c4672f3dfa78e1c3f1f5c7384264a118)
ah very likely, I think I will try this fix and revert the kernel.bbclass fix
locally and see if I still am
able to reproduce this issue. In any case I think the kernel.bbclass may be
abandoned since I now think it
was a wrong fix although it did fix the problem
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] kernel build fail after update
I met the same error when I inherited 'rm_work' in local.conf and performed a world build. This is reproducible with the latest code. 1. add in local.conf INHERIT += rm_work 2. bitbake world //Chen Qi On 11/19/2013 07:21 AM, Yi Qingliang wrote: after update poky, I got error when compile my own kernel, it looks like there is no directory '/mnt/src/kl360-build/tmp/work/kl360-jilong-linux- gnueabi/linux-jilong/3.9.4-gitAUTOINC+5dbff4f559/image'. in my bb file, I only inherit kernel. I found one patch 'Use hardlinks for do_populate_sysroot for speed' may be related with this error. ERROR: Error executing a python function in /mnt/src/optimus/poky/../meta- jilong/recipes-kernel/linux/linux-jilong.bb: The stack trace of python calls that resulted in this exception/failure was: File: 'sysroot_stage_all', lineno: 6, function: module 0002:def sysroot_stage_all(d): 0003:oe.path.copyhardlinktree(d.expand(/mnt/src/kl360- build/tmp/work/kl360-jilong-linux-gnueabi/linux-jilong/3.9.4- gitAUTOINC+5dbff4f559/image/usr/src/kernel), d.expand(/mnt/src/kl360- build/tmp/work/kl360-jilong-linux-gnueabi/linux-jilong/3.9.4- gitAUTOINC+5dbff4f559/sysroot-destdir//usr/src/kernel)) 0004: 0005: *** 0006:sysroot_stage_all(d) 0007: File: 'sysroot_stage_all', lineno: 3, function: sysroot_stage_all 0001: 0002:def sysroot_stage_all(d): *** 0003:oe.path.copyhardlinktree(d.expand(/mnt/src/kl360- build/tmp/work/kl360-jilong-linux-gnueabi/linux-jilong/3.9.4- gitAUTOINC+5dbff4f559/image/usr/src/kernel), d.expand(/mnt/src/kl360- build/tmp/work/kl360-jilong-linux-gnueabi/linux-jilong/3.9.4- gitAUTOINC+5dbff4f559/sysroot-destdir//usr/src/kernel)) 0004: 0005: 0006:sysroot_stage_all(d) 0007: File: '/mnt/src/optimus/poky/meta/lib/oe/path.py', lineno: 93, function: copyhardlinktree 0089:bb.utils.mkdirhier(dst) 0090:if os.path.isdir(src) and not len(os.listdir(src)): 0091:return 0092: *** 0093:if (os.stat(src).st_dev == os.stat(dst).st_dev): 0094:# Need to copy directories only with tar first since cp will error if two 0095:# writers try and create a directory at the same time 0096:cmd = 'cd %s; find . -type d -print | tar -cf - -C %s -p -- files-from - --no-recursion | tar -xf - -C %s' % (src, src, dst) 0097:check_output(cmd, shell=True, stderr=subprocess.STDOUT) Exception: OSError: [Errno 2] No such file or directory: '/mnt/src/kl360- build/tmp/work/kl360-jilong-linux-gnueabi/linux-jilong/3.9.4- gitAUTOINC+5dbff4f559/image/usr/src/kernel' ERROR: Function failed: sysroot_stage_all ERROR: Logfile of failure stored in: /mnt/src/kl360-build/tmp/work/kl360- jilong-linux-gnueabi/linux-jilong/3.9.4- gitAUTOINC+5dbff4f559/temp/log.do_populate_sysroot.5146 ERROR: Task 3 (/mnt/src/optimus/poky/../meta-jilong/recipes- kernel/linux/linux-jilong.bb, do_populate_sysroot) failed with exit code '1' ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] kernel: restore scripts in the sysroot
On Tue, Nov 19, 2013 at 9:59 PM, Khem Raj raj.k...@gmail.com wrote:
On Nov 19, 2013, at 2:45 PM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
On Tue, 2013-11-19 at 14:39 -0800, Khem Raj wrote:
On Nov 19, 2013, at 2:36 PM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
On Tue, 2013-11-19 at 14:29 -0800, Khem Raj wrote:
Well reproducer case is that build from sstate but such that an external
module needs to be rebuilt
if external module also comes from sstate then it all is fine. Its only
when everything is coming from
sstate except this external module which needs to be rebuilt then you see
this problem.
now, I see the code in module-base.class
#
# Ensure the hostprogs are available for module compilation. Modules that
# inherit this recipe and override do_compile() should be sure to call
# do_make_scripts() or ensure the scripts are built independently.
#
do_make_scripts() {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
make CC=${KERNEL_CC} LD=${KERNEL_LD} AR=${KERNEL_AR} \
-C ${STAGING_KERNEL_DIR} scripts
}
so it expects that, do_make_scripts is explicitly called by external
module recipes
and my recipes did override module_do_compile task but not do_compile
like below
module_do_compile() {
oe_runmake
}
so, is comment wrong there should it say module_do_compile instead ?
will it work with sstate always ?
it will be OK to revert it if thats the case.
Did you inherit module-base or module? I think the wording applies to
module and not module-base. I think the function used to be in module
and was moved along with the comment which is now incorrect.
inherit module
So in that case there is:
addtask make_scripts after do_patch before do_compile
do_make_scripts[lockfiles] = ${TMPDIR}/kernel-scripts.lock
do_make_scripts[deptask] = “do_populate_sysroot”
yes I see.
which forces the make_scripts task to run before compile. I don't see
how that could therefore fail? :/
Do you have a copy of the exact log?
Not anymore, it was sometime ago, the logs are unfortunately recycled.
I'm wondering if this is another
variant of the bitbake dependency bug I just tracked down
(http://git.yoctoproject.org/cgit.cgi/poky-contrib/patch/?id=7b49d336c4672f3dfa78e1c3f1f5c7384264a118)
ah very likely, I think I will try this fix and revert the kernel.bbclass fix
locally and see if I still am
able to reproduce this issue. In any case I think the kernel.bbclass may be
abandoned since I now think it
was a wrong fix although it did fix the problem
Agreed.
Since you have control over your recipes, you don't have to worry
about some of the more evil ones that build, and inside their own build head
reference the kernel-staging tree and attempt to build modules. Just getting
the right inheritance should fix it up.
The other case is a different concern, and even then, including module, and
overriding the do_compile() should work to get the scripts restored and not
just attempt to launch a build.
I'm going to be in Transit tomorrow, so won't be all that responsive, but
my vote is now to simply revert the sstate scripts changes once Khem confirms
that he is ok for his builds.
Cheers,
Bruce
Cheers,
Richard
--
Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/7] packagegroup-core-boot: Drop build-time dependency on virtual/kernel
On 11/17/2013 09:52 PM, Martin Jansa wrote: * because kernel isn't needed to build packagegroup and building it doesn't influence if it's included in image or not. Signed-off-by: Martin Jansa martin.ja...@gmail.com --- meta/recipes-core/packagegroups/packagegroup-core-boot.bb | 1 - 1 file changed, 1 deletion(-) diff --git a/meta/recipes-core/packagegroups/packagegroup-core-boot.bb b/meta/recipes-core/packagegroups/packagegroup-core-boot.bb index 486385a..5455899 100644 --- a/meta/recipes-core/packagegroups/packagegroup-core-boot.bb +++ b/meta/recipes-core/packagegroups/packagegroup-core-boot.bb @@ -5,7 +5,6 @@ SUMMARY = Minimal boot requirements DESCRIPTION = The minimal set of packages required to boot the system LICENSE = MIT -DEPENDS = virtual/kernel PR = r11 inherit packagegroup What about adding this dependency in image.bbclass? Otherwise, the kernel will not get built if it's not pulled in by other packages like v86d. For example, if we build core-image-minimal for qemumips, the kernel is not built by default and we have to `bitbake linux-yocto' before we can use `runqemu' to start target. Best Regards, Chen Qi ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [CONSOLIDATED PULL 00/51]
Richard, This is the pending pulls since last week that we have held up due to various issue with the autobuilder. As I send the email, the AB had not completed yet, but I have reviewed these patches and build them locally for 3 platforms. Please review the final AB output. There are at least 2 meta-yocto* patches that need to be merged as well for the acpi scripts from Paul and a patch for the format specificer. Thanks Sau! The following changes since commit 0eb947454e1c92467283e6f1adeca67c7c57698b: python: Fix ptest not working problems (2013-11-18 13:04:13 +) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib sgw/stage http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=sgw/stage Alexandru-Cezar Sardan (1): gcc: changed multilib options handling Carlos Rafael Giani (1): gstreamer1.0: upgrade to 1.2.0 Chen Qi (4): sysvinit: fix problem in switching runlevels license.bbclass: fix missing of license files on ubuntu build host shadow-native: allow for setting password in clear text sysvinit: use ALTERNATIVE to manage sulogin Chunrong Guo (1): mdadm: flag __SANE_USERSPACE_TYPES__ to include int-ll64.h for powerpc64 Cristian Iorga (1): telepathy-idle: upgrade to 0.2.0 Cristiana Voicu (2): at-spi2-core: upgrade to 2.10.2 liburcu: upgrade to 0.8.1 Dominik Holland (1): dbus: Don't depend on dbus-ptest-ptest for the nativesdk-dbus package Florin Sarbu (1): systemd: Fix packaging of pam config files. Hans Beckerus (1): initscripts: add missing dmesg.sh to run-level S Hongxu Jia (4): kernel-grub.bbclass: support /boot area within root partition lib32-qt4-examples: fix QA warnings and INSANE_SKIP not work lib32-packagegroup-core-nfs: fix qa issue - install files into a shared area when those files already exist xorg-driver: fix qa issue while multilib enabled - contains Xorg driver but no xorg-abi Irina Patru (1): distrodata.bbclass: Add fetch2 handlers to svn case in checkpkg Jack Mitchell (1): libjson: update to 0.11 and rename to json-c Kai Kang (1): lsb: update directory of install_initd and remove_initd Khem Raj (2): tcl: Install header into 8.6 instead of PN-PV in user/include libnl: Fix random segfaults due to memory corruption Laurentiu Palcu (1): flex: fix m4 issue on target Lu Chong (1): util-linux: Fix QA warnings about ALTERNATIVES Mihaela Sendrea (1): expect: Add recipe Ming Liu (3): grub: add xz RDEPENDS qemu: explicitly disable xen support kernel.bbclass: move bundle_initramfs after kernel_link_vmlinux Otavio Salvador (1): lttng-modules: Update to 2.3.3 version Paul Eggleton (1): ia32-base.inc: remove eee-acpi-scripts from MACHINE_EXTRA_RRECOMMENDS Paul Woegerer (2): lttng-ust: Update to version 2.3.1 lttng-tools: Update to version 2.3.1 Phil Blundell (3): boost: Add patch to avoid undefined references to boost::atomic::lockpool::get_lock_for() PATCH] kernel.bbclass: Use lzma not lzmash for decompressing bitbake.conf: Remove obsolete/unused MIRROR cruft Qiang Chen (1): util-linux: collect libs for related libxx-dev package Ross Burton (3): json-glib: upgrade to 0.16.2 weston: remove reference to gles in PACKAGECONFIG librsvg: upgrade to 2.40.0 Saul Wold (10): binutils: Add embedspu to standard binutils package sysstat: upgrade to 10.2.0 libcheck: upgrade to 0.9.11 libpcre: Cleanup FILESPATH squashfs-tools: remove FILESEXTRAPATH and move patches directory qemu-helper-native: remove unneeded FILESEXTRAPATH image_types: newer btrfs.mkfs needs an empty file to build the disk in btrfs-tools: Update to git HEAD kconfig-frontends: upgrade to 3.12.0.0 santiy.bbclass: Add testfile info to error messages (more verbose) Tobias Henkel (1): icecc: Use bb.utils.which instead of calling which Wenzong Fan (1): udev: remove extra -dev/-dbg packages meta/classes/distrodata.bbclass| 43 +- meta/classes/icecc.bbclass |6 +- meta/classes/image_types.bbclass |1 + meta/classes/insane.bbclass|3 +- meta/classes/kernel-grub.bbclass |9 +- meta/classes/kernel.bbclass|4 +- meta/classes/license.bbclass |4 +- meta/classes/sanity.bbclass|6 +- meta/conf/bitbake.conf | 11 - meta/conf/distro/include/seperatebuilddir.inc |2 +- meta/conf/machine/include/ia32-base.inc|2 +- meta/recipes-bsp/grub/grub_2.00.bb |2 +- .../fix-svc-gtk-doc.h-target.patch |0 ...athy-idle_0.1.16.bb = telepathy-idle_0.2.0.bb} |4 +- meta/recipes-core/dbus/dbus.inc|3 +- .../init-ifupdown/init-ifupdown_1.0.bb |2 +- meta/recipes-core/initscripts/initscripts_1.0.bb |8 +-
