* [PATCH v2 2/2] taglib: update to 1.11
From: Andreas Müller @ 2016-10-24 17:49 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <1477331349-3389-1-git-send-email-schnitzeltony@googlemail.com>
Signed-off-by: Andreas Müller <schnitzeltony@googlemail.com>
---
meta/recipes-support/taglib/{taglib_1.9.1.bb => taglib_1.11.bb} | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
rename meta/recipes-support/taglib/{taglib_1.9.1.bb => taglib_1.11.bb} (74%)
diff --git a/meta/recipes-support/taglib/taglib_1.9.1.bb b/meta/recipes-support/taglib/taglib_1.11.bb
similarity index 74%
rename from meta/recipes-support/taglib/taglib_1.9.1.bb
rename to meta/recipes-support/taglib/taglib_1.11.bb
index d125308..9c0d374 100644
--- a/meta/recipes-support/taglib/taglib_1.9.1.bb
+++ b/meta/recipes-support/taglib/taglib_1.11.bb
@@ -9,8 +9,8 @@ LIC_FILES_CHKSUM = "file://COPYING.LGPL;md5=4fbd65380cdd255951079008b364516c \
DEPENDS = "zlib"
SRC_URI = "http://taglib.github.io/releases/${BP}.tar.gz"
-SRC_URI[md5sum] = "0d35df96822bbd564c5504cb3c2e4d86"
-SRC_URI[sha256sum] = "72d371cd1419a87ae200447a53bff2be219283071e80fd12337928cc967dc71a"
+SRC_URI[md5sum] = "be39fa2054df40664cb557126ad7cf7c"
+SRC_URI[sha256sum] = "ed4cabb3d970ff9a30b2620071c2b054c4347f44fc63546dbe06f97980ece288"
UPSTREAM_CHECK_URI = "http://github.com/taglib/taglib/releases/"
@@ -30,3 +30,6 @@ do_configure_prepend () {
sed -i -e "s/atomic.hpp/atomic-not-exist.hpp/" ${S}/ConfigureChecks.cmake ${S}/taglib/toolkit/trefcounter.cpp
}
+# without -fPIC depending packages failed with many errors like:
+# | <...>/ld: error: <...>/usr/lib/libtag.a(modfilebase.cpp.o): requires unsupported dynamic reloc R_ARM_THM_MOVW_ABS_NC; recompile with -fPIC
+CXXFLAGS += "-fPIC"
--
2.5.5
^ permalink raw reply related
* [master][morty][PATCH] libunwind: add ptest support
From: Jagadeesh Krishnanjanappa @ 2016-10-24 18:15 UTC (permalink / raw)
To: openembedded-core
The patch include below changes:
1. Add do_compile_ptest task, which compiles and runs builtin
test cases. The libunwind test scripts has relink commands,
which needs to be run at host in order to create ELF test
binaries which can be readily executed at target.
Hence pass "-i" option to make, to ignore exit status of tests
executed at host.
2. Some of the libunwind test cases such as run-check-namespace,
run-coredump-unwind require debug symbols to be present in
libunwind library. So set INHIBIT_PACKAGE_STRIP to "1".
3. Add do_install_ptest task, which copies necessary
filesb to execute tests.
4. Add run-ptest script to execute tests at target.
5. Add dependent packages neede to execute test cases via RDEPENDS
(run-check-namespace test requires "nm" tool, which is given by binutils)
Test result obtained with qemux86-64:
-- snip --
PASS: test-proc-info
PASS: test-static-link
PASS: test-strerror
PASS: Gtest-bt
PASS: Ltest-bt
PASS: Gtest-exc
PASS: Ltest-exc
PASS: Gtest-init
PASS: Ltest-init
PASS: Gtest-concurrent
PASS: Ltest-concurrent
PASS: Gtest-resume-sig
PASS: Ltest-resume-sig
PASS: Gtest-resume-sig-rt
PASS: Ltest-resume-sig-rt
XFAIL: Gtest-dyn1
XFAIL: Ltest-dyn1
PASS: Gtest-trace
PASS: Ltest-trace
FAIL: test-async-sig
PASS: test-flush-cache
PASS: test-init-remote
PASS: test-mem
PASS: Ltest-varargs
PASS: Ltest-nomalloc
PASS: Ltest-nocalloc
PASS: Lrs-race
PASS: test-ptrace
PASS: test-setjmp
PASS: run-check-namespace
PASS: run-ptrace-mapper
PASS: run-ptrace-misc
PASS: run-coredump-unwind
============================================================================
Testsuite summary for libunwind 1.1
============================================================================
# TOTAL: 33
# PASS: 30
# SKIP: 0
# XFAIL: 2
# FAIL: 1
# XPASS: 0
# ERROR: 0
============================================================================
-- snip --
Signed-off-by: Jagadeesh Krishnanjanappa <jkrishnanjanappa@mvista.com>
---
meta/recipes-support/libunwind/libunwind/run-ptest | 2 ++
meta/recipes-support/libunwind/libunwind_git.bb | 32 ++++++++++++++++++++++
2 files changed, 34 insertions(+)
create mode 100644 meta/recipes-support/libunwind/libunwind/run-ptest
diff --git a/meta/recipes-support/libunwind/libunwind/run-ptest b/meta/recipes-support/libunwind/libunwind/run-ptest
new file mode 100644
index 0000000..8bf2e11
--- /dev/null
+++ b/meta/recipes-support/libunwind/libunwind/run-ptest
@@ -0,0 +1,2 @@
+#!/bin/sh
+make -C tests -k LOG_DRIVER="$PWD/tests/test-driver" check-TESTS
diff --git a/meta/recipes-support/libunwind/libunwind_git.bb b/meta/recipes-support/libunwind/libunwind_git.bb
index 4249430..078d3a9 100644
--- a/meta/recipes-support/libunwind/libunwind_git.bb
+++ b/meta/recipes-support/libunwind/libunwind_git.bb
@@ -11,6 +11,7 @@ SRC_URI = "git://git.sv.gnu.org/libunwind.git \
file://0001-Fix-build-on-mips-musl.patch \
file://0001-add-knobs-to-disable-enable-tests.patch \
file://0001-ppc32-Consider-ucontext-mismatches-between-glibc-and.patch \
+ file://run-ptest \
"
SRC_URI_append_libc-musl = " file://musl-header-conflict.patch"
@@ -27,3 +28,34 @@ SECURITY_CFLAGS_append_aarch64 = " -fPIE"
S = "${WORKDIR}/git"
LDFLAGS += "-Wl,-z,relro,-z,now ${@bb.utils.contains('DISTRO_FEATURES', 'ld-is-gold', ' -fuse-ld=bfd ', '', d)}"
+
+inherit ptest
+
+do_compile_ptest() {
+ # Build tests
+ oe_runmake -C ${B}/tests LOG_DRIVER="${S}/config/test-driver" -i check
+}
+
+do_install_ptest() {
+ # copy binaries excluding "*.o" and "*.log" files
+ install -d ${D}${PTEST_PATH}
+ cp -a ${B}/tests ${D}${PTEST_PATH}
+ rm -f `find ${D}${PTEST_PATH} | egrep "\.o$|\.log$"`
+
+ # copy dependent files for testing
+ [ -f ${S}/config/test-driver ] && cp ${S}/config/test-driver ${D}${PTEST_PATH}/tests/
+ cp ${S}/tests/run-* ${D}${PTEST_PATH}/tests/
+
+ # Use libunwind libraries present in standard path and tweak Makefile
+ # to run only tests at target
+ [ -f ${D}${PTEST_PATH}/tests/Makefile ] && \
+ sed -i -e "s|^\(.*\)\.log: .*(EXEEXT)|\1\.log:|" ${D}${PTEST_PATH}/tests/Makefile
+
+ [ -f ${D}${PTEST_PATH}/tests/check-namespace.sh ] && \
+ sed -i -e "s|^LIBUNWIND=.*|LIBUNWIND=${libdir}/libunwind.so|g" \
+ -e "s|^LIBUNWIND_GENERIC=.*|LIBUNWIND_GENERIC=${libdir}/libunwind-\${plat}.so|g" ${D}${PTEST_PATH}/tests/check-namespace.sh
+}
+
+INHIBIT_PACKAGE_STRIP = "1"
+
+RDEPENDS_${PN}-ptest += "make bash gawk binutils"
--
2.7.4
^ permalink raw reply related
* most efficient way to map perl RH rpms to OE package names?
From: Robert P. J. Day @ 2016-10-24 20:53 UTC (permalink / raw)
To: OE Core mailing list
i've just been handed a list of about 200 perl packages by their
centos rpm names, and i want to map most, if not all, of them to their
equivalent OE package names.
my first instinct (based on not having used a lot of perl OE
packages) is to add both "perl" and "perl-modules" to IMAGE_INSTALL,
just to fetch and build every possible module available through the OE
perl recipe -- that will at least give me an idea of what's available.
next, i can see the pattern in some OE package names -- i've
verified that the Time::HiRes package is available in OE as
perl-module-time-hires, which i assume is part of the dynamic naming
being done in perl_5.22.1.bb.
am i approaching this the right way?
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
^ permalink raw reply
* Re: most efficient way to map perl RH rpms to OE package names?
From: Christopher Larson @ 2016-10-24 21:50 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: OE Core mailing list
In-Reply-To: <alpine.LFD.2.20.1610241644480.15919@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1121 bytes --]
On Mon, Oct 24, 2016 at 1:53 PM, Robert P. J. Day <rpjday@crashcourse.ca>
wrote:
> i've just been handed a list of about 200 perl packages by their
> centos rpm names, and i want to map most, if not all, of them to their
> equivalent OE package names.
>
> my first instinct (based on not having used a lot of perl OE
> packages) is to add both "perl" and "perl-modules" to IMAGE_INSTALL,
> just to fetch and build every possible module available through the OE
> perl recipe -- that will at least give me an idea of what's available.
>
> next, i can see the pattern in some OE package names -- i've
> verified that the Time::HiRes package is available in OE as
> perl-module-time-hires, which i assume is part of the dynamic naming
> being done in perl_5.22.1.bb.
>
> am i approaching this the right way?
>
Could also bitbake perl, then use oe-pkgdata-util to locate the actual perl
modules in the packages, i.e. */Time/HiRes.pm.
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
[-- Attachment #2: Type: text/html, Size: 1679 bytes --]
^ permalink raw reply
* Re: basic bitbake commands to create an SDK?
From: Paul Eggleton @ 2016-10-25 1:01 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: openembedded-core
In-Reply-To: <alpine.LFD.2.20.1610221323110.8746@localhost.localdomain>
On Sat, 22 Oct 2016 13:24:58 Robert P. J. Day wrote:
> On Sat, 22 Oct 2016, Khem Raj wrote:
> > generally meta-toolchain is prior art. You want to use image
> > specific SDKs so -cpopulate_sdk <image> is fine. In this case it
> > will include the needed dev headers/libs in your SDK for that given
> > image automatically it can be any image
>
> yet another dumb question while my build is cranking away ... am i
> correct in assuming that i can generate the SDKs for multiple images
> (same architecture of course) in the same build directory, and the
> resulting generated artifacts will be distinguishable? that is, they
> won't step on each other?
Yes, that will work just fine.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
^ permalink raw reply
* Re: basic bitbake commands to create an SDK?
From: Paul Eggleton @ 2016-10-25 2:18 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: openembedded-core
In-Reply-To: <alpine.LFD.2.20.1610240549440.28159@ca624034.mitel.com>
On Mon, 24 Oct 2016 05:51:16 Robert P. J. Day wrote:
> On Sat, 22 Oct 2016, Khem Raj wrote:
> > I would recommend to try using eSDK, which can be generated using
> > -cpopulate_sdk_ext see
> >
> > https://wiki.yoctoproject.org/wiki/Application_Development_with_Extensible
> > _SDK
> just reading up on eSDKs now, am i correct in assuming that if i
> have the time and space to build an eSDK, there is no downside
> compared to building a standard SDK? as in, i don't lose anything from
> the standard SDK, i just get a richer feature set, etc.
Mostly correct, especially for master/morty where we sorted out the lack of
gdb and a few scripts required to support the Eclipse plugin. There are
differences though - please see the introduction of the latest SDK manual [1]
for a comparison chart.
Cheers,
Paul
[1] http://www.yoctoproject.org/docs/latest/sdk-manual/sdk-manual.html#sdk-manual-intro
--
Paul Eggleton
Intel Open Source Technology Centre
^ permalink raw reply
* Re: most efficient way to map perl RH rpms to OE package names?
From: Robert P. J. Day @ 2016-10-25 6:42 UTC (permalink / raw)
To: Christopher Larson; +Cc: OE Core mailing list
In-Reply-To: <CABcZANnYLS0pfSpdzf3NVV4KEg_88b9mPark9gpstJUFHZTzxQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1684 bytes --]
On Mon, 24 Oct 2016, Christopher Larson wrote:
>
> On Mon, Oct 24, 2016 at 1:53 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
> i've just been handed a list of about 200 perl packages by their
> centos rpm names, and i want to map most, if not all, of them to their
> equivalent OE package names.
>
> my first instinct (based on not having used a lot of perl OE
> packages) is to add both "perl" and "perl-modules" to IMAGE_INSTALL,
> just to fetch and build every possible module available through the OE
> perl recipe -- that will at least give me an idea of what's available.
>
> next, i can see the pattern in some OE package names -- i've
> verified that the Time::HiRes package is available in OE as
> perl-module-time-hires, which i assume is part of the dynamic naming
> being done in perl_5.22.1.bb.
>
> am i approaching this the right way?
>
> Could also bitbake perl, then use oe-pkgdata-util to locate the
> actual perl modules in the packages, i.e. */Time/HiRes.pm.
i had just started playing with oe-pkgdata-util, it obviously has a
lot of equivalent functionality to your "bb", does it obsolete "bb" at
this point?
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
^ permalink raw reply
* Re: most efficient way to map perl RH rpms to OE package names?
From: Robert P. J. Day @ 2016-10-25 6:48 UTC (permalink / raw)
To: Christopher Larson; +Cc: OE Core mailing list
In-Reply-To: <CABcZANnYLS0pfSpdzf3NVV4KEg_88b9mPark9gpstJUFHZTzxQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1781 bytes --]
On Mon, 24 Oct 2016, Christopher Larson wrote:
>
> On Mon, Oct 24, 2016 at 1:53 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
> i've just been handed a list of about 200 perl packages by their
> centos rpm names, and i want to map most, if not all, of them to their
> equivalent OE package names.
>
> my first instinct (based on not having used a lot of perl OE
> packages) is to add both "perl" and "perl-modules" to IMAGE_INSTALL,
> just to fetch and build every possible module available through the OE
> perl recipe -- that will at least give me an idea of what's available.
>
> next, i can see the pattern in some OE package names -- i've
> verified that the Time::HiRes package is available in OE as
> perl-module-time-hires, which i assume is part of the dynamic naming
> being done in perl_5.22.1.bb.
>
> am i approaching this the right way?
>
>
> Could also bitbake perl, then use oe-pkgdata-util to locate the
> actual perl modules in the packages, i.e. */Time/HiRes.pm.
i once wrote a wiki page on "bb", distinguishing between queries
you could make before you did a build, versus queries that needed a
build. it seems like oe-pkgdata-util needs a completed build for
pretty much everything, do i have that right?
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
^ permalink raw reply
* Re: most efficient way to map perl RH rpms to OE package names?
From: Robert P. J. Day @ 2016-10-25 7:05 UTC (permalink / raw)
To: Christopher Larson; +Cc: OE Core mailing list
In-Reply-To: <alpine.LFD.2.20.1610250246460.19688@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 2264 bytes --]
On Tue, 25 Oct 2016, Robert P. J. Day wrote:
> On Mon, 24 Oct 2016, Christopher Larson wrote:
>
> >
> > On Mon, Oct 24, 2016 at 1:53 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
> > i've just been handed a list of about 200 perl packages by their
> > centos rpm names, and i want to map most, if not all, of them to their
> > equivalent OE package names.
> >
> > my first instinct (based on not having used a lot of perl OE
> > packages) is to add both "perl" and "perl-modules" to IMAGE_INSTALL,
> > just to fetch and build every possible module available through the OE
> > perl recipe -- that will at least give me an idea of what's available.
> >
> > next, i can see the pattern in some OE package names -- i've
> > verified that the Time::HiRes package is available in OE as
> > perl-module-time-hires, which i assume is part of the dynamic naming
> > being done in perl_5.22.1.bb.
> >
> > am i approaching this the right way?
> >
> >
> > Could also bitbake perl, then use oe-pkgdata-util to locate the
> > actual perl modules in the packages, i.e. */Time/HiRes.pm.
>
> i once wrote a wiki page on "bb", distinguishing between queries
> you could make before you did a build, versus queries that needed a
> build. it seems like oe-pkgdata-util needs a completed build for
> pretty much everything, do i have that right?
never mind, i just read this snippet from the YP ref manual:
"You can use the oe-pkgdata-util command-line utility to query
PKGDATA_DIR and display various package-related information. When you
use the utility, you must use it to view information on packages that
have already been built."
so i'm assuming that means for *all* oe-pkgdata subcommands, no
exceptions.
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
^ permalink raw reply
* Re: meta-toolchain and meta-toolchain-qt for specific image
From: thilo.cestonaro @ 2016-10-25 7:28 UTC (permalink / raw)
To: anders@chargestorm.se; +Cc: openembedded-core@lists.openembedded.org
In-Reply-To: <20161024043614.3gqmsqpu2h52tnpr@ad.chargestorm.se>
[-- Attachment #1: Type: text/plain, Size: 445 bytes --]
Hey
> Well, have your image `inherit populate_sdk_qt5`, and then call
>
> `bitbake <your-image> -c populate_sdk`. That'll give you the standard,
> image-based SDK, with Qt5 in it.
>
Can the image and the sdk be build seperatly then? Or will a "bitbake <my-image>" build the qt5 toolchain directly too?
This is what I intended to get rid off. To be able to build the image and the sdk in two independed build steps.
Cheers,
Thilo
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3847 bytes --]
^ permalink raw reply
* [PATCH] oe-pkgdata-util: Use standard verb form in help info.
From: Robert P. J. Day @ 2016-10-25 7:31 UTC (permalink / raw)
To: OE Core mailing list
"Shows" -> "Show", to be consistent with standard form of help output.
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
---
yes, i am that pedantic.
diff --git a/scripts/oe-pkgdata-util b/scripts/oe-pkgdata-util
index bb917b4..dbffd6a 100755
--- a/scripts/oe-pkgdata-util
+++ b/scripts/oe-pkgdata-util
@@ -526,7 +526,7 @@ def main():
parser_lookup_recipe.set_defaults(func=lookup_recipe)
parser_package_info = subparsers.add_parser('package-info',
- help='Shows version, recipe and size information for one or more packages',
+ help='Show version, recipe and size information for one or more packages',
description='Looks up the specified runtime package(s) and display information')
parser_package_info.add_argument('pkg', nargs='*', help='Runtime package name to look up')
parser_package_info.add_argument('-f', '--file', help='Read package names from the specified file (one per line, first field only)')
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
^ permalink raw reply related
* [PATCH 0/1] systemd: CVE-2016-7795
From: Chen Qi @ 2016-10-25 7:40 UTC (permalink / raw)
To: openembedded-core
The following changes since commit 6e96deb024e4c41d911f590ff2b92b402f672661:
local.conf.sample.extended: remove RM_OLD_IMAGE (2016-10-19 17:07:14 +0100)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib ChenQi/CVE-2016-7795
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=ChenQi/CVE-2016-7795
Chen Qi (1):
systemd: CVE-2016-7795
...s-zero-length-notification-messages-again.patch | 68 ++++++++++++++++++++++
meta/recipes-core/systemd/systemd_230.bb | 1 +
2 files changed, 69 insertions(+)
create mode 100644 meta/recipes-core/systemd/systemd/0001-pid1-process-zero-length-notification-messages-again.patch
--
1.9.1
^ permalink raw reply
* [PATCH 1/1] systemd: CVE-2016-7795
From: Chen Qi @ 2016-10-25 7:40 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1477381190.git.Qi.Chen@windriver.com>
The manager_invoke_notify_message function in systemd 231 and earlier allows
local users to cause a denial of service (assertion failure and PID 1 hang)
via a zero-length message received over a notify socket.
The patch is a backport from the latest git repo.
Please see the link below for more information.
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-7795
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
---
...s-zero-length-notification-messages-again.patch | 68 ++++++++++++++++++++++
meta/recipes-core/systemd/systemd_230.bb | 1 +
2 files changed, 69 insertions(+)
create mode 100644 meta/recipes-core/systemd/systemd/0001-pid1-process-zero-length-notification-messages-again.patch
diff --git a/meta/recipes-core/systemd/systemd/0001-pid1-process-zero-length-notification-messages-again.patch b/meta/recipes-core/systemd/systemd/0001-pid1-process-zero-length-notification-messages-again.patch
new file mode 100644
index 0000000..0332593
--- /dev/null
+++ b/meta/recipes-core/systemd/systemd/0001-pid1-process-zero-length-notification-messages-again.patch
@@ -0,0 +1,68 @@
+Subject: pid1: process zero-length notification messages again
+
+This undoes 531ac2b. I acked that patch without looking at the code
+carefully enough. There are two problems:
+- we want to process the fds anyway
+- in principle empty notification messages are valid, and we should
+ process them as usual, including logging using log_unit_debug().
+
+Upstream-Status: Backport
+
+Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
+---
+ src/core/manager.c | 11 ++++++-----
+ 1 file changed, 6 insertions(+), 5 deletions(-)
+
+diff --git a/src/core/manager.c b/src/core/manager.c
+index 7838f56..f165d08e 100644
+--- a/src/core/manager.c
++++ b/src/core/manager.c
+@@ -1589,13 +1589,12 @@ static int manager_dispatch_cgroups_agent_fd(sd_event_source *source, int fd, ui
+ return 0;
+ }
+
+-static void manager_invoke_notify_message(Manager *m, Unit *u, pid_t pid, const char *buf, size_t n, FDSet *fds) {
++static void manager_invoke_notify_message(Manager *m, Unit *u, pid_t pid, const char *buf, FDSet *fds) {
+ _cleanup_strv_free_ char **tags = NULL;
+
+ assert(m);
+ assert(u);
+ assert(buf);
+- assert(n > 0);
+
+ tags = strv_split(buf, "\n\r");
+ if (!tags) {
+@@ -1688,25 +1687,27 @@ static int manager_dispatch_notify_fd(sd_event_source *source, int fd, uint32_t
+ return 0;
+ }
+
++ /* The message should be a string. Here we make sure it's NUL-terminated,
++ * but only the part until first NUL will be used anyway. */
+ buf[n] = 0;
+
+ /* Notify every unit that might be interested, but try
+ * to avoid notifying the same one multiple times. */
+ u1 = manager_get_unit_by_pid_cgroup(m, ucred->pid);
+ if (u1) {
+- manager_invoke_notify_message(m, u1, ucred->pid, buf, n, fds);
++ manager_invoke_notify_message(m, u1, ucred->pid, buf, fds);
+ found = true;
+ }
+
+ u2 = hashmap_get(m->watch_pids1, PID_TO_PTR(ucred->pid));
+ if (u2 && u2 != u1) {
+- manager_invoke_notify_message(m, u2, ucred->pid, buf, n, fds);
++ manager_invoke_notify_message(m, u2, ucred->pid, buf, fds);
+ found = true;
+ }
+
+ u3 = hashmap_get(m->watch_pids2, PID_TO_PTR(ucred->pid));
+ if (u3 && u3 != u2 && u3 != u1) {
+- manager_invoke_notify_message(m, u3, ucred->pid, buf, n, fds);
++ manager_invoke_notify_message(m, u3, ucred->pid, buf, fds);
+ found = true;
+ }
+
+--
+2.8.3
+
diff --git a/meta/recipes-core/systemd/systemd_230.bb b/meta/recipes-core/systemd/systemd_230.bb
index a949fe8..1a266c8 100644
--- a/meta/recipes-core/systemd/systemd_230.bb
+++ b/meta/recipes-core/systemd/systemd_230.bb
@@ -36,6 +36,7 @@ SRC_URI += " \
file://0021-include-missing.h-for-getting-secure_getenv-definiti.patch \
file://0022-socket-util-don-t-fail-if-libc-doesn-t-support-IDN.patch \
file://udev-re-enable-mount-propagation-for-udevd.patch \
+ file://0001-pid1-process-zero-length-notification-messages-again.patch \
"
SRC_URI_append_libc-uclibc = "\
file://0002-units-Prefer-getty-to-agetty-in-console-setup-system.patch \
--
1.9.1
^ permalink raw reply related
* Re: meta-toolchain and meta-toolchain-qt for specific image
From: Anders Darander @ 2016-10-25 7:49 UTC (permalink / raw)
To: thilo.cestonaro@ts.fujitsu.com; +Cc: openembedded-core@lists.openembedded.org
In-Reply-To: <1477380507.4894.4.camel@ts.fujitsu.com>
* thilo.cestonaro@ts.fujitsu.com <thilo.cestonaro@ts.fujitsu.com> [161025 09:28]:
> Hey
> > Well, have your image `inherit populate_sdk_qt5`, and then call
> > `bitbake <your-image> -c populate_sdk`. That'll give you the standard,
> > image-based SDK, with Qt5 in it.
> Can the image and the sdk be build seperatly then? Or will a "bitbake <my-image>" build the qt5 toolchain directly too?
> This is what I intended to get rid off. To be able to build the image and the sdk in two independed build steps.
Yes, `bitbake <my-image>` does only build your image and `bitbake
<my-image> -c populate_sdk` does only build the SDK.
Cheers,
Anders
--
Anders Darander, Senior System Architect
ChargeStorm AB / eStorm AB
^ permalink raw reply
* Re: [wic][PATCH] systemd-bootdisk.wks: use PARTUUID
From: Ed Bartosh @ 2016-10-25 7:56 UTC (permalink / raw)
To: Saul Wold; +Cc: benjamin.esquivel, openembedded-core
In-Reply-To: <1477330480.6169.3.camel@intel.com>
On Mon, Oct 24, 2016 at 10:34:40AM -0700, Saul Wold wrote:
> On Mon, 2016-10-24 at 16:54 +0300, Ed Bartosh wrote:
> > Root device name in systemd-bootdisk.wks is 'sda'. This can cause
> > images, produced using this wks to refuse booting if real device
> > name is not 'sda'. For example, when booting MinnowBoard MAX from
> > MicroSD card the boot process stucks with this message on the boot
> > console output: Waiting for root device /dev/sda2...
> > This happens because real device name of MicroSD card on this device
> > is mmcblk1.
> >
> > Used --use-uuid option for root partition. This should make
> > wic to put partiion UUID instead of device name into kernel command
> > line.
> >
> > [YOCTO #10485]
> >
> > Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
> > ---
> > scripts/lib/wic/canned-wks/systemd-bootdisk.wks | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/scripts/lib/wic/canned-wks/systemd-bootdisk.wks
> > b/scripts/lib/wic/canned-wks/systemd-bootdisk.wks
> > index b900023..4bd9d6a 100644
> > --- a/scripts/lib/wic/canned-wks/systemd-bootdisk.wks
> > +++ b/scripts/lib/wic/canned-wks/systemd-bootdisk.wks
> > @@ -4,7 +4,7 @@
> >
> > part /boot --source bootimg-efi --sourceparams="loader=systemd-boot"
> > --ondisk sda --label msdos --active --align 1024
> >
> > -part / --source rootfs --ondisk sda --fstype=ext4 --label platform
> > --align 1024
> > +part / --source rootfs --ondisk sda --fstype=ext4 --label platform
> > --align 1024 --use-uuid
> >
> part swap --ondisk sda --size 44 --label swap1 --fstype=swap
> >
> I understand the --use-uuid for the partition labeling, but how does it
> affect everything marked as ondisk sda? Or is ondisk ignored with use-
> uuid?
--use-uuid uses PARTUUID to specify root device in kernel command line
instead of /dev/sdaX. In this sense yes, sda is ignored.
However, disk name(sda) is also used to group partitions to one disk image.
Theoretically wic can produce several images if more than one disk name
is used in .wks file.
For swap position sda is still used, which can make swap partitions not
functional on the devices with different disk names. This needs to be fixed
by using PARTUUID in fstab for swap partitions. For this to work in poky images
busybox swapon should support PARTUUID syntax, which I'm not entirely sure it does.
--
Regards,
Ed
^ permalink raw reply
* Howto find the providing recipe for a specific package?
From: thilo.cestonaro @ 2016-10-25 9:32 UTC (permalink / raw)
To: openembedded-core@lists.openembedded.org
[-- Attachment #1: Type: text/plain, Size: 297 bytes --]
Hey!
How can I programmatically reverse lookup the recipe which provides a specific package?
e.g. kernel-module-xfrm6-mode-transport is produced via the recipe linux-mainline, in my case,
but the packagename doesn't tell this anyhow.
Is there a way to get the recipe?
Cheers,
Thilo
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3847 bytes --]
^ permalink raw reply
* Re: Howto find the providing recipe for a specific package?
From: Jussi Kukkonen @ 2016-10-25 10:01 UTC (permalink / raw)
To: thilo.cestonaro@ts.fujitsu.com; +Cc: openembedded-core@lists.openembedded.org
In-Reply-To: <1477387924.20929.1.camel@ts.fujitsu.com>
[-- Attachment #1: Type: text/plain, Size: 550 bytes --]
On 25 October 2016 at 12:32, thilo.cestonaro@ts.fujitsu.com <
thilo.cestonaro@ts.fujitsu.com> wrote:
> Hey!
>
> How can I programmatically reverse lookup the recipe which provides a
> specific package?
>
> e.g. kernel-module-xfrm6-mode-transport is produced via the recipe
> linux-mainline, in my case,
> but the packagename doesn't tell this anyhow.
>
> Is there a way to get the recipe?
>
This should work after the recipe has been built:
$ oe-pkgdata-util lookup-recipe kernel-module-xfrm6-mode-transport
HTH,
Jussi
[-- Attachment #2: Type: text/html, Size: 1082 bytes --]
^ permalink raw reply
* [PATCH v2] package.py: New EXTRA_STRIPFLAGS variable
From: Michael Blättler @ 2016-10-25 10:23 UTC (permalink / raw)
To: openembedded-core
The EXTRA_STRIPFLAGS variable can be used to pass additional parameters to the strip command.
This can be used to remove additional sections or to keep symbols.
The removal of additional sections can be useful to enable reproducible builds.
Sections which contain paths or md5sums of the debug binaries (like gnu_debuglink)
can be eliminated with this flag.
Signed-off-by: Pascal Bach <pascal.bach@siemens.com>
Signed-off-by: Michael Blättler <michael.blaettler@siemens.com>
---
meta/classes/package.bbclass | 5 +++--
meta/lib/oe/package.py | 13 ++++++-------
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index a6f0a7a..05b92a8 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -1055,14 +1055,15 @@ python split_and_strip_files () {
# Now lets go back over things and strip them
#
if (d.getVar('INHIBIT_PACKAGE_STRIP', True) != '1'):
+ extraflags = d.getVar('EXTRA_STRIPFLAGS', False)
strip = d.getVar("STRIP", True)
sfiles = []
for file in elffiles:
elf_file = int(elffiles[file])
#bb.note("Strip %s" % file)
- sfiles.append((file, elf_file, strip))
+ sfiles.append((file, elf_file, strip, extraflags))
for f in kernmods:
- sfiles.append((f, 16, strip))
+ sfiles.append((f, 16, strip, extraflags))
oe.utils.multiprocess_exec(sfiles, oe.package.runstrip)
diff --git a/meta/lib/oe/package.py b/meta/lib/oe/package.py
index 02642f2..757044a 100644
--- a/meta/lib/oe/package.py
+++ b/meta/lib/oe/package.py
@@ -10,7 +10,7 @@ def runstrip(arg):
import stat, subprocess
- (file, elftype, strip) = arg
+ (file, elftype, strip, extraflags) = arg
newmode = None
if not os.access(file, os.W_OK) or os.access(file, os.R_OK):
@@ -18,17 +18,16 @@ def runstrip(arg):
newmode = origmode | stat.S_IWRITE | stat.S_IREAD
os.chmod(file, newmode)
- extraflags = ""
-
- # kernel module
+ extraflags += ' '
+ # kernel module
if elftype & 16:
- extraflags = "--strip-debug --remove-section=.comment --remove-section=.note --preserve-dates"
+ extraflags += "--strip-debug --remove-section=.comment --remove-section=.note --preserve-dates"
# .so and shared library
elif ".so" in file and elftype & 8:
- extraflags = "--remove-section=.comment --remove-section=.note --strip-unneeded"
+ extraflags += "--remove-section=.comment --remove-section=.note --strip-unneeded"
# shared or executable:
elif elftype & 8 or elftype & 4:
- extraflags = "--remove-section=.comment --remove-section=.note"
+ extraflags += "--remove-section=.comment --remove-section=.note"
stripcmd = "'%s' %s '%s'" % (strip, extraflags, file)
bb.debug(1, "runstrip: %s" % stripcmd)
--
2.1.4
^ permalink raw reply related
* Re: Howto find the providing recipe for a specific package?
From: thilo.cestonaro @ 2016-10-25 11:03 UTC (permalink / raw)
To: jussi.kukkonen@intel.com; +Cc: openembedded-core@lists.openembedded.org
In-Reply-To: <CAHiDW_HLiPEOXC6FgaenUr1s0sByoG6Zn1X-u6Q2D439A8rOXg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 135 bytes --]
> $ oe-pkgdata-util lookup-recipe kernel-module-xfrm6-mode-transport
>
Thanks! That is what I was looking for!
Cheers,
Thilo
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3847 bytes --]
^ permalink raw reply
* [PATCH 2/4] recipetool: selftest: Add test for recipetool plugin loading
From: Ola x Nilsson @ 2016-10-25 11:03 UTC (permalink / raw)
To: olani, openembedded-core
In-Reply-To: <1477393415-13053-1-git-send-email-olani@axis.com>
From: Ola x Nilsson <ola.x.nilsson@axis.com>
Test that recipetool plugins are loaded in a well defined order.
Signed-off-by: Ola x Nilsson <ola.x.nilsson@axis.com>
---
meta-selftest/lib/recipetool/bbpath.py | 41 +++++++++++++++++++++++++++++++
meta/lib/oeqa/selftest/recipetool.py | 44 ++++++++++++++++++++++++++++++++++
2 files changed, 85 insertions(+)
create mode 100644 meta-selftest/lib/recipetool/bbpath.py
diff --git a/meta-selftest/lib/recipetool/bbpath.py b/meta-selftest/lib/recipetool/bbpath.py
new file mode 100644
index 0000000..783b2dc
--- /dev/null
+++ b/meta-selftest/lib/recipetool/bbpath.py
@@ -0,0 +1,41 @@
+import argparse
+
+already_loaded = False
+register_count = 0
+
+def plugin_name(filename):
+ return os.path.splitext(os.path.basename(filename))[0]
+
+def plugin_init(plugins):
+ global already_loaded
+ already_loaded = plugin_name(__file__) in (plugin_name(p.__name__) for p in plugins)
+
+def print_name(opts):
+ print (__file__)
+
+def print_bbdir(opts):
+ print (__file__.replace('/lib/recipetool/bbpath.py',''))
+
+def print_registered(opts):
+ #global kept_context
+ #print(kept_context.loaded)
+ print ("1")
+
+def multiloaded(opts):
+ global already_loaded
+ print("yes" if already_loaded else "no")
+
+def register_commands(subparsers):
+ global register_count
+ register_count += 1
+
+ def addparser(name, helptxt, func):
+ parser = subparsers.add_parser(name, help=helptxt,
+ formatter_class=argparse.ArgumentDefaultsHelpFormatter)
+ parser.set_defaults(func=func)
+ return parser
+
+ addparser('pluginfile', 'Print the filename of this plugin', print_name)
+ addparser('bbdir', 'Print the BBPATH directory of this plugin', print_bbdir)
+ addparser('count', 'How many times have this plugin been registered.', print_registered)
+ addparser('multiloaded', 'How many times have this plugin been initialized', multiloaded)
diff --git a/meta/lib/oeqa/selftest/recipetool.py b/meta/lib/oeqa/selftest/recipetool.py
index db1f8de..bcc2b46 100644
--- a/meta/lib/oeqa/selftest/recipetool.py
+++ b/meta/lib/oeqa/selftest/recipetool.py
@@ -1,5 +1,6 @@
import os
import logging
+import shutil
import tempfile
import urllib.parse
@@ -485,6 +486,47 @@ class RecipetoolTests(RecipetoolBase):
inherits = ['pkgconfig', 'autotools']
self._test_recipe_contents(recipefile, checkvars, inherits)
+ def _copy_file_with_cleanup(self, srcfile, basedstdir, *paths):
+ dstdir = basedstdir
+ self.assertTrue(os.path.exists(dstdir))
+ for p in paths:
+ dstdir = os.path.join(dstdir, p)
+ if not os.path.exists(dstdir):
+ os.makedirs(dstdir)
+ self.track_for_cleanup(dstdir)
+ dstfile = os.path.join(dstdir, os.path.basename(srcfile))
+ if srcfile != dstfile:
+ shutil.copy(srcfile, dstfile)
+ self.track_for_cleanup(dstfile)
+
+ def test_recipetool_load_plugin(self):
+ """Test that recipetool loads only the first found plugin in BBPATH."""
+
+ recipetool = runCmd("which recipetool")
+ fromname = runCmd("recipetool --quiet pluginfile")
+ srcfile = fromname.output
+ bbpath = get_bb_var('BBPATH')
+ searchpath = bbpath.split(':') + [os.path.dirname(recipetool.output)]
+ plugincontent = []
+ with open(srcfile) as fh:
+ plugincontent = fh.readlines()
+ try:
+ self.assertIn('meta-selftest', srcfile, 'wrong bbpath plugin found')
+ for path in searchpath:
+ self._copy_file_with_cleanup(srcfile, path, 'lib', 'recipetool')
+ result = runCmd("recipetool --quiet count")
+ self.assertEqual(result.output, '1')
+ result = runCmd("recipetool --quiet multiloaded")
+ self.assertEqual(result.output, "no")
+ for path in searchpath:
+ result = runCmd("recipetool --quiet bbdir")
+ self.assertEqual(result.output, path)
+ os.unlink(os.path.join(result.output, 'lib', 'recipetool', 'bbpath.py'))
+ finally:
+ with open(srcfile, 'w') as fh:
+ fh.writelines(plugincontent)
+
+
class RecipetoolAppendsrcBase(RecipetoolBase):
def _try_recipetool_appendsrcfile(self, testrecipe, newfile, destfile, options, expectedlines, expectedfiles):
cmd = 'recipetool appendsrcfile %s %s %s %s %s' % (options, self.templayerdir, testrecipe, newfile, destfile)
@@ -574,6 +616,8 @@ class RecipetoolAppendsrcBase(RecipetoolBase):
self.assertIn(filesdir, filesextrapaths)
+
+
class RecipetoolAppendsrcTests(RecipetoolAppendsrcBase):
@testcase(1273)
--
2.1.4
^ permalink raw reply related
* [PATCH 0/4] Load devtool and reciptool plugins in a well-defined manner
From: Ola x Nilsson @ 2016-10-25 11:03 UTC (permalink / raw)
To: olani, openembedded-core
From: Ola x Nilsson <ola.x.nilsson@axis.com>
Make devtool and recipetool load plugins in a well-defined and expected manner.
devtool and reciptool search for pluings first in scripts/lib/<tool>
and then in BBPATH. Each found plugin is loaded, which means that any
plugin found later in BBPATH shadows previously loaded plugins.
plugin_init is loaded for all plugins, no matter whether they are
later replaced. register_plugin is called once for each time a plugin
with a certain name is found, but it is always called on the last
loaded plugin.
Change the scriptutils.load_plugins function to never load a plugin
file if one with the same filename has already been loaded. This
means that the first found plugin wins.
Change the load order to first search BBPATH and then
scripts/lib/tools. This means that plugins in scripts/lib/<tool> can
be shadowed by plugins in layers.
Ola x Nilsson (4):
devtool: selftest: add test for devtool plugin loading
recipetool: selftest: Add test for recipetool plugin loading
devtool: Load plugins in a well defined order
recipetool: Load plugins in a well defined order
meta-selftest/lib/devtool/bbpath.py | 44 ++++++++++++++++++++++++++++++++++
meta-selftest/lib/recipetool/bbpath.py | 41 +++++++++++++++++++++++++++++++
meta/lib/oeqa/selftest/devtool.py | 43 +++++++++++++++++++++++++++++++++
meta/lib/oeqa/selftest/recipetool.py | 44 ++++++++++++++++++++++++++++++++++
scripts/devtool | 3 ++-
scripts/lib/scriptutils.py | 8 +++++--
scripts/recipetool | 4 ++--
7 files changed, 182 insertions(+), 5 deletions(-)
create mode 100644 meta-selftest/lib/devtool/bbpath.py
create mode 100644 meta-selftest/lib/recipetool/bbpath.py
--
2.1.4
^ permalink raw reply
* [PATCH 1/4] devtool: selftest: add test for devtool plugin loading
From: Ola x Nilsson @ 2016-10-25 11:03 UTC (permalink / raw)
To: olani, openembedded-core
In-Reply-To: <1477393415-13053-1-git-send-email-olani@axis.com>
From: Ola x Nilsson <ola.x.nilsson@axis.com>
Test that devtool plugins are loaded in a well defined order.
Signed-off-by: Ola x Nilsson <ola.x.nilsson@axis.com>
---
meta-selftest/lib/devtool/bbpath.py | 44 +++++++++++++++++++++++++++++++++++++
meta/lib/oeqa/selftest/devtool.py | 43 ++++++++++++++++++++++++++++++++++++
2 files changed, 87 insertions(+)
create mode 100644 meta-selftest/lib/devtool/bbpath.py
diff --git a/meta-selftest/lib/devtool/bbpath.py b/meta-selftest/lib/devtool/bbpath.py
new file mode 100644
index 0000000..5e8ffb3
--- /dev/null
+++ b/meta-selftest/lib/devtool/bbpath.py
@@ -0,0 +1,44 @@
+import argparse
+
+already_loaded = False
+kept_context = None
+
+def plugin_name(filename):
+ return os.path.splitext(os.path.basename(filename))[0]
+
+def plugin_init(plugins):
+ global already_loaded
+ already_loaded = plugin_name(__file__) in (plugin_name(p.__name__) for p in plugins)
+
+def print_name(args, config, basepath, workspace):
+ print (__file__)
+
+def print_bbdir(args, config, basepath, workspace):
+ print (__file__.replace('/lib/devtool/bbpath.py',''))
+
+def print_registered(args, config, basepath, workspace):
+ global kept_context
+ print(kept_context.loaded)
+
+def multiloaded(args, config, basepath, workspace):
+ global already_loaded
+ print("yes" if already_loaded else "no")
+
+def register_commands(subparsers, context):
+ global kept_context
+ kept_context = context
+ if 'loaded' in context.__dict__:
+ context.loaded += 1
+ else:
+ context.loaded = 1
+
+ def addparser(name, helptxt, func):
+ parser = subparsers.add_parser(name, help=helptxt,
+ formatter_class=argparse.ArgumentDefaultsHelpFormatter)
+ parser.set_defaults(func=func)
+ return parser
+
+ addparser('pluginfile', 'Print the filename of this plugin', print_name)
+ addparser('bbdir', 'Print the BBPATH directory of this plugin', print_bbdir)
+ addparser('count', 'How many times have this plugin been registered.', print_registered)
+ addparser('multiloaded', 'How many times have this plugin been initialized', multiloaded)
diff --git a/meta/lib/oeqa/selftest/devtool.py b/meta/lib/oeqa/selftest/devtool.py
index e992dcf..cd9077f 100644
--- a/meta/lib/oeqa/selftest/devtool.py
+++ b/meta/lib/oeqa/selftest/devtool.py
@@ -1191,6 +1191,49 @@ class DevtoolTests(DevtoolBase):
result = runCmd("devtool --quiet selftest-reverse \"%s\"" % s)
self.assertEqual(result.output, s[::-1])
+ def _copy_file_with_cleanup(self, srcfile, basedstdir, *paths):
+ dstdir = basedstdir
+ self.assertTrue(os.path.exists(dstdir))
+ for p in paths:
+ dstdir = os.path.join(dstdir, p)
+ if not os.path.exists(dstdir):
+ os.makedirs(dstdir)
+ self.track_for_cleanup(dstdir)
+ dstfile = os.path.join(dstdir, os.path.basename(srcfile))
+ if srcfile != dstfile:
+ shutil.copy(srcfile, dstfile)
+ self.track_for_cleanup(dstfile)
+
+ def test_devtool_load_plugin(self):
+ """Test that devtool loads only the first found plugin in BBPATH."""
+
+ self.track_for_cleanup(self.workspacedir)
+ self.add_command_to_tearDown('bitbake-layers remove-layer */workspace')
+
+ devtool = runCmd("which devtool")
+ fromname = runCmd("devtool --quiet pluginfile")
+ srcfile = fromname.output
+ bbpath = get_bb_var('BBPATH')
+ searchpath = bbpath.split(':') + [os.path.dirname(devtool.output)]
+ plugincontent = []
+ with open(srcfile) as fh:
+ plugincontent = fh.readlines()
+ try:
+ self.assertIn('meta-selftest', srcfile, 'wrong bbpath plugin found')
+ for path in searchpath:
+ self._copy_file_with_cleanup(srcfile, path, 'lib', 'devtool')
+ result = runCmd("devtool --quiet count")
+ self.assertEqual(result.output, '1')
+ result = runCmd("devtool --quiet multiloaded")
+ self.assertEqual(result.output, "no")
+ for path in searchpath:
+ result = runCmd("devtool --quiet bbdir")
+ self.assertEqual(result.output, path)
+ os.unlink(os.path.join(result.output, 'lib', 'devtool', 'bbpath.py'))
+ finally:
+ with open(srcfile, 'w') as fh:
+ fh.writelines(plugincontent)
+
def _setup_test_devtool_finish_upgrade(self):
# Check preconditions
self.assertTrue(not os.path.exists(self.workspacedir), 'This test cannot be run with a workspace directory under the build directory')
--
2.1.4
^ permalink raw reply related
* [PATCH 4/4] recipetool: Load plugins in a well defined order
From: Ola x Nilsson @ 2016-10-25 11:03 UTC (permalink / raw)
To: olani, openembedded-core
In-Reply-To: <1477393415-13053-1-git-send-email-olani@axis.com>
From: Ola x Nilsson <ola.x.nilsson@axis.com>
To allow recipetool plugins in one layer to shadow another in a well
defined way, first search BBPATH/lib/recipetool directories and then
scripts/lib/recipetool and load only the first found.
The previous search and load loop would load all found plugins with the
ones found later replacing any found before.
Signed-off-by: Ola x Nilsson <ola.x.nilsson@axis.com>
---
scripts/recipetool | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/scripts/recipetool b/scripts/recipetool
index 1052cd2..00c9007 100755
--- a/scripts/recipetool
+++ b/scripts/recipetool
@@ -78,8 +78,8 @@ def main():
tinfoil = tinfoil_init(False)
try:
- for path in ([scripts_path] +
- tinfoil.config_data.getVar('BBPATH', True).split(':')):
+ for path in (tinfoil.config_data.getVar('BBPATH', True).split(':')
+ + [scripts_path]):
pluginpath = os.path.join(path, 'lib', 'recipetool')
scriptutils.load_plugins(logger, plugins, pluginpath)
--
2.1.4
^ permalink raw reply related
* [PATCH 3/4] devtool: Load plugins in a well defined order
From: Ola x Nilsson @ 2016-10-25 11:03 UTC (permalink / raw)
To: olani, openembedded-core
In-Reply-To: <1477393415-13053-1-git-send-email-olani@axis.com>
From: Ola x Nilsson <ola.x.nilsson@axis.com>
To allow devtool plugins in one layer to shadow another in a well
defined way, first search BBPATH/lib/devtool directories and then
scripts/lib/devool and load only the first found.
The previous search and load loop would load all found plugins with the
ones found later replacing any found before.
Signed-off-by: Ola x Nilsson <ola.x.nilsson@axis.com>
---
scripts/devtool | 3 ++-
scripts/lib/scriptutils.py | 8 ++++++--
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/scripts/devtool b/scripts/devtool
index 0c32c50..2197493 100755
--- a/scripts/devtool
+++ b/scripts/devtool
@@ -294,7 +294,8 @@ def main():
finally:
tinfoil.shutdown()
- for path in [scripts_path] + global_args.bbpath.split(':'):
+ # Search BBPATH first to allow layers to override plugins in scripts_path
+ for path in global_args.bbpath.split(':') + [scripts_path]:
pluginpath = os.path.join(path, 'lib', 'devtool')
scriptutils.load_plugins(logger, plugins, pluginpath)
diff --git a/scripts/lib/scriptutils.py b/scripts/lib/scriptutils.py
index 5ccc027..27d82b6 100644
--- a/scripts/lib/scriptutils.py
+++ b/scripts/lib/scriptutils.py
@@ -52,10 +52,14 @@ def load_plugins(logger, plugins, pluginpath):
if fp:
fp.close()
+ def plugin_name(filename):
+ return os.path.splitext(os.path.basename(filename))[0]
+
+ known_plugins = [plugin_name(p.__name__) for p in plugins]
logger.debug('Loading plugins from %s...' % pluginpath)
for fn in glob.glob(os.path.join(pluginpath, '*.py')):
- name = os.path.splitext(os.path.basename(fn))[0]
- if name != '__init__':
+ name = plugin_name(fn)
+ if name != '__init__' and name not in known_plugins:
plugin = load_plugin(name)
if hasattr(plugin, 'plugin_init'):
plugin.plugin_init(plugins)
--
2.1.4
^ permalink raw reply related
* Re: meta-toolchain and meta-toolchain-qt for specific image
From: thilo.cestonaro @ 2016-10-25 11:03 UTC (permalink / raw)
To: anders@chargestorm.se; +Cc: openembedded-core@lists.openembedded.org
In-Reply-To: <20161025074921.sqpe3dup4jqkcqe5@ad.chargestorm.se>
[-- Attachment #1: Type: text/plain, Size: 188 bytes --]
> Yes, `bitbake <my-image>` does only build your image and `bitbake
> <my-image> -c populate_sdk` does only build the SDK.
>
Then I will give it a try!
Thanks!
Cheers,
Thilo
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3847 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox