[OE-core] [PATCH] puzzles: upgrade to r9733
Signed-off-by: Constantin Musca constantinx.mu...@intel.com
---
meta/recipes-sato/puzzles/{puzzles_r9712.bb = puzzles_r9733.bb} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename meta/recipes-sato/puzzles/{puzzles_r9712.bb = puzzles_r9733.bb} (100%)
diff --git a/meta/recipes-sato/puzzles/puzzles_r9712.bb
b/meta/recipes-sato/puzzles/puzzles_r9733.bb
similarity index 100%
rename from meta/recipes-sato/puzzles/puzzles_r9712.bb
rename to meta/recipes-sato/puzzles/puzzles_r9733.bb
--
1.7.11.7
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] connman: upgrade to 1.10
Hello Ross, I saw the change in netbase recipe that Constantin submitted as a patch. However, that patch has not been merged for 4 months now. I don't want that situation to happen to connman also. Ross, Saul, please advise. I can remake the patch as Costin did for netbase, but will it be merged? In the meantime, nightly builds fail because connman sanity tests fail. Regards, Cristian -Original Message- From: Ross Burton [mailto:ross.bur...@intel.com] Sent: Thursday, January 10, 2013 9:56 AM To: Iorga, Cristian Cc: openembedded-core@lists.openembedded.org Subject: Re: [OE-core] [PATCH] connman: upgrade to 1.10 On Thursday, 10 January 2013 at 07:15, Iorga, Cristian wrote: Well, I have the prior art stand by me. The same technique is applied for netbase. And, in this specific case, connman should be machine specific. Can you please give me more detail? The configuration file will have only the interface blacklist enabled in case of a qemu* machine. netbase is a lot smaller than connman. With this change you're rebuilding connman per-machine instead of sharing the package between compatible machines, with the only difference being a configuration file. Ross ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/5] quilt: Remove non-gnu.patch, and added configure flags for darwin.
---
meta/recipes-devtools/quilt/quilt-0.60.inc |4 +
meta/recipes-devtools/quilt/quilt-native.inc|1 -
meta/recipes-devtools/quilt/quilt/non-gnu.patch | 225 ---
3 files changed, 4 insertions(+), 226 deletions(-)
delete mode 100644 meta/recipes-devtools/quilt/quilt/non-gnu.patch
diff --git a/meta/recipes-devtools/quilt/quilt-0.60.inc
b/meta/recipes-devtools/quilt/quilt-0.60.inc
index 1e240a0..e0a2e51 100644
--- a/meta/recipes-devtools/quilt/quilt-0.60.inc
+++ b/meta/recipes-devtools/quilt/quilt-0.60.inc
@@ -12,6 +12,10 @@ SRC_URI[sha256sum] =
3d72a292e432beb9a73f9d0acfe3a77c9b4d7e42209919bb244e9958c7
inherit autotools
+EXTRA_OECONF_darwin += --without-date \
+--without-getopt \
+
+
PACKAGES += guards guards-doc
FILES_${PN} = ${sysconfdir} ${datadir}/quilt \
${bindir}/quilt ${libdir}/quilt
diff --git a/meta/recipes-devtools/quilt/quilt-native.inc
b/meta/recipes-devtools/quilt/quilt-native.inc
index 9345d88..5c4b0a2 100644
--- a/meta/recipes-devtools/quilt/quilt-native.inc
+++ b/meta/recipes-devtools/quilt/quilt-native.inc
@@ -1,4 +1,3 @@
-SRC_URI_append_build-darwin = ? file://non-gnu.patch
RDEPENDS_${PN} = diffstat-native patch-native bzip2-native util-linux-native
INHIBIT_AUTOTOOLS_DEPS = 1
diff --git a/meta/recipes-devtools/quilt/quilt/non-gnu.patch
b/meta/recipes-devtools/quilt/quilt/non-gnu.patch
deleted file mode 100644
index 520bf52..000
--- a/meta/recipes-devtools/quilt/quilt/non-gnu.patch
+++ /dev/null
@@ -1,225 +0,0 @@
-Upstream-Status: Pending
-
-Patch is from the Fink projetc (http://fink.sf.net)
-
-diff -r 7b51c215fc54 Makefile.in
a/Makefile.in Sat Mar 4 17:16:21 2006 -0800
-+++ b/Makefile.in Sat Mar 4 17:59:09 2006 -0800
-@@ -256,7 +256,7 @@ bin/guards.1 : bin/guards
- -e 's:@VERSION''@:$(VERSION):g' \
- -e 's:@RELEASE''@:$(RELEASE):g' \
- -e 's:@LOCALEDIR''@:$(localedir):g' \
-- -e 's:@DOCSUBDIR''@:$(docdir)/$(PACKAGE)-$(VERSION):g' \
-+ -e 's:@DOCSUBDIR''@:$(docdir)/$(PACKAGE):g' \
- $ $@
- @$(if $(filter-out $,$(NON_EXEC_IN)),chmod +x $@)
-
-@@ -320,11 +320,11 @@ endif
- $(INSTALL) -d $(BUILD_ROOT)$(libdir)/$(PACKAGE)
- $(INSTALL) -m 755 $(LIB:%=lib/%) $(BUILD_ROOT)$(libdir)/$(PACKAGE)/
-
-- $(INSTALL) -d $(BUILD_ROOT)$(docdir)/$(PACKAGE)-$(VERSION)/
-+ $(INSTALL) -d $(BUILD_ROOT)$(docdir)/$(PACKAGE)/
- $(INSTALL) -m 644 doc/README\
-- $(BUILD_ROOT)$(docdir)/$(PACKAGE)-$(VERSION)/
-+ $(BUILD_ROOT)$(docdir)/$(PACKAGE)/
- $(INSTALL) -m 644 doc/quilt.pdf doc/README.MAIL \
-- $(BUILD_ROOT)$(docdir)/$(PACKAGE)-$(VERSION)/
-+ $(BUILD_ROOT)$(docdir)/$(PACKAGE)/
-
- $(INSTALL) -d $(BUILD_ROOT)$(mandir)/man1
- $(INSTALL) -m 644 $(MAN1) $(BUILD_ROOT)$(mandir)/man1/
-@@ -367,7 +367,7 @@ uninstall ::
- $(notdir $(MAN1))) \
- $(BUILD_ROOT)$(etcdir)/bash_completion.d/quilt \
- $(BUILD_ROOT)$(etcdir)/quilt.quiltrc \
-- $(BUILD_ROOT)$(docdir)/$(PACKAGE)-$(VERSION)/
-+ $(BUILD_ROOT)$(docdir)/$(PACKAGE)/
-
- check: $(TESTS:test/%.test=test/.%.ok)
- check-all: $(TESTS:test/%.test=check-%)
-diff -r 7b51c215fc54 configure
a/configureSat Mar 4 17:16:21 2006 -0800
-+++ b/configureSat Mar 4 17:59:09 2006 -0800
-@@ -3882,29 +3882,6 @@ echo $as_me: error: Please specify the
- fi
-
-
--echo $as_me:$LINENO: checking whether $CP -l works 5
--echo $ECHO_N checking whether $CP -l works... $ECHO_C 6
--touch conftest.1
--if $CP -l conftest.1 conftest.2 2/dev/null; then
-- echo $as_me:$LINENO: result: yes 5
--echo ${ECHO_T}yes 6
--else
-- { { echo $as_me:$LINENO: error: no
--
--You appear to have a \`cp' that does not support hard links.
--You can download GNU fileutils from ftp.gnu.org
-- 5
--echo $as_me: error: no
--
--You appear to have a \`cp' that does not support hard links.
--You can download GNU fileutils from ftp.gnu.org
-- 2;}
-- { (exit 1); exit 1; }; }
--fi
--
--
--
--
-
- # Check whether --with-date or --without-date was given.
- if test ${with_date+set} = set; then
-@@ -3999,32 +3976,6 @@ echo $as_me: WARNING: Using internal da
- INTERNAL_DATE=1
-
- fi
--
--
--
--if test -z $INTERNAL_DATE; then
-- echo $as_me:$LINENO: checking whether $DATE --rfc-822 works 5
--echo $ECHO_N checking whether $DATE --rfc-822 works... $ECHO_C 6
-- if $DATE --rfc-822 /dev/null 2/dev/null; then
-- echo $as_me:$LINENO: result: yes 5
--echo ${ECHO_T}yes 6
-- else
-- { { echo $as_me:$LINENO: error: no
--
--If you don't have a version of \`date' that supports --rfc-822, you
--can
[OE-core] [PATCH 1/5] sanity: Make the required utilities more platform specific.
This might make us able to build on mac os X.
Signed-off-by: Martin Ertsaas marti...@gmail.com
---
meta/classes/sanity.bbclass | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
index 0ffa52d..03651be 100644
--- a/meta/classes/sanity.bbclass
+++ b/meta/classes/sanity.bbclass
@@ -2,7 +2,9 @@
# Sanity check the users setup for common misconfigurations
#
-SANITY_REQUIRED_UTILITIES ?= patch diffstat makeinfo git bzip2 tar gzip gawk
chrpath wget cpio
+SANITY_REQUIRED_UTILITIES ?= patch diffstat makeinfo git bzip2 tar gzip gawk
wget cpio
+SANITY_REQUIRED_UTILITIES_Linux ?= ${SANITY_REQUIRED_UTILITIES} chrpath
+SANITY_REQUIRED_UTILITIES_Darwin ?= ${SANITY_REQUIRED_UTILITIES}
install_name_tool
python check_bblayers_conf() {
bblayers_fn = os.path.join(d.getVar('TOPDIR', True), 'conf/bblayers.conf')
@@ -340,6 +342,10 @@ def check_sanity_validmachine(sanity_data):
return messages
+def get_required_utilities(sanity_data):
+import platform
+sanity_var = 'SANITY_REQUIRED_UTILITIES_%s' %platform.system()
+return sanity_data.getVar(sanity_var, True)
def check_sanity(sanity_data):
import subprocess
@@ -444,7 +450,7 @@ def check_sanity(sanity_data):
if not check_app_exists('${BUILD_PREFIX}g++', sanity_data):
missing = missing + C++ Compiler (%sg++), %
sanity_data.getVar(BUILD_PREFIX, True)
-required_utilities = sanity_data.getVar('SANITY_REQUIRED_UTILITIES', True)
+required_utilities = get_required_utilities(sanity_data)
if qemu-native in assume_provided:
if not check_app_exists(qemu-arm, sanity_data):
--
1.7.10.2 (Apple Git-33)
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 5/5] sstate: Do not add the --no-run-if-empty arguement to xargs when on Darwin, as it is not supported.
---
meta/classes/sstate.bbclass | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index 68fd996..e92fbae 100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -368,7 +368,7 @@ python sstate_cleanall() {
}
def sstate_hardcode_path(d):
-import subprocess
+import subprocess, platform
# Need to remove hardcoded paths and fix these when we install the
# staging packages.
@@ -390,7 +390,7 @@ def sstate_hardcode_path(d):
else:
sstate_grep_cmd = grep -l -e '%s' % (staging_host)
sstate_sed_cmd = sed -i -e 's:%s:FIXMESTAGINGDIRHOST:g' %
(staging_host)
-
+
fixmefn = sstate_builddir + fixmepath
sstate_scan_cmd = d.getVar('SSTATE_SCAN_CMD', True)
@@ -399,9 +399,13 @@ def sstate_hardcode_path(d):
# fixmepath file needs relative paths, drop sstate_builddir prefix
sstate_filelist_relative_cmd = sed -i -e 's:^%s::g' %s %
(sstate_builddir, fixmefn)
+xargs_no_empty_run_cmd = '--no-run-if-empty'
+if platform.system() == 'Darwin':
+xargs_no_empty_run_cmd = ''
+
# Limit the fixpaths and sed operations based on the initial grep search
# This has the side effect of making sure the vfs cache is hot
-sstate_hardcode_cmd = %s | xargs %s | %s | xargs --no-run-if-empty %s %
(sstate_scan_cmd, sstate_grep_cmd, sstate_filelist_cmd, sstate_sed_cmd)
+sstate_hardcode_cmd = %s | xargs %s | %s | xargs %s %s %
(sstate_scan_cmd, sstate_grep_cmd, sstate_filelist_cmd, xargs_no_empty_run_cmd,
sstate_sed_cmd)
print Removing hardcoded paths from sstate package: '%s' %
(sstate_hardcode_cmd)
subprocess.call(sstate_hardcode_cmd, shell=True)
--
1.7.10.2 (Apple Git-33)
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 4/5] lib/oe/path.py: Use shutil.rmtree if the path we wish to remove is a directory.
On mac, os.unlink can not be done to remove directories, and so we have to explicitly use shutil.rmtree instead to support mac. --- meta/lib/oe/path.py |9 + 1 file changed, 1 insertion(+), 8 deletions(-) diff --git a/meta/lib/oe/path.py b/meta/lib/oe/path.py index 7197b23..1da39b7 100644 --- a/meta/lib/oe/path.py +++ b/meta/lib/oe/path.py @@ -86,14 +86,7 @@ def copytree(src, dst): def remove(path, recurse=True): Equivalent to rm -f or rm -rf -for name in glob.glob(path): -try: -os.unlink(name) -except OSError, exc: -if recurse and exc.errno == errno.EISDIR: -shutil.rmtree(name) -elif exc.errno != errno.ENOENT: -raise +bb.utils.remove(path, recurse) def symlink(source, destination, force=False): Create a symbolic link -- 1.7.10.2 (Apple Git-33) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/5] quilt: Don't use BUILD_ROOT on darwin.
---
meta/recipes-devtools/quilt/quilt-0.60.inc |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/quilt/quilt-0.60.inc
b/meta/recipes-devtools/quilt/quilt-0.60.inc
index e0a2e51..5fe201f 100644
--- a/meta/recipes-devtools/quilt/quilt-0.60.inc
+++ b/meta/recipes-devtools/quilt/quilt-0.60.inc
@@ -25,9 +25,12 @@ FILES_guards-doc = ${mandir}/man1/guards.1
RDEPENDS_${PN} = bash
+EXTRA_OE_MAKE_ARGS_darwin ?=
+EXTRA_OE_MAKE_ARGS ?= BUILD_ROOT=${D}
+
# quilt ignores DESTDIR
do_install () {
- oe_runmake 'BUILD_ROOT=${D}' install
+ oe_runmake ${EXTRA_OE_MAKE_ARGS} install
# cleanup unpackaged files
rm -rf ${D}/${datadir}/emacs
}
--
1.7.10.2 (Apple Git-33)
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] connman: upgrade to 1.10
On Thu, Jan 10, 2013 at 07:56:30AM +, Ross Burton wrote: On Thursday, 10 January 2013 at 07:15, Iorga, Cristian wrote: Well, I have the prior art stand by me. The same technique is applied for netbase. And, in this specific case, connman should be machine specific. Can you please give me more detail? The configuration file will have only the interface blacklist enabled in case of a qemu* machine. netbase is a lot smaller than connman. and also listed in SIGGEN_EXCLUDERECIPES_ABISAFE With this change you're rebuilding connman per-machine instead of sharing the package between compatible machines, with the only difference being a configuration file. And rebuilding also all stuff depending on connman. Cheers, -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 00/14] Prepare recipes for automake-1.13 (batch 2)
The following changes since commit 0cfec10c4c7b0597f0e0c8f85539d901861a2f83: guile: add explicit dependency to avoid parallel build issue (2013-01-09 13:41:12 +) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib cazfi/am13 http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=cazfi/am13 Marko Lindqvist (14): dbus-glib: replace obsolete automake macros with working ones tslib: replace obsolete automake macros with working ones makedepend: replace obsolete automake macros with working ones alsa-lib: replace obsolete automake macros with working ones python: replace obsolete automake macros with working ones libogg: replace obsolete automake macros with working ones libmad: replace obsolete automake macros with working ones libvorbis: replace obsolete automake macros with working ones opensp: replace obsolete automake macros with working ones gconf: replace obsolete automake macros with working ones startup-notification: replace obsolete automake macros with working ones gtk+: replace obsolete automake macros with working ones gmp: replace obsolete automake macros with working ones bluez4: replace obsolete automake macros with working ones .../bluez4-4.101/obsolete_automake_macros.patch| 14 meta/recipes-connectivity/bluez/bluez4_4.101.bb|6 +++-- .../dbus-glib-0.100/obsolete_automake_macros.patch | 15 + meta/recipes-core/dbus/dbus-glib.inc |1 + meta/recipes-core/dbus/dbus-glib_0.100.bb |2 +- .../opensp-1.5.2/obsolete_automake_macros.patch| 15 + meta/recipes-devtools/opensp/opensp_1.5.2.bb |6 +++-- .../obsolete_automake_macros.patch | 14 meta/recipes-devtools/python/python-dbus_1.1.1.bb |6 +++-- .../obsolete_automake_macros.patch | 23 .../python/python-pygobject_2.27.91.bb |6 +++-- .../gconf-3.2.5/obsolete_automake_macros.patch | 14 meta/recipes-gnome/gnome/gconf_3.2.5.bb|6 +++-- .../gtk+-2.24.14/obsolete_automake_macros.patch| 23 meta/recipes-gnome/gtk+/gtk+_2.24.14.bb|1 + .../obsolete_automake_macros.patch | 15 + .../startup-notification_0.12.bb |4 +++- .../tslib/tslib/obsolete_automake_macros.patch | 15 + meta/recipes-graphics/tslib/tslib_1.0.bb |6 +++-- .../obsolete_automake_macros.patch | 15 + .../recipes-graphics/xorg-util/makedepend_1.0.4.bb |4 +++- .../alsa-lib-1.0.25/obsolete_automake_macros.patch | 15 + meta/recipes-multimedia/alsa/alsa-lib_1.0.25.bb|6 +++-- .../libmad/libmad/obsolete_automake_macros.patch | 14 meta/recipes-multimedia/libmad/libmad_0.15.1b.bb |6 +++-- .../libogg-1.3.0/obsolete_automake_macros.patch| 14 meta/recipes-multimedia/libogg/libogg_1.3.0.bb |6 +++-- .../libvorbis-1.3.3/obsolete_automake_macros.patch | 15 + .../libvorbis/libvorbis_1.3.3.bb |6 +++-- .../gmp/gmp-5.1.0/obsolete_automake_macros.patch | 13 +++ meta/recipes-support/gmp/gmp_5.1.0.bb |3 +++ 31 files changed, 286 insertions(+), 23 deletions(-) create mode 100644 meta/recipes-connectivity/bluez/bluez4-4.101/obsolete_automake_macros.patch create mode 100644 meta/recipes-core/dbus/dbus-glib-0.100/obsolete_automake_macros.patch create mode 100644 meta/recipes-devtools/opensp/opensp-1.5.2/obsolete_automake_macros.patch create mode 100644 meta/recipes-devtools/python/python-dbus-1.1.1/obsolete_automake_macros.patch create mode 100644 meta/recipes-devtools/python/python-pygobject/obsolete_automake_macros.patch create mode 100644 meta/recipes-gnome/gnome/gconf-3.2.5/obsolete_automake_macros.patch create mode 100644 meta/recipes-gnome/gtk+/gtk+-2.24.14/obsolete_automake_macros.patch create mode 100644 meta/recipes-graphics/startup-notification/startup-notification-0.12/obsolete_automake_macros.patch create mode 100644 meta/recipes-graphics/tslib/tslib/obsolete_automake_macros.patch create mode 100644 meta/recipes-graphics/xorg-util/makedepend-1.0.4/obsolete_automake_macros.patch create mode 100644 meta/recipes-multimedia/alsa/alsa-lib-1.0.25/obsolete_automake_macros.patch create mode 100644 meta/recipes-multimedia/libmad/libmad/obsolete_automake_macros.patch create mode 100644 meta/recipes-multimedia/libogg/libogg-1.3.0/obsolete_automake_macros.patch create mode 100644 meta/recipes-multimedia/libvorbis/libvorbis-1.3.3/obsolete_automake_macros.patch create mode 100644 meta/recipes-support/gmp/gmp-5.1.0/obsolete_automake_macros.patch -- 1.7.10.4 ___ Openembedded-core mailing list
[OE-core] glib2.0 and dbus dependency
when compiling using 4 threads, I got following error. the glib2.0-native want find dbus header file. If I compiled dbus/dbus-natigve, and then compile glib2.0 OK. when grep glib2.0 bb files, I can't find dbus in dependency, why? ERROR: Function failed: do_compile (see /mnt/src/arm9plf- build/tmp/work/x86_64-linux/glib-2.0-native/1_2.34.3- r0/temp/log.do_compile.28193 for further information) ERROR: Task 1851 (virtual:native:/mnt/src/optimus/poky/meta/recipes- core/glib-2.0/glib-2.0_2.34.3.bb, do_compile) failed with exit code '1' NOTE: Tasks Summary: Attempted 929 tasks of which 925 didn't need to be rerun and 1 failed. Waiting for 0 running tasks to finish: Summary: 1 task failed: virtual:native:/mnt/src/optimus/poky/meta/recipes- core/glib-2.0/glib-2.0_2.34.3.bb, do_compile Summary: There was 1 ERROR message shown, returning a non-zero exit code. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [oe-core][PATCH] boost: Use PARALLEL_MAKE for bjam
Like make, bjam accepts the parameter -jX for multithreaded execution
do_install also profits from this setting
Tested with a quad core 64bit intel cpu (with hyperthreading)
PARALLEL_MAKE=j16
$ time bitbake boost
before:
real14m37.433s
user7m40.785s
sys 4m30.109s
after:
real7m11.979s
user12m10.694s
sys 2m47.078s
Also fixes tab indention
Signed-off-by: Samuel Stirtzel s.stirt...@googlemail.com
---
meta/recipes-support/boost/boost.inc |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-support/boost/boost.inc
b/meta/recipes-support/boost/boost.inc
index 830fcb0..4fe5a35 100644
--- a/meta/recipes-support/boost/boost.inc
+++ b/meta/recipes-support/boost/boost.inc
@@ -120,10 +120,12 @@ BJAM_TOOLS = -sTOOLS=gcc \
'--layout=system' \
-BJAM_OPTS= '${BJAM_TOOLS} \
--sBOOST_BUILD_USER_CONFIG=${S}/tools/build/v2/user-config.jam \
+#use PARALLEL_MAKE to speed up the build
+BJAM_OPTS= '${PARALLEL_MAKE} \
+ ${BJAM_TOOLS} \
+ -sBOOST_BUILD_USER_CONFIG=${S}/tools/build/v2/user-config.jam \
--builddir=${S}/${TARGET_SYS} \
---disable-icu \
+ --disable-icu \
${BJAM_EXTRA}'
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] glib2.0 and dbus dependency
On Thu, Jan 10, 2013 at 06:31:22PM +, Yi Qingliang wrote: when compiling using 4 threads, I got following error. the glib2.0-native want find dbus header file. If I compiled dbus/dbus-natigve, and then compile glib2.0 OK. when grep glib2.0 bb files, I can't find dbus in dependency, why? It was causing cyclic dependency at least when dbus tests were enabled, I'm not sure if this was resolved already. ERROR: Function failed: do_compile (see /mnt/src/arm9plf- build/tmp/work/x86_64-linux/glib-2.0-native/1_2.34.3- r0/temp/log.do_compile.28193 for further information) ERROR: Task 1851 (virtual:native:/mnt/src/optimus/poky/meta/recipes- core/glib-2.0/glib-2.0_2.34.3.bb, do_compile) failed with exit code '1' NOTE: Tasks Summary: Attempted 929 tasks of which 925 didn't need to be rerun and 1 failed. Waiting for 0 running tasks to finish: Summary: 1 task failed: virtual:native:/mnt/src/optimus/poky/meta/recipes- core/glib-2.0/glib-2.0_2.34.3.bb, do_compile Summary: There was 1 ERROR message shown, returning a non-zero exit code. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] defining a new image: inherit image vs image_types?
possibly a distinction with no distinction but i wanted to throw
together a page on how one defines a new image type -- most
commonly, an SD card image -- and i started with what comes with the
meta-raspberrypi layer, which seems to work just fine.
what i noticed is that that layer introduces the new
sdcard_image-rpi.bbclass class file, which opens with:
inherit image_types
but then i remembered that the meta-ti layer does the same thing,
providing the new class file sdcard_image.bbclass which opens
instead with:
inherit image
i realize that the oe-core image.bbclass contains this snippet:
IMAGE_CLASSES ?= image_types
inherit ${IMAGE_CLASSES}
so it's clear that inheriting image is sufficient, but the
alternative *isn't* clear.
what's the preferred construction here? before digging further to
see if there's something subtle or equivalent happening, should it be
sufficient for new image definitions to simply:
inherit image_types
?? have i just not RTFS far enough to see that there's no difference?
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] sstate, cache or licence issue?
Hi,
Yes, this was bug#3674!
Applied:
sstate.bbclass:specify function dirs to avoid race
http://cgit.openembedded.org/openembedded-core/commit/?id=ccef1cf783669a4683eda9d4b44dbe6bcf426259
Tested with success. Thanks a lot!
Regards,
Matthieu Crapet
De : openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] De la part de ChenQi
Envoyé : jeudi 10 janvier 2013 03:32
À : openembedded-core@lists.openembedded.org
Objet : Re: [OE-core] sstate, cache or licence issue?
On 01/10/2013 01:40 AM, Matthieu CRAPET wrote:
Dear all,
I've got some trouble with my today's update to oe-core.
I created a basic (image) recipe:
---
DESCRIPTION = A console-only production image with headers.
PR = r0
LICENSE = MIT
IMAGE_FEATURES += dev-pkgs debug-tweaks package-management
ssh-server-openssh
inherit core-image
IMAGE_INSTALL += openssh openssl directfb directfb-examples
---
I've got a do_populate_lic failure but image is generated correctly
(do_rootfs is ok). It fails in sstate_create_package
| DEBUG: Executing shell function sstate_create_package
| shell-init: error retrieving current directory: getcwd: cannot access
parent directories: No such file or directory
| chdir: error retrieving current directory: getcwd: cannot access
parent directories: No such file or directory
run.sstate_create_package.$PID
sstate_create_package() {
cd
/lingot/build/tmp-eglibc/work/rp02-ing-linux-gnueabi/test-image/1.0-r0/sstate-build-populate-lic/
TFILE=`mktemp ...
...
The problem is that the directory exists (containing
license-destdir/test-image/{COPYING.MIT,LICENSE,generic_MIT})
If re-bitbake recipe, works fine.
If I bitbake -c cleanall first + manually delete recipe directory
(/lingot/build/tmp-eglibc/work/rp02-ing-linux-gnueabi/test-image) then,
re-bitbake recipe: the do_populate_lic fails again.
More surprising: if I wait some times (few minutes). I re-get the error
but with the extra lines:
| DEBUG: Removing manifest:
/lingot/build/tmp-eglibc/deploy/licenses/test-image/LICENSE
| DEBUG: Removing manifest:
/lingot/build/tmp-eglibc/deploy/licenses/test-image/COPYING.MIT
| DEBUG: Removing manifest:
/lingot/build/tmp-eglibc/deploy/licenses/test-image/generic_MIT
| DEBUG: Removing manifest:
/lingot/build/tmp-eglibc/deploy/licenses/test-image/
I added and removed package in IMAGE_INSTALL, sometimes it passes,
sometimes not, maybe there is a concurrent access somewhere?
Maybe it's the same bug with bug#3674
(https://bugzilla.yoctoproject.org/show_bug.cgi?id=3674).
Cheers,
Chen Qi
The two logs are available here:
http://pastebin.com/raw.php?i=CVczF2vB
Notice that I'm using my own external toolchain but I don't know that It is
relevant.
Any hint appreciated here!
Regards,
Matthieu Crapet
About Ingenico (Euronext: FR125346 - ING)
Ingenico is a leading provider of payment solutions, with over 17 million
terminals deployed in more than 125 countries. Its 3,600 employees worldwide
support retailers, banks and service providers to optimize and secure their
electronic payments solutions, develop their offer of services and increase
their point of sales revenue.
More information on www.ingenico.com http://www.ingenico.com/ .
This message may contain confidential and/or privileged information. If you are
not the addressee or authorized to receive this for the addressee, you must not
use, copy, disclose or take any action based on this message or any information
herein. If you have received this message in error, please advise the sender
immediately by reply e-mail and delete this message. Thank you for your
cooperation.
P Please consider the environment before printing this e-mail
___
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] update-modules, do we need it anymore?
On Tue, Jan 8, 2013 at 9:41 AM, Laurentiu Palcu laurentiu.pa...@intel.comwrote: Hi all, While working on making all postinstalls run on host, I saw that we still use update-modules script. However, neither the kmod modprobe nor the busybox one read /etc/modules.conf file anymore which is created by update-modules script. Both scan /etc/modprobe.d/*.conf files. So, does anybody know why do we still have it around? Most modern distributions declared update-modules as obsolete and /etc/modules.conf doesn't exist anymore. Am I missing something? I've been using the autoload functionality (not heavily, but from time to time) that is currently tied to update-modules. I did a quick scan of the alternatives in oe-core, and didn't immediately see that the same thing is possible via kmod. Is that the case, or am I missing something as well ? Cheers, Bruce Thanks, Laurentiu ___ 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] update-modules, do we need it anymore?
On 01/10/2013 03:45 PM, Bruce Ashfield wrote: On Tue, Jan 8, 2013 at 9:41 AM, Laurentiu Palcu laurentiu.pa...@intel.com mailto:laurentiu.pa...@intel.com wrote: Hi all, While working on making all postinstalls run on host, I saw that we still use update-modules script. However, neither the kmod modprobe nor the busybox one read /etc/modules.conf file anymore which is created by update-modules script. Both scan /etc/modprobe.d/*.conf files. So, does anybody know why do we still have it around? Most modern distributions declared update-modules as obsolete and /etc/modules.conf doesn't exist anymore. Am I missing something? I've been using the autoload functionality (not heavily, but from time to time) that is currently tied to update-modules. I did a quick scan of the alternatives in oe-core, and didn't immediately see that the same thing is possible via kmod. Is that the case, or am I missing something as well ? This autoload functionality seems to be provided by /etc/init.d/modutils.sh which is explicitly called from update-modules script. However, modutils.sh resides in modutils-initscripts.bb recipe. So, I personally see not use for update-modules anymore... Thanks, Laurentiu Cheers, Bruce Thanks, Laurentiu ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org mailto: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] [PATCH 4/5] lib/oe/path.py: Use shutil.rmtree if the path we wish to remove is a directory.
On Thu, Jan 10, 2013 at 1:50 AM, Martin Ertsaas marti...@gmail.com wrote: On mac, os.unlink can not be done to remove directories, and so we have to explicitly use shutil.rmtree instead to support mac. As pointed out for the bitbake patch, the functions can already handle this case if you pass recurse=True, and mac isn't at all special in this context. -- Christopher Larson ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] split mtd-utils
On Wed, Jan 9, 2013 at 6:17 PM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Wed, 2013-01-09 at 17:12 +0100, Frans Meulenbroeks wrote: As I am involved in embedded systems where flash is somewhat sparse I'm always eager to save a few bytes where possible. Today I noticed that mtd-utils (1.5.0 from danny) generates for my architecture (powerpc) roughly 780k of binaries in usr/sbin. 423k of it is due to ubifs related files. Would it be desired to put this in a separate package? e.g. mtd-utils-ubi and mtd-utils-nonubi with mtd-utils itself being empty but rdepend on those two? that way mtd-utils will still give all packages but those only wanting the non ubi stuff can limit themselves to that. If desired I can give this a stab. Sounds like a sensible split to me... Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core OE-Classic already has one packaging split: PACKAGES =+ mkfs-jffs2 mkfs-ubifs Recently I faced this same issue: for ubiattach we have to install full mtd-utils (700KiB) FYI there is a recipe for ubi-utils-klibc for more extreme size optimization. http://cgit.openembedded.org/meta-openembedded/tree/meta-initramfs/recipes-devtools/mtd Cheers Andrea ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] update-modules, do we need it anymore?
On Thu, Jan 10, 2013 at 9:24 AM, Laurentiu Palcu laurentiu.pa...@intel.comwrote: On 01/10/2013 04:10 PM, Bruce Ashfield wrote: I don't have any use for the rest of update-modules, so I don't disagree on that point. I'd just like to see a form of autoload support be continued if anything happens to update-modules. But since update-modules isn't mandatory, I suppose nothing drastic will happen to it regardless, but having a modern equivalent would be nice :) Just to be clear on this. Even if update-modules is removed, modules will still be autoloaded by modutils.sh which is run in rcS.d. Also, /etc/init.d/modutils.sh can be run separately. Right, but the files that it reads are generated in kernel.bbclass, right ? If so, the generation of those files is tied to update-modules being in the DISTRO_FEATURES and available. So if update-modules is removed, we want to update the kernel.bbclass to have a different generation of the autoload config files. Bruce Thanks, Laurentiu -- 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] defining a new image: inherit image vs image_types?
On Thu, Jan 10, 2013 at 08:31:52AM -0500, Robert P. J. Day wrote:
possibly a distinction with no distinction but i wanted to throw
together a page on how one defines a new image type -- most
commonly, an SD card image -- and i started with what comes with the
meta-raspberrypi layer, which seems to work just fine.
what i noticed is that that layer introduces the new
sdcard_image-rpi.bbclass class file, which opens with:
inherit image_types
but then i remembered that the meta-ti layer does the same thing,
providing the new class file sdcard_image.bbclass which opens
instead with:
inherit image
i realize that the oe-core image.bbclass contains this snippet:
IMAGE_CLASSES ?= image_types
inherit ${IMAGE_CLASSES}
so it's clear that inheriting image is sufficient, but the
alternative *isn't* clear.
what's the preferred construction here? before digging further to
see if there's something subtle or equivalent happening, should it be
sufficient for new image definitions to simply:
inherit image_types
?? have i just not RTFS far enough to see that there's no difference?
did you read image_types.bbclass?
Cheers,
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] defining a new image: inherit image vs image_types?
On Thu, 10 Jan 2013, Martin Jansa wrote:
On Thu, Jan 10, 2013 at 08:31:52AM -0500, Robert P. J. Day wrote:
possibly a distinction with no distinction but i wanted to throw
together a page on how one defines a new image type -- most
commonly, an SD card image -- and i started with what comes with the
meta-raspberrypi layer, which seems to work just fine.
what i noticed is that that layer introduces the new
sdcard_image-rpi.bbclass class file, which opens with:
inherit image_types
but then i remembered that the meta-ti layer does the same thing,
providing the new class file sdcard_image.bbclass which opens
instead with:
inherit image
i realize that the oe-core image.bbclass contains this snippet:
IMAGE_CLASSES ?= image_types
inherit ${IMAGE_CLASSES}
so it's clear that inheriting image is sufficient, but the
alternative *isn't* clear.
what's the preferred construction here? before digging further to
see if there's something subtle or equivalent happening, should it be
sufficient for new image definitions to simply:
inherit image_types
?? have i just not RTFS far enough to see that there's no difference?
did you read image_types.bbclass?
in fact, i'm reading it now, after verifying that the meta-ti layer
appears to be incorrect. so i think that answers my question.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] split mtd-utils
Cool, I'll have a peek at the oe classic recipe and give it a stab along the same spirit. Best regards, Frans 2013/1/10 Andrea Adami andrea.ad...@gmail.com On Wed, Jan 9, 2013 at 6:17 PM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Wed, 2013-01-09 at 17:12 +0100, Frans Meulenbroeks wrote: As I am involved in embedded systems where flash is somewhat sparse I'm always eager to save a few bytes where possible. Today I noticed that mtd-utils (1.5.0 from danny) generates for my architecture (powerpc) roughly 780k of binaries in usr/sbin. 423k of it is due to ubifs related files. Would it be desired to put this in a separate package? e.g. mtd-utils-ubi and mtd-utils-nonubi with mtd-utils itself being empty but rdepend on those two? that way mtd-utils will still give all packages but those only wanting the non ubi stuff can limit themselves to that. If desired I can give this a stab. Sounds like a sensible split to me... Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core OE-Classic already has one packaging split: PACKAGES =+ mkfs-jffs2 mkfs-ubifs Recently I faced this same issue: for ubiattach we have to install full mtd-utils (700KiB) FYI there is a recipe for ubi-utils-klibc for more extreme size optimization. http://cgit.openembedded.org/meta-openembedded/tree/meta-initramfs/recipes-devtools/mtd Cheers Andrea ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 00/21][RFC v3] systemd Integration
On Thu, Jan 10, 2013 at 12:02 AM, Radu Moisan radu.moi...@intel.com wrote: On 01/09/2013 07:14 PM, Khem Raj wrote: On Tue, Jan 8, 2013 at 4:24 AM, Radu Moisan radu.moi...@intel.com wrote: As Ross suggested I've done the following changes to the previous set: * added two patches (the first two) that address multiple init systems support,\ as in shifting from default hardcoded sysvinit to something more generic while the default values still remains on sysvinit * moved automatic setting of PREFERRED_PROVIDER_udev into default_providers.inc * removed ahavi-systemd since all it provided was service files; now service files are pulled in by avahi-daemon * also rebased on master btw. there has been more merges into meta-systemd in meta-openembedded since these patches were created I cant accertain that you picked those too but please redo this series so the history is a bit better for tracking purposes. I've tried to get in sync with meta-openembedded until they upgraded systemd to v196. hmm that would also explain the -lrt problem that Saul is seeing but I dont. I tried to upgrade but something changed in the latest version and dbus-daemon didn't start anymore and because of that a few other services depending on it. I spent some time debugging it but eventually I decided we should go with the previous version and address the update after we merge. More details about this at https://bugzilla.yoctoproject.org/show_bug.cgi?id=1625 but we have to fix it I think weather you merge it or not since I dont expect us to stay at 195 forever and especially when folks who use meta-systemd are already using 196 we wont be able to discard meta-systemd. Radu ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH V2] connman: upgrade to 1.10
From: Constantin Musca constantinx.mu...@intel.com
0002-storage.c-If-there-is-no-d_type-support-use-fstatat.patch
- adapted to the new version
0001-timezone.c-If-there-is-no-d_type-support-use-fstatat.patch
- patch removed (it is included in the new version)
inet-fix-ip-cleanup-functions.patch: added
- fix for ip cleanup functions
Signed-off-by: Constantin Musca constantinx.mu...@intel.com
Signed-off-by: Cristian Iorga cristian.io...@intel.com
---
meta/conf/layer.conf |1 +
meta/conf/machine/include/qemu.inc |2 +
meta/recipes-connectivity/connman/connman-conf.bb | 19 ++
.../connman/connman-conf/COPYING | 340
.../connman/connman-conf/qemu/main.conf| 78 +
...If-there-is-no-d_type-support-use-fstatat.patch | 61
...If-there-is-no-d_type-support-use-fstatat.patch | 38 ++-
.../connman/inet-fix-ip-cleanup-functions.patch| 40 +++
.../connman/{connman_1.4.bb = connman_1.10.bb}|8 +-
9 files changed, 507 insertions(+), 80 deletions(-)
create mode 100644 meta/recipes-connectivity/connman/connman-conf.bb
create mode 100644 meta/recipes-connectivity/connman/connman-conf/COPYING
create mode 100644
meta/recipes-connectivity/connman/connman-conf/qemu/main.conf
delete mode 100644
meta/recipes-connectivity/connman/connman/0001-timezone.c-If-there-is-no-d_type-support-use-fstatat.patch
create mode 100644
meta/recipes-connectivity/connman/connman/inet-fix-ip-cleanup-functions.patch
rename meta/recipes-connectivity/connman/{connman_1.4.bb = connman_1.10.bb}
(71%)
diff --git a/meta/conf/layer.conf b/meta/conf/layer.conf
index 78ceae9..3259e5c 100644
--- a/meta/conf/layer.conf
+++ b/meta/conf/layer.conf
@@ -22,6 +22,7 @@ SIGGEN_EXCLUDERECIPES_ABISAFE += \
shadow-securetty \
opkg-config-base \
netbase \
+ connman-conf \
formfactor \
xserver-xf86-config \
pointercal \
diff --git a/meta/conf/machine/include/qemu.inc
b/meta/conf/machine/include/qemu.inc
index 5d59a7f..41fe552 100644
--- a/meta/conf/machine/include/qemu.inc
+++ b/meta/conf/machine/include/qemu.inc
@@ -10,6 +10,8 @@ XSERVER ?= xserver-xorg \
MACHINE_FEATURES = apm alsa pcmcia bluetooth irda usbgadget screen
+MACHINEOVERRIDES .= :qemu
+
IMAGE_FSTYPES += tar.bz2 ext3
ROOT_FLASH_SIZE = 280
diff --git a/meta/recipes-connectivity/connman/connman-conf.bb
b/meta/recipes-connectivity/connman/connman-conf.bb
new file mode 100644
index 000..a6a6f53
--- /dev/null
+++ b/meta/recipes-connectivity/connman/connman-conf.bb
@@ -0,0 +1,19 @@
+#connman config to ignore wired interfaces on qemu machines
+
+LICENSE = GPLv2
+LIC_FILES_CHKSUM =
file://${WORKDIR}/COPYING;md5=12f884d2ae1ff87c09e5b7ccc2c4ca7e
+
+SRC_URI = file://COPYING
+SRC_URI_append_qemu = file://main.conf
+
+PR = r0
+
+PACKAGE_ARCH = ${MACHINE_ARCH}
+
+do_install() {
+#Blacklist ethn network interface in case of qemu* machines
+if test -e ${WORKDIR}/main.conf; then
+install -d ${D}${sysconfdir}/connman
+install -m 0644 ${WORKDIR}/main.conf ${D}${sysconfdir}/connman
+fi
+}
diff --git a/meta/recipes-connectivity/connman/connman-conf/COPYING
b/meta/recipes-connectivity/connman/connman-conf/COPYING
new file mode 100644
index 000..6d45519
--- /dev/null
+++ b/meta/recipes-connectivity/connman/connman-conf/COPYING
@@ -0,0 +1,340 @@
+ GNU GENERAL PUBLIC LICENSE
+ Version 2, June 1991
+
+ Copyright (C) 1989, 1991 Free Software Foundation, Inc.
+ 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+
+ Preamble
+
+ The licenses for most software are designed to take away your
+freedom to share and change it. By contrast, the GNU General Public
+License is intended to guarantee your freedom to share and change free
+software--to make sure the software is free for all its users. This
+General Public License applies to most of the Free Software
+Foundation's software and to any other program whose authors commit to
+using it. (Some other Free Software Foundation software is covered by
+the GNU Library General Public License instead.) You can apply it to
+your programs, too.
+
+ When we speak of free software, we are referring to freedom, not
+price. Our General Public Licenses are designed to make sure that you
+have the freedom to distribute copies of free software (and charge for
+this service if you wish), that you receive source code or can get it
+if you want it, that you can change the software or use pieces of it
+in new free programs; and that you know you can do these things.
+
+ To protect your rights, we need to make restrictions that forbid
+anyone to deny you these rights or to ask you to surrender the rights.
+These restrictions translate to certain
Re: [OE-core] [PATCH] connman: upgrade to 1.10
Hello all, In SIGGEN_EXCLUDERECIPES_ABISAFE only connman-conf needs to be added, or connman + connman-conf? (see my V2 patch for connman 1.10 upgrade) Regards, Cristian -Original Message- From: Martin Jansa [mailto:martin.ja...@gmail.com] Sent: Thursday, January 10, 2013 10:58 AM To: Burton, Ross Cc: Iorga, Cristian; openembedded-core@lists.openembedded.org Subject: Re: [OE-core] [PATCH] connman: upgrade to 1.10 On Thu, Jan 10, 2013 at 07:56:30AM +, Ross Burton wrote: On Thursday, 10 January 2013 at 07:15, Iorga, Cristian wrote: Well, I have the prior art stand by me. The same technique is applied for netbase. And, in this specific case, connman should be machine specific. Can you please give me more detail? The configuration file will have only the interface blacklist enabled in case of a qemu* machine. netbase is a lot smaller than connman. and also listed in SIGGEN_EXCLUDERECIPES_ABISAFE With this change you're rebuilding connman per-machine instead of sharing the package between compatible machines, with the only difference being a configuration file. And rebuilding also all stuff depending on connman. Cheers, -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] connman: upgrade to 1.10
On Thu, Jan 10, 2013 at 06:47:26PM +, Iorga, Cristian wrote: Hello all, In SIGGEN_EXCLUDERECIPES_ABISAFE only connman-conf needs to be added, or connman + connman-conf? (see my V2 patch for connman 1.10 upgrade) connman-conf only, V2 looks better Cheers, Regards, Cristian -Original Message- From: Martin Jansa [mailto:martin.ja...@gmail.com] Sent: Thursday, January 10, 2013 10:58 AM To: Burton, Ross Cc: Iorga, Cristian; openembedded-core@lists.openembedded.org Subject: Re: [OE-core] [PATCH] connman: upgrade to 1.10 On Thu, Jan 10, 2013 at 07:56:30AM +, Ross Burton wrote: On Thursday, 10 January 2013 at 07:15, Iorga, Cristian wrote: Well, I have the prior art stand by me. The same technique is applied for netbase. And, in this specific case, connman should be machine specific. Can you please give me more detail? The configuration file will have only the interface blacklist enabled in case of a qemu* machine. netbase is a lot smaller than connman. and also listed in SIGGEN_EXCLUDERECIPES_ABISAFE With this change you're rebuilding connman per-machine instead of sharing the package between compatible machines, with the only difference being a configuration file. And rebuilding also all stuff depending on connman. Cheers, -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/3] Misc patches
A couple of already sent patches that have been ignored (patchwork issues?)
The following changes since commit 0cfec10c4c7b0597f0e0c8f85539d901861a2f83:
guile: add explicit dependency to avoid parallel build issue (2013-01-09
13:41:12 +)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib cazfi/misc
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=cazfi/misc
Marko Lindqvist (3):
libxdamage: update to upstream version 1.1.4
coreutils: fix license segment md5sum boundary
help2man: update to upstream version 1.40.13
meta/recipes-core/coreutils/coreutils_8.14.bb|2 +-
.../{help2man-native_1.38.2.bb = help2man-native_1.40.13.bb}|6 +++---
.../xorg-lib/{libxdamage_1.1.3.bb = libxdamage_1.1.4.bb}|6 +++---
3 files changed, 7 insertions(+), 7 deletions(-)
rename meta/recipes-devtools/help2man/{help2man-native_1.38.2.bb =
help2man-native_1.40.13.bb} (78%)
rename meta/recipes-graphics/xorg-lib/{libxdamage_1.1.3.bb =
libxdamage_1.1.4.bb} (86%)
--
1.7.10.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH V2] connman: upgrade to 1.10
On Thursday, 10 January 2013 at 19:07, Saul Wold wrote: I am not wild about us having to carry around the COPYING file for GPLv2 as a patch file, is there any way use the existing copies we have in meta/files/common-licenses? I think that sysvinit-inittab uses the following: It's also declaring GPL on what is effectively just +NetworkInterfaceBlacklist = eth0. If we don't ship the entire example configuration file but just the two lines that we need, copyright almost certainly doesn't exist anyway. I'd prefer just shipping the fragment that we need. We don't need all of the comments and examples on the device. Ross ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH V2] connman: upgrade to 1.10
On 10 January 2013 18:42, Cristian Iorga cristian.io...@intel.com wrote: 0002-storage.c-If-there-is-no-d_type-support-use-fstatat.patch - adapted to the new version 0001-timezone.c-If-there-is-no-d_type-support-use-fstatat.patch - patch removed (it is included in the new version) inet-fix-ip-cleanup-functions.patch: added - fix for ip cleanup functions Signed-off-by: Constantin Musca constantinx.mu...@intel.com Signed-off-by: Cristian Iorga cristian.io...@intel.com Also document the point of connman-conf. diff --git a/meta/conf/machine/include/qemu.inc b/meta/conf/machine/include/qemu.inc index 5d59a7f..41fe552 100644 --- a/meta/conf/machine/include/qemu.inc +++ b/meta/conf/machine/include/qemu.inc @@ -10,6 +10,8 @@ XSERVER ?= xserver-xorg \ MACHINE_FEATURES = apm alsa pcmcia bluetooth irda usbgadget screen +MACHINEOVERRIDES .= :qemu + Please submit this as a separate patch, it's effectively unrelated to connman. Ross ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] linux-libc-headers: fix long path name build breakage
Richard/Saul, Here's a patch to fix the recent autobuilder failures with the updated linux-libc-headers (3.7) as the default. I wasn't sure if we needed a PR bump, but I added one anyone. Let me know if I should respin with it removed. I'll send this patch upstream for comments as well, but in it's current form it does get us up and running on the builders. Until this is accepted, it will be propagated to any 3.7 kernel headers, just in case they are used in a long path name configuration. Cheers, Bruce The following changes since commit 66f4c8a674d9f8db958b13866af4d63ab8cbcd44: guile: add explicit dependency to avoid parallel build issue (2013-01-09 15:05:26 +) are available in the git repository at: git://git.pokylinux.org/poky-contrib zedd/kernel http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel Bruce Ashfield (1): linux-libc-headers: fix headers install in long path name environments ...efile.headersinst-install-headers-from-sc.patch | 47 .../linux-libc-headers/linux-libc-headers_3.7.bb |4 ++ 2 files changed, 51 insertions(+) create mode 100644 meta/recipes-kernel/linux-libc-headers/linux-libc-headers/scripts-Makefile.headersinst-install-headers-from-sc.patch -- 1.7.10.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH V2] connman: upgrade to 1.10
On Thu, 2013-01-10 at 20:26 +, Burton, Ross wrote: On 10 January 2013 18:42, Cristian Iorga cristian.io...@intel.com wrote: 0002-storage.c-If-there-is-no-d_type-support-use-fstatat.patch - adapted to the new version 0001-timezone.c-If-there-is-no-d_type-support-use-fstatat.patch - patch removed (it is included in the new version) inet-fix-ip-cleanup-functions.patch: added - fix for ip cleanup functions Signed-off-by: Constantin Musca constantinx.mu...@intel.com Signed-off-by: Cristian Iorga cristian.io...@intel.com Also document the point of connman-conf. diff --git a/meta/conf/machine/include/qemu.inc b/meta/conf/machine/include/qemu.inc index 5d59a7f..41fe552 100644 --- a/meta/conf/machine/include/qemu.inc +++ b/meta/conf/machine/include/qemu.inc @@ -10,6 +10,8 @@ XSERVER ?= xserver-xorg \ MACHINE_FEATURES = apm alsa pcmcia bluetooth irda usbgadget screen +MACHINEOVERRIDES .= :qemu + Please submit this as a separate patch, it's effectively unrelated to connman. Please don't use qemu, use something like qemuall or allqemu since I have some thoughts about how this might interact with the qemu class, most involving the word badly ;-). Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] glib2.0 and dbus dependency
On Thursday, January 10, 2013 11:42:53 AM Martin Jansa wrote: On Thu, Jan 10, 2013 at 06:31:22PM +, Yi Qingliang wrote: when compiling using 4 threads, I got following error. the glib2.0-native want find dbus header file. If I compiled dbus/dbus-natigve, and then compile glib2.0 OK. when grep glib2.0 bb files, I can't find dbus in dependency, why? It was causing cyclic dependency at least when dbus tests were enabled, I'm not sure if this was resolved already. cyclic dependency OMG, do they really need 'cyclic dependency'? splitting them cannot solve 'cyclic dependency'? am i right? ERROR: Function failed: do_compile (see /mnt/src/arm9plf- build/tmp/work/x86_64-linux/glib-2.0-native/1_2.34.3- r0/temp/log.do_compile.28193 for further information) ERROR: Task 1851 (virtual:native:/mnt/src/optimus/poky/meta/recipes- core/glib-2.0/glib-2.0_2.34.3.bb, do_compile) failed with exit code '1' NOTE: Tasks Summary: Attempted 929 tasks of which 925 didn't need to be rerun and 1 failed. Waiting for 0 running tasks to finish: Summary: 1 task failed: virtual:native:/mnt/src/optimus/poky/meta/recipes- core/glib-2.0/glib-2.0_2.34.3.bb, do_compile Summary: There was 1 ERROR message shown, returning a non-zero exit code. ___ 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] glib2.0 and dbus dependency
On Fri, Jan 11, 2013 at 09:18:06AM +, Yi Qingliang wrote: On Thursday, January 10, 2013 11:42:53 AM Martin Jansa wrote: On Thu, Jan 10, 2013 at 06:31:22PM +, Yi Qingliang wrote: when compiling using 4 threads, I got following error. the glib2.0-native want find dbus header file. If I compiled dbus/dbus-natigve, and then compile glib2.0 OK. when grep glib2.0 bb files, I can't find dbus in dependency, why? It was causing cyclic dependency at least when dbus tests were enabled, I'm not sure if this was resolved already. cyclic dependency OMG, do they really need 'cyclic dependency'? splitting them cannot solve 'cyclic dependency'? am i right? Please check first if this is still valid: http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-December/027987.html I think it was resolved somewhere, but I'm not sure or you can just add it and see if it fails :). Cheers, -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] Fwd: Re: [poky] [PATCH] initscripts: added save-rtc to runlevel S
Original Message Subject:Re: [poky] [PATCH] initscripts: added save-rtc to runlevel S Date: Thu, 10 Jan 2013 11:20:16 -0800 From: Felipe Ferreri Tonello e...@felipetonello.com To: ChenQi qi.c...@windriver.com Chen Can you please send this email to the mailing list, so we can discuss there? Thank you, Felipe On 01/09/2013 06:23 PM, ChenQi wrote: On 01/10/2013 01:57 AM, Felipe Ferreri Tonello wrote: Hi Chen, Thank you for your answer. On 01/09/2013 12:16 AM, ChenQi wrote: On 01/09/2013 01:35 PM, Felipe Ferreri Tonello wrote: Hi Chen, On 01/08/2013 06:16 PM, ChenQi wrote: On 01/09/2013 08:18 AM, e...@felipetonello.com wrote: From: Felipe F. Tonello ftone...@cercacor.com It is necessary to add save-rtc.sh to runlevel S so the system is updated when it boots up. Hi ftonello, What do you mean by system is updated? I meant system clock. What is happening now is that when you turn off the device, without system halt, the next time the device is booted up the system clock is not in sync with the rtc. Hi Felipe, I'm sorry, but I really don't see why this patch works. Below is my understanding for the system clock, hardware clock and /etc/timestamp. (The file name 'save-rtc.sh' is somewhat misleading, 'save-timestamp.sh' would be a more reasonable one.) /etc/timestamp is used to provide a reasonable reference for system time. The initial contents in this file is the building time of the image. The system clock should always be in sync with the rtc as long as the /etc/init.d/hwclock.sh is present, whose main purpose is to sync system clock and hardware clock. No matter whether the system is shutdown normally or crashes, the system clock is according to the hardware clock by hwclock.sh. Is there anything special to enable hwclock.sh? In the current project, hwclock.sh is invoked in bootmisc.sh if /etc/init.d/hwclock.sh exists. Although there are symlinks in /etc/rc[2345].d/ like Sxxhwclock.sh - ../init.d/hwclock.sh, they have no real effect! This is a bug scheduled to be solved. For more details, refer to https://bugzilla.yoctoproject.org/show_bug.cgi?id=3612. For a temporary workaround, change the link names from 'hwclock.sh' to 'hwclock'. This bug will be solved soon :) Cheers, Chen Qi I understand what you say, but here that patch was the only way to have system clock (down to minutes, also, or even seconds, don't recall) sync up with the rtc. Btw, this patch I did few months ago. So I don't remember exactly what was happening. Do you know by the top of your mind how is this process? Because, as I remember, save-rtc.sh was never been called. I'm not sure. Felipe ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] glib2.0 and dbus dependency
On Friday, January 11, 2013 02:52:12 AM Martin Jansa wrote:
On Fri, Jan 11, 2013 at 09:18:06AM +, Yi Qingliang wrote:
On Thursday, January 10, 2013 11:42:53 AM Martin Jansa wrote:
On Thu, Jan 10, 2013 at 06:31:22PM +, Yi Qingliang wrote:
when compiling using 4 threads, I got following error.
the glib2.0-native want find dbus header file.
If I compiled dbus/dbus-natigve, and then compile glib2.0 OK.
when grep glib2.0 bb files, I can't find dbus in dependency, why?
It was causing cyclic dependency at least when dbus tests were enabled,
I'm not sure if this was resolved already.
cyclic dependency OMG, do they really need 'cyclic dependency'?
splitting them cannot solve 'cyclic dependency'? am i right?
Please check first if this is still valid:
http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-December/027987
.html
I think it was resolved somewhere, but I'm not sure or you can just add
it and see if it fails :).
indeed, I can't got 'just add what',
maybe you mean just add 'dbus' in glib2.0's DEPENDS?
I checked the glib2.0, found:
RDEPENDS_${PN}-ptest += \
..
python-dbus \
and the 'python-dbus' depends on 'dbus'.
but for glib2.0, it's compiling need dbus, not only running.
Cheers,
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] initscripts: remove finish.sh
From: Chen Qi qi.c...@windriver.com The following changes since commit 66f4c8a674d9f8db958b13866af4d63ab8cbcd44: guile: add explicit dependency to avoid parallel build issue (2013-01-09 15:05:26 +) are available in the git repository at: git://git.pokylinux.org/poky-contrib ChenQi/rm-finish.sh http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/rm-finish.sh Chen Qi (1): initscripts: remove finish.sh .../initscripts/initscripts-1.0/finish.sh | 14 -- meta/recipes-core/initscripts/initscripts_1.0.bb |7 ++- 2 files changed, 2 insertions(+), 19 deletions(-) delete mode 100755 meta/recipes-core/initscripts/initscripts-1.0/finish.sh -- 1.7.9.5 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] initscripts: remove finish.sh
From: Chen Qi qi.c...@windriver.com
Remove finish.sh from initscripts as it is no longer used.
Signed-off-by: Chen Qi qi.c...@windriver.com
---
.../initscripts/initscripts-1.0/finish.sh | 14 --
meta/recipes-core/initscripts/initscripts_1.0.bb |7 ++-
2 files changed, 2 insertions(+), 19 deletions(-)
delete mode 100755 meta/recipes-core/initscripts/initscripts-1.0/finish.sh
diff --git a/meta/recipes-core/initscripts/initscripts-1.0/finish.sh
b/meta/recipes-core/initscripts/initscripts-1.0/finish.sh
deleted file mode 100755
index 183a384..000
--- a/meta/recipes-core/initscripts/initscripts-1.0/finish.sh
+++ /dev/null
@@ -1,14 +0,0 @@
-#!/bin/sh
-### BEGIN INIT INFO
-# Provides: finish.sh
-# Required-Start:$remote_fs rmnologin
-# Required-Stop:
-# Default-Start: 2 3 4 5
-# Default-Stop:
-# Short-Description: Finish system start
-# Description:
-### END INIT INFO
-
-if ! test -e /etc/.configured; then
-/etc/.configured
-fi
diff --git a/meta/recipes-core/initscripts/initscripts_1.0.bb
b/meta/recipes-core/initscripts/initscripts_1.0.bb
index 39be9a8..6e15f88 100644
--- a/meta/recipes-core/initscripts/initscripts_1.0.bb
+++ b/meta/recipes-core/initscripts/initscripts_1.0.bb
@@ -3,7 +3,7 @@ DESCRIPTION = Initscripts provide the basic system startup
initialization scrip
SECTION = base
LICENSE = GPLv2
LIC_FILES_CHKSUM = file://COPYING;md5=751419260aa954499f7abaabaa882bbe
-PR = r138
+PR = r139
INHIBIT_DEFAULT_DEPS = 1
@@ -15,7 +15,6 @@ SRC_URI = file://functions \
file://hostname.sh \
file://mountall.sh \
file://banner.sh \
- file://finish.sh \
file://bootmisc.sh \
file://mountnfs.sh \
file://reboot \
@@ -31,7 +30,7 @@ SRC_URI = file://functions \
file://populate-volatile.sh \
file://volatiles \
file://save-rtc.sh \
- file://GPLv2.patch
+ file://GPLv2.patch
SRC_URI_append_arm = file://alignment.sh
@@ -69,7 +68,6 @@ do_install () {
install -m 0644${WORKDIR}/functions ${D}${sysconfdir}/init.d
install -m 0755${WORKDIR}/bootmisc.sh ${D}${sysconfdir}/init.d
install -m 0755${WORKDIR}/checkroot.sh ${D}${sysconfdir}/init.d
-# install -m 0755${WORKDIR}/finish.sh ${D}${sysconfdir}/init.d
install -m 0755${WORKDIR}/halt ${D}${sysconfdir}/init.d
install -m 0755${WORKDIR}/hostname.sh ${D}${sysconfdir}/init.d
install -m 0755${WORKDIR}/mountall.sh ${D}${sysconfdir}/init.d
@@ -123,7 +121,6 @@ do_install () {
ln -sf ../init.d/mountnfs.sh
${D}${sysconfdir}/rcS.d/S45mountnfs.sh
ln -sf ../init.d/bootmisc.sh
${D}${sysconfdir}/rcS.d/S55bootmisc.sh
# ln -sf ../init.d/urandom
${D}${sysconfdir}/rcS.d/S55urandom
-# ln -sf ../init.d/finish.sh
${D}${sysconfdir}/rcS.d/S99finish.sh
ln -sf ../init.d/sysfs.sh
${D}${sysconfdir}/rcS.d/S02sysfs.sh
# udev will run at S03 if installed
ln -sf ../init.d/populate-volatile.sh
${D}${sysconfdir}/rcS.d/S37populate-volatile.sh
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 4/5] lib/oe/path.py: Use shutil.rmtree if the path we wish to remove is a directory.
On 01/10/13 15:15, Chris Larson wrote: On Thu, Jan 10, 2013 at 1:50 AM, Martin Ertsaas marti...@gmail.com mailto:marti...@gmail.com wrote: On mac, os.unlink can not be done to remove directories, and so we have to explicitly use shutil.rmtree instead to support mac. As pointed out for the bitbake patch, the functions can already handle this case if you pass recurse=True, and mac isn't at all special in this context. -- Christopher Larson True. In this case though, I feel the patch is still valid though, and that I should instead change the commit message. What I want from this patch, as I see it again now, is to not duplicate the same code in both bitbake and oe-core, when the oe-core function 'remove' can just be calling bb.utils.remove. So personally I still want this patch, I just wish to change the commit message to something sane. Agreed? - Martin ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [for-denzil 3/3] bitbake: command: Fix getCmdLineAction bugs
From: Richard Purdie richard.pur...@linuxfoundation.org Executing bitbake doesn't get a sane message since the None return value wasn't being handled correctly. Also fix msg - cmd_action['msg'] as otherwise an invalid variable is accessed which then crashes the server due to the previous bug. (Bitbake rev: c6211291ae07410832031a5274690437cc2b09a6) Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org --- bitbake/lib/bb/command.py |6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/bitbake/lib/bb/command.py b/bitbake/lib/bb/command.py index c08e2ce..a143aed 100644 --- a/bitbake/lib/bb/command.py +++ b/bitbake/lib/bb/command.py @@ -148,8 +148,10 @@ class CommandsSync: Get any command parsed from the commandline cmd_action = command.cooker.commandlineAction -if cmd_action['msg']: -raise CommandError(msg) +if cmd_action is None: +return None +elif 'msg' in cmd_action and cmd_action['msg']: +raise CommandError(cmd_action['msg']) else: return cmd_action['action'] -- 1.7.9.7 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [for-denzil 2/3] bitbake: command: Add missing import traceback
From: Richard Purdie richard.pur...@linuxfoundation.org Without this, if an exception occurs the server will silently crash with no feedback to the user about why (since traceback isn't imported). (Bitbake rev: e637a635bf7b5a9a2e9dc20afc18aceec98d578f) Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org --- bitbake/lib/bb/command.py |1 + 1 file changed, 1 insertion(+) diff --git a/bitbake/lib/bb/command.py b/bitbake/lib/bb/command.py index 00b854e..c08e2ce 100644 --- a/bitbake/lib/bb/command.py +++ b/bitbake/lib/bb/command.py @@ -69,6 +69,7 @@ class Command: except CommandError as exc: return None, exc.args[0] except Exception: +import traceback return None, traceback.format_exc() else: return result, None -- 1.7.9.7 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
