[OE-core] [oeqa][PATCH] lib/oeqa/runtime: add test for gzip
From: Ting Wang ting.w...@windriver.com
Function tests:
1)gzip compress file
2)compressed file integrity check
3)zcat compress file
4)gzip decompress file
---
meta/classes/testimage.bbclass |4 ++--
meta/lib/oeqa/runtime/gzip.py | 32
2 files changed, 34 insertions(+), 2 deletions(-)
create mode 100644 meta/lib/oeqa/runtime/gzip.py
diff --git a/meta/classes/testimage.bbclass b/meta/classes/testimage.bbclass
index 4777e14..0d861e6 100644
--- a/meta/classes/testimage.bbclass
+++ b/meta/classes/testimage.bbclass
@@ -27,8 +27,8 @@ TEST_LOG_DIR ?= ${WORKDIR}/testimage
DEFAULT_TEST_SUITES = ping auto
DEFAULT_TEST_SUITES_pn-core-image-minimal = ping
-DEFAULT_TEST_SUITES_pn-core-image-sato = ping ssh df connman syslog xorg scp
vnc date rpm smart dmesg python
-DEFAULT_TEST_SUITES_pn-core-image-sato-sdk = ping ssh df connman syslog xorg
scp vnc date perl ldd gcc rpm smart kernelmodule dmesg python
+DEFAULT_TEST_SUITES_pn-core-image-sato = ping ssh df connman syslog xorg scp
vnc date rpm smart dmesg python gzip
+DEFAULT_TEST_SUITES_pn-core-image-sato-sdk = ping ssh df connman syslog xorg
scp vnc date perl ldd gcc rpm smart kernelmodule dmesg python gzip
TEST_SUITES ?= ${DEFAULT_TEST_SUITES}
diff --git a/meta/lib/oeqa/runtime/gzip.py b/meta/lib/oeqa/runtime/gzip.py
new file mode 100644
index 000..50e3b8f
--- /dev/null
+++ b/meta/lib/oeqa/runtime/gzip.py
@@ -0,0 +1,32 @@
+import unittest
+import os
+from oeqa.oetest import oeRuntimeTest, skipModule
+from oeqa.utils.decorators import *
+
+class GzipFunctionTest(oeRuntimeTest):
+
+@skipUnlessPassed('test_ssh')
+def test_gzip_create_testfile(self):
+(status, output) = self.target.run('echo It is a test file
/tmp/testfile.gzip')
+self.assertEqual(status, 0, msg=gzip test file create failed)
+
+@skipUnlessPassed('test_gzip_create_testfile')
+def test_gzip_fun1_compress(self):
+(status, output) = self.target.run('gzip /tmp/testfile.gzip')
+self.assertEqual(status, 0, msg=gzip compress file failed.)
+
+def test_gzip_fun2_integrity_check(self):
+(status, output) = self.target.run('gzip -t /tmp/testfile.gzip.gz')
+self.assertEqual(status, 0, msg=Check the compressed file integrity
failed)
+
+def test_gzip_fun3_zcat(self):
+(status, output) = self.target.run('zcat /tmp/testfile.gzip.gz')
+self.assertEqual(output, It is a test file, msg=Incorrect output:
%s % output)
+
+def test_gzip_fun4_decompress(self):
+(status, output) = self.target.run('gunzip /tmp/testfile.gzip.gz ls
/tmp/testfile.gzip')
+self.assertEqual(status, 0, msg=gzip decompress file failed.)
+
+@classmethod
+def tearDownClass(self):
+oeRuntimeTest.tc.target.run(rm /tmp/testfile.gzip)
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] rpm: fix a endian incompatible error in generating tag
A flaw was found in the way rpm generating arbitrary tags, which leads to a
incorrect query result, this issue is introduced by a incompatible endianess
when the generating process is executed on different architectures.
This patch resolves it by taking a uniform byte order.
Signed-off-by: Ming Liu ming@windriver.com
---
.../rpm-tag-generate-endian-conversion-fix.patch | 29
meta/recipes-devtools/rpm/rpm_5.4.9.bb |1 +
2 files changed, 30 insertions(+), 0 deletions(-)
create mode 100644
meta/recipes-devtools/rpm/rpm/rpm-tag-generate-endian-conversion-fix.patch
diff --git
a/meta/recipes-devtools/rpm/rpm/rpm-tag-generate-endian-conversion-fix.patch
b/meta/recipes-devtools/rpm/rpm/rpm-tag-generate-endian-conversion-fix.patch
new file mode 100644
index 000..4379515
--- /dev/null
+++ b/meta/recipes-devtools/rpm/rpm/rpm-tag-generate-endian-conversion-fix.patch
@@ -0,0 +1,29 @@
+fix a endian incompatible error in generating rpm tag
+
+A flaw was found in the way rpm generating arbitrary tags, which leads to a
+incorrect query result, this issue is introduced by a incompatible endianess
+when the generating process is executed on different architectures.
+
+This patch resolves it by taking a uniform byte order.
+
+Upstream-Status: Pending
+
+Signed-off-by: Ming Liu ming@windriver.com
+---
+ tagname.c |3 +++
+ 1 file changed, 3 insertions(+)
+
+diff -urpN a/rpmdb/tagname.c b/rpmdb/tagname.c
+--- a/rpmdb/tagname.c
b/rpmdb/tagname.c
+@@ -152,7 +152,10 @@ static rpmTag _tagGenerate(const char *s
+ xx = rpmDigestUpdate(ctx, s, nb);
+ xx = rpmDigestFinal(ctx, digest, digestlen, 0);
+ if (digest digestlen 4) {
++ /* The tag is stored in a uniform byte order for cross-endian
compatibility.
++ Swap to little-endian if appropriate. */
+ memcpy(tag, digest + (digestlen - 4), 4);
++ tag = htole32(tag);
+ tag = (rpmTag) (tag 0x3fff);
+ tag = (rpmTag) (tag | 0x4000);
+ }
diff --git a/meta/recipes-devtools/rpm/rpm_5.4.9.bb
b/meta/recipes-devtools/rpm/rpm_5.4.9.bb
index 9d376a5..7921f40 100644
--- a/meta/recipes-devtools/rpm/rpm_5.4.9.bb
+++ b/meta/recipes-devtools/rpm/rpm_5.4.9.bb
@@ -89,6 +89,7 @@ SRC_URI =
http://www.rpm5.org/files/rpm/rpm-5.4/rpm-5.4.9-0.20120508.src.rpm;ex
file://debugedit-valid-file-to-fix-segment-fault.patch \
file://rpm-platform-file-fix.patch \
file://rpm-lsb-compatibility.patch \
+ file://rpm-tag-generate-endian-conversion-fix.patch \
# Uncomment the following line to enable platform score debugging
--
1.7.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] busybox: lineedit: initialize delptr
In vi mode, the 'p' and 'P' commands caused a segfault when nothing had
been put in the buffer yet because the delptr was not initialized.
Signed-off-by: Ming Liu ming@windriver.com
---
.../busybox-lineedit-initialize-delptr.patch | 23
meta/recipes-core/busybox/busybox_1.21.1.bb|1 +
2 files changed, 24 insertions(+), 0 deletions(-)
create mode 100644
meta/recipes-core/busybox/busybox/busybox-lineedit-initialize-delptr.patch
diff --git
a/meta/recipes-core/busybox/busybox/busybox-lineedit-initialize-delptr.patch
b/meta/recipes-core/busybox/busybox/busybox-lineedit-initialize-delptr.patch
new file mode 100644
index 000..e59211b
--- /dev/null
+++ b/meta/recipes-core/busybox/busybox/busybox-lineedit-initialize-delptr.patch
@@ -0,0 +1,23 @@
+Derived from:
+http://git.busybox.net/busybox/commit/?id=46031da862a60422f80050a905cea0b67026b021.
+
+In vi mode, the 'p' and 'P' commands caused a segfault when nothing had
+been put in the buffer yet because the delptr was not initialized.
+
+Upstream-Status: Backport
+
+Signed-off-by: Shawn J. Goff shawn7...@gmail.com
+Signed-off-by: Denys Vlasenko vda.li...@googlemail.com
+Signed-off-by: Ming Liu ming@windriver.com
+
+diff -urpN a/libbb/lineedit.c b/libbb/lineedit.c
+--- a/libbb/lineedit.c
b/libbb/lineedit.c
+@@ -187,6 +187,7 @@ extern struct lineedit_statics *const li
+ cmdedit_termw = 80; \
+ IF_FEATURE_EDITING_FANCY_PROMPT(num_ok_lines = 1;) \
+ IF_USERNAME_OR_HOMEDIR(home_pwd_buf = (char*)null_str;) \
++ IF_FEATURE_EDITING_VI(delptr = delbuf;) \
+ } while (0)
+
+ static void deinit_S(void)
diff --git a/meta/recipes-core/busybox/busybox_1.21.1.bb
b/meta/recipes-core/busybox/busybox_1.21.1.bb
index 267604a..cf59f58 100644
--- a/meta/recipes-core/busybox/busybox_1.21.1.bb
+++ b/meta/recipes-core/busybox/busybox_1.21.1.bb
@@ -35,6 +35,7 @@ SRC_URI =
http://www.busybox.net/downloads/busybox-${PV}.tar.bz2;name=tarball \
file://busybox-list-suid-and-non-suid-app-configs.patch \
file://busybox-sed-fix-sed-clusternewline-testcase.patch \
file://find-get-rid-of-nested-functions.patch \
+ file://busybox-lineedit-initialize-delptr.patch \
SRC_URI[tarball.md5sum] = 795394f83903b5eec6567d51eebb417e
--
1.7.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] attr: enable ptest support
Install attr test suite and run it as ptest.
Signed-off-by: Chong Lu chong...@windriver.com
---
meta/recipes-support/attr/attr.inc | 15 +++-
.../attr/files/attr-make-ptest-pass.patch | 82 ++
meta/recipes-support/attr/files/run-ptest | 5 ++
3 files changed, 101 insertions(+), 1 deletion(-)
create mode 100644 meta/recipes-support/attr/files/attr-make-ptest-pass.patch
create mode 100644 meta/recipes-support/attr/files/run-ptest
diff --git a/meta/recipes-support/attr/attr.inc
b/meta/recipes-support/attr/attr.inc
index 4961ba7..8cb08e4 100644
--- a/meta/recipes-support/attr/attr.inc
+++ b/meta/recipes-support/attr/attr.inc
@@ -11,7 +11,10 @@ LIC_FILES_CHKSUM =
file://doc/COPYING;md5=2d0aa14b3fce4694e4f615e30186335f \
file://attr/attr.c;endline=17;md5=be0403261f0847e5f43ed5b08d19593c \
file://libattr/libattr.c;endline=17;md5=7970f77049f8fa1199fff62a7ab724fb
-SRC_URI = http://download.savannah.gnu.org/releases/attr/${BP}.src.tar.gz;
+SRC_URI = http://download.savannah.gnu.org/releases/attr/${BP}.src.tar.gz \
+ file://attr-make-ptest-pass.patch \
+ file://run-ptest \
+
require ea-acl.inc
@@ -20,3 +23,13 @@ do_install_append() {
sed -i ${D}${libdir}/libattr.la -e \
s,^libdir=\'${base_libdir}\'$,libdir=\'${libdir}\',
}
+
+inherit ptest
+
+do_install_ptest() {
+ cp -r ${S}/test ${D}${PTEST_PATH}
+ mkdir ${D}${PTEST_PATH}/include
+ cp ${S}/include/builddefs ${S}/include/buildmacros
${S}/include/buildrules ${D}${PTEST_PATH}/include/
+}
+
+RDEPENDS_${PN}-ptest = coreutils perl-module-filehandle
perl-module-getopt-std perl-module-posix
diff --git a/meta/recipes-support/attr/files/attr-make-ptest-pass.patch
b/meta/recipes-support/attr/files/attr-make-ptest-pass.patch
new file mode 100644
index 000..e2da8b0
--- /dev/null
+++ b/meta/recipes-support/attr/files/attr-make-ptest-pass.patch
@@ -0,0 +1,82 @@
+attr: make ptest pass
+
+Upstream-Status: Inappropriate [embedded specific]
+
+Delete the second '@' character of the same row in test/Makefile, else
+we would get the error as below:
+@echo: command not found
+In fs.test file, the result of `ls -s' is incorrect. Change it to make
+ext-tests pass.
+
+Signed-off-by: Chong Lu chong...@windriver.com
+---
+ test/Makefile|4 ++--
+ test/ext/fs.test | 22 +++---
+ 2 files changed, 13 insertions(+), 13 deletions(-)
+
+diff --git a/test/Makefile b/test/Makefile
+index b7bd8db..d916bf4 100644
+--- a/test/Makefile
b/test/Makefile
+@@ -40,10 +40,10 @@ $(TEST):
+ @echo *** $@ ***; perl run $@
+
+ $(EXT):
+- @echo EXT specific tests; @echo *** $@ ***; perl run $@
++ @echo EXT specific tests; echo *** $@ ***; perl run $@
+
+ $(ROOT):
+- @echo Note: Tests must run as root; @echo *** $@ ***; perl run $@
++ @echo Note: Tests must run as root; echo *** $@ ***; perl run $@
+
+ .PHONY: $(TEST) $(EXT) $(ROOT)
+ .NOTPARALLEL:
+diff --git a/test/ext/fs.test b/test/ext/fs.test
+index cc28fec..381d54b 100644
+--- a/test/ext/fs.test
b/test/ext/fs.test
+@@ -19,15 +19,15 @@ Test extended attribute block sharing
+ $ touch f g h
+ $ setfattr -n user.novalue f g h
+ $ ls -s f g h
+- 4 f
+- 4 g
+- 4 h
++ 0 f
++ 0 g
++ 0 h
+
+ $ setfattr -n user.name -v value f
+ $ ls -s f g h
+- 4 f
+- 4 g
+- 4 h
++ 0 f
++ 0 g
++ 0 h
+
+ $ getfattr -d f g h
+# file: f
+@@ -43,14 +43,14 @@ Test extended attribute block sharing
+
+ $ setfattr -n user.name -v value g
+ $ ls -s f g h
+- 4 f
+- 4 g
+- 4 h
++ 0 f
++ 0 g
++ 0 h
+
+ $ setfattr -x user.novalue h
+ $ ls -s f g h
+- 4 f
+- 4 g
++ 0 f
++ 0 g
+0 h
+
+ $ setfattr -n user.name -v other-value g
+--
+1.7.9.5
+
diff --git a/meta/recipes-support/attr/files/run-ptest
b/meta/recipes-support/attr/files/run-ptest
new file mode 100644
index 000..f0bd9fc
--- /dev/null
+++ b/meta/recipes-support/attr/files/run-ptest
@@ -0,0 +1,5 @@
+#!/bin/sh
+
+make -C test -k tests root-tests ext-tests |sed \
+ -e 's|^\[.*\] \(.*\) -- ok$|PASS: \1|' \
+ -e 's|^\[.*\] \(.*\) -- failed|FAIL: \1|'
--
1.8.1.2
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] attr: enable ptest support
The following changes since commit 6ee5d95317de77c1cfb6db6f1ab2de77f5fa085e: bitbake: fetch2/gitannex: Fix function arguments to match bitbake master (2014-01-08 15:27:37 +) are available in the git repository at: git://git.pokylinux.org/poky-contrib chonglu/attr http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=chonglu/attr Chong Lu (1): attr: enable ptest support meta/recipes-support/attr/attr.inc | 15 +++- .../attr/files/attr-make-ptest-pass.patch | 82 ++ meta/recipes-support/attr/files/run-ptest | 5 ++ 3 files changed, 101 insertions(+), 1 deletion(-) create mode 100644 meta/recipes-support/attr/files/attr-make-ptest-pass.patch create mode 100644 meta/recipes-support/attr/files/run-ptest -- 1.8.1.2 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oeqa][PATCH] lib/oeqa/runtime: add test for gzip
On 9 January 2014 08:25, ting.w...@windriver.com wrote: Function tests: 1)gzip compress file 2)compressed file integrity check 3)zcat compress file 4)gzip decompress file Wouldn't this be better implemented as a ptest for gzip? The qemu image tests are more concerned with image-wide functionality that can't be unit tested independently, but verifying that gzip works can be. Also, your test simply verifies that the commands execute, not that the contents is what you expect: a gzip that produced corrupted archives wouldn't be detected by this test. Finally, as I learnt yesterday, the skipUnlessPassed decorator isn't used to enforce ordering, so test_gzip_fun1_compress only runs after _create_testfile because it sorts that way alphabetically, not because of your decorators. As creating a file isn't a test, just do that in the test itself. Ross ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH V2] Modify buildstats to be merged inside buildhistory
--- a/meta/classes/buildhistory.bbclass
+++ b/meta/classes/buildhistory.bbclass
@@ -16,9 +16,12 @@ BUILDHISTORY_IMAGE_FILES ?= /etc/passwd
/etc/group
BUILDHISTORY_COMMIT ?= 0
BUILDHISTORY_COMMIT_AUTHOR ?= buildhistory
buildhistory@${DISTRO}
BUILDHISTORY_PUSH_REPO ?=
+BUILDSTATS_BASE = ${BUILDHISTORY_DIR}/buildstats
SSTATEPOSTINSTFUNCS += buildhistory_emit_pkghistory
+inherit buildstats
+
I don't think we need this inherit line. The user can still decide whether to
include it or not, if it is included, it can be under buildhistory control.
So it
should be safe simply to remove it.
Removing this inherit and using the manual suggested steps to activate
buildhistory in local.conf:
INHERIT += buildhistory
BUILDHISTORY_COMMIT = 1
Will result in buildhistory being inherited before buildstats:
cornel@NODE1:~/SSD/poky/build$ bitbake -e | grep 'INHERIT='
INHERIT= buildhistory poky-sanity package_rpm buildstats image-mklibs
image-prelink debian devshell sstate license sanity
This will cause part of the build_stats file(which is written at the end of the
build) to be left out of the commits when git is used for buildhistory:
cornel@NODE1:~/SSD/poky/build/buildhistory$ git status
# On branch master
# Changes not staged for commit:
# (use git add file... to update what will be committed)
# (use git checkout -- file... to discard changes in working directory)
#
# modified:
buildstats/core-image-minimal-qemux86-64/201401091123/build_stats
#
no changes added to commit (use git add and/or git commit -a)
An easy way to avoid this is to activate buildhistory by adding it after
buildstats in USER_CLASSES in local.conf:
USER_CLASSES ?= buildstats image-mklibs image-prelink buildhistory
Or
USER_CLASSES += buildhistory
So in order to make this work, we either change the suggested way to enable
buildhistory or find a workaround in code.
Regards,
Corneliu
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] bug scrub - RFC
On 08/01/14 23:20, Trevor Woerner wrote: Hi everyone, This is a Request For Comments email regarding a bug scrub party the OE TSC would like to hold. background: It has been noticed that the number of bugs in the bugzilla[1] has been climbing; it would be nice to hold a bug scrub event to raise awareness of the bugzilla and hopefully get some issues resolved. questions: 1) Currently it has been suggested this should be a 2-day event, should these two days be during the week or over a weekend? In either case, which 2 days? If it's two days long then why don't you do the best of both worlds and have a Friday/Saturday or Sunday/Monday combination? 2) Since this is an OE event, should it focus only on OE bugs[2], or should it be generalized for any bug? I don't think we should be limiting people to what they can work on while participating. 3) Should we create a sign-up sheet (wiki) to keep track of who is participating, and which issues are being looked at by whom? (anything else?) I think maybe a I will be there at some point for some amount of time column would be good, and maybe a place to register interest for certain bugs or areas of code that need improvement. notes: 1) If you or the company for which you work uses OE/Yocto, please consider making this a company event and having/allowing the engineers (to) participate. 2) Even if you're not a recipe-, or a build-, or a python-wizard there are still many things you can do to contribute. Being able to reproduce a bug or reporting that a bug can't be reproduced can sometimes be quite helpful (sometimes this points to a host issue or to a bug's description not being descriptive enough). Sometimes a bug is stuck in the needs info stage which maybe you can provide. People with different environments is always useful, either bleeding edge or very stable. Variety is the spice of life ;) 3) Can anyone think of way to help get the word out? 4) It would be cool to be able to provide incentives to help people get interested and contributing to knocking some bugs around. So if anyone (*cough* Intel) has any neat hardware (*cough* Galileo, Edison) they could offer as an incentive (or, conversely, if there's a board you'd like to see Yocto target) please see about making that happen. A unified effort towards a new trendy board would be a fun goal, but I worry that hardware teething issues would then eat up run of the mill bug fixing time, handouts for participation however, (bug fixed/reviewed by/tested by) would be a great idea. Thanks and best regards, Trevor [1] https://bugzilla.yoctoproject.org [2] https://bugzilla.yoctoproject.org/buglist.cgi?bug_status=UNCONFIRMEDbug_status=NEWbug_status=ACCEPTEDbug_status=IN%20PROGRESS%20DESIGNbug_status=IN%20PROGRESS%20DESIGN%20COMPLETEbug_status=IN%20PROGRESS%20IMPLEMENTATIONbug_status=IN%20PROGRESS%20REVIEWbug_status=REOPENEDbug_status=NEEDINFObug_status=WaitForUpstreamclassification=Build%20System%20%26%20Metadatalist_id=156074product=OE-Corequery_format=advancedresolution=---order=bug_id%20DESCquery_based_on= Cheers, -- Jack Mitchell (j...@embed.me.uk) Embedded Systems Engineer Cambridgeshire, UK http://www.embed.me.uk -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] libsoup: Remove libproxy from DEPENDS
Although libsoup did use to support direct usage of libproxy, it hasn't done so for some time. Worse, if libsoup depends on libproxy then it is impossible to build libproxy against webkit since webkit itself depends on libsoup in some configurations. Fix this by removing the extraneous entry from DEPENDS. Signed-off-by: Phil Blundell p...@pbcl.net --- meta/recipes-support/libsoup/libsoup-2.4_2.44.2.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-support/libsoup/libsoup-2.4_2.44.2.bb b/meta/recipes-support/libsoup/libsoup-2.4_2.44.2.bb index a7ea106..b245f68 100644 --- a/meta/recipes-support/libsoup/libsoup-2.4_2.44.2.bb +++ b/meta/recipes-support/libsoup/libsoup-2.4_2.44.2.bb @@ -7,7 +7,7 @@ LIC_FILES_CHKSUM = file://COPYING;md5=5f30f0716dfdd0d91eb439ebec522ec2 SECTION = x11/gnome/libs -DEPENDS = glib-2.0 gnutls libxml2 libproxy sqlite3 intltool-native +DEPENDS = glib-2.0 gnutls libxml2 sqlite3 intltool-native # libsoup-gnome is entirely deprecated and just stubs in 2.42 onwards. Enable # by default but let it be easily disabled. -- 1.8.5 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] qemu: Remove stray .git files after unpacking
The qemu tarball ships some extraneous .git metadata in the dtc/ and pixman/
subfolders, containing a reference to the path ../.git/modules which
doesn't exist. The presence of these files will confuse git if it happens
to recurse into the qemu source folder during an operation on some parent
directory, for example git clean at a higher level. Avoid that problem
(mostly) by removing them immediately after the sources are unpacked.
Signed-off-by: Phil Blundell p...@pbcl.net
---
meta/recipes-devtools/qemu/qemu_1.6.1.bb | 8
1 file changed, 8 insertions(+)
diff --git a/meta/recipes-devtools/qemu/qemu_1.6.1.bb
b/meta/recipes-devtools/qemu/qemu_1.6.1.bb
index 03e28a0..b5cd61e 100644
--- a/meta/recipes-devtools/qemu/qemu_1.6.1.bb
+++ b/meta/recipes-devtools/qemu/qemu_1.6.1.bb
@@ -11,6 +11,14 @@ SRC_URI[sha256sum] =
fc736f44aa10478223c881310a7e40fc8386547e9cadf7d01ca4685951
COMPATIBLE_HOST_class-target_mips64 = null
+do_sanitize_sources() {
+# These .git files point to a nonexistent path ../.git/modules and will
confuse git
+# if it tries to recurse into those directories.
+rm -f ${S}/dtc/.git ${S}/pixman/.git
+}
+
+addtask sanitize_sources after do_unpack before do_patch
+
do_install_append() {
# Prevent QA warnings about installed ${localstatedir}/run
if [ -d ${D}${localstatedir}/run ]; then rmdir ${D}${localstatedir}/run; fi
--
1.8.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] ptest.bblass: Fix package QA issues when disabled
On Thu, 2014-01-09 at 03:54 +, Nathan Rossi wrote:
-Original Message-
From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
Sent: Wednesday, January 08, 2014 10:58 PM
To: Nathan Rossi
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH] ptest.bblass: Fix package QA issues when
disabled
On Wed, 2014-01-08 at 17:05 +1000, Nathan Rossi wrote:
When the ptest distro feature is disabled, a ptest directory is still
created in the install phase, This directory is not cleaned up or
consumed by any package and will throw a QA error, e.g.
ERROR: QA Issue: glib-2.0: Files/directories were installed but not
shipped
/usr/lib/glib-2.0/ptest
ERROR: QA run found fatal errors. Please consider fixing them.
ERROR: Function failed: do_package_qa
This is caused by the do_install_ptest_base[cleandirs] task flag which
is not setup to be conditional on ptest being enabled. This patch
changes the task flag to emit the cleandirs path only when the ptest
distro feature is enabled.
Signed-off-by: Nathan Rossi nathan.ro...@xilinx.com
---
meta/classes/ptest.bbclass |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/ptest.bbclass b/meta/classes/ptest.bbclass
index ec10f80..3450085 100644
--- a/meta/classes/ptest.bbclass
+++ b/meta/classes/ptest.bbclass
@@ -49,7 +49,7 @@ do_install_ptest_base() {
fi
}
-do_install_ptest_base[cleandirs] = ${D}${PTEST_PATH}
+do_install_ptest_base[cleandirs] = ${@['',
'${D}${PTEST_PATH}'][(d.getVar('PTEST_ENABLED', True) or '') == '1']}
addtask configure_ptest_base after do_configure before do_compile
addtask compile_ptest_base after do_compile before do_install
How about we use the new add/deltask api to conditionally add these
tasks only when ptest is enabled?
Just wanted to double check, by add/deltask you are referring to
calling the bb.build.*task() functions in an anonymous function
correct?
Yes.
The number of conditionals in there is getting silly...
When I respin the patch I will refactor the other conditionals such
that it removes all ptest_base tasks when disabled instead of the
conditional checks in each task.
Sounds good, this should be much neater!
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-commits] Chen Qi : initscripts: split the functions script into a separate package
On Mon, Jan 06, 2014 at 10:15:11PM +, g...@git.openembedded.org wrote:
Module: openembedded-core.git
Branch: master
Commit: 736dd8380f41d6ff1d3d0e4fe33cc01e2e873ef6
URL:
http://git.openembedded.org/?p=openembedded-core.gita=commit;h=736dd8380f41d6ff1d3d0e4fe33cc01e2e873ef6
Author: Chen Qi qi.c...@windriver.com
Date: Mon Jan 6 15:27:34 2014 +0800
initscripts: split the functions script into a separate package
Many SysV init scripts need the /etc/init.d/functions script. But
this script is part of the initscripts package. As a result, the
initscripts package should always be installed into the system to
avoid errors when starting daemons. However, it makes no sense to
install the initscripts package into a systemd based image, because
what the init scripts provide has already been provided by the systemd.
On the other hand, the functions script might be still needed in a
systemd based image because other init scripts such as distcc might need
it.
The above situation leads to a natural separation of the functions script
from the initscripts package. And this patch does so. It separates the
functions script into initscripts-functions packages.
FYI: In cases where alternative initscripts are used (and
VIRTUAL-RUNTIME_initscripts) respected, these alternatives also need to
rprovide initscripts-functions (or at least u-a for functions), otherwise
u-a fails in do_rootfs which is fatal for read-only:
| ERROR: The following packages could not be configured offline and
rootfs is read-only: initscripts-functions
Signed-off-by: Chen Qi qi.c...@windriver.com
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
meta/recipes-core/initscripts/initscripts_1.0.bb | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/initscripts/initscripts_1.0.bb
b/meta/recipes-core/initscripts/initscripts_1.0.bb
index 5951e0c..d1644a3 100644
--- a/meta/recipes-core/initscripts/initscripts_1.0.bb
+++ b/meta/recipes-core/initscripts/initscripts_1.0.bb
@@ -42,8 +42,12 @@ KERNEL_VERSION =
inherit update-alternatives
DEPENDS_append = update-rc.d-native
-ALTERNATIVE_PRIORITY = 90
-ALTERNATIVE_${PN} = functions
+PACKAGES =+ ${PN}-functions
+RDEPENDS_${PN} = ${PN}-functions
+FILES_${PN}-functions = ${sysconfdir}/init.d/functions*
+
+ALTERNATIVE_PRIORITY_${PN}-functions = 90
+ALTERNATIVE_${PN}-functions = functions
ALTERNATIVE_LINK_NAME[functions] = ${sysconfdir}/init.d/functions
HALTARGS ?= -d -f
___
Openembedded-commits mailing list
openembedded-comm...@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-commits
--
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
[OE-core] Failed to build opkg with curl support
I define curl in PACKAGECONFIG for opkg. After that I'm getting circular dependency errors during building opkg. Best regards, Yevhen ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC OE-core/meta/lib] BSP Specific Qemurunner
On Thu, 2014-01-09 at 00:01 +, Sipke Vriend wrote: On Wednesday, 8 January 2014 11:53 PM Paul Eggleton wrote: On Wednesday 08 January 2014 13:12:41 Richard Purdie wrote: On Tue, 2014-01-07 at 22:59 +, Sipke Vriend wrote: Hi Richard, -Original Message- On Wednesday, 8 January 2014 12:00 AM, Richard Purdie wrote: On Tue, 2014-01-07 at 03:09 +, Sipke Vriend wrote: Hi, This RFC is a proposal to allow BSP layers to setup qemu with their specific requirements for the testimage oe-core functionality. The suggested changes will be exercised by the bitbake -c testimage image command. Similarly to the oeqa test cases this proposal extends the meta/lib/oeqa python modules to allow inclusion of python utility scripts in the BSP layers. Any BSP layer wishing to supply their own qemu setup would need to create an appropriate meta-bsplayer/lib/oeqa/utils/machinestarter.py The effect is that the lib/oeqa/utils/qemurunner will either allow the bsp layer provided machinestarter to spawn qemu or if not provided, spawn qemu via runqemu as currently. An example bsp layer is available here: https://github.com/sipke/meta-xilinx/tree/sipke/qemurunner with all required additions in the meta-xilinx/lib directory. This RFC is triggered by and indirectly related to Bugzilla report runqemu shouldn't hard-code machine knowledge https://bugzilla.yoctoproject.org/show_bug.cgi?id=4827 Why would we do this rather than improve runqemu to be extendable from BSP layers? Proposing as an additional way to launch qemu for oeqa testimage functionality, Improving runqemu can and probably should still happen. To consider: * it keeps testimage functionality (for bsp layers specific things) in the lib directly (similar to test cases) and as python. * testing (via testimage) may have a different requirement to that of running runqemu on the command line, so an alternate way to launch qemu could be useful. * should this approach of extending the oeqa testimage functionality into bsp layers be accepted, this could allow also for bsp specific hardware setup for testimage functionality in bsp layers. Primary aim is a solution which allows the bsp layer to control the setup of qemu (and eventually hardware) for testimage functionality. This is a proposal towards that goal. I thought Stefan was already also working on something towards this goal. I'd like to ensure we don't end up with two things doing the same thing. Stefan? Agreed. One solution is desired. Happy to coordinate with and assist Stefan, either implementing part of a solution (proposed one or another) and/or testing whatever Stefan comes up with against our bsp layer. I'm sorry for replying so late, this has been a slow week. I'm a bit confused because last time I checked I wasn't working on something similar :) (layer-controlled qemu/bsp setup), but I'm happy to help. I've looked at the patches themselves, and they are okay, but I'm not sure a layer-specific qemu setup for testimage is what we should do in the long term. Now, I can see the problem you are trying to fix here and why you need this... I always assumed that a BSP layer is mostly about real hw and that runqemu will deal with any qemu machine. So, as Richard said, we should probably fix runqemu. Now, I really like the idea of a layer-controlled/extendable target setup (be it qemu or hardware) and I think we should allow a layer to extend lib/oeqa/targetcontrol.py and provide (or extend) its own TEST_TARGET (besides qemu and simpleremote). That will prove more useful for hw stuff and it will allow a layer to completely control deployment of a qemu target too (deploy, start, stop, running commands, etc). E.g: perhaps a layer doesn't like the use of the ext3 images for qemu and needs to use something else. Thoughts? Cheers, Stefan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Qt in OE-core
On Wed, Jan 8, 2014 at 10:32 PM, Martin Jansa martin.ja...@gmail.comwrote: On Wed, Jan 08, 2014 at 11:21:08PM +, Paul Eggleton wrote: In my opinion... Personally I would be in favour of removing GTK+ and the GNOME UI from the core and putting them in their own layer for all the same reasons I think Qt should be in its own layer: - a basic image doesn't need them - we can have different layers to track separate major releases (as with qt3, qt4, and qt5) The trouble is, if you have no toolkit at all, how do you test that X still works properly? The selection we have provides a single unit allowing us to test the entire stack reasonably well without having to add anything else. I think that's a valuable thing to have. By testing oe-core + layer with X. Everybody else is using oe-core + couple of other layers, why do we need to make oe-core testable with X _in single_ layer? I'm not saying that oe-core should be tested with 30 layers like my world build, but why cannot AB have special build which builds oe-core + meta-xorg + meta-gnome and runs some runtime QA tests on that and then some other build with oe-core + meta-python for piglit tests? Is it limitation of AB scripts for builds that they cannot fetch other layers so they need everything glued together with combo-layer? I full agree here; this would be more in line of what we communicate to our users and layers being a good and nice way to modularize the system... -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Qt in OE-core
Hello, On Thu, Jan 9, 2014 at 4:32 AM, Koen Kooi k...@dominion.thruhere.netwrote: Op 9 jan. 2014, om 01:32 heeft Martin Jansa martin.ja...@gmail.com het volgende geschreven: On Wed, Jan 08, 2014 at 11:21:08PM +, Paul Eggleton wrote: In my opinion... Personally I would be in favour of removing GTK+ and the GNOME UI from the core and putting them in their own layer for all the same reasons I think Qt should be in its own layer: - a basic image doesn't need them - we can have different layers to track separate major releases (as with qt3, qt4, and qt5) The trouble is, if you have no toolkit at all, how do you test that X still works properly? The selection we have provides a single unit allowing us to test the entire stack reasonably well without having to add anything else. I think that's a valuable thing to have. By testing oe-core + layer with X. Everybody else is using oe-core + couple of other layers, why do we need to make oe-core testable with X _in single_ layer? I have never seen a good explanation for that I'm not saying that oe-core should be tested with 30 layers like my world build, but why cannot AB have special build which builds oe-core + meta-xorg + meta-gnome and runs some runtime QA tests on that and then some other build with oe-core + meta-python for piglit tests? And e.g. meta-xorg could live inside the oe-core git repo if additional git repos are too scary. Everyone using OE-Core/Poky in real world end using many GIT repositories so I don't think it is a problem. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] mesa-demos: Fix application demo2
From: Yasir-Khan yasir_k...@mentor.com
Simple fix for demo2 application. Pass color array to glColorPointer.
Signed-off-by: Yasir-Khan yasir_k...@mentor.com
---
.../mesa/mesa-demos/fix-demo2-color.patch | 13 +
meta/recipes-graphics/mesa/mesa-demos_8.1.0.bb |3 ++-
2 files changed, 15 insertions(+), 1 deletion(-)
create mode 100644 meta/recipes-graphics/mesa/mesa-demos/fix-demo2-color.patch
diff --git a/meta/recipes-graphics/mesa/mesa-demos/fix-demo2-color.patch
b/meta/recipes-graphics/mesa/mesa-demos/fix-demo2-color.patch
new file mode 100644
index 000..34e9994
--- /dev/null
+++ b/meta/recipes-graphics/mesa/mesa-demos/fix-demo2-color.patch
@@ -0,0 +1,13 @@
+diff --git a/src/egl/opengl/demo2.c b/src/egl/opengl/demo2.c
+index 71a1a31..505b474 100644
+--- a/src/egl/opengl/demo2.c
b/src/egl/opengl/demo2.c
+@@ -35,7 +35,7 @@ static void _subset_Rectf(GLfloat x1, GLfloat y1, GLfloat
x2, GLfloat y2,
+}
+
+glVertexPointer(2, GL_FLOAT, 0, v);
+- glColorPointer(4, GL_FLOAT, 0, v);
++ glColorPointer(4, GL_FLOAT, 0, c);
+glEnableClientState(GL_VERTEX_ARRAY);
+glEnableClientState(GL_COLOR_ARRAY);
+
diff --git a/meta/recipes-graphics/mesa/mesa-demos_8.1.0.bb
b/meta/recipes-graphics/mesa/mesa-demos_8.1.0.bb
index 4bb92f4..225d466 100644
--- a/meta/recipes-graphics/mesa/mesa-demos_8.1.0.bb
+++ b/meta/recipes-graphics/mesa/mesa-demos_8.1.0.bb
@@ -14,7 +14,8 @@ DEPENDS = virtual/libgl glew
SRC_URI = ftp://ftp.freedesktop.org/pub/mesa/demos/${PV}/${BPN}-${PV}.tar.bz2
\
file://glut.patch \
file://egl-mesa-screen-surface-build-fix.patch \
-file://egl-mesa-screen-surface-query.patch
+file://egl-mesa-screen-surface-query.patch \
+ file://fix-demo2-color.patch
SRC_URI[md5sum] = 9df33ba69a26bbfbc7c8148602e59542
SRC_URI[sha256sum] =
9703fa0646b32a1e68d2abf5628f936f77bf97c69ffcaac90de380820a87a828
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] mesa-demos: Fix application demo2
The patch is missing signed-off and more importantly upstream-status tags.
Ross
On 9 January 2014 13:52, Yasir Khan yasir_k...@mentor.com wrote:
From: Yasir-Khan yasir_k...@mentor.com
Simple fix for demo2 application. Pass color array to glColorPointer.
Signed-off-by: Yasir-Khan yasir_k...@mentor.com
---
.../mesa/mesa-demos/fix-demo2-color.patch | 13 +
meta/recipes-graphics/mesa/mesa-demos_8.1.0.bb |3 ++-
2 files changed, 15 insertions(+), 1 deletion(-)
create mode 100644
meta/recipes-graphics/mesa/mesa-demos/fix-demo2-color.patch
diff --git a/meta/recipes-graphics/mesa/mesa-demos/fix-demo2-color.patch
b/meta/recipes-graphics/mesa/mesa-demos/fix-demo2-color.patch
new file mode 100644
index 000..34e9994
--- /dev/null
+++ b/meta/recipes-graphics/mesa/mesa-demos/fix-demo2-color.patch
@@ -0,0 +1,13 @@
+diff --git a/src/egl/opengl/demo2.c b/src/egl/opengl/demo2.c
+index 71a1a31..505b474 100644
+--- a/src/egl/opengl/demo2.c
b/src/egl/opengl/demo2.c
+@@ -35,7 +35,7 @@ static void _subset_Rectf(GLfloat x1, GLfloat y1, GLfloat
x2, GLfloat y2,
+}
+
+glVertexPointer(2, GL_FLOAT, 0, v);
+- glColorPointer(4, GL_FLOAT, 0, v);
++ glColorPointer(4, GL_FLOAT, 0, c);
+glEnableClientState(GL_VERTEX_ARRAY);
+glEnableClientState(GL_COLOR_ARRAY);
+
diff --git a/meta/recipes-graphics/mesa/mesa-demos_8.1.0.bb
b/meta/recipes-graphics/mesa/mesa-demos_8.1.0.bb
index 4bb92f4..225d466 100644
--- a/meta/recipes-graphics/mesa/mesa-demos_8.1.0.bb
+++ b/meta/recipes-graphics/mesa/mesa-demos_8.1.0.bb
@@ -14,7 +14,8 @@ DEPENDS = virtual/libgl glew
SRC_URI =
ftp://ftp.freedesktop.org/pub/mesa/demos/${PV}/${BPN}-${PV}.tar.bz2 \
file://glut.patch \
file://egl-mesa-screen-surface-build-fix.patch \
-file://egl-mesa-screen-surface-query.patch
+file://egl-mesa-screen-surface-query.patch \
+ file://fix-demo2-color.patch
SRC_URI[md5sum] = 9df33ba69a26bbfbc7c8148602e59542
SRC_URI[sha256sum] =
9703fa0646b32a1e68d2abf5628f936f77bf97c69ffcaac90de380820a87a828
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libsoup: Remove libproxy from DEPENDS
On Thu, Jan 9, 2014 at 9:16 AM, Phil Blundell p...@pbcl.net wrote: Although libsoup did use to support direct usage of libproxy, it hasn't done so for some time. Worse, if libsoup depends on libproxy then it is impossible to build libproxy against webkit since webkit itself depends on libsoup in some configurations. Fix this by removing the extraneous entry from DEPENDS. Signed-off-by: Phil Blundell p...@pbcl.net Does it need a --disable-libproxy or so? -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Qt in OE-core
On 01/08/14 05:28, Richard Purdie wrote: On Tue, 2014-01-07 at 20:23 +0100, Martin Jansa wrote: With PACKAGECONFIGs which can list optional dependencies which aren't included in the the layer itself it's now easier to have recipe with optional qt5 support in oe-core, but qt5 itself in separate meta-qt5. What dependencies on other layers does meta-qt5 have? If the policy is all qt5 things into meta-qt5, the risk is a fairly large set of layer dependencies for meta-qt5. There is some perception I don't like external layers which isn't true. What I do dislike is dependency creep. If the meta-qt5 isn't usable without pulling in chunks of meta-oe for example, I'd think that rather sad and it might as well move to meta-oe at that point. Theoretically, which dependencies a given usage of qt5 has depends on which PACKAGECONFIGs are used. In other words, one OE image or one OE distribution might want to use OpenGL, while another might decide against it. http://qt-project.org/doc/qt-5/linux-requirements.html If we did move to breaking more things out into more layers, would the resulting increase in the number of layers be easier to manage if we didn't have to depend on the user correctly setting up their conf/bblayers.conf? I admit I'm not familiar with a large number of applications of OE/Yocto, but of the 3 of which I am aware (gumstix, imx53qsb, and internally at Linaro) all have moved to using repo (an external tool) and custom initialization scripts to better handle setting up a user's layers and configuration.[1][2] What if a distro configuration file, an image.bb, a MACHINE specification, or a layer could specify its dependencies itself? Would this lead to DLL hell[3] or would this be the missing ingredient which keeps some projects from having to resort to using external tools? If a distro has the power to decide which UI library to use on which backend, should it then be up to the distro configuration to specify which layer(s) to add, and maybe even which branch/commit to use, and maybe also specify these layers' priority and ordering? Maybe in a different scenario this decision wants to be handled by the image configuration instead. In either case, we wouldn't have to rely on external tools (repo) and manual intervention (hoping the user updates conf/bblayers.conf correctly) to get our layers right before we can build. Same goes for meta-qt5. If meta-qt5 has dependencies on specific other layers, maybe those dependencies could be part of the meta-qt5 definition such that these other layers are pulled in automatically? Or maybe a specific choice of PACKAGECONFIG would trigger the required dependency? Would it be possible to add a step in the build process that uses bitbake's fetcher to get or sync a project's layers before starting the process of fetching a recipe's sources based on information collected from hints in the various configuration files? [1] https://github.com/gumstix/Gumstix-YoctoProject-Repo/blob/master/README.md [2] https://github.com/Freescale/fsl-community-bsp-platform [3] http://en.wikipedia.org/wiki/DLL_Hell ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-commits] Robert Yang : autogen-native: upgrade to 5.18.2
On Mon, Jan 06, 2014 at 11:29:36AM +, g...@git.openembedded.org wrote: Module: openembedded-core.git Branch: master Commit: 6bcd2dafa379badab11bff9d7b607f7f5d72fc94 URL: http://git.openembedded.org/?p=openembedded-core.gita=commit;h=6bcd2dafa379badab11bff9d7b607f7f5d72fc94 Author: Robert Yang liezhi.y...@windriver.com Date: Fri Dec 27 01:05:14 2013 +0800 autogen-native: upgrade to 5.18.2 * Upgrade from 5.17.4 to 5.18.2 * Rename files - autogen Signed-off-by: Robert Yang liezhi.y...@windriver.com Signed-off-by: Saul Wold s...@linux.intel.com Fails in world builds: | gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I.. -I../autoopts -isystem/home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/include -pthread -I/home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/include/guile/2.0 -I/home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/include -isystem/home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/include -O2 -pipe -c -o autogen-ag.o `test -f 'ag.c' || echo './'`ag.c | In file included from /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/include/guile/2.0/libguile/array-handle.h:28:0, | from /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/include/guile/2.0/libguile.h:34, | from autogen.h:60, | from ag.c:7: | /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/include/guile/2.0/libguile/error.h:40:24: error: expected ')' before '__attribute__' | /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/include/guile/2.0/libguile/error.h:40:24: error: expected ',' or ';' before ')' token | /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/include/guile/2.0/libguile/error.h:42:27: error: expected ')' before '__attribute__' | /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/include/guile/2.0/libguile/error.h:42:27: error: expected ',' or ';' before ')' token | /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/include/guile/2.0/libguile/error.h:44:46: error: expected ')' before '__attribute__' | /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/include/guile/2.0/libguile/error.h:44:46: error: expected ',' or ';' before ')' token | /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/include/guile/2.0/libguile/error.h:46:30: error: expected ')' before '__attribute__' | /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/include/guile/2.0/libguile/error.h:46:30: error: expected ',' or ';' before ')' token | /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/include/guile/2.0/libguile/error.h:47:50: error: expected ')' before '__attribute__' | /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/include/guile/2.0/libguile/error.h:47:50: error: expected ',' or ';' before ')' token | /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/include/guile/2.0/libguile/error.h:49:6: error: expected ')' before '__attribute__' | /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/include/guile/2.0/libguile/error.h:49:6: error: expected ',' or ';' before ')' token | /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/include/guile/2.0/libguile/error.h:51:6: error: expected ')' before '__attribute__' | /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/include/guile/2.0/libguile/error.h:51:6: error: expected ',' or ';' before ')' token | /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/include/guile/2.0/libguile/error.h:52:44: error: expected ')' before '__attribute__' | /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/include/guile/2.0/libguile/error.h:52:44: error: expected ',' or ';' before ')' token | /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/include/guile/2.0/libguile/error.h:53:57: error: expected ')' before '__attribute__' | /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/include/guile/2.0/libguile/error.h:53:57: error: expected ',' or ';' before ')' token | /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/include/guile/2.0/libguile/error.h:55:21: error: expected ')' before '__attribute__' | /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/include/guile/2.0/libguile/error.h:55:21: error: expected ',' or ';' before ')' token |
[OE-core] State of bitbake world, Failed tasks 2014-01-09
http://www.openembedded.org/wiki/Bitbake_World_Status
== Failed tasks 2014-01-09 ==
=== common (6) ===
* meta-openembedded/meta-efl/recipes-efl/webkit/webkit-efl_svn.bb,
do_configure
* meta-openembedded/meta-multimedia/recipes-mediacentre/xbmc/xbmc_git.bb,
do_fetch
* meta-openembedded/meta-oe/recipes-devtools/tcltk/tk_8.6.0.bb, do_compile
* meta-openembedded/meta-oe/recipes-extended/gnuplot/gnuplot_4.4.4.bb,
do_compile
* meta-openembedded/meta-oe/recipes-navigation/monav/monav_0.3.bb,
do_compile
* meta-qt5/recipes-qt/qt5/qtwayland_git.bb, do_compile
=== common-x86 (5) ===
* meta-browser/recipes-mozilla/firefox/firefox_10.0.11esr.bb, do_compile
* meta-openembedded/meta-multimedia/recipes-multimedia/vlc/vlc_1.1.11.bb,
do_compile
* meta-openembedded/meta-oe/recipes-support/emacs/emacs_23.4.bb, do_compile
* meta-openembedded/meta-oe/recipes-support/ode/ode_0.9.bb, do_configure
* openembedded-core/meta/recipes-devtools/autogen/autogen-native_5.18.2.bb,
do_compile
=== qemuarm (5) ===
* meta-openembedded/meta-gnome/recipes-gnome/devilspie/devilspie2_0.24.bb,
do_compile
*
meta-openembedded/meta-networking/recipes-support/traceroute/traceroute_2.0.18.bb,
do_compile
*
meta-openembedded/meta-oe/recipes-support/bash-completion/bash-completion_2.0.bb,
do_install
* openembedded-core/meta/recipes-devtools/make/make_4.0.bb, do_compile
*
openembedded-core/meta/recipes-multimedia/gstreamer/gst-plugins-bad_0.10.23.bb,
do_compile
=== qemux86 (1) ===
*
meta-openembedded/meta-oe/recipes-graphics/xorg-driver/xf86-video-geode_2.11.14.bb,
do_compile
=== qemux86_64 (4) ===
*
meta-openembedded/meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb,
do_fetch
*
meta-openembedded/meta-oe/recipes-connectivity/libimobiledevice/libimobiledevice_1.1.4.bb,
do_configure
* meta-openembedded/meta-oe/recipes-core/libxml/libxml++_2.35.3.bb,
do_compile
*
meta-openembedded/meta-oe/recipes-devtools/python/python-m2crypto_0.21.1.bb,
do_compile
=== Number of failed tasks ===
{| class=wikitable
|-
||qemuarm ||11
||http://logs.nslu2-linux.org/buildlogs/oe/oe-shr-core-branches//log.world.20140107_145350.log/
|-
||qemux86 ||12
||http://logs.nslu2-linux.org/buildlogs/oe/oe-shr-core-branches//log.world.20140108_115626.log/
|-
||qemux86_64||15
||http://logs.nslu2-linux.org/buildlogs/oe/oe-shr-core-branches//log.world.20140109_011732.log/
|}
--
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-commits] Chen Qi : Add missing RDEPENDS of initscripts-functions
On Mon, Jan 06, 2014 at 10:15:11PM +, g...@git.openembedded.org wrote:
Module: openembedded-core.git
Branch: master
Commit: 6690c12cb1977f6bf93f3eb6d471dbd7db81bf28
URL:
http://git.openembedded.org/?p=openembedded-core.gita=commit;h=6690c12cb1977f6bf93f3eb6d471dbd7db81bf28
Author: Chen Qi qi.c...@windriver.com
Date: Mon Jan 6 15:27:35 2014 +0800
Add missing RDEPENDS of initscripts-functions
Now that the initscripts-functions has been packaged separately,
packages which may use the functions script should have a runtime
dependency on it.
Do really all these recipes need initscripts-functions e.g. when
building image with systemd?
I have initscripts in blacklist for long time (since switching to
systemd) and now it tries to bring initscripts-functions from it.
Signed-off-by: Chen Qi qi.c...@windriver.com
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
meta/recipes-bsp/alsa-state/alsa-state.bb | 2 +-
meta/recipes-bsp/apmd/apmd_3.2.2-14.bb| 1 +
meta/recipes-connectivity/irda-utils/irda-utils_0.9.18.bb | 2 ++
meta/recipes-connectivity/nfs-utils/nfs-utils_1.2.9.bb| 4 ++--
meta/recipes-connectivity/openssh/openssh_6.4p1.bb| 2 +-
meta/recipes-connectivity/ppp/ppp_2.4.5.bb| 1 +
meta/recipes-core/dbus/dbus.inc | 2 +-
meta/recipes-core/systemd/systemd_208.bb | 2 +-
meta/recipes-core/sysvinit/sysvinit_2.88dsf.bb| 2 +-
meta/recipes-devtools/distcc/distcc_3.1.bb| 1 +
meta/recipes-devtools/tcf-agent/tcf-agent_git.bb | 2 +-
meta/recipes-extended/at/at_3.1.14.bb | 3 +--
meta/recipes-extended/cronie/cronie_1.4.11.bb | 2 ++
meta/recipes-extended/rpcbind/rpcbind_0.2.1.bb| 2 ++
meta/recipes-extended/sysklogd/sysklogd.inc | 2 ++
meta/recipes-extended/xinetd/xinetd_2.3.15.bb | 1 +
meta/recipes-kernel/oprofile/oprofileui-server_git.bb | 2 +-
17 files changed, 22 insertions(+), 11 deletions(-)
diff --git a/meta/recipes-bsp/alsa-state/alsa-state.bb
b/meta/recipes-bsp/alsa-state/alsa-state.bb
index 552fcfc..4be74aa 100644
--- a/meta/recipes-bsp/alsa-state/alsa-state.bb
+++ b/meta/recipes-bsp/alsa-state/alsa-state.bb
@@ -37,7 +37,7 @@ PACKAGES += alsa-states
RRECOMMENDS_alsa-state = alsa-states
-RDEPENDS_${PN} = alsa-utils-alsactl
+RDEPENDS_${PN} = alsa-utils-alsactl initscripts-functions
FILES_${PN} = ${sysconfdir}/init.d ${sysconfdir}/asound.conf
CONFFILES_${PN} = ${sysconfdir}/asound.conf
diff --git a/meta/recipes-bsp/apmd/apmd_3.2.2-14.bb
b/meta/recipes-bsp/apmd/apmd_3.2.2-14.bb
index 8c4b75e..d5ddc17 100644
--- a/meta/recipes-bsp/apmd/apmd_3.2.2-14.bb
+++ b/meta/recipes-bsp/apmd/apmd_3.2.2-14.bb
@@ -8,6 +8,7 @@ LICENSE = GPLv2+
LIC_FILES_CHKSUM = file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
file://apm.h;beginline=6;endline=18;md5=7d4acc1250910a89f84ce3cc6557c4c2
DEPENDS = libtool-cross
+RDEPENDS_${PN} = initscripts-functions
PR = r2
SRC_URI = ${DEBIAN_MIRROR}/main/a/apmd/apmd_3.2.2.orig.tar.gz;name=tarball \
diff --git a/meta/recipes-connectivity/irda-utils/irda-utils_0.9.18.bb
b/meta/recipes-connectivity/irda-utils/irda-utils_0.9.18.bb
index 7f216ac..59c9b6a 100644
--- a/meta/recipes-connectivity/irda-utils/irda-utils_0.9.18.bb
+++ b/meta/recipes-connectivity/irda-utils/irda-utils_0.9.18.bb
@@ -24,6 +24,8 @@ inherit autotools update-rc.d
INITSCRIPT_NAME = irattach
INITSCRIPT_PARAMS = defaults 20
+RDEPENDS_${PN} += initscripts-functions
+
do_compile () {
oe_runmake -e -C irattach
oe_runmake -e -C irdaping
diff --git a/meta/recipes-connectivity/nfs-utils/nfs-utils_1.2.9.bb
b/meta/recipes-connectivity/nfs-utils/nfs-utils_1.2.9.bb
index 45eacd9..fd44ea1 100644
--- a/meta/recipes-connectivity/nfs-utils/nfs-utils_1.2.9.bb
+++ b/meta/recipes-connectivity/nfs-utils/nfs-utils_1.2.9.bb
@@ -9,8 +9,8 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=95f3a93a5c3c7888de623b46ea085a84
# util-linux for libblkid
DEPENDS = libcap libnfsidmap libevent util-linux sqlite3
-RDEPENDS_${PN}-client = rpcbind bash
-RDEPENDS_${PN} = ${PN}-client bash
+RDEPENDS_${PN}-client = rpcbind bash initscripts-functions
+RDEPENDS_${PN} = ${PN}-client bash initscripts-functions
RRECOMMENDS_${PN} = kernel-module-nfsd
inherit useradd
diff --git a/meta/recipes-connectivity/openssh/openssh_6.4p1.bb
b/meta/recipes-connectivity/openssh/openssh_6.4p1.bb
index 4f8d70a..c61d16f 100644
--- a/meta/recipes-connectivity/openssh/openssh_6.4p1.bb
+++ b/meta/recipes-connectivity/openssh/openssh_6.4p1.bb
@@ -122,7 +122,7 @@ FILES_${PN}-misc = ${bindir}/ssh* ${libexecdir}/ssh*
FILES_${PN}-keygen = ${bindir}/ssh-keygen
RDEPENDS_${PN} += ${PN}-scp ${PN}-ssh ${PN}-sshd ${PN}-keygen
-RDEPENDS_${PN}-sshd += ${PN}-keygen
Re: [OE-core] bug scrub - RFC
On 01/09/14 05:56, Jack Mitchell wrote: On 08/01/14 23:20, Trevor Woerner wrote: questions: 1) Currently it has been suggested this should be a 2-day event, should these two days be during the week or over a weekend? In either case, which 2 days? If it's two days long then why don't you do the best of both worlds and have a Friday/Saturday or Sunday/Monday combination? I was thinking of doing it either fully during the week, or fully on a weekend since my feeling is that most people either work with OE/Yocto during the weekdays or on the weekend. There's nothing to say we couldn't run this bug scrub during the week, then run a second bug scrub 2 months from now on a weekend (or visa versa). 2) Since this is an OE event, should it focus only on OE bugs[2], or should it be generalized for any bug? I don't think we should be limiting people to what they can work on while participating. Since this is an OE TSC event I didn't want any hard feelings ;-) I also thought that maybe it would be easier to get people interested if this bug scrub was targeted at a specific project. I thought there's a chance it might help get people interested if we said let's have a bug event where we target these 30 bugs instead of saying there are 1000's of bugs in the bugzilla, pick one and try to do something about it. 4) It would be cool to be able to provide incentives to help people get interested and contributing to knocking some bugs around. So if anyone (*cough* Intel) has any neat hardware (*cough* Galileo, Edison) they could offer as an incentive (or, conversely, if there's a board you'd like to see Yocto target) please see about making that happen. A unified effort towards a new trendy board would be a fun goal, but I worry that hardware teething issues would then eat up run of the mill bug fixing time, handouts for participation however, (bug fixed/reviewed by/tested by) would be a great idea. Sorry, yes, this is what I meant. ___ 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, Failed tasks 2014-01-09
On Thu, Jan 9, 2014 at 3:46 PM, Martin Jansa martin.ja...@gmail.com wrote: http://www.openembedded.org/wiki/Bitbake_World_Status == Failed tasks 2014-01-09 == === common (6) === * meta-openembedded/meta-efl/recipes-efl/webkit/webkit-efl_svn.bb, do_configure * meta-openembedded/meta-multimedia/recipes-mediacentre/xbmc/xbmc_git.bb, do_fetch * meta-openembedded/meta-oe/recipes-devtools/tcltk/tk_8.6.0.bb, do_compile * meta-openembedded/meta-oe/recipes-extended/gnuplot/gnuplot_4.4.4.bb, do_compile * meta-openembedded/meta-oe/recipes-navigation/monav/monav_0.3.bb, do_compile * meta-qt5/recipes-qt/qt5/qtwayland_git.bb, do_compile I have problems with qtwayland too and think that I am close to understand what's going on (on 5.2 branch). Where do I find logs for this error? Andreas ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Qt in OE-core
On Thu, 2014-01-09 at 01:32 +0100, Martin Jansa wrote: I'm not saying that oe-core should be tested with 30 layers like my world build, but why cannot AB have special build which builds oe-core + meta-xorg + meta-gnome and runs some runtime QA tests on that and then some other build with oe-core + meta-python for piglit tests? There's probably no reason that it can't be done. There are possibly a few reasons why it might not be a good idea though: - someone would need to keep track of what version of each layer the AB needs to be using and update its configuration accordingly; - there is a risk that you might end up spending all your time chasing spurious oe-core QA failures caused by problems with those external layers rather than finding genuine bugs in oe-core itself; - if either of those layers start depending on something else then you would need to add those dependencies as well, and so on potentially ad infinitum; - if something goes wrong in (say) meta-gnome that starts causing oe-core testsuite failures then you will be reliant on the meta-gnome maintainers to fix the problem in a reasonable time. If you're going to make testing be a first-class part of the oe-core development cycle then I think you can mount a fairly convincing argument that the core ought to be testable using only things that are either inside oe-core or at least under the control of the same maintainers. p. ___ 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, Failed tasks 2014-01-09
On Thu, Jan 09, 2014 at 04:12:52PM +0100, Andreas Müller wrote: On Thu, Jan 9, 2014 at 3:46 PM, Martin Jansa martin.ja...@gmail.com wrote: http://www.openembedded.org/wiki/Bitbake_World_Status == Failed tasks 2014-01-09 == === common (6) === * meta-openembedded/meta-efl/recipes-efl/webkit/webkit-efl_svn.bb, do_configure * meta-openembedded/meta-multimedia/recipes-mediacentre/xbmc/xbmc_git.bb, do_fetch * meta-openembedded/meta-oe/recipes-devtools/tcltk/tk_8.6.0.bb, do_compile * meta-openembedded/meta-oe/recipes-extended/gnuplot/gnuplot_4.4.4.bb, do_compile * meta-openembedded/meta-oe/recipes-navigation/monav/monav_0.3.bb, do_compile * meta-qt5/recipes-qt/qt5/qtwayland_git.bb, do_compile I have problems with qtwayland too and think that I am close to understand what's going on (on 5.2 branch). Where do I find logs for this error? Links for each machine are on the bottom of the e-mail: http://logs.nslu2-linux.org/buildlogs/oe/oe-shr-core-branches/... qtwayland builds for me fine with oe-core only and also in qt5-5.2.0 + webos-ports, so I haven't looked much into it yet. -- 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] bug scrub - RFC
On Thu, Jan 9, 2014 at 1:07 PM, Trevor Woerner trevor.woer...@linaro.orgwrote: On 01/09/14 05:56, Jack Mitchell wrote: On 08/01/14 23:20, Trevor Woerner wrote: questions: 1) Currently it has been suggested this should be a 2-day event, should these two days be during the week or over a weekend? In either case, which 2 days? If it's two days long then why don't you do the best of both worlds and have a Friday/Saturday or Sunday/Monday combination? I was thinking of doing it either fully during the week, or fully on a weekend since my feeling is that most people either work with OE/Yocto during the weekdays or on the weekend. There's nothing to say we couldn't run this bug scrub during the week, then run a second bug scrub 2 months from now on a weekend (or visa versa). Maybe mix it, Friday, Saturday, Sunday, Monday. So we give in a single 'event' opportunity to both. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] bug scrub - RFC
On 01/09/14 10:34, Otavio Salvador wrote: On Thu, Jan 9, 2014 at 1:07 PM, Trevor Woerner trevor.woer...@linaro.org mailto:trevor.woer...@linaro.org wrote: On 01/09/14 05:56, Jack Mitchell wrote: On 08/01/14 23:20, Trevor Woerner wrote: questions: 1) Currently it has been suggested this should be a 2-day event, should these two days be during the week or over a weekend? In either case, which 2 days? If it's two days long then why don't you do the best of both worlds and have a Friday/Saturday or Sunday/Monday combination? I was thinking of doing it either fully during the week, or fully on a weekend since my feeling is that most people either work with OE/Yocto during the weekdays or on the weekend. There's nothing to say we couldn't run this bug scrub during the week, then run a second bug scrub 2 months from now on a weekend (or visa versa). Maybe mix it, Friday, Saturday, Sunday, Monday. So we give in a single 'event' opportunity to both. Okay, I can agree to that. How about targeting next weekend (Jan 17-18 2014). Would that be too soon? ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] oeqa/runtime/systemd: wait for services to start/fail
When checking that no services have failed to start, actually wait for services
to finish starting by waiting for there not be no units in the activating
state.
Signed-off-by: Ross Burton ross.bur...@intel.com
---
meta/lib/oeqa/runtime/systemd.py | 28
1 file changed, 28 insertions(+)
diff --git a/meta/lib/oeqa/runtime/systemd.py b/meta/lib/oeqa/runtime/systemd.py
index eed29d3..6414dd6 100644
--- a/meta/lib/oeqa/runtime/systemd.py
+++ b/meta/lib/oeqa/runtime/systemd.py
@@ -32,8 +32,36 @@ class SystemdBasicTests(SystemdTest):
def test_systemd_list(self):
self.systemctl('list-unit-files')
+def settle(self):
+
+Block until systemd has finished activating any units being activated,
+or until two minutes has elapsed.
+
+Returns a tuple, either (True, None) if all units have finished
+acitvating, or (False, message string) if there are still units
+activating (generally, failing units that restart).
+
+import time
+settled = False
+endtime = time.time() + (60 * 2)
+while time.time() endtime:
+status = self.target.run('systemctl --state=activating | grep -q
0 loaded units listed')
+if status == 0:
+settled = True
+break
+time.sleep(10)
+
+if settled:
+return (True, None)
+else:
+status, output = self.target.run('systemctl --state=activating')
+return (settled, output)
+
@skipUnlessPassed('test_systemd_basic')
def test_systemd_failed(self):
+settled, output = self.settle()
+self.assertTrue(settled, msg=Timed out waiting for systemd to
settle:\n + output)
+
output = self.systemctl('list-units', '--failed')
match = re.search(0 loaded units listed, output)
if not match:
--
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] lib/oe/patch.py: Prefer git am over git apply when applying git patches
On Tue, Jan 7, 2014 at 11:46 AM, Otavio Salvador ota...@ossystems.com.br wrote: On Mon, Jan 6, 2014 at 8:10 PM, Saul Wold s...@linux.intel.com wrote: On 12/31/2013 06:18 AM, Laszlo Papp wrote: Ping? Alternatively, the system could also have an option for further fine-tuning what to do with git patches On Tue, Dec 24, 2013 at 12:44 PM, Laszlo Papp lp...@kde.org wrote: It is better to use git am when possible to preserve the commit messages and the mail format in general for patches when those are present. A typical use case is when developers would like to keep the changes on top of the latest upstream, and they may occasionally need to rebase. This is not possible with git diff and diff generated patches. Since this is not always the case, the fallback would be the git apply operation which is currently available. Looking at this, is it possible to detect a git patch and only then use git am? Since most of the patches carried in oe-core and other layers the 'git am' will typically fail and increase the build time since it will have to re-run the git apply, we don't want to had more forking and work in the main hot path. I am not the expert in this, neither is RP, so maybe Chris can comment further. I am not sure it'd buy us a lot trying to detect it; in fact using git am patches easy rework, rebase and upstreaming of those. +1 To detect it, we'd need to parse the file somehow and I am unsure it would be faster than just try to apply it. Agree; it may even be slower. I think it could be separated out later into a custom option if any performance issue comes up. IMO, it is a reasonable assumption if the patchtool set is git, then it is a git patch, not raw diff... ___ 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, Failed tasks 2014-01-09
On Thu, Jan 9, 2014 at 4:23 PM, Martin Jansa martin.ja...@gmail.com wrote: On Thu, Jan 09, 2014 at 04:12:52PM +0100, Andreas Müller wrote: On Thu, Jan 9, 2014 at 3:46 PM, Martin Jansa martin.ja...@gmail.com wrote: http://www.openembedded.org/wiki/Bitbake_World_Status == Failed tasks 2014-01-09 == === common (6) === * meta-openembedded/meta-efl/recipes-efl/webkit/webkit-efl_svn.bb, do_configure * meta-openembedded/meta-multimedia/recipes-mediacentre/xbmc/xbmc_git.bb, do_fetch * meta-openembedded/meta-oe/recipes-devtools/tcltk/tk_8.6.0.bb, do_compile * meta-openembedded/meta-oe/recipes-extended/gnuplot/gnuplot_4.4.4.bb, do_compile * meta-openembedded/meta-oe/recipes-navigation/monav/monav_0.3.bb, do_compile * meta-qt5/recipes-qt/qt5/qtwayland_git.bb, do_compile I have problems with qtwayland too and think that I am close to understand what's going on (on 5.2 branch). Where do I find logs for this error? Links for each machine are on the bottom of the e-mail: http://logs.nslu2-linux.org/buildlogs/oe/oe-shr-core-branches/... qtwayland builds for me fine with oe-core only and also in qt5-5.2.0 + webos-ports, so I haven't looked much into it yet. OK - I can't find that in the logs - but anyway: I am working also on 5.2.0 and my error for qtwayland showed up as tons of multiple defined GL data types as 'error: 'GLdouble' has a previous declaration as 'typedef GLfloat GLdouble'' Reason was that I had GL-headers in my sysroot but qtwayland was configured without wayland-egl / egl (it took me long to find out that that wayland-egl is supplied by mesa..). So qtwayland tried to build glx-compositor which does not work with GL/GLES headers in sysroot. After building egl and wayland-egl, qtwayland configured fine and the errors disappeared. Andreas ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] lib/oe/patch.py: Prefer git am over git apply when applying git patches
On Tue, Jan 7, 2014 at 12:16 PM, Koen Kooi k...@dominion.thruhere.net wrote: Op 6 jan. 2014, om 23:10 heeft Saul Wold s...@linux.intel.com het volgende geschreven: On 12/31/2013 06:18 AM, Laszlo Papp wrote: Ping? Alternatively, the system could also have an option for further fine-tuning what to do with git patches On Tue, Dec 24, 2013 at 12:44 PM, Laszlo Papp lp...@kde.org wrote: It is better to use git am when possible to preserve the commit messages and the mail format in general for patches when those are present. A typical use case is when developers would like to keep the changes on top of the latest upstream, and they may occasionally need to rebase. This is not possible with git diff and diff generated patches. Since this is not always the case, the fallback would be the git apply operation which is currently available. Looking at this, is it possible to detect a git patch and only then use git am? Since most of the patches carried in oe-core and other layers the 'git am' will typically fail All the patches I add are git am'able since I use a patch similar to this :) Cool. A big timesaver is to check for a .git/ in $WORKDIR otherwise git am will try to use a top level git tree (e.g. combo repo) and that's not what we want. Hmm, yeah, I agree. However, I do not have time currently for this, nor is this high-priority for me since it just works for me, and I am happy with that. Would it be possible to optimize it later? Failing that, what is the best practice to keep my changes separate from Yocto? I am referring to changes that are not upstreamed for whatever reason, like the maintainer saying that here it could be a performance regression (although non-measured at this point). Cheers ... ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/5] python-numpy: add (from meta-oe)
python-numpy is needed for Piglit. This recipe is taken directly from meta-oe. Signed-off-by: Ross Burton ross.bur...@intel.com --- .../python/python-numpy/aarch64/_numpyconfig.h | 30 + .../python/python-numpy/aarch64/config.h | 139 .../python/python-numpy/arm/config.h | 21 +++ .../python/python-numpy/arm/numpyconfig.h | 17 +++ .../python/python-numpy/armeb/config.h | 21 +++ .../python/python-numpy/armeb/numpyconfig.h| 17 +++ .../python/python-numpy/i586/config.h | 108 +++ .../python/python-numpy/i586/numpyconfig.h | 24 .../python/python-numpy/mipsel/config.h| 21 +++ .../python/python-numpy/mipsel/numpyconfig.h | 17 +++ .../python/python-numpy/trycompile.diff| 33 + .../python/python-numpy/unbreak-assumptions.diff | 16 +++ .../python/python-numpy/x86-64/_numpyconfig.h | 30 + .../python/python-numpy/x86-64/config.h| 139 meta/recipes-devtools/python/python-numpy_1.7.0.bb | 78 +++ 15 files changed, 711 insertions(+) create mode 100644 meta/recipes-devtools/python/python-numpy/aarch64/_numpyconfig.h create mode 100644 meta/recipes-devtools/python/python-numpy/aarch64/config.h create mode 100644 meta/recipes-devtools/python/python-numpy/arm/config.h create mode 100644 meta/recipes-devtools/python/python-numpy/arm/numpyconfig.h create mode 100644 meta/recipes-devtools/python/python-numpy/armeb/config.h create mode 100644 meta/recipes-devtools/python/python-numpy/armeb/numpyconfig.h create mode 100644 meta/recipes-devtools/python/python-numpy/i586/config.h create mode 100644 meta/recipes-devtools/python/python-numpy/i586/numpyconfig.h create mode 100644 meta/recipes-devtools/python/python-numpy/mipsel/config.h create mode 100644 meta/recipes-devtools/python/python-numpy/mipsel/numpyconfig.h create mode 100644 meta/recipes-devtools/python/python-numpy/trycompile.diff create mode 100644 meta/recipes-devtools/python/python-numpy/unbreak-assumptions.diff create mode 100644 meta/recipes-devtools/python/python-numpy/x86-64/_numpyconfig.h create mode 100644 meta/recipes-devtools/python/python-numpy/x86-64/config.h create mode 100644 meta/recipes-devtools/python/python-numpy_1.7.0.bb diff --git a/meta/recipes-devtools/python/python-numpy/aarch64/_numpyconfig.h b/meta/recipes-devtools/python/python-numpy/aarch64/_numpyconfig.h new file mode 100644 index 000..be57ac2 --- /dev/null +++ b/meta/recipes-devtools/python/python-numpy/aarch64/_numpyconfig.h @@ -0,0 +1,30 @@ +#define NPY_HAVE_ENDIAN_H 1 +#define NPY_SIZEOF_SHORT SIZEOF_SHORT +#define NPY_SIZEOF_INT SIZEOF_INT +#define NPY_SIZEOF_LONG SIZEOF_LONG +#define NPY_SIZEOF_FLOAT 4 +#define NPY_SIZEOF_COMPLEX_FLOAT 8 +#define NPY_SIZEOF_DOUBLE 8 +#define NPY_SIZEOF_COMPLEX_DOUBLE 16 +#define NPY_SIZEOF_LONGDOUBLE 16 +#define NPY_SIZEOF_COMPLEX_LONGDOUBLE 32 +#define NPY_SIZEOF_PY_INTPTR_T 8 +#define NPY_SIZEOF_PY_LONG_LONG 8 +#define NPY_SIZEOF_LONGLONG 8 +#define NPY_NO_SMP 0 +#define NPY_HAVE_DECL_ISNAN +#define NPY_HAVE_DECL_ISINF +#define NPY_HAVE_DECL_ISFINITE +#define NPY_HAVE_DECL_SIGNBIT +#define NPY_USE_C99_COMPLEX 1 +#define NPY_HAVE_COMPLEX_DOUBLE 1 +#define NPY_HAVE_COMPLEX_FLOAT 1 +#define NPY_HAVE_COMPLEX_LONG_DOUBLE 1 +#define NPY_USE_C99_FORMATS 1 +#define NPY_VISIBILITY_HIDDEN __attribute__((visibility(hidden))) +#define NPY_ABI_VERSION 0x0109 +#define NPY_API_VERSION 0x0007 + +#ifndef __STDC_FORMAT_MACROS +#define __STDC_FORMAT_MACROS 1 +#endif diff --git a/meta/recipes-devtools/python/python-numpy/aarch64/config.h b/meta/recipes-devtools/python/python-numpy/aarch64/config.h new file mode 100644 index 000..c30b868 --- /dev/null +++ b/meta/recipes-devtools/python/python-numpy/aarch64/config.h @@ -0,0 +1,139 @@ +#define HAVE_ENDIAN_H 1 +#define SIZEOF_PY_INTPTR_T 8 +#define SIZEOF_PY_LONG_LONG 8 +#define MATHLIB m +#define HAVE_SIN 1 +#define HAVE_COS 1 +#define HAVE_TAN 1 +#define HAVE_SINH 1 +#define HAVE_COSH 1 +#define HAVE_TANH 1 +#define HAVE_FABS 1 +#define HAVE_FLOOR 1 +#define HAVE_CEIL 1 +#define HAVE_SQRT 1 +#define HAVE_LOG10 1 +#define HAVE_LOG 1 +#define HAVE_EXP 1 +#define HAVE_ASIN 1 +#define HAVE_ACOS 1 +#define HAVE_ATAN 1 +#define HAVE_FMOD 1 +#define HAVE_MODF 1 +#define HAVE_FREXP 1 +#define HAVE_LDEXP 1 +#define HAVE_RINT 1 +#define HAVE_TRUNC 1 +#define HAVE_EXP2 1 +#define HAVE_LOG2 1 +#define HAVE_ATAN2 1 +#define HAVE_POW 1 +#define HAVE_NEXTAFTER 1 +#define HAVE_SINF 1 +#define HAVE_COSF 1 +#define HAVE_TANF 1 +#define HAVE_SINHF 1 +#define HAVE_COSHF 1 +#define HAVE_TANHF 1 +#define HAVE_FABSF 1 +#define HAVE_FLOORF 1 +#define HAVE_CEILF 1 +#define HAVE_RINTF 1 +#define HAVE_TRUNCF 1 +#define HAVE_SQRTF 1 +#define HAVE_LOG10F 1 +#define HAVE_LOGF 1 +#define HAVE_LOG1PF 1 +#define HAVE_EXPF 1 +#define HAVE_EXPM1F 1 +#define HAVE_ASINF 1 +#define
[OE-core] [PATCH 2/5] python-mako: add (from meta-oe)
python-mako is needed for Piglit. This recipe is taken directly from meta-oe.
Signed-off-by: Ross Burton ross.bur...@intel.com
---
meta/recipes-devtools/python/python-mako_0.7.2.bb | 22 +
1 file changed, 22 insertions(+)
create mode 100644 meta/recipes-devtools/python/python-mako_0.7.2.bb
diff --git a/meta/recipes-devtools/python/python-mako_0.7.2.bb
b/meta/recipes-devtools/python/python-mako_0.7.2.bb
new file mode 100644
index 000..1d2bdd7
--- /dev/null
+++ b/meta/recipes-devtools/python/python-mako_0.7.2.bb
@@ -0,0 +1,22 @@
+DESCRIPTION = Templating library for Python
+SECTION = devel/python
+LICENSE = MIT
+LIC_FILES_CHKSUM = file://LICENSE;md5=da8dd26ed9751ee0cfdf9df1a16bbb54
+
+PR = r2
+
+SRC_URI = http://www.makotemplates.org/downloads/Mako-${PV}.tar.gz;
+SRC_URI[md5sum] = e3c0a677aa4216da9e89ef8fa76cbafb
+SRC_URI[sha256sum] =
fe8698e845035586bd711a6748e4e40a208a58de276b9138026164700494b68f
+
+S = ${WORKDIR}/Mako-${PV}
+
+inherit setuptools
+
+RDEPENDS_${PN} = python-threading \
+ python-netclient \
+ python-html \
+
+RDEPENDS_${PN}_class-native =
+
+BBCLASSEXTEND = native nativesdk
--
1.7.10.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 4/5] piglit: add (from meta-oe)
Piglit is an OpenGL testing tool. This recipe is taken directly from meta-oe.
Signed-off-by: Ross Burton ross.bur...@intel.com
---
meta/recipes-graphics/piglit/piglit_git.bb | 44
1 file changed, 44 insertions(+)
create mode 100644 meta/recipes-graphics/piglit/piglit_git.bb
diff --git a/meta/recipes-graphics/piglit/piglit_git.bb
b/meta/recipes-graphics/piglit/piglit_git.bb
new file mode 100644
index 000..7c4f9a0
--- /dev/null
+++ b/meta/recipes-graphics/piglit/piglit_git.bb
@@ -0,0 +1,44 @@
+SUMMARY = OpenGL driver testing framework
+LICENSE = MIT LGPLv2+ GPLv3 GPLv2+ BSD-3-Clause
+LIC_FILES_CHKSUM = file://COPYING;md5=b2beded7103a3d8a442a2a0391d607b0
+
+SRC_URI = git://anongit.freedesktop.org/piglit
+
+# From 2012/12/30.
+SRCREV = bbeff5d21b06d37338ad28e42d88f499bef13268
+# (when PV goes above 1.0 remove the trailing r)
+PV = 1.0+gitr${SRCPV}
+
+S = ${WORKDIR}/git
+
+DEPENDS = virtual/libx11 waffle virtual/libgl libglu python-mako-native
python-numpy-native
+
+inherit cmake pythonnative
+
+# CMake sets the rpath at build time with the source tree, and will reset it at
+# install time. As we don't install this doesn't happen, so force the rpath to
+# what we need.
+EXTRA_OECMAKE = -DCMAKE_BUILD_WITH_INSTALL_RPATH=1
-DCMAKE_INSTALL_RPATH=${libdir}/piglit/lib
+
+do_install() {
+ install -d ${D}${bindir}
+install -m 0755 piglit-*.py ${D}${bindir}
+
+install -d ${D}${libdir}/piglit/
+
+install -d ${D}${libdir}/piglit/bin
+install -m 755 ${S}/bin/* ${D}${libdir}/piglit/bin
+
+cp -a lib/ ${D}${libdir}/piglit/
+cp -a framework/ ${D}${libdir}/piglit/
+cp -a generated_tests/ ${D}${libdir}/piglit/
+cp -a tests/ ${D}${libdir}/piglit/
+cp -a templates/ ${D}${libdir}/piglit/
+
+sed -i -e 's|sys.path.append(.*)|sys.path.append(${libdir}/piglit)|'
${D}${bindir}/piglit-*.py
+sed -i -e 's|^templatedir = .*$|templatedir =
${libdir}/piglit/templates|' ${D}${bindir}/piglit-summary-html.py
+}
+
+FILES_${PN}-dbg += ${libdir}/piglit/*/.debug/
+
+RDEPENDS_${PN} = python waffle python-json python-subprocess
python-multiprocessing python-textutils python-netserver python-shell
mesa-demos
--
1.7.10.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/5] waffle: add (from meta-oe)
Waffle is needed for Piglit. This recipe is taken directly frome meta-oe.
Signed-off-by: Ross Burton ross.bur...@intel.com
---
meta/recipes-graphics/waffle/files/cflags.patch | 27 ++
meta/recipes-graphics/waffle/waffle_1.2.2.bb| 34 +++
2 files changed, 61 insertions(+)
create mode 100644 meta/recipes-graphics/waffle/files/cflags.patch
create mode 100644 meta/recipes-graphics/waffle/waffle_1.2.2.bb
diff --git a/meta/recipes-graphics/waffle/files/cflags.patch
b/meta/recipes-graphics/waffle/files/cflags.patch
new file mode 100644
index 000..3819756
--- /dev/null
+++ b/meta/recipes-graphics/waffle/files/cflags.patch
@@ -0,0 +1,27 @@
+Upstream-Status: Backport
+Signed-off-by: Ross Burton ross.bur...@intel.com
+
+From 2abec1cb3c17fa5ec8d945d79acd74a39c38293a Mon Sep 17 00:00:00 2001
+From: Ross Burton ross.bur...@intel.com
+Date: Wed, 12 Dec 2012 12:57:18 +
+Subject: cmake: respect existing CMAKE_C_FLAGS
+
+When cross-compiling it's not unusual to need specific arguments passed to gcc
+such as --sysroot. Ensure that these are passed on from the toolchain file by
+appending to CMAKE_C_FLAGS instead of overwriting it.
+
+Signed-off-by: Ross Burton ross.bur...@intel.com
+
+Index: waffle-1.2.2/CMakeLists.txt
+===
+--- waffle-1.2.2.orig/CMakeLists.txt 2012-11-28 00:43:40.0 +
waffle-1.2.2/CMakeLists.txt2013-02-13 11:34:02.476188233 +
+@@ -212,7 +212,7 @@
+ #
--
+
+ # FIXME: Only enable c99 if compiler supports it.
+-set(CMAKE_C_FLAGS --std=c99 -Wall -Werror=implicit-function-declaration)
++set(CMAKE_C_FLAGS ${CMAKE_C_FLAGS} --std=c99 -Wall
-Werror=implicit-function-declaration)
+ if(${CMAKE_SYSTEM_NAME} STREQUAL Linux)
+ # On MacOS, the SSE2 headers trigger this error.
+ set(CMAKE_C_FLAGS ${CMAKE_C_FLAGS} -Werror=missing-prototypes)
diff --git a/meta/recipes-graphics/waffle/waffle_1.2.2.bb
b/meta/recipes-graphics/waffle/waffle_1.2.2.bb
new file mode 100644
index 000..4f80191
--- /dev/null
+++ b/meta/recipes-graphics/waffle/waffle_1.2.2.bb
@@ -0,0 +1,34 @@
+SUMMARY = cross-platform C library to defer selection of GL API and of window
system
+LICENSE = BSD-2-Clause
+LIC_FILES_CHKSUM = file://LICENSE.txt;md5=4c5154407c2490750dd461c50ad94797 \
+
file://include/waffle/waffle.h;endline=24;md5=61dbf8697f61c78645e75a93c585b1bf
+
+SRC_URI =
http://people.freedesktop.org/~chadversary/waffle/files/release/${BPN}-${PV}/${BPN}-${PV}.tar.xz
\
+ file://cflags.patch
+
+SRC_URI[md5sum] = fdd07cea7709422fbf72418ee63a285d
+SRC_URI[sha256sum] =
7e342c859b58d4e051b347ef3d7740ed2f3b6c506b93daec272724afe7dd1311
+
+inherit cmake
+
+# This should be overridden per-machine to reflect the capabilities of the GL
+# stack.
+PACKAGECONFIG ??= glx
+
+# I say virtual/libgl, actually wants gl.pc
+PACKAGECONFIG[glx] = -Dwaffle_has_glx=1,,virtual/libgl libx11
+
+# I say virtual/libgl, actually wants wayland-egl.pc, egl.pc, and the wayland
+# DISTRO_FEATURE.
+PACKAGECONFIG[wayland] = -Dwaffle_has_wayland=1,,virtual/libgl wayland
+
+# I say virtual/libgl, actually wants gbm.pc egl.pc
+PACKAGECONFIG[gbm] = -Dwaffle_has_wayland=1,,virtual/libgl udev
+
+# I say virtual/libgl, actually wants egl.pc
+PACKAGECONFIG[x11-egl] = -Dwaffle_has_x11_egl=1,,virtual/libgl libxcb
+
+# Take the flags added by PACKAGECONFIG and pass them to cmake.
+EXTRA_OECMAKE = ${EXTRA_OECONF}
+
+FILES_${PN}-dev += ${datadir}/cmake/Modules/FindWaffle.cmake
--
1.7.10.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] sstate-diff-machines.sh encounters IndexError
I just got round to trying sstate-diff-machines.sh in order to find out why
some of our recipes are thwarting the sstate cache but I couldn't make it
work. :(
With current oe-core 1028ac813fa9803ebfff6bcfa7f8b67012609b27 and bitbake
e13acb4113ce75226664c3006a9776cc885e860d I get the following error:
$ sstate-diff-machines.sh --tmpdir=tmp-eglibc --machines=qemux86
--targets=gcc-cross
[...]
NOTE: Reparsing files to collect dependency data
ERROR: An uncaught exception occured in runqueue, please see the failure below:
ERROR: Running idle function
Traceback (most recent call last):
File /vg0disk/mac/src/oe-core/bitbake/lib/bb/server/process.py, line 133,
in ProcessServer.idle_commands(delay=0.1, fds=[read-only Connection, handle
4, read-write Connection, handle 7]):
try:
retval = function(self, data, False)
if retval is False:
File /vg0disk/mac/src/oe-core/bitbake/lib/bb/cooker.py, line 1151, in
buildTargetsIdle(server=ProcessServer(ProcessServer-2, started),
rq=bb.runqueue.RunQueue instance at 0x2d118c0, abort=False):
try:
retval = rq.execute_runqueue()
except runqueue.TaskFailure as exc:
File /vg0disk/mac/src/oe-core/bitbake/lib/bb/runqueue.py, line 1082, in
RunQueue.execute_runqueue():
try:
return self._execute_runqueue()
except bb.runqueue.TaskFailure:
File /vg0disk/mac/src/oe-core/bitbake/lib/bb/runqueue.py, line 1034, in
RunQueue._execute_runqueue():
self.dump_signatures()
self.write_diffscenetasks(invalidtasks)
self.state = runQueueComplete
File /vg0disk/mac/src/oe-core/bitbake/lib/bb/runqueue.py, line 1227, in
RunQueue.write_diffscenetasks(invalidtasks=set([4, 389, 136, 269, 399, 472,
147, 20, 279, 409, 159, 32, 289, 419, 169, 42, 299, 429, 179, 52, 309, 439,
189, 62, 319, 449, 199, 72, 329, 460, 209, 339, 88, 219, 349, 482, 229, 102,
359, 239, 369, 116, 379, 126, 255])):
matches = {k : v for k, v in matches.iteritems() if h not in k}
latestmatch = sorted(matches.keys(), key=lambda f:
matches[f])[-1]
prevh = __find_md5__.search(latestmatch).group(0)
IndexError: list index out of range
NOTE: Tasks Summary: Attempted 0 tasks of which 0 didn't need to be rerun and
all succeeded.
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
Am I doing something silly or is this tool currently broken?
Thanks.
Mike.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] rpm: fix a endian incompatible error in generating tag
On 1/9/14, 2:49 AM, Ming Liu wrote:
A flaw was found in the way rpm generating arbitrary tags, which leads to a
incorrect query result, this issue is introduced by a incompatible endianess
when the generating process is executed on different architectures.
This patch resolves it by taking a uniform byte order.
Signed-off-by: Ming Liu ming@windriver.com
---
.../rpm-tag-generate-endian-conversion-fix.patch | 29
meta/recipes-devtools/rpm/rpm_5.4.9.bb |1 +
2 files changed, 30 insertions(+), 0 deletions(-)
create mode 100644
meta/recipes-devtools/rpm/rpm/rpm-tag-generate-endian-conversion-fix.patch
diff --git
a/meta/recipes-devtools/rpm/rpm/rpm-tag-generate-endian-conversion-fix.patch
b/meta/recipes-devtools/rpm/rpm/rpm-tag-generate-endian-conversion-fix.patch
new file mode 100644
index 000..4379515
--- /dev/null
+++ b/meta/recipes-devtools/rpm/rpm/rpm-tag-generate-endian-conversion-fix.patch
@@ -0,0 +1,29 @@
+fix a endian incompatible error in generating rpm tag
+
+A flaw was found in the way rpm generating arbitrary tags, which leads to a
+incorrect query result, this issue is introduced by a incompatible endianess
+when the generating process is executed on different architectures.
+
+This patch resolves it by taking a uniform byte order.
+
+Upstream-Status: Pending
+
+Signed-off-by: Ming Liu ming@windriver.com
+---
+ tagname.c |3 +++
+ 1 file changed, 3 insertions(+)
+
+diff -urpN a/rpmdb/tagname.c b/rpmdb/tagname.c
+--- a/rpmdb/tagname.c
b/rpmdb/tagname.c
+@@ -152,7 +152,10 @@ static rpmTag _tagGenerate(const char *s
+ xx = rpmDigestUpdate(ctx, s, nb);
+ xx = rpmDigestFinal(ctx, digest, digestlen, 0);
+ if (digest digestlen 4) {
++ /* The tag is stored in a uniform byte order for cross-endian
compatibility.
++ Swap to little-endian if appropriate. */
+ memcpy(tag, digest + (digestlen - 4), 4);
++ tag = htole32(tag);
+ tag = (rpmTag) (tag 0x3fff);
+ tag = (rpmTag) (tag | 0x4000);
The above code doesn't look right to me.
If this is reading in from the RPM package, it should be an le32toh..
Otherwise if it's generating the digest info.. then the htole32 should be
-after- the and | operations, otherwise the wrong part of the value will be
modified.
--Mark
+ }
diff --git a/meta/recipes-devtools/rpm/rpm_5.4.9.bb
b/meta/recipes-devtools/rpm/rpm_5.4.9.bb
index 9d376a5..7921f40 100644
--- a/meta/recipes-devtools/rpm/rpm_5.4.9.bb
+++ b/meta/recipes-devtools/rpm/rpm_5.4.9.bb
@@ -89,6 +89,7 @@ SRC_URI =
http://www.rpm5.org/files/rpm/rpm-5.4/rpm-5.4.9-0.20120508.src.rpm;ex
file://debugedit-valid-file-to-fix-segment-fault.patch \
file://rpm-platform-file-fix.patch \
file://rpm-lsb-compatibility.patch \
+ file://rpm-tag-generate-endian-conversion-fix.patch \
# Uncomment the following line to enable platform score debugging
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] unmaintained layers
Hi everyone, At the last TSC meeting the topic of unmaintained layers came up. Here is the sorted list of master layers from the layer index [1], would it be possible for those in the know to indicate which layers are, or are suspected of being, unmaintained? meta-aarch64 meta-acer meta-ada meta-android meta-angstrom meta-arago-distro meta-arago-extras meta-asus meta-aurora meta-baryon meta-beagleboard meta-beagleboard-extras meta-browser meta-bug meta-buglabs meta-chicken meta-chiefriver meta-clutter meta-crownbay meta-crystalforest meta-cubox meta-darwin meta-eca meta-efikamx meta-efl meta-eldk meta-emenlow meta-erlang meta-ettus meta-filesystems meta-fri2 meta-fsl-arm meta-fsl-arm-extra meta-fsl-demos meta-fsl-ppc meta-fso meta-games meta-geeksphone meta-gir meta-gnome meta-gpe meta-gstreamer10 meta-guacamayo meta-gumstix meta-gumstix-community meta-gumstix-extras meta-hamradio meta-handheld meta-hipos meta-htc meta-igep meta-initramfs meta-intel meta-ivi meta-jasperforest meta-java meta-kde meta-kernel-dev meta-kirkwood meta-linaro meta-linaro-toolchain meta-lsi meta-lxcbench meta-measured meta-mentor meta-micro meta-mingw meta-minnow meta-mono meta-multimedia meta-n450 meta-netbookpro meta-netmodule meta-networking meta-nokia meta-nslu2 meta-nuc meta-oe meta-openmoko meta-openpandora meta-openstack meta-openstack-compute-deploy meta-openstack-controller-deploy meta-openstack-qemu meta-opie meta-oracle-java meta-osmocombb meta-ouya meta-palm meta-perl meta-picosam9 meta-qt3 meta-qt5 meta-raspberrypi meta-realtime meta-ro-rootfs meta-romley meta-ros meta-ruby meta-samsung meta-sdr meta-security meta-selinux meta-shr meta-shr-distro meta-slugos meta-smalltalk meta-sourcery meta-sugarbay meta-sunxi meta-sys940x meta-systemd meta-telephony meta-telldus meta-ti meta-tlk meta-tracing meta-virtualization meta-web-kiosk meta-webos meta-webos-ports meta-webserver meta-woce meta-x10 meta-xfce meta-xilinx meta-xilinx-community meta-yassl meta-yocto meta-yocto-bsp meta-zynq meta-zynq-milo openembedded-core toolchain-layer Thank you for your input, and best regards, Trevor [1] http://layers.openembedded.org/layerindex/branch/master/layers/ ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 0/2] RFC: Implement deterministic uid/gid
I have updated the git://git.yoctoproject.org/poky-contrib mhatle/uidgid to the latest oe-core master. I haven't seen any comments on this RFC yet. Does anyone have any opinion either way on the code referenced here? I'm confident patch 01/02 should be added to master. The patch 02/02 works properly in all of my testing and does implement support for 'deterministic uid/gid' with dynamic passwd/group file construction during package install. The code is only activated if USERADD_REWRITE_PARAMS is set to '1', so it's low risk -- but it does add a fairly large chunk of code to be maintained over time. --Mark On 12/10/13, 12:31 PM, Mark Hatle wrote: The following series implements the deterministic uid/gid setting for a distribution. Currently when a filesystem is generated the uid/gid values are generally set at install time, so the install order determines what the actual uid/gid values become. In order to create a deterministic uid/gid set, that still dynamically constructs the passwd/group file, we add an option to read a special passwd/group file to allow the system to determine the values. It uses the existing parameters, and the values from the special passwd/group files to reconstruct the parameter set to ensure these items are fully defined with static values. The first patch (01/02) is generally applicable. It fixes a real bug in the way the user/group adds occur today within the system. Patch 02/02 implements the new functionality. The following changes since commit 8505f0fa48cc79d51616b923c6e2c778c4b46a44: libmatchbox: use PACKAGECONFIG (2013-12-10 14:13:01 +) are available in the git repository at: git://git.yoctoproject.org/poky-contrib mhatle/uidgid http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=mhatle/uidgid Mark Hatle (2): useradd.bbclass: Fix build time install issues useradd.bbclass: Add ability to select a static uid/gid automatically meta/classes/useradd.bbclass | 247 ++- meta/conf/local.conf.sample.extended | 24 2 files changed, 265 insertions(+), 6 deletions(-) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] unmaintained layers
On Thu, Jan 9, 2014 at 1:45 PM, Trevor Woerner trevor.woer...@linaro.org wrote: Hi everyone, At the last TSC meeting the topic of unmaintained layers came up. Here is the sorted list of master layers from the layer index [1], would it be possible for those in the know to indicate which layers are, or are suspected of being, unmaintained? Wouldn't it be easier to do an initial sort based on commit activity ? Versus an opt-in query ? meta-aarch64 meta-acer meta-ada meta-android meta-angstrom meta-arago-distro meta-arago-extras meta-asus meta-aurora meta-baryon meta-beagleboard meta-beagleboard-extras meta-browser meta-bug meta-buglabs meta-chicken meta-chiefriver meta-clutter meta-crownbay meta-crystalforest meta-cubox meta-darwin meta-eca meta-efikamx meta-efl meta-eldk meta-emenlow meta-erlang meta-ettus meta-filesystems meta-fri2 meta-fsl-arm meta-fsl-arm-extra meta-fsl-demos meta-fsl-ppc meta-fso meta-games meta-geeksphone meta-gir meta-gnome meta-gpe meta-gstreamer10 meta-guacamayo meta-gumstix meta-gumstix-community meta-gumstix-extras meta-hamradio meta-handheld meta-hipos meta-htc meta-igep meta-initramfs meta-intel meta-ivi meta-jasperforest meta-java meta-kde meta-kernel-dev maintained. meta-kirkwood meta-linaro meta-linaro-toolchain meta-lsi meta-lxcbench meta-measured meta-mentor meta-micro meta-mingw meta-minnow meta-mono meta-multimedia meta-n450 meta-netbookpro meta-netmodule meta-networking meta-nokia meta-nslu2 meta-nuc meta-oe meta-openmoko meta-openpandora meta-openstack meta-openstack-compute-deploy meta-openstack-controller-deploy meta-openstack-qemu All openstack layers are maintained. meta-opie meta-oracle-java meta-osmocombb meta-ouya meta-palm meta-perl meta-picosam9 meta-qt3 meta-qt5 meta-raspberrypi meta-realtime mantained meta-ro-rootfs meta-romley meta-ros meta-ruby meta-samsung meta-sdr meta-security meta-selinux meta-shr meta-shr-distro meta-slugos meta-smalltalk meta-sourcery meta-sugarbay meta-sunxi meta-sys940x meta-systemd meta-telephony meta-telldus meta-ti meta-tlk meta-tracing meta-virtualization maintained But I can't say if I didn't miss something I maintain in the list, since it is long and I scanned it quickly. Bruce meta-web-kiosk meta-webos meta-webos-ports meta-webserver meta-woce meta-x10 meta-xfce meta-xilinx meta-xilinx-community meta-yassl meta-yocto meta-yocto-bsp meta-zynq meta-zynq-milo openembedded-core toolchain-layer Thank you for your input, and best regards, Trevor [1] http://layers.openembedded.org/layerindex/branch/master/layers/ ___ 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] unmaintained layers
On 1/9/14, 3:45 PM, Bruce Ashfield wrote: On Thu, Jan 9, 2014 at 1:45 PM, Trevor Woerner trevor.woer...@linaro.org wrote: Hi everyone, At the last TSC meeting the topic of unmaintained layers came up. Here is the sorted list of master layers from the layer index [1], would it be possible for those in the know to indicate which layers are, or are suspected of being, unmaintained? Wouldn't it be easier to do an initial sort based on commit activity ? Versus an opt-in query ? I agree.. see below for mine.. meta-aarch64 meta-acer meta-ada meta-android meta-angstrom meta-arago-distro meta-arago-extras meta-asus meta-aurora meta-baryon meta-beagleboard meta-beagleboard-extras meta-browser meta-bug meta-buglabs meta-chicken meta-chiefriver meta-clutter meta-crownbay meta-crystalforest meta-cubox meta-darwin meta-eca meta-efikamx meta-efl meta-eldk meta-emenlow meta-erlang meta-ettus meta-filesystems meta-fri2 meta-fsl-arm meta-fsl-arm-extra meta-fsl-demos meta-fsl-ppc meta-fso meta-games meta-geeksphone meta-gir meta-gnome meta-gpe meta-gstreamer10 meta-guacamayo meta-gumstix meta-gumstix-community meta-gumstix-extras meta-hamradio meta-handheld meta-hipos meta-htc meta-igep meta-initramfs meta-intel meta-ivi meta-jasperforest meta-java meta-kde meta-kernel-dev maintained. meta-kirkwood meta-linaro meta-linaro-toolchain meta-lsi meta-lxcbench meta-measured meta-mentor meta-micro meta-mingw meta-minnow meta-mono meta-multimedia meta-n450 meta-netbookpro meta-netmodule meta-networking meta-nokia meta-nslu2 meta-nuc meta-oe meta-openmoko meta-openpandora meta-openstack meta-openstack-compute-deploy meta-openstack-controller-deploy meta-openstack-qemu All openstack layers are maintained. meta-opie meta-oracle-java meta-osmocombb meta-ouya meta-palm meta-perl meta-picosam9 meta-qt3 meta-qt5 meta-raspberrypi meta-realtime mantained meta-ro-rootfs meta-romley meta-ros meta-ruby meta-samsung meta-sdr meta-security meta-selinux maintained meta-shr meta-shr-distro meta-slugos meta-smalltalk meta-sourcery meta-sugarbay meta-sunxi meta-sys940x meta-systemd meta-telephony meta-telldus meta-ti meta-tlk meta-tracing meta-virtualization maintained But I can't say if I didn't miss something I maintain in the list, since it is long and I scanned it quickly. Bruce meta-web-kiosk meta-webos meta-webos-ports meta-webserver meta-woce meta-x10 meta-xfce meta-xilinx meta-xilinx-community meta-yassl meta-yocto meta-yocto-bsp meta-zynq meta-zynq-milo openembedded-core toolchain-layer Thank you for your input, and best regards, Trevor [1] http://layers.openembedded.org/layerindex/branch/master/layers/ ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 0/2] RFC: Implement deterministic uid/gid
On Thu, Jan 09, 2014 at 01:49:28PM -0600, Mark Hatle wrote: I have updated the git://git.yoctoproject.org/poky-contrib mhatle/uidgid to the latest oe-core master. I haven't seen any comments on this RFC yet. Does anyone have any opinion either way on the code referenced here? I wanted to do more tests and find some smaller reproducer, but I'm interested in this series. What I'm seeing in our builds is that when you compare files-in-image.txt report from independent (not reusing sstate-cache) builds with exactly the same metadata, group owners aren't deterministic. Random files in image getting owned by messagebus group etc., these issues went away when useradd class creating these ad-hoc groups had parameter for fixed gid or when I've added these groups directly to base-passwd group.master. Is this the same problem you're addressing in this patchset? I'm confident patch 01/02 should be added to master. The patch 02/02 works properly in all of my testing and does implement support for 'deterministic uid/gid' with dynamic passwd/group file construction during package install. The code is only activated if USERADD_REWRITE_PARAMS is set to '1', so it's low risk -- but it does add a fairly large chunk of code to be maintained over time. --Mark On 12/10/13, 12:31 PM, Mark Hatle wrote: The following series implements the deterministic uid/gid setting for a distribution. Currently when a filesystem is generated the uid/gid values are generally set at install time, so the install order determines what the actual uid/gid values become. In order to create a deterministic uid/gid set, that still dynamically constructs the passwd/group file, we add an option to read a special passwd/group file to allow the system to determine the values. It uses the existing parameters, and the values from the special passwd/group files to reconstruct the parameter set to ensure these items are fully defined with static values. The first patch (01/02) is generally applicable. It fixes a real bug in the way the user/group adds occur today within the system. Patch 02/02 implements the new functionality. The following changes since commit 8505f0fa48cc79d51616b923c6e2c778c4b46a44: libmatchbox: use PACKAGECONFIG (2013-12-10 14:13:01 +) are available in the git repository at: git://git.yoctoproject.org/poky-contrib mhatle/uidgid http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=mhatle/uidgid Mark Hatle (2): useradd.bbclass: Fix build time install issues useradd.bbclass: Add ability to select a static uid/gid automatically meta/classes/useradd.bbclass | 247 ++- meta/conf/local.conf.sample.extended | 24 2 files changed, 265 insertions(+), 6 deletions(-) ___ 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] unmaintained layers
On 01/09/14 17:43, Mark Hatle wrote: On 1/9/14, 3:45 PM, Bruce Ashfield wrote: On Thu, Jan 9, 2014 at 1:45 PM, Trevor Woerner trevor.woer...@linaro.org wrote: Hi everyone, At the last TSC meeting the topic of unmaintained layers came up. Here is the sorted list of master layers from the layer index [1], would it be possible for those in the know to indicate which layers are, or are suspected of being, unmaintained? Wouldn't it be easier to do an initial sort based on commit activity ? Versus an opt-in query ? I agree.. see below for mine.. To be honest, I had asked people to indicate which layers they thought were *un*maintained (since I assumed that list would be small), but this way works too. Interestingly enough, had I sorted the list on commit activity, according to http://git.yoctoproject.org/cgit/cgit.cgi/?s=idle meta-realtime hasn't been touched in 10 months which would make me suspect it was abandoned. ___ 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, Failed tasks 2014-01-09
On Thu, Jan 09, 2014 at 05:37:24PM +0100, Andreas Müller wrote: On Thu, Jan 9, 2014 at 4:23 PM, Martin Jansa martin.ja...@gmail.com wrote: On Thu, Jan 09, 2014 at 04:12:52PM +0100, Andreas Müller wrote: On Thu, Jan 9, 2014 at 3:46 PM, Martin Jansa martin.ja...@gmail.com wrote: http://www.openembedded.org/wiki/Bitbake_World_Status == Failed tasks 2014-01-09 == === common (6) === * meta-openembedded/meta-efl/recipes-efl/webkit/webkit-efl_svn.bb, do_configure * meta-openembedded/meta-multimedia/recipes-mediacentre/xbmc/xbmc_git.bb, do_fetch * meta-openembedded/meta-oe/recipes-devtools/tcltk/tk_8.6.0.bb, do_compile * meta-openembedded/meta-oe/recipes-extended/gnuplot/gnuplot_4.4.4.bb, do_compile * meta-openembedded/meta-oe/recipes-navigation/monav/monav_0.3.bb, do_compile * meta-qt5/recipes-qt/qt5/qtwayland_git.bb, do_compile I have problems with qtwayland too and think that I am close to understand what's going on (on 5.2 branch). Where do I find logs for this error? Links for each machine are on the bottom of the e-mail: http://logs.nslu2-linux.org/buildlogs/oe/oe-shr-core-branches/... qtwayland builds for me fine with oe-core only and also in qt5-5.2.0 + webos-ports, so I haven't looked much into it yet. OK - I can't find that in the logs - but anyway: I am working also on 5.2.0 and my error for qtwayland showed up as tons of multiple defined GL data types as e.g. http://logs.nslu2-linux.org/buildlogs/oe/oe-shr-core-branches/log.world.20140109_011732.log/bitbake.log has that, but if you're looking at it in browser you need to wait quite a long time for it to fetch completely and at least in chromium it sometimes fail to search in bigger text files for me. | In file included from /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/x86_64-oe-linux/qtwayland/5.1.0+gitAUTOINC+87dba733ac-r0/git/src/compositor/wayland_wrapper/qwlinputdevice.cpp:41:0: | /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/x86_64-oe-linux/qtwayland/5.1.0+gitAUTOINC+87dba733ac-r0/git/src/compositor/wayland_wrapper/qwlinputdevice_p.h:128:22: error: field 'pointer' has incomplete type | ::wl_pointer pointer; | ^ ... and a lot more like this 'error: 'GLdouble' has a previous declaration as 'typedef GLfloat GLdouble'' Reason was that I had GL-headers in my sysroot but qtwayland was configured without wayland-egl / egl (it took me long to find out that that wayland-egl is supplied by mesa..). So qtwayland tried to build glx-compositor which does not work with GL/GLES headers in sysroot. After building egl and wayland-egl, qtwayland configured fine and the errors disappeared. It's probably different error than what I have, but with latest mesa I had problem that I need to define MESA_EGL_NO_X11_HEADERS in qtbase and qtwebkit again to prevent using xorg includes, maybe that's where your 2nd GLdouble is leaking in? http://lists.openembedded.org/pipermail/openembedded-core/2014-January/088072.html -- 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] [RFC OE-core/meta/lib] BSP Specific Qemurunner
Hi Stefan, On Thursday, 9 January 2014 10:19 PM, Stanacar, StefanX wrote: On Thu, 2014-01-09 at 00:01 +, Sipke Vriend wrote: On Wednesday, 8 January 2014 11:53 PM Paul Eggleton wrote: On Wednesday 08 January 2014 13:12:41 Richard Purdie wrote: On Tue, 2014-01-07 at 22:59 +, Sipke Vriend wrote: Hi Richard, -Original Message- On Wednesday, 8 January 2014 12:00 AM, Richard Purdie wrote: On Tue, 2014-01-07 at 03:09 +, Sipke Vriend wrote: Hi, This RFC is a proposal to allow BSP layers to setup qemu with their specific requirements for the testimage oe-core functionality. The suggested changes will be exercised by the bitbake -c testimage image command. Similarly to the oeqa test cases this proposal extends the meta/lib/oeqa python modules to allow inclusion of python utility scripts in the BSP layers. Any BSP layer wishing to supply their own qemu setup would need to create an appropriate meta-bsplayer/lib/oeqa/utils/machinestarter.py The effect is that the lib/oeqa/utils/qemurunner will either allow the bsp layer provided machinestarter to spawn qemu or if not provided, spawn qemu via runqemu as currently. An example bsp layer is available here: https://github.com/sipke/meta-xilinx/tree/sipke/qemurunner with all required additions in the meta-xilinx/lib directory. This RFC is triggered by and indirectly related to Bugzilla report runqemu shouldn't hard-code machine knowledge https://bugzilla.yoctoproject.org/show_bug.cgi?id=4827 Why would we do this rather than improve runqemu to be extendable from BSP layers? Proposing as an additional way to launch qemu for oeqa testimage functionality, Improving runqemu can and probably should still happen. To consider: * it keeps testimage functionality (for bsp layers specific things) in the lib directly (similar to test cases) and as python. * testing (via testimage) may have a different requirement to that of running runqemu on the command line, so an alternate way to launch qemu could be useful. * should this approach of extending the oeqa testimage functionality into bsp layers be accepted, this could allow also for bsp specific hardware setup for testimage functionality in bsp layers. Primary aim is a solution which allows the bsp layer to control the setup of qemu (and eventually hardware) for testimage functionality. This is a proposal towards that goal. I thought Stefan was already also working on something towards this goal. I'd like to ensure we don't end up with two things doing the same thing. Stefan? Agreed. One solution is desired. Happy to coordinate with and assist Stefan, either implementing part of a solution (proposed one or another) and/or testing whatever Stefan comes up with against our bsp layer. I'm sorry for replying so late, this has been a slow week. I'm a bit confused because last time I checked I wasn't working on something similar :) (layer-controlled qemu/bsp setup), but I'm happy to help. No worries, you're not late and sorry for having inadvertently dragged you in it seems :) I've looked at the patches themselves, and they are okay, but I'm not sure a layer-specific qemu setup for testimage is what we should do in the long term. Now, I can see the problem you are trying to fix here and why you need this... I always assumed that a BSP layer is mostly about real hw and that runqemu will deal with any qemu machine. So, as Richard said, we should probably fix runqemu. Ok, let's fix runqemu for qemu setup, and see from that whether any changes are required within qemurunner.py or not. I can envisage there might be to remove some dependencies on infrastructure setup, but will not know for sure till the work is started. Has someone started and is there a branch available to track this work? Now, I really like the idea of a layer-controlled/extendable target setup (be it qemu or hardware) and I think we should allow a layer to extend lib/oeqa/targetcontrol.py and provide (or extend) its own TEST_TARGET (besides qemu and simpleremote). That will prove more useful for hw stuff and it will allow a layer to completely control deployment of a qemu target too (deploy, start, stop, running commands, etc). E.g: perhaps a layer doesn't like the use of the ext3 images for qemu and needs to use something else. Thoughts? Great, I like it. Will give it some more thought, but even the simple addition of allowing a bsp layer to provide its own TEST_TARGET class is a great step forward. Thanks Sipke Cheers, Stefan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] sstate-diff-machines.sh encounters IndexError
On Thu, Jan 09, 2014 at 05:26:05PM +, Mike Crowe wrote:
I just got round to trying sstate-diff-machines.sh in order to find out why
some of our recipes are thwarting the sstate cache but I couldn't make it
work. :(
With current oe-core 1028ac813fa9803ebfff6bcfa7f8b67012609b27 and bitbake
e13acb4113ce75226664c3006a9776cc885e860d I get the following error:
$ sstate-diff-machines.sh --tmpdir=tmp-eglibc --machines=qemux86
--targets=gcc-cross
[...]
NOTE: Reparsing files to collect dependency data
ERROR: An uncaught exception occured in runqueue, please see the failure
below:
ERROR: Running idle function
Traceback (most recent call last):
File /vg0disk/mac/src/oe-core/bitbake/lib/bb/server/process.py, line 133,
in ProcessServer.idle_commands(delay=0.1, fds=[read-only Connection, handle
4, read-write Connection, handle 7]):
try:
retval = function(self, data, False)
if retval is False:
File /vg0disk/mac/src/oe-core/bitbake/lib/bb/cooker.py, line 1151, in
buildTargetsIdle(server=ProcessServer(ProcessServer-2, started),
rq=bb.runqueue.RunQueue instance at 0x2d118c0, abort=False):
try:
retval = rq.execute_runqueue()
except runqueue.TaskFailure as exc:
File /vg0disk/mac/src/oe-core/bitbake/lib/bb/runqueue.py, line 1082, in
RunQueue.execute_runqueue():
try:
return self._execute_runqueue()
except bb.runqueue.TaskFailure:
File /vg0disk/mac/src/oe-core/bitbake/lib/bb/runqueue.py, line 1034, in
RunQueue._execute_runqueue():
self.dump_signatures()
self.write_diffscenetasks(invalidtasks)
self.state = runQueueComplete
File /vg0disk/mac/src/oe-core/bitbake/lib/bb/runqueue.py, line 1227, in
RunQueue.write_diffscenetasks(invalidtasks=set([4, 389, 136, 269, 399, 472,
147, 20, 279, 409, 159, 32, 289, 419, 169, 42, 299, 429, 179, 52, 309, 439,
189, 62, 319, 449, 199, 72, 329, 460, 209, 339, 88, 219, 349, 482, 229, 102,
359, 239, 369, 116, 379, 126, 255])):
matches = {k : v for k, v in matches.iteritems() if h not in
k}
latestmatch = sorted(matches.keys(), key=lambda f:
matches[f])[-1]
prevh = __find_md5__.search(latestmatch).group(0)
IndexError: list index out of range
NOTE: Tasks Summary: Attempted 0 tasks of which 0 didn't need to be rerun and
all succeeded.
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
Am I doing something silly or is this tool currently broken?
It's not fault of this script, bitbake -S is currently broken, see
http://lists.openembedded.org/pipermail/bitbake-devel/2013-December/004269.html
and
http://lists.openembedded.org/pipermail/bitbake-devel/2013-December/004271.html
Regards,
--
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] unmaintained layers
On Thu, Jan 09, 2014 at 04:45:38PM -0500, Bruce Ashfield wrote: On Thu, Jan 9, 2014 at 1:45 PM, Trevor Woerner trevor.woer...@linaro.org wrote: Hi everyone, At the last TSC meeting the topic of unmaintained layers came up. Here is the sorted list of master layers from the layer index [1], would it be possible for those in the know to indicate which layers are, or are suspected of being, unmaintained? Wouldn't it be easier to do an initial sort based on commit activity ? Versus an opt-in query ? Some BSPs are valid for very long time without any commit in it. So I think it will show a lot of false-possitives. meta-aarch64 meta-acer meta-ada meta-android meta-angstrom meta-arago-distro meta-arago-extras meta-asus meta-aurora meta-baryon meta-beagleboard meta-beagleboard-extras meta-browser meta-bug meta-buglabs meta-chicken meta-chiefriver meta-clutter meta-crownbay meta-crystalforest meta-cubox meta-darwin meta-eca meta-efikamx meta-efl meta-eldk meta-emenlow meta-erlang meta-ettus meta-filesystems meta-fri2 meta-fsl-arm meta-fsl-arm-extra meta-fsl-demos meta-fsl-ppc meta-fso meta-games meta-geeksphone meta-gir meta-gnome meta-gpe meta-gstreamer10 meta-guacamayo meta-gumstix meta-gumstix-community meta-gumstix-extras meta-hamradio meta-handheld meta-hipos meta-htc meta-igep meta-initramfs meta-intel meta-ivi meta-jasperforest meta-java meta-kde meta-kernel-dev maintained. meta-kirkwood meta-linaro meta-linaro-toolchain meta-lsi meta-lxcbench meta-measured meta-mentor meta-micro meta-mingw meta-minnow meta-mono meta-multimedia meta-n450 meta-netbookpro meta-netmodule meta-networking meta-nokia meta-nslu2 meta-nuc meta-oe meta-openmoko meta-openpandora meta-openstack meta-openstack-compute-deploy meta-openstack-controller-deploy meta-openstack-qemu All openstack layers are maintained. meta-opie meta-oracle-java meta-osmocombb meta-ouya meta-palm meta-perl meta-picosam9 meta-qt3 meta-qt5 meta-raspberrypi meta-realtime mantained meta-ro-rootfs meta-romley meta-ros meta-ruby meta-samsung meta-sdr meta-security meta-selinux meta-shr meta-shr-distro meta-slugos meta-smalltalk meta-sourcery meta-sugarbay meta-sunxi meta-sys940x meta-systemd meta-telephony meta-telldus meta-ti meta-tlk meta-tracing meta-virtualization maintained But I can't say if I didn't miss something I maintain in the list, since it is long and I scanned it quickly. Bruce meta-web-kiosk meta-webos meta-webos-ports meta-webserver meta-woce meta-x10 meta-xfce meta-xilinx meta-xilinx-community meta-yassl meta-yocto meta-yocto-bsp meta-zynq meta-zynq-milo openembedded-core toolchain-layer Thank you for your input, and best regards, Trevor [1] http://layers.openembedded.org/layerindex/branch/master/layers/ ___ 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 -- 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] unmaintained layers
On 01/09/2014 06:20 PM, Trevor Woerner wrote: On 01/09/14 17:43, Mark Hatle wrote: On 1/9/14, 3:45 PM, Bruce Ashfield wrote: On Thu, Jan 9, 2014 at 1:45 PM, Trevor Woerner trevor.woer...@linaro.org wrote: Hi everyone, At the last TSC meeting the topic of unmaintained layers came up. Here is the sorted list of master layers from the layer index [1], would it be possible for those in the know to indicate which layers are, or are suspected of being, unmaintained? Wouldn't it be easier to do an initial sort based on commit activity ? Versus an opt-in query ? I agree.. see below for mine.. To be honest, I had asked people to indicate which layers they thought were *un*maintained (since I assumed that list would be small), but this way works too. Interestingly enough, had I sorted the list on commit activity, according to http://git.yoctoproject.org/cgit/cgit.cgi/?s=idle meta-realtime hasn't been touched in 10 months which would make me suspect it was abandoned. This approach is a good test of which layer maintainers are paying attention to list traffic :) Philip ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] unmaintained layers
On Thu, Jan 9, 2014 at 4:35 PM, Martin Jansa martin.ja...@gmail.com wrote: On Thu, Jan 09, 2014 at 04:45:38PM -0500, Bruce Ashfield wrote: On Thu, Jan 9, 2014 at 1:45 PM, Trevor Woerner trevor.woer...@linaro.org wrote: Hi everyone, At the last TSC meeting the topic of unmaintained layers came up. Here is the sorted list of master layers from the layer index [1], would it be possible for those in the know to indicate which layers are, or are suspected of being, unmaintained? Wouldn't it be easier to do an initial sort based on commit activity ? Versus an opt-in query ? In case we're sticking to opt-in rather than opt-out, meta-mentor, meta-sourcery, meta-ro-rootfs, and meta-tracing are maintained by Mentor Graphics at this time. :) -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-commits] Chen Qi : initscripts: split the functions script into a separate package
On 01/09/2014 07:54 PM, Martin Jansa wrote:
On Mon, Jan 06, 2014 at 10:15:11PM +, g...@git.openembedded.org wrote:
Module: openembedded-core.git
Branch: master
Commit: 736dd8380f41d6ff1d3d0e4fe33cc01e2e873ef6
URL:
http://git.openembedded.org/?p=openembedded-core.gita=commit;h=736dd8380f41d6ff1d3d0e4fe33cc01e2e873ef6
Author: Chen Qi qi.c...@windriver.com
Date: Mon Jan 6 15:27:34 2014 +0800
initscripts: split the functions script into a separate package
Many SysV init scripts need the /etc/init.d/functions script. But
this script is part of the initscripts package. As a result, the
initscripts package should always be installed into the system to
avoid errors when starting daemons. However, it makes no sense to
install the initscripts package into a systemd based image, because
what the init scripts provide has already been provided by the systemd.
On the other hand, the functions script might be still needed in a
systemd based image because other init scripts such as distcc might need
it.
The above situation leads to a natural separation of the functions script
from the initscripts package. And this patch does so. It separates the
functions script into initscripts-functions packages.
FYI: In cases where alternative initscripts are used (and
VIRTUAL-RUNTIME_initscripts) respected, these alternatives also need to
rprovide initscripts-functions (or at least u-a for functions), otherwise
u-a fails in do_rootfs which is fatal for read-only:
| ERROR: The following packages could not be configured offline and
rootfs is read-only: initscripts-functions
Thanks a lot for your information.
Best Regards,
Chen Qi
Signed-off-by: Chen Qi qi.c...@windriver.com
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
meta/recipes-core/initscripts/initscripts_1.0.bb | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/initscripts/initscripts_1.0.bb
b/meta/recipes-core/initscripts/initscripts_1.0.bb
index 5951e0c..d1644a3 100644
--- a/meta/recipes-core/initscripts/initscripts_1.0.bb
+++ b/meta/recipes-core/initscripts/initscripts_1.0.bb
@@ -42,8 +42,12 @@ KERNEL_VERSION =
inherit update-alternatives
DEPENDS_append = update-rc.d-native
-ALTERNATIVE_PRIORITY = 90
-ALTERNATIVE_${PN} = functions
+PACKAGES =+ ${PN}-functions
+RDEPENDS_${PN} = ${PN}-functions
+FILES_${PN}-functions = ${sysconfdir}/init.d/functions*
+
+ALTERNATIVE_PRIORITY_${PN}-functions = 90
+ALTERNATIVE_${PN}-functions = functions
ALTERNATIVE_LINK_NAME[functions] = ${sysconfdir}/init.d/functions
HALTARGS ?= -d -f
___
Openembedded-commits mailing list
openembedded-comm...@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-commits
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-commits] Chen Qi : Add missing RDEPENDS of initscripts-functions
On 01/09/2014 10:49 PM, Martin Jansa wrote:
On Mon, Jan 06, 2014 at 10:15:11PM +, g...@git.openembedded.org wrote:
Module: openembedded-core.git
Branch: master
Commit: 6690c12cb1977f6bf93f3eb6d471dbd7db81bf28
URL:
http://git.openembedded.org/?p=openembedded-core.gita=commit;h=6690c12cb1977f6bf93f3eb6d471dbd7db81bf28
Author: Chen Qi qi.c...@windriver.com
Date: Mon Jan 6 15:27:35 2014 +0800
Add missing RDEPENDS of initscripts-functions
Now that the initscripts-functions has been packaged separately,
packages which may use the functions script should have a runtime
dependency on it.
Do really all these recipes need initscripts-functions e.g. when
building image with systemd?
Agree.
I think I should take into consideration whether the package has systemd
service file or not.
If the package has a service, its init script would be deleted anyway,
so it has no dependency on initscript-functions.
I'll send out a follow-up patch to fix this, together with other systemd
related patches.
Best Regards,
Chen Qi
I have initscripts in blacklist for long time (since switching to
systemd) and now it tries to bring initscripts-functions from it.
Signed-off-by: Chen Qi qi.c...@windriver.com
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
meta/recipes-bsp/alsa-state/alsa-state.bb | 2 +-
meta/recipes-bsp/apmd/apmd_3.2.2-14.bb| 1 +
meta/recipes-connectivity/irda-utils/irda-utils_0.9.18.bb | 2 ++
meta/recipes-connectivity/nfs-utils/nfs-utils_1.2.9.bb| 4 ++--
meta/recipes-connectivity/openssh/openssh_6.4p1.bb| 2 +-
meta/recipes-connectivity/ppp/ppp_2.4.5.bb| 1 +
meta/recipes-core/dbus/dbus.inc | 2 +-
meta/recipes-core/systemd/systemd_208.bb | 2 +-
meta/recipes-core/sysvinit/sysvinit_2.88dsf.bb| 2 +-
meta/recipes-devtools/distcc/distcc_3.1.bb| 1 +
meta/recipes-devtools/tcf-agent/tcf-agent_git.bb | 2 +-
meta/recipes-extended/at/at_3.1.14.bb | 3 +--
meta/recipes-extended/cronie/cronie_1.4.11.bb | 2 ++
meta/recipes-extended/rpcbind/rpcbind_0.2.1.bb| 2 ++
meta/recipes-extended/sysklogd/sysklogd.inc | 2 ++
meta/recipes-extended/xinetd/xinetd_2.3.15.bb | 1 +
meta/recipes-kernel/oprofile/oprofileui-server_git.bb | 2 +-
17 files changed, 22 insertions(+), 11 deletions(-)
diff --git a/meta/recipes-bsp/alsa-state/alsa-state.bb
b/meta/recipes-bsp/alsa-state/alsa-state.bb
index 552fcfc..4be74aa 100644
--- a/meta/recipes-bsp/alsa-state/alsa-state.bb
+++ b/meta/recipes-bsp/alsa-state/alsa-state.bb
@@ -37,7 +37,7 @@ PACKAGES += alsa-states
RRECOMMENDS_alsa-state = alsa-states
-RDEPENDS_${PN} = alsa-utils-alsactl
+RDEPENDS_${PN} = alsa-utils-alsactl initscripts-functions
FILES_${PN} = ${sysconfdir}/init.d ${sysconfdir}/asound.conf
CONFFILES_${PN} = ${sysconfdir}/asound.conf
diff --git a/meta/recipes-bsp/apmd/apmd_3.2.2-14.bb b/meta/recipes-bsp/apmd/apmd_3.2.2-14.bb
index 8c4b75e..d5ddc17 100644
--- a/meta/recipes-bsp/apmd/apmd_3.2.2-14.bb
+++ b/meta/recipes-bsp/apmd/apmd_3.2.2-14.bb
@@ -8,6 +8,7 @@ LICENSE = GPLv2+
LIC_FILES_CHKSUM = file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
file://apm.h;beginline=6;endline=18;md5=7d4acc1250910a89f84ce3cc6557c4c2
DEPENDS = libtool-cross
+RDEPENDS_${PN} = initscripts-functions
PR = r2
SRC_URI = ${DEBIAN_MIRROR}/main/a/apmd/apmd_3.2.2.orig.tar.gz;name=tarball \
diff --git a/meta/recipes-connectivity/irda-utils/irda-utils_0.9.18.bb
b/meta/recipes-connectivity/irda-utils/irda-utils_0.9.18.bb
index 7f216ac..59c9b6a 100644
--- a/meta/recipes-connectivity/irda-utils/irda-utils_0.9.18.bb
+++ b/meta/recipes-connectivity/irda-utils/irda-utils_0.9.18.bb
@@ -24,6 +24,8 @@ inherit autotools update-rc.d
INITSCRIPT_NAME = irattach
INITSCRIPT_PARAMS = defaults 20
+RDEPENDS_${PN} += initscripts-functions
+
do_compile () {
oe_runmake -e -C irattach
oe_runmake -e -C irdaping
diff --git a/meta/recipes-connectivity/nfs-utils/nfs-utils_1.2.9.bb
b/meta/recipes-connectivity/nfs-utils/nfs-utils_1.2.9.bb
index 45eacd9..fd44ea1 100644
--- a/meta/recipes-connectivity/nfs-utils/nfs-utils_1.2.9.bb
+++ b/meta/recipes-connectivity/nfs-utils/nfs-utils_1.2.9.bb
@@ -9,8 +9,8 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=95f3a93a5c3c7888de623b46ea085a84
# util-linux for libblkid
DEPENDS = libcap libnfsidmap libevent util-linux sqlite3
-RDEPENDS_${PN}-client = rpcbind bash
-RDEPENDS_${PN} = ${PN}-client bash
+RDEPENDS_${PN}-client = rpcbind bash initscripts-functions
+RDEPENDS_${PN} = ${PN}-client bash initscripts-functions
RRECOMMENDS_${PN} = kernel-module-nfsd
inherit useradd
diff --git a/meta/recipes-connectivity/openssh/openssh_6.4p1.bb
b/meta/recipes-connectivity/openssh/openssh_6.4p1.bb
index 4f8d70a..c61d16f 100644
---
Re: [OE-core] bug scrub - RFC
On 01/09/2014 10:07 AM, Trevor Woerner wrote: On 01/09/14 05:56, Jack Mitchell wrote: On 08/01/14 23:20, Trevor Woerner wrote: questions: 1) Currently it has been suggested this should be a 2-day event, should these two days be during the week or over a weekend? In either case, which 2 days? If it's two days long then why don't you do the best of both worlds and have a Friday/Saturday or Sunday/Monday combination? I was thinking of doing it either fully during the week, or fully on a weekend since my feeling is that most people either work with OE/Yocto during the weekdays or on the weekend. There's nothing to say we couldn't run this bug scrub during the week, then run a second bug scrub 2 months from now on a weekend (or visa versa). I'd suggest starting with a one day thing on a weekday so we can try and get a critical mass of people in place over a shorter period. We can always change things around based on how this works. 2) Since this is an OE event, should it focus only on OE bugs[2], or should it be generalized for any bug? I don't think we should be limiting people to what they can work on while participating. Since this is an OE TSC event I didn't want any hard feelings ;-) I also thought that maybe it would be easier to get people interested if this bug scrub was targeted at a specific project. I thought there's a chance it might help get people interested if we said let's have a bug event where we target these 30 bugs instead of saying there are 1000's of bugs in the bugzilla, pick one and try to do something about it. Can someone make a bugzilla query that lists bugs that are good candidates for a bug scrub. Ideally, things that are easy to resolve so we can beat the numbers down, Philip 4) It would be cool to be able to provide incentives to help people get interested and contributing to knocking some bugs around. So if anyone (*cough* Intel) has any neat hardware (*cough* Galileo, Edison) they could offer as an incentive (or, conversely, if there's a board you'd like to see Yocto target) please see about making that happen. A unified effort towards a new trendy board would be a fun goal, but I worry that hardware teething issues would then eat up run of the mill bug fixing time, handouts for participation however, (bug fixed/reviewed by/tested by) would be a great idea. Sorry, yes, this is what I meant. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] unmaintained layers
On 10 January 2014 06:54, Bruce Ashfield bruce.ashfi...@gmail.com wrote: On Thu, Jan 9, 2014 at 6:20 PM, Trevor Woerner trevor.woer...@linaro.org wrote: On 01/09/14 17:43, Mark Hatle wrote: On 1/9/14, 3:45 PM, Bruce Ashfield wrote: On Thu, Jan 9, 2014 at 1:45 PM, Trevor Woerner trevor.woer...@linaro.org wrote: Hi everyone, At the last TSC meeting the topic of unmaintained layers came up. Here is the sorted list of master layers from the layer index [1], would it be possible for those in the know to indicate which layers are, or are suspected of being, unmaintained? Wouldn't it be easier to do an initial sort based on commit activity ? Versus an opt-in query ? I agree.. see below for mine.. To be honest, I had asked people to indicate which layers they thought were *un*maintained (since I assumed that list would be small), but this way works too. I maintain meta-games, though I have only very little time to give it - not much activity to add new games, just keeping existing things working. That's to say that I would consider passing main maintainership, and keeping working only on my own games myself, to someone more active if someone steps up. - ML ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] unmaintained layers
On Thu, Jan 9, 2014 at 7:45 PM, Trevor Woerner trevor.woer...@linaro.org wrote: Hi everyone, At the last TSC meeting the topic of unmaintained layers came up. Here is the sorted list of master layers from the layer index [1], would it be possible for those in the know to indicate which layers are, or are suspected of being, unmaintained? ... meta-gumstix-community maintained ... meta-xfce maintained ... Andreas ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] unmaintained layers
On Thu, Jan 9, 2014 at 6:20 PM, Trevor Woerner trevor.woer...@linaro.org wrote: On 01/09/14 17:43, Mark Hatle wrote: On 1/9/14, 3:45 PM, Bruce Ashfield wrote: On Thu, Jan 9, 2014 at 1:45 PM, Trevor Woerner trevor.woer...@linaro.org wrote: Hi everyone, At the last TSC meeting the topic of unmaintained layers came up. Here is the sorted list of master layers from the layer index [1], would it be possible for those in the know to indicate which layers are, or are suspected of being, unmaintained? Wouldn't it be easier to do an initial sort based on commit activity ? Versus an opt-in query ? I agree.. see below for mine.. To be honest, I had asked people to indicate which layers they thought were *un*maintained (since I assumed that list would be small), but this way works too. It's always easier to get answers to a question when presented with a clear statement (like sending a patch, or a small list in the case), since it is something that people can quickly scan and react to (Hey, they think my layer is unmaintained!). But agreed, either way works (say if they are maintained or not) and you'll get the information, I just suspect you'll get it more quickly with a list that makes a clear statement and throws things into initial buckets on their behalf. Cheers, Bruce Interestingly enough, had I sorted the list on commit activity, according to http://git.yoctoproject.org/cgit/cgit.cgi/?s=idle meta-realtime hasn't been touched in 10 months which would make me suspect it was abandoned. ___ 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] unmaintained layers
On Thu, Jan 9, 2014 at 6:35 PM, Martin Jansa martin.ja...@gmail.com wrote: On Thu, Jan 09, 2014 at 04:45:38PM -0500, Bruce Ashfield wrote: On Thu, Jan 9, 2014 at 1:45 PM, Trevor Woerner trevor.woer...@linaro.org wrote: Hi everyone, At the last TSC meeting the topic of unmaintained layers came up. Here is the sorted list of master layers from the layer index [1], would it be possible for those in the know to indicate which layers are, or are suspected of being, unmaintained? Wouldn't it be easier to do an initial sort based on commit activity ? Versus an opt-in query ? Some BSPs are valid for very long time without any commit in it. So I think it will show a lot of false-possitives. Just false suspicions :) Bruce meta-aarch64 meta-acer meta-ada meta-android meta-angstrom meta-arago-distro meta-arago-extras meta-asus meta-aurora meta-baryon meta-beagleboard meta-beagleboard-extras meta-browser meta-bug meta-buglabs meta-chicken meta-chiefriver meta-clutter meta-crownbay meta-crystalforest meta-cubox meta-darwin meta-eca meta-efikamx meta-efl meta-eldk meta-emenlow meta-erlang meta-ettus meta-filesystems meta-fri2 meta-fsl-arm meta-fsl-arm-extra meta-fsl-demos meta-fsl-ppc meta-fso meta-games meta-geeksphone meta-gir meta-gnome meta-gpe meta-gstreamer10 meta-guacamayo meta-gumstix meta-gumstix-community meta-gumstix-extras meta-hamradio meta-handheld meta-hipos meta-htc meta-igep meta-initramfs meta-intel meta-ivi meta-jasperforest meta-java meta-kde meta-kernel-dev maintained. meta-kirkwood meta-linaro meta-linaro-toolchain meta-lsi meta-lxcbench meta-measured meta-mentor meta-micro meta-mingw meta-minnow meta-mono meta-multimedia meta-n450 meta-netbookpro meta-netmodule meta-networking meta-nokia meta-nslu2 meta-nuc meta-oe meta-openmoko meta-openpandora meta-openstack meta-openstack-compute-deploy meta-openstack-controller-deploy meta-openstack-qemu All openstack layers are maintained. meta-opie meta-oracle-java meta-osmocombb meta-ouya meta-palm meta-perl meta-picosam9 meta-qt3 meta-qt5 meta-raspberrypi meta-realtime mantained meta-ro-rootfs meta-romley meta-ros meta-ruby meta-samsung meta-sdr meta-security meta-selinux meta-shr meta-shr-distro meta-slugos meta-smalltalk meta-sourcery meta-sugarbay meta-sunxi meta-sys940x meta-systemd meta-telephony meta-telldus meta-ti meta-tlk meta-tracing meta-virtualization maintained But I can't say if I didn't miss something I maintain in the list, since it is long and I scanned it quickly. Bruce meta-web-kiosk meta-webos meta-webos-ports meta-webserver meta-woce meta-x10 meta-xfce meta-xilinx meta-xilinx-community meta-yassl meta-yocto meta-yocto-bsp meta-zynq meta-zynq-milo openembedded-core toolchain-layer Thank you for your input, and best regards, Trevor [1] http://layers.openembedded.org/layerindex/branch/master/layers/ ___ 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 -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com -- 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] [dora][PATCH 0/2] Dora backports
Hi Martin, Thanks, please see my comments in line. On 01/06/2014 06:21 PM, Martin Jansa wrote: The following changes since commit e86622a932bbd0acdea67ecfb15c8b06c27353d8: libsoup-2.4: add intltool-native to DEPENDS (2013-12-19 14:59:47 +) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib jansa/dora-backports2 http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=jansa/dora-backports2 Martin Jansa (1): ltp: set PREFERRED_PROVIDER and rename runtests_noltp.sh script I will take this. Richard Purdie (1): eglibc-initial.inc: Drop duplicate include It seems that this is a trivial fix, I don't think it's a good idea to merge it to dora. // Robert meta/conf/distro/include/default-providers.inc | 2 + meta/recipes-core/eglibc/eglibc-initial.inc| 2 - ...tests_noltp.sh-script-so-have-unique-name.patch | 202 + meta/recipes-extended/ltp/ltp_20130503.bb | 4 +- 4 files changed, 207 insertions(+), 3 deletions(-) create mode 100644 meta/recipes-extended/ltp/ltp/0001-Rename-runtests_noltp.sh-script-so-have-unique-name.patch ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] unmaintained layers
-Original Message- From: openembedded-core-boun...@lists.openembedded.org [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Trevor Woerner Sent: Friday, January 10, 2014 4:45 AM To: openembedded-core Subject: [OE-core] unmaintained layers Hi everyone, At the last TSC meeting the topic of unmaintained layers came up. Here is the sorted list of master layers from the layer index [1], would it be possible for those in the know to indicate which layers are, or are suspected of being, unmaintained? ... meta-xilinx Maintained. Regards, Nathan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] unmaintained layers
On 9 January 2014 20:45, Trevor Woerner trevor.woer...@linaro.org wrote: Hi everyone, At the last TSC meeting the topic of unmaintained layers came up. Here is the sorted list of master layers from the layer index [1], would it be possible for those in the know to indicate which layers are, or are suspected of being, unmaintained? meta-aarch64 maintained. meta-acer meta-ada meta-android meta-angstrom meta-arago-distro meta-arago-extras meta-asus meta-aurora meta-baryon meta-beagleboard meta-beagleboard-extras meta-browser meta-bug meta-buglabs meta-chicken meta-chiefriver meta-clutter meta-crownbay meta-crystalforest meta-cubox meta-darwin meta-eca meta-efikamx meta-efl meta-eldk meta-emenlow meta-erlang meta-ettus meta-filesystems meta-fri2 meta-fsl-arm meta-fsl-arm-extra meta-fsl-demos meta-fsl-ppc meta-fso meta-games meta-geeksphone meta-gir meta-gnome meta-gpe meta-gstreamer10 meta-guacamayo meta-gumstix meta-gumstix-community meta-gumstix-extras meta-hamradio meta-handheld meta-hipos meta-htc meta-igep meta-initramfs meta-intel meta-ivi meta-jasperforest meta-java meta-kde meta-kernel-dev meta-kirkwood meta-linaro meta-linaro-toolchain both maintained. meta-lsi meta-lxcbench meta-measured meta-mentor meta-micro meta-mingw meta-minnow meta-mono meta-multimedia meta-n450 meta-netbookpro meta-netmodule meta-networking meta-nokia meta-nslu2 meta-nuc meta-oe meta-openmoko meta-openpandora meta-openstack meta-openstack-compute-deploy meta-openstack-controller-deploy meta-openstack-qemu meta-opie meta-oracle-java meta-osmocombb meta-ouya meta-palm meta-perl meta-picosam9 meta-qt3 meta-qt5 meta-raspberrypi meta-realtime meta-ro-rootfs meta-romley meta-ros meta-ruby meta-samsung meta-sdr meta-security meta-selinux meta-shr meta-shr-distro meta-slugos meta-smalltalk meta-sourcery meta-sugarbay meta-sunxi meta-sys940x meta-systemd meta-telephony meta-telldus meta-ti meta-tlk meta-tracing meta-virtualization meta-web-kiosk meta-webos meta-webos-ports meta-webserver meta-woce meta-x10 meta-xfce meta-xilinx meta-xilinx-community meta-yassl meta-yocto meta-yocto-bsp meta-zynq meta-zynq-milo openembedded-core toolchain-layer Thank you for your input, and best regards, Trevor [1] http://layers.openembedded.org/layerindex/branch/master/layers/ ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core Cheers, Fathi ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] unmaintained layers
Hi Trevor, On 01/09/2014 07:45 PM, Trevor Woerner wrote: Hi everyone, At the last TSC meeting the topic of unmaintained layers came up. Here is the sorted list of master layers from the layer index [1], would it be possible for those in the know to indicate which layers are, or are suspected of being, unmaintained? meta-ros is maintained. Lukas ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] systemd-compat-units: do not mask available services
Do also check systemd_unitdir/system/ for available unit files.
This was hiding dnsmasq.service for us, as /etc/systemd/system has
priority over systemd_unitdir/system...
Signed-off-by: Anders Darander and...@chargestorm.se
---
meta/recipes-core/systemd/systemd-compat-units.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-core/systemd/systemd-compat-units.bb
b/meta/recipes-core/systemd/systemd-compat-units.bb
index 9f28283..e32ad79 100644
--- a/meta/recipes-core/systemd/systemd-compat-units.bb
+++ b/meta/recipes-core/systemd/systemd-compat-units.bb
@@ -42,7 +42,7 @@ pkg_postinst_${PN} () {
fi
for i in ${SYSTEMD_DISABLED_SYSV_SERVICES} ; do
- if [ \( -e $i -o $i.sh \) -a ! -e
$D${sysconfdir}/systemd/system/$i.service ] ; then
+ if [ \( -e $i -o $i.sh \) -a ! \( -e
$D${sysconfdir}/systemd/system/$i.service -o -e
$D${systemd_unitdir}/system/$i.service \) ] ; then
echo -n $i: ; systemctl ${OPTS} mask $i.service
fi
done ; echo
--
1.8.5.2
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] systemd-compat-units: do not mask real service files
systemd-compat-units might mask existing service files. This occuress if real service files mentioned in SYSTEMD_DISABLED_SYSV_SERVICES exists in systemd_unitdir/system instead of /etc/systemd/system. This was discovered when adding dnsmasq to our dora-based builds. The fix itself is ported to master. The following changes since commit 1028ac813fa9803ebfff6bcfa7f8b67012609b27: sstate: add do_package to the noexec list in setscene_depvalid (2014-01-07 13:58:28 +) are available in the git repository at: git://github.com/darander/oe-core systemd-compat-units https://github.com/darander/oe-core/tree/systemd-compat-units Anders Darander (1): systemd-compat-units: do not mask available services meta/recipes-core/systemd/systemd-compat-units.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 1.8.5.2 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] unmaintained layers
On 01/10/2014 02:45 AM, Trevor Woerner wrote: Hi everyone, At the last TSC meeting the topic of unmaintained layers came up. Here is the sorted list of master layers from the layer index [1], would it be possible for those in the know to indicate which layers are, or are suspected of being, unmaintained? meta-filesystems Maintained meta-perl Maintained //Hongxu [1] http://layers.openembedded.org/layerindex/branch/master/layers/ ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] pulseaudio: rescale input being passed to float method of speex
def get_speex_fpu_setting(bb, d):
if bb.data.getVar('TARGET_FPU', d, 1) in [ 'soft' ]:
return --enable-fixed-point --disable-float-api --disable-vbr
return
If we are using Pulseaudio with default settings (speex-float-1) and
the if condition in above method is evaluated true, we will end up facing
the original issue: streams that need to be resampled are not playedback
since input to speex is zeroed out when float input passed by Pulseaudio
in range of +/-1 is converted to int.
So isn't Case 2 appropriate, thoughts?
Regards,
Fahad
From: Koen Kooi [k...@dominion.thruhere.net]
Sent: Tuesday, January 07, 2014 3:22 PM
To: Arslan, Fahad
Cc: Saul Wold; openembedded-core@lists.openembedded.org; mar...@juszkiewicz.pl
Subject: Re: [OE-core] [PATCH] pulseaudio: rescale input being passed to float
method of speex
Marcins linaro mail address has expired, adding the other one
Op 7 jan. 2014, om 11:03 heeft Koen Kooi k...@dominion.thruhere.net het
volgende geschreven:
Op 7 jan. 2014, om 10:59 heeft Arslan, Fahad fahad_ars...@mentor.com het
volgende geschreven:
What affect does it have on the overall size of speex
If we enable floating point support, there is decrease in size of libs.
libspeexdsp.so is ~480 KB in fixed point configuration
libspeexdsp.so is ~220 KB in floating point configuration
Further details are shown below:
Case-1 (current configuration)
==
EXTRA_OECONF = --enable-fixed-point --with-ogg-libraries=${STAGING_LIBDIR}
\
--disable-float-api --disable-vbr \
--with-ogg-includes=${STAGING_INCDIR} --disable-oggtest
build$
build$ ls -l src/.libs/speex*
-rwxr-xr-x 1 farslan farslan 75112 Jan 7 14:09 src/.libs/speexdec
-rwxr-xr-x 1 farslan farslan 76989 Jan 7 14:09 src/.libs/speexenc
build$ file src/.libs/speex*
src/.libs/speexdec: ELF 32-bit LSB executable, ARM, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.16, not stripped
src/.libs/speexenc: ELF 32-bit LSB executable, ARM, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.16, not stripped
build$
build$
build$ ls -l libspeex/.libs/libspeex*.so.1.5.0
-rwxr-xr-x 1 farslan farslan 484940 Jan 7 14:09
libspeex/.libs/libspeexdsp.so.1.5.0
-rwxr-xr-x 1 farslan farslan 370309 Jan 7 14:09
libspeex/.libs/libspeex.so.1.5.0
build$
build$ file libspeex/.libs/libspeex*.so.1.5.0
libspeex/.libs/libspeexdsp.so.1.5.0: ELF 32-bit LSB shared object, ARM,
version 1 (SYSV), dynamically linked, not stripped
libspeex/.libs/libspeex.so.1.5.0:ELF 32-bit LSB shared object, ARM,
version 1 (SYSV), dynamically linked, not stripped
build$
Case-2 (suggested configuration)
==
EXTRA_OECONF = --with-ogg-libraries=${STAGING_LIBDIR} \
--enable-float-api --disable-vbr \
--with-ogg-includes=${STAGING_INCDIR} --disable-oggtest
Or case 3, which I implemented 3 years ago in
https://github.com/openembedded/openembedded/commit/e06553979d23531397af3dd71870abb80718c681
:
def get_speex_fpu_setting(bb, d):
if bb.data.getVar('TARGET_FPU', d, 1) in [ 'soft' ]:
return --enable-fixed-point --disable-float-api --disable-vbr
return
EXTRA_OECONF += ${@get_speex_fpu_setting(bb, d)}
That OE-classic recipe also has support for arm asm which speed things up a
lot.
regards,
Koen
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
