[OE-core] [PATCH] xserver-xf86-config: Loading glx module
From: Sujith H sujith_harida...@mentor.com This module was required to get opengl working with Qt5 version 5.4 ( when tested with qemuarm and qemux86). After adding this change to the xorg.conf and restarting xserver qtquick and qtdeclarative examples of Qt5 started working appropriately. Signed-off-by: Sujith H sujith_harida...@mentor.com Signed-off-by: Sujith H sujit...@gmail.com --- meta/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bb | 7 +++ 1 file changed, 7 insertions(+) diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bb b/meta/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bb index 549c7c8..bcd9d8a 100644 --- a/meta/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bb +++ b/meta/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bb @@ -17,4 +17,11 @@ do_install () { install -d ${D}/${sysconfdir}/X11 install -m 0644 ${WORKDIR}/xorg.conf ${D}/${sysconfdir}/X11/ fi +if ${@bb.utils.contains('DISTRO_FEATURES','x11','true','false',d)}; then +cat ${D}/${sysconfdir}/X11/xorg.conf EOF +Section Module +Load glx +EndSection +EOF +fi } -- 1.8.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] qt4: Fix QT4 applications spamming QWSLock::down(): Invalid argument
If you run a QT server application, and a client in a separate process, it will spam the log with QWSLock::down(): Invalid argument messages because of an old bug in the locking code. There's a patch on the net that fixes it, which I manually adapted by removing the commented-out debug statements. We have been using this patch for about half a year without problems, and the QT people apparently don't care about the bug, hence there's no upstream status. Including this into OE core will at least save other people the trouble of having to find and apply it for themselves. Signed-off-by: Mike Looijmans mike.looijm...@topic.nl --- meta/recipes-qt/qt4/qt4-4.8.6.inc |1 + 1 file changed, 1 insertion(+) diff --git a/meta/recipes-qt/qt4/qt4-4.8.6.inc b/meta/recipes-qt/qt4/qt4-4.8.6.inc index 074e82d..a2c0688 100644 --- a/meta/recipes-qt/qt4/qt4-4.8.6.inc +++ b/meta/recipes-qt/qt4/qt4-4.8.6.inc @@ -26,6 +26,7 @@ SRC_URI = http://download.qt-project.org/official_releases/qt/4.8/${PV}/qt-ever file://0030-aarch64_arm64_qatomic_support.patch \ file://0031-aarch64_arm64_mkspecs.patch \ file://0032-aarch64_add_header.patch \ + file://Fix-QWSLock-invalid-argument-logs.patch \ file://g++.conf \ file://linux.conf \ -- 1.7.9.5 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] qt4: Fix QT4 applications spamming QWSLock::down(): Invalid argument
If you run a QT server application, and a client in a separate process, it will spam the log with QWSLock::down(): Invalid argument messages because of an old bug in the locking code. There's a patch on the net that fixes it, which I manually adapted by removing the commented-out debug statements. We have been using this patch for about half a year without problems, and the QT people apparently don't care about the bug, hence there's no upstream status. Including this into OE core will at least save other people the trouble of having to find and apply it for themselves. Signed-off-by: Mike Looijmans mike.looijm...@topic.nl --- v2: The actual patch file was missing in the commit, added it. meta/recipes-qt/qt4/qt4-4.8.6.inc |1 + .../Fix-QWSLock-invalid-argument-logs.patch| 94 2 files changed, 95 insertions(+) create mode 100644 meta/recipes-qt/qt4/qt4-4.8.6/Fix-QWSLock-invalid-argument-logs.patch diff --git a/meta/recipes-qt/qt4/qt4-4.8.6.inc b/meta/recipes-qt/qt4/qt4-4.8.6.inc index 074e82d..a2c0688 100644 --- a/meta/recipes-qt/qt4/qt4-4.8.6.inc +++ b/meta/recipes-qt/qt4/qt4-4.8.6.inc @@ -26,6 +26,7 @@ SRC_URI = http://download.qt-project.org/official_releases/qt/4.8/${PV}/qt-ever file://0030-aarch64_arm64_qatomic_support.patch \ file://0031-aarch64_arm64_mkspecs.patch \ file://0032-aarch64_add_header.patch \ + file://Fix-QWSLock-invalid-argument-logs.patch \ file://g++.conf \ file://linux.conf \ diff --git a/meta/recipes-qt/qt4/qt4-4.8.6/Fix-QWSLock-invalid-argument-logs.patch b/meta/recipes-qt/qt4/qt4-4.8.6/Fix-QWSLock-invalid-argument-logs.patch new file mode 100644 index 000..8832c6c --- /dev/null +++ b/meta/recipes-qt/qt4/qt4-4.8.6/Fix-QWSLock-invalid-argument-logs.patch @@ -0,0 +1,94 @@ +From 52c34001bad85c3032618070b1d6b2a3c6880715 Mon Sep 17 00:00:00 2001 +From: Neil Jerram n...@ossau.homelinux.net +Date: Thu, 8 Nov 2012 08:18:32 + +Subject: [PATCH] Fix QWSLock invalid argument logs + +There was no known actual problem associated with these logs, but they +were spamming the log, so I thought it worth trying to understand and +fix them. + +The confusion is that there are two different ways of creating QWSLock +objects. QWSLock() creates an object that creates a new set of +semaphores, whereas QWSLock(id) creates an object that aliases the +existing set of semaphores with ID id. What seems to happen is that +each application creates a semaphore set scoped to that +application (QWSDisplay::Data::clientLock in qapplication_qws.cpp), +then this semaphore set is passed by complex means to +places (QWSClientPrivate and QWSMemorySurface) that use the semaphores +for a short period and then delete their QWSLock objects. + +The problem was that the QWSLock destructor always destroyed the +semaphore set, even when that QWSLock hadn't create the semaphores +itself, hence making the semaphores invalid for other QWSLock objects +still referencing the same set. + +Clearly a QWSLock object shouldn't destroy the semaphore set if it +didn't create it itself, and that is confirmed by the fact that one of +the implementations inside QWSLock already implements this logic, with +the 'owned' flag. The fix is to implement this for the #ifndef +QT_POSIX_IPC case - which is what is used in QtMoko - just as is +already implemented for the #ifdef QT_POSIX_IPC case. + +Modified by Mike Looijmans to remove the commented-out debug statements. + +--- + +diff --git a/src/gui/embedded/qwslock.cpp b/src/gui/embedded/qwslock.cpp +index 9914a24..1055785 100644 +--- a/src/gui/embedded/qwslock.cpp b/src/gui/embedded/qwslock.cpp +@@ -83,9 +83,13 @@ QWSLock::QWSLock(int id) : semId(id) + QWSSignalHandler::instance()-addWSLock(this); + #endif + ++owned = false; ++ + #ifndef QT_POSIX_IPC + if (semId == -1) { + semId = semget(IPC_PRIVATE, 3, IPC_CREAT | 0666); ++owned = true; ++ //qDebug(QWSLock::QWSLock(): %p, %d, this, (int)semId); + if (semId == -1) { + perror(QWSLock::QWSLock); + qFatal(Unable to create semaphore); +@@ -100,7 +104,6 @@ QWSLock::QWSLock(int id) : semId(id) + } + #else + sems[0] = sems[1] = sems[2] = SEM_FAILED; +-owned = false; + + if (semId == -1) { + // ### generate really unique IDs +@@ -134,9 +137,12 @@ QWSLock::~QWSLock() + + if (semId != -1) { + #ifndef QT_POSIX_IPC +-qt_semun semval; +-semval.val = 0; +-semctl(semId, 0, IPC_RMID, semval); ++ if (owned) { ++ qt_semun semval; ++ semval.val = 0; ++ semctl(semId, 0, IPC_RMID, semval); ++ } ++ //qDebug(QWSLock::~QWSLock(): %p, %d, this, (int)semId); + semId = -1; + #else + // emulate the SEM_UNDO behavior for the BackingStore lock +diff --git a/src/gui/embedded/qwslock_p.h b/src/gui/embedded/qwslock_p.h +index d324e4f..d867d20
[OE-core] [PATCH 1/1] archiver: archived files contain symbol link files
The archived files contains symbol link files. These files can not be accessed out of the building host. Copy files instead of creating symbol link when archiving. Signed-off-by: Jian Liu jian@windriver.com --- meta/lib/oe/patch.py | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/meta/lib/oe/patch.py b/meta/lib/oe/patch.py index b838be8..324a37e 100644 --- a/meta/lib/oe/patch.py +++ b/meta/lib/oe/patch.py @@ -432,7 +432,15 @@ class QuiltTree(PatchSet): if not self.initialized: self.InitFromDir() PatchSet.Import(self, patch, force) -oe.path.symlink(patch[file], self._quiltpatchpath(patch[file]), force=True) + +# if archiver work is being done, symbol link can not be used +src_file = patch[file] +des_file = self._quiltpatchpath(patch[file]) +if archiver in des_file: + os.system(cp %s %s%(src_file,des_file)) +else: + oe.path.symlink(src_file, des_file, force=True) + f = open(os.path.join(self.dir, patches,series), a); f.write(os.path.basename(patch[file]) + -p + patch[strippath]+\n) f.close() -- 1.8.3.2 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] What is expected of a kernel recipe nowadays?
On Tue, Jan 06, 2015 at 08:14:33AM +0100, Mike Looijmans wrote: On 01/05/2015 09:18 PM, Bruce Ashfield wrote: On Mon, Jan 5, 2015 at 3:29 AM, Mike Looijmans mike.looijm...@topic.nl wrote: I think I found it. The kernel bbclass changes S to point elsewhere. Moving the statement S = ${WORKDIR}/git to after the inherit kernel line makes the compile run again. Interesting. Can you confirm that Richard's commit: - commit 1dd37a2a9960ad26e27567d1871d78bec336e1a2 Author: Richard Purdie richard.pur...@linuxfoundation.org Date: Fri Dec 19 17:46:27 2014 + kernel: Fix non linux-yocto builds After the recent kernel changes, non linux-yocto builds stopped working properly for two reasons: a) ${S} was being reset to ${WORKDIR}/git for example and STAGING_KERNEL_DIR did not contain the source b) Most builds were using ${B} == ${S} This patch adds a fixup to the unpack function to handle the case where ${S} != ${STAGING_KERNEL_DIR} and also set up the infrastrcture so that B != S for kernel builds from now on. The kernel build system is one of the best for supporting this and there is no good reason not to take advantage of it. (From OE-Core rev: 106dab2fd0321e6b4e77b40111e59a3a31d329d4) Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org Is in your tree ? it should be fixing things up and allowing the source to be found. Yes, this is the part that changes S and it's how I discovered to move the assignment to after inheriting it. Alternatively, if you drop the explicit set of S, does the build start working again ? If I just remove the S=... line, it fails in the same way. The git fetch apparently places the code at WORKDIR/git where the new kernel recipe cannot find it. FWIW: I'm also seeing various kernel failures since the changes. Most my kernel are also using linux.inc from meta-oe which wasn't updated yet (I plan to look into it soon, unless someone else beats me to it) The worst part is that some of these issues are random (the race-condition showing more often than before). 1) do_unpack failing: ERROR: Error executing a python function in /home/jenkins/workspace/luneos-unstable/webos-ports/meta-smartphone/meta-samsung/recipes-kernel/linux/linux-samsung-tuna_git.bb: The stack trace of python calls that resulted in this exception/failure was: File: 'base_do_unpack', lineno: 24, function: module 0020:subprocess.call(d.expand(mv /home/jenkins/workspace/luneos-unstable/webos-ports/tmp-glibc/work/maguro-webos-linux-gnueabi/linux-samsung-tuna/3_3.0.72+gitrAUTOINC+f8ed73f94a-r12/git/ /home/jenkins/workspace/luneos-unstable/webos-ports/tmp-glibc/sysroots/maguro/usr/src/kernel), shell=True) 0021:os.symlink(kernsrc, s) 0022: 0023: *** 0024:base_do_unpack(d) 0025: File: 'base_do_unpack', lineno: 21, function: base_do_unpack 0017:bb.utils.mkdirhier(kernsrc) 0018:bb.utils.remove(kernsrc, recurse=True) 0019:import subprocess 0020:subprocess.call(d.expand(mv /home/jenkins/workspace/luneos-unstable/webos-ports/tmp-glibc/work/maguro-webos-linux-gnueabi/linux-samsung-tuna/3_3.0.72+gitrAUTOINC+f8ed73f94a-r12/git/ /home/jenkins/workspace/luneos-unstable/webos-ports/tmp-glibc/sysroots/maguro/usr/src/kernel), shell=True) *** 0021:os.symlink(kernsrc, s) 0022: 0023: 0024:base_do_unpack(d) 0025: Exception: OSError: [Errno 2] No such file or directory ERROR: Function failed: base_do_unpack ERROR: Logfile of failure stored in: /home/jenkins/workspace/luneos-unstable/webos-ports/tmp-glibc/work/maguro-webos-linux-gnueabi/linux-samsung-tuna/3_3.0.72+gitrAUTOINC+f8ed73f94a-r12/temp/log.do_unpack.13495 2) do_configure failing: ERROR: Function failed: do_configure (log file is located at /home/jenkins/workspace/luneos-unstable/webos-ports/tmp-glibc/work/mako-webos-linux-gnueabi/linux-lg-mako/3.4.0+gitrAUTOINC+38bdbfe224-r0/temp/log.do_configure.17498) ERROR: Logfile of failure stored in: /home/jenkins/workspace/luneos-unstable/webos-ports/tmp-glibc/work/mako-webos-linux-gnueabi/linux-lg-mako/3.4.0+gitrAUTOINC+38bdbfe224-r0/temp/log.do_configure.17498 Log data follows: | DEBUG: Executing python function sysroot_cleansstate | DEBUG: Python function sysroot_cleansstate finished | DEBUG: Executing shell function do_configure | NOTE: make oldconfig | make: *** No rule to make target `oldconfig'. Stop. | ERROR: oe_runmake failed | WARNING: exit code 1 from a shell command. | ERROR: Function failed: do_configure (log file is located at /home/jenkins/workspace/luneos-unstable/webos-ports/tmp-glibc/work/mako-webos-linux-gnueabi/linux-lg-mako/3.4.0+gitrAUTOINC+38bdbfe224-r0/temp/log.do_configure.17498) NOTE: recipe linux-lg-mako-3.4.0+gitrAUTOINC+38bdbfe224-r0: task do_configure:
[OE-core] [PATCH] xserver-xf86-config: Loading glx module
From: Sujith H sujith_harida...@mentor.com This module was required to get opengl working with Qt5 version 5.4 ( when tested with qemuarm and qemux86). After adding this change to the xorg.conf and restarting xserver qtquick and qtdeclarative examples of Qt5 started working appropriately. Signed-off-by: Sujith H sujith_harida...@mentor.com Signed-off-by: Sujith H sujit...@gmail.com --- meta/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bb | 7 +++ 1 file changed, 7 insertions(+) diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bb b/meta/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bb index 549c7c8..bcd9d8a 100644 --- a/meta/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bb +++ b/meta/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bb @@ -17,4 +17,11 @@ do_install () { install -d ${D}/${sysconfdir}/X11 install -m 0644 ${WORKDIR}/xorg.conf ${D}/${sysconfdir}/X11/ fi +if ${@bb.utils.contains('DISTRO_FEATURES','x11','true','false',d)}; then +cat ${D}/${sysconfdir}/X11/xorg.conf EOF +Section Module +Load glx +EndSection +EOF +fi } -- 1.8.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] What is expected of a kernel recipe nowadays?
On Tue, Jan 06, 2015 at 09:57:31AM +0100, Martin Jansa wrote: FWIW: I'm also seeing various kernel failures since the changes. Most my kernel are also using linux.inc from meta-oe which wasn't updated yet (I plan to look into it soon, unless someone else beats me to it) The worst part is that some of these issues are random (the race-condition showing more often than before). 1) do_unpack failing: ERROR: Error executing a python function in /home/jenkins/workspace/luneos-unstable/webos-ports/meta-smartphone/meta-samsung/recipes-kernel/linux/linux-samsung-tuna_git.bb: File: 'base_do_unpack', lineno: 21, function: base_do_unpack 0017:bb.utils.mkdirhier(kernsrc) 0018:bb.utils.remove(kernsrc, recurse=True) 0019:import subprocess 0020:subprocess.call(d.expand(mv /home/jenkins/workspace/luneos-unstable/webos-ports/tmp-glibc/work/maguro-webos-linux-gnueabi/linux-samsung-tuna/3_3.0.72+gitrAUTOINC+f8ed73f94a-r12/git/ /home/jenkins/workspace/luneos-unstable/webos-ports/tmp-glibc/sysroots/maguro/usr/src/kernel), shell=True) *** 0021:os.symlink(kernsrc, s) 0022: 0023: 0024:base_do_unpack(d) 0025: Exception: OSError: [Errno 2] No such file or directory This fails when S ends with slash, fix in http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/master 2) do_configure failing: ERROR: Function failed: do_configure (log file is located at /home/jenkins/workspace/luneos-unstable/webos-ports/tmp-glibc/work/mako-webos-linux-gnueabi/linux-lg-mako/3.4.0+gitrAUTOINC+38bdbfe224-r0/temp/log.do_configure.17498) ERROR: Logfile of failure stored in: /home/jenkins/workspace/luneos-unstable/webos-ports/tmp-glibc/work/mako-webos-linux-gnueabi/linux-lg-mako/3.4.0+gitrAUTOINC+38bdbfe224-r0/temp/log.do_configure.17498 Log data follows: | DEBUG: Executing python function sysroot_cleansstate | DEBUG: Python function sysroot_cleansstate finished | DEBUG: Executing shell function do_configure | NOTE: make oldconfig | make: *** No rule to make target `oldconfig'. Stop. | ERROR: oe_runmake failed | WARNING: exit code 1 from a shell command. | ERROR: Function failed: do_configure (log file is located at /home/jenkins/workspace/luneos-unstable/webos-ports/tmp-glibc/work/mako-webos-linux-gnueabi/linux-lg-mako/3.4.0+gitrAUTOINC+38bdbfe224-r0/temp/log.do_configure.17498) NOTE: recipe linux-lg-mako-3.4.0+gitrAUTOINC+38bdbfe224-r0: task do_configure: Failed ERROR: Task 491 (/home/jenkins/workspace/luneos-unstable/webos-ports/meta-smartphone/meta-lg/recipes-kernel/linux/linux-lg-mako_git.bb, do_configure) failed with exit code '1' This was caused by linux.inc, fixed in: http://lists.openembedded.org/pipermail/openembedded-devel/2015-January/099687.html 3) do_patch failing when S assignment is dropped This isn't relevant, S assignment is still needed -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] qt4: Fix QT4 applications spamming QWSLock::down(): Invalid argument
On 6 January 2015 at 10:34, Mike Looijmans mike.looijm...@topic.nl wrote: We have been using this patch for about half a year without problems, and the QT people apparently don't care about the bug, hence there's no upstream status. Including this into OE core will at least save other people the trouble of having to find and apply it for themselves. You still need an upstream-status - if it's been submitted to Qt but they're ignoring it then use Submitted and ideally put a link to the patch. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] What is expected of a kernel recipe nowadays?
On 6 January 2015 at 08:57, Martin Jansa martin.ja...@gmail.com wrote: 2) do_configure failing: ERROR: Function failed: do_configure (log file is located at /home/jenkins/workspace/luneos-unstable/webos-ports/tmp-glibc/work/mako-webos-linux-gnueabi/linux-lg-mako/3.4.0+gitrAUTOINC+38bdbfe224-r0/temp/log.do_configure.17498) ERROR: Logfile of failure stored in: /home/jenkins/workspace/luneos-unstable/webos-ports/tmp-glibc/work/mako-webos-linux-gnueabi/linux-lg-mako/3.4.0+gitrAUTOINC+38bdbfe224-r0/temp/log.do_configure.17498 Log data follows: | DEBUG: Executing python function sysroot_cleansstate | DEBUG: Python function sysroot_cleansstate finished | DEBUG: Executing shell function do_configure | NOTE: make oldconfig | make: *** No rule to make target `oldconfig'. Stop. | ERROR: oe_runmake failed | WARNING: exit code 1 from a shell command. | ERROR: Function failed: do_configure (log file is located at /home/jenkins/workspace/luneos-unstable/webos-ports/tmp-glibc/work/mako-webos-linux-gnueabi/linux-lg-mako/3.4.0+gitrAUTOINC+38bdbfe224-r0/temp/log.do_configure.17498) NOTE: recipe linux-lg-mako-3.4.0+gitrAUTOINC+38bdbfe224-r0: task do_configure: Failed ERROR: Task 491 (/home/jenkins/workspace/luneos-unstable/webos-ports/meta-smartphone/meta-lg/recipes-kernel/linux/ linux-lg-mako_git.bb, do_configure) failed with exit code '1' I'll Me Too here, often hitting this on rebuilds: DEBUG: Executing shell function do_configure NOTE: make -C /data/poky-master/tmp/sysroots/qemuarm64/usr/src/kernel O=/data/poky-master/tmp/work/qemuarm64-poky-linux/linux-yocto/3.14.24+gitAUTOINC+a227f20eff_902f34d361-r0/linux-qemuarm64-standard-build oldnoconfig make: Entering directory `/data/poky-master/tmp/sysroots/qemuarm64/usr/src/kernel' make: *** No rule to make target `oldnoconfig'. Stop. make: Leaving directory `/data/poky-master/tmp/sysroots/qemuarm64/usr/src/kernel' ERROR: Task 77 (/home/ross/Yocto/poky/meta/recipes-kernel/linux/linux-yocto_3.14.bb, do_configure) failed with exit code '1' Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] xserver-xf86-config: Loading glx module
On 6 January 2015 at 10:54, Sujith H sujit...@gmail.com wrote: +if ${@bb.utils.contains('DISTRO_FEATURES','x11','true','false',d)}; then Why would a X11-specific recipe need an X11 feature check? +cat ${D}/${sysconfdir}/X11/xorg.conf EOF +Section Module +Load glx +EndSection But GLX is automatically loaded by the xserver, My test machine doesn't have a xorg.conf and GLX loads on startup. Does your machine configuration ship a xorg.conf? Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] What is expected of a kernel recipe nowadays?
On 6 January 2015 at 11:04, Martin Jansa martin.ja...@gmail.com wrote: | make: *** No rule to make target `oldconfig'. Stop. | ERROR: oe_runmake failed | WARNING: exit code 1 from a shell command. | ERROR: Function failed: do_configure (log file is located at /home/jenkins/workspace/luneos-unstable/webos-ports/tmp-glibc/work/mako-webos-linux-gnueabi/linux-lg-mako/3.4.0+gitrAUTOINC+38bdbfe224-r0/temp/log.do_configure.17498) NOTE: recipe linux-lg-mako-3.4.0+gitrAUTOINC+38bdbfe224-r0: task do_configure: Failed ERROR: Task 491 (/home/jenkins/workspace/luneos-unstable/webos-ports/meta-smartphone/meta-lg/recipes-kernel/linux/ linux-lg-mako_git.bb, do_configure) failed with exit code '1' This was caused by linux.inc, fixed in: http://lists.openembedded.org/pipermail/openembedded-devel/2015-January/099687.html I'm replicating this error with an oe-core kernel, so there's more causes here. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] xserver-xf86-config: Loading glx module
On Tue, Jan 6, 2015 at 5:00 PM, Burton, Ross ross.bur...@intel.com wrote: On 6 January 2015 at 10:54, Sujith H sujit...@gmail.com wrote: +if ${@bb.utils.contains('DISTRO_FEATURES','x11','true','false',d)}; then Why would a X11-specific recipe need an X11 feature check? Correct, I will remove the x11 feature check from the patch. +cat ${D}/${sysconfdir}/X11/xorg.conf EOF +Section Module +Load glx +EndSection But GLX is automatically loaded by the xserver, My test machine doesn't have a xorg.conf and GLX loads on startup. Does your machine configuration ship a xorg.conf? No, we get the xorg.conf from this same recipe. And while I was testing some opengl related examples from Qt5, I was getting error saying: could not initialize glx . Hence I made a change in the recipe and added IMAGE_INSTALL_append = xserver-xorg-extension-glx and it worked fine. Hence I thought of adding this change. Let me know if there is any issues/concern. Ross -- സുജിത് ഹരിദാസന് Bangalore ProjectContributor to KDE project http://fci.wikia.com/wiki/Anti-DRM-Campaign Blog http://sujithh.info -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] xserver-xf86-config: Loading glx module
On Tue, Jan 6, 2015 at 6:38 PM, Burton, Ross ross.bur...@intel.com wrote: On 6 January 2015 at 12:51, sujith h sujit...@gmail.com wrote: saying: could not initialize glx . Hence I made a change in the recipe and added IMAGE_INSTALL_append = xserver-xorg-extension-glx and it worked fine. Hence I thought of adding this change. Let me know if there is any issues/concern. Actually installing the GLX module in the image is a prerequisite to loading the module... you don't need to modify the xorg.conf - as I said the GLX module (along with several other modules) are loaded automatically *if present*. Thanks for the clarification. I will check once again by adding glx module to the image and remove the patch and see the result. I will update here. Ross -- സുജിത് ഹരിദാസന് Bangalore ProjectContributor to KDE project http://fci.wikia.com/wiki/Anti-DRM-Campaign Blog http://sujithh.info -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] perl installation in the SDK references $OECORE_NATIVE_SYSROOT ?
Hi Jacob, On Sunday 07 December 2014 16:07:44 Jacob Kroon wrote: Like the topic says, I grepped for OECORE in the native sysroot of my SDK installation, and the only hit I got was this: usr/bin/perl:export PERL5LIB=$PERL5LIB:$OECORE_NATIVE_SYSROOT//usr/lib/perl:$OECORE_NATIVE_SYSRO OT//usr/lib/perl/5.20.0 I'm wondering if this reference is intentional, or if its something that should have been sed:ed out during sdk installation ? I believe this variable is set by the environment setup script, which we expect to be run prior to using the SDK, so yes I believe this is intentional. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] xserver-xf86-config: Loading glx module
From: Sujith H sujith_harida...@mentor.com This module was required to get opengl working with Qt5 version 5.4 ( when tested with qemuarm and qemux86). After adding this change to the xorg.conf and restarting xserver qtquick and qtdeclarative examples of Qt5 started working appropriately. Signed-off-by: Sujith H sujith_harida...@mentor.com Signed-off-by: Sujith H sujit...@gmail.com --- meta/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bb | 5 + 1 file changed, 5 insertions(+) diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bb b/meta/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bb index 549c7c8..391ebae 100644 --- a/meta/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bb +++ b/meta/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bb @@ -17,4 +17,9 @@ do_install () { install -d ${D}/${sysconfdir}/X11 install -m 0644 ${WORKDIR}/xorg.conf ${D}/${sysconfdir}/X11/ fi +cat ${D}/${sysconfdir}/X11/xorg.conf EOF +Section Module +Load glx +EndSection +EOF } -- 1.8.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3] qt4: Fix QT4 applications spamming QWSLock::down(): Invalid argument
If you run a QT server application, and a client in a separate process, it will spam the log with QWSLock::down(): Invalid argument messages because of an old bug in the locking code. There's a patch on the net that fixes it, which I manually adapted by removing the commented-out debug statements. We have been using this patch for about half a year without problems, and the QT people apparently don't care about the bug, for which this solution has been posted in 2012. Including this into OE core will at least save other people the trouble of having to find and apply it for themselves. Signed-off-by: Mike Looijmans mike.looijm...@topic.nl --- v3: Added my signoff, upstream-status and link to original patch to the patch meta/recipes-qt/qt4/qt4-4.8.6.inc |1 + .../Fix-QWSLock-invalid-argument-logs.patch| 98 2 files changed, 99 insertions(+) create mode 100644 meta/recipes-qt/qt4/qt4-4.8.6/Fix-QWSLock-invalid-argument-logs.patch diff --git a/meta/recipes-qt/qt4/qt4-4.8.6.inc b/meta/recipes-qt/qt4/qt4-4.8.6.inc index 074e82d..a2c0688 100644 --- a/meta/recipes-qt/qt4/qt4-4.8.6.inc +++ b/meta/recipes-qt/qt4/qt4-4.8.6.inc @@ -26,6 +26,7 @@ SRC_URI = http://download.qt-project.org/official_releases/qt/4.8/${PV}/qt-ever file://0030-aarch64_arm64_qatomic_support.patch \ file://0031-aarch64_arm64_mkspecs.patch \ file://0032-aarch64_add_header.patch \ + file://Fix-QWSLock-invalid-argument-logs.patch \ file://g++.conf \ file://linux.conf \ diff --git a/meta/recipes-qt/qt4/qt4-4.8.6/Fix-QWSLock-invalid-argument-logs.patch b/meta/recipes-qt/qt4/qt4-4.8.6/Fix-QWSLock-invalid-argument-logs.patch new file mode 100644 index 000..1f5f00f --- /dev/null +++ b/meta/recipes-qt/qt4/qt4-4.8.6/Fix-QWSLock-invalid-argument-logs.patch @@ -0,0 +1,98 @@ +From 52c34001bad85c3032618070b1d6b2a3c6880715 Mon Sep 17 00:00:00 2001 +From: Neil Jerram n...@ossau.homelinux.net +Date: Thu, 8 Nov 2012 08:18:32 + +Subject: [PATCH] Fix QWSLock invalid argument logs + +There was no known actual problem associated with these logs, but they +were spamming the log, so I thought it worth trying to understand and +fix them. + +The confusion is that there are two different ways of creating QWSLock +objects. QWSLock() creates an object that creates a new set of +semaphores, whereas QWSLock(id) creates an object that aliases the +existing set of semaphores with ID id. What seems to happen is that +each application creates a semaphore set scoped to that +application (QWSDisplay::Data::clientLock in qapplication_qws.cpp), +then this semaphore set is passed by complex means to +places (QWSClientPrivate and QWSMemorySurface) that use the semaphores +for a short period and then delete their QWSLock objects. + +The problem was that the QWSLock destructor always destroyed the +semaphore set, even when that QWSLock hadn't create the semaphores +itself, hence making the semaphores invalid for other QWSLock objects +still referencing the same set. + +Clearly a QWSLock object shouldn't destroy the semaphore set if it +didn't create it itself, and that is confirmed by the fact that one of +the implementations inside QWSLock already implements this logic, with +the 'owned' flag. The fix is to implement this for the #ifndef +QT_POSIX_IPC case - which is what is used in QtMoko - just as is +already implemented for the #ifdef QT_POSIX_IPC case. + +Original patch can be found here: + http://www.mail-archive.com/community@lists.openmoko.org/msg65512.html + +Upstream-Status: Submitted + +Signed-off-by: Mike Looijmans mike.looijm...@topic.nl + (Removed the commented-out debug statements from the original patch.) + +--- + +diff --git a/src/gui/embedded/qwslock.cpp b/src/gui/embedded/qwslock.cpp +index 9914a24..1055785 100644 +--- a/src/gui/embedded/qwslock.cpp b/src/gui/embedded/qwslock.cpp +@@ -83,9 +83,12 @@ QWSLock::QWSLock(int id) : semId(id) + QWSSignalHandler::instance()-addWSLock(this); + #endif + ++owned = false; ++ + #ifndef QT_POSIX_IPC + if (semId == -1) { + semId = semget(IPC_PRIVATE, 3, IPC_CREAT | 0666); ++owned = true; + if (semId == -1) { + perror(QWSLock::QWSLock); + qFatal(Unable to create semaphore); +@@ -100,7 +104,6 @@ QWSLock::QWSLock(int id) : semId(id) + } + #else + sems[0] = sems[1] = sems[2] = SEM_FAILED; +-owned = false; + + if (semId == -1) { + // ### generate really unique IDs +@@ -134,9 +137,11 @@ QWSLock::~QWSLock() + + if (semId != -1) { + #ifndef QT_POSIX_IPC +-qt_semun semval; +-semval.val = 0; +-semctl(semId, 0, IPC_RMID, semval); ++ if (owned) { ++ qt_semun semval; ++ semval.val = 0; ++ semctl(semId, 0, IPC_RMID, semval); ++ } + semId = -1; + #else + // emulate the SEM_UNDO behavior for the BackingStore lock +diff
Re: [OE-core] [PATCH] qt4: Fix QT4 applications spamming QWSLock::down(): Invalid argument
Ok, I'll add some extra information to the patch and submit a v3. M. On 01/06/2015 12:10 PM, Burton, Ross wrote: On 6 January 2015 at 10:34, Mike Looijmans mike.looijm...@topic.nl mailto:mike.looijm...@topic.nl wrote: We have been using this patch for about half a year without problems, and the QT people apparently don't care about the bug, hence there's no upstream status. Including this into OE core will at least save other people the trouble of having to find and apply it for themselves. You still need an upstream-status - if it's been submitted to Qt but they're ignoring it then use Submitted and ideally put a link to the patch. Ross Met vriendelijke groet / kind regards, Mike Looijmans System Expert TOPIC Embedded Systems Eindhovenseweg 32-C, NL-5683 KH Best Postbus 440, NL-5680 AK Best Telefoon: (+31) (0) 499 33 69 79 Telefax: (+31) (0) 499 33 69 70 E-mail: mike.looijm...@topic.nl Website: www.topic.nl Please consider the environment before printing this e-mail Topic zoekt gedreven (embedded) software specialisten! http://topic.nl/vacatures/topic-zoekt-software-engineers/ -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] xserver-xf86-config: Loading glx module
On 6 January 2015 at 12:51, sujith h sujit...@gmail.com wrote: saying: could not initialize glx . Hence I made a change in the recipe and added IMAGE_INSTALL_append = xserver-xorg-extension-glx and it worked fine. Hence I thought of adding this change. Let me know if there is any issues/concern. Actually installing the GLX module in the image is a prerequisite to loading the module... you don't need to modify the xorg.conf - as I said the GLX module (along with several other modules) are loaded automatically *if present*. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 00/12] Dizzy 1.7.1 additions
On Mon, 2015-01-05 at 12:40 -0800, Armin Kuster wrote: please consider this for inclusion for 1.7.1 Many security fixes and kernel update. The following changes since commit f4d9d7bc206aaf30ea5c72675df139425a2c8d90: lbdrm: fix build issue. (2014-12-27 08:43:41 -0800) are available in the git repository at: git://git.yoctoproject.org/poky-contrib akuster/dizzy_1_7_1 http://git.yoctoproject.org/cgit.cgi//log/?h=akuster/dizzy_1_7_1 I've merged this but it was tricky since this isn't based of the current dizzy branch. Where a patch is rejected (like the sysroot poison one), please drop it and please rebase against the current dizzy head in future. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Dizzy Merging
On Friday 02 January 2015 16:41:01 akuster808 wrote: On 12/31/2014 02:26 AM, Richard Purdie wrote: For the OE-Core patches, the gcc sysroot poison one should not go in. I'd also question the udev changes and the gcc shared work changes since those were fairly significant changes with a lot more risk. no worries. So, these patches are all still in your akuster/dizzy_1_7_1 branch. FWIW I agree, these aren't really stable branch material as far as I can tell. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] What is expected of a kernel recipe nowadays?
On Tue, Jan 6, 2015 at 6:33 AM, Burton, Ross ross.bur...@intel.com wrote: On 6 January 2015 at 11:04, Martin Jansa martin.ja...@gmail.com wrote: | make: *** No rule to make target `oldconfig'. Stop. | ERROR: oe_runmake failed | WARNING: exit code 1 from a shell command. | ERROR: Function failed: do_configure (log file is located at /home/jenkins/workspace/luneos-unstable/webos-ports/tmp-glibc/work/mako-webos-linux-gnueabi/linux-lg-mako/3.4.0+gitrAUTOINC+38bdbfe224-r0/temp/log.do_configure.17498) NOTE: recipe linux-lg-mako-3.4.0+gitrAUTOINC+38bdbfe224-r0: task do_configure: Failed ERROR: Task 491 (/home/jenkins/workspace/luneos-unstable/webos-ports/meta-smartphone/meta-lg/recipes-kernel/linux/linux-lg-mako_git.bb, do_configure) failed with exit code '1' This was caused by linux.inc, fixed in: http://lists.openembedded.org/pipermail/openembedded-devel/2015-January/099687.html I'm replicating this error with an oe-core kernel, so there's more causes here. Can you log the replicating steps and point me at the bug ? I can take any fixes from there. Bruce Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core -- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] xserver-xf86-config: Loading glx module
On Tue, Jan 6, 2015 at 6:41 PM, sujith h sujit...@gmail.com wrote: On Tue, Jan 6, 2015 at 6:38 PM, Burton, Ross ross.bur...@intel.com wrote: On 6 January 2015 at 12:51, sujith h sujit...@gmail.com wrote: saying: could not initialize glx . Hence I made a change in the recipe and added IMAGE_INSTALL_append = xserver-xorg-extension-glx and it worked fine. Hence I thought of adding this change. Let me know if there is any issues/concern. Actually installing the GLX module in the image is a prerequisite to loading the module... you don't need to modify the xorg.conf - as I said the GLX module (along with several other modules) are loaded automatically *if present*. Thanks for the clarification. I will check once again by adding glx module to the image and remove the patch and see the result. I will update here. Just now I had verified and thanks for the clarification again. It worked by removing the patch I had created and adding xserver-xorg-extension-glx to the image. Good learning for me :) Ross -- സുജിത് ഹരിദാസന് Bangalore ProjectContributor to KDE project http://fci.wikia.com/wiki/Anti-DRM-Campaign Blog http://sujithh.info -- സുജിത് ഹരിദാസന് Bangalore ProjectContributor to KDE project http://fci.wikia.com/wiki/Anti-DRM-Campaign Blog http://sujithh.info -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/1] file: add wrapper to nativesdk-file
On 11/10/14 10:07, Hongxu Jia wrote: The following changes since commit 0172cded27d73437784fe1578110937aede563eb: build-appliance-image: Update to dizzy head revision (2014-10-10 22:40:57 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib hongxu/fix-nativesdk-file http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=hongxu/fix-nativesdk-file Hongxu Jia (1): file: add wrapper to nativesdk-file meta/recipes-devtools/file/file_5.18.bb | 5 + 1 file changed, 5 insertions(+) With my most recent oe build I'm getting an error when trying to use file from the SDK. My target machine is x86 and my SDK is x86_64. Is anybody else seeing this? [jmitchell@newvsbuild filetest]$ file test.txt eng/jmitchell/oe-sensors/sdk/sysroots/x86_64-oecore-linux/usr/share/misc/magic.mgc, 1: Warning: offset `� ' invalid /eng/jmitchell/oe-sensors/sdk/sysroots/x86_64-oecore-linux/usr/share/misc/magic.mgc, 1: Warning: type `� ' invalid /eng/jmitchell/oe-sensors/sdk/sysroots/x86_64-oecore-linux/usr/share/misc/magic.mgc, 6: Warning: offset `Firmware v' invalid /eng/jmitchell/oe-sensors/sdk/sysroots/x86_64-oecore-linux/usr/share/misc/magic.mgc, 6: Warning: type `Firmware v' invalid .. /eng/jmitchell/oe-sensors/sdk/sysroots/x86_64-oecore-linux/usr/share/misc/magic.mgc, 1916: Warning: type `.' invalid file: Size of `/eng/jmitchell/oe-sensors/sdk/sysroots/x86_64-oecore-linux/usr/share/misc/magic.mgc' 3043460 is not a multiple of 248 -- Jack Mitchell (j...@embed.me.uk) Embedded Systems Engineer Cambridgeshire, UK http://www.embed.me.uk -- -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] lib/oe/terminal: add support for Terminology terminal emulator
Terminology is the default Enlightenment terminal emulator Signed-off-by: Rodrigo Chiossi rodrigo.chio...@intel.com --- meta/lib/oe/terminal.py | 4 1 file changed, 4 insertions(+) diff --git a/meta/lib/oe/terminal.py b/meta/lib/oe/terminal.py index 0a623c7..e9af726 100644 --- a/meta/lib/oe/terminal.py +++ b/meta/lib/oe/terminal.py @@ -63,6 +63,10 @@ class Xfce(XTerminal): command = 'xfce4-terminal -T {title} -e {command}' priority = 2 +class Terminology(XTerminal): +command = 'terminology -T={title} -e {command}' +priority = 2 + class Konsole(XTerminal): command = 'konsole -T {title} -e {command}' priority = 2 -- 2.1.3 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Dizzy broken for building SD cards with wic
https://bugzilla.yoctoproject.org/show_bug.cgi?id=7114 This bug also impacts dizzy now. Do we have a way to back the offending change out of dizzy while the bug is fixed? It's partly my fault the report came a week or so after we noticed it in master. Sorry for the delay getting it in the bug tracker. Philip -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 01/12] usbutils: Add version 008
On 6 January 2015 at 15:42, Saul Wold s...@linux.intel.com wrote: +FILES_${PN}-ids = ${datadir}/usb* + +RDEPENDS_${PN} = ${PN}-ids libudev The IDs are part of udev 196's hwdb, so usbutils-ids doesn't get created and this runtime dependency isn't satisfiable. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH] package.bbclass: omit .pyc and .pyo file
On 01/07/2015 09:07 AM, Robert Yang wrote: We should not ship .pyc or .pyo file, but there are a few packages ship .pyc, should we: 1) Ignore them in package.bbclass as this patch showes ? Or 2) Add a qa check then fix it by hand one by one ? 3) Fix it in a bbclass that python related recipes would generally inherit. Regards, Chen Qi Here is the list of oe-core's world build: python-smartpm-1.4.1 nativesdk-python-smartpm-1.4.1 python3-distribute-0.6.32 python-pycurl-7.19.5 python-pyrex-0.9.9 python-numpy-1.7.0 python-distribute-0.6.32 python-async-0.6.1 python-docutils-0.12 python-pycairo-1.10.0 python-scons-2.3.2 python-imaging-1.1.7 python-gitdb-0.5.4 Signed-off-by: Robert Yang liezhi.y...@windriver.com --- meta/classes/package.bbclass |6 ++ 1 file changed, 6 insertions(+) diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass index fc501fc..6960221 100644 --- a/meta/classes/package.bbclass +++ b/meta/classes/package.bbclass @@ -1022,6 +1022,9 @@ python populate_packages () { files.append(file) for file in files: +# Skip .pyc and .pyo file. +if file.endswith('.pyc') or file.endswith('.pyo'): +continue if not cpath.islink(file): if cpath.isdir(file): newfiles = [ os.path.join(file,x) for x in os.listdir(file) ] @@ -1083,6 +1086,9 @@ python populate_packages () { if not dir: dir = os.sep for f in (files + dirs): +# Skip .pyc and .pyo file. +if f.endswith('.pyc') or f.endswith('.pyo'): +continue path = os.path.join(dir, f) if ('.' + path) not in seen: unshipped.append(path) -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [daisy][PATCH] systemd: backport patch to fix reading journal backwards
Signed-off-by: Jonathan Liu net...@gmail.com --- ...-Fix-navigating-backwards-missing-entries.patch | 34 ++ meta/recipes-core/systemd/systemd_211.bb | 1 + 2 files changed, 35 insertions(+) create mode 100644 meta/recipes-core/systemd/systemd/0001-journal-Fix-navigating-backwards-missing-entries.patch diff --git a/meta/recipes-core/systemd/systemd/0001-journal-Fix-navigating-backwards-missing-entries.patch b/meta/recipes-core/systemd/systemd/0001-journal-Fix-navigating-backwards-missing-entries.patch new file mode 100644 index 000..621a0da --- /dev/null +++ b/meta/recipes-core/systemd/systemd/0001-journal-Fix-navigating-backwards-missing-entries.patch @@ -0,0 +1,34 @@ +From 2173cbf847fc53ca24950e77958c902edecfc207 Mon Sep 17 00:00:00 2001 +From: Olivier Brunel j...@jjacky.com +Date: Fri, 5 Dec 2014 16:06:45 +0100 +Subject: [PATCH] journal: Fix navigating backwards missing entries + +With DIRECTION_UP (i.e. navigating backwards) in generic_array_bisect() when the +needle was found as the last item in the array, it wasn't actually processed as +match, resulting in entries being missed. + +https://bugs.freedesktop.org/show_bug.cgi?id=86855 + +Upstream-Status: Backport + +Signed-off-by: Jonathan Liu net...@gmail.com +--- + src/journal/journal-file.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/src/journal/journal-file.c b/src/journal/journal-file.c +index 7858435..c5d2d19 100644 +--- a/src/journal/journal-file.c b/src/journal/journal-file.c +@@ -1657,7 +1657,7 @@ static int generic_array_bisect( + } + } + +-if (k n) { ++if (k = n) { + if (direction == DIRECTION_UP) { + i = n; + subtract_one = true; +-- +2.1.3 + diff --git a/meta/recipes-core/systemd/systemd_211.bb b/meta/recipes-core/systemd/systemd_211.bb index 44b1965..567c323 100644 --- a/meta/recipes-core/systemd/systemd_211.bb +++ b/meta/recipes-core/systemd/systemd_211.bb @@ -32,6 +32,7 @@ SRC_URI = git://anongit.freedesktop.org/systemd/systemd;branch=master;protocol= file://uclibc-sysinfo_h.patch \ file://uclibc-get-physmem.patch \ file://sd-bus-don-t-use-assert_return-to-check-for-disconne.patch \ + file://0001-journal-Fix-navigating-backwards-missing-entries.patch \ \ file://touchscreen.rules \ file://00-create-volatile.conf \ -- 2.2.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [RFC PATCH] package.bbclass: omit .pyc and .pyo file
We should not ship .pyc or .pyo file, but there are a few packages ship .pyc, should we: 1) Ignore them in package.bbclass as this patch showes ? Or 2) Add a qa check then fix it by hand one by one ? Here is the list of oe-core's world build: python-smartpm-1.4.1 nativesdk-python-smartpm-1.4.1 python3-distribute-0.6.32 python-pycurl-7.19.5 python-pyrex-0.9.9 python-numpy-1.7.0 python-distribute-0.6.32 python-async-0.6.1 python-docutils-0.12 python-pycairo-1.10.0 python-scons-2.3.2 python-imaging-1.1.7 python-gitdb-0.5.4 Signed-off-by: Robert Yang liezhi.y...@windriver.com --- meta/classes/package.bbclass |6 ++ 1 file changed, 6 insertions(+) diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass index fc501fc..6960221 100644 --- a/meta/classes/package.bbclass +++ b/meta/classes/package.bbclass @@ -1022,6 +1022,9 @@ python populate_packages () { files.append(file) for file in files: +# Skip .pyc and .pyo file. +if file.endswith('.pyc') or file.endswith('.pyo'): +continue if not cpath.islink(file): if cpath.isdir(file): newfiles = [ os.path.join(file,x) for x in os.listdir(file) ] @@ -1083,6 +1086,9 @@ python populate_packages () { if not dir: dir = os.sep for f in (files + dirs): +# Skip .pyc and .pyo file. +if f.endswith('.pyc') or f.endswith('.pyo'): +continue path = os.path.join(dir, f) if ('.' + path) not in seen: unshipped.append(path) -- 1.7.9.5 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH V2 0/1] libxml2: fix python path and add libxml2-python
Ping, the target createrepo can't work without this patch. // Robert On 10/31/2014 09:56 AM, Chong Lu wrote: Change since v1: add python to PACKAGECONFIG. The following changes since commit 4faca22b8fe63a86d820990207aaf84b3fa83e01: ref-manual: Updates to the migrating to YP 1.7 section. (2014-10-28 22:31:18 +) are available in the git repository at: git://git.pokylinux.org/poky-contrib chonglu/libxml2 http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=chonglu/libxml2 Robert Yang (1): libxml2: fix python path and add libxml2-python meta/recipes-core/libxml/libxml2.inc | 19 +-- 1 file changed, 9 insertions(+), 10 deletions(-) -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] parted: parted-ptest RDEPENDS on python
python scripts: parted-ptest/usr/lib64/parted/ptest/tests/gpt-header-move parted-ptest/usr/lib64/parted/ptest/tests/msdos-overlap Signed-off-by: Robert Yang liezhi.y...@windriver.com --- meta/recipes-extended/parted/parted_3.2.bb |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-extended/parted/parted_3.2.bb b/meta/recipes-extended/parted/parted_3.2.bb index 655a825..e225769 100644 --- a/meta/recipes-extended/parted/parted_3.2.bb +++ b/meta/recipes-extended/parted/parted_3.2.bb @@ -40,4 +40,4 @@ do_install_ptest() { sed -e 's| ../parted||' -i $t/tests/*.sh } -RDEPENDS_${PN}-ptest = bash coreutils perl util-linux-losetup +RDEPENDS_${PN}-ptest = bash coreutils perl util-linux-losetup python -- 1.7.9.5 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] pax-utils: RDEPENDS on python
python script: pax-utils/usr/bin/lddtree Signed-off-by: Robert Yang liezhi.y...@windriver.com --- meta/recipes-devtools/pax-utils/pax-utils_0.9.2.bb |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-devtools/pax-utils/pax-utils_0.9.2.bb b/meta/recipes-devtools/pax-utils/pax-utils_0.9.2.bb index ac14306..ea3d78e 100644 --- a/meta/recipes-devtools/pax-utils/pax-utils_0.9.2.bb +++ b/meta/recipes-devtools/pax-utils/pax-utils_0.9.2.bb @@ -12,7 +12,7 @@ SRC_URI = http://gentoo.osuosl.org/distfiles/pax-utils-${PV}.tar.xz; SRC_URI[md5sum] = 34c41888cec67759c21333bef13e950c SRC_URI[sha256sum] = 578801df0661b1b7b8fed0ce4a9859239f919fd37529907681e51091a1bcb4de -RDEPENDS_${PN} += bash +RDEPENDS_${PN} += bash python do_install() { oe_runmake PREFIX=${D}${prefix} DESTDIR=${D} install -- 1.7.9.5 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/2] fix RDEPENDS
The following changes since commit 24f19fedb40d0af84beb8e9a6595ea06f09d4615: gstreamer1.0-omx: use mulitple SCMs to fetch submodules (2014-12-31 08:22:53 +) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib rbt/rdep http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/rdep Robert Yang (2): parted: parted-ptest RDEPENDS on python pax-utils: RDEPENDS on python meta/recipes-devtools/pax-utils/pax-utils_0.9.2.bb |2 +- meta/recipes-extended/parted/parted_3.2.bb |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- 1.7.9.5 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 03/12] syslinux: Update to 6.0.3
Removed patches that are now committed upstream, rebase parallel make patch and add a new patch to remove a script that was calling git during the clean process. Signed-off-by: Saul Wold s...@linux.intel.com --- ...dd-SMT_TERMINAL-a-last-resort-region-type.patch | 50 --- ...an-build-a-linked-list-of-memory-scanners.patch | 450 - .../0003-PXELINUX-Add-bios-memscan-function.patch | 87 ...s_fbm-and-real_base_mem-to-calculate-free.patch | 65 --- .../isohybrid-fix-overflow-on-32-bit-system.patch | 40 -- .../syslinux-fix-parallel-building-issue.patch | 17 +- .../syslinux-libupload-depend-lib.patch| 0 .../syslinux/syslinux-remove-clean-script.patch| 17 + .../{syslinux_6.01.bb = syslinux_6.03.bb} | 12 +- 9 files changed, 28 insertions(+), 710 deletions(-) delete mode 100644 meta/recipes-devtools/syslinux/files/0001-movebits-Add-SMT_TERMINAL-a-last-resort-region-type.patch delete mode 100644 meta/recipes-devtools/syslinux/files/0002-memscan-build-a-linked-list-of-memory-scanners.patch delete mode 100644 meta/recipes-devtools/syslinux/files/0003-PXELINUX-Add-bios-memscan-function.patch delete mode 100644 meta/recipes-devtools/syslinux/files/0004-pxe-use-bios_fbm-and-real_base_mem-to-calculate-free.patch delete mode 100644 meta/recipes-devtools/syslinux/files/isohybrid-fix-overflow-on-32-bit-system.patch rename meta/recipes-devtools/syslinux/{files = syslinux}/syslinux-fix-parallel-building-issue.patch (75%) rename meta/recipes-devtools/syslinux/{files = syslinux}/syslinux-libupload-depend-lib.patch (100%) create mode 100644 meta/recipes-devtools/syslinux/syslinux/syslinux-remove-clean-script.patch rename meta/recipes-devtools/syslinux/{syslinux_6.01.bb = syslinux_6.03.bb} (84%) diff --git a/meta/recipes-devtools/syslinux/files/0001-movebits-Add-SMT_TERMINAL-a-last-resort-region-type.patch b/meta/recipes-devtools/syslinux/files/0001-movebits-Add-SMT_TERMINAL-a-last-resort-region-type.patch deleted file mode 100644 index fb03bbf..000 --- a/meta/recipes-devtools/syslinux/files/0001-movebits-Add-SMT_TERMINAL-a-last-resort-region-type.patch +++ /dev/null @@ -1,50 +0,0 @@ -Upstream-Status: Backport [ba638fd9bf72b0c786c88909014136cfa641a147] -Signed-off-by: Jonathan Liu net...@gmail.com - -From b663fd7257481438256f8267831dc10b06363b22 Mon Sep 17 00:00:00 2001 -From: Matt Fleming matt.flem...@intel.com -Date: Tue, 16 Jul 2013 22:16:11 +0100 -Subject: [PATCH 1/4] movebits: Add SMT_TERMINAL - a last resort region type - -Some memory regions are usable, but only as a last resort just before we -hand over control to a kernel image. Add the necessary movebits -infrastructure to use these regions when all other options have been -exhausted. - -Signed-off-by: Matt Fleming matt.flem...@intel.com - -Conflicts: - com32/lib/syslinux/zonelist.c - com32/include/syslinux/movebits.h | 1 + - com32/lib/syslinux/movebits.c | 2 +- - 2 files changed, 2 insertions(+), 1 deletion(-) - -diff --git a/com32/include/syslinux/movebits.h b/com32/include/syslinux/movebits.h -index 8bcdf3e..114a896 100644 a/com32/include/syslinux/movebits.h -+++ b/com32/include/syslinux/movebits.h -@@ -34,6 +34,7 @@ enum syslinux_memmap_types { - SMT_RESERVED, /* Unusable memory */ - SMT_ALLOC,/* Memory allocated by user */ - SMT_ZERO, /* Memory that should be zeroed */ -+SMT_TERMINAL, /* Memory to be used as a last resort */ - }; - - struct syslinux_memmap { -diff --git a/com32/lib/syslinux/movebits.c b/com32/lib/syslinux/movebits.c -index 7a05f3c..8ffdc63 100644 a/com32/lib/syslinux/movebits.c -+++ b/com32/lib/syslinux/movebits.c -@@ -160,7 +160,7 @@ static const struct syslinux_memmap *is_free_zone(const struct syslinux_memmap - if (list-start = start) { - if (llast = last) { - /* Chunk has a single, well-defined type */ -- if (list-type == SMT_FREE) { -+ if (list-type == SMT_FREE || list-type == SMT_TERMINAL) { - dprintf(F: 0x%08x bytes at 0x%08x\n, - list-next-start, list-start); - return list;/* It's free */ --- -1.8.5.3 - diff --git a/meta/recipes-devtools/syslinux/files/0002-memscan-build-a-linked-list-of-memory-scanners.patch b/meta/recipes-devtools/syslinux/files/0002-memscan-build-a-linked-list-of-memory-scanners.patch deleted file mode 100644 index 48d3955..000 --- a/meta/recipes-devtools/syslinux/files/0002-memscan-build-a-linked-list-of-memory-scanners.patch +++ /dev/null @@ -1,450 +0,0 @@ -Upstream-Status: Backport [787d7e568fe08d7080d2cd03cd9ee27c327eca67] -Signed-off-by: Jonathan Liu net...@gmail.com - -From 2e05f34c0c5bc0144bb203a169009dfb6837b4e3 Mon Sep 17 00:00:00 2001 -From: Matt Fleming matt.flem...@intel.com -Date: Wed, 17 Jul 2013 12:15:16 +0100 -Subject: [PATCH 2/4] memscan: build a linked list of memory
[OE-core] [PATCH 02/12] gnupg: Upgrade to 2.1.0
Add patch to use pkg-config instead of npth-config and remove --without-curl as it's not used anymore. Also needed a patch to add libgpg-error to correctly build dirmngr Signed-off-by: Saul Wold s...@linux.intel.com --- .../gnupg/gnupg/dirmngr-uses-libgpg-error.patch| 16 + meta/recipes-support/gnupg/gnupg/pkgconfig.patch | 24 +--- .../use-pkgconfig-instead-of-npth-config.patch | 72 ++ .../gnupg/{gnupg_2.0.26.bb = gnupg_2.1.0.bb} | 16 ++--- 4 files changed, 111 insertions(+), 17 deletions(-) create mode 100644 meta/recipes-support/gnupg/gnupg/dirmngr-uses-libgpg-error.patch create mode 100644 meta/recipes-support/gnupg/gnupg/use-pkgconfig-instead-of-npth-config.patch rename meta/recipes-support/gnupg/{gnupg_2.0.26.bb = gnupg_2.1.0.bb} (70%) diff --git a/meta/recipes-support/gnupg/gnupg/dirmngr-uses-libgpg-error.patch b/meta/recipes-support/gnupg/gnupg/dirmngr-uses-libgpg-error.patch new file mode 100644 index 000..3dc506c --- /dev/null +++ b/meta/recipes-support/gnupg/gnupg/dirmngr-uses-libgpg-error.patch @@ -0,0 +1,16 @@ +Upstream-Status: Pending +Signed-off-by: Saul Wold s...@linux.intel.com +Index: gnupg-2.1.0/dirmngr/Makefile.am +=== +--- gnupg-2.1.0.orig/dirmngr/Makefile.am gnupg-2.1.0/dirmngr/Makefile.am +@@ -71,7 +71,8 @@ endif + dirmngr_LDADD = $(libcommontlsnpth) $(libcommonpth) \ + ../gl/libgnu.a $(DNSLIBS) $(LIBASSUAN_LIBS) \ + $(LIBGCRYPT_LIBS) $(KSBA_LIBS) $(NPTH_LIBS) \ +- $(NTBTLS_LIBS) $(LIBGNUTLS_LIBS) $(LIBINTL) $(LIBICONV) ++ $(NTBTLS_LIBS) $(LIBGNUTLS_LIBS) $(LIBINTL) $(LIBICONV) \ ++$(GPG_ERROR_LIBS) + if !USE_LDAPWRAPPER + dirmngr_LDADD += $(ldaplibs) + endif diff --git a/meta/recipes-support/gnupg/gnupg/pkgconfig.patch b/meta/recipes-support/gnupg/gnupg/pkgconfig.patch index ae92392..5e036ba 100644 --- a/meta/recipes-support/gnupg/gnupg/pkgconfig.patch +++ b/meta/recipes-support/gnupg/gnupg/pkgconfig.patch @@ -5,11 +5,11 @@ Upstream-Status: Rejected RP 2014/5/22 -Index: gnupg-2.0.22/m4/gnupg-pth.m4 +Index: gnupg-2.1.0/m4/gnupg-pth.m4 === gnupg-2.0.22.orig/m4/gnupg-pth.m4 2013-10-04 12:32:53.0 + -+++ gnupg-2.0.22/m4/gnupg-pth.m4 2014-05-13 21:33:21.0 + -@@ -17,33 +17,9 @@ +--- gnupg-2.1.0.orig/m4/gnupg-pth.m4 gnupg-2.1.0/m4/gnupg-pth.m4 +@@ -17,33 +17,9 @@ dnl implied warranty of MERCHANTABILITY # Taken and modified from the m4 macros which come with Pth. AC_DEFUN([GNUPG_PTH_VERSION_CHECK], [ @@ -44,7 +44,7 @@ Index: gnupg-2.0.22/m4/gnupg-pth.m4 if test $have_pth = yes; then AC_MSG_RESULT(yes) AC_MSG_CHECKING([whether PTH installation is sane]) -@@ -51,9 +29,9 @@ +@@ -51,9 +27,9 @@ AC_DEFUN([GNUPG_PTH_VERSION_CHECK], _gnupg_pth_save_cflags=$CFLAGS _gnupg_pth_save_ldflags=$LDFLAGS _gnupg_pth_save_libs=$LIBS @@ -57,30 +57,34 @@ Index: gnupg-2.0.22/m4/gnupg-pth.m4 AC_LINK_IFELSE([AC_LANG_PROGRAM([#include pth.h ], [[ pth_init ();]])], -@@ -81,23 +59,11 @@ +@@ -80,26 +56,13 @@ AC_DEFUN([GNUPG_PTH_VERSION_CHECK], + # PTH_CLFAGS and PTH_LIBS are AS_SUBST. # AC_DEFUN([GNUPG_PATH_PTH], -+[ -[ AC_ARG_WITH(pth-prefix, - AC_HELP_STRING([--with-pth-prefix=PFX], -- [prefix where GNU Pth is installed]), +- [prefix where GNU Pth is installed (optional)]), - pth_config_prefix=$withval, pth_config_prefix=) - if test x$pth_config_prefix != x ; then - PTH_CONFIG=$pth_config_prefix/bin/pth-config - fi - AC_PATH_PROG(PTH_CONFIG, pth-config, no) ++[ tmp=ifelse([$1], ,1.3.7,$1) - if test $PTH_CONFIG != no; then -GNUPG_PTH_VERSION_CHECK($tmp) --if test $have_pth = yes; then +-if test $have_pth = yes; then - PTH_CFLAGS=`$PTH_CONFIG --cflags` - PTH_LIBS=`$PTH_CONFIG --ldflags` - PTH_LIBS=$PTH_LIBS `$PTH_CONFIG --libs --all` +- AC_DEFINE(HAVE_PTH, 1, + GNUPG_PTH_VERSION_CHECK($tmp) + if test $have_pth = yes; then -AC_DEFINE(HAVE_PTH, 1, ++ AC_DEFINE(HAVE_PTH, 1, [Defined if the GNU Pth is available]) -fi fi AC_SUBST(PTH_CFLAGS) AC_SUBST(PTH_LIBS) + ]) +- diff --git a/meta/recipes-support/gnupg/gnupg/use-pkgconfig-instead-of-npth-config.patch b/meta/recipes-support/gnupg/gnupg/use-pkgconfig-instead-of-npth-config.patch new file mode 100644 index 000..c6dbf1b --- /dev/null +++ b/meta/recipes-support/gnupg/gnupg/use-pkgconfig-instead-of-npth-config.patch @@ -0,0 +1,72 @@ +Upstream-Status: Inappropriate [openembedded specific] + +Signed-off-by: Saul Wold s...@linux.intel.com + + +Index: gnupg-2.1.0/m4/npth.m4 +=== +---
[OE-core] [PATCH 00/12] Package Updates
Ross, Richard: Here is another set up updates, built and tested on both Autobuilder and locally. This address the issues with libgpg-error for fsl also. Sau! The following changes since commit 24f19fedb40d0af84beb8e9a6595ea06f09d4615: gstreamer1.0-omx: use mulitple SCMs to fetch submodules (2014-12-31 08:22:53 +) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib 5149fba599906379ad08516e540c8b3e6f467e2f http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=sgw/stage André Draszik (1): openssl: fix hard paths in native openssl Saul Wold (11): usbutils: Add version 008 gnupg: Upgrade to 2.1.0 syslinux: Update to 6.0.3 gnu-efi: Upgrade to 3.0w json-c: Upgrade to 0.12 lsbinitscripts: Upgrade to 9.60 libffi: Upgrade to 3.2.1 libassuan: Upgrade to 2.2.0 libksba: Upgrade to 1.3.2 liburcu: Upgrade to 0.8.6 libgpg-error: Update to 1.17 .../gnu-efi/{gnu-efi_3.0u.bb = gnu-efi_3.0w.bb} | 1 + meta/recipes-bsp/usbutils/usbutils-008/iconv.patch | 41 ++ meta/recipes-bsp/usbutils/usbutils_008.bb | 35 ++ meta/recipes-connectivity/openssl/openssl.inc | 9 +- .../json-c/{json-c_0.11.bb = json-c_0.12.bb} | 6 +- ...dd-SMT_TERMINAL-a-last-resort-region-type.patch | 50 --- ...an-build-a-linked-list-of-memory-scanners.patch | 450 - .../0003-PXELINUX-Add-bios-memscan-function.patch | 87 ...s_fbm-and-real_base_mem-to-calculate-free.patch | 65 --- .../isohybrid-fix-overflow-on-32-bit-system.patch | 40 -- .../syslinux-fix-parallel-building-issue.patch | 17 +- .../syslinux-libupload-depend-lib.patch| 0 .../syslinux/syslinux-remove-clean-script.patch| 17 + .../{syslinux_6.01.bb = syslinux_6.03.bb} | 12 +- ...nitscripts_9.56.1.bb = lsbinitscripts_9.60.bb} | 6 +- .../libffi/{libffi_3.1.bb = libffi_3.2.1.bb} | 4 +- .../gnupg/gnupg/dirmngr-uses-libgpg-error.patch| 16 + meta/recipes-support/gnupg/gnupg/pkgconfig.patch | 24 +- .../use-pkgconfig-instead-of-npth-config.patch | 72 .../gnupg/{gnupg_2.0.26.bb = gnupg_2.1.0.bb} | 16 +- .../{libassuan_2.1.2.bb = libassuan_2.2.0.bb} | 4 +- .../pkgconfig.patch| 67 +-- .../{libgpg-error_1.12.bb = libgpg-error_1.17.bb} | 35 +- .../libksba/{libksba_1.3.1.bb = libksba_1.3.2.bb} | 4 +- .../liburcu/{files = liburcu}/aarch64.patch | 0 .../liburcu/{liburcu_0.8.5.bb = liburcu_0.8.6.bb} | 4 +- 26 files changed, 311 insertions(+), 771 deletions(-) rename meta/recipes-bsp/gnu-efi/{gnu-efi_3.0u.bb = gnu-efi_3.0w.bb} (99%) create mode 100644 meta/recipes-bsp/usbutils/usbutils-008/iconv.patch create mode 100644 meta/recipes-bsp/usbutils/usbutils_008.bb rename meta/recipes-devtools/json-c/{json-c_0.11.bb = json-c_0.12.bb} (75%) delete mode 100644 meta/recipes-devtools/syslinux/files/0001-movebits-Add-SMT_TERMINAL-a-last-resort-region-type.patch delete mode 100644 meta/recipes-devtools/syslinux/files/0002-memscan-build-a-linked-list-of-memory-scanners.patch delete mode 100644 meta/recipes-devtools/syslinux/files/0003-PXELINUX-Add-bios-memscan-function.patch delete mode 100644 meta/recipes-devtools/syslinux/files/0004-pxe-use-bios_fbm-and-real_base_mem-to-calculate-free.patch delete mode 100644 meta/recipes-devtools/syslinux/files/isohybrid-fix-overflow-on-32-bit-system.patch rename meta/recipes-devtools/syslinux/{files = syslinux}/syslinux-fix-parallel-building-issue.patch (75%) rename meta/recipes-devtools/syslinux/{files = syslinux}/syslinux-libupload-depend-lib.patch (100%) create mode 100644 meta/recipes-devtools/syslinux/syslinux/syslinux-remove-clean-script.patch rename meta/recipes-devtools/syslinux/{syslinux_6.01.bb = syslinux_6.03.bb} (84%) rename meta/recipes-extended/lsb/{lsbinitscripts_9.56.1.bb = lsbinitscripts_9.60.bb} (78%) rename meta/recipes-gnome/libffi/{libffi_3.1.bb = libffi_3.2.1.bb} (88%) create mode 100644 meta/recipes-support/gnupg/gnupg/dirmngr-uses-libgpg-error.patch create mode 100644 meta/recipes-support/gnupg/gnupg/use-pkgconfig-instead-of-npth-config.patch rename meta/recipes-support/gnupg/{gnupg_2.0.26.bb = gnupg_2.1.0.bb} (70%) rename meta/recipes-support/libassuan/{libassuan_2.1.2.bb = libassuan_2.2.0.bb} (86%) rename meta/recipes-support/libgpg-error/{libgpg-error-1.12 = libgpg-error}/pkgconfig.patch (70%) rename meta/recipes-support/libgpg-error/{libgpg-error_1.12.bb = libgpg-error_1.17.bb} (40%) rename meta/recipes-support/libksba/{libksba_1.3.1.bb = libksba_1.3.2.bb} (86%) rename meta/recipes-support/liburcu/{files = liburcu}/aarch64.patch (100%) rename meta/recipes-support/liburcu/{liburcu_0.8.5.bb = liburcu_0.8.6.bb} (83%) -- 2.1.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 01/12] usbutils: Add version 008
The latest version of usbutil (v008) uses the latest version of udev (v196 or greater) which is only available as part of the systemd package. So add systemd as a DEPENDS and REQUIRED_DISTRO_FEATURE. Add v008 version of iconv.patch COPYING file is GPLv2, but has newer formatting and address change. Signed-off-by: Saul Wold s...@linux.intel.com --- meta/recipes-bsp/usbutils/usbutils-008/iconv.patch | 41 ++ meta/recipes-bsp/usbutils/usbutils_008.bb | 35 ++ 2 files changed, 76 insertions(+) create mode 100644 meta/recipes-bsp/usbutils/usbutils-008/iconv.patch create mode 100644 meta/recipes-bsp/usbutils/usbutils_008.bb diff --git a/meta/recipes-bsp/usbutils/usbutils-008/iconv.patch b/meta/recipes-bsp/usbutils/usbutils-008/iconv.patch new file mode 100644 index 000..6455567 --- /dev/null +++ b/meta/recipes-bsp/usbutils/usbutils-008/iconv.patch @@ -0,0 +1,41 @@ +This patch adds support for detecting iconv support using autotools +uclibc does not have iconv implementation inside libc like glibc, therefore +the existing checks were not sufficient, it worked for glibc but not for +uclibc. The new patch portably detects the iconv support and adds the +libiconv to linker cmdline + +This patch should be submitted upstream too + +Upstream-Status: Pending + +Signed-off-by: Khem Raj raj.k...@gmail.com + +Index: usbutils-008/configure.ac +=== +--- usbutils-008.orig/configure.ac usbutils-008/configure.ac +@@ -10,7 +10,9 @@ AC_USE_SYSTEM_EXTENSIONS + AC_SYS_LARGEFILE + + AC_CHECK_HEADERS([byteswap.h]) +-AC_CHECK_FUNCS([nl_langinfo iconv]) ++ ++AM_GNU_GETTEXT ++AM_ICONV + + PKG_CHECK_MODULES(LIBUSB, libusb-1.0 = 1.0.0) + +Index: usbutils-008/Makefile.am +=== +--- usbutils-008.orig/Makefile.am usbutils-008/Makefile.am +@@ -29,7 +29,8 @@ lsusb_CPPFLAGS = \ + + lsusb_LDADD = \ + $(LIBUSB_LIBS) \ +- $(UDEV_LIBS) ++ $(UDEV_LIBS) \ ++ $(LIBICONV) + + man_MANS = \ + lsusb.8 \ diff --git a/meta/recipes-bsp/usbutils/usbutils_008.bb b/meta/recipes-bsp/usbutils/usbutils_008.bb new file mode 100644 index 000..afc6ea3 --- /dev/null +++ b/meta/recipes-bsp/usbutils/usbutils_008.bb @@ -0,0 +1,35 @@ +SUMMARY = Host side USB console utilities +DESCRIPTION = Contains the lsusb utility for inspecting the devices connected to the USB bus. +HOMEPAGE = http://www.linux-usb.org; +SECTION = base + +LICENSE = GPLv2+ +LIC_FILES_CHKSUM = file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263 + +DEPENDS = libusb zlib virtual/libiconv systemd + +SRC_URI = ${KERNELORG_MIRROR}/linux/utils/usb/usbutils/usbutils-${PV}.tar.gz \ + file://usb-devices-avoid-dependency-on-bash.patch \ + file://Fix-NULL-pointer-crash.patch \ + file://iconv.patch \ + + +RC_URI[md5sum] = cb20148c2e784577e924a7b4c560c8fb +SRC_URI[sha256sum] = 6d5f16c2961df37e22e492c736a3e162a8fde24480f23a40d85f79af80d3fe95 + +inherit autotools gettext pkgconfig distro_features_check +# This version of usbutils relies on the udev from systemd, so unless +# we can decouple udev from system, we require systemd for now. +REQUIRED_DISTRO_FEATURES = systemd + +do_install_append() { + # We only need the compressed copy, remove the uncompressed version + rm -f ${D}${datadir}/usb.ids +} + +PACKAGES += ${PN}-ids +FILES_${PN}-dev += ${datadir}/pkgconfig +FILES_${PN}-ids = ${datadir}/usb* + +RDEPENDS_${PN} = ${PN}-ids libudev +RDEPENDS_${PN}-ptest = libboost-system libboost-thread -- 2.1.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 04/12] openssl: fix hard paths in native openssl
From: André Draszik adras...@digisoft.tv This causes the package to not be relocateable from sstate The OpenSSL binaries respect a few environment variables for determining locations of files, so we now use these to point the binaries to the relocated locations. [YOCTO #6827] Signed-off-by: André Draszik adras...@digisoft.tv Signed-off-by: Saul Wold s...@linux.intel.com --- meta/recipes-connectivity/openssl/openssl.inc | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/meta/recipes-connectivity/openssl/openssl.inc b/meta/recipes-connectivity/openssl/openssl.inc index 9ec884f..31dfd8f 100644 --- a/meta/recipes-connectivity/openssl/openssl.inc +++ b/meta/recipes-connectivity/openssl/openssl.inc @@ -193,5 +193,12 @@ do_install_ptest () { install util/shlib_wrap.sh ${D}${PTEST_PATH}/util } -BBCLASSEXTEND = native nativesdk +do_install_append_virtclass-native() { + create_wrapper ${D}${bindir}/openssl \ + OPENSSL_CONF=${libdir}/ssl/openssl.cnf \ + SSL_CERT_DIR=${libdir}/ssl/certs \ + SSL_CERT_FILE=${libdir}/ssl/cert.pem \ + OPENSSL_ENGINES=${libdir}/ssl/engines +} +BBCLASSEXTEND = native nativesdk -- 2.1.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 06/12] json-c: Upgrade to 0.12
Added CFLAGS to prevent compiler error of unused size variable Signed-off-by: Saul Wold s...@linux.intel.com --- meta/recipes-devtools/json-c/{json-c_0.11.bb = json-c_0.12.bb} | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) rename meta/recipes-devtools/json-c/{json-c_0.11.bb = json-c_0.12.bb} (75%) diff --git a/meta/recipes-devtools/json-c/json-c_0.11.bb b/meta/recipes-devtools/json-c/json-c_0.12.bb similarity index 75% rename from meta/recipes-devtools/json-c/json-c_0.11.bb rename to meta/recipes-devtools/json-c/json-c_0.12.bb index 389e0f9..79cf6dc 100644 --- a/meta/recipes-devtools/json-c/json-c_0.11.bb +++ b/meta/recipes-devtools/json-c/json-c_0.12.bb @@ -6,8 +6,8 @@ LIC_FILES_CHKSUM = file://COPYING;md5=de54b60fbbc35123ba193fea8ee216f2 SRC_URI = https://s3.amazonaws.com/json-c_releases/releases/${BP}.tar.gz; -SRC_URI[md5sum] = aa02367d2f7a830bf1e3376f77881e98 -SRC_URI[sha256sum] = 28dfc65145dc0d4df1dfe7701ac173c4e5f9347176c8983edbfac9149494448c +SRC_URI[md5sum] = 3ca4bbb881dfc4017e8021b5e0a8c491 +SRC_URI[sha256sum] = 000c01b2b3f82dcb4261751eb71f1b084404fb7d6a282f06074d3c17078b9f3f RPROVIDES_${PN} = libjson @@ -19,3 +19,5 @@ do_configure_prepend() { # Clean up autoconf cruft that should not be in the tarball rm -f ${S}/config.status } + +CFLAGS += -Wno-error=unused-but-set-variable -- 2.1.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 05/12] gnu-efi: Upgrade to 3.0w
Signed-off-by: Saul Wold s...@linux.intel.com --- meta/recipes-bsp/gnu-efi/{gnu-efi_3.0u.bb = gnu-efi_3.0w.bb} | 1 + 1 file changed, 1 insertion(+) rename meta/recipes-bsp/gnu-efi/{gnu-efi_3.0u.bb = gnu-efi_3.0w.bb} (99%) diff --git a/meta/recipes-bsp/gnu-efi/gnu-efi_3.0u.bb b/meta/recipes-bsp/gnu-efi/gnu-efi_3.0w.bb similarity index 99% rename from meta/recipes-bsp/gnu-efi/gnu-efi_3.0u.bb rename to meta/recipes-bsp/gnu-efi/gnu-efi_3.0w.bb index dbf2a07..e854245 100644 --- a/meta/recipes-bsp/gnu-efi/gnu-efi_3.0u.bb +++ b/meta/recipes-bsp/gnu-efi/gnu-efi_3.0w.bb @@ -8,6 +8,7 @@ SRC_URI = http://downloads.sourceforge.net/gnu-efi/gnu-efi_3.0u.orig.tar.gz \ file://parallel-make.patch \ file://parallel-make-archives.patch \ + SRC_URI[md5sum] = d15d3c700e79a1e2938544d73edc572d SRC_URI[sha256sum] = 3c0d450d5829204ca05dcb3b2aae772e52c379b7c7e09146759c6315606f934e -- 2.1.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 07/12] lsbinitscripts: Upgrade to 9.60
Signed-off-by: Saul Wold s...@linux.intel.com --- .../lsb/{lsbinitscripts_9.56.1.bb = lsbinitscripts_9.60.bb}| 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) rename meta/recipes-extended/lsb/{lsbinitscripts_9.56.1.bb = lsbinitscripts_9.60.bb} (78%) diff --git a/meta/recipes-extended/lsb/lsbinitscripts_9.56.1.bb b/meta/recipes-extended/lsb/lsbinitscripts_9.60.bb similarity index 78% rename from meta/recipes-extended/lsb/lsbinitscripts_9.56.1.bb rename to meta/recipes-extended/lsb/lsbinitscripts_9.60.bb index cf3a863..1490582 100644 --- a/meta/recipes-extended/lsb/lsbinitscripts_9.56.1.bb +++ b/meta/recipes-extended/lsb/lsbinitscripts_9.60.bb @@ -6,12 +6,12 @@ DEPENDS = popt glib-2.0 LIC_FILES_CHKSUM = file://COPYING;md5=ebf4e8b49780ab187d51bd26aaa022c6 S=${WORKDIR}/initscripts-${PV} -SRC_URI = http://pkgs.fedoraproject.org/repo/pkgs/initscripts/initscripts-9.56.1.tar.bz2/8ca2abb3877e8019a5e726c25501e8e3/initscripts-9.56.1.tar.bz2 \ +SRC_URI = http://pkgs.fedoraproject.org/repo/pkgs/initscripts/initscripts-9.60.tar.bz2/5c9cd83e4e04257fef3ffd8e549b7f81/initscripts-9.60.tar.bz2 \ file://functions.patch \ -SRC_URI[md5sum] = 8ca2abb3877e8019a5e726c25501e8e3 -SRC_URI[sha256sum] = e6fbe1daa5cbfc6fab12ccac2955bde0c16ec8d9fbdb9f7c6c33fadc81da6574 +SRC_URI[md5sum] = 5c9cd83e4e04257fef3ffd8e549b7f81 +SRC_URI[sha256sum] = 254508884ceeef22e24f4e8b051bb51958ae8252bd7b02cd2b7bcce3fb453dc2 inherit update-alternatives -- 2.1.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 08/12] libffi: Upgrade to 3.2.1
Signed-off-by: Saul Wold s...@linux.intel.com --- meta/recipes-gnome/libffi/{libffi_3.1.bb = libffi_3.2.1.bb} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename meta/recipes-gnome/libffi/{libffi_3.1.bb = libffi_3.2.1.bb} (88%) diff --git a/meta/recipes-gnome/libffi/libffi_3.1.bb b/meta/recipes-gnome/libffi/libffi_3.2.1.bb similarity index 88% rename from meta/recipes-gnome/libffi/libffi_3.1.bb rename to meta/recipes-gnome/libffi/libffi_3.2.1.bb index bc97aba..2302810 100644 --- a/meta/recipes-gnome/libffi/libffi_3.1.bb +++ b/meta/recipes-gnome/libffi/libffi_3.2.1.bb @@ -12,8 +12,8 @@ LIC_FILES_CHKSUM = file://LICENSE;md5=3610bb17683a0089ed64055416b2ae1b SRC_URI = ftp://sourceware.org/pub/libffi/${BP}.tar.gz \ file://fix-libffi.la-location.patch -SRC_URI[md5sum] = f5898b29bbfd70502831a212d9249d10 -SRC_URI[sha256sum] = 97feeeadca5e21870fa4433bc953d1b3af3f698d5df8a428f68b73cd60aef6eb +SRC_URI[md5sum] = 83b89587607e3eb65c70d361f13bab43 +SRC_URI[sha256sum] = d06ebb8e1d9a22d19e38d63fdb83954253f39bedc5d46232a05645685722ca37 EXTRA_OECONF += --disable-builddir -- 2.1.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 10/12] libksba: Upgrade to 1.3.2
Signed-off-by: Saul Wold s...@linux.intel.com --- meta/recipes-support/libksba/{libksba_1.3.1.bb = libksba_1.3.2.bb} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename meta/recipes-support/libksba/{libksba_1.3.1.bb = libksba_1.3.2.bb} (86%) diff --git a/meta/recipes-support/libksba/libksba_1.3.1.bb b/meta/recipes-support/libksba/libksba_1.3.2.bb similarity index 86% rename from meta/recipes-support/libksba/libksba_1.3.1.bb rename to meta/recipes-support/libksba/libksba_1.3.2.bb index 6950dbb..cce08c3 100644 --- a/meta/recipes-support/libksba/libksba_1.3.1.bb +++ b/meta/recipes-support/libksba/libksba_1.3.2.bb @@ -16,8 +16,8 @@ inherit autotools binconfig-disabled pkgconfig texinfo SRC_URI = ftp://ftp.gnupg.org/gcrypt/${BPN}/${BPN}-${PV}.tar.bz2 \ file://ksba-add-pkgconfig-support.patch -SRC_URI[md5sum] = 9be95245fcfa9d56f56853078ef2650b -SRC_URI[sha256sum] = bc96b95516bd2b67f413bc8b5cc5a75a2583c6e666d24dfd0d5bcc6b1aab46f9 +SRC_URI[md5sum] = c3c9a66e22d87fe3ae59865250b8a09c +SRC_URI[sha256sum] = eb95537955dfc2845690a4cc3836074fa6d0a2c2ca2cbf1759364d3bd9868406 do_configure_prepend () { # Else these could be used in preference to those in aclocal-copy -- 2.1.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 09/12] libassuan: Upgrade to 2.2.0
Signed-off-by: Saul Wold s...@linux.intel.com --- .../libassuan/{libassuan_2.1.2.bb = libassuan_2.2.0.bb} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename meta/recipes-support/libassuan/{libassuan_2.1.2.bb = libassuan_2.2.0.bb} (86%) diff --git a/meta/recipes-support/libassuan/libassuan_2.1.2.bb b/meta/recipes-support/libassuan/libassuan_2.2.0.bb similarity index 86% rename from meta/recipes-support/libassuan/libassuan_2.1.2.bb rename to meta/recipes-support/libassuan/libassuan_2.2.0.bb index 97dec6a..5fc8b8c 100644 --- a/meta/recipes-support/libassuan/libassuan_2.1.2.bb +++ b/meta/recipes-support/libassuan/libassuan_2.2.0.bb @@ -13,8 +13,8 @@ DEPENDS = libgpg-error SRC_URI = ftp://ftp.gnupg.org/gcrypt/libassuan/libassuan-${PV}.tar.bz2 \ file://libassuan-add-pkgconfig-support.patch -SRC_URI[md5sum] = 1dc4c3e1dbfb3939bfa2d72db8e136ba -SRC_URI[sha256sum] = 39f8a7c9349aaaf7ccd937b90660153ec4d2d4df2465018754e5bcae5b1db77b +SRC_URI[md5sum] = a104faed3e97b9c302c5d67cc22b1d60 +SRC_URI[sha256sum] = 7df58ed70be4b694f77efd1f3b3f103c6311b6b71e04a370382f9fe8204f6ec6 BINCONFIG = ${bindir}/libassuan-config -- 2.1.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 12/12] libgpg-error: Update to 1.17
Rebased the pkgconfig.patch Added do_compile_prepend() copy an architecture specific header file. Signed-off-by: Saul Wold s...@linux.intel.com --- .../pkgconfig.patch| 67 ++ .../{libgpg-error_1.12.bb = libgpg-error_1.17.bb} | 35 +-- 2 files changed, 72 insertions(+), 30 deletions(-) rename meta/recipes-support/libgpg-error/{libgpg-error-1.12 = libgpg-error}/pkgconfig.patch (70%) rename meta/recipes-support/libgpg-error/{libgpg-error_1.12.bb = libgpg-error_1.17.bb} (40%) diff --git a/meta/recipes-support/libgpg-error/libgpg-error-1.12/pkgconfig.patch b/meta/recipes-support/libgpg-error/libgpg-error/pkgconfig.patch similarity index 70% rename from meta/recipes-support/libgpg-error/libgpg-error-1.12/pkgconfig.patch rename to meta/recipes-support/libgpg-error/libgpg-error/pkgconfig.patch index 89c9d22..96476ba 100644 --- a/meta/recipes-support/libgpg-error/libgpg-error-1.12/pkgconfig.patch +++ b/meta/recipes-support/libgpg-error/libgpg-error/pkgconfig.patch @@ -5,11 +5,11 @@ Upstream-Status: Pending -Index: libgpg-error-1.12/configure.ac +Index: libgpg-error-1.17/configure.ac === libgpg-error-1.12.orig/configure.ac2014-05-13 21:14:26.846393236 + -+++ libgpg-error-1.12/configure.ac 2014-05-13 21:14:26.926393236 + -@@ -217,6 +217,7 @@ +--- libgpg-error-1.17.orig/configure.ac libgpg-error-1.17/configure.ac +@@ -521,6 +521,7 @@ AC_CONFIG_FILES([src/Makefile tests/Make AC_CONFIG_FILES([lang/Makefile lang/cl/Makefile lang/cl/gpg-error.asd]) AC_CONFIG_FILES([src/versioninfo.rc]) AC_CONFIG_FILES([src/gpg-error-config], [chmod +x src/gpg-error-config]) @@ -17,11 +17,11 @@ Index: libgpg-error-1.12/configure.ac AC_OUTPUT -Index: libgpg-error-1.12/src/Makefile.am +Index: libgpg-error-1.17/src/Makefile.am === libgpg-error-1.12.orig/src/Makefile.am 2014-05-13 21:14:26.846393236 + -+++ libgpg-error-1.12/src/Makefile.am 2014-05-13 21:14:26.934393236 + -@@ -37,13 +37,15 @@ +--- libgpg-error-1.17.orig/src/Makefile.am libgpg-error-1.17/src/Makefile.am +@@ -74,13 +74,15 @@ nodist_include_HEADERS = gpg-error.h bin_SCRIPTS = gpg-error-config m4datadir = $(datadir)/aclocal m4data_DATA = gpg-error.m4 @@ -31,17 +31,17 @@ Index: libgpg-error-1.12/src/Makefile.am EXTRA_DIST = mkstrtable.awk err-sources.h.in err-codes.h.in \ mkerrnos.awk errnos.in README \ mkerrcodes.awk mkerrcodes1.awk mkerrcodes2.awk mkerrcodes.c \ - mkheader.awk gpg-error.h.in mkw32errmap.c w32-add.h w32ce-add.h \ + mkheader.c gpg-error.h.in mkw32errmap.c w32-add.h w32ce-add.h \ err-sources.h err-codes.h gpg-error-config.in gpg-error.m4 \ -- gpg-error.def.in versioninfo.rc.in -+ gpg-error.def.in versioninfo.rc.in gpg-error.pc.in +- gpg-error.vers gpg-error.def.in versioninfo.rc.in \ ++ gpg-error.vers gpg-error.def.in versioninfo.rc.in gpg-error.pc \ + $(lock_obj_pub) BUILT_SOURCES = err-sources.h err-codes.h code-to-errno.h code-from-errno.h \ - err-sources-sym.h err-codes-sym.h errnos-sym.h gpg-error.h \ -Index: libgpg-error-1.12/src/gpg-error.pc.in +Index: libgpg-error-1.17/src/gpg-error.pc.in === /dev/null 1970-01-01 00:00:00.0 + -+++ libgpg-error-1.12/src/gpg-error.pc.in 2014-05-13 21:48:20.266382916 + +--- /dev/null libgpg-error-1.17/src/gpg-error.pc.in @@ -0,0 +1,11 @@ +prefix=@prefix@ +exec_prefix=@exec_prefix@ @@ -54,11 +54,11 @@ Index: libgpg-error-1.12/src/gpg-error.pc.in +Version: @VERSION@ +Libs: -L${libdir} -lgpg-error +Cflags: -I${includedir} -Index: libgpg-error-1.12/src/gpg-error.m4 +Index: libgpg-error-1.17/src/gpg-error.m4 === libgpg-error-1.12.orig/src/gpg-error.m42014-05-13 21:45:02.038383922 + -+++ libgpg-error-1.12/src/gpg-error.m4 2014-05-13 21:47:08.362383281 + -@@ -15,58 +15,14 @@ +--- libgpg-error-1.17.orig/src/gpg-error.m4 libgpg-error-1.17/src/gpg-error.m4 +@@ -26,73 +26,13 @@ dnl is added to the gpg_config_script_wa dnl AC_DEFUN([AM_PATH_GPG_ERROR], [ AC_REQUIRE([AC_CANONICAL_HOST]) @@ -70,7 +70,7 @@ Index: libgpg-error-1.12/src/gpg-error.m4 - AC_HELP_STRING([--with-libgpg-error-prefix=PFX], - [prefix where GPG Error is installed (optional)]), - [gpg_error_config_prefix=$withval]) - +- - dnl Accept --with-gpg-error-prefix and make it work the same as - dnl --with-libgpg-error-prefix above, for backwards compatibility, - dnl but do not document this old, inconsistently-named option. @@ -78,14 +78,27 @@ Index: libgpg-error-1.12/src/gpg-error.m4 - [gpg_error_config_prefix=$withval]) +
[OE-core] [PATCH 11/12] liburcu: Upgrade to 0.8.6
Move patches from files to liburcu directory Signed-off-by: Saul Wold s...@linux.intel.com --- meta/recipes-support/liburcu/{files = liburcu}/aarch64.patch | 0 meta/recipes-support/liburcu/{liburcu_0.8.5.bb = liburcu_0.8.6.bb} | 4 ++-- 2 files changed, 2 insertions(+), 2 deletions(-) rename meta/recipes-support/liburcu/{files = liburcu}/aarch64.patch (100%) rename meta/recipes-support/liburcu/{liburcu_0.8.5.bb = liburcu_0.8.6.bb} (83%) diff --git a/meta/recipes-support/liburcu/files/aarch64.patch b/meta/recipes-support/liburcu/liburcu/aarch64.patch similarity index 100% rename from meta/recipes-support/liburcu/files/aarch64.patch rename to meta/recipes-support/liburcu/liburcu/aarch64.patch diff --git a/meta/recipes-support/liburcu/liburcu_0.8.5.bb b/meta/recipes-support/liburcu/liburcu_0.8.6.bb similarity index 83% rename from meta/recipes-support/liburcu/liburcu_0.8.5.bb rename to meta/recipes-support/liburcu/liburcu_0.8.6.bb index 62323d3..263b77e 100644 --- a/meta/recipes-support/liburcu/liburcu_0.8.5.bb +++ b/meta/recipes-support/liburcu/liburcu_0.8.6.bb @@ -12,8 +12,8 @@ SRC_URI = http://lttng.org/files/urcu/userspace-rcu-${PV}.tar.bz2 \ file://aarch64.patch \ -SRC_URI[md5sum] = 24ba9e03542b747d3378434eb0041acf -SRC_URI[sha256sum] = a2562eaca107ec6eca2856632b6035c6aaf38df79020195ed8955a7b4773312a +SRC_URI[md5sum] = 834d91d939dd55108a05763be9879856 +SRC_URI[sha256sum] = b1a5d3bce014ba7a702759bc60b692c1cd46ff0e8a5b53f0d0a95e22db74ab21 S = ${WORKDIR}/userspace-rcu-${PV} CFLAGS_append_libc-uclibc = -D_GNU_SOURCE -- 2.1.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 4/4] manifest.py/image.bbclass: add var-INSTALL_ALL to install all packages of a recipes.
Add variable INSTALL_ALL to install all available packages of a recipe, the recipe comes from the package listed in PACKAGE_INSTALL (IMAGE_INSTALL also) Here is the design: 1) According to the packages listed in PACKAGE_INSTALL, figure out recipes which produced them by invoking script oe-pkgdata-util; 2) Go on invoking script oe-pkgdata-util to list all available packages in these recipes except *-(doc|dbg|dev|staticdev|locale|ptest), and use them to replace packages in PACKAGE_INSTALL; 3) Packages installation at do_rootfs time as normal; 4) INSTALL_ALL is a global switch for all packages listed in PACKAGE_INSTALL, you also could assign INSTALL_ALL_pkgname ?= 1 for the particular package in PACKAGE_INSTALL; [YOCTO #5264] Signed-off-by: Hongxu Jia hongxu@windriver.com --- meta/classes/image.bbclass | 19 +++- meta/lib/oe/manifest.py| 56 -- 2 files changed, 72 insertions(+), 3 deletions(-) diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass index 07e7f99..8c7df9a 100644 --- a/meta/classes/image.bbclass +++ b/meta/classes/image.bbclass @@ -54,6 +54,16 @@ def check_image_features(d): if feature not in valid_features: bb.fatal('%s' in IMAGE_FEATURES is not a valid image feature. Valid features: %s % (feature, ' '.join(valid_features))) +# Assign INSTALL_ALL ?= 1 means: +# 1) According to the packages listed in PACKAGE_INSTALL, figure out recipes +#which produced them by invoking script oe-pkgdata-util; +# 2) Go on invoking script oe-pkgdata-util to list all available packages in +#these recipes except *-(doc|dbg|dev|staticdev|locale|ptest), and use them +#to replace packages in PACKAGE_INSTALL; +# 3) INSTALL_ALL is a global switch for all packages listed in PACKAGE_INSTALL, +#you also could assign INSTALL_ALL_pkgname ?= 1 for the particular +#package in PACKAGE_INSTALL. +INSTALL_ALL ?= 0 IMAGE_INSTALL ?= IMAGE_INSTALL[type] = list export PACKAGE_INSTALL ?= ${IMAGE_INSTALL} ${ROOTFS_BOOTSTRAP_INSTALL} ${FEATURE_INSTALL} @@ -95,9 +105,16 @@ def rootfs_variables(d): 'SDK_OUTPUT','SDKPATHNATIVE','SDKTARGETSYSROOT','SDK_DIR','SDK_VENDOR','SDKIMAGE_INSTALL_COMPLEMENTARY','SDK_PACKAGE_ARCHS','SDK_OUTPUT','SDKTARGETSYSROOT','MULTILIBRE_ALLOW_REP', 'MULTILIB_TEMP_ROOTFS','MULTILIB_VARIANTS','MULTILIBS','ALL_MULTILIB_PACKAGE_ARCHS','MULTILIB_GLOBAL_VARIANTS','BAD_RECOMMENDATIONS','NO_RECOMMENDATIONS','PACKAGE_ARCHS', 'PACKAGE_CLASSES','TARGET_VENDOR','TARGET_VENDOR','TARGET_ARCH','TARGET_OS','OVERRIDES','BBEXTENDVARIANT','FEED_DEPLOYDIR_BASE_URI','INTERCEPT_DIR','BUILDNAME','USE_DEVFS', - 'STAGING_KERNEL_DIR','COMPRESSIONTYPES'] + 'STAGING_KERNEL_DIR','COMPRESSIONTYPES', 'INSTALL_ALL'] variables.extend(command_variables(d)) variables.extend(variable_depends(d)) + +for pkg in (d.getVar('PACKAGE_INSTALL', True) or '').split(): +installall_var = 'INSTALL_ALL_%s' % pkg +installall_val = d.getVar(installall_var, True) +if installall_val and installall_var not in variables: +variables.append(installall_var) + return .join(variables) do_rootfs[vardeps] += ${@rootfs_variables(d)} diff --git a/meta/lib/oe/manifest.py b/meta/lib/oe/manifest.py index 42832f1..b61ee9d 100644 --- a/meta/lib/oe/manifest.py +++ b/meta/lib/oe/manifest.py @@ -2,6 +2,7 @@ from abc import ABCMeta, abstractmethod import os import re import bb +import subprocess class Manifest(object): @@ -139,6 +140,55 @@ class Manifest(object): pass +Find recipe which produced package pkgname, and look up all available +packages in that recipe except *-(doc|dbg|dev|staticdev|locale|ptest) + +def _lookup_packages(self, pkgtype=PKG_TYPE_ATTEMPT_ONLY, pkgname=None): +if pkgname is None: +bb.warn('pkgname is None') +return [] + +if pkgtype == self.PKG_TYPE_ATTEMPT_ONLY or \ + pkgtype == self.PKG_TYPE_LANGUAGE: +return [] + +if self.d.getVar('INSTALL_ALL', True) != '1' and \ + self.d.getVar('INSTALL_ALL_%s' % pkgname, True) != '1': +return [] + +pkgdata_dir = self.d.getVar('PKGDATA_DIR', True) +cmd = oe-pkgdata-util lookup-recipe %s %s % (pkgdata_dir, pkgname) +try: +recipe = subprocess.check_output(cmd, + stderr=subprocess.STDOUT, + shell=True) +except subprocess.CalledProcessError as e: +bb.note(Could not lookup recipe for package %s % (pkgname)) +return [] + +cmd = oe-pkgdata-util list-packages %s %s % (pkgdata_dir, recipe) +try: +output = subprocess.check_output(cmd, + stderr=subprocess.STDOUT, +
[OE-core] [PATCH 3/4] python3: avoid debian renaming for libpython3
When Debian-renaming, 'libpython3' was incorrectly converted to 'libpython3.3m1.0', it caused install 'libpython3' failed. (IMAGE_INSTALL_append = python3, INSTALL_ALL_python3 = 1) ... ERROR: libpython3 not found in the base feeds (qemux86 i586 x86 noarch any all). libpython3.3m1.0-3.3.3-r0.0@i586 ... We assign DEBIAN_NOAUTONAME for 'libpython3' to avoid debian renaming. The same to 'libpython3-staticdev'. [YOCTO #5264] Signed-off-by: Hongxu Jia hongxu@windriver.com --- meta/recipes-devtools/python/python3_3.3.3.bb | 2 ++ 1 file changed, 2 insertions(+) diff --git a/meta/recipes-devtools/python/python3_3.3.3.bb b/meta/recipes-devtools/python/python3_3.3.3.bb index 2c1f63f..3163fbd 100644 --- a/meta/recipes-devtools/python/python3_3.3.3.bb +++ b/meta/recipes-devtools/python/python3_3.3.3.bb @@ -204,6 +204,8 @@ FILES_${PN}-pyvenv += ${bindir}/pyvenv-${PYTHON_MAJMIN} ${bindir}/pyvenv PACKAGES =+ libpython3 libpython3-staticdev FILES_libpython3 = ${libdir}/libpython*.so.* FILES_libpython3-staticdev += ${libdir}/python${PYTHON_MAJMIN}/config-${PYTHON_BINABI}/libpython${PYTHON_BINABI}.a +DEBIAN_NOAUTONAME_libpython3 = 1 +DEBIAN_NOAUTONAME_libpython3-staticdev = 1 # catch debug extensions (isn't that already in python-core-dbg?) FILES_${PN}-dbg += ${libdir}/python${PYTHON_MAJMIN}/lib-dynload/.debug -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/4] add variable INSTALL_ALL to install all packages in recipes
Test Steps: Install busybox and lib32-python3 to core-image-minimal, and also install all available packages of recipes busybox and python3. 1. vim local.conf ... MACHINE ?= qemux86-64 require conf/multilib.conf MULTILIBS = multilib:lib32 DEFAULTTUNE_virtclass-multilib-lib32 = x86 IMAGE_INSTALL_append = busybox lib32-python3 INSTALL_ALL_busybox ?= 1 INSTALL_ALL_lib32-python3 ?= 1 ... 2. Build core-image-minimal $ bitbake core-image-minimal 3. Check installed_pkgs.txt, all available packages of recipes busybox and lib32-python3 have been installed. ... $ cat tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/installed_pkgs.txt ... busybox core2-64 busybox-hwclock core2-64 busybox-syslog core2-64 busybox-udhcpc core2-64 busybox-udhcpd core2-64 ... 4. Edit local.conf to assign INSTALL_ALL_busybox ?= 0 5. build core-image-minimal 6. Check installed_pkgs.txt, busybox-udhcpd not installed ... $ cat tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/installed_pkgs.txt ... busybox core2-64 busybox-hwclock core2-64 busybox-syslog core2-64 busybox-udhcpc core2-64 ... //Hongxu The following changes since commit bfe7d3032a61a20010b5b758be07581e1bf01cba: gstreamer1.0-omx: use mulitple SCMs to fetch submodules (2014-12-31 17:04:52 +) are available in the git repository at: git://git.pokylinux.org/poky-contrib hongxu/install-all http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=hongxu/install-all Hongxu Jia (4): scripts/oe-pkgdata-util: support rprovides for lookup-recipe scripts/oe-pkgdata-util: add ability to list all produced packages from a recipe python3: avoid debian renaming for libpython3 manifest.py/image.bbclass: add var-INSTALL_ALL to install all packages of a recipes. meta/classes/image.bbclass| 19 - meta/lib/oe/manifest.py | 56 +- meta/recipes-devtools/python/python3_3.3.3.bb | 2 + scripts/oe-pkgdata-util | 101 +- 4 files changed, 174 insertions(+), 4 deletions(-) -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/4] scripts/oe-pkgdata-util: support rprovides for lookup-recipe
If failed to invoke lookup-recipe while pkg not generated but provided by others, such as python3, it is provided by python3-core ... $ bitbake python3 $ oe-pkgdata-util -d lookup-recipe tmp/sysroots/qemux86/pkgdata/ python3 ERROR: the following packages could not be found: python3 ... In this situation, we search the pkg's rprovides (if available) to replace. [YOCTO #5264] Signed-off-by: Hongxu Jia hongxu@windriver.com --- scripts/oe-pkgdata-util | 54 + 1 file changed, 54 insertions(+) diff --git a/scripts/oe-pkgdata-util b/scripts/oe-pkgdata-util index bf87547..e43f773 100755 --- a/scripts/oe-pkgdata-util +++ b/scripts/oe-pkgdata-util @@ -27,6 +27,7 @@ import fnmatch import re import optparse from collections import defaultdict +import codecs def glob(args, usage, debug=False): if len(args) 3: @@ -234,6 +235,19 @@ def lookup_recipe(args, usage, debug=False): print('ERROR: Unable to find pkgdata directory %s' % pkgdata_dir) sys.exit(1) +# If the pkg not generated, search the rprovides to replace +rprovides = collect_rprovides(pkgdata_dir) +for pkg in pkgs[:]: +pkgfile = os.path.join(pkgdata_dir, 'runtime', pkg) +if not os.path.exists(pkgfile): +for newpkg, oldpkg in rprovides.items(): +if oldpkg == pkg: +if debug: +print('%s rprovides %s' % (newpkg, pkg)) +pkgs.remove(pkg) +pkgs.append(newpkg) +break + mappings = defaultdict(list) for pkg in pkgs: pkgfile = os.path.join(pkgdata_dir, 'runtime-reverse', pkg) @@ -254,6 +268,46 @@ def lookup_recipe(args, usage, debug=False): items.extend(mappings.get(pkg, [])) print '\n'.join(items) +def collect_rprovides(pkgdata_dir): +def read_pkgdatafile(fn): +pkgdata = {} +def decode(str): +c = codecs.getdecoder(string_escape) +return c(str)[0] + +if os.access(fn, os.R_OK): +import re +f = open(fn, 'r') +lines = f.readlines() +f.close() +r = re.compile(([^:]+):\s*(.*)) +for l in lines: +m = r.match(l) +if m: +pkgdata[m.group(1)] = decode(m.group(2)) +return pkgdata + +rprovides_dict = dict() +if os.path.exists(pkgdata_dir): +for root, dirs, files in os.walk(%s/runtime % pkgdata_dir): +for pkgname in files: +pkgdatafile = %s/%s % (root, pkgname) +if not os.access(%s.packaged % pkgdatafile, os.R_OK): +continue + +try: +sdata = read_pkgdatafile(pkgdatafile) +rprovides = sdata.get('RPROVIDES_%s' % pkgname) +if rprovides: +rprovides_dict[pkgname] = rprovides + +except Exception as e: +print(ERROR:%s: Failed to read pkgdata file %s: %s: %s % + (pkgname, pkgdatafile, e.__class__, str(e))) +sys.exit(1) + +return rprovides_dict + def find_path(args, usage, debug=False): if len(args) 2: usage() -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/4] scripts/oe-pkgdata-util: add ability to list all produced packages from a recipe
Add a list-packages command to list all produced packages by a particular recipe. [YOCTO #5264] Signed-off-by: Hongxu Jia hongxu@windriver.com --- scripts/oe-pkgdata-util | 47 ++- 1 file changed, 46 insertions(+), 1 deletion(-) diff --git a/scripts/oe-pkgdata-util b/scripts/oe-pkgdata-util index e43f773..984f66e 100755 --- a/scripts/oe-pkgdata-util +++ b/scripts/oe-pkgdata-util @@ -28,6 +28,7 @@ import re import optparse from collections import defaultdict import codecs +import errno def glob(args, usage, debug=False): if len(args) 3: @@ -308,6 +309,46 @@ def collect_rprovides(pkgdata_dir): return rprovides_dict +def list_packages(args, usage, debug=False): +if len(args) 2: +usage() +sys.exit(1) + +pkgdata_dir = args[0] +if not os.path.exists(pkgdata_dir): +print('ERROR: Unable to find pkgdata directory %s' % pkgdata_dir) +sys.exit(1) + +if len(args[1].split()) != 1: +print('ERROR: Only one recipe name is acceptable') +sys.exit(1) + +recipe = args[1] +packages = +try: +with open(os.path.join(pkgdata_dir, recipe)) as f: +for line in f.readlines(): +if line.startswith('PACKAGES: '): +packages = line.split(': ', 1)[1].split() +break +except IOError as e: +if e.errno == errno.ENOENT: +print('ERROR: The recipe %s does not exist' % recipe) +sys.exit(1) +else: +raise + +# Filter out packages that not generated +for pkg in packages[:]: +flag_packaged = %s/runtime/%s.packaged % (pkgdata_dir, pkg) +if not os.access(flag_packaged, os.R_OK): +if debug: +print(%s not produced by %s % (pkg, recipe)) +packages.remove(pkg) + +print '\n'.join(packages) + + def find_path(args, usage, debug=False): if len(args) 2: usage() @@ -354,7 +395,9 @@ Available commands: find the package providing the specified path (wildcards * ? allowed) read-value pkgdatadir value-name pkgs read the named value from the pkgdata files for the specified -packages''') +packages +list-packages pkgdatadir recipe +list all packages produced by the particular recipe''') parser.add_option(-d, --debug, help = Enable debug output, @@ -377,6 +420,8 @@ Available commands: find_path(args[1:], parser.print_help, options.debug) elif args[0] == read-value: read_value(args[1:], parser.print_help, options.debug) +elif args[0] == list-packages: +list_packages(args[1:], parser.print_help, options.debug) else: parser.print_help() sys.exit(1) -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] layerindex.bbclass: Add ability to fetch layers from layer index
It maybe depends on other layers when one layer is added to BBLAYERS. If define LAYERDEPENDS variable in this layer, we will get error from bitbake. But sometimes, we don't have defined. Add a mechanism to fetch layers from layer index and update bblayers.conf as appropriate. The layer index stores dependencies of all layers. Query dependency from layer index and fetch layer repo, then add this layer to BBLAYERS. [YOCTO #5348] Signed-off-by: Chong Lu chong...@windriver.com --- meta/classes/layerindex.bbclass | 154 1 file changed, 154 insertions(+) create mode 100644 meta/classes/layerindex.bbclass diff --git a/meta/classes/layerindex.bbclass b/meta/classes/layerindex.bbclass new file mode 100644 index 000..21d4d97 --- /dev/null +++ b/meta/classes/layerindex.bbclass @@ -0,0 +1,154 @@ +LAYER_FETCH_DIR ??= ${COREBASE} + +python layerindex_handler() { +import bb.event +if not e.data: +return + +import httplib, urlparse, json +import os + +def get_json_data(apiurl = http://layers.openembedded.org/layerindex/api/;): +proxy_settings = os.environ.get(http_proxy, None) +conn = None +_parsedurl = urlparse.urlparse(apiurl) +path = _parsedurl.path +query = _parsedurl.query +def parse_url(url): +parsedurl = urlparse.urlparse(url) +try: +(host, port) = parsedurl.netloc.split(:) +except ValueError: +host = parsedurl.netloc +port = None + +if port is None: +port = 80 +else: +port = int(port) +return (host, port) + +if proxy_settings is None: +host, port = parse_url(apiurl) +conn = httplib.HTTPConnection(host, port) +conn.request(GET, path + ? + query) +else: +host, port = parse_url(proxy_settings) +conn = httplib.HTTPConnection(host, port) +conn.request(GET, apiurl) + +r = conn.getresponse() +if r.status != 200: +bb.fatal(Failed to read + path + : %d %s % (r.status, r.reason)) +return json.loads(r.read()) + +def get_deps_url(name, layeritems, layerbranches, layerdependencies): +def layeritems_info(items_name = None, items_id = None): +litems = {} +for li in layeritems: +if li['name'] == items_name: +litems['id'] = li['id'] +break +if li['id'] == items_id: +litems['vcs_url'] = li['vcs_url'] +litems['name'] = li['name'] +break +return litems + +def layerbranches_info(items_id): +lbranch = {} +for lb in layerbranches: +# branch is master. +if lb['layer'] == items_id and lb['branch'] == 1: +lbranch['id'] = lb['id'] +lbranch['vcs_subdir'] = lb['vcs_subdir'] +break +if not lbranch['id']: +bb.fatal(The id of layerBranches is not found.) +return lbranch + +def layerdependencies_info(lb_id): +ld_deps = [] +for ld in layerdependencies: +if ld['layerbranch'] == lb_id and not ld['dependency'] in ld_deps: +ld_deps.append(ld['dependency']) +if not ld_deps: +bb.fatal(The dependency of layerDependencies is not found.) +return ld_deps + +itemsid = layeritems_info(items_name = name)['id'] +lbid = layerbranches_info(itemsid)['id'] +layerdict = {} +for dependency in layerdependencies_info(lbid): +layername = layeritems_info(items_id = dependency)['name'] +layerurl = layeritems_info(items_id = dependency)['vcs_url'] +layersubdir = layerbranches_info(dependency)['vcs_subdir'] +layerdict[layername] = layerurl, layersubdir +return layerdict + +import sys +import subprocess + +def download_layer(url, subdir): +fetchdir = e.data.getVar(LAYER_FETCH_DIR, True) +if not fetchdir: +bb.fatal(Please set LAYER_FETCH_DIR variable.) +if not os.path.exists(fetchdir): +os.makedirs(fetchdir) +urldir = url.split(/)[-1] +if urldir.endswith(.git): +urldir = urldir.split(.)[0] +repodir = os.path.join(fetchdir, urldir) +if subdir: +layerdir = os.path.join(repodir, subdir) +else: +layerdir = repodir +if not os.path.exists(layerdir): +bb.warn(Fetch '%s' to '%s' % (layer, e.data.getVar(LAYER_FETCH_DIR, True))) +result = subprocess.call('git clone %s %s' % (url, repodir), shell = True) +if result: +bb.fatal(Failed to download %s % url) +
[OE-core] [PATCH 0/1] layerindex.bbclass: Add ability to fetch layers from layer index
How to use this class: For example: If you want to build python-nova, first you should know meta-openstack layer includes python-nova. And then, add meta-openstack to conf/bblayers.conf: ... BBLAYERS ?= \ /buildarea2/clu1/source/poky/meta \ /buildarea2/clu1/source/poky/meta-yocto \ /buildarea2/clu1/source/poky/meta-yocto-bsp \ /buildarea2/clu1/source/poky/meta-cloud-services/meta-openstack \ ... And then, run bitbake python-nova, we will get following error: $ bitbake python-nova ERROR: Layer 'meta-openstack' depends on layer 'meta-ruby', but this layer is not enabled in your configuration Add '/buildarea2/clu1/source/poky/meta-openembedded/meta-ruby' to BBLAYERS. You can check conf/bblayers.conf Summary: There was 1 ERROR message shown, returning a non-zero exit code. Check conf/bblayers.conf, the meta-ruby has already added to BBALYERS. ... BBLAYERS += /buildarea2/clu1/source/poky/meta-openembedded/meta-ruby And then, run bitbake python-nova, we will get following error: $ bitbake python-nova ERROR: Layer 'ruby-layer' depends on layer 'openembedded-layer', but this layer is not enabled in your configuration Summary: There was 1 ERROR message shown, returning a non-zero exit code. We need add meta-oe to BBLAYERS and continue to run bitbake python-nova, still error: $ bitbake python-nova ERROR: Layer 'meta-openstack' depends on layer 'meta-networking', but this layer is not enabled in your configuration Add '/buildarea2/clu1/source/poky/meta-openembedded/meta-networking' to BBLAYERS. You can check conf/bblayers.conf Summary: There was 1 ERROR message shown, returning a non-zero exit code. Check conf/bblayers.conf, the meta-networking has already added to BBALYERS. ... BBLAYERS += /buildarea2/clu1/source/poky/meta-openembedded/meta-networking Continue to run, will get error: $ bitbake python-nova ERROR: Layer 'networking-layer' depends on layer 'meta-python', but this layer is not enabled in your configuration Summary: There was 1 ERROR message shown, returning a non-zero exit code. Add meta-python to BBLAYERS manually: ... BBLAYERS ?= \ /buildarea2/clu1/source/poky/meta \ /buildarea2/clu1/source/poky/meta-yocto \ /buildarea2/clu1/source/poky/meta-yocto-bsp \ /buildarea2/clu1/source/poky/meta-cloud-services/meta-openstack \ /buildarea2/clu1/source/poky/meta-openembedded/meta-oe \ /buildarea2/clu1/source/poky/meta-openembedded/meta-python \ ... Still run bitbake python-nova, will fetch layer automatically: $ bitbake python-nova WARNING: Fetch 'meta-virtualization' to '/buildarea2/clu1/source/poky' Cloning into '/buildarea2/clu1/source/poky/meta-virtualization'... remote: Counting objects: 1461, done. remote: Compressing objects: 100% (791/791), done. remote: Total 1461 (delta 803), reused 1262 (delta 604) Receiving objects: 100% (1461/1461), 303.15 KiB | 158.00 KiB/s, done. Resolving deltas: 100% (803/803), done. Checking connectivity... done. ERROR: Layer 'meta-openstack' depends on layer 'meta-virtualization', but this layer is not enabled in your configuration Add '/buildarea2/clu1/source/poky/meta-virtualization' to BBLAYERS. You can check conf/bblayers.conf Summary: There was 1 WARNING message shown. Summary: There was 1 ERROR message shown, returning a non-zero exit code. Check conf/bblayers.conf, meta-virtualization layer is added to BBLAYERS Finally, run bitbake python-nova, recipes are parsed. The following changes since commit 2674ddb4b0c0645c91d1794cbd9166418b984351: dev-manual: Some minor fixes to some text. (2015-01-06 14:27:03 +) are available in the git repository at: git://git.pokylinux.org/poky-contrib chonglu/layerindex http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=chonglu/layerindex Chong Lu (1): layerindex.bbclass: Add ability to fetch layers from layer index meta/classes/layerindex.bbclass | 154 1 file changed, 154 insertions(+) create mode 100644 meta/classes/layerindex.bbclass -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] so, which mailing list is for what?
On Tue, 6 Jan 2015, Nicolas Dechesne wrote: On Tue, Jan 6, 2015 at 5:59 PM, Robert P. J. Day rpj...@crashcourse.ca wrote: apparently, i still don't have a handle on the correct mailing list for particular patch submissions -- where's the explanation as to what goes where? http://www.openembedded.org/wiki/Mailing_lists in particular, i want to submit some cleanups for some oe-core packagegroup recipe files, which list does that go to? thanks. i'll figure this out eventually. oe-core patches should go to openembedded-core@lists.openembedded.org thank you kindly. 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.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] Tidy up aesthetics of packagegroup recipe files.
Some aesthetic cleanup of packagegroup files to make them more consistent and easier to read: * standard indentation and line continuation * as much as possible, use ${PN} instead of hardcoded filename Signed-off-by: Robert P. J. Day rpj...@crashcourse.ca --- while pedantic, this cleanup makes the packagegroup files easier to peruse and use for demo when i'm teaching classes. also, as much as possible and when consistent over the entire file, i replaced the hardcoded packagegroup filename with the variable ${PN} to make it more visually obvious that that's what was happening. to test, i just created a new project and ran a bitbake parse, and everything seemed fine. diff --git a/meta/recipes-core/packagegroups/packagegroup-base.bb b/meta/recipes-core/packagegroups/packagegroup-base.bb index f4b2cd5..61031c7 100644 --- a/meta/recipes-core/packagegroups/packagegroup-base.bb +++ b/meta/recipes-core/packagegroups/packagegroup-base.bb @@ -11,38 +11,37 @@ inherit packagegroup PROVIDES = ${PACKAGES} PACKAGES = ' \ -packagegroup-base \ -packagegroup-base-extended \ -packagegroup-distro-base \ -packagegroup-machine-base \ -\ -${@bb.utils.contains(MACHINE_FEATURES, acpi, packagegroup-base-acpi, ,d)} \ -${@bb.utils.contains(MACHINE_FEATURES, alsa, packagegroup-base-alsa, , d)} \ -${@bb.utils.contains(MACHINE_FEATURES, apm, packagegroup-base-apm, , d)} \ -${@bb.utils.contains(MACHINE_FEATURES, ext2, packagegroup-base-ext2, , d)} \ -${@bb.utils.contains(MACHINE_FEATURES, vfat, packagegroup-base-vfat, , d)} \ -${@bb.utils.contains(MACHINE_FEATURES, irda, packagegroup-base-irda, ,d)} \ -${@bb.utils.contains(MACHINE_FEATURES, keyboard, packagegroup-base-keyboard, , d)} \ -${@bb.utils.contains(MACHINE_FEATURES, pci, packagegroup-base-pci, ,d)} \ -${@bb.utils.contains(MACHINE_FEATURES, pcmcia, packagegroup-base-pcmcia, , d)} \ -${@bb.utils.contains(MACHINE_FEATURES, phone, packagegroup-base-phone, , d)} \ -${@bb.utils.contains(MACHINE_FEATURES, serial, packagegroup-base-serial, , d)} \ -${@bb.utils.contains(MACHINE_FEATURES, usbgadget, packagegroup-base-usbgadget, , d)} \ -${@bb.utils.contains(MACHINE_FEATURES, usbhost, packagegroup-base-usbhost, , d)} \ -\ -${@bb.utils.contains(DISTRO_FEATURES, bluetooth, packagegroup-base-bluetooth, , d)} \ -${@bb.utils.contains(DISTRO_FEATURES, wifi, packagegroup-base-wifi, , d)} \ -${@bb.utils.contains(DISTRO_FEATURES, 3g, packagegroup-base-3g, , d)} \ -${@bb.utils.contains(DISTRO_FEATURES, nfc, packagegroup-base-nfc, , d)} \ -${@bb.utils.contains(DISTRO_FEATURES, cramfs, packagegroup-base-cramfs, , d)} \ -${@bb.utils.contains(DISTRO_FEATURES, ipsec, packagegroup-base-ipsec, , d)} \ -${@bb.utils.contains(DISTRO_FEATURES, ipv6, packagegroup-base-ipv6, , d)} \ -${@bb.utils.contains(DISTRO_FEATURES, nfs, packagegroup-base-nfs, , d)} \ -${@bb.utils.contains(DISTRO_FEATURES, ppp, packagegroup-base-ppp, , d)} \ -${@bb.utils.contains(DISTRO_FEATURES, smbfs, packagegroup-base-smbfs, , d)} \ -${@bb.utils.contains(DISTRO_FEATURES, zeroconf, packagegroup-base-zeroconf, , d)} \ -\ -' +packagegroup-base \ +packagegroup-base-extended \ +packagegroup-distro-base \ +packagegroup-machine-base \ +\ +${@bb.utils.contains(MACHINE_FEATURES, acpi, packagegroup-base-acpi, ,d)} \ +${@bb.utils.contains(MACHINE_FEATURES, alsa, packagegroup-base-alsa, , d)} \ +${@bb.utils.contains(MACHINE_FEATURES, apm, packagegroup-base-apm, , d)} \ +${@bb.utils.contains(MACHINE_FEATURES, ext2, packagegroup-base-ext2, , d)} \ +${@bb.utils.contains(MACHINE_FEATURES, vfat, packagegroup-base-vfat, , d)} \ +${@bb.utils.contains(MACHINE_FEATURES, irda, packagegroup-base-irda, ,d)} \ +${@bb.utils.contains(MACHINE_FEATURES, keyboard, packagegroup-base-keyboard, , d)} \ +${@bb.utils.contains(MACHINE_FEATURES, pci, packagegroup-base-pci, ,d)} \ +${@bb.utils.contains(MACHINE_FEATURES, pcmcia, packagegroup-base-pcmcia, , d)} \ +${@bb.utils.contains(MACHINE_FEATURES, phone, packagegroup-base-phone, , d)} \ +${@bb.utils.contains(MACHINE_FEATURES, serial, packagegroup-base-serial, , d)} \ +${@bb.utils.contains(MACHINE_FEATURES, usbgadget, packagegroup-base-usbgadget, , d)} \ +${@bb.utils.contains(MACHINE_FEATURES, usbhost, packagegroup-base-usbhost, , d)} \ +\ +${@bb.utils.contains(DISTRO_FEATURES, bluetooth, packagegroup-base-bluetooth, , d)} \ +${@bb.utils.contains(DISTRO_FEATURES, wifi, packagegroup-base-wifi, , d)} \ +${@bb.utils.contains(DISTRO_FEATURES, 3g, packagegroup-base-3g, , d)} \ +
Re: [OE-core] [PATCH 05/12] gnu-efi: Upgrade to 3.0w
On 6 January 2015 at 15:42, Saul Wold s...@linux.intel.com wrote: --- a/meta/recipes-bsp/gnu-efi/gnu-efi_3.0u.bb +++ b/meta/recipes-bsp/gnu-efi/gnu-efi_3.0w.bb @@ -8,6 +8,7 @@ SRC_URI = http://downloads.sourceforge.net/gnu-efi/gnu-efi_3.0u.orig.tar.gz \ file://parallel-make.patch \ file://parallel-make-archives.patch \ + SRC_URI[md5sum] = d15d3c700e79a1e2938544d73edc572d SRC_URI[sha256sum] = 3c0d450d5829204ca05dcb3b2aae772e52c379b7c7e09146759c6315606f934e No change to the checksums, presumably they didn't brute-force a sha256sum attack to do that. ;) Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 05/12] gnu-efi: Upgrade to 3.0w
On 01/06/2015 08:37 AM, Burton, Ross wrote: On 6 January 2015 at 15:42, Saul Wold s...@linux.intel.com wrote: --- a/meta/recipes-bsp/gnu-efi/gnu-efi_3.0u.bb +++ b/meta/recipes-bsp/gnu-efi/gnu-efi_3.0w.bb @@ -8,6 +8,7 @@ SRC_URI = http://downloads.sourceforge.net/gnu-efi/gnu-efi_3.0u.orig.tar.gz \ file://parallel-make.patch \ file://parallel-make-archives.patch \ + SRC_URI[md5sum] = d15d3c700e79a1e2938544d73edc572d SRC_URI[sha256sum] = 3c0d450d5829204ca05dcb3b2aae772e52c379b7c7e09146759c6315606f934e No change to the checksums, presumably they didn't brute-force a sha256sum attack to do that. ;) Looking at this, it would probably have helped if I actually updated the tarball, Sorry for the noise with this gnu-efi non-update! Sau! Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] so, which mailing list is for what?
On Tue, Jan 6, 2015 at 5:59 PM, Robert P. J. Day rpj...@crashcourse.ca wrote: apparently, i still don't have a handle on the correct mailing list for particular patch submissions -- where's the explanation as to what goes where? http://www.openembedded.org/wiki/Mailing_lists in particular, i want to submit some cleanups for some oe-core packagegroup recipe files, which list does that go to? thanks. i'll figure this out eventually. oe-core patches should go to openembedded-core@lists.openembedded.org -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Tidy up aesthetics of packagegroup recipe files.
On Tue, Jan 06, 2015 at 01:03:04PM -0500, Robert P. J. Day wrote: Some aesthetic cleanup of packagegroup files to make them more consistent and easier to read: * standard indentation and line continuation * as much as possible, use ${PN} instead of hardcoded filename I think the consensus was to put closing quote as first character on own line (not aligned with other entries). This way it's easier to spot where multi-line variable starts and ends. If you really want, you can find discussion about this on ML. Signed-off-by: Robert P. J. Day rpj...@crashcourse.ca --- while pedantic, this cleanup makes the packagegroup files easier to peruse and use for demo when i'm teaching classes. also, as much as possible and when consistent over the entire file, i replaced the hardcoded packagegroup filename with the variable ${PN} to make it more visually obvious that that's what was happening. to test, i just created a new project and ran a bitbake parse, and everything seemed fine. diff --git a/meta/recipes-core/packagegroups/packagegroup-base.bb b/meta/recipes-core/packagegroups/packagegroup-base.bb index f4b2cd5..61031c7 100644 --- a/meta/recipes-core/packagegroups/packagegroup-base.bb +++ b/meta/recipes-core/packagegroups/packagegroup-base.bb @@ -11,38 +11,37 @@ inherit packagegroup PROVIDES = ${PACKAGES} PACKAGES = ' \ -packagegroup-base \ -packagegroup-base-extended \ -packagegroup-distro-base \ -packagegroup-machine-base \ -\ -${@bb.utils.contains(MACHINE_FEATURES, acpi, packagegroup-base-acpi, ,d)} \ -${@bb.utils.contains(MACHINE_FEATURES, alsa, packagegroup-base-alsa, , d)} \ -${@bb.utils.contains(MACHINE_FEATURES, apm, packagegroup-base-apm, , d)} \ -${@bb.utils.contains(MACHINE_FEATURES, ext2, packagegroup-base-ext2, , d)} \ -${@bb.utils.contains(MACHINE_FEATURES, vfat, packagegroup-base-vfat, , d)} \ -${@bb.utils.contains(MACHINE_FEATURES, irda, packagegroup-base-irda, ,d)} \ -${@bb.utils.contains(MACHINE_FEATURES, keyboard, packagegroup-base-keyboard, , d)} \ -${@bb.utils.contains(MACHINE_FEATURES, pci, packagegroup-base-pci, ,d)} \ -${@bb.utils.contains(MACHINE_FEATURES, pcmcia, packagegroup-base-pcmcia, , d)} \ -${@bb.utils.contains(MACHINE_FEATURES, phone, packagegroup-base-phone, , d)} \ -${@bb.utils.contains(MACHINE_FEATURES, serial, packagegroup-base-serial, , d)} \ -${@bb.utils.contains(MACHINE_FEATURES, usbgadget, packagegroup-base-usbgadget, , d)} \ -${@bb.utils.contains(MACHINE_FEATURES, usbhost, packagegroup-base-usbhost, , d)} \ -\ -${@bb.utils.contains(DISTRO_FEATURES, bluetooth, packagegroup-base-bluetooth, , d)} \ -${@bb.utils.contains(DISTRO_FEATURES, wifi, packagegroup-base-wifi, , d)} \ -${@bb.utils.contains(DISTRO_FEATURES, 3g, packagegroup-base-3g, , d)} \ -${@bb.utils.contains(DISTRO_FEATURES, nfc, packagegroup-base-nfc, , d)} \ -${@bb.utils.contains(DISTRO_FEATURES, cramfs, packagegroup-base-cramfs, , d)} \ -${@bb.utils.contains(DISTRO_FEATURES, ipsec, packagegroup-base-ipsec, , d)} \ -${@bb.utils.contains(DISTRO_FEATURES, ipv6, packagegroup-base-ipv6, , d)} \ -${@bb.utils.contains(DISTRO_FEATURES, nfs, packagegroup-base-nfs, , d)} \ -${@bb.utils.contains(DISTRO_FEATURES, ppp, packagegroup-base-ppp, , d)} \ -${@bb.utils.contains(DISTRO_FEATURES, smbfs, packagegroup-base-smbfs, , d)} \ -${@bb.utils.contains(DISTRO_FEATURES, zeroconf, packagegroup-base-zeroconf, , d)} \ -\ -' +packagegroup-base \ +packagegroup-base-extended \ +packagegroup-distro-base \ +packagegroup-machine-base \ +\ +${@bb.utils.contains(MACHINE_FEATURES, acpi, packagegroup-base-acpi, ,d)} \ +${@bb.utils.contains(MACHINE_FEATURES, alsa, packagegroup-base-alsa, , d)} \ +${@bb.utils.contains(MACHINE_FEATURES, apm, packagegroup-base-apm, , d)} \ +${@bb.utils.contains(MACHINE_FEATURES, ext2, packagegroup-base-ext2, , d)} \ +${@bb.utils.contains(MACHINE_FEATURES, vfat, packagegroup-base-vfat, , d)} \ +${@bb.utils.contains(MACHINE_FEATURES, irda, packagegroup-base-irda, ,d)} \ +${@bb.utils.contains(MACHINE_FEATURES, keyboard, packagegroup-base-keyboard, , d)} \ +${@bb.utils.contains(MACHINE_FEATURES, pci, packagegroup-base-pci, ,d)} \ +${@bb.utils.contains(MACHINE_FEATURES, pcmcia, packagegroup-base-pcmcia, , d)} \ +${@bb.utils.contains(MACHINE_FEATURES, phone, packagegroup-base-phone, , d)} \ +${@bb.utils.contains(MACHINE_FEATURES, serial, packagegroup-base-serial, , d)} \ +${@bb.utils.contains(MACHINE_FEATURES,
[OE-core] so, which mailing list is for what?
apparently, i still don't have a handle on the correct mailing list for particular patch submissions -- where's the explanation as to what goes where? in particular, i want to submit some cleanups for some oe-core packagegroup recipe files, which list does that go to? thanks. i'll figure this out eventually. 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.openembedded.org/mailman/listinfo/openembedded-core