Re: [OE-core] Moving oe-core GNOME recipes over to meta-gnome
Koen, I have checked the build log, following should be in the keep list: gconf-dbus gnome-common gnome-desktop gnome-doc-utils gnome-keyring gnome-mime-data gnome-vfs libgnome-keyring Thanks, edwin Koen Kooi wrote: Op 9 jun 2011, om 12:50 heeft Koen Kooi het volgende geschreven: Hi, There are a number of non-sato GNOME recipes still in oe-core that should be moved over to meta-gnome. Metacity is one of those. Could the yocto people please draw up a list of the recipes they want to keep in oe-core and I will send patches to remove the others. Any movement on this? ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] distro_tracking_field: update recipe maintainer
reassign Qing's recipe to other team member Signed-off-by: Yu Ke ke...@intel.com --- .../conf/distro/include/distro_tracking_fields.inc | 111 ++-- 1 files changed, 55 insertions(+), 56 deletions(-) diff --git a/meta/conf/distro/include/distro_tracking_fields.inc b/meta/conf/distro/include/distro_tracking_fields.inc index f4aa1ea..8318e5f 100644 --- a/meta/conf/distro/include/distro_tracking_fields.inc +++ b/meta/conf/distro/include/distro_tracking_fields.inc @@ -1,7 +1,7 @@ RECIPE_STATUS_pn-diffutils = green RECIPE_LATEST_VERSION_pn-diffutils = 3.0 RECIPE_LAST_UPDATE_pn-diffutils = Dec 10, 2010 -RECIPE_MAINTAINER_pn-diffutils = Qing He qing...@intel.com +RECIPE_MAINTAINER_pn-diffutils = Mei Lei lei@intel.com RECIPE_STATUS_pn-epdfview = red RECIPE_LATEST_VERSION_pn-epdfview = check @@ -223,7 +223,7 @@ RECIPE_LATEST_VERSION_pn-dbus = 1.4.1 RECIPE_INTEL_SECTION_pn-dbus = base libs RECIPE_LATEST_RELEASE_DATE_pn-dbus = 12/2010 RECIPE_LAST_UPDATE_pn-dbus = Jan 20, 2011 -RECIPE_MAINTAINER_pn-dbus = Qing He qing...@intel.com +RECIPE_MAINTAINER_pn-dbus = Dongxiao Xu dongxiao...@intel.com RECIPE_STATUS_pn-dbus-glib = green RECIPE_DEPENDENCY_CHECK_pn-dbus-glib = not done @@ -325,7 +325,7 @@ RECIPE_MAINTAINER_pn-libtirpc = Dongxiao Xu dongxiao...@intel.com RECIPE_STATUS_pn-gdbm = green RECIPE_LAST_UPDATE_pn-gdbm = Jul 21, 2006 -RECIPE_MAINTAINER_pn-gdbm = Qing He qing...@intel.com +RECIPE_MAINTAINER_pn-gdbm = Yu Ke ke...@intel.com RECIPE_LATEST_VERSION_pn-gdbm = 1.8.3 RECIPE_INTEL_SECTION_pn-gdbm = base libs RECIPE_LATEST_RELEASE_DATE_pn-gdbm = 10/2002 @@ -339,7 +339,6 @@ RECIPE_LATEST_RELEASE_DATE_pn-pth = 06/2006 RECIPE_STATUS_pn-python-pycurl = yellow # several exports to work with python RECIPE_LAST_UPDATE_pn-python-pycurl = Mar 25, 2010 -RECIPE_MAINTAINER_pn-python-pycurl = Qing He qing...@intel.com RECIPE_DEPENDENCY_CHECK_pn-python-pycurl = not done RECIPE_LATEST_VERSION_pn-python-pycurl = 7.19.0 RECIPE_PATCH_pn-python-pycurl+no-static-link = no static libraries @@ -426,7 +425,7 @@ RECIPE_COMMENTS_pn-libgcrypt = RECIPE_STATUS_pn-gnutls = yellow # need explict pre configure RECIPE_LAST_UPDATE_pn-gnutls = May 25, 2011 -RECIPE_MAINTAINER_pn-gnutls = Qing He qing...@intel.com +RECIPE_MAINTAINER_pn-gnutls = Yu Ke ke...@intel.com RECIPE_DEPENDENCY_CHECK_pn-gnutls = done RECIPE_LATEST_VERSION_pn-gnutls = 2.12.5 RECIPE_PATCH_pn-gnutls+gnutls-openssl = unkown @@ -439,7 +438,7 @@ RECIPE_COMMENTS_pn-gnutls = requires libtasn1, but has an internal copy RECIPE_STATUS_pn-lzo = green RECIPE_LAST_UPDATE_pn-lzo = Dec 31, 2010 -RECIPE_MAINTAINER_pn-lzo = Qing He qing...@intel.com +RECIPE_MAINTAINER_pn-lzo = Dexuan Cui dexuan@intel.com RECIPE_LATEST_VERSION_pn-lzo = 2.04 RECIPE_INTEL_SECTION_pn-lzo = base libs RECIPE_LATEST_RELEASE_DATE_pn-lzo = 10/2010 @@ -473,7 +472,7 @@ RECIPE_LATEST_RELEASE_DATE_pn-libnss-mdns = 05/2007 RECIPE_STATUS_pn-ncurses = green RECIPE_LAST_UPDATE_pn-ncurses = Dec 30, 2010 -RECIPE_MAINTAINER_pn-ncurses = Qing He qing...@intel.com +RECIPE_MAINTAINER_pn-ncurses = Saul Wold s...@linux.intel.com RECIPE_LATEST_VERSION_pn-ncurses = 5.7 RECIPE_INTEL_SECTION_pn-ncurses = base libs RECIPE_LATEST_RELEASE_DATE_pn-ncurses = 11/2008 @@ -524,7 +523,7 @@ RECIPE_COMMENTS_pn-libcap = RECIPE_STATUS_pn-libevent = green RECIPE_LAST_UPDATE_pn-libevent = Jul 7, 2010 -RECIPE_MAINTAINER_pn-libevent = Qing He qing...@intel.com +RECIPE_MAINTAINER_pn-libevent = Scott Garman scott.a.gar...@intel.com RECIPE_NO_UPDATE_REASON_pn-libevent=libevent 2 is incompatible RECIPE_LATEST_VERSION_pn-libevent = 2.0.11 RECIPE_INTEL_SECTION_pn-libevent = base libs @@ -533,7 +532,7 @@ RECIPE_MANUAL_CHECK_DATE_pn-libevent = May 24, 2011 RECIPE_STATUS_pn-libnfsidmap = green RECIPE_LAST_UPDATE_pn-libnfsidmap = Jan 20, 2011 -RECIPE_MAINTAINER_pn-libnfsidmap = Qing He qing...@intel.com +RECIPE_MAINTAINER_pn-libnfsidmap = Scott Garman scott.a.gar...@intel.com RECIPE_LATEST_VERSION_pn-libnfsidmap = 0.24 RECIPE_INTEL_SECTION_pn-libnfsidmap = base libs RECIPE_LATEST_RELEASE_DATE_pn-libnfsidmap = 12/2010 @@ -579,7 +578,7 @@ DISTRO_PN_ALIAS_pn-libcheck = Ubuntu=check Fedora=check OpenSuSE=check RECIPE_STATUS_pn-augeas = green RECIPE_DEPENDENCY_CHECK_pn-augeas = done RECIPE_LAST_UPDATE_pn-augeas = Aug 20, 2010 -RECIPE_MAINTAINER_pn-augeas = Qing He qing...@intel.com +RECIPE_MAINTAINER_pn-augeas = Saul Wold s...@linux.intel.com RECIPE_LATEST_VERSION_pn-augeas = 0.7.3 RECIPE_INTEL_SECTION_pn-augeas = base libs RECIPE_TIME_BETWEEN_LAST_TWO_RELEASES_pn-augeas = 1 month @@ -594,12 +593,12 @@ RECIPE_INTEL_SECTION_pn-sat-solver = base libs DISTRO_PN_ALIAS_pn-sat-solver = OSPDT OpenSuSE=satsolver-tools RECIPE_COMMENTS_pn-sat-solver = RECIPE_LAST_UPDATE_pn-sat-solver = Aug 20, 2010 -RECIPE_MAINTAINER_pn-sat-solver = Qing He qing...@intel.com +RECIPE_MAINTAINER_pn-sat-solver = Mark Hatle mark.ha...@windriver.com RECIPE_STATUS_pn-libzypp = green
[OE-core] Architecture mismatch QA check not fatal?
Hi, I was building qt this weekend and I noticed this one: WARNING: QA Issue: Architecture did not match (40 to 62) on /work/armv7a-angstrom-linux-gnueabi/qt4-embedded-4.7.3-r26.1/packages-split/qt4-embedded-tools/usr/bin/moc WARNING: QA Issue: Architecture did not match (40 to 62) on /work/armv7a-angstrom-linux-gnueabi/qt4-embedded-4.7.3-r26.1/packages-split/qt4-embedded-tools/usr/bin/uic WARNING: QA Issue: Architecture did not match (40 to 62) on /work/armv7a-angstrom-linux-gnueabi/qt4-embedded-4.7.3-r26.1/packages-split/qt4-embedded-tools/usr/bin/rcc Shouldn't that be a fatal error, shipping x86 binaries in arm packages? regards, Koen ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] glib-2.0 2.28.x: update to 2.28.8
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
...003-gatomic-proper-pointer-get-cast.patch.patch | 28
.../0005-glib-mkenums-interpreter.patch.patch | 25 +
meta/recipes-core/glib-2.0/glib-2.0_2.28.6.bb | 18
meta/recipes-core/glib-2.0/glib-2.0_2.28.8.bb | 22 +++
meta/recipes-core/glib-2.0/glib.inc|3 +-
5 files changed, 77 insertions(+), 19 deletions(-)
create mode 100644
meta/recipes-core/glib-2.0/glib-2.0/0003-gatomic-proper-pointer-get-cast.patch.patch
create mode 100644
meta/recipes-core/glib-2.0/glib-2.0/0005-glib-mkenums-interpreter.patch.patch
delete mode 100644 meta/recipes-core/glib-2.0/glib-2.0_2.28.6.bb
create mode 100644 meta/recipes-core/glib-2.0/glib-2.0_2.28.8.bb
diff --git
a/meta/recipes-core/glib-2.0/glib-2.0/0003-gatomic-proper-pointer-get-cast.patch.patch
b/meta/recipes-core/glib-2.0/glib-2.0/0003-gatomic-proper-pointer-get-cast.patch.patch
new file mode 100644
index 000..ad1ca12
--- /dev/null
+++
b/meta/recipes-core/glib-2.0/glib-2.0/0003-gatomic-proper-pointer-get-cast.patch.patch
@@ -0,0 +1,28 @@
+From 3d371334d5668bcd02a38ff99884bd343c244d68 Mon Sep 17 00:00:00 2001
+From: Koen Kooi k...@dominion.thruhere.net
+Date: Sat, 18 Jun 2011 23:51:35 +0200
+Subject: [PATCH 3/7] gatomic-proper-pointer-get-cast.patch
+
+Upstream-Status: Unknown
+
+Signed-off-by: Koen Kooi k...@dominion.thruhere.net
+---
+ glib/gatomic.h |2 +-
+ 1 files changed, 1 insertions(+), 1 deletions(-)
+
+diff --git a/glib/gatomic.h b/glib/gatomic.h
+index ddd39b8..b758142 100644
+--- a/glib/gatomic.h
b/glib/gatomic.h
+@@ -70,7 +70,7 @@ void g_atomic_pointer_set (volatile
gpointer G_GNUC_MAY_ALI
+ (g_atomic_int_set) ((volatile gint G_GNUC_MAY_ALIAS *) (volatile void *)
(atomic), (newval)))
+ # define g_atomic_pointer_get(atomic) \
+ ((void) sizeof (gchar [sizeof (*(atomic)) == sizeof (gpointer) ? 1 : -1]), \
+- (g_atomic_pointer_get) ((volatile gpointer G_GNUC_MAY_ALIAS *) (volatile
void *) (atomic)))
++ (g_atomic_pointer_get) ((volatile gpointer G_GNUC_MAY_ALIAS *) (volatile
void G_GNUC_MAY_ALIAS *) (atomic)))
+ # define g_atomic_pointer_set(atomic, newval) \
+ ((void) sizeof (gchar [sizeof (*(atomic)) == sizeof (gpointer) ? 1 : -1]), \
+ (g_atomic_pointer_set) ((volatile gpointer G_GNUC_MAY_ALIAS *) (volatile
void *) (atomic), (newval)))
+--
+1.6.6.1
+
diff --git
a/meta/recipes-core/glib-2.0/glib-2.0/0005-glib-mkenums-interpreter.patch.patch
b/meta/recipes-core/glib-2.0/glib-2.0/0005-glib-mkenums-interpreter.patch.patch
new file mode 100644
index 000..6780330
--- /dev/null
+++
b/meta/recipes-core/glib-2.0/glib-2.0/0005-glib-mkenums-interpreter.patch.patch
@@ -0,0 +1,25 @@
+From a8e5c4a808e7f8572bd5023645a6cb4386b9aff8 Mon Sep 17 00:00:00 2001
+From: Koen Kooi k...@dominion.thruhere.net
+Date: Sat, 18 Jun 2011 23:52:17 +0200
+Subject: [PATCH 5/7] don't leak buildpaths into perl hashbang
+
+Upstream-Status: Unknown
+
+Signed-off-by: Koen Kooi k...@dominion.thruhere.net
+---
+ gobject/glib-mkenums.in |2 +-
+ 1 files changed, 1 insertions(+), 1 deletions(-)
+
+diff --git a/gobject/glib-mkenums.in b/gobject/glib-mkenums.in
+index 6372245..b486fe9 100755
+--- a/gobject/glib-mkenums.in
b/gobject/glib-mkenums.in
+@@ -1,4 +1,4 @@
+-#! @PERL_PATH@
++#! /usr/bin/env perl
+
+ use warnings;
+ use File::Basename;
+--
+1.6.6.1
+
diff --git a/meta/recipes-core/glib-2.0/glib-2.0_2.28.6.bb
b/meta/recipes-core/glib-2.0/glib-2.0_2.28.6.bb
deleted file mode 100644
index ca5f4c8..000
--- a/meta/recipes-core/glib-2.0/glib-2.0_2.28.6.bb
+++ /dev/null
@@ -1,18 +0,0 @@
-require glib.inc
-
-PE = 1
-PR = r1
-
-SRC_URI = ${GNOME_MIRROR}/glib/2.28/glib-${PV}.tar.bz2 \
- file://configure-libtool.patch \
- file://60_wait-longer-for-threads-to-die.patch \
- file://g_once_init_enter.patch \
-
-# Only apply this patch for target recipe on uclibc
-SRC_URI_append_libc-uclibc = ${@['', 'file://no-iconv.patch']['${PN}' ==
'${BPN}']}
-
-SRC_URI[md5sum] = 7d8fc15ae70d5111c0cf2a79d50ef717
-SRC_URI[sha256sum] =
557fb7c39d21b9359fbac51fd6b0b883bc97a2561c0166eef993a4078312f578
-
-SRC_URI_append_virtclass-native = file://glib-gettextize-dir.patch
-BBCLASSEXTEND = native
diff --git a/meta/recipes-core/glib-2.0/glib-2.0_2.28.8.bb
b/meta/recipes-core/glib-2.0/glib-2.0_2.28.8.bb
new file mode 100644
index 000..e84aea5
--- /dev/null
+++ b/meta/recipes-core/glib-2.0/glib-2.0_2.28.8.bb
@@ -0,0 +1,22 @@
+require glib.inc
+
+PR = r1
+PE = 1
+
+SRC_URI = ${GNOME_MIRROR}/glib/2.28/glib-${PV}.tar.bz2 \
+ file://configure-libtool.patch \
+ file://60_wait-longer-for-threads-to-die.patch \
+ file://g_once_init_enter.patch \
+ file://0003-gatomic-proper-pointer-get-cast.patch.patch \
+ file://0005-glib-mkenums-interpreter.patch.patch \
+
+# Only apply this patch for target
[OE-core] [PATCH 0/1]distrodata.bbclass:Get the extend recipe's information from nonbbextended recipe
Hi Saul, This patch will fix the issue that native and nativesdk and some other extend recipes colud not get some information(like matainer information or laskchecktime). Please review it. Thanks, Lei The following changes since commit 2163461ec94528ecf046a04edc5db3d2dd3a6b8b: Tom Zanussi (1): systemtap: remove non-core COMPATIBLE_MACHINES are available in the git repository at: git://git.pokylinux.org/poky-contrib lmei3/distrodata http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=lmei3/distrodata Mei Lei (1): distrodata.bbclass: Get the extend recipe's information from non bbextended recipe meta/classes/distrodata.bbclass | 46 --- 1 files changed, 33 insertions(+), 13 deletions(-) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] distrodata.bbclass: Get the extend recipe's information from non bbextended recipe
This patch will check whether the recipe is an extened recipe, if yes, some
informaiton couldn't be got, so collect those information(like maintainer
information or lastcheckversion) from non bbextended recipe.
Signed-off-by: Mei Lei lei@intel.com
---
meta/classes/distrodata.bbclass | 46 ---
1 files changed, 33 insertions(+), 13 deletions(-)
diff --git a/meta/classes/distrodata.bbclass b/meta/classes/distrodata.bbclass
index f24cff8..e91200d 100644
--- a/meta/classes/distrodata.bbclass
+++ b/meta/classes/distrodata.bbclass
@@ -215,6 +215,7 @@ python checkpkg_eventhandler() {
addtask checkpkg
do_checkpkg[nostamp] = 1
python do_checkpkg() {
+ localdata = bb.data.createCopy(d)
import sys
import re
import tempfile
@@ -435,18 +436,38 @@ python do_checkpkg() {
generate package information from .bb file
pname = bb.data.getVar('PN', d, True)
- pdesc = bb.data.getVar('DESCRIPTION', d, True)
- pgrp = bb.data.getVar('SECTION', d, True)
- pversion = bb.data.getVar('PV', d, True)
- plicense = bb.data.getVar('LICENSE', d, True)
- psection = bb.data.getVar('SECTION', d, True)
- phome = bb.data.getVar('HOMEPAGE', d, True)
- prelease = bb.data.getVar('PR', d, True)
- ppriority = bb.data.getVar('PRIORITY', d, True)
- pdepends = bb.data.getVar('DEPENDS', d, True)
- pbugtracker = bb.data.getVar('BUGTRACKER', d, True)
- ppe = bb.data.getVar('PE', d, True)
- psrcuri = bb.data.getVar('SRC_URI', d, True)
+
+ if pname.find(-native) != -1:
+ pnstripped = pname.split(-native)
+ bb.note(Native Split: %s % pnstripped)
+ bb.data.setVar('OVERRIDES', pn- + pnstripped[0] + : +
bb.data.getVar('OVERRIDES', d, True), localdata)
+ bb.data.update_data(localdata)
+
+ if pname.find(-cross) != -1:
+ pnstripped = pname.split(-cross)
+ bb.note(cross Split: %s % pnstripped)
+ bb.data.setVar('OVERRIDES', pn- + pnstripped[0] + : +
bb.data.getVar('OVERRIDES', d, True), localdata)
+ bb.data.update_data(localdata)
+
+ if pname.find(-initial) != -1:
+ pnstripped = pname.split(-initial)
+ bb.note(initial Split: %s % pnstripped)
+ bb.data.setVar('OVERRIDES', pn- + pnstripped[0] + : +
bb.data.getVar('OVERRIDES', d, True), localdata)
+ bb.data.update_data(localdata)
+
+ pdesc = bb.data.getVar('DESCRIPTION', localdata, True)
+ pgrp = bb.data.getVar('SECTION', localdata, True)
+ pversion = bb.data.getVar('PV', localdata, True)
+ plicense = bb.data.getVar('LICENSE', localdata, True)
+ psection = bb.data.getVar('SECTION', localdata, True)
+ phome = bb.data.getVar('HOMEPAGE', localdata, True)
+ prelease = bb.data.getVar('PR', localdata, True)
+ ppriority = bb.data.getVar('PRIORITY', localdata, True)
+ pdepends = bb.data.getVar('DEPENDS', localdata, True)
+ pbugtracker = bb.data.getVar('BUGTRACKER', localdata, True)
+ ppe = bb.data.getVar('PE', localdata, True)
+ psrcuri = bb.data.getVar('SRC_URI', localdata, True)
+ maintainer = bb.data.getVar('RECIPE_MAINTAINER', localdata, True)
found = 0
for uri in src_uri.split():
@@ -616,7 +637,6 @@ python do_checkpkg() {
else:
pmstatus = UPDATE
- maintainer = bb.data.getVar('RECIPE_MAINTAINER', d, True)
psrcuri = psrcuri.split()[0]
pdepends = .join(pdepends.split(\t))
pdesc = .join(pdesc.split(\t))
--
1.6.3.3
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] 'elfutils' needed to build kernel (perf), but not listed in DEPENDS
On Mon, 2011-06-20 at 13:09 +0200, Koen Kooi wrote: Hi, I finally tracked down the heisenbug that was causing kernel builds to fail: kernel*bbclass has no DEPENDS on elfutils, but it still tries to build perf. While grepping I also stumbled accross this gem: image-swab.bbclass:PARALLEL_MAKE_pn-elfutils = Parallel make fails only when using swabber? Correct, we're still trying to work out why this only happens with swabber and whether its a real PARALLEL_MAKE issue or some kind of bad interaction with make :( Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] BUG: intltool depends on libxml-parser-perl to be installed on host
On Sun, Jun 19, 2011 at 22:28, Cui, Dexuan dexuan@intel.com wrote: And I guess you're using incremental building? Does building from scratch work? No; I got it when rebuilding from scratch. into host system to it to build. Do the DEPENDS look right? Maybe this needs the class for bringing in perl-native... It seems to do so. Are you able to reproduce it? Hi Otavio, I can't reproduce the issue. Could you please report a bug at http://bugzilla.yoctoproject.org/ so we can better track the issue? First it would be better to be able to reproduce it. (devel)~/hacking/el/openembedded-core% bitbake intltool -c cleansstate ... NOTE: Running task 1 of 2 (ID: 0, /home/otavio/hacking/el/openembedded-core/meta/recipes-devtools/intltool/intltool_0.40.6.bb, do_clean) NOTE: package intltool-0.40.6-r1: task do_clean: Started NOTE: package intltool-0.40.6-r1: task do_clean: Succeeded NOTE: Running task 2 of 2 (ID: 1, /home/otavio/hacking/el/openembedded-core/meta/recipes-devtools/intltool/intltool_0.40.6.bb, do_cleansstate) NOTE: package intltool-0.40.6-r1: task do_cleansstate: Started NOTE: package intltool-0.40.6-r1: task do_cleansstate: Succeeded NOTE: Tasks Summary: Attempted 2 tasks of which 0 didn't need to be rerun and 0 failed. bitbake intltool -c cleansstate 7.07s user 1.27s system 150% cpu 5.541 total (devel)~/hacking/el/openembedded-core% sudo apt-get remove libxml-parser-perl [sudo] password for otavio: Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be REMOVED: libxml-parser-perl 0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded. After this operation, 758 kB disk space will be freed. Do you want to continue [Y/n]? (Reading database ... 38363 files and directories currently installed.) Removing libxml-parser-perl ... Processing triggers for man-db ... I am attaching the configure log of intltool for reference. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br log.do_configure.4821 Description: Binary data ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Architecture mismatch QA check not fatal?
On 6/20/11 2:41 AM, Koen Kooi wrote: Hi, I was building qt this weekend and I noticed this one: WARNING: QA Issue: Architecture did not match (40 to 62) on /work/armv7a-angstrom-linux-gnueabi/qt4-embedded-4.7.3-r26.1/packages-split/qt4-embedded-tools/usr/bin/moc WARNING: QA Issue: Architecture did not match (40 to 62) on /work/armv7a-angstrom-linux-gnueabi/qt4-embedded-4.7.3-r26.1/packages-split/qt4-embedded-tools/usr/bin/uic WARNING: QA Issue: Architecture did not match (40 to 62) on /work/armv7a-angstrom-linux-gnueabi/qt4-embedded-4.7.3-r26.1/packages-split/qt4-embedded-tools/usr/bin/rcc Shouldn't that be a fatal error, shipping x86 binaries in arm packages? There are a couple of very minor use cases where this may be necessary. So I'm wondering if we can put in an override mechanism that tells the system to make the QA a warning instead of an error for select packages. Otherwise, yes.. this should be an error. (The minor cases are primarily firmware loaded into off-board cards in PCI chasis and such.. occasionally these firmware are ELF and of an architecture not the same as the host.. it's rare, but I have seen it before.) --Mark regards, Koen ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Architecture mismatch QA check not fatal?
On Mon, 2011-06-20 at 08:23 -0500, Mark Hatle wrote: (The minor cases are primarily firmware loaded into off-board cards in PCI chasis and such.. occasionally these firmware are ELF and of an architecture not the same as the host.. it's rare, but I have seen it before.) Shouldn't those firmware images just go in a separate package? p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Architecture mismatch QA check not fatal?
Op 20 jun 2011, om 15:29 heeft Phil Blundell het volgende geschreven: On Mon, 2011-06-20 at 08:23 -0500, Mark Hatle wrote: (The minor cases are primarily firmware loaded into off-board cards in PCI chasis and such.. occasionally these firmware are ELF and of an architecture not the same as the host.. it's rare, but I have seen it before.) Shouldn't those firmware images just go in a separate package? If we do that we can use INSANE_SKIP_firmwarepackage = True, which seems like a good solution. regards, Koen ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] OE Changelog for 2011-06-6 to 2011-06-13
On Sat, Jun 18, 2011 at 1:40 PM, Paul Eggleton paul.eggle...@linux.intel.com wrote: On Saturday 18 June 2011 18:29:48 cliff.br...@gmail.com wrote: meta-yocto: git://git.yoctoproject.org/poky ... Changelog for meta-yocto: This clearly contains more than just changes to the meta-yocto subdirectory of the poky repo. Can you please set this up to be filtered? Otherwise we're just effectively getting dupes of commits to bitbake and oe-core. Hi Paul, I'll look into filtering. Can you describe how the bitbake and oe-core directories are synchronized to content in the poky repo? Thanks, Cliff -- = http://bec-systems.com ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] OE Changelog for 2011-06-6 to 2011-06-13
On Sat, Jun 18, 2011 at 3:34 PM, Chris Larson clar...@kergoth.com wrote: Speaking of which, if we do that, might be a good idea to add bitbake itself specifically, in case any of the changes to master will impact the userbase. Done, thanks. Cliff -- = http://bec-systems.com ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Architecture mismatch QA check not fatal?
On 6/20/11 8:31 AM, Koen Kooi wrote: Op 20 jun 2011, om 15:29 heeft Phil Blundell het volgende geschreven: On Mon, 2011-06-20 at 08:23 -0500, Mark Hatle wrote: (The minor cases are primarily firmware loaded into off-board cards in PCI chasis and such.. occasionally these firmware are ELF and of an architecture not the same as the host.. it's rare, but I have seen it before.) Shouldn't those firmware images just go in a separate package? Depends on how the system is configured.. Often I see them packaged with the firmware loader -- which is the proper arch, etc.. If we do that we can use INSANE_SKIP_firmwarepackage = True, which seems like a good solution. Ya, as long as we can skip -- or change it to a warning instead of an error.. I think we're good. Like I said, this is rare and unlikely to be an issue in anything in oe-core, meta-oe or even the distributions based on oe-core.. but I have seen it in customer production environments before. --Mark regards, Koen ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] OE Changelog for 2011-06-6 to 2011-06-13
On Monday 20 June 2011 14:48:45 Cliff Brake wrote: Can you describe how the bitbake and oe-core directories are synchronized to content in the poky repo? Sure. Richard can correct me on this, but my understanding is at the moment he has a bunch of scripts that grab changes from the local clones of the source repositories as patches, which are then applied on top of the Poky repository. Richard runs these scripts periodically. Some time soon these scripts will be replaced by the combo layer tool that Ke posted last week. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Architecture mismatch QA check not fatal?
Op 20 jun 2011, om 15:55 heeft Mark Hatle het volgende geschreven: On 6/20/11 8:31 AM, Koen Kooi wrote: Op 20 jun 2011, om 15:29 heeft Phil Blundell het volgende geschreven: On Mon, 2011-06-20 at 08:23 -0500, Mark Hatle wrote: (The minor cases are primarily firmware loaded into off-board cards in PCI chasis and such.. occasionally these firmware are ELF and of an architecture not the same as the host.. it's rare, but I have seen it before.) Shouldn't those firmware images just go in a separate package? Depends on how the system is configured.. Often I see them packaged with the firmware loader -- which is the proper arch, etc.. If we do that we can use INSANE_SKIP_firmwarepackage = True, which seems like a good solution. Ya, as long as we can skip -- or change it to a warning instead of an error.. I think we're good. Like I said, this is rare and unlikely to be an issue in anything in oe-core, meta-oe or even the distributions based on oe-core.. but I have seen it in customer production environments before. We have exactly 1 xorg driver in oe .dev that triggers it :) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/1] More LICENSE cleanup and additional common-licenses
On Mon, Jun 20, 2011 at 9:00 AM, Flanagan, Elizabeth elizabeth.flana...@intel.com wrote: Khem, Yes, this should correct it from complaining about not having that license. GPL-3.0-with-GCC-exception is the correct text for GCCRUNTIMELIBRARYEXCEPTION and this patch changes the license over to that naming convention. The parser chokes on portions of fields like GCC RUNTIME LIBRARY EXCEPTION (which is what the original was in the recipe). This change makes it so that it's consistent and tells people what the license actually is. For example, there is a GCC-2.0-with-GCC-exception. This limits possible confusion and assists in license wrangling. thanks -b On Wed, Jun 15, 2011 at 4:58 PM, Khem Raj raj.k...@gmail.com wrote: On Wed, Jun 15, 2011 at 2:01 PM, Flanagan, Elizabeth elizabeth.flana...@intel.com wrote: I've added some more licenses from the SPDX project as well as corrected some text. GCC's LICENSE field was problematic and I've corrected it to the actual GPL exception license text. I've also cleaned up gdb's LICENSE field. It always wanted GCCRUNTIMELIBRARYEXCEPTION license and did not find it. I have local copy in metadata meta/files/common-licenses/GCCRUNTIMELIBRARYEXCEPTION It that fixed too ? If not then I have uploaded it here http://paste.ubuntu.com/627695/ The following changes since commit e1f6ebba3ab2fc8a469c1d96fc6d4c4b8f16845c: meta-yocto: use FILESEXTRAPATHS_prepend := in all bbappends (2011-06-15 11:49:42 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib eflanagan/license_corrections http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=eflanagan/license_corrections Beth Flanagan (1): common-licenses: Additions and corrections meta/files/common-licenses/AAL | 6 +- meta/files/common-licenses/AFL-1.2 | 123 meta/files/common-licenses/AFL-2.0 | 48 ++ meta/files/common-licenses/AFL-2.1 | 50 ++ meta/files/common-licenses/AFL-3.0 | 27 + meta/files/common-licenses/AGPL-3.0 | 3 + meta/files/common-licenses/ANTLR-PD | 32 + meta/files/common-licenses/APL-1.0 | 218 +++ meta/files/common-licenses/APSL-1.0 | 372 +++ meta/files/common-licenses/APSL-1.1 | 374 +++ meta/files/common-licenses/APSL-1.2 | 105 meta/files/common-licenses/APSL-2.0 | 102 +++ meta/files/common-licenses/Apache-1.0 | 61 ++ meta/files/common-licenses/Apache-1.1 | 60 ++ meta/files/common-licenses/Apache-2.0 | 4 +- meta/files/common-licenses/Artistic-1.0 | 50 ++ meta/files/common-licenses/Artistic-2.0 | 203 ++ meta/files/common-licenses/BSD-2-Clause | 26 +- meta/files/common-licenses/BSD-3-Clause | 26 +- meta/files/common-licenses/BSD-4-Clause | 17 +- meta/files/common-licenses/BSL-1.0 | 25 + meta/files/common-licenses/CATOSL-1.1 | 116 meta/files/common-licenses/CC-BY-1.0 | 60 ++ meta/files/common-licenses/CC-BY-2.0 | 63 ++ meta/files/common-licenses/CC-BY-2.5 | 63 ++ meta/files/common-licenses/CC-BY-3.0 | 70 ++ meta/files/common-licenses/CC-BY-NC-1.0 | 63 ++ meta/files/common-licenses/CC-BY-NC-2.0 | 66 ++ meta/files/common-licenses/CC-BY-NC-2.5 | 66 ++ meta/files/common-licenses/CC-BY-NC-3.0 | 72 +++ meta/files/common-licenses/CC-BY-NC-ND-1.0 | 5 + meta/files/common-licenses/CC-BY-NC-ND-2.0 | 63 ++ meta/files/common-licenses/CC-BY-NC-ND-2.5 | 63 ++ meta/files/common-licenses/CC-BY-NC-ND-3.0 | 69 ++ meta/files/common-licenses/CC-BY-NC-SA-1.0 | 64 ++ meta/files/common-licenses/CC-BY-NC-SA-2.0 | 68 ++ meta/files/common-licenses/CC-BY-NC-SA-2.5 | 68 ++ meta/files/common-licenses/CC-BY-NC-SA-3.0 | 74 +++ meta/files/common-licenses/CC-BY-ND-1.0 | 59 ++ meta/files/common-licenses/CC-BY-ND-2.0 | 62 ++ meta/files/common-licenses/CC-BY-ND-2.5 | 62 ++ meta/files/common-licenses/CC-BY-ND-3.0 | 68 ++ meta/files/common-licenses/CC-BY-SA-1.0 | 63 ++ meta/files/common-licenses/CC-BY-SA-2.0 | 67 ++ meta/files/common-licenses/CC-BY-SA-2.5 | 67 ++ meta/files/common-licenses/CC-BY-SA-3.0 | 74 +++ meta/files/common-licenses/CC0-1.0 | 32 + meta/files/common-licenses/CDDL-1.0 | 131 meta/files/common-licenses/CECILL-1.0 | 242 +++ meta/files/common-licenses/CECILL-2.0 | 243 +++ meta/files/common-licenses/CECILL-B
[OE-core] [PATCH 1/2] sanity.bbclass: pass the data object to the less frequent test harnesses
By passing the data object to the less frequently run test harnesses
(check_sanity_tmpdir_change(), check_sanity_sstate_dir_change() and
check_sanity_version_change()) we can run tests against BitBake data here
too.
Signed-off-by: Joshua Lock j...@linux.intel.com
---
meta/classes/sanity.bbclass | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
index fc005aa..bffa4f5 100644
--- a/meta/classes/sanity.bbclass
+++ b/meta/classes/sanity.bbclass
@@ -21,7 +21,7 @@ def check_conf_exists(fn, data):
return True
return False
-def check_sanity_sstate_dir_change(sstate_dir):
+def check_sanity_sstate_dir_change(sstate_dir, data):
# Sanity checks to be done when the value of SSTATE_DIR changes
# Check that SSTATE_DIR isn't on a filesystem with limited filename length
(eg. eCryptFS)
@@ -30,14 +30,14 @@ def check_sanity_sstate_dir_change(sstate_dir):
testmsg = check_create_long_filename(sstate_dir, SSTATE_DIR)
return testmsg
-def check_sanity_tmpdir_change(tmpdir):
+def check_sanity_tmpdir_change(tmpdir, data):
# Sanity checks to be done when the value of TMPDIR changes
# Check that TMPDIR isn't on a filesystem with limited filename length
(eg. eCryptFS)
testmsg = check_create_long_filename(tmpdir, TMPDIR)
return testmsg
-def check_sanity_version_change():
+def check_sanity_version_change(data):
# Sanity checks to be done when SANITY_VERSION changes
return
@@ -262,14 +262,14 @@ def check_sanity(e):
sanity_version = int(data.getVar('SANITY_VERSION', e.data, True) or 1)
if last_sanity_version sanity_version:
-messages = messages + check_sanity_version_change()
-messages = messages + check_sanity_tmpdir_change(tmpdir)
-messages = messages + check_sanity_sstate_dir_change(sstate_dir)
+messages = messages + check_sanity_version_change(e.data)
+messages = messages + check_sanity_tmpdir_change(tmpdir, e.data)
+messages = messages + check_sanity_sstate_dir_change(sstate_dir,
e.data)
else:
if last_tmpdir != tmpdir:
-messages = messages + check_sanity_tmpdir_change(tmpdir)
+messages = messages + check_sanity_tmpdir_change(tmpdir, e.data)
if last_sstate_dir != sstate_dir:
-messages = messages + check_sanity_sstate_dir_change(sstate_dir)
+messages = messages + check_sanity_sstate_dir_change(sstate_dir,
e.data)
if os.path.exists(conf):
f = file(sanityverfile, 'w')
--
1.7.5.2
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/2] sanity: implement network connectivity test v2
v2 of this change set based on feedback from Jeremy Puhlman. Changes since v1: * Allow checked URI's to be configurable. Note: I opted to leave the fallback hard coded. I can certainly remove this and add them toa configuration file somewhere if desired. If this is requested I'll probably remove the DISABLE_NETWORK_SANITY variable and just disable the check if CONNECTIVITY_CHECK_URIS is unset. * Don't copy the data structure if it's not needed. In response to a Yocto Bugzilla request[1] I've written a sanity test to check whether BitBake is able to fecth from http, https and git sources. The idea being that if the user is behing a proxy and this test fails we can more easily help them diagnose and fix their problem. I've built on the existing infrastructure for less frequent sanity tests so whilst this test is reasonably heavy it will only run when TMPDIR changes (usually first run?). Further I added a variable to disable just this sanity check. People shipping offline installs to customers should just be able to set the variable in their shipped configuration and not worry about this sanity check irritating people. The error message points to a wiki page[2] which is pretty vanilla right now but the intention would be to flesh it out with guidance on common proxy/nat/etc issues. The following changes since commit 835d817f1ba7b99167743fdb86ba80f3a07bd82d: systemtap: remove non-core COMPATIBLE_MACHINES (2011-06-16 22:12:40 +0100) are available in the git repository at: git://git.openembedded.net/openembedded-core-contrib josh/connection-test Joshua Lock (2): sanity.bbclass: pass the data object to the less frequent test harnesses sanity: implement network connectivity test meta/classes/sanity.bbclass | 50 --- 1 files changed, 42 insertions(+), 8 deletions(-) -- 1.7.5.2 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] sanity: implement network connectivity test
Sanity test to verify files can be fetched from the network using git, http
and https fetchers point users at a page to help get set up in the case of a
failure.
Addresses [YOCTO #933]
Signed-off-by: Joshua Lock j...@linux.intel.com
---
meta/classes/sanity.bbclass | 34 ++
1 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
index bffa4f5..650df5f 100644
--- a/meta/classes/sanity.bbclass
+++ b/meta/classes/sanity.bbclass
@@ -35,6 +35,8 @@ def check_sanity_tmpdir_change(tmpdir, data):
# Check that TMPDIR isn't on a filesystem with limited filename length
(eg. eCryptFS)
testmsg = check_create_long_filename(tmpdir, TMPDIR)
+# Check that we can fetch from various network transports
+testmsg = testmsg + check_connectivity(data)
return testmsg
def check_sanity_version_change(data):
@@ -75,6 +77,38 @@ def check_create_long_filename(filepath, pathname):
return Failed to create a file in %s: %s % (pathname, strerror)
return
+def check_connectivity(d):
+# URI's to check can be set in the CONNECTIVITY_CHECK_URIS variable using
+# the same syntax as SRC_URI.
+test_uris = (bb.data.getVar('CONNECTIVITY_CHECK_URIS', d, True) or
).split()
+# If no URI's set, fallback to some default ones we know of
+if len(test_uris) == 0:
+test_uris = [http://yoctoproject.org/about;,
+
https://eula-downloads.yoctoproject.org/crownbay/crownbay-bernard-5.0.0;,
+
git://git.yoctoproject.org/yocto-firewall-test;protocol=git;rev=HEAD]
+retval =
+
+# Only check connectivity if network access and this check enabled.
+# Because it's a fairly heavy test allow disabling of just this sanity test
+# by setting DISABLE_NETWORK_SANITY.
+network_disabled = not bb.data.getVar('BB_NO_NETWORK', d, True)
+check_disabled = bb.data.getVar('DISABLE_NETWORK_SANITY', d, True)
+if check_disabled or network_disabled:
+data = bb.data.createCopy(d)
+dldir = bb.data.expand('${TMPDIR}/sanity', data)
+bb.data.setVar('DL_DIR', dldir, data)
+
+try:
+fetcher = bb.fetch2.Fetch(test_uris, data)
+fetcher.download()
+ fetcher.clean(test_uris)
+except Exception:
+retval = Error connecting to the network to fetch, http/https and
git checked.\nPlease check the wiki
(https://wiki.yoctoproject.org/wiki/Connectivity\%20Troubleshooting) for more
suggestions.\n
+finally:
+# Make sure we tidy up the cruft
+oe.path.remove(dldir)
+return retval
+
def check_sanity(e):
from bb import note, error, data, __version__
--
1.7.5.2
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] Linux 3.0-rcX (was Re: [RFC] qemu* kernel configs)
* Bruce Ashfield bruce.ashfi...@gmail.com [110614 17:13]: Thanks for the breakdown, it definitely helps. Now that I've got some 3.0-rcX items done, and recipe renaming behind me, I'll have a look at these and see how best to incorporate the configs. Just curious, what 3.0-rcX items have you done? Will you submit patches for these item soon, or wait for a more complete set? I'm currently just curious, as I've played a little with 3.0-rcX in my sparetime, and I've got a patch series in a local tree that at least builds 3.0-rcX (and also removes some of the support for 2.4-kernels). I've haven't yet looked into libc-headers, just enough to build the 3.0-rcX kernel. However, I've just learned today, that some other project we're using, might port their drivers and SW-stack to 3.0-rcX, instead of choosing a later 2.6.3x kernel. If they go for that route, I'm interested in getting official 3.0-support in OE-core sooner than later... Regards, Anders -- Anders Darander ChargeStorm AB ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Linux 3.0-rcX (was Re: [RFC] qemu* kernel configs)
On Mon, Jun 20, 2011 at 2:44 PM, Anders Darander and...@chargestorm.se wrote: * Bruce Ashfield bruce.ashfi...@gmail.com [110614 17:13]: Thanks for the breakdown, it definitely helps. Now that I've got some 3.0-rcX items done, and recipe renaming behind me, I'll have a look at these and see how best to incorporate the configs. Just curious, what 3.0-rcX items have you done? Will you submit patches for these item soon, or wait for a more complete set? I'm currently just curious, as I've played a little with 3.0-rcX in my sparetime, and I've got a patch series in a local tree that at least builds 3.0-rcX (and also removes some of the support for 2.4-kernels). I've haven't yet looked into libc-headers, just enough to build the 3.0-rcX kernel. My first focus is (and largely was) getting our qemu* patches and meta data up and running on the 3.0 kernel. I've booted most of the qemu variants now, with qemuppc consuming time to find some missing interrupts at the moment. That was done from a purely kernel point of view. Setting the version to 2.6.40 was a temporary work around to focus on the kernel items. I'm now starting into the fallout to the rest of the build and dependent packages. I'm staying away from 2.4 removal at the moment. So if you've got some patches to send, I'd be happy to save them, it would save me some time! Cheers, Bruce However, I've just learned today, that some other project we're using, might port their drivers and SW-stack to 3.0-rcX, instead of choosing a later 2.6.3x kernel. If they go for that route, I'm interested in getting official 3.0-support in OE-core sooner than later... Regards, Anders -- Anders Darander ChargeStorm AB ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/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.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Linux 3.0-rcX (was Re: [RFC] qemu* kernel configs)
On 20 jun 2011, at 21:19, Bruce Ashfield bruce.ashfi...@gmail.com wrote: On Mon, Jun 20, 2011 at 2:44 PM, Anders Darander and...@chargestorm.se wrote: I'm currently just curious, as I've played a little with 3.0-rcX in my sparetime, and I've got a patch series in a local tree that at least builds 3.0-rcX (and also removes some of the support for 2.4-kernels). I've haven't yet looked into libc-headers, just enough to build the 3.0-rcX kernel. My first focus is (and largely was) getting our qemu* patches and meta data up and running on the 3.0 kernel. I've booted most of the qemu variants now, with qemuppc consuming time to find some missing interrupts at the moment. Ah, good to know. Then it is probably time for me to update my modified linux-yocto recipe, to get the latest patches form linux-yocto-dev.git. That was done from a purely kernel point of view. Setting the version to 2.6.40 was a temporary work around to focus on the kernel items. Ok, sounds like a good move. I'm now starting into the fallout to the rest of the build and dependent packages. I'm staying away from 2.4 removal at the moment. So if you've got some patches to send, I'd be happy to save them, it would save me some time! Sure, I'll try to get an RFC out tomorrow evening, shown what I've got sofar. I started from the other end, trying to get all the kernel-build related classes work for both 2.6.X and 3.X. There is definitely a lot more that could / should get removed in the end; but at least I've got a 3.0-rcX kernel successfully built. Regards, Anders ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] MINUTES: OE-TSC meeting 16-Jun-2011
oe-tsc minutes, 16-Jun-2011 Attending: Koen, Khem, Tom, Richard, Mark Apologies: Stefan Notes: Jefro Agenda 01) choose a meeting chair Tom 02) topics khem: fallback source mirror for oe-core premirrors? who maintains no-longer-upstream mirror? kitchen-sink mirror is not a benefit for oe-core, but it is beneficial for yocto, angstrom mirror becomes a distro concept meta-oe is not a distro, won't have a policy oe-core on its own will degrade over time - ok, as oe-core -only users are advanced? khem thinks adding fallback mirrors not a bad choice, given certain constraints --when we have a release we can revisit if it's appropriate there khem: patches appearing for recipes on oe-dev: -- khem to send email regarding put stuff in meta-oe long term support for 2011.03-maintenance -- Tom to change strategy for maint branch, oe.dev master to oe-core/meta-oe/layer khem: promote devs to participate in oe-user -- on agenda for next week 03) action items from last week mark: posted the Commit Policy Guidelines on the wiki, to much fanfare tom: GNOME stuff moving along RP: sent email to board, no response yet 04) TSC structure elections -- RP to send a note to board asking for status on prior message 05) Status updates - oe-core discussions about multilib, tuning files - bsp guidelines - metadata layer splitting - infrastructure Raw Transcript (1:01:00 PM) Tartarus: I'll chair, too, if no one has already volunteered (1:01:15 PM) Jefro: hi Tartarus - no one has volunteered yet, congratulations (1:02:46 PM) Jefro: Agenda is at http://pastebin.com/PhJpWfjr (1:02:52 PM) Tartarus: thanks (1:03:01 PM) Tartarus: waiting on Khem, but, #2, new items? (1:03:07 PM) fray: I don't hve anything to add (1:03:14 PM) ***Tartarus has none (1:03:25 PM) Tartarus: RP? koen? khem? (1:03:35 PM) Tartarus: (and khem's no or new topics will move us on to #3) (1:04:01 PM) Jefro: stefan sends apologies (1:04:18 PM) khem: ich bin hier (1:04:28 PM) fray: (we on 3 then?) (1:04:40 PM) Tartarus: Well, i thought RP and koen would reply quickly ;) (1:05:04 PM) Tartarus: RP__ ? (for making his irc client beep, presumably) (1:06:12 PM) khem: I think fall back src mirror for oe-core (1:06:20 PM) khem: we could talk about that (1:06:43 PM) Tartarus: fine by me (1:07:03 PM) fray: good topic.. I have some minor input for that (1:07:12 PM) Tartarus: RP__, koen, ping? (1:08:07 PM) koen: pong (1:08:12 PM) Tartarus: new topics? (1:09:04 PM) khem: I am seeing some new patches for recipes on oe.dev (1:09:26 PM) khem: I guess because people adopted releases and are now posting the updates (1:09:38 PM) Tartarus: khem: So, you want to bring up discussion winding down oe.dev? (1:09:41 PM) khem: so how should we handle that (1:10:14 PM) Tartarus: Or just that topic, new work going into oe.dev and what to tell/remind people? (1:10:16 PM) khem: Tartarus: yeah should we change the policy for release branch (1:10:23 PM) khem: where it can take patches if needed (1:10:32 PM) khem: but the new patches what to do about those (1:10:38 PM) Tartarus: khem, hm? (1:10:39 PM) khem: some recipes are not in any layer (1:10:50 PM) Tartarus: well, hang on (1:10:56 PM) Tartarus: ok, new topic added to the list (1:10:58 PM) koen: Tartarus: long term support for 2011.03-maintenance (1:11:17 PM) khem: and I would like to promote devs to participate in oe-user (1:11:18 PM) Tartarus: ok, so we've got oe-core mirror, dev happening in oe.dev and 2011.03-maint long term (1:11:19 PM) RP__: soory brb (1:11:40 PM) Tartarus: and promoting oe-user (1:11:44 PM) Tartarus: got all that so far, Jefro? (1:11:50 PM) koen: oe-user? (1:11:54 PM) khem: ml (1:12:10 PM) koen: didn't we say that should go away we'd only have 1 list? (1:12:11 PM) ***fray is sorry to say he didn't know there was an oe-user (1:12:12 PM) khem: to encourage more devs (1:12:34 PM) Tartarus: koen: it's added to the topic list, we'll cover history then (1:12:40 PM) khem: fray: if you go to lists.linuxtogo.org (1:12:47 PM) khem: and grep for OpenEmbedded (1:12:51 PM) Tartarus: Lets move on to #3 and let RP give any new topics when he's back again (1:12:51 PM) khem: you will see all of them (1:13:02 PM) fray: sounds good.. (1:13:11 PM) Tartarus: #3, AI updates (1:13:14 PM) Tartarus: I know fray has one (1:13:21 PM) Jefro: Tartarus - yes, I have it all (1:13:34 PM) fray: my status update.. the Commit Policy Guidelines were posted on the Wiki. An email has been sent to the oe-dev oe-core lists with that information on behalf of the TSC (1:13:54 PM) fray: One minor note. I found a small typo in one spot and fixed it before posting the final version. I assume that's not a problem. ;) (1:14:04 PM) khem: I dont think so (1:15:00 PM) Tartarus: Anyone else have AIs? (1:15:20 PM) Tartarus: GNOME stuff seems to be moving along, but maybe that was already last week (1:15:22 PM) fray: RP had one for the election info.. I haven't seen a response yet (1:15:40 PM) Tartarus: Ah
Re: [OE-core] [PATCH 0/6 V3] Share gcc work directories
On Sun, Jun 19, 2011 at 6:48 PM, Robert Yang liezhi.y...@windriver.com wrote: How does this interact with rm_work? The rm_work does not delete anything in work-shared, I think this is fine, otherwise the source can not be shared. it also limits the possibility of patching the sources differently if need be. Can it do that easily suppose gcc intermediate needs a patch for a given arch and others don't then can it make gcc cross intermediate not use shared source ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] RFD: Recipe variants, multilib and package handling
On 06/13/2011 04:52 AM, Richard Purdie wrote:
[snip]
Discussion
==
I don't think option a) above is viable and the current plan implies
we'd do b) but its extremely ugly. I'm therefore tempted to look more
seriously at c). The bigger issues would appear to be:
* It breaks with convention/tradition for OE (xxx-native vs native:xxx)
True, but how long do we stick with things that are limiting us when we
need a change to fix a real problem? And this is a little easier to
deal with, now that we do really have a notion of doing releases so we
can more easily explain to folks when the change is.
* It would add the constraint of packaging starting with ${PN}
I know we have some, but do they also really have a good reason for not
being ${PN}-foo now, possibly other than we borrowed the notion there
from someone else? For example, I know Ubuntu is still 'ssh' for
'openssh', but we don't do that one.
* It would require changes to the likes of debian.bbclass to account
for package prefixes when performing auto renaming
Maybe we need to rename debian.bbclass while we're at it and yes, taking
into account multilib is, to me, just a 'yeah, gonna have to' as part of
the problem.
* It would break a small set of the metadata where packages don't start
with ${PN} (although the class could simply refuse to extend these
automatically).
I think refusing is a good starting point to encourage someone that
needs it to update the recipe, or it can be a janitor project in the end
if the set is small enough...
Things to consider:
* Would we just do this for multilibs or would we transition native
recipes to the new style of naming? We don't have PACKAGES problems
for native recipes.
I see a positive here being one less thing to change, but the downside
being one more set of logic sitting around. Perhaps as a second pass
migrating native over...
* Likewise, would nativesdk transition? Is has more PACKAGES problems
so likely yes, it would make sense to transition.
I think it'll have to, at least before it's all said and done, otherwise
you will run into someone extending for both and puzzling over the
different names they get.
* Would we stick with - as a delimiter or switch to something like
:?
Internally, that might make things easier but in terms of writing out
the packages, that could be a problem...
Thoughts/suggestions/better ideas welcome...
I wish it was easier to abstract things away so we could get namespace B
and keep that information around to solve problem 'i'. Then problem
'ii' would just be about changing how we define PN.
--
Tom Rini
Mentor Graphics Corporation
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/3] qt4-tools-nativesdk: fix unpack failure due to missing g++.conf
On 06/18/2011 11:56 AM, Paul Eggleton wrote:
FILESPATHPKG was being used to in order to bring in linux.conf and
g++.conf in this recipe, however this probably never worked since
FILESPATHPKG always has the MACHINE appended to it and these are not
machine-specific files.
FILESPATHPKG is not supported in oe-core. Its an oe.dev feature for now.
The only reason it built was that these two files
could be found within the files subdir until we removed Qt 4.6.3.
Using FILESEXTRAPATHS (as qt4-tools-native does) solves this.
Signed-off-by: Paul Eggletonpaul.eggle...@linux.intel.com
---
meta/recipes-qt/qt4/qt4-tools-nativesdk.inc |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-qt/qt4/qt4-tools-nativesdk.inc
b/meta/recipes-qt/qt4/qt4-tools-nativesdk.inc
index 5faf40c..d1f4b47 100644
--- a/meta/recipes-qt/qt4/qt4-tools-nativesdk.inc
+++ b/meta/recipes-qt/qt4/qt4-tools-nativesdk.inc
@@ -5,9 +5,10 @@ HOMEPAGE = http://qt.nokia.com;
PRIORITY = optional
LICENSE = LGPLv2.1 | GPLv3
-INC_PR = r3
+INC_PR = r4
+
+FILESEXTRAPATHS =. ${FILE_DIRNAME}/qt-${PV}:
-FILESPATHPKG =. qt-${PV}:
inherit nativesdk qmake2
SRC_URI =
http://get.qt.nokia.com/qt/source/qt-everywhere-opensource-src-${PV}.tar.gz \
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] base-passwd: remove login.defs references
login.defs is owned by shadow-utils, and doesn't belong here. The shadow-sysroot recipe was created to handle the case this was originally added for (useradd.bbclass support). Signed-off-by: Scott Garman scott.a.gar...@intel.com --- .../base-passwd/base-passwd-3.5.22/login.defs | 386 .../recipes-core/base-passwd/base-passwd_3.5.22.bb | 11 +- 2 files changed, 2 insertions(+), 395 deletions(-) delete mode 100644 meta/recipes-core/base-passwd/base-passwd-3.5.22/login.defs diff --git a/meta/recipes-core/base-passwd/base-passwd-3.5.22/login.defs b/meta/recipes-core/base-passwd/base-passwd-3.5.22/login.defs deleted file mode 100644 index 1d392ac..000 --- a/meta/recipes-core/base-passwd/base-passwd-3.5.22/login.defs +++ /dev/null @@ -1,386 +0,0 @@ -# -# /etc/login.defs - Configuration control definitions for the shadow package. -# -# $Id: login.defs 3038 2009-07-23 20:41:35Z nekral-guest $ -# - -# -# Delay in seconds before being allowed another attempt after a login failure -# Note: When PAM is used, some modules may enfore a minimal delay (e.g. -# pam_unix enforces a 2s delay) -# -FAIL_DELAY 3 - -# -# Enable logging and display of /var/log/faillog login failure info. -# -FAILLOG_ENAB yes - -# -# Enable display of unknown usernames when login failures are recorded. -# -LOG_UNKFAIL_ENAB no - -# -# Enable logging of successful logins -# -LOG_OK_LOGINS no - -# -# Enable logging and display of /var/log/lastlog login time info. -# -LASTLOG_ENAB yes - -# -# Enable checking and display of mailbox status upon login. -# -# Disable if the shell startup files already check for mail -# (mailx -e or equivalent). -# -#MAIL_CHECK_ENAB yes - -# -# Enable additional checks upon password changes. -# -OBSCURE_CHECKS_ENAByes - -# -# Enable checking of time restrictions specified in /etc/porttime. -# -PORTTIME_CHECKS_ENAB yes - -# -# Enable setting of ulimit, umask, and niceness from passwd gecos field. -# -QUOTAS_ENAByes - -# -# Enable syslog logging of su activity - in addition to sulog file logging. -# SYSLOG_SG_ENAB does the same for newgrp and sg. -# -SYSLOG_SU_ENAB yes -SYSLOG_SG_ENAB yes - -# -# If defined, either full pathname of a file containing device names or -# a : delimited list of device names. Root logins will be allowed only -# upon these devices. -# -CONSOLE/etc/securetty -#CONSOLE console:tty01:tty02:tty03:tty04 - -# -# If defined, all su activity is logged to this file. -# -#SULOG_FILE/var/log/sulog - -# -# If defined, : delimited list of message of the day files to -# be displayed upon login. -# -MOTD_FILE /etc/motd -#MOTD_FILE /etc/motd:/usr/lib/news/news-motd - -# -# If defined, this file will be output before each login prompt. -# -#ISSUE_FILE/etc/issue - -# -# If defined, file which maps tty line to TERM environment parameter. -# Each line of the file is in a format something like vt100 tty01. -# -#TTYTYPE_FILE /etc/ttytype - -# -# If defined, login failures will be logged here in a utmp format. -# last, when invoked as lastb, will read /var/log/btmp, so... -# -FTMP_FILE /var/log/btmp - -# -# If defined, name of file whose presence which will inhibit non-root -# logins. The contents of this file should be a message indicating -# why logins are inhibited. -# -NOLOGINS_FILE /etc/nologin - -# -# If defined, the command name to display when running su -. For -# example, if this is defined as su then a ps will display the -# command is -su. If not defined, then ps would display the -# name of the shell actually being run, e.g. something like -sh. -# -SU_NAMEsu - -# -# *REQUIRED* -# Directory where mailboxes reside, _or_ name of file, relative to the -# home directory. If you _do_ define both, #MAIL_DIR takes precedence. -# -#MAIL_DIR /var/spool/mail -MAIL_FILE .mail - -# -# If defined, file which inhibits all the usual chatter during the login -# sequence. If a full pathname, then hushed mode will be enabled if the -# user's name or shell are found in the file. If not a full pathname, then -# hushed mode will be enabled if the file exists in the user's home directory. -# -HUSHLOGIN_FILE .hushlogin -#HUSHLOGIN_FILE/etc/hushlogins - -# -# If defined, either a TZ environment parameter spec or the -# fully-rooted pathname of a file containing such a spec. -# -#ENV_TZTZ=CST6CDT -#ENV_TZ/etc/tzname - -# -# If defined, an HZ environment parameter spec. -# -# for Linux/x86 -ENV_HZ HZ=100 -# For Linux/Alpha... -#ENV_HZHZ=1024 - -# -# *REQUIRED* The default PATH settings, for superuser and normal users. -# -# (they are minimal, add the rest in the shell startup files) -ENV_SUPATH PATH=/sbin:/bin:/usr/sbin:/usr/bin -ENV_PATH PATH=/bin:/usr/bin - -# -# Terminal permissions -# -# TTYGROUPLogin tty will be
[OE-core] [PATCH 1/2] shadow-sysroot: new recipe for useradd.bbclass support
Packaging login.defs with base-passwd causes problems due to the file being included in target package installs. Instead, this shadow-sysroot recipe can be used by useradd.bbclass to put login.defs into the target sysroot without disturbing packages intended for target devices. Signed-off-by: Scott Garman scott.a.gar...@intel.com --- .../shadow/files/login.defs_shadow-sysroot | 386 .../shadow/shadow-sysroot_4.1.4.3.bb | 41 ++ 2 files changed, 427 insertions(+), 0 deletions(-) create mode 100644 meta/recipes-extended/shadow/files/login.defs_shadow-sysroot create mode 100644 meta/recipes-extended/shadow/shadow-sysroot_4.1.4.3.bb diff --git a/meta/recipes-extended/shadow/files/login.defs_shadow-sysroot b/meta/recipes-extended/shadow/files/login.defs_shadow-sysroot new file mode 100644 index 000..8a68dd3 --- /dev/null +++ b/meta/recipes-extended/shadow/files/login.defs_shadow-sysroot @@ -0,0 +1,386 @@ +# +# /etc/login.defs - Configuration control definitions for the shadow package. +# +# $Id: login.defs 3038 2009-07-23 20:41:35Z nekral-guest $ +# + +# +# Delay in seconds before being allowed another attempt after a login failure +# Note: When PAM is used, some modules may enfore a minimal delay (e.g. +# pam_unix enforces a 2s delay) +# +FAIL_DELAY 3 + +# +# Enable logging and display of /var/log/faillog login failure info. +# +#FAILLOG_ENAB yes + +# +# Enable display of unknown usernames when login failures are recorded. +# +LOG_UNKFAIL_ENAB no + +# +# Enable logging of successful logins +# +LOG_OK_LOGINS no + +# +# Enable logging and display of /var/log/lastlog login time info. +# +#LASTLOG_ENAB yes + +# +# Enable checking and display of mailbox status upon login. +# +# Disable if the shell startup files already check for mail +# (mailx -e or equivalent). +# +##MAIL_CHECK_ENAB yes + +# +# Enable additional checks upon password changes. +# +#OBSCURE_CHECKS_ENAB yes + +# +# Enable checking of time restrictions specified in /etc/porttime. +# +#PORTTIME_CHECKS_ENAB yes + +# +# Enable setting of ulimit, umask, and niceness from passwd gecos field. +# +#QUOTAS_ENAB yes + +# +# Enable syslog logging of su activity - in addition to sulog file logging. +# SYSLOG_SG_ENAB does the same for newgrp and sg. +# +SYSLOG_SU_ENAB yes +SYSLOG_SG_ENAB yes + +# +# If defined, either full pathname of a file containing device names or +# a : delimited list of device names. Root logins will be allowed only +# upon these devices. +# +CONSOLE/etc/securetty +#CONSOLE console:tty01:tty02:tty03:tty04 + +# +# If defined, all su activity is logged to this file. +# +#SULOG_FILE/var/log/sulog + +# +# If defined, : delimited list of message of the day files to +# be displayed upon login. +# +#MOTD_FILE /etc/motd +#MOTD_FILE /etc/motd:/usr/lib/news/news-motd + +# +# If defined, this file will be output before each login prompt. +# +#ISSUE_FILE/etc/issue + +# +# If defined, file which maps tty line to TERM environment parameter. +# Each line of the file is in a format something like vt100 tty01. +# +#TTYTYPE_FILE /etc/ttytype + +# +# If defined, login failures will be logged here in a utmp format. +# last, when invoked as lastb, will read /var/log/btmp, so... +# +#FTMP_FILE /var/log/btmp + +# +# If defined, name of file whose presence which will inhibit non-root +# logins. The contents of this file should be a message indicating +# why logins are inhibited. +# +#NOLOGINS_FILE /etc/nologin + +# +# If defined, the command name to display when running su -. For +# example, if this is defined as su then a ps will display the +# command is -su. If not defined, then ps would display the +# name of the shell actually being run, e.g. something like -sh. +# +SU_NAMEsu + +# +# *REQUIRED* +# Directory where mailboxes reside, _or_ name of file, relative to the +# home directory. If you _do_ define both, #MAIL_DIR takes precedence. +# +#MAIL_DIR /var/spool/mail +MAIL_FILE .mail + +# +# If defined, file which inhibits all the usual chatter during the login +# sequence. If a full pathname, then hushed mode will be enabled if the +# user's name or shell are found in the file. If not a full pathname, then +# hushed mode will be enabled if the file exists in the user's home directory. +# +HUSHLOGIN_FILE .hushlogin +#HUSHLOGIN_FILE/etc/hushlogins + +# +# If defined, either a TZ environment parameter spec or the +# fully-rooted pathname of a file containing such a spec. +# +#ENV_TZTZ=CST6CDT +#ENV_TZ/etc/tzname + +# +# If defined, an HZ environment parameter spec. +# +# for Linux/x86 +#ENV_HZHZ=100 +# For Linux/Alpha... +#ENV_HZHZ=1024 + +# +# *REQUIRED* The default PATH settings, for superuser and normal users. +# +# (they are minimal, add the rest in the
Re: [OE-core] [PATCH 0/6 V3] Share gcc work directories
On 06/21/2011 05:01 AM, Khem Raj wrote:
On Sun, Jun 19, 2011 at 6:48 PM, Robert Yangliezhi.y...@windriver.com wrote:
How does this interact with rm_work?
The rm_work does not delete anything in work-shared, I think this is fine,
otherwise the source can not be shared.
it also limits the possibility of patching the sources differently if need be.
Can it do that easily suppose gcc intermediate needs a patch for a given arch
Yes, the source must be the same if they want to use the shared source. When we
want to patch the source, I think proper way is try to patch them general(not
only for a given arch).
and others don't then can it make gcc cross intermediate not use shared source
Yes, when the following variables are not defined(or defined to other value)
for gcc intermediate, then it would not use the shared source.
S = ${TMPDIR}/work-shared/gcc-${PV}/gcc-${PV}
B = ${WORKDIR}/gcc-${PV}/build.${HOST_SYS}.${TARGET_SYS}
# SS means Shared Stamps directory
SS = ${TMPDIR}/stamps/work-shared/gcc-${PV}
do_fetch[stamp-base] = ${SS}
do_unpack[stamp-base] = ${SS}
do_patch[stamp-base] = ${SS}
# SW means Shared Work directory
SW = ${TMPDIR}/work-shared/gcc-${PV}
WORKDIR_task-unpack = ${SW}
WORKDIR_task-patch = ${SW}
// Robert
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/6] connman: Upgrade to version 0.75
Hi Koen,
-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
Koen Kooi
Sent: Friday, June 17, 2011 3:15 PM
To: Patches and discussions about the oe-core layer
Subject: Re: [OE-core] [PATCH 1/6] connman: Upgrade to version 0.75
Op 17 jun 2011, om 09:08 heeft Xu, Dongxiao het volgende geschreven:
I would say put ofono as a DISTRO_FEATURE
You don't need to build ofono to have ofono support in connman.
Angstrom (and hence meta-oe) build with it enabled by default to
support people who want to use the plugin on their phones. Since
it's a nicely seperated plugin,
Do you mean connman-plugin-ofono could work correctly without the ofono
recipe?
According to my understanding, connman-plugin-ofono controls the telephony
device by talking with ofonod daemon through dbus mechanism.
On another aspect, ofono project has support for different types of modems,
and I don't think connman-plugin-ofono has the ability.
Therefore I think the ofono recipe is needed.
I'm saying that ofono is not a *build* dependency for the connman-ofono
plugin.
Yes we don't need ofono to build connman or connman-plugin-ofono, but we need
to assign ofono as RDEPENDS of connman-plugin-ofono by the following logic:
python populate_packages_prepend() {
depmap = dict( wifi=wpa-supplicant, resolvconf=resolvconf,
bluetooth=bluez4, ofono=ofono )
packages = []
hook = lambda file,pkg,b,c,d:packages.append((file,pkg))
plugin_dir = bb.data.expand('${libdir}/connman/plugins/', d)
plugin_name = bb.data.expand('${PN}-plugin-%s', d)
do_split_packages(d, plugin_dir, '^(.*).so$', plugin_name, '${PN}
plugin for %s', extra_depends='', hook=hook )
for (file, package) in packages:
plugintype = package.split( '-' )[-1]
if plugintype in depmap:
bb.note( Adding rdependency on %s to package %s % (
depmap[plugintype], package ) )
bb.data.setVar(RDEPENDS_%s % package,
depmap[plugintype], d)
}
Since we didn't assign ofono as any direct build/runtime dependency of connman.
Therefore we will face a problem that, while doing rootfs, ofono is not built
out while connman-plugin-ofono has runtime dependency on it, and it will cause
do_rootfs error.
I saw in meta-oe, there are following lines, I understand it as a workaround to
handle the late added rdepends.
# we need to define the depends here, the dynamic stuff is too late
DEPENDS = libnl wpa-supplicant dbus glib-2.0 ppp busybox dhcp resolvconf
bluez4 iptables gnutls ntp
Therefore I think we also need to add ofono in the DEPENDS line to solve our
problem.
Thanks,
Dongxiao
regards,
Koen
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
