Re: [OE-core] [PATCH] systemtap: 3.3 -> 4.0
On Tue, 16 Oct 2018, Richard Purdie wrote: On Tue, 2018-10-16 at 10:27 +0100, Burton, Ross wrote: On Mon, 15 Oct 2018 at 19:22, Victor Kamensky wrote: Upgrade systemtap from 3.3 to 4.0: Removed backported patch. WARNING: systemtap-4.0-r0 do_package_qa: QA Issue: systemtap: /systemtap/etc/stap-exporter/EXAMPLE is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination systemtap: /systemtap/etc/stap-exporter/EXAMPLE_NOERROR is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination systemtap: /systemtap/etc/stap-exporter/errno.stp is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination systemtap: /systemtap/etc/stap-exporter/syscalllatency.stp is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination systemtap: /systemtap/etc/stap-exporter/timeout.stp is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination systemtap: /systemtap/etc/stap-exporter/topsys.stp is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated] There are also other issues from the addition of systemd unit files in 4.0. I've a patch in -next which tweaks both issues which I'll put in for testing. Richard, thank you very prompt help. In the long term it would be beneficial that those issues be fixed in SystemTap itself, correct? If so, I can look at creating proper patches and pushing them into SystemTap. Also on my todo list is to attempt to push few existing OE systemtap patches into SystemTap upstream source. I believe they look like quite legit issues and I hope they could be upstreamed. Thanks, Victor Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] boost.inc: make libboost_python3.so available
On 2018年10月16日 20:05, Burton, Ross wrote: On Tue, 16 Oct 2018 at 12:18, Burton, Ross wrote: OpenCV has a patch to "fix" (bodge) the Py2 build: https://github.com/ros-perception/vision_opencv/pull/239 But this doesn't work for Py3. This was just pushed: https://github.com/ros-perception/vision_opencv/commit/b57fd5b Thanks Ross! I'm fine not add the the hack fix from boost side, but as I know there is another package camera-calibration-parsers which has the same problem as below apart from cv-bridge. BTW, there may some other package also has this kind of problem. This to say we need to fix the issue for the this kind of packages one by one. meta-ros/recipes-ros/image-common/camera-calibration-parsers_1.11.13.bb:do_configure failed | CMake Error at /$Prj/camera-calibration-parsers/1.11.13-r0/recipe-sysroot-native/usr/share/cmake-3.12/Modules/FindBoost.cmake:2048 (message): | Unable to find the requested Boost libraries. | | Boost version: 1.68.0 | | Boost include path: | /$Prj/camera-calibration-parsers/1.11.13-r0/recipe-sysroot/usr/include | | | Could not find the following Boost libraries: | | boost_python3 | | Some (but not all) of the required Boost libraries were found. You may | need to install these additional Boost libraries. Alternatively, set | BOOST_LIBRARYDIR to the directory containing Boost libraries or BOOST_ROOT | to the location of Boost. | Call Stack (most recent call first): | CMakeLists.txt:10 (find_package) Thanks, Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] ifupdown: fix issue for configuring loopback interface
The patch inet-6-.defn-fix-inverted-checks-for-loopback.patch introduced an issue that ifup/ifdown can not configure loopback interface: $ cat /etc/network/interfaces auto lo iface lo inet loopback $ ifconfig -s Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVRTX-OK TX-ERR TX-DRP TX-OVR Flg eth0 1500 0 1 0 0 074 0 0 0 BMRU lo65536 0 2 0 0 0 2 0 0 0 LRU $ ifdown lo $ ifconfig -s Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVRTX-OK TX-ERR TX-DRP TX-OVR Flg eth0 1500 0 1 0 0 074 0 0 0 BMRU lo65536 0 2 0 0 0 2 0 0 0 LRU The original patch is for 0.7.x and the change is not needed for 0.8.x. Update the patch to make the ifup/ifdown can configure lo interface: $ ifconfig -s Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVRTX-OK TX-ERR TX-DRP TX-OVR Flg eth0 1500 0 0 0 0 077 0 0 0 BMRU lo65536 0 2 0 0 0 2 0 0 0 LRU $ ifdown lo $ ifconfig -s Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVRTX-OK TX-ERR TX-DRP TX-OVR Flg eth0 1500 0 0 0 0 080 0 0 0 BMRU $ ifup lo $ ifconfig -s Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVRTX-OK TX-ERR TX-DRP TX-OVR Flg eth0 1500 0 0 0 0 081 0 0 0 BMRU lo65536 0 2 0 0 0 2 0 0 0 LRU Signed-off-by: Yi Zhao --- ...-6-.defn-fix-inverted-checks-for-loopback.patch | 38 +++--- 1 file changed, 11 insertions(+), 27 deletions(-) diff --git a/meta/recipes-core/ifupdown/files/inet-6-.defn-fix-inverted-checks-for-loopback.patch b/meta/recipes-core/ifupdown/files/inet-6-.defn-fix-inverted-checks-for-loopback.patch index 2013933..37a61c9 100644 --- a/meta/recipes-core/ifupdown/files/inet-6-.defn-fix-inverted-checks-for-loopback.patch +++ b/meta/recipes-core/ifupdown/files/inet-6-.defn-fix-inverted-checks-for-loopback.patch @@ -1,4 +1,4 @@ -From d88af5aa0312ea18aac791d1da79b7bcd032 Mon Sep 17 00:00:00 2001 +From 7efe4676747e4e4a056b9bfb4e9424c8354e9996 Mon Sep 17 00:00:00 2001 From: "Maxin B. John" Date: Wed, 21 Dec 2016 15:32:07 +0200 Subject: [PATCH] inet[6].defn: fix inverted checks for loopback @@ -35,12 +35,13 @@ Upstream-Status: Inappropriate [OE specific] Signed-off-by: Paul Gortmaker Signed-off-by: Maxin B. John +Signed-off-by: Yi Zhao --- - inet.defn | 148 +++--- - 1 file changed, 74 insertions(+), 74 deletions(-) + inet.defn | 140 +++--- + 1 file changed, 70 insertions(+), 70 deletions(-) diff --git a/inet.defn b/inet.defn -index 75e6744..b5f5da2 100644 +index 75e6744..23c7756 100644 --- a/inet.defn +++ b/inet.defn @@ -6,10 +6,10 @@ method loopback @@ -48,11 +49,11 @@ index 75e6744..b5f5da2 100644 up -/bin/ip link set dev %iface% up if (!iface_is_lo()) -+ip link set dev %iface% up if (iface_is_lo()) ++ip link set dev %iface% up if (!iface_is_lo()) down -/bin/ip link set dev %iface% down if (!iface_is_lo()) -+ip link set dev %iface% down if (iface_is_lo()) ++ip link set dev %iface% down if (!iface_is_lo()) method static description @@ -211,23 +212,20 @@ index 75e6744..b5f5da2 100644 architecture kfreebsd -@@ -211,12 +211,12 @@ method loopback +@@ -211,11 +211,11 @@ method loopback This method may be used to define the IPv4 loopback interface. up -/sbin/ifconfig %iface% 127.0.0.1 up \ -- if (!iface_is_lo()) +ifconfig %iface% 127.0.0.1 up \ -+ if (iface_is_lo()) + if (!iface_is_lo()) down -/sbin/ifconfig %iface% down \ -- if (!iface_is_lo()) +ifconfig %iface% down \ -+ if (iface_is_lo()) + if (!iface_is_lo()) method static - description @@ -238,15 +238,15 @@ method static hwaddress cleanup_hwaddress @@ -339,20 +337,6 @@ index 75e6744..b5f5da2 100644 architecture hurd method loopback -@@ -367,11 +367,11 @@ method loopback - - up - inetutils-ifconfig --interface %iface% --address 127.0.0.1 --up \ -- if (!iface_is_lo()) -+ if (iface_is_lo()) - - down - inetutils-ifconfig --interface %iface% --down \ -- if (!iface_is_lo()) -+ if (iface_is_lo()) - - method static - description @@ -432,23 +432,23 @@ method dhcp up @@ -418,5 +402,5 @@ index 75e6744..b5f5da2 100644 -/usr/sbin/avahi-autoipd --kill %iface% +avahi-autoipd --kill %iface% -- -2.4.0 +2.7.4 -- 2.7.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] ✗ patchtest: failure for valgrind: update from 3.13.0 to 3.14.0
== Series Details == Series: valgrind: update from 3.13.0 to 3.14.0 Revision: 1 URL : https://patchwork.openembedded.org/series/14563/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been executed on the proposed series by patchtest resulting in the following failures: * Issue Patches not removed from tree [test_src_uri_left_files] Suggested fixAmend the patch containing the software patch file removal Patch0002-fix-broken-inline-asm-in-tests-on-mips32-linux.patch If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core@lists.openembedded.org) raising your concerns. Otherwise we would appreciate you correcting the issues and submitting a new version of the patchset if applicable. Please ensure you add/increment the version number when sending the new version (i.e. [PATCH] -> [PATCH v2] -> [PATCH v3] -> ...). --- Guidelines: https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] valgrind upgrade
I know it's late, I know we're weary, I know our plans don't include [1] valgrind 3.14 which was released recently after 1.5 years of development. I believe that some of the M3 valgrind QA results we'ren't very good so if we're going to try to fix those problems, perhaps we should be working on the 3.14 release. I've reviewed and updated the patches but so far I've only built for qemux86. The other qemus are building overnight. If someone wants to test basic runtime functions and better still run the ptests, that would be great. The important bits of the release notes IMO: * More than 100 bugs fixed. * Valgrind is now buildable with link-time optimisation (LTO). A new configure option --enable-lto=yes allows building Valgrind with LTO. If the toolchain supports it, this produces a smaller/faster Valgrind (up to 10%). Note that if you are doing Valgrind development, --enable-lto=yes massively slows down the build process. -- I haven't added support for that option yet. A 10% performance boost is hard to turn down but we'd need to understand the build impact. * The new option --keep-debuginfo=no|yes (default no) can be used to retain debug info for unloaded code. This allows saved stack traces (e.g. for memory leaks) to include file/line info for code that has been dlclose'd (or similar). See the user manual for more information and known limitations. -- sounds like it should be a default but I haven't added it yet. Full release notes: http://valgrind.org/docs/manual/dist.news.html ../Randy [1] With apologies for the first line to Kenny Rogers. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] valgrind: update from 3.13.0 to 3.14.0
Removed patches are all upstream.
Adjusted two patches due to rebase.
Signed-off-by: Randy MacLeod
---
...se-ucontext_t-instead-of-struct-ucon.patch | 30 ---
...ntext-APIs-are-not-available-on-musl.patch | 17 ++--
.../0004-Fix-out-of-tree-builds.patch | 49 ++-
.../valgrind/valgrind/link-gz-tests.patch | 27 --
...sk-CPUID-support-in-HWCAP-on-aarch64.patch | 36
.../valgrind/valgrind/ppc-headers.patch | 87 ---
...{valgrind_3.13.0.bb => valgrind_3.14.0.bb} | 11 +--
7 files changed, 40 insertions(+), 217 deletions(-)
delete mode 100644
meta/recipes-devtools/valgrind/valgrind/0001-memcheck-tests-Use-ucontext_t-instead-of-struct-ucon.patch
delete mode 100644 meta/recipes-devtools/valgrind/valgrind/link-gz-tests.patch
delete mode 100644
meta/recipes-devtools/valgrind/valgrind/mask-CPUID-support-in-HWCAP-on-aarch64.patch
delete mode 100644 meta/recipes-devtools/valgrind/valgrind/ppc-headers.patch
rename meta/recipes-devtools/valgrind/{valgrind_3.13.0.bb =>
valgrind_3.14.0.bb} (91%)
diff --git
a/meta/recipes-devtools/valgrind/valgrind/0001-memcheck-tests-Use-ucontext_t-instead-of-struct-ucon.patch
b/meta/recipes-devtools/valgrind/valgrind/0001-memcheck-tests-Use-ucontext_t-instead-of-struct-ucon.patch
deleted file mode 100644
index bf16a1adfe..00
---
a/meta/recipes-devtools/valgrind/valgrind/0001-memcheck-tests-Use-ucontext_t-instead-of-struct-ucon.patch
+++ /dev/null
@@ -1,30 +0,0 @@
-From 629ac492b1d9bc709d17337eb9b1c28603eca250 Mon Sep 17 00:00:00 2001
-From: Khem Raj
-Date: Wed, 28 Jun 2017 11:01:25 -0700
-Subject: [PATCH] memcheck/tests: Use ucontext_t instead of struct ucontext
-
-glibc 2.26 does not expose struct ucontext anymore
-
-Upstream-Status: Submitted [https://bugs.kde.org/show_bug.cgi?id=381769]
-
-Signed-off-by: Khem Raj
- memcheck/tests/linux/stack_changes.c | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/memcheck/tests/linux/stack_changes.c
b/memcheck/tests/linux/stack_changes.c
-index ffb49c6..acc4109 100644
a/memcheck/tests/linux/stack_changes.c
-+++ b/memcheck/tests/linux/stack_changes.c
-@@ -11,7 +11,7 @@
- // checks that Valgrind notices their stack changes properly.
-
- #ifdef __GLIBC__
--typedef struct ucontext mycontext;
-+typedef ucontext_t mycontext;
-
- mycontext ctx1, ctx2, oldc;
- int count;
---
-2.13.2
-
diff --git
a/meta/recipes-devtools/valgrind/valgrind/0002-context-APIs-are-not-available-on-musl.patch
b/meta/recipes-devtools/valgrind/valgrind/0002-context-APIs-are-not-available-on-musl.patch
index 3f9f33b487..480fe33247 100644
---
a/meta/recipes-devtools/valgrind/valgrind/0002-context-APIs-are-not-available-on-musl.patch
+++
b/meta/recipes-devtools/valgrind/valgrind/0002-context-APIs-are-not-available-on-musl.patch
@@ -1,17 +1,20 @@
-From 862b807076d57f2f58ed9d572ddac8bb402774a2 Mon Sep 17 00:00:00 2001
-From: Khem Raj
-Date: Sat, 10 Jun 2017 01:01:10 -0700
-Subject: [PATCH 2/6] context APIs are not available on musl
+From bd4e926e7e14747b3cd4d7b2a1bd5410b22f3ea2 Mon Sep 17 00:00:00 2001
+From: Randy MacLeod
+Date: Tue, 16 Oct 2018 21:27:46 -0400
+Subject: [PATCH] context APIs are not available on musl
Upstream-Status: Pending
+Updated patch for valgrind-3.14
+
Signed-off-by: Khem Raj
+Signed-off-by: Randy MacLeod
---
memcheck/tests/linux/stack_changes.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/memcheck/tests/linux/stack_changes.c
b/memcheck/tests/linux/stack_changes.c
-index a978fc2..ffb49c6 100644
+index 7f97b90a5..a26cb4ae6 100644
--- a/memcheck/tests/linux/stack_changes.c
+++ b/memcheck/tests/linux/stack_changes.c
@@ -10,6 +10,7 @@
@@ -19,7 +22,7 @@ index a978fc2..ffb49c6 100644
// checks that Valgrind notices their stack changes properly.
+#ifdef __GLIBC__
- typedef struct ucontext mycontext;
+ typedef ucontext_t mycontext;
mycontext ctx1, ctx2, oldc;
@@ -51,9 +52,11 @@ int init_context(mycontext *uc)
@@ -45,5 +48,5 @@ index a978fc2..ffb49c6 100644
return 0;
}
--
-2.13.1
+2.17.0
diff --git
a/meta/recipes-devtools/valgrind/valgrind/0004-Fix-out-of-tree-builds.patch
b/meta/recipes-devtools/valgrind/valgrind/0004-Fix-out-of-tree-builds.patch
index 39022d04ae..75bb0aa7cb 100644
--- a/meta/recipes-devtools/valgrind/valgrind/0004-Fix-out-of-tree-builds.patch
+++ b/meta/recipes-devtools/valgrind/valgrind/0004-Fix-out-of-tree-builds.patch
@@ -1,7 +1,7 @@
-From 739421e253e6eba3eb6438651822f80fa9c0502a Mon Sep 17 00:00:00 2001
-From: Alexander Kanavin
-Date: Tue, 15 Dec 2015 15:31:50 +0200
-Subject: [PATCH 1/2] Fix out of tree builds.
+From 8f916dcb395fe5a2429f2867ba4daf8ef3af073a Mon Sep 17 00:00:00 2001
+From: Randy MacLeod
+Date: Tue, 16 Oct 2018 21:01:04 -0400
+Subject: [PATCH] Fix out of tree builds.
The paths to these files need to be fully specified in
the out of tree build case. glibc-2.X.supp is a generated file so the full path
@@ -9,18 +9,21 @@ is
[OE-core] [AUH] Upgrade status: 2018-10-16
Recipe upgrade statistics: * Failed(other errors): 1 u-boot, 2018.09, Marek Vasut * Failed(do_compile): 28 nfs-utils, 2.3.3, Robert Yang u-boot-fw-utils, 2018.09, Marek Vasut python3-pygobject, 3.30.1, Derek Straka gstreamer1.0-python, 1.14.4, Anuj Mittal gstreamer1.0-plugins-good, 1.14.4, Anuj Mittal dmidecode, 3.2, Alexander Kanavin libsoup-2.4, 2.64.1, Ross Burton gst-validate, 1.14.4, Anuj Mittal prelink, 1.0-new-commits-available, Mark Hatle gnu-efi, 3.0.9, Yi Zhao systemtap, 4.0, Victor Kamensky python3-pycairo, 1.17.1, Derek Straka epiphany, 3.30.1, Alexander Kanavin git, 2.19.1, Robert Yang cmake, 3.12.3, Otavio Salvador gstreamer1.0-vaapi, 1.14.4, Anuj Mittal at-spi2-atk, 2.30.0, Ross Burton dpkg, 1.19.2, Aníbal Limón gstreamer1.0-plugins-base, 1.14.4, Anuj Mittal e2fsprogs, 1.44.4, Robert Yang iptables, 1.8.0, Changhyeok Bae glib-networking, 2.58.0, Ross Burton systemtap-uprobes, 4.0, Victor Kamensky piglit, 1.0-new-commits-available, Ross Burton gstreamer1.0-plugins-bad, 1.14.4, Anuj Mittal gstreamer1.0-rtsp-server, 1.14.4, Anuj Mittal u-boot-mkimage, 2018.09, Marek Vasut openssh, 7.8., Armin Kuster * Succeeded: 51 linux-firmware, 0.0-new-commits-available, Otavio Salvador lz4, 1.8.3, Denys Dmytriyenko libepoxy, 1.5.3, Ross Burton nss, 3.39, Armin Kuster kmscube, git-new-commits-available, Carlos Rafael Giani gstreamer1.0, 1.14.4, Anuj Mittal sbc, 1.4, Tanu Kaskinen python-setuptools, 40.4.3, Derek Straka vala, 0.42.2, Alexander Kanavin python-numpy, 1.15.2, Derek Straka gnupg, 2.2.10, Hongxu Jia ccache, 3.4.3, Robert Yang eudev, 3.2.6, Ross Burton mtools, 4.0.19, Ross Burton glib-2.0, 2.58.1, Ross Burton gnutls, 3.6.4, Armin Kuster xkeyboard-config, 2.25, Armin Kuster python3-numpy, 1.15.2, Derek Straka json-glib, 1.4.4, Yi Zhao gsettings-desktop-schemas, 3.28.1, Ross Burton puzzles, 0.0-new-commits-available, Ross Burton ncurses, 6.1+20180714, Hongxu Jia lttng-ust, 2.10.2, Richard Purdie libxcb, 1.13.1, Armin Kuster ofono, 1.25, Ross Burton harfbuzz, 1.9.0, Ross Burton psmisc, 23.2, Alexander Kanavin apr, 1.6.5, Hongxu Jia ethtool, 4.18, Changhyeok Bae busybox, 1.29.3, Andrej Valek gnu-config, 20180713-new-commits-available, Robert Yang python3-pbr, 4.3.0, Derek Straka libpcre2, 10.32, Armin Kuster subversion, 1.10.3, Richard Purdie xserver-xorg, 1.20.2, Armin Kuster python3-setuptools, 40.4.3, Derek Straka python3-pip, 18.1, Derek Straka sqlite3, 3.25.2, Ross Burton libdrm, 2.4.95, Otavio Salvador libsm, 1.2.3, Armin Kuster curl, 7.61.1, Armin Kuster python3-gitdb, 2.0.5, Derek Straka pkgconf, 1.5.4, Ross Burton sudo, 1.8.25p1, Chen Qi xf86-input-libinput, 0.28.1, Armin Kuster at-spi2-core, 2.30.0, Ross Burton lighttpd, 1.4.51, Alexander Kanavin gst-examples, 0.0.1-new-commits-available, Anuj Mittal libinput, 1.12.1, Ross Burton adwaita-icon-theme, 3.30.0, Ross Burton sysstat, 12.1.1, Chen Qi * Failed (devtool error): 46 mesa, 18.2.2, Otavio Salvador acl, 2.2.53, Chen Qi acpica, 20181003, Fathi Boudra connman, 1.36, Changhyeok Bae ifupdown, 0.8.33, Ross Burton lttng-tools, 2.10.5, Richard Purdie squashfs-tools, 4.3-new-commits-available, Robert Yang librepo, 1.9.2, Alexander Kanavin libpcap, 1.9.0, Ross Burton apt, 1.7.0, Aníbal Limón libdnf, 0.22.0, Alexander Kanavin glide, 0.13.2, Otavio Salvador gtk+3, 3.24.1, Ross Burton lzop, 1.04, Denys Dmytriyenko sed, 4.5, Chen Qi binutils, 2.31.1, Khem Raj elfutils, 0.174, Hongxu Jia atk, 2.30.0, Ross Burton nspr, 4.20, Armin Kuster webkitgtk, 2.22.2, Alexander Kanavin build-compare, 2015.02.10-new-commits-available, Paul Eggleton build-appliance-image, 19.0.1, Richard Purdie meson, 0.48.0, Alexander Kanavin go, 1.11.1, Khem Raj ltp, 20180926, Yi Zhao attr, 2.4.48, Chen Qi dnf, 4.0.4, Alexander Kanavin fontconfig, 2.13.1, Ross Burton man-db, 2.8.4, Hongxu Jia lsbinitscripts, 10.01, Ross Burton bison, 3.1, Chen Qi flex, 2.6.4, Chen Qi sysvinit, 2.90, Ross Burton db, 5.3.28+dfsg1, Mark Hatle libx11, 1.6.7, Armin
[OE-core] ✗ patchtest: failure for harfbuzz:1.8.8->1.9.0 (rev2)
== Series Details == Series: harfbuzz:1.8.8->1.9.0 (rev2) Revision: 2 URL : https://patchwork.openembedded.org/series/14560/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been executed on the proposed series by patchtest resulting in the following failures: * Issue Series sent to the wrong mailing list or some patches from the series correspond to different mailing lists [test_target_mailing_list] Suggested fixSend the series again to the correct mailing list (ML) Suggested ML openembedded-de...@lists.openembedded.org [http://git.openembedded.org/meta-openembedded/] Patch's path:meta-networking/recipes-support/geoip/geoipupdate_2.5.0.bb * Issue Series does not apply on top of target branch [test_series_merge_on_head] Suggested fixRebase your series on top of targeted branch Targeted branch master (currently at 74833a612c) If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core@lists.openembedded.org) raising your concerns. Otherwise we would appreciate you correcting the issues and submitting a new version of the patchset if applicable. Please ensure you add/increment the version number when sending the new version (i.e. [PATCH] -> [PATCH v2] -> [PATCH v3] -> ...). --- Guidelines: https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] [PATCH] e2fsprogs:1.44.3->1.44.4
Upgrade e2fsprogs from 1.44.3 to 1.44.4
Signed-off-by: Hong Liu
---
.../e2fsprogs/{e2fsprogs_1.44.3.bb => e2fsprogs_1.44.4.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-devtools/e2fsprogs/{e2fsprogs_1.44.3.bb =>
e2fsprogs_1.44.4.bb} (98%)
diff --git a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.44.3.bb
b/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.44.4.bb
similarity index 98%
rename from meta/recipes-devtools/e2fsprogs/e2fsprogs_1.44.3.bb
rename to meta/recipes-devtools/e2fsprogs/e2fsprogs_1.44.4.bb
index 823d18b..99b4d68 100644
--- a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.44.3.bb
+++ b/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.44.4.bb
@@ -12,7 +12,7 @@ SRC_URI_append_class-native = "
file://e2fsprogs-fix-missing-check-for-permissio
file://quiet-debugfs.patch \
"
-SRCREV = "85e53f42f98d5334914de01e972e9ed44bccd0a5"
+SRCREV = "40e66e2e8be046f909dfff73b3909f15c9d0f400"
UPSTREAM_CHECK_GITTAGREGEX = "v(?P\d+\.\d+(\.\d+)*)$"
EXTRA_OECONF += "--libdir=${base_libdir} --sbindir=${base_sbindir} \
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] [PATCH] geoipupdate:2.5.0->3.1.1
1.Upgrade geoipupdate from 2.5.0 to 3.1.1.
Signed-off-by: Hong Liu
---
.../geoip/{geoipupdate-2.5.0 => geoipupdate-3.1.1}/GeoIP.conf | 0
.../{geoipupdate-2.5.0 => geoipupdate-3.1.1}/geoipupdate.cron | 0
.../geoip/{geoipupdate_2.5.0.bb => geoipupdate_3.1.1.bb} | 8
3 files changed, 4 insertions(+), 4 deletions(-)
rename meta-networking/recipes-support/geoip/{geoipupdate-2.5.0 =>
geoipupdate-3.1.1}/GeoIP.conf (100%)
rename meta-networking/recipes-support/geoip/{geoipupdate-2.5.0 =>
geoipupdate-3.1.1}/geoipupdate.cron (100%)
rename meta-networking/recipes-support/geoip/{geoipupdate_2.5.0.bb =>
geoipupdate_3.1.1.bb} (76%)
diff --git a/meta-networking/recipes-support/geoip/geoipupdate-2.5.0/GeoIP.conf
b/meta-networking/recipes-support/geoip/geoipupdate-3.1.1/GeoIP.conf
similarity index 100%
rename from meta-networking/recipes-support/geoip/geoipupdate-2.5.0/GeoIP.conf
rename to meta-networking/recipes-support/geoip/geoipupdate-3.1.1/GeoIP.conf
diff --git
a/meta-networking/recipes-support/geoip/geoipupdate-2.5.0/geoipupdate.cron
b/meta-networking/recipes-support/geoip/geoipupdate-3.1.1/geoipupdate.cron
similarity index 100%
rename from
meta-networking/recipes-support/geoip/geoipupdate-2.5.0/geoipupdate.cron
rename to
meta-networking/recipes-support/geoip/geoipupdate-3.1.1/geoipupdate.cron
diff --git a/meta-networking/recipes-support/geoip/geoipupdate_2.5.0.bb
b/meta-networking/recipes-support/geoip/geoipupdate_3.1.1.bb
similarity index 76%
rename from meta-networking/recipes-support/geoip/geoipupdate_2.5.0.bb
rename to meta-networking/recipes-support/geoip/geoipupdate_3.1.1.bb
index f4eb2b7..8eb71c5 100644
--- a/meta-networking/recipes-support/geoip/geoipupdate_2.5.0.bb
+++ b/meta-networking/recipes-support/geoip/geoipupdate_3.1.1.bb
@@ -6,17 +6,17 @@ SECTION = "net"
DEPENDS = "zlib curl"
-SRC_URI =
"https://github.com/maxmind/geoipupdate/releases/download/v2.5.0/geoipupdate-2.5.0.tar.gz
\
+SRC_URI =
"https://github.com/maxmind/geoipupdate/releases/download/v3.1.1/geoipupdate-3.1.1.tar.gz
\
file://GeoIP.conf \
file://geoipupdate.cron \
"
-SRC_URI[md5sum] = "28f633c49ec87ab01ad3c0fb0228a696"
-SRC_URI[sha256sum] =
"5119fd0e338cd083e886228b26679c64bcbaade8a815be092aecf865a610ab26"
+SRC_URI[md5sum] = "e4b9bb0b60748e2f49c8ed07ea330fbd"
+SRC_URI[sha256sum] =
"3de22e3fe3282024288a00807bbea9a1ffa2d1e8fe9c611f4b14a5b4d8ebe08a"
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "\
-file://ChangeLog.md;md5=11d2e31df0de2be3ccc3e2286c4dafcb \
+file://ChangeLog.md;md5=30029632df335cb696f68ecc2a428987 \
"
FILES_${PN} = "/usr/share/GeoIP \
/etc/GeoIP.conf \
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] [PATCH] harfbuzz:1.8.8->1.9.0
1.Upgrade harfbuzz from 1.8.8 to 1.9.0.
Signed-off-by: Hong Liu
---
.../harfbuzz/{harfbuzz_1.8.8.bb => harfbuzz_1.9.0.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-graphics/harfbuzz/{harfbuzz_1.8.8.bb => harfbuzz_1.9.0.bb}
(90%)
diff --git a/meta/recipes-graphics/harfbuzz/harfbuzz_1.8.8.bb
b/meta/recipes-graphics/harfbuzz/harfbuzz_1.9.0.bb
similarity index 90%
rename from meta/recipes-graphics/harfbuzz/harfbuzz_1.8.8.bb
rename to meta/recipes-graphics/harfbuzz/harfbuzz_1.9.0.bb
index b904d93..0b27634 100644
--- a/meta/recipes-graphics/harfbuzz/harfbuzz_1.8.8.bb
+++ b/meta/recipes-graphics/harfbuzz/harfbuzz_1.9.0.bb
@@ -11,8 +11,8 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=e021dd6dda6ff1e6b1044002fc662b9b \
DEPENDS = "glib-2.0 cairo fontconfig freetype"
SRC_URI = "http://www.freedesktop.org/software/harfbuzz/release/${BP}.tar.bz2;
-SRC_URI[md5sum] = "81dbce82d6471ec2b2a627ce02d03e5d"
-SRC_URI[sha256sum] =
"a8e5c86e4d99e1cc9865ec1b8e9b05b98e413c2a885cd11f8e9bb9502dd3e3a9"
+SRC_URI[md5sum] = "263a3f1cb014e3ad2e4123c238a9bfc5"
+SRC_URI[sha256sum] =
"11eca62bf0ac549b8d6be55f4e130946399939cdfe7a562fdaee711190248b00"
inherit autotools pkgconfig lib_package gtk-doc
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] mesa: enable virgl driver for qemux86/qemux86-64
On 9/20/18 6:37 PM, Burton, Ross wrote:
> I'm assuming you have a local config to turn on gallium, as that isn't
> enabled by default.
This appears to be changing the basehash for mesa.
Fro bitbake-diffsigs:
Hash for dependent task mesa/mesa_18.1.9.bb.do_configure changed from
cd484f650abebbd8126040df82218cb8 to cf71872a3ad0ccea0933b914d1eef467
basehash changed from 8f512789ad94158da66c949e97a15ae8 to
3a5c711c799c7ba6edd399ebf84fcc65
Variable GALLIUMDRIVERS value changed:
@@ -1,4 +1,4 @@
-swrast${@bb.utils.contains('PACKAGECONFIG', 'etnaviv', ',etnaviv', '',
d)}${@bb.utils.contains('PACKAGECONFIG', 'imx', ',imx', '',
d)}${@bb.utils.contains('PACKAGECONFIG', 'gallium-llvm',
',${GALLIUMDRIVERS_LLVM}', '', d)}
+swrast${@bb.utils.contains('PACKAGECONFIG', 'etnaviv', ',etnaviv', '',
d)}${@bb.utils.contains('PACKAGECONFIG', 'imx', ',imx', '',
d)}${@bb.utils.contains('PACKAGECONFIG', 'gallium-llvm',
',${GALLIUMDRIVERS_LLVM}', '', d)},virgl
PACKAGECONFIG{etnaviv} = Unset
PACKAGECONFIG{gallium-llvm} = Unset
PACKAGECONFIG{imx} = Unset
I'm finding this when I try to do a genericx86-64 and qemux86-64 build in the
same project. The package, and everything depending on mesa keeps building due
to this.
I'm wondering if virgl should be enabled by default, and then disabled as a
distro config if the user really doesn't want it?
--Mark
> Ross
> On Wed, 19 Sep 2018 at 04:28, wrote:
>>
>> From: Ming Liu
>>
>> virgl driver should be enabled for qemux86/qemux86-64 machines, or else
>> it will cause runtime issue due to virtio_gpu driver missing.
>>
>> Signed-off-by: Ming Liu
>> ---
>> meta/recipes-graphics/mesa/mesa.inc | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/meta/recipes-graphics/mesa/mesa.inc
>> b/meta/recipes-graphics/mesa/mesa.inc
>> index 5afd0db..8d0e2cb 100644
>> --- a/meta/recipes-graphics/mesa/mesa.inc
>> +++ b/meta/recipes-graphics/mesa/mesa.inc
>> @@ -91,6 +91,8 @@ GALLIUMDRIVERS_LLVM33_ENABLED =
>> "${@oe.utils.version_less_or_equal('MESA_LLVM_RE
>> GALLIUMDRIVERS_LLVM = "r300,svga,nouveau${@',${GALLIUMDRIVERS_LLVM33}' if
>> ${GALLIUMDRIVERS_LLVM33_ENABLED} else ''}"
>> GALLIUMDRIVERS_append_x86 = "${@bb.utils.contains('PACKAGECONFIG',
>> 'gallium-llvm', ',${GALLIUMDRIVERS_LLVM}', '', d)}"
>> GALLIUMDRIVERS_append_x86-64 = "${@bb.utils.contains('PACKAGECONFIG',
>> 'gallium-llvm', ',${GALLIUMDRIVERS_LLVM}', '', d)}"
>> +GALLIUMDRIVERS_append_qemux86 = ",virgl"
>> +GALLIUMDRIVERS_append_qemux86-64 = ",virgl"
>> # keep --with-gallium-drivers separate, because when only one of gallium
>> versions is enabled, other 2 were adding --without-gallium-drivers
>> PACKAGECONFIG[gallium] = "--enable-texture-float
>> --with-gallium-drivers=${GALLIUMDRIVERS}, --without-gallium-drivers"
>> MESA_LLVM_RELEASE ?= "6.0"
>> --
>> 2.7.4
>>
>> --
>> ___
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] util-linux: fix alternatives setting for switch-root
V2: Fixed typo in previous version: -ALTERNATIVE_util-linux-switch-root +ALTERNATIVE_util-linux-switch-root in keeping with the existing package name. Adding util-linux-switch-root to an image works and the dangling symlink in the sdk is also gone. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] util-linux: fix alternatives setting for switch-root
The alternative setting for switch_root belongs to the util-linux-switch-root
package instead of the util-linux package. Fix this problem to avoid
a dangling symlink:
/usr/bin/switch_root-> /usr/bin/switch_root.util-linux
on target and in the sdk.
Signed-off-by: Randy MacLeod
---
meta/recipes-core/util-linux/util-linux.inc | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/util-linux/util-linux.inc
b/meta/recipes-core/util-linux/util-linux.inc
index 60ac9c2006..3d8b3ff592 100644
--- a/meta/recipes-core/util-linux/util-linux.inc
+++ b/meta/recipes-core/util-linux/util-linux.inc
@@ -206,7 +206,7 @@ do_install_append_class-native () {
ALTERNATIVE_PRIORITY = "80"
ALTERNATIVE_${PN} = " \
-dmesg kill more mkswap blockdev pivot_root switch_root \
+dmesg kill more mkswap blockdev pivot_root \
hexdump last lastb logger mesg renice wall \
setsid chrt flock utmpdump eject nologin taskset fallocate \
fsfreeze nsenter \
@@ -218,7 +218,6 @@ ALTERNATIVE_LINK_NAME[more] = "${base_bindir}/more"
ALTERNATIVE_LINK_NAME[mkswap] = "${base_sbindir}/mkswap"
ALTERNATIVE_LINK_NAME[blockdev] = "${base_sbindir}/blockdev"
ALTERNATIVE_LINK_NAME[pivot_root] = "${base_sbindir}/pivot_root"
-ALTERNATIVE_LINK_NAME[switch_root] = "${base_sbindir}/switch_root"
ALTERNATIVE_LINK_NAME[eject] = "${bindir}/eject"
ALTERNATIVE_LINK_NAME[fallocate] = "${bindir}/fallocate"
ALTERNATIVE_LINK_NAME[fsfreeze] = "${sbindir}/fsfreeze"
@@ -294,6 +293,9 @@ ALTERNATIVE_LINK_NAME[mountpoint] =
"${base_bindir}/mountpoint"
ALTERNATIVE_util-linux-unshare = "unshare"
ALTERNATIVE_LINK_NAME[unshare] = "${bindir}/unshare"
+ALTERNATIVE_util-linux-switch-root = "switch_root"
+ALTERNATIVE_LINK_NAME[switch_root] = "${base_sbindir}/switch_root"
+
BBCLASSEXTEND = "native nativesdk"
python do_package_prepend () {
--
2.17.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] meta/classes/testimage.bbclass: Only validate IMAGE_FSTYPES when is QEMU
When use simpleremote target the flash/boot process is executed
manually, the IMAGE_FSTYPES validation is only needed when execute
testimage against qemu.
The supported_fstypes comes from oeqa.core.target.qemu module.
Signed-off-by: Aníbal Limón
---
meta/classes/testimage.bbclass | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/meta/classes/testimage.bbclass b/meta/classes/testimage.bbclass
index 2642a722e7..734cb7caae 100644
--- a/meta/classes/testimage.bbclass
+++ b/meta/classes/testimage.bbclass
@@ -194,12 +194,13 @@ def testimage_main(d):
machine = d.getVar("MACHINE")
# Get rootfs
-fstypes = [fs for fs in d.getVar('IMAGE_FSTYPES').split(' ')
- if fs in supported_fstypes]
-if not fstypes:
-bb.fatal('Unsupported image type built. Add a comptible image to '
- 'IMAGE_FSTYPES. Supported types: %s' %
- ', '.join(supported_fstypes))
+fstypes = d.getVar('IMAGE_FSTYPES')
+if d.getVar("TEST_TARGET") == "qemu":
+fstypes = [fs for fs in fstypes if fs in supported_fstypes]
+if not fstypes:
+bb.fatal('Unsupported image type built. Add a comptible image to '
+ 'IMAGE_FSTYPES. Supported types: %s' %
+ ', '.join(supported_fstypes))
rootfs = '%s.%s' % (image_name, fstypes[0])
# Get tmpdir (not really used, just for compatibility)
--
2.11.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3] rpm: handle virtual memory usage when limit is set
Fix the situation where the task do_package_write_rpm ends up in
"liblzma: memory allocation failed". This happens if the host
environment has set a limit on virtual_memory for the user with
'ulimit -v' for packages with a lot of binary packages, e.g. glibc-locale.
Signed-off-by: Peter Bergin
---
v1->v2:
- moved upstream-status to correct place
v2->v3:
- reworked the case when it is not possible to lower number of threads
to avoid endless loop
- changed upstream-status according to suggestion
- other minor updates after review comments
...-restrict-virtual-memory-usage-if-limit-s.patch | 65 ++
meta/recipes-devtools/rpm/rpm_4.14.2.bb| 1 +
2 files changed, 66 insertions(+)
create mode 100644
meta/recipes-devtools/rpm/files/0001-rpm-rpmio.c-restrict-virtual-memory-usage-if-limit-s.patch
diff --git
a/meta/recipes-devtools/rpm/files/0001-rpm-rpmio.c-restrict-virtual-memory-usage-if-limit-s.patch
b/meta/recipes-devtools/rpm/files/0001-rpm-rpmio.c-restrict-virtual-memory-usage-if-limit-s.patch
new file mode 100644
index 000..6454785
--- /dev/null
+++
b/meta/recipes-devtools/rpm/files/0001-rpm-rpmio.c-restrict-virtual-memory-usage-if-limit-s.patch
@@ -0,0 +1,65 @@
+From 0066b862bb3a09f39295abd5d972a53ac8dc1555 Mon Sep 17 00:00:00 2001
+From: Peter Bergin
+Date: Wed, 19 Sep 2018 15:12:31 +0200
+Subject: [PATCH] rpm/rpmio.c: restrict virtual memory usage if limit set
+
+A solution to avoid OOM situation when the virtual memory is restricted
+for a user (ulimit -v). As the lzopen_internal function is run in parallel
+one instance per CPU thread the available virtual memory is limited per
+CPU thread.
+
+Upstream-Status: Pending [merge of multithreading patches to upstream]
+
+Signed-off-by: Peter Bergin
+---
+ rpmio/rpmio.c | 34 ++
+ 1 file changed, 34 insertions(+)
+
+diff --git a/rpmio/rpmio.c b/rpmio/rpmio.c
+index e051c98..b3c56b6 100644
+--- a/rpmio/rpmio.c
b/rpmio/rpmio.c
+@@ -845,6 +845,40 @@ static LZFILE *lzopen_internal(const char *mode, int fd,
int xz)
+ }
+ #endif
+
++ struct rlimit virtual_memory;
++ getrlimit(RLIMIT_AS, _memory);
++ if (virtual_memory.rlim_cur != RLIM_INFINITY) {
++ const uint64_t virtual_memlimit =
virtual_memory.rlim_cur;
++ const uint64_t virtual_memlimit_per_cpu_thread =
++ virtual_memlimit / lzma_cputhreads();
++ uint64_t memory_usage_virt;
++ rpmlog(RPMLOG_NOTICE, "XZ: virtual memory restricted to
%lu and "
++ "per CPU thread %lu\n", virtual_memlimit,
virtual_memlimit_per_cpu_thread);
++ /* keep reducing the number of compression threads
until memory
++ usage falls below the limit per CPU thread*/
++ while ((memory_usage_virt =
lzma_stream_encoder_mt_memusage(_options)) >
++ virtual_memlimit_per_cpu_thread) {
++ /* If number of threads goes down to zero
lzma_stream_encoder will
++ * will return UINT64_MAX. We must check here
to avoid an infinite loop.
++ * If we get into situation that one thread
requires more virtual memory
++ * than available we set one thread, print
error message and try anyway. */
++ if (--mt_options.threads == 0) {
++ mt_options.threads = 1;
++ rpmlog(RPMLOG_WARNING,
++ "XZ: Could not adjust number of
threads to get below "
++ "virtual memory limit %lu. usage
%lu\n",
++ virtual_memlimit_per_cpu_thread,
memory_usage_virt);
++ break;
++ }
++ }
++ if (threads != (int)mt_options.threads)
++ rpmlog(RPMLOG_NOTICE,
++ "XZ: Adjusted the number of threads from
%d to %d to not "
++ "exceed the memory usage limit of %lu
bytes\n",
++ threads, mt_options.threads,
virtual_memlimit);
++
++ }
++
+ ret = lzma_stream_encoder_mt(>strm, _options);
+ }
+ #endif
+--
+2.7.4
+
diff --git a/meta/recipes-devtools/rpm/rpm_4.14.2.bb
b/meta/recipes-devtools/rpm/rpm_4.14.2.bb
index 46f8837..200fe4d 100644
--- a/meta/recipes-devtools/rpm/rpm_4.14.2.bb
+++ b/meta/recipes-devtools/rpm/rpm_4.14.2.bb
@@ -39,6 +39,7 @@ SRC_URI =
"git://github.com/rpm-software-management/rpm;branch=rpm-4.14.x \
file://0003-rpmstrpool.c-make-operations-over-string-pools-threa.patch \
[OE-core] [PATCH] libgcc/gcc-runtime: Disable thumb mode on armv6
Without this the build fails for armv6t targets due to invalid
assembler instructions in thumb mode.
[YOCTO #12929]
Signed-off-by: Richard Purdie
---
meta/recipes-devtools/gcc/gcc-runtime_8.2.bb| 2 ++
meta/recipes-devtools/gcc/libgcc-initial_8.2.bb | 3 +++
meta/recipes-devtools/gcc/libgcc_8.2.bb | 3 +++
3 files changed, 8 insertions(+)
diff --git a/meta/recipes-devtools/gcc/gcc-runtime_8.2.bb
b/meta/recipes-devtools/gcc/gcc-runtime_8.2.bb
index fe787174e8a..a1c7a76d0b1 100644
--- a/meta/recipes-devtools/gcc/gcc-runtime_8.2.bb
+++ b/meta/recipes-devtools/gcc/gcc-runtime_8.2.bb
@@ -8,3 +8,5 @@ FILES_libgomp-dev += "\
${libdir}/gcc/${TARGET_SYS}/${BINV}/include/openacc.h \
"
+# Building with thumb enabled on armv6t fails
+ARM_INSTRUCTION_SET_armv6 = "arm"
diff --git a/meta/recipes-devtools/gcc/libgcc-initial_8.2.bb
b/meta/recipes-devtools/gcc/libgcc-initial_8.2.bb
index 19f253fce85..0c698c26ec0 100644
--- a/meta/recipes-devtools/gcc/libgcc-initial_8.2.bb
+++ b/meta/recipes-devtools/gcc/libgcc-initial_8.2.bb
@@ -1,2 +1,5 @@
require recipes-devtools/gcc/gcc-${PV}.inc
require libgcc-initial.inc
+
+# Building with thumb enabled on armv6t fails
+ARM_INSTRUCTION_SET_armv6 = "arm"
diff --git a/meta/recipes-devtools/gcc/libgcc_8.2.bb
b/meta/recipes-devtools/gcc/libgcc_8.2.bb
index a5152f28e9b..ea210a11308 100644
--- a/meta/recipes-devtools/gcc/libgcc_8.2.bb
+++ b/meta/recipes-devtools/gcc/libgcc_8.2.bb
@@ -1,2 +1,5 @@
require recipes-devtools/gcc/gcc-${PV}.inc
require libgcc.inc
+
+# Building with thumb enabled on armv6t fails
+ARM_INSTRUCTION_SET_armv6 = "arm"
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] systemtap: Fix issues from 4.0 upgrade
4.0 adds systemd support but installs the unit files in the wrong location.
Fix this in do_install and inherit systemd to package them correctly.
Also fix ownership of files manually copied in to root:root to avoid QA
warnings.
Signed-off-by: Richard Purdie
---
meta/recipes-kernel/systemtap/systemtap_git.bb | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-kernel/systemtap/systemtap_git.bb
b/meta/recipes-kernel/systemtap/systemtap_git.bb
index 0b7833e901b..3c45bfa9374 100644
--- a/meta/recipes-kernel/systemtap/systemtap_git.bb
+++ b/meta/recipes-kernel/systemtap/systemtap_git.bb
@@ -25,7 +25,7 @@ PACKAGECONFIG[sqlite] =
"--enable-sqlite,--disable-sqlite,sqlite3"
PACKAGECONFIG[monitor] = "--enable-monitor,--disable-monitor,ncurses json-c"
PACKAGECONFIG[python3-probes] =
"--with-python3-probes,--without-python3-probes,python3-setuptools-native"
-inherit autotools gettext pkgconfig distutils3-base
+inherit autotools gettext pkgconfig distutils3-base systemd
do_configure_prepend () {
# Improve reproducibility for c++ object files
@@ -39,6 +39,14 @@ do_install_append () {
rm -rf ${D}${datadir}/${PN}
rm ${D}${libexecdir}/${PN}/stap-env
fi
+
+ # Fix makefile hardcoded path assumptions for systemd (assumes $prefix)
+ install -d `dirname ${D}${systemd_unitdir}`
+ mv ${D}${prefix}/lib/systemd `dirname ${D}${systemd_unitdir}`
+ rmdir ${D}${prefix}/lib --ignore-fail-on-non-empty
+
+ # Ensure correct ownership for files copied in
+ chown root.root ${D}${sysconfdir}/stap-exporter/* -R
}
BBCLASSEXTEND = "nativesdk"
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Yocto Project Status WW42’18
Current Dev Position: YP 2.6 M4. Next Deadline: YP 2.6 M4 Build Target was Oct. 1, 2018 SWAT Team Rotation: · SWAT lead is currently: Ross · SWAT team rotation: Ross -> Amanda on Oct. 17, 2018 · SWAT team rotation: Amanda -> Tracy on Oct. 24, 2018 · https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team Key Status/Updates: · YP 2.6 M3 rc1 has completed QA and should be published today. · The release of M3 is reluctant since there are a number of open bugs, a number of ptest regressions and some questions about build performance regressions. · A number of good ptest fixes have already merged and we’re hoping to rerun those tests to check the status before we build M4. · “Manual” QA test definitions merged into oeqa which means all testcases are now documented in our metadata and this is definitive now rather than testopia. · With upcoming changes to Yocto Project QA, its desirable to have better test result reporting merged into the codebase, particularly for the stable release process in the future. Unfortunately these patches aren’t quite ready to merge yet but it's probably better to hold the release until they’re ready. · Since M3 is now being released we will create the thud branches this week in preparation for the main 2.6 release. · The project provided a response to the automated testing survey recently carried out, the response can be viewed at https://elinux.org/Yocto_project_survey_response and gives a good overview of the different kinds of testing the project performs. · There is a recently found bug in “_remove” operator handling which may mean changes to its documented behaviour in order to address the issues found (remove operations aren’t reflected in sstate hashes currently). · It was discovered that the new autobuilder wasn’t testing the ipk/deb packaging backends so this was fixed and some issues with the test cases was also resolved. Planned Releases for YP 2.6: · YP 2.6 M4 Build Target is Oct. 1, 2018 · YP 2.6 M4 Release Target is Oct. 26, 2018 Planned upcoming dot releases: · YP 2.4.4 (Rocko) will be targeted after YP 2.6 M4 is done. · YP 2.5.2 (Sumo) will be targeted after YP 2.4.4 is done. Tracking Metrics: · WDD 2462 (last week 2527) (https://wiki.yoctoproject.org/charts/combo.html) · Poky Patch Metrics oTotal patches found: 1682 (last week 1665) oPercentage of patches in the Pending State: 736 (44%) [last week 735 (44%)] Key Status Links for YP: https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.6_Status https://wiki.yoctoproject.org/wiki/Yocto_2.6_Schedule https://wiki.yoctoproject.org/wiki/Yocto_2.6_Features The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status [If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!] Thanks, Stephen K. Jolley Yocto Project Program Manager INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124 •Cell:(208) 244-4460 • Email: stephen.k.jol...@intel.com -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] rootfs: possibility to add packages to debug rootfs
Static libraries are not included in rootfs, it means, that sources are
not going into debug rootfs. This option enables to install additional
packages even if the standard package is not installed.
Signed-off-by: Andrej Valek
---
meta/classes/image.bbclass | 4 +++-
meta/classes/populate_sdk_base.bbclass | 2 +-
meta/lib/oe/package_manager.py | 11 +++
meta/lib/oe/rootfs.py | 3 +++
4 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 34fdbb0850..452b1ad391 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -38,6 +38,8 @@ IMAGE_FEATURES[validitems] += "debug-tweaks read-only-rootfs
empty-root-password
# Generate companion debugfs?
IMAGE_GEN_DEBUGFS ?= "0"
+# These pacackages will be installed as additional into debug rootfs
+IMAGE_INSTALL_DEBUGFS ?= ""
# These packages will be removed from a read-only rootfs after all other
# packages have been installed
@@ -125,7 +127,7 @@ def rootfs_variables(d):
'IMAGE_ROOTFS_MAXSIZE','IMAGE_NAME','IMAGE_LINK_NAME','IMAGE_MANIFEST','DEPLOY_DIR_IMAGE','IMAGE_FSTYPES','IMAGE_INSTALL_COMPLEMENTARY','IMAGE_LINGUAS',
'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_ARCH','TARGET_OS','OVERRIDES','BBEXTENDVARIANT','FEED_DEPLOYDIR_BASE_URI','INTERCEPT_DIR','USE_DEVFS',
- 'CONVERSIONTYPES', 'IMAGE_GEN_DEBUGFS', 'ROOTFS_RO_UNNEEDED',
'IMGDEPLOYDIR', 'PACKAGE_EXCLUDE_COMPLEMENTARY',
'REPRODUCIBLE_TIMESTAMP_ROOTFS']
+ 'CONVERSIONTYPES', 'IMAGE_GEN_DEBUGFS', 'ROOTFS_RO_UNNEEDED',
'IMGDEPLOYDIR', 'PACKAGE_EXCLUDE_COMPLEMENTARY',
'REPRODUCIBLE_TIMESTAMP_ROOTFS', 'IMAGE_INSTALL_DEBUGFS']
variables.extend(rootfs_command_variables(d))
variables.extend(variable_depends(d))
return " ".join(variables)
diff --git a/meta/classes/populate_sdk_base.bbclass
b/meta/classes/populate_sdk_base.bbclass
index d9a391c613..677ba3cf12 100644
--- a/meta/classes/populate_sdk_base.bbclass
+++ b/meta/classes/populate_sdk_base.bbclass
@@ -296,7 +296,7 @@ def sdk_command_variables(d):
def sdk_variables(d):
variables =
['BUILD_IMAGES_FROM_FEEDS','SDK_OS','SDK_OUTPUT','SDKPATHNATIVE','SDKTARGETSYSROOT','SDK_DIR','SDK_VENDOR','SDKIMAGE_INSTALL_COMPLEMENTARY','SDK_PACKAGE_ARCHS','SDK_OUTPUT',
'SDKTARGETSYSROOT','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','BBEXTENDVARIANT','FEED_DEPLOYDIR_BASE_URI',
'PACKAGE_EXCLUDE_COMPLEMENTARY']
+
'PACKAGE_CLASSES','TARGET_VENDOR','TARGET_VENDOR','TARGET_ARCH','TARGET_OS','BBEXTENDVARIANT','FEED_DEPLOYDIR_BASE_URI',
'PACKAGE_EXCLUDE_COMPLEMENTARY', 'IMAGE_INSTALL_DEBUGFS']
variables.extend(sdk_command_variables(d))
return " ".join(variables)
diff --git a/meta/lib/oe/package_manager.py b/meta/lib/oe/package_manager.py
index 8f4b42b0da..1316a284e7 100644
--- a/meta/lib/oe/package_manager.py
+++ b/meta/lib/oe/package_manager.py
@@ -594,6 +594,17 @@ class PackageManager(object, metaclass=ABCMeta):
# And now delete the binary locales
self.remove(fnmatch.filter(self.list_installed(),
"glibc-binary-localedata-*"), False)
+def install_additional(self):
+"""
+Install additional packages. Possibility to install additional
packages,
+which are not automatically installed via complementary packages of
+standard one, e.g. debug packages of static library
+"""
+additional_pkgs = self.d.getVar('IMAGE_INSTALL_DEBUGFS')
+if additional_pkgs:
+bb.note("Installing additional packages ...")
+self.install(additional_pkgs.split(), attempt_only=True)
+
def deploy_dir_lock(self):
if self.deploy_dir is None:
raise RuntimeError("deploy_dir is not set!")
diff --git a/meta/lib/oe/rootfs.py b/meta/lib/oe/rootfs.py
index ddda552263..bf3d4bcf38 100644
--- a/meta/lib/oe/rootfs.py
+++ b/meta/lib/oe/rootfs.py
@@ -148,6 +148,9 @@ class Rootfs(object, metaclass=ABCMeta):
bb.note(" Install complementary '*-src' packages...")
self.pm.install_complementary('*-src')
+bb.note(" Install additional packages...")
+self.pm.install_additional()
+
bb.note(" Rename debug rootfs...")
try:
shutil.rmtree(self.image_rootfs + '-dbg')
--
2.11.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
Re: [OE-core] [PATCH] boost.inc: make libboost_python3.so available
On Tue, 16 Oct 2018 at 12:18, Burton, Ross wrote: > OpenCV has a patch to "fix" (bodge) the Py2 build: > > https://github.com/ros-perception/vision_opencv/pull/239 > > But this doesn't work for Py3. This was just pushed: https://github.com/ros-perception/vision_opencv/commit/b57fd5b Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] freetype: remove compile of windows resource files
On Tue, 16 Oct 2018 at 04:36, Changqing Li wrote: > do_compile failed with below error: > x86_64-wrs-linux-libtool: compile: x86_64-wrs-linux-windres > --include-dir=work/corei7-64-wrs-linux/freetype/2.9.1-r0/recipe-sysroot/usr/include > /work/corei7-64-wrs-linux/freetype/2.9.1-r0/freetype-2.9.1/src/base/ftver.rc > -o work/corei7-64-wrs-linux/freetype/2.9.1-r0/build/.libs/ftver.o > work/corei7-64-wrs-linux/freetype/2.9.1-r0/build//x86_64-wrs-linux-libtool: > line 1752: x86_64-wrs-linux-windres: command not found > work/corei7-64-wrs-linux/freetype/2.9.1-r0/freetype-2.9.1/builds/freetype.mk:263: > recipe for target > 'work/corei7-64-wrs-linux/freetype/2.9.1-r0/build/ftver.lo' failed > make: *** [work/corei7-64-wrs-linux/freetype/2.9.1-r0/build/ftver.lo] > Error 1 > ERROR: oe_runmake failed Right, so I'd say a better fix would be in meta-mingw to stop RC being exported in target builds. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] boost.inc: make libboost_python3.so available
Right. This was a change in Boost 1.67 onwards: https://github.com/boostorg/python/commit/d4d41d94aecc9f8098aabd3587fcb95458451f71#diff-42dd6ec1330a7c47aaccf2ab2b8f1e02 OpenCV has a patch to "fix" (bodge) the Py2 build: https://github.com/ros-perception/vision_opencv/pull/239 But this doesn't work for Py3. Boost and CMake consider this change correct and the documentation for the cmake/boost integration reflects this: https://gitlab.kitware.com/cmake/cmake/blob/master/Modules/FindBoost.cmake#L43 So the worst-case fix is to patch opencv to look for "python35" instead of "python3", although this will break when we upgrade to Python 3. A better solution would be to upstream a patch that uses the Python version to generate the correct name. Ross On Tue, 16 Oct 2018 at 11:38, Burton, Ross wrote: > > On Tue, 16 Oct 2018 at 11:01, wrote: > > I'm a little worried about why we're having to create these links when > > other software seems able to expect these things by default. Is this > > some standard packaging most distros do? I'm a little worried we're > > creating an ABI here which doesn't exist... > > https://koji.fedoraproject.org/koji/rpminfo?rpmID=14904908 says that > Fedora's boost-python3 package contains just > /usr/lib64/libboost_python3.so.1.66.0. Their spec file at > https://src.fedoraproject.org/rpms/boost/blob/master/f/boost.spec is > hairy (as one expects for Boost) but doesn't appear to rename the > file. > > So the question is why does our build produce libboost_python35.so? > > Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] boost.inc: make libboost_python3.so available
On Tue, 16 Oct 2018 at 11:01, wrote: > I'm a little worried about why we're having to create these links when > other software seems able to expect these things by default. Is this > some standard packaging most distros do? I'm a little worried we're > creating an ABI here which doesn't exist... https://koji.fedoraproject.org/koji/rpminfo?rpmID=14904908 says that Fedora's boost-python3 package contains just /usr/lib64/libboost_python3.so.1.66.0. Their spec file at https://src.fedoraproject.org/rpms/boost/blob/master/f/boost.spec is hairy (as one expects for Boost) but doesn't appear to rename the file. So the question is why does our build produce libboost_python35.so? Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] boost.inc: make libboost_python3.so available
On Tue, 2018-10-16 at 02:00 -0700, mingli...@windriver.com wrote:
> From: Mingli Yu
>
> Currently boost provides ${libdir}/libboost_python35.so,
> but there is some logic as below in CMakeLists.txt
> of package cv-bridge under meta-ros layer.
> [snip]
> if(PYTHONLIBS_VERSION_STRING VERSION_LESS 3)
> find_package(Boost REQUIRED python)
> else()
> find_package(Boost REQUIRED python3)
> endif()
> [snip]
>
> And comes below do_configure error for cv-bridge:
> meta-ros/recipes-ros/vision-opencv/cv-bridge_1.11.16.bb:do_configure
> > CMake Error at $Prj/cv-bridge/1.11.16-r0/recipe-sysroot-
> > native/usr/share/cmake-3.12/Modules/FindBoost.cmake:2048 (message):
> > Unable to find the requested Boost libraries.
> >
> > Boost version: 1.68.0
> >
> > Boost include path:
> > $Prj/cv-bridge/1.11.16-r0/recipe-sysroot/usr/include
> >
> >
> > Could not find the following Boost libraries:
> >
> > boost_python3
> >
> > No Boost libraries were found. You may need to set
> > BOOST_LIBRARYDIR to the
> > directory containing Boost libraries or BOOST_ROOT to the
> > location of
> > Boost.
> > Call Stack (most recent call first):
> > CMakeLists.txt:11 (find_package)
>
> Can update CMakeLists.txt of cv-bridge as below
> to remove the configure error:
> - find_package(Boost REQUIRED python3)
> + find_package(Boost REQUIRED python35)
>
> But once the python version changes such as
> python37, it fails again. So make boost provides
> libboost_python3.so to make the fix flexibly.
>
> [YOCTO #12833]
>
> Signed-off-by: Mingli Yu
> ---
> meta/recipes-support/boost/boost.inc | 4
> 1 file changed, 4 insertions(+)
I'm a little worried about why we're having to create these links when
other software seems able to expect these things by default. Is this
some standard packaging most distros do? I'm a little worried we're
creating an ABI here which doesn't exist...
Put another way, why doesn't upstream create this link if its expected
to work?
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] systemtap: 3.3 -> 4.0
On Tue, 2018-10-16 at 10:27 +0100, Burton, Ross wrote: > On Mon, 15 Oct 2018 at 19:22, Victor Kamensky > wrote: > > Upgrade systemtap from 3.3 to 4.0: Removed backported patch. > > WARNING: systemtap-4.0-r0 do_package_qa: QA Issue: systemtap: > /systemtap/etc/stap-exporter/EXAMPLE is owned by uid 1000, which is > the same as the user running bitbake. This may be due to host > contamination > systemtap: /systemtap/etc/stap-exporter/EXAMPLE_NOERROR is owned by > uid 1000, which is the same as the user running bitbake. This may be > due to host contamination > systemtap: /systemtap/etc/stap-exporter/errno.stp is owned by uid > 1000, which is the same as the user running bitbake. This may be due > to host contamination > systemtap: /systemtap/etc/stap-exporter/syscalllatency.stp is owned > by > uid 1000, which is the same as the user running bitbake. This may be > due to host contamination > systemtap: /systemtap/etc/stap-exporter/timeout.stp is owned by uid > 1000, which is the same as the user running bitbake. This may be due > to host contamination > systemtap: /systemtap/etc/stap-exporter/topsys.stp is owned by uid > 1000, which is the same as the user running bitbake. This may be due > to host contamination [host-user-contaminated] There are also other issues from the addition of systemd unit files in 4.0. I've a patch in -next which tweaks both issues which I'll put in for testing. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] systemtap: 3.3 -> 4.0
On Mon, 15 Oct 2018 at 19:22, Victor Kamensky wrote: > Upgrade systemtap from 3.3 to 4.0: Removed backported patch. WARNING: systemtap-4.0-r0 do_package_qa: QA Issue: systemtap: /systemtap/etc/stap-exporter/EXAMPLE is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination systemtap: /systemtap/etc/stap-exporter/EXAMPLE_NOERROR is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination systemtap: /systemtap/etc/stap-exporter/errno.stp is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination systemtap: /systemtap/etc/stap-exporter/syscalllatency.stp is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination systemtap: /systemtap/etc/stap-exporter/timeout.stp is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination systemtap: /systemtap/etc/stap-exporter/topsys.stp is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated] -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] wic: search nonarch STAGING_DATADIR for multilib
From: Kai Kang Build lib32-core-image-minimal with wic successfully by following config: MACHINE = "qemux86-64" require conf/multilib.conf MULTILIBS = "multilib:lib32" DEFAULTTUNE_virtclass-multilib-lib32 = "x86" IMAGE_FSTYPES = "wic" The following changes since commit b02f3bfe2fee291a9db85094e5f31b1933acf871: local.conf.sample.extended: add another warning to comment about GLIBC_GENERATE_LOCALES (2018-10-14 23:45:40 +0100) are available in the Git repository at: git://git.pokylinux.org/poky-contrib kangkai/wic http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=kangkai/wic Kai Kang (1): wic: search nonarch STAGING_DATADIR for multilib scripts/lib/wic/plugins/source/bootimg-pcbios.py | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) -- 2.18.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] wic: search nonarch STAGING_DATADIR for multilib
From: Kai Kang
It fails to build multilib image such as lib32-core-image-minimal with
wic by set 'IMAGE_FSTYPES = "wic"':
| ERROR: Couldn't find correct bootimg_dir, exiting
When multilib is enabled, STAGING_DATADIR is expanded with MLPREFIX. But
dependencies of images such as syslinux is still populated to nonarch
STAGING_DATADIR.
Search nonarch STAGING_DATADIR to fix the error.
Signed-off-by: Kai Kang
---
scripts/lib/wic/plugins/source/bootimg-pcbios.py | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/scripts/lib/wic/plugins/source/bootimg-pcbios.py
b/scripts/lib/wic/plugins/source/bootimg-pcbios.py
index d599112dd7..9347aa7fcb 100644
--- a/scripts/lib/wic/plugins/source/bootimg-pcbios.py
+++ b/scripts/lib/wic/plugins/source/bootimg-pcbios.py
@@ -26,6 +26,7 @@
import logging
import os
+import re
from wic import WicError
from wic.engine import get_custom_config
@@ -47,10 +48,17 @@ class BootimgPcbiosPlugin(SourcePlugin):
"""
Check if dirname exists in default bootimg_dir or in STAGING_DIR.
"""
-for result in (bootimg_dir, get_bitbake_var("STAGING_DATADIR")):
+staging_datadir = get_bitbake_var("STAGING_DATADIR")
+for result in (bootimg_dir, staging_datadir):
if os.path.exists("%s/%s" % (result, dirname)):
return result
+# STAGING_DATADIR is expanded with MLPREFIX if multilib is enabled
+# but dependency syslinux is still populated to original
STAGING_DATADIR
+nonarch_datadir = re.sub('/[^/]*recipe-sysroot', '/recipe-sysroot',
staging_datadir)
+if os.path.exists(os.path.join(nonarch_datadir, dirname)):
+return nonarch_datadir
+
raise WicError("Couldn't find correct bootimg_dir, exiting")
@classmethod
--
2.18.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] boost.inc: make libboost_python3.so available
From: Mingli Yu
Currently boost provides ${libdir}/libboost_python35.so,
but there is some logic as below in CMakeLists.txt
of package cv-bridge under meta-ros layer.
[snip]
if(PYTHONLIBS_VERSION_STRING VERSION_LESS 3)
find_package(Boost REQUIRED python)
else()
find_package(Boost REQUIRED python3)
endif()
[snip]
And comes below do_configure error for cv-bridge:
meta-ros/recipes-ros/vision-opencv/cv-bridge_1.11.16.bb:do_configure
| CMake Error at
$Prj/cv-bridge/1.11.16-r0/recipe-sysroot-native/usr/share/cmake-3.12/Modules/FindBoost.cmake:2048
(message):
| Unable to find the requested Boost libraries.
|
| Boost version: 1.68.0
|
| Boost include path:
| $Prj/cv-bridge/1.11.16-r0/recipe-sysroot/usr/include
|
|
| Could not find the following Boost libraries:
|
| boost_python3
|
| No Boost libraries were found. You may need to set BOOST_LIBRARYDIR to the
| directory containing Boost libraries or BOOST_ROOT to the location of
| Boost.
| Call Stack (most recent call first):
| CMakeLists.txt:11 (find_package)
Can update CMakeLists.txt of cv-bridge as below
to remove the configure error:
- find_package(Boost REQUIRED python3)
+ find_package(Boost REQUIRED python35)
But once the python version changes such as
python37, it fails again. So make boost provides
libboost_python3.so to make the fix flexibly.
[YOCTO #12833]
Signed-off-by: Mingli Yu
---
meta/recipes-support/boost/boost.inc | 4
1 file changed, 4 insertions(+)
diff --git a/meta/recipes-support/boost/boost.inc
b/meta/recipes-support/boost/boost.inc
index c4faea211f0..98f0b71d73a 100644
--- a/meta/recipes-support/boost/boost.inc
+++ b/meta/recipes-support/boost/boost.inc
@@ -198,6 +198,10 @@ do_install() {
ln -s libboost_${lib}.so
${D}${libdir}/libboost_${lib}-mt.so
fi
done
+ if [ -e ${D}${libdir}/libboost_python3[0-9].so ] && [ ! -e
${D}${libdir}/libboost_python3.so ]; then
+ lib_python3_so=$(basename `ls
${D}${libdir}/libboost_python3[0-9].so`)
+ ln -s ${lib_python3_so} ${D}${libdir}/libboost_python3.so
+ fi
}
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] ✗ patchtest: failure for gobject-introspection.bbclass: fix gir installed but not shipped in any package while multilib enabled
== Series Details == Series: gobject-introspection.bbclass: fix gir installed but not shipped in any package while multilib enabled Revision: 1 URL : https://patchwork.openembedded.org/series/14549/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been executed on the proposed series by patchtest resulting in the following failures: * Patchgobject-introspection.bbclass: fix gir installed but not shipped in any package while multilib enabled Issue Commit shortlog is too long [test_shortlog_length] Suggested fixEdit shortlog so that it is 90 characters or less (currently 102 characters) If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core@lists.openembedded.org) raising your concerns. Otherwise we would appreciate you correcting the issues and submitting a new version of the patchset if applicable. Please ensure you add/increment the version number when sending the new version (i.e. [PATCH] -> [PATCH v2] -> [PATCH v3] -> ...). --- Guidelines: https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] binutils: fix three CVE issues
Backport the CVE patches from the upstream:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;
h=30838132997e6a3cfe3ec11c58b32b22f6f6b102
h=cf93e9c2cf8f8b2566f8fc86e961592b51b5980d
[BZ 23686] https://sourceware.org/bugzilla/show_bug.cgi?id=23686
[BZ 23685] https://sourceware.org/bugzilla/show_bug.cgi?id=23685
The one is for CVE-2018-17358 and CVE-2018-17359, and the another
is for CVE-2018-17360.
Signed-off-by: Zhixiong Chi
---
.../binutils/binutils-2.31.inc| 2 +
.../binutils/binutils/CVE-2018-17358.patch| 144 ++
.../binutils/binutils/CVE-2018-17360.patch| 65
3 files changed, 211 insertions(+)
create mode 100644 meta/recipes-devtools/binutils/binutils/CVE-2018-17358.patch
create mode 100644 meta/recipes-devtools/binutils/binutils/CVE-2018-17360.patch
diff --git a/meta/recipes-devtools/binutils/binutils-2.31.inc
b/meta/recipes-devtools/binutils/binutils-2.31.inc
index 76add0fe4b..27a643d765 100644
--- a/meta/recipes-devtools/binutils/binutils-2.31.inc
+++ b/meta/recipes-devtools/binutils/binutils-2.31.inc
@@ -41,6 +41,8 @@ SRC_URI = "\
file://0019-Improved-robustness.-Return-FALSE-in-case-of-NULL-po.patch \
file://0020-Make-sure-global-symbol-is-not-an-indirect-or-warnin.patch \
file://0021-PLT-information-was-still-being-generated-when-symbo.patch \
+ file://CVE-2018-17358.patch \
+ file://CVE-2018-17360.patch \
"
S = "${WORKDIR}/git"
diff --git a/meta/recipes-devtools/binutils/binutils/CVE-2018-17358.patch
b/meta/recipes-devtools/binutils/binutils/CVE-2018-17358.patch
new file mode 100644
index 00..813509160f
--- /dev/null
+++ b/meta/recipes-devtools/binutils/binutils/CVE-2018-17358.patch
@@ -0,0 +1,144 @@
+From 30838132997e6a3cfe3ec11c58b32b22f6f6b102 Mon Sep 17 00:00:00 2001
+From: Alan Modra
+Date: Thu, 20 Sep 2018 15:29:17 +0930
+Subject: [PATCH] Bug 23686, two segment faults in nm
+
+Fixes the bugs exposed by the testcases in the PR, plus two more bugs
+I noticed when looking at _bfd_stab_section_find_nearest_line.
+
+ PR 23686
+ * dwarf2.c (read_section): Error when attempting to malloc
+ "(bfd_size_type) -1".
+ * syms.c (_bfd_stab_section_find_nearest_line): Bounds check
+ function_name. Bounds check reloc address. Formatting. Ensure
+ .stabstr zero terminated.
+CVE: CVE-2018-17358 and CVE-2018-17359
+Upstream-Status: Backport
+Signed-off-by: Zhixiong Chi
+---
+ bfd/ChangeLog | 9 +
+ bfd/dwarf2.c | 9 -
+ bfd/syms.c| 22 --
+ 3 files changed, 33 insertions(+), 7 deletions(-)
+
+diff --git a/bfd/ChangeLog b/bfd/ChangeLog
+index 04c0c2a..fef5479 100644
+--- a/bfd/ChangeLog
b/bfd/ChangeLog
+@@ -1,3 +1,12 @@
++2018-09-20 Alan Modra
++
++ PR 23686
++ * dwarf2.c (read_section): Error when attempting to malloc
++ "(bfd_size_type) -1".
++ * syms.c (_bfd_stab_section_find_nearest_line): Bounds check
++ function_name. Bounds check reloc address. Formatting. Ensure
++ .stabstr zero terminated.
++
+ 2018-08-12 H.J. Lu
+
+ PR ld/23428
+diff --git a/bfd/dwarf2.c b/bfd/dwarf2.c
+index 3b28855..77a7368 100644
+--- a/bfd/dwarf2.c
b/bfd/dwarf2.c
+@@ -527,6 +527,7 @@ read_section (bfd * abfd,
+ asection *msec;
+ const char *section_name = sec->uncompressed_name;
+ bfd_byte *contents = *section_buffer;
++ bfd_size_type amt;
+
+ /* The section may have already been read. */
+ if (contents == NULL)
+@@ -549,7 +550,13 @@ read_section (bfd * abfd,
+ *section_size = msec->rawsize ? msec->rawsize : msec->size;
+ /* Paranoia - alloc one extra so that we can make sure a string
+section is NUL terminated. */
+- contents = (bfd_byte *) bfd_malloc (*section_size + 1);
++ amt = *section_size + 1;
++ if (amt == 0)
++ {
++bfd_set_error (bfd_error_no_memory);
++return FALSE;
++ }
++ contents = (bfd_byte *) bfd_malloc (amt);
+ if (contents == NULL)
+ return FALSE;
+ if (syms
+diff --git a/bfd/syms.c b/bfd/syms.c
+index 187071f..e09640a 100644
+--- a/bfd/syms.c
b/bfd/syms.c
+@@ -1035,6 +1035,10 @@ _bfd_stab_section_find_nearest_line (bfd *abfd,
+0, strsize))
+ return FALSE;
+
++ /* Stab strings ought to be nul terminated. Ensure the last one
++ is, to prevent running off the end of the buffer. */
++ info->strs[strsize - 1] = 0;
++
+ /* If this is a relocatable object file, we have to relocate
+the entries in .stab. This should always be simple 32 bit
+relocations against symbols defined in this object file, so
+@@ -1073,7 +1077,8 @@ _bfd_stab_section_find_nearest_line (bfd *abfd,
+ || r->howto->bitsize != 32
+ || r->howto->pc_relative
+ || r->howto->bitpos != 0
+-|| r->howto->dst_mask != 0x)
++
[OE-core] [PATCH] gobject-introspection.bbclass: fix gir installed but not shipped in any package while multilib enabled
Since commit [9524330 gobject-introspection: fix multilib install
file conflicts] applied in oe-core, while multilib enabled, gir
files will be installed to `${libdir}'.
Refer above commit, modify gobject-introspection.bbclass to
split gir to package correctly.
Signed-off-by: Hongxu Jia
---
meta/classes/gobject-introspection.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/gobject-introspection.bbclass
b/meta/classes/gobject-introspection.bbclass
index b6160b8..a323c1f 100644
--- a/meta/classes/gobject-introspection.bbclass
+++ b/meta/classes/gobject-introspection.bbclass
@@ -40,4 +40,4 @@ FILES_${PN}_append = " ${libdir}/girepository-*/*.typelib"
# .gir files go to dev package, as they're needed for developing (but not for
# running) things that depends on introspection.
-FILES_${PN}-dev_append = " ${datadir}/gir-*/*.gir"
+FILES_${PN}-dev_append = " ${datadir}/gir-*/*.gir ${libdir}/gir-*/*.gir"
--
2.10.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] ✗ patchtest: failure for binutils: fix three CVE issues
== Series Details == Series: binutils: fix three CVE issues Revision: 1 URL : https://patchwork.openembedded.org/series/14548/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been executed on the proposed series by patchtest resulting in the following failures: * Issue Series does not apply on top of target branch [test_series_merge_on_head] Suggested fixRebase your series on top of targeted branch Targeted branch master (currently at e2fa6bc137) If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core@lists.openembedded.org) raising your concerns. Otherwise we would appreciate you correcting the issues and submitting a new version of the patchset if applicable. Please ensure you add/increment the version number when sending the new version (i.e. [PATCH] -> [PATCH v2] -> [PATCH v3] -> ...). --- Guidelines: https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] binutils: fix three CVE issues
Backport the CVE patches from the upstream:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;
h=30838132997e6a3cfe3ec11c58b32b22f6f6b102
h=cf93e9c2cf8f8b2566f8fc86e961592b51b5980d
[BZ 23686] https://sourceware.org/bugzilla/show_bug.cgi?id=23686
[BZ 23685] https://sourceware.org/bugzilla/show_bug.cgi?id=23685
The one is for CVE-2018-17358 and CVE-2018-17359, and the another
is for CVE-2018-17360.
Signed-off-by: Zhixiong Chi
---
.../binutils/binutils-2.31.inc| 2 +
.../binutils/binutils/CVE-2018-17358.patch| 144 ++
.../binutils/binutils/CVE-2018-17360.patch| 65
3 files changed, 211 insertions(+)
create mode 100644 meta/recipes-devtools/binutils/binutils/CVE-2018-17358.patch
create mode 100644 meta/recipes-devtools/binutils/binutils/CVE-2018-17360.patch
diff --git a/meta/recipes-devtools/binutils/binutils-2.31.inc
b/meta/recipes-devtools/binutils/binutils-2.31.inc
index bc951d73e4..7d9dc56ab7 100644
--- a/meta/recipes-devtools/binutils/binutils-2.31.inc
+++ b/meta/recipes-devtools/binutils/binutils-2.31.inc
@@ -37,6 +37,8 @@ SRC_URI = "\
file://0015-sync-with-OE-libtool-changes.patch \
file://0016-add-i386pep-emulation-for-x86_64.patch \
file://0017-improve-check-for-input-file-matching-output-file.patch \
+ file://CVE-2018-17358.patch \
+ file://CVE-2018-17360.patch \
"
S = "${WORKDIR}/git"
diff --git a/meta/recipes-devtools/binutils/binutils/CVE-2018-17358.patch
b/meta/recipes-devtools/binutils/binutils/CVE-2018-17358.patch
new file mode 100644
index 00..813509160f
--- /dev/null
+++ b/meta/recipes-devtools/binutils/binutils/CVE-2018-17358.patch
@@ -0,0 +1,144 @@
+From 30838132997e6a3cfe3ec11c58b32b22f6f6b102 Mon Sep 17 00:00:00 2001
+From: Alan Modra
+Date: Thu, 20 Sep 2018 15:29:17 +0930
+Subject: [PATCH] Bug 23686, two segment faults in nm
+
+Fixes the bugs exposed by the testcases in the PR, plus two more bugs
+I noticed when looking at _bfd_stab_section_find_nearest_line.
+
+ PR 23686
+ * dwarf2.c (read_section): Error when attempting to malloc
+ "(bfd_size_type) -1".
+ * syms.c (_bfd_stab_section_find_nearest_line): Bounds check
+ function_name. Bounds check reloc address. Formatting. Ensure
+ .stabstr zero terminated.
+CVE: CVE-2018-17358 and CVE-2018-17359
+Upstream-Status: Backport
+Signed-off-by: Zhixiong Chi
+---
+ bfd/ChangeLog | 9 +
+ bfd/dwarf2.c | 9 -
+ bfd/syms.c| 22 --
+ 3 files changed, 33 insertions(+), 7 deletions(-)
+
+diff --git a/bfd/ChangeLog b/bfd/ChangeLog
+index 04c0c2a..fef5479 100644
+--- a/bfd/ChangeLog
b/bfd/ChangeLog
+@@ -1,3 +1,12 @@
++2018-09-20 Alan Modra
++
++ PR 23686
++ * dwarf2.c (read_section): Error when attempting to malloc
++ "(bfd_size_type) -1".
++ * syms.c (_bfd_stab_section_find_nearest_line): Bounds check
++ function_name. Bounds check reloc address. Formatting. Ensure
++ .stabstr zero terminated.
++
+ 2018-08-12 H.J. Lu
+
+ PR ld/23428
+diff --git a/bfd/dwarf2.c b/bfd/dwarf2.c
+index 3b28855..77a7368 100644
+--- a/bfd/dwarf2.c
b/bfd/dwarf2.c
+@@ -527,6 +527,7 @@ read_section (bfd * abfd,
+ asection *msec;
+ const char *section_name = sec->uncompressed_name;
+ bfd_byte *contents = *section_buffer;
++ bfd_size_type amt;
+
+ /* The section may have already been read. */
+ if (contents == NULL)
+@@ -549,7 +550,13 @@ read_section (bfd * abfd,
+ *section_size = msec->rawsize ? msec->rawsize : msec->size;
+ /* Paranoia - alloc one extra so that we can make sure a string
+section is NUL terminated. */
+- contents = (bfd_byte *) bfd_malloc (*section_size + 1);
++ amt = *section_size + 1;
++ if (amt == 0)
++ {
++bfd_set_error (bfd_error_no_memory);
++return FALSE;
++ }
++ contents = (bfd_byte *) bfd_malloc (amt);
+ if (contents == NULL)
+ return FALSE;
+ if (syms
+diff --git a/bfd/syms.c b/bfd/syms.c
+index 187071f..e09640a 100644
+--- a/bfd/syms.c
b/bfd/syms.c
+@@ -1035,6 +1035,10 @@ _bfd_stab_section_find_nearest_line (bfd *abfd,
+0, strsize))
+ return FALSE;
+
++ /* Stab strings ought to be nul terminated. Ensure the last one
++ is, to prevent running off the end of the buffer. */
++ info->strs[strsize - 1] = 0;
++
+ /* If this is a relocatable object file, we have to relocate
+the entries in .stab. This should always be simple 32 bit
+relocations against symbols defined in this object file, so
+@@ -1073,7 +1077,8 @@ _bfd_stab_section_find_nearest_line (bfd *abfd,
+ || r->howto->bitsize != 32
+ || r->howto->pc_relative
+ || r->howto->bitpos != 0
+-|| r->howto->dst_mask != 0x)
++|| r->howto->dst_mask != 0x
++
