From raj.khem at gmail.com Sun Mar 1 01:42:58 2020 From: raj.khem at gmail.com (Khem Raj) Date: Sat, 29 Feb 2020 17:42:58 -0800 Subject: [OE-core] [PATCH 0/3] Fix host contamination QA errors Message-ID: <20200301014301.805156-1-raj.khem@gmail.com> These patches fix host-user-contaminated QA issues Khem Raj (3): dbus-test: Fix QA host-contamination errors strace: Fix host contamination QA errors boost: Fix host-user-contaminated QA errors meta/recipes-core/dbus/dbus-test_1.12.16.bb | 4 +-- .../strace/0001-Evaluate-AC_PROG_LN_S.patch | 29 +++++++++++++++++++ meta/recipes-devtools/strace/strace_5.5.bb | 1 + meta/recipes-support/boost/boost.inc | 1 + 4 files changed, 33 insertions(+), 2 deletions(-) create mode 100644 meta/recipes-devtools/strace/strace/0001-Evaluate-AC_PROG_LN_S.patch -- 2.25.1 From raj.khem at gmail.com Sun Mar 1 01:42:59 2020 From: raj.khem at gmail.com (Khem Raj) Date: Sat, 29 Feb 2020 17:42:59 -0800 Subject: [OE-core] [PATCH 1/3] dbus-test: Fix QA host-contamination errors In-Reply-To: <20200301014301.805156-1-raj.khem@gmail.com> References: <20200301014301.805156-1-raj.khem@gmail.com> Message-ID: <20200301014301.805156-2-raj.khem@gmail.com> Errors like below are fixed bus/connection.h is owned by uid 1000, which is the same as t he user running bitbake. This may be due to host contamination Signed-off-by: Khem Raj --- meta/recipes-core/dbus/dbus-test_1.12.16.bb | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/recipes-core/dbus/dbus-test_1.12.16.bb b/meta/recipes-core/dbus/dbus-test_1.12.16.bb index bea0e74ed0..91e2ba69d2 100644 --- a/meta/recipes-core/dbus/dbus-test_1.12.16.bb +++ b/meta/recipes-core/dbus/dbus-test_1.12.16.bb @@ -70,11 +70,11 @@ do_install_ptest() { install ${B}/test/test-segfault ${D}${PTEST_PATH}/test - cp -r ${B}/test/data ${D}${PTEST_PATH}/test + cp -R --no-dereference --preserve=mode,links ${B}/test/data ${D}${PTEST_PATH}/test install ${B}/dbus/.libs/test-dbus ${D}${PTEST_PATH}/test install -d ${D}${PTEST_PATH}/test/.libs - cp -a ${B}/dbus/.libs/*.so* ${D}${PTEST_PATH}/test/.libs + cp -R --no-dereference --preserve=mode,links ${B}/dbus/.libs/*.so* ${D}${PTEST_PATH}/test/.libs # Remove build host references... find "${D}${PTEST_PATH}/test/data" \( -name *.service -o -name *.conf -o -name "*.aaprofile" \) -type f -exec \ -- 2.25.1 From raj.khem at gmail.com Sun Mar 1 01:43:00 2020 From: raj.khem at gmail.com (Khem Raj) Date: Sat, 29 Feb 2020 17:43:00 -0800 Subject: [OE-core] [PATCH 2/3] strace: Fix host contamination QA errors In-Reply-To: <20200301014301.805156-1-raj.khem@gmail.com> References: <20200301014301.805156-1-raj.khem@gmail.com> Message-ID: <20200301014301.805156-3-raj.khem@gmail.com> Signed-off-by: Khem Raj --- .../strace/0001-Evaluate-AC_PROG_LN_S.patch | 29 +++++++++++++++++++ meta/recipes-devtools/strace/strace_5.5.bb | 1 + 2 files changed, 30 insertions(+) create mode 100644 meta/recipes-devtools/strace/strace/0001-Evaluate-AC_PROG_LN_S.patch diff --git a/meta/recipes-devtools/strace/strace/0001-Evaluate-AC_PROG_LN_S.patch b/meta/recipes-devtools/strace/strace/0001-Evaluate-AC_PROG_LN_S.patch new file mode 100644 index 0000000000..c956256bed --- /dev/null +++ b/meta/recipes-devtools/strace/strace/0001-Evaluate-AC_PROG_LN_S.patch @@ -0,0 +1,29 @@ +From 49e58e2d8ada869ebc75ab6e17c80e20e00ee625 Mon Sep 17 00:00:00 2001 +From: Khem Raj +Date: Sat, 29 Feb 2020 13:21:08 -0800 +Subject: [PATCH] Evaluate AC_PROG_LN_S + +Fixes +strace: /usr/lib/strace/ptest/tests/ioctl_evdev-success-Xverbose.gen.test is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination + +Upstream-Status: Pending +Signed-off-by: Khem Raj +--- + configure.ac | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/configure.ac b/configure.ac +index 65f000b..c4cbf55 100644 +--- a/configure.ac ++++ b/configure.ac +@@ -25,6 +25,7 @@ AC_CONFIG_HEADERS([config.h]) + AM_INIT_AUTOMAKE([foreign nostdinc dist-xz silent-rules parallel-tests subdir-objects 1.13]) + AM_MAINTAINER_MODE + AC_CANONICAL_HOST ++AC_PROG_LN_S + + RPM_CHANGELOGTIME="$(LC_TIME=C date -u '+%a %b %d %Y')" + AC_SUBST(RPM_CHANGELOGTIME) +-- +2.25.1 + diff --git a/meta/recipes-devtools/strace/strace_5.5.bb b/meta/recipes-devtools/strace/strace_5.5.bb index 6e7d63949d..f3b7c4462e 100644 --- a/meta/recipes-devtools/strace/strace_5.5.bb +++ b/meta/recipes-devtools/strace/strace_5.5.bb @@ -13,6 +13,7 @@ SRC_URI = "https://strace.io/files/${PV}/strace-${PV}.tar.xz \ file://0001-caps-abbrev.awk-fix-gawk-s-path.patch \ file://ptest-spacesave.patch \ file://uintptr_t.patch \ + file://0001-Evaluate-AC_PROG_LN_S.patch \ " SRC_URI[md5sum] = "dbce2e84632b39a4ed86b9fc60447af9" SRC_URI[sha256sum] = "9f58958c8e59ea62293d907d10572e352b582bd7948ed21aa28ebb47e5bf30ff" -- 2.25.1 From raj.khem at gmail.com Sun Mar 1 01:43:01 2020 From: raj.khem at gmail.com (Khem Raj) Date: Sat, 29 Feb 2020 17:43:01 -0800 Subject: [OE-core] [PATCH 3/3] boost: Fix host-user-contaminated QA errors In-Reply-To: <20200301014301.805156-1-raj.khem@gmail.com> References: <20200301014301.805156-1-raj.khem@gmail.com> Message-ID: <20200301014301.805156-4-raj.khem@gmail.com> bjam calls cp directly, which can install with same user name as bitbake in staging, which is caught by packager and reported, therefore override cp command to use right options to make cp behave like install utility Signed-off-by: Khem Raj --- meta/recipes-support/boost/boost.inc | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/recipes-support/boost/boost.inc b/meta/recipes-support/boost/boost.inc index e15dce4e1d..7f44638135 100644 --- a/meta/recipes-support/boost/boost.inc +++ b/meta/recipes-support/boost/boost.inc @@ -189,6 +189,7 @@ do_compile() { } do_install() { + export CP="cp -R --no-dereference --preserve=mode,links" bjam ${BJAM_OPTS} \ --libdir=${D}${libdir} \ --includedir=${D}${includedir} \ -- 2.25.1 From richard.purdie at linuxfoundation.org Sun Mar 1 07:57:38 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Sun, 01 Mar 2020 07:57:38 +0000 Subject: [OE-core] [PATCH 1/3] dbus-test: Fix QA host-contamination errors In-Reply-To: <20200301014301.805156-2-raj.khem@gmail.com> References: <20200301014301.805156-1-raj.khem@gmail.com> <20200301014301.805156-2-raj.khem@gmail.com> Message-ID: <6ebd8c098cac7dab116f9043e7b64fe9b3376601.camel@linuxfoundation.org> On Sat, 2020-02-29 at 17:42 -0800, Khem Raj wrote: > Errors like below are fixed > > bus/connection.h is owned by uid 1000, which is the same as t > he user running bitbake. This may be due to host contamination > > Signed-off-by: Khem Raj > --- > meta/recipes-core/dbus/dbus-test_1.12.16.bb | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Why aren't we seeing this everywhere? The autobuilders don't show it and no other reports. What is unique to your setup to reproduce this? Cheers, Richard > diff --git a/meta/recipes-core/dbus/dbus-test_1.12.16.bb > b/meta/recipes-core/dbus/dbus-test_1.12.16.bb > index bea0e74ed0..91e2ba69d2 100644 > --- a/meta/recipes-core/dbus/dbus-test_1.12.16.bb > +++ b/meta/recipes-core/dbus/dbus-test_1.12.16.bb > @@ -70,11 +70,11 @@ do_install_ptest() { > > install ${B}/test/test-segfault ${D}${PTEST_PATH}/test > > - cp -r ${B}/test/data ${D}${PTEST_PATH}/test > + cp -R --no-dereference --preserve=mode,links ${B}/test/data > ${D}${PTEST_PATH}/test > install ${B}/dbus/.libs/test-dbus ${D}${PTEST_PATH}/test > > install -d ${D}${PTEST_PATH}/test/.libs > - cp -a ${B}/dbus/.libs/*.so* ${D}${PTEST_PATH}/test/.libs > + cp -R --no-dereference --preserve=mode,links > ${B}/dbus/.libs/*.so* ${D}${PTEST_PATH}/test/.libs > > # Remove build host references... > find "${D}${PTEST_PATH}/test/data" \( -name *.service -o -name > *.conf -o -name "*.aaprofile" \) -type f -exec \ > -- > 2.25.1 > From raj.khem at gmail.com Sun Mar 1 08:12:05 2020 From: raj.khem at gmail.com (Khem Raj) Date: Sun, 1 Mar 2020 00:12:05 -0800 Subject: [OE-core] [PATCH 1/3] dbus-test: Fix QA host-contamination errors In-Reply-To: <6ebd8c098cac7dab116f9043e7b64fe9b3376601.camel@linuxfoundation.org> References: <20200301014301.805156-1-raj.khem@gmail.com> <20200301014301.805156-2-raj.khem@gmail.com> <6ebd8c098cac7dab116f9043e7b64fe9b3376601.camel@linuxfoundation.org> Message-ID: On Sat, Feb 29, 2020 at 11:57 PM Richard Purdie < richard.purdie at linuxfoundation.org> wrote: > On Sat, 2020-02-29 at 17:42 -0800, Khem Raj wrote: > > Errors like below are fixed > > > > bus/connection.h is owned by uid 1000, which is the same as t > > he user running bitbake. This may be due to host contamination > > > > Signed-off-by: Khem Raj > > --- > > meta/recipes-core/dbus/dbus-test_1.12.16.bb | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > Why aren't we seeing this everywhere? The autobuilders don't show it > and no other reports. What is unique to your setup to reproduce this? These are QA warnings by default and in my distro I turned it into error so they were being reported before too Secondly this is a Debian10 minimum container running in docker where the user id is 1000 for the build user other than that there is nothing special > > > Cheers, > > Richard > > > diff --git a/meta/recipes-core/dbus/dbus-test_1.12.16.bb > > b/meta/recipes-core/dbus/dbus-test_1.12.16.bb > > index bea0e74ed0..91e2ba69d2 100644 > > --- a/meta/recipes-core/dbus/dbus-test_1.12.16.bb > > +++ b/meta/recipes-core/dbus/dbus-test_1.12.16.bb > > @@ -70,11 +70,11 @@ do_install_ptest() { > > > > install ${B}/test/test-segfault ${D}${PTEST_PATH}/test > > > > - cp -r ${B}/test/data ${D}${PTEST_PATH}/test > > + cp -R --no-dereference --preserve=mode,links ${B}/test/data > > ${D}${PTEST_PATH}/test > > install ${B}/dbus/.libs/test-dbus ${D}${PTEST_PATH}/test > > > > install -d ${D}${PTEST_PATH}/test/.libs > > - cp -a ${B}/dbus/.libs/*.so* ${D}${PTEST_PATH}/test/.libs > > + cp -R --no-dereference --preserve=mode,links > > ${B}/dbus/.libs/*.so* ${D}${PTEST_PATH}/test/.libs > > > > # Remove build host references... > > find "${D}${PTEST_PATH}/test/data" \( -name *.service -o -name > > *.conf -o -name "*.aaprofile" \) -type f -exec \ > > -- > > 2.25.1 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard.purdie at linuxfoundation.org Sun Mar 1 08:14:41 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Sun, 01 Mar 2020 08:14:41 +0000 Subject: [OE-core] [PATCH 1/3] dbus-test: Fix QA host-contamination errors In-Reply-To: References: <20200301014301.805156-1-raj.khem@gmail.com> <20200301014301.805156-2-raj.khem@gmail.com> <6ebd8c098cac7dab116f9043e7b64fe9b3376601.camel@linuxfoundation.org> Message-ID: <7737c4f098af15087a434de3b1a09d8d651ebaa8.camel@linuxfoundation.org> On Sun, 2020-03-01 at 00:12 -0800, Khem Raj wrote: > > > On Sat, Feb 29, 2020 at 11:57 PM Richard Purdie < > richard.purdie at linuxfoundation.org> wrote: > > On Sat, 2020-02-29 at 17:42 -0800, Khem Raj wrote: > > > Errors like below are fixed > > > > > > bus/connection.h is owned by uid 1000, which is the same as t > > > he user running bitbake. This may be due to host contamination > > > > > > Signed-off-by: Khem Raj > > > --- > > > meta/recipes-core/dbus/dbus-test_1.12.16.bb | 4 ++-- > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > Why aren't we seeing this everywhere? The autobuilders don't show > > it > > and no other reports. What is unique to your setup to reproduce > > this? > > These are QA warnings by default and in my distro I turned it into > error so they were being reported before too The autobuilder would show any warnings or errors and we're not seeing either. > Secondly this is a Debian10 minimum container running in docker where > the user id is 1000 for the build user other than that there is > nothing special We run debian10 builders on the autobuilder. I just don't understand why weren't not seeing this everywhere. We really need to understand why this is :/. Cheers, Richard From raj.khem at gmail.com Sun Mar 1 08:17:50 2020 From: raj.khem at gmail.com (Khem Raj) Date: Sun, 1 Mar 2020 00:17:50 -0800 Subject: [OE-core] [PATCH 1/3] dbus-test: Fix QA host-contamination errors In-Reply-To: <7737c4f098af15087a434de3b1a09d8d651ebaa8.camel@linuxfoundation.org> References: <20200301014301.805156-1-raj.khem@gmail.com> <20200301014301.805156-2-raj.khem@gmail.com> <6ebd8c098cac7dab116f9043e7b64fe9b3376601.camel@linuxfoundation.org> <7737c4f098af15087a434de3b1a09d8d651ebaa8.camel@linuxfoundation.org> Message-ID: On Sun, Mar 1, 2020 at 12:14 AM Richard Purdie < richard.purdie at linuxfoundation.org> wrote: > On Sun, 2020-03-01 at 00:12 -0800, Khem Raj wrote: > > > > > > On Sat, Feb 29, 2020 at 11:57 PM Richard Purdie < > > richard.purdie at linuxfoundation.org> wrote: > > > On Sat, 2020-02-29 at 17:42 -0800, Khem Raj wrote: > > > > Errors like below are fixed > > > > > > > > bus/connection.h is owned by uid 1000, which is the same as t > > > > he user running bitbake. This may be due to host contamination > > > > > > > > Signed-off-by: Khem Raj > > > > --- > > > > meta/recipes-core/dbus/dbus-test_1.12.16.bb | 4 ++-- > > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > Why aren't we seeing this everywhere? The autobuilders don't show > > > it > > > and no other reports. What is unique to your setup to reproduce > > > this? > > > > These are QA warnings by default and in my distro I turned it into > > error so they were being reported before too > > The autobuilder would show any warnings or errors and we're not seeing > either. > > > Secondly this is a Debian10 minimum container running in docker where > > the user id is 1000 for the build user other than that there is > > nothing special > > We run debian10 builders on the autobuilder. > > I just don't understand why weren't not seeing this everywhere. We > really need to understand why this is :/. >From what you see from fixes what it?s reporting are legit errors Why it?s not showing up everywhere I am not sure I don?t see it on Ubuntu 18.04 boxes without docker as well > > Cheers, > > Richard > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard.purdie at linuxfoundation.org Sun Mar 1 08:20:33 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Sun, 01 Mar 2020 08:20:33 +0000 Subject: [OE-core] [PATCH 1/3] dbus-test: Fix QA host-contamination errors In-Reply-To: References: <20200301014301.805156-1-raj.khem@gmail.com> <20200301014301.805156-2-raj.khem@gmail.com> <6ebd8c098cac7dab116f9043e7b64fe9b3376601.camel@linuxfoundation.org> <7737c4f098af15087a434de3b1a09d8d651ebaa8.camel@linuxfoundation.org> Message-ID: <6ac648b5b9d02cb857e9d784d7bf95e071567ca1.camel@linuxfoundation.org> On Sun, 2020-03-01 at 00:17 -0800, Khem Raj wrote: > > > On Sun, Mar 1, 2020 at 12:14 AM Richard Purdie < > richard.purdie at linuxfoundation.org> wrote: > > On Sun, 2020-03-01 at 00:12 -0800, Khem Raj wrote: > > > > > > > > > On Sat, Feb 29, 2020 at 11:57 PM Richard Purdie < > > > richard.purdie at linuxfoundation.org> wrote: > > > > On Sat, 2020-02-29 at 17:42 -0800, Khem Raj wrote: > > > > > Errors like below are fixed > > > > > > > > > > bus/connection.h is owned by uid 1000, which is the same as t > > > > > he user running bitbake. This may be due to host > > contamination > > > > > > > > > > Signed-off-by: Khem Raj > > > > > --- > > > > > meta/recipes-core/dbus/dbus-test_1.12.16.bb | 4 ++-- > > > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > > > Why aren't we seeing this everywhere? The autobuilders don't > > show > > > > it > > > > and no other reports. What is unique to your setup to reproduce > > > > this? > > > > > > These are QA warnings by default and in my distro I turned it > > into > > > error so they were being reported before too > > > > The autobuilder would show any warnings or errors and we're not > > seeing > > either. > > > > > Secondly this is a Debian10 minimum container running in docker > > where > > > the user id is 1000 for the build user other than that there is > > > nothing special > > > > We run debian10 builders on the autobuilder. > > > > I just don't understand why weren't not seeing this everywhere. We > > really need to understand why this is :/. > > From what you see from fixes what it?s reporting are legit errors > Why it?s not showing up everywhere I am not sure > I don?t see it on Ubuntu 18.04 boxes without docker as well I understand the need for the fixes, I'm just very concerned we have what amounts to undetected non-determinism in the build :( I'm more concerned about fixing that (and ensuring we can detect/fix all cases) than I am about the individual errors. Cheers, Richard From rpjday at crashcourse.ca Sun Mar 1 11:39:30 2020 From: rpjday at crashcourse.ca (Robert P. J. Day) Date: Sun, 1 Mar 2020 06:39:30 -0500 (EST) Subject: [OE-core] is there ever a compelling reason for "FILESEXTRAPATHS_append := ..."? Message-ID: occasionally, i run across an existing bbappend file which contains FILESEXTRAPATHS_append := ... and that makes me nervous as i don't see the rationale in *appending* to that variable in a bbappend file -- seems to defeat the purpose of potentially overriding what's in the original .bb recipe. now, sometimes it's obvious that it's broken as i'm currently looking at an example: FILESEXTRAPATHS_append := "${THISDIR}/${PN}:" which makes no sense at all with the colon at the end. but other than something so clearly broken, are there situations to append to FILESEXTRAPATHS? that just seems counter-productive, but maybe i'm missing something. rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ======================================================================== From rpjday at crashcourse.ca Sun Mar 1 11:50:53 2020 From: rpjday at crashcourse.ca (Robert P. J. Day) Date: Sun, 1 Mar 2020 06:50:53 -0500 (EST) Subject: [OE-core] is there ever a compelling reason for "FILESEXTRAPATHS_append := ..."? In-Reply-To: References: Message-ID: On Sun, 1 Mar 2020, Robert P. J. Day wrote: > > occasionally, i run across an existing bbappend file which contains > > FILESEXTRAPATHS_append := ... > > and that makes me nervous as i don't see the rationale in *appending* > to that variable in a bbappend file -- seems to defeat the purpose of > potentially overriding what's in the original .bb recipe. > > now, sometimes it's obvious that it's broken as i'm currently > looking at an example: > > FILESEXTRAPATHS_append := "${THISDIR}/${PN}:" > > which makes no sense at all with the colon at the end. but other than > something so clearly broken, are there situations to append to > FILESEXTRAPATHS? that just seems counter-productive, but maybe i'm > missing something. figured i'd scan for examples of that in some of the many layers i have checked out and found the following: meta-boundary/recipes-qt/qt4/qt4-embedded_%.bbappend:FILESEXTRAPATHS_append := "${THISDIR}/files:" meta-intel/recipes-core/zlib/zlib-intel_1.2.11.1.jtkv6.3.bb:FILESEXTRAPATHS_append = ":${COREBASE}/meta/recipes-core/zlib/zlib" meta-qt5/recipes-qt/qt5/qt5-ptest.inc:FILESEXTRAPATHS_append := ":${THISDIR}/ptest" meta-virtualization/recipes-networking/openvswitch/openvswitch_git.bb:FILESEXTRAPATHS_append := "${THISDIR}/${PN}-git:" note that a couple seem clearly(?) wrong (like that last one), but i'm open to clarification as to when this is useful. (i think i see the application in that meta-intel layer example, although should that use "OEROOT" rather than "COREBASE"?) rday From otavio at ossystems.com.br Sun Mar 1 13:13:53 2020 From: otavio at ossystems.com.br (Otavio Salvador) Date: Sun, 1 Mar 2020 10:13:53 -0300 Subject: [OE-core] [RFC PATCH] easysplash: Add recipes for 1.0.0 release Message-ID: <20200301131353.3470253-1-otavio@ossystems.com.br> A simple program for animated splash screens using Software Rendering or OpenGL ES. It consists of the main splash screen program (easysplash) and a small control program (easysplashctl). EasySplash takes as input zip archives containing a description and PNG-encoded image frames. Signed-off-by: Otavio Salvador --- We decided to open source this so more people can rely on this for their Embedded Linux devices use. The APACHE-2.0 or MIT license can be used, as preferred as all source is dual licensed. On this commit, we are adding the two animations we have been using for demos, so it can be used as testing. I believe it'd be good if a specific one was developed for OpenEmbedded / Yocto Project used, thus the use of a RFC patch. meta/classes/easysplash-animation.bbclass | 20 ++++++ .../easysplash-bootanimation-default_1.0.bb | 12 ++++ ...asysplash-bootanimation-ossystems_1.0.1.bb | 11 +++ .../easysplash/easysplash/easysplash.default | 2 + .../recipes-core/easysplash/easysplash_git.bb | 71 +++++++++++++++++++ 5 files changed, 116 insertions(+) create mode 100644 meta/classes/easysplash-animation.bbclass create mode 100644 meta/recipes-core/easysplash/easysplash-bootanimation-default_1.0.bb create mode 100644 meta/recipes-core/easysplash/easysplash-bootanimation-ossystems_1.0.1.bb create mode 100644 meta/recipes-core/easysplash/easysplash/easysplash.default create mode 100644 meta/recipes-core/easysplash/easysplash_git.bb diff --git a/meta/classes/easysplash-animation.bbclass b/meta/classes/easysplash-animation.bbclass new file mode 100644 index 0000000000..76b84f179a --- /dev/null +++ b/meta/classes/easysplash-animation.bbclass @@ -0,0 +1,20 @@ +# -*- python -*- +# easysplash-animation.bbclass allows for easy packaging of EasySplash +# animation packages. +# +# Copyright (C) 2015, O.S. Systems Softwares Ltda. All Rights Reserved +# Released under the MIT license (see packages/COPYING) + +inherit update-alternatives allarch + +ALTERNATIVE_${PN} += "bootanimation" +ALTERNATIVE_TARGET[bootanimation] = "/lib/easysplash/${PN}.zip" +ALTERNATIVE_LINK_NAME[bootanimation] = "/lib/easysplash/bootanimation.zip" +ALTERNATIVE_PRIORITY[bootanimation] = "50" + +do_install_append() { + install -Dm 0644 ${S}/*.zip ${D}/lib/easysplash/${PN}.zip +} + +FILES_${PN} += "/lib/easysplash/${PN}.zip" +RDEPENDS_${PN} += "easysplash" diff --git a/meta/recipes-core/easysplash/easysplash-bootanimation-default_1.0.bb b/meta/recipes-core/easysplash/easysplash-bootanimation-default_1.0.bb new file mode 100644 index 0000000000..c94d2d18d4 --- /dev/null +++ b/meta/recipes-core/easysplash/easysplash-bootanimation-default_1.0.bb @@ -0,0 +1,12 @@ +SUMMARY = "O.S. Systems default boot animation for easysplash" +LICENSE = "CLOSED" + +SRC_URI = "http://download.ossystems.com.br/tarballs/${BPN}-${PV}.zip;unpack=0" +SRC_URI[md5sum] = "882345727cdea329f4d43484c3b3835f" +SRC_URI[sha256sum] = "5f77a53887d1fe2774aa319853ed5288950089a74507717ffb9071dc5e0e2d7e" + +S = "${WORKDIR}" + +inherit easysplash-animation + +ALTERNATIVE_PRIORITY[bootanimation] = "10" diff --git a/meta/recipes-core/easysplash/easysplash-bootanimation-ossystems_1.0.1.bb b/meta/recipes-core/easysplash/easysplash-bootanimation-ossystems_1.0.1.bb new file mode 100644 index 0000000000..7091df2ca5 --- /dev/null +++ b/meta/recipes-core/easysplash/easysplash-bootanimation-ossystems_1.0.1.bb @@ -0,0 +1,11 @@ +SUMMARY = "O.S. Systems animation used for image demos" +LICENSE = "CLOSED" + +SRC_URI = "http://download.ossystems.com.br/tarballs/${PN}-${PV}.zip;unpack=0" + +SRC_URI[md5sum] = "e721376508827f79382463a8dcde1cb8" +SRC_URI[sha256sum] = "472f0e5cf1dc865a450d1b87d3e93dcbb7ae5e16021d5864a01a6d28ff24b0ca" + +S = "${WORKDIR}" + +inherit easysplash-animation diff --git a/meta/recipes-core/easysplash/easysplash/easysplash.default b/meta/recipes-core/easysplash/easysplash/easysplash.default new file mode 100644 index 0000000000..6fad9200e3 --- /dev/null +++ b/meta/recipes-core/easysplash/easysplash/easysplash.default @@ -0,0 +1,2 @@ +# EASYSPLASH_GBM_DRM_DEVICE: Path to a DRI device node. Example: /dev/dri/card0. +# EASYSPLASH_GBM_DRM_CONNECTOR: The DRM connector to use. Example HDMI input, LVDS pins, etc. diff --git a/meta/recipes-core/easysplash/easysplash_git.bb b/meta/recipes-core/easysplash/easysplash_git.bb new file mode 100644 index 0000000000..196fd297a0 --- /dev/null +++ b/meta/recipes-core/easysplash/easysplash_git.bb @@ -0,0 +1,71 @@ +# Copyright (C) 2015, 2016 O.S. Systems Software Ltda. All Rights Reserved +# Released under the MIT license (see packages/COPYING) + +SUMMARY = "Userspace framebuffer boot animation based on usplash" +DESCRIPTION = "EasySplash is a simple program for animated splash screens using OpenGL ES \ +for rendering. It takes as input zip archives containing a description and PNG-encoded \ +image frames." +LIC_FILES_CHKSUM = " \ + file://LICENSE-APACHE-2.0;md5=b377b220f43d747efdec40d69fcaa69d \ + file://LICENSE-MIT;md5=b377b220f43d747efdec40d69fcaa69d \ +" +LICENSE = "Apache-2.0 | MIT" +SECTION = "base" + +DEPENDS = "zlib libpng" + +SRCREV = "d4a78a04ac2c8f1504db7ace1bce337e009e0fe7" +SRC_URI = " \ + git://github.com/OSSystems/easysplash.git \ + file://${BPN}.default \ +" + +PV = "1.0.0+git${SRCPV}" + +S = "${WORKDIR}/git" + +inherit cmake pkgconfig update-rc.d systemd + +# We want the binaries to be in /sbin +EXTRA_OECMAKE += "-DCMAKE_INSTALL_PREFIX:PATH=/ \ + -DCTL_FIFO_PATH=/dev/easysplashctl \ + -DEASYSPLASH_PID_FILE=/dev/easysplash.pid" + +INITSCRIPT_NAME = "easysplash-start" +INITSCRIPT_PARAMS_${PN} = "start 5 S ." + +SYSTEMD_SERVICE_${PN} = "easysplash-start.service easysplash-quit.service" + +PACKAGECONFIG_DISTRO ?= "${@bb.utils.contains('DISTRO_FEATURES', 'sysvinit', 'sysvinit', '', d)} \ + ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'systemd', '', d)}" + +PACKAGECONFIG ?= "${PACKAGECONFIG_DISTRO} swrender" +#PACKAGECONFIG_mx6q ?= "${PACKAGECONFIG_DISTRO} vivante-g2d" +#PACKAGECONFIG_mx6dl ?= "${PACKAGECONFIG_DISTRO} vivante-g2d" +#PACKAGECONFIG_rpi ?= "${PACKAGECONFIG_DISTRO} rpi-dispmanx" +#PACKAGECONFIG_use-mainline-bsp ?= "${PACKAGECONFIG_DISTRO} mesa-gbm" + +PACKAGECONFIG[swrender] = "-DDISPLAY_TYPE_SWRENDER=TRUE,-DDISPLAY_TYPE_SWRENDER=FALSE,pixman" +PACKAGECONFIG[vivante-g2d] = "-DDISPLAY_TYPE_G2D=TRUE,-DDISPLAY_TYPE_G2D=FALSE,virtual/libg2d" +# NOTE: not adding -DDISPLAY_TYPE_GLES=FALSE when the packageconfig isn't used +# because both mesa-gbm and vivante-gles2 enable GLES, and DDISPLAY_TYPE_GLES=FALSE +# is anyway the default +PACKAGECONFIG[vivante-gles2] = "-DDISPLAY_TYPE_GLES=TRUE -DEGL_PLATFORM_VIV_FB=TRUE,,virtual/libgles2" +# libgbm is part of the mesa recipe +PACKAGECONFIG[mesa-gbm] = "-DDISPLAY_TYPE_GLES=TRUE -DEGL_PLATFORM_GBM=TRUE,,virtual/libgles2 mesa libdrm udev" +PACKAGECONFIG[rpi-dispmanx] = "-DDISPLAY_TYPE_GLES=TRUE -DEGL_PLATFORM_RPI_DISPMANX=TRUE,,virtual/libgles2 userland" +PACKAGECONFIG[sysvinit] = "-DENABLE_SYSVINIT_SUPPORT=TRUE, -DENABLE_SYSVINIT_SUPPORT=FALSE" +PACKAGECONFIG[systemd] = "-DENABLE_SYSTEMD_SUPPORT=TRUE, -DENABLE_SYSTEMD_SUPPORT=FALSE, systemd" + +do_install_append() { + install -Dm 0644 ${WORKDIR}/${PN}.default ${D}${sysconfdir}/default/${PN} +} + +RRECOMMENDS_${PN} = "easysplash-bootanimation-default" + +# NXP SoC arch +PACKAGE_ARCH_imx = "${MACHINE_SOCARCH}" +PACKAGE_ARCH_use-mainline-bsp = "${MACHINE_SOCARCH}" + +# Raspberry Pi +PACKAGE_ARCH_rpi = "${MACHINE_ARCH}" -- 2.25.1 From pjtexier at koncepto.io Sun Mar 1 13:14:28 2020 From: pjtexier at koncepto.io (Pierre-Jean Texier) Date: Sun, 1 Mar 2020 14:14:28 +0100 Subject: [OE-core] [PATCH] sysklogd: upgrade 2.0.3 -> 2.1.1 Message-ID: <1583068468-12550-1-git-send-email-pjtexier@koncepto.io> License-Update: Relicensed under the BSD-3-Clause license since v2.1 Remove patches applied upstream. Since version v2.1, klogd was removed from the sysklogd project since syslogd performs logging of kernel messages. So, this patch remove klogd support. Signed-off-by: Pierre-Jean Texier --- ...pat-to-simplify-build-deps-and-really-fix.patch | 127 --------------------- .../0001-Remove-__BEGIN_DECLS-__END_DECLS.patch | 44 ------- .../files/0002-include-sys-types.h-for-off_t.patch | 29 ----- meta/recipes-extended/sysklogd/files/sysklogd | 22 ---- meta/recipes-extended/sysklogd/sysklogd.inc | 16 +-- meta/recipes-extended/sysklogd/sysklogd_2.0.3.bb | 3 - meta/recipes-extended/sysklogd/sysklogd_2.1.1.bb | 3 + 7 files changed, 8 insertions(+), 236 deletions(-) delete mode 100644 meta/recipes-extended/sysklogd/files/0001-Drop-libcompat-to-simplify-build-deps-and-really-fix.patch delete mode 100644 meta/recipes-extended/sysklogd/files/0001-Remove-__BEGIN_DECLS-__END_DECLS.patch delete mode 100644 meta/recipes-extended/sysklogd/files/0002-include-sys-types.h-for-off_t.patch delete mode 100644 meta/recipes-extended/sysklogd/sysklogd_2.0.3.bb create mode 100644 meta/recipes-extended/sysklogd/sysklogd_2.1.1.bb diff --git a/meta/recipes-extended/sysklogd/files/0001-Drop-libcompat-to-simplify-build-deps-and-really-fix.patch b/meta/recipes-extended/sysklogd/files/0001-Drop-libcompat-to-simplify-build-deps-and-really-fix.patch deleted file mode 100644 index 9ba7ecc..0000000 --- a/meta/recipes-extended/sysklogd/files/0001-Drop-libcompat-to-simplify-build-deps-and-really-fix.patch +++ /dev/null @@ -1,127 +0,0 @@ -From 84d70e63fc105e3713943ed8c0bdd4e31a698226 Mon Sep 17 -00:00:00 2001 From: Joachim Nilsson Date: Thu, 16 Jan -2020 22:16:51 +0100 Subject: [PATCH] Drop libcompat to simplify build deps -and really fix - -The original idea with libcompat was to keep as few objects as -possible for linking with libsyslog. That in turn to prevent -a user of libsyslog from suddenly also getting strong binding -to symbols like strlcpy() from libsyslog, rather than their C -library of choice. - -However, this caused strlcpy.c to be built as both .o and .lo -files, which in turn caused really bizarre build problems due -to bad DAG dependency. - -This patch drops libcompat and instead marks all replacement APIs -as weak symbols, which a C library can override. - -Signed-off-by: Joachim Nilsson - -Upstream-Status: Backport -[https://github.com/troglobit/sysklogd/commit/84d70e63fc105e3713943ed8c0bdd4e31a698226] - -Signed-off-by: Changqing Li ---- - lib/pidfile.c | 8 +++++++- - lib/utimensat.c | 10 ++++++++-- - src/Makefile.am | 7 +------ - 3 files changed, 16 insertions(+), 9 deletions(-) - -diff --git a/lib/pidfile.c b/lib/pidfile.c -index 81f2315..25b1c04 100644 ---- a/lib/pidfile.c -+++ b/lib/pidfile.c -@@ -31,6 +31,9 @@ - * POSSIBILITY OF SUCH DAMAGE. - */ - -+#include -+#ifndef HAVE_PIDFILE -+ - #define _GNU_SOURCE /* Needed with GLIBC to get asprintf() */ - #include /* utimensat() */ - #include /* utimensat() on *BSD */ -@@ -54,7 +57,7 @@ const char *__pidfile_path = RUNSTATEDIR; - const char *__pidfile_name = NULL; - - int --pidfile(const char *basename) -+__pidfile(const char *basename) - { - int save_errno; - int atexit_already; -@@ -127,6 +130,9 @@ pidfile(const char *basename) - return (0); - } - -+weak_alias(__pidfile, pidfile); -+#endif /* HAVE_PIDFILE */ -+ - static void - pidfile_cleanup(void) - { -diff --git a/lib/utimensat.c b/lib/utimensat.c -index edf7e10..b68ce0e 100644 ---- a/lib/utimensat.c -+++ b/lib/utimensat.c -@@ -15,7 +15,8 @@ - * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. - */ - --#include "config.h" -+#include -+#ifndef HAVE_UTIMENSAT - - #include - #ifdef HAVE_FCNTL_H -@@ -23,7 +24,8 @@ - #endif - #include /* lutimes(), utimes(), utimensat() */ - --int utimensat(int dirfd, const char *pathname, const struct timespec ts[2], int flags) -+int -+__utimensat(int dirfd, const char *pathname, const struct timespec ts[2], int flags) - { - int ret = -1; - struct timeval tv[2]; -@@ -45,3 +47,7 @@ int utimensat(int dirfd, const char *pathname, const struct timespec ts[2], int - - return ret; - } -+ -+weak_alias(__utimensat, utimensat); -+ -+#endif /* HAVE_UTIMENSAT */ -diff --git a/src/Makefile.am b/src/Makefile.am -index 6e2a51c..1db88d3 100644 ---- a/src/Makefile.am -+++ b/src/Makefile.am -@@ -19,7 +19,6 @@ - bin_PROGRAMS = - sbin_PROGRAMS = syslogd - lib_LTLIBRARIES = libsyslog.la --noinst_LTLIBRARIES = libcompat.la - - if ENABLE_KLOGD - sbin_PROGRAMS += klogd -@@ -48,10 +47,6 @@ logger_CPPFLAGS = $(AM_CPPFLAGS) -D_XOPEN_SOURCE=600 - logger_LDADD = $(LIBS) $(LIBOBJS) - logger_LDADD += libsyslog.la - --# Convenience library for libsyslog instead of linking with $(LTLIBOBJS), --# which would pull in pidfile() and other (strong) symbols as well. --libcompat_la_SOURCES = ../lib/strlcpy.c ../lib/strlcat.c -- - pkgconfigdir = $(libdir)/pkgconfig - pkgincludedir = $(includedir)/syslog - pkgconfig_DATA = libsyslog.pc -@@ -59,4 +54,4 @@ pkginclude_HEADERS = syslog.h - libsyslog_la_SOURCES = syslog.c syslog.h compat.h - libsyslog_la_CPPFLAGS = $(AM_CPPFLAGS) -D_XOPEN_SOURCE=600 - libsyslog_la_LDFLAGS = $(AM_LDFLAGS) -version-info 0:0:0 --libsyslog_la_LIBADD = libcompat.la -+libsyslog_la_LIBADD = $(LTLIBOJBS) --- -2.7.4 - diff --git a/meta/recipes-extended/sysklogd/files/0001-Remove-__BEGIN_DECLS-__END_DECLS.patch b/meta/recipes-extended/sysklogd/files/0001-Remove-__BEGIN_DECLS-__END_DECLS.patch deleted file mode 100644 index b2d45c0..0000000 --- a/meta/recipes-extended/sysklogd/files/0001-Remove-__BEGIN_DECLS-__END_DECLS.patch +++ /dev/null @@ -1,44 +0,0 @@ -From 8c7995ac8da99eed55bf5410c558b1f0a74998d0 Mon Sep 17 00:00:00 2001 -From: Khem Raj -Date: Sat, 7 Dec 2019 10:27:28 -0800 -Subject: [PATCH 1/2] Remove __BEGIN_DECLS/__END_DECLS - -The __BEGIN_DECLS and __END_DECLS are internal identifiers in glibc and -are not defined in any standard. Using them fails build on musl -libc, its better to avoid them - -Upstream-Status: Submitted [https://github.com/troglobit/sysklogd/pull/10] -Signed-off-by: Khem Raj ---- - src/syslog.h | 8 ++++++-- - 1 file changed, 6 insertions(+), 2 deletions(-) - -diff --git a/src/syslog.h b/src/syslog.h -index 4fb7627..120a18f 100644 ---- a/src/syslog.h -+++ b/src/syslog.h -@@ -221,7 +221,9 @@ struct syslog_data { - .log_mask = 0xff, \ - } - --__BEGIN_DECLS -+#ifdef __cplusplus -+extern "C" { -+#endif - void openlog (const char *, int, int); - void closelog (void); - -@@ -245,7 +247,9 @@ void syslogp_r (int, struct syslog_data *, const char *, const char *, - const char *, ...); - void vsyslogp_r (int, struct syslog_data *, const char *, const char *, - const char *, va_list); --__END_DECLS -+#ifdef __cplusplus -+} -+#endif - - #else /* !__KERNEL__ */ - --- -2.24.0 - diff --git a/meta/recipes-extended/sysklogd/files/0002-include-sys-types.h-for-off_t.patch b/meta/recipes-extended/sysklogd/files/0002-include-sys-types.h-for-off_t.patch deleted file mode 100644 index 799a7a4..0000000 --- a/meta/recipes-extended/sysklogd/files/0002-include-sys-types.h-for-off_t.patch +++ /dev/null @@ -1,29 +0,0 @@ -From 10cff4ba2d09b30f8f1967f910e8ab08447a8add Mon Sep 17 00:00:00 2001 -From: Khem Raj -Date: Sat, 7 Dec 2019 10:31:04 -0800 -Subject: [PATCH 2/2] include sys/types.h for off_t - -Fixes -error: unknown type name 'off_t' - -Upstream-Status: Submitted [https://github.com/troglobit/sysklogd/pull/10] -Signed-off-by: Khem Raj ---- - src/compat.h | 1 + - 1 file changed, 1 insertion(+) - -diff --git a/src/compat.h b/src/compat.h -index a867636..1ef1bf0 100644 ---- a/src/compat.h -+++ b/src/compat.h -@@ -34,6 +34,7 @@ - #include - #include - #include -+#include - - /* - * The following macro is used to remove const cast-away warnings --- -2.24.0 - diff --git a/meta/recipes-extended/sysklogd/files/sysklogd b/meta/recipes-extended/sysklogd/files/sysklogd index 4a4ca8a..2a356a6 100755 --- a/meta/recipes-extended/sysklogd/files/sysklogd +++ b/meta/recipes-extended/sysklogd/files/sysklogd @@ -18,9 +18,7 @@ PATH=/bin:/usr/bin:/sbin:/usr/sbin pidfile_syslogd=/var/run/syslogd.pid -pidfile_klogd=/var/run/klogd.pid binpath_syslogd=/usr/sbin/syslogd -binpath_klogd=/usr/sbin/klogd test -x $binpath || exit 0 @@ -112,28 +110,16 @@ case "$1" in create_xconsole start-stop-daemon --start --quiet --pidfile $pidfile_syslogd --name syslogd --startas $binpath_syslogd -- $SYSLOGD log_end_msg $? - log_begin_msg "Starting kernel log daemon..." - start-stop-daemon --start --quiet --pidfile $pidfile_klogd --name klogd --startas $binpath_klogd -- $KLOGD - log_end_msg $? ;; stop) log_begin_msg "Stopping system log daemon..." start-stop-daemon --stop --quiet --pidfile $pidfile_syslogd --name syslogd log_end_msg $? - log_begin_msg "Stopping kernel log daemon..." - start-stop-daemon --stop --quiet --retry 3 --exec $binpath_klogd --pidfile $pidfile_klogd - log_end_msg $? ;; reload|force-reload) log_begin_msg "Reloading system log daemon..." start-stop-daemon --stop --quiet --signal 1 --pidfile $pidfile_syslogd --name syslogd log_end_msg $? - log_begin_msg "Reloading kernel log daemon..." - pid=`cat $pidfile_klogd 2> /dev/null` - start-stop-daemon --stop --quiet --retry 3 --exec $binpath_klogd --pidfile $pidfile_klogd - waitpid $pid - start-stop-daemon --start --quiet --pidfile $pidfile_klogd --name klogd --startas $binpath_klogd -- $KLOGD - log_end_msg $? ;; restart) log_begin_msg "Restarting system log daemon..." @@ -142,12 +128,6 @@ case "$1" in waitpid $pid start-stop-daemon --start --quiet --pidfile $pidfile_syslogd --name syslogd --startas $binpath_syslogd -- $SYSLOGD log_end_msg $? - log_begin_msg "Reloading kernel log daemon..." - pid=`cat $pidfile_klogd 2> /dev/null` - start-stop-daemon --stop --quiet --retry 3 --exec $binpath_klogd --pidfile $pidfile_klogd - waitpid $pid - start-stop-daemon --start --quiet --pidfile $pidfile_klogd --name klogd --startas $binpath_klogd -- $KLOGD - log_end_msg $? ;; reload-or-restart) if running @@ -160,8 +140,6 @@ case "$1" in status) status syslogd RETVAL=$? - status klogd - rval=$? [ $RETVAL -eq 0 ] && exit $rval exit $RETVAL ;; diff --git a/meta/recipes-extended/sysklogd/sysklogd.inc b/meta/recipes-extended/sysklogd/sysklogd.inc index 8618c9f..2e3d983 100644 --- a/meta/recipes-extended/sysklogd/sysklogd.inc +++ b/meta/recipes-extended/sysklogd/sysklogd.inc @@ -1,27 +1,21 @@ SUMMARY = "System Log Daemons" -DESCRIPTION = "The sysklogd package implements two system log daemons: syslogd, klogd" +DESCRIPTION = "The sysklogd package implements system log daemons: syslogd" HOMEPAGE = "http://www.infodrom.org/projects/sysklogd/" SECTION = "base" -LICENSE = "GPLv2+ & BSD" -LICENSE_syslogd = "BSD" -LICENSE_klogd = "GPLv2+" -LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263 \ +LICENSE = "BSD-3-Clause" +LIC_FILES_CHKSUM = "file://LICENSE;md5=5b4be4b2549338526758ef479c040943 \ file://src/syslogd.c;beginline=2;endline=15;md5=a880fecbc04503f071c494a9c0dd4f97 \ - file://src/klogd.c;beginline=2;endline=19;md5=4f5591d04cccbeb0352758ed4a9d7213 \ " inherit update-rc.d update-alternatives systemd autotools SRC_URI = "git://github.com/troglobit/sysklogd.git;nobranch=1 \ - file://0001-Remove-__BEGIN_DECLS-__END_DECLS.patch \ - file://0002-include-sys-types.h-for-off_t.patch \ - file://0001-Drop-libcompat-to-simplify-build-deps-and-really-fix.patch \ file://sysklogd \ " S = "${WORKDIR}/git" -EXTRA_OECONF = "--with-systemd=${systemd_system_unitdir} --with-klogd --without-logger" +EXTRA_OECONF = "--with-systemd=${systemd_system_unitdir} --without-logger" do_install_append () { install -d ${D}${sysconfdir} @@ -31,7 +25,7 @@ do_install_append () { } SYSTEMD_PACKAGES = "${PN}" -SYSTEMD_SERVICE_${PN} = "syslogd.service klogd.service" +SYSTEMD_SERVICE_${PN} = "syslogd.service" SYSTEMD_AUTO_ENABLE = "enable" INITSCRIPT_NAME = "syslog" diff --git a/meta/recipes-extended/sysklogd/sysklogd_2.0.3.bb b/meta/recipes-extended/sysklogd/sysklogd_2.0.3.bb deleted file mode 100644 index 21f750f..0000000 --- a/meta/recipes-extended/sysklogd/sysklogd_2.0.3.bb +++ /dev/null @@ -1,3 +0,0 @@ -require sysklogd.inc - -SRCREV = "ad686ca86d977f9eac4cd0a0d0e9a5964a4621d3" diff --git a/meta/recipes-extended/sysklogd/sysklogd_2.1.1.bb b/meta/recipes-extended/sysklogd/sysklogd_2.1.1.bb new file mode 100644 index 0000000..eb6b4ef --- /dev/null +++ b/meta/recipes-extended/sysklogd/sysklogd_2.1.1.bb @@ -0,0 +1,3 @@ +require sysklogd.inc + +SRCREV = "24dafe9a27ac959ebeb89acd3ebd3d62cca4b755" -- 2.7.4 From otavio.salvador at ossystems.com.br Sun Mar 1 13:28:04 2020 From: otavio.salvador at ossystems.com.br (Otavio Salvador) Date: Sun, 1 Mar 2020 10:28:04 -0300 Subject: [OE-core] is there ever a compelling reason for "FILESEXTRAPATHS_append := ..."? In-Reply-To: References: Message-ID: Hello Robert, The idea behind its use is to put the local layer as a preference for the lookup for each of SRC_URI references. This is required so we can override files / patches when using the bbappend. Another common use is to make multiple recipes to share files, which are included on SRC_URI as well. On Sun, Mar 1, 2020 at 8:51 AM Robert P. J. Day wrote: > > On Sun, 1 Mar 2020, Robert P. J. Day wrote: > > > > > occasionally, i run across an existing bbappend file which contains > > > > FILESEXTRAPATHS_append := ... > > > > and that makes me nervous as i don't see the rationale in *appending* > > to that variable in a bbappend file -- seems to defeat the purpose of > > potentially overriding what's in the original .bb recipe. > > > > now, sometimes it's obvious that it's broken as i'm currently > > looking at an example: > > > > FILESEXTRAPATHS_append := "${THISDIR}/${PN}:" > > > > which makes no sense at all with the colon at the end. but other than > > something so clearly broken, are there situations to append to > > FILESEXTRAPATHS? that just seems counter-productive, but maybe i'm > > missing something. > > figured i'd scan for examples of that in some of the many layers i > have checked out and found the following: > > meta-boundary/recipes-qt/qt4/qt4-embedded_%.bbappend:FILESEXTRAPATHS_append > := "${THISDIR}/files:" > > meta-intel/recipes-core/zlib/zlib-intel_1.2.11.1.jtkv6.3.bb:FILESEXTRAPATHS_append > = ":${COREBASE}/meta/recipes-core/zlib/zlib" > > meta-qt5/recipes-qt/qt5/qt5-ptest.inc:FILESEXTRAPATHS_append := > ":${THISDIR}/ptest" > > meta-virtualization/recipes-networking/openvswitch/openvswitch_git.bb:FILESEXTRAPATHS_append > := "${THISDIR}/${PN}-git:" > > note that a couple seem clearly(?) wrong (like that last one), but > i'm open to clarification as to when this is useful. (i think i see > the application in that meta-intel layer example, although should that > use "OEROOT" rather than "COREBASE"?) > > rday > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core at lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 From richard.purdie at linuxfoundation.org Sun Mar 1 17:05:27 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Sun, 01 Mar 2020 17:05:27 +0000 Subject: [OE-core] [PATCH 1/3] dbus-test: Fix QA host-contamination errors In-Reply-To: <6ac648b5b9d02cb857e9d784d7bf95e071567ca1.camel@linuxfoundation.org> References: <20200301014301.805156-1-raj.khem@gmail.com> <20200301014301.805156-2-raj.khem@gmail.com> <6ebd8c098cac7dab116f9043e7b64fe9b3376601.camel@linuxfoundation.org> <7737c4f098af15087a434de3b1a09d8d651ebaa8.camel@linuxfoundation.org> <6ac648b5b9d02cb857e9d784d7bf95e071567ca1.camel@linuxfoundation.org> Message-ID: On Sun, 2020-03-01 at 08:20 +0000, Richard Purdie wrote: > On Sun, 2020-03-01 at 00:17 -0800, Khem Raj wrote: > > > > On Sun, Mar 1, 2020 at 12:14 AM Richard Purdie < > > richard.purdie at linuxfoundation.org> wrote: > > > On Sun, 2020-03-01 at 00:12 -0800, Khem Raj wrote: > > > > > > > > On Sat, Feb 29, 2020 at 11:57 PM Richard Purdie < > > > > Why aren't we seeing this everywhere? The autobuilders don't > > > show > > > > > it > > > > > and no other reports. What is unique to your setup to > > > > > reproduce > > > > > this? > > > > > > > > These are QA warnings by default and in my distro I turned it > > > into > > > > error so they were being reported before too > > > > > > The autobuilder would show any warnings or errors and we're not > > > seeing > > > either. > > > > > > > Secondly this is a Debian10 minimum container running in docker > > > where > > > > the user id is 1000 for the build user other than that there is > > > > nothing special > > > > > > We run debian10 builders on the autobuilder. > > > > > > I just don't understand why weren't not seeing this everywhere. > > > We > > > really need to understand why this is :/. > > > > From what you see from fixes what it?s reporting are legit errors > > Why it?s not showing up everywhere I am not sure > > I don?t see it on Ubuntu 18.04 boxes without docker as well > > I understand the need for the fixes, I'm just very concerned we have > what amounts to undetected non-determinism in the build :( > > I'm more concerned about fixing that (and ensuring we can detect/fix > all cases) than I am about the individual errors. I did a bit more thinking/checking on this. An interesting command to experiment with is: $ touch /tmp/test; ls -la /tmp/test; ./tmp/sysroots-components/x86_64/pseudo-native/usr/bin/pseudo sh -c "ls -la /tmp/test*; cp /tmp/test /tmp/test2; ls -la /tmp/test*; rm /tmp/test*" which for me shows: -rw-rw-r-- 1 richard richard 0 Mar 1 17:03 /tmp/test Warning: PSEUDO_PREFIX unset, defaulting to XXX./tmp/sysroots-components/x86_64/pseudo-native/usr. -rw-rw-r-- 1 1000 1000 0 Mar 1 17:03 /tmp/test -rw-rw-r-- 1 1000 1000 0 Mar 1 17:03 /tmp/test -rw-rw-r-- 1 0 0 0 Mar 1 17:03 /tmp/test2 Can you see if that is different on your two machines? If so, lets have a look at the output of: touch /tmp/test; ls -la /tmp/test; PSEUDO_DEBUG=nfoPdeViDxy ./tmp/sysroots-components/x86_64/pseudo-native/usr/bin/pseudo sh -c "ls -la /tmp/test*; cp /tmp/test /tmp/test2; ls -la /tmp/test*; rm /tmp/test*" which turns on pseudo's debug output and see if that sheds some light on why this is behaving differently, perhaps because its under docker? Cheers, Richard From schnitzeltony at gmail.com Sun Mar 1 17:23:19 2020 From: schnitzeltony at gmail.com (=?UTF-8?q?Andreas=20M=C3=BCller?=) Date: Sun, 1 Mar 2020 18:23:19 +0100 Subject: [OE-core] [PATCH] mime-xdg.bbclass: Fix typo in comment Message-ID: <20200301172319.2758-1-schnitzeltony@gmail.com> Signed-off-by: Andreas M?ller --- meta/classes/mime-xdg.bbclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/classes/mime-xdg.bbclass b/meta/classes/mime-xdg.bbclass index 63169e990d..642a5b7595 100644 --- a/meta/classes/mime-xdg.bbclass +++ b/meta/classes/mime-xdg.bbclass @@ -8,7 +8,7 @@ PACKAGE_WRITE_DEPS += "desktop-file-utils-native" DESKTOPDIR = "${datadir}/applications" # There are recipes out there installing their .desktop files as absolute -# symlinks. For us these are dangling and cannot be introspected for "MymeType" +# symlinks. For us these are dangling and cannot be introspected for "MimeType" # easily. By addding package-names to MIME_XDG_PACKAGES, packager can force # proper update-desktop-database handling. Note that all introspection is # skipped for MIME_XDG_PACKAGES not empty -- 2.21.0 From bunk at stusta.de Sun Mar 1 20:26:06 2020 From: bunk at stusta.de (Adrian Bunk) Date: Sun, 1 Mar 2020 22:26:06 +0200 Subject: [OE-core] [PATCH] make: Use gziped sources Message-ID: <20200301202606.27648-1-bunk@stusta.de> Building lzip-native just for being able to build make is not worth saving 1 MB download, especially since this creates a bottleneck for the whole build. Signed-off-by: Adrian Bunk --- meta/recipes-devtools/make/make.inc | 2 +- meta/recipes-devtools/make/make_4.3.bb | 3 +-- 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/meta/recipes-devtools/make/make.inc b/meta/recipes-devtools/make/make.inc index 4142cf23d3..a0a72b6295 100644 --- a/meta/recipes-devtools/make/make.inc +++ b/meta/recipes-devtools/make/make.inc @@ -5,7 +5,7 @@ called the makefile, which lists each of the non-source files and how to compute HOMEPAGE = "http://www.gnu.org/software/make/" SECTION = "devel" -SRC_URI = "${GNU_MIRROR}/make/make-${PV}.tar.lz \ +SRC_URI = "${GNU_MIRROR}/make/make-${PV}.tar.gz \ " inherit autotools gettext pkgconfig texinfo diff --git a/meta/recipes-devtools/make/make_4.3.bb b/meta/recipes-devtools/make/make_4.3.bb index 70caf0ae16..cd0ecd4df2 100644 --- a/meta/recipes-devtools/make/make_4.3.bb +++ b/meta/recipes-devtools/make/make_4.3.bb @@ -12,7 +12,6 @@ SRC_URI += "\ EXTRA_OECONF += "--without-guile" -SRC_URI[md5sum] = "d5c40e7bd1e97a7404f5d3be982f479a" -SRC_URI[sha256sum] = "de1a441c4edf952521db30bfca80baae86a0ff1acd0a00402999344f04c45e82" +SRC_URI[sha256sum] = "e05fdde47c5f7ca45cb697e973894ff4f5d79e13b750ed57d7b66d8defc78e19" BBCLASSEXTEND = "native nativesdk" -- 2.17.1 From rpjday at crashcourse.ca Sun Mar 1 20:29:35 2020 From: rpjday at crashcourse.ca (Robert P. J. Day) Date: Sun, 1 Mar 2020 15:29:35 -0500 (EST) Subject: [OE-core] best practises: how to properly "steal" recipes from a newer layer? Message-ID: looking for a "best practises" suggestion ... currently working with a layer based on morty (2.2), migrating it to thud (2.6) and i notice that there are a *lot* of .bb recipe files in the morty layer that did not exist in any of the official OE/YP layers in morty, so they were added by either: 1) writing the recipe from scratch, compatible with morty, or 2) flat-out stealing that recipe from a *newer* layer, as long as it was compatible (this was done frequently) all of this introduces a bit of complexity. when i peruse the recipe (.bb) files in the vendor's morty-based layer, it's not at all obvious whether a given recipe file was written from scratch because it did not exist, or whether it was "stolen" from a newer layer (thud, warrior, etc...) as long as it was compatible. there is nothing in the log to identify how that recipe file came into existence, and that makes it messy since it requires examining each recipe file individually and checking whether there is *now* (or at least in a newer layer) such a recipe that can be appropriated (and possibly customized by a simple .bbappend file). actual example -- in the vendor's morty-based layer, there is a full recipe file for "cloc", for counting lines of code. such a recipe did not exist in any OE/YP layer back in morty ... or thud ... or warrior ... or zeus ... but it was introduced in jan of 2020 in master, ikn meta-oe/recipes-devtools. so, apparently, the vendor wrote a cloc recipe file from scratch as it simply did not exist anywhere in the OE/YP universe *at that time*. and something that simple (perl-based program to count lines of code) is probably going to work fine with any layer. so in the midst of migration from morty to thud, that cloc recipe is *still* not going to exist in thud but, based on my diligent research, i now know it *will* exist in a newer layer/branch. so what is the best way to use recipes in that circumstance? if i just blindly copy the recipe file forward, i'm going to have to go through this all again at the next migration. is there a reasonable way to add recipes to my (thud-based) layer that clearly shows those recipes are being scarfed from a newer layer? and i don't mean mentioning that in the commit msg as that will still require perusing all those commit messages. is there a clean way to do this? it may sound trivial, but in this case, i'm looking at a couple hundred recipes that eventually show up in newer layers that i could steal, and i really want to hang onto that information for the next migration. thoughts? rday From alex.kanavin at gmail.com Sun Mar 1 20:39:57 2020 From: alex.kanavin at gmail.com (Alexander Kanavin) Date: Sun, 1 Mar 2020 21:39:57 +0100 Subject: [OE-core] [RFC PATCH] easysplash: Add recipes for 1.0.0 release In-Reply-To: <20200301131353.3470253-1-otavio@ossystems.com.br> References: <20200301131353.3470253-1-otavio@ossystems.com.br> Message-ID: On Sun, 1 Mar 2020 at 14:14, Otavio Salvador wrote: > +++ b/meta/recipes-core/easysplash/easysplash-bootanimation-default_1.0.bb > @@ -0,0 +1,12 @@ > +SUMMARY = "O.S. Systems default boot animation for easysplash" > +LICENSE = "CLOSED" > CLOSED? > +PACKAGECONFIG[mesa-gbm] = "-DDISPLAY_TYPE_GLES=TRUE > -DEGL_PLATFORM_GBM=TRUE,,virtual/libgles2 mesa libdrm udev" > This I think should also be enabled by default subject to opengl in DISTRO_FEATURES. Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.kanavin at gmail.com Sun Mar 1 20:40:58 2020 From: alex.kanavin at gmail.com (Alexander Kanavin) Date: Sun, 1 Mar 2020 21:40:58 +0100 Subject: [OE-core] [RFC PATCH] easysplash: Add recipes for 1.0.0 release In-Reply-To: References: <20200301131353.3470253-1-otavio@ossystems.com.br> Message-ID: Oh, and: testing this somehow would be nice. Can you add it to the virgl selftest? Alex On Sun, 1 Mar 2020 at 21:39, Alexander Kanavin wrote: > On Sun, 1 Mar 2020 at 14:14, Otavio Salvador > wrote: > >> +++ b/meta/recipes-core/easysplash/ >> easysplash-bootanimation-default_1.0.bb >> @@ -0,0 +1,12 @@ >> +SUMMARY = "O.S. Systems default boot animation for easysplash" >> +LICENSE = "CLOSED" >> > > CLOSED? > > >> +PACKAGECONFIG[mesa-gbm] = "-DDISPLAY_TYPE_GLES=TRUE >> -DEGL_PLATFORM_GBM=TRUE,,virtual/libgles2 mesa libdrm udev" >> > > This I think should also be enabled by default subject to opengl in > DISTRO_FEATURES. > > Alex > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bunk at stusta.de Sun Mar 1 21:58:51 2020 From: bunk at stusta.de (Adrian Bunk) Date: Sun, 1 Mar 2020 23:58:51 +0200 Subject: [OE-core] best practises: how to properly "steal" recipes from a newer layer? In-Reply-To: References: Message-ID: <20200301215851.GA15475@localhost> On Sun, Mar 01, 2020 at 03:29:35PM -0500, Robert P. J. Day wrote: >... > 1) writing the recipe from scratch, compatible with morty, or > 2) flat-out stealing that recipe from a *newer* layer, as long as > it was compatible (this was done frequently) >... > if i just blindly copy the recipe file forward, i'm going to have to > go through this all again at the next migration. is there a reasonable > way to add recipes to my (thud-based) layer that clearly shows those > recipes are being scarfed from a newer layer? and i don't mean > mentioning that in the commit msg as that will still require perusing > all those commit messages. > > is there a clean way to do this? it may sound trivial, but in this > case, i'm looking at a couple hundred recipes that eventually show up > in newer layers that i could steal, and i really want to hang onto > that information for the next migration. > > thoughts? My usual approach for 2) is to have a recipes-backport/ in the layer that contains all recipes taken from more recent layers - completely new recipes, new versions of recipes, and sometimes just one specific change backported into a .bbappend. Example in a layer for warrior (dropping an unwanted patch): $ cat recipes-backport/e2fsprogs/e2fsprogs_1.44.5.bbappend SRC_URI_remove = "file://Revert-mke2fs-enable-the-metadata_csum-and-64bit-fea.patch" $ If you have many backported changes and migrations are often not to the latest Yocto release, you could further split this into recipes-backport-from-warrior/ etc. With an "upstream first" policy all upstreamable cases of 1) become cases of 2). For the example above see [1]. > rday cu Adrian [1] https://github.com/openembedded/openembedded-core/commit/f5edce401cfb31ebd0200adaba9a201caf7ea705 From otavio.salvador at ossystems.com.br Sun Mar 1 22:19:34 2020 From: otavio.salvador at ossystems.com.br (Otavio Salvador) Date: Sun, 1 Mar 2020 19:19:34 -0300 Subject: [OE-core] [RFC PATCH] easysplash: Add recipes for 1.0.0 release In-Reply-To: References: <20200301131353.3470253-1-otavio@ossystems.com.br> Message-ID: Hello Alex, On Sun, Mar 1, 2020 at 5:41 PM Alexander Kanavin wrote: > Oh, and: testing this somehow would be nice. Can you add it to the virgl selftest? I am open to contribute to add it and integrate if needed, however, the goal of this RFC is check if there is interest from this community and then we see what is need to be done. > > Alex > > On Sun, 1 Mar 2020 at 21:39, Alexander Kanavin wrote: >> >> On Sun, 1 Mar 2020 at 14:14, Otavio Salvador wrote: >>> >>> +++ b/meta/recipes-core/easysplash/easysplash-bootanimation-default_1.0.bb >>> @@ -0,0 +1,12 @@ >>> +SUMMARY = "O.S. Systems default boot animation for easysplash" >>> +LICENSE = "CLOSED" >> >> >> CLOSED? >> >>> >>> +PACKAGECONFIG[mesa-gbm] = "-DDISPLAY_TYPE_GLES=TRUE -DEGL_PLATFORM_GBM=TRUE,,virtual/libgles2 mesa libdrm udev" >> >> >> This I think should also be enabled by default subject to opengl in DISTRO_FEATURES. >> >> Alex > > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core at lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 From denis at denix.org Mon Mar 2 00:05:10 2020 From: denis at denix.org (Denys Dmytriyenko) Date: Sun, 1 Mar 2020 19:05:10 -0500 Subject: [OE-core] [PATCH] wayland-protocols: upgrade 1.18 -> 1.20 Message-ID: <1583107510-32807-1-git-send-email-denis@denix.org> From: Denys Dmytriyenko wayland-protocols 1.20 is now available. This release is a brown paper bag release adding the missing README.md, GOVERNANCE.md and MEMBERS.md files to the tarball. Distributions that distribute one or more of these files should ignore the 1.19 release and move directly to 1.20. https://lists.freedesktop.org/archives/wayland-devel/2020-February/041269.html Signed-off-by: Denys Dmytriyenko --- .../wayland/{wayland-protocols_1.18.bb => wayland-protocols_1.20.bb} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename meta/recipes-graphics/wayland/{wayland-protocols_1.18.bb => wayland-protocols_1.20.bb} (86%) diff --git a/meta/recipes-graphics/wayland/wayland-protocols_1.18.bb b/meta/recipes-graphics/wayland/wayland-protocols_1.20.bb similarity index 86% rename from meta/recipes-graphics/wayland/wayland-protocols_1.18.bb rename to meta/recipes-graphics/wayland/wayland-protocols_1.20.bb index c8bec66..3fb78f6 100644 --- a/meta/recipes-graphics/wayland/wayland-protocols_1.18.bb +++ b/meta/recipes-graphics/wayland/wayland-protocols_1.20.bb @@ -11,8 +11,8 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=c7b12b6702da38ca028ace54aae3d484 \ SRC_URI = "https://wayland.freedesktop.org/releases/${BPN}-${PV}.tar.xz \ " -SRC_URI[md5sum] = "af38f22d8e233c2f2e00ddc8dcc94694" -SRC_URI[sha256sum] = "3d73b7e7661763dc09d7d9107678400101ecff2b5b1e531674abfa81e04874b3" +SRC_URI[md5sum] = "b0836533a3f2dc6585b1dae00341157f" +SRC_URI[sha256sum] = "9782b7a1a863d82d7c92478497d13c758f52e7da4f197aa16443f73de77e4de7" UPSTREAM_CHECK_URI = "https://wayland.freedesktop.org/releases.html" -- 2.7.4 From anuj.mittal at intel.com Mon Mar 2 04:45:52 2020 From: anuj.mittal at intel.com (Anuj Mittal) Date: Mon, 2 Mar 2020 12:45:52 +0800 Subject: [OE-core] [PATCH 1/3] enchant2: upgrade 2.2.7 -> 2.2.8 Message-ID: <20200302044554.1265618-1-anuj.mittal@intel.com> Signed-off-by: Anuj Mittal --- .../enchant/{enchant2_2.2.7.bb => enchant2_2.2.8.bb} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename meta/recipes-support/enchant/{enchant2_2.2.7.bb => enchant2_2.2.8.bb} (85%) diff --git a/meta/recipes-support/enchant/enchant2_2.2.7.bb b/meta/recipes-support/enchant/enchant2_2.2.8.bb similarity index 85% rename from meta/recipes-support/enchant/enchant2_2.2.7.bb rename to meta/recipes-support/enchant/enchant2_2.2.8.bb index 03db5c7fae..4ddbe55da5 100644 --- a/meta/recipes-support/enchant/enchant2_2.2.7.bb +++ b/meta/recipes-support/enchant/enchant2_2.2.8.bb @@ -9,8 +9,8 @@ DEPENDS = "glib-2.0" inherit autotools pkgconfig SRC_URI = "https://github.com/AbiWord/enchant/releases/download/v${PV}/enchant-${PV}.tar.gz" -SRC_URI[md5sum] = "8a6ea1bb143c64e0edf5e49c7e7cb984" -SRC_URI[sha256sum] = "1b22976135812b35cb5b8d21a53ad11d5e7c1426c93f51e7a314a2a42cab3a09" +SRC_URI[md5sum] = "c7b9d6a392ecb8758e499f783e8dc883" +SRC_URI[sha256sum] = "c7b5e2853f0dd0b1aafea2f9e071941affeec3a76df8e3f6d67a718c89293555" UPSTREAM_CHECK_URI = "https://github.com/AbiWord/enchant/releases" -- 2.24.1 From anuj.mittal at intel.com Mon Mar 2 04:45:53 2020 From: anuj.mittal at intel.com (Anuj Mittal) Date: Mon, 2 Mar 2020 12:45:53 +0800 Subject: [OE-core] [PATCH 2/3] libsoup-2.4: upgrade 2.68.3 -> 2.68.4 In-Reply-To: <20200302044554.1265618-1-anuj.mittal@intel.com> References: <20200302044554.1265618-1-anuj.mittal@intel.com> Message-ID: <20200302044554.1265618-2-anuj.mittal@intel.com> Signed-off-by: Anuj Mittal --- .../libsoup/{libsoup-2.4_2.68.3.bb => libsoup-2.4_2.68.4.bb} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename meta/recipes-support/libsoup/{libsoup-2.4_2.68.3.bb => libsoup-2.4_2.68.4.bb} (91%) diff --git a/meta/recipes-support/libsoup/libsoup-2.4_2.68.3.bb b/meta/recipes-support/libsoup/libsoup-2.4_2.68.4.bb similarity index 91% rename from meta/recipes-support/libsoup/libsoup-2.4_2.68.3.bb rename to meta/recipes-support/libsoup/libsoup-2.4_2.68.4.bb index e8bc7d6470..6731b3373e 100644 --- a/meta/recipes-support/libsoup/libsoup-2.4_2.68.3.bb +++ b/meta/recipes-support/libsoup/libsoup-2.4_2.68.4.bb @@ -10,8 +10,8 @@ DEPENDS = "glib-2.0 glib-2.0-native libxml2 sqlite3 intltool-native libpsl" SHRT_VER = "${@d.getVar('PV').split('.')[0]}.${@d.getVar('PV').split('.')[1]}" SRC_URI = "${GNOME_MIRROR}/libsoup/${SHRT_VER}/libsoup-${PV}.tar.xz" -SRC_URI[md5sum] = "29ee2ee7017945b64ede063b1396011c" -SRC_URI[sha256sum] = "534bb08e35b0ff3702f3adfde87d3441e27c12f9f5ec351f056fe04cba02bafb" +SRC_URI[md5sum] = "603f3a945cd6ecc1fda644d7853b3b81" +SRC_URI[sha256sum] = "2d50b12922cc516ab6a7c35844d42f9c8a331668bbdf139232743d82582b3294" CVE_PRODUCT = "libsoup" -- 2.24.1 From anuj.mittal at intel.com Mon Mar 2 04:45:54 2020 From: anuj.mittal at intel.com (Anuj Mittal) Date: Mon, 2 Mar 2020 12:45:54 +0800 Subject: [OE-core] [PATCH 3/3] stress-ng: upgrade 0.11.00 -> 0.11.01 In-Reply-To: <20200302044554.1265618-1-anuj.mittal@intel.com> References: <20200302044554.1265618-1-anuj.mittal@intel.com> Message-ID: <20200302044554.1265618-3-anuj.mittal@intel.com> Signed-off-by: Anuj Mittal --- .../stress-ng/{stress-ng_0.11.00.bb => stress-ng_0.11.01.bb} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename meta/recipes-extended/stress-ng/{stress-ng_0.11.00.bb => stress-ng_0.11.01.bb} (83%) diff --git a/meta/recipes-extended/stress-ng/stress-ng_0.11.00.bb b/meta/recipes-extended/stress-ng/stress-ng_0.11.01.bb similarity index 83% rename from meta/recipes-extended/stress-ng/stress-ng_0.11.00.bb rename to meta/recipes-extended/stress-ng/stress-ng_0.11.01.bb index c8471ebadd..3486be1b03 100644 --- a/meta/recipes-extended/stress-ng/stress-ng_0.11.00.bb +++ b/meta/recipes-extended/stress-ng/stress-ng_0.11.01.bb @@ -8,8 +8,8 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263" SRC_URI = "https://kernel.ubuntu.com/~cking/tarballs/${BPN}/${BP}.tar.xz \ file://0001-Do-not-preserve-ownership-when-installing-example-jo.patch \ " -SRC_URI[md5sum] = "781f8a0f8509a01793d815210086e78a" -SRC_URI[sha256sum] = "a41a6a4a7ea4e50aab7331e5594af7d1b3b6e5815751d137a78a6e166295294e" +SRC_URI[md5sum] = "a558fc7fb9d0a851afe6de09080b5401" +SRC_URI[sha256sum] = "9fe19548c87aa1a1b9b2be3b359ec2621b88bcb16998b77527549a7736f65494" DEPENDS = "coreutils-native" -- 2.24.1 From akuster808 at gmail.com Mon Mar 2 05:39:56 2020 From: akuster808 at gmail.com (Armin Kuster) Date: Sun, 1 Mar 2020 21:39:56 -0800 Subject: [OE-core] [PATCH] wic/engine: lets display an error not a traceback Message-ID: <20200302053956.10998-1-akuster808@gmail.com> If the requested partition does not exist in this request "wic ls {path}:pnum" display a nice message not a trackback Also fix displaying the pnum and not "%s" Signed-off-by: Armin Kuster --- scripts/lib/wic/engine.py | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/scripts/lib/wic/engine.py b/scripts/lib/wic/engine.py index 83c42c9987..9ff4394757 100644 --- a/scripts/lib/wic/engine.py +++ b/scripts/lib/wic/engine.py @@ -291,7 +291,7 @@ class Disk: def _get_part_image(self, pnum): if pnum not in self.partitions: - raise WicError("Partition %s is not in the image") + raise WicError("Partition %s is not in the image" % pnum) part = self.partitions[pnum] # check if fstype is supported for fstype in self.fstypes: @@ -314,6 +314,9 @@ class Disk: seek=self.partitions[pnum].start) def dir(self, pnum, path): + if pnum not in self.partitions: + raise WicError("Partition %s is not in the image" % pnum) + if self.partitions[pnum].fstype.startswith('ext'): return exec_cmd("{} {} -R 'ls -l {}'".format(self.debugfs, self._get_part_image(pnum), -- 2.17.1 From chee.yang.lee at intel.com Mon Mar 2 06:32:59 2020 From: chee.yang.lee at intel.com (chee.yang.lee at intel.com) Date: Mon, 2 Mar 2020 14:32:59 +0800 Subject: [OE-core] [PATCH][zeus] virglrenderer: fix multiple CVEs Message-ID: <1583130779-81072-1-git-send-email-chee.yang.lee@intel.com> From: Lee Chee Yang fix these CVE: CVE-2019-18390 CVE-2019-18391 CVE-2020-8002 Signed-off-by: Lee Chee Yang --- .../virglrenderer/CVE-2019-18390.patch | 66 ++++++++++++++++++++++ .../virglrenderer/CVE-2019-18391.patch | 51 +++++++++++++++++ .../virglrenderer/CVE-2020-8002.patch | 39 +++++++++++++ .../virglrenderer/virglrenderer_0.8.0.bb | 3 + 4 files changed, 159 insertions(+) create mode 100644 meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2019-18390.patch create mode 100644 meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2019-18391.patch create mode 100644 meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2020-8002.patch diff --git a/meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2019-18390.patch b/meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2019-18390.patch new file mode 100644 index 0000000..ad61c95 --- /dev/null +++ b/meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2019-18390.patch @@ -0,0 +1,66 @@ +From 24f67de7a9088a873844a39be03cee6882260ac9 Mon Sep 17 00:00:00 2001 +From: Gert Wollny +Date: Mon, 7 Oct 2019 10:59:56 +0200 +Subject: [PATCH] vrend: check info formats in blits + +Closes #141 +Closes #142 + +v2 : drop colon in error description (Emil) + +Signed-off-by: Gert Wollny +Reviewed-by: Emil Velikov + +Upstream-Status: Backport +[https://gitlab.freedesktop.org/virgl/virglrenderer/commit/24f67de7a9088a873844a39be03cee6882260ac9] +CVE: CVE-2019-18390 +Signed-off-by: Lee Chee Yang +--- + src/virgl_hw.h | 1 + + src/vrend_renderer.c | 11 +++++++++++ + 2 files changed, 12 insertions(+) + +diff --git a/src/virgl_hw.h b/src/virgl_hw.h +index 145780bf..5ccf3073 100644 +--- a/src/virgl_hw.h ++++ b/src/virgl_hw.h +@@ -426,6 +426,7 @@ enum virgl_ctx_errors { + VIRGL_ERROR_CTX_ILLEGAL_CMD_BUFFER, + VIRGL_ERROR_CTX_GLES_HAVE_TES_BUT_MISS_TCS, + VIRGL_ERROR_GL_ANY_SAMPLES_PASSED, ++ VIRGL_ERROR_CTX_ILLEGAL_FORMAT, + }; + + #define VIRGL_RESOURCE_Y_0_TOP (1 << 0) +diff --git a/src/vrend_renderer.c b/src/vrend_renderer.c +index 14fefb38..aa6a89c1 100644 +--- a/src/vrend_renderer.c ++++ b/src/vrend_renderer.c +@@ -758,6 +758,7 @@ static const char *vrend_ctx_error_strings[] = { + [VIRGL_ERROR_CTX_ILLEGAL_CMD_BUFFER] = "Illegal command buffer", + [VIRGL_ERROR_CTX_GLES_HAVE_TES_BUT_MISS_TCS] = "On GLES context and shader program has tesselation evaluation shader but no tesselation control shader", + [VIRGL_ERROR_GL_ANY_SAMPLES_PASSED] = "Query for ANY_SAMPLES_PASSED not supported", ++ [VIRGL_ERROR_CTX_ILLEGAL_FORMAT] = "Illegal format ID", + }; + + static void __report_context_error(const char *fname, struct vrend_context *ctx, +@@ -8492,6 +8493,16 @@ void vrend_renderer_blit(struct vrend_context *ctx, + if (ctx->in_error) + return; + ++ if (!info->src.format || (enum virgl_formats)info->src.format >= VIRGL_FORMAT_MAX) { ++ report_context_error(ctx, VIRGL_ERROR_CTX_ILLEGAL_FORMAT, info->src.format); ++ return; ++ } ++ ++ if (!info->dst.format || (enum virgl_formats)info->dst.format >= VIRGL_FORMAT_MAX) { ++ report_context_error(ctx, VIRGL_ERROR_CTX_ILLEGAL_FORMAT, info->dst.format); ++ return; ++ } ++ + if (info->render_condition_enable == false) + vrend_pause_render_condition(ctx, true); + +-- +2.24.1 + diff --git a/meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2019-18391.patch b/meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2019-18391.patch new file mode 100644 index 0000000..cc641d8 --- /dev/null +++ b/meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2019-18391.patch @@ -0,0 +1,51 @@ +From 2abeb1802e3c005b17a7123e382171b3fb665971 Mon Sep 17 00:00:00 2001 +From: Gert Wollny +Date: Tue, 8 Oct 2019 17:27:01 +0200 +Subject: [PATCH] vrend: check that the transfer iov holds enough data for the + data upload + +Closes #140 + +Signed-off-by: Gert Wollny +Reviewed-by: Emil Velikov + +Upstream-Status: Backport +[https://gitlab.freedesktop.org/virgl/virglrenderer/commit/2abeb1802e3c005b17a7123e382171b3fb665971] +CVE: CVE-2019-18391 +Signed-off-by: Lee Chee Yang +--- + src/vrend_renderer.c | 11 +++++++++-- + 1 file changed, 9 insertions(+), 2 deletions(-) + +diff --git a/src/vrend_renderer.c b/src/vrend_renderer.c +index 694e1d0e..fe23846b 100644 +--- a/src/vrend_renderer.c ++++ b/src/vrend_renderer.c +@@ -7005,15 +7005,22 @@ static int vrend_renderer_transfer_write_iov(struct vrend_context *ctx, + invert = true; + } + ++ send_size = util_format_get_nblocks(res->base.format, info->box->width, ++ info->box->height) * elsize; ++ if (res->target == GL_TEXTURE_3D || ++ res->target == GL_TEXTURE_2D_ARRAY || ++ res->target == GL_TEXTURE_CUBE_MAP_ARRAY) ++ send_size *= info->box->depth; ++ + if (need_temp) { +- send_size = util_format_get_nblocks(res->base.format, info->box->width, +- info->box->height) * elsize * info->box->depth; + data = malloc(send_size); + if (!data) + return ENOMEM; + read_transfer_data(iov, num_iovs, data, res->base.format, info->offset, + stride, layer_stride, info->box, invert); + } else { ++ if (send_size > iov[0].iov_len - info->offset) ++ return EINVAL; + data = (char*)iov[0].iov_base + info->offset; + } + +-- +2.24.1 + diff --git a/meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2020-8002.patch b/meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2020-8002.patch new file mode 100644 index 0000000..925f2c8 --- /dev/null +++ b/meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2020-8002.patch @@ -0,0 +1,39 @@ +From 63bcca251f093d83da7e290ab4bbd38ae69089b5 Mon Sep 17 00:00:00 2001 +From: Gert Wollny +Date: Wed, 15 Jan 2020 13:43:58 +0100 +Subject: [PATCH] vrend: Don't try launching a grid if no CS is available + +Closes #155 + +Signed-off-by: Gert Wollny +Reviewed-by: Gurchetan Singh + +Upstream-Status: Backport +[https://gitlab.freedesktop.org/virgl/virglrenderer/-/commit/63bcca251f093d83da7e290ab4bbd38ae69089b5.patch] +CVE: CVE-2020-8002 +Signed-off-by: Lee Chee Yang +--- + src/vrend_renderer.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +diff --git a/src/vrend_renderer.c b/src/vrend_renderer.c +index a054bad8..2280fc43 100644 +--- a/src/vrend_renderer.c ++++ b/src/vrend_renderer.c +@@ -4604,6 +4604,13 @@ void vrend_launch_grid(struct vrend_context *ctx, + } + ctx->sub->shader_dirty = true; + } ++ ++ if (!ctx->sub->prog) { ++ vrend_printf("%s: Skipping compute shader execution due to missing shaders: %s\n", ++ __func__, ctx->debug_name); ++ return; ++ } ++ + vrend_use_program(ctx, ctx->sub->prog->id); + + vrend_draw_bind_ubo_shader(ctx, PIPE_SHADER_COMPUTE, 0); +-- +2.24.1 + diff --git a/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.0.bb b/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.0.bb index d2b11c1..e91ccc6 100644 --- a/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.0.bb +++ b/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.0.bb @@ -8,6 +8,9 @@ DEPENDS = "libdrm mesa libepoxy" SRCREV = "48cc96c9aebb9d0164830a157efc8916f08f00c0" SRC_URI = "git://anongit.freedesktop.org/virglrenderer \ file://0001-gallium-Expand-libc-check-to-be-platform-OS-check.patch \ + file://CVE-2019-18390.patch \ + file://CVE-2019-18391.patch \ + file://CVE-2020-8002.patch \ " S = "${WORKDIR}/git" -- 2.7.4 From anuj.mittal at intel.com Mon Mar 2 08:43:23 2020 From: anuj.mittal at intel.com (Anuj Mittal) Date: Mon, 2 Mar 2020 16:43:23 +0800 Subject: [OE-core] [zeus][PATCH 00/22] zeus review request In-Reply-To: References: Message-ID: <1992cd09-6147-5366-9704-e45185d7cc7c@intel.com> On 28-Feb-20 11:37 PM, akuster808 wrote: > > > On 2/28/20 7:23 AM, Anuj Mittal wrote: >> Next set of changes for zeus. Please review. >> >> Clean a-full on autobuilder except a single unrelated fetch failure for esdk test. >> >> https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/751 > > Great. When do you want responses back by ? > I will send the merge request if I don't get any feedback by tomorrow. Thanks, Anuj From rpjday at crashcourse.ca Mon Mar 2 12:40:35 2020 From: rpjday at crashcourse.ca (rpjday at crashcourse.ca) Date: Mon, 02 Mar 2020 07:40:35 -0500 Subject: [OE-core] how to cleanly centralize a zillion BBCLASSEXTEND += "nativesdk" settings? Message-ID: <20200302074035.Horde.5xguZSt_-_Yd241eE1Zo8Pb@crashcourse.ca> layer i'm currently perusing has many, many bbappend files, of which quite a number are nothing more than the single line: BBCLASSEXTEND += "nativesdk" literally, at least a hundred append files are like that. so rather than clutter up the layer with all those trivial .bbappend files, can one cram all that into a single .conf file? as i read it, can i do something like: BBCLASSEXTEND_append_pn-pkg1 = " nativesdk" BBCLASSEXTEND_append_pn-pkg2 = " nativesdk" ... and on and on ... and toss all that into a distro.conf file or something? and even if that works, is it considered good coding style? rday From richard.purdie at linuxfoundation.org Mon Mar 2 16:47:57 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Mon, 02 Mar 2020 16:47:57 +0000 Subject: [OE-core] M3 build status In-Reply-To: References: Message-ID: On Sat, 2020-02-29 at 07:38 -0800, akuster808 wrote: > > On 2/29/20 5:13 AM, Richard Purdie wrote: > > Just to quickly update everyone, a number of patches we probably > > wanted > > in 3.1 have had issues but have had the issues resolved and the > > patches > > have now merged. Thanks to all who dived in and helped with those! > So no Bind update? There is still time, please send an updated patch! > > The patches/issues I'm aware of that are left: > > > > * ltp upgrade (musl issue) > > * util-linux upgrade (breaks wic test, probably simple fix) > I can look at the two above but can't start until Sunday so if > someone else grabs them today, have at it. These are now done thankfully. > > * coreutils ptest addition (blocked on libmodule-build-per > > reproducibility issue) Still not done. > > * psplash systemd race (smurray may have a fix) Still not done. > > * autobuilder new branch handling for initial run test comparisons > > (open high bug with RP) > > * tinfoil race (open high bug, struggling for owner) Both done. > > * LockedSigs intermittent test failure (RP has open high bug, no > > clue > > how to reproduce or why, total mystery) Spent hours on this, limited success :( > > * Intermittent selftest failure with SystemExit (High open bug, > > Kai owns) Still pending. > > As ever, help with any of these welcome. We'll build M3 when a > > majority of the above are ready. Also, I've realised: * there is a high priority pseudo issue assigned to me * gcc buildtools tarball issue + the bind issue you mention > So where are patches going doing this time that will be in after the > release? I try not to encourage people to send upgrade patches during stabilisation as its a distraction for everyone and means fewer people caring about the release. I have had to queue them in the past since people ignore this and I may have to again depending on what people do :(. Cheers, Richard From zhengjunling at huawei.com Mon Mar 2 17:17:43 2020 From: zhengjunling at huawei.com (Junling Zheng) Date: Tue, 3 Mar 2020 01:17:43 +0800 Subject: [OE-core] [RESEND PATCH 1/2] security_flags: Remove stack protector flags from LDFLAGS Message-ID: <20200302171744.30713-1-zhengjunling@huawei.com> The stack protector flag is a compile option, not a link option, so remove it from LDFLAGS. Signed-off-by: Junling Zheng --- meta/conf/distro/include/security_flags.inc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/conf/distro/include/security_flags.inc b/meta/conf/distro/include/security_flags.inc index aaf04e9e59..5b79340be9 100644 --- a/meta/conf/distro/include/security_flags.inc +++ b/meta/conf/distro/include/security_flags.inc @@ -26,8 +26,8 @@ SECURITY_STACK_PROTECTOR ?= "-fstack-protector-strong" SECURITY_CFLAGS ?= "${SECURITY_STACK_PROTECTOR} ${SECURITY_PIE_CFLAGS} ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}" SECURITY_NO_PIE_CFLAGS ?= "${SECURITY_STACK_PROTECTOR} ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}" -SECURITY_LDFLAGS ?= "${SECURITY_STACK_PROTECTOR} -Wl,-z,relro,-z,now" -SECURITY_X_LDFLAGS ?= "${SECURITY_STACK_PROTECTOR} -Wl,-z,relro" +SECURITY_LDFLAGS ?= "-Wl,-z,relro,-z,now" +SECURITY_X_LDFLAGS ?= "-Wl,-z,relro" # powerpc does not get on with pie for reasons not looked into as yet GCCPIE_powerpc = "" -- 2.17.1 From zhengjunling at huawei.com Mon Mar 2 17:17:44 2020 From: zhengjunling at huawei.com (Junling Zheng) Date: Tue, 3 Mar 2020 01:17:44 +0800 Subject: [OE-core] [RESEND PATCH 2/2] arch-arm64.inc: Do not append aarch64 in MACHINEOVERRIDES In-Reply-To: <20200302171744.30713-1-zhengjunling@huawei.com> References: <20200302171744.30713-1-zhengjunling@huawei.com> Message-ID: <20200302171744.30713-2-zhengjunling@huawei.com> Currently, for arch-arm64, poky will append the MACHINEOVERRIDES with "aarch64:", which has the higher priority than TRANSLATED_TARGET_ARCH. So, for aarch64 big endian, the variable '_aarch64' will override not only '', but also '_aarch64-be', thus we will get an incorrect variable. Signed-off-by: Junling Zheng --- meta/conf/machine/include/arm/arch-arm64.inc | 2 -- 1 file changed, 2 deletions(-) diff --git a/meta/conf/machine/include/arm/arch-arm64.inc b/meta/conf/machine/include/arm/arch-arm64.inc index 53f4566815..32294bd218 100644 --- a/meta/conf/machine/include/arm/arch-arm64.inc +++ b/meta/conf/machine/include/arm/arch-arm64.inc @@ -4,8 +4,6 @@ require conf/machine/include/arm/arch-armv7ve.inc TUNEVALID[aarch64] = "Enable instructions for aarch64" -MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'aarch64', 'aarch64:', '' ,d)}" - # Little Endian base configs AVAILTUNES += "aarch64 aarch64_be" ARMPKGARCH_tune-aarch64 ?= "aarch64" -- 2.17.1 From zhengjunling at huawei.com Mon Mar 2 17:11:53 2020 From: zhengjunling at huawei.com (Junling Zheng) Date: Tue, 3 Mar 2020 01:11:53 +0800 Subject: [OE-core] [PATCH] arch-arm64.inc: Do not append aarch64 in MACHINEOVERRIDES Message-ID: <20200302171153.28030-1-zhengjunling@huawei.com> Currently, for arch-arm64, poky will append the MACHINEOVERRIDES with "aarch64:", which has the higher priority than TRANSLATED_TARGET_ARCH. So, for aarch64 big endian, the variable '_aarch64' will override not only '', but also '_aarch64-be', thus we will get an incorrect variable. Signed-off-by: Junling Zheng --- meta/conf/machine/include/arm/arch-arm64.inc | 2 -- 1 file changed, 2 deletions(-) diff --git a/meta/conf/machine/include/arm/arch-arm64.inc b/meta/conf/machine/include/arm/arch-arm64.inc index 53f4566815..32294bd218 100644 --- a/meta/conf/machine/include/arm/arch-arm64.inc +++ b/meta/conf/machine/include/arm/arch-arm64.inc @@ -4,8 +4,6 @@ require conf/machine/include/arm/arch-armv7ve.inc TUNEVALID[aarch64] = "Enable instructions for aarch64" -MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'aarch64', 'aarch64:', '' ,d)}" - # Little Endian base configs AVAILTUNES += "aarch64 aarch64_be" ARMPKGARCH_tune-aarch64 ?= "aarch64" -- 2.17.1 From rbilovol at cisco.com Mon Mar 2 18:15:40 2020 From: rbilovol at cisco.com (Ruslan Bilovol) Date: Mon, 2 Mar 2020 20:15:40 +0200 Subject: [OE-core] [PATCH] kernel-devsrc: support 4.4+ ARM/ARM64 kernels In-Reply-To: <20200214192456.2944-1-rbilovol@cisco.com> References: <20200214192456.2944-1-rbilovol@cisco.com> Message-ID: <36999460-5db4-29f6-e0e5-4ef152893fbc@cisco.com> Gentle ping On 2/14/20 9:24 PM, Ruslan Bilovol wrote: > Linux Kernel 4.4 is an LTS kernel so people may still > build it with OE. > > Thus make copying of some files optional: > - arm64 module.lds file first appeared with kernel v4.6 commit > fd045f6cd98e arm64: add support for module PLTs" > - arm32 *.tbl files first appeared in kernel v4.10 in > commit 96a8fae0fe09 "ARM: convert to generated > system call tables" > > Signed-off-by: Ruslan Bilovol > --- > meta/recipes-kernel/linux/kernel-devsrc.bb | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/meta/recipes-kernel/linux/kernel-devsrc.bb b/meta/recipes-kernel/linux/kernel-devsrc.bb > index 2fa4be67cc..2ac679e204 100644 > --- a/meta/recipes-kernel/linux/kernel-devsrc.bb > +++ b/meta/recipes-kernel/linux/kernel-devsrc.bb > @@ -147,7 +147,7 @@ do_install() { > cp -a --parents arch/arm64/kernel/vdso/note.S $kerneldir/build/ > cp -a --parents arch/arm64/kernel/vdso/gen_vdso_offsets.sh $kerneldir/build/ > > - cp -a --parents arch/arm64/kernel/module.lds $kerneldir/build/ > + cp -a --parents arch/arm64/kernel/module.lds $kerneldir/build/ 2>/dev/null || : > fi > > if [ "${ARCH}" = "powerpc" ]; then > @@ -187,7 +187,7 @@ do_install() { > > # required for generate missing syscalls prepare phase > cp -a --parents $(find arch/x86 -type f -name "syscall_32.tbl") $kerneldir/build > - cp -a --parents $(find arch/arm -type f -name "*.tbl") $kerneldir/build > + cp -a --parents $(find arch/arm -type f -name "*.tbl") $kerneldir/build 2>/dev/null || : > > if [ "${ARCH}" = "x86" ]; then > # files for 'make prepare' to succeed with kernel-devel > From raj.khem at gmail.com Mon Mar 2 18:29:37 2020 From: raj.khem at gmail.com (Khem Raj) Date: Mon, 2 Mar 2020 10:29:37 -0800 Subject: [OE-core] [PATCH] arch-arm64.inc: Do not append aarch64 in MACHINEOVERRIDES In-Reply-To: <20200302171153.28030-1-zhengjunling@huawei.com> References: <20200302171153.28030-1-zhengjunling@huawei.com> Message-ID: <666b3145-0e57-cf3c-f1f4-22d6fd0521e5@gmail.com> On 3/2/20 9:11 AM, Junling Zheng wrote: > Currently, for arch-arm64, poky will append the MACHINEOVERRIDES with > "aarch64:", which has the higher priority than TRANSLATED_TARGET_ARCH. > So, for aarch64 big endian, the variable '_aarch64' will override > not only '', but also '_aarch64-be', thus we will get an > incorrect variable. > > Signed-off-by: Junling Zheng > --- > meta/conf/machine/include/arm/arch-arm64.inc | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/meta/conf/machine/include/arm/arch-arm64.inc b/meta/conf/machine/include/arm/arch-arm64.inc > index 53f4566815..32294bd218 100644 > --- a/meta/conf/machine/include/arm/arch-arm64.inc > +++ b/meta/conf/machine/include/arm/arch-arm64.inc > @@ -4,8 +4,6 @@ require conf/machine/include/arm/arch-armv7ve.inc > > TUNEVALID[aarch64] = "Enable instructions for aarch64" > > -MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'aarch64', 'aarch64:', '' ,d)}" > - if its removed here, where is it being added for other machines, question is, should we treat aarch64 as LE equivalent of aarch64_be or should be treated as common aarch64 and a new define like aarch64_le defined. > # Little Endian base configs > AVAILTUNES += "aarch64 aarch64_be" > ARMPKGARCH_tune-aarch64 ?= "aarch64" > From raj.khem at gmail.com Mon Mar 2 18:40:04 2020 From: raj.khem at gmail.com (Khem Raj) Date: Mon, 2 Mar 2020 10:40:04 -0800 Subject: [OE-core] [RESEND PATCH 1/2] security_flags: Remove stack protector flags from LDFLAGS In-Reply-To: <20200302171744.30713-1-zhengjunling@huawei.com> References: <20200302171744.30713-1-zhengjunling@huawei.com> Message-ID: On 3/2/20 9:17 AM, Junling Zheng wrote: > The stack protector flag is a compile option, not a link option, so > remove it from LDFLAGS. we use compiler driver to do linking as well, what does this change fix for you. > > Signed-off-by: Junling Zheng > --- > meta/conf/distro/include/security_flags.inc | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/meta/conf/distro/include/security_flags.inc b/meta/conf/distro/include/security_flags.inc > index aaf04e9e59..5b79340be9 100644 > --- a/meta/conf/distro/include/security_flags.inc > +++ b/meta/conf/distro/include/security_flags.inc > @@ -26,8 +26,8 @@ SECURITY_STACK_PROTECTOR ?= "-fstack-protector-strong" > SECURITY_CFLAGS ?= "${SECURITY_STACK_PROTECTOR} ${SECURITY_PIE_CFLAGS} ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}" > SECURITY_NO_PIE_CFLAGS ?= "${SECURITY_STACK_PROTECTOR} ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}" > > -SECURITY_LDFLAGS ?= "${SECURITY_STACK_PROTECTOR} -Wl,-z,relro,-z,now" > -SECURITY_X_LDFLAGS ?= "${SECURITY_STACK_PROTECTOR} -Wl,-z,relro" > +SECURITY_LDFLAGS ?= "-Wl,-z,relro,-z,now" > +SECURITY_X_LDFLAGS ?= "-Wl,-z,relro" > > # powerpc does not get on with pie for reasons not looked into as yet > GCCPIE_powerpc = "" > From raj.khem at gmail.com Mon Mar 2 18:49:37 2020 From: raj.khem at gmail.com (Khem Raj) Date: Mon, 2 Mar 2020 10:49:37 -0800 Subject: [OE-core] [PATCH 1/3] dbus-test: Fix QA host-contamination errors In-Reply-To: References: <20200301014301.805156-1-raj.khem@gmail.com> <20200301014301.805156-2-raj.khem@gmail.com> <6ebd8c098cac7dab116f9043e7b64fe9b3376601.camel@linuxfoundation.org> <7737c4f098af15087a434de3b1a09d8d651ebaa8.camel@linuxfoundation.org> <6ac648b5b9d02cb857e9d784d7bf95e071567ca1.camel@linuxfoundation.org> Message-ID: On 3/1/20 9:05 AM, Richard Purdie wrote: > On Sun, 2020-03-01 at 08:20 +0000, Richard Purdie wrote: >> On Sun, 2020-03-01 at 00:17 -0800, Khem Raj wrote: >>> >>> On Sun, Mar 1, 2020 at 12:14 AM Richard Purdie < >>> richard.purdie at linuxfoundation.org> wrote: >>>> On Sun, 2020-03-01 at 00:12 -0800, Khem Raj wrote: >>>>> >>>>> On Sat, Feb 29, 2020 at 11:57 PM Richard Purdie < >>>>> Why aren't we seeing this everywhere? The autobuilders don't >>>> show >>>>>> it >>>>>> and no other reports. What is unique to your setup to >>>>>> reproduce >>>>>> this? >>>>> >>>>> These are QA warnings by default and in my distro I turned it >>>> into >>>>> error so they were being reported before too >>>> >>>> The autobuilder would show any warnings or errors and we're not >>>> seeing >>>> either. >>>> >>>>> Secondly this is a Debian10 minimum container running in docker >>>> where >>>>> the user id is 1000 for the build user other than that there is >>>>> nothing special >>>> >>>> We run debian10 builders on the autobuilder. >>>> >>>> I just don't understand why weren't not seeing this everywhere. >>>> We >>>> really need to understand why this is :/. >>> >>> From what you see from fixes what it?s reporting are legit errors >>> Why it?s not showing up everywhere I am not sure >>> I don?t see it on Ubuntu 18.04 boxes without docker as well >> >> I understand the need for the fixes, I'm just very concerned we have >> what amounts to undetected non-determinism in the build :( >> >> I'm more concerned about fixing that (and ensuring we can detect/fix >> all cases) than I am about the individual errors. > > I did a bit more thinking/checking on this. > > An interesting command to experiment with is: > > $ touch /tmp/test; ls -la /tmp/test; ./tmp/sysroots-components/x86_64/pseudo-native/usr/bin/pseudo sh -c "ls -la /tmp/test*; cp /tmp/test /tmp/test2; ls -la /tmp/test*; rm /tmp/test*" > > which for me shows: > > -rw-rw-r-- 1 richard richard 0 Mar 1 17:03 /tmp/test > Warning: PSEUDO_PREFIX unset, defaulting to XXX./tmp/sysroots-components/x86_64/pseudo-native/usr. > -rw-rw-r-- 1 1000 1000 0 Mar 1 17:03 /tmp/test > -rw-rw-r-- 1 1000 1000 0 Mar 1 17:03 /tmp/test > -rw-rw-r-- 1 0 0 0 Mar 1 17:03 /tmp/test2 > > Can you see if that is different on your two machines? above cmd output is exactly same as yours. -rw-r--r-- 1 build build 0 Mar 2 18:49 /tmp/test Warning: PSEUDO_PREFIX unset, defaulting to /mnt/b/yoe/build/./tmp/sysroots-components/x86_64/pseudo-native/usr. -rw-r--r-- 1 1000 1000 0 Mar 2 18:49 /tmp/test -rw-r--r-- 1 1000 1000 0 Mar 2 18:49 /tmp/test -rw-r--r-- 1 0 0 0 Mar 2 18:49 /tmp/test2 > > If so, lets have a look at the output of: > > touch /tmp/test; ls -la /tmp/test; PSEUDO_DEBUG=nfoPdeViDxy ./tmp/sysroots-components/x86_64/pseudo-native/usr/bin/pseudo sh -c "ls -la /tmp/test*; cp /tmp/test /tmp/test2; ls -la /tmp/test*; rm /tmp/test*" > > which turns on pseudo's debug output and see if that sheds some light > on why this is behaving differently, perhaps because its under docker? > I have attached the logfile. > Cheers, > > Richard > > -------------- next part -------------- paes: append_element gave us '', current '' paes: append_element gave us '/mnt', current '' paes: append_element gave us '/mnt/b', current '' paes: append_element gave us '/mnt/b/yoe', current '' paes: append_element gave us '/mnt/b/yoe/build', current '' paes: append_element gave us '/mnt/b/yoe/build/.', current '' paes: append_element gave us '/mnt/b/yoe/build/./tmp', current '' paes: append_element gave us '/mnt/b/yoe/build/./tmp/sysroots-components', current '' paes: append_element gave us '/mnt/b/yoe/build/./tmp/sysroots-components/x86_64', current '' paes: append_element gave us '/mnt/b/yoe/build/./tmp/sysroots-components/x86_64/pseudo-native', current '' paes: append_element gave us '/mnt/b/yoe/build/./tmp/sysroots-components/x86_64/pseudo-native/usr', current '' paes: append_element gave us '/mnt/b/yoe/build/./tmp/sysroots-components/x86_64/pseudo-native/usr/bin', current '' paes: append_element gave us '/mnt/b/yoe/build/./tmp/sysroots-components/x86_64/pseudo-native/usr/bin/pseudo', current '' Warning: PSEUDO_PREFIX unset, defaulting to /mnt/b/yoe/build/./tmp/sysroots-components/x86_64/pseudo-native/usr. pseudo_env: PSEUDO_PREFIX => /mnt/b/yoe/build/./tmp/sysroots-components/x86_64/pseudo-native/usr pseudo_env: PSEUDO_BINDIR => /mnt/b/yoe/build/./tmp/sysroots-components/x86_64/pseudo-native/usr/bin pseudo_env: PSEUDO_LIBDIR => /mnt/b/yoe/build/./tmp/sysroots-components/x86_64/pseudo-native/usr/lib/pseudo/lib pseudo_env: PSEUDO_LOCALSTATEDIR => /mnt/b/yoe/build/./tmp/sysroots-components/x86_64/pseudo-native/usr/var/pseudo pseudo_env: PSEUDO_OPTS => pseudo_env: PSEUDO_DEBUG => nfoPdDyeiVx 43: new pid: 43 [sh] 43: umask calling real syscall. 43: umask calling real syscall. 43: open calling real syscall. 43: fcntl calling real syscall. 43: close calling real syscall. 43: fcntl calling real syscall. 43: open calling real syscall. 43: fcntl calling real syscall. 43: close calling real syscall. 43: fcntl calling real syscall. 43: pathconf calling real syscall. 43: getcwd calling real syscall. 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/dev', current '' 43: paes: append_element gave us '/dev/tty', current '' 43: openat(path /dev/tty), flags 4002, stat rc 0, stat mode 20666 43: open /dev/tty [fd 3] (+buf) [dev/ino: 54/23598651] (020444): fcntl calling real syscall. 43: close calling real syscall. 43: fcntl calling real syscall. 43: open calling real syscall. 43: fchdir calling real syscall. 43: fchdir calling real syscall. 43: close calling real syscall. 43: msg type 1 (none), external path sh, mode 00 43: wrote 79 bytes 43: got header, type 4, pathlen 0 43: msg type 6 (open), external path /dev/tty, mode 020444 43: wrote 85 bytes 43: got header, type 4, pathlen 0 43: (43) succeed 43: close /dev/tty [fd 3]: (43) (no request) 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/mnt', current '' 43: paes: append_element gave us '/mnt/b', current '' 43: paes: append_element gave us '/mnt/b/yoe', current '' 43: paes: append_element gave us '/mnt/b/yoe/build', current '' 43: stat /mnt/b/yoe/build (+buf) (040755): msg type 3 (stat), external path /mnt/b/yoe/build, mode 040755 43: wrote 93 bytes 43: got header, type 4, pathlen 0 43: (43) fail mode 040755 uid 1000:100 43: paes: append_element gave us '/mnt/b/yoe/build', current '' 43: stat /mnt/b/yoe/build (+buf) (040755): msg type 3 (stat), external path /mnt/b/yoe/build, mode 040755 43: wrote 93 bytes 43: got header, type 4, pathlen 0 43: (43) fail mode 040755 uid 1000:100 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/mnt', current '' 43: stat /mnt (+buf) (040755): msg type 3 (stat), external path /mnt, mode 040755 43: wrote 81 bytes 43: got header, type 4, pathlen 0 43: (43) fail mode 040755 uid 0:0 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/mnt', current '' 43: paes: append_element gave us '/mnt/b', current '' 43: stat /mnt/b (+buf) (040755): msg type 3 (stat), external path /mnt/b, mode 040755 43: wrote 83 bytes 43: got header, type 4, pathlen 0 43: (43) fail mode 040755 uid 0:0 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/mnt', current '' 43: paes: append_element gave us '/mnt/b', current '' 43: paes: append_element gave us '/mnt/b/yoe', current '' 43: stat /mnt/b/yoe (+buf) (040755): msg type 3 (stat), external path /mnt/b/yoe, mode 040755 43: wrote 87 bytes 43: got header, type 4, pathlen 0 43: (43) fail mode 040755 uid 1000:100 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/mnt', current '' 43: paes: append_element gave us '/mnt/b', current '' 43: paes: append_element gave us '/mnt/b/yoe', current '' 43: paes: append_element gave us '/mnt/b/yoe/build', current '' 43: stat /mnt/b/yoe/build (+buf) (040755): msg type 3 (stat), external path /mnt/b/yoe/build, mode 040755 43: wrote 93 bytes 43: got header, type 4, pathlen 0 43: (43) fail mode 040755 uid 1000:100 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/mnt', current '' 43: paes: append_element gave us '/mnt/b', current '' 43: paes: append_element gave us '/mnt/b/yoe', current '' 43: stat /mnt/b/yoe (+buf) (040755): msg type 3 (stat), external path /mnt/b/yoe, mode 040755 43: wrote 87 bytes 43: got header, type 4, pathlen 0 43: (43) fail mode 040755 uid 1000:100 43: paes: append_element gave us '/mnt/b/yoe/build', current '' 43: stat /mnt/b/yoe/build (+buf) (040755): msg type 3 (stat), external path /mnt/b/yoe/build, mode 040755 43: wrote 93 bytes 43: got header, type 4, pathlen 0 43: (43) fail mode 040755 uid 1000:100 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/usr', current '' 43: paes: append_element gave us '/usr/local', current '' 43: paes: append_element gave us '/usr/local/sbin', current '' 43: paes: append_element gave us '/usr/local/sbin/sh', current '' 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/usr', current '' 43: paes: append_element gave us '/usr/local', current '' 43: paes: append_element gave us '/usr/local/bin', current '' 43: paes: append_element gave us '/usr/local/bin/sh', current '' 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/usr', current '' 43: paes: append_element gave us '/usr/sbin', current '' 43: paes: append_element gave us '/usr/sbin/sh', current '' 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/usr', current '' 43: paes: append_element gave us '/usr/bin', current '' 43: paes: append_element gave us '/usr/bin/sh', current '' 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/sbin', current '' 43: paes: append_element gave us '/sbin/sh', current '' 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/bin', current '' 43: readlink calling real syscall. 43: paes: append_element gave us '/bin/bash', current '' 43: paes: append_element gave us '/bin/bash', current '' 43: stat /bin/bash (+buf) (0100755): msg type 3 (stat), external path /bin/bash, mode 0100755 43: wrote 86 bytes 43: got header, type 4, pathlen 0 43: (43) fail mode 0100755 uid 0:0 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/bin', current '' 43: readlink calling real syscall. 43: paes: append_element gave us '/bin/bash', current '' 43: paes: append_element gave us '/bin/bash', current '' 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/bin', current '' 43: readlink calling real syscall. 43: paes: append_element gave us '/bin/bash', current '' 43: paes: append_element gave us '/bin/bash', current '' 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/bin', current '' 43: readlink calling real syscall. 43: paes: append_element gave us '/bin/bash', current '' 43: paes: append_element gave us '/bin/bash', current '' 43: stat /bin/bash (+buf) (0100755): msg type 3 (stat), external path /bin/bash, mode 0100755 43: wrote 86 bytes 43: got header, type 4, pathlen 0 43: (43) fail mode 0100755 uid 0:0 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/bin', current '' 43: readlink calling real syscall. 43: paes: append_element gave us '/bin/bash', current '' 43: paes: append_element gave us '/bin/bash', current '' 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/bin', current '' 43: readlink calling real syscall. 43: paes: append_element gave us '/bin/bash', current '' 43: paes: append_element gave us '/bin/bash', current '' 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/tmp', current '' 43: open /tmp [fd 3] (+buf) [dev/ino: 51/1685687] (041777): (43) (no request) 43: close /tmp [fd 3]: (43) (no request) 43: paes: append_element gave us '/mnt/b/yoe/build', current '' 43: stat /mnt/b/yoe/build (+buf) (040755): msg type 3 (stat), external path /mnt/b/yoe/build, mode 040755 43: wrote 93 bytes 43: got header, type 4, pathlen 0 43: (43) fail mode 040755 uid 1000:100 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/usr', current '' 43: paes: append_element gave us '/usr/local', current '' 43: paes: append_element gave us '/usr/local/sbin', current '' 43: paes: append_element gave us '/usr/local/sbin/ls', current '' 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/usr', current '' 43: paes: append_element gave us '/usr/local', current '' 43: paes: append_element gave us '/usr/local/bin', current '' 43: paes: append_element gave us '/usr/local/bin/ls', current '' 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/usr', current '' 43: paes: append_element gave us '/usr/sbin', current '' 43: paes: append_element gave us '/usr/sbin/ls', current '' 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/usr', current '' 43: paes: append_element gave us '/usr/bin', current '' 43: paes: append_element gave us '/usr/bin/ls', current '' 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/sbin', current '' 43: paes: append_element gave us '/sbin/ls', current '' 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/bin', current '' 43: paes: append_element gave us '/bin/ls', current '' 43: stat /bin/ls (+buf) (0100755): msg type 3 (stat), external path /bin/ls, mode 0100755 43: wrote 84 bytes 43: got header, type 4, pathlen 0 43: (43) fail mode 0100755 uid 0:0 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/bin', current '' 43: paes: append_element gave us '/bin/ls', current '' 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/bin', current '' 43: paes: append_element gave us '/bin/ls', current '' 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/bin', current '' 43: paes: append_element gave us '/bin/ls', current '' 43: stat /bin/ls (+buf) (0100755): msg type 3 (stat), external path /bin/ls, mode 0100755 43: wrote 84 bytes 43: got header, type 4, pathlen 0 43: (43) fail mode 0100755 uid 0:0 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/bin', current '' 43: paes: append_element gave us '/bin/ls', current '' 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/bin', current '' 43: paes: append_element gave us '/bin/ls', current '' 43: pseudo_env: PSEUDO_PREFIX => /mnt/b/yoe/build/./tmp/sysroots-components/x86_64/pseudo-native/usr 43: pseudo_env: PSEUDO_BINDIR => /mnt/b/yoe/build/./tmp/sysroots-components/x86_64/pseudo-native/usr/bin 43: pseudo_env: PSEUDO_LIBDIR => /mnt/b/yoe/build/./tmp/sysroots-components/x86_64/pseudo-native/usr/lib/pseudo/lib 43: pseudo_env: PSEUDO_LOCALSTATEDIR => /mnt/b/yoe/build/./tmp/sysroots-components/x86_64/pseudo-native/usr/var/pseudo 43: pseudo_env: PSEUDO_OPTS => 43: pseudo_env: PSEUDO_DEBUG => nfoPdDyeiVx 43: pseudo_env: PSEUDO_DISABLED => 0 44: new pid: 44 [sh] 44: close calling real syscall. 44: getcwd calling real syscall. 44: paes: append_element gave us '', current '' 44: paes: append_element gave us '/bin', current '' 44: paes: append_element gave us '/bin/ls', current '' 44: exec /bin/ls: (44) (no request) 44: setting up envp environment. 44: new pid: 44 [ls] 44: umask calling real syscall. 44: umask calling real syscall. 44: open calling real syscall. 44: fcntl calling real syscall. 44: close calling real syscall. 44: fcntl calling real syscall. 44: open calling real syscall. 44: fcntl calling real syscall. 44: close calling real syscall. 44: fcntl calling real syscall. 44: pathconf calling real syscall. 44: getcwd calling real syscall. 44: paes: append_element gave us '', current '' 44: paes: append_element gave us '/proc', current '' 44: paes: append_element gave us '/proc/filesystems', current '' 44: fopen '/proc/filesystems': fd 3 44: open /proc/filesystems [fd 3] (+buf) [dev/ino: 53/4026532070] (0100444): fcntl calling real syscall. 44: close calling real syscall. 44: fcntl calling real syscall. 44: open calling real syscall. 44: fchdir calling real syscall. 44: fchdir calling real syscall. 44: close calling real syscall. 44: msg type 1 (none), external path ls, mode 00 44: wrote 79 bytes 44: got header, type 4, pathlen 0 44: msg type 6 (open), external path /proc/filesystems, mode 0100444 44: wrote 94 bytes 44: got header, type 4, pathlen 0 44: (44) succeed 44: close /proc/filesystems [fd 3]: (44) (no request) 44: paes: append_element gave us '', current '' 44: paes: append_element gave us '/etc', current '' 44: paes: append_element gave us '/etc/selinux', current '' 44: paes: append_element gave us '/etc/selinux/config', current '' 44: new pid: 44 [ls] 44: close calling real syscall. 44: getcwd calling real syscall. 44: paes: append_element gave us '', current '' 44: paes: append_element gave us '/tmp', current '' 44: paes: append_element gave us '/tmp/test', current '' 44: stat /tmp/test (+buf) (0100644): fcntl calling real syscall. 44: close calling real syscall. 44: fcntl calling real syscall. 44: open calling real syscall. 44: fchdir calling real syscall. 44: fchdir calling real syscall. 44: close calling real syscall. 44: msg type 1 (none), external path ls, mode 00 44: wrote 79 bytes 44: got header, type 4, pathlen 0 44: msg type 3 (stat), external path /tmp/test, mode 0100644 44: wrote 86 bytes 44: got header, type 4, pathlen 0 44: (44) fail mode 0100644 uid 1000:1000 44: paes: append_element gave us '', current '' 44: paes: append_element gave us '/tmp', current '' 44: paes: append_element gave us '/tmp/test', current '' 44: getxattr(/tmp/test [fd -1], security.selinux) 44: getxattr, name 'security.selinux' 44: combined path buffer at 0x55b1f4c5e460 [27 bytes]: 44: 0x000000 2f 74 6d 70 2f 74 65 73 74 00 73 65 63 75 72 69 '/tmp/test.securi' 44: 0x000010 74 79 2e 73 65 6c 69 6e 75 78 00 'ty.selinux.' 44: get-xattr security.selinux -> /tmp/test (+buf) (0100644): msg type 3 (get-xattr), external path /tmp/test, mode 0100644 44: wrote 103 bytes 44: got header, type 4, pathlen 0 44: (44) fail 44: paes: append_element gave us '', current '' 44: paes: append_element gave us '/tmp', current '' 44: paes: append_element gave us '/tmp/test', current '' 44: getxattr(/tmp/test [fd -1], system.posix_acl_access) 44: getxattr, name 'system.posix_acl_access' 44: combined path buffer at 0x55b1f4c5e460 [34 bytes]: 44: 0x000000 2f 74 6d 70 2f 74 65 73 74 00 73 79 73 74 65 6d '/tmp/test.system' 44: 0x000010 2e 70 6f 73 69 78 5f 61 63 6c 5f 61 63 63 65 73 '.posix_acl_acces' 44: 0x000020 73 00 's.' 44: get-xattr system.posix_acl_access -> /tmp/test (+buf) (0100644): msg type 3 (get-xattr), external path /tmp/test, mode 0100644 44: wrote 110 bytes 44: got header, type 4, pathlen 0 44: (44) fail -rw-r--r-- 1 1000 1000 0 Mar 2 18:46 /tmp/test 44: close [fd 1]: (44) (no request) 44: close [fd 2]: fcntl calling real syscall. 44: fcntl calling real syscall. 44: (44) (no request) 44: msg type 1 (none), external path ls, mode 00 44: wrote 79 bytes 44: got header, type 4, pathlen 0 43: paes: append_element gave us '/mnt/b/yoe/build', current '' 43: stat /mnt/b/yoe/build (+buf) (040755): msg type 3 (stat), external path /mnt/b/yoe/build, mode 040755 43: wrote 93 bytes 43: got header, type 4, pathlen 0 43: (43) fail mode 040755 uid 1000:100 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/usr', current '' 43: paes: append_element gave us '/usr/local', current '' 43: paes: append_element gave us '/usr/local/sbin', current '' 43: paes: append_element gave us '/usr/local/sbin/cp', current '' 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/usr', current '' 43: paes: append_element gave us '/usr/local', current '' 43: paes: append_element gave us '/usr/local/bin', current '' 43: paes: append_element gave us '/usr/local/bin/cp', current '' 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/usr', current '' 43: paes: append_element gave us '/usr/sbin', current '' 43: paes: append_element gave us '/usr/sbin/cp', current '' 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/usr', current '' 43: paes: append_element gave us '/usr/bin', current '' 43: paes: append_element gave us '/usr/bin/cp', current '' 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/sbin', current '' 43: paes: append_element gave us '/sbin/cp', current '' 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/bin', current '' 43: paes: append_element gave us '/bin/cp', current '' 43: stat /bin/cp (+buf) (0100755): msg type 3 (stat), external path /bin/cp, mode 0100755 43: wrote 84 bytes 43: got header, type 4, pathlen 0 43: (43) fail mode 0100755 uid 0:0 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/bin', current '' 43: paes: append_element gave us '/bin/cp', current '' 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/bin', current '' 43: paes: append_element gave us '/bin/cp', current '' 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/bin', current '' 43: paes: append_element gave us '/bin/cp', current '' 43: stat /bin/cp (+buf) (0100755): msg type 3 (stat), external path /bin/cp, mode 0100755 43: wrote 84 bytes 43: got header, type 4, pathlen 0 43: (43) fail mode 0100755 uid 0:0 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/bin', current '' 43: paes: append_element gave us '/bin/cp', current '' 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/bin', current '' 43: paes: append_element gave us '/bin/cp', current '' 43: pseudo_env: PSEUDO_PREFIX => /mnt/b/yoe/build/./tmp/sysroots-components/x86_64/pseudo-native/usr 43: pseudo_env: PSEUDO_BINDIR => /mnt/b/yoe/build/./tmp/sysroots-components/x86_64/pseudo-native/usr/bin 43: pseudo_env: PSEUDO_LIBDIR => /mnt/b/yoe/build/./tmp/sysroots-components/x86_64/pseudo-native/usr/lib/pseudo/lib 43: pseudo_env: PSEUDO_LOCALSTATEDIR => /mnt/b/yoe/build/./tmp/sysroots-components/x86_64/pseudo-native/usr/var/pseudo 43: pseudo_env: PSEUDO_OPTS => 43: pseudo_env: PSEUDO_DEBUG => nfoPdDyeiVx 43: pseudo_env: PSEUDO_DISABLED => 0 45: new pid: 45 [sh] 45: close calling real syscall. 45: getcwd calling real syscall. 45: paes: append_element gave us '', current '' 45: paes: append_element gave us '/bin', current '' 45: paes: append_element gave us '/bin/cp', current '' 45: exec /bin/cp: (45) (no request) 45: setting up envp environment. 45: new pid: 45 [cp] 45: umask calling real syscall. 45: umask calling real syscall. 45: open calling real syscall. 45: fcntl calling real syscall. 45: close calling real syscall. 45: fcntl calling real syscall. 45: open calling real syscall. 45: fcntl calling real syscall. 45: close calling real syscall. 45: fcntl calling real syscall. 45: pathconf calling real syscall. 45: getcwd calling real syscall. 45: paes: append_element gave us '', current '' 45: paes: append_element gave us '/proc', current '' 45: paes: append_element gave us '/proc/filesystems', current '' 45: fopen '/proc/filesystems': fd 3 45: open /proc/filesystems [fd 3] (+buf) [dev/ino: 53/4026532070] (0100444): fcntl calling real syscall. 45: close calling real syscall. 45: fcntl calling real syscall. 45: open calling real syscall. 45: fchdir calling real syscall. 45: fchdir calling real syscall. 45: close calling real syscall. 45: msg type 1 (none), external path cp, mode 00 45: wrote 79 bytes 45: got header, type 4, pathlen 0 45: msg type 6 (open), external path /proc/filesystems, mode 0100444 45: wrote 94 bytes 45: got header, type 4, pathlen 0 45: (45) succeed 45: close /proc/filesystems [fd 3]: (45) (no request) 45: paes: append_element gave us '', current '' 45: paes: append_element gave us '/etc', current '' 45: paes: append_element gave us '/etc/selinux', current '' 45: paes: append_element gave us '/etc/selinux/config', current '' 45: new pid: 45 [cp] 45: close calling real syscall. 45: getcwd calling real syscall. 45: paes: append_element gave us '', current '' 45: paes: append_element gave us '/tmp', current '' 45: paes: append_element gave us '/tmp/test2', current '' 45: paes: append_element gave us '', current '' 45: paes: append_element gave us '/tmp', current '' 45: paes: append_element gave us '/tmp/test', current '' 45: stat /tmp/test (+buf) (0100644): fcntl calling real syscall. 45: close calling real syscall. 45: fcntl calling real syscall. 45: open calling real syscall. 45: fchdir calling real syscall. 45: fchdir calling real syscall. 45: close calling real syscall. 45: msg type 1 (none), external path cp, mode 00 45: wrote 79 bytes 45: got header, type 4, pathlen 0 45: msg type 3 (stat), external path /tmp/test, mode 0100644 45: wrote 86 bytes 45: got header, type 4, pathlen 0 45: (45) fail mode 0100644 uid 1000:1000 45: paes: append_element gave us '', current '' 45: paes: append_element gave us '/tmp', current '' 45: paes: append_element gave us '/tmp/test2', current '' 45: paes: append_element gave us '', current '' 45: paes: append_element gave us '/tmp', current '' 45: paes: append_element gave us '/tmp/test', current '' 45: openat(path /tmp/test), flags 0, stat rc 0, stat mode 100644 45: open /tmp/test [fd 3] (+buf) [dev/ino: 51/2003671] (0100044): (45) (no request) 45: fstat /tmp/test [fd 3] (+buf) [dev/ino: 51/2003671] (0100644): msg type 3 (fstat), external path /tmp/test, mode 0100644 45: wrote 86 bytes 45: got header, type 4, pathlen 0 45: (45) fail mode 0100644 uid 1000:1000 45: paes: append_element gave us '', current '' 45: paes: append_element gave us '/tmp', current '' 45: paes: append_element gave us '/tmp/test2', current '' 45: openat_creat: /tmp/test2 -> 0644 45: openat(path /tmp/test2), flags 301, stat rc 0, stat mode 100644 45: creat /tmp/test2 (+buf) (0100644): fuid: 0 msg type 6 (creat), external path /tmp/test2, mode 0100644 45: wrote 87 bytes 45: got header, type 4, pathlen 0 45: (45) succeed 45: open /tmp/test2 [fd 4] (+buf) [dev/ino: 51/2003585] (0100644): (45) (no request) 45: fstat /tmp/test2 [fd 4] (+buf) [dev/ino: 51/2003585] (0100644): msg type 3 (fstat), external path /tmp/test2, mode 0100644 45: wrote 87 bytes 45: got header, type 4, pathlen 0 45: (45) succeed mode 0100644 uid 0:0 45: close /tmp/test2 [fd 4]: (45) (no request) 45: close /tmp/test [fd 3]: (45) (no request) 45: close [fd 0]: (45) (no request) 45: close [fd 1]: (45) (no request) 45: close [fd 2]: fcntl calling real syscall. 45: fcntl calling real syscall. 45: (45) (no request) 45: msg type 1 (none), external path cp, mode 00 45: wrote 79 bytes 45: got header, type 4, pathlen 0 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/tmp', current '' 43: open /tmp [fd 3] (+buf) [dev/ino: 51/1685687] (041777): (43) (no request) 43: close /tmp [fd 3]: (43) (no request) 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/bin', current '' 43: paes: append_element gave us '/bin/ls', current '' 43: stat /bin/ls (+buf) (0100755): msg type 3 (stat), external path /bin/ls, mode 0100755 43: wrote 84 bytes 43: got header, type 4, pathlen 0 43: (43) fail mode 0100755 uid 0:0 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/bin', current '' 43: paes: append_element gave us '/bin/ls', current '' 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/bin', current '' 43: paes: append_element gave us '/bin/ls', current '' 43: pseudo_env: PSEUDO_PREFIX => /mnt/b/yoe/build/./tmp/sysroots-components/x86_64/pseudo-native/usr 43: pseudo_env: PSEUDO_BINDIR => /mnt/b/yoe/build/./tmp/sysroots-components/x86_64/pseudo-native/usr/bin 43: pseudo_env: PSEUDO_LIBDIR => /mnt/b/yoe/build/./tmp/sysroots-components/x86_64/pseudo-native/usr/lib/pseudo/lib 43: pseudo_env: PSEUDO_LOCALSTATEDIR => /mnt/b/yoe/build/./tmp/sysroots-components/x86_64/pseudo-native/usr/var/pseudo 43: pseudo_env: PSEUDO_OPTS => 43: pseudo_env: PSEUDO_DEBUG => nfoPdDyeiVx 43: pseudo_env: PSEUDO_DISABLED => 0 46: new pid: 46 [sh] 46: close calling real syscall. 46: getcwd calling real syscall. 46: paes: append_element gave us '', current '' 46: paes: append_element gave us '/bin', current '' 46: paes: append_element gave us '/bin/ls', current '' 46: exec /bin/ls: (46) (no request) 46: setting up envp environment. 46: new pid: 46 [ls] 46: umask calling real syscall. 46: umask calling real syscall. 46: open calling real syscall. 46: fcntl calling real syscall. 46: close calling real syscall. 46: fcntl calling real syscall. 46: open calling real syscall. 46: fcntl calling real syscall. 46: close calling real syscall. 46: fcntl calling real syscall. 46: pathconf calling real syscall. 46: getcwd calling real syscall. 46: paes: append_element gave us '', current '' 46: paes: append_element gave us '/proc', current '' 46: paes: append_element gave us '/proc/filesystems', current '' 46: fopen '/proc/filesystems': fd 3 46: open /proc/filesystems [fd 3] (+buf) [dev/ino: 53/4026532070] (0100444): fcntl calling real syscall. 46: close calling real syscall. 46: fcntl calling real syscall. 46: open calling real syscall. 46: fchdir calling real syscall. 46: fchdir calling real syscall. 46: close calling real syscall. 46: msg type 1 (none), external path ls, mode 00 46: wrote 79 bytes 46: got header, type 4, pathlen 0 46: msg type 6 (open), external path /proc/filesystems, mode 0100444 46: wrote 94 bytes 46: got header, type 4, pathlen 0 46: (46) succeed 46: close /proc/filesystems [fd 3]: (46) (no request) 46: paes: append_element gave us '', current '' 46: paes: append_element gave us '/etc', current '' 46: paes: append_element gave us '/etc/selinux', current '' 46: paes: append_element gave us '/etc/selinux/config', current '' 46: new pid: 46 [ls] 46: close calling real syscall. 46: getcwd calling real syscall. 46: paes: append_element gave us '', current '' 46: paes: append_element gave us '/tmp', current '' 46: paes: append_element gave us '/tmp/test', current '' 46: stat /tmp/test (+buf) (0100644): fcntl calling real syscall. 46: close calling real syscall. 46: fcntl calling real syscall. 46: open calling real syscall. 46: fchdir calling real syscall. 46: fchdir calling real syscall. 46: close calling real syscall. 46: msg type 1 (none), external path ls, mode 00 46: wrote 79 bytes 46: got header, type 4, pathlen 0 46: msg type 3 (stat), external path /tmp/test, mode 0100644 46: wrote 86 bytes 46: got header, type 4, pathlen 0 46: (46) fail mode 0100644 uid 1000:1000 46: paes: append_element gave us '', current '' 46: paes: append_element gave us '/tmp', current '' 46: paes: append_element gave us '/tmp/test', current '' 46: getxattr(/tmp/test [fd -1], security.selinux) 46: getxattr, name 'security.selinux' 46: combined path buffer at 0x563c5fc60460 [27 bytes]: 46: 0x000000 2f 74 6d 70 2f 74 65 73 74 00 73 65 63 75 72 69 '/tmp/test.securi' 46: 0x000010 74 79 2e 73 65 6c 69 6e 75 78 00 'ty.selinux.' 46: get-xattr security.selinux -> /tmp/test (+buf) (0100644): msg type 3 (get-xattr), external path /tmp/test, mode 0100644 46: wrote 103 bytes 46: got header, type 4, pathlen 0 46: (46) fail 46: paes: append_element gave us '', current '' 46: paes: append_element gave us '/tmp', current '' 46: paes: append_element gave us '/tmp/test', current '' 46: getxattr(/tmp/test [fd -1], system.posix_acl_access) 46: getxattr, name 'system.posix_acl_access' 46: combined path buffer at 0x563c5fc60460 [34 bytes]: 46: 0x000000 2f 74 6d 70 2f 74 65 73 74 00 73 79 73 74 65 6d '/tmp/test.system' 46: 0x000010 2e 70 6f 73 69 78 5f 61 63 6c 5f 61 63 63 65 73 '.posix_acl_acces' 46: 0x000020 73 00 's.' 46: get-xattr system.posix_acl_access -> /tmp/test (+buf) (0100644): msg type 3 (get-xattr), external path /tmp/test, mode 0100644 46: wrote 110 bytes 46: got header, type 4, pathlen 0 46: (46) fail 46: paes: append_element gave us '', current '' 46: paes: append_element gave us '/tmp', current '' 46: paes: append_element gave us '/tmp/test2', current '' 46: stat /tmp/test2 (+buf) (0100644): msg type 3 (stat), external path /tmp/test2, mode 0100644 46: wrote 87 bytes 46: got header, type 4, pathlen 0 46: (46) succeed mode 0100644 uid 0:0 46: paes: append_element gave us '', current '' 46: paes: append_element gave us '/tmp', current '' 46: paes: append_element gave us '/tmp/test2', current '' 46: getxattr(/tmp/test2 [fd -1], security.selinux) 46: getxattr, name 'security.selinux' 46: combined path buffer at 0x563c5fc60460 [28 bytes]: 46: 0x000000 2f 74 6d 70 2f 74 65 73 74 32 00 73 65 63 75 72 '/tmp/test2.secur' 46: 0x000010 69 74 79 2e 73 65 6c 69 6e 75 78 00 'ity.selinux.' 46: get-xattr security.selinux -> /tmp/test2 (+buf) (0100644): msg type 3 (get-xattr), external path /tmp/test2, mode 0100644 46: wrote 104 bytes 46: got header, type 4, pathlen 0 46: (46) fail 46: paes: append_element gave us '', current '' 46: paes: append_element gave us '/tmp', current '' 46: paes: append_element gave us '/tmp/test2', current '' 46: getxattr(/tmp/test2 [fd -1], system.posix_acl_access) 46: getxattr, name 'system.posix_acl_access' 46: combined path buffer at 0x563c5fc60460 [35 bytes]: 46: 0x000000 2f 74 6d 70 2f 74 65 73 74 32 00 73 79 73 74 65 '/tmp/test2.syste' 46: 0x000010 6d 2e 70 6f 73 69 78 5f 61 63 6c 5f 61 63 63 65 'm.posix_acl_acce' 46: 0x000020 73 73 00 'ss.' 46: get-xattr system.posix_acl_access -> /tmp/test2 (+buf) (0100644): msg type 3 (get-xattr), external path /tmp/test2, mode 0100644 46: wrote 111 bytes 46: got header, type 4, pathlen 0 46: (46) fail -rw-r--r-- 1 1000 1000 0 Mar 2 18:46 /tmp/test -rw-r--r-- 1 0 0 0 Mar 2 18:46 /tmp/test2 46: close [fd 1]: (46) (no request) 46: close [fd 2]: fcntl calling real syscall. 46: fcntl calling real syscall. 46: (46) (no request) 46: msg type 1 (none), external path ls, mode 00 46: wrote 79 bytes 46: got header, type 4, pathlen 0 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/tmp', current '' 43: open /tmp [fd 3] (+buf) [dev/ino: 51/1685687] (041777): (43) (no request) 43: close /tmp [fd 3]: (43) (no request) 43: paes: append_element gave us '/mnt/b/yoe/build', current '' 43: stat /mnt/b/yoe/build (+buf) (040755): msg type 3 (stat), external path /mnt/b/yoe/build, mode 040755 43: wrote 93 bytes 43: got header, type 4, pathlen 0 43: (43) fail mode 040755 uid 1000:100 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/usr', current '' 43: paes: append_element gave us '/usr/local', current '' 43: paes: append_element gave us '/usr/local/sbin', current '' 43: paes: append_element gave us '/usr/local/sbin/rm', current '' 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/usr', current '' 43: paes: append_element gave us '/usr/local', current '' 43: paes: append_element gave us '/usr/local/bin', current '' 43: paes: append_element gave us '/usr/local/bin/rm', current '' 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/usr', current '' 43: paes: append_element gave us '/usr/sbin', current '' 43: paes: append_element gave us '/usr/sbin/rm', current '' 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/usr', current '' 43: paes: append_element gave us '/usr/bin', current '' 43: paes: append_element gave us '/usr/bin/rm', current '' 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/sbin', current '' 43: paes: append_element gave us '/sbin/rm', current '' 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/bin', current '' 43: paes: append_element gave us '/bin/rm', current '' 43: stat /bin/rm (+buf) (0100755): msg type 3 (stat), external path /bin/rm, mode 0100755 43: wrote 84 bytes 43: got header, type 4, pathlen 0 43: (43) fail mode 0100755 uid 0:0 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/bin', current '' 43: paes: append_element gave us '/bin/rm', current '' 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/bin', current '' 43: paes: append_element gave us '/bin/rm', current '' 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/bin', current '' 43: paes: append_element gave us '/bin/rm', current '' 43: stat /bin/rm (+buf) (0100755): msg type 3 (stat), external path /bin/rm, mode 0100755 43: wrote 84 bytes 43: got header, type 4, pathlen 0 43: (43) fail mode 0100755 uid 0:0 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/bin', current '' 43: paes: append_element gave us '/bin/rm', current '' 43: paes: append_element gave us '', current '' 43: paes: append_element gave us '/bin', current '' 43: paes: append_element gave us '/bin/rm', current '' 43: pseudo_env: PSEUDO_PREFIX => /mnt/b/yoe/build/./tmp/sysroots-components/x86_64/pseudo-native/usr 43: pseudo_env: PSEUDO_BINDIR => /mnt/b/yoe/build/./tmp/sysroots-components/x86_64/pseudo-native/usr/bin 43: pseudo_env: PSEUDO_LIBDIR => /mnt/b/yoe/build/./tmp/sysroots-components/x86_64/pseudo-native/usr/lib/pseudo/lib 43: pseudo_env: PSEUDO_LOCALSTATEDIR => /mnt/b/yoe/build/./tmp/sysroots-components/x86_64/pseudo-native/usr/var/pseudo 43: pseudo_env: PSEUDO_OPTS => 43: pseudo_env: PSEUDO_DEBUG => nfoPdDyeiVx 43: pseudo_env: PSEUDO_DISABLED => 0 47: new pid: 47 [sh] 47: close calling real syscall. 47: getcwd calling real syscall. 47: paes: append_element gave us '', current '' 47: paes: append_element gave us '/bin', current '' 47: paes: append_element gave us '/bin/rm', current '' 47: exec /bin/rm: (47) (no request) 47: setting up envp environment. 47: new pid: 47 [rm] 47: umask calling real syscall. 47: umask calling real syscall. 47: open calling real syscall. 47: fcntl calling real syscall. 47: close calling real syscall. 47: fcntl calling real syscall. 47: open calling real syscall. 47: fcntl calling real syscall. 47: close calling real syscall. 47: fcntl calling real syscall. 47: pathconf calling real syscall. 47: getcwd calling real syscall. 47: paes: append_element gave us '', current '' 47: paes: append_element gave us '/tmp', current '' 47: paes: append_element gave us '/tmp/test', current '' 47: stat /tmp/test (+buf) (0100644): fcntl calling real syscall. 47: close calling real syscall. 47: fcntl calling real syscall. 47: open calling real syscall. 47: fchdir calling real syscall. 47: fchdir calling real syscall. 47: close calling real syscall. 47: msg type 1 (none), external path rm, mode 00 47: wrote 79 bytes 47: got header, type 4, pathlen 0 47: msg type 3 (stat), external path /tmp/test, mode 0100644 47: wrote 86 bytes 47: got header, type 4, pathlen 0 47: (47) fail mode 0100644 uid 1000:1000 47: paes: append_element gave us '', current '' 47: paes: append_element gave us '/tmp', current '' 47: paes: append_element gave us '/tmp/test', current '' 47: may-unlink /tmp/test (+buf) (0100644): msg type 3 (may-unlink), external path /tmp/test, mode 0100644 47: wrote 86 bytes 47: got header, type 4, pathlen 0 47: (47) fail 47: unlink on , not in database, no effect. 47: paes: append_element gave us '', current '' 47: paes: append_element gave us '/tmp', current '' 47: paes: append_element gave us '/tmp/test2', current '' 47: stat /tmp/test2 (+buf) (0100644): msg type 3 (stat), external path /tmp/test2, mode 0100644 47: wrote 87 bytes 47: got header, type 4, pathlen 0 47: (47) succeed mode 0100644 uid 0:0 47: paes: append_element gave us '', current '' 47: paes: append_element gave us '/tmp', current '' 47: paes: append_element gave us '/tmp/test2', current '' 47: may-unlink /tmp/test2 (+buf) (0100644): msg type 3 (may-unlink), external path /tmp/test2, mode 0100644 47: wrote 87 bytes 47: got header, type 4, pathlen 0 47: (47) succeed 47: did-unlink /tmp/test2 (+buf) (0100644): msg type 6 (did-unlink), external path /tmp/test2, mode 0100644 47: wrote 87 bytes 47: got header, type 4, pathlen 0 47: (47) succeed 47: msg type 1 (none), external path rm, mode 00 47: wrote 79 bytes 47: got header, type 4, pathlen 0 47: close [fd 0]: (47) (no request) 47: close [fd 1]: (47) (no request) 47: close [fd 2]: fcntl calling real syscall. 47: fcntl calling real syscall. 47: (47) (no request) 43: msg type 1 (none), external path sh, mode 00 43: wrote 79 bytes 43: got header, type 4, pathlen 0 From scott.murray at konsulko.com Mon Mar 2 19:14:26 2020 From: scott.murray at konsulko.com (Scott Murray) Date: Mon, 2 Mar 2020 14:14:26 -0500 Subject: [OE-core] [PATCH] psplash: update to latest git revision and clean up Message-ID: <20200302191426.4167152-1-scott.murray@konsulko.com> Update SRCREV to pick up: c359546 Fix psplash-systemd failures 3c0a4f3 Remove generated psplash-poky-img.h Also: * set the unit type in psplash-start.service to "notify" to complete the psplash-systemd race fix * remove the rest of the now unnecessary has_png logic bits * change the generated image header destination to B instead of S since that now works after the recent makefile changes, and will avoid unnecessarily polluting the source tree Signed-off-by: Scott Murray --- meta/recipes-core/psplash/files/psplash-start.service | 1 + meta/recipes-core/psplash/psplash_git.bb | 7 ++----- 2 files changed, 3 insertions(+), 5 deletions(-) diff --git a/meta/recipes-core/psplash/files/psplash-start.service b/meta/recipes-core/psplash/files/psplash-start.service index af9d5d6c20..a8c97c7a75 100644 --- a/meta/recipes-core/psplash/files/psplash-start.service +++ b/meta/recipes-core/psplash/files/psplash-start.service @@ -4,6 +4,7 @@ DefaultDependencies=no RequiresMountsFor=/run [Service] +Type=notify ExecStart=/usr/bin/psplash [Install] diff --git a/meta/recipes-core/psplash/psplash_git.bb b/meta/recipes-core/psplash/psplash_git.bb index 875adb13fc..22c71f099b 100644 --- a/meta/recipes-core/psplash/psplash_git.bb +++ b/meta/recipes-core/psplash/psplash_git.bb @@ -6,7 +6,7 @@ LICENSE = "GPLv2+" LIC_FILES_CHKSUM = "file://psplash.h;beginline=1;endline=8;md5=8f232c1e95929eacab37f00900580224" DEPENDS = "gdk-pixbuf-native" -SRCREV = "aea172a24c5b0bdc0f4efa780c0faa00c9238362" +SRCREV = "0a902f7cd875ccf018456451be369f05fa55f962" PV = "0.1+git${SRCPV}" PR = "r15" @@ -24,7 +24,6 @@ python __anonymous() { splashfiles = d.getVar('SPLASH_IMAGES').split() pkgs = [] localpaths = [] - haspng = False for uri in splashfiles: fetcher = bb.fetch2.Fetch([uri], d) flocal = os.path.basename(fetcher.localpath(uri)) @@ -42,8 +41,6 @@ python __anonymous() { bb.fatal("The output name '%s' derived from the URI %s is not valid, please specify the outsuffix parameter" % (outname, uri)) else: pkgs.append(outname) - if flocal.endswith(".png"): - haspng = True localpaths.append(flocal) # Set these so that we have less work to do in do_compile and do_install_append @@ -82,7 +79,7 @@ python do_compile () { # Build a separate executable for each splash image workdir = d.getVar('WORKDIR') convertscript = "%s/make-image-header.sh" % d.getVar('S') - destfile = "%s/psplash-poky-img.h" % d.getVar('S') + destfile = "%s/psplash-poky-img.h" % d.getVar('B') localfiles = d.getVar('SPLASH_LOCALPATHS').split() outputfiles = d.getVar('SPLASH_INSTALL').split() for localfile, outputfile in zip(localfiles, outputfiles): -- 2.24.1 From sjolley.yp.pm at gmail.com Mon Mar 2 19:45:51 2020 From: sjolley.yp.pm at gmail.com (sjolley.yp.pm at gmail.com) Date: Mon, 2 Mar 2020 11:45:51 -0800 Subject: [OE-core] Yocto Project Newcomer & Unassigned Bugs - Help Needed Message-ID: <0e9a01d5f0cb$2e828270$8b878750$@gmail.com> All, The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on the triage page under the appropriate heading: https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs The idea is these bugs should be straight forward for a person to help work on who doesn't have deep experience with the project. If anyone can help, please take ownership of the bug and send patches! If anyone needs help/advice there are people on irc who can likely do so, or some of the more experienced contributors will likely be happy to help too. Also, the triage team meets weekly and does its best to handle the bugs reported into the Bugzilla. The number of people attending that meeting has fallen, as have the number of people available to help fix bugs. One of the things we hear users report is they don't know how to help. We (the triage team) are therefore going to start reporting out the currently 291 unassigned or newcomer bugs. We're hoping people may be able to spare some time now and again to help out with these. Bugs are split into two types, "true bugs" where things don't work as they should and "enhancements" which are features we'd want to add to the system. There are also roughly four different "priority" classes right now, "3.1", "3.2, "3.99" and "Future", the more pressing/urgent issues being in "3.1" and then "3.2". Please review this link and if a bug is something you would be able to help with either take ownership of the bug, or send me (sjolley.yp.pm at gmail.com ) an e-mail with the bug number you would like and I will assign it to you (please make sure you have a Bugzilla account). The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer _Bugs Thanks, Stephen K. Jolley Yocto Project Program Manager * Cell: (208) 244-4460 * Email: sjolley.yp.pm at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From sjolley.yp.pm at gmail.com Mon Mar 2 21:07:36 2020 From: sjolley.yp.pm at gmail.com (sjolley.yp.pm at gmail.com) Date: Mon, 2 Mar 2020 13:07:36 -0800 Subject: [OE-core] Reminder: Yocto Project Technical Team Meeting @ Monthly from 8am on the first Tuesday (PDT) Message-ID: <0eec01d5f0d6$9a72f3b0$cf58db10$@gmail.com> All, Just a reminder we will hold the monthly Yocto Project Technical Meeting at 8am PST tomorrow. (3/3) Yocto Project Technical Team Meeting: We encourage people attending the meeting to logon and announce themselves on the Yocto Project IRC chancel during the meeting (optional): Yocto IRC: http://webchat.freenode.net/?channels=#yocto Wiki: https://www.yoctoproject.org/public-virtual-meetings/ When Monthly from 8am to 8:30am on the first Tuesday Pacific Time Where Zoom Meeting: https://zoom.us/j/990892712 I am tracking the minutes at: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9d DH4/edit?pli=1 Please request access if you want to assist in editing them. The world should have view access. Thanks, Stephen K. Jolley Yocto Project Program Manager * Cell: (208) 244-4460 * Email: sjolley.yp.pm at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard.purdie at linuxfoundation.org Mon Mar 2 21:08:27 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Mon, 02 Mar 2020 21:08:27 +0000 Subject: [OE-core] [PATCH 1/3] dbus-test: Fix QA host-contamination errors In-Reply-To: References: <20200301014301.805156-1-raj.khem@gmail.com> <20200301014301.805156-2-raj.khem@gmail.com> <6ebd8c098cac7dab116f9043e7b64fe9b3376601.camel@linuxfoundation.org> <7737c4f098af15087a434de3b1a09d8d651ebaa8.camel@linuxfoundation.org> <6ac648b5b9d02cb857e9d784d7bf95e071567ca1.camel@linuxfoundation.org> Message-ID: <62e5739220e0f491acd489c2abcc35213d91d138.camel@linuxfoundation.org> On Mon, 2020-03-02 at 10:49 -0800, Khem Raj wrote: > On 3/1/20 9:05 AM, Richard Purdie wrote: > > On Sun, 2020-03-01 at 08:20 +0000, Richard Purdie wrote: > > > On Sun, 2020-03-01 at 00:17 -0800, Khem Raj wrote: > > > I understand the need for the fixes, I'm just very concerned we > > > have > > > what amounts to undetected non-determinism in the build :( > > > > > > I'm more concerned about fixing that (and ensuring we can > > > detect/fix > > > all cases) than I am about the individual errors. > > > > I did a bit more thinking/checking on this. > > > > An interesting command to experiment with is: > > > > $ touch /tmp/test; ls -la /tmp/test; ./tmp/sysroots- > > components/x86_64/pseudo-native/usr/bin/pseudo sh -c "ls -la > > /tmp/test*; cp /tmp/test /tmp/test2; ls -la /tmp/test*; rm > > /tmp/test*" > > > > which for me shows: > > > > -rw-rw-r-- 1 richard richard 0 Mar 1 17:03 /tmp/test > > Warning: PSEUDO_PREFIX unset, defaulting to XXX./tmp/sysroots- > > components/x86_64/pseudo-native/usr. > > -rw-rw-r-- 1 1000 1000 0 Mar 1 17:03 /tmp/test > > -rw-rw-r-- 1 1000 1000 0 Mar 1 17:03 /tmp/test > > -rw-rw-r-- 1 0 0 0 Mar 1 17:03 /tmp/test2 > > > > Can you see if that is different on your two machines? > > above cmd output is exactly same as yours. > > -rw-r--r-- 1 build build 0 Mar 2 18:49 /tmp/test > Warning: PSEUDO_PREFIX unset, defaulting to > /mnt/b/yoe/build/./tmp/sysroots-components/x86_64/pseudo-native/usr. > -rw-r--r-- 1 1000 1000 0 Mar 2 18:49 /tmp/test > -rw-r--r-- 1 1000 1000 0 Mar 2 18:49 /tmp/test > -rw-r--r-- 1 0 0 0 Mar 2 18:49 /tmp/test2 Hmm, this means the test is flawed as we need to find out how /tmp/test2 becomes owned by 1000.1000. Any ideas how we can simplify this down to reproduce that? I did wonder if its coreutils-native was somehow creeping into DEPENDS and had a different config between your two hosts which was causing different behaviour but I'd need to check into whether that happens. Any other ideas why the behaviour difference or how to reproduce it? Cheers, Richard From raj.khem at gmail.com Mon Mar 2 21:33:42 2020 From: raj.khem at gmail.com (Khem Raj) Date: Mon, 2 Mar 2020 13:33:42 -0800 Subject: [OE-core] [PATCH 1/3] dbus-test: Fix QA host-contamination errors In-Reply-To: <62e5739220e0f491acd489c2abcc35213d91d138.camel@linuxfoundation.org> References: <20200301014301.805156-1-raj.khem@gmail.com> <20200301014301.805156-2-raj.khem@gmail.com> <6ebd8c098cac7dab116f9043e7b64fe9b3376601.camel@linuxfoundation.org> <7737c4f098af15087a434de3b1a09d8d651ebaa8.camel@linuxfoundation.org> <6ac648b5b9d02cb857e9d784d7bf95e071567ca1.camel@linuxfoundation.org> <62e5739220e0f491acd489c2abcc35213d91d138.camel@linuxfoundation.org> Message-ID: <7ad45b7f-cb58-a584-fdfb-aa9dca2862dd@gmail.com> On 3/2/20 1:08 PM, Richard Purdie wrote: > On Mon, 2020-03-02 at 10:49 -0800, Khem Raj wrote: >> On 3/1/20 9:05 AM, Richard Purdie wrote: >>> On Sun, 2020-03-01 at 08:20 +0000, Richard Purdie wrote: >>>> On Sun, 2020-03-01 at 00:17 -0800, Khem Raj wrote: >>>> I understand the need for the fixes, I'm just very concerned we >>>> have >>>> what amounts to undetected non-determinism in the build :( >>>> >>>> I'm more concerned about fixing that (and ensuring we can >>>> detect/fix >>>> all cases) than I am about the individual errors. >>> >>> I did a bit more thinking/checking on this. >>> >>> An interesting command to experiment with is: >>> >>> $ touch /tmp/test; ls -la /tmp/test; ./tmp/sysroots- >>> components/x86_64/pseudo-native/usr/bin/pseudo sh -c "ls -la >>> /tmp/test*; cp /tmp/test /tmp/test2; ls -la /tmp/test*; rm >>> /tmp/test*" >>> >>> which for me shows: >>> >>> -rw-rw-r-- 1 richard richard 0 Mar 1 17:03 /tmp/test >>> Warning: PSEUDO_PREFIX unset, defaulting to XXX./tmp/sysroots- >>> components/x86_64/pseudo-native/usr. >>> -rw-rw-r-- 1 1000 1000 0 Mar 1 17:03 /tmp/test >>> -rw-rw-r-- 1 1000 1000 0 Mar 1 17:03 /tmp/test >>> -rw-rw-r-- 1 0 0 0 Mar 1 17:03 /tmp/test2 >>> >>> Can you see if that is different on your two machines? >> >> above cmd output is exactly same as yours. >> >> -rw-r--r-- 1 build build 0 Mar 2 18:49 /tmp/test >> Warning: PSEUDO_PREFIX unset, defaulting to >> /mnt/b/yoe/build/./tmp/sysroots-components/x86_64/pseudo-native/usr. >> -rw-r--r-- 1 1000 1000 0 Mar 2 18:49 /tmp/test >> -rw-r--r-- 1 1000 1000 0 Mar 2 18:49 /tmp/test >> -rw-r--r-- 1 0 0 0 Mar 2 18:49 /tmp/test2 > > Hmm, this means the test is flawed as we need to find out how > /tmp/test2 becomes owned by 1000.1000. > > Any ideas how we can simplify this down to reproduce that? > Even on baremetal ubuntu 18.04 I am seeing dlm-4.0.9: dlm: /usr/lib/libdlmcontrol.so is owned by uid 3004, which is the same as the user running bitbake. This may be due to host contamination dlm: /usr/lib/libdlm_lt.so is owned by uid 3004, which is the same as the user running bitbake. This may be due to host contamination dlm: /usr/lib/libdlm.so is owned by uid 3004, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated] dlm-4.0.9: dlm: /usr/lib/libdlmcontrol.so.3 is owned by uid 3004, which is the same as the user running bitbake. This may be due to host contamination dlm: /usr/lib/libdlm_lt.so.3 is owned by uid 3004, which is the same as the user running bitbake. This may be due to host contamination dlm: /usr/lib/libdlm.so.3 is owned by uid 3004, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated] this might be again a dlm issue to fix. but perhaps a good one to try if AB system can build it without these QA diagnostics. dlm is in meta-networking. > I did wonder if its coreutils-native was somehow creeping into DEPENDS > and had a different config between your two hosts which was causing > different behaviour but I'd need to check into whether that happens. > > Any other ideas why the behaviour difference or how to reproduce it? > can you promote host-user-contaminated form QA warning to QA error in poky and see if builds fail ? > Cheers, > > Richard > > > > From bunk at stusta.de Mon Mar 2 21:34:41 2020 From: bunk at stusta.de (Adrian Bunk) Date: Mon, 2 Mar 2020 23:34:41 +0200 Subject: [OE-core] [PATCH] arch-arm64.inc: Do not append aarch64 in MACHINEOVERRIDES In-Reply-To: <666b3145-0e57-cf3c-f1f4-22d6fd0521e5@gmail.com> References: <20200302171153.28030-1-zhengjunling@huawei.com> <666b3145-0e57-cf3c-f1f4-22d6fd0521e5@gmail.com> Message-ID: <20200302213441.GA13148@localhost> On Mon, Mar 02, 2020 at 10:29:37AM -0800, Khem Raj wrote: > > > On 3/2/20 9:11 AM, Junling Zheng wrote: > > Currently, for arch-arm64, poky will append the MACHINEOVERRIDES with > > "aarch64:", which has the higher priority than TRANSLATED_TARGET_ARCH. > > So, for aarch64 big endian, the variable '_aarch64' will override > > not only '', but also '_aarch64-be', thus we will get an > > incorrect variable. > > > > Signed-off-by: Junling Zheng > > --- > > meta/conf/machine/include/arm/arch-arm64.inc | 2 -- > > 1 file changed, 2 deletions(-) > > > > diff --git a/meta/conf/machine/include/arm/arch-arm64.inc b/meta/conf/machine/include/arm/arch-arm64.inc > > index 53f4566815..32294bd218 100644 > > --- a/meta/conf/machine/include/arm/arch-arm64.inc > > +++ b/meta/conf/machine/include/arm/arch-arm64.inc > > @@ -4,8 +4,6 @@ require conf/machine/include/arm/arch-armv7ve.inc > > TUNEVALID[aarch64] = "Enable instructions for aarch64" > > -MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'aarch64', 'aarch64:', '' ,d)}" > > - > > if its removed here, where is it being added for other machines, question > is, should we treat aarch64 as LE equivalent of aarch64_be > or should be treated as common aarch64 and a new define like aarch64_le > defined. >... As far as I am aware all other distributions and config.guess are treating aarch64/arm64 as little endian and 64bit, unless suffixed. cu Adrian From richard.purdie at linuxfoundation.org Mon Mar 2 21:43:56 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Mon, 02 Mar 2020 21:43:56 +0000 Subject: [OE-core] [PATCH 1/3] dbus-test: Fix QA host-contamination errors In-Reply-To: <7ad45b7f-cb58-a584-fdfb-aa9dca2862dd@gmail.com> References: <20200301014301.805156-1-raj.khem@gmail.com> <20200301014301.805156-2-raj.khem@gmail.com> <6ebd8c098cac7dab116f9043e7b64fe9b3376601.camel@linuxfoundation.org> <7737c4f098af15087a434de3b1a09d8d651ebaa8.camel@linuxfoundation.org> <6ac648b5b9d02cb857e9d784d7bf95e071567ca1.camel@linuxfoundation.org> <62e5739220e0f491acd489c2abcc35213d91d138.camel@linuxfoundation.org> <7ad45b7f-cb58-a584-fdfb-aa9dca2862dd@gmail.com> Message-ID: <6327a5cd07b661cb2f883256ed18d45a324cd0ba.camel@linuxfoundation.org> On Mon, 2020-03-02 at 13:33 -0800, Khem Raj wrote: > > On 3/2/20 1:08 PM, Richard Purdie wrote: > > On Mon, 2020-03-02 at 10:49 -0800, Khem Raj wrote: > > > On 3/1/20 9:05 AM, Richard Purdie wrote: > > > > On Sun, 2020-03-01 at 08:20 +0000, Richard Purdie wrote: > > > > > On Sun, 2020-03-01 at 00:17 -0800, Khem Raj wrote: > > > > > I understand the need for the fixes, I'm just very concerned > > > > > we > > > > > have > > > > > what amounts to undetected non-determinism in the build :( > > > > > > > > > > I'm more concerned about fixing that (and ensuring we can > > > > > detect/fix > > > > > all cases) than I am about the individual errors. > > > > > > > > I did a bit more thinking/checking on this. > > > > > > > > An interesting command to experiment with is: > > > > > > > > $ touch /tmp/test; ls -la /tmp/test; ./tmp/sysroots- > > > > components/x86_64/pseudo-native/usr/bin/pseudo sh -c "ls -la > > > > /tmp/test*; cp /tmp/test /tmp/test2; ls -la /tmp/test*; rm > > > > /tmp/test*" > > > > > > > > which for me shows: > > > > > > > > -rw-rw-r-- 1 richard richard 0 Mar 1 17:03 /tmp/test > > > > Warning: PSEUDO_PREFIX unset, defaulting to XXX./tmp/sysroots- > > > > components/x86_64/pseudo-native/usr. > > > > -rw-rw-r-- 1 1000 1000 0 Mar 1 17:03 /tmp/test > > > > -rw-rw-r-- 1 1000 1000 0 Mar 1 17:03 /tmp/test > > > > -rw-rw-r-- 1 0 0 0 Mar 1 17:03 /tmp/test2 > > > > > > > > Can you see if that is different on your two machines? > > > > > > above cmd output is exactly same as yours. > > > > > > -rw-r--r-- 1 build build 0 Mar 2 18:49 /tmp/test > > > Warning: PSEUDO_PREFIX unset, defaulting to > > > /mnt/b/yoe/build/./tmp/sysroots-components/x86_64/pseudo- > > > native/usr. > > > -rw-r--r-- 1 1000 1000 0 Mar 2 18:49 /tmp/test > > > -rw-r--r-- 1 1000 1000 0 Mar 2 18:49 /tmp/test > > > -rw-r--r-- 1 0 0 0 Mar 2 18:49 /tmp/test2 > > > > Hmm, this means the test is flawed as we need to find out how > > /tmp/test2 becomes owned by 1000.1000. > > > > Any ideas how we can simplify this down to reproduce that? > > > > Even on baremetal ubuntu 18.04 I am seeing > > dlm-4.0.9: dlm: /usr/lib/libdlmcontrol.so is owned by uid 3004, which is > the same as the user running bitbake. This may be due to host contamination > dlm: /usr/lib/libdlm_lt.so is owned by uid 3004, which is the same as > the user running bitbake. This may be due to host contamination > dlm: /usr/lib/libdlm.so is owned by uid 3004, which is the same as the > user running bitbake. This may be due to host contamination > [host-user-contaminated] > dlm-4.0.9: dlm: /usr/lib/libdlmcontrol.so.3 is owned by uid 3004, which > is the same as the user running bitbake. This may be due to host > contamination > dlm: /usr/lib/libdlm_lt.so.3 is owned by uid 3004, which is the same as > the user running bitbake. This may be due to host contamination > dlm: /usr/lib/libdlm.so.3 is owned by uid 3004, which is the same as the > user running bitbake. This may be due to host contamination > [host-user-contaminated] > > this might be again a dlm issue to fix. but perhaps a good one to > try if AB system can build it without these QA diagnostics. > > dlm is in meta-networking. That could well be a dlm recipe bug. I'm more interested in the ones which reproducibly break on one machine but work on another. > > I did wonder if its coreutils-native was somehow creeping into > > DEPENDS > > and had a different config between your two hosts which was causing > > different behaviour but I'd need to check into whether that > > happens. > > > > Any other ideas why the behaviour difference or how to reproduce > > it? > > > > can you promote host-user-contaminated form QA warning to QA error > in poky and see if builds fail ? As its already a warning, we'd see it on the autobuilder. *Any* warning turns the build orange rather than green. We don't any warnings in core builds, we fixed them all. This is why I know its not happening on the autobuilder... Cheers, Richard From zhengjunling at huawei.com Tue Mar 3 03:10:45 2020 From: zhengjunling at huawei.com (Junling Zheng) Date: Tue, 3 Mar 2020 11:10:45 +0800 Subject: [OE-core] [PATCH] arch-arm64.inc: Do not append aarch64 in MACHINEOVERRIDES In-Reply-To: <666b3145-0e57-cf3c-f1f4-22d6fd0521e5@gmail.com> References: <20200302171153.28030-1-zhengjunling@huawei.com> <666b3145-0e57-cf3c-f1f4-22d6fd0521e5@gmail.com> Message-ID: <9d41cd5d-7355-175d-391c-35231c9a7e92@huawei.com> On 2020/3/3 2:29, Khem Raj wrote: > > > On 3/2/20 9:11 AM, Junling Zheng wrote: >> Currently, for arch-arm64, poky will append the MACHINEOVERRIDES with >> "aarch64:", which has the higher priority than TRANSLATED_TARGET_ARCH. >> So, for aarch64 big endian, the variable '_aarch64' will override >> not only '', but also '_aarch64-be', thus we will get an >> incorrect variable. >> >> Signed-off-by: Junling Zheng >> --- >> meta/conf/machine/include/arm/arch-arm64.inc | 2 -- >> 1 file changed, 2 deletions(-) >> >> diff --git a/meta/conf/machine/include/arm/arch-arm64.inc b/meta/conf/machine/include/arm/arch-arm64.inc >> index 53f4566815..32294bd218 100644 >> --- a/meta/conf/machine/include/arm/arch-arm64.inc >> +++ b/meta/conf/machine/include/arm/arch-arm64.inc >> @@ -4,8 +4,6 @@ require conf/machine/include/arm/arch-armv7ve.inc >> TUNEVALID[aarch64] = "Enable instructions for aarch64" >> -MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'aarch64', 'aarch64:', '' ,d)}" >> - > > if its removed here, where is it being added for other machines, question is, should we treat aarch64 as LE equivalent of aarch64_be > or should be treated as common aarch64 and a new define like aarch64_le defined. > Currently, for arm64, we have aarch64_be to represent big endian, but no overrides to represent little endian only. So, IMO, we should treat aarch64 as little enaian only, like arm and armeb. >> # Little Endian base configs >> AVAILTUNES += "aarch64 aarch64_be" >> ARMPKGARCH_tune-aarch64 ?= "aarch64" >> > > From Mingli.Yu at windriver.com Tue Mar 3 03:11:00 2020 From: Mingli.Yu at windriver.com (Yu, Mingli) Date: Tue, 3 Mar 2020 03:11:00 +0000 Subject: [OE-core] bash: Fix CVE-2019-18276 In-Reply-To: <41e8a2902bc8594a17f0afa1744f04a6facd5316.camel@intel.com> References: <4f09ab13-9571-3464-2fc3-334bc91b9c09@case.edu> <444185BB2F013F4E92378F99BCF8A58BC9AF9CBD@ALA-MBD.corp.ad.wrs.com> <99d34efd-3a68-0b05-0e15-fbfd360a2f2a@case.edu> <9b99752af2094590137fdaacf6668f170b34158c.camel@linuxfoundation.org>, <41e8a2902bc8594a17f0afa1744f04a6facd5316.camel@intel.com> Message-ID: Hi Anuj, I agree the Backport status is not accurate as the patch doesn't go to master branch, but why do you say the patch is irrelevant to the CVE-2019-18276, could you help to provide more info? Hi Chet, Does https://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel&id=951bdaad7a18cc0dc1036bba86b18b90874d39ff fix the issue reported in CVE-2019-18276? Could you help to provide some info here? Thanks, Mingli ________________________________________ From: openembedded-core-bounces at lists.openembedded.org [openembedded-core-bounces at lists.openembedded.org] on behalf of Mittal, Anuj [anuj.mittal at intel.com] Sent: Tuesday, February 18, 2020 11:43 PM To: chet.ramey at case.edu; richard.purdie at linuxfoundation.org; openembedded-core at lists.openembedded.org; Huo, De; preid at electromag.com.au; akuster808 at gmail.com Subject: Re: [OE-core] bash: Fix CVE-2019-18276 On Tue, 2020-02-18 at 15:35 +0000, Richard Purdie wrote: > On Tue, 2020-02-18 at 10:28 -0500, Chet Ramey wrote: > > On 2/17/20 9:46 PM, Huo, De wrote: > > > I applied the patch to fix CVE defect CVE-2019-18276. > > > > That's not exactly an answer to the question of who produced the > > patch. > > If that patch is the one causing failures when it's applied, > > doesn't it > > make sense to go back to the person who produced it and ask them to > > update it if necessary? > > Its likely a general CVE patch where both configure and configure.ac > are patched. For OE, we can drop the configure part since we > reautoconf > the code. Its therefore the OE port of the patch which is likely at > fault. > > Someone just needs to remove that section of the patch. There are other issues with this patch which should also be fixed I think. It has been marked as a Backport while it is not one. The patch includes changes that are irrelevant to the CVE. And, it should have gone to master first. Thanks, Anuj -- _______________________________________________ Openembedded-core mailing list Openembedded-core at lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core From zhengjunling at huawei.com Tue Mar 3 03:22:32 2020 From: zhengjunling at huawei.com (Junling Zheng) Date: Tue, 3 Mar 2020 11:22:32 +0800 Subject: [OE-core] [RESEND PATCH 1/2] security_flags: Remove stack protector flags from LDFLAGS In-Reply-To: References: <20200302171744.30713-1-zhengjunling@huawei.com> Message-ID: On 2020/3/3 2:40, Khem Raj wrote: > > > On 3/2/20 9:17 AM, Junling Zheng wrote: >> The stack protector flag is a compile option, not a link option, so >> remove it from LDFLAGS. > > we use compiler driver to do linking as well, what does this change fix for you. > I know that we use gcc to do linking, and this is just a code cleaning, not a bugfix :) >> >> Signed-off-by: Junling Zheng >> --- >> meta/conf/distro/include/security_flags.inc | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/meta/conf/distro/include/security_flags.inc b/meta/conf/distro/include/security_flags.inc >> index aaf04e9e59..5b79340be9 100644 >> --- a/meta/conf/distro/include/security_flags.inc >> +++ b/meta/conf/distro/include/security_flags.inc >> @@ -26,8 +26,8 @@ SECURITY_STACK_PROTECTOR ?= "-fstack-protector-strong" >> SECURITY_CFLAGS ?= "${SECURITY_STACK_PROTECTOR} ${SECURITY_PIE_CFLAGS} ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}" >> SECURITY_NO_PIE_CFLAGS ?= "${SECURITY_STACK_PROTECTOR} ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}" >> -SECURITY_LDFLAGS ?= "${SECURITY_STACK_PROTECTOR} -Wl,-z,relro,-z,now" >> -SECURITY_X_LDFLAGS ?= "${SECURITY_STACK_PROTECTOR} -Wl,-z,relro" >> +SECURITY_LDFLAGS ?= "-Wl,-z,relro,-z,now" >> +SECURITY_X_LDFLAGS ?= "-Wl,-z,relro" >> # powerpc does not get on with pie for reasons not looked into as yet >> GCCPIE_powerpc = "" >> > > From akuster808 at gmail.com Tue Mar 3 04:17:58 2020 From: akuster808 at gmail.com (akuster808) Date: Mon, 2 Mar 2020 20:17:58 -0800 Subject: [OE-core] M3 build status In-Reply-To: References: Message-ID: <47102fa1-dd23-b5ce-1fcb-d05d97d74794@gmail.com> On 3/2/20 8:47 AM, Richard Purdie wrote: > On Sat, 2020-02-29 at 07:38 -0800, akuster808 wrote: >> On 2/29/20 5:13 AM, Richard Purdie wrote: >>> Just to quickly update everyone, a number of patches we probably >>> wanted >>> in 3.1 have had issues but have had the issues resolved and the >>> patches >>> have now merged. Thanks to all who dived in and helped with those! >> So no Bind update? > There is still time, please send an updated patch! Its unclear to me what change is outstanding. - armin > >>> The patches/issues I'm aware of that are left: >>> >>> * ltp upgrade (musl issue) >>> * util-linux upgrade (breaks wic test, probably simple fix) >> I can look at the two above but can't start until Sunday so if >> someone else grabs them today, have at it. > These are now done thankfully. > >>> * coreutils ptest addition (blocked on libmodule-build-per >>> reproducibility issue) > Still not done. > >>> * psplash systemd race (smurray may have a fix) > Still not done. > >>> * autobuilder new branch handling for initial run test comparisons >>> (open high bug with RP) >>> * tinfoil race (open high bug, struggling for owner) > Both done. > >>> * LockedSigs intermittent test failure (RP has open high bug, no >>> clue >>> how to reproduce or why, total mystery) > Spent hours on this, limited success :( > >>> * Intermittent selftest failure with SystemExit (High open bug, >>> Kai owns) > Still pending. > >>> As ever, help with any of these welcome. We'll build M3 when a >>> majority of the above are ready. > Also, I've realised: > * there is a high priority pseudo issue assigned to me > * gcc buildtools tarball issue > > + the bind issue you mention > >> So where are patches going doing this time that will be in after the >> release? > I try not to encourage people to send upgrade patches during > stabilisation as its a distraction for everyone and means fewer people > caring about the release. I have had to queue them in the past since > people ignore this and I may have to again depending on what people do > :(. > > Cheers, > > Richard > > > > > From richard.purdie at linuxfoundation.org Tue Mar 3 07:01:17 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Tue, 03 Mar 2020 07:01:17 +0000 Subject: [OE-core] M3 build status In-Reply-To: <47102fa1-dd23-b5ce-1fcb-d05d97d74794@gmail.com> References: <47102fa1-dd23-b5ce-1fcb-d05d97d74794@gmail.com> Message-ID: <1c358709eca41c0607ba0301bdaa45b01da2e454.camel@linuxfoundation.org> On Mon, 2020-03-02 at 20:17 -0800, akuster808 wrote: > > On 3/2/20 8:47 AM, Richard Purdie wrote: > > On Sat, 2020-02-29 at 07:38 -0800, akuster808 wrote: > > > On 2/29/20 5:13 AM, Richard Purdie wrote: > > > > Just to quickly update everyone, a number of patches we > > > > probably > > > > wanted > > > > in 3.1 have had issues but have had the issues resolved and the > > > > patches > > > > have now merged. Thanks to all who dived in and helped with > > > > those! > > > So no Bind update? > > There is still time, please send an updated patch! > Its unclear to me what change is outstanding. libuv maintainer entry? If I merge what is there if will break builds :( Cheers, Richard From wallinux at gmail.com Tue Mar 3 07:51:32 2020 From: wallinux at gmail.com (Anders Wallin) Date: Tue, 3 Mar 2020 08:51:32 +0100 Subject: [OE-core] [PATCH] babeltrace: only check latest git tag version for 1.x.x Message-ID: <20200303075132.25849-1-wallinux@gmail.com> version 2.x.x will be added with a new babeltrace2 recipe Signed-off-by: Anders Wallin --- meta/recipes-kernel/lttng/babeltrace_1.5.8.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-kernel/lttng/babeltrace_1.5.8.bb b/meta/recipes-kernel/lttng/babeltrace_1.5.8.bb index c050dc674d..3268c5de9c 100644 --- a/meta/recipes-kernel/lttng/babeltrace_1.5.8.bb +++ b/meta/recipes-kernel/lttng/babeltrace_1.5.8.bb @@ -11,7 +11,7 @@ SRC_URI = "git://git.linuxfoundation.org/diamon/babeltrace.git;branch=stable-1.5 file://run-ptest \ " SRCREV = "054a54ae10b01a271afc4f19496c041b10fb414c" -UPSTREAM_CHECK_GITTAGREGEX = "v(?P\d+(\.\d+)+)$" +UPSTREAM_CHECK_GITTAGREGEX = "v(?P1+(\.\d+)+)$" S = "${WORKDIR}/git" -- 2.25.1 From peter.kjellerstedt at axis.com Tue Mar 3 11:21:42 2020 From: peter.kjellerstedt at axis.com (Peter Kjellerstedt) Date: Tue, 3 Mar 2020 11:21:42 +0000 Subject: [OE-core] [PATCH] python3-scons: Fix license file collision In-Reply-To: <20200229161603.495994-1-richard.purdie@linuxfoundation.org> References: <20200229161603.495994-1-richard.purdie@linuxfoundation.org> Message-ID: <390fd7bab651456084420a36a41478a4@XBOX03.axis.com> > -----Original Message----- > From: openembedded-core-bounces at lists.openembedded.org On Behalf Of Richard Purdie > Sent: den 29 februari 2020 17:16 > To: openembedded-core at lists.openembedded.org > Subject: [OE-core] [PATCH] python3-scons: Fix license file collision > > Downloading a file called "LICENSE" into DL_DIR is 'problematic' and collides with the > file from other versions of the recipe at best. > > Rename it to something more specific to avoid collision problems. > > Signed-off-by: Richard Purdie > --- > meta/recipes-devtools/python/python3-scons_3.1.2.bb | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/meta/recipes-devtools/python/python3-scons_3.1.2.bb b/meta/recipes-devtools/python/python3-scons_3.1.2.bb > index aa7a2a8300d..ce117a92d4f 100644 > --- a/meta/recipes-devtools/python/python3-scons_3.1.2.bb > +++ b/meta/recipes-devtools/python/python3-scons_3.1.2.bb > @@ -1,10 +1,10 @@ > SUMMARY = "Software Construction tool (make/autotools replacement)" > SECTION = "devel/python" > LICENSE = "MIT" > -LIC_FILES_CHKSUM = "file://${WORKDIR}/LICENSE;md5=e14e1b33428df24a40a782ae142785d0" > +LIC_FILES_CHKSUM = "file://${WORKDIR}/LICENSE-python3-scons-${PV};md5=e14e1b33428df24a40a782ae142785d0" > > # pypi package does not have a valid license file > -SRC_URI += "https://raw.githubusercontent.com/SCons/scons/${PV}/LICENSE;name=license" > +SRC_URI += "https://raw.githubusercontent.com/SCons/scons/${PV}/LICENSE;downloadfilename=LICENSE-python3-scons-${PV};name=license" Any reason to not use "${BP}" instead of "python3-scons-${PV}" above? Or should I send a cleanup patch? > > SRC_URI[md5sum] = "f9c4ad06dcf1427be95472eaf380c81a" > SRC_URI[sha256sum] = "8aaa483c303efeb678e6f7c776c8444a482f8ddc3ad891f8b6cdd35264da9a1f" > -- > 2.25.0 //Peter From peter.kjellerstedt at axis.com Tue Mar 3 11:59:58 2020 From: peter.kjellerstedt at axis.com (Peter Kjellerstedt) Date: Tue, 3 Mar 2020 11:59:58 +0000 Subject: [OE-core] [PATCH] arch-arm64.inc: Do not append aarch64 in MACHINEOVERRIDES In-Reply-To: <9d41cd5d-7355-175d-391c-35231c9a7e92@huawei.com> References: <20200302171153.28030-1-zhengjunling@huawei.com> <666b3145-0e57-cf3c-f1f4-22d6fd0521e5@gmail.com> <9d41cd5d-7355-175d-391c-35231c9a7e92@huawei.com> Message-ID: <41b7391039564f10a0c8b4f63eeb4274@XBOX03.axis.com> > -----Original Message----- > From: openembedded-core-bounces at lists.openembedded.org bounces at lists.openembedded.org> On Behalf Of Junling Zheng > Sent: den 3 mars 2020 04:11 > To: Khem Raj ; openembedded- > core at lists.openembedded.org > Cc: wangnan0 at huawei.com > Subject: Re: [OE-core] [PATCH] arch-arm64.inc: Do not append aarch64 in > MACHINEOVERRIDES > > On 2020/3/3 2:29, Khem Raj wrote: > > > > > > On 3/2/20 9:11 AM, Junling Zheng wrote: > >> Currently, for arch-arm64, poky will append the MACHINEOVERRIDES with > >> "aarch64:", which has the higher priority than TRANSLATED_TARGET_ARCH. > >> So, for aarch64 big endian, the variable '_aarch64' will override > >> not only '', but also '_aarch64-be', thus we will get an > >> incorrect variable. > >> > >> Signed-off-by: Junling Zheng > >> --- > >> meta/conf/machine/include/arm/arch-arm64.inc | 2 -- > >> 1 file changed, 2 deletions(-) > >> > >> diff --git a/meta/conf/machine/include/arm/arch-arm64.inc > b/meta/conf/machine/include/arm/arch-arm64.inc > >> index 53f4566815..32294bd218 100644 > >> --- a/meta/conf/machine/include/arm/arch-arm64.inc > >> +++ b/meta/conf/machine/include/arm/arch-arm64.inc > >> @@ -4,8 +4,6 @@ require conf/machine/include/arm/arch-armv7ve.inc > >> TUNEVALID[aarch64] = "Enable instructions for aarch64" > >> -MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'aarch64', 'aarch64:', '' ,d)}" > >> - > > > > if its removed here, where is it being added for other machines, > question is, should we treat aarch64 as LE equivalent of aarch64_be > > or should be treated as common aarch64 and a new define like aarch64_le > defined. > > > > Currently, for arm64, we have aarch64_be to represent big endian, but no > overrides to represent little endian only. > > So, IMO, we should treat aarch64 as little enaian only, like arm and > armeb. > > >> # Little Endian base configs > >> AVAILTUNES += "aarch64 aarch64_be" > >> ARMPKGARCH_tune-aarch64 ?= "aarch64" Please, before removing "aarch64" from MACHINEOVERRIDES, add "armv8a" or similar. This is how it is done for the armv7* based chips. E.g., I would expect to see tune-cortexa53.inc have: MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'cortexa53', 'armv8a:', '' ,d)}" Which corresponds to how it is done for armv7*. At least we currently rely on being able to do, e.g.: COMPATIBLE_MACHINE = "aarch64|armv7a|armv7ve" and if you remove "aarch64" from MACHINEOVERRIDES, we need a suitable substitute. //Peter From peter.kjellerstedt at axis.com Tue Mar 3 12:29:10 2020 From: peter.kjellerstedt at axis.com (Peter Kjellerstedt) Date: Tue, 3 Mar 2020 12:29:10 +0000 Subject: [OE-core] [PATCH] babeltrace: only check latest git tag version for 1.x.x In-Reply-To: <20200303075132.25849-1-wallinux@gmail.com> References: <20200303075132.25849-1-wallinux@gmail.com> Message-ID: <6fd917f010304276a503801ab9c2c40f@XBOX03.axis.com> > -----Original Message----- > From: openembedded-core-bounces at lists.openembedded.org bounces at lists.openembedded.org> On Behalf Of Anders Wallin > Sent: den 3 mars 2020 08:52 > To: openembedded-core at lists.openembedded.org > Subject: [OE-core] [PATCH] babeltrace: only check latest git tag version > for 1.x.x > > version 2.x.x will be added with a new babeltrace2 recipe > > Signed-off-by: Anders Wallin > --- > meta/recipes-kernel/lttng/babeltrace_1.5.8.bb | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/meta/recipes-kernel/lttng/babeltrace_1.5.8.bb b/meta/recipes- > kernel/lttng/babeltrace_1.5.8.bb > index c050dc674d..3268c5de9c 100644 > --- a/meta/recipes-kernel/lttng/babeltrace_1.5.8.bb > +++ b/meta/recipes-kernel/lttng/babeltrace_1.5.8.bb > @@ -11,7 +11,7 @@ SRC_URI = > "git://git.linuxfoundation.org/diamon/babeltrace.git;branch=stable-1.5 > file://run-ptest \ > " > SRCREV = "054a54ae10b01a271afc4f19496c041b10fb414c" > -UPSTREAM_CHECK_GITTAGREGEX = "v(?P\d+(\.\d+)+)$" > +UPSTREAM_CHECK_GITTAGREGEX = "v(?P1+(\.\d+)+)$" Change "1+" to "1" or you will match, e.g., "11" and "111". > > S = "${WORKDIR}/git" > > -- > 2.25.1 //Peter From peter.kjellerstedt at axis.com Tue Mar 3 12:32:52 2020 From: peter.kjellerstedt at axis.com (Peter Kjellerstedt) Date: Tue, 3 Mar 2020 12:32:52 +0000 Subject: [OE-core] how to cleanly centralize a zillion BBCLASSEXTEND += "nativesdk" settings? In-Reply-To: <20200302074035.Horde.5xguZSt_-_Yd241eE1Zo8Pb@crashcourse.ca> References: <20200302074035.Horde.5xguZSt_-_Yd241eE1Zo8Pb@crashcourse.ca> Message-ID: <52350a7bd080413c9dbc6e1783f14e2c@XBOX03.axis.com> > -----Original Message----- > From: openembedded-core-bounces at lists.openembedded.org bounces at lists.openembedded.org> On Behalf Of rpjday at crashcourse.ca > Sent: den 2 mars 2020 13:41 > To: openembedded-core at lists.openembedded.org > Subject: [OE-core] how to cleanly centralize a zillion BBCLASSEXTEND += > "nativesdk" settings? > > layer i'm currently perusing has many, many bbappend files, of which > quite a number are nothing more than the single line: > > BBCLASSEXTEND += "nativesdk" > > literally, at least a hundred append files are like that. so rather > than clutter up the layer with all those trivial .bbappend files, > can one cram all that into a single .conf file? as i read it, can i > do something like: > > BBCLASSEXTEND_append_pn-pkg1 = " nativesdk" > BBCLASSEXTEND_append_pn-pkg2 = " nativesdk" > ... and on and on ... > > and toss all that into a distro.conf file or something? > > and even if that works, is it considered good coding style? > > rday Sounds perfectly fine. We do something similar, but in our case we need to add "native" to BBCLASSEXTEND for a whole bunch of recipes. //Peter From richard.purdie at linuxfoundation.org Tue Mar 3 13:05:04 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Tue, 3 Mar 2020 13:05:04 +0000 Subject: [OE-core] [PATCH] systemd: Fix service file for race issues Message-ID: <20200303130504.714554-1-richard.purdie@linuxfoundation.org> It seems this service needs both Requires: and After: according to the definitions in the systemd docs, else we see boot race failures. Signed-off-by: Richard Purdie --- meta/recipes-core/psplash/files/psplash-systemd.service | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/recipes-core/psplash/files/psplash-systemd.service b/meta/recipes-core/psplash/files/psplash-systemd.service index 249aa540394..4e18980bb27 100644 --- a/meta/recipes-core/psplash/files/psplash-systemd.service +++ b/meta/recipes-core/psplash/files/psplash-systemd.service @@ -2,6 +2,7 @@ Description=Start psplash-systemd progress communication helper DefaultDependencies=no After=systemd-start.service +After=psplash-start.service Requires=psplash-start.service RequiresMountsFor=/run -- 2.25.0 From herve.jourdain at neuf.fr Tue Mar 3 13:05:19 2020 From: herve.jourdain at neuf.fr (Herve Jourdain) Date: Tue, 3 Mar 2020 14:05:19 +0100 Subject: [OE-core] [PATCH] arch-arm64.inc: Do not append aarch64 in MACHINEOVERRIDES In-Reply-To: <41b7391039564f10a0c8b4f63eeb4274@XBOX03.axis.com> References: <20200302171153.28030-1-zhengjunling@huawei.com> <666b3145-0e57-cf3c-f1f4-22d6fd0521e5@gmail.com> <9d41cd5d-7355-175d-391c-35231c9a7e92@huawei.com> <41b7391039564f10a0c8b4f63eeb4274@XBOX03.axis.com> Message-ID: <000501d5f15c$6e210280$4a630780$@neuf.fr> Hi, Just my 2 cents about this. armv8-a is the architecture of the arm core, while aarch64/aarch32 is the execution mode on said architecture. So I believe that we should have overrides for BOTH the architecture and the execution mode, as you can have armv8-a executing in 32 bits mode - and btw, the instruction set in 32 bits mode is not exactly the same as armv7-ve, so in terms of optimization it does help to know you're running on an armv8-a architecture, even if it's in 32 bits mode. There was no such problem before armv8-a architecture, since all previous architectures were running in 32 bits mode only. Armv8-a changes that as it's a "hybrid", with support for both aarch64 and aarch32. I expect later arch to support only aarch64. There is also an additional thing to consider, there is not just one armv8-a profiles, there already are several, and they shall all be taken into account. I believe that at this time, the valid ones are armv8.0-a, armv8.1-a, armv8.2-a, armv8.3-a and armv8.4-a. And let me answer before someone asks, yes the gcc compiler DOES provide compiler options for all those architectures, with those exact names - except armv8.0-a is just named armv8-a (-march=armv8-a or -march=armv8.[1,2,3,4]-a). So it just makes sense to support them all. So overall, I believe we should support all those arm v8 architectures, and add the corresponding override to the cpu definition files (for instance, as Peter mentioned, cortex-a53 is an armv8.0-a. But a cortex-a55 or cortex-a75 would be an armv8.2-a). Finally, the arm architecture is slightly more complex than just armv8.x-a, since the support for "features" is optional. So at least "crc" and "crypto" features should be added, in order to have a "comprehensive" view of the armv8 architecture. And yes, the "features" are also supported by the gcc compiler. So the arm architecture would really be fully defined by armv8.x-a+[no]crc+[no]crypto, depending on the underlying SoC and what they implemented or not as optional features. And this is probably what should end up going into the tune-cortexa53.inc and others (and should be override-able, since again not all cortexa53 are created the same). Cheers, Herve -----Original Message----- From: openembedded-core-bounces at lists.openembedded.org On Behalf Of Peter Kjellerstedt Sent: 03 March 2020 13:00 To: Junling Zheng ; Khem Raj ; openembedded-core at lists.openembedded.org Cc: wangnan0 at huawei.com Subject: Re: [OE-core] [PATCH] arch-arm64.inc: Do not append aarch64 in MACHINEOVERRIDES > -----Original Message----- > From: openembedded-core-bounces at lists.openembedded.org > On Behalf Of > Junling Zheng > Sent: den 3 mars 2020 04:11 > To: Khem Raj ; openembedded- > core at lists.openembedded.org > Cc: wangnan0 at huawei.com > Subject: Re: [OE-core] [PATCH] arch-arm64.inc: Do not append aarch64 > in MACHINEOVERRIDES > > On 2020/3/3 2:29, Khem Raj wrote: > > > > > > On 3/2/20 9:11 AM, Junling Zheng wrote: > >> Currently, for arch-arm64, poky will append the MACHINEOVERRIDES > >> with "aarch64:", which has the higher priority than TRANSLATED_TARGET_ARCH. > >> So, for aarch64 big endian, the variable '_aarch64' will > >> override not only '', but also '_aarch64-be', thus we > >> will get an incorrect variable. > >> > >> Signed-off-by: Junling Zheng > >> --- > >> meta/conf/machine/include/arm/arch-arm64.inc | 2 -- > >> 1 file changed, 2 deletions(-) > >> > >> diff --git a/meta/conf/machine/include/arm/arch-arm64.inc > b/meta/conf/machine/include/arm/arch-arm64.inc > >> index 53f4566815..32294bd218 100644 > >> --- a/meta/conf/machine/include/arm/arch-arm64.inc > >> +++ b/meta/conf/machine/include/arm/arch-arm64.inc > >> @@ -4,8 +4,6 @@ require conf/machine/include/arm/arch-armv7ve.inc > >> TUNEVALID[aarch64] = "Enable instructions for aarch64" > >> -MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'aarch64', 'aarch64:', '' ,d)}" > >> - > > > > if its removed here, where is it being added for other machines, > question is, should we treat aarch64 as LE equivalent of aarch64_be > > or should be treated as common aarch64 and a new define like > > aarch64_le > defined. > > > > Currently, for arm64, we have aarch64_be to represent big endian, but > no overrides to represent little endian only. > > So, IMO, we should treat aarch64 as little enaian only, like arm and > armeb. > > >> # Little Endian base configs > >> AVAILTUNES += "aarch64 aarch64_be" > >> ARMPKGARCH_tune-aarch64 ?= "aarch64" Please, before removing "aarch64" from MACHINEOVERRIDES, add "armv8a" or similar. This is how it is done for the armv7* based chips. E.g., I would expect to see tune-cortexa53.inc have: MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'cortexa53', 'armv8a:', '' ,d)}" Which corresponds to how it is done for armv7*. At least we currently rely on being able to do, e.g.: COMPATIBLE_MACHINE = "aarch64|armv7a|armv7ve" and if you remove "aarch64" from MACHINEOVERRIDES, we need a suitable substitute. //Peter -- _______________________________________________ Openembedded-core mailing list Openembedded-core at lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core From peter.kjellerstedt at axis.com Tue Mar 3 13:15:45 2020 From: peter.kjellerstedt at axis.com (Peter Kjellerstedt) Date: Tue, 3 Mar 2020 13:15:45 +0000 Subject: [OE-core] is there ever a compelling reason for "FILESEXTRAPATHS_append := ..."? In-Reply-To: References: Message-ID: <673fe5c88b2842ea8a023562a2043be3@XBOX03.axis.com> > -----Original Message----- > From: openembedded-core-bounces at lists.openembedded.org bounces at lists.openembedded.org> On Behalf Of Robert P. J. Day > Sent: den 1 mars 2020 12:51 > To: OE Core mailing list > Subject: Re: [OE-core] is there ever a compelling reason for > "FILESEXTRAPATHS_append := ..."? > > On Sun, 1 Mar 2020, Robert P. J. Day wrote: > > > > > occasionally, i run across an existing bbappend file which contains > > > > FILESEXTRAPATHS_append := ... > > > > and that makes me nervous as i don't see the rationale in *appending* > > to that variable in a bbappend file -- seems to defeat the purpose of > > potentially overriding what's in the original .bb recipe. > > > > now, sometimes it's obvious that it's broken as i'm currently > > looking at an example: > > > > FILESEXTRAPATHS_append := "${THISDIR}/${PN}:" > > > > which makes no sense at all with the colon at the end. but other than > > something so clearly broken, are there situations to append to > > FILESEXTRAPATHS? that just seems counter-productive, but maybe i'm > > missing something. > > figured i'd scan for examples of that in some of the many layers i > have checked out and found the following: > > meta-boundary/recipes-qt/qt4/qt4-embedded_%.bbappend:FILESEXTRAPATHS_append := "${THISDIR}/files:" > > meta-intel/recipes-core/zlib/zlib-intel_1.2.11.1.jtkv6.3.bb:FILESEXTRAPATHS_append = ":${COREBASE}/meta/recipes-core/zlib/zlib" > > meta-qt5/recipes-qt/qt5/qt5-ptest.inc:FILESEXTRAPATHS_append := ":${THISDIR}/ptest" > > meta-virtualization/recipes-networking/openvswitch/openvswitch_git.bb:FILESEXTRAPATHS_append := "${THISDIR}/${PN}-git:" > > note that a couple seem clearly(?) wrong (like that last one), but Although contradictory to logic, it is apparently correct to use ":" both with _prepend and _append when adding to FILESEXTRAPATHS (see the default value set by bitbake.conf, which is "__default:"). However, problems _will_ arise if different bbappend files for the same recipe do it differently... It can also be noted that the QA test in insane.bbclass suggests to use ":" with _append, further adding to the confusion. > i'm open to clarification as to when this is useful. (i think i see > the application in that meta-intel layer example, although should that > use "OEROOT" rather than "COREBASE"?) No, ${COREBASE} is correct. (OEROOT is not a bitbake variable, it is only available in the oe-init-build-env script.) > > rday //Peter From richard.purdie at linuxfoundation.org Tue Mar 3 13:28:28 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Tue, 03 Mar 2020 13:28:28 +0000 Subject: [OE-core] [PATCH] python3-scons: Fix license file collision In-Reply-To: <390fd7bab651456084420a36a41478a4@XBOX03.axis.com> References: <20200229161603.495994-1-richard.purdie@linuxfoundation.org> <390fd7bab651456084420a36a41478a4@XBOX03.axis.com> Message-ID: <7bc3721593abda11b0fbc0802969b387f47a20aa.camel@linuxfoundation.org> On Tue, 2020-03-03 at 11:21 +0000, Peter Kjellerstedt wrote: > > SUMMARY = "Software Construction tool (make/autotools replacement)" > > SECTION = "devel/python" > > LICENSE = "MIT" > > -LIC_FILES_CHKSUM = "file://${WORKDIR}/LICENSE;md5=e14e1b33428df24a40a782ae142785d0" > > +LIC_FILES_CHKSUM = "file://${WORKDIR}/LICENSE-python3-scons-${PV};md5=e14e1b33428df24a40a782ae142785d0" > > > > # pypi package does not have a valid license file > > -SRC_URI += "https://raw.githubusercontent.com/SCons/scons/${PV}/LICENSE;name=license" > > +SRC_URI += "https://raw.githubusercontent.com/SCons/scons/${PV}/LICENSE;downloadfilename=LICENSE-python3-scons-${PV};name=license" > > Any reason to not use "${BP}" instead of "python3-scons-${PV}" above? > Or should I send a cleanup patch? No reason. I tend to find BP a little harder to read I guess but its just a personal preference. Cheers, Richard From patchwork at patchwork.openembedded.org Tue Mar 3 13:32:39 2020 From: patchwork at patchwork.openembedded.org (Patchwork) Date: Tue, 03 Mar 2020 13:32:39 -0000 Subject: [OE-core] =?utf-8?q?=E2=9C=97_patchtest=3A_failure_for_systemd=3A?= =?utf-8?q?_Fix_service_file_for_race_issues?= In-Reply-To: <20200303130504.714554-1-richard.purdie@linuxfoundation.org> References: <20200303130504.714554-1-richard.purdie@linuxfoundation.org> Message-ID: <20200303133239.2274.21282@do> == Series Details == Series: systemd: Fix service file for race issues Revision: 1 URL : https://patchwork.openembedded.org/series/23063/ 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 fix Rebase your series on top of targeted branch Targeted branch master (currently at d6b1809e8c) If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core at 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 From peter.kjellerstedt at axis.com Tue Mar 3 13:33:28 2020 From: peter.kjellerstedt at axis.com (Peter Kjellerstedt) Date: Tue, 3 Mar 2020 13:33:28 +0000 Subject: [OE-core] [PATCH] arch-arm64.inc: Do not append aarch64 in MACHINEOVERRIDES In-Reply-To: <000501d5f15c$6e210280$4a630780$@neuf.fr> References: <20200302171153.28030-1-zhengjunling@huawei.com> <666b3145-0e57-cf3c-f1f4-22d6fd0521e5@gmail.com> <9d41cd5d-7355-175d-391c-35231c9a7e92@huawei.com> <41b7391039564f10a0c8b4f63eeb4274@XBOX03.axis.com> <000501d5f15c$6e210280$4a630780$@neuf.fr> Message-ID: <0c22ed9d4f9b473b8a3c7df94b625712@XBOX03.axis.com> > -----Original Message----- > From: Herve Jourdain > Sent: den 3 mars 2020 14:05 > To: Peter Kjellerstedt ; 'Junling Zheng' > ; 'Khem Raj' ; openembedded- > core at lists.openembedded.org > Cc: wangnan0 at huawei.com > Subject: RE: [OE-core] [PATCH] arch-arm64.inc: Do not append aarch64 in > MACHINEOVERRIDES > > Hi, > > Just my 2 cents about this. > armv8-a is the architecture of the arm core, while aarch64/aarch32 is the > execution mode on said architecture. > So I believe that we should have overrides for BOTH the architecture and the > execution mode, as you can have armv8-a executing in 32 bits mode - and btw, There is still an override for aarch64 even after removing it from MACHINEOVERRIDES. It is provided via ${TRANSLATED_TARGET_ARCH}, which will be either "aarch64" or "aarch64-be". The problem before was that for big endian tunes, both aarch64 and aarch64-be would be overrides. > the instruction set in 32 bits mode is not exactly the same as armv7-ve, so > in terms of optimization it does help to know you're running on an armv8-a > architecture, even if it's in 32 bits mode. > There was no such problem before armv8-a architecture, since all previous > architectures were running in 32 bits mode only. Armv8-a changes that as > it's a "hybrid", with support for both aarch64 and aarch32. > I expect later arch to support only aarch64. > > There is also an additional thing to consider, there is not just one armv8-a > profiles, there already are several, and they shall all be taken into account. > I believe that at this time, the valid ones are armv8.0-a, armv8.1-a, > armv8.2-a, armv8.3-a and armv8.4-a. > > And let me answer before someone asks, yes the gcc compiler DOES provide > compiler options for all those architectures, with those exact names - > except armv8.0-a is just named armv8-a (-march=armv8-a or -march=armv8.[1,2,3,4]-a). > So it just makes sense to support them all. > > So overall, I believe we should support all those arm v8 architectures, and > add the corresponding override to the cpu definition files (for instance, as > Peter mentioned, cortex-a53 is an armv8.0-a. But a cortex-a55 or cortex-a75 > would be an armv8.2-a). > > Finally, the arm architecture is slightly more complex than just armv8.x-a, > since the support for "features" is optional. So at least "crc" and "crypto" > features should be added, in order to have a "comprehensive" view of the > armv8 architecture. And yes, the "features" are also supported by the gcc > compiler. > So the arm architecture would really be fully defined by > armv8.x-a+[no]crc+[no]crypto, depending on the underlying SoC and what they The crc and crypto features are currently specified in TUNE_FEATURES. Not sure if it is a good idea to include them in MACHINEOVERRIDES as well, but my gut instinct says it is not. > implemented or not as optional features. And this is probably what should > end up going into the tune-cortexa53.inc and others (and should be > override-able, since again not all cortexa53 are created the same). > > Cheers, > Herve > > -----Original Message----- > From: openembedded-core-bounces at lists.openembedded.org > On Behalf Of Peter > Kjellerstedt > Sent: 03 March 2020 13:00 > To: Junling Zheng ; Khem Raj > ; > openembedded-core at lists.openembedded.org > Cc: wangnan0 at huawei.com > Subject: Re: [OE-core] [PATCH] arch-arm64.inc: Do not append aarch64 in > MACHINEOVERRIDES > > > -----Original Message----- > > From: openembedded-core-bounces at lists.openembedded.org > > On Behalf Of > > Junling Zheng > > Sent: den 3 mars 2020 04:11 > > To: Khem Raj ; openembedded- > > core at lists.openembedded.org > > Cc: wangnan0 at huawei.com > > Subject: Re: [OE-core] [PATCH] arch-arm64.inc: Do not append aarch64 > > in MACHINEOVERRIDES > > > > On 2020/3/3 2:29, Khem Raj wrote: > > > > > > > > > On 3/2/20 9:11 AM, Junling Zheng wrote: > > >> Currently, for arch-arm64, poky will append the MACHINEOVERRIDES > > >> with "aarch64:", which has the higher priority than > TRANSLATED_TARGET_ARCH. > > >> So, for aarch64 big endian, the variable '_aarch64' will > > >> override not only '', but also '_aarch64-be', thus we > > >> will get an incorrect variable. > > >> > > >> Signed-off-by: Junling Zheng > > >> --- > > >> meta/conf/machine/include/arm/arch-arm64.inc | 2 -- > > >> 1 file changed, 2 deletions(-) > > >> > > >> diff --git a/meta/conf/machine/include/arm/arch-arm64.inc > > b/meta/conf/machine/include/arm/arch-arm64.inc > > >> index 53f4566815..32294bd218 100644 > > >> --- a/meta/conf/machine/include/arm/arch-arm64.inc > > >> +++ b/meta/conf/machine/include/arm/arch-arm64.inc > > >> @@ -4,8 +4,6 @@ require conf/machine/include/arm/arch-armv7ve.inc > > >> TUNEVALID[aarch64] = "Enable instructions for aarch64" > > >> -MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', > 'aarch64', 'aarch64:', '' ,d)}" > > >> - > > > > > > if its removed here, where is it being added for other machines, > > question is, should we treat aarch64 as LE equivalent of aarch64_be > > > or should be treated as common aarch64 and a new define like > > > aarch64_le > > defined. > > > > > > > Currently, for arm64, we have aarch64_be to represent big endian, but > > no overrides to represent little endian only. > > > > So, IMO, we should treat aarch64 as little enaian only, like arm and > > armeb. > > > > >> # Little Endian base configs > > >> AVAILTUNES += "aarch64 aarch64_be" > > >> ARMPKGARCH_tune-aarch64 ?= "aarch64" > > Please, before removing "aarch64" from MACHINEOVERRIDES, add "armv8a" or > similar. This is how it is done for the armv7* based chips. E.g., I would > expect to see tune-cortexa53.inc have: > > MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'cortexa53', > 'armv8a:', '' ,d)}" > > Which corresponds to how it is done for armv7*. > > At least we currently rely on being able to do, e.g.: > > COMPATIBLE_MACHINE = "aarch64|armv7a|armv7ve" > > and if you remove "aarch64" from MACHINEOVERRIDES, we need a suitable > substitute. > > //Peter //Peter From bunk at stusta.de Tue Mar 3 13:39:31 2020 From: bunk at stusta.de (Adrian Bunk) Date: Tue, 3 Mar 2020 15:39:31 +0200 Subject: [OE-core] [PATCH] arch-arm64.inc: Do not append aarch64 in MACHINEOVERRIDES In-Reply-To: <41b7391039564f10a0c8b4f63eeb4274@XBOX03.axis.com> References: <20200302171153.28030-1-zhengjunling@huawei.com> <666b3145-0e57-cf3c-f1f4-22d6fd0521e5@gmail.com> <9d41cd5d-7355-175d-391c-35231c9a7e92@huawei.com> <41b7391039564f10a0c8b4f63eeb4274@XBOX03.axis.com> Message-ID: <20200303133931.GB13148@localhost> On Tue, Mar 03, 2020 at 11:59:58AM +0000, Peter Kjellerstedt wrote: >... > Which corresponds to how it is done for armv7*. > > At least we currently rely on being able to do, e.g.: > > COMPATIBLE_MACHINE = "aarch64|armv7a|armv7ve" > > and if you remove "aarch64" from MACHINEOVERRIDES, we need a suitable > substitute. What does "aarch64" actually mean here? Does it also cover 32bit-only aarch64 CPUs? Similar to x86 there are 3 ABIs, and aarch64ilp32 is different from aarch32. Different from x86, there is no ABI that is available in all aarch64 CPUs. They can be 32bit-only or 64bit-only, and aarch32 support is optional. > //Peter cu Adrian From ernst.sjostrand at verisure.com Tue Mar 3 13:39:05 2020 From: ernst.sjostrand at verisure.com (=?utf-8?B?RXJuc3QgU2rDtnN0cmFuZA==?=) Date: Tue, 3 Mar 2020 13:39:05 +0000 Subject: [OE-core] [PATCH] systemd: Fix service file for race issues In-Reply-To: <20200303130504.714554-1-richard.purdie@linuxfoundation.org> References: <20200303130504.714554-1-richard.purdie@linuxfoundation.org> Message-ID: <16815724bf55f5e740b3725b6e092fd5a348fc0c.camel@verisure.com> Yeah it's exactly like that, been bitten by that before. Regards //Ernst tis 2020-03-03 klockan 13:05 +0000 skrev Richard Purdie: It seems this service needs both Requires: and After: according to the definitions in the systemd docs, else we see boot race failures. Signed-off-by: Richard Purdie < richard.purdie at linuxfoundation.org > --- meta/recipes-core/psplash/files/psplash-systemd.service | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/recipes-core/psplash/files/psplash-systemd.service b/meta/recipes-core/psplash/files/psplash-systemd.service index 249aa540394..4e18980bb27 100644 --- a/meta/recipes-core/psplash/files/psplash-systemd.service +++ b/meta/recipes-core/psplash/files/psplash-systemd.service @@ -2,6 +2,7 @@ Description=Start psplash-systemd progress communication helper DefaultDependencies=no After=systemd-start.service +After=psplash-start.service Requires=psplash-start.service RequiresMountsFor=/run -- 2.25.0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhengjunling at huawei.com Tue Mar 3 14:13:46 2020 From: zhengjunling at huawei.com (Junling Zheng) Date: Tue, 3 Mar 2020 22:13:46 +0800 Subject: [OE-core] [PATCH] arch-arm64.inc: Do not append aarch64 in MACHINEOVERRIDES In-Reply-To: <41b7391039564f10a0c8b4f63eeb4274@XBOX03.axis.com> References: <20200302171153.28030-1-zhengjunling@huawei.com> <666b3145-0e57-cf3c-f1f4-22d6fd0521e5@gmail.com> <9d41cd5d-7355-175d-391c-35231c9a7e92@huawei.com> <41b7391039564f10a0c8b4f63eeb4274@XBOX03.axis.com> Message-ID: On 2020/3/3 19:59, Peter Kjellerstedt wrote: >> -----Original Message----- >> From: openembedded-core-bounces at lists.openembedded.org > bounces at lists.openembedded.org> On Behalf Of Junling Zheng >> Sent: den 3 mars 2020 04:11 >> To: Khem Raj ; openembedded- >> core at lists.openembedded.org >> Cc: wangnan0 at huawei.com >> Subject: Re: [OE-core] [PATCH] arch-arm64.inc: Do not append aarch64 in >> MACHINEOVERRIDES >> >> On 2020/3/3 2:29, Khem Raj wrote: >>> >>> >>> On 3/2/20 9:11 AM, Junling Zheng wrote: >>>> Currently, for arch-arm64, poky will append the MACHINEOVERRIDES with >>>> "aarch64:", which has the higher priority than TRANSLATED_TARGET_ARCH. >>>> So, for aarch64 big endian, the variable '_aarch64' will override >>>> not only '', but also '_aarch64-be', thus we will get an >>>> incorrect variable. >>>> >>>> Signed-off-by: Junling Zheng >>>> --- >>>> meta/conf/machine/include/arm/arch-arm64.inc | 2 -- >>>> 1 file changed, 2 deletions(-) >>>> >>>> diff --git a/meta/conf/machine/include/arm/arch-arm64.inc >> b/meta/conf/machine/include/arm/arch-arm64.inc >>>> index 53f4566815..32294bd218 100644 >>>> --- a/meta/conf/machine/include/arm/arch-arm64.inc >>>> +++ b/meta/conf/machine/include/arm/arch-arm64.inc >>>> @@ -4,8 +4,6 @@ require conf/machine/include/arm/arch-armv7ve.inc >>>> TUNEVALID[aarch64] = "Enable instructions for aarch64" >>>> -MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'aarch64', 'aarch64:', '' ,d)}" >>>> - >>> >>> if its removed here, where is it being added for other machines, >> question is, should we treat aarch64 as LE equivalent of aarch64_be >>> or should be treated as common aarch64 and a new define like aarch64_le >> defined. >>> >> >> Currently, for arm64, we have aarch64_be to represent big endian, but no >> overrides to represent little endian only. >> >> So, IMO, we should treat aarch64 as little enaian only, like arm and >> armeb. >> >>>> # Little Endian base configs >>>> AVAILTUNES += "aarch64 aarch64_be" >>>> ARMPKGARCH_tune-aarch64 ?= "aarch64" > > Please, before removing "aarch64" from MACHINEOVERRIDES, add "armv8a" or > similar. This is how it is done for the armv7* based chips. E.g., I would > expect to see tune-cortexa53.inc have: > > MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'cortexa53', 'armv8a:', '' ,d)}" > arch-armv8a.inc has set "armv8a:" as overrides, and tune-cortexa53.inc requires arch-armv8a.inc. > Which corresponds to how it is done for armv7*. > > At least we currently rely on being able to do, e.g.: > > COMPATIBLE_MACHINE = "aarch64|armv7a|armv7ve" > > and if you remove "aarch64" from MACHINEOVERRIDES, we need a suitable > substitute. > > //Peter > > > . > From peter.kjellerstedt at axis.com Tue Mar 3 14:19:43 2020 From: peter.kjellerstedt at axis.com (Peter Kjellerstedt) Date: Tue, 3 Mar 2020 14:19:43 +0000 Subject: [OE-core] [PATCH] arch-arm64.inc: Do not append aarch64 in MACHINEOVERRIDES In-Reply-To: <20200303133931.GB13148@localhost> References: <20200302171153.28030-1-zhengjunling@huawei.com> <666b3145-0e57-cf3c-f1f4-22d6fd0521e5@gmail.com> <9d41cd5d-7355-175d-391c-35231c9a7e92@huawei.com> <41b7391039564f10a0c8b4f63eeb4274@XBOX03.axis.com> <20200303133931.GB13148@localhost> Message-ID: <1b7474f1cd58427dbe42f74b50b3514f@XBOX03.axis.com> > -----Original Message----- > From: Adrian Bunk > Sent: den 3 mars 2020 14:40 > To: Peter Kjellerstedt > Cc: Junling Zheng ; Khem Raj > ; openembedded-core at lists.openembedded.org; > wangnan0 at huawei.com > Subject: Re: [OE-core] [PATCH] arch-arm64.inc: Do not append aarch64 in > MACHINEOVERRIDES > > On Tue, Mar 03, 2020 at 11:59:58AM +0000, Peter Kjellerstedt wrote: > >... > > Which corresponds to how it is done for armv7*. > > > > At least we currently rely on being able to do, e.g.: > > > > COMPATIBLE_MACHINE = "aarch64|armv7a|armv7ve" > > > > and if you remove "aarch64" from MACHINEOVERRIDES, we need a suitable > > substitute. > > What does "aarch64" actually mean here? > Does it also cover 32bit-only aarch64 CPUs? We haven't had to reflect about that as all aarch64 based SoCs we use are 64-bit only. So I guess we live in a simplified world. Still, we need a way to separate them from our armv7 or mips based SoCs... > Similar to x86 there are 3 ABIs, and aarch64ilp32 is different from > aarch32. > > Different from x86, there is no ABI that is available in all aarch64 CPUs. > They can be 32bit-only or 64bit-only, and aarch32 support is optional. > > > //Peter > > cu > Adrian //Peter From peter.kjellerstedt at axis.com Tue Mar 3 14:20:27 2020 From: peter.kjellerstedt at axis.com (Peter Kjellerstedt) Date: Tue, 3 Mar 2020 14:20:27 +0000 Subject: [OE-core] [PATCH] arch-arm64.inc: Do not append aarch64 in MACHINEOVERRIDES In-Reply-To: References: <20200302171153.28030-1-zhengjunling@huawei.com> <666b3145-0e57-cf3c-f1f4-22d6fd0521e5@gmail.com> <9d41cd5d-7355-175d-391c-35231c9a7e92@huawei.com> <41b7391039564f10a0c8b4f63eeb4274@XBOX03.axis.com> Message-ID: <241102f474044a96bb3d6fdaa96199b4@XBOX03.axis.com> > -----Original Message----- > From: Junling Zheng > Sent: den 3 mars 2020 15:14 > To: Peter Kjellerstedt ; Khem Raj > ; openembedded-core at lists.openembedded.org > Cc: wangnan0 at huawei.com > Subject: Re: [OE-core] [PATCH] arch-arm64.inc: Do not append aarch64 in > MACHINEOVERRIDES > > On 2020/3/3 19:59, Peter Kjellerstedt wrote: > >> -----Original Message----- > >> From: openembedded-core-bounces at lists.openembedded.org core- > >> bounces at lists.openembedded.org> On Behalf Of Junling Zheng > >> Sent: den 3 mars 2020 04:11 > >> To: Khem Raj ; openembedded- > >> core at lists.openembedded.org > >> Cc: wangnan0 at huawei.com > >> Subject: Re: [OE-core] [PATCH] arch-arm64.inc: Do not append aarch64 in > >> MACHINEOVERRIDES > >> > >> On 2020/3/3 2:29, Khem Raj wrote: > >>> > >>> > >>> On 3/2/20 9:11 AM, Junling Zheng wrote: > >>>> Currently, for arch-arm64, poky will append the MACHINEOVERRIDES with > >>>> "aarch64:", which has the higher priority than > TRANSLATED_TARGET_ARCH. > >>>> So, for aarch64 big endian, the variable '_aarch64' will > override > >>>> not only '', but also '_aarch64-be', thus we will get an > >>>> incorrect variable. > >>>> > >>>> Signed-off-by: Junling Zheng > >>>> --- > >>>> meta/conf/machine/include/arm/arch-arm64.inc | 2 -- > >>>> 1 file changed, 2 deletions(-) > >>>> > >>>> diff --git a/meta/conf/machine/include/arm/arch-arm64.inc > >> b/meta/conf/machine/include/arm/arch-arm64.inc > >>>> index 53f4566815..32294bd218 100644 > >>>> --- a/meta/conf/machine/include/arm/arch-arm64.inc > >>>> +++ b/meta/conf/machine/include/arm/arch-arm64.inc > >>>> @@ -4,8 +4,6 @@ require conf/machine/include/arm/arch-armv7ve.inc > >>>> TUNEVALID[aarch64] = "Enable instructions for aarch64" > >>>> -MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', > 'aarch64', 'aarch64:', '' ,d)}" > >>>> - > >>> > >>> if its removed here, where is it being added for other machines, > >> question is, should we treat aarch64 as LE equivalent of aarch64_be > >>> or should be treated as common aarch64 and a new define like > aarch64_le > >> defined. > >>> > >> > >> Currently, for arm64, we have aarch64_be to represent big endian, but > no > >> overrides to represent little endian only. > >> > >> So, IMO, we should treat aarch64 as little enaian only, like arm and > >> armeb. > >> > >>>> # Little Endian base configs > >>>> AVAILTUNES += "aarch64 aarch64_be" > >>>> ARMPKGARCH_tune-aarch64 ?= "aarch64" > > > > Please, before removing "aarch64" from MACHINEOVERRIDES, add "armv8a" or > > similar. This is how it is done for the armv7* based chips. E.g., I > would > > expect to see tune-cortexa53.inc have: > > > > MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'cortexa53', 'armv8a:', '' ,d)}" > > > > arch-armv8a.inc has set "armv8a:" as overrides, and tune-cortexa53.inc > requires arch-armv8a.inc. But it never adds "armv8a" (or ${TUNE_FEATURES_tune-armv8a}) to TUNE_FEATURES, it adds "aarch64", so the above is never triggered... > > Which corresponds to how it is done for armv7*. > > > > At least we currently rely on being able to do, e.g.: > > > > COMPATIBLE_MACHINE = "aarch64|armv7a|armv7ve" > > > > and if you remove "aarch64" from MACHINEOVERRIDES, we need a suitable > > substitute. > > > > //Peter //Peter From ticotimo at gmail.com Tue Mar 3 14:25:41 2020 From: ticotimo at gmail.com (Tim Orling) Date: Tue, 3 Mar 2020 06:25:41 -0800 Subject: [OE-core] how to cleanly centralize a zillion BBCLASSEXTEND += "nativesdk" settings? In-Reply-To: <52350a7bd080413c9dbc6e1783f14e2c@XBOX03.axis.com> References: <20200302074035.Horde.5xguZSt_-_Yd241eE1Zo8Pb@crashcourse.ca> <52350a7bd080413c9dbc6e1783f14e2c@XBOX03.axis.com> Message-ID: On Tue, Mar 3, 2020 at 4:32 AM Peter Kjellerstedt < peter.kjellerstedt at axis.com> wrote: > > -----Original Message----- > > From: openembedded-core-bounces at lists.openembedded.org > > bounces at lists.openembedded.org> On Behalf Of rpjday at crashcourse.ca > > Sent: den 2 mars 2020 13:41 > > To: openembedded-core at lists.openembedded.org > > Subject: [OE-core] how to cleanly centralize a zillion BBCLASSEXTEND += > > "nativesdk" settings? > > > > layer i'm currently perusing has many, many bbappend files, of which > > quite a number are nothing more than the single line: > > > > BBCLASSEXTEND += "nativesdk" > > > > literally, at least a hundred append files are like that. so rather > > than clutter up the layer with all those trivial .bbappend files, > > can one cram all that into a single .conf file? as i read it, can i > > do something like: > > > > BBCLASSEXTEND_append_pn-pkg1 = " nativesdk" > > BBCLASSEXTEND_append_pn-pkg2 = " nativesdk" > > ... and on and on ... > > > > and toss all that into a distro.conf file or something? > > > > and even if that works, is it considered good coding style? > > > > rday > > Sounds perfectly fine. We do something similar, but in our case we need > to add "native" to BBCLASSEXTEND for a whole bunch of recipes. > Should patches be sent to add native and nativesdk? Drop the technical debt by upstreaming... > > //Peter > > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core at lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core > -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard.purdie at linuxfoundation.org Tue Mar 3 14:38:29 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Tue, 03 Mar 2020 14:38:29 +0000 Subject: [OE-core] how to cleanly centralize a zillion BBCLASSEXTEND += "nativesdk" settings? In-Reply-To: References: <20200302074035.Horde.5xguZSt_-_Yd241eE1Zo8Pb@crashcourse.ca> <52350a7bd080413c9dbc6e1783f14e2c@XBOX03.axis.com> Message-ID: On Tue, 2020-03-03 at 06:25 -0800, Tim Orling wrote: > > > On Tue, Mar 3, 2020 at 4:32 AM Peter Kjellerstedt < > peter.kjellerstedt at axis.com> wrote: > > > -----Original Message----- > > > From: openembedded-core-bounces at lists.openembedded.org > > > > bounces at lists.openembedded.org> On Behalf Of > > rpjday at crashcourse.ca > > > Sent: den 2 mars 2020 13:41 > > > To: openembedded-core at lists.openembedded.org > > > Subject: [OE-core] how to cleanly centralize a zillion > > BBCLASSEXTEND += > > > "nativesdk" settings? > > > > > > layer i'm currently perusing has many, many bbappend files, of > > which > > > quite a number are nothing more than the single line: > > > > > > BBCLASSEXTEND += "nativesdk" > > > > > > literally, at least a hundred append files are like that. so > > rather > > > than clutter up the layer with all those trivial .bbappend files, > > > can one cram all that into a single .conf file? as i read it, can > > i > > > do something like: > > > > > > BBCLASSEXTEND_append_pn-pkg1 = " nativesdk" > > > BBCLASSEXTEND_append_pn-pkg2 = " nativesdk" > > > ... and on and on ... > > > > > > and toss all that into a distro.conf file or something? > > > > > > and even if that works, is it considered good coding style? > > > > > > rday > > > > Sounds perfectly fine. We do something similar, but in our case we > > need > > to add "native" to BBCLASSEXTEND for a whole bunch of recipes. > > > > Should patches be sent to add native and nativesdk? Drop the > technical debt by upstreaming... I'm torn on this since adding these does have performance impact. We've talked about adding them as defaults but it does increase parsing time and so on... Cheers, Richard From zhengjunling at huawei.com Tue Mar 3 14:39:33 2020 From: zhengjunling at huawei.com (Junling Zheng) Date: Tue, 3 Mar 2020 22:39:33 +0800 Subject: [OE-core] [PATCH] arch-arm64.inc: Do not append aarch64 in MACHINEOVERRIDES In-Reply-To: <241102f474044a96bb3d6fdaa96199b4@XBOX03.axis.com> References: <20200302171153.28030-1-zhengjunling@huawei.com> <666b3145-0e57-cf3c-f1f4-22d6fd0521e5@gmail.com> <9d41cd5d-7355-175d-391c-35231c9a7e92@huawei.com> <41b7391039564f10a0c8b4f63eeb4274@XBOX03.axis.com> <241102f474044a96bb3d6fdaa96199b4@XBOX03.axis.com> Message-ID: <4cf21ebb-cfb2-f020-2dfb-55fb57b315c5@huawei.com> On 2020/3/3 22:20, Peter Kjellerstedt wrote: >> -----Original Message----- >> From: Junling Zheng >> Sent: den 3 mars 2020 15:14 >> To: Peter Kjellerstedt ; Khem Raj >> ; openembedded-core at lists.openembedded.org >> Cc: wangnan0 at huawei.com >> Subject: Re: [OE-core] [PATCH] arch-arm64.inc: Do not append aarch64 in >> MACHINEOVERRIDES >> >> On 2020/3/3 19:59, Peter Kjellerstedt wrote: >>>> -----Original Message----- >>>> From: openembedded-core-bounces at lists.openembedded.org > core- >>>> bounces at lists.openembedded.org> On Behalf Of Junling Zheng >>>> Sent: den 3 mars 2020 04:11 >>>> To: Khem Raj ; openembedded- >>>> core at lists.openembedded.org >>>> Cc: wangnan0 at huawei.com >>>> Subject: Re: [OE-core] [PATCH] arch-arm64.inc: Do not append aarch64 in >>>> MACHINEOVERRIDES >>>> >>>> On 2020/3/3 2:29, Khem Raj wrote: >>>>> >>>>> >>>>> On 3/2/20 9:11 AM, Junling Zheng wrote: >>>>>> Currently, for arch-arm64, poky will append the MACHINEOVERRIDES with >>>>>> "aarch64:", which has the higher priority than >> TRANSLATED_TARGET_ARCH. >>>>>> So, for aarch64 big endian, the variable '_aarch64' will >> override >>>>>> not only '', but also '_aarch64-be', thus we will get an >>>>>> incorrect variable. >>>>>> >>>>>> Signed-off-by: Junling Zheng >>>>>> --- >>>>>> meta/conf/machine/include/arm/arch-arm64.inc | 2 -- >>>>>> 1 file changed, 2 deletions(-) >>>>>> >>>>>> diff --git a/meta/conf/machine/include/arm/arch-arm64.inc >>>> b/meta/conf/machine/include/arm/arch-arm64.inc >>>>>> index 53f4566815..32294bd218 100644 >>>>>> --- a/meta/conf/machine/include/arm/arch-arm64.inc >>>>>> +++ b/meta/conf/machine/include/arm/arch-arm64.inc >>>>>> @@ -4,8 +4,6 @@ require conf/machine/include/arm/arch-armv7ve.inc >>>>>> TUNEVALID[aarch64] = "Enable instructions for aarch64" >>>>>> -MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', >> 'aarch64', 'aarch64:', '' ,d)}" >>>>>> - >>>>> >>>>> if its removed here, where is it being added for other machines, >>>> question is, should we treat aarch64 as LE equivalent of aarch64_be >>>>> or should be treated as common aarch64 and a new define like >> aarch64_le >>>> defined. >>>>> >>>> >>>> Currently, for arm64, we have aarch64_be to represent big endian, but >> no >>>> overrides to represent little endian only. >>>> >>>> So, IMO, we should treat aarch64 as little enaian only, like arm and >>>> armeb. >>>> >>>>>> # Little Endian base configs >>>>>> AVAILTUNES += "aarch64 aarch64_be" >>>>>> ARMPKGARCH_tune-aarch64 ?= "aarch64" >>> >>> Please, before removing "aarch64" from MACHINEOVERRIDES, add "armv8a" or >>> similar. This is how it is done for the armv7* based chips. E.g., I >> would >>> expect to see tune-cortexa53.inc have: >>> >>> MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'cortexa53', 'armv8a:', '' ,d)}" >>> >> >> arch-armv8a.inc has set "armv8a:" as overrides, and tune-cortexa53.inc >> requires arch-armv8a.inc. > > But it never adds "armv8a" (or ${TUNE_FEATURES_tune-armv8a}) to > TUNE_FEATURES, it adds "aarch64", so the above is never triggered... > I guess the logic is: if you set DEFAULTTUNE as armv8a, then it will add "armv8a" to TUNE_FEATURES, and then "armv8a:" will be added into MACHINEOVERRIDES. Am I right? >>> Which corresponds to how it is done for armv7*. >>> >>> At least we currently rely on being able to do, e.g.: >>> >>> COMPATIBLE_MACHINE = "aarch64|armv7a|armv7ve" >>> >>> and if you remove "aarch64" from MACHINEOVERRIDES, we need a suitable >>> substitute. >>> >>> //Peter > > //Peter > > > . > From wallinux at gmail.com Tue Mar 3 15:54:20 2020 From: wallinux at gmail.com (Anders Wallin) Date: Tue, 3 Mar 2020 16:54:20 +0100 Subject: [OE-core] [PATCH v2] babeltrace: only check latest git tag version for 1.x.x Message-ID: <20200303155420.24684-1-wallinux@gmail.com> version 2.x.x will be added with a new babeltrace2 recipe Signed-off-by: Anders Wallin --- meta/recipes-kernel/lttng/babeltrace_1.5.8.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-kernel/lttng/babeltrace_1.5.8.bb b/meta/recipes-kernel/lttng/babeltrace_1.5.8.bb index c050dc674d..4d2492a170 100644 --- a/meta/recipes-kernel/lttng/babeltrace_1.5.8.bb +++ b/meta/recipes-kernel/lttng/babeltrace_1.5.8.bb @@ -11,7 +11,7 @@ SRC_URI = "git://git.linuxfoundation.org/diamon/babeltrace.git;branch=stable-1.5 file://run-ptest \ " SRCREV = "054a54ae10b01a271afc4f19496c041b10fb414c" -UPSTREAM_CHECK_GITTAGREGEX = "v(?P\d+(\.\d+)+)$" +UPSTREAM_CHECK_GITTAGREGEX = "v(?P1(\.\d+)+)$" S = "${WORKDIR}/git" -- 2.25.1 From trini at konsulko.com Tue Mar 3 15:57:33 2020 From: trini at konsulko.com (Tom Rini) Date: Tue, 3 Mar 2020 10:57:33 -0500 Subject: [OE-core] how to cleanly centralize a zillion BBCLASSEXTEND += "nativesdk" settings? In-Reply-To: References: <20200302074035.Horde.5xguZSt_-_Yd241eE1Zo8Pb@crashcourse.ca> <52350a7bd080413c9dbc6e1783f14e2c@XBOX03.axis.com> Message-ID: <20200303155733.GF18302@bill-the-cat> On Tue, Mar 03, 2020 at 02:38:29PM +0000, Richard Purdie wrote: > On Tue, 2020-03-03 at 06:25 -0800, Tim Orling wrote: > > > > > > On Tue, Mar 3, 2020 at 4:32 AM Peter Kjellerstedt < > > peter.kjellerstedt at axis.com> wrote: > > > > -----Original Message----- > > > > From: openembedded-core-bounces at lists.openembedded.org > > > > > > bounces at lists.openembedded.org> On Behalf Of > > > rpjday at crashcourse.ca > > > > Sent: den 2 mars 2020 13:41 > > > > To: openembedded-core at lists.openembedded.org > > > > Subject: [OE-core] how to cleanly centralize a zillion > > > BBCLASSEXTEND += > > > > "nativesdk" settings? > > > > > > > > layer i'm currently perusing has many, many bbappend files, of > > > which > > > > quite a number are nothing more than the single line: > > > > > > > > BBCLASSEXTEND += "nativesdk" > > > > > > > > literally, at least a hundred append files are like that. so > > > rather > > > > than clutter up the layer with all those trivial .bbappend files, > > > > can one cram all that into a single .conf file? as i read it, can > > > i > > > > do something like: > > > > > > > > BBCLASSEXTEND_append_pn-pkg1 = " nativesdk" > > > > BBCLASSEXTEND_append_pn-pkg2 = " nativesdk" > > > > ... and on and on ... > > > > > > > > and toss all that into a distro.conf file or something? > > > > > > > > and even if that works, is it considered good coding style? > > > > > > > > rday > > > > > > Sounds perfectly fine. We do something similar, but in our case we > > > need > > > to add "native" to BBCLASSEXTEND for a whole bunch of recipes. > > > > > > > Should patches be sent to add native and nativesdk? Drop the > > technical debt by upstreaming... > > I'm torn on this since adding these does have performance impact. We've > talked about adding them as defaults but it does increase parsing time > and so on... Just how much does it increase parsing time? For any use case with a fairly deep SDK you end up with the case in question here. -- Tom From sjolley.yp.pm at gmail.com Tue Mar 3 15:59:34 2020 From: sjolley.yp.pm at gmail.com (sjolley.yp.pm at gmail.com) Date: Tue, 3 Mar 2020 07:59:34 -0800 Subject: [OE-core] Yocto Project Status WW09'20 Message-ID: <107c01d5f174$bbf566a0$33e033e0$@gmail.com> Current Dev Position: YP 3.1 M3 - At Feature Freeze, build pending Next Deadline: YP 3.1 M3 build date 2/24/2020 Next Team Meetings: * Bug Triage meeting Thursday Mar. 5th at 7:30am PDT ( https://zoom.us/j/454367603) * Monthly Project Meeting Tuesday Mar. 3rd at 8am PDT ( https://zoom.us/j/990892712) * Weekly Engineering Sync Tuesday Mar. 10th at 8am PDT ( https://zoom.us/j/990892712) * Twitch - See http://www.twitch.tv/letoatreidesthe2nd Key Status/Updates: * YP 2.7.3 and 3.0.2 have been released. * YP 3.1 has been announced as an LTS release: https://www.yoctoproject.org/yocto-project-long-term-support-announced/ * We are now past M3 feature freeze. A number of key issues have been addressed, thanks to everyone who contributed: * psplash systemd race issues fixed (Thanks Scott) * make mips issue root caused and glibc fix pulled in (Thanks Victor/Khem) * ltp upgrade resolved (Thanks Petr) * util-linux update resolved (Thanks Pierre-Jean) * Uninative tumbleweed issue resolved (Thanks Michael) * libgpg-error upgrade (Thanks Alex) * There were many other fixes and upgrades, thanks all! * The remaining issues we need to look at addressing before we build M3 are: * bind upgrade (needs libuv maintainer fix and resend from Armin) * coreutils ptest blocked on libmodule-build-perl reproducibility issue * Locked signature selftest failure * SystemExit() intermittent selftest failure * pseudo sysroot high priority bug * gcc buildtools tarball solution for centos7 support * Recipe upgrades are now much less likely to be accepted unless there is a pressing need, ideally these should be held until 3.1 is released and development for 3.2 is started. We do not have a tracking branch for 3.2 as we'd like to focus people on 3.1 right now. * Bug metrics are not good with a rise in WDD when typically it should be falling for this point in a release cycle. YP 3.1 Milestone Dates: * YP 3.1 M3 build date 2/24/2020 * YP 3.1 M3 release date 3/6/2020 * YP 3.1 M4 build date 3/30/2020 * YP 3.1 M4 release date 4/24/2020 Planned upcoming dot releases: * YP 3.0.3 build date 5/4/2020 * YP 3.0.3 release date 5/15/2020 * YP 2.7.4 build date 5/18/2020 * YP 2.7.4 release date 5/29/2020 Tracking Metrics: * WDD 2720 (last week 2665) ( https://wiki.yoctoproject.org/charts/combo.html) * Poky Patch Metrics * Total patches found: 1346 (last week 1356) * Patches in the Pending State: 539 (40%) [last week 543 (40%)] The Yocto Project's technical governance is through its Technical Steering Committee, more information is available at: https://wiki.yoctoproject.org/wiki/TSC 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 * Cell: (208) 244-4460 * Email: sjolley.yp.pm at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From git at andred.net Tue Mar 3 16:05:10 2020 From: git at andred.net (=?UTF-8?q?Andr=C3=A9=20Draszik?=) Date: Tue, 3 Mar 2020 16:05:10 +0000 Subject: [OE-core] [PATCH v2 1/4] lib/oe/utils: allow to set a lower bound on returned cpu_count() Message-ID: <20200303160513.17645-1-git@andred.net> This will be needed for making xz compression more deterministic, as xz archives are created differently in single- vs multi-threaded modes. This means that due to bitbake's default of using as many threads as there are cores in the system, files compressed with xz will be different if built on a multi-core system compared to single-core systems. Allowing cpu_count() here to return a lower bound, will allow forcing xz to always use multi-threaded operation. Signed-off-by: Andr? Draszik --- meta/lib/oe/utils.py | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/meta/lib/oe/utils.py b/meta/lib/oe/utils.py index e350b05ddf..aee4336482 100644 --- a/meta/lib/oe/utils.py +++ b/meta/lib/oe/utils.py @@ -248,9 +248,10 @@ def trim_version(version, num_parts=2): trimmed = ".".join(parts[:num_parts]) return trimmed -def cpu_count(): +def cpu_count(at_least=1): import multiprocessing - return multiprocessing.cpu_count() + cpus = multiprocessing.cpu_count() + return max(cpus, at_least) def execute_pre_post_process(d, cmds): if cmds is None: -- 2.23.0.rc1 From git at andred.net Tue Mar 3 16:05:11 2020 From: git at andred.net (=?UTF-8?q?Andr=C3=A9=20Draszik?=) Date: Tue, 3 Mar 2020 16:05:11 +0000 Subject: [OE-core] [PATCH v2 2/4] bitbake.conf: more deterministic xz compression (threads) In-Reply-To: <20200303160513.17645-1-git@andred.net> References: <20200303160513.17645-1-git@andred.net> Message-ID: <20200303160513.17645-2-git@andred.net> xz archives can be non-deterministic / non-reproducible: a) archives are created differently in single- vs multi-threaded modes b) xz will scale down the compression level so as to be try to work within any memory limit given to it when operating in single-threaded mode This means that due to bitbake's default of using as many threads as there are cores in the system, files compressed with xz will be different if built on a multi-core system compared to single-core systems. They will also potentially be different if built on single-core systems with different amounts of physical memory, due to bitbake's default of limiting xz's memory consumption. Force multi-threaded operation by default, even on single-core systems, so as to ensure archives are created in the same way in all cases. Signed-off-by: Andr? Draszik --- meta/conf/bitbake.conf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf index e201b671bb..131ba296d3 100644 --- a/meta/conf/bitbake.conf +++ b/meta/conf/bitbake.conf @@ -795,7 +795,7 @@ BB_NUMBER_THREADS ?= "${@oe.utils.cpu_count()}" PARALLEL_MAKE ?= "-j ${@oe.utils.cpu_count()}" # Default parallelism and resource usage for xz -XZ_DEFAULTS ?= "--memlimit=50% --threads=${@oe.utils.cpu_count()}" +XZ_DEFAULTS ?= "--memlimit=50% --threads=${@oe.utils.cpu_count(at_least=2)}" ################################################################## # Magic Cookie for SANITY CHECK -- 2.23.0.rc1 From git at andred.net Tue Mar 3 16:05:12 2020 From: git at andred.net (=?UTF-8?q?Andr=C3=A9=20Draszik?=) Date: Tue, 3 Mar 2020 16:05:12 +0000 Subject: [OE-core] [PATCH v2 3/4] bitbake.conf: omit XZ threads and RAM from sstate signatures In-Reply-To: <20200303160513.17645-1-git@andred.net> References: <20200303160513.17645-1-git@andred.net> Message-ID: <20200303160513.17645-3-git@andred.net> The number of threads used, and the amount of memory allowed to be used, should not affect sstate signatures, as they don't affect the outcome of the compression if xz operates in multi-threaded mode [1]. Otherwise, it becomes impossible to re-use sstate from automated builders on developer's machines (as the former might execute bitbake with certain constraints different compared to developer's machines). This is in particular a problem with the opkg package writing backend, as the OPKGBUILDCMD depends on XZ_DEFAULTS. Without the vardepexclude, there is no re-use possible of the package_write_ipk sstate. Whitelist the maximum number of threads and the memory limit given assumptions outlined in [2] below. Signed-off-by: Andr? Draszik [1] When starting out in multi-threaded mode, the output is always deterministic, as even if xz scales down to single-threaded later, the archives are still split into blocks and size information is still added, thus keeping them compatible with multi-threaded mode. Also, when starting out in multi-threaded mode, xz never scales down the compression level to accomodate memory usage restrictions, it just scales down the number of threads and errors out if it can not accomodate the memory limit. [2] Assumptions * We only support multi-threaded mode (threads >= 2), builds should not try to use xz in single-threaded mode * The thread limit should be set via XZ_THREADS, not via modifying XZ_DEFAULTS or XZ_OPTS, or any other way * The thread limit should not be set to xz's magic value zero (0), as that will lead to single-threaded mode on single-core systems. --- meta/conf/bitbake.conf | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf index 131ba296d3..4b544a22cd 100644 --- a/meta/conf/bitbake.conf +++ b/meta/conf/bitbake.conf @@ -795,7 +795,10 @@ BB_NUMBER_THREADS ?= "${@oe.utils.cpu_count()}" PARALLEL_MAKE ?= "-j ${@oe.utils.cpu_count()}" # Default parallelism and resource usage for xz -XZ_DEFAULTS ?= "--memlimit=50% --threads=${@oe.utils.cpu_count(at_least=2)}" +XZ_MEMLIMIT ?= "50%" +XZ_THREADS ?= "${@oe.utils.cpu_count(at_least=2)}" +XZ_DEFAULTS ?= "--memlimit=${XZ_MEMLIMIT} --threads=${XZ_THREADS}" +XZ_DEFAULTS[vardepsexclude] += "XZ_MEMLIMIT XZ_THREADS" ################################################################## # Magic Cookie for SANITY CHECK -- 2.23.0.rc1 From git at andred.net Tue Mar 3 16:05:13 2020 From: git at andred.net (=?UTF-8?q?Andr=C3=A9=20Draszik?=) Date: Tue, 3 Mar 2020 16:05:13 +0000 Subject: [OE-core] [PATCH v2 4/4] reproducible: try to ensure reproducible xz archives In-Reply-To: <20200303160513.17645-1-git@andred.net> References: <20200303160513.17645-1-git@andred.net> Message-ID: <20200303160513.17645-4-git@andred.net> xz suffers from a reproducibility problem when not using multi- threaded mode: a) archives are created differently in single- vs multi-threaded modes b) xz will scale down the compression level so as to be able to work within any memory limit given to it when being launched in single-threaded mode. Thus, for reproducible xz archives we need to launch xz with at least two threads. Add a little sanity test, and error out otherwise, so as to guarantee no difference due this fact. Assumptions: * The thread limit should be set via XZ_THREADS, not via modifying XZ_DEFAULTS or XZ_OPTS, or any other way * The thread limit should not be set to xz's magic value zero (0), as that will lead to single-threaded mode on single-core systems This patch here doesn't prevent people from shooting themselves into the foot by changing XZ_DEFAULTS to change the number of threads directly, but it's can serve as a hint at least. Signed-off-by: Andr? Draszik --- meta/classes/reproducible_build.bbclass | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/meta/classes/reproducible_build.bbclass b/meta/classes/reproducible_build.bbclass index 750eb950f2..e07bef87d8 100644 --- a/meta/classes/reproducible_build.bbclass +++ b/meta/classes/reproducible_build.bbclass @@ -35,6 +35,7 @@ # SOURCE_DATE_EPOCH is set for all tasks that might use it (do_configure, do_compile, do_package, ...) BUILD_REPRODUCIBLE_BINARIES ??= '1' +BUILD_REPRODUCIBLE_XZ_ARCHIVES ??= '1' inherit ${@oe.utils.ifelse(d.getVar('BUILD_REPRODUCIBLE_BINARIES') == '1', 'reproducible_build_simple', '')} SDE_DIR ="${WORKDIR}/source-date-epoch" @@ -198,4 +199,8 @@ BB_HASHBASE_WHITELIST += "SOURCE_DATE_EPOCH" python () { if d.getVar('BUILD_REPRODUCIBLE_BINARIES') == '1': d.appendVarFlag("do_unpack", "postfuncs", " do_create_source_date_epoch_stamp") + + if d.getVar('BUILD_REPRODUCIBLE_XZ_ARCHIVES') == '1': + if int(d.getVar('XZ_THREADS')) < 2: + bb.fatal("Can not build reproducible XZ archives without threading") } -- 2.23.0.rc1 From git at andred.net Tue Mar 3 16:08:03 2020 From: git at andred.net (=?ISO-8859-1?Q?Andr=E9?= Draszik) Date: Tue, 03 Mar 2020 16:08:03 +0000 Subject: [OE-core] [PATCH v2 4/4] reproducible: try to ensure reproducible xz archives In-Reply-To: <20200303160513.17645-4-git@andred.net> References: <20200303160513.17645-1-git@andred.net> <20200303160513.17645-4-git@andred.net> Message-ID: On Tue, 2020-03-03 at 16:05 +0000, Andr? Draszik wrote: > xz suffers from a reproducibility problem when not using multi- > threaded mode: > a) archives are created differently in single- vs multi-threaded > modes > b) xz will scale down the compression level so as to be able to > work within any memory limit given to it when being launched > in single-threaded mode. > > Thus, for reproducible xz archives we need to launch xz with > at least two threads. > > Add a little sanity test, and error out otherwise, so as to > guarantee no difference due this fact. > > Assumptions: > * The thread limit should be set via XZ_THREADS, not via > modifying XZ_DEFAULTS or XZ_OPTS, or any other way > * The thread limit should not be set to xz's magic value > zero (0), as that will lead to single-threaded mode on > single-core systems > > This patch here doesn't prevent people from shooting themselves > into the foot by changing XZ_DEFAULTS to change the number > of threads directly, but it's can serve as a hint at least. I don't know if this patch is useful, feel free to drop it. In an ideal world, it'd parse the output of xz --verbose --verbose, to catch all possible ways people might be adjusting the thread limit, but that's non-trivial. Cheers, Andre' > > Signed-off-by: Andr? Draszik > --- > meta/classes/reproducible_build.bbclass | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/meta/classes/reproducible_build.bbclass b/meta/classes/reproducible_build.bbclass > index 750eb950f2..e07bef87d8 100644 > --- a/meta/classes/reproducible_build.bbclass > +++ b/meta/classes/reproducible_build.bbclass > @@ -35,6 +35,7 @@ > # SOURCE_DATE_EPOCH is set for all tasks that might use it (do_configure, do_compile, do_package, ...) > > BUILD_REPRODUCIBLE_BINARIES ??= '1' > +BUILD_REPRODUCIBLE_XZ_ARCHIVES ??= '1' > inherit ${@oe.utils.ifelse(d.getVar('BUILD_REPRODUCIBLE_BINARIES') == '1', 'reproducible_build_simple', '')} > > SDE_DIR ="${WORKDIR}/source-date-epoch" > @@ -198,4 +199,8 @@ BB_HASHBASE_WHITELIST += "SOURCE_DATE_EPOCH" > python () { > if d.getVar('BUILD_REPRODUCIBLE_BINARIES') == '1': > d.appendVarFlag("do_unpack", "postfuncs", " do_create_source_date_epoch_stamp") > + > + if d.getVar('BUILD_REPRODUCIBLE_XZ_ARCHIVES') == '1': > + if int(d.getVar('XZ_THREADS')) < 2: > + bb.fatal("Can not build reproducible XZ archives without threading") > } From jacob.kroon at gmail.com Tue Mar 3 17:41:57 2020 From: jacob.kroon at gmail.com (Jacob Kroon) Date: Tue, 3 Mar 2020 18:41:57 +0100 Subject: [OE-core] freetype: add pixmap to PACKAGECONFIG In-Reply-To: <20200229234742.3780-1-matt.ranostay@konsulko.com> References: <20200229234742.3780-1-matt.ranostay@konsulko.com> Message-ID: <6353532b-aa0e-a005-2589-2e8281863fd5@gmail.com> On 3/1/20 12:47 AM, Matt Ranostay wrote: > Add pixmap to PACKAGECONFIG defaults to allow consumers to > render color emojis without distro changes. > > Signed-off-by: Matt Ranostay > --- > meta/recipes-graphics/freetype/freetype_2.10.1.bb | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/meta/recipes-graphics/freetype/freetype_2.10.1.bb b/meta/recipes-graphics/freetype/freetype_2.10.1.bb > index b179a0ed47..d1c093054b 100644 > --- a/meta/recipes-graphics/freetype/freetype_2.10.1.bb > +++ b/meta/recipes-graphics/freetype/freetype_2.10.1.bb > @@ -27,7 +27,7 @@ AUTOTOOLS_SCRIPT_PATH = "${S}/builds/unix" > CONFIGURE_SCRIPT = "${S}/configure" > EXTRA_AUTORECONF += "--exclude=autoheader --exclude=automake" > > -PACKAGECONFIG ??= "zlib" > +PACKAGECONFIG ??= "zlib pixmap" > > PACKAGECONFIG[bzip2] = "--with-bzip2,--without-bzip2,bzip2" > # harfbuzz results in a circular dependency so enabling is non-trivial > My distro does not care about rendering color emojis. Building my image now pulls in libpng unless I remove the packageconfig in a distro conf. The pixmap packageconfig has defaulted to being off since it was added in 2013 in commmit 7cbf6060ac14b0f4d2f038f821ca980be0d46cb0. Wouldn't it make sense to keep it off by default and let whoever needs it enable it ? /Jacob From jpuhlman at mvista.com Tue Mar 3 19:17:40 2020 From: jpuhlman at mvista.com (Jeremy Puhlman) Date: Tue, 3 Mar 2020 11:17:40 -0800 Subject: [OE-core] how to cleanly centralize a zillion BBCLASSEXTEND += "nativesdk" settings? In-Reply-To: References: <20200302074035.Horde.5xguZSt_-_Yd241eE1Zo8Pb@crashcourse.ca> <52350a7bd080413c9dbc6e1783f14e2c@XBOX03.axis.com> Message-ID: <418c43d7-a2ce-6ad6-e9e5-c72ed390df9f@mvista.com> On 3/3/2020 6:38 AM, Richard Purdie wrote: > On Tue, 2020-03-03 at 06:25 -0800, Tim Orling wrote: >> >> On Tue, Mar 3, 2020 at 4:32 AM Peter Kjellerstedt < >> peter.kjellerstedt at axis.com> wrote: >>>> -----Original Message----- >>>> From: openembedded-core-bounces at lists.openembedded.org >>> >>> bounces at lists.openembedded.org> On Behalf Of >>> rpjday at crashcourse.ca >>>> Sent: den 2 mars 2020 13:41 >>>> To: openembedded-core at lists.openembedded.org >>>> Subject: [OE-core] how to cleanly centralize a zillion >>> BBCLASSEXTEND += >>>> "nativesdk" settings? >>>> >>>> layer i'm currently perusing has many, many bbappend files, of >>> which >>>> quite a number are nothing more than the single line: >>>> >>>> BBCLASSEXTEND += "nativesdk" >>>> >>>> literally, at least a hundred append files are like that. so >>> rather >>>> than clutter up the layer with all those trivial .bbappend files, >>>> can one cram all that into a single .conf file? as i read it, can >>> i >>>> do something like: >>>> >>>> BBCLASSEXTEND_append_pn-pkg1 = " nativesdk" >>>> BBCLASSEXTEND_append_pn-pkg2 = " nativesdk" >>>> ... and on and on ... >>>> >>>> and toss all that into a distro.conf file or something? >>>> >>>> and even if that works, is it considered good coding style? >>>> >>>> rday >>> Sounds perfectly fine. We do something similar, but in our case we >>> need >>> to add "native" to BBCLASSEXTEND for a whole bunch of recipes. >>> >> Should patches be sent to add native and nativesdk? Drop the >> technical debt by upstreaming... > I'm torn on this since adding these does have performance impact. We've > talked about adding them as defaults but it does increase parsing time > and so on... Why not a couple of distro level classes? all-recipes-native all-recipes-nativesdk Or something similar. Then you can turn it on if you need it, and leave it optional to not impose a parse performance pentalty on those that don't need or want it. -- Jeremy A. Puhlman jpuhlman at mvista.com From jpuhlman at mvista.com Tue Mar 3 19:21:24 2020 From: jpuhlman at mvista.com (Jeremy Puhlman) Date: Tue, 3 Mar 2020 11:21:24 -0800 Subject: [OE-core] [PATCH] arch-arm64.inc: Do not append aarch64 in MACHINEOVERRIDES In-Reply-To: <20200303133931.GB13148@localhost> References: <20200302171153.28030-1-zhengjunling@huawei.com> <666b3145-0e57-cf3c-f1f4-22d6fd0521e5@gmail.com> <9d41cd5d-7355-175d-391c-35231c9a7e92@huawei.com> <41b7391039564f10a0c8b4f63eeb4274@XBOX03.axis.com> <20200303133931.GB13148@localhost> Message-ID: <64fa9ad2-55e8-1283-bd34-c22bf5d14cd5@mvista.com> On 3/3/2020 5:39 AM, Adrian Bunk wrote: > On Tue, Mar 03, 2020 at 11:59:58AM +0000, Peter Kjellerstedt wrote: >> ... >> Which corresponds to how it is done for armv7*. >> >> At least we currently rely on being able to do, e.g.: >> >> COMPATIBLE_MACHINE = "aarch64|armv7a|armv7ve" >> >> and if you remove "aarch64" from MACHINEOVERRIDES, we need a suitable >> substitute. > What does "aarch64" actually mean here? > Does it also cover 32bit-only aarch64 CPUs? > > Similar to x86 there are 3 ABIs, and aarch64ilp32 is different from aarch32. > > Different from x86, there is no ABI that is available in all aarch64 CPUs. > They can be 32bit-only or 64bit-only, and aarch32 support is optional. In our past work with ilp32, aarch64 usually covered both because in general the abi's have more in common then they are different. If something specific for ilp32 was required we would use the aarch64ipl32 override to resolve the issue. Not so sure about aarch32 as? I haven't done much with it. -- Jeremy A. Puhlman jpuhlman at mvista.com From raj.khem at gmail.com Tue Mar 3 19:27:24 2020 From: raj.khem at gmail.com (Khem Raj) Date: Tue, 3 Mar 2020 11:27:24 -0800 Subject: [OE-core] [PATCH] arch-arm64.inc: Do not append aarch64 in MACHINEOVERRIDES In-Reply-To: <20200302213441.GA13148@localhost> References: <20200302171153.28030-1-zhengjunling@huawei.com> <666b3145-0e57-cf3c-f1f4-22d6fd0521e5@gmail.com> <20200302213441.GA13148@localhost> Message-ID: <782f99dd-dcf6-6e02-e7fb-08539711b1d7@gmail.com> On 3/2/20 1:34 PM, Adrian Bunk wrote: > On Mon, Mar 02, 2020 at 10:29:37AM -0800, Khem Raj wrote: >> >> >> On 3/2/20 9:11 AM, Junling Zheng wrote: >>> Currently, for arch-arm64, poky will append the MACHINEOVERRIDES with >>> "aarch64:", which has the higher priority than TRANSLATED_TARGET_ARCH. >>> So, for aarch64 big endian, the variable '_aarch64' will override >>> not only '', but also '_aarch64-be', thus we will get an >>> incorrect variable. >>> >>> Signed-off-by: Junling Zheng >>> --- >>> meta/conf/machine/include/arm/arch-arm64.inc | 2 -- >>> 1 file changed, 2 deletions(-) >>> >>> diff --git a/meta/conf/machine/include/arm/arch-arm64.inc b/meta/conf/machine/include/arm/arch-arm64.inc >>> index 53f4566815..32294bd218 100644 >>> --- a/meta/conf/machine/include/arm/arch-arm64.inc >>> +++ b/meta/conf/machine/include/arm/arch-arm64.inc >>> @@ -4,8 +4,6 @@ require conf/machine/include/arm/arch-armv7ve.inc >>> TUNEVALID[aarch64] = "Enable instructions for aarch64" >>> -MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'aarch64', 'aarch64:', '' ,d)}" >>> - >> >> if its removed here, where is it being added for other machines, question >> is, should we treat aarch64 as LE equivalent of aarch64_be >> or should be treated as common aarch64 and a new define like aarch64_le >> defined. >> ... > > As far as I am aware all other distributions and config.guess are > treating aarch64/arm64 as little endian and 64bit, unless suffixed. this is effective only in defining overrides and like we have for mips there is a common override like mipsarch, that apply to all mips. and mips in itself does mean MIPS BE, so my question was if there is a value in having a common overrrided across all aarch64 variants we have irrepective of endianness or wordlength, its fine if we want to treat aarch64 as LE From raj.khem at gmail.com Tue Mar 3 19:31:44 2020 From: raj.khem at gmail.com (Khem Raj) Date: Tue, 3 Mar 2020 11:31:44 -0800 Subject: [OE-core] [PATCH] arch-arm64.inc: Do not append aarch64 in MACHINEOVERRIDES In-Reply-To: <41b7391039564f10a0c8b4f63eeb4274@XBOX03.axis.com> References: <20200302171153.28030-1-zhengjunling@huawei.com> <666b3145-0e57-cf3c-f1f4-22d6fd0521e5@gmail.com> <9d41cd5d-7355-175d-391c-35231c9a7e92@huawei.com> <41b7391039564f10a0c8b4f63eeb4274@XBOX03.axis.com> Message-ID: <395e6f3d-7223-4322-9f65-3117a68c17af@gmail.com> On 3/3/20 3:59 AM, Peter Kjellerstedt wrote: >> -----Original Message----- >> From: openembedded-core-bounces at lists.openembedded.org > bounces at lists.openembedded.org> On Behalf Of Junling Zheng >> Sent: den 3 mars 2020 04:11 >> To: Khem Raj ; openembedded- >> core at lists.openembedded.org >> Cc: wangnan0 at huawei.com >> Subject: Re: [OE-core] [PATCH] arch-arm64.inc: Do not append aarch64 in >> MACHINEOVERRIDES >> >> On 2020/3/3 2:29, Khem Raj wrote: >>> >>> >>> On 3/2/20 9:11 AM, Junling Zheng wrote: >>>> Currently, for arch-arm64, poky will append the MACHINEOVERRIDES with >>>> "aarch64:", which has the higher priority than TRANSLATED_TARGET_ARCH. >>>> So, for aarch64 big endian, the variable '_aarch64' will override >>>> not only '', but also '_aarch64-be', thus we will get an >>>> incorrect variable. >>>> >>>> Signed-off-by: Junling Zheng >>>> --- >>>> meta/conf/machine/include/arm/arch-arm64.inc | 2 -- >>>> 1 file changed, 2 deletions(-) >>>> >>>> diff --git a/meta/conf/machine/include/arm/arch-arm64.inc >> b/meta/conf/machine/include/arm/arch-arm64.inc >>>> index 53f4566815..32294bd218 100644 >>>> --- a/meta/conf/machine/include/arm/arch-arm64.inc >>>> +++ b/meta/conf/machine/include/arm/arch-arm64.inc >>>> @@ -4,8 +4,6 @@ require conf/machine/include/arm/arch-armv7ve.inc >>>> TUNEVALID[aarch64] = "Enable instructions for aarch64" >>>> -MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'aarch64', 'aarch64:', '' ,d)}" >>>> - >>> >>> if its removed here, where is it being added for other machines, >> question is, should we treat aarch64 as LE equivalent of aarch64_be >>> or should be treated as common aarch64 and a new define like aarch64_le >> defined. >>> >> >> Currently, for arm64, we have aarch64_be to represent big endian, but no >> overrides to represent little endian only. >> >> So, IMO, we should treat aarch64 as little enaian only, like arm and >> armeb. >> >>>> # Little Endian base configs >>>> AVAILTUNES += "aarch64 aarch64_be" >>>> ARMPKGARCH_tune-aarch64 ?= "aarch64" > > Please, before removing "aarch64" from MACHINEOVERRIDES, add "armv8a" or > similar. This is how it is done for the armv7* based chips. E.g., I would > expect to see tune-cortexa53.inc have: > > MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'cortexa53', 'armv8a:', '' ,d)}" > > Which corresponds to how it is done for armv7*. > > At least we currently rely on being able to do, e.g.: > > COMPATIBLE_MACHINE = "aarch64|armv7a|armv7ve" > > and if you remove "aarch64" from MACHINEOVERRIDES, we need a suitable > substitute. I think armv8a or somesuch might be better in the above usecase, but so far I think we have treated aarch64 as common arm64 notation, so removing this might have more changes needed in rest of metadata, which would be not good. > > //Peter > From akuster808 at gmail.com Tue Mar 3 21:09:03 2020 From: akuster808 at gmail.com (Armin Kuster) Date: Tue, 3 Mar 2020 13:09:03 -0800 Subject: [OE-core] [v2][PATCH] libuv: move from meta-oe to core for bind update Message-ID: <20200303210903.29570-1-akuster808@gmail.com> From: Armin Kuster Signed-off-by: Armin Kuster [v2] Add maintainer Update to newer version in meta-oe --- meta/conf/distro/include/maintainers.inc | 1 + .../libuv/libuv_1.34.2.bb | 19 +++++++++++++++++++ 2 files changed, 20 insertions(+) create mode 100644 meta/recipes-connectivity/libuv/libuv_1.34.2.bb diff --git a/meta/conf/distro/include/maintainers.inc b/meta/conf/distro/include/maintainers.inc index 10095ffe76..d724148014 100644 --- a/meta/conf/distro/include/maintainers.inc +++ b/meta/conf/distro/include/maintainers.inc @@ -392,6 +392,7 @@ RECIPE_MAINTAINER_pn-liburcu = "Alexander Kanavin " RECIPE_MAINTAINER_pn-liburi-perl = "Tim Orling " RECIPE_MAINTAINER_pn-libusb1 = "Anuj Mittal " RECIPE_MAINTAINER_pn-libubootenv = "Stefano Babic " +RECIPE_MAINTAINER_pn-libuv = "Armin Kuster " RECIPE_MAINTAINER_pn-libva = "Anuj Mittal " RECIPE_MAINTAINER_pn-libva-utils = "Anuj Mittal " RECIPE_MAINTAINER_pn-libvorbis = "Tanu Kaskinen " diff --git a/meta/recipes-connectivity/libuv/libuv_1.34.2.bb b/meta/recipes-connectivity/libuv/libuv_1.34.2.bb new file mode 100644 index 0000000000..234cec37bb --- /dev/null +++ b/meta/recipes-connectivity/libuv/libuv_1.34.2.bb @@ -0,0 +1,19 @@ +SUMMARY = "A multi-platform support library with a focus on asynchronous I/O" +HOMEPAGE = "https://github.com/libuv/libuv" +BUGTRACKER = "https://github.com/libuv/libuv/issues" +LICENSE = "MIT" +LIC_FILES_CHKSUM = "file://LICENSE;md5=a68902a430e32200263d182d44924d47" + +SRCREV = "f868c9ab0c307525a16fff99fd21e32a6ebc3837" +SRC_URI = "git://github.com/libuv/libuv;branch=v1.x" + +S = "${WORKDIR}/git" + +inherit autotools + +do_configure() { + ${S}/autogen.sh || bbnote "${PN} failed to autogen.sh" + oe_runconf +} + +BBCLASSEXTEND = "native" -- 2.17.1 From raj.khem at gmail.com Tue Mar 3 21:17:34 2020 From: raj.khem at gmail.com (Khem Raj) Date: Tue, 3 Mar 2020 13:17:34 -0800 Subject: [OE-core] [v2][PATCH] libuv: move from meta-oe to core for bind update In-Reply-To: <20200303210903.29570-1-akuster808@gmail.com> References: <20200303210903.29570-1-akuster808@gmail.com> Message-ID: <8f852a36-aa41-7f75-0f57-7d82fd19377e@gmail.com> Please send removal for meta-oe as well, once its merged in core, otherwise meta-oe will override it. On 3/3/20 1:09 PM, Armin Kuster wrote: > From: Armin Kuster > > Signed-off-by: Armin Kuster > > [v2] > Add maintainer > Update to newer version in meta-oe > --- > meta/conf/distro/include/maintainers.inc | 1 + > .../libuv/libuv_1.34.2.bb | 19 +++++++++++++++++++ > 2 files changed, 20 insertions(+) > create mode 100644 meta/recipes-connectivity/libuv/libuv_1.34.2.bb > > diff --git a/meta/conf/distro/include/maintainers.inc b/meta/conf/distro/include/maintainers.inc > index 10095ffe76..d724148014 100644 > --- a/meta/conf/distro/include/maintainers.inc > +++ b/meta/conf/distro/include/maintainers.inc > @@ -392,6 +392,7 @@ RECIPE_MAINTAINER_pn-liburcu = "Alexander Kanavin " > RECIPE_MAINTAINER_pn-liburi-perl = "Tim Orling " > RECIPE_MAINTAINER_pn-libusb1 = "Anuj Mittal " > RECIPE_MAINTAINER_pn-libubootenv = "Stefano Babic " > +RECIPE_MAINTAINER_pn-libuv = "Armin Kuster " > RECIPE_MAINTAINER_pn-libva = "Anuj Mittal " > RECIPE_MAINTAINER_pn-libva-utils = "Anuj Mittal " > RECIPE_MAINTAINER_pn-libvorbis = "Tanu Kaskinen " > diff --git a/meta/recipes-connectivity/libuv/libuv_1.34.2.bb b/meta/recipes-connectivity/libuv/libuv_1.34.2.bb > new file mode 100644 > index 0000000000..234cec37bb > --- /dev/null > +++ b/meta/recipes-connectivity/libuv/libuv_1.34.2.bb > @@ -0,0 +1,19 @@ > +SUMMARY = "A multi-platform support library with a focus on asynchronous I/O" > +HOMEPAGE = "https://github.com/libuv/libuv" > +BUGTRACKER = "https://github.com/libuv/libuv/issues" > +LICENSE = "MIT" > +LIC_FILES_CHKSUM = "file://LICENSE;md5=a68902a430e32200263d182d44924d47" > + > +SRCREV = "f868c9ab0c307525a16fff99fd21e32a6ebc3837" > +SRC_URI = "git://github.com/libuv/libuv;branch=v1.x" > + > +S = "${WORKDIR}/git" > + > +inherit autotools > + > +do_configure() { > + ${S}/autogen.sh || bbnote "${PN} failed to autogen.sh" > + oe_runconf > +} > + > +BBCLASSEXTEND = "native" > From martin.jansa at gmail.com Tue Mar 3 21:22:43 2020 From: martin.jansa at gmail.com (Martin Jansa) Date: Tue, 3 Mar 2020 22:22:43 +0100 Subject: [OE-core] [v2][PATCH] libuv: move from meta-oe to core for bind update In-Reply-To: <20200303210903.29570-1-akuster808@gmail.com> References: <20200303210903.29570-1-akuster808@gmail.com> Message-ID: <20200303212243.vm7nwzuf4viwwaat@jama> On Tue, Mar 03, 2020 at 01:09:03PM -0800, Armin Kuster wrote: > From: Armin Kuster > > Signed-off-by: Armin Kuster > > [v2] > Add maintainer > Update to newer version in meta-oe This belongs either under --- or in this case normal commit message before Signed-off-by (without '[v2]'). > --- > meta/conf/distro/include/maintainers.inc | 1 + > .../libuv/libuv_1.34.2.bb | 19 +++++++++++++++++++ > 2 files changed, 20 insertions(+) > create mode 100644 meta/recipes-connectivity/libuv/libuv_1.34.2.bb > > diff --git a/meta/conf/distro/include/maintainers.inc b/meta/conf/distro/include/maintainers.inc > index 10095ffe76..d724148014 100644 > --- a/meta/conf/distro/include/maintainers.inc > +++ b/meta/conf/distro/include/maintainers.inc > @@ -392,6 +392,7 @@ RECIPE_MAINTAINER_pn-liburcu = "Alexander Kanavin " > RECIPE_MAINTAINER_pn-liburi-perl = "Tim Orling " > RECIPE_MAINTAINER_pn-libusb1 = "Anuj Mittal " > RECIPE_MAINTAINER_pn-libubootenv = "Stefano Babic " > +RECIPE_MAINTAINER_pn-libuv = "Armin Kuster " > RECIPE_MAINTAINER_pn-libva = "Anuj Mittal " > RECIPE_MAINTAINER_pn-libva-utils = "Anuj Mittal " > RECIPE_MAINTAINER_pn-libvorbis = "Tanu Kaskinen " > diff --git a/meta/recipes-connectivity/libuv/libuv_1.34.2.bb b/meta/recipes-connectivity/libuv/libuv_1.34.2.bb > new file mode 100644 > index 0000000000..234cec37bb > --- /dev/null > +++ b/meta/recipes-connectivity/libuv/libuv_1.34.2.bb > @@ -0,0 +1,19 @@ > +SUMMARY = "A multi-platform support library with a focus on asynchronous I/O" > +HOMEPAGE = "https://github.com/libuv/libuv" > +BUGTRACKER = "https://github.com/libuv/libuv/issues" > +LICENSE = "MIT" > +LIC_FILES_CHKSUM = "file://LICENSE;md5=a68902a430e32200263d182d44924d47" > + > +SRCREV = "f868c9ab0c307525a16fff99fd21e32a6ebc3837" > +SRC_URI = "git://github.com/libuv/libuv;branch=v1.x" > + > +S = "${WORKDIR}/git" > + > +inherit autotools > + > +do_configure() { > + ${S}/autogen.sh || bbnote "${PN} failed to autogen.sh" > + oe_runconf > +} > + > +BBCLASSEXTEND = "native" > -- > 2.17.1 > > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core at lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From leon at sidebranch.com Tue Mar 3 21:23:08 2020 From: leon at sidebranch.com (Leon Woestenberg) Date: Tue, 3 Mar 2020 22:23:08 +0100 Subject: [OE-core] freetype: add pixmap to PACKAGECONFIG In-Reply-To: <6353532b-aa0e-a005-2589-2e8281863fd5@gmail.com> References: <20200229234742.3780-1-matt.ranostay@konsulko.com> <6353532b-aa0e-a005-2589-2e8281863fd5@gmail.com> Message-ID: Hello all, On Tue, Mar 3, 2020 at 6:42 PM Jacob Kroon wrote: > > On 3/1/20 12:47 AM, Matt Ranostay wrote: > > Add pixmap to PACKAGECONFIG defaults to allow consumers to > > render color emojis without distro changes. > > > > Signed-off-by: Matt Ranostay > > --- > > -PACKAGECONFIG ??= "zlib" > > +PACKAGECONFIG ??= "zlib pixmap" > > > Wouldn't it make sense to keep it off by default and let whoever needs it enable it ? > /Jacob > I would agree, and would also vote for opt-in rather than opt-out for this use-case. Do we have a more generic stance on how we select the PACKAGECONFIG defaults? Regards, Leon. From richard.purdie at linuxfoundation.org Tue Mar 3 21:45:25 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Tue, 03 Mar 2020 21:45:25 +0000 Subject: [OE-core] freetype: add pixmap to PACKAGECONFIG In-Reply-To: References: <20200229234742.3780-1-matt.ranostay@konsulko.com> <6353532b-aa0e-a005-2589-2e8281863fd5@gmail.com> Message-ID: <5251314825f750f21564e99b8e20b0de2625fd50.camel@linuxfoundation.org> On Tue, 2020-03-03 at 22:23 +0100, Leon Woestenberg wrote: > Hello all, > > On Tue, Mar 3, 2020 at 6:42 PM Jacob Kroon > wrote: > > On 3/1/20 12:47 AM, Matt Ranostay wrote: > > > Add pixmap to PACKAGECONFIG defaults to allow consumers to > > > render color emojis without distro changes. > > > > > > Signed-off-by: Matt Ranostay > > > --- > > > -PACKAGECONFIG ??= "zlib" > > > +PACKAGECONFIG ??= "zlib pixmap" > > > > > Wouldn't it make sense to keep it off by default and let whoever > > needs it enable it ? > > /Jacob > > > I would agree, and would also vote for opt-in rather than opt-out for > this use-case. > > Do we have a more generic stance on how we select the PACKAGECONFIG > defaults? It feels like I've seen this come in a few times, I've said no, it keeps coming back, I gave in. Basically the policy is trying to keep things as sensible defaults for the majority of users. Many of our users are concerned about build time, space usage and minimisation of dependencies. These things do change over time as our userbase changes and as the demands and expectations from software changes. In this case its fairly hard to figure out that tweaking this option breaks emojis and libpng isn't such an uncommon or problematic library. Its hard for me as the maintainer of all this to get a decent feeling for how people feel about some changes so its also based a lot on feel, there is only limited patch review a lot of the time. If there is strong demand not to have this, we can revert it. I'd like to see how many people do/don't want it and see a few more opinions on that though. Cheers, Richard From martin.jansa at gmail.com Tue Mar 3 22:10:50 2020 From: martin.jansa at gmail.com (Martin Jansa) Date: Tue, 3 Mar 2020 23:10:50 +0100 Subject: [OE-core] freetype: add pixmap to PACKAGECONFIG In-Reply-To: <5251314825f750f21564e99b8e20b0de2625fd50.camel@linuxfoundation.org> References: <20200229234742.3780-1-matt.ranostay@konsulko.com> <6353532b-aa0e-a005-2589-2e8281863fd5@gmail.com> <5251314825f750f21564e99b8e20b0de2625fd50.camel@linuxfoundation.org> Message-ID: <20200303221050.ldjizftg4vnq4m6r@jama> On Tue, Mar 03, 2020 at 09:45:25PM +0000, Richard Purdie wrote: > On Tue, 2020-03-03 at 22:23 +0100, Leon Woestenberg wrote: > > Hello all, > > > > On Tue, Mar 3, 2020 at 6:42 PM Jacob Kroon > > wrote: > > > On 3/1/20 12:47 AM, Matt Ranostay wrote: > > > > Add pixmap to PACKAGECONFIG defaults to allow consumers to > > > > render color emojis without distro changes. > > > > > > > > Signed-off-by: Matt Ranostay > > > > --- > > > > -PACKAGECONFIG ??= "zlib" > > > > +PACKAGECONFIG ??= "zlib pixmap" > > > > > > > Wouldn't it make sense to keep it off by default and let whoever > > > needs it enable it ? > > > /Jacob > > > > > I would agree, and would also vote for opt-in rather than opt-out for > > this use-case. > > > > Do we have a more generic stance on how we select the PACKAGECONFIG > > defaults? > > It feels like I've seen this come in a few times, I've said no, it > keeps coming back, I gave in. > > Basically the policy is trying to keep things as sensible defaults for > the majority of users. Many of our users are concerned about build > time, space usage and minimisation of dependencies. > > These things do change over time as our userbase changes and as the > demands and expectations from software changes. > > In this case its fairly hard to figure out that tweaking this option > breaks emojis and libpng isn't such an uncommon or problematic library. > > Its hard for me as the maintainer of all this to get a decent feeling > for how people feel about some changes so its also based a lot on feel, > there is only limited patch review a lot of the time. > > If there is strong demand not to have this, we can revert it. I'd like > to see how many people do/don't want it and see a few more opinions on > that though. We (as LGE) have pixmap enabled at least since 2015, because people really want their color emojis on TVs, so having this enabled by default will allow me to eventually drop 1 bbappend from our layers eventually when we upgrade to 3.1. So I would vote to keep this change. But on the other hand it will still leave 828 other bbappends, so it doesn't make much difference to me :). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From jacob.kroon at gmail.com Tue Mar 3 22:14:09 2020 From: jacob.kroon at gmail.com (Jacob Kroon) Date: Tue, 3 Mar 2020 23:14:09 +0100 Subject: [OE-core] freetype: add pixmap to PACKAGECONFIG In-Reply-To: <20200303221050.ldjizftg4vnq4m6r@jama> References: <20200229234742.3780-1-matt.ranostay@konsulko.com> <6353532b-aa0e-a005-2589-2e8281863fd5@gmail.com> <5251314825f750f21564e99b8e20b0de2625fd50.camel@linuxfoundation.org> <20200303221050.ldjizftg4vnq4m6r@jama> Message-ID: On 3/3/20 11:10 PM, Martin Jansa wrote: > On Tue, Mar 03, 2020 at 09:45:25PM +0000, Richard Purdie wrote: >> On Tue, 2020-03-03 at 22:23 +0100, Leon Woestenberg wrote: >>> Hello all, >>> >>> On Tue, Mar 3, 2020 at 6:42 PM Jacob Kroon >>> wrote: >>>> On 3/1/20 12:47 AM, Matt Ranostay wrote: >>>>> Add pixmap to PACKAGECONFIG defaults to allow consumers to >>>>> render color emojis without distro changes. >>>>> >>>>> Signed-off-by: Matt Ranostay >>>>> --- >>>>> -PACKAGECONFIG ??= "zlib" >>>>> +PACKAGECONFIG ??= "zlib pixmap" >>>>> >>>> Wouldn't it make sense to keep it off by default and let whoever >>>> needs it enable it ? >>>> /Jacob >>>> >>> I would agree, and would also vote for opt-in rather than opt-out for >>> this use-case. >>> >>> Do we have a more generic stance on how we select the PACKAGECONFIG >>> defaults? >> >> It feels like I've seen this come in a few times, I've said no, it >> keeps coming back, I gave in. >> >> Basically the policy is trying to keep things as sensible defaults for >> the majority of users. Many of our users are concerned about build >> time, space usage and minimisation of dependencies. >> >> These things do change over time as our userbase changes and as the >> demands and expectations from software changes. >> >> In this case its fairly hard to figure out that tweaking this option >> breaks emojis and libpng isn't such an uncommon or problematic library. >> >> Its hard for me as the maintainer of all this to get a decent feeling >> for how people feel about some changes so its also based a lot on feel, >> there is only limited patch review a lot of the time. >> >> If there is strong demand not to have this, we can revert it. I'd like >> to see how many people do/don't want it and see a few more opinions on >> that though. > > We (as LGE) have pixmap enabled at least since 2015, because people > really want their color emojis on TVs, so having this enabled by default > will allow me to eventually drop 1 bbappend from our layers eventually > when we upgrade to 3.1. > > So I would vote to keep this change. > > But on the other hand it will still leave 828 other bbappends, so it > doesn't make much difference to me :). > Fair enough, sounds like there are good reasons to have it enabled by default. /Jacob From joe.slater at windriver.com Tue Mar 3 22:56:41 2020 From: joe.slater at windriver.com (Joe Slater) Date: Tue, 3 Mar 2020 14:56:41 -0800 Subject: [OE-core] [oe-core][PATCH 1/1] blktrace: modify two scripts for python3 Message-ID: <20200303225641.55243-1-joe.slater@windriver.com> Backport from git.kernel.dk. Changed shebangs to use python3. Signed-off-by: Joe Slater --- .../blktrace/make-btt-scripts-python3-ready.patch | 197 +++++++++++++++++++++ meta/recipes-kernel/blktrace/blktrace_git.bb | 1 + 2 files changed, 198 insertions(+) create mode 100644 meta/recipes-kernel/blktrace/blktrace/make-btt-scripts-python3-ready.patch diff --git a/meta/recipes-kernel/blktrace/blktrace/make-btt-scripts-python3-ready.patch b/meta/recipes-kernel/blktrace/blktrace/make-btt-scripts-python3-ready.patch new file mode 100644 index 0000000..3b0c1c6 --- /dev/null +++ b/meta/recipes-kernel/blktrace/blktrace/make-btt-scripts-python3-ready.patch @@ -0,0 +1,197 @@ +From 70d5ca2d5f3d6b97c11c641b7e0c5836983219a0 Mon Sep 17 00:00:00 2001 +From: Eric Sandeen +Date: Wed, 28 Mar 2018 15:26:36 -0500 +Subject: [oe-core][PATCH 1/1] make btt scripts python3-ready + +Many distributions are moving to python3 by default. Here's +an attempt to make the python scripts in blktrace python3-ready. + +Most of this was done with automated tools. I hand fixed some +space-vs tab issues, and cast an array index to integer. It +passes rudimentary testing when run under python2.7 as well +as python3. + +This doesn't do anything with the shebangs, it leaves them both +invoking whatever "env python" coughs up on the system. + +Signed-off-by: Eric Sandeen +Signed-off-by: Jens Axboe + +Unchanged except to modify shebangs to use python3 since +oe-core does not support python2 anymore. + +Upstream-Status: Backport [git://git.kernel.dk/blktrace.git commit 70d5ca2d5...] + +Signed-off-by: Joe Slater + +--- + btt/bno_plot.py | 28 +++++++++++++++------------- + btt/btt_plot.py | 22 +++++++++++++--------- + 2 files changed, 28 insertions(+), 22 deletions(-) + +--- git.orig/btt/bno_plot.py ++++ git/btt/bno_plot.py +@@ -1,4 +1,4 @@ +-#! /usr/bin/env python ++#! /usr/bin/env python3 + # + # btt blkno plotting interface + # +@@ -38,6 +38,8 @@ automatically push the keys under the gr + To exit the plotter, enter 'quit' or ^D at the 'gnuplot> ' prompt. + """ + ++from __future__ import absolute_import ++from __future__ import print_function + import getopt, glob, os, sys, tempfile + + verbose = 0 +@@ -60,14 +62,14 @@ def parse_args(in_args): + + try: + (opts, args) = getopt.getopt(in_args, s_opts, l_opts) +- except getopt.error, msg: +- print >>sys.stderr, msg +- print >>sys.stderr, __doc__ ++ except getopt.error as msg: ++ print(msg, file=sys.stderr) ++ print(__doc__, file=sys.stderr) + sys.exit(1) + + for (o, a) in opts: + if o in ('-h', '--help'): +- print __doc__ ++ print(__doc__) + sys.exit(0) + elif o in ('-v', '--verbose'): + verbose += 1 +@@ -84,10 +86,10 @@ if __name__ == '__main__': + (bnos, keys_below) = parse_args(sys.argv[1:]) + + if verbose: +- print 'Using files:', +- for bno in bnos: print bno, +- if keys_below: print '\nKeys are to be placed below graph' +- else: print '' ++ print('Using files:', end=' ') ++ for bno in bnos: print(bno, end=' ') ++ if keys_below: print('\nKeys are to be placed below graph') ++ else: print('') + + tmpdir = tempfile.mktemp() + os.mkdir(tmpdir) +@@ -99,7 +101,7 @@ if __name__ == '__main__': + fo = open(t, 'w') + for line in open(f, 'r'): + fld = line.split(None) +- print >>fo, fld[0], fld[1], int(fld[2])-int(fld[1]) ++ print(fld[0], fld[1], int(fld[2])-int(fld[1]), file=fo) + fo.close() + + t = t[t.rfind('/')+1:] +@@ -107,16 +109,16 @@ if __name__ == '__main__': + else: plot_cmd = "%s,'%s'" % (plot_cmd, t) + + fo = open('%s/plot.cmds' % tmpdir, 'w') +- print >>fo, cmds +- if len(bnos) > 10 or keys_below: print >>fo, 'set key below' +- print >>fo, plot_cmd ++ print(cmds, file=fo) ++ if len(bnos) > 10 or keys_below: print('set key below', file=fo) ++ print(plot_cmd, file=fo) + fo.close() + + pid = os.fork() + if pid == 0: + cmd = 'gnuplot %s/plot.cmds -' % tmpdir + +- if verbose: print 'Executing %s' % cmd ++ if verbose: print('Executing %s' % cmd) + + os.chdir(tmpdir) + os.system(cmd) +--- git.orig/btt/btt_plot.py ++++ git/btt/btt_plot.py +@@ -1,4 +1,4 @@ +-#! /usr/bin/env python ++#! /usr/bin/env python3 + # + # btt_plot.py: Generate matplotlib plots for BTT generate data files + # +@@ -55,6 +55,10 @@ Arguments: + but the -o (--output) and -T (--title) options will be ignored. + """ + ++from __future__ import absolute_import ++from __future__ import print_function ++import six ++from six.moves import range + __author__ = 'Alan D. Brunelle ' + + #------------------------------------------------------------------------------ +@@ -82,7 +86,7 @@ get_base = lambda file: file[file.find( + def fatal(msg): + """Generate fatal error message and exit""" + +- print >>sys.stderr, 'FATAL: %s' % msg ++ print('FATAL: %s' % msg, file=sys.stderr) + sys.exit(1) + + #------------------------------------------------------------------------------ +@@ -163,7 +167,7 @@ def get_data(files): + if not os.path.exists(file): + fatal('%s not found' % file) + elif verbose: +- print 'Processing %s' % file ++ print('Processing %s' % file) + + xs = [] + ys = [] +@@ -214,8 +218,8 @@ def parse_args(args): + + try: + (opts, args) = getopt.getopt(args[1:], s_opts, l_opts) +- except getopt.error, msg: +- print >>sys.stderr, msg ++ except getopt.error as msg: ++ print(msg, file=sys.stderr) + fatal(__doc__) + + for (o, a) in opts: +@@ -293,15 +297,15 @@ def generate_output(type, db): + def color(idx, style): + """Returns a color/symbol type based upon the index passed.""" + +- colors = [ 'b', 'g', 'r', 'c', 'm', 'y', 'k' ] ++ colors = [ 'b', 'g', 'r', 'c', 'm', 'y', 'k' ] + l_styles = [ '-', ':', '--', '-.' ] + m_styles = [ 'o', '+', '.', ',', 's', 'v', 'x', '<', '>' ] + + color = colors[idx % len(colors)] + if style == 'line': +- style = l_styles[(idx / len(l_styles)) % len(l_styles)] ++ style = l_styles[int((idx / len(l_styles)) % len(l_styles))] + elif style == 'marker': +- style = m_styles[(idx / len(m_styles)) % len(m_styles)] ++ style = m_styles[int((idx / len(m_styles)) % len(m_styles))] + + return '%s%s' % (color, style) + +@@ -314,7 +318,7 @@ def generate_output(type, db): + ofile = '%s.png' % type + + if verbose: +- print 'Generating plot into %s' % ofile ++ print('Generating plot into %s' % ofile) + + fig = plt.figure(figsize=plot_size) + ax = fig.add_subplot(111) +@@ -329,7 +333,7 @@ def generate_output(type, db): + legends = None + + keys = [] +- for file in db.iterkeys(): ++ for file in six.iterkeys(db): + if not file in ['min_x', 'max_x', 'min_y', 'max_y']: + keys.append(file) + diff --git a/meta/recipes-kernel/blktrace/blktrace_git.bb b/meta/recipes-kernel/blktrace/blktrace_git.bb index 2605ff9..6903053 100644 --- a/meta/recipes-kernel/blktrace/blktrace_git.bb +++ b/meta/recipes-kernel/blktrace/blktrace_git.bb @@ -12,6 +12,7 @@ PV = "1.2.0+git${SRCPV}" SRC_URI = "git://git.kernel.dk/blktrace.git \ file://ldflags.patch \ file://CVE-2018-10689.patch \ + file://make-btt-scripts-python3-ready.patch \ " S = "${WORKDIR}/git" -- 2.7.4 From richard.purdie at linuxfoundation.org Tue Mar 3 22:57:34 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Tue, 03 Mar 2020 22:57:34 +0000 Subject: [OE-core] Yocto Project Long Term Support (LTS) Announced Message-ID: <0587ded5e0871e7b92052cbe6e5d72fc31968669.camel@linuxfoundation.org> Its posted at: https://www.yoctoproject.org/yocto-project-long-term-support-announced/ but I'll copy it below since this is an important announcement """ To fulfill the evolving requirements of its members and users, the Yocto Project announced a new plan to extend support for selected releases. The new support plan covers an initial two-year period and the first candidate to benefit from this change will be the Yocto Project 3.1 release. A very important criterion for evaluating and adopting a software platform is support. This holds true when it comes to development tools as well. Yocto Project releases are usually maintained for one year. Beyond this period, releases move to community support, which means they only receive occasional patches for critical defects and updates, and no regular defect fixes and security updates. Although this follows the open source culture, where development is particularly known for speed and bleeding-edge innovation, there has been a rising interest among project members and end users for extending this period. As a result, the Yocto Project technical leadership put together a proposal to address this need as well as arranging the tools and processes to allow it to best benefit the project and its users. The project aims to choose an LTS release every two years. The project components covered under the new plan will match the core subset of those included in the standard release process: Bitbake, OE-Core, meta- yocto, and yocto-docs. These components will now receive the usual defect fixes and updates for the extended period of two years. Additional layers, such as meta-mingw, meta-gplv2 or general OSV vendor layers will not be covered and will follow their usual standard support models. The LTS release will support the original kernel it has been shipped with. Yocto Project technical leadership will continuously evaluate other similar older LTS kernels on a case by case basis depending on the status of upstream support. The version of linux-libc-headers would not change to avoid user-space problems. This change will also benefit other downstream projects relying on Yocto Project releases that have longer life cycles such as AGL, RDK etc. The decisions that the technical leadership makes will take into account the community feedback, people committing resources and input from the member organizations. The LTS maintainer will be responsible for queuing and reviewing suitable changes and starting and monitoring builds. The maintainer may have assistance from the community in resolving new issues identified during build or the QA run. Reviews will use the usual community review mailing list processes. For example, where applicable, a merge request will be sent to the appropriate repo owner once all issues found during the review have been addressed. The Yocto Project LTS maintainer role hasn?t been appointed yet. At the moment, the project technical leadership is focused on finding the dedicated resources. For more information, and to discuss the LTS maintainer role, contact lts-maintainer at yoctoproject.org. """ I think there will be some questions and the TSC has been working on documenting the processes around this which are on the wiki. I believe Armin will follow up with some details about what this means for the existing stable series. Cheers, Richard From jpuhlman at mvista.com Tue Mar 3 23:22:02 2020 From: jpuhlman at mvista.com (Jeremy Puhlman) Date: Tue, 3 Mar 2020 15:22:02 -0800 Subject: [OE-core] Multilib conflicts in man pages. Message-ID: <62ba6d2a-098e-acbd-db0e-b2283a3b476a@mvista.com> Is there a preferred method in oe-core for dealing with man pages that conflict due to differences in multilib pathing. For example an application lives in /usr/lib/foo/bar for one abi but /usr/lib64/foo/bar in another, and that kind of information is encoded in to the man pages. Some things i have seen done in the past, is move the man pages under /user/share/man/${PN} or use something like mutlilib script to deal with it. I am just curious if there is a canned, preferred way the project handles those or wants to handle them? xinit, xserver-org, and groff each exhibit? these issues. -- Jeremy A. Puhlman jpuhlman at mvista.com From richard.purdie at linuxfoundation.org Tue Mar 3 23:28:04 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Tue, 03 Mar 2020 23:28:04 +0000 Subject: [OE-core] [PATCH 2/2] bind: Update to latest ESV version 9.16 In-Reply-To: <20200227205608.26788-3-akuster808@gmail.com> References: <20200227205608.26788-1-akuster808@gmail.com> <20200227205608.26788-3-akuster808@gmail.com> Message-ID: <94b6b796b1fef8eeb229cfed0e8467ef415d5221.camel@linuxfoundation.org> On Thu, 2020-02-27 at 12:56 -0800, Armin Kuster wrote: > From: Armin Kuster > > Removed obsolete packageconfig options > > License change to MPL-2.0 > https://gitlab.isc.org/isc-projects/bind9/blob/master/LICENSE > > Refreshed: > bind-ensure-searching-for-json-headers-searches-sysr.patch > 0001-named-lwresd-V-and-start-log-hide-build-options.patch > > Drop obsolete patch: 0001-configure.in-remove-useless-L-use_openssl- > lib.patch > > Signed-off-by: Armin Kuster Do we need to upgrade dhcp too? https://autobuilder.yoctoproject.org/typhoon/#/builders/23/builds/1879 https://autobuilder.yoctoproject.org/typhoon/#/builders/45/builds/1649 Cheers, Richard From denis at denix.org Tue Mar 3 23:45:09 2020 From: denis at denix.org (Denys Dmytriyenko) Date: Tue, 3 Mar 2020 18:45:09 -0500 Subject: [OE-core] [PATCH] openssl: recommend cryptodev-module for corresponding PACKAGECONFIG Message-ID: <1583279109-41106-1-git-send-email-denis@denix.org> From: Denys Dmytriyenko Signed-off-by: Denys Dmytriyenko --- meta/recipes-connectivity/openssl/openssl_1.1.1d.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb b/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb index c2ba005..a9965e7 100644 --- a/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb +++ b/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb @@ -34,7 +34,7 @@ PACKAGECONFIG ?= "" PACKAGECONFIG_class-native = "" PACKAGECONFIG_class-nativesdk = "" -PACKAGECONFIG[cryptodev-linux] = "enable-devcryptoeng,disable-devcryptoeng,cryptodev-linux" +PACKAGECONFIG[cryptodev-linux] = "enable-devcryptoeng,disable-devcryptoeng,cryptodev-linux,,cryptodev-module" B = "${WORKDIR}/build" do_configure[cleandirs] = "${B}" -- 2.7.4 From anuj.mittal at intel.com Tue Mar 3 23:49:59 2020 From: anuj.mittal at intel.com (Mittal, Anuj) Date: Tue, 3 Mar 2020 23:49:59 +0000 Subject: [OE-core] bash: Fix CVE-2019-18276 In-Reply-To: References: <4f09ab13-9571-3464-2fc3-334bc91b9c09@case.edu> <444185BB2F013F4E92378F99BCF8A58BC9AF9CBD@ALA-MBD.corp.ad.wrs.com> <99d34efd-3a68-0b05-0e15-fbfd360a2f2a@case.edu> <9b99752af2094590137fdaacf6668f170b34158c.camel@linuxfoundation.org> ,<41e8a2902bc8594a17f0afa1744f04a6facd5316.camel@intel.com> Message-ID: <5cc81afa618ea969dc3d03f6e7ce356ec08e8efe.camel@intel.com> On Tue, 2020-03-03 at 03:11 +0000, Yu, Mingli wrote: > Hi Anuj, > > I agree the Backport status is not accurate as the patch doesn't go > to master branch, but why do you say the patch is irrelevant to the > CVE-2019-18276, could you help to provide more info? I didn't say that the patch was irrelevant to the CVE. I had said that not all the changes were relevant. I believe the glob changes in the patch were irrelevant. Those changes also introduced a failure in bash ptests. Thanks, Anuj From anuj.mittal at intel.com Tue Mar 3 23:59:38 2020 From: anuj.mittal at intel.com (Anuj Mittal) Date: Wed, 4 Mar 2020 07:59:38 +0800 Subject: [OE-core] [zeus][PATCH 00/22] zeus merge request, cover letter only Message-ID: Please merge these changes from stable/zeus-next. Clean a-full on autobuilder except a single unrelated fetch failure for esdk test: https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/751 Thanks, Anuj The following changes since commit f39285bb82e68945a81034b84da09ca1078d6719: Revert "bash: Fix CVE-2019-18276" (2020-02-19 18:53:10 +0000) are available in the Git repository at: git://push.openembedded.org/openembedded-core-contrib stable/zeus-next Alexander Kanavin (5): perl: update to 5.30.1 perl: package Config.pm from arch directory into the main perl package perl: install typemap and other extutils metadata as part of perl-core libmodule-build-perl: fix ptests perl: fix failing ptests Anuj Mittal (3): openssh: backport patch to fix "cert not yet valid" test ncurses: add CVE_VERSION libxml2: fix CVE-2020-7595 Bruce Ashfield (2): linux-yocto/5.2: update to v5.2.29 linux-yocto/5.2: update to v5.2.32 Jeremy Puhlman (1): toolchain-shar-extract: ignore timestamp on decompress Kevin Hao (1): xserver-nodm-init: Fix the start failure for non-root user Lee Chee Yang (2): qemu: Fix CVE-2020-1711 libxml2: Fix CVE-2019-20388 Nathan Rossi (2): glibc-testsuite: Remove the do_install task glibc-testsuite: Exclude this recipe from world builds Richard Purdie (2): perl: Fix encode module reproducibility issues perl: Fix makefile race causing configuration differences Ross Burton (1): perl: improve reproducibility Tim Orling (1): liberror-perl: upgrade 0.17028 -> 0.17029 Trevor Gamblin (1): qemurunner.py: add try/except for pid handling race Yi Zhao (1): ppp: Security fix CVE-2020-8597 meta/files/toolchain-shar-extract.sh | 2 +- meta/lib/oeqa/utils/qemurunner.py | 5 +- ...zo-decided-to-use-2020-as-a-future-d.patch | 46 +++++++++++++ .../openssh/openssh_8.0p1.bb | 1 + ...01-pppd-Fix-bounds-check-in-EAP-code.patch | 47 ++++++++++++++ meta/recipes-connectivity/ppp/ppp_2.4.7.bb | 1 + .../glibc/glibc-testsuite_2.30.bb | 3 + .../libxml/libxml2/CVE-2019-20388.patch | 37 +++++++++++ .../libxml/libxml2/CVE-2020-7595.patch | 36 +++++++++++ meta/recipes-core/libxml/libxml2_2.9.9.bb | 2 + .../ncurses/ncurses_6.1+20190803.bb | 2 + ...correctly-exclude-unbuilt-extensions.patch | 27 ++++++++ .../perl/files/encodefix.patch | 20 ++++++ .../perl/files/fix-setgroup.patch | 49 -------------- .../perl/files/perl-configpm-switch.patch | 4 +- .../recipes-devtools/perl/files/racefix.patch | 24 +++++++ ...rl_0.17028.bb => liberror-perl_0.17029.bb} | 4 +- .../perl/libmodule-build-perl/run-ptest | 2 - .../perl/libmodule-build-perl_0.4229.bb | 3 + .../perl/{perl_5.30.0.bb => perl_5.30.1.bb} | 31 ++++++--- meta/recipes-devtools/qemu/qemu.inc | 3 +- .../qemu/qemu/CVE-2020-1711.patch | 64 +++++++++++++++++++ .../xserver-nodm-init/capability.conf | 2 + .../x11-common/xserver-nodm-init/xserver-nodm | 8 +++ .../x11-common/xserver-nodm-init_3.0.bb | 7 +- .../linux/linux-yocto-rt_5.2.bb | 6 +- .../linux/linux-yocto-tiny_5.2.bb | 8 +-- meta/recipes-kernel/linux/linux-yocto_5.2.bb | 22 +++---- 28 files changed, 379 insertions(+), 87 deletions(-) create mode 100644 meta/recipes-connectivity/openssh/openssh/0001-upstream-what-bozo-decided-to-use-2020-as-a-future-d.patch create mode 100644 meta/recipes-connectivity/ppp/ppp/0001-pppd-Fix-bounds-check-in-EAP-code.patch create mode 100644 meta/recipes-core/libxml/libxml2/CVE-2019-20388.patch create mode 100644 meta/recipes-core/libxml/libxml2/CVE-2020-7595.patch create mode 100644 meta/recipes-devtools/perl/files/0001-tests-adjust-to-correctly-exclude-unbuilt-extensions.patch create mode 100644 meta/recipes-devtools/perl/files/encodefix.patch delete mode 100644 meta/recipes-devtools/perl/files/fix-setgroup.patch create mode 100644 meta/recipes-devtools/perl/files/racefix.patch rename meta/recipes-devtools/perl/{liberror-perl_0.17028.bb => liberror-perl_0.17029.bb} (89%) rename meta/recipes-devtools/perl/{perl_5.30.0.bb => perl_5.30.1.bb} (93%) create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2020-1711.patch create mode 100644 meta/recipes-graphics/x11-common/xserver-nodm-init/capability.conf -- 2.24.1 From jpuhlman at mvista.com Wed Mar 4 00:24:09 2020 From: jpuhlman at mvista.com (Jeremy A. Puhlman) Date: Tue, 3 Mar 2020 16:24:09 -0800 Subject: [OE-core] [PATCH] python3-native: Should not search the system for headers/libraries. Message-ID: <20200304002409.10056-1-jpuhlman@mvista.com> From: Jeremy Puhlman The specific issue here is rpc/rpc.h, but its likely more general. /usr/include is searched for rpc/rpc.h and if it exists on the system, it changes behavior. If you are using the extended buildtools tarball on a machine that has /usr/include/rpc/rpc.h, it will decide that is good enough and not continue to search. nis fails to build because /usr/include and /usr/lib are not part of the include/link paths for the buildtools tarball compiler(nor should they be). This makes it so python3-native will not build if you are using the extended buildtools tarball, but from a larger issue perspective it is building in likely different ways depending on what machine it is building on. libtirpc is already a depend so we shouldn't need the hosts rpc/rcp.h. Signed-off-by: Jeremy A. Puhlman --- ...Don-t-search-system-for-headers-libraries.patch | 29 ++++++++++++++++++++++ meta/recipes-devtools/python/python3_3.8.1.bb | 1 + 2 files changed, 30 insertions(+) create mode 100644 meta/recipes-devtools/python/python3/0001-Don-t-search-system-for-headers-libraries.patch diff --git a/meta/recipes-devtools/python/python3/0001-Don-t-search-system-for-headers-libraries.patch b/meta/recipes-devtools/python/python3/0001-Don-t-search-system-for-headers-libraries.patch new file mode 100644 index 0000000000..acf8e1e9b5 --- /dev/null +++ b/meta/recipes-devtools/python/python3/0001-Don-t-search-system-for-headers-libraries.patch @@ -0,0 +1,29 @@ +From 85e8f86ad2b7dec0848cd55b8e810a5e2722b20a Mon Sep 17 00:00:00 2001 +From: Jeremy Puhlman +Date: Wed, 4 Mar 2020 00:06:42 +0000 +Subject: [PATCH] Don't search system for headers/libraries + +Upstream-Status: Inappropriate [oe-core specific] +Signed-off-by: Jeremy Puhlman +--- + setup.py | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/setup.py b/setup.py +index 9da1b3a..59782c0 100644 +--- a/setup.py ++++ b/setup.py +@@ -674,8 +674,8 @@ class PyBuildExt(build_ext): + add_dir_to_list(self.compiler.include_dirs, + sysconfig.get_config_var("INCLUDEDIR")) + +- system_lib_dirs = ['/lib64', '/usr/lib64', '/lib', '/usr/lib'] +- system_include_dirs = ['/usr/include'] ++ system_lib_dirs = [] ++ system_include_dirs = [] + # lib_dirs and inc_dirs are used to search for files; + # if a file is found in one of those directories, it can + # be assumed that no additional -I,-L directives are needed. +-- +2.24.1 + diff --git a/meta/recipes-devtools/python/python3_3.8.1.bb b/meta/recipes-devtools/python/python3_3.8.1.bb index 77968528c7..5e3c29cb4c 100644 --- a/meta/recipes-devtools/python/python3_3.8.1.bb +++ b/meta/recipes-devtools/python/python3_3.8.1.bb @@ -37,6 +37,7 @@ SRC_URI = "http://www.python.org/ftp/python/${PV}/Python-${PV}.tar.xz \ SRC_URI_append_class-native = " \ file://0001-distutils-sysconfig-append-STAGING_LIBDIR-python-sys.patch \ file://12-distutils-prefix-is-inside-staging-area.patch \ + file://0001-Don-t-search-system-for-headers-libraries.patch \ " SRC_URI[md5sum] = "b3fb85fd479c0bf950c626ef80cacb57" -- 2.13.3 From otavio.salvador at ossystems.com.br Wed Mar 4 00:31:30 2020 From: otavio.salvador at ossystems.com.br (Otavio Salvador) Date: Tue, 3 Mar 2020 21:31:30 -0300 Subject: [OE-core] [PATCH v2 4/4] reproducible: try to ensure reproducible xz archives In-Reply-To: References: <20200303160513.17645-1-git@andred.net> <20200303160513.17645-4-git@andred.net> Message-ID: On Tue, Mar 3, 2020 at 1:08 PM Andr? Draszik wrote: > On Tue, 2020-03-03 at 16:05 +0000, Andr? Draszik wrote: > In an ideal world, it'd parse the output of xz --verbose --verbose, to catch > all possible ways people might be adjusting the thread limit, but that's > non-trivial. Couldn't we just "enforce" at least two threads? It is quite unlikely we ever use OE on a single core machine (as it'd take few years to finish the build hehe) it seems like a reasonable assumption. -- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 From Mingli.Yu at windriver.com Wed Mar 4 01:14:27 2020 From: Mingli.Yu at windriver.com (Yu, Mingli) Date: Wed, 4 Mar 2020 01:14:27 +0000 Subject: [OE-core] bash: Fix CVE-2019-18276 In-Reply-To: References: <4f09ab13-9571-3464-2fc3-334bc91b9c09@case.edu> <444185BB2F013F4E92378F99BCF8A58BC9AF9CBD@ALA-MBD.corp.ad.wrs.com> <99d34efd-3a68-0b05-0e15-fbfd360a2f2a@case.edu> <9b99752af2094590137fdaacf6668f170b34158c.camel@linuxfoundation.org> <41e8a2902bc8594a17f0afa1744f04a6facd5316.camel@intel.com> , Message-ID: Thanks Chet very much for your confirmation! If the commit fixs the CVE-2019-18276, why is it merged to the master branch? Thanks, Mingli ________________________________________ From: Chet Ramey [chet.ramey at case.edu] Sent: Tuesday, March 03, 2020 9:55 PM To: Yu, Mingli; Mittal, Anuj; richard.purdie at linuxfoundation.org; openembedded-core at lists.openembedded.org; Huo, De; preid at electromag.com.au; akuster808 at gmail.com Cc: chet.ramey at case.edu Subject: Re: [OE-core] bash: Fix CVE-2019-18276 On 3/2/20 10:11 PM, Yu, Mingli wrote: > Does https://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel&id=951bdaad7a18cc0dc1036bba86b18b90874d39ff fix the issue reported in CVE-2019-18276? Could you help to provide some info here? Yes, the changes from 6/27 fix the issue in the CVE. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From Mingli.Yu at windriver.com Wed Mar 4 01:16:42 2020 From: Mingli.Yu at windriver.com (Yu, Mingli) Date: Wed, 4 Mar 2020 01:16:42 +0000 Subject: [OE-core] bash: Fix CVE-2019-18276 In-Reply-To: <5cc81afa618ea969dc3d03f6e7ce356ec08e8efe.camel@intel.com> References: <4f09ab13-9571-3464-2fc3-334bc91b9c09@case.edu> <444185BB2F013F4E92378F99BCF8A58BC9AF9CBD@ALA-MBD.corp.ad.wrs.com> <99d34efd-3a68-0b05-0e15-fbfd360a2f2a@case.edu> <9b99752af2094590137fdaacf6668f170b34158c.camel@linuxfoundation.org> ,<41e8a2902bc8594a17f0afa1744f04a6facd5316.camel@intel.com> , <5cc81afa618ea969dc3d03f6e7ce356ec08e8efe.camel@intel.com> Message-ID: Got it, thanks Anuj! Thanks, Mingli ________________________________________ From: openembedded-core-bounces at lists.openembedded.org [openembedded-core-bounces at lists.openembedded.org] on behalf of Mittal, Anuj [anuj.mittal at intel.com] Sent: Wednesday, March 04, 2020 7:49 AM To: openembedded-core at lists.openembedded.org Subject: Re: [OE-core] bash: Fix CVE-2019-18276 On Tue, 2020-03-03 at 03:11 +0000, Yu, Mingli wrote: > Hi Anuj, > > I agree the Backport status is not accurate as the patch doesn't go > to master branch, but why do you say the patch is irrelevant to the > CVE-2019-18276, could you help to provide more info? I didn't say that the patch was irrelevant to the CVE. I had said that not all the changes were relevant. I believe the glob changes in the patch were irrelevant. Those changes also introduced a failure in bash ptests. Thanks, Anuj -- _______________________________________________ Openembedded-core mailing list Openembedded-core at lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core From akuster808 at gmail.com Wed Mar 4 05:43:47 2020 From: akuster808 at gmail.com (akuster808) Date: Tue, 3 Mar 2020 21:43:47 -0800 Subject: [OE-core] Stable release changes now that YP has an LTS program Message-ID: <8e1a92f2-b131-4594-b07c-58192fa2f5b7@gmail.com> Hello, As Richard has pointed out, The Yocto Project now has a LTS program.? It means the stable branch life cycles are changing.? The new standard life span for a stable release will be 7 months before transitioning to "Community Supported". That extra month is so we can pull in changes missed in the release.? With Zeus, we are giving it 9 months to help folks transition? and before it goes to "Community Supported". The "Community Supported" and "EOL" policies are being work on by the Yocto TSC. The LTS and Stable processes are on the YP wiki and where the "Community Supported" and "EOL" policies/processes will be noted. https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS let me know if anything needs clarification. regards, Armin From richard.purdie at linuxfoundation.org Wed Mar 4 06:03:05 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Wed, 04 Mar 2020 06:03:05 +0000 Subject: [OE-core] [PATCH v2 4/4] reproducible: try to ensure reproducible xz archives In-Reply-To: References: <20200303160513.17645-1-git@andred.net> <20200303160513.17645-4-git@andred.net> Message-ID: <58536cd2e8f56acd7f52637ab80cac88a6102e6d.camel@linuxfoundation.org> On Tue, 2020-03-03 at 21:31 -0300, Otavio Salvador wrote: > On Tue, Mar 3, 2020 at 1:08 PM Andr? Draszik wrote: > > On Tue, 2020-03-03 at 16:05 +0000, Andr? Draszik wrote: > > In an ideal world, it'd parse the output of xz --verbose --verbose, > > to catch > > all possible ways people might be adjusting the thread limit, but > > that's > > non-trivial. > > Couldn't we just "enforce" at least two threads? It is quite unlikely > we ever use OE on a single core machine (as it'd take few years to > finish the build hehe) it seems like a reasonable assumption. An earlier patch does, unless you actually set XZ_THREADS = "1". If you do that, things are still reproducible in that the output will be consistent, just not with any other value of XZ_THREADS. So I think we should be fine without this patch. Cheers, Richard From adrian.freihofer at siemens.com Wed Mar 4 08:12:27 2020 From: adrian.freihofer at siemens.com (Freihofer, Adrian) Date: Wed, 4 Mar 2020 08:12:27 +0000 Subject: [OE-core] [PATCH] bitbake: gitsm: download submodules Message-ID: <84e64ccddc46261a59bb1e281ef3294e08119abc.camel@siemens.com> The unpack function failed because the submodules were not downloaded. Calling download before unpack for each submodule solves this issue. Signed-off-by: Adrian Freihofer --- bitbake/lib/bb/fetch2/gitsm.py | 1 + 1 file changed, 1 insertion(+) diff --git a/bitbake/lib/bb/fetch2/gitsm.py b/bitbake/lib/bb/fetch2/gitsm.py index c622771d21..3715e9824f 100644 --- a/bitbake/lib/bb/fetch2/gitsm.py +++ b/bitbake/lib/bb/fetch2/gitsm.py @@ -184,6 +184,7 @@ class GitSM(Git): try: newfetch = Fetch([url], d, cache=False) + newfetch.download() newfetch.unpack(root=os.path.dirname(os.path.join(repo _conf, 'modules', module))) except Exception as e: logger.error('gitsm: submodule unpack failed: %s %s' % (type(e).__name__, str(e))) From adrian.freihofer at siemens.com Wed Mar 4 08:14:18 2020 From: adrian.freihofer at siemens.com (Freihofer, Adrian) Date: Wed, 4 Mar 2020 08:14:18 +0000 Subject: [OE-core] [PATCH] runqemu: support multiple NICs Message-ID: <2b48cd168e6050723f4c30b059098b319e5b6df5.camel@siemens.com> Emulating more than one network interface with runqemu is sometimes a bit tricky, but possible. For example, this leads to an emulated device with eth0 and eth1: QB_NETWORK_DEVICE_prepend = " \ -device virtio-neti-device,mac=52:54:00:12:34:03 \ " On some emulated NIC types, Qemu and the kernel enumerate the eths in the guest in reverse order to how the device parameters are passed to Qemu. So in this case it is important that the additional NICs are prepended to the -device parameter, which gets automatically added by Qemu. Otherwise, the interface eth1 will be connected to the host, but eth0 will be assigned the IP address 192.168.7.x, which obviously does not work. When booting Qemu with two NICs, but only one set of network configuration parameters passed to the kernel, the kernel seems to search for a configuration for all NICs. This delays the boot process for a very long time. This change solves the timeout problem. Tested with: oe-selftest --run-tests runqemu --- scripts/runqemu | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/runqemu b/scripts/runqemu index dd0aa4b28f..d34f8eec25 100755 --- a/scripts/runqemu +++ b/scripts/runqemu @@ -1147,7 +1147,7 @@ class BaseConfig(object): client = gateway + 1 if self.fstype == 'nfs': self.setup_nfs() - netconf = "192.168.7.%s::192.168.7.%s:255.255.255.0" % (client, gateway) + netconf = "192.168.7.%s::192.168.7.%s:255.255.255.0::eth0" % (client, gateway) logger.info("Network configuration: %s", netconf) self.kernel_cmdline_script += " ip=%s" % netconf mac = "%s%02x" % (self.mac_tap, client) From patchwork at patchwork.openembedded.org Wed Mar 4 08:32:24 2020 From: patchwork at patchwork.openembedded.org (Patchwork) Date: Wed, 04 Mar 2020 08:32:24 -0000 Subject: [OE-core] =?utf-8?q?=E2=9C=97_patchtest=3A_failure_for_bitbake=3A?= =?utf-8?q?_gitsm=3A_download_submodules?= In-Reply-To: <84e64ccddc46261a59bb1e281ef3294e08119abc.camel@siemens.com> References: <84e64ccddc46261a59bb1e281ef3294e08119abc.camel@siemens.com> Message-ID: <20200304083224.2275.45471@do> == Series Details == Series: bitbake: gitsm: download submodules Revision: 1 URL : https://patchwork.openembedded.org/series/23079/ 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 cannot be parsed correctly due to malformed diff lines [test_mbox_format] Suggested fix Create the series again using git-format-patch and ensure it can be applied using git am Diff line _conf, 'modules', module))) * Issue Series does not apply on top of target branch [test_series_merge_on_head] Suggested fix Rebase your series on top of targeted branch Targeted branch master (currently at d6b1809e8c) If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core at 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 From patchwork at patchwork.openembedded.org Wed Mar 4 08:32:25 2020 From: patchwork at patchwork.openembedded.org (Patchwork) Date: Wed, 04 Mar 2020 08:32:25 -0000 Subject: [OE-core] =?utf-8?q?=E2=9C=97_patchtest=3A_failure_for_runqemu=3A?= =?utf-8?q?_support_multiple_NICs?= In-Reply-To: <2b48cd168e6050723f4c30b059098b319e5b6df5.camel@siemens.com> References: <2b48cd168e6050723f4c30b059098b319e5b6df5.camel@siemens.com> Message-ID: <20200304083225.2276.86888@do> == Series Details == Series: runqemu: support multiple NICs Revision: 1 URL : https://patchwork.openembedded.org/series/23080/ 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 cannot be parsed correctly due to malformed diff lines [test_mbox_format] Suggested fix Create the series again using git-format-patch and ensure it can be applied using git am Diff line (client, gateway) * Issue Series does not apply on top of target branch [test_series_merge_on_head] Suggested fix Rebase your series on top of targeted branch Targeted branch master (currently at d6b1809e8c) * Patch runqemu: support multiple NICs Issue Patch is missing Signed-off-by [test_signed_off_by_presence] Suggested fix Sign off the patch (either manually or with "git commit --amend -s") If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core at 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 From adrian.freihofer at siemens.com Wed Mar 4 08:33:07 2020 From: adrian.freihofer at siemens.com (Freihofer, Adrian) Date: Wed, 4 Mar 2020 08:33:07 +0000 Subject: [OE-core] [PATCH v2] runqemu: support multiple NICs References: <2b48cd168e6050723f4c30b059098b319e5b6df5.camel@siemens.com> Message-ID: Emulating more than one network interface with runqemu is sometimes a bit tricky, but possible. For example, this leads to an emulated device with eth0 and eth1: QB_NETWORK_DEVICE_prepend = " \ -device virtio-neti-device,mac=52:54:00:12:34:03 \ " On some emulated NIC types, Qemu and the kernel enumerate the eths in the guest in reverse order to how the device parameters are passed to Qemu. So in this case it is important that the additional NICs are prepended to the -device parameter, which gets automatically added by Qemu. Otherwise, the interface eth1 will be connected to the host, but eth0 will be assigned the IP address 192.168.7.x, which obviously does not work. When booting Qemu with two NICs, but only one set of network configuration parameters passed to the kernel, the kernel seems to search for a configuration for all NICs. This delays the boot process for a very long time. This change solves the timeout problem. Tested with: oe-selftest --run-tests runqemu Signed-off-by: Adrian Freihofer --- scripts/runqemu | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/runqemu b/scripts/runqemu index dd0aa4b28f..d34f8eec25 100755 --- a/scripts/runqemu +++ b/scripts/runqemu @@ -1147,7 +1147,7 @@ class BaseConfig(object): client = gateway + 1 if self.fstype == 'nfs': self.setup_nfs() - netconf = "192.168.7.%s::192.168.7.%s:255.255.255.0" % (client, gateway) + netconf = "192.168.7.%s::192.168.7.%s:255.255.255.0::eth0" % (client, gateway) logger.info("Network configuration: %s", netconf) self.kernel_cmdline_script += " ip=%s" % netconf mac = "%s%02x" % (self.mac_tap, client) -- Siemens Schweiz AG, Smart Infrastructure SI BP R&D ZG FW CCP Theilerstrasse 1a 6300 Zug, Switzerland Mobile: +41 796819596 From ricardo at ribalda.com Wed Mar 4 08:34:37 2020 From: ricardo at ribalda.com (Ricardo Ribalda Delgado) Date: Wed, 4 Mar 2020 09:34:37 +0100 Subject: [OE-core] [PATCH 1/2] wic: Fix permissions when using exclude or include path Message-ID: <20200304083438.1022216-1-ricardo@ribalda.com> When parameters include_path or exclude_path are passed to the rootfs plugin, it will copy the partition content into a folder and make all the modifications there. This is done using copyhardlinktree(), which does not take into consideration the content of the pseudo folder, which contains the information about the right permissions and ownership of the folders. This results in a rootfs owned by the user that is running the wic command (usually UID 1000), which makes some rootfs unbootable. To fix this we copy the content of the pseudo folders to the new folder and modify the pseudo database using the "pseudo -B" command. Signed-off-by: Ricardo Ribalda Delgado --- scripts/lib/wic/plugins/source/rootfs.py | 22 +++++++++++++++++++--- 1 file changed, 19 insertions(+), 3 deletions(-) diff --git a/scripts/lib/wic/plugins/source/rootfs.py b/scripts/lib/wic/plugins/source/rootfs.py index 705aeb5563..40419a64b3 100644 --- a/scripts/lib/wic/plugins/source/rootfs.py +++ b/scripts/lib/wic/plugins/source/rootfs.py @@ -16,11 +16,11 @@ import os import shutil import sys -from oe.path import copyhardlinktree +from oe.path import copyhardlinktree, copytree from wic import WicError from wic.pluginbase import SourcePlugin -from wic.misc import get_bitbake_var +from wic.misc import get_bitbake_var, exec_native_cmd logger = logging.getLogger('wic') @@ -44,6 +44,15 @@ class RootfsPlugin(SourcePlugin): return os.path.realpath(image_rootfs_dir) + @staticmethod + def __get_pseudo(native_sysroot, rootfs): + pseudo = "export PSEUDO_PREFIX=%s/usr;" % native_sysroot + pseudo += "export PSEUDO_LOCALSTATEDIR=%s;" % os.path.join(rootfs, "../pseudo") + pseudo += "export PSEUDO_PASSWD=%s;" % rootfs + pseudo += "export PSEUDO_NOSYMLINKEXP=1;" + pseudo += "%s " % get_bitbake_var("FAKEROOTCMD") + return pseudo + @classmethod def do_prepare_partition(cls, part, source_params, cr, cr_workdir, oe_builddir, bootimg_dir, kernel_dir, @@ -78,9 +87,16 @@ class RootfsPlugin(SourcePlugin): if os.path.lexists(new_rootfs): shutil.rmtree(os.path.join(new_rootfs)) - copyhardlinktree(part.rootfs_dir, new_rootfs) + if os.path.lexists(os.path.join(new_rootfs, "../pseudo")): + shutil.rmtree(os.path.join(new_rootfs, "../pseudo")) + copytree(os.path.join(part.rootfs_dir, "../pseudo"), + os.path.join(new_rootfs, "../pseudo")) + pseudo_cmd = "%s -B -m %s -M %s" % (cls.__get_pseudo(native_sysroot,new_rootfs), + part.rootfs_dir, new_rootfs) + exec_native_cmd(pseudo_cmd, native_sysroot) + for path in part.include_path or []: copyhardlinktree(path, new_rootfs) -- 2.25.1 From ricardo at ribalda.com Wed Mar 4 08:34:38 2020 From: ricardo at ribalda.com (Ricardo Ribalda Delgado) Date: Wed, 4 Mar 2020 09:34:38 +0100 Subject: [OE-core] [PATCH 2/2] wic: Add --embed-rootfs argument In-Reply-To: <20200304083438.1022216-1-ricardo@ribalda.com> References: <20200304083438.1022216-1-ricardo@ribalda.com> Message-ID: <20200304083438.1022216-2-ricardo@ribalda.com> This option adds the content of a rootfs on a specific location on the rootfs. It is very useful for making a partition that contains the rootfs for a host and a target Eg: / -> Roofs for the host /export/ -> Rootfs for the target (which will netboot) Although today we support making a partition for "/export" this might not be compatible with some upgrade systems, or we might be limited by the number of partitions. With this patch we can use something like: part / --source rootfs --embed-rootfs=target-image:/export on the .wks file. Signed-off-by: Ricardo Ribalda Delgado --- scripts/lib/wic/help.py | 7 +++++++ scripts/lib/wic/ksparser.py | 1 + scripts/lib/wic/partition.py | 1 + scripts/lib/wic/plugins/source/rootfs.py | 20 +++++++++++++++++++- 4 files changed, 28 insertions(+), 1 deletion(-) diff --git a/scripts/lib/wic/help.py b/scripts/lib/wic/help.py index 4d342fcf05..67a33e6a65 100644 --- a/scripts/lib/wic/help.py +++ b/scripts/lib/wic/help.py @@ -979,6 +979,13 @@ DESCRIPTION copies. This option only has an effect with the rootfs source plugin. + --embed-rootfs: This option is specific to wic. It embeds a rootfs into + the given path to the resulting image. The option + contains two fields, the roofs and the path, separated + by a colon. The rootfs follows the same logic as the + rootfs-dir argument. This option only has an effect + with the rootfs source plugin. + --extra-space: This option is specific to wic. It adds extra space after the space filled by the content of the partition. The final size can go diff --git a/scripts/lib/wic/ksparser.py b/scripts/lib/wic/ksparser.py index 650b976223..d422e2a6bb 100644 --- a/scripts/lib/wic/ksparser.py +++ b/scripts/lib/wic/ksparser.py @@ -138,6 +138,7 @@ class KickStart(): part.add_argument('--align', type=int) part.add_argument('--exclude-path', nargs='+') part.add_argument('--include-path', nargs='+') + part.add_argument('--embed-rootfs', nargs='+') part.add_argument("--extra-space", type=sizetype) part.add_argument('--fsoptions', dest='fsopts') part.add_argument('--fstype', default='vfat', diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py index 2d95f78439..13857df82f 100644 --- a/scripts/lib/wic/partition.py +++ b/scripts/lib/wic/partition.py @@ -31,6 +31,7 @@ class Partition(): self.extra_space = args.extra_space self.exclude_path = args.exclude_path self.include_path = args.include_path + self.embed_rootfs = args.embed_rootfs self.fsopts = args.fsopts self.fstype = args.fstype self.label = args.label diff --git a/scripts/lib/wic/plugins/source/rootfs.py b/scripts/lib/wic/plugins/source/rootfs.py index 40419a64b3..16359601dc 100644 --- a/scripts/lib/wic/plugins/source/rootfs.py +++ b/scripts/lib/wic/plugins/source/rootfs.py @@ -80,7 +80,7 @@ class RootfsPlugin(SourcePlugin): new_rootfs = None # Handle excluded paths. - if part.exclude_path or part.include_path: + if part.exclude_path or part.include_path or part.embed_rootfs: # We need a new rootfs directory we can delete files from. Copy to # workdir. new_rootfs = os.path.realpath(os.path.join(cr_workdir, "rootfs%d" % part.lineno)) @@ -100,6 +100,24 @@ class RootfsPlugin(SourcePlugin): for path in part.include_path or []: copyhardlinktree(path, new_rootfs) + for embed in part.embed_rootfs or []: + [embed_rootfs, path] = embed.split(":") + #we need to remove the initial / for os.path.join to work + if os.path.isabs(path): + path = path[1:] + if embed_rootfs in krootfs_dir: + embed_rootfs = krootfs_dir[embed_rootfs] + embed_rootfs = cls.__get_rootfs_dir(embed_rootfs) + tar_file = os.path.realpath(os.path.join(cr_workdir, "aux.tar")) + tar_cmd = "%s tar cpf %s -C %s ." % (cls.__get_pseudo(native_sysroot, + embed_rootfs), tar_file, embed_rootfs) + exec_native_cmd(tar_cmd, native_sysroot) + untar_cmd = "%s tar xf %s -C %s ." % (cls.__get_pseudo(native_sysroot, new_rootfs), + tar_file, os.path.join(new_rootfs, path)) + exec_native_cmd(untar_cmd, native_sysroot, + cls.__get_pseudo(native_sysroot, new_rootfs)) + os.remove(tar_file) + for orig_path in part.exclude_path or []: path = orig_path if os.path.isabs(path): -- 2.25.1 From patchwork at patchwork.openembedded.org Wed Mar 4 09:02:56 2020 From: patchwork at patchwork.openembedded.org (Patchwork) Date: Wed, 04 Mar 2020 09:02:56 -0000 Subject: [OE-core] =?utf-8?q?=E2=9C=97_patchtest=3A_failure_for_runqemu=3A?= =?utf-8?q?_support_multiple_NICs_=28rev2=29?= In-Reply-To: <2b48cd168e6050723f4c30b059098b319e5b6df5.camel@siemens.com> References: <2b48cd168e6050723f4c30b059098b319e5b6df5.camel@siemens.com> Message-ID: <20200304090256.2276.64115@do> == Series Details == Series: runqemu: support multiple NICs (rev2) Revision: 2 URL : https://patchwork.openembedded.org/series/23080/ 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 cannot be parsed correctly due to malformed diff lines [test_mbox_format] Suggested fix Create the series again using git-format-patch and ensure it can be applied using git am Diff line (client, gateway) * Issue Series does not apply on top of target branch [test_series_merge_on_head] Suggested fix Rebase your series on top of targeted branch Targeted branch master (currently at d6b1809e8c) If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core at 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 From bunk at stusta.de Wed Mar 4 09:05:07 2020 From: bunk at stusta.de (Adrian Bunk) Date: Wed, 4 Mar 2020 11:05:07 +0200 Subject: [OE-core] [RFC][PATCH 1/2] nss: Move to meta-oe In-Reply-To: References: <20200223193408.5602-1-bunk@stusta.de> <20200224051745.GA6683@localhost> <20200227132729.GA6240@localhost> Message-ID: <20200304090507.GA7923@localhost> On Thu, Feb 27, 2020 at 03:03:18PM +0100, Alexander Kanavin wrote: > On Thu, 27 Feb 2020 at 14:28, Adrian Bunk wrote: > > > >... > > > > It is a crypto library with a history of unfixed CVEs in supported > > stable Yocto releases. > > > > If the issue is unfixed CVEs, then I do not think it's particularly > relevant which layer the recipe is in. Stable release maintainers are not > expected to 'track and fix CVEs', that one is on users. Yesterdays LTS announcement makes it clear that the Yocto project does provide regular security updates for supported stable branches: <-- snip --> Yocto Project releases are usually maintained for one year. Beyond this period, releases move to community support, which means they only receive occasional patches for critical defects and updates, and no regular defect fixes and security updates. <-- snip --> > Alex cu Adrian From git at andred.net Wed Mar 4 09:17:29 2020 From: git at andred.net (=?ISO-8859-1?Q?Andr=E9?= Draszik) Date: Wed, 04 Mar 2020 09:17:29 +0000 Subject: [OE-core] linux-firmware broken (was: Re: [PATCH 09/24] linux-firmware: upgrade to latest revision) In-Reply-To: <20200129090738.1398-9-alex.kanavin@gmail.com> References: <20200129090738.1398-1-alex.kanavin@gmail.com> <20200129090738.1398-9-alex.kanavin@gmail.com> Message-ID: <2588ab8f2899ec2b139a9ce3619ae6ed06648ba3.camel@andred.net> On Wed, 2020-01-29 at 10:07 +0100, Alexander Kanavin wrote: > License-Update: Copyright years, file lists > Signed-off-by: Alexander Kanavin This recipe update has broken linux-firmware for various devices I think. It appears that since upstream's 20191022 release, linux-firmware is not meant to be installed via simple copying anymore (as this recipe still does in do_install()), but instead you're meant to use their copy-firmware.sh script. In particular, all the symlinks that used to be part of the upstream git are missing now, because copy-firmware extracts them on the fly from the WHENCE file, they're not part of the git repository anymore. Without those various kernel drivers will fail to load their firmware... Cheers, Andre' > --- > ...ux-firmware_20190815.bb => linux-firmware_20200117.bb} | 8 +++++--- > 1 file changed, 5 insertions(+), 3 deletions(-) > rename meta/recipes-kernel/linux-firmware/{linux-firmware_20190815.bb => linux-firmware_20200117.bb} (99%) > > diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20190815.bb b/meta/recipes-kernel/linux-firmware/linux- > firmware_20200117.bb > similarity index 99% > rename from meta/recipes-kernel/linux-firmware/linux-firmware_20190815.bb > rename to meta/recipes-kernel/linux-firmware/linux-firmware_20200117.bb > index d83000b64f0..8111c410161 100644 > --- a/meta/recipes-kernel/linux-firmware/linux-firmware_20190815.bb > +++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20200117.bb > @@ -66,7 +66,7 @@ LICENSE = "\ > LIC_FILES_CHKSUM = "file://LICENCE.Abilis;md5=b5ee3f410780e56711ad48eadc22b8bc \ > file://LICENCE.adsp_sst;md5=615c45b91a5a4a9fe046d6ab9a2df728 \ > file://LICENCE.agere;md5=af0133de6b4a9b2522defd5f188afd31 \ > - file://LICENSE.amdgpu;md5=ab515ef6495ab5c5a3b08ab2db62df11 \ > + file://LICENSE.amdgpu;md5=d357524f5099e2a3db3c1838921c593f \ > file://LICENSE.amd-ucode;md5=3c5399dc9148d7f0e1f41e34b69cf14f \ > file://LICENSE.amlogic_vdec;md5=dc44f59bf64a81643e500ad3f39a468a \ > file://LICENCE.atheros_firmware;md5=30a14c7823beedac9fa39c64fdd01a13 \ > @@ -88,6 +88,7 @@ LIC_FILES_CHKSUM = "file://LICENCE.Abilis;md5=b5ee3f410780e56711ad48eadc22b8bc \ > file://LICENCE.i2400m;md5=14b901969e23c41881327c0d9e4b7d36 \ > file://LICENSE.i915;md5=2b0b2e0d20984affd4490ba2cba02570 \ > file://LICENCE.ibt_firmware;md5=fdbee1ddfe0fb7ab0b2fcd6b454a366b \ > + file://LICENSE.ice;md5=742ab4850f2670792940e6d15c974b2f \ > file://LICENCE.IntcSST2;md5=9e7d8bea77612d7cc7d9e9b54b623062 \ > file://LICENCE.it913x;md5=1fbf727bfb6a949810c4dbfa7e6ce4f8 \ > file://LICENCE.iwlwifi_firmware;md5=3fd842911ea93c29cd32679aa23e1c88 \ > @@ -98,6 +99,7 @@ LIC_FILES_CHKSUM = "file://LICENCE.Abilis;md5=b5ee3f410780e56711ad48eadc22b8bc \ > file://LICENCE.myri10ge_firmware;md5=42e32fb89f6b959ca222e25ac8df8fed \ > file://LICENCE.Netronome;md5=4add08f2577086d44447996503cddf5f \ > file://LICENCE.nvidia;md5=4428a922ed3ba2ceec95f076a488ce07 \ > + file://LICENCE.NXP;md5=58bb8ba632cd729b9ba6183bc6aed36f \ > file://LICENCE.OLPC;md5=5b917f9d8c061991be4f6f5f108719cd \ > file://LICENCE.open-ath9k-htc-firmware;md5=1b33c9f4d17bc4d457bdb23727046837 \ > file://LICENCE.phanfw;md5=954dcec0e051f9409812b561ea743bfa \ > @@ -123,7 +125,7 @@ LIC_FILES_CHKSUM = "file://LICENCE.Abilis;md5=b5ee3f410780e56711ad48eadc22b8bc \ > file://LICENCE.xc4000;md5=0ff51d2dc49fce04814c9155081092f0 \ > file://LICENCE.xc5000;md5=1e170c13175323c32c7f4d0998d53f66 \ > file://LICENCE.xc5000c;md5=12b02efa3049db65d524aeb418dd87ca \ > - file://WHENCE;md5=37a01e379219d1e06dbccfa90a8fc0ad \ > + file://WHENCE;md5=cdcd9f664a404c681bb745bcac6253a3 \ > " > > # These are not common licenses, set NO_GENERIC_LICENSE for them > @@ -192,7 +194,7 @@ NO_GENERIC_LICENSE[WHENCE] = "WHENCE" > > PE = "1" > > -SRCREV = "07b925b450bfb4cf3e141c612ec5b104658cd020" > +SRCREV = "9c340bd1bdabf53808a9178a7be98c5f2ad599a7" > > SRC_URI = "git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git" > > -- > 2.25.0 > From alex.kanavin at gmail.com Wed Mar 4 09:36:52 2020 From: alex.kanavin at gmail.com (Alexander Kanavin) Date: Wed, 4 Mar 2020 10:36:52 +0100 Subject: [OE-core] [RFC][PATCH 1/2] nss: Move to meta-oe In-Reply-To: <20200304090507.GA7923@localhost> References: <20200223193408.5602-1-bunk@stusta.de> <20200224051745.GA6683@localhost> <20200227132729.GA6240@localhost> <20200304090507.GA7923@localhost> Message-ID: You are misinterpreting the announcement. The security updates are provided by users as patches to the mailing list, maintainers merely collect and integrate them. There is no promise from the project to do anything else, and LTS doesn?t change that, it only extends the maintainer duty from one year to two. Moving a recipe in or out of core does not fundamentally change how much attention it gets w.r.t. security fixes. Alex On Wed 4. Mar 2020 at 10.05, Adrian Bunk wrote: > On Thu, Feb 27, 2020 at 03:03:18PM +0100, Alexander Kanavin wrote: > > On Thu, 27 Feb 2020 at 14:28, Adrian Bunk wrote: > > > > > >... > > > > > > It is a crypto library with a history of unfixed CVEs in supported > > > stable Yocto releases. > > > > > > > If the issue is unfixed CVEs, then I do not think it's particularly > > relevant which layer the recipe is in. Stable release maintainers are not > > expected to 'track and fix CVEs', that one is on users. > > Yesterdays LTS announcement makes it clear that the Yocto project does > provide regular security updates for supported stable branches: > > <-- snip --> > > Yocto Project releases are usually maintained for one year. > Beyond this period, releases move to community support, which means > they only receive occasional patches for critical defects and updates, > and no regular defect fixes and security updates. > > <-- snip --> > > > > Alex > > cu > Adrian > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbarker at konsulko.com Wed Mar 4 09:42:50 2020 From: pbarker at konsulko.com (Paul Barker) Date: Wed, 4 Mar 2020 09:42:50 +0000 Subject: [OE-core] [PATCH 2/2] wic: Add --embed-rootfs argument In-Reply-To: <20200304083438.1022216-2-ricardo@ribalda.com> References: <20200304083438.1022216-1-ricardo@ribalda.com> <20200304083438.1022216-2-ricardo@ribalda.com> Message-ID: <20200304094250.3eda52e1@ub1910> On Wed, 4 Mar 2020 09:34:38 +0100 Ricardo Ribalda Delgado wrote: > This option adds the content of a rootfs on a specific location on the > rootfs. > > It is very useful for making a partition that contains the rootfs for a > host and a target Eg: > > / -> Roofs for the host > /export/ -> Rootfs for the target (which will netboot) > > Although today we support making a partition for "/export" this might > not be compatible with some upgrade systems, or we might be limited by > the number of partitions. > > With this patch we can use something like: > > part / --source rootfs --embed-rootfs=target-image:/export I considered using a syntax like this for --include-path but I chose not to as it's not easy to choose a separator. ':' is a valid character in a directory name. My approach is to handle this in two steps: 1) Add a new task before do_image_wic which creates an 'embedded-rootfs' directory and copies 'target-image' to 'embedded-rootfs/export'. 2) Use '--include-path=embedded-rootfs' in the wks file. > > on the .wks file. > > Signed-off-by: Ricardo Ribalda Delgado > --- > scripts/lib/wic/help.py | 7 +++++++ > scripts/lib/wic/ksparser.py | 1 + > scripts/lib/wic/partition.py | 1 + > scripts/lib/wic/plugins/source/rootfs.py | 20 +++++++++++++++++++- > 4 files changed, 28 insertions(+), 1 deletion(-) > > diff --git a/scripts/lib/wic/help.py b/scripts/lib/wic/help.py > index 4d342fcf05..67a33e6a65 100644 > --- a/scripts/lib/wic/help.py > +++ b/scripts/lib/wic/help.py > @@ -979,6 +979,13 @@ DESCRIPTION > copies. This option only has an effect with the rootfs > source plugin. > > + --embed-rootfs: This option is specific to wic. It embeds a rootfs into > + the given path to the resulting image. The option > + contains two fields, the roofs and the path, separated > + by a colon. The rootfs follows the same logic as the > + rootfs-dir argument. This option only has an effect > + with the rootfs source plugin. > + > --extra-space: This option is specific to wic. It adds extra > space after the space filled by the content > of the partition. The final size can go > diff --git a/scripts/lib/wic/ksparser.py b/scripts/lib/wic/ksparser.py > index 650b976223..d422e2a6bb 100644 > --- a/scripts/lib/wic/ksparser.py > +++ b/scripts/lib/wic/ksparser.py > @@ -138,6 +138,7 @@ class KickStart(): > part.add_argument('--align', type=int) > part.add_argument('--exclude-path', nargs='+') > part.add_argument('--include-path', nargs='+') > + part.add_argument('--embed-rootfs', nargs='+') > part.add_argument("--extra-space", type=sizetype) > part.add_argument('--fsoptions', dest='fsopts') > part.add_argument('--fstype', default='vfat', > diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py > index 2d95f78439..13857df82f 100644 > --- a/scripts/lib/wic/partition.py > +++ b/scripts/lib/wic/partition.py > @@ -31,6 +31,7 @@ class Partition(): > self.extra_space = args.extra_space > self.exclude_path = args.exclude_path > self.include_path = args.include_path > + self.embed_rootfs = args.embed_rootfs > self.fsopts = args.fsopts > self.fstype = args.fstype > self.label = args.label > diff --git a/scripts/lib/wic/plugins/source/rootfs.py b/scripts/lib/wic/plugins/source/rootfs.py > index 40419a64b3..16359601dc 100644 > --- a/scripts/lib/wic/plugins/source/rootfs.py > +++ b/scripts/lib/wic/plugins/source/rootfs.py > @@ -80,7 +80,7 @@ class RootfsPlugin(SourcePlugin): > > new_rootfs = None > # Handle excluded paths. > - if part.exclude_path or part.include_path: > + if part.exclude_path or part.include_path or part.embed_rootfs: > # We need a new rootfs directory we can delete files from. Copy to > # workdir. > new_rootfs = os.path.realpath(os.path.join(cr_workdir, "rootfs%d" % part.lineno)) > @@ -100,6 +100,24 @@ class RootfsPlugin(SourcePlugin): > for path in part.include_path or []: > copyhardlinktree(path, new_rootfs) > > + for embed in part.embed_rootfs or []: > + [embed_rootfs, path] = embed.split(":") > + #we need to remove the initial / for os.path.join to work > + if os.path.isabs(path): > + path = path[1:] > + if embed_rootfs in krootfs_dir: > + embed_rootfs = krootfs_dir[embed_rootfs] > + embed_rootfs = cls.__get_rootfs_dir(embed_rootfs) > + tar_file = os.path.realpath(os.path.join(cr_workdir, "aux.tar")) > + tar_cmd = "%s tar cpf %s -C %s ." % (cls.__get_pseudo(native_sysroot, > + embed_rootfs), tar_file, embed_rootfs) > + exec_native_cmd(tar_cmd, native_sysroot) > + untar_cmd = "%s tar xf %s -C %s ." % (cls.__get_pseudo(native_sysroot, new_rootfs), > + tar_file, os.path.join(new_rootfs, path)) > + exec_native_cmd(untar_cmd, native_sysroot, > + cls.__get_pseudo(native_sysroot, new_rootfs)) > + os.remove(tar_file) > + Why are you using an intermediate tar file here? > for orig_path in part.exclude_path or []: > path = orig_path > if os.path.isabs(path): -- Paul Barker Konsulko Group From pbarker at konsulko.com Wed Mar 4 09:53:34 2020 From: pbarker at konsulko.com (Paul Barker) Date: Wed, 4 Mar 2020 09:53:34 +0000 Subject: [OE-core] [PATCH 1/2] wic: Fix permissions when using exclude or include path In-Reply-To: <20200304083438.1022216-1-ricardo@ribalda.com> References: <20200304083438.1022216-1-ricardo@ribalda.com> Message-ID: <20200304095334.1f20ddd9@ub1910> On Wed, 4 Mar 2020 09:34:37 +0100 Ricardo Ribalda Delgado wrote: > When parameters include_path or exclude_path are passed to the rootfs > plugin, it will copy the partition content into a folder and make all > the modifications there. > > This is done using copyhardlinktree(), which does not take into > consideration the content of the pseudo folder, which contains the > information about the right permissions and ownership of the folders. How are you running wic here? In the do_image_wic task it's executed under pseudo so all this is handled already. Executing wic outside of bitbake may need some more testing here. > > This results in a rootfs owned by the user that is running the wic > command (usually UID 1000), which makes some rootfs unbootable. > > To fix this we copy the content of the pseudo folders to the new folder > and modify the pseudo database using the "pseudo -B" command. > > Signed-off-by: Ricardo Ribalda Delgado > --- > scripts/lib/wic/plugins/source/rootfs.py | 22 +++++++++++++++++++--- > 1 file changed, 19 insertions(+), 3 deletions(-) > > diff --git a/scripts/lib/wic/plugins/source/rootfs.py b/scripts/lib/wic/plugins/source/rootfs.py > index 705aeb5563..40419a64b3 100644 > --- a/scripts/lib/wic/plugins/source/rootfs.py > +++ b/scripts/lib/wic/plugins/source/rootfs.py > @@ -16,11 +16,11 @@ import os > import shutil > import sys > > -from oe.path import copyhardlinktree > +from oe.path import copyhardlinktree, copytree > > from wic import WicError > from wic.pluginbase import SourcePlugin > -from wic.misc import get_bitbake_var > +from wic.misc import get_bitbake_var, exec_native_cmd > > logger = logging.getLogger('wic') > > @@ -44,6 +44,15 @@ class RootfsPlugin(SourcePlugin): > > return os.path.realpath(image_rootfs_dir) > > + @staticmethod > + def __get_pseudo(native_sysroot, rootfs): > + pseudo = "export PSEUDO_PREFIX=%s/usr;" % native_sysroot > + pseudo += "export PSEUDO_LOCALSTATEDIR=%s;" % os.path.join(rootfs, "../pseudo") > + pseudo += "export PSEUDO_PASSWD=%s;" % rootfs > + pseudo += "export PSEUDO_NOSYMLINKEXP=1;" > + pseudo += "%s " % get_bitbake_var("FAKEROOTCMD") > + return pseudo > + > @classmethod > def do_prepare_partition(cls, part, source_params, cr, cr_workdir, > oe_builddir, bootimg_dir, kernel_dir, > @@ -78,9 +87,16 @@ class RootfsPlugin(SourcePlugin): > > if os.path.lexists(new_rootfs): > shutil.rmtree(os.path.join(new_rootfs)) > - > copyhardlinktree(part.rootfs_dir, new_rootfs) > > + if os.path.lexists(os.path.join(new_rootfs, "../pseudo")): > + shutil.rmtree(os.path.join(new_rootfs, "../pseudo")) > + copytree(os.path.join(part.rootfs_dir, "../pseudo"), > + os.path.join(new_rootfs, "../pseudo")) I don't like stepping up the directory tree like this. We should be more explicit with the paths. > + pseudo_cmd = "%s -B -m %s -M %s" % (cls.__get_pseudo(native_sysroot,new_rootfs), > + part.rootfs_dir, new_rootfs) > + exec_native_cmd(pseudo_cmd, native_sysroot) > + > for path in part.include_path or []: > copyhardlinktree(path, new_rootfs) ^^^^^^^^^^^^^^^^ If this is the right approach I imagine you would also need to fix things up with pseudo after the copyhardlinktree call above. -- Paul Barker Konsulko Group From ricardo at ribalda.com Wed Mar 4 09:56:20 2020 From: ricardo at ribalda.com (Ricardo Ribalda Delgado) Date: Wed, 4 Mar 2020 10:56:20 +0100 Subject: [OE-core] [PATCH 2/2] wic: Add --embed-rootfs argument In-Reply-To: <20200304094250.3eda52e1@ub1910> References: <20200304083438.1022216-1-ricardo@ribalda.com> <20200304083438.1022216-2-ricardo@ribalda.com> <20200304094250.3eda52e1@ub1910> Message-ID: Hi Paul Thanks for your reply On Wed, Mar 4, 2020 at 10:43 AM Paul Barker wrote: > > On Wed, 4 Mar 2020 09:34:38 +0100 > Ricardo Ribalda Delgado wrote: > > > This option adds the content of a rootfs on a specific location on the > > rootfs. > > > > It is very useful for making a partition that contains the rootfs for a > > host and a target Eg: > > > > / -> Roofs for the host > > /export/ -> Rootfs for the target (which will netboot) > > > > Although today we support making a partition for "/export" this might > > not be compatible with some upgrade systems, or we might be limited by > > the number of partitions. > > > > With this patch we can use something like: > > > > part / --source rootfs --embed-rootfs=target-image:/export > > I considered using a syntax like this for --include-path but I chose not to > as it's not easy to choose a separator. ':' is a valid character in a > directory name. I think we have to live with not being able to copy files to a directory with a colon :( > > My approach is to handle this in two steps: > > 1) Add a new task before do_image_wic which creates an 'embedded-rootfs' > directory and copies 'target-image' to 'embedded-rootfs/export'. > > 2) Use '--include-path=embedded-rootfs' in the wks file. > The biggest problem with that approach is permissions. We need files with UID 0, siticky bits, etc. We lose the pseudo database if we simply copy to a folder. Also, if we have a complex system with multiple partitions I prefer to handle all in a single .wks file instead of a script + wks file > > > > on the .wks file. > > > > Signed-off-by: Ricardo Ribalda Delgado > > --- > > scripts/lib/wic/help.py | 7 +++++++ > > scripts/lib/wic/ksparser.py | 1 + > > scripts/lib/wic/partition.py | 1 + > > scripts/lib/wic/plugins/source/rootfs.py | 20 +++++++++++++++++++- > > 4 files changed, 28 insertions(+), 1 deletion(-) > > > > diff --git a/scripts/lib/wic/help.py b/scripts/lib/wic/help.py > > index 4d342fcf05..67a33e6a65 100644 > > --- a/scripts/lib/wic/help.py > > +++ b/scripts/lib/wic/help.py > > @@ -979,6 +979,13 @@ DESCRIPTION > > copies. This option only has an effect with the rootfs > > source plugin. > > > > + --embed-rootfs: This option is specific to wic. It embeds a rootfs into > > + the given path to the resulting image. The option > > + contains two fields, the roofs and the path, separated > > + by a colon. The rootfs follows the same logic as the > > + rootfs-dir argument. This option only has an effect > > + with the rootfs source plugin. > > + > > --extra-space: This option is specific to wic. It adds extra > > space after the space filled by the content > > of the partition. The final size can go > > diff --git a/scripts/lib/wic/ksparser.py b/scripts/lib/wic/ksparser.py > > index 650b976223..d422e2a6bb 100644 > > --- a/scripts/lib/wic/ksparser.py > > +++ b/scripts/lib/wic/ksparser.py > > @@ -138,6 +138,7 @@ class KickStart(): > > part.add_argument('--align', type=int) > > part.add_argument('--exclude-path', nargs='+') > > part.add_argument('--include-path', nargs='+') > > + part.add_argument('--embed-rootfs', nargs='+') > > part.add_argument("--extra-space", type=sizetype) > > part.add_argument('--fsoptions', dest='fsopts') > > part.add_argument('--fstype', default='vfat', > > diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py > > index 2d95f78439..13857df82f 100644 > > --- a/scripts/lib/wic/partition.py > > +++ b/scripts/lib/wic/partition.py > > @@ -31,6 +31,7 @@ class Partition(): > > self.extra_space = args.extra_space > > self.exclude_path = args.exclude_path > > self.include_path = args.include_path > > + self.embed_rootfs = args.embed_rootfs > > self.fsopts = args.fsopts > > self.fstype = args.fstype > > self.label = args.label > > diff --git a/scripts/lib/wic/plugins/source/rootfs.py b/scripts/lib/wic/plugins/source/rootfs.py > > index 40419a64b3..16359601dc 100644 > > --- a/scripts/lib/wic/plugins/source/rootfs.py > > +++ b/scripts/lib/wic/plugins/source/rootfs.py > > @@ -80,7 +80,7 @@ class RootfsPlugin(SourcePlugin): > > > > new_rootfs = None > > # Handle excluded paths. > > - if part.exclude_path or part.include_path: > > + if part.exclude_path or part.include_path or part.embed_rootfs: > > # We need a new rootfs directory we can delete files from. Copy to > > # workdir. > > new_rootfs = os.path.realpath(os.path.join(cr_workdir, "rootfs%d" % part.lineno)) > > @@ -100,6 +100,24 @@ class RootfsPlugin(SourcePlugin): > > for path in part.include_path or []: > > copyhardlinktree(path, new_rootfs) > > > > + for embed in part.embed_rootfs or []: > > + [embed_rootfs, path] = embed.split(":") > > + #we need to remove the initial / for os.path.join to work > > + if os.path.isabs(path): > > + path = path[1:] > > + if embed_rootfs in krootfs_dir: > > + embed_rootfs = krootfs_dir[embed_rootfs] > > + embed_rootfs = cls.__get_rootfs_dir(embed_rootfs) > > + tar_file = os.path.realpath(os.path.join(cr_workdir, "aux.tar")) > > + tar_cmd = "%s tar cpf %s -C %s ." % (cls.__get_pseudo(native_sysroot, > > + embed_rootfs), tar_file, embed_rootfs) > > + exec_native_cmd(tar_cmd, native_sysroot) > > + untar_cmd = "%s tar xf %s -C %s ." % (cls.__get_pseudo(native_sysroot, new_rootfs), > > + tar_file, os.path.join(new_rootfs, path)) > > + exec_native_cmd(untar_cmd, native_sysroot, > > + cls.__get_pseudo(native_sysroot, new_rootfs)) > > + os.remove(tar_file) > > + > > Why are you using an intermediate tar file here? For the permissions :( > > > for orig_path in part.exclude_path or []: > > path = orig_path > > if os.path.isabs(path): > > > > -- > Paul Barker > Konsulko Group -- Ricardo Ribalda From pbarker at konsulko.com Wed Mar 4 09:59:44 2020 From: pbarker at konsulko.com (Paul Barker) Date: Wed, 4 Mar 2020 09:59:44 +0000 Subject: [OE-core] [PATCH] bitbake: gitsm: download submodules In-Reply-To: <84e64ccddc46261a59bb1e281ef3294e08119abc.camel@siemens.com> References: <84e64ccddc46261a59bb1e281ef3294e08119abc.camel@siemens.com> Message-ID: <20200304095944.792423a0@ub1910> On Wed, 4 Mar 2020 08:12:27 +0000 "Freihofer, Adrian" wrote: > The unpack function failed because the submodules were not downloaded. > Calling download before unpack for each submodule solves this issue. > > Signed-off-by: Adrian Freihofer > --- > bitbake/lib/bb/fetch2/gitsm.py | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/bitbake/lib/bb/fetch2/gitsm.py > b/bitbake/lib/bb/fetch2/gitsm.py > index c622771d21..3715e9824f 100644 > --- a/bitbake/lib/bb/fetch2/gitsm.py > +++ b/bitbake/lib/bb/fetch2/gitsm.py > @@ -184,6 +184,7 @@ class GitSM(Git): > > try: > newfetch = Fetch([url], d, cache=False) > + newfetch.download() > newfetch.unpack(root=os.path.dirname(os.path.join(repo > _conf, 'modules', module))) > except Exception as e: > logger.error('gitsm: submodule unpack failed: %s %s' % > (type(e).__name__, str(e))) You shouldn't be trying to download submodules in the do_unpack step. If they're missing at this stage it probably indicates a fetch issue. What's the exact error that you're seeing? This could be related to the issue I saw when the fetcher uses git shallow tarballs from a mirror - if that's the case I'm planning to get that fixed this weekend. Also, your email client seems to have chewed the patch up. It's best to send patches using `git send-email` only. -- Paul Barker Konsulko Group From ricardo at ribalda.com Wed Mar 4 10:02:47 2020 From: ricardo at ribalda.com (Ricardo Ribalda Delgado) Date: Wed, 4 Mar 2020 11:02:47 +0100 Subject: [OE-core] [PATCH 1/2] wic: Fix permissions when using exclude or include path In-Reply-To: <20200304095334.1f20ddd9@ub1910> References: <20200304083438.1022216-1-ricardo@ribalda.com> <20200304095334.1f20ddd9@ub1910> Message-ID: Hi Paul On Wed, Mar 4, 2020 at 10:53 AM Paul Barker wrote: > > On Wed, 4 Mar 2020 09:34:37 +0100 > Ricardo Ribalda Delgado wrote: > > > When parameters include_path or exclude_path are passed to the rootfs > > plugin, it will copy the partition content into a folder and make all > > the modifications there. > > > > This is done using copyhardlinktree(), which does not take into > > consideration the content of the pseudo folder, which contains the > > information about the right permissions and ownership of the folders. > > How are you running wic here? In the do_image_wic task it's executed under > pseudo so all this is handled already. Executing wic outside of bitbake may > need some more testing here. I am running wic outside bitbake. But even if it is run under bitbake, it should also fail. The pseudo directory needs to be present on the target image > > > > > This results in a rootfs owned by the user that is running the wic > > command (usually UID 1000), which makes some rootfs unbootable. > > > > To fix this we copy the content of the pseudo folders to the new folder > > and modify the pseudo database using the "pseudo -B" command. > > > > Signed-off-by: Ricardo Ribalda Delgado > > --- > > scripts/lib/wic/plugins/source/rootfs.py | 22 +++++++++++++++++++--- > > 1 file changed, 19 insertions(+), 3 deletions(-) > > > > diff --git a/scripts/lib/wic/plugins/source/rootfs.py b/scripts/lib/wic/plugins/source/rootfs.py > > index 705aeb5563..40419a64b3 100644 > > --- a/scripts/lib/wic/plugins/source/rootfs.py > > +++ b/scripts/lib/wic/plugins/source/rootfs.py > > @@ -16,11 +16,11 @@ import os > > import shutil > > import sys > > > > -from oe.path import copyhardlinktree > > +from oe.path import copyhardlinktree, copytree > > > > from wic import WicError > > from wic.pluginbase import SourcePlugin > > -from wic.misc import get_bitbake_var > > +from wic.misc import get_bitbake_var, exec_native_cmd > > > > logger = logging.getLogger('wic') > > > > @@ -44,6 +44,15 @@ class RootfsPlugin(SourcePlugin): > > > > return os.path.realpath(image_rootfs_dir) > > > > + @staticmethod > > + def __get_pseudo(native_sysroot, rootfs): > > + pseudo = "export PSEUDO_PREFIX=%s/usr;" % native_sysroot > > + pseudo += "export PSEUDO_LOCALSTATEDIR=%s;" % os.path.join(rootfs, "../pseudo") > > + pseudo += "export PSEUDO_PASSWD=%s;" % rootfs > > + pseudo += "export PSEUDO_NOSYMLINKEXP=1;" > > + pseudo += "%s " % get_bitbake_var("FAKEROOTCMD") > > + return pseudo > > + > > @classmethod > > def do_prepare_partition(cls, part, source_params, cr, cr_workdir, > > oe_builddir, bootimg_dir, kernel_dir, > > @@ -78,9 +87,16 @@ class RootfsPlugin(SourcePlugin): > > > > if os.path.lexists(new_rootfs): > > shutil.rmtree(os.path.join(new_rootfs)) > > - > > copyhardlinktree(part.rootfs_dir, new_rootfs) > > > > + if os.path.lexists(os.path.join(new_rootfs, "../pseudo")): > > + shutil.rmtree(os.path.join(new_rootfs, "../pseudo")) > > + copytree(os.path.join(part.rootfs_dir, "../pseudo"), > > + os.path.join(new_rootfs, "../pseudo")) > > I don't like stepping up the directory tree like this. We should be more > explicit with the paths. You are thinking on: os.path.dirname(directory) > > > + pseudo_cmd = "%s -B -m %s -M %s" % (cls.__get_pseudo(native_sysroot,new_rootfs), > > + part.rootfs_dir, new_rootfs) > > + exec_native_cmd(pseudo_cmd, native_sysroot) > > + > > for path in part.include_path or []: > > copyhardlinktree(path, new_rootfs) > > ^^^^^^^^^^^^^^^^ > > If this is the right approach I imagine you would also need to fix things up > with pseudo after the copyhardlinktree call above. I do not think it is needed. include_path does not contain its own pseudo directory > > -- > Paul Barker > Konsulko Group -- Ricardo Ribalda From pbarker at konsulko.com Wed Mar 4 10:08:55 2020 From: pbarker at konsulko.com (Paul Barker) Date: Wed, 4 Mar 2020 10:08:55 +0000 Subject: [OE-core] [PATCH 2/2] wic: Add --embed-rootfs argument In-Reply-To: References: <20200304083438.1022216-1-ricardo@ribalda.com> <20200304083438.1022216-2-ricardo@ribalda.com> <20200304094250.3eda52e1@ub1910> Message-ID: <20200304100855.637a61e1@ub1910> On Wed, 4 Mar 2020 10:56:20 +0100 Ricardo Ribalda Delgado wrote: > Hi Paul > > Thanks for your reply > > On Wed, Mar 4, 2020 at 10:43 AM Paul Barker wrote: > > > > On Wed, 4 Mar 2020 09:34:38 +0100 > > Ricardo Ribalda Delgado wrote: > > > > > This option adds the content of a rootfs on a specific location on the > > > rootfs. > > > > > > It is very useful for making a partition that contains the rootfs for a > > > host and a target Eg: > > > > > > / -> Roofs for the host > > > /export/ -> Rootfs for the target (which will netboot) > > > > > > Although today we support making a partition for "/export" this might > > > not be compatible with some upgrade systems, or we might be limited by > > > the number of partitions. > > > > > > With this patch we can use something like: > > > > > > part / --source rootfs --embed-rootfs=target-image:/export > > > > I considered using a syntax like this for --include-path but I chose not to > > as it's not easy to choose a separator. ':' is a valid character in a > > directory name. > > I think we have to live with not being able to copy files to a > directory with a colon :( I wouldn't like to place a limitation like that on users and I'd like to avoid the proliferation of similar arguments here. How about modifying '--include-path' to take two arguments, a source path and a destination prefix? The python argument parser should be able to handle this and you can build a list of tuples (source_path, dest_prefix) when parsing the arguments. The '--include-path' argument hasn't been part of a Yocto release yet it's just on the master branch so I think if we're going to fix it with a breaking change, now is definitely the time. > > > > > My approach is to handle this in two steps: > > > > 1) Add a new task before do_image_wic which creates an 'embedded-rootfs' > > directory and copies 'target-image' to 'embedded-rootfs/export'. > > > > 2) Use '--include-path=embedded-rootfs' in the wks file. > > > > The biggest problem with that approach is permissions. We need files > with UID 0, siticky bits, etc. We lose the pseudo database if we > simply copy to a folder. > > Also, if we have a complex system with multiple partitions I prefer to > handle all in a single .wks file instead of a script + wks file > > > > > > > on the .wks file. > > > > > > Signed-off-by: Ricardo Ribalda Delgado > > > --- > > > scripts/lib/wic/help.py | 7 +++++++ > > > scripts/lib/wic/ksparser.py | 1 + > > > scripts/lib/wic/partition.py | 1 + > > > scripts/lib/wic/plugins/source/rootfs.py | 20 +++++++++++++++++++- > > > 4 files changed, 28 insertions(+), 1 deletion(-) > > > > > > diff --git a/scripts/lib/wic/help.py b/scripts/lib/wic/help.py > > > index 4d342fcf05..67a33e6a65 100644 > > > --- a/scripts/lib/wic/help.py > > > +++ b/scripts/lib/wic/help.py > > > @@ -979,6 +979,13 @@ DESCRIPTION > > > copies. This option only has an effect with the rootfs > > > source plugin. > > > > > > + --embed-rootfs: This option is specific to wic. It embeds a rootfs into > > > + the given path to the resulting image. The option > > > + contains two fields, the roofs and the path, separated > > > + by a colon. The rootfs follows the same logic as the > > > + rootfs-dir argument. This option only has an effect > > > + with the rootfs source plugin. > > > + > > > --extra-space: This option is specific to wic. It adds extra > > > space after the space filled by the content > > > of the partition. The final size can go > > > diff --git a/scripts/lib/wic/ksparser.py b/scripts/lib/wic/ksparser.py > > > index 650b976223..d422e2a6bb 100644 > > > --- a/scripts/lib/wic/ksparser.py > > > +++ b/scripts/lib/wic/ksparser.py > > > @@ -138,6 +138,7 @@ class KickStart(): > > > part.add_argument('--align', type=int) > > > part.add_argument('--exclude-path', nargs='+') > > > part.add_argument('--include-path', nargs='+') > > > + part.add_argument('--embed-rootfs', nargs='+') > > > part.add_argument("--extra-space", type=sizetype) > > > part.add_argument('--fsoptions', dest='fsopts') > > > part.add_argument('--fstype', default='vfat', > > > diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py > > > index 2d95f78439..13857df82f 100644 > > > --- a/scripts/lib/wic/partition.py > > > +++ b/scripts/lib/wic/partition.py > > > @@ -31,6 +31,7 @@ class Partition(): > > > self.extra_space = args.extra_space > > > self.exclude_path = args.exclude_path > > > self.include_path = args.include_path > > > + self.embed_rootfs = args.embed_rootfs > > > self.fsopts = args.fsopts > > > self.fstype = args.fstype > > > self.label = args.label > > > diff --git a/scripts/lib/wic/plugins/source/rootfs.py b/scripts/lib/wic/plugins/source/rootfs.py > > > index 40419a64b3..16359601dc 100644 > > > --- a/scripts/lib/wic/plugins/source/rootfs.py > > > +++ b/scripts/lib/wic/plugins/source/rootfs.py > > > @@ -80,7 +80,7 @@ class RootfsPlugin(SourcePlugin): > > > > > > new_rootfs = None > > > # Handle excluded paths. > > > - if part.exclude_path or part.include_path: > > > + if part.exclude_path or part.include_path or part.embed_rootfs: > > > # We need a new rootfs directory we can delete files from. Copy to > > > # workdir. > > > new_rootfs = os.path.realpath(os.path.join(cr_workdir, "rootfs%d" % part.lineno)) > > > @@ -100,6 +100,24 @@ class RootfsPlugin(SourcePlugin): > > > for path in part.include_path or []: > > > copyhardlinktree(path, new_rootfs) > > > > > > + for embed in part.embed_rootfs or []: > > > + [embed_rootfs, path] = embed.split(":") > > > + #we need to remove the initial / for os.path.join to work > > > + if os.path.isabs(path): > > > + path = path[1:] > > > + if embed_rootfs in krootfs_dir: > > > + embed_rootfs = krootfs_dir[embed_rootfs] > > > + embed_rootfs = cls.__get_rootfs_dir(embed_rootfs) > > > + tar_file = os.path.realpath(os.path.join(cr_workdir, "aux.tar")) > > > + tar_cmd = "%s tar cpf %s -C %s ." % (cls.__get_pseudo(native_sysroot, > > > + embed_rootfs), tar_file, embed_rootfs) > > > + exec_native_cmd(tar_cmd, native_sysroot) > > > + untar_cmd = "%s tar xf %s -C %s ." % (cls.__get_pseudo(native_sysroot, new_rootfs), > > > + tar_file, os.path.join(new_rootfs, path)) > > > + exec_native_cmd(untar_cmd, native_sysroot, > > > + cls.__get_pseudo(native_sysroot, new_rootfs)) > > > + os.remove(tar_file) > > > + > > > > Why are you using an intermediate tar file here? > > For the permissions :( Your previous patch handled this using 'pseudo -B'. It would be good to be consistent if possible - either use an intermediate tar file in all cases if it's necessary or use 'pseudo -B' in all cases. -- Paul Barker Konsulko Group From alex.kanavin at gmail.com Wed Mar 4 10:13:07 2020 From: alex.kanavin at gmail.com (Alexander Kanavin) Date: Wed, 4 Mar 2020 11:13:07 +0100 Subject: [OE-core] [PATCH] linux-firmware: use 'make install' for installation Message-ID: <20200304101307.31198-1-alex.kanavin@gmail.com> Copying the source tree over was missing important symlinks that since recent updates can only be created with make install. Signed-off-by: Alexander Kanavin --- .../linux-firmware/linux-firmware_20200122.bb | 22 +------------------ 1 file changed, 1 insertion(+), 21 deletions(-) diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb b/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb index 0d1422cfca..f7198cb56a 100644 --- a/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb +++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb @@ -208,27 +208,7 @@ do_compile() { } do_install() { - install -d ${D}${nonarch_base_libdir}/firmware/ - cp -r * ${D}${nonarch_base_libdir}/firmware/ - - # Avoid Makefile to be deployed - rm ${D}${nonarch_base_libdir}/firmware/Makefile - - # Remove unbuild firmware which needs cmake and bash - rm ${D}${nonarch_base_libdir}/firmware/carl9170fw -rf - - # Remove pointless bash script - rm ${D}${nonarch_base_libdir}/firmware/configure - - # Remove python script used to check the WHENCE file - rm ${D}${nonarch_base_libdir}/firmware/check_whence.py - - # Libertas sd8686 - ln -sf libertas/sd8686_v9.bin ${D}${nonarch_base_libdir}/firmware/sd8686.bin - ln -sf libertas/sd8686_v9_helper.bin ${D}${nonarch_base_libdir}/firmware/sd8686_helper.bin - - # fixup wl12xx location, after 2.6.37 the kernel searches a different location for it - ( cd ${D}${nonarch_base_libdir}/firmware ; ln -sf ti-connectivity/* . ) + oe_runmake 'DESTDIR=${D}' install } -- 2.25.1 From alex.kanavin at gmail.com Wed Mar 4 10:13:48 2020 From: alex.kanavin at gmail.com (Alexander Kanavin) Date: Wed, 4 Mar 2020 11:13:48 +0100 Subject: [OE-core] linux-firmware broken (was: Re: [PATCH 09/24] linux-firmware: upgrade to latest revision) In-Reply-To: <2588ab8f2899ec2b139a9ce3619ae6ed06648ba3.camel@andred.net> References: <20200129090738.1398-1-alex.kanavin@gmail.com> <20200129090738.1398-9-alex.kanavin@gmail.com> <2588ab8f2899ec2b139a9ce3619ae6ed06648ba3.camel@andred.net> Message-ID: Patch sent :) Alex On Wed, 4 Mar 2020 at 10:17, Andr? Draszik wrote: > On Wed, 2020-01-29 at 10:07 +0100, Alexander Kanavin wrote: > > License-Update: Copyright years, file lists > > Signed-off-by: Alexander Kanavin > > This recipe update has broken linux-firmware for various devices I think. > > It appears that since upstream's 20191022 release, linux-firmware is not > meant to be installed via simple copying anymore (as this recipe still > does in do_install()), but instead you're meant to use their > copy-firmware.sh script. > > In particular, all the symlinks that used to be part of the upstream git > are missing now, because copy-firmware extracts them on the fly from the > WHENCE file, they're not part of the git repository anymore. Without those > various kernel drivers will fail to load their firmware... > > > Cheers, > Andre' > > > > --- > > ...ux-firmware_20190815.bb => linux-firmware_20200117.bb} | 8 +++++--- > > 1 file changed, 5 insertions(+), 3 deletions(-) > > rename meta/recipes-kernel/linux-firmware/{linux-firmware_20190815.bb > => linux-firmware_20200117.bb} (99%) > > > > diff --git a/meta/recipes-kernel/linux-firmware/ > linux-firmware_20190815.bb b/meta/recipes-kernel/linux-firmware/linux- > > firmware_20200117.bb > > similarity index 99% > > rename from meta/recipes-kernel/linux-firmware/ > linux-firmware_20190815.bb > > rename to meta/recipes-kernel/linux-firmware/linux-firmware_20200117.bb > > index d83000b64f0..8111c410161 100644 > > --- a/meta/recipes-kernel/linux-firmware/linux-firmware_20190815.bb > > +++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20200117.bb > > @@ -66,7 +66,7 @@ LICENSE = "\ > > LIC_FILES_CHKSUM = > "file://LICENCE.Abilis;md5=b5ee3f410780e56711ad48eadc22b8bc \ > > > file://LICENCE.adsp_sst;md5=615c45b91a5a4a9fe046d6ab9a2df728 \ > > > file://LICENCE.agere;md5=af0133de6b4a9b2522defd5f188afd31 \ > > - > file://LICENSE.amdgpu;md5=ab515ef6495ab5c5a3b08ab2db62df11 \ > > + > file://LICENSE.amdgpu;md5=d357524f5099e2a3db3c1838921c593f \ > > > file://LICENSE.amd-ucode;md5=3c5399dc9148d7f0e1f41e34b69cf14f \ > > > file://LICENSE.amlogic_vdec;md5=dc44f59bf64a81643e500ad3f39a468a \ > > > file://LICENCE.atheros_firmware;md5=30a14c7823beedac9fa39c64fdd01a13 \ > > @@ -88,6 +88,7 @@ LIC_FILES_CHKSUM = > "file://LICENCE.Abilis;md5=b5ee3f410780e56711ad48eadc22b8bc \ > > > file://LICENCE.i2400m;md5=14b901969e23c41881327c0d9e4b7d36 \ > > > file://LICENSE.i915;md5=2b0b2e0d20984affd4490ba2cba02570 \ > > > file://LICENCE.ibt_firmware;md5=fdbee1ddfe0fb7ab0b2fcd6b454a366b \ > > + > file://LICENSE.ice;md5=742ab4850f2670792940e6d15c974b2f \ > > > file://LICENCE.IntcSST2;md5=9e7d8bea77612d7cc7d9e9b54b623062 \ > > > file://LICENCE.it913x;md5=1fbf727bfb6a949810c4dbfa7e6ce4f8 \ > > > file://LICENCE.iwlwifi_firmware;md5=3fd842911ea93c29cd32679aa23e1c88 \ > > @@ -98,6 +99,7 @@ LIC_FILES_CHKSUM = > "file://LICENCE.Abilis;md5=b5ee3f410780e56711ad48eadc22b8bc \ > > > file://LICENCE.myri10ge_firmware;md5=42e32fb89f6b959ca222e25ac8df8fed \ > > > file://LICENCE.Netronome;md5=4add08f2577086d44447996503cddf5f \ > > > file://LICENCE.nvidia;md5=4428a922ed3ba2ceec95f076a488ce07 \ > > + > file://LICENCE.NXP;md5=58bb8ba632cd729b9ba6183bc6aed36f \ > > > file://LICENCE.OLPC;md5=5b917f9d8c061991be4f6f5f108719cd \ > > > file://LICENCE.open-ath9k-htc-firmware;md5=1b33c9f4d17bc4d457bdb23727046837 > \ > > > file://LICENCE.phanfw;md5=954dcec0e051f9409812b561ea743bfa \ > > @@ -123,7 +125,7 @@ LIC_FILES_CHKSUM = > "file://LICENCE.Abilis;md5=b5ee3f410780e56711ad48eadc22b8bc \ > > > file://LICENCE.xc4000;md5=0ff51d2dc49fce04814c9155081092f0 \ > > > file://LICENCE.xc5000;md5=1e170c13175323c32c7f4d0998d53f66 \ > > > file://LICENCE.xc5000c;md5=12b02efa3049db65d524aeb418dd87ca \ > > - file://WHENCE;md5=37a01e379219d1e06dbccfa90a8fc0ad \ > > + file://WHENCE;md5=cdcd9f664a404c681bb745bcac6253a3 \ > > " > > > > # These are not common licenses, set NO_GENERIC_LICENSE for them > > @@ -192,7 +194,7 @@ NO_GENERIC_LICENSE[WHENCE] = "WHENCE" > > > > PE = "1" > > > > -SRCREV = "07b925b450bfb4cf3e141c612ec5b104658cd020" > > +SRCREV = "9c340bd1bdabf53808a9178a7be98c5f2ad599a7" > > > > SRC_URI = "git:// > git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git" > > > > -- > > 2.25.0 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ricardo at ribalda.com Wed Mar 4 10:14:43 2020 From: ricardo at ribalda.com (Ricardo Ribalda Delgado) Date: Wed, 4 Mar 2020 11:14:43 +0100 Subject: [OE-core] [PATCH 2/2] wic: Add --embed-rootfs argument In-Reply-To: <20200304100855.637a61e1@ub1910> References: <20200304083438.1022216-1-ricardo@ribalda.com> <20200304083438.1022216-2-ricardo@ribalda.com> <20200304094250.3eda52e1@ub1910> <20200304100855.637a61e1@ub1910> Message-ID: Hi Paul On Wed, Mar 4, 2020 at 11:09 AM Paul Barker wrote: > > On Wed, 4 Mar 2020 10:56:20 +0100 > Ricardo Ribalda Delgado wrote: > > > Hi Paul > > > > Thanks for your reply > > > > On Wed, Mar 4, 2020 at 10:43 AM Paul Barker wrote: > > > > > > On Wed, 4 Mar 2020 09:34:38 +0100 > > > Ricardo Ribalda Delgado wrote: > > > > > > > This option adds the content of a rootfs on a specific location on the > > > > rootfs. > > > > > > > > It is very useful for making a partition that contains the rootfs for a > > > > host and a target Eg: > > > > > > > > / -> Roofs for the host > > > > /export/ -> Rootfs for the target (which will netboot) > > > > > > > > Although today we support making a partition for "/export" this might > > > > not be compatible with some upgrade systems, or we might be limited by > > > > the number of partitions. > > > > > > > > With this patch we can use something like: > > > > > > > > part / --source rootfs --embed-rootfs=target-image:/export > > > > > > I considered using a syntax like this for --include-path but I chose not to > > > as it's not easy to choose a separator. ':' is a valid character in a > > > directory name. > > > > I think we have to live with not being able to copy files to a > > directory with a colon :( > > I wouldn't like to place a limitation like that on users and I'd like to > avoid the proliferation of similar arguments here. > > How about modifying '--include-path' to take two arguments, a source path and > a destination prefix? The python argument parser should be able to handle > this and you can build a list of tuples (source_path, dest_prefix) when > parsing the arguments. > > The '--include-path' argument hasn't been part of a Yocto release yet it's > just on the master branch so I think if we're going to fix it with a breaking > change, now is definitely the time. That sounds good to me. I do not mind having two arguments. for embed-rootfs. and probably will look better on include-path > > > > > > > > > My approach is to handle this in two steps: > > > > > > 1) Add a new task before do_image_wic which creates an 'embedded-rootfs' > > > directory and copies 'target-image' to 'embedded-rootfs/export'. > > > > > > 2) Use '--include-path=embedded-rootfs' in the wks file. > > > > > > > The biggest problem with that approach is permissions. We need files > > with UID 0, siticky bits, etc. We lose the pseudo database if we > > simply copy to a folder. > > > > Also, if we have a complex system with multiple partitions I prefer to > > handle all in a single .wks file instead of a script + wks file > > > > > > > > > > on the .wks file. > > > > > > > > Signed-off-by: Ricardo Ribalda Delgado > > > > --- > > > > scripts/lib/wic/help.py | 7 +++++++ > > > > scripts/lib/wic/ksparser.py | 1 + > > > > scripts/lib/wic/partition.py | 1 + > > > > scripts/lib/wic/plugins/source/rootfs.py | 20 +++++++++++++++++++- > > > > 4 files changed, 28 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/scripts/lib/wic/help.py b/scripts/lib/wic/help.py > > > > index 4d342fcf05..67a33e6a65 100644 > > > > --- a/scripts/lib/wic/help.py > > > > +++ b/scripts/lib/wic/help.py > > > > @@ -979,6 +979,13 @@ DESCRIPTION > > > > copies. This option only has an effect with the rootfs > > > > source plugin. > > > > > > > > + --embed-rootfs: This option is specific to wic. It embeds a rootfs into > > > > + the given path to the resulting image. The option > > > > + contains two fields, the roofs and the path, separated > > > > + by a colon. The rootfs follows the same logic as the > > > > + rootfs-dir argument. This option only has an effect > > > > + with the rootfs source plugin. > > > > + > > > > --extra-space: This option is specific to wic. It adds extra > > > > space after the space filled by the content > > > > of the partition. The final size can go > > > > diff --git a/scripts/lib/wic/ksparser.py b/scripts/lib/wic/ksparser.py > > > > index 650b976223..d422e2a6bb 100644 > > > > --- a/scripts/lib/wic/ksparser.py > > > > +++ b/scripts/lib/wic/ksparser.py > > > > @@ -138,6 +138,7 @@ class KickStart(): > > > > part.add_argument('--align', type=int) > > > > part.add_argument('--exclude-path', nargs='+') > > > > part.add_argument('--include-path', nargs='+') > > > > + part.add_argument('--embed-rootfs', nargs='+') > > > > part.add_argument("--extra-space", type=sizetype) > > > > part.add_argument('--fsoptions', dest='fsopts') > > > > part.add_argument('--fstype', default='vfat', > > > > diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py > > > > index 2d95f78439..13857df82f 100644 > > > > --- a/scripts/lib/wic/partition.py > > > > +++ b/scripts/lib/wic/partition.py > > > > @@ -31,6 +31,7 @@ class Partition(): > > > > self.extra_space = args.extra_space > > > > self.exclude_path = args.exclude_path > > > > self.include_path = args.include_path > > > > + self.embed_rootfs = args.embed_rootfs > > > > self.fsopts = args.fsopts > > > > self.fstype = args.fstype > > > > self.label = args.label > > > > diff --git a/scripts/lib/wic/plugins/source/rootfs.py b/scripts/lib/wic/plugins/source/rootfs.py > > > > index 40419a64b3..16359601dc 100644 > > > > --- a/scripts/lib/wic/plugins/source/rootfs.py > > > > +++ b/scripts/lib/wic/plugins/source/rootfs.py > > > > @@ -80,7 +80,7 @@ class RootfsPlugin(SourcePlugin): > > > > > > > > new_rootfs = None > > > > # Handle excluded paths. > > > > - if part.exclude_path or part.include_path: > > > > + if part.exclude_path or part.include_path or part.embed_rootfs: > > > > # We need a new rootfs directory we can delete files from. Copy to > > > > # workdir. > > > > new_rootfs = os.path.realpath(os.path.join(cr_workdir, "rootfs%d" % part.lineno)) > > > > @@ -100,6 +100,24 @@ class RootfsPlugin(SourcePlugin): > > > > for path in part.include_path or []: > > > > copyhardlinktree(path, new_rootfs) > > > > > > > > + for embed in part.embed_rootfs or []: > > > > + [embed_rootfs, path] = embed.split(":") > > > > + #we need to remove the initial / for os.path.join to work > > > > + if os.path.isabs(path): > > > > + path = path[1:] > > > > + if embed_rootfs in krootfs_dir: > > > > + embed_rootfs = krootfs_dir[embed_rootfs] > > > > + embed_rootfs = cls.__get_rootfs_dir(embed_rootfs) > > > > + tar_file = os.path.realpath(os.path.join(cr_workdir, "aux.tar")) > > > > + tar_cmd = "%s tar cpf %s -C %s ." % (cls.__get_pseudo(native_sysroot, > > > > + embed_rootfs), tar_file, embed_rootfs) > > > > + exec_native_cmd(tar_cmd, native_sysroot) > > > > + untar_cmd = "%s tar xf %s -C %s ." % (cls.__get_pseudo(native_sysroot, new_rootfs), > > > > + tar_file, os.path.join(new_rootfs, path)) > > > > + exec_native_cmd(untar_cmd, native_sysroot, > > > > + cls.__get_pseudo(native_sysroot, new_rootfs)) > > > > + os.remove(tar_file) > > > > + > > > > > > Why are you using an intermediate tar file here? > > > > For the permissions :( > > Your previous patch handled this using 'pseudo -B'. It would be good to be > consistent if possible - either use an intermediate tar file in all cases if > it's necessary or use 'pseudo -B' in all cases. Unfortunately, you cannot use pseudo -B in this case. You use pseudo -B when you move one pseudo-aware partition to somewhere else. But now we are merging two pseudo-aware partitions. Also I would not use the intermediate tar on the first place because it is a waste of space + cpu resources. Copyhardlink is the right tool > > -- > Paul Barker > Konsulko Group -- Ricardo Ribalda From zhengrq.fnst at cn.fujitsu.com Wed Mar 4 10:15:07 2020 From: zhengrq.fnst at cn.fujitsu.com (Zheng Ruoqin) Date: Wed, 4 Mar 2020 18:15:07 +0800 Subject: [OE-core] [PATCH] xkbcomp: upgrade 1.4.2 -> 1.4.3 Message-ID: <1583316907-9688-1-git-send-email-zhengrq.fnst@cn.fujitsu.com> Signed-off-by: Zheng Ruoqin --- .../xorg-app/{xkbcomp_1.4.2.bb => xkbcomp_1.4.3.bb} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename meta/recipes-graphics/xorg-app/{xkbcomp_1.4.2.bb => xkbcomp_1.4.3.bb} (79%) diff --git a/meta/recipes-graphics/xorg-app/xkbcomp_1.4.2.bb b/meta/recipes-graphics/xorg-app/xkbcomp_1.4.3.bb similarity index 79% rename from meta/recipes-graphics/xorg-app/xkbcomp_1.4.2.bb rename to meta/recipes-graphics/xorg-app/xkbcomp_1.4.3.bb index ed1eed8662..2fa79c8438 100644 --- a/meta/recipes-graphics/xorg-app/xkbcomp_1.4.2.bb +++ b/meta/recipes-graphics/xorg-app/xkbcomp_1.4.3.bb @@ -15,5 +15,5 @@ BBCLASSEXTEND = "native" EXTRA_OECONF += "--disable-selective-werror" -SRC_URI[md5sum] = "12610df19df2af3797f2c130ee2bce97" -SRC_URI[sha256sum] = "6dd8bcb9be7e85bd7294abe261b8c7b0539d2fc93e41b80fb8bd013767ce8424" +SRC_URI[md5sum] = "6e4751d99373f85d459ab4dff28893f5" +SRC_URI[sha256sum] = "06242c169fc11caf601cac46d781d467748c6a330e15b36dce46520b8ac8d435" -- 2.17.1 From jupiter.hce at gmail.com Wed Mar 4 10:29:11 2020 From: jupiter.hce at gmail.com (JH) Date: Wed, 4 Mar 2020 21:29:11 +1100 Subject: [OE-core] Does Yocto / OE build u-boot image for u-boot configs in #define CONFIG_EXTRA_ENV_SETTINGS? Message-ID: Hi, I created recipes-bsp and an appended file u-boot-imx_2018.03.bbappend to build a customized imx6ullevk image, I added my configures in #define CONFIG_EXTRA_ENV_SETTINGS in mx6ullevk.h, it built the u-boot-ram.imx and u-boot-nand.imx, I tried uuu to store u-boot-ram.imx to the =customized imx6ullevk board, all settings in CONFIG_EXTRA_ENV_SETTINGS were lost, set nothing in u-boot. It did not seem that Yocto / OE built the u-boot correctly and properly, what I could be missing? Thank you. Kind regards, - jh From wallinux at gmail.com Wed Mar 4 10:32:37 2020 From: wallinux at gmail.com (Anders Wallin) Date: Wed, 4 Mar 2020 11:32:37 +0100 Subject: [OE-core] [PATCH] babeltrace2: added first version, 2.0.1 Message-ID: <20200304103237.4650-1-wallinux@gmail.com> Babeltrace 1 vs. Babeltrace 2 The Babeltrace project exists since 2010. In 2020, Babeltrace 2 was released. Babeltrace 2 is a complete rewrite of the library, Python bindings, and CLI. It is plugin based and offers much more features and potential than Babeltrace 1. Because Babeltrace 2 is still a young released project, some distributions still provide packages for the Babeltrace 1 project. Both projects can coexist on the same system as there are no common installed files. Signed-off-by: Anders Wallin --- meta/conf/distro/include/distro_alias.inc | 1 + meta/conf/distro/include/maintainers.inc | 1 + .../distro/include/ptest-packagelists.inc | 1 + .../packagegroup-core-tools-profile.bb | 2 + ...001-test_plugin-do-not-test-in-.libs.patch | 24 +++++ .../lttng/babeltrace2/run-ptest | 9 ++ .../recipes-kernel/lttng/babeltrace2_2.0.1.bb | 92 +++++++++++++++++++ 7 files changed, 130 insertions(+) create mode 100644 meta/recipes-kernel/lttng/babeltrace2/0001-test_plugin-do-not-test-in-.libs.patch create mode 100755 meta/recipes-kernel/lttng/babeltrace2/run-ptest create mode 100644 meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb diff --git a/meta/conf/distro/include/distro_alias.inc b/meta/conf/distro/include/distro_alias.inc index 79ebcaee29..0e4a9a9f8f 100644 --- a/meta/conf/distro/include/distro_alias.inc +++ b/meta/conf/distro/include/distro_alias.inc @@ -15,6 +15,7 @@ DISTRO_PN_ALIAS_pn-alsa-utils-scripts = "OE-Core" DISTRO_PN_ALIAS_pn-atk = "Fedora=atk OpenSuSE=atk" DISTRO_PN_ALIAS_pn-avahi-ui = "Ubuntu=avahi-discover Debian=avahi-discover" DISTRO_PN_ALIAS_pn-babeltrace = "OSPDT" +DISTRO_PN_ALIAS_pn-babeltrace2 = "OSPDT" DISTRO_PN_ALIAS_pn-bjam = "OpenSuSE=boost-jam Debian=bjam" DISTRO_PN_ALIAS_pn-blktool = "Debian=blktool Mandriva=blktool" DISTRO_PN_ALIAS_pn-bluez5 = "Fedora=bluez Opensuse=bluez" diff --git a/meta/conf/distro/include/maintainers.inc b/meta/conf/distro/include/maintainers.inc index 10095ffe76..adb18228e7 100644 --- a/meta/conf/distro/include/maintainers.inc +++ b/meta/conf/distro/include/maintainers.inc @@ -59,6 +59,7 @@ RECIPE_MAINTAINER_pn-automake = "Robert Yang " RECIPE_MAINTAINER_pn-avahi = "Yi Zhao " RECIPE_MAINTAINER_pn-avahi-ui = "Yi Zhao " RECIPE_MAINTAINER_pn-babeltrace = "Alexander Kanavin " +RECIPE_MAINTAINER_pn-babeltrace2 = "Alexander Kanavin " RECIPE_MAINTAINER_pn-base-files = "Anuj Mittal " RECIPE_MAINTAINER_pn-base-passwd = "Anuj Mittal " RECIPE_MAINTAINER_pn-bash = "Hongxu Jia " diff --git a/meta/conf/distro/include/ptest-packagelists.inc b/meta/conf/distro/include/ptest-packagelists.inc index 4afac58e3a..d6f3aafc7f 100644 --- a/meta/conf/distro/include/ptest-packagelists.inc +++ b/meta/conf/distro/include/ptest-packagelists.inc @@ -64,6 +64,7 @@ PTESTS_FAST = "\ PTESTS_SLOW = "\ babeltrace-ptest \ + babeltrace2-ptest \ busybox-ptest \ dbus-test-ptest \ e2fsprogs-ptest \ diff --git a/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb b/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb index 984c2fac92..ac180b542a 100644 --- a/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb +++ b/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb @@ -46,6 +46,7 @@ LTTNGMODULES = "lttng-modules" LTTNGMODULES_arc = "" BABELTRACE = "babeltrace" +BABELTRACE2 = "babeltrace2" # valgrind does not work on the following configurations/architectures @@ -69,6 +70,7 @@ RDEPENDS_${PN} = "\ ${LTTNGTOOLS} \ ${LTTNGMODULES} \ ${BABELTRACE} \ + ${BABELTRACE2} \ ${SYSTEMTAP} \ ${VALGRIND} \ " diff --git a/meta/recipes-kernel/lttng/babeltrace2/0001-test_plugin-do-not-test-in-.libs.patch b/meta/recipes-kernel/lttng/babeltrace2/0001-test_plugin-do-not-test-in-.libs.patch new file mode 100644 index 0000000000..d1dbabab44 --- /dev/null +++ b/meta/recipes-kernel/lttng/babeltrace2/0001-test_plugin-do-not-test-in-.libs.patch @@ -0,0 +1,24 @@ +From 49edc1efa64d7597f492c78b2b7c4b115c0a0ef7 Mon Sep 17 00:00:00 2001 +Message-Id: <49edc1efa64d7597f492c78b2b7c4b115c0a0ef7.1581587378.git.anders.wallin at windriver.com> +From: Anders Wallin +Date: Thu, 13 Feb 2020 10:49:28 +0100 +Subject: [PATCH] test_plugin: do not test in .libs + +Signed-off-by: Anders Wallin +--- + tests/lib/test_plugin | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/tests/lib/test_plugin b/tests/lib/test_plugin +index 652c90cc..1f817c50 100755 +--- a/tests/lib/test_plugin ++++ b/tests/lib/test_plugin +@@ -26,4 +26,4 @@ fi + # shellcheck source=../utils/utils.sh + source "$UTILSSH" + +-"${BT_TESTS_BUILDDIR}/lib/plugin" "${BT_TESTS_BUILDDIR}/lib/test-plugin-plugins/.libs" ++"${BT_TESTS_BUILDDIR}/lib/plugin" "${BT_TESTS_BUILDDIR}/lib/test-plugin-plugins" +-- +2.25.0 + diff --git a/meta/recipes-kernel/lttng/babeltrace2/run-ptest b/meta/recipes-kernel/lttng/babeltrace2/run-ptest new file mode 100755 index 0000000000..72fe223436 --- /dev/null +++ b/meta/recipes-kernel/lttng/babeltrace2/run-ptest @@ -0,0 +1,9 @@ +#!/bin/sh +# use target=recheck if you want to recheck failing tests +[ "$target" = "" ] && target=check + +# Without --ignore-exit, the tap harness causes any FAILs within a +# test plan to raise ERRORs; this is just noise. +makeargs="LOG_DRIVER_FLAGS=--ignore-exit abs_top_srcdir=$PWD abs_top_builddir=$PWD GREP=grep SED=sed PYTHON=python3" + +exec make -C tests -k -s $makeargs $target 2>/dev/null diff --git a/meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb b/meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb new file mode 100644 index 0000000000..bcbc1ff7d1 --- /dev/null +++ b/meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb @@ -0,0 +1,92 @@ +SUMMARY = "Babeltrace2 - Trace Format Babel Tower" +DESCRIPTION = "Babeltrace provides trace read and write libraries in host side, as well as a trace converter, which used to convert LTTng 2.0 traces into human-readable log." +HOMEPAGE = "http://babeltrace.org/" +BUGTRACKER = "https://bugs.lttng.org/projects/babeltrace" +LICENSE = "MIT & GPLv2 & LGPLv2.1 & BSD-2-Clause" +LIC_FILES_CHKSUM = "file://LICENSE;md5=a6a458c13f18385b7bc5069a6d7b176e" + +DEPENDS = "glib-2.0 util-linux popt bison-native flex-native" + +SRC_URI = "git://git.linuxfoundation.org/diamon/babeltrace.git;branch=stable-2.0 \ + file://run-ptest \ + file://0001-test_plugin-do-not-test-in-.libs.patch \ + " +SRCREV = "06df58f89ee51b1a2c6a2c187ec3f15691633910" +UPSTREAM_CHECK_GITTAGREGEX = "v(?P2(\.\d+)+)$" + +S = "${WORKDIR}/git" + +inherit autotools pkgconfig ptest + +EXTRA_OECONF = "--disable-debug-info" + +PACKAGECONFIG ??= "manpages" +PACKAGECONFIG[manpages] = ", --disable-man-pages, asciidoc-native xmlto-native" + +FILES_${PN}-staticdev += "${libdir}/babeltrace2/plugins/*.a" +FILES_${PN} += "${libdir}/babeltrace2/plugins/*.so" + +ASNEEDED = "" + +RDEPENDS_${PN}-ptest += "bash gawk python3" + +do_compile_ptest () { + make -C tests all +} + +do_install_ptest () { + install -d "${D}${PTEST_PATH}/tests" + + # Copy required files from source directory + for d in $(find "${S}/tests" -type d -printf '%P ') ; do + install -d "${D}${PTEST_PATH}/tests/$d" + find "${S}/tests/$d" -maxdepth 1 -executable -type f \ + -exec install -t "${D}${PTEST_PATH}/tests/$d" {} + + find "${S}/tests/$d" -maxdepth 1 -name *.sh \ + -exec install -t "${D}${PTEST_PATH}/tests/$d" {} \; + find "${S}/tests/$d" -maxdepth 1 -name *.py \ + -exec install -t "${D}${PTEST_PATH}/tests/$d" {} \; + find "${S}/tests/$d" -maxdepth 1 -name *.expect \ + -exec install -t "${D}${PTEST_PATH}/tests/$d" {} \; + done + install -d "${D}${PTEST_PATH}/tests/data/ctf-traces/" + cp -a ${S}/tests/data/ctf-traces/* ${D}${PTEST_PATH}/tests/data/ctf-traces/ + + # Copy the tests directory tree and the executables and + # Makefiles found within. + install -D "${B}/tests/Makefile" "${D}${PTEST_PATH}/tests/" + for d in $(find "${B}/tests" -type d -not -name .libs -printf '%P ') ; do + install -d "${D}${PTEST_PATH}/tests/$d" + find "${B}/tests/$d" -maxdepth 1 -executable -type f \ + -exec install -t "${D}${PTEST_PATH}/tests/$d" {} + + test -r "${B}/tests/$d/Makefile" && \ + install -t "${D}${PTEST_PATH}/tests/$d" "${B}/tests/$d/Makefile" + find "${B}/tests/$d" -maxdepth 1 -name *.sh \ + -exec install -t "${D}${PTEST_PATH}/tests/$d" {} \; + done + + for d in $(find "${B}/tests" -type d -name .libs -printf '%P ') ; do + for f in $(find "${B}/tests/$d" -maxdepth 1 -executable -type f -printf '%P ') ; do + cp ${B}/tests/$d/$f ${D}${PTEST_PATH}/tests/`dirname $d`/$f + done + done + + # Prevent attempts to update Makefiles during test runs, and + # silence "Making check in $SUBDIR" messages. + find "${D}${PTEST_PATH}" -name Makefile -type f -exec \ + sed -i \ + -e '/Makefile:/,/^$/d' \ + -e '/%: %.in/,/^$/d' \ + -e '/echo "Making $$target in $$subdir"; \\/d' \ + -e 's/^srcdir = \(.*\)/srcdir = ./' \ + -e 's/^builddir = \(.*\)/builddir = ./' \ + -e 's/^all-am:.*/all-am:/' \ + {} + + + # Substitute links to installed binaries. + install -d "${D}${PTEST_PATH}/src/cli/" + ln -s "${bindir}/babeltrace2" ${D}${PTEST_PATH}/src/cli/ + + # Remove architechture specific testfiles + rm -rf ${D}${PTEST_PATH}/tests/data/plugins/flt.lttng-utils.debug-info/* +} -- 2.25.1 From patchwork at patchwork.openembedded.org Wed Mar 4 11:02:05 2020 From: patchwork at patchwork.openembedded.org (Patchwork) Date: Wed, 04 Mar 2020 11:02:05 -0000 Subject: [OE-core] =?utf-8?q?=E2=9C=97_patchtest=3A_failure_for_babeltrace?= =?utf-8?q?2=3A_added_first_version=2C_2=2E0=2E1?= In-Reply-To: <20200304103237.4650-1-wallinux@gmail.com> References: <20200304103237.4650-1-wallinux@gmail.com> Message-ID: <20200304110205.2274.75222@do> == Series Details == Series: babeltrace2: added first version, 2.0.1 Revision: 1 URL : https://patchwork.openembedded.org/series/23087/ 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 Added patch file is missing Upstream-Status in the header [test_upstream_status_presence_format] Suggested fix Add Upstream-Status: to the header of meta/recipes-kernel/lttng/babeltrace2/0001-test_plugin-do-not-test-in-.libs.patch Standard format Upstream-Status: Valid status Pending, Accepted, Backport, Denied, Inappropriate [reason], Submitted [where] If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core at 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 From bunk at stusta.de Wed Mar 4 11:32:17 2020 From: bunk at stusta.de (Adrian Bunk) Date: Wed, 4 Mar 2020 13:32:17 +0200 Subject: [OE-core] [RFC][PATCH 1/2] nss: Move to meta-oe In-Reply-To: References: <20200223193408.5602-1-bunk@stusta.de> <20200224051745.GA6683@localhost> <20200227132729.GA6240@localhost> <20200304090507.GA7923@localhost> Message-ID: <20200304113217.GB7923@localhost> On Wed, Mar 04, 2020 at 10:36:52AM +0100, Alexander Kanavin wrote: > You are misinterpreting the announcement. The security updates are provided > by users as patches to the mailing list, maintainers merely collect and > integrate them. There is no promise from the project to do anything else, > and LTS doesn?t change that, it only extends the maintainer duty from one > year to two. Moving a recipe in or out of core does not fundamentally > change how much attention it gets w.r.t. security fixes. The part in question does not even talk about LTS, it describes the status quo for the current stable releases with one year support. >... > > <-- snip --> > > > > Yocto Project releases are usually maintained for one year. > > Beyond this period, releases move to community support, which means > > they only receive occasional patches for critical defects and updates, > > and no regular defect fixes and security updates. > > > > <-- snip --> >... This announcement states pretty clearly that security updates are provided for stable branches, but not for community supported branches. I am sure there will be an update to the announcement if this doesn't reflect current reality. cu Adrian From alex.kanavin at gmail.com Wed Mar 4 12:13:19 2020 From: alex.kanavin at gmail.com (Alexander Kanavin) Date: Wed, 4 Mar 2020 13:13:19 +0100 Subject: [OE-core] [RFC][PATCH 1/2] nss: Move to meta-oe In-Reply-To: <20200304113217.GB7923@localhost> References: <20200223193408.5602-1-bunk@stusta.de> <20200224051745.GA6683@localhost> <20200227132729.GA6240@localhost> <20200304090507.GA7923@localhost> <20200304113217.GB7923@localhost> Message-ID: On Wed, 4 Mar 2020 at 12:32, Adrian Bunk wrote: > I am sure there will be an update to the announcement if this doesn't > reflect current reality. > Who is expected to do the actual work of tracking CVEs, making action points and performing the actions? The current reality is this: the security update work is done ad hoc by community, even for stable branches. There is no rigorous security process like in Debian, and no roles to follow in that process. This means that if no one bothers to make a patch, the security issue will remain unfixed, and this does happen often. If you are expecting anything else (e.g. that listed recipe maintainers should do something), you're setting yourself up to be disappointed. Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.freihofer at siemens.com Wed Mar 4 12:30:10 2020 From: adrian.freihofer at siemens.com (Freihofer, Adrian) Date: Wed, 4 Mar 2020 12:30:10 +0000 Subject: [OE-core] [PATCH] bitbake: gitsm: download submodules In-Reply-To: <20200304095944.792423a0@ub1910> References: <84e64ccddc46261a59bb1e281ef3294e08119abc.camel@siemens.com> <20200304095944.792423a0@ub1910> Message-ID: -----Original Message----- From: Paul Barker To: "Freihofer, Adrian" Cc: openembedded-core at lists.openembedded.org < openembedded-core at lists.openembedded.org> Subject: Re: [OE-core] [PATCH] bitbake: gitsm: download submodules Date: Wed, 04 Mar 2020 09:59:44 +0000 On Wed, 4 Mar 2020 08:12:27 +0000 "Freihofer, Adrian" wrote: > The unpack function failed because the submodules were not > downloaded. > Calling download before unpack for each submodule solves this issue. > > Signed-off-by: Adrian Freihofer > --- > bitbake/lib/bb/fetch2/gitsm.py | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/bitbake/lib/bb/fetch2/gitsm.py > b/bitbake/lib/bb/fetch2/gitsm.py > index c622771d21..3715e9824f 100644 > --- a/bitbake/lib/bb/fetch2/gitsm.py > +++ b/bitbake/lib/bb/fetch2/gitsm.py > @@ -184,6 +184,7 @@ class GitSM(Git): > > try: > newfetch = Fetch([url], d, cache=False) > + newfetch.download() > newfetch.unpack(root=os.path.dirname(os.path.join(re > po > _conf, 'modules', module))) > except Exception as e: > logger.error('gitsm: submodule unpack failed: %s %s' > % > (type(e).__name__, str(e))) You shouldn't be trying to download submodules in the do_unpack step. If they're missing at this stage it probably indicates a fetch issue. Basically true, but the information about which submodules need to be downloaded is not available before the top level repo has been unpacked. I guess the solution must be something like: fetch top-level unpack top-level foreach submodule: fetch submodule unpack submodule What's the exact error that you're seeing? Don't remeber exactly. But when I debugged the flow, it became obvious, that the submodules are not downloaded. This could be related to the issue I saw when the fetcher uses git shallow tarballs from a mirror - if that's the case I'm planning to get that fixed this weekend. Yes, the problem occurs with git shallows. The patch solves it with and without shallows for us. Also, your email client seems to have chewed the patch up. It's best to send patches using `git send-email` only. Sorry, we switched to a new e-mail solution. I have to adapt my setup. From alex.kanavin at gmail.com Wed Mar 4 12:58:43 2020 From: alex.kanavin at gmail.com (Alexander Kanavin) Date: Wed, 4 Mar 2020 13:58:43 +0100 Subject: [OE-core] [PATCH] libmodule-build-perl: make it reproducible Message-ID: <20200304125843.917-1-alex.kanavin@gmail.com> Particularly, delete html docs as they have sysroot paths in them, and adjust build configuration to not refer to host paths either. Signed-off-by: Alexander Kanavin --- .../perl/libmodule-build-perl_0.4231.bb | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/meta/recipes-devtools/perl/libmodule-build-perl_0.4231.bb b/meta/recipes-devtools/perl/libmodule-build-perl_0.4231.bb index b1967c7b03..a6fd7b1c07 100644 --- a/meta/recipes-devtools/perl/libmodule-build-perl_0.4231.bb +++ b/meta/recipes-devtools/perl/libmodule-build-perl_0.4231.bb @@ -33,13 +33,26 @@ do_patch_module_build () { do_patch[postfuncs] += "do_patch_module_build" +EXTRA_CPAN_BUILD_FLAGS = "--create_packlist=0" + +do_install_append () { + rm -rf ${D}${docdir}/perl/html +} + do_install_ptest() { cp -r ${B}/inc ${D}${PTEST_PATH} cp -r ${B}/blib ${D}${PTEST_PATH} cp -r ${B}/_build ${D}${PTEST_PATH} cp -r ${B}/lib ${D}${PTEST_PATH} chown -R root:root ${D}${PTEST_PATH} - sed -i -e "s,'perl' => .*,'perl' => '/usr/bin/perl'\,,g" ${D}${PTEST_PATH}/_build/build_params + sed -i -e "s,'perl' => .*,'perl' => '/usr/bin/perl'\,,g" \ + -e "s,${STAGING_BINDIR_NATIVE}/perl-native/\.\.,${bindir}/,g" \ + -e "s,${S},,g" \ + -e "s,${D},,g" \ + ${D}${PTEST_PATH}/_build/build_params \ + ${D}${PTEST_PATH}/_build/runtime_params + rm -rf ${D}${PTEST_PATH}/blib/libhtml/site/lib/Module/ + rm -rf ${D}${PTEST_PATH}/_build/magicnum } RDEPENDS_${PN} += " \ -- 2.25.1 From alex.kanavin at gmail.com Wed Mar 4 13:00:54 2020 From: alex.kanavin at gmail.com (Alexander Kanavin) Date: Wed, 4 Mar 2020 14:00:54 +0100 Subject: [OE-core] Yocto Project Status WW09'20 In-Reply-To: <107c01d5f174$bbf566a0$33e033e0$@gmail.com> References: <107c01d5f174$bbf566a0$33e033e0$@gmail.com> Message-ID: On Tue, 3 Mar 2020 at 16:59, wrote: > coreutils ptest blocked on libmodule-build-perl reproducibility issue > I sent a patch for this. Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From ricardo at ribalda.com Wed Mar 4 13:49:44 2020 From: ricardo at ribalda.com (Ricardo Ribalda Delgado) Date: Wed, 4 Mar 2020 14:49:44 +0100 Subject: [OE-core] [PATCH 2/2] wic: Add --embed-rootfs argument In-Reply-To: References: <20200304083438.1022216-1-ricardo@ribalda.com> <20200304083438.1022216-2-ricardo@ribalda.com> <20200304094250.3eda52e1@ub1910> <20200304100855.637a61e1@ub1910> Message-ID: Hi Paul On Wed, Mar 4, 2020 at 11:14 AM Ricardo Ribalda Delgado wrote: > > Hi Paul > > On Wed, Mar 4, 2020 at 11:09 AM Paul Barker wrote: > > > > On Wed, 4 Mar 2020 10:56:20 +0100 > > Ricardo Ribalda Delgado wrote: > > > > > Hi Paul > > > > > > Thanks for your reply > > > > > > On Wed, Mar 4, 2020 at 10:43 AM Paul Barker wrote: > > > > > > > > On Wed, 4 Mar 2020 09:34:38 +0100 > > > > Ricardo Ribalda Delgado wrote: > > > > > > > > > This option adds the content of a rootfs on a specific location on the > > > > > rootfs. > > > > > > > > > > It is very useful for making a partition that contains the rootfs for a > > > > > host and a target Eg: > > > > > > > > > > / -> Roofs for the host > > > > > /export/ -> Rootfs for the target (which will netboot) > > > > > > > > > > Although today we support making a partition for "/export" this might > > > > > not be compatible with some upgrade systems, or we might be limited by > > > > > the number of partitions. > > > > > > > > > > With this patch we can use something like: > > > > > > > > > > part / --source rootfs --embed-rootfs=target-image:/export > > > > > > > > I considered using a syntax like this for --include-path but I chose not to > > > > as it's not easy to choose a separator. ':' is a valid character in a > > > > directory name. > > > > > > I think we have to live with not being able to copy files to a > > > directory with a colon :( > > > > I wouldn't like to place a limitation like that on users and I'd like to > > avoid the proliferation of similar arguments here. > > > > How about modifying '--include-path' to take two arguments, a source path and > > a destination prefix? The python argument parser should be able to handle > > this and you can build a list of tuples (source_path, dest_prefix) when > > parsing the arguments. > > > > The '--include-path' argument hasn't been part of a Yocto release yet it's > > just on the master branch so I think if we're going to fix it with a breaking > > change, now is definitely the time. > > That sounds good to me. I do not mind having two arguments. for > embed-rootfs. and probably will look better on include-path How do you think that the parameters should look like: --embed-rootfs target-image /export target-image2 /export2 --embed-rootfs (target-image, /export) (target-image2, /export2) ?? Shall I change it for include-path and embed-rootfs or you want to take care of include-path? > > > > > > > > > > > > > > My approach is to handle this in two steps: > > > > > > > > 1) Add a new task before do_image_wic which creates an 'embedded-rootfs' > > > > directory and copies 'target-image' to 'embedded-rootfs/export'. > > > > > > > > 2) Use '--include-path=embedded-rootfs' in the wks file. > > > > > > > > > > The biggest problem with that approach is permissions. We need files > > > with UID 0, siticky bits, etc. We lose the pseudo database if we > > > simply copy to a folder. > > > > > > Also, if we have a complex system with multiple partitions I prefer to > > > handle all in a single .wks file instead of a script + wks file > > > > > > > > > > > > > on the .wks file. > > > > > > > > > > Signed-off-by: Ricardo Ribalda Delgado > > > > > --- > > > > > scripts/lib/wic/help.py | 7 +++++++ > > > > > scripts/lib/wic/ksparser.py | 1 + > > > > > scripts/lib/wic/partition.py | 1 + > > > > > scripts/lib/wic/plugins/source/rootfs.py | 20 +++++++++++++++++++- > > > > > 4 files changed, 28 insertions(+), 1 deletion(-) > > > > > > > > > > diff --git a/scripts/lib/wic/help.py b/scripts/lib/wic/help.py > > > > > index 4d342fcf05..67a33e6a65 100644 > > > > > --- a/scripts/lib/wic/help.py > > > > > +++ b/scripts/lib/wic/help.py > > > > > @@ -979,6 +979,13 @@ DESCRIPTION > > > > > copies. This option only has an effect with the rootfs > > > > > source plugin. > > > > > > > > > > + --embed-rootfs: This option is specific to wic. It embeds a rootfs into > > > > > + the given path to the resulting image. The option > > > > > + contains two fields, the roofs and the path, separated > > > > > + by a colon. The rootfs follows the same logic as the > > > > > + rootfs-dir argument. This option only has an effect > > > > > + with the rootfs source plugin. > > > > > + > > > > > --extra-space: This option is specific to wic. It adds extra > > > > > space after the space filled by the content > > > > > of the partition. The final size can go > > > > > diff --git a/scripts/lib/wic/ksparser.py b/scripts/lib/wic/ksparser.py > > > > > index 650b976223..d422e2a6bb 100644 > > > > > --- a/scripts/lib/wic/ksparser.py > > > > > +++ b/scripts/lib/wic/ksparser.py > > > > > @@ -138,6 +138,7 @@ class KickStart(): > > > > > part.add_argument('--align', type=int) > > > > > part.add_argument('--exclude-path', nargs='+') > > > > > part.add_argument('--include-path', nargs='+') > > > > > + part.add_argument('--embed-rootfs', nargs='+') > > > > > part.add_argument("--extra-space", type=sizetype) > > > > > part.add_argument('--fsoptions', dest='fsopts') > > > > > part.add_argument('--fstype', default='vfat', > > > > > diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py > > > > > index 2d95f78439..13857df82f 100644 > > > > > --- a/scripts/lib/wic/partition.py > > > > > +++ b/scripts/lib/wic/partition.py > > > > > @@ -31,6 +31,7 @@ class Partition(): > > > > > self.extra_space = args.extra_space > > > > > self.exclude_path = args.exclude_path > > > > > self.include_path = args.include_path > > > > > + self.embed_rootfs = args.embed_rootfs > > > > > self.fsopts = args.fsopts > > > > > self.fstype = args.fstype > > > > > self.label = args.label > > > > > diff --git a/scripts/lib/wic/plugins/source/rootfs.py b/scripts/lib/wic/plugins/source/rootfs.py > > > > > index 40419a64b3..16359601dc 100644 > > > > > --- a/scripts/lib/wic/plugins/source/rootfs.py > > > > > +++ b/scripts/lib/wic/plugins/source/rootfs.py > > > > > @@ -80,7 +80,7 @@ class RootfsPlugin(SourcePlugin): > > > > > > > > > > new_rootfs = None > > > > > # Handle excluded paths. > > > > > - if part.exclude_path or part.include_path: > > > > > + if part.exclude_path or part.include_path or part.embed_rootfs: > > > > > # We need a new rootfs directory we can delete files from. Copy to > > > > > # workdir. > > > > > new_rootfs = os.path.realpath(os.path.join(cr_workdir, "rootfs%d" % part.lineno)) > > > > > @@ -100,6 +100,24 @@ class RootfsPlugin(SourcePlugin): > > > > > for path in part.include_path or []: > > > > > copyhardlinktree(path, new_rootfs) > > > > > > > > > > + for embed in part.embed_rootfs or []: > > > > > + [embed_rootfs, path] = embed.split(":") > > > > > + #we need to remove the initial / for os.path.join to work > > > > > + if os.path.isabs(path): > > > > > + path = path[1:] > > > > > + if embed_rootfs in krootfs_dir: > > > > > + embed_rootfs = krootfs_dir[embed_rootfs] > > > > > + embed_rootfs = cls.__get_rootfs_dir(embed_rootfs) > > > > > + tar_file = os.path.realpath(os.path.join(cr_workdir, "aux.tar")) > > > > > + tar_cmd = "%s tar cpf %s -C %s ." % (cls.__get_pseudo(native_sysroot, > > > > > + embed_rootfs), tar_file, embed_rootfs) > > > > > + exec_native_cmd(tar_cmd, native_sysroot) > > > > > + untar_cmd = "%s tar xf %s -C %s ." % (cls.__get_pseudo(native_sysroot, new_rootfs), > > > > > + tar_file, os.path.join(new_rootfs, path)) > > > > > + exec_native_cmd(untar_cmd, native_sysroot, > > > > > + cls.__get_pseudo(native_sysroot, new_rootfs)) > > > > > + os.remove(tar_file) > > > > > + > > > > > > > > Why are you using an intermediate tar file here? > > > > > > For the permissions :( > > > > Your previous patch handled this using 'pseudo -B'. It would be good to be > > consistent if possible - either use an intermediate tar file in all cases if > > it's necessary or use 'pseudo -B' in all cases. > > Unfortunately, you cannot use pseudo -B in this case. > > You use pseudo -B when you move one pseudo-aware partition to > somewhere else. But now we are merging two pseudo-aware partitions. > > Also I would not use the intermediate tar on the first place because > it is a waste of space + cpu resources. Copyhardlink is the right > tool > > > > > > -- > > Paul Barker > > Konsulko Group > > > > -- > Ricardo Ribalda -- Ricardo Ribalda From bunk at stusta.de Wed Mar 4 14:01:09 2020 From: bunk at stusta.de (Adrian Bunk) Date: Wed, 4 Mar 2020 16:01:09 +0200 Subject: [OE-core] Does YP provide security support for stable and LTS branches? In-Reply-To: References: <20200223193408.5602-1-bunk@stusta.de> <20200224051745.GA6683@localhost> <20200227132729.GA6240@localhost> <20200304090507.GA7923@localhost> <20200304113217.GB7923@localhost> Message-ID: <20200304140109.GC7923@localhost> On Wed, Mar 04, 2020 at 01:13:19PM +0100, Alexander Kanavin wrote: > On Wed, 4 Mar 2020 at 12:32, Adrian Bunk wrote: > > > I am sure there will be an update to the announcement if this doesn't > > reflect current reality. > > Who is expected to do the actual work of tracking CVEs, making action > points and performing the actions? The current reality is this: the > security update work is done ad hoc by community, even for stable branches. > There is no rigorous security process like in Debian, and no roles to > follow in that process. This means that if no one bothers to make a patch, > the security issue will remain unfixed, and this does happen often. If you > are expecting anything else (e.g. that listed recipe maintainers should do > something), you're setting yourself up to be disappointed. All I am expecting is honesty. If YP does not provide security support for supported stable branches, then public statements that community support would be worse than stable branches due to lack of security support are dishonest and offensive. It also puts all users of Yocto stable and LTS releases and billions of devices at danger if the Yocto project announces security support but does not deliver. The normal user expects that that the announced "usual defect fixes and updates for the extended period of two years" in LTS include the regular security updates that were claimed for stable branches earlier in the same announcement. For cases where I am the user the only benefit of going through the pain of upgrading existing products from older releases to Yocto 3.1 would be 2 years of security support from upstream. Doing the upgrade and only discovering afterwards that it doesn't bring the benefit that was promised would make me . Let me repeat that the only thing I am expecting is honesty, and all I am asking for is that if YP does not provide security support for stable and LTS branches this should be communicated clearly so that all users are aware. > Alex cu Adrian From stefan at agner.ch Wed Mar 4 13:55:43 2020 From: stefan at agner.ch (Stefan Agner) Date: Wed, 4 Mar 2020 14:55:43 +0100 Subject: [OE-core] [PATCH] kernel-yocto.bbclass: fix a wrong inter-task dependency Message-ID: <20200304135543.1832937-1-stefan@agner.ch> From: Ming Liu do_kernel_checkout and do_symlink_kernsrc are both modifying ${S}, they could conflict with eacher other, move do_kernel_checkout after do_symlink_kernsrc does fix that. Signed-off-by: Ming Liu Signed-off-by: Stefan Agner --- meta/classes/kernel-yocto.bbclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/classes/kernel-yocto.bbclass b/meta/classes/kernel-yocto.bbclass index 44863adc27..d71ce212a8 100644 --- a/meta/classes/kernel-yocto.bbclass +++ b/meta/classes/kernel-yocto.bbclass @@ -317,7 +317,7 @@ do_kernel_checkout() { } do_kernel_checkout[dirs] = "${S}" -addtask kernel_checkout before do_kernel_metadata after do_unpack +addtask kernel_checkout before do_kernel_metadata after do_symlink_kernsrc addtask kernel_metadata after do_validate_branches do_unpack before do_patch do_kernel_metadata[depends] = "kern-tools-native:do_populate_sysroot" do_validate_branches[depends] = "kern-tools-native:do_populate_sysroot" -- 2.25.0 From jpewhacker at gmail.com Wed Mar 4 14:31:55 2020 From: jpewhacker at gmail.com (Joshua Watt) Date: Wed, 4 Mar 2020 08:31:55 -0600 Subject: [OE-core] [PATCH 2/2] wic: Add --embed-rootfs argument In-Reply-To: References: <20200304083438.1022216-1-ricardo@ribalda.com> <20200304083438.1022216-2-ricardo@ribalda.com> <20200304094250.3eda52e1@ub1910> <20200304100855.637a61e1@ub1910> Message-ID: <872b6980-5810-7d8a-36b2-f53ae50df0a6@gmail.com> On 3/4/20 7:49 AM, Ricardo Ribalda Delgado wrote: > Hi Paul > > On Wed, Mar 4, 2020 at 11:14 AM Ricardo Ribalda Delgado > wrote: >> Hi Paul >> >> On Wed, Mar 4, 2020 at 11:09 AM Paul Barker wrote: >>> On Wed, 4 Mar 2020 10:56:20 +0100 >>> Ricardo Ribalda Delgado wrote: >>> >>>> Hi Paul >>>> >>>> Thanks for your reply >>>> >>>> On Wed, Mar 4, 2020 at 10:43 AM Paul Barker wrote: >>>>> On Wed, 4 Mar 2020 09:34:38 +0100 >>>>> Ricardo Ribalda Delgado wrote: >>>>> >>>>>> This option adds the content of a rootfs on a specific location on the >>>>>> rootfs. >>>>>> >>>>>> It is very useful for making a partition that contains the rootfs for a >>>>>> host and a target Eg: >>>>>> >>>>>> / -> Roofs for the host >>>>>> /export/ -> Rootfs for the target (which will netboot) >>>>>> >>>>>> Although today we support making a partition for "/export" this might >>>>>> not be compatible with some upgrade systems, or we might be limited by >>>>>> the number of partitions. >>>>>> >>>>>> With this patch we can use something like: >>>>>> >>>>>> part / --source rootfs --embed-rootfs=target-image:/export >>>>> I considered using a syntax like this for --include-path but I chose not to >>>>> as it's not easy to choose a separator. ':' is a valid character in a >>>>> directory name. >>>> I think we have to live with not being able to copy files to a >>>> directory with a colon :( >>> I wouldn't like to place a limitation like that on users and I'd like to >>> avoid the proliferation of similar arguments here. >>> >>> How about modifying '--include-path' to take two arguments, a source path and >>> a destination prefix? The python argument parser should be able to handle >>> this and you can build a list of tuples (source_path, dest_prefix) when >>> parsing the arguments. >>> >>> The '--include-path' argument hasn't been part of a Yocto release yet it's >>> just on the master branch so I think if we're going to fix it with a breaking >>> change, now is definitely the time. >> That sounds good to me. I do not mind having two arguments. for >> embed-rootfs. and probably will look better on include-path > How do you think that the parameters should look like: > > --embed-rootfs target-image /export target-image2 /export2 > --embed-rootfs (target-image, /export) (target-image2, /export2) > ?? FWIW, it should probably end up looking like this: ?--embed-rootfs target-image /export --embed-rootfs target-image2 /export2 The python argparse snippet you would use for this would be something like: ?parser.add_argument('--embed-rootfs', nargs=2, action='append', default=(), help='...') > > Shall I change it for include-path and embed-rootfs or you want to > take care of include-path? > >>>>> My approach is to handle this in two steps: >>>>> >>>>> 1) Add a new task before do_image_wic which creates an 'embedded-rootfs' >>>>> directory and copies 'target-image' to 'embedded-rootfs/export'. >>>>> >>>>> 2) Use '--include-path=embedded-rootfs' in the wks file. >>>>> >>>> The biggest problem with that approach is permissions. We need files >>>> with UID 0, siticky bits, etc. We lose the pseudo database if we >>>> simply copy to a folder. >>>> >>>> Also, if we have a complex system with multiple partitions I prefer to >>>> handle all in a single .wks file instead of a script + wks file >>>> >>>>>> on the .wks file. >>>>>> >>>>>> Signed-off-by: Ricardo Ribalda Delgado >>>>>> --- >>>>>> scripts/lib/wic/help.py | 7 +++++++ >>>>>> scripts/lib/wic/ksparser.py | 1 + >>>>>> scripts/lib/wic/partition.py | 1 + >>>>>> scripts/lib/wic/plugins/source/rootfs.py | 20 +++++++++++++++++++- >>>>>> 4 files changed, 28 insertions(+), 1 deletion(-) >>>>>> >>>>>> diff --git a/scripts/lib/wic/help.py b/scripts/lib/wic/help.py >>>>>> index 4d342fcf05..67a33e6a65 100644 >>>>>> --- a/scripts/lib/wic/help.py >>>>>> +++ b/scripts/lib/wic/help.py >>>>>> @@ -979,6 +979,13 @@ DESCRIPTION >>>>>> copies. This option only has an effect with the rootfs >>>>>> source plugin. >>>>>> >>>>>> + --embed-rootfs: This option is specific to wic. It embeds a rootfs into >>>>>> + the given path to the resulting image. The option >>>>>> + contains two fields, the roofs and the path, separated >>>>>> + by a colon. The rootfs follows the same logic as the >>>>>> + rootfs-dir argument. This option only has an effect >>>>>> + with the rootfs source plugin. >>>>>> + >>>>>> --extra-space: This option is specific to wic. It adds extra >>>>>> space after the space filled by the content >>>>>> of the partition. The final size can go >>>>>> diff --git a/scripts/lib/wic/ksparser.py b/scripts/lib/wic/ksparser.py >>>>>> index 650b976223..d422e2a6bb 100644 >>>>>> --- a/scripts/lib/wic/ksparser.py >>>>>> +++ b/scripts/lib/wic/ksparser.py >>>>>> @@ -138,6 +138,7 @@ class KickStart(): >>>>>> part.add_argument('--align', type=int) >>>>>> part.add_argument('--exclude-path', nargs='+') >>>>>> part.add_argument('--include-path', nargs='+') >>>>>> + part.add_argument('--embed-rootfs', nargs='+') >>>>>> part.add_argument("--extra-space", type=sizetype) >>>>>> part.add_argument('--fsoptions', dest='fsopts') >>>>>> part.add_argument('--fstype', default='vfat', >>>>>> diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py >>>>>> index 2d95f78439..13857df82f 100644 >>>>>> --- a/scripts/lib/wic/partition.py >>>>>> +++ b/scripts/lib/wic/partition.py >>>>>> @@ -31,6 +31,7 @@ class Partition(): >>>>>> self.extra_space = args.extra_space >>>>>> self.exclude_path = args.exclude_path >>>>>> self.include_path = args.include_path >>>>>> + self.embed_rootfs = args.embed_rootfs >>>>>> self.fsopts = args.fsopts >>>>>> self.fstype = args.fstype >>>>>> self.label = args.label >>>>>> diff --git a/scripts/lib/wic/plugins/source/rootfs.py b/scripts/lib/wic/plugins/source/rootfs.py >>>>>> index 40419a64b3..16359601dc 100644 >>>>>> --- a/scripts/lib/wic/plugins/source/rootfs.py >>>>>> +++ b/scripts/lib/wic/plugins/source/rootfs.py >>>>>> @@ -80,7 +80,7 @@ class RootfsPlugin(SourcePlugin): >>>>>> >>>>>> new_rootfs = None >>>>>> # Handle excluded paths. >>>>>> - if part.exclude_path or part.include_path: >>>>>> + if part.exclude_path or part.include_path or part.embed_rootfs: >>>>>> # We need a new rootfs directory we can delete files from. Copy to >>>>>> # workdir. >>>>>> new_rootfs = os.path.realpath(os.path.join(cr_workdir, "rootfs%d" % part.lineno)) >>>>>> @@ -100,6 +100,24 @@ class RootfsPlugin(SourcePlugin): >>>>>> for path in part.include_path or []: >>>>>> copyhardlinktree(path, new_rootfs) >>>>>> >>>>>> + for embed in part.embed_rootfs or []: >>>>>> + [embed_rootfs, path] = embed.split(":") >>>>>> + #we need to remove the initial / for os.path.join to work >>>>>> + if os.path.isabs(path): >>>>>> + path = path[1:] >>>>>> + if embed_rootfs in krootfs_dir: >>>>>> + embed_rootfs = krootfs_dir[embed_rootfs] >>>>>> + embed_rootfs = cls.__get_rootfs_dir(embed_rootfs) >>>>>> + tar_file = os.path.realpath(os.path.join(cr_workdir, "aux.tar")) >>>>>> + tar_cmd = "%s tar cpf %s -C %s ." % (cls.__get_pseudo(native_sysroot, >>>>>> + embed_rootfs), tar_file, embed_rootfs) >>>>>> + exec_native_cmd(tar_cmd, native_sysroot) >>>>>> + untar_cmd = "%s tar xf %s -C %s ." % (cls.__get_pseudo(native_sysroot, new_rootfs), >>>>>> + tar_file, os.path.join(new_rootfs, path)) >>>>>> + exec_native_cmd(untar_cmd, native_sysroot, >>>>>> + cls.__get_pseudo(native_sysroot, new_rootfs)) >>>>>> + os.remove(tar_file) >>>>>> + >>>>> Why are you using an intermediate tar file here? >>>> For the permissions :( >>> Your previous patch handled this using 'pseudo -B'. It would be good to be >>> consistent if possible - either use an intermediate tar file in all cases if >>> it's necessary or use 'pseudo -B' in all cases. >> Unfortunately, you cannot use pseudo -B in this case. >> >> You use pseudo -B when you move one pseudo-aware partition to >> somewhere else. But now we are merging two pseudo-aware partitions. >> >> Also I would not use the intermediate tar on the first place because >> it is a waste of space + cpu resources. Copyhardlink is the right >> tool >> >> >>> -- >>> Paul Barker >>> Konsulko Group >> >> >> -- >> Ricardo Ribalda > > From ricardo at ribalda.com Wed Mar 4 14:49:35 2020 From: ricardo at ribalda.com (Ricardo Ribalda Delgado) Date: Wed, 4 Mar 2020 15:49:35 +0100 Subject: [OE-core] [PATCH v2 1/2] wic: Fix permissions when using exclude or include path Message-ID: <20200304144936.2559106-1-ricardo@ribalda.com> When parameters include_path or exclude_path are passed to the rootfs plugin, it will copy the partition content into a folder and make all the modifications there. This is done using copyhardlinktree(), which does not take into consideration the content of the pseudo folder, which contains the information about the right permissions and ownership of the folders. This results in a rootfs owned by the user that is running the wic command (usually UID 1000), which makes some rootfs unbootable. To fix this we copy the content of the pseudo folders to the new folder and modify the pseudo database using the "pseudo -B" command. Signed-off-by: Ricardo Ribalda Delgado --- scripts/lib/wic/plugins/source/rootfs.py | 22 +++++++++++++++++++--- 1 file changed, 19 insertions(+), 3 deletions(-) diff --git a/scripts/lib/wic/plugins/source/rootfs.py b/scripts/lib/wic/plugins/source/rootfs.py index 705aeb5563..40419a64b3 100644 --- a/scripts/lib/wic/plugins/source/rootfs.py +++ b/scripts/lib/wic/plugins/source/rootfs.py @@ -16,11 +16,11 @@ import os import shutil import sys -from oe.path import copyhardlinktree +from oe.path import copyhardlinktree, copytree from wic import WicError from wic.pluginbase import SourcePlugin -from wic.misc import get_bitbake_var +from wic.misc import get_bitbake_var, exec_native_cmd logger = logging.getLogger('wic') @@ -44,6 +44,15 @@ class RootfsPlugin(SourcePlugin): return os.path.realpath(image_rootfs_dir) + @staticmethod + def __get_pseudo(native_sysroot, rootfs): + pseudo = "export PSEUDO_PREFIX=%s/usr;" % native_sysroot + pseudo += "export PSEUDO_LOCALSTATEDIR=%s;" % os.path.join(rootfs, "../pseudo") + pseudo += "export PSEUDO_PASSWD=%s;" % rootfs + pseudo += "export PSEUDO_NOSYMLINKEXP=1;" + pseudo += "%s " % get_bitbake_var("FAKEROOTCMD") + return pseudo + @classmethod def do_prepare_partition(cls, part, source_params, cr, cr_workdir, oe_builddir, bootimg_dir, kernel_dir, @@ -78,9 +87,16 @@ class RootfsPlugin(SourcePlugin): if os.path.lexists(new_rootfs): shutil.rmtree(os.path.join(new_rootfs)) - copyhardlinktree(part.rootfs_dir, new_rootfs) + if os.path.lexists(os.path.join(new_rootfs, "../pseudo")): + shutil.rmtree(os.path.join(new_rootfs, "../pseudo")) + copytree(os.path.join(part.rootfs_dir, "../pseudo"), + os.path.join(new_rootfs, "../pseudo")) + pseudo_cmd = "%s -B -m %s -M %s" % (cls.__get_pseudo(native_sysroot,new_rootfs), + part.rootfs_dir, new_rootfs) + exec_native_cmd(pseudo_cmd, native_sysroot) + for path in part.include_path or []: copyhardlinktree(path, new_rootfs) -- 2.25.1 From ricardo at ribalda.com Wed Mar 4 14:49:36 2020 From: ricardo at ribalda.com (Ricardo Ribalda Delgado) Date: Wed, 4 Mar 2020 15:49:36 +0100 Subject: [OE-core] [PATCH v2 2/2] wic: Add --embed-rootfs argument In-Reply-To: <20200304144936.2559106-1-ricardo@ribalda.com> References: <20200304144936.2559106-1-ricardo@ribalda.com> Message-ID: <20200304144936.2559106-2-ricardo@ribalda.com> This option adds the content of a rootfs on a specific location on the rootfs. It is very useful for making a partition that contains the rootfs for a host and a target Eg: / -> Roofs for the host /export/ -> Rootfs for the target (which will netboot) Although today we support making a partition for "/export" this might not be compatible with some upgrade systems, or we might be limited by the number of partitions. With this patch we can use something like: part / --source rootfs --embed-rootfs target-image /export --embed-rootfs target-image2 /export2 on the .wks file. Signed-off-by: Ricardo Ribalda Delgado --- scripts/lib/wic/help.py | 8 ++++++++ scripts/lib/wic/ksparser.py | 1 + scripts/lib/wic/partition.py | 1 + scripts/lib/wic/plugins/source/rootfs.py | 22 +++++++++++++++++++++- 4 files changed, 31 insertions(+), 1 deletion(-) diff --git a/scripts/lib/wic/help.py b/scripts/lib/wic/help.py index 4d342fcf05..140dc504cd 100644 --- a/scripts/lib/wic/help.py +++ b/scripts/lib/wic/help.py @@ -979,6 +979,14 @@ DESCRIPTION copies. This option only has an effect with the rootfs source plugin. + --embed-rootfs: This option is specific to wic. It embeds a rootfs into + the given path to the resulting image. The option + contains two fields, the roofs and the path, separated + by a space. The rootfs follows the same logic as the + rootfs-dir argument. Multiple options can be provided + in order to embed multiple rootfs. This option only has + an effect with the rootfs source plugin. + --extra-space: This option is specific to wic. It adds extra space after the space filled by the content of the partition. The final size can go diff --git a/scripts/lib/wic/ksparser.py b/scripts/lib/wic/ksparser.py index 650b976223..64c8c1175e 100644 --- a/scripts/lib/wic/ksparser.py +++ b/scripts/lib/wic/ksparser.py @@ -138,6 +138,7 @@ class KickStart(): part.add_argument('--align', type=int) part.add_argument('--exclude-path', nargs='+') part.add_argument('--include-path', nargs='+') + part.add_argument('--embed-rootfs', nargs=2, action='append') part.add_argument("--extra-space", type=sizetype) part.add_argument('--fsoptions', dest='fsopts') part.add_argument('--fstype', default='vfat', diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py index 2d95f78439..13857df82f 100644 --- a/scripts/lib/wic/partition.py +++ b/scripts/lib/wic/partition.py @@ -31,6 +31,7 @@ class Partition(): self.extra_space = args.extra_space self.exclude_path = args.exclude_path self.include_path = args.include_path + self.embed_rootfs = args.embed_rootfs self.fsopts = args.fsopts self.fstype = args.fstype self.label = args.label diff --git a/scripts/lib/wic/plugins/source/rootfs.py b/scripts/lib/wic/plugins/source/rootfs.py index 40419a64b3..089aaea477 100644 --- a/scripts/lib/wic/plugins/source/rootfs.py +++ b/scripts/lib/wic/plugins/source/rootfs.py @@ -17,6 +17,7 @@ import shutil import sys from oe.path import copyhardlinktree, copytree +from pathlib import Path from wic import WicError from wic.pluginbase import SourcePlugin @@ -80,7 +81,7 @@ class RootfsPlugin(SourcePlugin): new_rootfs = None # Handle excluded paths. - if part.exclude_path or part.include_path: + if part.exclude_path or part.include_path or part.embed_rootfs: # We need a new rootfs directory we can delete files from. Copy to # workdir. new_rootfs = os.path.realpath(os.path.join(cr_workdir, "rootfs%d" % part.lineno)) @@ -100,6 +101,25 @@ class RootfsPlugin(SourcePlugin): for path in part.include_path or []: copyhardlinktree(path, new_rootfs) + for embed in part.embed_rootfs or []: + [embed_rootfs, path] = embed + #we need to remove the initial / for os.path.join to work + if os.path.isabs(path): + path = path[1:] + if embed_rootfs in krootfs_dir: + embed_rootfs = krootfs_dir[embed_rootfs] + embed_rootfs = cls.__get_rootfs_dir(embed_rootfs) + tar_file = os.path.realpath(os.path.join(cr_workdir, "aux.tar")) + tar_cmd = "%s tar cpf %s -C %s ." % (cls.__get_pseudo(native_sysroot, + embed_rootfs), tar_file, embed_rootfs) + exec_native_cmd(tar_cmd, native_sysroot) + untar_cmd = "%s tar xf %s -C %s ." % (cls.__get_pseudo(native_sysroot, new_rootfs), + tar_file, os.path.join(new_rootfs, path)) + Path(os.path.join(new_rootfs, path)).mkdir(parents=True, exist_ok=True) + exec_native_cmd(untar_cmd, native_sysroot, + cls.__get_pseudo(native_sysroot, new_rootfs)) + os.remove(tar_file) + for orig_path in part.exclude_path or []: path = orig_path if os.path.isabs(path): -- 2.25.1 From bruce.ashfield at gmail.com Wed Mar 4 14:55:20 2020 From: bruce.ashfield at gmail.com (bruce.ashfield at gmail.com) Date: Wed, 4 Mar 2020 09:55:20 -0500 Subject: [OE-core] [PATCH 0/4] kernel-yocto: consolidated pull request Message-ID: From: Bruce Ashfield Hi all, As mentioned on the technical call yesterday, here's my latest set of 5.2 updates, 5.4 updates and more importantly, the removal of 5.2 from master. As usual, I'll continue to support and update 5.2, just without sending SRCREV updates to master. The last set of updates to v5.2 put it in good shape, and they are ready for backport to any stable branches. I ran this through the AB and didn't see any issues or old references to v5.2. I'll follow up to other lists to drop a few of the old bbappends. Cheers, Bruce The following changes since commit 92e172b5b4de8927d36409386dfce0fc2718f5d1: systemd: Fix service file for race issues (2020-03-03 13:06:29 +0000) are available in the Git repository at: git://git.yoctoproject.org/poky-contrib zedd/kernel http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel Bruce Ashfield (4): linux-yocto/5.2: backport perf build fix for latest binutils linux-yocto: common-pc-drivers.cfg: add CONFIG_INPUT_UINPUT linux-yocto/5.4: update to v5.4.23 linux-yocto: drop 5.2 recipes .../linux/linux-yocto-rt_5.2.bb | 44 --------------- .../linux/linux-yocto-rt_5.4.bb | 6 +-- .../linux/linux-yocto-tiny_5.2.bb | 32 ----------- .../linux/linux-yocto-tiny_5.4.bb | 8 +-- meta/recipes-kernel/linux/linux-yocto_5.2.bb | 54 ------------------- meta/recipes-kernel/linux/linux-yocto_5.4.bb | 22 ++++---- 6 files changed, 18 insertions(+), 148 deletions(-) delete mode 100644 meta/recipes-kernel/linux/linux-yocto-rt_5.2.bb delete mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny_5.2.bb delete mode 100644 meta/recipes-kernel/linux/linux-yocto_5.2.bb -- 2.19.1 From bruce.ashfield at gmail.com Wed Mar 4 14:55:21 2020 From: bruce.ashfield at gmail.com (bruce.ashfield at gmail.com) Date: Wed, 4 Mar 2020 09:55:21 -0500 Subject: [OE-core] [PATCH 1/4] linux-yocto/5.2: backport perf build fix for latest binutils In-Reply-To: References: Message-ID: <5d990fd6d22bc9e8b5e41777aa487d13bf3122df.1583333447.git.bruce.ashfield@gmail.com> From: Bruce Ashfield [ Author: Changbin Du Date: Tue Jan 28 23:29:38 2020 +0800 perf: Make perf able to build with latest libbfd libbfd has changed the bfd_section_* macros to inline functions bfd_section_ since 2019-09-18. See below two commits: o http://www.sourceware.org/ml/gdb-cvs/2019-09/msg00064.html o https://www.sourceware.org/ml/gdb-cvs/2019-09/msg00072.html This fix make perf able to build with both old and new libbfd. Signed-off-by: Changbin Du Acked-by: Jiri Olsa Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/20200128152938.31413-1-changbin.du at gmail.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Bruce Ashfield ] Signed-off-by: Bruce Ashfield --- .../recipes-kernel/linux/linux-yocto-rt_5.2.bb | 2 +- .../linux/linux-yocto-tiny_5.2.bb | 4 ++-- meta/recipes-kernel/linux/linux-yocto_5.2.bb | 18 +++++++++--------- 3 files changed, 12 insertions(+), 12 deletions(-) diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.2.bb b/meta/recipes-kernel/linux/linux-yocto-rt_5.2.bb index 441545f55e..a23a5e6f93 100644 --- a/meta/recipes-kernel/linux/linux-yocto-rt_5.2.bb +++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.2.bb @@ -11,7 +11,7 @@ python () { raise bb.parse.SkipRecipe("Set PREFERRED_PROVIDER_virtual/kernel to linux-yocto-rt to enable it") } -SRCREV_machine ?= "b18bde6f0d8d1a5710cec9792372c03543cf0be9" +SRCREV_machine ?= "78e147f949b5b18524aa7bd72f1cc8f7ae8039f8" SRCREV_meta ?= "bb2776d6beaae64b1a0fc902b64376f082085498" SRC_URI = "git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \ diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_5.2.bb b/meta/recipes-kernel/linux/linux-yocto-tiny_5.2.bb index 6d49e00e21..ac9904f415 100644 --- a/meta/recipes-kernel/linux/linux-yocto-tiny_5.2.bb +++ b/meta/recipes-kernel/linux/linux-yocto-tiny_5.2.bb @@ -15,8 +15,8 @@ DEPENDS += "openssl-native util-linux-native" KMETA = "kernel-meta" KCONF_BSP_AUDIT_LEVEL = "2" -SRCREV_machine_qemuarm ?= "ed1c3b7ad8221ba4e20ce7e4e4f6a73afd5015d4" -SRCREV_machine ?= "c926964d00caf714f42878535af8c7374452072d" +SRCREV_machine_qemuarm ?= "e0a3a01b24070b15121e938ea19755091bf0d662" +SRCREV_machine ?= "73b12de4c879e4569bef3b2d0ee9c783a9788b27" SRCREV_meta ?= "bb2776d6beaae64b1a0fc902b64376f082085498" PV = "${LINUX_VERSION}+git${SRCPV}" diff --git a/meta/recipes-kernel/linux/linux-yocto_5.2.bb b/meta/recipes-kernel/linux/linux-yocto_5.2.bb index 44516dcacb..eab142e1c6 100644 --- a/meta/recipes-kernel/linux/linux-yocto_5.2.bb +++ b/meta/recipes-kernel/linux/linux-yocto_5.2.bb @@ -12,15 +12,15 @@ KBRANCH_qemux86 ?= "v5.2/standard/base" KBRANCH_qemux86-64 ?= "v5.2/standard/base" KBRANCH_qemumips64 ?= "v5.2/standard/mti-malta64" -SRCREV_machine_qemuarm ?= "1ed2236e622e5b79d910fc1db37ec6eec5a94fdc" -SRCREV_machine_qemuarm64 ?= "c926964d00caf714f42878535af8c7374452072d" -SRCREV_machine_qemumips ?= "e669e4307d07072458904ac0fda56f7192e2880d" -SRCREV_machine_qemuppc ?= "c926964d00caf714f42878535af8c7374452072d" -SRCREV_machine_qemuriscv64 ?= "c926964d00caf714f42878535af8c7374452072d" -SRCREV_machine_qemux86 ?= "c926964d00caf714f42878535af8c7374452072d" -SRCREV_machine_qemux86-64 ?= "c926964d00caf714f42878535af8c7374452072d" -SRCREV_machine_qemumips64 ?= "217cada95bbe7eb4c3a6d40ee141ea4cea3bc1b6" -SRCREV_machine ?= "c926964d00caf714f42878535af8c7374452072d" +SRCREV_machine_qemuarm ?= "fdb7cd1bb5e4238e5b3d120ce9db31119ec2b5ee" +SRCREV_machine_qemuarm64 ?= "73b12de4c879e4569bef3b2d0ee9c783a9788b27" +SRCREV_machine_qemumips ?= "eb7faee13cfce200e9add4ba1852a3fe5d8b92e6" +SRCREV_machine_qemuppc ?= "73b12de4c879e4569bef3b2d0ee9c783a9788b27" +SRCREV_machine_qemuriscv64 ?= "73b12de4c879e4569bef3b2d0ee9c783a9788b27" +SRCREV_machine_qemux86 ?= "73b12de4c879e4569bef3b2d0ee9c783a9788b27" +SRCREV_machine_qemux86-64 ?= "73b12de4c879e4569bef3b2d0ee9c783a9788b27" +SRCREV_machine_qemumips64 ?= "8e3bfeb7e9b5aa92c5bea941d361ff5b081a2aaa" +SRCREV_machine ?= "73b12de4c879e4569bef3b2d0ee9c783a9788b27" SRCREV_meta ?= "bb2776d6beaae64b1a0fc902b64376f082085498" # remap qemuarm to qemuarma15 for the 5.2 kernel -- 2.19.1 From bruce.ashfield at gmail.com Wed Mar 4 14:55:22 2020 From: bruce.ashfield at gmail.com (bruce.ashfield at gmail.com) Date: Wed, 4 Mar 2020 09:55:22 -0500 Subject: [OE-core] [PATCH 2/4] linux-yocto: common-pc-drivers.cfg: add CONFIG_INPUT_UINPUT In-Reply-To: References: Message-ID: <92e84d3da50438e84d3c2c6c9f33260426419e7d.1583333447.git.bruce.ashfield@gmail.com> From: Bruce Ashfield Integrating the following configuration tweak: [ Author: Alexander Kanavin Date: Mon Feb 24 10:34:00 2020 +0100 common-pc-drivers.cfg: add CONFIG_INPUT_UINPUT This will allow testing libinput in particular: https://www.kernel.org/doc/html/latest/input/uinput.html https://wayland.freedesktop.org/libinput/doc/latest/test-suite.html Signed-off-by: Alexander Kanavin Signed-off-by: Bruce Ashfield ] Signed-off-by: Bruce Ashfield --- meta/recipes-kernel/linux/linux-yocto-rt_5.4.bb | 2 +- meta/recipes-kernel/linux/linux-yocto-tiny_5.4.bb | 2 +- meta/recipes-kernel/linux/linux-yocto_5.4.bb | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.4.bb b/meta/recipes-kernel/linux/linux-yocto-rt_5.4.bb index 37282b2e05..964d2fe674 100644 --- a/meta/recipes-kernel/linux/linux-yocto-rt_5.4.bb +++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.4.bb @@ -12,7 +12,7 @@ python () { } SRCREV_machine ?= "e3a0470f1ebedce56d1c924f8ac8d3638f52304c" -SRCREV_meta ?= "c11911d4d1cf0d0b069dfd1922b41256f61442de" +SRCREV_meta ?= "13a856e7e5df0d8f951bd4060ac441cf35925c9e" SRC_URI = "git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \ git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.4;destsuffix=${KMETA}" diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_5.4.bb b/meta/recipes-kernel/linux/linux-yocto-tiny_5.4.bb index 463451fa35..47fcc98d93 100644 --- a/meta/recipes-kernel/linux/linux-yocto-tiny_5.4.bb +++ b/meta/recipes-kernel/linux/linux-yocto-tiny_5.4.bb @@ -17,7 +17,7 @@ KCONF_BSP_AUDIT_LEVEL = "2" SRCREV_machine_qemuarm ?= "f0aeaeffb8ba6d0c24f9f0212fd7a11866c918b8" SRCREV_machine ?= "f4d7dbafb103e4f782323017c239c548871c1567" -SRCREV_meta ?= "c11911d4d1cf0d0b069dfd1922b41256f61442de" +SRCREV_meta ?= "13a856e7e5df0d8f951bd4060ac441cf35925c9e" PV = "${LINUX_VERSION}+git${SRCPV}" diff --git a/meta/recipes-kernel/linux/linux-yocto_5.4.bb b/meta/recipes-kernel/linux/linux-yocto_5.4.bb index 5dd7b68063..53d5652446 100644 --- a/meta/recipes-kernel/linux/linux-yocto_5.4.bb +++ b/meta/recipes-kernel/linux/linux-yocto_5.4.bb @@ -21,7 +21,7 @@ SRCREV_machine_qemux86 ?= "f4d7dbafb103e4f782323017c239c548871c1567" SRCREV_machine_qemux86-64 ?= "f4d7dbafb103e4f782323017c239c548871c1567" SRCREV_machine_qemumips64 ?= "fcbec8b4f0f2f24a31ce5c6e6439c69f7512fb31" SRCREV_machine ?= "f4d7dbafb103e4f782323017c239c548871c1567" -SRCREV_meta ?= "c11911d4d1cf0d0b069dfd1922b41256f61442de" +SRCREV_meta ?= "13a856e7e5df0d8f951bd4060ac441cf35925c9e" # remap qemuarm to qemuarma15 for the 5.4 kernel # KMACHINE_qemuarm ?= "qemuarma15" -- 2.19.1 From bruce.ashfield at gmail.com Wed Mar 4 14:55:23 2020 From: bruce.ashfield at gmail.com (bruce.ashfield at gmail.com) Date: Wed, 4 Mar 2020 09:55:23 -0500 Subject: [OE-core] [PATCH 3/4] linux-yocto/5.4: update to v5.4.23 In-Reply-To: References: Message-ID: <8e4937eea468d286d7c8b7f98e673c442c034ad7.1583333447.git.bruce.ashfield@gmail.com> From: Bruce Ashfield Updating linux-yocto/5.4 to the latest korg -stable release that comprises the following commits: bfe3046ecafd Linux 5.4.23 bb7ffcbec227 ASoC: SOF: Intel: hda: Add iDisp4 DAI fb81480206ae bpf: Selftests build error in sockmap_basic.c 19be2b3eea34 s390/mm: Explicitly compare PAGE_DEFAULT_KEY against zero in storage_key_init_range 148c8531b69c s390/kaslr: Fix casts in get_random e26be2667399 net/mlx5e: Fix crash in recovery flow without devlink reporter fca1cdd3417e net/mlx5: Fix sleep while atomic in mlx5_eswitch_get_vepa 06320052ee69 net/mlx5e: Reset RQ doorbell counter before moving RQ state from RST to RDY 773dfd2223e3 xen: Enable interrupts when calling _cond_resched() 9724b3f28dab ata: ahci: Add shutdown to freeze hardware resources of ahci 8eb92c122840 io_uring: prevent sq_thread from spinning when it should stop b0f5f25c5541 rxrpc: Fix call RCU cleanup using non-bh-safe locks 829e0a0ae2dc netfilter: xt_hashlimit: limit the max size of hashtable 86502c68b81e ALSA: seq: Fix concurrent access to queue current tick/time 2b550d1c7ac6 ALSA: seq: Avoid concurrent access to queue flags 84e041a5df79 ALSA: rawmidi: Avoid bit fields for state flags c7deb9612e35 io_uring: fix __io_iopoll_check deadlock in io_sq_thread d562fdad84dd arm64: lse: Fix LSE atomics with LLVM 8132323eb397 bpf, offload: Replace bitwise AND by logical AND in bpf_prog_offload_info_fill 2463a30f6678 genirq/proc: Reject invalid affinity masks (again) c23074e20989 crypto: rename sm3-256 to sm3 in hash_algo_name 8278f34f6ca8 iommu/vt-d: Fix compile warning from intel-svm.h cfde4697ea4d ecryptfs: replace BUG_ON with error handling code 4c585d1e98d9 ASoC: fsl_sai: Fix exiting path on probing failure 59c723344aec ASoC: atmel: fix atmel_ssc_set_audio link failure 125b4a5345e2 staging: greybus: use after free in gb_audio_manager_remove_all() 2ca19dfafc04 staging: rtl8723bs: fix copy of overlapping memory e6535a8c5d98 usb: dwc2: Fix in ISOC request length checking ceb1997a2ec3 usb: gadget: composite: Fix bMaxPower for SuperSpeedPlus 826a43b22ce6 scsi: Revert "target: iscsi: Wait for all commands to finish before freeing a session" d92e714a463d scsi: Revert "RDMA/isert: Fix a recently introduced regression related to logout" 42b4f3c8ec0b drm/msm/dpu: fix BGR565 vs RGB565 confusion 337cbf3ea855 drm/i915/gt: Protect defer_request() from new waiters 93805d430c53 drm/bridge: tc358767: fix poll timeouts 7de50906e772 drm/i915/gvt: more locking for ppgtt mm LRU list 19f8fb273193 drm/i915/execlists: Always force a context reload when rewinding RING_TAIL 1e0175a15474 drm/i915/gt: Detect if we miss WaIdleLiteRestore 341c8e03a90a Revert "dmaengine: imx-sdma: Fix memory leak" 9ad7f8df34d2 Btrfs: fix deadlock during fast fsync when logging prealloc extents beyond eof 73e1f2663273 btrfs: don't set path->leave_spinning for truncate d3d0fb9d42d3 Btrfs: fix race between shrinking truncate and fiemap c383f8ad2a12 Btrfs: fix btrfs_wait_ordered_range() so that it waits for all ordered extents 9af8e258895f btrfs: do not check delayed items are empty for single transaction cleanup 6065ca5d013d btrfs: reset fs_root to NULL on error in open_ctree 37a2e704807a btrfs: fix bytes_may_use underflow in prealloc error condtition 40ea30638d20 btrfs: destroy qgroup extent records on transaction abort 7e946e30a46d KVM: apic: avoid calculating pending eoi from an uninitialized val dc5537061baf KVM: nVMX: handle nested posted interrupts when apicv is disabled for L1 16f8553f75b5 KVM: nVMX: clear PIN_BASED_POSTED_INTR from nested pinbased_ctls only when apicv is globally disabled 0f042f5e98f1 KVM: nVMX: Check IO instruction VM-exit conditions c4064f14f744 KVM: nVMX: Refactor IO bitmap checks into helper function e5d25003d059 ext4: fix race between writepages and enabling EXT4_EXTENTS_FL 5195dc6e9365 ext4: rename s_journal_flag_rwsem to s_writepages_rwsem 6ccdd6616a1c ext4: fix mount failure with quota configured as module eac2bb1042b2 ext4: fix potential race between s_flex_groups online resizing and access 58631f8cbc24 ext4: fix potential race between s_group_info online resizing and access bb43897de9b3 ext4: fix potential race between online resizing and write operations ded8c21ac49c ext4: add cond_resched() to __ext4_find_entry() 1673674ccd86 ext4: fix a data race in EXT4_I(inode)->i_disksize 56b3949a2b5f KVM: x86: don't notify userspace IOAPIC on edge-triggered interrupt EOI 24dfae91a23a KVM: nVMX: Don't emulate instructions in guest mode e61c236dcf34 sched/psi: Fix OOB write when writing 0 bytes to PSI files 26ae0493c181 drm/i915: Update drm/i915 bug filing URL 2104c4905a08 drm/i915: Wean off drm_pci_alloc/drm_pci_free 3e740fa80cc8 drm/nouveau/kms/gv100-: Re-set LUT after clearing for modesets 5e7dda6ddad1 drm/amdgpu/gfx10: disable gfxoff when reading rlc clock 7e482baf6d70 drm/amdgpu/gfx9: disable gfxoff when reading rlc clock f141fac489ee drm/amdgpu/soc15: fix xclk for raven 95236ae76bf8 mm: Avoid creating virtual address aliases in brk()/mmap()/mremap() 9bb971b33565 lib/stackdepot.c: fix global out-of-bounds in stack_slabs ef32399bf729 mm/sparsemem: pfn_to_page is not valid yet on SPARSEMEM 198f5aa0f73e mm/vmscan.c: don't round up scan size for online memory cgroup 8735a5b6e1fb genirq/irqdomain: Make sure all irq domain flags are distinct 6e304262e393 nvme-multipath: Fix memory leak with ana_log_buf e078c8d8971b mm/memcontrol.c: lost css_put in memcg_expand_shrinker_maps() aa4f749f8136 Revert "ipc,sem: remove uneeded sem_undo_list lock usage in exit_sem()" 7b77e5a08224 ACPI: PM: s2idle: Check fixed wakeup events in acpi_s2idle_wake() f18121a59b5a MAINTAINERS: Update drm/i915 bug filing URL cf3c30a7112c serdev: ttyport: restore client ops on deregistration 80990c30b776 tty: serial: qcom_geni_serial: Fix RX cancel command failure 5b0af5e58368 tty: serial: imx: setup the correct sg entry for tx dma 671ea19c3214 tty/serial: atmel: manage shutdown in case of RS485 or ISO7816 mode 5ae6e5683755 serial: 8250: Check UPF_IRQ_SHARED in advance e0253c422024 x86/cpu/amd: Enable the fixed Instructions Retired counter IRPERF 88e4901d3ebd x86/mce/amd: Fix kobject lifetime de2cce5ae563 x86/mce/amd: Publish the bank pointer only after setup has succeeded 6df12de90e74 x86/ima: use correct identifier for SetupMode variable 453692eb5a38 jbd2: fix ocfs2 corrupt when clearing block group bits 98583fb54c2b arm64: memory: Add missing brackets to untagged_addr() macro 9b9374cf1ea7 powerpc/hugetlb: Fix 8M hugepages on 8xx 723a44f2288e powerpc/hugetlb: Fix 512k hugepages on 8xx with 16k page size 2ffeef3db358 powerpc/entry: Fix an #if which should be an #ifdef in entry_32.S 04e3f1d1e135 powerpc/tm: Fix clearing MSR[TS] in current when reclaiming on signal delivery a03b3cea86fd powerpc/eeh: Fix deadlock handling dead PHB 9e1fab44502c powerpc/8xx: Fix clearing of bits 20-23 in ITLB miss 2558e71bbfc5 drm/panfrost: perfcnt: Reserve/use the AS attached to the perfcnt MMU context 3b8edaada13e staging: rtl8723bs: Fix potential overuse of kernel memory 4113e08e75d3 staging: rtl8723bs: Fix potential security hole de63cd8b5521 staging: rtl8188eu: Fix potential overuse of kernel memory ddedb84fcdc8 staging: rtl8188eu: Fix potential security hole 91aa9e475827 scsi: Revert "target/core: Inline transport_lun_remove_cmd()" 24aeb16934e8 usb: dwc3: debug: fix string position formatting mixup with ret and len 6dbf3ea0f566 usb: dwc3: gadget: Check for IOC/LST bit in TRB->ctrl fields 256cc85f6f86 usb: dwc2: Fix SET/CLEAR_FEATURE and GET_STATUS flows c2f07cb7e317 USB: hub: Fix the broken detection of USB3 device in SMSC hub e5d078af8e5f USB: hub: Don't record a connect-change event during reset-resume 5af8add0167c USB: Fix novation SourceControl XL after suspend b3c64c8b2fab usb: uas: fix a plug & unplug racing e805982b13e3 USB: quirks: blacklist duplicate ep on Sound Devices USBPre2 4c02497e8f65 USB: core: add endpoint-blacklist quirk f9965af8e493 usb: host: xhci: update event ring dequeue pointer on purpose 5d0faf16f960 xhci: Fix memory leak when caching protocol extended capability PSI tables - take 2 ef69cf19bda8 xhci: apply XHCI_PME_STUCK_QUIRK to Intel Comet Lake platforms 02e326360053 xhci: fix runtime pm enabling for quirky Intel hosts 512dae7753cd xhci: Force Maximum Packet size for Full-speed bulk devices to valid range. 22ff13ac65cb staging: vt6656: fix sign of rx_dbm to bb_pre_ed_rssi. 41a53f5b68ec staging: android: ashmem: Disallow ashmem memory from being remapped 897d5aaf3397 vt: vt_ioctl: fix race in VT_RESIZEX 21275a431289 vt: selection, handle pending signals in paste_selection a2c3858faf3a vt: fix scrollback flushing on background consoles 1eb78bc92c84 floppy: check FDC index for errors before assigning it c5455e3fab20 e1000e: Use rtnl_lock to prevent race conditions between net and pci/pm 47a7a44650c1 USB: misc: iowarrior: add support for the 100 device 9b5e87086fa9 USB: misc: iowarrior: add support for the 28 and 28L devices c8e28d325c97 USB: misc: iowarrior: add support for 2 OEMed devices cfda8551dd59 thunderbolt: Prevent crash if non-active NVMem file is read 802a8369d21f btrfs: handle logged extent failure properly 3c4ef8ac8f4b ecryptfs: fix a memory leak bug in ecryptfs_init_messaging() 7e1dbc6656ff ecryptfs: fix a memory leak bug in parse_tag_1_packet() 909149bf61da tpm: Initialize crypto_id of allocated_banks to HASH_ALGO__LAST 9f83363875be ASoC: sun8i-codec: Fix setting DAI data format 3de0bbe21312 ASoC: codec2codec: avoid invalid/double-free of pcm runtime c45877ca9f62 ALSA: hda/realtek - Apply quirk for yet another MSI laptop 9dc3b7a5833a ALSA: hda/realtek - Apply quirk for MSI GP63, too 80c1e9c4c484 ALSA: hda: Use scnprintf() for printing texts for sysfs/procfs b76e00b67dc6 iommu/qcom: Fix bogus detach logic f22dcb31727e Linux 5.4.22 105542cea2ea rtc: Kconfig: select REGMAP_I2C when necessary cea9007ebb95 bcache: properly initialize 'path' and 'err' in register_bcache() 7967c3299e3f drm/amdgpu/display: handle multiple numbers of fclks in dcn_calcs.c (v2) 51c9c98a7bbe s390/pci: Recover handle in clp_set_pci_fn() 332c8b5bc358 mlxsw: spectrum_dpipe: Add missing error path 399ca7ee9130 fuse: don't overflow LLONG_MAX with end offset 77912b69a989 virtio_balloon: prevent pfn array overflow 9c80ae965082 cifs: log warning message (once) if out of disk space 3f14879fd6ce i40e: Relax i40e_xsk_wakeup's return value when PF is busy 6fa2bb0d06ca help_next should increase position index 6b851823ceaa NFS: Fix memory leaks 0562d37d143a drm/amdgpu/smu10: fix smu10_get_clock_by_type_with_voltage c3e3d17d0c5b drm/amdgpu/smu10: fix smu10_get_clock_by_type_with_latency 17bddc85f980 brd: check and limit max_part par 7291351c00e1 microblaze: Prevent the overflow of the start 7ceb32672b1e asm-generic/tlb: add missing CONFIG symbol 7a48064a42e0 iwlwifi: mvm: Check the sta is not NULL in iwl_mvm_cfg_he_sta() 1656781d15c0 iwlwifi: mvm: Fix thermal zone registration 0448387729d9 nvme-pci: remove nvmeq->tags 1d0fbf3e2687 nvmet: Pass lockdep expression to RCU lists d5461fdd9645 irqchip/gic-v3-its: Reference to its_invall_cmd descriptor when building INVALL 793137b0511c bcache: fix incorrect data type usage in btree_flush_write() 57a180a630d8 bcache: explicity type cast in bset_bkey_last() 374eec821858 bcache: fix memory corruption in bch_cache_accounting_clear() dc8c75f35374 reiserfs: prevent NULL pointer dereference in reiserfs_insert_item() 23b88b51de5c lib/scatterlist.c: adjust indentation in __sg_alloc_table 5a553bd43f59 ocfs2: fix a NULL pointer dereference when call ocfs2_update_inode_fsync_trans() 799c4c1e389f ocfs2: make local header paths relative to C files 7a97311de48d btrfs: do not do delalloc reservation under page lock a531e6ba85a0 powerpc: Do not consider weak unresolved symbol relocations as bad 528c36e14b17 radeon: insert 10ms sleep in dce5_crtc_load_lut 224c0751dfb7 trigger_next should increase position index e349287276c2 ftrace: fpid_next() should increase position index 8a7bfa3d97dc char: hpet: Fix out-of-bounds read bug 427f39e23326 drm/nouveau/disp/nv50-: prevent oops when no channel method map provided 39c6932240c5 irqchip/gic-v3: Only provision redistributors that are enabled in ACPI 074c4c43fce2 drm/amd/display: do not allocate display_mode_lib unnecessarily 1687b204ae83 rbd: work around -Wuninitialized warning bd4e1894166b ceph: check availability of mds cluster on mount after wait timeout 7288d5338c85 powerpc/mm: Don't log user reads to 0xffffffff 3ce3df5d00d0 bpf: map_seq_next should always increase position index 9a178494d05b cifs: fix NULL dereference in match_prepath 9c5ede115a6e cifs: Fix mount options set in automount 1d8e40cf86e4 cifs: fix unitialized variable poential problem with network I/O cache lock patch a2763f62baa4 iwlegacy: ensure loop counter addr does not wrap and cause an infinite loop 034c5f26d2bf rtw88: fix potential NULL skb access in TX ISR e7e4d0eaa639 hostap: Adjust indentation in prism2_hostapd_add_sta 32662df2d0bc ALSA: usb-audio: add quirks for Line6 Helix devices fw>=2.82 2ccaac382af0 ARM: 8951/1: Fix Kexec compilation issue. 16ec28640dc6 selftests/eeh: Bump EEH wait time to 60s 93df1b23b157 powerpc/pseries/lparcfg: Fix display of Maximum Memory 411327180703 jbd2: make sure ESHUTDOWN to be recorded in the journal superblock 314e25f4b0cf jbd2: switch to use jbd2_journal_abort() when failed to submit the commit record b911c5e8686a selftests: bpf: Reset global state between reuseport test runs 251c53a92b54 alarmtimer: Make alarmtimer platform device child of RTC device 777baa1baf63 iommu/vt-d: Remove unnecessary WARN_ON_ONCE() b5f6bf0fdd71 bcache: fix use-after-free in register_bcache() 393b8509be33 bcache: rework error unwinding in register_bcache f7d8ebf26d23 bcache: cached_dev_free needs to put the sb page 714cd4a5127a btrfs: Fix split-brain handling when changing FSID to metadata uuid dc22bc8a8626 btrfs: separate definition of assertion failure handlers 3420f1b304b3 media: uvcvideo: Add a quirk to force GEO GC6500 Camera bits-per-pixel value 3f6c8de753ed powerpc/sriov: Remove VF eeh_dev state when disabling SR-IOV 9d5fc7f14ef2 drm/nouveau/mmu: fix comptag memory leak 707518c16ba4 sunrpc: Fix potential leaks in sunrpc_cache_unhash() 46503858e275 ALSA: hda - Add docking station support for Lenovo Thinkpad T420s ea038a5270b5 bpf, btf: Always output invariant hit in pahole DWARF to BTF transform f11aefc9961d driver core: platform: fix u32 greater or equal to zero comparison 843eb0a8cf53 s390/ftrace: generate traced function stack frame 68c3cc414e08 s390: adjust -mpacked-stack support check for clang 10 838bddc295a0 x86/decoder: Add TEST opcode to Group3-2 a4f6948e57f0 objtool: Fix ARCH=x86_64 build error 59e2355bdfc5 kbuild: use -S instead of -E for precise cc-option test in Kconfig ba6ad897c3dc spi: spi-fsl-qspi: Ensure width is respected in spi-mem operations dbdc1c12966e ALSA: hda/hdmi - add retry logic to parse_intel_hdmi() fa7d320dbbbe irqchip/mbigen: Set driver .suppress_bind_attrs to avoid remove problems 27f3dc35fd59 regulator: core: Fix exported symbols to the exported GPL version 18eca3cb5dd9 remoteproc: Initialize rproc_class before use 496d6c021828 module: avoid setting info->name early in case we can fall back to info->mod->name 7303a0b0a537 btrfs: device stats, log when stats are zeroed f9ab58f9a2ab btrfs: safely advance counter when looking up bio csums ebf8e5411888 btrfs: fix possible NULL-pointer dereference in integrity checks 50b93369668b pwm: Remove set but not set variable 'pwm' adf4ab6d8312 ide: serverworks: potential overflow in svwks_set_pio_mode() e5c8d3abd927 cmd64x: potential buffer overflow in cmd64x_program_timings() 419035d75dbe pwm: omap-dmtimer: Remove PWM chip in .remove before making it unfunctional e7e6b53fea10 x86/mm: Fix NX bit clearing issue in kernel_map_pages_in_pgd 225a5b5bee00 f2fs: fix memleak of kobject 337c7b95e16e regulator: vctrl-regulator: Avoid deadlock getting and setting the voltage bf754c88865d ASoC: SOF: Intel: hda: Fix SKL dai count 84255fe86d07 debugobjects: Fix various data races 0b2ecef39d8e watchdog/softlockup: Enforce that timestamp is valid on boot d8a6a443ff0a perf/x86/amd: Constrain Large Increment per Cycle events f2323c374e49 sched/topology: Assert non-NUMA topology masks don't (partially) overlap 5d13f62b9ef6 sched/core: Fix size of rq::uclamp initialization 8da6ae7dcb16 arm64: dts: ti: k3-j721e-main: Add missing power-domains for smmu 88cf251d3c0d KVM: PPC: Remove set but not used variable 'ra', 'rs', 'rt' d4870a4343f3 EDAC/sifive: Fix return value check in ecc_register() 0a8f90d5654d drm/amd/display: fixup DML dependencies 304982d21e2b arm64: fix alternatives with LLVM's integrated assembler f68668292496 arm64: lse: fix LSE atomics with LLVM's integrated assembler b04235f1e11d RDMA/mlx5: Don't fake udata for kernel path da2d50868e59 ALSA: usb-audio: add implicit fb quirk for MOTU M Series 5a6f5b327fce crypto: essiv - fix AEAD capitalization and preposition use in help text 817faa4ed433 scsi: iscsi: Don't destroy session if there are outstanding connections 12b685be50c7 scsi: ufs-mediatek: add apply_dev_quirks variant operation 4fa2dd4eebfd scsi: ufs: pass device information to apply_dev_quirks 0016939be0ee f2fs: free sysfs kobject 06c34c604b13 f2fs: set I_LINKABLE early to avoid wrong access by vfs f51caa62dea1 ALSA: usb-audio: unlock on error in probe 480494e28a51 iommu/arm-smmu-v3: Use WRITE_ONCE() when changing validity of an STE 23d3f191a576 kbuild: remove *.tmp file when filechk fails 1fc9746acbb2 usb: musb: omap2430: Get rid of musb .set_vbus for omap2430 glue 9112d1ef5a1b perf/imx_ddr: Fix cpu hotplug state cleanup 994b203b619d drm/vmwgfx: prevent memory leak in vmw_cmdbuf_res_add 13d368cd1e13 gpiolib: Set lockdep class for hierarchical irq domains 7f0d9ac2621e dm thin: don't allow changing data device during thin-pool reload 74f42a77318e drm/nouveau/fault/gv100-: fix memory leak on module unload 18792937b064 drm/nouveau/drm/ttm: Remove set but not used variable 'mem' a94c84c5c4bc drm/nouveau: Fix copy-paste error in nouveau_fence_wait_uevent_handler 93672fa5b9b3 drm/nouveau/gr/gk20a,gm200-: add terminators to method lists read from fw 63e00e2c80e5 drm/nouveau/secboot/gm20b: initialize pointer in gm20b_secboot_new() 760baae7ab35 vme: bridges: reduce stack usage 76fac0e735c7 bpf: Return -EBADRQC for invalid map type in __bpf_tx_xdp_map be1113b4b415 ASoC: SOF: Intel: hda-dai: fix compilation warning in pcm_prepare a8b37e32415e driver core: Print device when resources present in really_probe() 3f6af05d1d1b driver core: platform: Prevent resouce overflow from causing infinite loops 11c759264c32 visorbus: fix uninitialized variable access 83f964dd14a7 misc: xilinx_sdfec: fix xsdfec_poll()'s return type 9087af8639c2 tty: synclink_gt: Adjust indentation in several functions 71faeca11055 tty: synclinkmp: Adjust indentation in several functions a922fa72a860 raid6/test: fix a compilation warning 6cfe307b5be7 ASoC: atmel: fix build error with CONFIG_SND_ATMEL_SOC_DMA=m 5bff3c470f84 ALSA: usb-audio: Add boot quirk for MOTU M Series d691d1e5836d ARM: dts: rockchip: add reg property to brcmf sub node for rk3188-bqedison2qc 7c32c479b1e0 arm64: dts: rockchip: add reg property to brcmf sub-nodes f9de6fb6e679 arm64: dts: rockchip: fix dwmmc clock name for px30 989a495ed9a3 clocksource: davinci: only enable clockevents once tim34 is initialized 48be6f9d2f7e wan: ixp4xx_hss: fix compile-testing on 64-bit 73f48c1004d4 x86/nmi: Remove irq_work from the long duration NMI handler b075c29e816c bnxt: Detach page from page pool before sending up the stack 1e703d621b9c Input: edt-ft5x06 - work around first register access error 2b1fd461067f rcu: Use WRITE_ONCE() for assignments to ->pprev for hlist_nulls 5f0a4eba2a88 efi/x86: Don't panic or BUG() on non-critical error conditions 5cf01eacd5c2 soc/tegra: fuse: Correct straps' address for older Tegra124 device trees 75d916c3b393 IB/hfi1: Add RcvShortLengthErrCnt to hfi1stats 9cfe6c21ff17 IB/hfi1: Add software counter for ctxt0 seq drop 8689967be56d staging: rtl8188: avoid excessive stack usage bfe29951e250 drm/mediatek: Add gamma property according to hardware capability 6ceef50235d1 udf: Fix free space reporting for metadata and virtual partitions 03560e4a19fe usbip: Fix unsafe unaligned pointer usage e653e1c05423 ARM: dts: stm32: Add power-supply for DSI panel on stm32f469-disco 6e86c4ce5d3a usb: dwc3: use proper initializers for property entries ab7edf7fa651 drm: remove the newline for CRC source name. 9d89ff3d27e0 RDMA/hns: Avoid printing address of mtt page 5a2a529974e1 mlx5: work around high stack usage with gcc 010cdc1be053 drm/amdkfd: Fix permissions of hang_hws 960671ac5065 iommu/vt-d: Avoid sending invalid page response 2aab9e9d1f3d iommu/vt-d: Match CPU and IOMMU paging mode 4ffdfc414d81 ACPI: button: Add DMI quirk for Razer Blade Stealth 13 late 2019 lid switch e9e24f2ca9a6 ASoC: Intel: sof_rt5682: Ignore the speaker amp when there isn't one. d00a15040454 vfio/spapr/nvlink2: Skip unpinning pages on error exit e44b48f5bb64 tools lib api fs: Fix gcc9 stringop-truncation compilation error 3e32b1282b11 net: phy: fixed_phy: fix use-after-free when checking link GPIO 4070a491bfcf ALSA: sh: Fix compile warning wrt const cf24ed82438c ALSA: hda/realtek - Apply mic mute LED quirk for Dell E7xx laptops, too 2417ea1d07a5 clk: uniphier: Add SCSSI clock gate for each channel 6447bfe82922 clk: Use parent node pointer during registration if necessary 6c7984312d35 ALSA: sh: Fix unused variable warnings 9f87fff25159 clk: sunxi-ng: add mux and pll notifiers for A64 CPU clock d1d92e97260f RDMA/rxe: Fix error type of mmap_offset c87c4d442b9f fbdev: fix numbering of fbcon options 67ca691658f5 ASoC: soc-topology: fix endianness issues 04361b8961d6 reset: uniphier: Add SCSSI reset control for each channel e39aac0e65f1 pinctrl: sh-pfc: sh7269: Fix CAN function GPIOs 9ed73297980b drm/fbdev: Fallback to non tiled mode if all tiles not present d3db7b78e7d6 PM / devfreq: rk3399_dmc: Add COMPILE_TEST and HAVE_ARM_SMCCC dependency 704582e6a714 PM / devfreq: exynos-ppmu: Fix excessive stack usage bc866376d7cd x86/vdso: Provide missing include file b5fe09b676de crypto: chtls - Fixed memory leak a739564c4c53 net: phy: realtek: add logging for the RGMII TX delay configuration 4783bf08f8d2 bpf: Print error message for bpftool cgroup show 8a7aa4feeaea dmaengine: imx-sdma: Fix memory leak f99958a96c7f dmaengine: Store module owner in dma_device struct 93a3eff6fab3 clk: actually call the clock init before any other callback of the clock fa0150ba88fa iommu/iova: Silence warnings under memory pressure 8c358435459b iommu/amd: Only support x2APIC with IVHD type 11h/40h b1b7add9d2de iommu/amd: Check feature support bit before accessing MSI capability registers 0c09d9dc8440 arm64: dts: qcom: db845c: Enable ath10k 8bit host-cap quirk ce591c921944 scsi: lpfc: Fix: Rework setting of fdmi symbolic node name registration 111749fba968 selinux: ensure we cleanup the internal AVC counters on error in avc_update() 069d2385f381 ARM: dts: r8a7779: Add device node for ARM global timer f9b42cb09d8b clk: renesas: rcar-gen3: Allow changing the RPC[D2] clocks d80f9dfe47ce drm/mediatek: handle events when enabling/disabling crtc 57cd234da28c crypto: inside-secure - add unspecified HAS_IOMEM dependency df0f4455a12f scsi: aic7xxx: Adjust indentation in ahc_find_syncrate f6ebbf46c3a8 scsi: ufs: Complete pending requests in host reset and restore path 8728001e1e41 nfsd: Clone should commit src file metadata too d67d31cb0e92 ACPICA: Disassembler: create buffer fields in ACPI_PARSE_LOAD_PASS1 3fa5ba7b1912 clk: qcom: smd: Add missing bimc clock 43ef7ad610dc drm/amdgpu: fix KIQ ring test fail in TDR of SRIOV 75423fdad259 orinoco: avoid assertion in case of NULL pointer 5a14db967b72 rtlwifi: rtl_pci: Fix -Wcast-function-type f20bc906af52 iwlegacy: Fix -Wcast-function-type 3acea3092a33 ipw2x00: Fix -Wcast-function-type bc8746721cdf b43legacy: Fix -Wcast-function-type 90053ff023da PCI: Add DMA alias quirk for PLX PEX NTB 27a35f09367f PCI: Add nr_devfns parameter to pci_add_dma_alias() dd77f77004b6 ALSA: usx2y: Adjust indentation in snd_usX2Y_hwdep_dsp_status b6c857e5e500 netfilter: nft_tunnel: add the missing ERSPAN_VERSION nla_policy 1e2b6e5f32aa fore200e: Fix incorrect checks of NULL pointer dereference 58bc57b373e0 r8169: check that Realtek PHY driver module is loaded cdd5b09bcbc0 samples/bpf: Set -fno-stack-protector when building BPF programs af77e76625be reiserfs: Fix spurious unlock in reiserfs_fill_super() error handling 6107a895e383 media: v4l2-device.h: Explicitly compare grp{id,mask} to zero in v4l2_device macros cf03458ab2cf selftests/net: make so_txtime more robust to timer variance 687ef9c269b6 gpu/drm: ingenic: Avoid null pointer deference in plane atomic update e07c107a2483 Revert "nfp: abm: fix memory leak in nfp_abm_u32_knode_replace" 6a05af0b718a PCI: Increase D3 delay for AMD Ryzen5/7 XHCI controllers 5700b8073f03 PCI: Add generic quirk for increasing D3hot delay 1e7b1684de37 media: cx23885: Add support for AVerMedia CE310B a3a7f90936d7 PCI: iproc: Apply quirk_paxc_bridge() for module as well as built-in 76ce0e269b4a bus: ti-sysc: Implement quirk handling for CLKDM_NOAUTO 2fc336213605 ARM: dts: imx6: rdu2: Limit USBH1 to Full Speed f3e63a4ddf19 ARM: dts: imx6: rdu2: Disable WP for USDHC2 and USDHC3 dbe3806c7191 ARM: exynos_defconfig: Bring back explicitly wanted options 4ece124849a2 clk: imx: Add correct failure handling for clk based helpers 0685dfa0a2ff padata: validate cpumask without removed CPU during offline c3a007435359 arm64: dts: qcom: msm8996: Disable USB2 PHY suspend by core 0e44cd879ba1 selinux: ensure we cleanup the internal AVC counters on error in avc_insert() 5fed8c513adb opp: Free static OPPs on errors while adding them ef6b35dfe142 arm: dts: allwinner: H3: Add PMU node 5a241d7bf1e6 arm64: dts: allwinner: H5: Add PMU node 02dfae36b03f arm64: dts: allwinner: H6: Add PMU mode 5f0a50b0a37d NFC: port100: Convert cpu_to_le16(le16_to_cpu(E1) + E2) to use le16_add_cpu(). 53d9b08dc80d net/wan/fsl_ucc_hdlc: reject muram offsets above 64K 12ba455b1d28 regulator: rk808: Lower log level on optional GPIOs being not available bae02d239a38 ASoC: intel: sof_rt5682: Add support for tgl-max98357a-rt5682 fa54ae038c95 ASoC: intel: sof_rt5682: Add quirk for number of HDMI DAI's 4c50665fc968 modules: lockdep: Suppress suspicious RCU usage warning fa0316aaf094 arm64: dts: rockchip: Fix NanoPC-T4 cooling maps 3a28e0701264 drm/panel: simple: Add Logic PD Type 28 display support c3c3f3449b8c drm/amdgpu: Ensure ret is always initialized when using SOC15_WAIT_ON_RREG ddbdf757a7ef ath10k: correct the tlv len of ath10k_wmi_tlv_op_gen_config_pno_start 69c12b79e9e2 drm/amdgpu: remove 4 set but not used variable in amdgpu_atombios_get_connector_info_from_object_table ad9728b377a6 bpf, sockhash: Synchronize_rcu before free'ing map 25c85d8574d8 drm/amdkfd: Fix a bug in SDMA RLC queue counting under HWS mode dff5d0fc77a5 clk: qcom: rcg2: Don't crash if our parent can't be found; return an error 8d122cd0d266 clk: qcom: Don't overwrite 'cfg' in clk_rcg2_dfs_populate_freq() 8ba34cdadba3 kconfig: fix broken dependency in randconfig-generated .config 39a708219509 block, bfq: do not plug I/O for bfq_queues with no proc refs b0d5c881d36e drivers/block/zram/zram_drv.c: fix error return codes not being returned in writeback_store 53aaa9f1a638 Btrfs: keep pages dirty when using btrfs_writepage_fixup_worker 3aa694d0e112 KVM: s390: ENOTSUPP -> EOPNOTSUPP fixups 25cbba5d4e14 nbd: add a flush_workqueue in nbd_start_device 201fdd62bb23 tracing: Simplify assignment parsing for hist triggers 7bc84d854017 drm/amd/display: Retrain dongles when SINK_COUNT becomes non-zero 806f57ec2b52 rtc: i2c/spi: Avoid inclusion of REGMAP support when not needed b752d473b1fb selftests: settings: tests can be in subsubdirs 6f65dd66ea6f brcmfmac: sdio: Fix OOB interrupt initialization on brcm43362 abf8d588e3b1 rtw88: fix rate mask for 1SS chip 3eee03d0ffb8 ath10k: Correct the DMA direction for management tx buffers 494c30b80550 ext4, jbd2: ensure panic when aborting with zero errno 8343f165f3d4 ARM: 8952/1: Disable kmemleak on XIP kernels 8c72748e9f6a tracing: Fix very unlikely race of registering two stat tracers 75225eee8715 tracing: Fix tracing_stat return values in error handling paths 8be3ac46ef80 powerpc/iov: Move VF pdev fixup into pcibios_fixup_iov() 256e52a1a915 s390/pci: Fix possible deadlock in recover_store() 37ea6d15b197 wan/hdlc_x25: fix skb handling 77b131f652d4 dmaengine: fsl-qdma: fix duplicated argument to && d30a4882e630 udf: Allow writing to 'Rewritable' partitions a3536e5589c7 pwm: omap-dmtimer: Simplify error handling 971579fae1b4 x86/sysfb: Fix check for bad VRAM size 7828a927b850 clk: ti: dra7: fix parent for gmac_clkctrl 2d7fa7564bc4 ext4: fix deadlock allocating bio_post_read_ctx from mempool c982320078dd jbd2: clear JBD2_ABORT flag before journal_reset to update log tail info when load journal 56953ccd7f00 kselftest: Minimise dependency of get_size on C library interfaces 6aa96ec9c196 drm/amd/display: Clear state after exiting fixed active VRR state c7fc72092134 clocksource/drivers/bcm2835_timer: Fix memory leak of timer 9f0414eed212 usb: dwc2: Fix IN FIFO allocation 2cea5895b69d usb: gadget: udc: fix possible sleep-in-atomic-context bugs in gr_probe() 531d0ac5fbbd drm/nouveau/nouveau: fix incorrect sizeof on args.src an args.dst d34ecf4949de spi: fsl-lpspi: fix only one cs-gpio working 9f3a2e147f0e drm/amdgpu/sriov: workaround on rev_id for Navi12 under sriov 750a95d63746 uio: fix a sleep-in-atomic-context bug in uio_dmem_genirq_irqcontrol() b2f28d11f2a1 raid6/test: fix a compilation error 448563605d98 net: ethernet: ixp4xx: Standard module init b5d649f14470 sparc: Add .exit.data section. c09d0bd924ac MIPS: Loongson: Fix potential NULL dereference in loongson3_platform_init() ed140997f80c efi/x86: Map the entire EFI vendor string before copying it 04a5bebd7789 pinctrl: baytrail: Do not clear IRQ flags on direct-irq enabled pins 9ad79d4fa032 IB/core: Let IB core distribute cache update events f606721660a6 kernel/module: Fix memleak in module_add_modinfo_attrs() fc3c0fc85d69 media: sti: bdisp: fix a possible sleep-in-atomic-context bug in bdisp_device_run() bc4730880281 char/random: silence a lockdep splat with printk() 0b455673e7c4 x86/fpu: Deactivate FPU state after failure during state load 9b743915bd00 iommu/vt-d: Fix off-by-one in PASID allocation 739abce96dd0 gpio: gpio-grgpio: fix possible sleep-in-atomic-context bugs in grgpio_irq_map/unmap() e715aa99c502 clk: meson: meson8b: make the CCF use the glitch-free mali mux 271b18405eb0 powerpc/powernv/iov: Ensure the pdn for VFs always contains a valid PE number 2f812301bacf clk: at91: sam9x60: fix programmable clock prescaler e1e1cdbc646f media: sun4i-csi: Fix [HV]sync polarity handling 65fbde986aef media: sun4i-csi: Fix data sampling polarity handling f5076ea1bc9d media: sun4i-csi: Deal with DRAM offset cb514c01f6e4 media: i2c: mt9v032: fix enum mbus codes and frame sizes ecb8ea6f93e5 media: ov5640: Fix check for PLL1 exceeding max allowed rate 9c76a7b28edc pxa168fb: Fix the function used to release some memory in an error handling path 4a8bb7ce9f0b drm/msm/adreno: fix zap vs no-zap handling 4aa148666a70 drm/mipi_dbi: Fix off-by-one bugs in mipi_dbi_blank() d21cc4ea7a82 printk: fix exclusive_console replaying f46afae807aa pinctrl: sh-pfc: sh7264: Fix CAN function GPIOs fcc0000109b0 gianfar: Fix TX timestamping with a stacked DSA driver c324effa6d9d ALSA: ctl: allow TLV read operation for callback type of element in locked case 4125714ce1d6 ext4: fix ext4_dax_read/write inode locking sequence for IOCB_NOWAIT 348a7ccdb9f0 leds: pca963x: Fix open-drain initialization 4e2d5e3eb865 drm/amd/display: Map ODM memory correctly when doing ODM combine b3224bf30709 PCI: Fix pci_add_dma_alias() bitmask size 071963d37143 brcmfmac: Fix use after free in brcmf_sdio_readframes() 55195593a8c6 brcmfmac: Fix memory leak in brcmf_p2p_create_p2pdev() c4d0a90b5029 cpu/hotplug, stop_machine: Fix stop_machine vs hotplug order 4d7f8ca608b2 clk: meson: pll: Fix by 0 division in __pll_params_to_rate() 343fc9a26887 media: meson: add missing allocation failure check on new_buf 85275286d118 f2fs: call f2fs_balance_fs outside of locked page 678b25bfd983 f2fs: preallocate DIO blocks when forcing buffered_io 255edefeb0b8 rcu: Fix data-race due to atomic_t copy-by-value b7725deb9d61 rcu: Fix missed wakeup of exp_wq waiters 3ece067c12e1 rcu/nocb: Fix dump_tree hierarchy print always active 2339f7a55c84 drm/qxl: Complete exception handling in qxl_device_init() 3deb6e993ec4 wil6210: fix break that is never reached because of zero'ing of a retry counter 281ebbcdee49 ath10k: Fix qmi init error handling 726196728c2c drm/gma500: Fixup fbdev stolen size usage evaluation 60e055d59d0e net/sched: flower: add missing validation of TCA_FLOWER_FLAGS 58cd462bc5b1 net/sched: matchall: add missing validation of TCA_MATCHALL_FLAGS d9bc012b4a47 net: dsa: tag_qca: Make sure there is headroom for tag 42dd56266b9f net/smc: fix leak of kernel memory to user space f1f2eea30d19 enic: prevent waking up stopped tx queues over watchdog reset 8f22873582a7 core: Don't skip generic XDP program execution for cloned SKBs 2d636a1263be Linux 5.4.21 c10cfc131c0b mmc: core: Rework wp-gpio handling b0ad23142a2a gpio: add gpiod_toggle_active_low() 2cbbe28c734b KVM: x86/mmu: Fix struct guest_walker arrays for 5-level paging ac3aea49cc35 ext4: choose hardlimit when softlimit is larger than hardlimit in ext4_statfs_project() 9275ae515385 jbd2: do not clear the BH_Mapped flag when forgetting a metadata buffer f09998f7a11f jbd2: move the clearing of b_modified flag to the journal_unmap_buffer() 0e365eafbcaa Revert "drm/sun4i: drv: Allow framebuffer modifiers in mode config" 590d35beddcc NFSv4.1 make cachethis=no for writes 7bee7eabf0ed perf stat: Don't report a null stalled cycles per insn metric 1164c3380958 KVM: x86: Mask off reserved bit from #DB exception payload ec86856b4672 arm64: dts: fast models: Fix FVP PCI interrupt-map property 51a610a5c88d cifs: fix mount option display for sec=krb5i db5a68ffad2a mac80211: fix quiet mode activation in action frames 671338889e8f hwmon: (pmbus/ltc2978) Fix PMBus polling of MFR_COMMON definitions. 98509dfe6f25 perf/x86/intel: Fix inaccurate period in context switch for auto-reload 1d2a31baf6b6 spmi: pmic-arb: Set lockdep class for hierarchical irq domains 9f6f61c61a84 sched/uclamp: Reject negative values in cpu_uclamp_write() 115402ee80ce s390/time: Fix clk type in get_tod_clock ae88de70c254 RDMA/core: Fix protection fault in get_pkey_idx_qp_list 2c753af06f23 RDMA/rxe: Fix soft lockup problem due to using tasklets in softirq 8662e612ae4c RDMA/hfi1: Fix memory leak in _dev_comp_vect_mappings_create b860a4524217 RDMA/iw_cxgb4: initiate CLOSE when entering TERM c60c4b4b6bf2 RDMA/core: Fix invalid memory access in spec_filter_size 8a14f01c4d0f IB/umad: Fix kernel crash while unloading ib_umad 6603342a6060 IB/rdmavt: Reset all QPs when the device is shut down b16dfda32ca5 IB/hfi1: Close window for pq and request coliding 327f33e54c7f IB/hfi1: Acquire lock to release TID entries when user file is closed e30e30c042fe IB/mlx5: Return failure when rts2rts_qp_counters_set_id is not supported cf0ea974b6a2 drivers: ipmi: fix off-by-one bounds check that leads to a out-of-bounds write 5e9f573dc8e7 nvme: fix the parameter order for nvme_get_log in nvme_get_fw_slot_info fa3c053b8313 bus: moxtet: fix potential stack buffer overflow 279c15b917ec drm/panfrost: Make sure the shrinker does not reclaim referenced BOs 3ea7f138cec1 drm/vgem: Close use-after-free race in vgem_gem_create 9ea66515918e s390/uv: Fix handling of length extensions 9e6874da9446 s390/pkey: fix missing length of protected key on return ebc3ddc1a255 perf/x86/amd: Add missing L2 misses event spec to AMD Family 17h's event map db6f68908bce KVM: nVMX: Use correct root level for nested EPT shadow page tables ce8b9b8032bd EDAC/mc: Fix use-after-free and memleaks during device removal b2e977a9731f EDAC/sysfs: Remove csrow objects on errors 03f6c2bf9562 cifs: make sure we do not overflow the max EA buffer size ff04f342f8c4 xprtrdma: Fix DMA scatter-gather list mapping imbalance 22f15745c4e7 arm64: ssbs: Fix context-switch when SSBS is present on all CPUs 4267ba3bac6d gpio: xilinx: Fix bug where the wrong GPIO register is written to 8791bb8f8471 ARM: npcm: Bring back GPIOLIB support cafaf6bcce60 btrfs: log message when rw remount is attempted with unclean tree-log 2655c88c03e8 btrfs: print message when tree-log replay starts f3cdf024ed19 btrfs: ref-verify: fix memory leaks bf4a9715a914 Btrfs: fix race between using extent maps and merging them c43f560acc85 ext4: improve explanation of a mount failure caused by a misconfigured kernel 94f0fe04da78 ext4: add cond_resched() to ext4_protect_reserved_inode 5b0a26514d6c ext4: fix checksum errors with indexed dirs 449e607322d7 ext4: fix support for inode sizes > 1024 bytes f080204b677d ext4: don't assume that mmp_nodename/bdevname have NUL 86c30da1b684 ALSA: usb-audio: Add clock validity quirk for Denon MC7000/MCX8000 67d49871f8e4 ALSA: usb-audio: sound: usb: usb true/false for bool return type c3b35c87e5b6 ACPI: PM: s2idle: Prevent spurious SCIs from waking up the system 303740645567 ACPICA: Introduce acpi_any_gpe_status_set() 0671627a5faa ACPI: PM: s2idle: Avoid possible race related to the EC GPE b9f78af90d92 ACPI: EC: Fix flushing of pending work 25487999ca3a ALSA: usb-audio: Apply sample rate quirk for Audioengine D1 2b7e7004970a ALSA: hda/realtek - Fix silent output on MSI-GL73 1e73c5eae8c6 ALSA: hda/realtek - Add more codec supported Headset Button c28273b42c95 ALSA: usb-audio: Fix UAC2/3 effect unit parsing 2323beb68436 Input: synaptics - remove the LEN0049 dmi id from topbuttonpad list efca0d73501a Input: synaptics - enable SMBus on ThinkPad L470 c6426ba5731b Input: synaptics - switch T470s to RMI4 by default Signed-off-by: Bruce Ashfield --- .../linux/linux-yocto-rt_5.4.bb | 6 ++--- .../linux/linux-yocto-tiny_5.4.bb | 8 +++---- meta/recipes-kernel/linux/linux-yocto_5.4.bb | 22 +++++++++---------- 3 files changed, 18 insertions(+), 18 deletions(-) diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.4.bb b/meta/recipes-kernel/linux/linux-yocto-rt_5.4.bb index 964d2fe674..1c238c9b88 100644 --- a/meta/recipes-kernel/linux/linux-yocto-rt_5.4.bb +++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.4.bb @@ -11,13 +11,13 @@ python () { raise bb.parse.SkipRecipe("Set PREFERRED_PROVIDER_virtual/kernel to linux-yocto-rt to enable it") } -SRCREV_machine ?= "e3a0470f1ebedce56d1c924f8ac8d3638f52304c" -SRCREV_meta ?= "13a856e7e5df0d8f951bd4060ac441cf35925c9e" +SRCREV_machine ?= "f617c0993374d56792e266e37606d424166b1edd" +SRCREV_meta ?= "b8c82ba37370e4698ff0c42f3e54b8b4f2fb4ac0" SRC_URI = "git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \ git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.4;destsuffix=${KMETA}" -LINUX_VERSION ?= "5.4.20" +LINUX_VERSION ?= "5.4.23" LIC_FILES_CHKSUM = "file://COPYING;md5=bbea815ee2795b2f4230826c0c6b8814" diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_5.4.bb b/meta/recipes-kernel/linux/linux-yocto-tiny_5.4.bb index 47fcc98d93..193bd9ba77 100644 --- a/meta/recipes-kernel/linux/linux-yocto-tiny_5.4.bb +++ b/meta/recipes-kernel/linux/linux-yocto-tiny_5.4.bb @@ -6,7 +6,7 @@ KCONFIG_MODE = "--allnoconfig" require recipes-kernel/linux/linux-yocto.inc -LINUX_VERSION ?= "5.4.20" +LINUX_VERSION ?= "5.4.23" LIC_FILES_CHKSUM = "file://COPYING;md5=bbea815ee2795b2f4230826c0c6b8814" DEPENDS += "${@bb.utils.contains('ARCH', 'x86', 'elfutils-native', '', d)}" @@ -15,9 +15,9 @@ DEPENDS += "openssl-native util-linux-native" KMETA = "kernel-meta" KCONF_BSP_AUDIT_LEVEL = "2" -SRCREV_machine_qemuarm ?= "f0aeaeffb8ba6d0c24f9f0212fd7a11866c918b8" -SRCREV_machine ?= "f4d7dbafb103e4f782323017c239c548871c1567" -SRCREV_meta ?= "13a856e7e5df0d8f951bd4060ac441cf35925c9e" +SRCREV_machine_qemuarm ?= "d361ce4ddedafa6d504d726c5da098d32f46886e" +SRCREV_machine ?= "06356153574af37fccb30f5e632edeb54ddd1f7b" +SRCREV_meta ?= "b8c82ba37370e4698ff0c42f3e54b8b4f2fb4ac0" PV = "${LINUX_VERSION}+git${SRCPV}" diff --git a/meta/recipes-kernel/linux/linux-yocto_5.4.bb b/meta/recipes-kernel/linux/linux-yocto_5.4.bb index 53d5652446..ab7c646fec 100644 --- a/meta/recipes-kernel/linux/linux-yocto_5.4.bb +++ b/meta/recipes-kernel/linux/linux-yocto_5.4.bb @@ -12,16 +12,16 @@ KBRANCH_qemux86 ?= "v5.4/standard/base" KBRANCH_qemux86-64 ?= "v5.4/standard/base" KBRANCH_qemumips64 ?= "v5.4/standard/mti-malta64" -SRCREV_machine_qemuarm ?= "aa91aac123d12d9d4f420862238a437781fe3825" -SRCREV_machine_qemuarm64 ?= "f4d7dbafb103e4f782323017c239c548871c1567" -SRCREV_machine_qemumips ?= "6cb162ab5262318fc52a7cbef86afcf48c6b2449" -SRCREV_machine_qemuppc ?= "f4d7dbafb103e4f782323017c239c548871c1567" -SRCREV_machine_qemuriscv64 ?= "f4d7dbafb103e4f782323017c239c548871c1567" -SRCREV_machine_qemux86 ?= "f4d7dbafb103e4f782323017c239c548871c1567" -SRCREV_machine_qemux86-64 ?= "f4d7dbafb103e4f782323017c239c548871c1567" -SRCREV_machine_qemumips64 ?= "fcbec8b4f0f2f24a31ce5c6e6439c69f7512fb31" -SRCREV_machine ?= "f4d7dbafb103e4f782323017c239c548871c1567" -SRCREV_meta ?= "13a856e7e5df0d8f951bd4060ac441cf35925c9e" +SRCREV_machine_qemuarm ?= "3745c440f4781ffaab809f999c14da1abd3457bb" +SRCREV_machine_qemuarm64 ?= "06356153574af37fccb30f5e632edeb54ddd1f7b" +SRCREV_machine_qemumips ?= "eb0e84ae58eb7a88a48bdbddfb53095228840974" +SRCREV_machine_qemuppc ?= "06356153574af37fccb30f5e632edeb54ddd1f7b" +SRCREV_machine_qemuriscv64 ?= "06356153574af37fccb30f5e632edeb54ddd1f7b" +SRCREV_machine_qemux86 ?= "06356153574af37fccb30f5e632edeb54ddd1f7b" +SRCREV_machine_qemux86-64 ?= "06356153574af37fccb30f5e632edeb54ddd1f7b" +SRCREV_machine_qemumips64 ?= "7ca67eee407193dff5132da8bacc036f670faaea" +SRCREV_machine ?= "06356153574af37fccb30f5e632edeb54ddd1f7b" +SRCREV_meta ?= "b8c82ba37370e4698ff0c42f3e54b8b4f2fb4ac0" # remap qemuarm to qemuarma15 for the 5.4 kernel # KMACHINE_qemuarm ?= "qemuarma15" @@ -30,7 +30,7 @@ SRC_URI = "git://git.yoctoproject.org/linux-yocto.git;name=machine;branch=${KBRA git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.4;destsuffix=${KMETA}" LIC_FILES_CHKSUM = "file://COPYING;md5=bbea815ee2795b2f4230826c0c6b8814" -LINUX_VERSION ?= "5.4.20" +LINUX_VERSION ?= "5.4.23" DEPENDS += "${@bb.utils.contains('ARCH', 'x86', 'elfutils-native', '', d)}" DEPENDS += "openssl-native util-linux-native" -- 2.19.1 From bruce.ashfield at gmail.com Wed Mar 4 14:55:24 2020 From: bruce.ashfield at gmail.com (bruce.ashfield at gmail.com) Date: Wed, 4 Mar 2020 09:55:24 -0500 Subject: [OE-core] [PATCH 4/4] linux-yocto: drop 5.2 recipes In-Reply-To: References: Message-ID: <8141796746818f0e5ba8f9eece7ee5a4f0b4218b.1583333447.git.bruce.ashfield@gmail.com> From: Bruce Ashfield linux-yocto 5.4 will serve as the versioned reference kernel in the upcoming release, and -dev will serve as the "newer" kernel. As such, we drop v5.2 from master, but will continue to update and support it in released branches. Signed-off-by: Bruce Ashfield --- .../linux/linux-yocto-rt_5.2.bb | 44 --------------- .../linux/linux-yocto-tiny_5.2.bb | 32 ----------- meta/recipes-kernel/linux/linux-yocto_5.2.bb | 54 ------------------- 3 files changed, 130 deletions(-) delete mode 100644 meta/recipes-kernel/linux/linux-yocto-rt_5.2.bb delete mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny_5.2.bb delete mode 100644 meta/recipes-kernel/linux/linux-yocto_5.2.bb diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.2.bb b/meta/recipes-kernel/linux/linux-yocto-rt_5.2.bb deleted file mode 100644 index a23a5e6f93..0000000000 --- a/meta/recipes-kernel/linux/linux-yocto-rt_5.2.bb +++ /dev/null @@ -1,44 +0,0 @@ -KBRANCH ?= "v5.2/standard/preempt-rt/base" - -require recipes-kernel/linux/linux-yocto.inc - -# Skip processing of this recipe if it is not explicitly specified as the -# PREFERRED_PROVIDER for virtual/kernel. This avoids errors when trying -# to build multiple virtual/kernel providers, e.g. as dependency of -# core-image-rt-sdk, core-image-rt. -python () { - if d.getVar("KERNEL_PACKAGE_NAME") == "kernel" and d.getVar("PREFERRED_PROVIDER_virtual/kernel") != "linux-yocto-rt": - raise bb.parse.SkipRecipe("Set PREFERRED_PROVIDER_virtual/kernel to linux-yocto-rt to enable it") -} - -SRCREV_machine ?= "78e147f949b5b18524aa7bd72f1cc8f7ae8039f8" -SRCREV_meta ?= "bb2776d6beaae64b1a0fc902b64376f082085498" - -SRC_URI = "git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \ - git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.2;destsuffix=${KMETA}" - -LINUX_VERSION ?= "5.2.32" - -LIC_FILES_CHKSUM = "file://COPYING;md5=bbea815ee2795b2f4230826c0c6b8814" - -DEPENDS += "${@bb.utils.contains('ARCH', 'x86', 'elfutils-native', '', d)}" -DEPENDS += "openssl-native util-linux-native" - -PV = "${LINUX_VERSION}+git${SRCPV}" - -KMETA = "kernel-meta" -KCONF_BSP_AUDIT_LEVEL = "2" - -LINUX_KERNEL_TYPE = "preempt-rt" - -COMPATIBLE_MACHINE = "(qemux86|qemux86-64|qemuarm|qemuarmv5|qemuarm64|qemuppc|qemumips)" - -KERNEL_DEVICETREE_qemuarmv5 = "versatile-pb.dtb" - -# Functionality flags -KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc features/taskstats/taskstats.scc" -KERNEL_FEATURES_append = " ${KERNEL_EXTRA_FEATURES}" -KERNEL_FEATURES_append_qemuall=" cfg/virtio.scc features/drm-bochs/drm-bochs.scc" -KERNEL_FEATURES_append_qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc" -KERNEL_FEATURES_append_qemux86-64=" cfg/sound.scc cfg/paravirt_kvm.scc" -KERNEL_FEATURES_append = "${@bb.utils.contains("DISTRO_FEATURES", "ptest", " features/scsi/scsi-debug.scc", "" ,d)}" diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_5.2.bb b/meta/recipes-kernel/linux/linux-yocto-tiny_5.2.bb deleted file mode 100644 index ac9904f415..0000000000 --- a/meta/recipes-kernel/linux/linux-yocto-tiny_5.2.bb +++ /dev/null @@ -1,32 +0,0 @@ -KBRANCH ?= "v5.2/standard/tiny/base" -KBRANCH_qemuarm ?= "v5.2/standard/tiny/arm-versatile-926ejs" - -LINUX_KERNEL_TYPE = "tiny" -KCONFIG_MODE = "--allnoconfig" - -require recipes-kernel/linux/linux-yocto.inc - -LINUX_VERSION ?= "5.2.32" -LIC_FILES_CHKSUM = "file://COPYING;md5=bbea815ee2795b2f4230826c0c6b8814" - -DEPENDS += "${@bb.utils.contains('ARCH', 'x86', 'elfutils-native', '', d)}" -DEPENDS += "openssl-native util-linux-native" - -KMETA = "kernel-meta" -KCONF_BSP_AUDIT_LEVEL = "2" - -SRCREV_machine_qemuarm ?= "e0a3a01b24070b15121e938ea19755091bf0d662" -SRCREV_machine ?= "73b12de4c879e4569bef3b2d0ee9c783a9788b27" -SRCREV_meta ?= "bb2776d6beaae64b1a0fc902b64376f082085498" - -PV = "${LINUX_VERSION}+git${SRCPV}" - -SRC_URI = "git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \ - git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.2;destsuffix=${KMETA}" - -COMPATIBLE_MACHINE = "qemux86|qemux86-64|qemuarm|qemuarmv5" - -# Functionality flags -KERNEL_FEATURES = "" - -KERNEL_DEVICETREE_qemuarmv5 = "versatile-pb.dtb" diff --git a/meta/recipes-kernel/linux/linux-yocto_5.2.bb b/meta/recipes-kernel/linux/linux-yocto_5.2.bb deleted file mode 100644 index eab142e1c6..0000000000 --- a/meta/recipes-kernel/linux/linux-yocto_5.2.bb +++ /dev/null @@ -1,54 +0,0 @@ -KBRANCH ?= "v5.2/standard/base" - -require recipes-kernel/linux/linux-yocto.inc - -# board specific branches -KBRANCH_qemuarm ?= "v5.2/standard/arm-versatile-926ejs" -KBRANCH_qemuarm64 ?= "v5.2/standard/qemuarm64" -KBRANCH_qemumips ?= "v5.2/standard/mti-malta32" -KBRANCH_qemuppc ?= "v5.2/standard/qemuppc" -KBRANCH_qemuriscv64 ?= "v5.2/standard/base" -KBRANCH_qemux86 ?= "v5.2/standard/base" -KBRANCH_qemux86-64 ?= "v5.2/standard/base" -KBRANCH_qemumips64 ?= "v5.2/standard/mti-malta64" - -SRCREV_machine_qemuarm ?= "fdb7cd1bb5e4238e5b3d120ce9db31119ec2b5ee" -SRCREV_machine_qemuarm64 ?= "73b12de4c879e4569bef3b2d0ee9c783a9788b27" -SRCREV_machine_qemumips ?= "eb7faee13cfce200e9add4ba1852a3fe5d8b92e6" -SRCREV_machine_qemuppc ?= "73b12de4c879e4569bef3b2d0ee9c783a9788b27" -SRCREV_machine_qemuriscv64 ?= "73b12de4c879e4569bef3b2d0ee9c783a9788b27" -SRCREV_machine_qemux86 ?= "73b12de4c879e4569bef3b2d0ee9c783a9788b27" -SRCREV_machine_qemux86-64 ?= "73b12de4c879e4569bef3b2d0ee9c783a9788b27" -SRCREV_machine_qemumips64 ?= "8e3bfeb7e9b5aa92c5bea941d361ff5b081a2aaa" -SRCREV_machine ?= "73b12de4c879e4569bef3b2d0ee9c783a9788b27" -SRCREV_meta ?= "bb2776d6beaae64b1a0fc902b64376f082085498" - -# remap qemuarm to qemuarma15 for the 5.2 kernel -# KMACHINE_qemuarm ?= "qemuarma15" - -SRC_URI = "git://git.yoctoproject.org/linux-yocto.git;name=machine;branch=${KBRANCH}; \ - git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.2;destsuffix=${KMETA}" - -LIC_FILES_CHKSUM = "file://COPYING;md5=bbea815ee2795b2f4230826c0c6b8814" -LINUX_VERSION ?= "5.2.32" - -DEPENDS += "${@bb.utils.contains('ARCH', 'x86', 'elfutils-native', '', d)}" -DEPENDS += "openssl-native util-linux-native" - -PV = "${LINUX_VERSION}+git${SRCPV}" - -KMETA = "kernel-meta" -KCONF_BSP_AUDIT_LEVEL = "2" - -KERNEL_DEVICETREE_qemuarmv5 = "versatile-pb.dtb" - -COMPATIBLE_MACHINE = "qemuarm|qemuarmv5|qemuarm64|qemux86|qemuppc|qemumips|qemumips64|qemux86-64|qemuriscv64" - -# Functionality flags -KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc" -KERNEL_FEATURES_append = " ${KERNEL_EXTRA_FEATURES}" -KERNEL_FEATURES_append_qemuall=" cfg/virtio.scc features/drm-bochs/drm-bochs.scc" -KERNEL_FEATURES_append_qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc" -KERNEL_FEATURES_append_qemux86-64=" cfg/sound.scc cfg/paravirt_kvm.scc" -KERNEL_FEATURES_append = " ${@bb.utils.contains("TUNE_FEATURES", "mx32", " cfg/x32.scc", "" ,d)}" -KERNEL_FEATURES_append = " ${@bb.utils.contains("DISTRO_FEATURES", "ptest", " features/scsi/scsi-debug.scc", "" ,d)}" -- 2.19.1 From alex.kanavin at gmail.com Wed Mar 4 16:00:44 2020 From: alex.kanavin at gmail.com (Alexander Kanavin) Date: Wed, 4 Mar 2020 17:00:44 +0100 Subject: [OE-core] Does YP provide security support for stable and LTS branches? In-Reply-To: <20200304140109.GC7923@localhost> References: <20200223193408.5602-1-bunk@stusta.de> <20200224051745.GA6683@localhost> <20200227132729.GA6240@localhost> <20200304090507.GA7923@localhost> <20200304113217.GB7923@localhost> <20200304140109.GC7923@localhost> Message-ID: Taking offense or getting angry at the yocto project is entirely misdirected. The liability for insecure millions of devices does not lie with the yocto project, it lies with the OEMs. If the OEMs are unwilling to allocate manpower to work on security, there?s very little the yocto project can do. We are already struggling to find people to work on actual bugs, and there?s simply no manpower to do security properly. Still, stable releases *are* much better than community supported ones, they do get a lot of CVEs and bugs fixed, all I wanted to say is that the exhaustive process to fix everything that could be insecure is not there. Alex On Wed 4. Mar 2020 at 15.01, Adrian Bunk wrote: > On Wed, Mar 04, 2020 at 01:13:19PM +0100, Alexander Kanavin wrote: > > On Wed, 4 Mar 2020 at 12:32, Adrian Bunk wrote: > > > > > I am sure there will be an update to the announcement if this doesn't > > > reflect current reality. > > > > Who is expected to do the actual work of tracking CVEs, making action > > points and performing the actions? The current reality is this: the > > security update work is done ad hoc by community, even for stable > branches. > > There is no rigorous security process like in Debian, and no roles to > > follow in that process. This means that if no one bothers to make a > patch, > > the security issue will remain unfixed, and this does happen often. If > you > > are expecting anything else (e.g. that listed recipe maintainers should > do > > something), you're setting yourself up to be disappointed. > > All I am expecting is honesty. > > If YP does not provide security support for supported stable branches, > then public statements that community support would be worse than stable > branches due to lack of security support are dishonest and offensive. > > It also puts all users of Yocto stable and LTS releases and billions of > devices at danger if the Yocto project announces security support but > does not deliver. > > The normal user expects that that the announced "usual defect fixes and > updates for the extended period of two years" in LTS include the regular > security updates that were claimed for stable branches earlier in the > same announcement. > > For cases where I am the user the only benefit of going through the pain > of upgrading existing products from older releases to Yocto 3.1 would be > 2 years of security support from upstream. Doing the upgrade and only > discovering afterwards that it doesn't bring the benefit that was > promised would make me . > > Let me repeat that the only thing I am expecting is honesty, > and all I am asking for is that if YP does not provide security > support for stable and LTS branches this should be communicated > clearly so that all users are aware. > > > Alex > > cu > Adrian > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bunk at stusta.de Wed Mar 4 17:24:15 2020 From: bunk at stusta.de (Adrian Bunk) Date: Wed, 4 Mar 2020 19:24:15 +0200 Subject: [OE-core] Does YP provide security support for stable and LTS branches? In-Reply-To: References: <20200224051745.GA6683@localhost> <20200227132729.GA6240@localhost> <20200304090507.GA7923@localhost> <20200304113217.GB7923@localhost> <20200304140109.GC7923@localhost> Message-ID: <20200304172415.GA29456@localhost> On Wed, Mar 04, 2020 at 05:00:44PM +0100, Alexander Kanavin wrote: > Taking offense or getting angry at the yocto project is entirely > misdirected. I am not angry if YP does not provide security support. I am angry when YP is telling lies that it would provide security support, but does not actually provide it. > The liability for insecure millions of devices does not lie > with the yocto project, it lies with the OEMs. >... The liability for insecure millions of devices lies 100% with the Yocto Project if it claims to provide security support but does not actually provide it. If a user has to decide today whether an upcoming product will run Ubuntu 20.04 LTS or Yocto 3.1 LTS, then it should be clear to the user whether or not choosing Yocto will provide upstream security support the same way as Ubuntu. A user reading the YP LTS announcement expects security support similar to what Ubuntu is offering, and might only notice that this isn't true after a known vulnerability gets exploited on millions of devices. If security support for YP stable and LTS releases is only on a community support basis and usually incomplete, then it is on YP to make that clear to all users instead of claiming the opposite - in other projects LTS does include security support, sometimes only security fixes are permitted. This could be combined with a call for help for security support, an advantage of being honest would be that it becomes visible for users that there is a resource shortage. > Alex cu Adrian From jpewhacker at gmail.com Wed Mar 4 18:31:39 2020 From: jpewhacker at gmail.com (Joshua Watt) Date: Wed, 4 Mar 2020 12:31:39 -0600 Subject: [OE-core] [PATCH] classes/kernel.bbclass: Fix parsing errors Message-ID: <20200304183139.1512-1-JPEWhacker@gmail.com> legitimize_package_name wants the actual value of KERNEL_REVISION, so use d.getVar() to fetch it as is done elsewhere in the file. Failing to do so can result it weird errors at parsing time. Signed-off-by: Joshua Watt --- meta/classes/kernel.bbclass | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass index 15219c596f..0eadd3efb8 100644 --- a/meta/classes/kernel.bbclass +++ b/meta/classes/kernel.bbclass @@ -570,9 +570,9 @@ RDEPENDS_${KERNEL_PACKAGE_NAME} = "${KERNEL_PACKAGE_NAME}-base" # Allow machines to override this dependency if kernel image files are # not wanted in images as standard RDEPENDS_${KERNEL_PACKAGE_NAME}-base ?= "${KERNEL_PACKAGE_NAME}-image" -PKG_${KERNEL_PACKAGE_NAME}-image = "${KERNEL_PACKAGE_NAME}-image-${@legitimize_package_name('${KERNEL_VERSION}')}" +PKG_${KERNEL_PACKAGE_NAME}-image = "${KERNEL_PACKAGE_NAME}-image-${@legitimize_package_name(d.getVar('KERNEL_VERSION'))}" RDEPENDS_${KERNEL_PACKAGE_NAME}-image += "${@oe.utils.conditional('KERNEL_IMAGETYPE', 'vmlinux', '${KERNEL_PACKAGE_NAME}-vmlinux', '', d)}" -PKG_${KERNEL_PACKAGE_NAME}-base = "${KERNEL_PACKAGE_NAME}-${@legitimize_package_name('${KERNEL_VERSION}')}" +PKG_${KERNEL_PACKAGE_NAME}-base = "${KERNEL_PACKAGE_NAME}-${@legitimize_package_name(d.getVar('KERNEL_VERSION'))}" RPROVIDES_${KERNEL_PACKAGE_NAME}-base += "${KERNEL_PACKAGE_NAME}-${KERNEL_VERSION}" ALLOW_EMPTY_${KERNEL_PACKAGE_NAME} = "1" ALLOW_EMPTY_${KERNEL_PACKAGE_NAME}-base = "1" -- 2.17.1 From jpuhlman at mvista.com Wed Mar 4 19:39:36 2020 From: jpuhlman at mvista.com (Jeremy A. Puhlman) Date: Wed, 4 Mar 2020 11:39:36 -0800 Subject: [OE-core] [PATCH] buildtools-extended-tarball: add nativesdk-libxcrypt-dev Message-ID: <20200304193936.27389-1-jpuhlman@mvista.com> From: Jeremy Puhlman virtual/crypt-native is assume provided in bitbake.conf, so buildtools-extended-tarball shoud provide crypt since it doesn't use the host's headers/libraries. [YOCTO #13714] Signed-off-by: Jeremy A. Puhlman --- meta/recipes-core/meta/buildtools-extended-tarball.bb | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/recipes-core/meta/buildtools-extended-tarball.bb b/meta/recipes-core/meta/buildtools-extended-tarball.bb index d756036373..4a79b09fda 100644 --- a/meta/recipes-core/meta/buildtools-extended-tarball.bb +++ b/meta/recipes-core/meta/buildtools-extended-tarball.bb @@ -25,6 +25,7 @@ TOOLCHAIN_HOST_TASK += "\ nativesdk-libstdc++-dev \ nativesdk-libtool \ nativesdk-pkgconfig \ + nativesdk-libxcrypt-dev \ " TOOLCHAIN_OUTPUTNAME = "${SDK_ARCH}-buildtools-extended-nativesdk-standalone-${DISTRO_VERSION}" -- 2.20.1 From akuster808 at gmail.com Wed Mar 4 20:26:29 2020 From: akuster808 at gmail.com (akuster808) Date: Wed, 4 Mar 2020 12:26:29 -0800 Subject: [OE-core] [Openembedded-architecture] Does YP provide security support for stable and LTS branches? In-Reply-To: <20200304172415.GA29456@localhost> References: <20200224051745.GA6683@localhost> <20200227132729.GA6240@localhost> <20200304090507.GA7923@localhost> <20200304113217.GB7923@localhost> <20200304140109.GC7923@localhost> <20200304172415.GA29456@localhost> Message-ID: <01b3bb37-f65f-8048-1a27-b859b62d7f98@gmail.com> Adrian, On 3/4/20 9:24 AM, Adrian Bunk wrote: > On Wed, Mar 04, 2020 at 05:00:44PM +0100, Alexander Kanavin wrote: >> Taking offense or getting angry at the yocto project is entirely >> misdirected. > I am not angry if YP does not provide security support. > > I am angry when YP is telling lies that it would provide security > support, but does not actually provide it. ?I am sure its not the intent of the Yocto Project to miss lead folks. > >> The liability for insecure millions of devices does not lie >> with the yocto project, it lies with the OEMs. >> ... > The liability for insecure millions of devices lies 100% with the Yocto > Project if it claims to provide security support but does not actually > provide it. > > If a user has to decide today whether an upcoming product will run > Ubuntu 20.04 LTS or Yocto 3.1 LTS, then it should be clear to the > user whether or not choosing Yocto will provide upstream security > support the same way as Ubuntu. > > A user reading the YP LTS announcement expects security support similar > to what Ubuntu is offering, and might only notice that this isn't true > after a known vulnerability gets exploited on millions of devices. I didn't get that out of the announcement. It only reference in the LTS announcement? regarding Security was in context to Community support. The new new LTS / Stable process wiki does not claim such claims either. https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS > > If security support for YP stable and LTS releases is only on a > community support basis and usually incomplete, then it is on YP > to make that clear to all users instead of claiming the opposite - in > other projects LTS does include security support, sometimes only > security fixes are permitted. Can point out where those statements are made? Again, I am sure the Yocto Project would like to know. > > This could be combined with a call for help for security support, > an advantage of being honest would be that it becomes visible for > users that there is a resource shortage. There are weekly status reports? and minutes from various meeting that include the attendees list.? The attendees list has not grown. The build swat team was shut down as no one stepped up to help. That was an opportunity for the community to step up. There is request for help regarding defects sent out every week and if it wasn't for WindRiver, Intel, Joshua Watt and Richard the open defects would go uncheck. So the resource issue has been floating around on the various mailing lists for some time. What do you think needs to be done to make it even more visible? regards, armin > >> Alex > cu > Adrian > _______________________________________________ > Openembedded-architecture mailing list > Openembedded-architecture at lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-architecture From hnathan918 at gmail.com Wed Mar 4 22:05:55 2020 From: hnathan918 at gmail.com (Nathan Hartman) Date: Wed, 4 Mar 2020 14:05:55 -0800 Subject: [OE-core] [PATCH] mesa: updated to 20.0 release Message-ID: <20200304220555.30563-1-hnathan918@gmail.com> Signed-off-by: Nathan Hartman Uprev'd mesa and mesa-gl recipes to 20.0 release. As glx-tls was updated to elf-tls in the 20.0 release, the mesa.inc file was updated to reflect this change. --- .../mesa/{mesa-gl_19.1.6.bb => mesa-gl_20.0.0.bb} | 0 meta/recipes-graphics/mesa/mesa.inc | 12 ++++++------ .../mesa/{mesa_19.1.6.bb => mesa_20.0.0.bb} | 13 +++++++------ 3 files changed, 13 insertions(+), 12 deletions(-) rename meta/recipes-graphics/mesa/{mesa-gl_19.1.6.bb => mesa-gl_20.0.0.bb} (100%) rename meta/recipes-graphics/mesa/{mesa_19.1.6.bb => mesa_20.0.0.bb} (54%) diff --git a/meta/recipes-graphics/mesa/mesa-gl_19.1.6.bb b/meta/recipes-graphics/mesa/mesa-gl_20.0.0.bb similarity index 100% rename from meta/recipes-graphics/mesa/mesa-gl_19.1.6.bb rename to meta/recipes-graphics/mesa/mesa-gl_20.0.0.bb diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-graphics/mesa/mesa.inc index 9e5808ee27..a678ceae00 100644 --- a/meta/recipes-graphics/mesa/mesa.inc +++ b/meta/recipes-graphics/mesa/mesa.inc @@ -10,7 +10,7 @@ HOMEPAGE = "http://mesa3d.org" BUGTRACKER = "https://bugs.freedesktop.org" SECTION = "x11" LICENSE = "MIT" -LIC_FILES_CHKSUM = "file://docs/license.html;md5=725f991a1cc322aa7a0cd3a2016621c4" +LIC_FILES_CHKSUM = "file://docs/license.html;md5=c1843d93c460bbf778d6037ce324f9f7" PE = "2" @@ -57,12 +57,12 @@ PACKAGECONFIG_class-target ??= "${@bb.utils.filter('DISTRO_FEATURES', 'wayland v ${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'opengl egl gles gbm dri gallium', '', d)} \ ${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl', 'x11 dri3', '', d)} \ ${@bb.utils.contains('DISTRO_FEATURES', 'x11 vulkan', 'dri3', '', d)} \ - glx-tls \ + elf-tls \ " -PACKAGECONFIG_class-native ?= "gbm dri egl opengl glx-tls" -PACKAGECONFIG_class-nativesdk ?= "gbm dri egl opengl glx-tls" +PACKAGECONFIG_class-native ?= "gbm dri egl opengl elf-tls" +PACKAGECONFIG_class-nativesdk ?= "gbm dri egl opengl elf-tls" -PACKAGECONFIG_remove_libc-musl = "glx-tls" +PACKAGECONFIG_remove_libc-musl = "elf-tls" # "gbm" requires "dri", "opengl" PACKAGECONFIG[gbm] = "-Dgbm=true,-Dgbm=false" @@ -70,7 +70,7 @@ PACKAGECONFIG[gbm] = "-Dgbm=true,-Dgbm=false" X11_DEPS = "xorgproto virtual/libx11 libxext libxxf86vm libxdamage libxfixes xrandr" # "x11" requires "opengl" PACKAGECONFIG[x11] = ",-Dglx=disabled,${X11_DEPS}" -PACKAGECONFIG[glx-tls] = "-Dglx-tls=true, -Dglx-tls=false" +PACKAGECONFIG[elf-tls] = "-Delf-tls=true, -Delf-tls=false" PACKAGECONFIG[xvmc] = "-Dgallium-xvmc=true,-Dgallium-xvmc=false,libxvmc" PACKAGECONFIG[wayland] = ",,wayland-native wayland libdrm wayland-protocols" diff --git a/meta/recipes-graphics/mesa/mesa_19.1.6.bb b/meta/recipes-graphics/mesa/mesa_20.0.0.bb similarity index 54% rename from meta/recipes-graphics/mesa/mesa_19.1.6.bb rename to meta/recipes-graphics/mesa/mesa_20.0.0.bb index 19221e9e25..d38754e852 100644 --- a/meta/recipes-graphics/mesa/mesa_19.1.6.bb +++ b/meta/recipes-graphics/mesa/mesa_20.0.0.bb @@ -1,13 +1,14 @@ require ${BPN}.inc SRC_URI = "https://mesa.freedesktop.org/archive/mesa-${PV}.tar.xz \ - file://0001-meson.build-check-for-all-linux-host_os-combinations.patch \ - file://0002-meson.build-make-TLS-GLX-optional-again.patch \ - file://0003-Allow-enable-DRI-without-DRI-drivers.patch \ + file://0001-meson.build-check-for-all-linux-host_os-combinations.patch \ + file://0002-meson.build-make-TLS-ELF-optional.patch \ + file://0003-Allow-enable-DRI-without-DRI-drivers.patch \ + file://0004-Revert-mesa-Enable-asm-unconditionally-now-that-gen_.patch \ + file://0005-vc4-use-intmax_t-for-formatted-output-of-timespec-me.patch \ " - -SRC_URI[md5sum] = "7dbb40b8d10e89bee0a5bfc85350647b" -SRC_URI[sha256sum] = "2a369b7b48545c6486e7e44913ad022daca097c8bd937bf30dcf3f17a94d3496" +SRC_URI[md5sum] = "681229d992bbd6250a5be4f308708795" +SRC_URI[sha256sum] = "bb6db3e54b608d2536d4000b3de7dd3ae115fc114e8acbb5afff4b3bbed04b34" UPSTREAM_CHECK_GITTAGREGEX = "mesa-(?P\d+(\.\d+)+)" -- 2.17.1 From jpuhlman at mvista.com Wed Mar 4 22:24:47 2020 From: jpuhlman at mvista.com (Jeremy A. Puhlman) Date: Wed, 4 Mar 2020 14:24:47 -0800 Subject: [OE-core] [PATCH] gdbm: add depend on readline for consistent builds Message-ID: <20200304222447.1787-1-jpuhlman@mvista.com> From: Jeremy Puhlman Whether readline is installed on the build host or not influences the way gdbm builds. Depend on readline for a consistent build. This fails to build on a system with readline, and using the buildtools-extended installer. Signed-off-by: Jeremy A. Puhlman --- meta/recipes-support/gdbm/gdbm_1.18.1.bb | 2 ++ 1 file changed, 2 insertions(+) diff --git a/meta/recipes-support/gdbm/gdbm_1.18.1.bb b/meta/recipes-support/gdbm/gdbm_1.18.1.bb index 7e2efe3c9b..5326184181 100644 --- a/meta/recipes-support/gdbm/gdbm_1.18.1.bb +++ b/meta/recipes-support/gdbm/gdbm_1.18.1.bb @@ -15,6 +15,8 @@ SRC_URI[sha256sum] = "86e613527e5dba544e73208f42b78b7c022d4fa5a6d5498bf18c8d6f74 inherit autotools gettext texinfo lib_package ptest +DEPENDS_class-native += "readline" + # Needed for dbm python module EXTRA_OECONF = "-enable-libgdbm-compat" -- 2.20.1 From patchwork at patchwork.openembedded.org Wed Mar 4 22:32:27 2020 From: patchwork at patchwork.openembedded.org (Patchwork) Date: Wed, 04 Mar 2020 22:32:27 -0000 Subject: [OE-core] =?utf-8?q?=E2=9C=97_patchtest=3A_failure_for_mesa=3A_up?= =?utf-8?q?dated_to_20=2E0_release?= In-Reply-To: <20200304220555.30563-1-hnathan918@gmail.com> References: <20200304220555.30563-1-hnathan918@gmail.com> Message-ID: <20200304223227.2277.39635@do> == Series Details == Series: mesa: updated to 20.0 release Revision: 1 URL : https://patchwork.openembedded.org/series/23100/ 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 fix Rebase your series on top of targeted branch Targeted branch master (currently at d6b1809e8c) If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core at 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 From akuster808 at gmail.com Wed Mar 4 22:35:17 2020 From: akuster808 at gmail.com (akuster808) Date: Wed, 4 Mar 2020 14:35:17 -0800 Subject: [OE-core] [PATCH] mesa: updated to 20.0 release In-Reply-To: <20200304220555.30563-1-hnathan918@gmail.com> References: <20200304220555.30563-1-hnathan918@gmail.com> Message-ID: <8798738b-8c20-d265-c217-3150d77a44be@gmail.com> On 3/4/20 2:05 PM, Nathan Hartman wrote: > Signed-off-by: Nathan Hartman > > Uprev'd mesa and mesa-gl recipes to 20.0 release. > > As glx-tls was updated to elf-tls in the 20.0 release, the mesa.inc file > was updated to reflect this change. Why did the LIC_FILES_CHKSUM change? please include that in the commit message Do the mesa-demos still work? - armin > > > --- > .../mesa/{mesa-gl_19.1.6.bb => mesa-gl_20.0.0.bb} | 0 > meta/recipes-graphics/mesa/mesa.inc | 12 ++++++------ > .../mesa/{mesa_19.1.6.bb => mesa_20.0.0.bb} | 13 +++++++------ > 3 files changed, 13 insertions(+), 12 deletions(-) > rename meta/recipes-graphics/mesa/{mesa-gl_19.1.6.bb => mesa-gl_20.0.0.bb} (100%) > rename meta/recipes-graphics/mesa/{mesa_19.1.6.bb => mesa_20.0.0.bb} (54%) > > diff --git a/meta/recipes-graphics/mesa/mesa-gl_19.1.6.bb b/meta/recipes-graphics/mesa/mesa-gl_20.0.0.bb > similarity index 100% > rename from meta/recipes-graphics/mesa/mesa-gl_19.1.6.bb > rename to meta/recipes-graphics/mesa/mesa-gl_20.0.0.bb > diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-graphics/mesa/mesa.inc > index 9e5808ee27..a678ceae00 100644 > --- a/meta/recipes-graphics/mesa/mesa.inc > +++ b/meta/recipes-graphics/mesa/mesa.inc > @@ -10,7 +10,7 @@ HOMEPAGE = "http://mesa3d.org" > BUGTRACKER = "https://bugs.freedesktop.org" > SECTION = "x11" > LICENSE = "MIT" > -LIC_FILES_CHKSUM = "file://docs/license.html;md5=725f991a1cc322aa7a0cd3a2016621c4" > +LIC_FILES_CHKSUM = "file://docs/license.html;md5=c1843d93c460bbf778d6037ce324f9f7" > > PE = "2" > > @@ -57,12 +57,12 @@ PACKAGECONFIG_class-target ??= "${@bb.utils.filter('DISTRO_FEATURES', 'wayland v > ${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'opengl egl gles gbm dri gallium', '', d)} \ > ${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl', 'x11 dri3', '', d)} \ > ${@bb.utils.contains('DISTRO_FEATURES', 'x11 vulkan', 'dri3', '', d)} \ > - glx-tls \ > + elf-tls \ > " > -PACKAGECONFIG_class-native ?= "gbm dri egl opengl glx-tls" > -PACKAGECONFIG_class-nativesdk ?= "gbm dri egl opengl glx-tls" > +PACKAGECONFIG_class-native ?= "gbm dri egl opengl elf-tls" > +PACKAGECONFIG_class-nativesdk ?= "gbm dri egl opengl elf-tls" > > -PACKAGECONFIG_remove_libc-musl = "glx-tls" > +PACKAGECONFIG_remove_libc-musl = "elf-tls" > > # "gbm" requires "dri", "opengl" > PACKAGECONFIG[gbm] = "-Dgbm=true,-Dgbm=false" > @@ -70,7 +70,7 @@ PACKAGECONFIG[gbm] = "-Dgbm=true,-Dgbm=false" > X11_DEPS = "xorgproto virtual/libx11 libxext libxxf86vm libxdamage libxfixes xrandr" > # "x11" requires "opengl" > PACKAGECONFIG[x11] = ",-Dglx=disabled,${X11_DEPS}" > -PACKAGECONFIG[glx-tls] = "-Dglx-tls=true, -Dglx-tls=false" > +PACKAGECONFIG[elf-tls] = "-Delf-tls=true, -Delf-tls=false" > PACKAGECONFIG[xvmc] = "-Dgallium-xvmc=true,-Dgallium-xvmc=false,libxvmc" > PACKAGECONFIG[wayland] = ",,wayland-native wayland libdrm wayland-protocols" > > diff --git a/meta/recipes-graphics/mesa/mesa_19.1.6.bb b/meta/recipes-graphics/mesa/mesa_20.0.0.bb > similarity index 54% > rename from meta/recipes-graphics/mesa/mesa_19.1.6.bb > rename to meta/recipes-graphics/mesa/mesa_20.0.0.bb > index 19221e9e25..d38754e852 100644 > --- a/meta/recipes-graphics/mesa/mesa_19.1.6.bb > +++ b/meta/recipes-graphics/mesa/mesa_20.0.0.bb > @@ -1,13 +1,14 @@ > require ${BPN}.inc > > SRC_URI = "https://mesa.freedesktop.org/archive/mesa-${PV}.tar.xz \ > - file://0001-meson.build-check-for-all-linux-host_os-combinations.patch \ > - file://0002-meson.build-make-TLS-GLX-optional-again.patch \ > - file://0003-Allow-enable-DRI-without-DRI-drivers.patch \ > + file://0001-meson.build-check-for-all-linux-host_os-combinations.patch \ > + file://0002-meson.build-make-TLS-ELF-optional.patch \ > + file://0003-Allow-enable-DRI-without-DRI-drivers.patch \ > + file://0004-Revert-mesa-Enable-asm-unconditionally-now-that-gen_.patch \ > + file://0005-vc4-use-intmax_t-for-formatted-output-of-timespec-me.patch \ > " > - > -SRC_URI[md5sum] = "7dbb40b8d10e89bee0a5bfc85350647b" > -SRC_URI[sha256sum] = "2a369b7b48545c6486e7e44913ad022daca097c8bd937bf30dcf3f17a94d3496" > +SRC_URI[md5sum] = "681229d992bbd6250a5be4f308708795" > +SRC_URI[sha256sum] = "bb6db3e54b608d2536d4000b3de7dd3ae115fc114e8acbb5afff4b3bbed04b34" > > UPSTREAM_CHECK_GITTAGREGEX = "mesa-(?P\d+(\.\d+)+)" > From richard.purdie at linuxfoundation.org Wed Mar 4 22:42:04 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Wed, 04 Mar 2020 22:42:04 +0000 Subject: [OE-core] Yocto Project Status WW09'20 In-Reply-To: References: <107c01d5f174$bbf566a0$33e033e0$@gmail.com> Message-ID: On Wed, 2020-03-04 at 14:00 +0100, Alexander Kanavin wrote: > On Tue, 3 Mar 2020 at 16:59, wrote: > > coreutils ptest blocked on libmodule-build-perl reproducibility > > issue > > > > I sent a patch for this. Thanks! Just FYI I think there may also be a couple of other packages coreutils pulls in and they may also have reproducibility issues (gettext-ptest, glibc-locale-* and procps*). Cheers, Richard From christopher.w.clark at gmail.com Wed Mar 4 23:17:24 2020 From: christopher.w.clark at gmail.com (christopher.w.clark at gmail.com) Date: Wed, 4 Mar 2020 15:17:24 -0800 Subject: [OE-core] [PATCH] qemu: update Xen packages names for the xen-tools recipe Message-ID: <20200304231724.6236-1-christopher.w.clark@gmail.com> From: Christopher Clark The Xen recipe has been divided into separate recipes for the hypervisor and tools in meta-virtualization commit 545461ba, so the package name references in the qemu recipe need to be updated to the new xen-tools packages. This change allows the temporary bbappend applied to qemu in meta-virtualization in that change to be retired. Signed-off-by: Christopher Clark --- meta/recipes-devtools/qemu/qemu.inc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-devtools/qemu/qemu.inc b/meta/recipes-devtools/qemu/qemu.inc index f26e722f43..f3342eaf28 100644 --- a/meta/recipes-devtools/qemu/qemu.inc +++ b/meta/recipes-devtools/qemu/qemu.inc @@ -136,7 +136,7 @@ PACKAGECONFIG[sdl] = "--enable-sdl,--disable-sdl,libsdl2" PACKAGECONFIG[virtfs] = "--enable-virtfs --enable-attr,--disable-virtfs,libcap attr," PACKAGECONFIG[aio] = "--enable-linux-aio,--disable-linux-aio,libaio," PACKAGECONFIG[xfs] = "--enable-xfsctl,--disable-xfsctl,xfsprogs," -PACKAGECONFIG[xen] = "--enable-xen,--disable-xen,xen,xen-libxenstore xen-libxenctrl xen-libxenguest" +PACKAGECONFIG[xen] = "--enable-xen,--disable-xen,xen-tools,xen-tools-libxenstore xen-tools-libxenctrl xen-tools-libxenguest" PACKAGECONFIG[vnc-sasl] = "--enable-vnc --enable-vnc-sasl,--disable-vnc-sasl,cyrus-sasl," PACKAGECONFIG[vnc-jpeg] = "--enable-vnc --enable-vnc-jpeg,--disable-vnc-jpeg,jpeg," PACKAGECONFIG[vnc-png] = "--enable-vnc --enable-vnc-png,--disable-vnc-png,libpng," -- 2.17.1 From raj.khem at gmail.com Wed Mar 4 23:22:20 2020 From: raj.khem at gmail.com (Khem Raj) Date: Wed, 4 Mar 2020 15:22:20 -0800 Subject: [OE-core] [PATCH] gdbm: add depend on readline for consistent builds In-Reply-To: <20200304222447.1787-1-jpuhlman@mvista.com> References: <20200304222447.1787-1-jpuhlman@mvista.com> Message-ID: On Wed, Mar 4, 2020 at 2:25 PM Jeremy A. Puhlman wrote: > > From: Jeremy Puhlman > > Whether readline is installed on the build host or not > influences the way gdbm builds. Depend on readline for > a consistent build. > > This fails to build on a system with readline, and using > the buildtools-extended installer. > > Signed-off-by: Jeremy A. Puhlman > --- > meta/recipes-support/gdbm/gdbm_1.18.1.bb | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/meta/recipes-support/gdbm/gdbm_1.18.1.bb b/meta/recipes-support/gdbm/gdbm_1.18.1.bb > index 7e2efe3c9b..5326184181 100644 > --- a/meta/recipes-support/gdbm/gdbm_1.18.1.bb > +++ b/meta/recipes-support/gdbm/gdbm_1.18.1.bb > @@ -15,6 +15,8 @@ SRC_URI[sha256sum] = "86e613527e5dba544e73208f42b78b7c022d4fa5a6d5498bf18c8d6f74 > > inherit autotools gettext texinfo lib_package ptest > > +DEPENDS_class-native += "readline" > + shouldn't this be readline-native > # Needed for dbm python module > EXTRA_OECONF = "-enable-libgdbm-compat" > > -- > 2.20.1 > > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core at lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core From armccurdy at gmail.com Wed Mar 4 23:43:58 2020 From: armccurdy at gmail.com (Andre McCurdy) Date: Wed, 4 Mar 2020 15:43:58 -0800 Subject: [OE-core] [PATCH] gdbm: add depend on readline for consistent builds In-Reply-To: References: <20200304222447.1787-1-jpuhlman@mvista.com> Message-ID: On Wed, Mar 4, 2020 at 3:22 PM Khem Raj wrote: > > On Wed, Mar 4, 2020 at 2:25 PM Jeremy A. Puhlman wrote: > > > > From: Jeremy Puhlman > > > > Whether readline is installed on the build host or not > > influences the way gdbm builds. Depend on readline for > > a consistent build. It sounds like configuring with --without-readline would be a better solution? > > This fails to build on a system with readline, and using > > the buildtools-extended installer. > > > > Signed-off-by: Jeremy A. Puhlman > > --- > > meta/recipes-support/gdbm/gdbm_1.18.1.bb | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/meta/recipes-support/gdbm/gdbm_1.18.1.bb b/meta/recipes-support/gdbm/gdbm_1.18.1.bb > > index 7e2efe3c9b..5326184181 100644 > > --- a/meta/recipes-support/gdbm/gdbm_1.18.1.bb > > +++ b/meta/recipes-support/gdbm/gdbm_1.18.1.bb > > @@ -15,6 +15,8 @@ SRC_URI[sha256sum] = "86e613527e5dba544e73208f42b78b7c022d4fa5a6d5498bf18c8d6f74 > > > > inherit autotools gettext texinfo lib_package ptest > > > > +DEPENDS_class-native += "readline" Don't use += with an over-ride. It doesn't do what you might expect. From jpuhlman at mvista.com Wed Mar 4 23:48:03 2020 From: jpuhlman at mvista.com (Jeremy A. Puhlman) Date: Wed, 4 Mar 2020 15:48:03 -0800 Subject: [OE-core] [PATCH] gdbm: add depend on readline for consistent builds In-Reply-To: References: <20200304222447.1787-1-jpuhlman@mvista.com> Message-ID: On 3/4/2020 3:43 PM, Andre McCurdy wrote: > On Wed, Mar 4, 2020 at 3:22 PM Khem Raj wrote: >> On Wed, Mar 4, 2020 at 2:25 PM Jeremy A. Puhlman wrote: >>> From: Jeremy Puhlman >>> >>> Whether readline is installed on the build host or not >>> influences the way gdbm builds. Depend on readline for >>> a consistent build. > It sounds like configuring with --without-readline would be a better solution? Its an either/or. I suggested both in the bug(13714) basically either works. > >>> This fails to build on a system with readline, and using >>> the buildtools-extended installer. >>> >>> Signed-off-by: Jeremy A. Puhlman >>> --- >>> meta/recipes-support/gdbm/gdbm_1.18.1.bb | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git a/meta/recipes-support/gdbm/gdbm_1.18.1.bb b/meta/recipes-support/gdbm/gdbm_1.18.1.bb >>> index 7e2efe3c9b..5326184181 100644 >>> --- a/meta/recipes-support/gdbm/gdbm_1.18.1.bb >>> +++ b/meta/recipes-support/gdbm/gdbm_1.18.1.bb >>> @@ -15,6 +15,8 @@ SRC_URI[sha256sum] = "86e613527e5dba544e73208f42b78b7c022d4fa5a6d5498bf18c8d6f74 >>> >>> inherit autotools gettext texinfo lib_package ptest >>> >>> +DEPENDS_class-native += "readline" > Don't use += with an over-ride. It doesn't do what you might expect. Okay. -- Jeremy A. Puhlman jpuhlman at mvista.com From armccurdy at gmail.com Thu Mar 5 00:03:50 2020 From: armccurdy at gmail.com (Andre McCurdy) Date: Wed, 4 Mar 2020 16:03:50 -0800 Subject: [OE-core] [PATCH] gdbm: add depend on readline for consistent builds In-Reply-To: References: <20200304222447.1787-1-jpuhlman@mvista.com> Message-ID: On Wed, Mar 4, 2020 at 3:48 PM Jeremy A. Puhlman wrote: > On 3/4/2020 3:43 PM, Andre McCurdy wrote: > > On Wed, Mar 4, 2020 at 3:22 PM Khem Raj wrote: > >> On Wed, Mar 4, 2020 at 2:25 PM Jeremy A. Puhlman wrote: > >>> From: Jeremy Puhlman > >>> > >>> Whether readline is installed on the build host or not > >>> influences the way gdbm builds. Depend on readline for > >>> a consistent build. > > It sounds like configuring with --without-readline would be a better solution? > Its an either/or. I suggested both in the bug(13714) basically either works. If both approaches work then an explicit configure option is preferred. > >>> This fails to build on a system with readline, and using > >>> the buildtools-extended installer. > >>> > >>> Signed-off-by: Jeremy A. Puhlman > >>> --- > >>> meta/recipes-support/gdbm/gdbm_1.18.1.bb | 2 ++ > >>> 1 file changed, 2 insertions(+) > >>> > >>> diff --git a/meta/recipes-support/gdbm/gdbm_1.18.1.bb b/meta/recipes-support/gdbm/gdbm_1.18.1.bb > >>> index 7e2efe3c9b..5326184181 100644 > >>> --- a/meta/recipes-support/gdbm/gdbm_1.18.1.bb > >>> +++ b/meta/recipes-support/gdbm/gdbm_1.18.1.bb > >>> @@ -15,6 +15,8 @@ SRC_URI[sha256sum] = "86e613527e5dba544e73208f42b78b7c022d4fa5a6d5498bf18c8d6f74 > >>> > >>> inherit autotools gettext texinfo lib_package ptest > >>> > >>> +DEPENDS_class-native += "readline" > > Don't use += with an over-ride. It doesn't do what you might expect. > Okay. > > -- > Jeremy A. Puhlman > jpuhlman at mvista.com > From jpuhlman at mvista.com Thu Mar 5 00:04:49 2020 From: jpuhlman at mvista.com (Jeremy A. Puhlman) Date: Wed, 4 Mar 2020 16:04:49 -0800 Subject: [OE-core] [PATCH] gdbm: add depend on readline for consistent builds Message-ID: <20200305000449.6207-1-jpuhlman@mvista.com> From: Jeremy Puhlman Whether readline is installed on the build host or not influences the way gdbm builds. Depend on readline for a consistent build. This fails to build on a system with readline, and using the buildtools-extended installer. Signed-off-by: Jeremy A. Puhlman --- meta/recipes-support/gdbm/gdbm_1.18.1.bb | 2 ++ 1 file changed, 2 insertions(+) diff --git a/meta/recipes-support/gdbm/gdbm_1.18.1.bb b/meta/recipes-support/gdbm/gdbm_1.18.1.bb index 7e2efe3c9b..5326184181 100644 --- a/meta/recipes-support/gdbm/gdbm_1.18.1.bb +++ b/meta/recipes-support/gdbm/gdbm_1.18.1.bb @@ -15,6 +15,8 @@ SRC_URI[sha256sum] = "86e613527e5dba544e73208f42b78b7c022d4fa5a6d5498bf18c8d6f74 inherit autotools gettext texinfo lib_package ptest +DEPENDS_class-native += "readline" + # Needed for dbm python module EXTRA_OECONF = "-enable-libgdbm-compat" -- 2.20.1 From jpuhlman at mvista.com Thu Mar 5 00:05:48 2020 From: jpuhlman at mvista.com (Jeremy A. Puhlman) Date: Wed, 4 Mar 2020 16:05:48 -0800 Subject: [OE-core] [PATCH] gdbm-native: disable readline for the native package. Message-ID: <20200305000548.6357-1-jpuhlman@mvista.com> From: Jeremy Puhlman --- meta/recipes-support/gdbm/gdbm_1.18.1.bb | 2 ++ 1 file changed, 2 insertions(+) diff --git a/meta/recipes-support/gdbm/gdbm_1.18.1.bb b/meta/recipes-support/gdbm/gdbm_1.18.1.bb index 5326184181..52e35c8c2e 100644 --- a/meta/recipes-support/gdbm/gdbm_1.18.1.bb +++ b/meta/recipes-support/gdbm/gdbm_1.18.1.bb @@ -20,6 +20,8 @@ DEPENDS_class-native += "readline" # Needed for dbm python module EXTRA_OECONF = "-enable-libgdbm-compat" +EXTRA_OECONF_class-native = "--without-readline" + # Stop presence of dbm/nbdm on the host contaminating builds CACHED_CONFIGUREVARS += "ac_cv_lib_ndbm_main=no ac_cv_lib_dbm_main=no" -- 2.20.1 From jpuhlman at mvista.com Thu Mar 5 00:07:22 2020 From: jpuhlman at mvista.com (Jeremy A. Puhlman) Date: Wed, 4 Mar 2020 16:07:22 -0800 Subject: [OE-core] [PATCH] gdbm: add depend on readline for consistent builds In-Reply-To: References: <20200304222447.1787-1-jpuhlman@mvista.com> Message-ID: On 3/4/2020 4:03 PM, Andre McCurdy wrote: > On Wed, Mar 4, 2020 at 3:48 PM Jeremy A. Puhlman wrote: >> On 3/4/2020 3:43 PM, Andre McCurdy wrote: >>> On Wed, Mar 4, 2020 at 3:22 PM Khem Raj wrote: >>>> On Wed, Mar 4, 2020 at 2:25 PM Jeremy A. Puhlman wrote: >>>>> From: Jeremy Puhlman >>>>> >>>>> Whether readline is installed on the build host or not >>>>> influences the way gdbm builds. Depend on readline for >>>>> a consistent build. >>> It sounds like configuring with --without-readline would be a better solution? >> Its an either/or. I suggested both in the bug(13714) basically either works. > If both approaches work then an explicit configure option is preferred. Alternate patch sent. > >>>>> This fails to build on a system with readline, and using >>>>> the buildtools-extended installer. >>>>> >>>>> Signed-off-by: Jeremy A. Puhlman >>>>> --- >>>>> meta/recipes-support/gdbm/gdbm_1.18.1.bb | 2 ++ >>>>> 1 file changed, 2 insertions(+) >>>>> >>>>> diff --git a/meta/recipes-support/gdbm/gdbm_1.18.1.bb b/meta/recipes-support/gdbm/gdbm_1.18.1.bb >>>>> index 7e2efe3c9b..5326184181 100644 >>>>> --- a/meta/recipes-support/gdbm/gdbm_1.18.1.bb >>>>> +++ b/meta/recipes-support/gdbm/gdbm_1.18.1.bb >>>>> @@ -15,6 +15,8 @@ SRC_URI[sha256sum] = "86e613527e5dba544e73208f42b78b7c022d4fa5a6d5498bf18c8d6f74 >>>>> >>>>> inherit autotools gettext texinfo lib_package ptest >>>>> >>>>> +DEPENDS_class-native += "readline" >>> Don't use += with an over-ride. It doesn't do what you might expect. >> Okay. >> >> -- >> Jeremy A. Puhlman >> jpuhlman at mvista.com >> -- Jeremy A. Puhlman jpuhlman at mvista.com From armccurdy at gmail.com Thu Mar 5 00:16:14 2020 From: armccurdy at gmail.com (Andre McCurdy) Date: Wed, 4 Mar 2020 16:16:14 -0800 Subject: [OE-core] [PATCH] gdbm-native: disable readline for the native package. In-Reply-To: <20200305000548.6357-1-jpuhlman@mvista.com> References: <20200305000548.6357-1-jpuhlman@mvista.com> Message-ID: On Wed, Mar 4, 2020 at 4:05 PM Jeremy A. Puhlman wrote: > > From: Jeremy Puhlman > > --- > meta/recipes-support/gdbm/gdbm_1.18.1.bb | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/meta/recipes-support/gdbm/gdbm_1.18.1.bb b/meta/recipes-support/gdbm/gdbm_1.18.1.bb > index 5326184181..52e35c8c2e 100644 > --- a/meta/recipes-support/gdbm/gdbm_1.18.1.bb > +++ b/meta/recipes-support/gdbm/gdbm_1.18.1.bb > @@ -20,6 +20,8 @@ DEPENDS_class-native += "readline" > # Needed for dbm python module > EXTRA_OECONF = "-enable-libgdbm-compat" > > +EXTRA_OECONF_class-native = "--without-readline" Assuming the target version is being built without readline support (presumably that's true as the recipe doesn't indicate any dependency on readline, but you should double check) then this configure option should be passed in all cases, not just for native. > # Stop presence of dbm/nbdm on the host contaminating builds > CACHED_CONFIGUREVARS += "ac_cv_lib_ndbm_main=no ac_cv_lib_dbm_main=no" > > -- > 2.20.1 > > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core at lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core From jpuhlman at mvista.com Thu Mar 5 00:18:25 2020 From: jpuhlman at mvista.com (Jeremy A. Puhlman) Date: Wed, 4 Mar 2020 16:18:25 -0800 Subject: [OE-core] [PATCH] gdbm-native: disable readline for the native package. In-Reply-To: References: <20200305000548.6357-1-jpuhlman@mvista.com> Message-ID: On 3/4/2020 4:16 PM, Andre McCurdy wrote: > On Wed, Mar 4, 2020 at 4:05 PM Jeremy A. Puhlman wrote: >> From: Jeremy Puhlman >> >> --- >> meta/recipes-support/gdbm/gdbm_1.18.1.bb | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/meta/recipes-support/gdbm/gdbm_1.18.1.bb b/meta/recipes-support/gdbm/gdbm_1.18.1.bb >> index 5326184181..52e35c8c2e 100644 >> --- a/meta/recipes-support/gdbm/gdbm_1.18.1.bb >> +++ b/meta/recipes-support/gdbm/gdbm_1.18.1.bb >> @@ -20,6 +20,8 @@ DEPENDS_class-native += "readline" >> # Needed for dbm python module >> EXTRA_OECONF = "-enable-libgdbm-compat" >> >> +EXTRA_OECONF_class-native = "--without-readline" > Assuming the target version is being built without readline support > (presumably that's true as the recipe doesn't indicate any dependency > on readline, but you should double check) then this configure option > should be passed in all cases, not just for native. There is not explicit dependency which is why we are here in the first place for native. > >> # Stop presence of dbm/nbdm on the host contaminating builds >> CACHED_CONFIGUREVARS += "ac_cv_lib_ndbm_main=no ac_cv_lib_dbm_main=no" >> >> -- >> 2.20.1 >> >> -- >> _______________________________________________ >> Openembedded-core mailing list >> Openembedded-core at lists.openembedded.org >> http://lists.openembedded.org/mailman/listinfo/openembedded-core -- Jeremy A. Puhlman jpuhlman at mvista.com From armccurdy at gmail.com Thu Mar 5 00:26:35 2020 From: armccurdy at gmail.com (Andre McCurdy) Date: Wed, 4 Mar 2020 16:26:35 -0800 Subject: [OE-core] [PATCH] gdbm-native: disable readline for the native package. In-Reply-To: References: <20200305000548.6357-1-jpuhlman@mvista.com> Message-ID: On Wed, Mar 4, 2020 at 4:18 PM Jeremy A. Puhlman wrote: > On 3/4/2020 4:16 PM, Andre McCurdy wrote: > > On Wed, Mar 4, 2020 at 4:05 PM Jeremy A. Puhlman wrote: > >> From: Jeremy Puhlman > >> > >> --- > >> meta/recipes-support/gdbm/gdbm_1.18.1.bb | 2 ++ > >> 1 file changed, 2 insertions(+) > >> > >> diff --git a/meta/recipes-support/gdbm/gdbm_1.18.1.bb b/meta/recipes-support/gdbm/gdbm_1.18.1.bb > >> index 5326184181..52e35c8c2e 100644 > >> --- a/meta/recipes-support/gdbm/gdbm_1.18.1.bb > >> +++ b/meta/recipes-support/gdbm/gdbm_1.18.1.bb > >> @@ -20,6 +20,8 @@ DEPENDS_class-native += "readline" > >> # Needed for dbm python module > >> EXTRA_OECONF = "-enable-libgdbm-compat" > >> > >> +EXTRA_OECONF_class-native = "--without-readline" > > Assuming the target version is being built without readline support > > (presumably that's true as the recipe doesn't indicate any dependency > > on readline, but you should double check) then this configure option > > should be passed in all cases, not just for native. > There is not explicit dependency which is why we are here in the first > place for native. Right. The native issue can be fixed and the target case made clearer by adding the explicit configure option. Point is just that you shouldn't limit the explicit configure option to native if it's applicable for target too. > > > >> # Stop presence of dbm/nbdm on the host contaminating builds > >> CACHED_CONFIGUREVARS += "ac_cv_lib_ndbm_main=no ac_cv_lib_dbm_main=no" > >> > >> -- > >> 2.20.1 > >> > >> -- > >> _______________________________________________ > >> Openembedded-core mailing list > >> Openembedded-core at lists.openembedded.org > >> http://lists.openembedded.org/mailman/listinfo/openembedded-core > > -- > Jeremy A. Puhlman > jpuhlman at mvista.com > From joe.slater at windriver.com Thu Mar 5 00:30:20 2020 From: joe.slater at windriver.com (Joe Slater) Date: Wed, 4 Mar 2020 16:30:20 -0800 Subject: [OE-core] [oe-core][PATCH 1/1] dnf: fix python3 syntax warning Message-ID: <20200305003020.5164-1-joe.slater@windriver.com> Backport from dnf version 4.2.7. Signed-off-by: Joe Slater --- .../dnf/dnf/Fix-SyntaxWarning.patch | 34 ++++++++++++++++++++++ meta/recipes-devtools/dnf/dnf_4.2.2.bb | 1 + 2 files changed, 35 insertions(+) create mode 100644 meta/recipes-devtools/dnf/dnf/Fix-SyntaxWarning.patch diff --git a/meta/recipes-devtools/dnf/dnf/Fix-SyntaxWarning.patch b/meta/recipes-devtools/dnf/dnf/Fix-SyntaxWarning.patch new file mode 100644 index 0000000..1bd8b09 --- /dev/null +++ b/meta/recipes-devtools/dnf/dnf/Fix-SyntaxWarning.patch @@ -0,0 +1,34 @@ +From 23c5b15efe42e5e6ee695e54798bac248532d8d6 Mon Sep 17 00:00:00 2001 + +Date: Tue, 28 May 2019 13:14:51 +0200 +Subject: [oe-core][PATCH 1/1] Fix SyntaxWarning: "is" with a literal. Did you + mean "=="? + +--- + dnf/cli/commands/repoquery.py | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) +--- + +Unchanged. Appears in version 4.2.7. + +Upstream-Status: Backport [git://github.com/rpm-software-management/dnf.git] + +Signed-off-by: Joe Slater + + +diff --git a/dnf/cli/commands/repoquery.py b/dnf/cli/commands/repoquery.py +index 941a470..63fc668 100644 +--- a/dnf/cli/commands/repoquery.py ++++ b/dnf/cli/commands/repoquery.py +@@ -611,7 +611,7 @@ class RepoQueryCommand(commands.Command): + + def tree_seed(self, query, aquery, opts, level=-1, usedpkgs=None): + for pkg in sorted(set(query.run()), key=lambda p: p.name): +- usedpkgs = set() if usedpkgs is None or level is -1 else usedpkgs ++ usedpkgs = set() if usedpkgs is None or level == -1 else usedpkgs + if pkg.name.startswith("rpmlib") or pkg.name.startswith("solvable"): + return + self.grow_tree(level, pkg, opts) +-- +2.7.4 + diff --git a/meta/recipes-devtools/dnf/dnf_4.2.2.bb b/meta/recipes-devtools/dnf/dnf_4.2.2.bb index f6e616e..5244e10 100644 --- a/meta/recipes-devtools/dnf/dnf_4.2.2.bb +++ b/meta/recipes-devtools/dnf/dnf_4.2.2.bb @@ -13,6 +13,7 @@ SRC_URI = "git://github.com/rpm-software-management/dnf.git \ file://0005-Do-not-prepend-installroot-to-logdir.patch \ file://0029-Do-not-set-PYTHON_INSTALL_DIR-by-running-python.patch \ file://0030-Run-python-scripts-using-env.patch \ + file://Fix-SyntaxWarning.patch \ " SRCREV = "9947306a55271b8b7c9e2b6e3b7d582885b6045d" -- 2.7.4 From jpuhlman at mvista.com Thu Mar 5 00:32:20 2020 From: jpuhlman at mvista.com (Jeremy A. Puhlman) Date: Wed, 4 Mar 2020 16:32:20 -0800 Subject: [OE-core] [PATCH v2] gdbm-native: disable readline for the native package. Message-ID: <20200305003220.7961-1-jpuhlman@mvista.com> Turns off readline for both. Also corrected a typo with enable-libgdbm-compat Signed-off-by: Jeremy A. Puhlman --- meta/recipes-support/gdbm/gdbm_1.18.1.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-support/gdbm/gdbm_1.18.1.bb b/meta/recipes-support/gdbm/gdbm_1.18.1.bb index 7e2efe3c9b..5cb7c558b8 100644 --- a/meta/recipes-support/gdbm/gdbm_1.18.1.bb +++ b/meta/recipes-support/gdbm/gdbm_1.18.1.bb @@ -16,7 +16,7 @@ SRC_URI[sha256sum] = "86e613527e5dba544e73208f42b78b7c022d4fa5a6d5498bf18c8d6f74 inherit autotools gettext texinfo lib_package ptest # Needed for dbm python module -EXTRA_OECONF = "-enable-libgdbm-compat" +EXTRA_OECONF = "--enable-libgdbm-compat --without-readline" # Stop presence of dbm/nbdm on the host contaminating builds CACHED_CONFIGUREVARS += "ac_cv_lib_ndbm_main=no ac_cv_lib_dbm_main=no" -- 2.20.1 From patchwork at patchwork.openembedded.org Thu Mar 5 00:32:30 2020 From: patchwork at patchwork.openembedded.org (Patchwork) Date: Thu, 05 Mar 2020 00:32:30 -0000 Subject: [OE-core] =?utf-8?q?=E2=9C=97_patchtest=3A_failure_for_gdbm-nativ?= =?utf-8?q?e=3A_disable_readline_for_the_native_package=2E?= In-Reply-To: <20200305000548.6357-1-jpuhlman@mvista.com> References: <20200305000548.6357-1-jpuhlman@mvista.com> Message-ID: <20200305003230.2277.95591@do> == Series Details == Series: gdbm-native: disable readline for the native package. Revision: 1 URL : https://patchwork.openembedded.org/series/23104/ 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: * Patch gdbm-native: disable readline for the native package. Issue Patch is missing Signed-off-by [test_signed_off_by_presence] Suggested fix Sign off the patch (either manually or with "git commit --amend -s") If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core at 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 From jpuhlman at mvista.com Thu Mar 5 00:33:10 2020 From: jpuhlman at mvista.com (Jeremy A. Puhlman) Date: Wed, 4 Mar 2020 16:33:10 -0800 Subject: [OE-core] [PATCH v2] gdbm-native: disable readline for the native package. Message-ID: <20200305003310.8052-1-jpuhlman@mvista.com> Turns off readline for both. Also corrected a typo with enable-libgdbm-compat Signed-off-by: Jeremy A. Puhlman --- meta/recipes-support/gdbm/gdbm_1.18.1.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-support/gdbm/gdbm_1.18.1.bb b/meta/recipes-support/gdbm/gdbm_1.18.1.bb index 7e2efe3c9b..5cb7c558b8 100644 --- a/meta/recipes-support/gdbm/gdbm_1.18.1.bb +++ b/meta/recipes-support/gdbm/gdbm_1.18.1.bb @@ -16,7 +16,7 @@ SRC_URI[sha256sum] = "86e613527e5dba544e73208f42b78b7c022d4fa5a6d5498bf18c8d6f74 inherit autotools gettext texinfo lib_package ptest # Needed for dbm python module -EXTRA_OECONF = "-enable-libgdbm-compat" +EXTRA_OECONF = "--enable-libgdbm-compat --without-readline" # Stop presence of dbm/nbdm on the host contaminating builds CACHED_CONFIGUREVARS += "ac_cv_lib_ndbm_main=no ac_cv_lib_dbm_main=no" -- 2.20.1 From changqing.li at windriver.com Thu Mar 5 04:58:25 2020 From: changqing.li at windriver.com (changqing.li at windriver.com) Date: Thu, 5 Mar 2020 12:58:25 +0800 Subject: [OE-core] [PATCH] python-numpy: convert shebang from python to python3 Message-ID: <1583384305-192675-1-git-send-email-changqing.li@windriver.com> From: Changqing Li Signed-off-by: Changqing Li --- ...01-convert-shebang-from-python-to-python3.patch | 579 +++++++++++++++++++++ .../recipes-devtools/python-numpy/python-numpy.inc | 1 + 2 files changed, 580 insertions(+) create mode 100644 meta/recipes-devtools/python-numpy/files/0001-convert-shebang-from-python-to-python3.patch diff --git a/meta/recipes-devtools/python-numpy/files/0001-convert-shebang-from-python-to-python3.patch b/meta/recipes-devtools/python-numpy/files/0001-convert-shebang-from-python-to-python3.patch new file mode 100644 index 0000000..b86e131 --- /dev/null +++ b/meta/recipes-devtools/python-numpy/files/0001-convert-shebang-from-python-to-python3.patch @@ -0,0 +1,579 @@ +From c53237f90e4a3a435a20517552186d394d6d09c8 Mon Sep 17 00:00:00 2001 +From: Changqing Li +Date: Thu, 5 Mar 2020 12:02:35 +0800 +Subject: [PATCH] convert shebang from python to python3 + +Upstream-Status: Backport +[https://github.com/numpy/numpy/commit/583901a074dc65145d3d6136ba7dcd02634d680b] + +Signed-off-by: Changqing Li +--- + doc/DISTUTILS.rst.txt | 2 +- + doc/cdoc/numpyfilter.py | 2 +- + doc/postprocess.py | 2 +- + doc/summarize.py | 2 +- + numpy/distutils/conv_template.py | 2 +- + numpy/distutils/cpuinfo.py | 2 +- + numpy/distutils/from_template.py | 2 +- + numpy/distutils/setup.py | 2 +- + numpy/distutils/system_info.py | 2 +- + numpy/f2py/__init__.py | 2 +- + numpy/f2py/auxfuncs.py | 2 +- + numpy/f2py/capi_maps.py | 2 +- + numpy/f2py/cb_rules.py | 2 +- + numpy/f2py/cfuncs.py | 2 +- + numpy/f2py/common_rules.py | 2 +- + numpy/f2py/crackfortran.py | 2 +- + numpy/f2py/diagnose.py | 2 +- + numpy/f2py/f2py2e.py | 2 +- + numpy/f2py/f90mod_rules.py | 2 +- + numpy/f2py/func2subr.py | 2 +- + numpy/f2py/rules.py | 2 +- + numpy/f2py/setup.py | 2 +- + numpy/f2py/use_rules.py | 2 +- + numpy/linalg/lapack_lite/clapack_scrub.py | 2 +- + numpy/linalg/lapack_lite/make_lite.py | 2 +- + numpy/ma/bench.py | 2 +- + numpy/ma/setup.py | 2 +- + numpy/matrixlib/setup.py | 2 +- + numpy/random/examples/cython/extending.pyx | 2 +- + numpy/random/examples/cython/extending_distributions.pyx | 2 +- + numpy/setup.py | 2 +- + numpy/testing/print_coercion_tables.py | 2 +- + numpy/testing/setup.py | 2 +- + runtests.py | 2 +- + setup.py | 2 +- + tools/c_coverage/c_coverage_report.py | 2 +- + tools/changelog.py | 2 +- + tools/ci/push_docs_to_repo.py | 2 +- + tools/cythonize.py | 2 +- + tools/find_deprecated_escaped_characters.py | 2 +- + tools/refguide_check.py | 2 +- + tools/swig/test/setup.py | 2 +- + tools/swig/test/testArray.py | 2 +- + tools/swig/test/testFarray.py | 2 +- + tools/swig/test/testFlat.py | 2 +- + tools/swig/test/testFortran.py | 2 +- + tools/swig/test/testMatrix.py | 2 +- + tools/swig/test/testSuperTensor.py | 2 +- + tools/swig/test/testTensor.py | 2 +- + tools/swig/test/testVector.py | 2 +- + tools/test-installed-numpy.py | 2 +- + 51 files changed, 51 insertions(+), 51 deletions(-) + +diff --git a/doc/DISTUTILS.rst.txt b/doc/DISTUTILS.rst.txt +index eadde63..2402110 100644 +--- a/doc/DISTUTILS.rst.txt ++++ b/doc/DISTUTILS.rst.txt +@@ -59,7 +59,7 @@ SciPy pure Python package example + + Below is an example of a minimal ``setup.py`` file for a pure SciPy package:: + +- #!/usr/bin/env python ++ #!/usr/bin/env python3 + def configuration(parent_package='',top_path=None): + from numpy.distutils.misc_util import Configuration + config = Configuration('mypackage',parent_package,top_path) +diff --git a/doc/cdoc/numpyfilter.py b/doc/cdoc/numpyfilter.py +index 0ec5069..067bd36 100755 +--- a/doc/cdoc/numpyfilter.py ++++ b/doc/cdoc/numpyfilter.py +@@ -1,4 +1,4 @@ +-#!/usr/bin/env python ++#!/usr/bin/env python3 + """ + numpyfilter.py INPUTFILE + +diff --git a/doc/postprocess.py b/doc/postprocess.py +index 2e50c11..1be6f39 100755 +--- a/doc/postprocess.py ++++ b/doc/postprocess.py +@@ -1,4 +1,4 @@ +-#!/usr/bin/env python ++#!/usr/bin/env python3 + """ + %prog MODE FILES... + +diff --git a/doc/summarize.py b/doc/summarize.py +index cfce271..563af02 100755 +--- a/doc/summarize.py ++++ b/doc/summarize.py +@@ -1,4 +1,4 @@ +-#!/usr/bin/env python ++#!/usr/bin/env python3 + """ + summarize.py + +diff --git a/numpy/distutils/conv_template.py b/numpy/distutils/conv_template.py +index 3bcb7b8..88432c8 100644 +--- a/numpy/distutils/conv_template.py ++++ b/numpy/distutils/conv_template.py +@@ -1,4 +1,4 @@ +-#!/usr/bin/env python ++#!/usr/bin/env python3 + """ + takes templated file .xxx.src and produces .xxx file where .xxx is + .i or .c or .h, using the following template rules +diff --git a/numpy/distutils/cpuinfo.py b/numpy/distutils/cpuinfo.py +index 5802993..7f6742e 100644 +--- a/numpy/distutils/cpuinfo.py ++++ b/numpy/distutils/cpuinfo.py +@@ -1,4 +1,4 @@ +-#!/usr/bin/env python ++#!/usr/bin/env python3 + """ + cpuinfo + +diff --git a/numpy/distutils/from_template.py b/numpy/distutils/from_template.py +index c5c1163..af75971 100644 +--- a/numpy/distutils/from_template.py ++++ b/numpy/distutils/from_template.py +@@ -1,4 +1,4 @@ +-#!/usr/bin/env python ++#!/usr/bin/env python3 + """ + + process_file(filename) +diff --git a/numpy/distutils/setup.py b/numpy/distutils/setup.py +index 82a53bd..646921b 100644 +--- a/numpy/distutils/setup.py ++++ b/numpy/distutils/setup.py +@@ -1,4 +1,4 @@ +-#!/usr/bin/env python ++#!/usr/bin/env python3 + from __future__ import division, print_function + + def configuration(parent_package='',top_path=None): +diff --git a/numpy/distutils/system_info.py b/numpy/distutils/system_info.py +index f94dce1..df526f6 100644 +--- a/numpy/distutils/system_info.py ++++ b/numpy/distutils/system_info.py +@@ -1,4 +1,4 @@ +-#!/usr/bin/env python ++#!/usr/bin/env python3 + """ + This file defines a set of system_info classes for getting + information about various resources (libraries, library directories, +diff --git a/numpy/f2py/__init__.py b/numpy/f2py/__init__.py +index d146739..0a83b99 100644 +--- a/numpy/f2py/__init__.py ++++ b/numpy/f2py/__init__.py +@@ -1,4 +1,4 @@ +-#!/usr/bin/env python ++#!/usr/bin/env python3 + """Fortran to Python Interface Generator. + + """ +diff --git a/numpy/f2py/auxfuncs.py b/numpy/f2py/auxfuncs.py +index 404bdbd..d23d959 100644 +--- a/numpy/f2py/auxfuncs.py ++++ b/numpy/f2py/auxfuncs.py +@@ -1,4 +1,4 @@ +-#!/usr/bin/env python ++#!/usr/bin/env python3 + """ + + Auxiliary functions for f2py2e. +diff --git a/numpy/f2py/capi_maps.py b/numpy/f2py/capi_maps.py +index c41dd77..a3e2dc2 100644 +--- a/numpy/f2py/capi_maps.py ++++ b/numpy/f2py/capi_maps.py +@@ -1,4 +1,4 @@ +-#!/usr/bin/env python ++#!/usr/bin/env python3 + """ + + Copyright 1999,2000 Pearu Peterson all rights reserved, +diff --git a/numpy/f2py/cb_rules.py b/numpy/f2py/cb_rules.py +index 183d7c2..93e93fe 100644 +--- a/numpy/f2py/cb_rules.py ++++ b/numpy/f2py/cb_rules.py +@@ -1,4 +1,4 @@ +-#!/usr/bin/env python ++#!/usr/bin/env python3 + """ + + Build call-back mechanism for f2py2e. +diff --git a/numpy/f2py/cfuncs.py b/numpy/f2py/cfuncs.py +index d59b630..3847745 100644 +--- a/numpy/f2py/cfuncs.py ++++ b/numpy/f2py/cfuncs.py +@@ -1,4 +1,4 @@ +-#!/usr/bin/env python ++#!/usr/bin/env python3 + """ + + C declarations, CPP macros, and C functions for f2py2e. +diff --git a/numpy/f2py/common_rules.py b/numpy/f2py/common_rules.py +index 62c1ba2..c1825d4 100644 +--- a/numpy/f2py/common_rules.py ++++ b/numpy/f2py/common_rules.py +@@ -1,4 +1,4 @@ +-#!/usr/bin/env python ++#!/usr/bin/env python3 + """ + + Build common block mechanism for f2py2e. +diff --git a/numpy/f2py/crackfortran.py b/numpy/f2py/crackfortran.py +index 2aaf5d7..fb5ef2f 100755 +--- a/numpy/f2py/crackfortran.py ++++ b/numpy/f2py/crackfortran.py +@@ -1,4 +1,4 @@ +-#!/usr/bin/env python ++#!/usr/bin/env python3 + """ + crackfortran --- read fortran (77,90) code and extract declaration information. + +diff --git a/numpy/f2py/diagnose.py b/numpy/f2py/diagnose.py +index 0241fed..6c0304c 100644 +--- a/numpy/f2py/diagnose.py ++++ b/numpy/f2py/diagnose.py +@@ -1,4 +1,4 @@ +-#!/usr/bin/env python ++#!/usr/bin/env python3 + from __future__ import division, absolute_import, print_function + + import os +diff --git a/numpy/f2py/f2py2e.py b/numpy/f2py/f2py2e.py +index 110337f..c0789f6 100755 +--- a/numpy/f2py/f2py2e.py ++++ b/numpy/f2py/f2py2e.py +@@ -1,4 +1,4 @@ +-#!/usr/bin/env python ++#!/usr/bin/env python3 + """ + + f2py2e - Fortran to Python C/API generator. 2nd Edition. +diff --git a/numpy/f2py/f90mod_rules.py b/numpy/f2py/f90mod_rules.py +index 85eae80..70be128 100644 +--- a/numpy/f2py/f90mod_rules.py ++++ b/numpy/f2py/f90mod_rules.py +@@ -1,4 +1,4 @@ +-#!/usr/bin/env python ++#!/usr/bin/env python3 + """ + + Build F90 module support for f2py2e. +diff --git a/numpy/f2py/func2subr.py b/numpy/f2py/func2subr.py +index 6010d5a..fdea0c2 100644 +--- a/numpy/f2py/func2subr.py ++++ b/numpy/f2py/func2subr.py +@@ -1,4 +1,4 @@ +-#!/usr/bin/env python ++#!/usr/bin/env python3 + """ + + Rules for building C/API module with f2py2e. +diff --git a/numpy/f2py/rules.py b/numpy/f2py/rules.py +index 1b41498..790d197 100755 +--- a/numpy/f2py/rules.py ++++ b/numpy/f2py/rules.py +@@ -1,4 +1,4 @@ +-#!/usr/bin/env python ++#!/usr/bin/env python3 + """ + + Rules for building C/API module with f2py2e. +diff --git a/numpy/f2py/setup.py b/numpy/f2py/setup.py +index c0c50ce..044c9f2 100644 +--- a/numpy/f2py/setup.py ++++ b/numpy/f2py/setup.py +@@ -1,4 +1,4 @@ +-#!/usr/bin/env python ++#!/usr/bin/env python3 + """ + setup.py for installing F2PY + +diff --git a/numpy/f2py/use_rules.py b/numpy/f2py/use_rules.py +index 6f44f16..8214f42 100644 +--- a/numpy/f2py/use_rules.py ++++ b/numpy/f2py/use_rules.py +@@ -1,4 +1,4 @@ +-#!/usr/bin/env python ++#!/usr/bin/env python3 + """ + + Build 'use others module data' mechanism for f2py2e. +diff --git a/numpy/linalg/lapack_lite/clapack_scrub.py b/numpy/linalg/lapack_lite/clapack_scrub.py +index 4345861..91e66e7 100644 +--- a/numpy/linalg/lapack_lite/clapack_scrub.py ++++ b/numpy/linalg/lapack_lite/clapack_scrub.py +@@ -1,4 +1,4 @@ +-#!/usr/bin/env python ++#!/usr/bin/env python3 + from __future__ import division, absolute_import, print_function + + import sys, os +diff --git a/numpy/linalg/lapack_lite/make_lite.py b/numpy/linalg/lapack_lite/make_lite.py +index 61102d6..0211f4e 100755 +--- a/numpy/linalg/lapack_lite/make_lite.py ++++ b/numpy/linalg/lapack_lite/make_lite.py +@@ -1,4 +1,4 @@ +-#!/usr/bin/env python ++#!/usr/bin/env python3 + """ + Usage: make_lite.py + +diff --git a/numpy/ma/bench.py b/numpy/ma/bench.py +index a9ba42d..a377436 100644 +--- a/numpy/ma/bench.py ++++ b/numpy/ma/bench.py +@@ -1,4 +1,4 @@ +-#! /usr/bin/env python ++#!/usr/bin/env python3 + # -*- coding: utf-8 -*- + + from __future__ import division, print_function +diff --git a/numpy/ma/setup.py b/numpy/ma/setup.py +index d1d6c89..a04b79b 100644 +--- a/numpy/ma/setup.py ++++ b/numpy/ma/setup.py +@@ -1,4 +1,4 @@ +-#!/usr/bin/env python ++#!/usr/bin/env python3 + from __future__ import division, print_function + + def configuration(parent_package='',top_path=None): +diff --git a/numpy/matrixlib/setup.py b/numpy/matrixlib/setup.py +index d0981d6..57534d1 100644 +--- a/numpy/matrixlib/setup.py ++++ b/numpy/matrixlib/setup.py +@@ -1,4 +1,4 @@ +-#!/usr/bin/env python ++#!/usr/bin/env python3 + from __future__ import division, print_function + + def configuration(parent_package='', top_path=None): +diff --git a/numpy/random/examples/cython/extending.pyx b/numpy/random/examples/cython/extending.pyx +index a6a4ba4..33f28f9 100644 +--- a/numpy/random/examples/cython/extending.pyx ++++ b/numpy/random/examples/cython/extending.pyx +@@ -1,4 +1,4 @@ +-#!/usr/bin/env python ++#!/usr/bin/env python3 + #cython: language_level=3 + + from libc.stdint cimport uint32_t +diff --git a/numpy/random/examples/cython/extending_distributions.pyx b/numpy/random/examples/cython/extending_distributions.pyx +index 3cefec9..7a526ab 100644 +--- a/numpy/random/examples/cython/extending_distributions.pyx ++++ b/numpy/random/examples/cython/extending_distributions.pyx +@@ -1,4 +1,4 @@ +-#!/usr/bin/env python ++#!/usr/bin/env python3 + #cython: language_level=3 + """ + This file shows how the distributions that are accessed through +diff --git a/numpy/setup.py b/numpy/setup.py +index 4ccdaee..db06c82 100644 +--- a/numpy/setup.py ++++ b/numpy/setup.py +@@ -1,4 +1,4 @@ +-#!/usr/bin/env python ++#!/usr/bin/env python3 + from __future__ import division, print_function + + +diff --git a/numpy/testing/print_coercion_tables.py b/numpy/testing/print_coercion_tables.py +index 3a359f4..a9c5363 100755 +--- a/numpy/testing/print_coercion_tables.py ++++ b/numpy/testing/print_coercion_tables.py +@@ -1,4 +1,4 @@ +-#!/usr/bin/env python ++#!/usr/bin/env python3 + """Prints type-coercion tables for the built-in NumPy types + + """ +diff --git a/numpy/testing/setup.py b/numpy/testing/setup.py +index 7c3f2fb..bd315ee 100755 +--- a/numpy/testing/setup.py ++++ b/numpy/testing/setup.py +@@ -1,4 +1,4 @@ +-#!/usr/bin/env python ++#!/usr/bin/env python3 + from __future__ import division, print_function + + +diff --git a/runtests.py b/runtests.py +index 23245ae..cafdb92 100755 +--- a/runtests.py ++++ b/runtests.py +@@ -1,4 +1,4 @@ +-#!/usr/bin/env python ++#!/usr/bin/env python3 + """ + runtests.py [OPTIONS] [-- ARGS] + +diff --git a/setup.py b/setup.py +index a205913..010884f 100755 +--- a/setup.py ++++ b/setup.py +@@ -1,4 +1,4 @@ +-#!/usr/bin/env python ++#!/usr/bin/env python3 + """ NumPy is the fundamental package for array computing with Python. + + It provides: +diff --git a/tools/c_coverage/c_coverage_report.py b/tools/c_coverage/c_coverage_report.py +index 327f6dc..8837684 100755 +--- a/tools/c_coverage/c_coverage_report.py ++++ b/tools/c_coverage/c_coverage_report.py +@@ -1,4 +1,4 @@ +-#!/usr/bin/env python ++#!/usr/bin/env python3 + """ + A script to create C code-coverage reports based on the output of + valgrind's callgrind tool. +diff --git a/tools/changelog.py b/tools/changelog.py +index b135b14..5d8b33c 100755 +--- a/tools/changelog.py ++++ b/tools/changelog.py +@@ -1,4 +1,4 @@ +-#!/usr/bin/env python ++#!/usr/bin/env python3 + # -*- encoding:utf-8 -*- + """ + Script to generate contributor and pull request lists +diff --git a/tools/ci/push_docs_to_repo.py b/tools/ci/push_docs_to_repo.py +index a989668..ae53054 100755 +--- a/tools/ci/push_docs_to_repo.py ++++ b/tools/ci/push_docs_to_repo.py +@@ -1,4 +1,4 @@ +-#!/usr/bin/env python ++#!/usr/bin/env python3 + + import argparse + import subprocess +diff --git a/tools/cythonize.py b/tools/cythonize.py +index c81b72d..c1d4384 100755 +--- a/tools/cythonize.py ++++ b/tools/cythonize.py +@@ -1,4 +1,4 @@ +-#!/usr/bin/env python ++#!/usr/bin/env python3 + """ cythonize + + Cythonize pyx files into C files as needed. +diff --git a/tools/find_deprecated_escaped_characters.py b/tools/find_deprecated_escaped_characters.py +index 6f90001..10e0378 100644 +--- a/tools/find_deprecated_escaped_characters.py ++++ b/tools/find_deprecated_escaped_characters.py +@@ -1,4 +1,4 @@ +-#! /usr/bin/env python ++#!/usr/bin/env python3 + r""" + Look for escape sequences deprecated in Python 3.6. + +diff --git a/tools/refguide_check.py b/tools/refguide_check.py +index c208072..798e322 100644 +--- a/tools/refguide_check.py ++++ b/tools/refguide_check.py +@@ -1,4 +1,4 @@ +-#!/usr/bin/env python ++#!/usr/bin/env python3 + """ + refguide_check.py [OPTIONS] [-- ARGS] + +diff --git a/tools/swig/test/setup.py b/tools/swig/test/setup.py +index 4ff870e..f8f05e6 100755 +--- a/tools/swig/test/setup.py ++++ b/tools/swig/test/setup.py +@@ -1,4 +1,4 @@ +-#! /usr/bin/env python ++#!/usr/bin/env python3 + from __future__ import division, print_function + + # System imports +diff --git a/tools/swig/test/testArray.py b/tools/swig/test/testArray.py +index 8d9c797..54ffe71 100755 +--- a/tools/swig/test/testArray.py ++++ b/tools/swig/test/testArray.py +@@ -1,4 +1,4 @@ +-#! /usr/bin/env python ++#!/usr/bin/env python3 + from __future__ import division, absolute_import, print_function + + # System imports +diff --git a/tools/swig/test/testFarray.py b/tools/swig/test/testFarray.py +index 0037dc9..bedf384 100755 +--- a/tools/swig/test/testFarray.py ++++ b/tools/swig/test/testFarray.py +@@ -1,4 +1,4 @@ +-#! /usr/bin/env python ++#!/usr/bin/env python3 + from __future__ import division, absolute_import, print_function + + # System imports +diff --git a/tools/swig/test/testFlat.py b/tools/swig/test/testFlat.py +index 71be277..55034bf 100755 +--- a/tools/swig/test/testFlat.py ++++ b/tools/swig/test/testFlat.py +@@ -1,4 +1,4 @@ +-#! /usr/bin/env python ++#!/usr/bin/env python3 + from __future__ import division, absolute_import, print_function + + # System imports +diff --git a/tools/swig/test/testFortran.py b/tools/swig/test/testFortran.py +index 426e894..0f7d0e6 100644 +--- a/tools/swig/test/testFortran.py ++++ b/tools/swig/test/testFortran.py +@@ -1,4 +1,4 @@ +-#! /usr/bin/env python ++#!/usr/bin/env python3 + from __future__ import division, absolute_import, print_function + + # System imports +diff --git a/tools/swig/test/testMatrix.py b/tools/swig/test/testMatrix.py +index 065be0d..854a23c 100755 +--- a/tools/swig/test/testMatrix.py ++++ b/tools/swig/test/testMatrix.py +@@ -1,4 +1,4 @@ +-#! /usr/bin/env python ++#!/usr/bin/env python3 + from __future__ import division, absolute_import, print_function + + # System imports +diff --git a/tools/swig/test/testSuperTensor.py b/tools/swig/test/testSuperTensor.py +index 97fe80c..31b63d0 100644 +--- a/tools/swig/test/testSuperTensor.py ++++ b/tools/swig/test/testSuperTensor.py +@@ -1,4 +1,4 @@ +-#! /usr/bin/env python ++#!/usr/bin/env python3 + from __future__ import division, print_function + + # System imports +diff --git a/tools/swig/test/testTensor.py b/tools/swig/test/testTensor.py +index ac1b749..f47d9e8 100755 +--- a/tools/swig/test/testTensor.py ++++ b/tools/swig/test/testTensor.py +@@ -1,4 +1,4 @@ +-#! /usr/bin/env python ++#!/usr/bin/env python3 + from __future__ import division, absolute_import, print_function + + # System imports +diff --git a/tools/swig/test/testVector.py b/tools/swig/test/testVector.py +index 45e763b..067b922 100755 +--- a/tools/swig/test/testVector.py ++++ b/tools/swig/test/testVector.py +@@ -1,4 +1,4 @@ +-#! /usr/bin/env python ++#!/usr/bin/env python3 + from __future__ import division, absolute_import, print_function + + # System imports +diff --git a/tools/test-installed-numpy.py b/tools/test-installed-numpy.py +index 5240253..fd7541c 100755 +--- a/tools/test-installed-numpy.py ++++ b/tools/test-installed-numpy.py +@@ -1,4 +1,4 @@ +-#!/usr/bin/env python ++#!/usr/bin/env python3 + from __future__ import division, absolute_import, print_function + + # A simple script to test the installed version of numpy by calling +-- +2.7.4 + diff --git a/meta/recipes-devtools/python-numpy/python-numpy.inc b/meta/recipes-devtools/python-numpy/python-numpy.inc index 8413434..42032a0 100644 --- a/meta/recipes-devtools/python-numpy/python-numpy.inc +++ b/meta/recipes-devtools/python-numpy/python-numpy.inc @@ -8,6 +8,7 @@ SRCNAME = "numpy" SRC_URI = "https://github.com/${SRCNAME}/${SRCNAME}/releases/download/v${PV}/${SRCNAME}-${PV}.tar.gz \ file://0001-Don-t-search-usr-and-so-on-for-libraries-by-default-.patch \ file://0001-numpy-random-setup.py-remove-the-detection-of-x86-ta.patch \ + file://0001-convert-shebang-from-python-to-python3.patch \ " SRC_URI[md5sum] = "9147c3ee75e58d657b5b8b5a4f3564e0" SRC_URI[sha256sum] = "fb0415475e673cb9a6dd816df999e0ab9f86fa3af2b1770944e7288d2bea4ac9" -- 2.7.4 From pbarker at konsulko.com Thu Mar 5 09:28:55 2020 From: pbarker at konsulko.com (Paul Barker) Date: Thu, 5 Mar 2020 09:28:55 +0000 Subject: [OE-core] [PATCH 1/2] wic: Fix permissions when using exclude or include path In-Reply-To: References: <20200304083438.1022216-1-ricardo@ribalda.com> <20200304095334.1f20ddd9@ub1910> Message-ID: <20200305092855.1f9ccae8@ub1910> On Wed, 4 Mar 2020 11:02:47 +0100 Ricardo Ribalda Delgado wrote: > Hi Paul > > On Wed, Mar 4, 2020 at 10:53 AM Paul Barker wrote: > > > > On Wed, 4 Mar 2020 09:34:37 +0100 > > Ricardo Ribalda Delgado wrote: > > > > > When parameters include_path or exclude_path are passed to the rootfs > > > plugin, it will copy the partition content into a folder and make all > > > the modifications there. > > > > > > This is done using copyhardlinktree(), which does not take into > > > consideration the content of the pseudo folder, which contains the > > > information about the right permissions and ownership of the folders. > > > > How are you running wic here? In the do_image_wic task it's executed under > > pseudo so all this is handled already. Executing wic outside of bitbake may > > need some more testing here. > > I am running wic outside bitbake. But even if it is run under bitbake, > it should also fail. The pseudo directory needs to be present on the > target image If you're running wic outside of bitbake, is there any guarantee that pseudo is available? > > > > > > > > > This results in a rootfs owned by the user that is running the wic > > > command (usually UID 1000), which makes some rootfs unbootable. > > > > > > To fix this we copy the content of the pseudo folders to the new folder > > > and modify the pseudo database using the "pseudo -B" command. > > > > > > Signed-off-by: Ricardo Ribalda Delgado > > > --- > > > scripts/lib/wic/plugins/source/rootfs.py | 22 +++++++++++++++++++--- > > > 1 file changed, 19 insertions(+), 3 deletions(-) > > > > > > diff --git a/scripts/lib/wic/plugins/source/rootfs.py b/scripts/lib/wic/plugins/source/rootfs.py > > > index 705aeb5563..40419a64b3 100644 > > > --- a/scripts/lib/wic/plugins/source/rootfs.py > > > +++ b/scripts/lib/wic/plugins/source/rootfs.py > > > @@ -16,11 +16,11 @@ import os > > > import shutil > > > import sys > > > > > > -from oe.path import copyhardlinktree > > > +from oe.path import copyhardlinktree, copytree > > > > > > from wic import WicError > > > from wic.pluginbase import SourcePlugin > > > -from wic.misc import get_bitbake_var > > > +from wic.misc import get_bitbake_var, exec_native_cmd > > > > > > logger = logging.getLogger('wic') > > > > > > @@ -44,6 +44,15 @@ class RootfsPlugin(SourcePlugin): > > > > > > return os.path.realpath(image_rootfs_dir) > > > > > > + @staticmethod > > > + def __get_pseudo(native_sysroot, rootfs): > > > + pseudo = "export PSEUDO_PREFIX=%s/usr;" % native_sysroot > > > + pseudo += "export PSEUDO_LOCALSTATEDIR=%s;" % os.path.join(rootfs, "../pseudo") > > > + pseudo += "export PSEUDO_PASSWD=%s;" % rootfs > > > + pseudo += "export PSEUDO_NOSYMLINKEXP=1;" > > > + pseudo += "%s " % get_bitbake_var("FAKEROOTCMD") > > > + return pseudo > > > + > > > @classmethod > > > def do_prepare_partition(cls, part, source_params, cr, cr_workdir, > > > oe_builddir, bootimg_dir, kernel_dir, > > > @@ -78,9 +87,16 @@ class RootfsPlugin(SourcePlugin): > > > > > > if os.path.lexists(new_rootfs): > > > shutil.rmtree(os.path.join(new_rootfs)) > > > - > > > copyhardlinktree(part.rootfs_dir, new_rootfs) > > > > > > + if os.path.lexists(os.path.join(new_rootfs, "../pseudo")): > > > + shutil.rmtree(os.path.join(new_rootfs, "../pseudo")) > > > + copytree(os.path.join(part.rootfs_dir, "../pseudo"), > > > + os.path.join(new_rootfs, "../pseudo")) > > > > I don't like stepping up the directory tree like this. We should be more > > explicit with the paths. > > You are thinking on: > os.path.dirname(directory) No, I'm wondering why we're taking a step up the directory tree from `part.rootfs_dir`. I can point that at any path using the `--rootfs-dir` argument and there's no guarantee that ../pseudo exists or is relevant to the path I gave to `--rootfs-dir`. > > > > > > + pseudo_cmd = "%s -B -m %s -M %s" % (cls.__get_pseudo(native_sysroot,new_rootfs), > > > + part.rootfs_dir, new_rootfs) > > > + exec_native_cmd(pseudo_cmd, native_sysroot) > > > + > > > for path in part.include_path or []: > > > copyhardlinktree(path, new_rootfs) > > > > ^^^^^^^^^^^^^^^^ > > > > If this is the right approach I imagine you would also need to fix things up > > with pseudo after the copyhardlinktree call above. > > I do not think it is needed. include_path does not contain its own > pseudo directory That's not necessarily true. The include_path could have been built by Yocto using pseudo. I can see that there is an issue using these arguments to wic outside of bitbake but I'm not sure this is the correct solution. -- Paul Barker Konsulko Group From pbarker at konsulko.com Thu Mar 5 09:33:29 2020 From: pbarker at konsulko.com (Paul Barker) Date: Thu, 5 Mar 2020 09:33:29 +0000 Subject: [OE-core] [PATCH v2 2/2] wic: Add --embed-rootfs argument In-Reply-To: <20200304144936.2559106-2-ricardo@ribalda.com> References: <20200304144936.2559106-1-ricardo@ribalda.com> <20200304144936.2559106-2-ricardo@ribalda.com> Message-ID: <20200305093329.1eed6cdd@ub1910> On Wed, 4 Mar 2020 15:49:36 +0100 Ricardo Ribalda Delgado wrote: > This option adds the content of a rootfs on a specific location on the > rootfs. > > It is very useful for making a partition that contains the rootfs for a > host and a target Eg: > > / -> Roofs for the host > /export/ -> Rootfs for the target (which will netboot) > > Although today we support making a partition for "/export" this might > not be compatible with some upgrade systems, or we might be limited by > the number of partitions. > > With this patch we can use something like: > > part / --source rootfs --embed-rootfs target-image /export --embed-rootfs target-image2 /export2 I like this but it still leaves confusion between `--include-path` and --embed-rootfs` as they're similar but slightly different. Can we just modify `--include-path` to have this syntax? > > on the .wks file. > > Signed-off-by: Ricardo Ribalda Delgado > --- > scripts/lib/wic/help.py | 8 ++++++++ > scripts/lib/wic/ksparser.py | 1 + > scripts/lib/wic/partition.py | 1 + > scripts/lib/wic/plugins/source/rootfs.py | 22 +++++++++++++++++++++- > 4 files changed, 31 insertions(+), 1 deletion(-) > > diff --git a/scripts/lib/wic/help.py b/scripts/lib/wic/help.py > index 4d342fcf05..140dc504cd 100644 > --- a/scripts/lib/wic/help.py > +++ b/scripts/lib/wic/help.py > @@ -979,6 +979,14 @@ DESCRIPTION > copies. This option only has an effect with the rootfs > source plugin. > > + --embed-rootfs: This option is specific to wic. It embeds a rootfs into > + the given path to the resulting image. The option > + contains two fields, the roofs and the path, separated > + by a space. The rootfs follows the same logic as the > + rootfs-dir argument. Multiple options can be provided > + in order to embed multiple rootfs. This option only has > + an effect with the rootfs source plugin. > + > --extra-space: This option is specific to wic. It adds extra > space after the space filled by the content > of the partition. The final size can go > diff --git a/scripts/lib/wic/ksparser.py b/scripts/lib/wic/ksparser.py > index 650b976223..64c8c1175e 100644 > --- a/scripts/lib/wic/ksparser.py > +++ b/scripts/lib/wic/ksparser.py > @@ -138,6 +138,7 @@ class KickStart(): > part.add_argument('--align', type=int) > part.add_argument('--exclude-path', nargs='+') > part.add_argument('--include-path', nargs='+') > + part.add_argument('--embed-rootfs', nargs=2, action='append') > part.add_argument("--extra-space", type=sizetype) > part.add_argument('--fsoptions', dest='fsopts') > part.add_argument('--fstype', default='vfat', > diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py > index 2d95f78439..13857df82f 100644 > --- a/scripts/lib/wic/partition.py > +++ b/scripts/lib/wic/partition.py > @@ -31,6 +31,7 @@ class Partition(): > self.extra_space = args.extra_space > self.exclude_path = args.exclude_path > self.include_path = args.include_path > + self.embed_rootfs = args.embed_rootfs > self.fsopts = args.fsopts > self.fstype = args.fstype > self.label = args.label > diff --git a/scripts/lib/wic/plugins/source/rootfs.py b/scripts/lib/wic/plugins/source/rootfs.py > index 40419a64b3..089aaea477 100644 > --- a/scripts/lib/wic/plugins/source/rootfs.py > +++ b/scripts/lib/wic/plugins/source/rootfs.py > @@ -17,6 +17,7 @@ import shutil > import sys > > from oe.path import copyhardlinktree, copytree > +from pathlib import Path > > from wic import WicError > from wic.pluginbase import SourcePlugin > @@ -80,7 +81,7 @@ class RootfsPlugin(SourcePlugin): > > new_rootfs = None > # Handle excluded paths. > - if part.exclude_path or part.include_path: > + if part.exclude_path or part.include_path or part.embed_rootfs: > # We need a new rootfs directory we can delete files from. Copy to > # workdir. > new_rootfs = os.path.realpath(os.path.join(cr_workdir, "rootfs%d" % part.lineno)) > @@ -100,6 +101,25 @@ class RootfsPlugin(SourcePlugin): > for path in part.include_path or []: > copyhardlinktree(path, new_rootfs) > > + for embed in part.embed_rootfs or []: > + [embed_rootfs, path] = embed > + #we need to remove the initial / for os.path.join to work > + if os.path.isabs(path): > + path = path[1:] > + if embed_rootfs in krootfs_dir: > + embed_rootfs = krootfs_dir[embed_rootfs] > + embed_rootfs = cls.__get_rootfs_dir(embed_rootfs) > + tar_file = os.path.realpath(os.path.join(cr_workdir, "aux.tar")) > + tar_cmd = "%s tar cpf %s -C %s ." % (cls.__get_pseudo(native_sysroot, > + embed_rootfs), tar_file, embed_rootfs) > + exec_native_cmd(tar_cmd, native_sysroot) > + untar_cmd = "%s tar xf %s -C %s ." % (cls.__get_pseudo(native_sysroot, new_rootfs), > + tar_file, os.path.join(new_rootfs, path)) > + Path(os.path.join(new_rootfs, path)).mkdir(parents=True, exist_ok=True) > + exec_native_cmd(untar_cmd, native_sysroot, > + cls.__get_pseudo(native_sysroot, new_rootfs)) > + os.remove(tar_file) > + > for orig_path in part.exclude_path or []: > path = orig_path > if os.path.isabs(path): As said in my other email, if you're running wic outside bitbake I'm not sure you can guarantee pseudo is available. And now I think about it, if you're running wic inside bitbake (as part of do_image_wic), you'd be running pseudo under pseudo and I have no idea how that would work out. -- Paul Barker Konsulko Group From pbarker at konsulko.com Thu Mar 5 09:42:09 2020 From: pbarker at konsulko.com (Paul Barker) Date: Thu, 5 Mar 2020 09:42:09 +0000 Subject: [OE-core] [PATCH] bitbake: gitsm: download submodules In-Reply-To: References: <84e64ccddc46261a59bb1e281ef3294e08119abc.camel@siemens.com> <20200304095944.792423a0@ub1910> Message-ID: <20200305094209.3704f549@ub1910> On Wed, 4 Mar 2020 12:30:10 +0000 "Freihofer, Adrian" wrote: > -----Original Message----- > From: Paul Barker > To: "Freihofer, Adrian" > Cc: openembedded-core at lists.openembedded.org < > openembedded-core at lists.openembedded.org> > Subject: Re: [OE-core] [PATCH] bitbake: gitsm: download submodules > Date: Wed, 04 Mar 2020 09:59:44 +0000 > > On Wed, 4 Mar 2020 08:12:27 +0000 > "Freihofer, Adrian" wrote: > > > The unpack function failed because the submodules were not > > downloaded. > > Calling download before unpack for each submodule solves this issue. > > > > Signed-off-by: Adrian Freihofer > > --- > > bitbake/lib/bb/fetch2/gitsm.py | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/bitbake/lib/bb/fetch2/gitsm.py > > b/bitbake/lib/bb/fetch2/gitsm.py > > index c622771d21..3715e9824f 100644 > > --- a/bitbake/lib/bb/fetch2/gitsm.py > > +++ b/bitbake/lib/bb/fetch2/gitsm.py > > @@ -184,6 +184,7 @@ class GitSM(Git): > > > > try: > > newfetch = Fetch([url], d, cache=False) > > + newfetch.download() > > newfetch.unpack(root=os.path.dirname(os.path.join(re > > po > > _conf, 'modules', module))) > > except Exception as e: > > logger.error('gitsm: submodule unpack failed: %s %s' > > % > > (type(e).__name__, str(e))) > > You shouldn't be trying to download submodules in the do_unpack step. > If > they're missing at this stage it probably indicates a fetch issue. > > Basically true, but the information about which submodules need to be > downloaded is not available before the top level repo has been > unpacked. I guess the solution must be something like: > > fetch top-level > unpack top-level > foreach submodule: > fetch submodule > unpack submodule > > What's the exact error that you're seeing? > > Don't remeber exactly. But when I debugged the flow, it became obvious, > that the submodules are not downloaded. > > This could be related to the issue I saw when the fetcher uses git > shallow > tarballs from a mirror - if that's the case I'm planning to get that > fixed > this weekend. > > Yes, the problem occurs with git shallows. The patch solves it with and > without shallows for us. > > Also, your email client seems to have chewed the patch up. It's best to > send > patches using `git send-email` only. > > Sorry, we switched to a new e-mail solution. I have to adapt my setup. The problem with your patch is that it would require network access during do_unpack which then breaks our ability to do offline builds. Do you only see this issue when fetching from git shallow mirror tarballs? If so, the mirror tarballs need to be extracted during do_fetch but not placed in the usual 'git2' directory (as future fetches can't cope with shallow clones in that directory). Fixing this also has some impact on archiver.bbclass as that also needs to be able to walk the tree of submodules correctly. -- Paul Barker Konsulko Group From ricardo at ribalda.com Thu Mar 5 09:46:27 2020 From: ricardo at ribalda.com (Ricardo Ribalda Delgado) Date: Thu, 5 Mar 2020 10:46:27 +0100 Subject: [OE-core] [PATCH 1/2] wic: Fix permissions when using exclude or include path In-Reply-To: <20200305092855.1f9ccae8@ub1910> References: <20200304083438.1022216-1-ricardo@ribalda.com> <20200304095334.1f20ddd9@ub1910> <20200305092855.1f9ccae8@ub1910> Message-ID: Hi Paul On Thu, Mar 5, 2020 at 10:32 AM Paul Barker wrote: > > On Wed, 4 Mar 2020 11:02:47 +0100 > Ricardo Ribalda Delgado wrote: > > > Hi Paul > > > > On Wed, Mar 4, 2020 at 10:53 AM Paul Barker wrote: > > > > > > On Wed, 4 Mar 2020 09:34:37 +0100 > > > Ricardo Ribalda Delgado wrote: > > > > > > > When parameters include_path or exclude_path are passed to the rootfs > > > > plugin, it will copy the partition content into a folder and make all > > > > the modifications there. > > > > > > > > This is done using copyhardlinktree(), which does not take into > > > > consideration the content of the pseudo folder, which contains the > > > > information about the right permissions and ownership of the folders. > > > > > > How are you running wic here? In the do_image_wic task it's executed under > > > pseudo so all this is handled already. Executing wic outside of bitbake may > > > need some more testing here. > > > > I am running wic outside bitbake. But even if it is run under bitbake, > > it should also fail. The pseudo directory needs to be present on the > > target image > > If you're running wic outside of bitbake, is there any guarantee that pseudo > is available? Yes, the same guarantee that the ext3_tools are available. So I believe we are safe here. Actually in my docker pseudo is not installed and when I invoke with wic, everything is fine. > > > > > > > > > > > > > > This results in a rootfs owned by the user that is running the wic > > > > command (usually UID 1000), which makes some rootfs unbootable. > > > > > > > > To fix this we copy the content of the pseudo folders to the new folder > > > > and modify the pseudo database using the "pseudo -B" command. > > > > > > > > Signed-off-by: Ricardo Ribalda Delgado > > > > --- > > > > scripts/lib/wic/plugins/source/rootfs.py | 22 +++++++++++++++++++--- > > > > 1 file changed, 19 insertions(+), 3 deletions(-) > > > > > > > > diff --git a/scripts/lib/wic/plugins/source/rootfs.py b/scripts/lib/wic/plugins/source/rootfs.py > > > > index 705aeb5563..40419a64b3 100644 > > > > --- a/scripts/lib/wic/plugins/source/rootfs.py > > > > +++ b/scripts/lib/wic/plugins/source/rootfs.py > > > > @@ -16,11 +16,11 @@ import os > > > > import shutil > > > > import sys > > > > > > > > -from oe.path import copyhardlinktree > > > > +from oe.path import copyhardlinktree, copytree > > > > > > > > from wic import WicError > > > > from wic.pluginbase import SourcePlugin > > > > -from wic.misc import get_bitbake_var > > > > +from wic.misc import get_bitbake_var, exec_native_cmd > > > > > > > > logger = logging.getLogger('wic') > > > > > > > > @@ -44,6 +44,15 @@ class RootfsPlugin(SourcePlugin): > > > > > > > > return os.path.realpath(image_rootfs_dir) > > > > > > > > + @staticmethod > > > > + def __get_pseudo(native_sysroot, rootfs): > > > > + pseudo = "export PSEUDO_PREFIX=%s/usr;" % native_sysroot > > > > + pseudo += "export PSEUDO_LOCALSTATEDIR=%s;" % os.path.join(rootfs, "../pseudo") > > > > + pseudo += "export PSEUDO_PASSWD=%s;" % rootfs > > > > + pseudo += "export PSEUDO_NOSYMLINKEXP=1;" > > > > + pseudo += "%s " % get_bitbake_var("FAKEROOTCMD") > > > > + return pseudo > > > > + > > > > @classmethod > > > > def do_prepare_partition(cls, part, source_params, cr, cr_workdir, > > > > oe_builddir, bootimg_dir, kernel_dir, > > > > @@ -78,9 +87,16 @@ class RootfsPlugin(SourcePlugin): > > > > > > > > if os.path.lexists(new_rootfs): > > > > shutil.rmtree(os.path.join(new_rootfs)) > > > > - > > > > copyhardlinktree(part.rootfs_dir, new_rootfs) > > > > > > > > + if os.path.lexists(os.path.join(new_rootfs, "../pseudo")): > > > > + shutil.rmtree(os.path.join(new_rootfs, "../pseudo")) > > > > + copytree(os.path.join(part.rootfs_dir, "../pseudo"), > > > > + os.path.join(new_rootfs, "../pseudo")) > > > > > > I don't like stepping up the directory tree like this. We should be more > > > explicit with the paths. > > > > You are thinking on: > > os.path.dirname(directory) > > No, I'm wondering why we're taking a step up the directory tree from > `part.rootfs_dir`. I can point that at any path using the `--rootfs-dir` > argument and there's no guarantee that ../pseudo exists or is relevant to the > path I gave to `--rootfs-dir`. Because we are asuming that the rootfs is being generated with OE/yocto, and there is where the pseudo folder lives. It is the same asumption part.prepare_rootfs() is taking. > > > > > > > > > > + pseudo_cmd = "%s -B -m %s -M %s" % (cls.__get_pseudo(native_sysroot,new_rootfs), > > > > + part.rootfs_dir, new_rootfs) > > > > + exec_native_cmd(pseudo_cmd, native_sysroot) > > > > + > > > > for path in part.include_path or []: > > > > copyhardlinktree(path, new_rootfs) > > > > > > ^^^^^^^^^^^^^^^^ > > > > > > If this is the right approach I imagine you would also need to fix things up > > > with pseudo after the copyhardlinktree call above. > > > > I do not think it is needed. include_path does not contain its own > > pseudo directory > > That's not necessarily true. The include_path could have been built by Yocto > using pseudo. Then you need to provide where the pseudo folder is. Eg --include_path folder/A/B/C/D/file Where is the pseudo database? in folder/A/B/C/D/pseudo, folder/A/B/C/pseudo , folder/A/B/C/pseudo /... > > I can see that there is an issue using these arguments to wic outside of > bitbake but I'm not sure this is the correct solution. > > -- > Paul Barker > Konsulko Group -- Ricardo Ribalda From mingli.yu at windriver.com Thu Mar 5 10:02:57 2020 From: mingli.yu at windriver.com (mingli.yu at windriver.com) Date: Thu, 5 Mar 2020 18:02:57 +0800 Subject: [OE-core] [PATCH] netbase: Upgrade to 6.1 Message-ID: <1583402577-350047-1-git-send-email-mingli.yu@windriver.com> From: Mingli Yu Signed-off-by: Mingli Yu --- meta/recipes-core/netbase/{netbase_6.0.bb => netbase_6.1.bb} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename meta/recipes-core/netbase/{netbase_6.0.bb => netbase_6.1.bb} (82%) diff --git a/meta/recipes-core/netbase/netbase_6.0.bb b/meta/recipes-core/netbase/netbase_6.1.bb similarity index 82% rename from meta/recipes-core/netbase/netbase_6.0.bb rename to meta/recipes-core/netbase/netbase_6.1.bb index 2fb5762..bc0049c 100644 --- a/meta/recipes-core/netbase/netbase_6.0.bb +++ b/meta/recipes-core/netbase/netbase_6.1.bb @@ -8,8 +8,8 @@ PE = "1" SRC_URI = "${DEBIAN_MIRROR}/main/n/${BPN}/${BPN}_${PV}.tar.xz" -SRC_URI[md5sum] = "3417b0487161f1a2b070a3308cd7f957" -SRC_URI[sha256sum] = "692baeb7b76eba5580c7edbc97ce1784a06b5aa4b367c5ed0b39e0ce7a97d594" +SRC_URI[md5sum] = "e5871a3a5c8390557b8033cf19316a55" +SRC_URI[sha256sum] = "084d743bd84d4d9380bac4c71c51e57406dce44f5a69289bb823c903e9b035d8" UPSTREAM_CHECK_URI = "${DEBIAN_MIRROR}/main/n/netbase/" do_install () { -- 2.7.4 From rbilovol at cisco.com Thu Mar 5 11:52:13 2020 From: rbilovol at cisco.com (Ruslan Bilovol) Date: Thu, 5 Mar 2020 13:52:13 +0200 Subject: [OE-core] [PATCH] openssl: pass PERL=perl environment variable to configurator In-Reply-To: <1545427980-17876-1-git-send-email-rbilovol@cisco.com> References: <1545427980-17876-1-git-send-email-rbilovol@cisco.com> Message-ID: <91749d3c-5074-0129-ea6a-1f85d787fbd3@cisco.com> It seems this patch was forgotten and master moved forward. Will resend it from latest master Thanks, Ruslan On 12/21/18 11:33 PM, Ruslan Bilovol wrote: > In our build environment we use wrapper script > for perl in non-standard configuration with > extra variables set (provided by custom > buildtools-tarball). > > In this case openssl fails to build because > by default it's Configure script detects and uses > perl executable directly (with absolute path) > obviously missing extra settings from wrapper > script. > > Pass PERL=perl environment variable to Configure, > so it won't try to use perl executable directly > but will use what is provided from environment. > > Signed-off-by: Ruslan Bilovol > --- > meta/recipes-connectivity/openssl/openssl_1.1.1a.bb | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1a.bb b/meta/recipes-connectivity/openssl/openssl_1.1.1a.bb > index 5c4e69c..6a72b5c 100644 > --- a/meta/recipes-connectivity/openssl/openssl_1.1.1a.bb > +++ b/meta/recipes-connectivity/openssl/openssl_1.1.1a.bb > @@ -112,7 +112,7 @@ do_configure () { > fi > # WARNING: do not set compiler/linker flags (-I/-D etc.) in EXTRA_OECONF, as they will fully replace the > # environment variables set by bitbake. Adjust the environment variables instead. > - PERL5LIB="${S}/external/perl/Text-Template-1.46/lib/" \ > + PERL=perl PERL5LIB="${S}/external/perl/Text-Template-1.46/lib/" \ > perl ${S}/Configure ${EXTRA_OECONF} ${PACKAGECONFIG_CONFARGS} --prefix=$useprefix --openssldir=${libdir}/ssl-1.1 --libdir=${libdir} $target > perl ${B}/configdata.pm --dump > } > From rbilovol at cisco.com Thu Mar 5 11:53:33 2020 From: rbilovol at cisco.com (Ruslan Bilovol) Date: Thu, 5 Mar 2020 13:53:33 +0200 Subject: [OE-core] [PATCH RESEND] openssl: pass PERL=perl environment variable to configurator Message-ID: <20200305115333.31139-1-rbilovol@cisco.com> In our build environment we use wrapper script for perl in non-standard configuration with extra variables set (provided by custom buildtools-tarball). In this case openssl fails to build because by default it's Configure script detects and uses perl executable directly (with absolute path) obviously missing extra settings from wrapper script. Pass PERL=perl environment variable to Configure, so it won't try to use perl executable directly but will use what is provided from environment. Signed-off-by: Ruslan Bilovol --- meta/recipes-connectivity/openssl/openssl_1.1.1d.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb b/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb index c2ba005f47..d4871fe973 100644 --- a/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb +++ b/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb @@ -123,7 +123,7 @@ do_configure () { fi # WARNING: do not set compiler/linker flags (-I/-D etc.) in EXTRA_OECONF, as they will fully replace the # environment variables set by bitbake. Adjust the environment variables instead. - PERL5LIB="${S}/external/perl/Text-Template-1.46/lib/" \ + PERL=perl PERL5LIB="${S}/external/perl/Text-Template-1.46/lib/" \ perl ${S}/Configure ${EXTRA_OECONF} ${PACKAGECONFIG_CONFARGS} --prefix=$useprefix --openssldir=${libdir}/ssl-1.1 --libdir=${libdir} $target perl ${B}/configdata.pm --dump } -- 2.17.1 From wallinux at gmail.com Thu Mar 5 12:06:29 2020 From: wallinux at gmail.com (Anders Wallin) Date: Thu, 5 Mar 2020 13:06:29 +0100 Subject: [OE-core] [PATCH v2] babeltrace2: added first version, 2.0.1 Message-ID: <20200305120629.329-1-wallinux@gmail.com> Babeltrace 1 vs. Babeltrace 2 The Babeltrace project exists since 2010. In 2020, Babeltrace 2 was released. Babeltrace 2 is a complete rewrite of the library, Python bindings, and CLI. It is plugin based and offers much more features and potential than Babeltrace 1. Because Babeltrace 2 is still a young released project, some distributions still provide packages for the Babeltrace 1 project. Both projects can coexist on the same system as there are no common installed files. Signed-off-by: Anders Wallin --- meta/conf/distro/include/distro_alias.inc | 1 + meta/conf/distro/include/maintainers.inc | 1 + .../distro/include/ptest-packagelists.inc | 1 + .../packagegroup-core-tools-profile.bb | 2 + ...not-run-test-applications-from-.libs.patch | 28 ++++++ .../lttng/babeltrace2/run-ptest | 9 ++ .../recipes-kernel/lttng/babeltrace2_2.0.1.bb | 92 +++++++++++++++++++ 7 files changed, 134 insertions(+) create mode 100644 meta/recipes-kernel/lttng/babeltrace2/0001-tests-do-not-run-test-applications-from-.libs.patch create mode 100755 meta/recipes-kernel/lttng/babeltrace2/run-ptest create mode 100644 meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb diff --git a/meta/conf/distro/include/distro_alias.inc b/meta/conf/distro/include/distro_alias.inc index 79ebcaee29..0e4a9a9f8f 100644 --- a/meta/conf/distro/include/distro_alias.inc +++ b/meta/conf/distro/include/distro_alias.inc @@ -15,6 +15,7 @@ DISTRO_PN_ALIAS_pn-alsa-utils-scripts = "OE-Core" DISTRO_PN_ALIAS_pn-atk = "Fedora=atk OpenSuSE=atk" DISTRO_PN_ALIAS_pn-avahi-ui = "Ubuntu=avahi-discover Debian=avahi-discover" DISTRO_PN_ALIAS_pn-babeltrace = "OSPDT" +DISTRO_PN_ALIAS_pn-babeltrace2 = "OSPDT" DISTRO_PN_ALIAS_pn-bjam = "OpenSuSE=boost-jam Debian=bjam" DISTRO_PN_ALIAS_pn-blktool = "Debian=blktool Mandriva=blktool" DISTRO_PN_ALIAS_pn-bluez5 = "Fedora=bluez Opensuse=bluez" diff --git a/meta/conf/distro/include/maintainers.inc b/meta/conf/distro/include/maintainers.inc index 10095ffe76..adb18228e7 100644 --- a/meta/conf/distro/include/maintainers.inc +++ b/meta/conf/distro/include/maintainers.inc @@ -59,6 +59,7 @@ RECIPE_MAINTAINER_pn-automake = "Robert Yang " RECIPE_MAINTAINER_pn-avahi = "Yi Zhao " RECIPE_MAINTAINER_pn-avahi-ui = "Yi Zhao " RECIPE_MAINTAINER_pn-babeltrace = "Alexander Kanavin " +RECIPE_MAINTAINER_pn-babeltrace2 = "Alexander Kanavin " RECIPE_MAINTAINER_pn-base-files = "Anuj Mittal " RECIPE_MAINTAINER_pn-base-passwd = "Anuj Mittal " RECIPE_MAINTAINER_pn-bash = "Hongxu Jia " diff --git a/meta/conf/distro/include/ptest-packagelists.inc b/meta/conf/distro/include/ptest-packagelists.inc index 4afac58e3a..d6f3aafc7f 100644 --- a/meta/conf/distro/include/ptest-packagelists.inc +++ b/meta/conf/distro/include/ptest-packagelists.inc @@ -64,6 +64,7 @@ PTESTS_FAST = "\ PTESTS_SLOW = "\ babeltrace-ptest \ + babeltrace2-ptest \ busybox-ptest \ dbus-test-ptest \ e2fsprogs-ptest \ diff --git a/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb b/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb index 984c2fac92..ac180b542a 100644 --- a/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb +++ b/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb @@ -46,6 +46,7 @@ LTTNGMODULES = "lttng-modules" LTTNGMODULES_arc = "" BABELTRACE = "babeltrace" +BABELTRACE2 = "babeltrace2" # valgrind does not work on the following configurations/architectures @@ -69,6 +70,7 @@ RDEPENDS_${PN} = "\ ${LTTNGTOOLS} \ ${LTTNGMODULES} \ ${BABELTRACE} \ + ${BABELTRACE2} \ ${SYSTEMTAP} \ ${VALGRIND} \ " diff --git a/meta/recipes-kernel/lttng/babeltrace2/0001-tests-do-not-run-test-applications-from-.libs.patch b/meta/recipes-kernel/lttng/babeltrace2/0001-tests-do-not-run-test-applications-from-.libs.patch new file mode 100644 index 0000000000..805dde8064 --- /dev/null +++ b/meta/recipes-kernel/lttng/babeltrace2/0001-tests-do-not-run-test-applications-from-.libs.patch @@ -0,0 +1,28 @@ +From 582713cc9a013481eeef253195d644020f637ec4 Mon Sep 17 00:00:00 2001 +Message-Id: <582713cc9a013481eeef253195d644020f637ec4.1583403622.git.wallinux at gmail.com> +From: Anders Wallin +Date: Thu, 5 Mar 2020 11:20:04 +0100 +Subject: [PATCH] tests: do not run test applications from .libs + +Cross compile specific change + +Upstream-Status: Inappropriate [oe-core specific] + +Signed-off-by: Anders Wallin +--- + tests/lib/test_plugin | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/tests/lib/test_plugin b/tests/lib/test_plugin +index 652c90cc..1f817c50 100755 +--- a/tests/lib/test_plugin ++++ b/tests/lib/test_plugin +@@ -26,4 +26,4 @@ fi + # shellcheck source=../utils/utils.sh + source "$UTILSSH" + +-"${BT_TESTS_BUILDDIR}/lib/plugin" "${BT_TESTS_BUILDDIR}/lib/test-plugin-plugins/.libs" ++"${BT_TESTS_BUILDDIR}/lib/plugin" "${BT_TESTS_BUILDDIR}/lib/test-plugin-plugins" +-- +2.25.1 + diff --git a/meta/recipes-kernel/lttng/babeltrace2/run-ptest b/meta/recipes-kernel/lttng/babeltrace2/run-ptest new file mode 100755 index 0000000000..72fe223436 --- /dev/null +++ b/meta/recipes-kernel/lttng/babeltrace2/run-ptest @@ -0,0 +1,9 @@ +#!/bin/sh +# use target=recheck if you want to recheck failing tests +[ "$target" = "" ] && target=check + +# Without --ignore-exit, the tap harness causes any FAILs within a +# test plan to raise ERRORs; this is just noise. +makeargs="LOG_DRIVER_FLAGS=--ignore-exit abs_top_srcdir=$PWD abs_top_builddir=$PWD GREP=grep SED=sed PYTHON=python3" + +exec make -C tests -k -s $makeargs $target 2>/dev/null diff --git a/meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb b/meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb new file mode 100644 index 0000000000..16953d6807 --- /dev/null +++ b/meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb @@ -0,0 +1,92 @@ +SUMMARY = "Babeltrace2 - Trace Format Babel Tower" +DESCRIPTION = "Babeltrace provides trace read and write libraries in host side, as well as a trace converter, which used to convert LTTng 2.0 traces into human-readable log." +HOMEPAGE = "http://babeltrace.org/" +BUGTRACKER = "https://bugs.lttng.org/projects/babeltrace" +LICENSE = "MIT & GPLv2 & LGPLv2.1 & BSD-2-Clause" +LIC_FILES_CHKSUM = "file://LICENSE;md5=a6a458c13f18385b7bc5069a6d7b176e" + +DEPENDS = "glib-2.0 util-linux popt bison-native flex-native" + +SRC_URI = "git://git.linuxfoundation.org/diamon/babeltrace.git;branch=stable-2.0 \ + file://run-ptest \ + file://0001-tests-do-not-run-test-applications-from-.libs.patch \ + " +SRCREV = "06df58f89ee51b1a2c6a2c187ec3f15691633910" +UPSTREAM_CHECK_GITTAGREGEX = "v(?P2(\.\d+)+)$" + +S = "${WORKDIR}/git" + +inherit autotools pkgconfig ptest + +EXTRA_OECONF = "--disable-debug-info" + +PACKAGECONFIG ??= "manpages" +PACKAGECONFIG[manpages] = ", --disable-man-pages, asciidoc-native xmlto-native" + +FILES_${PN}-staticdev += "${libdir}/babeltrace2/plugins/*.a" +FILES_${PN} += "${libdir}/babeltrace2/plugins/*.so" + +ASNEEDED = "" + +RDEPENDS_${PN}-ptest += "bash gawk python3" + +do_compile_ptest () { + make -C tests all +} + +do_install_ptest () { + install -d "${D}${PTEST_PATH}/tests" + + # Copy required files from source directory + for d in $(find "${S}/tests" -type d -printf '%P ') ; do + install -d "${D}${PTEST_PATH}/tests/$d" + find "${S}/tests/$d" -maxdepth 1 -executable -type f \ + -exec install -t "${D}${PTEST_PATH}/tests/$d" {} + + find "${S}/tests/$d" -maxdepth 1 -name *.sh \ + -exec install -t "${D}${PTEST_PATH}/tests/$d" {} \; + find "${S}/tests/$d" -maxdepth 1 -name *.py \ + -exec install -t "${D}${PTEST_PATH}/tests/$d" {} \; + find "${S}/tests/$d" -maxdepth 1 -name *.expect \ + -exec install -t "${D}${PTEST_PATH}/tests/$d" {} \; + done + install -d "${D}${PTEST_PATH}/tests/data/ctf-traces/" + cp -a ${S}/tests/data/ctf-traces/* ${D}${PTEST_PATH}/tests/data/ctf-traces/ + + # Copy the tests directory tree and the executables and + # Makefiles found within. + install -D "${B}/tests/Makefile" "${D}${PTEST_PATH}/tests/" + for d in $(find "${B}/tests" -type d -not -name .libs -printf '%P ') ; do + install -d "${D}${PTEST_PATH}/tests/$d" + find "${B}/tests/$d" -maxdepth 1 -executable -type f \ + -exec install -t "${D}${PTEST_PATH}/tests/$d" {} + + test -r "${B}/tests/$d/Makefile" && \ + install -t "${D}${PTEST_PATH}/tests/$d" "${B}/tests/$d/Makefile" + find "${B}/tests/$d" -maxdepth 1 -name *.sh \ + -exec install -t "${D}${PTEST_PATH}/tests/$d" {} \; + done + + for d in $(find "${B}/tests" -type d -name .libs -printf '%P ') ; do + for f in $(find "${B}/tests/$d" -maxdepth 1 -executable -type f -printf '%P ') ; do + cp ${B}/tests/$d/$f ${D}${PTEST_PATH}/tests/`dirname $d`/$f + done + done + + # Prevent attempts to update Makefiles during test runs, and + # silence "Making check in $SUBDIR" messages. + find "${D}${PTEST_PATH}" -name Makefile -type f -exec \ + sed -i \ + -e '/Makefile:/,/^$/d' \ + -e '/%: %.in/,/^$/d' \ + -e '/echo "Making $$target in $$subdir"; \\/d' \ + -e 's/^srcdir = \(.*\)/srcdir = ./' \ + -e 's/^builddir = \(.*\)/builddir = ./' \ + -e 's/^all-am:.*/all-am:/' \ + {} + + + # Substitute links to installed binaries. + install -d "${D}${PTEST_PATH}/src/cli/" + ln -s "${bindir}/babeltrace2" ${D}${PTEST_PATH}/src/cli/ + + # Remove architechture specific testfiles + rm -rf ${D}${PTEST_PATH}/tests/data/plugins/flt.lttng-utils.debug-info/* +} -- 2.25.1 From ricardo at ribalda.com Thu Mar 5 12:26:19 2020 From: ricardo at ribalda.com (Ricardo Ribalda Delgado) Date: Thu, 5 Mar 2020 13:26:19 +0100 Subject: [OE-core] [PATCH v2 2/2] wic: Add --embed-rootfs argument In-Reply-To: <20200305093329.1eed6cdd@ub1910> References: <20200304144936.2559106-1-ricardo@ribalda.com> <20200304144936.2559106-2-ricardo@ribalda.com> <20200305093329.1eed6cdd@ub1910> Message-ID: Hi Paul, On Thu, Mar 5, 2020 at 10:37 AM Paul Barker wrote: > > On Wed, 4 Mar 2020 15:49:36 +0100 > Ricardo Ribalda Delgado wrote: > > > This option adds the content of a rootfs on a specific location on the > > rootfs. > > > > It is very useful for making a partition that contains the rootfs for a > > host and a target Eg: > > > > / -> Roofs for the host > > /export/ -> Rootfs for the target (which will netboot) > > > > Although today we support making a partition for "/export" this might > > not be compatible with some upgrade systems, or we might be limited by > > the number of partitions. > > > > With this patch we can use something like: > > > > part / --source rootfs --embed-rootfs target-image /export --embed-rootfs target-image2 /export2 > > I like this but it still leaves confusion between `--include-path` and > --embed-rootfs` as they're similar but slightly different. Can we just modify > `--include-path` to have this syntax? I think they are different enough. - include-path ads a file/folder - embed-rootfs adds a rootfs, which is either a folder or a image.bb file. > > > > > on the .wks file. > > > > Signed-off-by: Ricardo Ribalda Delgado > > --- > > scripts/lib/wic/help.py | 8 ++++++++ > > scripts/lib/wic/ksparser.py | 1 + > > scripts/lib/wic/partition.py | 1 + > > scripts/lib/wic/plugins/source/rootfs.py | 22 +++++++++++++++++++++- > > 4 files changed, 31 insertions(+), 1 deletion(-) > > > > diff --git a/scripts/lib/wic/help.py b/scripts/lib/wic/help.py > > index 4d342fcf05..140dc504cd 100644 > > --- a/scripts/lib/wic/help.py > > +++ b/scripts/lib/wic/help.py > > @@ -979,6 +979,14 @@ DESCRIPTION > > copies. This option only has an effect with the rootfs > > source plugin. > > > > + --embed-rootfs: This option is specific to wic. It embeds a rootfs into > > + the given path to the resulting image. The option > > + contains two fields, the roofs and the path, separated > > + by a space. The rootfs follows the same logic as the > > + rootfs-dir argument. Multiple options can be provided > > + in order to embed multiple rootfs. This option only has > > + an effect with the rootfs source plugin. > > + > > --extra-space: This option is specific to wic. It adds extra > > space after the space filled by the content > > of the partition. The final size can go > > diff --git a/scripts/lib/wic/ksparser.py b/scripts/lib/wic/ksparser.py > > index 650b976223..64c8c1175e 100644 > > --- a/scripts/lib/wic/ksparser.py > > +++ b/scripts/lib/wic/ksparser.py > > @@ -138,6 +138,7 @@ class KickStart(): > > part.add_argument('--align', type=int) > > part.add_argument('--exclude-path', nargs='+') > > part.add_argument('--include-path', nargs='+') > > + part.add_argument('--embed-rootfs', nargs=2, action='append') > > part.add_argument("--extra-space", type=sizetype) > > part.add_argument('--fsoptions', dest='fsopts') > > part.add_argument('--fstype', default='vfat', > > diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py > > index 2d95f78439..13857df82f 100644 > > --- a/scripts/lib/wic/partition.py > > +++ b/scripts/lib/wic/partition.py > > @@ -31,6 +31,7 @@ class Partition(): > > self.extra_space = args.extra_space > > self.exclude_path = args.exclude_path > > self.include_path = args.include_path > > + self.embed_rootfs = args.embed_rootfs > > self.fsopts = args.fsopts > > self.fstype = args.fstype > > self.label = args.label > > diff --git a/scripts/lib/wic/plugins/source/rootfs.py b/scripts/lib/wic/plugins/source/rootfs.py > > index 40419a64b3..089aaea477 100644 > > --- a/scripts/lib/wic/plugins/source/rootfs.py > > +++ b/scripts/lib/wic/plugins/source/rootfs.py > > @@ -17,6 +17,7 @@ import shutil > > import sys > > > > from oe.path import copyhardlinktree, copytree > > +from pathlib import Path > > > > from wic import WicError > > from wic.pluginbase import SourcePlugin > > @@ -80,7 +81,7 @@ class RootfsPlugin(SourcePlugin): > > > > new_rootfs = None > > # Handle excluded paths. > > - if part.exclude_path or part.include_path: > > + if part.exclude_path or part.include_path or part.embed_rootfs: > > # We need a new rootfs directory we can delete files from. Copy to > > # workdir. > > new_rootfs = os.path.realpath(os.path.join(cr_workdir, "rootfs%d" % part.lineno)) > > @@ -100,6 +101,25 @@ class RootfsPlugin(SourcePlugin): > > for path in part.include_path or []: > > copyhardlinktree(path, new_rootfs) > > > > + for embed in part.embed_rootfs or []: > > + [embed_rootfs, path] = embed > > + #we need to remove the initial / for os.path.join to work > > + if os.path.isabs(path): > > + path = path[1:] > > + if embed_rootfs in krootfs_dir: > > + embed_rootfs = krootfs_dir[embed_rootfs] > > + embed_rootfs = cls.__get_rootfs_dir(embed_rootfs) > > + tar_file = os.path.realpath(os.path.join(cr_workdir, "aux.tar")) > > + tar_cmd = "%s tar cpf %s -C %s ." % (cls.__get_pseudo(native_sysroot, > > + embed_rootfs), tar_file, embed_rootfs) > > + exec_native_cmd(tar_cmd, native_sysroot) > > + untar_cmd = "%s tar xf %s -C %s ." % (cls.__get_pseudo(native_sysroot, new_rootfs), > > + tar_file, os.path.join(new_rootfs, path)) > > + Path(os.path.join(new_rootfs, path)).mkdir(parents=True, exist_ok=True) > > + exec_native_cmd(untar_cmd, native_sysroot, > > + cls.__get_pseudo(native_sysroot, new_rootfs)) > > + os.remove(tar_file) > > + > > for orig_path in part.exclude_path or []: > > path = orig_path > > if os.path.isabs(path): > > As said in my other email, if you're running wic outside bitbake I'm not sure > you can guarantee pseudo is available. And now I think about it, if you're > running wic inside bitbake (as part of do_image_wic), you'd be running pseudo > under pseudo and I have no idea how that would work out. > pseudo is warranted because wic launches "bitbake wic-tools", which has as DEPENDS pseudo-native. scripts/wic: subprocess.check_call(["bitbake", "wic-tools"]) I have tried to run it inside bitbake with --exclude-path and everything seems to work fine. > -- > Paul Barker > Konsulko Group -- Ricardo Ribalda From hnathan918 at gmail.com Thu Mar 5 15:41:19 2020 From: hnathan918 at gmail.com (Nathan Hartman) Date: Thu, 5 Mar 2020 07:41:19 -0800 Subject: [OE-core] [PATCH v2] mesa: updated to 20.0 release Message-ID: <20200305154119.120789-1-hnathan918@gmail.com> Updated mesa and mesa-gl recipes to 20.0 release. The license checksum difference is due to a small change in the license formatting. The asterisk for footnotes was changed to a '[1]' See: https://gitlab.freedesktop.org/mesa/mesa/-/commit/199572b65b7a03ffc887783e7f0f96f95bf1f99d glxgears runs successfully at 60 fps on a rpi4. Signed-off-by: Nathan Hartman --- .../mesa/{mesa-gl_19.3.4.bb => mesa-gl_20.0.0.bb} | 0 meta/recipes-graphics/mesa/mesa.inc | 2 +- meta/recipes-graphics/mesa/{mesa_19.3.4.bb => mesa_20.0.0.bb} | 4 ++-- 3 files changed, 3 insertions(+), 3 deletions(-) rename meta/recipes-graphics/mesa/{mesa-gl_19.3.4.bb => mesa-gl_20.0.0.bb} (100%) rename meta/recipes-graphics/mesa/{mesa_19.3.4.bb => mesa_20.0.0.bb} (88%) diff --git a/meta/recipes-graphics/mesa/mesa-gl_19.3.4.bb b/meta/recipes-graphics/mesa/mesa-gl_20.0.0.bb similarity index 100% rename from meta/recipes-graphics/mesa/mesa-gl_19.3.4.bb rename to meta/recipes-graphics/mesa/mesa-gl_20.0.0.bb diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-graphics/mesa/mesa.inc index 54d7ea8961..b7ef496fdc 100644 --- a/meta/recipes-graphics/mesa/mesa.inc +++ b/meta/recipes-graphics/mesa/mesa.inc @@ -10,7 +10,7 @@ HOMEPAGE = "http://mesa3d.org" BUGTRACKER = "https://bugs.freedesktop.org" SECTION = "x11" LICENSE = "MIT" -LIC_FILES_CHKSUM = "file://docs/license.html;md5=3a4999caf82cc503ac8b9e37c235782e" +LIC_FILES_CHKSUM = "file://docs/license.html;md5=c1843d93c460bbf778d6037ce324f9f7" PE = "2" diff --git a/meta/recipes-graphics/mesa/mesa_19.3.4.bb b/meta/recipes-graphics/mesa/mesa_20.0.0.bb similarity index 88% rename from meta/recipes-graphics/mesa/mesa_19.3.4.bb rename to meta/recipes-graphics/mesa/mesa_20.0.0.bb index 5f456c2429..2ed7ca2252 100644 --- a/meta/recipes-graphics/mesa/mesa_19.3.4.bb +++ b/meta/recipes-graphics/mesa/mesa_20.0.0.bb @@ -9,8 +9,8 @@ SRC_URI = "https://mesa.freedesktop.org/archive/mesa-${PV}.tar.xz \ file://0001-meson-misdetects-64bit-atomics-on-mips-clang.patch \ " -SRC_URI[md5sum] = "09e7700d9af511384d131fb77b5802cb" -SRC_URI[sha256sum] = "1da467e6ae2799a517e242462331eafd29ae77d9872f3a845df81f7c308e8fe4" +SRC_URI[md5sum] = "681229d992bbd6250a5be4f308708795" +SRC_URI[sha256sum] = "bb6db3e54b608d2536d4000b3de7dd3ae115fc114e8acbb5afff4b3bbed04b34" UPSTREAM_CHECK_GITTAGREGEX = "mesa-(?P\d+(\.\d+)+)" -- 2.17.1 From git at andred.net Thu Mar 5 16:20:27 2020 From: git at andred.net (=?ISO-8859-1?Q?Andr=E9?= Draszik) Date: Thu, 05 Mar 2020 16:20:27 +0000 Subject: [OE-core] [PATCH] linux-firmware: use 'make install' for installation In-Reply-To: <20200304101307.31198-1-alex.kanavin@gmail.com> References: <20200304101307.31198-1-alex.kanavin@gmail.com> Message-ID: On Wed, 2020-03-04 at 11:13 +0100, Alexander Kanavin wrote: > Copying the source tree over was missing important symlinks > that since recent updates can only be created with make install. Thanks for the quick fix Alex, but unfortunately now all the -license packages are non-existent and image creation fails, because their install: target doesn't copy the license files. Cheers, Andre' > > Signed-off-by: Alexander Kanavin > --- > .../linux-firmware/linux-firmware_20200122.bb | 22 +------------------ > 1 file changed, 1 insertion(+), 21 deletions(-) > > diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb b/meta/recipes-kernel/linux-firmware/linux- > firmware_20200122.bb > index 0d1422cfca..f7198cb56a 100644 > --- a/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb > +++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb > @@ -208,27 +208,7 @@ do_compile() { > } > > do_install() { > - install -d ${D}${nonarch_base_libdir}/firmware/ > - cp -r * ${D}${nonarch_base_libdir}/firmware/ > - > - # Avoid Makefile to be deployed > - rm ${D}${nonarch_base_libdir}/firmware/Makefile > - > - # Remove unbuild firmware which needs cmake and bash > - rm ${D}${nonarch_base_libdir}/firmware/carl9170fw -rf > - > - # Remove pointless bash script > - rm ${D}${nonarch_base_libdir}/firmware/configure > - > - # Remove python script used to check the WHENCE file > - rm ${D}${nonarch_base_libdir}/firmware/check_whence.py > - > - # Libertas sd8686 > - ln -sf libertas/sd8686_v9.bin ${D}${nonarch_base_libdir}/firmware/sd8686.bin > - ln -sf libertas/sd8686_v9_helper.bin ${D}${nonarch_base_libdir}/firmware/sd8686_helper.bin > - > - # fixup wl12xx location, after 2.6.37 the kernel searches a different location for it > - ( cd ${D}${nonarch_base_libdir}/firmware ; ln -sf ti-connectivity/* . ) > + oe_runmake 'DESTDIR=${D}' install > } > > > -- > 2.25.1 > From pjtexier at koncepto.io Thu Mar 5 16:33:53 2020 From: pjtexier at koncepto.io (Pierre-Jean Texier) Date: Thu, 5 Mar 2020 17:33:53 +0100 Subject: [OE-core] [PATCH] curl: upgrade 7.68.0 -> 7.69.0 Message-ID: <1583426033-30063-1-git-send-email-pjtexier@koncepto.io> Bugfix release. For details, see full changelog - https://curl.haxx.se/changes.html#7_69_0 Signed-off-by: Pierre-Jean Texier --- meta/recipes-support/curl/{curl_7.68.0.bb => curl_7.69.0.bb} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename meta/recipes-support/curl/{curl_7.68.0.bb => curl_7.69.0.bb} (95%) diff --git a/meta/recipes-support/curl/curl_7.68.0.bb b/meta/recipes-support/curl/curl_7.69.0.bb similarity index 95% rename from meta/recipes-support/curl/curl_7.68.0.bb rename to meta/recipes-support/curl/curl_7.69.0.bb index 0a1547c..cf4f4bc 100644 --- a/meta/recipes-support/curl/curl_7.68.0.bb +++ b/meta/recipes-support/curl/curl_7.69.0.bb @@ -9,8 +9,8 @@ SRC_URI = "http://curl.haxx.se/download/curl-${PV}.tar.bz2 \ file://0001-replace-krb5-config-with-pkg-config.patch \ " -SRC_URI[md5sum] = "40d6784bd1a86e079d63cc668ba9bd8f" -SRC_URI[sha256sum] = "207f54917dd6a2dc733065ccf18d61bb5bebeaceb5df49cd9445483e8623eeb9" +SRC_URI[md5sum] = "04eb86d1138c2ff3dbfd497f7de85daa" +SRC_URI[sha256sum] = "668d451108a7316cff040b23c79bc766e7ed84122074e44f662b8982f2e76739" CVE_PRODUCT = "curl libcurl" inherit autotools pkgconfig binconfig multilib_header -- 2.7.4 From alex.kanavin at gmail.com Thu Mar 5 16:44:52 2020 From: alex.kanavin at gmail.com (Alexander Kanavin) Date: Thu, 5 Mar 2020 17:44:52 +0100 Subject: [OE-core] [PATCH] linux-firmware: use 'make install' for installation In-Reply-To: References: <20200304101307.31198-1-alex.kanavin@gmail.com> Message-ID: Right I think this should be easy to fix, we need to copy LICENSE.* manually. I'll get to it soon. Alex On Thu, 5 Mar 2020 at 17:20, Andr? Draszik wrote: > On Wed, 2020-03-04 at 11:13 +0100, Alexander Kanavin wrote: > > Copying the source tree over was missing important symlinks > > that since recent updates can only be created with make install. > > Thanks for the quick fix Alex, but unfortunately now all the -license > packages > are non-existent and image creation fails, because their install: target > doesn't copy the license files. > > Cheers, > Andre' > > > > > Signed-off-by: Alexander Kanavin > > --- > > .../linux-firmware/linux-firmware_20200122.bb | 22 +------------------ > > 1 file changed, 1 insertion(+), 21 deletions(-) > > > > diff --git a/meta/recipes-kernel/linux-firmware/ > linux-firmware_20200122.bb b/meta/recipes-kernel/linux-firmware/linux- > > firmware_20200122.bb > > index 0d1422cfca..f7198cb56a 100644 > > --- a/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb > > +++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb > > @@ -208,27 +208,7 @@ do_compile() { > > } > > > > do_install() { > > - install -d ${D}${nonarch_base_libdir}/firmware/ > > - cp -r * ${D}${nonarch_base_libdir}/firmware/ > > - > > - # Avoid Makefile to be deployed > > - rm ${D}${nonarch_base_libdir}/firmware/Makefile > > - > > - # Remove unbuild firmware which needs cmake and bash > > - rm ${D}${nonarch_base_libdir}/firmware/carl9170fw -rf > > - > > - # Remove pointless bash script > > - rm ${D}${nonarch_base_libdir}/firmware/configure > > - > > - # Remove python script used to check the WHENCE file > > - rm ${D}${nonarch_base_libdir}/firmware/check_whence.py > > - > > - # Libertas sd8686 > > - ln -sf libertas/sd8686_v9.bin > ${D}${nonarch_base_libdir}/firmware/sd8686.bin > > - ln -sf libertas/sd8686_v9_helper.bin > ${D}${nonarch_base_libdir}/firmware/sd8686_helper.bin > > - > > - # fixup wl12xx location, after 2.6.37 the kernel searches a > different location for it > > - ( cd ${D}${nonarch_base_libdir}/firmware ; ln -sf > ti-connectivity/* . ) > > + oe_runmake 'DESTDIR=${D}' install > > } > > > > > > -- > > 2.25.1 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From git at andred.net Thu Mar 5 16:56:17 2020 From: git at andred.net (=?ISO-8859-1?Q?Andr=E9?= Draszik) Date: Thu, 05 Mar 2020 16:56:17 +0000 Subject: [OE-core] [PATCH] linux-firmware: use 'make install' for installation In-Reply-To: References: <20200304101307.31198-1-alex.kanavin@gmail.com> Message-ID: On Thu, 2020-03-05 at 17:44 +0100, Alexander Kanavin wrote: > Right I think this should be easy to fix, we need to copy LICENSE.* manually. I'll get to it soon. > Keep in mind there's different spelling, and two more files :-) This works for me: + cp -r GPL-2 LICENCE.* LICENSE.* WHENCE ${D}${nonarch_base_libdir}/firmware/ Cheers, A. > Alex > > On Thu, 5 Mar 2020 at 17:20, Andr? Draszik wrote: > > On Wed, 2020-03-04 at 11:13 +0100, Alexander Kanavin wrote: > > > Copying the source tree over was missing important symlinks > > > that since recent updates can only be created with make install. > > > > Thanks for the quick fix Alex, but unfortunately now all the -license packages > > are non-existent and image creation fails, because their install: target > > doesn't copy the license files. > > > > Cheers, > > Andre' > > > > > > > > Signed-off-by: Alexander Kanavin > > > --- > > > .../linux-firmware/linux-firmware_20200122.bb | 22 +------------------ > > > 1 file changed, 1 insertion(+), 21 deletions(-) > > > > > > diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb b/meta/recipes-kernel/linux- > > firmware/linux- > > > firmware_20200122.bb > > > index 0d1422cfca..f7198cb56a 100644 > > > --- a/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb > > > +++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb > > > @@ -208,27 +208,7 @@ do_compile() { > > > } > > > > > > do_install() { > > > - install -d ${D}${nonarch_base_libdir}/firmware/ > > > - cp -r * ${D}${nonarch_base_libdir}/firmware/ > > > - > > > - # Avoid Makefile to be deployed > > > - rm ${D}${nonarch_base_libdir}/firmware/Makefile > > > - > > > - # Remove unbuild firmware which needs cmake and bash > > > - rm ${D}${nonarch_base_libdir}/firmware/carl9170fw -rf > > > - > > > - # Remove pointless bash script > > > - rm ${D}${nonarch_base_libdir}/firmware/configure > > > - > > > - # Remove python script used to check the WHENCE file > > > - rm ${D}${nonarch_base_libdir}/firmware/check_whence.py > > > - > > > - # Libertas sd8686 > > > - ln -sf libertas/sd8686_v9.bin ${D}${nonarch_base_libdir}/firmware/sd8686.bin > > > - ln -sf libertas/sd8686_v9_helper.bin ${D}${nonarch_base_libdir}/firmware/sd8686_helper.bin > > > - > > > - # fixup wl12xx location, after 2.6.37 the kernel searches a different location for it > > > - ( cd ${D}${nonarch_base_libdir}/firmware ; ln -sf ti-connectivity/* . ) > > > + oe_runmake 'DESTDIR=${D}' install > > > } > > > > > > > > > -- > > > 2.25.1 > > > > > From alex.kanavin at gmail.com Thu Mar 5 18:41:38 2020 From: alex.kanavin at gmail.com (Alexander Kanavin) Date: Thu, 5 Mar 2020 19:41:38 +0100 Subject: [OE-core] [PATCH] linux-firmware: use 'make install' for installation In-Reply-To: References: <20200304101307.31198-1-alex.kanavin@gmail.com> Message-ID: Maybe you could send a follow up patch then? I won?t get to it until tomorrow. Alex On Thu 5. Mar 2020 at 17.56, Andr? Draszik wrote: > On Thu, 2020-03-05 at 17:44 +0100, Alexander Kanavin wrote: > > Right I think this should be easy to fix, we need to copy LICENSE.* > manually. I'll get to it soon. > > > > Keep in mind there's different spelling, and two more files :-) > This works for me: > > + cp -r GPL-2 LICENCE.* LICENSE.* WHENCE > ${D}${nonarch_base_libdir}/firmware/ > > > Cheers, > A. > > > Alex > > > > On Thu, 5 Mar 2020 at 17:20, Andr? Draszik wrote: > > > On Wed, 2020-03-04 at 11:13 +0100, Alexander Kanavin wrote: > > > > Copying the source tree over was missing important symlinks > > > > that since recent updates can only be created with make install. > > > > > > Thanks for the quick fix Alex, but unfortunately now all the -license > packages > > > are non-existent and image creation fails, because their install: > target > > > doesn't copy the license files. > > > > > > Cheers, > > > Andre' > > > > > > > > > > > Signed-off-by: Alexander Kanavin > > > > --- > > > > .../linux-firmware/linux-firmware_20200122.bb | 22 > +------------------ > > > > 1 file changed, 1 insertion(+), 21 deletions(-) > > > > > > > > diff --git a/meta/recipes-kernel/linux-firmware/ > linux-firmware_20200122.bb b/meta/recipes-kernel/linux- > > > firmware/linux- > > > > firmware_20200122.bb > > > > index 0d1422cfca..f7198cb56a 100644 > > > > --- a/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb > > > > +++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb > > > > @@ -208,27 +208,7 @@ do_compile() { > > > > } > > > > > > > > do_install() { > > > > - install -d ${D}${nonarch_base_libdir}/firmware/ > > > > - cp -r * ${D}${nonarch_base_libdir}/firmware/ > > > > - > > > > - # Avoid Makefile to be deployed > > > > - rm ${D}${nonarch_base_libdir}/firmware/Makefile > > > > - > > > > - # Remove unbuild firmware which needs cmake and bash > > > > - rm ${D}${nonarch_base_libdir}/firmware/carl9170fw -rf > > > > - > > > > - # Remove pointless bash script > > > > - rm ${D}${nonarch_base_libdir}/firmware/configure > > > > - > > > > - # Remove python script used to check the WHENCE file > > > > - rm ${D}${nonarch_base_libdir}/firmware/check_whence.py > > > > - > > > > - # Libertas sd8686 > > > > - ln -sf libertas/sd8686_v9.bin > ${D}${nonarch_base_libdir}/firmware/sd8686.bin > > > > - ln -sf libertas/sd8686_v9_helper.bin > ${D}${nonarch_base_libdir}/firmware/sd8686_helper.bin > > > > - > > > > - # fixup wl12xx location, after 2.6.37 the kernel searches a > different location for it > > > > - ( cd ${D}${nonarch_base_libdir}/firmware ; ln -sf > ti-connectivity/* . ) > > > > + oe_runmake 'DESTDIR=${D}' install > > > > } > > > > > > > > > > > > -- > > > > 2.25.1 > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sk at typedivision.de Thu Mar 5 19:30:00 2020 From: sk at typedivision.de (Stefan Kral) Date: Thu, 5 Mar 2020 20:30:00 +0100 Subject: [OE-core] [PATCH] oeqa-runtime: add missing import os to ptest case Message-ID: <20200305193000.34658-1-sk@typedivision.de> Add missing import os statement to the oeqa runtime ptest.py Signed-off-by: Stefan Kral --- meta/lib/oeqa/runtime/cases/ptest.py | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/lib/oeqa/runtime/cases/ptest.py b/meta/lib/oeqa/runtime/cases/ptest.py index 5626f707b9..99a44f0767 100644 --- a/meta/lib/oeqa/runtime/cases/ptest.py +++ b/meta/lib/oeqa/runtime/cases/ptest.py @@ -2,6 +2,7 @@ # SPDX-License-Identifier: MIT # +import os import unittest import pprint import datetime -- 2.17.2 (Apple Git-113) From git at andred.net Thu Mar 5 20:27:39 2020 From: git at andred.net (=?UTF-8?q?Andr=C3=A9=20Draszik?=) Date: Thu, 5 Mar 2020 20:27:39 +0000 Subject: [OE-core] [master-next] linux-firmware: install / package all license files again Message-ID: <20200305202739.21127-1-git@andred.net> This doesn't happen with make install, hence all the -license packages are missing, since they'd otherwise be empty. Signed-off-by: Andr? Draszik --- meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb b/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb index f7198cb56a..6039dc9d71 100644 --- a/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb +++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb @@ -209,6 +209,7 @@ do_compile() { do_install() { oe_runmake 'DESTDIR=${D}' install + cp GPL-2 LICEN[CS]E.* WHENCE ${D}${nonarch_base_libdir}/firmware/ } -- 2.23.0.rc1 From git at andred.net Thu Mar 5 20:32:07 2020 From: git at andred.net (=?UTF-8?q?Andr=C3=A9=20Draszik?=) Date: Thu, 5 Mar 2020 20:32:07 +0000 Subject: [OE-core] [PATCH][master-next] linux-firmware: also install / package all license files Message-ID: <20200305203207.20498-1-git@andred.net> This doesn't happen with make install, hence all the -license packages are missing, since they'd otherwise be empty. Signed-off-by: Andr? Draszik --- meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb b/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb index f7198cb56a..6039dc9d71 100644 --- a/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb +++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb @@ -209,6 +209,7 @@ do_compile() { do_install() { oe_runmake 'DESTDIR=${D}' install + cp GPL-2 LICEN[CS]E.* WHENCE ${D}${nonarch_base_libdir}/firmware/ } -- 2.23.0.rc1 From raj.khem at gmail.com Thu Mar 5 21:18:55 2020 From: raj.khem at gmail.com (Khem Raj) Date: Thu, 5 Mar 2020 13:18:55 -0800 Subject: [OE-core] [PATCH] pulseaudio: Fix inline assembly syntax for arm Message-ID: <20200305211855.1015522-1-raj.khem@gmail.com> Ensures that gcc can use right operand constraints Signed-off-by: Khem Raj --- ...ap-arm-Adjust-inline-asm-constraints.patch | 114 ++++++++++++++++++ .../pulseaudio/pulseaudio_13.0.bb | 1 + 2 files changed, 115 insertions(+) create mode 100644 meta/recipes-multimedia/pulseaudio/pulseaudio/0001-remap-arm-Adjust-inline-asm-constraints.patch diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio/0001-remap-arm-Adjust-inline-asm-constraints.patch b/meta/recipes-multimedia/pulseaudio/pulseaudio/0001-remap-arm-Adjust-inline-asm-constraints.patch new file mode 100644 index 0000000000..95133fd9d4 --- /dev/null +++ b/meta/recipes-multimedia/pulseaudio/pulseaudio/0001-remap-arm-Adjust-inline-asm-constraints.patch @@ -0,0 +1,114 @@ +From 3450d1fcfe8a8f84553ab299cd96ae0705ddffbe Mon Sep 17 00:00:00 2001 +From: Khem Raj +Date: Thu, 5 Mar 2020 11:48:28 -0800 +Subject: [PATCH] remap/arm: Adjust inline asm constraints + +gcc10 can effectively emit single precision registers if right +operand modifier constraint is not in use + +This results in assembler rejecting the code + +/tmp/ccEG4QpI.s:646: Error: VFP/Neon double precision register expected -- `vtbl.8 d3,{d0,d1},s8' +/tmp/ccEG4QpI.s:678: Error: invalid instruction shape -- `vmul.f32 d0,d0,s8' + +Therefore add %P qualifier to request double registers sinece 'w' could +mean variable could be stored in s0..s14 and GCC defaults to printing out s0..s14. +Note those registers map to d0..d7 also. + +Output generated is exactly same with gcc9, and it also now compiles +with gcc10 + +Its not documented well in gcc docs and there is a ticket for that +https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84343 + +Upstream-Status: Submitted [https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/261] +Signed-off-by: Khem Raj +--- + src/pulsecore/remap_neon.c | 22 +++++++++++----------- + 1 file changed, 11 insertions(+), 11 deletions(-) + +diff --git a/src/pulsecore/remap_neon.c b/src/pulsecore/remap_neon.c +index 41208986d..ca3b95b48 100644 +--- a/src/pulsecore/remap_neon.c ++++ b/src/pulsecore/remap_neon.c +@@ -189,7 +189,7 @@ static void remap_ch4_to_mono_float32ne_neon(pa_remap_t *m, float *dst, const fl + "vadd.f32 d0, d0, d1 \n\t" + "vadd.f32 d2, d2, d3 \n\t" + "vadd.f32 d0, d0, d2 \n\t" +- "vmul.f32 d0, d0, %[quart] \n\t" ++ "vmul.f32 d0, d0, %P[quart] \n\t" + "vst1.32 {d0}, [%[dst]]! \n\t" + : [dst] "+r" (dst), [src] "+r" (src) /* output operands */ + : [quart] "w" (quart) /* input operands */ +@@ -276,7 +276,7 @@ static void remap_arrange_stereo_s16ne_neon(pa_remap_t *m, int16_t *dst, const i + for (; n >= 2; n -= 2) { + __asm__ __volatile__ ( + "vld1.s16 d0, [%[src]]! \n\t" +- "vtbl.8 d0, {d0}, %[t] \n\t" ++ "vtbl.8 d0, {d0}, %P[t] \n\t" + "vst1.s16 d0, [%[dst]]! \n\t" + : [dst] "+r" (dst), [src] "+r" (src) /* output operands */ + : [t] "w" (t) /* input operands */ +@@ -287,7 +287,7 @@ static void remap_arrange_stereo_s16ne_neon(pa_remap_t *m, int16_t *dst, const i + if (n > 0) { + __asm__ __volatile__ ( + "vld1.32 d0[0], [%[src]]! \n\t" +- "vtbl.8 d0, {d0}, %[t] \n\t" ++ "vtbl.8 d0, {d0}, %P[t] \n\t" + "vst1.32 d0[0], [%[dst]]! \n\t" + : [dst] "+r" (dst), [src] "+r" (src) /* output operands */ + : [t] "w" (t) /* input operands */ +@@ -302,8 +302,8 @@ static void remap_arrange_ch2_ch4_s16ne_neon(pa_remap_t *m, int16_t *dst, const + for (; n > 0; n--) { + __asm__ __volatile__ ( + "vld1.32 d0[0], [%[src]]! \n\t" +- "vtbl.8 d0, {d0}, %[t] \n\t" +- "vst1.s16 d0, [%[dst]]! \n\t" ++ "vtbl.8 d0, {d0}, %P[t] \n\t" ++ "vst1.s16 d0, [%[dst]]! \n\t" + : [dst] "+r" (dst), [src] "+r" (src) /* output operands */ + : [t] "w" (t) /* input operands */ + : "memory", "d0" /* clobber list */ +@@ -317,7 +317,7 @@ static void remap_arrange_ch4_s16ne_neon(pa_remap_t *m, int16_t *dst, const int1 + for (; n > 0; n--) { + __asm__ __volatile__ ( + "vld1.s16 d0, [%[src]]! \n\t" +- "vtbl.8 d0, {d0}, %[t] \n\t" ++ "vtbl.8 d0, {d0}, %P[t] \n\t" + "vst1.s16 d0, [%[dst]]! \n\t" + : [dst] "+r" (dst), [src] "+r" (src) /* output operands */ + : [t] "w" (t) /* input operands */ +@@ -332,7 +332,7 @@ static void remap_arrange_stereo_float32ne_neon(pa_remap_t *m, float *dst, const + for (; n > 0; n--) { + __asm__ __volatile__ ( + "vld1.f32 d0, [%[src]]! \n\t" +- "vtbl.8 d0, {d0}, %[t] \n\t" ++ "vtbl.8 d0, {d0}, %P[t] \n\t" + "vst1.s16 {d0}, [%[dst]]! \n\t" + : [dst] "+r" (dst), [src] "+r" (src) /* output operands */ + : [t] "w" (t) /* input operands */ +@@ -349,8 +349,8 @@ static void remap_arrange_ch2_ch4_any32ne_neon(pa_remap_t *m, float *dst, const + for (; n > 0; n--) { + __asm__ __volatile__ ( + "vld1.f32 d0, [%[src]]! \n\t" +- "vtbl.8 d1, {d0}, %[t0] \n\t" +- "vtbl.8 d2, {d0}, %[t1] \n\t" ++ "vtbl.8 d1, {d0}, %P[t0] \n\t" ++ "vtbl.8 d2, {d0}, %P[t1] \n\t" + "vst1.s16 {d1,d2}, [%[dst]]! \n\t" + : [dst] "+r" (dst), [src] "+r" (src) /* output operands */ + : [t0] "w" (t0), [t1] "w" (t1) /* input operands */ +@@ -366,8 +366,8 @@ static void remap_arrange_ch4_float32ne_neon(pa_remap_t *m, float *dst, const fl + for (; n > 0; n--) { + __asm__ __volatile__ ( + "vld1.f32 {d0,d1}, [%[src]]! \n\t" +- "vtbl.8 d2, {d0,d1}, %[t0] \n\t" +- "vtbl.8 d3, {d0,d1}, %[t1] \n\t" ++ "vtbl.8 d2, {d0,d1}, %P[t0] \n\t" ++ "vtbl.8 d3, {d0,d1}, %P[t1] \n\t" + "vst1.s16 {d2,d3}, [%[dst]]! \n\t" + : [dst] "+r" (dst), [src] "+r" (src) /* output operands */ + : [t0] "w" (t0), [t1] "w" (t1) /* input operands */ +-- +2.25.1 + diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio_13.0.bb b/meta/recipes-multimedia/pulseaudio/pulseaudio_13.0.bb index 7f8ebc2090..601499b6da 100644 --- a/meta/recipes-multimedia/pulseaudio/pulseaudio_13.0.bb +++ b/meta/recipes-multimedia/pulseaudio/pulseaudio_13.0.bb @@ -3,6 +3,7 @@ require pulseaudio.inc SRC_URI = "http://freedesktop.org/software/pulseaudio/releases/${BP}.tar.xz \ file://0001-client-conf-Add-allow-autospawn-for-root.patch \ file://0002-do-not-display-CLFAGS-to-improve-reproducibility-bui.patch \ + file://0001-remap-arm-Adjust-inline-asm-constraints.patch \ file://volatiles.04_pulse \ " SRC_URI[md5sum] = "e41d606f90254ed45c90520faf83d95c" -- 2.25.1 From joe.slater at windriver.com Thu Mar 5 22:04:54 2020 From: joe.slater at windriver.com (Joe Slater) Date: Thu, 5 Mar 2020 14:04:54 -0800 Subject: [OE-core] [oe-core][PATCH 1/1] libdnf: fix deprecation warning Message-ID: <20200305220454.108763-1-joe.slater@windriver.com> Backport from libdnf. Fix is in version 0.35.2. Signed-off-by: Joe Slater --- .../libdnf/libdnf/fix-deprecation-warning.patch | 71 ++++++++++++++++++++++ meta/recipes-devtools/libdnf/libdnf_0.28.1.bb | 1 + 2 files changed, 72 insertions(+) create mode 100644 meta/recipes-devtools/libdnf/libdnf/fix-deprecation-warning.patch diff --git a/meta/recipes-devtools/libdnf/libdnf/fix-deprecation-warning.patch b/meta/recipes-devtools/libdnf/libdnf/fix-deprecation-warning.patch new file mode 100644 index 0000000..3a3e02f --- /dev/null +++ b/meta/recipes-devtools/libdnf/libdnf/fix-deprecation-warning.patch @@ -0,0 +1,71 @@ +From 66d9b2ba3fbc7b04f2b5ad9d0e5371340c037b5f Mon Sep 17 00:00:00 2001 +From: Marek Blaha +Date: Wed, 10 Jul 2019 10:11:01 +0200 +Subject: [oe-core][PATCH 1/1] Fix Python 3.8 deprecation warning + (RhBug:1724244) + +This deprecation warning was introduced in Python 3.8 by +https://bugs.python.org/issue36381: + +/usr/lib/python3.8/site-packages/dnf/package.py:57: DeprecationWarning: PY_SSIZE_T_CLEAN will be required for '#' formats + return super(Package, self).chksum + +https://bugzilla.redhat.com/show_bug.cgi?id=1724244 +--- + python/hawkey/package-py.cpp | 3 ++- + python/hawkey/packagedelta-py.cpp | 3 ++- + 2 files changed, 4 insertions(+), 2 deletions(-) +--- + +Unchanged. Appears in version 0.35.2. + +Upstream-Status: Backport [git://github.com/rpm-software-management/libdnf.git] + +Signed-off-by: Joe Slater + + +diff --git a/python/hawkey/package-py.cpp b/python/hawkey/package-py.cpp +index 5102bba..68e03cb 100644 +--- a/python/hawkey/package-py.cpp ++++ b/python/hawkey/package-py.cpp +@@ -18,6 +18,7 @@ + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + */ + ++#define PY_SSIZE_T_CLEAN + #include + #include + +@@ -251,7 +252,7 @@ get_chksum(_PackageObject *self, void *closure) + #if PY_MAJOR_VERSION < 3 + res = Py_BuildValue("is#", type, cs, checksum_length); + #else +- res = Py_BuildValue("iy#", type, cs, checksum_length); ++ res = Py_BuildValue("iy#", type, cs, (Py_ssize_t)checksum_length); + #endif + + return res; +diff --git a/python/hawkey/packagedelta-py.cpp b/python/hawkey/packagedelta-py.cpp +index ca1cb7d..1a64836 100644 +--- a/python/hawkey/packagedelta-py.cpp ++++ b/python/hawkey/packagedelta-py.cpp +@@ -18,6 +18,7 @@ + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + */ + ++#define PY_SSIZE_T_CLEAN + #include + + // hawkey +@@ -92,7 +93,7 @@ get_chksum(_PackageDeltaObject *self, void *closure) + #if PY_MAJOR_VERSION < 3 + res = Py_BuildValue("is#", type, cs, checksum_length); + #else +- res = Py_BuildValue("iy#", type, cs, checksum_length); ++ res = Py_BuildValue("iy#", type, cs, (Py_ssize_t)checksum_length); + #endif + + return res; +-- +2.7.4 + diff --git a/meta/recipes-devtools/libdnf/libdnf_0.28.1.bb b/meta/recipes-devtools/libdnf/libdnf_0.28.1.bb index d498347..163a2ee 100644 --- a/meta/recipes-devtools/libdnf/libdnf_0.28.1.bb +++ b/meta/recipes-devtools/libdnf/libdnf_0.28.1.bb @@ -8,6 +8,7 @@ SRC_URI = "git://github.com/rpm-software-management/libdnf \ file://0001-Get-parameters-for-both-libsolv-and-libsolvext-libdn.patch \ file://0001-Add-WITH_TESTS-option.patch \ file://0001-include-stdexcept-for-runtime_error.patch \ + file://fix-deprecation-warning.patch \ " SRCREV = "751f89045b80d58c0d05800f74357cf78cdf7e77" -- 2.7.4 From adrian.freihofer at siemens.com Thu Mar 5 22:56:15 2020 From: adrian.freihofer at siemens.com (Freihofer, Adrian) Date: Thu, 5 Mar 2020 22:56:15 +0000 Subject: [OE-core] [PATCH] bitbake: gitsm: download submodules In-Reply-To: <20200305094209.3704f549@ub1910> References: <84e64ccddc46261a59bb1e281ef3294e08119abc.camel@siemens.com> <20200304095944.792423a0@ub1910> <20200305094209.3704f549@ub1910> Message-ID: <1292952b0e1fd7de3b123a1fbef8366cd7a22b80.camel@siemens.com> On Thu, 2020-03-05 at 09:42 +0000, Paul Barker wrote: > On Wed, 4 Mar 2020 12:30:10 +0000 > "Freihofer, Adrian" wrote: > > > -----Original Message----- > > From: Paul Barker > > To: "Freihofer, Adrian" > > Cc: openembedded-core at lists.openembedded.org < > > openembedded-core at lists.openembedded.org> > > Subject: Re: [OE-core] [PATCH] bitbake: gitsm: download submodules > > Date: Wed, 04 Mar 2020 09:59:44 +0000 > > > > On Wed, 4 Mar 2020 08:12:27 +0000 > > "Freihofer, Adrian" wrote: > > > > > The unpack function failed because the submodules were not > > > downloaded. > > > Calling download before unpack for each submodule solves this > > > issue. > > > > > > Signed-off-by: Adrian Freihofer > > > --- > > > bitbake/lib/bb/fetch2/gitsm.py | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/bitbake/lib/bb/fetch2/gitsm.py > > > b/bitbake/lib/bb/fetch2/gitsm.py > > > index c622771d21..3715e9824f 100644 > > > --- a/bitbake/lib/bb/fetch2/gitsm.py > > > +++ b/bitbake/lib/bb/fetch2/gitsm.py > > > @@ -184,6 +184,7 @@ class GitSM(Git): > > > > > > try: > > > newfetch = Fetch([url], d, cache=False) > > > + newfetch.download() > > > newfetch.unpack(root=os.path.dirname(os.path.joi > > > n(re > > > po > > > _conf, 'modules', module))) > > > except Exception as e: > > > logger.error('gitsm: submodule unpack failed: %s > > > %s' > > > % > > > (type(e).__name__, str(e))) > > > > You shouldn't be trying to download submodules in the do_unpack > > step. > > If > > they're missing at this stage it probably indicates a fetch issue. > > > > Basically true, but the information about which submodules need to > > be > > downloaded is not available before the top level repo has been > > unpacked. I guess the solution must be something like: > > > > fetch top-level > > unpack top-level > > foreach submodule: > > fetch submodule > > unpack submodule > > > > What's the exact error that you're seeing? > > > > Don't remeber exactly. But when I debugged the flow, it became > > obvious, > > that the submodules are not downloaded. > > > > This could be related to the issue I saw when the fetcher uses git > > shallow > > tarballs from a mirror - if that's the case I'm planning to get > > that > > fixed > > this weekend. > > > > Yes, the problem occurs with git shallows. The patch solves it with > > and > > without shallows for us. > > > > Also, your email client seems to have chewed the patch up. It's > > best to > > send > > patches using `git send-email` only. > > > > Sorry, we switched to a new e-mail solution. I have to adapt my > > setup. > > The problem with your patch is that it would require network access > during > do_unpack which then breaks our ability to do offline builds. Fetching in the unpack task is probably really wrong, I agree. However, it also works on our CI infrastructure which runs without Internet connectivity. > > Do you only see this issue when fetching from git shallow mirror > tarballs? On our CI which works with gitshallow archives, fetching did not work at all. On machines with Internet access we also had problems, but I did not completely analyze what happened. The ovmf package from poky was causing the troubles in our case. > If so, the mirror tarballs need to be extracted during do_fetch but > not placed in the usual 'git2' directory (as future fetches can't > cope with shallow clones in that directory). Do you already have an idea how this could be implemented? > > Fixing this also has some impact on archiver.bbclass as that also > needs to be able to walk the tree of submodules correctly. Yes. > From chee.yang.lee at intel.com Fri Mar 6 02:27:26 2020 From: chee.yang.lee at intel.com (chee.yang.lee at intel.com) Date: Fri, 6 Mar 2020 10:27:26 +0800 Subject: [OE-core] [PATCH] cve-check: show whitelisted status Message-ID: <1583461646-73057-1-git-send-email-chee.yang.lee@intel.com> From: Chee Yang Lee change whitelisted CVE status from "Patched" to "Whitelisted". [Yocto #13687] Signed-off-by: Chee Yang Lee --- meta/classes/cve-check.bbclass | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass index 7412436..7f98da6 100644 --- a/meta/classes/cve-check.bbclass +++ b/meta/classes/cve-check.bbclass @@ -56,10 +56,10 @@ python do_cve_check () { patched_cves = get_patches_cves(d) except FileNotFoundError: bb.fatal("Failure in searching patches") - patched, unpatched = check_cves(d, patched_cves) + whitelisted, patched, unpatched = check_cves(d, patched_cves) if patched or unpatched: cve_data = get_cve_info(d, patched + unpatched) - cve_write_data(d, patched, unpatched, cve_data) + cve_write_data(d, patched, unpatched, whitelisted, cve_data) else: bb.note("No CVE database found, skipping CVE check") @@ -263,7 +263,7 @@ def check_cves(d, patched_cves): conn.close() - return (list(patched_cves), cves_unpatched) + return (list(cve_whitelist), list(patched_cves), cves_unpatched) def get_cve_info(d, cves): """ @@ -287,7 +287,7 @@ def get_cve_info(d, cves): conn.close() return cve_data -def cve_write_data(d, patched, unpatched, cve_data): +def cve_write_data(d, patched, unpatched, whitelisted, cve_data): """ Write CVE information in WORKDIR; and to CVE_CHECK_DIR, and CVE manifest if enabled. @@ -303,7 +303,9 @@ def cve_write_data(d, patched, unpatched, cve_data): write_string += "PACKAGE NAME: %s\n" % d.getVar("PN") write_string += "PACKAGE VERSION: %s\n" % d.getVar("PV") write_string += "CVE: %s\n" % cve - if cve in patched: + if cve in whitelisted: + write_string += "CVE STATUS: Whitelisted\n" + elif cve in patched: write_string += "CVE STATUS: Patched\n" else: unpatched_cves.append(cve) -- 2.7.4 From tanuk at iki.fi Fri Mar 6 06:26:59 2020 From: tanuk at iki.fi (Tanu Kaskinen) Date: Fri, 06 Mar 2020 08:26:59 +0200 Subject: [OE-core] [PATCH V3] alsa-utils: upgrade 1.2.1 -> 1.2.2 In-Reply-To: <1c4e397e80d53d8ef779cf84b57dc4d051ef3238.camel@linuxfoundation.org> References: <20200223125620.6117-1-praveen.lisieux2011@gmail.com> <1c4e397e80d53d8ef779cf84b57dc4d051ef3238.camel@linuxfoundation.org> Message-ID: <579c97b18435e5145a0bea9f7f01a44c9d22c63a.camel@iki.fi> On Sun, 2020-02-23 at 13:11 +0000, Richard Purdie wrote: > On Sun, 2020-02-23 at 18:26 +0530, Praveen Muthusamy wrote: > > From: Praveen Muthusamy > > > > Changelog: https://alsa-project.org/wiki/Changes_v1.2.1.2_v1.2.2 > > > > Signed-off-by: Praveen Muthusamy > > --- > > ...lsa-utils-scripts_1.2.1.bb => alsa-utils-scripts_1.2.2.bb} | 0 > > .../alsa/{alsa-utils_1.2.1.bb => alsa-utils_1.2.2.bb} | 4 ++-- > > 2 files changed, 2 insertions(+), 2 deletions(-) > > rename meta/recipes-multimedia/alsa/{alsa-utils-scripts_1.2.1.bb => alsa-utils-scripts_1.2.2.bb} (100%) > > rename meta/recipes-multimedia/alsa/{alsa-utils_1.2.1.bb => alsa-utils_1.2.2.bb} (97%) > > Thanks, does this address the previous testing failure though? alsa-utils 1.2.2 seems to depend on alsa-lib 1.2.2 (specifically, alsatplg uses a new function in libatopology), so alsa-utils can't be updated before alsa-lib. -- Tanu https://www.patreon.com/tanuk https://liberapay.com/tanuk From ernst.sjostrand at verisure.com Fri Mar 6 07:41:23 2020 From: ernst.sjostrand at verisure.com (=?utf-8?B?RXJuc3QgU2rDtnN0cmFuZA==?=) Date: Fri, 6 Mar 2020 07:41:23 +0000 Subject: [OE-core] [PATCH v2] mesa: updated to 20.0 release In-Reply-To: <20200305154119.120789-1-hnathan918@gmail.com> References: <20200305154119.120789-1-hnathan918@gmail.com> Message-ID: Mesa usually says "This is a .0 release, and you may want to continue to to track 19.3.x until 20.0.1 comes out in two weeks. 19.3.5 is planned to be the final 19.3 release and is planned for next Wednesday." Luckily, 20.0.1 came out now! Regards //Ernst tor 2020-03-05 klockan 07:41 -0800 skrev Nathan Hartman: Updated mesa and mesa-gl recipes to 20.0 release. The license checksum difference is due to a small change in the license formatting. The asterisk for footnotes was changed to a '[1]' See: https://urldefense.com/v3/__https://gitlab.freedesktop.org/mesa/mesa/-/commit/199572b65b7a03ffc887783e7f0f96f95bf1f99d__;!!BFCLnRDDbM3FOmw!vm2EGt5MPmgb233VXYjTajZoZZmc6dc_QI6lMbnV1rbBkqhqY2B3uAYs7LL6gdJptVVzSw$ glxgears runs successfully at 60 fps on a rpi4. Signed-off-by: Nathan Hartman < hnathan918 at gmail.com > --- .../mesa/{mesa-gl_19.3.4.bb => mesa-gl_20.0.0.bb} | 0 meta/recipes-graphics/mesa/mesa.inc | 2 +- meta/recipes-graphics/mesa/{mesa_19.3.4.bb => mesa_20.0.0.bb} | 4 ++-- 3 files changed, 3 insertions(+), 3 deletions(-) rename meta/recipes-graphics/mesa/{mesa-gl_19.3.4.bb => mesa-gl_20.0.0.bb} (100%) rename meta/recipes-graphics/mesa/{mesa_19.3.4.bb => mesa_20.0.0.bb} (88%) diff --git a/meta/recipes-graphics/mesa/mesa-gl_19.3.4.bb b/meta/recipes-graphics/mesa/mesa-gl_20.0.0.bb similarity index 100% rename from meta/recipes-graphics/mesa/mesa-gl_19.3.4.bb rename to meta/recipes-graphics/mesa/mesa-gl_20.0.0.bb diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-graphics/mesa/mesa.inc index 54d7ea8961..b7ef496fdc 100644 --- a/meta/recipes-graphics/mesa/mesa.inc +++ b/meta/recipes-graphics/mesa/mesa.inc @@ -10,7 +10,7 @@ HOMEPAGE = " https://urldefense.com/v3/__http://mesa3d.org__;!!BFCLnRDDbM3FOmw!vm2EGt5MPmgb233VXYjTajZoZZmc6dc_QI6lMbnV1rbBkqhqY2B3uAYs7LL6gdIQHGBJ_A$ " BUGTRACKER = " https://urldefense.com/v3/__https://bugs.freedesktop.org__;!!BFCLnRDDbM3FOmw!vm2EGt5MPmgb233VXYjTajZoZZmc6dc_QI6lMbnV1rbBkqhqY2B3uAYs7LL6gdIQ_4aXZw$ " SECTION = "x11" LICENSE = "MIT" -LIC_FILES_CHKSUM = " file://docs/license.html;md5=3a4999caf82cc503ac8b9e37c235782e" +LIC_FILES_CHKSUM = " file://docs/license.html;md5=c1843d93c460bbf778d6037ce324f9f7" PE = "2" diff --git a/meta/recipes-graphics/mesa/mesa_19.3.4.bb b/meta/recipes-graphics/mesa/mesa_20.0.0.bb similarity index 88% rename from meta/recipes-graphics/mesa/mesa_19.3.4.bb rename to meta/recipes-graphics/mesa/mesa_20.0.0.bb index 5f456c2429..2ed7ca2252 100644 --- a/meta/recipes-graphics/mesa/mesa_19.3.4.bb +++ b/meta/recipes-graphics/mesa/mesa_20.0.0.bb @@ -9,8 +9,8 @@ SRC_URI = " https://urldefense.com/v3/__https://mesa.freedesktop.org/archive/mesa-$*7BPV*7D.tar.xz__;JSU!!BFCLnRDDbM3FOmw!vm2EGt5MPmgb233VXYjTajZoZZmc6dc_QI6lMbnV1rbBkqhqY2B3uAYs7LL6gdKys71eOA$ \ file://0001-meson-misdetects-64bit-atomics-on-mips-clang.patch \ " -SRC_URI[md5sum] = "09e7700d9af511384d131fb77b5802cb" -SRC_URI[sha256sum] = "1da467e6ae2799a517e242462331eafd29ae77d9872f3a845df81f7c308e8fe4" +SRC_URI[md5sum] = "681229d992bbd6250a5be4f308708795" +SRC_URI[sha256sum] = "bb6db3e54b608d2536d4000b3de7dd3ae115fc114e8acbb5afff4b3bbed04b34" UPSTREAM_CHECK_GITTAGREGEX = "mesa-(?P\d+(\.\d+)+)" -- 2.17.1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard.purdie at linuxfoundation.org Fri Mar 6 08:47:30 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Fri, 6 Mar 2020 08:47:30 +0000 Subject: [OE-core] [PATCH] sstate: Drop obsolete check in hash validation Message-ID: <20200306084730.1009856-1-richard.purdie@linuxfoundation.org> Now this function has a summary parameter we can drop this check. It could well be why the mysterious "locked sigs" selftest fails interemittently if this function were called with a single hash to check. [YOCTO #13605] (with luck) Signed-off-by: Richard Purdie --- meta/classes/sstate.bbclass | 4 ---- 1 file changed, 4 deletions(-) diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass index 0beeb33707b..c73c3b42a7f 100644 --- a/meta/classes/sstate.bbclass +++ b/meta/classes/sstate.bbclass @@ -966,10 +966,6 @@ def sstate_checkhashes(sq_data, d, siginfo=False, currentcount=0, summary=True, if len(tasklist) >= min_tasks: bb.event.fire(bb.event.ProcessFinished(msg), d) - # Likely checking an individual task hash again for multiconfig sharing of sstate tasks so skip reporting - if len(sq_data['hash']) == 1: - return found - inheritlist = d.getVar("INHERIT") if "toaster" in inheritlist: evdata = {'missed': [], 'found': []}; -- 2.25.0 From git at andred.net Fri Mar 6 09:35:14 2020 From: git at andred.net (=?UTF-8?q?Andr=C3=A9=20Draszik?=) Date: Fri, 6 Mar 2020 09:35:14 +0000 Subject: [OE-core] [PATCH 1/2] linux-firmware: drop remnants of pre-2.6.37 support (TI) Message-ID: <20200306093515.25244-1-git@andred.net> Now that this recipe uses make install, we don't manually create symlinks for firmware files for older kernel in do_install(). As such, the FILES statement can be updated as well. Signed-off-by: Andr? Draszik --- meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb | 3 --- 1 file changed, 3 deletions(-) diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb b/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb index 6039dc9d71..798e2b5c7c 100644 --- a/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb +++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb @@ -512,15 +512,12 @@ LICENSE_${PN}-ti-connectivity-license = "Firmware-ti-connectivity" FILES_${PN}-ti-connectivity-license = "${nonarch_base_libdir}/firmware/LICENCE.ti-connectivity" FILES_${PN}-wlcommon = " \ - ${nonarch_base_libdir}/firmware/TI* \ ${nonarch_base_libdir}/firmware/ti-connectivity/TI* \ " FILES_${PN}-wl12xx = " \ - ${nonarch_base_libdir}/firmware/wl12* \ ${nonarch_base_libdir}/firmware/ti-connectivity/wl12* \ " FILES_${PN}-wl18xx = " \ - ${nonarch_base_libdir}/firmware/wl18* \ ${nonarch_base_libdir}/firmware/ti-connectivity/wl18* \ " -- 2.23.0.rc1 From git at andred.net Fri Mar 6 09:35:15 2020 From: git at andred.net (=?UTF-8?q?Andr=C3=A9=20Draszik?=) Date: Fri, 6 Mar 2020 09:35:15 +0000 Subject: [OE-core] [PATCH 2/2] linux-firmware: TI: fix wl18xx support In-Reply-To: <20200306093515.25244-1-git@andred.net> References: <20200306093515.25244-1-git@andred.net> Message-ID: <20200306093515.25244-2-git@andred.net> wl1271-nvs.bin belongs to the wl18xx driver (and respective package created here), see kernel source. Due to the way packages are assembled here it ends up in the wrong package, though. Fix by placing it in the -common package as it's merely a symlink to wl127x-nvs.bin (which does belong to the wl12xx), so that both drivers have access to it. Signed-off-by: Andr? Draszik --- .../linux-firmware/linux-firmware_20200122.bb | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb b/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb index 798e2b5c7c..e9fedd1602 100644 --- a/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb +++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb @@ -511,8 +511,17 @@ LICENSE_${PN}-wl18xx = "Firmware-ti-connectivity" LICENSE_${PN}-ti-connectivity-license = "Firmware-ti-connectivity" FILES_${PN}-ti-connectivity-license = "${nonarch_base_libdir}/firmware/LICENCE.ti-connectivity" +# wl18xx optionally needs wl1271-nvs.bin (which itself is a symlink to +# wl127x-nvs.bin) - see linux/drivers/net/wireless/ti/wlcore/sdio.c +# and drivers/net/wireless/ti/wlcore/spi.c. +# While they're optional and actually only used to override the MAC +# address on wl18xx, driver loading will delay (by udev timout - 60s) +# if not there. So let's make it available always. Because it's a +# symlink, both need to go to wlcommon. FILES_${PN}-wlcommon = " \ ${nonarch_base_libdir}/firmware/ti-connectivity/TI* \ + ${nonarch_base_libdir}/firmware/ti-connectivity/wl127x-nvs.bin \ + ${nonarch_base_libdir}/firmware/ti-connectivity/wl1271-nvs.bin \ " FILES_${PN}-wl12xx = " \ ${nonarch_base_libdir}/firmware/ti-connectivity/wl12* \ -- 2.23.0.rc1 From bunk at stusta.de Fri Mar 6 10:04:22 2020 From: bunk at stusta.de (Adrian Bunk) Date: Fri, 6 Mar 2020 12:04:22 +0200 Subject: [OE-core] [Openembedded-architecture] Does YP provide security support for stable and LTS branches? In-Reply-To: <01b3bb37-f65f-8048-1a27-b859b62d7f98@gmail.com> References: <20200227132729.GA6240@localhost> <20200304090507.GA7923@localhost> <20200304113217.GB7923@localhost> <20200304140109.GC7923@localhost> <20200304172415.GA29456@localhost> <01b3bb37-f65f-8048-1a27-b859b62d7f98@gmail.com> Message-ID: <20200306100422.GA17785@localhost> On Wed, Mar 04, 2020 at 12:26:29PM -0800, akuster808 wrote: ... > On 3/4/20 9:24 AM, Adrian Bunk wrote: ... > > This could be combined with a call for help for security support, > > an advantage of being honest would be that it becomes visible for > > users that there is a resource shortage. > There are weekly status reports? and minutes from various meeting that > include the attendees list.? The attendees list has not grown. The build > swat team was shut down as no one stepped up to help. That was an > opportunity for the community to step up. Yocto is setup as a B2B project providing a basis for embedded products, your "community" are mainly companies. The "build everything yourself" niche for non-embedded is already occupied by Gentoo. For most community companies there is no clear Return on Investment if they would use the opportunity to invest in upstream involvement. > There is request for help regarding defects sent out every week and if > it wasn't for WindRiver, Intel, Joshua Watt and Richard the open defects > would go uncheck. > > So the resource issue has been floating around on the various mailing > lists for some time. What do you think needs to be done to make it even > more visible? >... You are confusing developers with users. Developers are following development discussions. Users who are being paid for building a product based on Yocto read the user information at https://www.yoctoproject.org/ especially the great manuals written by Scott. Development discussions are mostly irrelevant for users. To make a non-Yocto example: I am using Ubuntu LTS on my laptop. The security support provided by Canonical is essential for me, and as part of the community I am using their bugtracker in rare cases where I have problems. I have neither time nor interest in following upstream discussions regarding development of future Ubuntu releases. >... > >> The liability for insecure millions of devices does not lie > >> with the yocto project, it lies with the OEMs. > >> ... > > The liability for insecure millions of devices lies 100% with the Yocto > > Project if it claims to provide security support but does not actually > > provide it. > > > > If a user has to decide today whether an upcoming product will run > > Ubuntu 20.04 LTS or Yocto 3.1 LTS, then it should be clear to the > > user whether or not choosing Yocto will provide upstream security > > support the same way as Ubuntu. > > > > A user reading the YP LTS announcement expects security support similar > > to what Ubuntu is offering, and might only notice that this isn't true > > after a known vulnerability gets exploited on millions of devices. > I didn't get that out of the announcement. It only reference in the LTS > announcement? regarding Security was in context to Community support. >... The wording is "releases move to community support, which means they only receive occasional patches for critical defects and updates, and no regular defect fixes and security updates". When the move to community support means no regular security updates, this is a clear claim from YP that before the move there are regular security updates. YP then claims for LTS that "These components will now receive the usual defect fixes and updates for the extended period of two years." When YP states "A very important criterion for evaluating and adopting a software platform is support." the one kind of support that really matters for users of long term support releases is security support. This is the baseline users expect from anything called LTS, and the main reason why users want to use LTS releases. If YP does not want to be responsible for insecure millions of devices, it is up to YP to not make incorrect claims and make it clear in announcements and user documentation if security support is not provided by YP. This allows users to mitigate by allocating resources for security support of their products, instead of unknowingly shipping millions of insecure devices. It would also allow YP to develop offers for community companies to pool smaller contributions together - 50 companies each paying 2k per year for pooled security support is cheaper for them than each of them locally providing the same security support. cu Adrian From richard.purdie at linuxfoundation.org Fri Mar 6 10:36:59 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Fri, 06 Mar 2020 10:36:59 +0000 Subject: [OE-core] [Openembedded-architecture] Does YP provide security support for stable and LTS branches? In-Reply-To: <20200306100422.GA17785@localhost> References: <20200227132729.GA6240@localhost> <20200304090507.GA7923@localhost> <20200304113217.GB7923@localhost> <20200304140109.GC7923@localhost> <20200304172415.GA29456@localhost> <01b3bb37-f65f-8048-1a27-b859b62d7f98@gmail.com> <20200306100422.GA17785@localhost> Message-ID: <877e317932176664bc7b0120439c56d4dda791af.camel@linuxfoundation.org> On Fri, 2020-03-06 at 12:04 +0200, Adrian Bunk wrote: > For most community companies there is no clear Return on Investment > if they would use the opportunity to invest in upstream involvement. That isn't true. If you fix something yourself and hold the change you get to maintain it. If you work with upstream you can share the maintenance burden with the community going forward. That is a direct ROI, there are also more indirect benefits. > > > > The liability for insecure millions of devices does not lie > > > > with the yocto project, it lies with the OEMs. > > > > ... > > > The liability for insecure millions of devices lies 100% with the > > > Yocto > > > Project if it claims to provide security support but does not > > > actually > > > provide it. > > > > > > If a user has to decide today whether an upcoming product will > > > run > > > Ubuntu 20.04 LTS or Yocto 3.1 LTS, then it should be clear to the > > > user whether or not choosing Yocto will provide upstream > > > security > > > support the same way as Ubuntu. > > > > > > A user reading the YP LTS announcement expects security support > > > similar > > > to what Ubuntu is offering, and might only notice that this isn't > > > true > > > after a known vulnerability gets exploited on millions of > > > devices. > > I didn't get that out of the announcement. It only reference in the > > LTS > > announcement regarding Security was in context to Community > > support. > > ... > > The wording is "releases move to community support, which means they > only receive occasional patches for critical defects and updates, > and no regular defect fixes and security updates". > > When the move to community support means no regular security updates, > this is a clear claim from YP that before the move there are regular > security updates. I think you're being rather pedantic here and I'd suggest we go back to what the essence of this announcement is. Today, our stable branch maintenance is done "ad-hoc" by volunteers. I/we can't ask them to do anything in any given time frame, its a best effort. I *hugely* appreciate what those people do but it has its limitations. Even with the non-stable side of the project, the patch review/testing/merging and debugging which patch causes which regression basically falls onto one person, me. Yes, people help, its hugely appreciated when they do but I'm the only person paid to do it (amongst many other things) and I therefore know first hand how much work this is. We want to extend the lifespan of some releases. We can't ask/force our volunteers to do that, its not reasonable. The project is therefore looking to try something different where we have someone with time dedicated to this. There are certainly limitations to what will likely be one part time person can do, however we are hoping it improves on what we have today and may even set a mechanism by which the project can better operate for key functionality in future. We're putting this into the context of the maintainer who coordinates things, not someone to write the individual security fixes as that is the only realistic way we can make this work. If people share their security patches they'll have a lot of work, if nobody shares such fixes, it will be minimal. Time will tell if people can/will share. I do think it makes sense to try. > YP then claims for LTS that "These components will now receive the > usual defect fixes and updates for the extended period of two years." So the current process is extended for a longer period. That seems quite clear. > When YP states "A very important criterion for evaluating and > adopting a software platform is support." the one kind of support > that really matters for users of long term support releases is > security support. This is the baseline users expect from anything > called LTS, and the main reason why users want to use LTS releases. And we are trying to put something in place which better supports review and merging of patches into that LTS. That is a form of security support. We can't afford a team of 20 to work on it but it is an improvement from our current volunteer best efforts? We're also not competing with member company offerings. If you want a full set of security guarantees, please use a company which offers that service, several project members will be happy to help (and charge accordingly). > If YP does not want to be responsible for insecure millions of > devices, it is up to YP to not make incorrect claims and make it > clear in announcements and user documentation if security support is > not provided by YP. I think the definition of "security support" is arguable to be different things but the intent of what we're trying to do here is clear. No, the person will not write the patches, the intent is to coordinate the maintenance of the branch. If there are huge security holes I would at least expect they can highlight the issues and then coordinate any help in fixing them. That in itself is a level of security support btw. > This allows users to mitigate by allocating resources for security > support of their products, instead of unknowingly shipping millions > of insecure devices. > > It would also allow YP to develop offers for community companies to > pool smaller contributions together - 50 companies each paying 2k per > year for pooled security support is cheaper for them than each of > them locally providing the same security support. This is what we're effectively trying to do. The level of "security support" you can do with $100k/year is a maintainer/coordinator of the stable branch. Even writing a spec for that is hard, if you have one we'd love a copy btw. Taking a step back, please realise that we are trying to improve what we can offer within the realms of what is practical. We can improve the maintenance function, we're not going to be able to write every security fix or provide guarantees. Its incredibly hard to find funding to try and then organise what we're trying to do, it would be nice if you could try and help us support in doing so. If we need to clarify how this is documented/presented, we should do so. Accusing people of misleading/lying/false information isn't helpful, or in fact accurate. Cheers, Richard From richard.purdie at linuxfoundation.org Fri Mar 6 10:50:08 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Fri, 06 Mar 2020 10:50:08 +0000 Subject: [OE-core] [PATCH v2] mesa: updated to 20.0 release In-Reply-To: References: <20200305154119.120789-1-hnathan918@gmail.com> Message-ID: On Fri, 2020-03-06 at 07:41 +0000, Ernst Sj?strand wrote: > Mesa usually says "This is a .0 release, and you may want to continue > to to track 19.3.x until > 20.0.1 comes out in two weeks. 19.3.5 is planned to be the final 19.3 > release and is planned for next Wednesday." > > Luckily, 20.0.1 came out now! I'm aware the .0 releases are not recommended but given where we are with feature freeze and LTS, I decided 20.0.0 was a better bet and merged it. I'll take an update to 20.0.1 despite the feature freeze. Cheers, Richard From mingli.yu at windriver.com Fri Mar 6 11:25:16 2020 From: mingli.yu at windriver.com (mingli.yu at windriver.com) Date: Fri, 6 Mar 2020 19:25:16 +0800 Subject: [OE-core] [PATCH] parselogs.py: ignore rdrand initialization failure Message-ID: <1583493916-432974-1-git-send-email-mingli.yu@windriver.com> From: Mingli Yu On the system whose cpu doesn't support rdrand, there comes below message when start rngd service #systemctl status rngd [snip] Feb 25 05:08:14 qemux86-64 rngd[133]: [rdrand]: Initialization Failed [snip] Actually the failed message doesn't matter as it only indicates one entropy source as rdrand fails to initialize and won't affect rngd function. So add to ignore the failure message to fix below error during do_testimage: NOTE: ====================================================================== NOTE: FAIL: test_parselogs (parselogs.ParseLogsTest) NOTE: ---------------------------------------------------------------------- NOTE: Traceback (most recent call last): File "/buildarea/layers/oe-core/meta/lib/oeqa/core/decorator/__init__.py", line 36, in wrapped_f return func(*args, **kwargs) File "/buildarea/layers/oe-core/meta/lib/oeqa/runtime/cases/parselogs.py", line 370, in test_parselogs self.assertEqual(errcount, 0, msg=self.msg) AssertionError: 1 != 0 : Log: /buildarea/tmp/work/qemux86-64-wrs-linux/wrlinux-image-std/1.0-r5/target_logs/daemon.log Central error: 2020-03-06T09:45:12.774286+00:00 qemux86-64 rngd[134]: [rdrand]: Initialization Failed Reference: https://github.com/nhorman/rng-tools/pull/84 Signed-off-by: Mingli Yu --- meta/lib/oeqa/runtime/cases/parselogs.py | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/meta/lib/oeqa/runtime/cases/parselogs.py b/meta/lib/oeqa/runtime/cases/parselogs.py index 3cad070..6444fe8 100644 --- a/meta/lib/oeqa/runtime/cases/parselogs.py +++ b/meta/lib/oeqa/runtime/cases/parselogs.py @@ -56,7 +56,8 @@ common_errors = [ "error retry time-out =", "logind: cannot setup systemd-logind helper (-61), using legacy fallback", "Error changing net interface name 'eth0' to ", - "Cannot find a map file" + "Cannot find a map file", + "[rdrand]: Initialization Failed" ] video_related = [ -- 2.7.4 From alex.kanavin at gmail.com Fri Mar 6 11:28:50 2020 From: alex.kanavin at gmail.com (Alexander Kanavin) Date: Fri, 6 Mar 2020 12:28:50 +0100 Subject: [OE-core] [PATCH] parselogs.py: ignore rdrand initialization failure In-Reply-To: <1583493916-432974-1-git-send-email-mingli.yu@windriver.com> References: <1583493916-432974-1-git-send-email-mingli.yu@windriver.com> Message-ID: qemux86_64 is used extensively on the autobuilder, so what are the circumstances where this issue arises? Alex On Fri, 6 Mar 2020 at 12:25, wrote: > From: Mingli Yu > > On the system whose cpu doesn't support rdrand, > there comes below message when start rngd service > #systemctl status rngd > [snip] > Feb 25 05:08:14 qemux86-64 rngd[133]: [rdrand]: Initialization Failed > [snip] > > Actually the failed message doesn't matter as it > only indicates one entropy source as rdrand fails > to initialize and won't affect rngd function. > > So add to ignore the failure message to fix below > error during do_testimage: > NOTE: > ====================================================================== > NOTE: FAIL: test_parselogs (parselogs.ParseLogsTest) > NOTE: > ---------------------------------------------------------------------- > NOTE: Traceback (most recent call last): > File > "/buildarea/layers/oe-core/meta/lib/oeqa/core/decorator/__init__.py", line > 36, in wrapped_f > return func(*args, **kwargs) > File > "/buildarea/layers/oe-core/meta/lib/oeqa/runtime/cases/parselogs.py", line > 370, in test_parselogs > self.assertEqual(errcount, 0, msg=self.msg) > AssertionError: 1 != 0 : Log: > /buildarea/tmp/work/qemux86-64-wrs-linux/wrlinux-image-std/1.0-r5/target_logs/daemon.log > Central error: 2020-03-06T09:45:12.774286+00:00 qemux86-64 rngd[134]: > [rdrand]: Initialization Failed > > Reference: https://github.com/nhorman/rng-tools/pull/84 > > Signed-off-by: Mingli Yu > --- > meta/lib/oeqa/runtime/cases/parselogs.py | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/meta/lib/oeqa/runtime/cases/parselogs.py > b/meta/lib/oeqa/runtime/cases/parselogs.py > index 3cad070..6444fe8 100644 > --- a/meta/lib/oeqa/runtime/cases/parselogs.py > +++ b/meta/lib/oeqa/runtime/cases/parselogs.py > @@ -56,7 +56,8 @@ common_errors = [ > "error retry time-out =", > "logind: cannot setup systemd-logind helper (-61), using legacy > fallback", > "Error changing net interface name 'eth0' to ", > - "Cannot find a map file" > + "Cannot find a map file", > + "[rdrand]: Initialization Failed" > ] > > video_related = [ > -- > 2.7.4 > > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core at lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleksandr.s.popovych at globallogic.com Fri Mar 6 13:24:33 2020 From: oleksandr.s.popovych at globallogic.com (Oleksandr Popovych) Date: Fri, 6 Mar 2020 15:24:33 +0200 Subject: [OE-core] [PATCH v6] expat: Added ptest In-Reply-To: References: <20200212121911.4752-1-oleksandr.s.popovych@globallogic.com> Message-ID: Hello, Randy On Wed, Feb 12, 2020 at 7:17 PM Randy MacLeod wrote: > > On 2/12/20 7:19 AM, Oleksandr Popovych via Openembedded-core wrote: > > For ptest support for this package several additional patches and > > run-ptest script were added and recipe was changed. > > > > Signed-off-by: Oleksandr Popovych > > --- > > ...d-Makefile-targets-for-ptest-support.patch | 40 ++++++++++++++ > > ...ort-for-ptests-in-form-of-new-target.patch | 33 ++++++++++++ > > ...ed-suitable-format-of-tests-in-ptest.patch | 52 +++++++++++++++++++ > > meta/recipes-core/expat/expat/run-ptest | 3 ++ > > meta/recipes-core/expat/expat_2.2.9.bb | 12 ++++- > > 5 files changed, 139 insertions(+), 1 deletion(-) > > create mode 100644 meta/recipes-core/expat/expat/0001-expat-Added-Makefile-targets-for-ptest-support.patch > > create mode 100644 meta/recipes-core/expat/expat/0002-expat-Added-support-for-ptests-in-form-of-new-target.patch > > create mode 100644 meta/recipes-core/expat/expat/0003-expat-Added-suitable-format-of-tests-in-ptest.patch > > create mode 100644 meta/recipes-core/expat/expat/run-ptest > > > > diff --git a/meta/recipes-core/expat/expat/0001-expat-Added-Makefile-targets-for-ptest-support.patch b/meta/recipes-core/expat/expat/0001-expat-Added-Makefile-targets-for-ptest-support.patch > > new file mode 100644 > > index 0000000000..de213b4bc5 > > --- /dev/null > > +++ b/meta/recipes-core/expat/expat/0001-expat-Added-Makefile-targets-for-ptest-support.patch > > @@ -0,0 +1,40 @@ > > +From e306bd4849f61f50dad1f5d29fb650c347d78ad6 Mon Sep 17 00:00:00 2001 > > +From: Oleksandr Popovych > > +Date: Thu, 6 Feb 2020 13:41:45 +0200 > > +Subject: [PATCH 1/3] expat: Added Makefile targets for ptest support > > + > > +install-ptest, runtests and check tagrets are added. > > + > > +Upstream-Status: Inappropriate [oe-core specific] > > + > > +Signed-off-by: Oleksandr Popovych > > +--- > > + Makefile.am | 15 +++++++++++++++ > > + 1 file changed, 15 insertions(+) > > + > > +diff --git a/Makefile.am b/Makefile.am > > +index 5e1d37d..c63b44a 100644 > > +--- a/Makefile.am > > ++++ b/Makefile.am > > +@@ -152,3 +152,18 @@ qa: > > + QA_COMPILER=clang QA_SANITIZER=memory ./qa.sh > > + QA_COMPILER=clang QA_SANITIZER=undefined ./qa.sh > > + QA_COMPILER=gcc QA_PROCESSOR=gcov ./qa.sh > > ++ > > ++.PHONY: install-ptest > > ++install-ptest: > > if you call this, install-test and don't change the behaviour used when > testing self-hosted development, then perhaps > the upstream will accept the changes. > > > ++ echo $(S) > > ++ (if [ -d tests/.libs ] ; then cd tests/.libs; fi; \ > > ++ install runtests runtestspp $(DESTDIR)) > > ++ cp Makefile $(DESTDIR) > > ++ sed -i -e 's|^Makefile:|_Makefile:|' $(DESTDIR)/Makefile > > ++ > > ++.PHONY: runtests > > ++runtests: > > ++ @echo "C variant of tests:" > > ++ @$(CHECKER) ./runtests$(EXEEXT) -q > > ++ @echo "C++ variant of tests:" > > ++ @$(CHECKER) ./runtestspp$(EXEEXT) -q > > +-- > > +2.17.1 > > + > > diff --git a/meta/recipes-core/expat/expat/0002-expat-Added-support-for-ptests-in-form-of-new-target.patch b/meta/recipes-core/expat/expat/0002-expat-Added-support-for-ptests-in-form-of-new-target.patch > > new file mode 100644 > > index 0000000000..26ae144a37 > > --- /dev/null > > +++ b/meta/recipes-core/expat/expat/0002-expat-Added-support-for-ptests-in-form-of-new-target.patch > > @@ -0,0 +1,33 @@ > > +From 9a5085243b632a777f55269f7f6d2e40dd73a7bc Mon Sep 17 00:00:00 2001 > > +From: Oleksandr Popovych > > +Date: Thu, 6 Feb 2020 13:43:57 +0200 > > +Subject: [PATCH 2/3] expat: Added support for ptests in form of new target > > + > > +configure.am file changed, according to this advice: > > +https://wiki.yoctoproject.org/wiki/Ptest#Building_the_test_suite > > + > > +Upstream-Status: Inappropriate [oe-core specific] > > + > > +Signed-off-by: Oleksandr Popovych > > +--- > > + configure.ac | 4 ++-- > > + 1 file changed, 2 insertions(+), 2 deletions(-) > > + > > +diff --git a/configure.ac b/configure.ac > > +index d58ac03..8e6b41e 100644 > > +--- a/configure.ac > > ++++ b/configure.ac > > +@@ -34,8 +34,8 @@ AC_CONFIG_SRCDIR([Makefile.in]) > > + AC_CONFIG_AUX_DIR([conftools]) > > + AC_CONFIG_MACRO_DIR([m4]) > > + AC_CANONICAL_HOST > > +-AM_INIT_AUTOMAKE > > +- > > ++AM_INIT_AUTOMAKE([serial-tests]) > > ++AM_EXTRA_RECURSIVE_TARGETS([buildtest-TESTS]) > > > Cross-compiling is increasingly common. > Upstream might accept you changes to split up > building, installing and running tests. > According to this information: https://github.com/libexpat/libexpat/issues/330 Autotools that are used for building this library are going to become deprecated, and library maintainers are planning to switch on CMake instead. Latest release already has CMake build system support. This system is still experimental, but it already has split up building and running tests (installation can be implemented in recipe). With migration on CMake there will no be reason for upstreaming changes for potentially deprecated feature. But... cmake-native package has expat-native as RDEPENDS. That creates a dependency loop between this packages. I was able to fix it by splitting recipes for expat and expat-native, and build expat with CMake and expat-native with autotools... So does expat recipe need to be rewritten on cmake-based building? And how can such dependency loop be solved propertly, if recipe need to be changed? > > Same goes for the PASS/ FAIL printfs below. > According to conversation about my changes offer: https://github.com/libexpat/libexpat/issues/382 maintainers would rather be interested in changing testing framework on more functional and adapting their tests for it than making changes in the current one. So my patches are not suitable for upstreaming. And I see several ways for solving this situation: - discard patches and rewrite run-tests script and recipe without making any changes in the code (So patches are not required, but tests output will be reduced to 2 lines: "PASS/FAIL/SKIP: runtests" and "PASS/FAIL/SKIP: runtestspp" because there are 2 testing executables) - leave patches marked as "Inappropriate" (maybe with reason updating) - accept expat maintainers offer and change their current testing framework "... to something C-based, existing, capable, self-contained, and integrate it into both the CMake and Autotools build systems while we have both...". (This requires a lot of time, efforts and experience, but will be acceptable for upstreaming) So should I try to implement and upstream changes of expat testing framework, or I can leave this for somebody else? > > Working with upstream takes a bit more time but if we > don't have to carry patches for years, it's worth it. > > Finally, how about adding the test results in the long log > with info about the image and machine used? The time > needed to run the tests will be useful to determine if these > ptests can be added to: > > meta/conf/distro/include/ptest-packagelists.inc > > and you could do that if the tests run in < 30 seconds in qemux86-64 > with kvm support. > CMake based building system of this library uses such tool like CTest. This tool can run built tests, show their output and write it to log file simultaneously with time tracking of tests` execution. This can be additional "pros" for migration on CMake-based build system, of course with adding one additional RDEPENS-ptest value for package. > > Thanks, > > ../Randy > > > + > > + dnl > > + dnl Increment LIBREVISION if source code has changed at all > > +-- > > +2.17.1 > > + > > diff --git a/meta/recipes-core/expat/expat/0003-expat-Added-suitable-format-of-tests-in-ptest.patch b/meta/recipes-core/expat/expat/0003-expat-Added-suitable-format-of-tests-in-ptest.patch > > new file mode 100644 > > index 0000000000..9a85a26117 > > --- /dev/null > > +++ b/meta/recipes-core/expat/expat/0003-expat-Added-suitable-format-of-tests-in-ptest.patch > > @@ -0,0 +1,52 @@ > > +From 825f344543676fc3314f4e074163fd638db8e8f9 Mon Sep 17 00:00:00 2001 > > +From: Oleksandr Popovych > > +Date: Thu, 6 Feb 2020 13:44:56 +0200 > > +Subject: [PATCH 3/3] expat: Added suitable format of tests in ptest > > + > > +Some changes in testcases code were applied for testcase engine. > > +This was just adding of message outputs in "RESULT: TESTNAME" form... > > + > > +Upstream-Status: Inappropriate [oe-core specific] > > + > > +Signed-off-by: Oleksandr Popovych > > +--- > > + tests/minicheck.c | 4 ++++ > > + 1 file changed, 4 insertions(+) > > + > > +diff --git a/tests/minicheck.c b/tests/minicheck.c > > +index a5a1efb..b39cda9 100644 > > +--- a/tests/minicheck.c > > ++++ b/tests/minicheck.c > > +@@ -164,6 +164,7 @@ srunner_run_all(SRunner *runner, int verbosity) { > > + if (tc->setup != NULL) { > > + /* setup */ > > + if (setjmp(env)) { > > ++ printf("SKIP: %s\n", _check_current_function); > > + add_failure(runner, verbosity); > > + continue; > > + } > > +@@ -171,6 +172,7 @@ srunner_run_all(SRunner *runner, int verbosity) { > > + } > > + /* test */ > > + if (setjmp(env)) { > > ++ printf("FAIL: %s\n", _check_current_function); > > + add_failure(runner, verbosity); > > + continue; > > + } > > +@@ -179,11 +181,13 @@ srunner_run_all(SRunner *runner, int verbosity) { > > + /* teardown */ > > + if (tc->teardown != NULL) { > > + if (setjmp(env)) { > > ++ printf("PASS: %s\n", _check_current_function); > > + add_failure(runner, verbosity); > > + continue; > > + } > > + tc->teardown(); > > + } > > ++ printf("PASS: %s\n", _check_current_function); > > + } > > + tc = tc->next_tcase; > > + } > > +-- > > +2.17.1 > > + > > diff --git a/meta/recipes-core/expat/expat/run-ptest b/meta/recipes-core/expat/expat/run-ptest > > new file mode 100644 > > index 0000000000..df994c0838 > > --- /dev/null > > +++ b/meta/recipes-core/expat/expat/run-ptest > > @@ -0,0 +1,3 @@ > > +#!/bin/bash > > + > > +make -k runtests > > diff --git a/meta/recipes-core/expat/expat_2.2.9.bb b/meta/recipes-core/expat/expat_2.2.9.bb > > index 8f3db41352..420ffddc80 100644 > > --- a/meta/recipes-core/expat/expat_2.2.9.bb > > +++ b/meta/recipes-core/expat/expat_2.2.9.bb > > @@ -8,15 +8,25 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=5b8620d98e49772d95fc1d291c26aa79" > > > > SRC_URI = "${SOURCEFORGE_MIRROR}/expat/expat-${PV}.tar.bz2 \ > > file://libtool-tag.patch \ > > + file://0001-expat-Added-Makefile-targets-for-ptest-support.patch \ > > + file://0002-expat-Added-support-for-ptests-in-form-of-new-target.patch \ > > + file://0003-expat-Added-suitable-format-of-tests-in-ptest.patch \ > > + file://run-ptest \ > > " > > > > SRC_URI[md5sum] = "875a2c2ff3e8eb9e5a5cd62db2033ab5" > > SRC_URI[sha256sum] = "f1063084dc4302a427dabcca499c8312b3a32a29b7d2506653ecc8f950a9a237" > > > > -inherit autotools lib_package > > +inherit autotools ptest lib_package > > + > > +RDEPENDS_${PN}-ptest += "make bash" > > > > do_configure_prepend () { > > rm -f ${S}/conftools/libtool.m4 > > } > > > > +do_compile_ptest() { > > + oe_runmake buildtest-TESTS > > +} > > + > > BBCLASSEXTEND = "native nativesdk" > > > -- > # Randy MacLeod > # Wind River Linux > Thank you for your attention -- Popovych Oleksandr GlobalLogic Inc. From alex.kiernan at gmail.com Fri Mar 6 14:35:18 2020 From: alex.kiernan at gmail.com (Alex Kiernan) Date: Fri, 6 Mar 2020 14:35:18 +0000 Subject: [OE-core] [OE-Core][PATCH] linux-firmware: Fix usrmerge builds Message-ID: <20200306143518.46121-1-alex.kiernan@gmail.com> FIRMWAREDIR defaults to /lib, failing when usrmerge is enabled: ERROR: linux-firmware-1_20200122-r0 do_install: Execution of '/home/akiernan/poky/build/tmp/work/core2-64-poky-linux/linux-firmware/1_20200122-r0/temp/run.do_install.31218' failed with exit code 1: mkdir -p /home/akiernan/poky/build/tmp/work/core2-64-poky-linux/linux-firmware/1_20200122-r0/image/lib/firmware ./copy-firmware.sh /home/akiernan/poky/build/tmp/work/core2-64-poky-linux/linux-firmware/1_20200122-r0/image/lib/firmware cp: target '/home/akiernan/poky/build/tmp/work/core2-64-poky-linux/linux-firmware/1_20200122-r0/image/usr/lib/firmware/' is not a directory Signed-off-by: Alex Kiernan --- meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb b/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb index 6039dc9d711f..8f963f4f4224 100644 --- a/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb +++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20200122.bb @@ -208,7 +208,7 @@ do_compile() { } do_install() { - oe_runmake 'DESTDIR=${D}' install + oe_runmake 'DESTDIR=${D}' 'FIRMWAREDIR=${nonarch_base_libdir}/firmware' install cp GPL-2 LICEN[CS]E.* WHENCE ${D}${nonarch_base_libdir}/firmware/ } -- 2.17.1 From andrej.valek at siemens.com Fri Mar 6 15:32:32 2020 From: andrej.valek at siemens.com (Andrej Valek) Date: Fri, 6 Mar 2020 16:32:32 +0100 Subject: [OE-core] [PATCH 0/2] Extensible SDK improvements Message-ID: <20200306153234.23875-1-andrej.valek@siemens.com> "add option to append lines into local.conf": - What about dropping "sdk_extraconf"? Andrej Valek (2): populate_sdk_ext.bbclass: enable custom templateconf.cfg populate_sdk_ext.bbclass: add option to append lines into local.conf meta/classes/buildhistory.bbclass | 4 ++-- meta/classes/populate_sdk_ext.bbclass | 22 ++++++++++++++++++---- 2 files changed, 20 insertions(+), 6 deletions(-) -- 2.11.0 From andrej.valek at siemens.com Fri Mar 6 15:32:33 2020 From: andrej.valek at siemens.com (Andrej Valek) Date: Fri, 6 Mar 2020 16:32:33 +0100 Subject: [OE-core] [PATCH 1/2] populate_sdk_ext: enable custom templateconf.cfg In-Reply-To: <20200306153234.23875-1-andrej.valek@siemens.com> References: <20200306153234.23875-1-andrej.valek@siemens.com> Message-ID: <20200306153234.23875-2-andrej.valek@siemens.com> Do not always override templateconf.cfg content. Add option to use already existing file. Signed-off-by: Andrej Valek --- meta/classes/populate_sdk_ext.bbclass | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/meta/classes/populate_sdk_ext.bbclass b/meta/classes/populate_sdk_ext.bbclass index 57fd29b1bb..9f26cfc131 100644 --- a/meta/classes/populate_sdk_ext.bbclass +++ b/meta/classes/populate_sdk_ext.bbclass @@ -388,9 +388,13 @@ python copy_buildsystem () { bb.utils.mkdirhier(os.path.join(baseoutpath, 'cache')) shutil.copyfile(builddir + '/cache/bb_unihashes.dat', baseoutpath + '/cache/bb_unihashes.dat') - # Write a templateconf.cfg - with open(baseoutpath + '/conf/templateconf.cfg', 'w') as f: - f.write('meta/conf\n') + # Use templateconf.cfg file from builddir if exists + if os.path.exists(builddir + '/conf/templateconf.cfg'): + shutil.copyfile(builddir + '/conf/templateconf.cfg', baseoutpath + '/conf/templateconf.cfg') + else: + # Write a templateconf.cfg + with open(baseoutpath + '/conf/templateconf.cfg', 'w') as f: + f.write('meta/conf\n') # Ensure any variables set from the external environment (by way of # BB_ENV_EXTRAWHITE) are set in the SDK's configuration -- 2.11.0 From andrej.valek at siemens.com Fri Mar 6 15:32:34 2020 From: andrej.valek at siemens.com (Andrej Valek) Date: Fri, 6 Mar 2020 16:32:34 +0100 Subject: [OE-core] [PATCH 2/2] populate_sdk_ext: add option to append lines into local.conf In-Reply-To: <20200306153234.23875-1-andrej.valek@siemens.com> References: <20200306153234.23875-1-andrej.valek@siemens.com> Message-ID: <20200306153234.23875-3-andrej.valek@siemens.com> Add option to add new lines into local.conf content in ext_sdk case via SDK_LOCAL_CONF_EXTRALIST variable. Signed-off-by: Andrej Valek --- meta/classes/buildhistory.bbclass | 4 ++-- meta/classes/populate_sdk_ext.bbclass | 12 +++++++++++- 2 files changed, 13 insertions(+), 3 deletions(-) diff --git a/meta/classes/buildhistory.bbclass b/meta/classes/buildhistory.bbclass index eb7295570d..a347811edc 100644 --- a/meta/classes/buildhistory.bbclass +++ b/meta/classes/buildhistory.bbclass @@ -757,8 +757,8 @@ def buildhistory_get_sdkvars(d): sdkvars = "DISTRO DISTRO_VERSION SDK_NAME SDK_VERSION SDKMACHINE SDKIMAGE_FEATURES BAD_RECOMMENDATIONS NO_RECOMMENDATIONS PACKAGE_EXCLUDE" if d.getVar('BB_CURRENTTASK') == 'populate_sdk_ext': # Extensible SDK uses some additional variables - sdkvars += " SDK_LOCAL_CONF_WHITELIST SDK_LOCAL_CONF_BLACKLIST SDK_INHERIT_BLACKLIST SDK_UPDATE_URL SDK_EXT_TYPE SDK_RECRDEP_TASKS SDK_INCLUDE_PKGDATA SDK_INCLUDE_TOOLCHAIN" - listvars = "SDKIMAGE_FEATURES BAD_RECOMMENDATIONS PACKAGE_EXCLUDE SDK_LOCAL_CONF_WHITELIST SDK_LOCAL_CONF_BLACKLIST SDK_INHERIT_BLACKLIST" + sdkvars += " SDK_LOCAL_CONF_EXTRALIST SDK_LOCAL_CONF_WHITELIST SDK_LOCAL_CONF_BLACKLIST SDK_INHERIT_BLACKLIST SDK_UPDATE_URL SDK_EXT_TYPE SDK_RECRDEP_TASKS SDK_INCLUDE_PKGDATA SDK_INCLUDE_TOOLCHAIN" + listvars = "SDKIMAGE_FEATURES BAD_RECOMMENDATIONS PACKAGE_EXCLUDE SDK_LOCAL_CONF_EXTRALIST SDK_LOCAL_CONF_WHITELIST SDK_LOCAL_CONF_BLACKLIST SDK_INHERIT_BLACKLIST" return outputvars(sdkvars, listvars, d) diff --git a/meta/classes/populate_sdk_ext.bbclass b/meta/classes/populate_sdk_ext.bbclass index 9f26cfc131..2eccf52df1 100644 --- a/meta/classes/populate_sdk_ext.bbclass +++ b/meta/classes/populate_sdk_ext.bbclass @@ -25,6 +25,7 @@ SDK_INCLUDE_BUILDTOOLS ?= '1' SDK_RECRDEP_TASKS ?= "" +SDK_LOCAL_CONF_EXTRALIST ?= "" SDK_LOCAL_CONF_WHITELIST ?= "" SDK_LOCAL_CONF_BLACKLIST ?= "CONF_VERSION \ BB_NUMBER_THREADS \ @@ -372,7 +373,16 @@ python copy_buildsystem () { for line in xf: f.write(line) - # If you define a sdk_extraconf() function then it can contain additional config + # Allow additional config through SDK_LOCAL_CONF_EXTRALIST + local_conf_extralist = (d.getVar('SDK_LOCAL_CONF_EXTRALIST') or '').split() + if local_conf_extralist: + for var in local_conf_extralist: + value = d.getVar(var) or "" + if value: + f.write('%s = "%s"\n' % (var, value)) + f.write('\n') + + # If you define a sdk_extraconf variable then it can contain additional config # (Though this is awkward; sdk-extra.conf should probably be used instead) extraconf = (d.getVar('sdk_extraconf') or '').strip() if extraconf: -- 2.11.0 From richard.purdie at linuxfoundation.org Fri Mar 6 17:16:48 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Fri, 06 Mar 2020 17:16:48 +0000 Subject: [OE-core] [PATCH 0/2] Extensible SDK improvements In-Reply-To: <20200306153234.23875-1-andrej.valek@siemens.com> References: <20200306153234.23875-1-andrej.valek@siemens.com> Message-ID: On Fri, 2020-03-06 at 16:32 +0100, Andrej Valek wrote: > "add option to append lines into local.conf": > - What about dropping "sdk_extraconf"? I'm curious what you didn't find useful about the other format and why this version is better? Cheers, Richard From martin.jansa at gmail.com Fri Mar 6 18:04:13 2020 From: martin.jansa at gmail.com (Martin Jansa) Date: Fri, 6 Mar 2020 19:04:13 +0100 Subject: [OE-core] [yocto] [zeus] icu-native-64.2-r0 do_configure: configure failed Message-ID: <20200306180413.z4e5km64jcm6azbv@jama> > On 30/10/2019 06:25, star at gmx.li wrote: > > Build of image failed, I got strange and long error messages like: > > > > | from distutils.sysconfig import parse_makefile > > | ModuleNotFoundError: No module named 'distutils.sysconfig' > > | configure: error: Python failed to run; see above error. > > > a) What goes wrong here and how can this be avoid? > > distutils.sysconfig is part of the standard Python library. What > distribution are you using? It's possible that you've only got a > 'minimal' Python installed instead of the full thing. I came across this old thread when trying "bitbake world" in really minimalistic docker container with ubuntu-18.04 where I've installed only the dependencies explicitly checked by sanity check and HOSTTOOLS. And indeed python3 package in ubuntu doesn't depend on python3-distutils, I don't know how "standard Python library" is defined, but this wasn't explicitly "minimal" python, just the default what you get with python3 in ubuntu. Maybe it would be worth adding python3native in icu to catch issues like this? Luckily it's needed only in zeus, because icu 65.1 currently in dunfell/master doesn't depend on python3-distutils anymore since: https://github.com/unicode-org/icu/commit/b4d41b0561b6e8de38b99850ce0e4be8ef536bb1 There is only one more recipe with this issue (at least in the layers i was testing and that's: openembedded-core/meta/recipes-core/ovmf/ovmf_git.bb in zeus as well as master which is explicitly using python3 from host: export PYTHON_COMMAND = "${HOSTTOOLS_DIR}/python3" and then fails with: | Python reported: "No module named 'distutils.util" | | GNUmakefile:11: recipe for target 'test' failed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From jpuhlman at mvista.com Fri Mar 6 18:48:35 2020 From: jpuhlman at mvista.com (Jeremy A. Puhlman) Date: Fri, 6 Mar 2020 10:48:35 -0800 Subject: [OE-core] Multilib conflicts in man pages. In-Reply-To: <62ba6d2a-098e-acbd-db0e-b2283a3b476a@mvista.com> References: <62ba6d2a-098e-acbd-db0e-b2283a3b476a@mvista.com> Message-ID: <30ccd839-f804-881e-cec8-e667961e8c04@mvista.com> Anyone have a thought? On 3/3/2020 3:22 PM, Jeremy Puhlman wrote: > Is there a preferred method in oe-core for dealing with man pages that > conflict due to differences > in multilib pathing. > > For example an application lives in /usr/lib/foo/bar for one abi but > /usr/lib64/foo/bar in another, and > that kind of information is encoded in to the man pages. > > Some things i have seen done in the past, is move the man pages under > /user/share/man/${PN} or > use something like mutlilib script to deal with it. > > I am just curious if there is a canned, preferred way the project > handles those or wants to handle them? > > xinit, xserver-org, and groff each exhibit? these issues. > -- Jeremy A. Puhlman jpuhlman at mvista.com From hnathan918 at gmail.com Fri Mar 6 20:19:36 2020 From: hnathan918 at gmail.com (Nathan Hartman) Date: Fri, 6 Mar 2020 12:19:36 -0800 Subject: [OE-core] [PATCH] mesa: updated to mesa 20.0.1 release Message-ID: <20200306201936.62066-1-hnathan918@gmail.com> Updated to 20.0.1 release: https://www.mesa3d.org/relnotes/20.0.1.html Signed-off-by: Nathan Hartman --- .../mesa/{mesa-gl_20.0.0.bb => mesa-gl_20.0.1.bb} | 0 meta/recipes-graphics/mesa/{mesa_20.0.0.bb => mesa_20.0.1.bb} | 4 ++-- 2 files changed, 2 insertions(+), 2 deletions(-) rename meta/recipes-graphics/mesa/{mesa-gl_20.0.0.bb => mesa-gl_20.0.1.bb} (100%) rename meta/recipes-graphics/mesa/{mesa_20.0.0.bb => mesa_20.0.1.bb} (88%) diff --git a/meta/recipes-graphics/mesa/mesa-gl_20.0.0.bb b/meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb similarity index 100% rename from meta/recipes-graphics/mesa/mesa-gl_20.0.0.bb rename to meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb diff --git a/meta/recipes-graphics/mesa/mesa_20.0.0.bb b/meta/recipes-graphics/mesa/mesa_20.0.1.bb similarity index 88% rename from meta/recipes-graphics/mesa/mesa_20.0.0.bb rename to meta/recipes-graphics/mesa/mesa_20.0.1.bb index 2ed7ca2252..e18c00b051 100644 --- a/meta/recipes-graphics/mesa/mesa_20.0.0.bb +++ b/meta/recipes-graphics/mesa/mesa_20.0.1.bb @@ -9,8 +9,8 @@ SRC_URI = "https://mesa.freedesktop.org/archive/mesa-${PV}.tar.xz \ file://0001-meson-misdetects-64bit-atomics-on-mips-clang.patch \ " -SRC_URI[md5sum] = "681229d992bbd6250a5be4f308708795" -SRC_URI[sha256sum] = "bb6db3e54b608d2536d4000b3de7dd3ae115fc114e8acbb5afff4b3bbed04b34" +SRC_URI[md5sum] = "428ac511e4b05647a00b3778f1279da7" +SRC_URI[sha256sum] = "6153ba3f8cb0524bbfc08e4db76b408126b2d1be8f789dffe28d1a0461eedde4" UPSTREAM_CHECK_GITTAGREGEX = "mesa-(?P\d+(\.\d+)+)" -- 2.17.1 From alex.kanavin at gmail.com Fri Mar 6 21:51:38 2020 From: alex.kanavin at gmail.com (Alexander Kanavin) Date: Fri, 6 Mar 2020 22:51:38 +0100 Subject: [OE-core] [PATCH] gettext: fix ptest package reproducibilty Message-ID: <20200306215138.15785-1-alex.kanavin@gmail.com> Signed-off-by: Alexander Kanavin --- ...t-env.in-do-not-add-C-CXX-parameters.patch | 29 +++++++++++++++++++ meta/recipes-core/gettext/gettext_0.20.1.bb | 1 + 2 files changed, 30 insertions(+) create mode 100644 meta/recipes-core/gettext/gettext-0.20.1/0001-init-env.in-do-not-add-C-CXX-parameters.patch diff --git a/meta/recipes-core/gettext/gettext-0.20.1/0001-init-env.in-do-not-add-C-CXX-parameters.patch b/meta/recipes-core/gettext/gettext-0.20.1/0001-init-env.in-do-not-add-C-CXX-parameters.patch new file mode 100644 index 0000000000..d45b75869a --- /dev/null +++ b/meta/recipes-core/gettext/gettext-0.20.1/0001-init-env.in-do-not-add-C-CXX-parameters.patch @@ -0,0 +1,29 @@ +From 9b912a47f790a7b282ec0c2295a188c5d8fb6a7c Mon Sep 17 00:00:00 2001 +From: Alexander Kanavin +Date: Fri, 6 Mar 2020 21:04:05 +0000 +Subject: [PATCH] init-env.in: do not add C/CXX parameters + +These are taken from the cross environment and include +sysroot paths, so are not reproducible. + +Upstream-Status: Inappropriate [oe-core specific] +Signed-off-by: Alexander Kanavin +--- + gettext-tools/tests/init-env.in | 4 ---- + 1 file changed, 4 deletions(-) + +diff --git a/gettext-tools/tests/init-env.in b/gettext-tools/tests/init-env.in +index cc84ffd..b69c990 100644 +--- a/gettext-tools/tests/init-env.in ++++ b/gettext-tools/tests/init-env.in +@@ -3,10 +3,6 @@ top_builddir=../.. + + OBJEXT="@OBJEXT@" + EXEEXT="@EXEEXT@" +-CC="@CC@" +-CFLAGS="@CFLAGS@" +-CXX="@CXX@" +-CXXFLAGS="@CXXFLAGS@" + CPPFLAGS="@CPPFLAGS@" + LDFLAGS="@LDFLAGS@" + LTLIBINTL="@LTLIBINTL@" diff --git a/meta/recipes-core/gettext/gettext_0.20.1.bb b/meta/recipes-core/gettext/gettext_0.20.1.bb index 214803f767..85493e7595 100644 --- a/meta/recipes-core/gettext/gettext_0.20.1.bb +++ b/meta/recipes-core/gettext/gettext_0.20.1.bb @@ -25,6 +25,7 @@ SRC_URI = "${GNU_MIRROR}/gettext/gettext-${PV}.tar.gz \ file://serial-tests-config.patch \ file://0001-msgmerge-Fix-behaviour-of-for-msgfmt-on-PO-files-wit.patch \ file://0001-tests-autopoint-3-unset-MAKEFLAGS.patch \ + file://0001-init-env.in-do-not-add-C-CXX-parameters.patch \ " SRC_URI[md5sum] = "bb5b0c0caa028105f3ca1905ddc306e2" SRC_URI[sha256sum] = "66415634c6e8c3fa8b71362879ec7575e27da43da562c798a8a2f223e6e47f5c" -- 2.25.1 From alex.kanavin at gmail.com Fri Mar 6 21:53:37 2020 From: alex.kanavin at gmail.com (Alexander Kanavin) Date: Fri, 6 Mar 2020 22:53:37 +0100 Subject: [OE-core] Yocto Project Status WW09'20 In-Reply-To: References: <107c01d5f174$bbf566a0$33e033e0$@gmail.com> Message-ID: On Wed, 4 Mar 2020 at 23:42, Richard Purdie < richard.purdie at linuxfoundation.org> wrote: > > Just FYI I think there may also be a couple of other packages coreutils > pulls in and they may also have reproducibility issues (gettext-ptest, > glibc-locale-* and procps*). > Patch for gettext also sent :) glibc-locale and procps I could not reproduce :-/ Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard.purdie at linuxfoundation.org Fri Mar 6 22:00:50 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Fri, 06 Mar 2020 22:00:50 +0000 Subject: [OE-core] Multilib conflicts in man pages. In-Reply-To: <62ba6d2a-098e-acbd-db0e-b2283a3b476a@mvista.com> References: <62ba6d2a-098e-acbd-db0e-b2283a3b476a@mvista.com> Message-ID: <446c96a2d520e581eee85d519233fdb961c9d1c2.camel@linuxfoundation.org> On Tue, 2020-03-03 at 15:22 -0800, Jeremy Puhlman wrote: > Is there a preferred method in oe-core for dealing with man pages > that conflict due to differences in multilib pathing. > > For example an application lives in /usr/lib/foo/bar for one abi but > /usr/lib64/foo/bar in another, and > that kind of information is encoded in to the man pages. > > Some things i have seen done in the past, is move the man pages > under > /user/share/man/${PN} or > use something like mutlilib script to deal with it. > > I am just curious if there is a canned, preferred way the project > handles those or wants to handle them? > > xinit, xserver-org, and groff each exhibit these issues. Could we just put a placeholder into the man page so they'd be identical? Multiple copies seems like overkill for something as trivial... Cheers, Richard From jpuhlman at mvista.com Fri Mar 6 22:03:36 2020 From: jpuhlman at mvista.com (Jeremy A. Puhlman) Date: Fri, 6 Mar 2020 14:03:36 -0800 Subject: [OE-core] Multilib conflicts in man pages. In-Reply-To: <446c96a2d520e581eee85d519233fdb961c9d1c2.camel@linuxfoundation.org> References: <62ba6d2a-098e-acbd-db0e-b2283a3b476a@mvista.com> <446c96a2d520e581eee85d519233fdb961c9d1c2.camel@linuxfoundation.org> Message-ID: <620f2c52-9492-77dd-f629-65649ab432d7@mvista.com> On 3/6/2020 2:00 PM, Richard Purdie wrote: > On Tue, 2020-03-03 at 15:22 -0800, Jeremy Puhlman wrote: >> Is there a preferred method in oe-core for dealing with man pages >> that conflict due to differences in multilib pathing. >> >> For example an application lives in /usr/lib/foo/bar for one abi but >> /usr/lib64/foo/bar in another, and >> that kind of information is encoded in to the man pages. >> >> Some things i have seen done in the past, is move the man pages >> under >> /user/share/man/${PN} or >> use something like mutlilib script to deal with it. >> >> I am just curious if there is a canned, preferred way the project >> handles those or wants to handle them? >> >> xinit, xserver-org, and groff each exhibit these issues. > Could we just put a placeholder into the man page so they'd be > identical? Multiple copies seems like overkill for something as > trivial... Yeah, that works as well. Just need to brush up on my man-page-fu. > > Cheers, > > Richard > > -- Jeremy A. Puhlman jpuhlman at mvista.com From denis at denix.org Fri Mar 6 22:04:37 2020 From: denis at denix.org (Denys Dmytriyenko) Date: Fri, 6 Mar 2020 17:04:37 -0500 Subject: [OE-core] [PATCH] openssl: recommend cryptodev-module for corresponding PACKAGECONFIG In-Reply-To: <1583279109-41106-1-git-send-email-denis@denix.org> References: <1583279109-41106-1-git-send-email-denis@denix.org> Message-ID: <20200306220437.GF1578@denix.org> Ping. Any comments? On Tue, Mar 03, 2020 at 06:45:09PM -0500, Denys Dmytriyenko wrote: > From: Denys Dmytriyenko > > Signed-off-by: Denys Dmytriyenko > --- > meta/recipes-connectivity/openssl/openssl_1.1.1d.bb | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb b/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb > index c2ba005..a9965e7 100644 > --- a/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb > +++ b/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb > @@ -34,7 +34,7 @@ PACKAGECONFIG ?= "" > PACKAGECONFIG_class-native = "" > PACKAGECONFIG_class-nativesdk = "" > > -PACKAGECONFIG[cryptodev-linux] = "enable-devcryptoeng,disable-devcryptoeng,cryptodev-linux" > +PACKAGECONFIG[cryptodev-linux] = "enable-devcryptoeng,disable-devcryptoeng,cryptodev-linux,,cryptodev-module" > > B = "${WORKDIR}/build" > do_configure[cleandirs] = "${B}" > -- > 2.7.4 > > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core at lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core From jpuhlman at mvista.com Fri Mar 6 22:14:04 2020 From: jpuhlman at mvista.com (Jeremy A. Puhlman) Date: Fri, 6 Mar 2020 14:14:04 -0800 Subject: [OE-core] Multilib conflicts in man pages. In-Reply-To: <446c96a2d520e581eee85d519233fdb961c9d1c2.camel@linuxfoundation.org> References: <62ba6d2a-098e-acbd-db0e-b2283a3b476a@mvista.com> <446c96a2d520e581eee85d519233fdb961c9d1c2.camel@linuxfoundation.org> Message-ID: On 3/6/2020 2:00 PM, Richard Purdie wrote: > On Tue, 2020-03-03 at 15:22 -0800, Jeremy Puhlman wrote: >> Is there a preferred method in oe-core for dealing with man pages >> that conflict due to differences in multilib pathing. >> >> For example an application lives in /usr/lib/foo/bar for one abi but >> /usr/lib64/foo/bar in another, and >> that kind of information is encoded in to the man pages. >> >> Some things i have seen done in the past, is move the man pages >> under >> /user/share/man/${PN} or >> use something like mutlilib script to deal with it. >> >> I am just curious if there is a canned, preferred way the project >> handles those or wants to handle them? >> >> xinit, xserver-org, and groff each exhibit these issues. > Could we just put a placeholder into the man page so they'd be > identical? Multiple copies seems like overkill for something as > trivial... A placeholder like: /usr//sys.startxrc from /usr/lib64/sys.startxrc > Cheers, > > Richard > > -- Jeremy A. Puhlman jpuhlman at mvista.com From martin.jansa at gmail.com Fri Mar 6 22:19:35 2020 From: martin.jansa at gmail.com (Martin Jansa) Date: Fri, 6 Mar 2020 23:19:35 +0100 Subject: [OE-core] [PATCH RESEND] openssl: pass PERL=perl environment variable to configurator In-Reply-To: <20200305115333.31139-1-rbilovol@cisco.com> References: <20200305115333.31139-1-rbilovol@cisco.com> Message-ID: This breaks c_rehash calls from dash (works fine with bash) dash doesn't like #!perl shebang, would PERL="/usr/bin/env perl" work for you? But unfortunately just passing PERL like this doesn't pass do_configure: Creating Makefile sh: 1: /usr/bin/env perl: not found WARNING: exit code 1 from a shell command. But passing it as: HASHBANGPERL="/usr/bin/env perl" PERL=perl seems to work. On Thu, Mar 5, 2020 at 12:55 PM Ruslan Bilovol via Openembedded-core < openembedded-core at lists.openembedded.org> wrote: > In our build environment we use wrapper script > for perl in non-standard configuration with > extra variables set (provided by custom > buildtools-tarball). > > In this case openssl fails to build because > by default it's Configure script detects and uses > perl executable directly (with absolute path) > obviously missing extra settings from wrapper > script. > > Pass PERL=perl environment variable to Configure, > so it won't try to use perl executable directly > but will use what is provided from environment. > > Signed-off-by: Ruslan Bilovol > --- > meta/recipes-connectivity/openssl/openssl_1.1.1d.bb | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb > b/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb > index c2ba005f47..d4871fe973 100644 > --- a/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb > +++ b/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb > @@ -123,7 +123,7 @@ do_configure () { > fi > # WARNING: do not set compiler/linker flags (-I/-D etc.) in > EXTRA_OECONF, as they will fully replace the > # environment variables set by bitbake. Adjust the environment > variables instead. > - PERL5LIB="${S}/external/perl/Text-Template-1.46/lib/" \ > + PERL=perl PERL5LIB="${S}/external/perl/Text-Template-1.46/lib/" \ > perl ${S}/Configure ${EXTRA_OECONF} ${PACKAGECONFIG_CONFARGS} > --prefix=$useprefix --openssldir=${libdir}/ssl-1.1 --libdir=${libdir} > $target > perl ${B}/configdata.pm --dump > } > -- > 2.17.1 > > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core at lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core > -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard.purdie at linuxfoundation.org Fri Mar 6 22:31:11 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Fri, 06 Mar 2020 22:31:11 +0000 Subject: [OE-core] Multilib conflicts in man pages. In-Reply-To: References: <62ba6d2a-098e-acbd-db0e-b2283a3b476a@mvista.com> <446c96a2d520e581eee85d519233fdb961c9d1c2.camel@linuxfoundation.org> Message-ID: On Fri, 2020-03-06 at 14:14 -0800, Jeremy A. Puhlman wrote: > > On 3/6/2020 2:00 PM, Richard Purdie wrote: > > On Tue, 2020-03-03 at 15:22 -0800, Jeremy Puhlman wrote: > > > Is there a preferred method in oe-core for dealing with man pages > > > that conflict due to differences in multilib pathing. > > > > > > For example an application lives in /usr/lib/foo/bar for one abi > > > but > > > /usr/lib64/foo/bar in another, and > > > that kind of information is encoded in to the man pages. > > > > > > Some things i have seen done in the past, is move the man pages > > > under > > > /user/share/man/${PN} or > > > use something like mutlilib script to deal with it. > > > > > > I am just curious if there is a canned, preferred way the project > > > handles those or wants to handle them? > > > > > > xinit, xserver-org, and groff each exhibit these issues. > > Could we just put a placeholder into the man page so they'd be > > identical? Multiple copies seems like overkill for something as > > trivial... > > A placeholder like: > /usr//sys.startxrc > from > /usr/lib64/sys.startxrc Yes, not sure about the exact form. You could just do: /usr/lib*/sys.startxrc or /usr//sys.startxrc ? Cheers, Richard From raj.khem at gmail.com Sat Mar 7 07:29:04 2020 From: raj.khem at gmail.com (Khem Raj) Date: Fri, 6 Mar 2020 23:29:04 -0800 Subject: [OE-core] [PATCH] make: Fix build on arm/clang Message-ID: <20200307072904.2435002-1-raj.khem@gmail.com> clang defines __arm which is interpreted as non-posix by make build system but thats not correct when using clang so patch addresses that Signed-off-by: Khem Raj --- ...inst-Do-not-undef-POSIX-on-clang-arm.patch | 38 +++++++++++++++++++ meta/recipes-devtools/make/make_4.3.bb | 1 + 2 files changed, 39 insertions(+) create mode 100644 meta/recipes-devtools/make/make/0001-makeinst-Do-not-undef-POSIX-on-clang-arm.patch diff --git a/meta/recipes-devtools/make/make/0001-makeinst-Do-not-undef-POSIX-on-clang-arm.patch b/meta/recipes-devtools/make/make/0001-makeinst-Do-not-undef-POSIX-on-clang-arm.patch new file mode 100644 index 0000000000..2da7c983dc --- /dev/null +++ b/meta/recipes-devtools/make/make/0001-makeinst-Do-not-undef-POSIX-on-clang-arm.patch @@ -0,0 +1,38 @@ +From 86b7947156a0c33e768d0a265e38f2881a70a7e2 Mon Sep 17 00:00:00 2001 +From: Khem Raj +Date: Fri, 6 Mar 2020 23:19:37 -0800 +Subject: [PATCH] makeinst: Do not undef POSIX on clang/arm + +if __arm internal compiler macro is defined then make assumes that the +system is not posix and goes ahead and undefs POSIX, which results in +miscompiling make with clang, since clang does define __arm unlike gcc +which does not, but they both support posix just fine, so here check for +compiler not being clang when __arm is defined before undefining posix + +Fixes error like +../make-4.3/src/job.c:507:27: error: too many arguments to function call, expected 0, have 1 + sigsetmask (siggetmask (0) & ~fatal_signal_mask) + ~~~~~~~~~~ ^ + +Upstream-Status: Pending +Signed-off-by: Khem Raj +--- + src/makeint.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/src/makeint.h b/src/makeint.h +index c428a36..fadf963 100644 +--- a/src/makeint.h ++++ b/src/makeint.h +@@ -115,7 +115,7 @@ extern int errno; + #endif + + /* Some systems define _POSIX_VERSION but are not really POSIX.1. */ +-#if (defined (butterfly) || defined (__arm) || (defined (__mips) && defined (_SYSTYPE_SVR3)) || (defined (sequent) && defined (i386))) ++#if (defined (butterfly) || (defined (__arm) && !defined(__clang__)) || (defined (__mips) && defined (_SYSTYPE_SVR3)) || (defined (sequent) && defined (i386))) + # undef POSIX + #endif + +-- +2.25.1 + diff --git a/meta/recipes-devtools/make/make_4.3.bb b/meta/recipes-devtools/make/make_4.3.bb index cd0ecd4df2..3e0eb543ba 100644 --- a/meta/recipes-devtools/make/make_4.3.bb +++ b/meta/recipes-devtools/make/make_4.3.bb @@ -8,6 +8,7 @@ SRC_URI += "\ file://0001-src-dir.c-fix-buffer-overflow-warning.patch \ file://0002-w32-compat-dirent.c-follow-header.patch \ file://0003-posixfcn-fcntl-gnulib-make-emulated.patch \ + file://0001-makeinst-Do-not-undef-POSIX-on-clang-arm.patch \ " EXTRA_OECONF += "--without-guile" -- 2.25.1 From anuj.mittal at intel.com Sat Mar 7 09:10:44 2020 From: anuj.mittal at intel.com (Mittal, Anuj) Date: Sat, 7 Mar 2020 09:10:44 +0000 Subject: [OE-core] [zeus][PATCH 00/22] zeus merge request, cover letter only In-Reply-To: References: Message-ID: <746f728ea1ad8878ce0432185acb77837f6d24a3.camel@intel.com> Ping. On Wed, 2020-03-04 at 07:59 +0800, Anuj Mittal wrote: > Please merge these changes from stable/zeus-next. > > Clean a-full on autobuilder except a single unrelated fetch failure > for > esdk test: > https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/751 > > Thanks, > > Anuj > > The following changes since commit > f39285bb82e68945a81034b84da09ca1078d6719: > > Revert "bash: Fix CVE-2019-18276" (2020-02-19 18:53:10 +0000) > > are available in the Git repository at: > > git://push.openembedded.org/openembedded-core-contrib stable/zeus- > next > > Alexander Kanavin (5): > perl: update to 5.30.1 > perl: package Config.pm from arch directory into the main perl > package > perl: install typemap and other extutils metadata as part of perl- > core > libmodule-build-perl: fix ptests > perl: fix failing ptests > > Anuj Mittal (3): > openssh: backport patch to fix "cert not yet valid" test > ncurses: add CVE_VERSION > libxml2: fix CVE-2020-7595 > > Bruce Ashfield (2): > linux-yocto/5.2: update to v5.2.29 > linux-yocto/5.2: update to v5.2.32 > > Jeremy Puhlman (1): > toolchain-shar-extract: ignore timestamp on decompress > > Kevin Hao (1): > xserver-nodm-init: Fix the start failure for non-root user > > Lee Chee Yang (2): > qemu: Fix CVE-2020-1711 > libxml2: Fix CVE-2019-20388 > > Nathan Rossi (2): > glibc-testsuite: Remove the do_install task > glibc-testsuite: Exclude this recipe from world builds > > Richard Purdie (2): > perl: Fix encode module reproducibility issues > perl: Fix makefile race causing configuration differences > > Ross Burton (1): > perl: improve reproducibility > > Tim Orling (1): > liberror-perl: upgrade 0.17028 -> 0.17029 > > Trevor Gamblin (1): > qemurunner.py: add try/except for pid handling race > > Yi Zhao (1): > ppp: Security fix CVE-2020-8597 > > meta/files/toolchain-shar-extract.sh | 2 +- > meta/lib/oeqa/utils/qemurunner.py | 5 +- > ...zo-decided-to-use-2020-as-a-future-d.patch | 46 +++++++++++++ > .../openssh/openssh_8.0p1.bb | 1 + > ...01-pppd-Fix-bounds-check-in-EAP-code.patch | 47 ++++++++++++++ > meta/recipes-connectivity/ppp/ppp_2.4.7.bb | 1 + > .../glibc/glibc-testsuite_2.30.bb | 3 + > .../libxml/libxml2/CVE-2019-20388.patch | 37 +++++++++++ > .../libxml/libxml2/CVE-2020-7595.patch | 36 +++++++++++ > meta/recipes-core/libxml/libxml2_2.9.9.bb | 2 + > .../ncurses/ncurses_6.1+20190803.bb | 2 + > ...correctly-exclude-unbuilt-extensions.patch | 27 ++++++++ > .../perl/files/encodefix.patch | 20 ++++++ > .../perl/files/fix-setgroup.patch | 49 -------------- > .../perl/files/perl-configpm-switch.patch | 4 +- > .../recipes-devtools/perl/files/racefix.patch | 24 +++++++ > ...rl_0.17028.bb => liberror-perl_0.17029.bb} | 4 +- > .../perl/libmodule-build-perl/run-ptest | 2 - > .../perl/libmodule-build-perl_0.4229.bb | 3 + > .../perl/{perl_5.30.0.bb => perl_5.30.1.bb} | 31 ++++++--- > meta/recipes-devtools/qemu/qemu.inc | 3 +- > .../qemu/qemu/CVE-2020-1711.patch | 64 > +++++++++++++++++++ > .../xserver-nodm-init/capability.conf | 2 + > .../x11-common/xserver-nodm-init/xserver-nodm | 8 +++ > .../x11-common/xserver-nodm-init_3.0.bb | 7 +- > .../linux/linux-yocto-rt_5.2.bb | 6 +- > .../linux/linux-yocto-tiny_5.2.bb | 8 +-- > meta/recipes-kernel/linux/linux-yocto_5.2.bb | 22 +++---- > 28 files changed, 379 insertions(+), 87 deletions(-) > create mode 100644 meta/recipes-connectivity/openssh/openssh/0001- > upstream-what-bozo-decided-to-use-2020-as-a-future-d.patch > create mode 100644 meta/recipes-connectivity/ppp/ppp/0001-pppd-Fix- > bounds-check-in-EAP-code.patch > create mode 100644 meta/recipes-core/libxml/libxml2/CVE-2019- > 20388.patch > create mode 100644 meta/recipes-core/libxml/libxml2/CVE-2020- > 7595.patch > create mode 100644 meta/recipes-devtools/perl/files/0001-tests- > adjust-to-correctly-exclude-unbuilt-extensions.patch > create mode 100644 meta/recipes-devtools/perl/files/encodefix.patch > delete mode 100644 meta/recipes-devtools/perl/files/fix- > setgroup.patch > create mode 100644 meta/recipes-devtools/perl/files/racefix.patch > rename meta/recipes-devtools/perl/{liberror-perl_0.17028.bb => > liberror-perl_0.17029.bb} (89%) > rename meta/recipes-devtools/perl/{perl_5.30.0.bb => perl_5.30.1.bb} > (93%) > create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2020- > 1711.patch > create mode 100644 meta/recipes-graphics/x11-common/xserver-nodm- > init/capability.conf > > -- > 2.24.1 > From adrian.freihofer at gmail.com Sat Mar 7 11:54:46 2020 From: adrian.freihofer at gmail.com (Adrian Freihofer) Date: Sat, 07 Mar 2020 12:54:46 +0100 Subject: [OE-core] [PATCH 0/2] Extensible SDK improvements Message-ID: Hi Richard, We have found two already supported ways to copy variables from the bitbake environment local.conf to the eSDK local.conf If a variable is defined in the local.conf bitbake environment, SDK_LOCAL_CONF_WHITELIST and SDK_LOCAL_CONF_BLACKLIST can be used to add it to the local.conf eSDK file. If a variable should be statically defined for the eSDK but not for the bitbake environment, sdk-extra.conf is useful. Now we would like to add a third way to add variables which are dynamically calculated by bitbake but need to be statically added to the eSDK local.conf. For example we would like to support something like that: def get_version_from_git(d): version = d.getVar("GIT_VERSION", True) if version: return version # runs in eSDK else: return bb.process.run("git... # runs in bitbake GIT_VERSION := "${@get_version_from_git(d)}" SDK_LOCAL_CONF_EXTRALIST_append = " GIT_VERSION" Regards, Adrian From richard.purdie at linuxfoundation.org Sat Mar 7 12:40:42 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Sat, 07 Mar 2020 12:40:42 +0000 Subject: [OE-core] [PATCH 0/2] Extensible SDK improvements In-Reply-To: References: Message-ID: <8718ce405436564b3ad55fa52046e5e55ee562dd.camel@linuxfoundation.org> On Sat, 2020-03-07 at 12:54 +0100, Adrian Freihofer wrote: > Hi Richard, > > We have found two already supported ways to copy variables from the > bitbake environment local.conf to the eSDK local.conf > > If a variable is defined in the local.conf bitbake environment, > SDK_LOCAL_CONF_WHITELIST and SDK_LOCAL_CONF_BLACKLIST can be used to > add it to the local.conf eSDK file. > > If a variable should be statically defined for the eSDK but not for > the > bitbake environment, sdk-extra.conf is useful. > > Now we would like to add a third way to add variables which are > dynamically calculated by bitbake but need to be statically added to > the eSDK local.conf. For example we would like to support something > like that: > > def get_version_from_git(d): > version = d.getVar("GIT_VERSION", True) > if version: > return version # runs in eSDK > else: > return bb.process.run("git... # runs in bitbake > > GIT_VERSION := "${@get_version_from_git(d)}" > > SDK_LOCAL_CONF_EXTRALIST_append = " GIT_VERSION" This worries me a bit since it means the eSDK and the "real" build can behave differently. I appreciate that can happen even with the other variables and means of setting them but this takes it to a new level. Ultimately I think we're aiming to have normal builds convert into an eSDK and vice versa more easily. This seems to pull us further away from that :/. What is the reasoning for having them behaving differently? Cheers, Richard From martin.jansa at gmail.com Sat Mar 7 13:30:06 2020 From: martin.jansa at gmail.com (Martin Jansa) Date: Sat, 7 Mar 2020 14:30:06 +0100 Subject: [OE-core] [PATCH] openssl: fix perl shebang in c_rehash Message-ID: <20200307133006.21223-1-Martin.Jansa@gmail.com> * passing PERL=perl breaks c_rehash calls from dash (works fine with bash) dash doesn't like #!perl shebang PERL="/usr/bin/env perl" unfortunately just passing PERL like this doesn't pass do_configure: Creating Makefile sh: 1: /usr/bin/env perl: not found WARNING: exit code 1 from a shell command. But passing it as: HASHBANGPERL="/usr/bin/env perl" PERL=perl seems to work. Signed-off-by: Martin Jansa --- meta/recipes-connectivity/openssl/openssl_1.1.1d.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb b/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb index d4871fe973..a1a53aff3c 100644 --- a/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb +++ b/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb @@ -123,7 +123,7 @@ do_configure () { fi # WARNING: do not set compiler/linker flags (-I/-D etc.) in EXTRA_OECONF, as they will fully replace the # environment variables set by bitbake. Adjust the environment variables instead. - PERL=perl PERL5LIB="${S}/external/perl/Text-Template-1.46/lib/" \ + HASHBANGPERL="/usr/bin/env perl" PERL=perl PERL5LIB="${S}/external/perl/Text-Template-1.46/lib/" \ perl ${S}/Configure ${EXTRA_OECONF} ${PACKAGECONFIG_CONFARGS} --prefix=$useprefix --openssldir=${libdir}/ssl-1.1 --libdir=${libdir} $target perl ${B}/configdata.pm --dump } -- 2.20.1 From jpuhlman at mvista.com Sat Mar 7 13:51:03 2020 From: jpuhlman at mvista.com (Jeremy A. Puhlman) Date: Sat, 7 Mar 2020 05:51:03 -0800 Subject: [OE-core] [PATCH 1/3] groff: Make manpages binary identical Message-ID: <20200307135105.12838-1-jpuhlman@mvista.com> From: Jeremy Puhlman Signed-off-by: Jeremy A. Puhlman --- .../0001-Make-manpages-mulitlib-identical.patch | 27 ++++++++++++++++++++++ meta/recipes-extended/groff/groff_1.22.4.bb | 1 + 2 files changed, 28 insertions(+) create mode 100644 meta/recipes-extended/groff/files/0001-Make-manpages-mulitlib-identical.patch diff --git a/meta/recipes-extended/groff/files/0001-Make-manpages-mulitlib-identical.patch b/meta/recipes-extended/groff/files/0001-Make-manpages-mulitlib-identical.patch new file mode 100644 index 0000000000..2f6b091bff --- /dev/null +++ b/meta/recipes-extended/groff/files/0001-Make-manpages-mulitlib-identical.patch @@ -0,0 +1,27 @@ +From e738f9185ba90f2083c846ade3551234bb5a7cbc Mon Sep 17 00:00:00 2001 +From: Jeremy Puhlman +Date: Sat, 7 Mar 2020 00:59:13 +0000 +Subject: [PATCH] Make manpages mulitlib identical + +Upstream-status: pending +Signed-off-by: Jeremy Puhlman +--- + Makefile.am | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/Makefile.am b/Makefile.am +index d18c49b..6175fe9 100644 +--- a/Makefile.am ++++ b/Makefile.am +@@ -917,7 +917,7 @@ SUFFIXES += .man + -e "s|[@]MDATE[@]|`$(PERL) $(top_srcdir)/mdate.pl $<`|g" \ + -e "s|[@]OLDFONTDIR[@]|`echo $(oldfontdir) | sed -f $(makevarescape)`|g" \ + -e "s|[@]PDFDOCDIR[@]|`echo $(pdfdocdir) | sed -f $(makevarescape)`|g" \ +- -e "s|[@]SYSTEMMACRODIR[@]|`echo $(systemtmacdir) | sed -f $(makevarescape)`|g" \ ++ -e "s|[@]SYSTEMMACRODIR[@]|`echo $(systemtmacdir) | sed -e 's,$(libdir),$(prefix)/lib*,' | sed -f $(makevarescape)`|g" \ + -e "s|[@]TMAC_AN_PREFIX[@]|$(tmac_an_prefix)|g" \ + -e "s|[@]TMAC_M_PREFIX[@]|$(tmac_m_prefix)|g" \ + -e "s|[@]TMAC_MDIR[@]|$(tmacdir)/mm|g" \ +-- +2.23.0 + diff --git a/meta/recipes-extended/groff/groff_1.22.4.bb b/meta/recipes-extended/groff/groff_1.22.4.bb index 082597f693..e398478349 100644 --- a/meta/recipes-extended/groff/groff_1.22.4.bb +++ b/meta/recipes-extended/groff/groff_1.22.4.bb @@ -12,6 +12,7 @@ SRC_URI = "${GNU_MIRROR}/groff/groff-${PV}.tar.gz \ file://groff-not-search-fonts-on-build-host.patch \ file://0001-support-musl.patch \ file://0001-Include-config.h.patch \ + file://0001-Make-manpages-mulitlib-identical.patch \ " SRC_URI[md5sum] = "08fb04335e2f5e73f23ea4c3adbf0c5f" -- 2.13.3 From jpuhlman at mvista.com Sat Mar 7 13:51:04 2020 From: jpuhlman at mvista.com (Jeremy A. Puhlman) Date: Sat, 7 Mar 2020 05:51:04 -0800 Subject: [OE-core] [PATCH 2/3] xserver-xorg: make manpage mutlilib identical In-Reply-To: <20200307135105.12838-1-jpuhlman@mvista.com> References: <20200307135105.12838-1-jpuhlman@mvista.com> Message-ID: <20200307135105.12838-2-jpuhlman@mvista.com> From: Jeremy Puhlman Signed-off-by: Jeremy A. Puhlman --- meta/recipes-graphics/xorg-xserver/xserver-xorg.inc | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc b/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc index 14ba6bfee6..b4f0760176 100644 --- a/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc +++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc @@ -152,6 +152,7 @@ PACKAGECONFIG[gcrypt] = "--with-sha1=libgcrypt,,libgcrypt" do_install_append () { # Its assumed base-files creates this for us rmdir ${D}${localstatedir}/log/ + sed -i -e 's,${libdir}/xorg/modules,${prefix}/lib*/xorg/modules,' ${D}${mandir}/man5/xorg.conf.5 } # Add runtime provides for the ABI versions of the video and input subsystems, -- 2.13.3 From jpuhlman at mvista.com Sat Mar 7 13:51:05 2020 From: jpuhlman at mvista.com (Jeremy A. Puhlman) Date: Sat, 7 Mar 2020 05:51:05 -0800 Subject: [OE-core] [PATCH 3/3] xinit: make manpages multilib identical In-Reply-To: <20200307135105.12838-1-jpuhlman@mvista.com> References: <20200307135105.12838-1-jpuhlman@mvista.com> Message-ID: <20200307135105.12838-3-jpuhlman@mvista.com> From: Jeremy Puhlman Signed-off-by: Jeremy A. Puhlman --- .../0001-Make-manpage-multilib-identical.patch | 28 ++++++++++++++++++++++ meta/recipes-graphics/xorg-app/xinit_1.4.1.bb | 2 ++ 2 files changed, 30 insertions(+) create mode 100644 meta/recipes-graphics/xorg-app/xinit/0001-Make-manpage-multilib-identical.patch diff --git a/meta/recipes-graphics/xorg-app/xinit/0001-Make-manpage-multilib-identical.patch b/meta/recipes-graphics/xorg-app/xinit/0001-Make-manpage-multilib-identical.patch new file mode 100644 index 0000000000..649905574c --- /dev/null +++ b/meta/recipes-graphics/xorg-app/xinit/0001-Make-manpage-multilib-identical.patch @@ -0,0 +1,28 @@ +From d642e60d8963f1b90569cd0ab5c29ac2c9bfe939 Mon Sep 17 00:00:00 2001 +From: Jeremy Puhlman +Date: Fri, 6 Mar 2020 22:28:14 +0000 +Subject: [PATCH] Make manpage multilib identical + +Upstream-Status: Submitted + +Signed-off-by: Jeremy Puhlman +--- + man/Makefile.am | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/man/Makefile.am b/man/Makefile.am +index 9c6569f..608e933 100644 +--- a/man/Makefile.am ++++ b/man/Makefile.am +@@ -12,7 +12,7 @@ MAN_SUBSTS+= -e 's|__XSERVERNAME__|$(XSERVERNAME)|g' \ + -e 's|__XCONFIGFILEMAN__|$(XCONFIGFILEMAN)|g' \ + -e 's|__xinitdir__|$(XINITDIR)|g' \ + -e 's|__bindir__|$(bindir)|g' \ +- -e 's|__libdir__|$(libdir)|g' \ ++ -e 's|__libdir__|$(prefix)/lib*|g' \ + -e 's|__configdir__|$(XINITDIR)|g' + + +-- +2.23.0 + diff --git a/meta/recipes-graphics/xorg-app/xinit_1.4.1.bb b/meta/recipes-graphics/xorg-app/xinit_1.4.1.bb index 5626ebbd52..c9e28d9bba 100644 --- a/meta/recipes-graphics/xorg-app/xinit_1.4.1.bb +++ b/meta/recipes-graphics/xorg-app/xinit_1.4.1.bb @@ -12,6 +12,8 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=18f01e7b39807bebe2b8df101a039b68" PE = "1" +SRC_URI += "file://0001-Make-manpage-multilib-identical.patch" + SRC_URI[md5sum] = "6d506ab2efc17a08e87778654e099d37" SRC_URI[sha256sum] = "de9b8f617b68a70f6caf87da01fcf0ebd2b75690cdcba9c921d0ef54fa54abb9" -- 2.13.3 From patchwork at patchwork.openembedded.org Sat Mar 7 14:02:32 2020 From: patchwork at patchwork.openembedded.org (Patchwork) Date: Sat, 07 Mar 2020 14:02:32 -0000 Subject: [OE-core] =?utf-8?q?=E2=9C=97_patchtest=3A_failure_for_=22groff?= =?utf-8?q?=3A_Make_manpages_binary_id=2E=2E=2E=22_and_2_more?= In-Reply-To: <20200307135105.12838-1-jpuhlman@mvista.com> References: <20200307135105.12838-1-jpuhlman@mvista.com> Message-ID: <20200307140232.2273.22025@do> == Series Details == Series: "groff: Make manpages binary id..." and 2 more Revision: 1 URL : https://patchwork.openembedded.org/series/23144/ 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 Upstream-Status is in incorrect format [test_upstream_status_presence_format] Suggested fix Fix Upstream-Status format in 0001-Make-manpages-mulitlib-identical.patch Current Upstream-status: pending Standard format Upstream-Status: Valid status Pending, Accepted, Backport, Denied, Inappropriate [reason], Submitted [where] If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core at 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 From jpuhlman at mvista.com Sat Mar 7 14:05:48 2020 From: jpuhlman at mvista.com (Jeremy A. Puhlman) Date: Sat, 7 Mar 2020 06:05:48 -0800 Subject: [OE-core] [PATCH v2] groff: Make manpages binary identical Message-ID: <20200307140548.13517-1-jpuhlman@mvista.com> From: Jeremy Puhlman Signed-off-by: Jeremy A. Puhlman --- .../0001-Make-manpages-mulitlib-identical.patch | 27 ++++++++++++++++++++++ meta/recipes-extended/groff/groff_1.22.4.bb | 1 + 2 files changed, 28 insertions(+) create mode 100644 meta/recipes-extended/groff/files/0001-Make-manpages-mulitlib-identical.patch diff --git a/meta/recipes-extended/groff/files/0001-Make-manpages-mulitlib-identical.patch b/meta/recipes-extended/groff/files/0001-Make-manpages-mulitlib-identical.patch new file mode 100644 index 0000000000..329a97cb2e --- /dev/null +++ b/meta/recipes-extended/groff/files/0001-Make-manpages-mulitlib-identical.patch @@ -0,0 +1,27 @@ +From e738f9185ba90f2083c846ade3551234bb5a7cbc Mon Sep 17 00:00:00 2001 +From: Jeremy Puhlman +Date: Sat, 7 Mar 2020 00:59:13 +0000 +Subject: [PATCH] Make manpages mulitlib identical + +Upstream-status: Pending +Signed-off-by: Jeremy Puhlman +--- + Makefile.am | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/Makefile.am b/Makefile.am +index d18c49b..6175fe9 100644 +--- a/Makefile.am ++++ b/Makefile.am +@@ -917,7 +917,7 @@ SUFFIXES += .man + -e "s|[@]MDATE[@]|`$(PERL) $(top_srcdir)/mdate.pl $<`|g" \ + -e "s|[@]OLDFONTDIR[@]|`echo $(oldfontdir) | sed -f $(makevarescape)`|g" \ + -e "s|[@]PDFDOCDIR[@]|`echo $(pdfdocdir) | sed -f $(makevarescape)`|g" \ +- -e "s|[@]SYSTEMMACRODIR[@]|`echo $(systemtmacdir) | sed -f $(makevarescape)`|g" \ ++ -e "s|[@]SYSTEMMACRODIR[@]|`echo $(systemtmacdir) | sed -e 's,$(libdir),$(prefix)/lib*,' | sed -f $(makevarescape)`|g" \ + -e "s|[@]TMAC_AN_PREFIX[@]|$(tmac_an_prefix)|g" \ + -e "s|[@]TMAC_M_PREFIX[@]|$(tmac_m_prefix)|g" \ + -e "s|[@]TMAC_MDIR[@]|$(tmacdir)/mm|g" \ +-- +2.23.0 + diff --git a/meta/recipes-extended/groff/groff_1.22.4.bb b/meta/recipes-extended/groff/groff_1.22.4.bb index 082597f693..e398478349 100644 --- a/meta/recipes-extended/groff/groff_1.22.4.bb +++ b/meta/recipes-extended/groff/groff_1.22.4.bb @@ -12,6 +12,7 @@ SRC_URI = "${GNU_MIRROR}/groff/groff-${PV}.tar.gz \ file://groff-not-search-fonts-on-build-host.patch \ file://0001-support-musl.patch \ file://0001-Include-config.h.patch \ + file://0001-Make-manpages-mulitlib-identical.patch \ " SRC_URI[md5sum] = "08fb04335e2f5e73f23ea4c3adbf0c5f" -- 2.13.3 From raj.khem at gmail.com Sat Mar 7 14:17:09 2020 From: raj.khem at gmail.com (Khem Raj) Date: Sat, 7 Mar 2020 06:17:09 -0800 Subject: [OE-core] [PATCH v2] babeltrace2: added first version, 2.0.1 In-Reply-To: <20200305120629.329-1-wallinux@gmail.com> References: <20200305120629.329-1-wallinux@gmail.com> Message-ID: I am seeing a QA textrel issue with clang/arm http://errors.yoctoproject.org/Errors/Details/393983/ On Thu, Mar 5, 2020 at 4:07 AM Anders Wallin wrote: > > Babeltrace 1 vs. Babeltrace 2 > > The Babeltrace project exists since 2010. In 2020, Babeltrace 2 was released. > Babeltrace 2 is a complete rewrite of the library, Python bindings, and CLI. It > is plugin based and offers much more features and potential than Babeltrace 1. > > Because Babeltrace 2 is still a young released project, some distributions still > provide packages for the Babeltrace 1 project. Both projects can coexist on the > same system as there are no common installed files. > > Signed-off-by: Anders Wallin > --- > meta/conf/distro/include/distro_alias.inc | 1 + > meta/conf/distro/include/maintainers.inc | 1 + > .../distro/include/ptest-packagelists.inc | 1 + > .../packagegroup-core-tools-profile.bb | 2 + > ...not-run-test-applications-from-.libs.patch | 28 ++++++ > .../lttng/babeltrace2/run-ptest | 9 ++ > .../recipes-kernel/lttng/babeltrace2_2.0.1.bb | 92 +++++++++++++++++++ > 7 files changed, 134 insertions(+) > create mode 100644 meta/recipes-kernel/lttng/babeltrace2/0001-tests-do-not-run-test-applications-from-.libs.patch > create mode 100755 meta/recipes-kernel/lttng/babeltrace2/run-ptest > create mode 100644 meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb > > diff --git a/meta/conf/distro/include/distro_alias.inc b/meta/conf/distro/include/distro_alias.inc > index 79ebcaee29..0e4a9a9f8f 100644 > --- a/meta/conf/distro/include/distro_alias.inc > +++ b/meta/conf/distro/include/distro_alias.inc > @@ -15,6 +15,7 @@ DISTRO_PN_ALIAS_pn-alsa-utils-scripts = "OE-Core" > DISTRO_PN_ALIAS_pn-atk = "Fedora=atk OpenSuSE=atk" > DISTRO_PN_ALIAS_pn-avahi-ui = "Ubuntu=avahi-discover Debian=avahi-discover" > DISTRO_PN_ALIAS_pn-babeltrace = "OSPDT" > +DISTRO_PN_ALIAS_pn-babeltrace2 = "OSPDT" > DISTRO_PN_ALIAS_pn-bjam = "OpenSuSE=boost-jam Debian=bjam" > DISTRO_PN_ALIAS_pn-blktool = "Debian=blktool Mandriva=blktool" > DISTRO_PN_ALIAS_pn-bluez5 = "Fedora=bluez Opensuse=bluez" > diff --git a/meta/conf/distro/include/maintainers.inc b/meta/conf/distro/include/maintainers.inc > index 10095ffe76..adb18228e7 100644 > --- a/meta/conf/distro/include/maintainers.inc > +++ b/meta/conf/distro/include/maintainers.inc > @@ -59,6 +59,7 @@ RECIPE_MAINTAINER_pn-automake = "Robert Yang " > RECIPE_MAINTAINER_pn-avahi = "Yi Zhao " > RECIPE_MAINTAINER_pn-avahi-ui = "Yi Zhao " > RECIPE_MAINTAINER_pn-babeltrace = "Alexander Kanavin " > +RECIPE_MAINTAINER_pn-babeltrace2 = "Alexander Kanavin " > RECIPE_MAINTAINER_pn-base-files = "Anuj Mittal " > RECIPE_MAINTAINER_pn-base-passwd = "Anuj Mittal " > RECIPE_MAINTAINER_pn-bash = "Hongxu Jia " > diff --git a/meta/conf/distro/include/ptest-packagelists.inc b/meta/conf/distro/include/ptest-packagelists.inc > index 4afac58e3a..d6f3aafc7f 100644 > --- a/meta/conf/distro/include/ptest-packagelists.inc > +++ b/meta/conf/distro/include/ptest-packagelists.inc > @@ -64,6 +64,7 @@ PTESTS_FAST = "\ > > PTESTS_SLOW = "\ > babeltrace-ptest \ > + babeltrace2-ptest \ > busybox-ptest \ > dbus-test-ptest \ > e2fsprogs-ptest \ > diff --git a/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb b/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb > index 984c2fac92..ac180b542a 100644 > --- a/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb > +++ b/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb > @@ -46,6 +46,7 @@ LTTNGMODULES = "lttng-modules" > LTTNGMODULES_arc = "" > > BABELTRACE = "babeltrace" > +BABELTRACE2 = "babeltrace2" > > # valgrind does not work on the following configurations/architectures > > @@ -69,6 +70,7 @@ RDEPENDS_${PN} = "\ > ${LTTNGTOOLS} \ > ${LTTNGMODULES} \ > ${BABELTRACE} \ > + ${BABELTRACE2} \ > ${SYSTEMTAP} \ > ${VALGRIND} \ > " > diff --git a/meta/recipes-kernel/lttng/babeltrace2/0001-tests-do-not-run-test-applications-from-.libs.patch b/meta/recipes-kernel/lttng/babeltrace2/0001-tests-do-not-run-test-applications-from-.libs.patch > new file mode 100644 > index 0000000000..805dde8064 > --- /dev/null > +++ b/meta/recipes-kernel/lttng/babeltrace2/0001-tests-do-not-run-test-applications-from-.libs.patch > @@ -0,0 +1,28 @@ > +From 582713cc9a013481eeef253195d644020f637ec4 Mon Sep 17 00:00:00 2001 > +Message-Id: <582713cc9a013481eeef253195d644020f637ec4.1583403622.git.wallinux at gmail.com> > +From: Anders Wallin > +Date: Thu, 5 Mar 2020 11:20:04 +0100 > +Subject: [PATCH] tests: do not run test applications from .libs > + > +Cross compile specific change > + > +Upstream-Status: Inappropriate [oe-core specific] > + > +Signed-off-by: Anders Wallin > +--- > + tests/lib/test_plugin | 2 +- > + 1 file changed, 1 insertion(+), 1 deletion(-) > + > +diff --git a/tests/lib/test_plugin b/tests/lib/test_plugin > +index 652c90cc..1f817c50 100755 > +--- a/tests/lib/test_plugin > ++++ b/tests/lib/test_plugin > +@@ -26,4 +26,4 @@ fi > + # shellcheck source=../utils/utils.sh > + source "$UTILSSH" > + > +-"${BT_TESTS_BUILDDIR}/lib/plugin" "${BT_TESTS_BUILDDIR}/lib/test-plugin-plugins/.libs" > ++"${BT_TESTS_BUILDDIR}/lib/plugin" "${BT_TESTS_BUILDDIR}/lib/test-plugin-plugins" > +-- > +2.25.1 > + > diff --git a/meta/recipes-kernel/lttng/babeltrace2/run-ptest b/meta/recipes-kernel/lttng/babeltrace2/run-ptest > new file mode 100755 > index 0000000000..72fe223436 > --- /dev/null > +++ b/meta/recipes-kernel/lttng/babeltrace2/run-ptest > @@ -0,0 +1,9 @@ > +#!/bin/sh > +# use target=recheck if you want to recheck failing tests > +[ "$target" = "" ] && target=check > + > +# Without --ignore-exit, the tap harness causes any FAILs within a > +# test plan to raise ERRORs; this is just noise. > +makeargs="LOG_DRIVER_FLAGS=--ignore-exit abs_top_srcdir=$PWD abs_top_builddir=$PWD GREP=grep SED=sed PYTHON=python3" > + > +exec make -C tests -k -s $makeargs $target 2>/dev/null > diff --git a/meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb b/meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb > new file mode 100644 > index 0000000000..16953d6807 > --- /dev/null > +++ b/meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb > @@ -0,0 +1,92 @@ > +SUMMARY = "Babeltrace2 - Trace Format Babel Tower" > +DESCRIPTION = "Babeltrace provides trace read and write libraries in host side, as well as a trace converter, which used to convert LTTng 2.0 traces into human-readable log." > +HOMEPAGE = "http://babeltrace.org/" > +BUGTRACKER = "https://bugs.lttng.org/projects/babeltrace" > +LICENSE = "MIT & GPLv2 & LGPLv2.1 & BSD-2-Clause" > +LIC_FILES_CHKSUM = "file://LICENSE;md5=a6a458c13f18385b7bc5069a6d7b176e" > + > +DEPENDS = "glib-2.0 util-linux popt bison-native flex-native" > + > +SRC_URI = "git://git.linuxfoundation.org/diamon/babeltrace.git;branch=stable-2.0 \ > + file://run-ptest \ > + file://0001-tests-do-not-run-test-applications-from-.libs.patch \ > + " > +SRCREV = "06df58f89ee51b1a2c6a2c187ec3f15691633910" > +UPSTREAM_CHECK_GITTAGREGEX = "v(?P2(\.\d+)+)$" > + > +S = "${WORKDIR}/git" > + > +inherit autotools pkgconfig ptest > + > +EXTRA_OECONF = "--disable-debug-info" > + > +PACKAGECONFIG ??= "manpages" > +PACKAGECONFIG[manpages] = ", --disable-man-pages, asciidoc-native xmlto-native" > + > +FILES_${PN}-staticdev += "${libdir}/babeltrace2/plugins/*.a" > +FILES_${PN} += "${libdir}/babeltrace2/plugins/*.so" > + > +ASNEEDED = "" > + > +RDEPENDS_${PN}-ptest += "bash gawk python3" > + > +do_compile_ptest () { > + make -C tests all > +} > + > +do_install_ptest () { > + install -d "${D}${PTEST_PATH}/tests" > + > + # Copy required files from source directory > + for d in $(find "${S}/tests" -type d -printf '%P ') ; do > + install -d "${D}${PTEST_PATH}/tests/$d" > + find "${S}/tests/$d" -maxdepth 1 -executable -type f \ > + -exec install -t "${D}${PTEST_PATH}/tests/$d" {} + > + find "${S}/tests/$d" -maxdepth 1 -name *.sh \ > + -exec install -t "${D}${PTEST_PATH}/tests/$d" {} \; > + find "${S}/tests/$d" -maxdepth 1 -name *.py \ > + -exec install -t "${D}${PTEST_PATH}/tests/$d" {} \; > + find "${S}/tests/$d" -maxdepth 1 -name *.expect \ > + -exec install -t "${D}${PTEST_PATH}/tests/$d" {} \; > + done > + install -d "${D}${PTEST_PATH}/tests/data/ctf-traces/" > + cp -a ${S}/tests/data/ctf-traces/* ${D}${PTEST_PATH}/tests/data/ctf-traces/ > + > + # Copy the tests directory tree and the executables and > + # Makefiles found within. > + install -D "${B}/tests/Makefile" "${D}${PTEST_PATH}/tests/" > + for d in $(find "${B}/tests" -type d -not -name .libs -printf '%P ') ; do > + install -d "${D}${PTEST_PATH}/tests/$d" > + find "${B}/tests/$d" -maxdepth 1 -executable -type f \ > + -exec install -t "${D}${PTEST_PATH}/tests/$d" {} + > + test -r "${B}/tests/$d/Makefile" && \ > + install -t "${D}${PTEST_PATH}/tests/$d" "${B}/tests/$d/Makefile" > + find "${B}/tests/$d" -maxdepth 1 -name *.sh \ > + -exec install -t "${D}${PTEST_PATH}/tests/$d" {} \; > + done > + > + for d in $(find "${B}/tests" -type d -name .libs -printf '%P ') ; do > + for f in $(find "${B}/tests/$d" -maxdepth 1 -executable -type f -printf '%P ') ; do > + cp ${B}/tests/$d/$f ${D}${PTEST_PATH}/tests/`dirname $d`/$f > + done > + done > + > + # Prevent attempts to update Makefiles during test runs, and > + # silence "Making check in $SUBDIR" messages. > + find "${D}${PTEST_PATH}" -name Makefile -type f -exec \ > + sed -i \ > + -e '/Makefile:/,/^$/d' \ > + -e '/%: %.in/,/^$/d' \ > + -e '/echo "Making $$target in $$subdir"; \\/d' \ > + -e 's/^srcdir = \(.*\)/srcdir = ./' \ > + -e 's/^builddir = \(.*\)/builddir = ./' \ > + -e 's/^all-am:.*/all-am:/' \ > + {} + > + > + # Substitute links to installed binaries. > + install -d "${D}${PTEST_PATH}/src/cli/" > + ln -s "${bindir}/babeltrace2" ${D}${PTEST_PATH}/src/cli/ > + > + # Remove architechture specific testfiles > + rm -rf ${D}${PTEST_PATH}/tests/data/plugins/flt.lttng-utils.debug-info/* > +} > -- > 2.25.1 > > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core at lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core From patchwork at patchwork.openembedded.org Sat Mar 7 14:32:23 2020 From: patchwork at patchwork.openembedded.org (Patchwork) Date: Sat, 07 Mar 2020 14:32:23 -0000 Subject: [OE-core] =?utf-8?q?=E2=9C=97_patchtest=3A_failure_for_groff=3A_M?= =?utf-8?q?ake_manpages_binary_identical?= In-Reply-To: <20200307140548.13517-1-jpuhlman@mvista.com> References: <20200307140548.13517-1-jpuhlman@mvista.com> Message-ID: <20200307143223.2277.46482@do> == Series Details == Series: groff: Make manpages binary identical Revision: 1 URL : https://patchwork.openembedded.org/series/23145/ 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 Upstream-Status is in incorrect format [test_upstream_status_presence_format] Suggested fix Fix Upstream-Status format in 0001-Make-manpages-mulitlib-identical.patch Current Upstream-status: Pending Standard format Upstream-Status: Valid status Pending, Accepted, Backport, Denied, Inappropriate [reason], Submitted [where] If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core at 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 From adrian.freihofer at gmail.com Sat Mar 7 14:55:46 2020 From: adrian.freihofer at gmail.com (Adrian Freihofer) Date: Sat, 07 Mar 2020 15:55:46 +0100 Subject: [OE-core] [PATCH 0/2] Extensible SDK improvements In-Reply-To: <8718ce405436564b3ad55fa52046e5e55ee562dd.camel@linuxfoundation.org> References: <8718ce405436564b3ad55fa52046e5e55ee562dd.camel@linuxfoundation.org> Message-ID: <06f78962af6ad632793a533a22d8f1b91e5a50fc.camel@gmail.com> On Sat, 2020-03-07 at 12:40 +0000, Richard Purdie wrote: > On Sat, 2020-03-07 at 12:54 +0100, Adrian Freihofer wrote: > > Hi Richard, > > > > We have found two already supported ways to copy variables from the > > bitbake environment local.conf to the eSDK local.conf > > > > If a variable is defined in the local.conf bitbake environment, > > SDK_LOCAL_CONF_WHITELIST and SDK_LOCAL_CONF_BLACKLIST can be used to > > add it to the local.conf eSDK file. > > > > If a variable should be statically defined for the eSDK but not for > > the > > bitbake environment, sdk-extra.conf is useful. > > > > Now we would like to add a third way to add variables which are > > dynamically calculated by bitbake but need to be statically added to > > the eSDK local.conf. For example we would like to support something > > like that: > > > > def get_version_from_git(d): > > version = d.getVar("GIT_VERSION", True) > > if version: > > return version # runs in eSDK > > else: > > return bb.process.run("git... # runs in bitbake > > > > GIT_VERSION := "${@get_version_from_git(d)}" > > > > SDK_LOCAL_CONF_EXTRALIST_append = " GIT_VERSION" > > This worries me a bit since it means the eSDK and the "real" build can > behave differently. I appreciate that can happen even with the other > variables and means of setting them but this takes it to a new level. > That I understand. The usage of the SDK_LOCAL_CONF_EXTRALIST would be very specific. Wrong usage would lead to a broken sstate in the eSDK. > Ultimately I think we're aiming to have normal builds convert into an > eSDK and vice versa more easily. This seems to pull us further away > from that :/. > > What is the reasoning for having them behaving differently? Our goal is to equate the eSDK behavior with the behavior of the real build, also for the example with the GIT_VERSION, which bitbake and git will dynamically evaluate at eSDK build time. Suppose we want to compile the GIT_VERSION (last tag) from poky without any manual steps into the firmware. bitbake can simply call $ describe git --tags --dirty uninative-2,8-74-g56446f4570-dirty With Bitbake the variable can change. But in eSDK the GIT_VERSION must be a constant. The above function behaves like a constant if GIT_VERSION is defined in the local.conf for example. But it has a dynamic behavior if GIT_VERSION is undefined. The only missing part in the current Poky, is a way to automatically write the value to the local.conf of the eSDK. I don't think this would be much different than the already existing sdk-extra.conf file. Regards, Adrian > Cheers, > > Richard > > > From adrian.freihofer at gmail.com Sat Mar 7 15:01:45 2020 From: adrian.freihofer at gmail.com (Adrian Freihofer) Date: Sat, 7 Mar 2020 16:01:45 +0100 Subject: [OE-core] [PATCH v3] runqemu: support multiple NICs Message-ID: <20200307150145.3100113-1-adrian.freihofer@siemens.com> Emulating more than one network interface with runqemu is sometimes a bit tricky, but possible. For example, this leads to an emulated device with eth0 and eth1: QB_NETWORK_DEVICE_prepend = " \ -device virtio-net-device,mac=52:54:00:12:34:03 \ " Note: On some emulated NIC types, Qemu and the kernel enumerate the eths in the guest in reverse order to how the device parameters are passed to Qemu. So in this case it is important that the additional NICs are prepended to the -device parameter, which gets automatically added by Qemu. Otherwise, the interface eth1 will be connected to the host, but eth0 will be assigned the IP address 192.168.7.x, which obviously does not work. When booting Qemu with two NICs, but only one set of network configuration parameters gets passed to the kernel, the kernel seems to search for a configuration for all NICs. This delays the boot process for a very long time. This change solves the timeout problem. Tested with: oe-selftest --run-tests runqemu Signed-off-by: Adrian Freihofer --- scripts/runqemu | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/runqemu b/scripts/runqemu index dd0aa4b28f..d34f8eec25 100755 --- a/scripts/runqemu +++ b/scripts/runqemu @@ -1147,7 +1147,7 @@ class BaseConfig(object): client = gateway + 1 if self.fstype == 'nfs': self.setup_nfs() - netconf = "192.168.7.%s::192.168.7.%s:255.255.255.0" % (client, gateway) + netconf = "192.168.7.%s::192.168.7.%s:255.255.255.0::eth0" % (client, gateway) logger.info("Network configuration: %s", netconf) self.kernel_cmdline_script += " ip=%s" % netconf mac = "%s%02x" % (self.mac_tap, client) -- 2.24.1 From richard.purdie at linuxfoundation.org Sat Mar 7 15:59:18 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Sat, 7 Mar 2020 15:59:18 +0000 Subject: [OE-core] [PATCH] files/toolchain-shar-extract.sh: Rework PATH cleaning Message-ID: <20200307155918.1157101-1-richard.purdie@linuxfoundation.org> Trying to create a clean PATH breaks cases where we install a buildtools tarball on hosts to provide newer versions of gcc. Rework the fix for #8698 to clean up directories in PATH which don't exist isntead. Do it with python as the shell version was too fraught with corner cases. Signed-off-by: Richard Purdie --- meta/files/toolchain-shar-extract.sh | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/meta/files/toolchain-shar-extract.sh b/meta/files/toolchain-shar-extract.sh index 4c4b4deb4cf..0002c9d7870 100644 --- a/meta/files/toolchain-shar-extract.sh +++ b/meta/files/toolchain-shar-extract.sh @@ -1,13 +1,7 @@ #!/bin/sh -[ -z "$ENVCLEANED" ] && exec /usr/bin/env -i ENVCLEANED=1 HOME="$HOME" \ - LC_ALL=en_US.UTF-8 \ - TERM=$TERM \ - ICECC_PATH="$ICECC_PATH" \ - http_proxy="$http_proxy" https_proxy="$https_proxy" ftp_proxy="$ftp_proxy" \ - no_proxy="$no_proxy" all_proxy="$all_proxy" GIT_PROXY_COMMAND="$GIT_PROXY_COMMAND" "$0" "$@" -[ -f /etc/environment ] && . /etc/environment -export PATH=`echo "$PATH" | sed -e 's/:\.//' -e 's/::/:/'` +# Remove invalid PATH elements first (maybe from a previously setup toolchain now deleted +PATH=`python3 -c 'import os; print(":".join(e for e in os.environ["PATH"].split(":") if os.path.exists(e)))'` tweakpath () { case ":${PATH}:" in -- 2.25.0 From richard.purdie at linuxfoundation.org Sat Mar 7 15:59:43 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Sat, 07 Mar 2020 15:59:43 +0000 Subject: [OE-core] =?utf-8?q?=E2=9C=97_patchtest=3A_failure_for_groff=3A_M?= =?utf-8?q?ake_manpages_binary_identical?= In-Reply-To: <20200307143223.2277.46482@do> References: <20200307140548.13517-1-jpuhlman@mvista.com> <20200307143223.2277.46482@do> Message-ID: <3d264f5439b9216788b9bdd50996c88dd3cc0b38.camel@linuxfoundation.org> On Sat, 2020-03-07 at 14:32 +0000, Patchwork wrote: > == Series Details == > > Series: groff: Make manpages binary identical > Revision: 1 > URL : https://patchwork.openembedded.org/series/23145/ > 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 Upstream-Status is in incorrect format > [test_upstream_status_presence_format] > Suggested fix Fix Upstream-Status format in 0001-Make-manpages- > mulitlib-identical.patch > Current Upstream-status: Pending > Standard format Upstream-Status: > Valid status Pending, Accepted, Backport, Denied, Inappropriate > [reason], Submitted [where] > I fixed status -> Status and queued in -next. Cheers, Richard From jpuhlman at mvista.com Sat Mar 7 16:01:04 2020 From: jpuhlman at mvista.com (Jeremy A. Puhlman) Date: Sat, 7 Mar 2020 08:01:04 -0800 Subject: [OE-core] =?utf-8?q?=E2=9C=97_patchtest=3A_failure_for_groff=3A_M?= =?utf-8?q?ake_manpages_binary_identical?= In-Reply-To: <3d264f5439b9216788b9bdd50996c88dd3cc0b38.camel@linuxfoundation.org> References: <20200307140548.13517-1-jpuhlman@mvista.com> <20200307143223.2277.46482@do> <3d264f5439b9216788b9bdd50996c88dd3cc0b38.camel@linuxfoundation.org> Message-ID: On 3/7/2020 7:59 AM, Richard Purdie wrote: > On Sat, 2020-03-07 at 14:32 +0000, Patchwork wrote: >> == Series Details == >> >> Series: groff: Make manpages binary identical >> Revision: 1 >> URL : https://patchwork.openembedded.org/series/23145/ >> 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 Upstream-Status is in incorrect format >> [test_upstream_status_presence_format] >> Suggested fix Fix Upstream-Status format in 0001-Make-manpages- >> mulitlib-identical.patch >> Current Upstream-status: Pending >> Standard format Upstream-Status: >> Valid status Pending, Accepted, Backport, Denied, Inappropriate >> [reason], Submitted [where] >> > I fixed status -> Status and queued in -next. Ah sorry about that. I was blind to the case difference. Thank you. > > Cheers, > > Richard > > -- Jeremy A. Puhlman jpuhlman at mvista.com From richard.purdie at linuxfoundation.org Sat Mar 7 16:17:28 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Sat, 07 Mar 2020 16:17:28 +0000 Subject: [OE-core] buildtools-extended-tarball wrapping builds Message-ID: Hi, I just wanted to mention that we now have the ability to wrap builds on specific workers with specific buildtools tarballs. Currently this functionality is in master, we do have the option of porting the helper code to other stable branches. We have had multiple issues, with the infrastucture internal url/cert handling, git/cert environment issues, an issue with eSDK testing (next has a fix in testing), the crypt fix already submitted (meaning M2's tarball doesn't help) and so on, I'm hoping we've gotten to the bottom of those. This does mean we could drop gcc 4.8/4.9 support if we wanted to and rely on the tarball support for centos7/debian8. I'm torn on that, we are still missing: a) Support for wrapping a build with buildtools more auotmatically (like we do with uninative) b) documentation of buildtools-extended-tarball and to drop, we'd probably need these pieces. I'd note the people who vocally said they needed centos7 support are not the ones who are doing this work. The only reason I'm pushing it is I know it will ultimately help support our LTS efforts. Cheers, Richard From richard.purdie at linuxfoundation.org Sat Mar 7 16:20:53 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Sat, 07 Mar 2020 16:20:53 +0000 Subject: [OE-core] [PATCH 0/2] Extensible SDK improvements In-Reply-To: <06f78962af6ad632793a533a22d8f1b91e5a50fc.camel@gmail.com> References: <8718ce405436564b3ad55fa52046e5e55ee562dd.camel@linuxfoundation.org> <06f78962af6ad632793a533a22d8f1b91e5a50fc.camel@gmail.com> Message-ID: <61c89136e75765e8cb188bf16b5fddd7ff28c8b3.camel@linuxfoundation.org> On Sat, 2020-03-07 at 15:55 +0100, Adrian Freihofer wrote: > On Sat, 2020-03-07 at 12:40 +0000, Richard Purdie wrote: > > On Sat, 2020-03-07 at 12:54 +0100, Adrian Freihofer wrote: > > > Hi Richard, > > > > > > We have found two already supported ways to copy variables from > > > the > > > bitbake environment local.conf to the eSDK local.conf > > > > > > If a variable is defined in the local.conf bitbake environment, > > > SDK_LOCAL_CONF_WHITELIST and SDK_LOCAL_CONF_BLACKLIST can be used > > > to > > > add it to the local.conf eSDK file. > > > > > > If a variable should be statically defined for the eSDK but not > > > for > > > the > > > bitbake environment, sdk-extra.conf is useful. > > > > > > Now we would like to add a third way to add variables which are > > > dynamically calculated by bitbake but need to be statically added > > > to > > > the eSDK local.conf. For example we would like to support > > > something > > > like that: > > > > > > def get_version_from_git(d): > > > version = d.getVar("GIT_VERSION", True) > > > if version: > > > return version # runs in eSDK > > > else: > > > return bb.process.run("git... # runs in bitbake > > > > > > GIT_VERSION := "${@get_version_from_git(d)}" > > > > > > SDK_LOCAL_CONF_EXTRALIST_append = " GIT_VERSION" > > > > This worries me a bit since it means the eSDK and the "real" build > > can > > behave differently. I appreciate that can happen even with the > > other > > variables and means of setting them but this takes it to a new > > level. > > > That I understand. The usage of the SDK_LOCAL_CONF_EXTRALIST would be > very specific. Wrong usage would lead to a broken sstate in the eSDK. > > > Ultimately I think we're aiming to have normal builds convert into > > an > > eSDK and vice versa more easily. This seems to pull us further away > > from that :/. > > > > What is the reasoning for having them behaving differently? > > Our goal is to equate the eSDK behavior with the behavior of the real > build, also for the example with the GIT_VERSION, which bitbake and > git > will dynamically evaluate at eSDK build time. > > Suppose we want to compile the GIT_VERSION (last tag) from poky > without > any manual steps into the firmware. bitbake can simply call > > $ describe git --tags --dirty > uninative-2,8-74-g56446f4570-dirty > > With Bitbake the variable can change. But in eSDK the GIT_VERSION > must > be a constant. The above function behaves like a constant if > GIT_VERSION is defined in the local.conf for example. But it has a > dynamic behavior if GIT_VERSION is undefined. The only missing part > in > the current Poky, is a way to automatically write the value to the > local.conf of the eSDK. I don't think this would be much different > than > the already existing sdk-extra.conf file. I've been thinking about this further. Why is any of this in local.conf in the first place? I'd suggest the bulk of it should be in your distro or class files? I understand we do need some simple changes to local.conf in many cases but any complex logic really should not be there. The above does look like more complex logic to me... I'm therefore leaning towards saying no to this patch, its just going to cause us problems in the future. Cheers, Richard From richard.purdie at linuxfoundation.org Sat Mar 7 16:58:49 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Sat, 07 Mar 2020 16:58:49 +0000 Subject: [OE-core] Yocto Project Status WW09'20 In-Reply-To: References: <107c01d5f174$bbf566a0$33e033e0$@gmail.com> Message-ID: On Fri, 2020-03-06 at 22:53 +0100, Alexander Kanavin wrote: > On Wed, 4 Mar 2020 at 23:42, Richard Purdie < > richard.purdie at linuxfoundation.org> wrote: > > Just FYI I think there may also be a couple of other packages > > coreutils > > pulls in and they may also have reproducibility issues (gettext- > > ptest, > > glibc-locale-* and procps*). > > Patch for gettext also sent :) glibc-locale and procps I could not > reproduce :-/ Thanks for that fix, it helps! FWIW, what I'm seeing with glibc-locale is that these files "disappear" from the packages in one of my builds: ./usr/share/locale/vi/LC_MESSAGES/libc.mo ./usr/share/locale/ko/LC_MESSAGES/libc.mo ./usr/share/locale/en_GB/LC_MESSAGES/libc.mo ./usr/share/locale/ca/LC_MESSAGES/libc.mo ./usr/share/locale/fr/LC_MESSAGES/libc.mo ./usr/share/locale/pl/LC_MESSAGES/libc.mo ./usr/share/locale/id/LC_MESSAGES/libc.mo ./usr/share/locale/hr/LC_MESSAGES/libc.mo ./usr/share/locale/uk/LC_MESSAGES/libc.mo ./usr/share/locale/ja/LC_MESSAGES/libc.mo ./usr/share/locale/gl/LC_MESSAGES/libc.mo ./usr/share/locale/es/LC_MESSAGES/libc.mo ./usr/share/locale/el/LC_MESSAGES/libc.mo ./usr/share/locale/pt_BR/LC_MESSAGES/libc.mo ./usr/share/locale/sl/LC_MESSAGES/libc.mo ./usr/share/locale/lt/LC_MESSAGES/libc.mo ./usr/share/locale/rw/LC_MESSAGES/libc.mo ./usr/share/locale/sv/LC_MESSAGES/libc.mo ./usr/share/locale/cs/LC_MESSAGES/libc.mo ./usr/share/locale/nl/LC_MESSAGES/libc.mo ./usr/share/locale/zh_CN/LC_MESSAGES/libc.mo ./usr/share/locale/ia/LC_MESSAGES/libc.mo ./usr/share/locale/fi/LC_MESSAGES/libc.mo ./usr/share/locale/be/LC_MESSAGES/libc.mo ./usr/share/locale/ru/LC_MESSAGES/libc.mo ./usr/share/locale/nb/LC_MESSAGES/libc.mo ./usr/share/locale/zh_TW/LC_MESSAGES/libc.mo ./usr/share/locale/tr/LC_MESSAGES/libc.mo ./usr/share/locale/de/LC_MESSAGES/libc.mo ./usr/share/locale/da/LC_MESSAGES/libc.mo ./usr/share/locale/pt/LC_MESSAGES/libc.mo ./usr/share/locale/hu/LC_MESSAGES/libc.mo ./usr/share/locale/eo/LC_MESSAGES/libc.mo ./usr/share/locale/it/LC_MESSAGES/libc.mo ./usr/share/locale/bg/LC_MESSAGES/libc.mo ./usr/share/locale/sk/LC_MESSAGES/libc.mo I can conform they're not in the glibc stashed-locale sstate object so they disappear somewhere before that in the glibc recipe itself. Quite where/why I don't know as yet. For procps, the timestamps in the output are different, that is the only difference. That means something is indeterminate with the source epoch for that recipe. Again, why, I don't know. The two stamps are: 2019-12-08?04:06:03 2019-12-08?04:05:49 This latter one could potentially be a bug in hashequiv (cc Joshua). It may need that stamps patch I have fixed up to resolve it. The fix it needs is to make it apply only to certain tasks. Cheers, Richard From richard.purdie at linuxfoundation.org Sat Mar 7 17:02:32 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Sat, 07 Mar 2020 17:02:32 +0000 Subject: [OE-core] Yocto Project Status WW09'20 In-Reply-To: References: <107c01d5f174$bbf566a0$33e033e0$@gmail.com> Message-ID: On Sat, 2020-03-07 at 16:58 +0000, Richard Purdie wrote: > On Fri, 2020-03-06 at 22:53 +0100, Alexander Kanavin wrote: > > On Wed, 4 Mar 2020 at 23:42, Richard Purdie < > > richard.purdie at linuxfoundation.org> wrote: > > > Just FYI I think there may also be a couple of other packages > > > coreutils > > > pulls in and they may also have reproducibility issues (gettext- > > > ptest, > > > glibc-locale-* and procps*). > > > > Patch for gettext also sent :) glibc-locale and procps I could not > > reproduce :-/ > > Thanks for that fix, it helps! > > FWIW, what I'm seeing with glibc-locale is that these files > "disappear" > from the packages in one of my builds: > > ./usr/share/locale/vi/LC_MESSAGES/libc.mo > ./usr/share/locale/ko/LC_MESSAGES/libc.mo > ./usr/share/locale/en_GB/LC_MESSAGES/libc.mo > ./usr/share/locale/ca/LC_MESSAGES/libc.mo > ./usr/share/locale/fr/LC_MESSAGES/libc.mo > ./usr/share/locale/pl/LC_MESSAGES/libc.mo > ./usr/share/locale/id/LC_MESSAGES/libc.mo > ./usr/share/locale/hr/LC_MESSAGES/libc.mo > ./usr/share/locale/uk/LC_MESSAGES/libc.mo > ./usr/share/locale/ja/LC_MESSAGES/libc.mo > ./usr/share/locale/gl/LC_MESSAGES/libc.mo > ./usr/share/locale/es/LC_MESSAGES/libc.mo > ./usr/share/locale/el/LC_MESSAGES/libc.mo > ./usr/share/locale/pt_BR/LC_MESSAGES/libc.mo > ./usr/share/locale/sl/LC_MESSAGES/libc.mo > ./usr/share/locale/lt/LC_MESSAGES/libc.mo > ./usr/share/locale/rw/LC_MESSAGES/libc.mo > ./usr/share/locale/sv/LC_MESSAGES/libc.mo > ./usr/share/locale/cs/LC_MESSAGES/libc.mo > ./usr/share/locale/nl/LC_MESSAGES/libc.mo > ./usr/share/locale/zh_CN/LC_MESSAGES/libc.mo > ./usr/share/locale/ia/LC_MESSAGES/libc.mo > ./usr/share/locale/fi/LC_MESSAGES/libc.mo > ./usr/share/locale/be/LC_MESSAGES/libc.mo > ./usr/share/locale/ru/LC_MESSAGES/libc.mo > ./usr/share/locale/nb/LC_MESSAGES/libc.mo > ./usr/share/locale/zh_TW/LC_MESSAGES/libc.mo > ./usr/share/locale/tr/LC_MESSAGES/libc.mo > ./usr/share/locale/de/LC_MESSAGES/libc.mo > ./usr/share/locale/da/LC_MESSAGES/libc.mo > ./usr/share/locale/pt/LC_MESSAGES/libc.mo > ./usr/share/locale/hu/LC_MESSAGES/libc.mo > ./usr/share/locale/eo/LC_MESSAGES/libc.mo > ./usr/share/locale/it/LC_MESSAGES/libc.mo > ./usr/share/locale/bg/LC_MESSAGES/libc.mo > ./usr/share/locale/sk/LC_MESSAGES/libc.mo > > I can conform they're not in the glibc stashed-locale sstate object > so > they disappear somewhere before that in the glibc recipe itself. > > Quite where/why I don't know as yet. Just to save anyone digging, the difference is in configure, one has msgfmt in the sysroot, one does not. It is there later in the build so its probably task dependencies not being right. Cheers, Richard From richard.purdie at linuxfoundation.org Sat Mar 7 18:09:40 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Sat, 07 Mar 2020 18:09:40 +0000 Subject: [OE-core] [PATCH v3] runqemu: support multiple NICs In-Reply-To: <20200307150145.3100113-1-adrian.freihofer@siemens.com> References: <20200307150145.3100113-1-adrian.freihofer@siemens.com> Message-ID: <9f8bb6a3d6cb168c1ec2ddb5e2ff5e5970f5668d.camel@linuxfoundation.org> On Sat, 2020-03-07 at 16:01 +0100, Adrian Freihofer wrote: > Emulating more than one network interface with runqemu is sometimes a > bit tricky, but possible. For example, this leads to an emulated device > with eth0 and eth1: > > QB_NETWORK_DEVICE_prepend = " \ > -device virtio-net-device,mac=52:54:00:12:34:03 \ > " > > Note: > On some emulated NIC types, Qemu and the kernel enumerate the eths in > the guest in reverse order to how the device parameters are passed to > Qemu. So in this case it is important that the additional NICs are > prepended to the -device parameter, which gets automatically added by > Qemu. Otherwise, the interface eth1 will be connected to the host, but > eth0 will be assigned the IP address 192.168.7.x, which obviously does > not work. > > When booting Qemu with two NICs, but only one set of network > configuration parameters gets passed to the kernel, the kernel seems to > search for a configuration for all NICs. This delays the boot process > for a very long time. > > This change solves the timeout problem. Tested with: > oe-selftest --run-tests runqemu This appears to break our automated testing, e.g.: https://autobuilder.yoctoproject.org/typhoon/#/builders/76/builds/1657 (there is a full list of failures on https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/779 but the missing xz ones aren't yours!) Cheers, Richard From christopher.w.clark at gmail.com Sat Mar 7 20:03:30 2020 From: christopher.w.clark at gmail.com (christopher.w.clark at gmail.com) Date: Sat, 7 Mar 2020 12:03:30 -0800 Subject: [OE-core] [PATCH] kernel.bbclass: fix SOURCE_DATE_EPOCH for non-git kernel builds Message-ID: <20200307200330.23915-1-christopher.w.clark@gmail.com> From: Christopher Clark Only use git to set SOURCE_DATE_EPOCH if ${S} is the top level of a git repository. Fixes the following errors with the prior logic when building a kernel that is not obtained from a git repository: 1. With TMPDIR set to a directory outside any git repository on a mounted filesystem, reproducible builds fail in do_compile with this git error: fatal: not a git repository (or any parent up to mount point ) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). aborting before the error handling logic. 2. With TMPDIR located within a subdirectory of a git repository, the SOURCE_DATE_EPOCH timestamp would be that of said repository rather than that of the kernel. Signed-off-by: Christopher Clark --- meta/classes/kernel.bbclass | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass index 0eadd3efb8..2603f24709 100644 --- a/meta/classes/kernel.bbclass +++ b/meta/classes/kernel.bbclass @@ -296,10 +296,14 @@ kernel_do_compile() { if [ "${SOURCE_DATE_EPOCH}" = "" -o "${SOURCE_DATE_EPOCH}" = "0" ]; then olddir=`pwd` cd ${S} - SOURCE_DATE_EPOCH=`git log -1 --pretty=%ct` - # git repo not guaranteed, so fall back to REPRODUCIBLE_TIMESTAMP_ROOTFS - if [ $? -ne 0 ]; then - SOURCE_DATE_EPOCH=${REPRODUCIBLE_TIMESTAMP_ROOTFS} + # This kernel dir is not necessarily a git repo and we + # must ensure that git does not incorrectly query a + # repository in a parent directory. + GIT_TOP=`git rev-parse --show-toplevel 2>/dev/null || echo ""` + if [ "${S}" = "${GIT_TOP}" ]; then + SOURCE_DATE_EPOCH=`git log -1 --pretty=%ct` + else + SOURCE_DATE_EPOCH="${REPRODUCIBLE_TIMESTAMP_ROOTFS}" fi cd $olddir fi -- 2.17.1 From adrian.fiergolski at fastree3d.com Sat Mar 7 22:07:05 2020 From: adrian.fiergolski at fastree3d.com (Adrian Fiergolski) Date: Sat, 7 Mar 2020 23:07:05 +0100 Subject: [OE-core] [opencv] debugging Message-ID: <79087be9-c34e-8e27-5b0f-e7b21d03f89f@fastree3d.com> Hi, I would like to build /opencv/ with debug symbols and with possible minimum optimization (I need to debug it). In the /opencv/ recipe I haven't found any PACKAGECONFIG related to debugging. I have tried to add /EXTRA_OECMAKE_append = " -DCMAKE_BUILD_TYPE=Debug" / in the recipe but it gives the error: ninja: error: 'TBB_ENV_LIB_DEBUG-NOTFOUND', needed by 'lib/libopencv_core.so.4.1.0', missing and no known rule to make it Has anyone tried to build /opencv/ in debug mode and could share how it was achieved? Regards, Adrian Fiergolski -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.kiernan at gmail.com Sat Mar 7 22:34:07 2020 From: alex.kiernan at gmail.com (Alex Kiernan) Date: Sat, 7 Mar 2020 22:34:07 +0000 Subject: [OE-core] [PATCH] kernel.bbclass: fix SOURCE_DATE_EPOCH for non-git kernel builds In-Reply-To: <20200307200330.23915-1-christopher.w.clark@gmail.com> References: <20200307200330.23915-1-christopher.w.clark@gmail.com> Message-ID: On Sat, Mar 7, 2020 at 8:04 PM wrote: > > From: Christopher Clark > > Only use git to set SOURCE_DATE_EPOCH if ${S} is the top level of a git > repository. > > Fixes the following errors with the prior logic when building a kernel > that is not obtained from a git repository: > > 1. With TMPDIR set to a directory outside any git repository on a > mounted filesystem, reproducible builds fail in do_compile with this git > error: > > fatal: not a git repository (or any parent up to mount point ) > Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). > > aborting before the error handling logic. > > 2. With TMPDIR located within a subdirectory of a git repository, the > SOURCE_DATE_EPOCH timestamp would be that of said repository rather than > that of the kernel. > > Signed-off-by: Christopher Clark > --- > meta/classes/kernel.bbclass | 12 ++++++++---- > 1 file changed, 8 insertions(+), 4 deletions(-) > > diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass > index 0eadd3efb8..2603f24709 100644 > --- a/meta/classes/kernel.bbclass > +++ b/meta/classes/kernel.bbclass > @@ -296,10 +296,14 @@ kernel_do_compile() { > if [ "${SOURCE_DATE_EPOCH}" = "" -o "${SOURCE_DATE_EPOCH}" = "0" ]; then > olddir=`pwd` > cd ${S} > - SOURCE_DATE_EPOCH=`git log -1 --pretty=%ct` > - # git repo not guaranteed, so fall back to REPRODUCIBLE_TIMESTAMP_ROOTFS > - if [ $? -ne 0 ]; then > - SOURCE_DATE_EPOCH=${REPRODUCIBLE_TIMESTAMP_ROOTFS} > + # This kernel dir is not necessarily a git repo and we > + # must ensure that git does not incorrectly query a > + # repository in a parent directory. > + GIT_TOP=`git rev-parse --show-toplevel 2>/dev/null || echo ""` > + if [ "${S}" = "${GIT_TOP}" ]; then Will that work if ${S} isn't a canonical path? > + SOURCE_DATE_EPOCH=`git log -1 --pretty=%ct` > + else > + SOURCE_DATE_EPOCH="${REPRODUCIBLE_TIMESTAMP_ROOTFS}" > fi > cd $olddir > fi Would something like this resolve the problem (untested): diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass index 0eadd3efb8d9..a17ca7adccca 100644 --- a/meta/classes/kernel.bbclass +++ b/meta/classes/kernel.bbclass @@ -294,14 +294,11 @@ kernel_do_compile() { # kernel sources do not use do_unpack, so SOURCE_DATE_EPOCH may not # be set.... if [ "${SOURCE_DATE_EPOCH}" = "" -o "${SOURCE_DATE_EPOCH}" = "0" ]; then - olddir=`pwd` - cd ${S} - SOURCE_DATE_EPOCH=`git log -1 --pretty=%ct` + SOURCE_DATE_EPOCH=`git --git-dir="${S}/.git}" log -1 --pretty=%ct` # git repo not guaranteed, so fall back to REPRODUCIBLE_TIMESTAMP_ROOTFS if [ $? -ne 0 ]; then SOURCE_DATE_EPOCH=${REPRODUCIBLE_TIMESTAMP_ROOTFS} fi - cd $olddir fi ts=`LC_ALL=C date -d @$SOURCE_DATE_EPOCH` -- Alex Kiernan From richard.purdie at linuxfoundation.org Sat Mar 7 22:37:47 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Sat, 7 Mar 2020 22:37:47 +0000 Subject: [OE-core] [PATCH 1/2] glibc: Explicitly disable msgfmt Message-ID: <20200307223748.1178851-1-richard.purdie@linuxfoundation.org> If configure is rerun it finds msgfmt from gettext-native which is installed during package_write_ipk|deb and means builds are not determinisic. Whether msgfmt is needed is debatable (libc.mo files arne't generated without it) however we should at least be consistent which this patch ensures. Signed-off-by: Richard Purdie --- meta/recipes-core/glibc/glibc.inc | 3 +++ 1 file changed, 3 insertions(+) diff --git a/meta/recipes-core/glibc/glibc.inc b/meta/recipes-core/glibc/glibc.inc index 58d2ba7bc44..23a6ca99ae0 100644 --- a/meta/recipes-core/glibc/glibc.inc +++ b/meta/recipes-core/glibc/glibc.inc @@ -9,8 +9,11 @@ inherit autotools texinfo features_check systemd LEAD_SONAME = "libc.so" +# msgfmt could come from gettext-native but we don't depend on that and +# disable for reproducibility CACHED_CONFIGUREVARS += " \ ac_cv_path_BASH_SHELL=${base_bindir}/bash \ + ac_cv_prog_MSGFMT= \ libc_cv_slibdir=${base_libdir} \ libc_cv_rootsbindir=${base_sbindir} \ libc_cv_localedir=${localedir} \ -- 2.25.0 From richard.purdie at linuxfoundation.org Sat Mar 7 22:37:48 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Sat, 7 Mar 2020 22:37:48 +0000 Subject: [OE-core] [PATCH 2/2] reproducibile_build: Fix SDE file generation when unpack reruns In-Reply-To: <20200307223748.1178851-1-richard.purdie@linuxfoundation.org> References: <20200307223748.1178851-1-richard.purdie@linuxfoundation.org> Message-ID: <20200307223748.1178851-2-richard.purdie@linuxfoundation.org> Currently, if an existing TMPDIR is rebuilt, do_fetch/do_unpack can rerun but SDE would remain unchanged. This leads to different results compared to a fresh build. An example change which triggered this is: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=cb4e69e6346a9fbeebf83a5d5397cacbd41d48b5 Instead, delete any existing SDE and recalculate if we're reunning. Also rename and drop the do_ prefix since these are for tasks, not functions. Signed-off-by: Richard Purdie --- meta/classes/reproducible_build.bbclass | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/meta/classes/reproducible_build.bbclass b/meta/classes/reproducible_build.bbclass index 750eb950f28..8da40f656ac 100644 --- a/meta/classes/reproducible_build.bbclass +++ b/meta/classes/reproducible_build.bbclass @@ -150,11 +150,12 @@ def fixed_source_date_epoch(): bb.debug(1, "No tarball or git repo found to determine SOURCE_DATE_EPOCH") return 0 -python do_create_source_date_epoch_stamp() { +python create_source_date_epoch_stamp() { epochfile = d.getVar('SDE_FILE') + # If it exists we need to regenerate as the sources may have changed if os.path.isfile(epochfile): - bb.debug(1, "Reusing SOURCE_DATE_EPOCH from: %s" % epochfile) - return + bb.debug(1, "Deleting existing SOURCE_DATE_EPOCH from: %s" % epochfile) + os.remove(epochfile) sourcedir = d.getVar('S') source_date_epoch = ( @@ -197,5 +198,5 @@ BB_HASHBASE_WHITELIST += "SOURCE_DATE_EPOCH" python () { if d.getVar('BUILD_REPRODUCIBLE_BINARIES') == '1': - d.appendVarFlag("do_unpack", "postfuncs", " do_create_source_date_epoch_stamp") + d.appendVarFlag("do_unpack", "postfuncs", " create_source_date_epoch_stamp") } -- 2.25.0 From peter.kjellerstedt at axis.com Sun Mar 8 02:40:24 2020 From: peter.kjellerstedt at axis.com (Peter Kjellerstedt) Date: Sun, 8 Mar 2020 02:40:24 +0000 Subject: [OE-core] [PATCH 1/2] glibc: Explicitly disable msgfmt In-Reply-To: <20200307223748.1178851-1-richard.purdie@linuxfoundation.org> References: <20200307223748.1178851-1-richard.purdie@linuxfoundation.org> Message-ID: > -----Original Message----- > From: openembedded-core-bounces at lists.openembedded.org bounces at lists.openembedded.org> On Behalf Of Richard Purdie > Sent: den 7 mars 2020 23:38 > To: openembedded-core at lists.openembedded.org > Subject: [OE-core] [PATCH 1/2] glibc: Explicitly disable msgfmt > > If configure is rerun it finds msgfmt from gettext-native which is installed > during package_write_ipk|deb and means builds are not determinisic. > > Whether msgfmt is needed is debatable (libc.mo files arne't generated without arne't -> aren't > it) however we should at least be consistent which this patch ensures. Add a period and two commas: it). However, we should at least be consistent, which this patch ensures. > > Signed-off-by: Richard Purdie > --- > meta/recipes-core/glibc/glibc.inc | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/meta/recipes-core/glibc/glibc.inc b/meta/recipes- > core/glibc/glibc.inc > index 58d2ba7bc44..23a6ca99ae0 100644 > --- a/meta/recipes-core/glibc/glibc.inc > +++ b/meta/recipes-core/glibc/glibc.inc > @@ -9,8 +9,11 @@ inherit autotools texinfo features_check systemd > > LEAD_SONAME = "libc.so" > > +# msgfmt could come from gettext-native but we don't depend on that and > +# disable for reproducibility > CACHED_CONFIGUREVARS += " \ > ac_cv_path_BASH_SHELL=${base_bindir}/bash \ > + ac_cv_prog_MSGFMT= \ > libc_cv_slibdir=${base_libdir} \ > libc_cv_rootsbindir=${base_sbindir} \ > libc_cv_localedir=${localedir} \ > -- > 2.25.0 //Peter From raj.khem at gmail.com Sun Mar 8 04:17:44 2020 From: raj.khem at gmail.com (Khem Raj) Date: Sat, 7 Mar 2020 20:17:44 -0800 Subject: [OE-core] [PATCH 1/2] glibc: Explicitly disable msgfmt In-Reply-To: <20200307223748.1178851-1-richard.purdie@linuxfoundation.org> References: <20200307223748.1178851-1-richard.purdie@linuxfoundation.org> Message-ID: On Sat, Mar 7, 2020 at 2:37 PM Richard Purdie wrote: > > If configure is rerun it finds msgfmt from gettext-native which is installed > during package_write_ipk|deb and means builds are not determinisic. > > Whether msgfmt is needed is debatable (libc.mo files arne't generated without > it) however we should at least be consistent which this patch ensures. > I think we could turn it into a packageconfig and add depending on gettext-native in knob, keep the knob disabled by default. While dont think translation files will be commonly installed on systems OE targets but its seems limiting if we simply disable it. > Signed-off-by: Richard Purdie > --- > meta/recipes-core/glibc/glibc.inc | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/meta/recipes-core/glibc/glibc.inc b/meta/recipes-core/glibc/glibc.inc > index 58d2ba7bc44..23a6ca99ae0 100644 > --- a/meta/recipes-core/glibc/glibc.inc > +++ b/meta/recipes-core/glibc/glibc.inc > @@ -9,8 +9,11 @@ inherit autotools texinfo features_check systemd > > LEAD_SONAME = "libc.so" > > +# msgfmt could come from gettext-native but we don't depend on that and > +# disable for reproducibility > CACHED_CONFIGUREVARS += " \ > ac_cv_path_BASH_SHELL=${base_bindir}/bash \ > + ac_cv_prog_MSGFMT= \ > libc_cv_slibdir=${base_libdir} \ > libc_cv_rootsbindir=${base_sbindir} \ > libc_cv_localedir=${localedir} \ > -- > 2.25.0 > > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core at lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core From richard.purdie at linuxfoundation.org Sun Mar 8 08:14:40 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Sun, 08 Mar 2020 08:14:40 +0000 Subject: [OE-core] M3 build status In-Reply-To: References: Message-ID: On Mon, 2020-03-02 at 16:47 +0000, Richard Purdie wrote: > On Sat, 2020-02-29 at 07:38 -0800, akuster808 wrote: > > > > * coreutils ptest addition (blocked on libmodule-build-per > > > reproducibility issue) > > Still not done. This is now closer. Alex fixed the libmodule-build-perl and gettext reproducibility issues (thanks!), I tracked down a glibc issue and procps one I saw locally. On a fresh autobuilder run we saw: https://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20200307-mk0v6ljq/packages/diff-html/ and https://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20200307-5pvgdd3a/packages/diff-html/ which I believe is the remaining blocking issue on coreutils-ptest. > > > * psplash systemd race (smurray may have a fix) > > Still not done. Now done. > > > * LockedSigs intermittent test failure (RP has open high bug, no > > > clue > > > how to reproduce or why, total mystery) > > Spent hours on this, limited success :( Turned out to be a logging issue, hopefully fixed. > > > > * Intermittent selftest failure with SystemExit (High open bug, > > > Kai owns) > > Still pending. Still pending. There are also other intermittent Medium+ selftest bugs we're seeing now the source of major failures has been addressed. > > > As ever, help with any of these welcome. We'll build M3 when a > > > majority of the above are ready. > > Also, I've realised: > * there is a high priority pseudo issue assigned to me Not done. > * gcc buildtools tarball issue Moved forwards. The tarball breaks eSDK testing and my fix didn't work. There is an open question of whether we want to automate use of this or not and whether we support Centos7 for the LTS with or without the tarball. > + the bind issue you mention We've established we can't take that. This puts us closer to the M3 build but probably not quite there yet. Cheers, Richard From richard.purdie at linuxfoundation.org Sun Mar 8 08:18:20 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Sun, 08 Mar 2020 08:18:20 +0000 Subject: [OE-core] [PATCH 1/2] glibc: Explicitly disable msgfmt In-Reply-To: References: <20200307223748.1178851-1-richard.purdie@linuxfoundation.org> Message-ID: On Sat, 2020-03-07 at 20:17 -0800, Khem Raj wrote: > On Sat, Mar 7, 2020 at 2:37 PM Richard Purdie > wrote: > > If configure is rerun it finds msgfmt from gettext-native which is > > installed > > during package_write_ipk|deb and means builds are not determinisic. > > > > Whether msgfmt is needed is debatable (libc.mo files arne't > > generated without > > it) however we should at least be consistent which this patch > > ensures. > > > > I think we could turn it into a packageconfig and add depending on > gettext-native in knob, keep the knob disabled by default. While > dont think translation files will be commonly installed on systems OE > targets but its seems limiting if we simply disable it. Keep in mind that currently in any build from scratch it is disabled. This patch doesn't regress anything, it just ensures builds are reproducible. I agree if anyone wants it, we can add a PACKAGECONFIG. Cheers, Richard From adrian.freihofer at gmail.com Sun Mar 8 08:47:34 2020 From: adrian.freihofer at gmail.com (Adrian Freihofer) Date: Sun, 08 Mar 2020 09:47:34 +0100 Subject: [OE-core] [PATCH 0/2] Extensible SDK improvements In-Reply-To: <61c89136e75765e8cb188bf16b5fddd7ff28c8b3.camel@linuxfoundation.org> References: <8718ce405436564b3ad55fa52046e5e55ee562dd.camel@linuxfoundation.org> <06f78962af6ad632793a533a22d8f1b91e5a50fc.camel@gmail.com> <61c89136e75765e8cb188bf16b5fddd7ff28c8b3.camel@linuxfoundation.org> Message-ID: <36f700e8bdf668d7e727a3b3afdfde2cdd1b1808.camel@gmail.com> Hi Richard, We are going to handle that in our own layer. That's fine. Thank you for the timely clarification anyway. Regards, Adrian On Sat, 2020-03-07 at 16:20 +0000, Richard Purdie wrote: > On Sat, 2020-03-07 at 15:55 +0100, Adrian Freihofer wrote: > > On Sat, 2020-03-07 at 12:40 +0000, Richard Purdie wrote: > > > On Sat, 2020-03-07 at 12:54 +0100, Adrian Freihofer wrote: > > > > Hi Richard, > > > > > > > > We have found two already supported ways to copy variables from > > > > the > > > > bitbake environment local.conf to the eSDK local.conf > > > > > > > > If a variable is defined in the local.conf bitbake environment, > > > > SDK_LOCAL_CONF_WHITELIST and SDK_LOCAL_CONF_BLACKLIST can be used > > > > to > > > > add it to the local.conf eSDK file. > > > > > > > > If a variable should be statically defined for the eSDK but not > > > > for > > > > the > > > > bitbake environment, sdk-extra.conf is useful. > > > > > > > > Now we would like to add a third way to add variables which are > > > > dynamically calculated by bitbake but need to be statically added > > > > to > > > > the eSDK local.conf. For example we would like to support > > > > something > > > > like that: > > > > > > > > def get_version_from_git(d): > > > > version = d.getVar("GIT_VERSION", True) > > > > if version: > > > > return version # runs in eSDK > > > > else: > > > > return bb.process.run("git... # runs in bitbake > > > > > > > > GIT_VERSION := "${@get_version_from_git(d)}" > > > > > > > > SDK_LOCAL_CONF_EXTRALIST_append = " GIT_VERSION" > > > > > > This worries me a bit since it means the eSDK and the "real" build > > > can > > > behave differently. I appreciate that can happen even with the > > > other > > > variables and means of setting them but this takes it to a new > > > level. > > > > > That I understand. The usage of the SDK_LOCAL_CONF_EXTRALIST would be > > very specific. Wrong usage would lead to a broken sstate in the eSDK. > > > > > Ultimately I think we're aiming to have normal builds convert into > > > an > > > eSDK and vice versa more easily. This seems to pull us further away > > > from that :/. > > > > > > What is the reasoning for having them behaving differently? > > > > Our goal is to equate the eSDK behavior with the behavior of the real > > build, also for the example with the GIT_VERSION, which bitbake and > > git > > will dynamically evaluate at eSDK build time. > > > > Suppose we want to compile the GIT_VERSION (last tag) from poky > > without > > any manual steps into the firmware. bitbake can simply call > > > > $ describe git --tags --dirty > > uninative-2,8-74-g56446f4570-dirty > > > > With Bitbake the variable can change. But in eSDK the GIT_VERSION > > must > > be a constant. The above function behaves like a constant if > > GIT_VERSION is defined in the local.conf for example. But it has a > > dynamic behavior if GIT_VERSION is undefined. The only missing part > > in > > the current Poky, is a way to automatically write the value to the > > local.conf of the eSDK. I don't think this would be much different > > than > > the already existing sdk-extra.conf file. > > I've been thinking about this further. Why is any of this in local.conf > in the first place? > > I'd suggest the bulk of it should be in your distro or class files? > > I understand we do need some simple changes to local.conf in many cases > but any complex logic really should not be there. The above does look > like more complex logic to me... > > I'm therefore leaning towards saying no to this patch, its just going > to cause us problems in the future. > > Cheers, > > Richard > > > From bunk at stusta.de Sun Mar 8 12:22:20 2020 From: bunk at stusta.de (Adrian Bunk) Date: Sun, 8 Mar 2020 14:22:20 +0200 Subject: [OE-core] [PATCH] cve-check: show whitelisted status In-Reply-To: <1583461646-73057-1-git-send-email-chee.yang.lee@intel.com> References: <1583461646-73057-1-git-send-email-chee.yang.lee@intel.com> Message-ID: <20200308122220.GA29115@localhost> On Fri, Mar 06, 2020 at 10:27:26AM +0800, chee.yang.lee at intel.com wrote: > From: Chee Yang Lee > > change whitelisted CVE status from "Patched" to "Whitelisted". >... Thanks a lot for working on this. >... > index 7412436..7f98da6 100644 > --- a/meta/classes/cve-check.bbclass > +++ b/meta/classes/cve-check.bbclass > @@ -56,10 +56,10 @@ python do_cve_check () { > patched_cves = get_patches_cves(d) > except FileNotFoundError: > bb.fatal("Failure in searching patches") > - patched, unpatched = check_cves(d, patched_cves) > + whitelisted, patched, unpatched = check_cves(d, patched_cves) >... Unfortunately this doesn't work: $ . oe-init-build-env $ echo 'INHERIT += "cve-check"' >> conf/local.conf $ bitbake core-image-minimal ... ERROR: glibc-locale-2.31-r0 do_cve_check: Error executing a python function in exec_python_func() autogenerated: The stack trace of python calls that resulted in this exception/failure was: File: 'exec_python_func() autogenerated', lineno: 2, function: 0001: *** 0002:do_cve_check(d) 0003: File: '/tmp/poky/meta/classes/cve-check.bbclass', lineno: 59, function: do_cve_check 0055: try: 0056: patched_cves = get_patches_cves(d) 0057: except FileNotFoundError: 0058: bb.fatal("Failure in searching patches") *** 0059: whitelisted, patched, unpatched = check_cves(d, patched_cves) 0060: if patched or unpatched: 0061: cve_data = get_cve_info(d, patched + unpatched) 0062: cve_write_data(d, patched, unpatched, whitelisted, cve_data) 0063: else: Exception: ValueError: not enough values to unpack (expected 3, got 2) ERROR: Logfile of failure stored in: /tmp/poky/build/tmp/work/core2-64-poky-linux/glibc-locale/2.31-r0/temp/log.do_cve_check.3713 ERROR: Task (/tmp/poky/meta/recipes-core/glibc/glibc-locale_2.31.bb:do_cve_check) failed with exit code '1' cu Adrian From alex.kanavin at gmail.com Sun Mar 8 13:08:38 2020 From: alex.kanavin at gmail.com (Alexander Kanavin) Date: Sun, 8 Mar 2020 14:08:38 +0100 Subject: [OE-core] M3 build status In-Reply-To: References: Message-ID: On Sun, 8 Mar 2020 at 09:15, Richard Purdie < richard.purdie at linuxfoundation.org> wrote: > This is now closer. Alex fixed the libmodule-build-perl and gettext > reproducibility issues (thanks!), I tracked down a glibc issue and > procps one I saw locally. On a fresh autobuilder run we saw: > > > https://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20200307-mk0v6ljq/packages/diff-html/ > and > > https://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20200307-5pvgdd3a/packages/diff-html/ > > which I believe is the remaining blocking issue on coreutils-ptest. > Not quite. The coreutils-ptest itself seems to persistently fail here: AssertionError: Failed ptests: {'coreutils': ['tests/tail-2/assert.sh']} so I'd like to have that fixed before it goes in. We have a 100% ptest pass rate now (except for random timing fluctuations), which I don't want to see regressed :) Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard.purdie at linuxfoundation.org Sun Mar 8 13:18:18 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Sun, 08 Mar 2020 13:18:18 +0000 Subject: [OE-core] M3 build status In-Reply-To: References: Message-ID: <07697e4e61eec35dc6ca42fd7c0b6694aca036c4.camel@linuxfoundation.org> On Sun, 2020-03-08 at 14:08 +0100, Alexander Kanavin wrote: > On Sun, 8 Mar 2020 at 09:15, Richard Purdie < > richard.purdie at linuxfoundation.org> wrote: > > This is now closer. Alex fixed the libmodule-build-perl and gettext > > reproducibility issues (thanks!), I tracked down a glibc issue and > > procps one I saw locally. On a fresh autobuilder run we saw: > > > > https://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20200307-mk0v6ljq/packages/diff-html/ > > and > > https://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20200307-5pvgdd3a/packages/diff-html/ > > > > which I believe is the remaining blocking issue on coreutils-ptest. > > Not quite. The coreutils-ptest itself seems to persistently fail > here: > > AssertionError: Failed ptests: > {'coreutils': ['tests/tail-2/assert.sh']} > > so I'd like to have that fixed before it goes in. We have a 100% > ptest pass rate now (except for random timing fluctuations), which I > don't want to see regressed :) I agree that would be nice and something we need to do before release, I may let us sort that one test in M4 to enable the M3 build, I have to take a pragmatic approach to this. That said, there is a more pressing issue: https://autobuilder.yoctoproject.org/typhoon/#/builders/44/builds/1686 which is somehow seemingly related to the coreutils change, I just can't see how as yet :/ (as well as the gcc-plugin reproducibility issues) Cheers, Richard From richard.purdie at linuxfoundation.org Sun Mar 8 14:34:42 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Sun, 08 Mar 2020 14:34:42 +0000 Subject: [OE-core] M3 build status In-Reply-To: <07697e4e61eec35dc6ca42fd7c0b6694aca036c4.camel@linuxfoundation.org> References: <07697e4e61eec35dc6ca42fd7c0b6694aca036c4.camel@linuxfoundation.org> Message-ID: On Sun, 2020-03-08 at 13:18 +0000, Richard Purdie wrote: > On Sun, 2020-03-08 at 14:08 +0100, Alexander Kanavin wrote: > > On Sun, 8 Mar 2020 at 09:15, Richard Purdie < > > richard.purdie at linuxfoundation.org> wrote: > > > This is now closer. Alex fixed the libmodule-build-perl and > > > gettext > > > reproducibility issues (thanks!), I tracked down a glibc issue > > > and > > > procps one I saw locally. On a fresh autobuilder run we saw: > > > > > > https://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20200307-mk0v6ljq/packages/diff-html/ > > > and > > > https://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20200307-5pvgdd3a/packages/diff-html/ > > > > > > which I believe is the remaining blocking issue on coreutils- > > > ptest. > > > > Not quite. The coreutils-ptest itself seems to persistently fail > > here: > > > > AssertionError: Failed ptests: > > {'coreutils': ['tests/tail-2/assert.sh']} > > > > so I'd like to have that fixed before it goes in. We have a 100% > > ptest pass rate now (except for random timing fluctuations), which > > I > > don't want to see regressed :) > > I agree that would be nice and something we need to do before > release, > I may let us sort that one test in M4 to enable the M3 build, I have > to > take a pragmatic approach to this. > > That said, there is a more pressing issue: > > https://autobuilder.yoctoproject.org/typhoon/#/builders/44/builds/1686 > > which is somehow seemingly related to the coreutils change, I just > can't see how as yet :/ > > (as well as the gcc-plugin reproducibility issues) Caused by the new libmodule-build-perl which depends upon build- essential and hence gcc which isn't target multilib 'safe'. If we could stop the -ptest package dependencies leaking to -dev we'd avoid this. Cheers, Richard From trevor.gamblin at windriver.com Sun Mar 8 15:47:42 2020 From: trevor.gamblin at windriver.com (Trevor Gamblin) Date: Sun, 8 Mar 2020 11:47:42 -0400 Subject: [OE-core] M3 build status In-Reply-To: References: <07697e4e61eec35dc6ca42fd7c0b6694aca036c4.camel@linuxfoundation.org> Message-ID: On 3/8/20 10:34 AM, Richard Purdie wrote: > On Sun, 2020-03-08 at 13:18 +0000, Richard Purdie wrote: >> On Sun, 2020-03-08 at 14:08 +0100, Alexander Kanavin wrote: >>> On Sun, 8 Mar 2020 at 09:15, Richard Purdie < >>> richard.purdie at linuxfoundation.org> wrote: >>>> This is now closer. Alex fixed the libmodule-build-perl and >>>> gettext >>>> reproducibility issues (thanks!), I tracked down a glibc issue >>>> and >>>> procps one I saw locally. On a fresh autobuilder run we saw: >>>> >>>> https://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20200307-mk0v6ljq/packages/diff-html/ >>>> and >>>> https://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20200307-5pvgdd3a/packages/diff-html/ >>>> >>>> which I believe is the remaining blocking issue on coreutils- >>>> ptest. >>> Not quite. The coreutils-ptest itself seems to persistently fail >>> here: >>> >>> AssertionError: Failed ptests: >>> {'coreutils': ['tests/tail-2/assert.sh']} >>> >>> so I'd like to have that fixed before it goes in. We have a 100% >>> ptest pass rate now (except for random timing fluctuations), which >>> I >>> don't want to see regressed :) >> I agree that would be nice and something we need to do before >> release, >> I may let us sort that one test in M4 to enable the M3 build, I have >> to >> take a pragmatic approach to this. >> >> That said, there is a more pressing issue: >> >> https://autobuilder.yoctoproject.org/typhoon/#/builders/44/builds/1686 >> >> which is somehow seemingly related to the coreutils change, I just >> can't see how as yet :/ >> >> (as well as the gcc-plugin reproducibility issues) > Caused by the new libmodule-build-perl which depends upon build- > essential and hence gcc which isn't target multilib 'safe'. coreutils is fighting hard to avoid getting a ptest! I'll have a look at these issues first thing tomorrow. > > If we could stop the -ptest package dependencies leaking to -dev we'd > avoid this. > > Cheers, > > Richard > > From akuster808 at gmail.com Sun Mar 8 18:13:13 2020 From: akuster808 at gmail.com (akuster808) Date: Sun, 8 Mar 2020 11:13:13 -0700 Subject: [OE-core] Stable life cycle status Message-ID: Hello, Thud has moved to "Community supported" today. The older releases have moved to EOL as no one has stepped up to take on the maintenance of those older branches. regards, Armin From bunk at stusta.de Sun Mar 8 21:46:10 2020 From: bunk at stusta.de (Adrian Bunk) Date: Sun, 8 Mar 2020 23:46:10 +0200 Subject: [OE-core] [Openembedded-architecture] Does YP provide security support for stable and LTS branches? In-Reply-To: <877e317932176664bc7b0120439c56d4dda791af.camel@linuxfoundation.org> References: <20200304090507.GA7923@localhost> <20200304113217.GB7923@localhost> <20200304140109.GC7923@localhost> <20200304172415.GA29456@localhost> <01b3bb37-f65f-8048-1a27-b859b62d7f98@gmail.com> <20200306100422.GA17785@localhost> <877e317932176664bc7b0120439c56d4dda791af.camel@linuxfoundation.org> Message-ID: <20200308214610.GB1425@localhost> On Fri, Mar 06, 2020 at 10:36:59AM +0000, Richard Purdie wrote: > On Fri, 2020-03-06 at 12:04 +0200, Adrian Bunk wrote: > > For most community companies there is no clear Return on Investment > > if they would use the opportunity to invest in upstream involvement. > > That isn't true. If you fix something yourself and hold the change you > get to maintain it. If you work with upstream you can share the > maintenance burden with the community going forward. That is a direct > ROI, there are also more indirect benefits. I was responding to Armin talking about the build swat team. It is hard to see the ROI for a community company when participating in something like that. Upstreaming of own local changes is a different story. >... > Today, our stable branch maintenance is done "ad-hoc" by volunteers. > I/we can't ask them to do anything in any given time frame, its a best > effort. I *hugely* appreciate what those people do but it has its > limitations. On developer lists the message is always "we are short on resources, please help". Which reaches the few people already involved in development. The message to users is that everything is fine and what new things Yocto is additionally offering. No regular user of Wikipedia would miss the regular fundraising where the project needs/wants money. >... > > The wording is "releases move to community support, which means they > > only receive occasional patches for critical defects and updates, > > and no regular defect fixes and security updates". > > > > When the move to community support means no regular security updates, > > this is a clear claim from YP that before the move there are regular > > security updates. > > I think you're being rather pedantic here and I'd suggest we go back to > what the essence of this announcement is. The essence for me is that a few days after I am told on the developer list that 'track and fix CVEs' for stable releases is on users, YP makes an announcement that is worded to make users believe the opposite. I am getting attacks like being accused of making "toxic accusations" for stating the fact that millions of devices being put at risk by YP misrepresenting the status of security support to users who are building products based on Yocto. It is on YP to make it clear to users whether or not Yocto comes with the same set of security guarantees as distributions like Ubuntu or Debian. If it is the duty of every user of Yocto to track and fix CVEs, then this has to be stated clearly instead of implying the opposite. This gives users the opportunity to mitigate, instead of unknowingly shipping insecure products. E.g. embedded products based on Ubuntu with its security support from Linux Foundation member Canonical are clearly better than embedded products based on any distribution without similar security support. And while you are downloading an Ubuntu image from their website you are on a "Contribute with PayPal" page. >... > > If YP does not want to be responsible for insecure millions of > > devices, it is up to YP to not make incorrect claims and make it > > clear in announcements and user documentation if security support is > > not provided by YP. > > I think the definition of "security support" is arguable to be > different things but the intent of what we're trying to do here is > clear. No, the person will not write the patches, the intent is to > coordinate the maintenance of the branch. If there are huge security > holes I would at least expect they can highlight the issues and then > coordinate any help in fixing them. That in itself is a level of > security support btw. This is a bit of a strawman, the problem is elsewhere. Vulnerabilities are rarely OE/Yocto-specific, in practice security support means applying the same patches that other distributions are also applying. When a security advisory will be published for Ubuntu 20.04 LTS there will be a patch available for usually approximately the same version of this software as is in Yocto 3.1 LTS. Going back to where this discussion started: If YP gives the impression that stable and LTS series are security supported by YP, then it is a problem when a crypto library like nss is not getting any security fixes in Yocto 2.7. Debian stable ships the same upstream version and applied fixes for 5 CVEs last year. In practice security support means integrating these existing patches. And providing security support means that there is a person resposible for integrating such existing patches from elsewhere. >... > Its incredibly hard to find funding to try and then organise what we're > trying to do, it would be nice if you could try and help us support in > doing so. >... Do you have constructive suggestions how people can help with funding who do not have access to money sources that could contribute 6 digit amounts to upstream Yocto? Any support I could provide or might be able to organize would be 4 digits per year, and I am not aware of any existing way to pool such contributions easily for paying people for upstream YP work. The best I could offer would be that I open a company that sends invoices for small contributions and pays people from that money. Which sounds like a clear non-starter for financing YP stable/LTS branch maintainance - this would likely have to be organized through the LF. I might have use for continued warrior maintainance and might volunteer as community maintainer for that after the 12 months, but this doesn't generate funding for YP. It is really hard to help you find funding when you are offering opportunities to fund YP only for big companies with huge budgets, but aren't offering any opportunity to give a 1k contribution to YP. I fully understand that improving on that would be difficult, but this is a reason why most businesses are not able to help you even if they want to. > Cheers, > > Richard cu Adrian From alex.kanavin at gmail.com Sun Mar 8 22:08:08 2020 From: alex.kanavin at gmail.com (Alexander Kanavin) Date: Sun, 8 Mar 2020 23:08:08 +0100 Subject: [OE-core] [Openembedded-architecture] Does YP provide security support for stable and LTS branches? In-Reply-To: <20200308214610.GB1425@localhost> References: <20200304090507.GA7923@localhost> <20200304113217.GB7923@localhost> <20200304140109.GC7923@localhost> <20200304172415.GA29456@localhost> <01b3bb37-f65f-8048-1a27-b859b62d7f98@gmail.com> <20200306100422.GA17785@localhost> <877e317932176664bc7b0120439c56d4dda791af.camel@linuxfoundation.org> <20200308214610.GB1425@localhost> Message-ID: On Sun, 8 Mar 2020 at 22:46, Adrian Bunk wrote: > It is on YP to make it clear to users whether or not Yocto comes with > the same set of security guarantees as distributions like Ubuntu or > Debian. > If it is the duty of every user of Yocto to track and fix CVEs, > then this has to be stated clearly instead of implying the opposite. > This gives users the opportunity to mitigate, instead of unknowingly > shipping insecure products. > Do you have any actual evidence for actual users shipping insecure products because they mistakenly believe Yocto takes care of security for them? This has been the situation from the start of the project, certainly this was the case 5 years ago when I joined it, and the only person ever to make an issue out of it is you. Everyone else seems to understand the deal they're getting by using Yocto without a commercial support contract. Yes, there are millions of insecure yocto-based devices out there, but there reasons they are insecure have nothing to do with what you say. Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From bunk at stusta.de Mon Mar 9 00:23:08 2020 From: bunk at stusta.de (Adrian Bunk) Date: Mon, 9 Mar 2020 02:23:08 +0200 Subject: [OE-core] [Openembedded-architecture] Does YP provide security support for stable and LTS branches? In-Reply-To: References: <20200304113217.GB7923@localhost> <20200304140109.GC7923@localhost> <20200304172415.GA29456@localhost> <01b3bb37-f65f-8048-1a27-b859b62d7f98@gmail.com> <20200306100422.GA17785@localhost> <877e317932176664bc7b0120439c56d4dda791af.camel@linuxfoundation.org> <20200308214610.GB1425@localhost> Message-ID: <20200309002308.GD1425@localhost> On Sun, Mar 08, 2020 at 11:08:08PM +0100, Alexander Kanavin wrote: > On Sun, 8 Mar 2020 at 22:46, Adrian Bunk wrote: > > > It is on YP to make it clear to users whether or not Yocto comes with > > the same set of security guarantees as distributions like Ubuntu or > > Debian. > > If it is the duty of every user of Yocto to track and fix CVEs, > > then this has to be stated clearly instead of implying the opposite. > > This gives users the opportunity to mitigate, instead of unknowingly > > shipping insecure products. > > > > Do you have any actual evidence for actual users shipping insecure products > because they mistakenly believe Yocto takes care of security for them? Nothing to discuss in public. > This > has been the situation from the start of the project, certainly this was > the case 5 years ago when I joined it, and the only person ever to make an > issue out of it is you. Everyone else seems to understand the deal they're > getting by using Yocto without a commercial support contract. >... You are saying that 'track and fix CVEs' is on users. Let's check what YP is telling users. Click on the "Is Yocto Project for you?" link on the YP frontpage: https://www.yoctoproject.org/is-yocto-project-for-you/ 13. Yocto Project follows a strict release schedule incorporating security patches in all supported releases. This predictability is crucial for projects that are based on Yocto Project and allows the development teams to plan their activities. Developers can choose which Yocto Project branch on which to base their activities as a function of their needs. The development branch will ensure access to the latest features while the stable branches will reduce the pace of changes. CVEs (common vulnerabilities and exposures) issues are supported for the latest 2 releases. > Alex cu Adrian From anuj.mittal at intel.com Mon Mar 9 00:45:00 2020 From: anuj.mittal at intel.com (Anuj Mittal) Date: Mon, 9 Mar 2020 08:45:00 +0800 Subject: [OE-core] [PATCH 1/3] sqlite3: fix CVE-2020-9327 Message-ID: <20200309004502.4096343-1-anuj.mittal@intel.com> Signed-off-by: Anuj Mittal --- .../sqlite/files/CVE-2020-9327.patch | 141 ++++++++++++++++++ meta/recipes-support/sqlite/sqlite3_3.31.1.bb | 1 + 2 files changed, 142 insertions(+) create mode 100644 meta/recipes-support/sqlite/files/CVE-2020-9327.patch diff --git a/meta/recipes-support/sqlite/files/CVE-2020-9327.patch b/meta/recipes-support/sqlite/files/CVE-2020-9327.patch new file mode 100644 index 0000000000..fecbbabce8 --- /dev/null +++ b/meta/recipes-support/sqlite/files/CVE-2020-9327.patch @@ -0,0 +1,141 @@ +From 45d491851e1bca378de158a5e279fd584ce548e4 Mon Sep 17 00:00:00 2001 +From: "D. Richard Hipp" +Date: Mon, 17 Feb 2020 00:12:04 +0000 +Subject: [PATCH] [PATCH 1/2] Take care when checking the table of a TK_COLUMN + expression node to see if the table is a virtual table to first ensure that + the Expr.y.pTab pointer is not null due to generated column optimizations. + Ticket [4374860b29383380]. + +FossilOrigin-Name: 9d0d4ab95dc0c56e053c2924ed322a9ea7b25439e6f74599f706905a1994e454 + +[PATCH 2/2] A better (smaller and faster) solution to ticket + [4374860b29383380]. + +FossilOrigin-Name: abc473fb8fb999005dc79a360e34f97b3b25429decf1820dd2afa5c19577753d + +The two patches were converted to amalgamation format + +Signed-off-by: Anuj Mittal +Upstream-Status: Backport +CVE: CVE-2020-9327 +--- + sqlite3.c | 35 ++++++++++++++++++++++++----------- + sqlite3.h | 2 +- + 2 files changed, 25 insertions(+), 12 deletions(-) + +diff --git a/sqlite3.c b/sqlite3.c +index 55dc686..64fae04 100644 +--- a/sqlite3.c ++++ b/sqlite3.c +@@ -1167,7 +1167,7 @@ extern "C" { + */ + #define SQLITE_VERSION "3.31.1" + #define SQLITE_VERSION_NUMBER 3031001 +-#define SQLITE_SOURCE_ID "2020-01-27 19:55:54 3bfa9cc97da10598521b342961df8f5f68c7388fa117345eeb516eaa837bb4d6" ++#define SQLITE_SOURCE_ID "2020-01-27 19:55:54 3bfa9cc97da10598521b342961df8f5f68c7388fa117345eeb516eaa837balt1" + + /* + ** CAPI3REF: Run-Time Library Version Numbers +@@ -17428,8 +17428,11 @@ struct Table { + */ + #ifndef SQLITE_OMIT_VIRTUALTABLE + # define IsVirtual(X) ((X)->nModuleArg) ++# define ExprIsVtab(X) \ ++ ((X)->op==TK_COLUMN && (X)->y.pTab!=0 && (X)->y.pTab->nModuleArg) + #else + # define IsVirtual(X) 0 ++# define ExprIsVtab(X) 0 + #endif + + /* +@@ -104133,19 +104136,25 @@ static int impliesNotNullRow(Walker *pWalker, Expr *pExpr){ + case TK_LT: + case TK_LE: + case TK_GT: +- case TK_GE: ++ case TK_GE: { ++ Expr *pLeft = pExpr->pLeft; ++ Expr *pRight = pExpr->pRight; + testcase( pExpr->op==TK_EQ ); + testcase( pExpr->op==TK_NE ); + testcase( pExpr->op==TK_LT ); + testcase( pExpr->op==TK_LE ); + testcase( pExpr->op==TK_GT ); + testcase( pExpr->op==TK_GE ); +- if( (pExpr->pLeft->op==TK_COLUMN && IsVirtual(pExpr->pLeft->y.pTab)) +- || (pExpr->pRight->op==TK_COLUMN && IsVirtual(pExpr->pRight->y.pTab)) ++ /* The y.pTab=0 assignment in wherecode.c always happens after the ++ ** impliesNotNullRow() test */ ++ if( (pLeft->op==TK_COLUMN && ALWAYS(pLeft->y.pTab!=0) ++ && IsVirtual(pLeft->y.pTab)) ++ || (pRight->op==TK_COLUMN && ALWAYS(pRight->y.pTab!=0) ++ && IsVirtual(pRight->y.pTab)) + ){ +- return WRC_Prune; ++ return WRC_Prune; + } +- ++ } + default: + return WRC_Continue; + } +@@ -142591,7 +142600,8 @@ static int isAuxiliaryVtabOperator( + ** MATCH(expression,vtab_column) + */ + pCol = pList->a[1].pExpr; +- if( pCol->op==TK_COLUMN && IsVirtual(pCol->y.pTab) ){ ++ testcase( pCol->op==TK_COLUMN && pCol->y.pTab==0 ); ++ if( ExprIsVtab(pCol) ){ + for(i=0; iu.zToken, aOp[i].zOp)==0 ){ + *peOp2 = aOp[i].eOp2; +@@ -142613,7 +142623,8 @@ static int isAuxiliaryVtabOperator( + ** with function names in an arbitrary case. + */ + pCol = pList->a[0].pExpr; +- if( pCol->op==TK_COLUMN && IsVirtual(pCol->y.pTab) ){ ++ testcase( pCol->op==TK_COLUMN && pCol->y.pTab==0 ); ++ if( ExprIsVtab(pCol) ){ + sqlite3_vtab *pVtab; + sqlite3_module *pMod; + void (*xNotUsed)(sqlite3_context*,int,sqlite3_value**); +@@ -142636,10 +142647,12 @@ static int isAuxiliaryVtabOperator( + int res = 0; + Expr *pLeft = pExpr->pLeft; + Expr *pRight = pExpr->pRight; +- if( pLeft->op==TK_COLUMN && IsVirtual(pLeft->y.pTab) ){ ++ testcase( pLeft->op==TK_COLUMN && pLeft->y.pTab==0 ); ++ if( ExprIsVtab(pLeft) ){ + res++; + } +- if( pRight && pRight->op==TK_COLUMN && IsVirtual(pRight->y.pTab) ){ ++ testcase( pRight && pRight->op==TK_COLUMN && pRight->y.pTab==0 ); ++ if( pRight && ExprIsVtab(pRight) ){ + res++; + SWAP(Expr*, pLeft, pRight); + } +@@ -228440,7 +228453,7 @@ SQLITE_API int sqlite3_stmt_init( + #endif /* !defined(SQLITE_CORE) || defined(SQLITE_ENABLE_STMTVTAB) */ + + /************** End of stmt.c ************************************************/ +-#if __LINE__!=228443 ++#if __LINE__!=228456 + #undef SQLITE_SOURCE_ID + #define SQLITE_SOURCE_ID "2020-01-27 19:55:54 3bfa9cc97da10598521b342961df8f5f68c7388fa117345eeb516eaa837balt2" + #endif +diff --git a/sqlite3.h b/sqlite3.h +index cef6eea..5b9796c 100644 +--- a/sqlite3.h ++++ b/sqlite3.h +@@ -125,7 +125,7 @@ extern "C" { + */ + #define SQLITE_VERSION "3.31.1" + #define SQLITE_VERSION_NUMBER 3031001 +-#define SQLITE_SOURCE_ID "2020-01-27 19:55:54 3bfa9cc97da10598521b342961df8f5f68c7388fa117345eeb516eaa837bb4d6" ++#define SQLITE_SOURCE_ID "2020-01-27 19:55:54 3bfa9cc97da10598521b342961df8f5f68c7388fa117345eeb516eaa837balt1" + + /* + ** CAPI3REF: Run-Time Library Version Numbers +-- +2.25.1 + diff --git a/meta/recipes-support/sqlite/sqlite3_3.31.1.bb b/meta/recipes-support/sqlite/sqlite3_3.31.1.bb index 903d66ab29..de564e2698 100644 --- a/meta/recipes-support/sqlite/sqlite3_3.31.1.bb +++ b/meta/recipes-support/sqlite/sqlite3_3.31.1.bb @@ -4,6 +4,7 @@ LICENSE = "PD" LIC_FILES_CHKSUM = "file://sqlite3.h;endline=11;md5=786d3dc581eff03f4fd9e4a77ed00c66" SRC_URI = "http://www.sqlite.org/2020/sqlite-autoconf-${SQLITE_PV}.tar.gz \ + file://CVE-2020-9327.patch \ " SRC_URI[md5sum] = "2d0a553534c521504e3ac3ad3b90f125" SRC_URI[sha256sum] = "62284efebc05a76f909c580ffa5c008a7d22a1287285d68b7825a2b6b51949ae" -- 2.24.1 From anuj.mittal at intel.com Mon Mar 9 00:45:01 2020 From: anuj.mittal at intel.com (Anuj Mittal) Date: Mon, 9 Mar 2020 08:45:01 +0800 Subject: [OE-core] [PATCH 2/3] e2fsprogs: fix CVE-2019-5188 In-Reply-To: <20200309004502.4096343-1-anuj.mittal@intel.com> References: <20200309004502.4096343-1-anuj.mittal@intel.com> Message-ID: <20200309004502.4096343-2-anuj.mittal@intel.com> Also see: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948508 Signed-off-by: Anuj Mittal --- ...-t-try-to-rehash-a-deleted-directory.patch | 49 ++++++++++++++++ .../e2fsprogs/e2fsprogs/CVE-2019-5188.patch | 57 +++++++++++++++++++ .../e2fsprogs/e2fsprogs_1.45.4.bb | 2 + 3 files changed, 108 insertions(+) create mode 100644 meta/recipes-devtools/e2fsprogs/e2fsprogs/0001-e2fsck-don-t-try-to-rehash-a-deleted-directory.patch create mode 100644 meta/recipes-devtools/e2fsprogs/e2fsprogs/CVE-2019-5188.patch diff --git a/meta/recipes-devtools/e2fsprogs/e2fsprogs/0001-e2fsck-don-t-try-to-rehash-a-deleted-directory.patch b/meta/recipes-devtools/e2fsprogs/e2fsprogs/0001-e2fsck-don-t-try-to-rehash-a-deleted-directory.patch new file mode 100644 index 0000000000..ba4e3a3c97 --- /dev/null +++ b/meta/recipes-devtools/e2fsprogs/e2fsprogs/0001-e2fsck-don-t-try-to-rehash-a-deleted-directory.patch @@ -0,0 +1,49 @@ +From 71ba13755337e19c9a826dfc874562a36e1b24d3 Mon Sep 17 00:00:00 2001 +From: Theodore Ts'o +Date: Thu, 19 Dec 2019 19:45:06 -0500 +Subject: [PATCH] e2fsck: don't try to rehash a deleted directory + +If directory has been deleted in pass1[bcd] processing, then we +shouldn't try to rehash the directory in pass 3a when we try to +rehash/reoptimize directories. + +Signed-off-by: Theodore Ts'o + +Upstream-Status: Backport [https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/?id=71ba13755337e19c9a826dfc874562a36e1b24d3] +Signed-off-by: Anuj Mittal +--- + e2fsck/pass1b.c | 4 ++++ + e2fsck/rehash.c | 2 ++ + 2 files changed, 6 insertions(+) + +diff --git a/e2fsck/pass1b.c b/e2fsck/pass1b.c +index 5693b9cf..bca701ca 100644 +--- a/e2fsck/pass1b.c ++++ b/e2fsck/pass1b.c +@@ -705,6 +705,10 @@ static void delete_file(e2fsck_t ctx, ext2_ino_t ino, + fix_problem(ctx, PR_1B_BLOCK_ITERATE, &pctx); + if (ctx->inode_bad_map) + ext2fs_unmark_inode_bitmap2(ctx->inode_bad_map, ino); ++ if (ctx->inode_reg_map) ++ ext2fs_unmark_inode_bitmap2(ctx->inode_reg_map, ino); ++ ext2fs_unmark_inode_bitmap2(ctx->inode_dir_map, ino); ++ ext2fs_unmark_inode_bitmap2(ctx->inode_used_map, ino); + ext2fs_inode_alloc_stats2(fs, ino, -1, LINUX_S_ISDIR(dp->inode.i_mode)); + quota_data_sub(ctx->qctx, &dp->inode, ino, + pb.dup_blocks * fs->blocksize); +diff --git a/e2fsck/rehash.c b/e2fsck/rehash.c +index 3dd1e941..2c908be0 100644 +--- a/e2fsck/rehash.c ++++ b/e2fsck/rehash.c +@@ -1028,6 +1028,8 @@ void e2fsck_rehash_directories(e2fsck_t ctx) + if (!ext2fs_u32_list_iterate(iter, &ino)) + break; + } ++ if (!ext2fs_test_inode_bitmap2(ctx->inode_dir_map, ino)) ++ continue; + + pctx.dir = ino; + if (first) { +-- +2.24.1 + diff --git a/meta/recipes-devtools/e2fsprogs/e2fsprogs/CVE-2019-5188.patch b/meta/recipes-devtools/e2fsprogs/e2fsprogs/CVE-2019-5188.patch new file mode 100644 index 0000000000..de4bce0037 --- /dev/null +++ b/meta/recipes-devtools/e2fsprogs/e2fsprogs/CVE-2019-5188.patch @@ -0,0 +1,57 @@ +From 8dd73c149f418238f19791f9d666089ef9734dff Mon Sep 17 00:00:00 2001 +From: Theodore Ts'o +Date: Thu, 19 Dec 2019 19:37:34 -0500 +Subject: [PATCH] e2fsck: abort if there is a corrupted directory block when + rehashing + +In e2fsck pass 3a, when we are rehashing directories, at least in +theory, all of the directories should have had corruptions with +respect to directory entry structure fixed. However, it's possible +(for example, if the user declined a fix) that we can reach this stage +of processing with a corrupted directory entries. + +So check for that case and don't try to process a corrupted directory +block so we don't run into trouble in mutate_name() if there is a +zero-length file name. + +Addresses: TALOS-2019-0973 +Addresses: CVE-2019-5188 +Signed-off-by: Theodore Ts'o + +CVE: CVE-2019-5188 +Signed-off-by: Anuj Mittal +Upstream-Status: Backport [https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/?id=8dd73c149f418238f19791f9d666089ef9734dff] +--- + e2fsck/rehash.c | 9 +++++++++ + 1 file changed, 9 insertions(+) + +diff --git a/e2fsck/rehash.c b/e2fsck/rehash.c +index a5fc1be1..3dd1e941 100644 +--- a/e2fsck/rehash.c ++++ b/e2fsck/rehash.c +@@ -160,6 +160,10 @@ static int fill_dir_block(ext2_filsys fs, + dir_offset += rec_len; + if (dirent->inode == 0) + continue; ++ if ((name_len) == 0) { ++ fd->err = EXT2_ET_DIR_CORRUPTED; ++ return BLOCK_ABORT; ++ } + if (!fd->compress && (name_len == 1) && + (dirent->name[0] == '.')) + continue; +@@ -401,6 +405,11 @@ static int duplicate_search_and_fix(e2fsck_t ctx, ext2_filsys fs, + continue; + } + new_len = ext2fs_dirent_name_len(ent->dir); ++ if (new_len == 0) { ++ /* should never happen */ ++ ext2fs_unmark_valid(fs); ++ continue; ++ } + memcpy(new_name, ent->dir->name, new_len); + mutate_name(new_name, &new_len); + for (j=0; j < fd->num_array; j++) { +-- +2.24.1 + diff --git a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.45.4.bb b/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.45.4.bb index 6e69eea21c..fc92b77ab6 100644 --- a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.45.4.bb +++ b/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.45.4.bb @@ -7,6 +7,8 @@ SRC_URI += "file://remove.ldconfig.call.patch \ file://0001-misc-create_inode.c-set-dir-s-mode-correctly.patch \ file://0001-configure.ac-correct-AM_GNU_GETTEXT.patch \ file://0001-intl-do-not-try-to-use-gettext-defines-that-no-longe.patch \ + file://CVE-2019-5188.patch \ + file://0001-e2fsck-don-t-try-to-rehash-a-deleted-directory.patch \ " SRC_URI_append_class-native = " file://e2fsprogs-fix-missing-check-for-permission-denied.patch \ -- 2.24.1 From anuj.mittal at intel.com Mon Mar 9 00:45:02 2020 From: anuj.mittal at intel.com (Anuj Mittal) Date: Mon, 9 Mar 2020 08:45:02 +0800 Subject: [OE-core] [PATCH 3/3] e2fsprogs: backport upstream patch In-Reply-To: <20200309004502.4096343-1-anuj.mittal@intel.com> References: <20200309004502.4096343-1-anuj.mittal@intel.com> Message-ID: <20200309004502.4096343-3-anuj.mittal@intel.com> Fixes a bug wherein a use after free could potentially be used to run malicious code if a user can be tricked into running e2fsck on a maliciously crafted file system. Also see: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948517 Signed-off-by: Anuj Mittal --- ...fix-use-after-free-in-calculate_tree.patch | 76 +++++++++++++++++++ .../e2fsprogs/e2fsprogs_1.45.4.bb | 1 + 2 files changed, 77 insertions(+) create mode 100644 meta/recipes-devtools/e2fsprogs/e2fsprogs/e2fsck-fix-use-after-free-in-calculate_tree.patch diff --git a/meta/recipes-devtools/e2fsprogs/e2fsprogs/e2fsck-fix-use-after-free-in-calculate_tree.patch b/meta/recipes-devtools/e2fsprogs/e2fsprogs/e2fsck-fix-use-after-free-in-calculate_tree.patch new file mode 100644 index 0000000000..342a2b855b --- /dev/null +++ b/meta/recipes-devtools/e2fsprogs/e2fsprogs/e2fsck-fix-use-after-free-in-calculate_tree.patch @@ -0,0 +1,76 @@ +From: Wang Shilong +Date: Mon, 30 Dec 2019 19:52:39 -0500 +Subject: e2fsck: fix use after free in calculate_tree() + +The problem is alloc_blocks() will call get_next_block() which might +reallocate outdir->buf, and memory address could be changed after +this. To fix this, pointers that point into outdir->buf, such as +int_limit and root need to be recaulated based on the new starting +address of outdir->buf. + +[ Changed to correctly recalculate int_limit, and to optimize how we + reallocate outdir->buf. -TYT ] + +Addresses-Debian-Bug: 948517 +Signed-off-by: Wang Shilong +Signed-off-by: Theodore Ts'o +(cherry picked from commit 101e73e99ccafa0403fcb27dd7413033b587ca01) + +Signed-off-by: Anuj Mittal +Upstream-Status: Backport [https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/?id=101e73e99ccafa0403fcb27dd7413033b587ca01] +--- + e2fsck/rehash.c | 17 ++++++++++++++++- + 1 file changed, 16 insertions(+), 1 deletion(-) + +diff --git a/e2fsck/rehash.c b/e2fsck/rehash.c +index 0a5888a9..2574e151 100644 +--- a/e2fsck/rehash.c ++++ b/e2fsck/rehash.c +@@ -295,7 +295,11 @@ static errcode_t get_next_block(ext2_filsys fs, struct out_dir *outdir, + errcode_t retval; + + if (outdir->num >= outdir->max) { +- retval = alloc_size_dir(fs, outdir, outdir->max + 50); ++ int increment = outdir->max / 10; ++ ++ if (increment < 50) ++ increment = 50; ++ retval = alloc_size_dir(fs, outdir, outdir->max + increment); + if (retval) + return retval; + } +@@ -637,6 +641,9 @@ static int alloc_blocks(ext2_filsys fs, + if (retval) + return retval; + ++ /* outdir->buf might be reallocated */ ++ *prev_ent = (struct ext2_dx_entry *) (outdir->buf + *prev_offset); ++ + *next_ent = set_int_node(fs, block_start); + *limit = (struct ext2_dx_countlimit *)(*next_ent); + if (next_offset) +@@ -726,6 +733,9 @@ static errcode_t calculate_tree(ext2_filsys fs, + return retval; + } + if (c3 == 0) { ++ int delta1 = (char *)int_limit - outdir->buf; ++ int delta2 = (char *)root - outdir->buf; ++ + retval = alloc_blocks(fs, &limit, &int_ent, + &dx_ent, &int_offset, + NULL, outdir, i, &c2, +@@ -733,6 +743,11 @@ static errcode_t calculate_tree(ext2_filsys fs, + if (retval) + return retval; + ++ /* outdir->buf might be reallocated */ ++ int_limit = (struct ext2_dx_countlimit *) ++ (outdir->buf + delta1); ++ root = (struct ext2_dx_entry *) ++ (outdir->buf + delta2); + } + dx_ent->block = ext2fs_cpu_to_le32(i); + if (c3 != limit->limit) +-- +2.24.1 + diff --git a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.45.4.bb b/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.45.4.bb index fc92b77ab6..4f7cafeac9 100644 --- a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.45.4.bb +++ b/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.45.4.bb @@ -9,6 +9,7 @@ SRC_URI += "file://remove.ldconfig.call.patch \ file://0001-intl-do-not-try-to-use-gettext-defines-that-no-longe.patch \ file://CVE-2019-5188.patch \ file://0001-e2fsck-don-t-try-to-rehash-a-deleted-directory.patch \ + file://e2fsck-fix-use-after-free-in-calculate_tree.patch \ " SRC_URI_append_class-native = " file://e2fsprogs-fix-missing-check-for-permission-denied.patch \ -- 2.24.1 From christopher.w.clark at gmail.com Mon Mar 9 04:45:51 2020 From: christopher.w.clark at gmail.com (Christopher Clark) Date: Sun, 8 Mar 2020 21:45:51 -0700 Subject: [OE-core] [PATCH] kernel.bbclass: fix SOURCE_DATE_EPOCH for non-git kernel builds In-Reply-To: References: <20200307200330.23915-1-christopher.w.clark@gmail.com> Message-ID: On Sat, Mar 7, 2020 at 2:34 PM Alex Kiernan wrote: > > On Sat, Mar 7, 2020 at 8:04 PM wrote: > > > > From: Christopher Clark > > > > Only use git to set SOURCE_DATE_EPOCH if ${S} is the top level of a git > > repository. > > > > Fixes the following errors with the prior logic when building a kernel > > that is not obtained from a git repository: > > > > 1. With TMPDIR set to a directory outside any git repository on a > > mounted filesystem, reproducible builds fail in do_compile with this git > > error: > > > > fatal: not a git repository (or any parent up to mount point ) > > Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). > > > > aborting before the error handling logic. > > > > 2. With TMPDIR located within a subdirectory of a git repository, the > > SOURCE_DATE_EPOCH timestamp would be that of said repository rather than > > that of the kernel. > > > > Signed-off-by: Christopher Clark > > --- > > meta/classes/kernel.bbclass | 12 ++++++++---- > > 1 file changed, 8 insertions(+), 4 deletions(-) > > > > diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass > > index 0eadd3efb8..2603f24709 100644 > > --- a/meta/classes/kernel.bbclass > > +++ b/meta/classes/kernel.bbclass > > @@ -296,10 +296,14 @@ kernel_do_compile() { > > if [ "${SOURCE_DATE_EPOCH}" = "" -o "${SOURCE_DATE_EPOCH}" = "0" ]; then > > olddir=`pwd` > > cd ${S} > > - SOURCE_DATE_EPOCH=`git log -1 --pretty=%ct` > > - # git repo not guaranteed, so fall back to REPRODUCIBLE_TIMESTAMP_ROOTFS > > - if [ $? -ne 0 ]; then > > - SOURCE_DATE_EPOCH=${REPRODUCIBLE_TIMESTAMP_ROOTFS} > > + # This kernel dir is not necessarily a git repo and we > > + # must ensure that git does not incorrectly query a > > + # repository in a parent directory. > > + GIT_TOP=`git rev-parse --show-toplevel 2>/dev/null || echo ""` > > + if [ "${S}" = "${GIT_TOP}" ]; then > > Will that work if ${S} isn't a canonical path? Good question; it would be better to avoid the comparison. > > > + SOURCE_DATE_EPOCH=`git log -1 --pretty=%ct` > > + else > > + SOURCE_DATE_EPOCH="${REPRODUCIBLE_TIMESTAMP_ROOTFS}" > > fi > > cd $olddir > > fi > > Would something like this resolve the problem (untested): Thanks for the suggestion to use the git-dir option. git is somewhat picky about argument ordering and any error encountered at that point aborts the build rather than falling into error handling logic below, but I have a revised v2 patch now that I will post shortly. Christopher > > diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass > index 0eadd3efb8d9..a17ca7adccca 100644 > --- a/meta/classes/kernel.bbclass > +++ b/meta/classes/kernel.bbclass > @@ -294,14 +294,11 @@ kernel_do_compile() { > # kernel sources do not use do_unpack, so > SOURCE_DATE_EPOCH may not > # be set.... > if [ "${SOURCE_DATE_EPOCH}" = "" -o > "${SOURCE_DATE_EPOCH}" = "0" ]; then > - olddir=`pwd` > - cd ${S} > - SOURCE_DATE_EPOCH=`git log -1 --pretty=%ct` > + SOURCE_DATE_EPOCH=`git --git-dir="${S}/.git}" > log -1 --pretty=%ct` > # git repo not guaranteed, so fall back to > REPRODUCIBLE_TIMESTAMP_ROOTFS > if [ $? -ne 0 ]; then > > SOURCE_DATE_EPOCH=${REPRODUCIBLE_TIMESTAMP_ROOTFS} > fi > - cd $olddir > fi > > ts=`LC_ALL=C date -d @$SOURCE_DATE_EPOCH` > > -- > Alex Kiernan From christopher.w.clark at gmail.com Mon Mar 9 04:48:13 2020 From: christopher.w.clark at gmail.com (christopher.w.clark at gmail.com) Date: Sun, 8 Mar 2020 21:48:13 -0700 Subject: [OE-core] [PATCH v2] kernel.bbclass: fix SOURCE_DATE_EPOCH for non-git kernel builds Message-ID: <20200309044813.16015-1-christopher.w.clark@gmail.com> From: Christopher Clark The source directory is not always a git repository, so when querying git for data to set SOURCE_DATE_EPOCH, specify ${S}/.git as the git directory to prevent retrieving incorrect data from any parent directory. Fixes the following errors with the prior logic when building a kernel that is not obtained from a git repository: 1. With TMPDIR set to a directory outside any git repository on a mounted filesystem, reproducible builds fail in do_compile with this git error: fatal: not a git repository (or any parent up to mount point ) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). aborting before the error handling logic. 2. With TMPDIR located within a subdirectory of a git repository, the SOURCE_DATE_EPOCH timestamp would be that of said repository rather than that of the kernel. Signed-off-by: Christopher Clark --- meta/classes/kernel.bbclass | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass index 0eadd3efb8..a724645466 100644 --- a/meta/classes/kernel.bbclass +++ b/meta/classes/kernel.bbclass @@ -294,14 +294,10 @@ kernel_do_compile() { # kernel sources do not use do_unpack, so SOURCE_DATE_EPOCH may not # be set.... if [ "${SOURCE_DATE_EPOCH}" = "" -o "${SOURCE_DATE_EPOCH}" = "0" ]; then - olddir=`pwd` - cd ${S} - SOURCE_DATE_EPOCH=`git log -1 --pretty=%ct` - # git repo not guaranteed, so fall back to REPRODUCIBLE_TIMESTAMP_ROOTFS - if [ $? -ne 0 ]; then - SOURCE_DATE_EPOCH=${REPRODUCIBLE_TIMESTAMP_ROOTFS} - fi - cd $olddir + # The source directory is not necessarily a git repository, so we + # specify the git-dir to ensure that git does not query a + # repository in any parent directory. + SOURCE_DATE_EPOCH=`git --git-dir="${S}/.git" log -1 --pretty=%ct 2>/dev/null || echo "${REPRODUCIBLE_TIMESTAMP_ROOTFS}"` fi ts=`LC_ALL=C date -d @$SOURCE_DATE_EPOCH` -- 2.17.1 From chee.yang.lee at intel.com Mon Mar 9 04:57:03 2020 From: chee.yang.lee at intel.com (chee.yang.lee at intel.com) Date: Mon, 9 Mar 2020 12:57:03 +0800 Subject: [OE-core] [PATCH] cve-check: fix ValueError Message-ID: <1583729823-29198-1-git-send-email-chee.yang.lee@intel.com> From: Chee Yang Lee fix below error for whitelisted recipe and recipe skip cve check. Error: The stack trace of python calls that resulted in this exception/failure was: File: 'exec_python_func() autogenerated', lineno: 2, function: 0001: *** 0002:do_cve_check(d) 0003: File: '/poky-master/meta/classes/cve-check.bbclass', lineno: 59, function: do_cve_check 0055: try: 0056: patched_cves = get_patches_cves(d) 0057: except FileNotFoundError: 0058: bb.fatal("Failure in searching patches") *** 0059: whitelisted, patched, unpatched = check_cves(d, patched_cves) 0060: if patched or unpatched: 0061: cve_data = get_cve_info(d, patched + unpatched) 0062: cve_write_data(d, patched, unpatched, whitelisted, cve_data) 0063: else: Exception: ValueError: not enough values to unpack (expected 3, got 2) Signed-off-by: Chee Yang Lee --- meta/classes/cve-check.bbclass | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass index 7f98da6..5d84b93 100644 --- a/meta/classes/cve-check.bbclass +++ b/meta/classes/cve-check.bbclass @@ -179,13 +179,13 @@ def check_cves(d, patched_cves): products = d.getVar("CVE_PRODUCT").split() # If this has been unset then we're not scanning for CVEs here (for example, image recipes) if not products: - return ([], []) + return ([], [], []) pv = d.getVar("CVE_VERSION").split("+git")[0] # If the recipe has been whitlisted we return empty lists if d.getVar("PN") in d.getVar("CVE_CHECK_PN_WHITELIST").split(): bb.note("Recipe has been whitelisted, skipping check") - return ([], []) + return ([], [], []) old_cve_whitelist = d.getVar("CVE_CHECK_CVE_WHITELIST") if old_cve_whitelist: -- 2.7.4 From zhixiong.chi at windriver.com Mon Mar 9 07:43:41 2020 From: zhixiong.chi at windriver.com (Zhixiong Chi) Date: Mon, 9 Mar 2020 00:43:41 -0700 Subject: [OE-core] [PATCH] glibc: CVE-2020-10029 Message-ID: <20200309074341.39158-1-zhixiong.chi@windriver.com> Backport the CVE patch from upstream: [https://sourceware.org/git/gitweb.cgi?p=glibc.git; a=patch;h=9333498794cde1d5cca518badf79533a24114b6f] Signed-off-by: Zhixiong Chi --- .../glibc/glibc/CVE-2020-10029.patch | 128 ++++++++++++++++++ meta/recipes-core/glibc/glibc_2.31.bb | 1 + 2 files changed, 129 insertions(+) create mode 100644 meta/recipes-core/glibc/glibc/CVE-2020-10029.patch diff --git a/meta/recipes-core/glibc/glibc/CVE-2020-10029.patch b/meta/recipes-core/glibc/glibc/CVE-2020-10029.patch new file mode 100644 index 0000000000..22a15f5fdc --- /dev/null +++ b/meta/recipes-core/glibc/glibc/CVE-2020-10029.patch @@ -0,0 +1,128 @@ +From ce265ec5bc25ec35fba53807abac1b0c8469895e Mon Sep 17 00:00:00 2001 +From: Joseph Myers +Date: Wed, 12 Feb 2020 23:31:56 +0000 +Subject: [PATCH] Avoid ldbl-96 stack corruption from range reduction of + + pseudo-zero (bug 25487). + +Bug 25487 reports stack corruption in ldbl-96 sinl on a pseudo-zero +argument (an representation where all the significand bits, including +the explicit high bit, are zero, but the exponent is not zero, which +is not a valid representation for the long double type). + +Although this is not a valid long double representation, existing +practice in this area (see bug 4586, originally marked invalid but +subsequently fixed) is that we still seek to avoid invalid memory +accesses as a result, in case of programs that treat arbitrary binary +data as long double representations, although the invalid +representations of the ldbl-96 format do not need to be consistently +handled the same as any particular valid representation. + +This patch makes the range reduction detect pseudo-zero and unnormal +representations that would otherwise go to __kernel_rem_pio2, and +returns a NaN for them instead of continuing with the range reduction +process. (Pseudo-zero and unnormal representations whose unbiased +exponent is less than -1 have already been safely returned from the +function before this point without going through the rest of range +reduction.) Pseudo-zero representations would previously result in +the value passed to __kernel_rem_pio2 being all-zero, which is +definitely unsafe; unnormal representations would previously result in +a value passed whose high bit is zero, which might well be unsafe +since that is not a form of input expected by __kernel_rem_pio2. + +Tested for x86_64. + +CVE: CVE-2020-10029 +Upstream-Status: Backport [https://sourceware.org/git/gitweb.cgi?p=glibc.git; +a=patch;h=9333498794cde1d5cca518badf79533a24114b6f] +Signed-off-by: Zhixiong Chi + +--- + sysdeps/ieee754/ldbl-96/Makefile | 3 ++- + sysdeps/ieee754/ldbl-96/e_rem_pio2l.c | 12 +++++++++ + sysdeps/ieee754/ldbl-96/test-sinl-pseudo.c | 41 ++++++++++++++++++++++++++++++ + 3 files changed, 55 insertions(+), 1 deletion(-) + create mode 100644 sysdeps/ieee754/ldbl-96/test-sinl-pseudo.c + +diff --git a/sysdeps/ieee754/ldbl-96/Makefile b/sysdeps/ieee754/ldbl-96/Makefile +index b103254..052c1c7 100644 +--- a/sysdeps/ieee754/ldbl-96/Makefile ++++ b/sysdeps/ieee754/ldbl-96/Makefile +@@ -17,5 +17,6 @@ + # . + + ifeq ($(subdir),math) +-tests += test-canonical-ldbl-96 test-totalorderl-ldbl-96 ++tests += test-canonical-ldbl-96 test-totalorderl-ldbl-96 test-sinl-pseudo ++CFLAGS-test-sinl-pseudo.c += -fstack-protector-all + endif +diff --git a/sysdeps/ieee754/ldbl-96/e_rem_pio2l.c b/sysdeps/ieee754/ldbl-96/e_rem_pio2l.c +index 805de22..1aeccb4 100644 +--- a/sysdeps/ieee754/ldbl-96/e_rem_pio2l.c ++++ b/sysdeps/ieee754/ldbl-96/e_rem_pio2l.c +@@ -210,6 +210,18 @@ __ieee754_rem_pio2l (long double x, long double *y) + return 0; + } + ++ if ((i0 & 0x80000000) == 0) ++ { ++ /* Pseudo-zero and unnormal representations are not valid ++ representations of long double. We need to avoid stack ++ corruption in __kernel_rem_pio2, which expects input in a ++ particular normal form, but those representations do not need ++ to be consistently handled like any particular floating-point ++ value. */ ++ y[1] = y[0] = __builtin_nanl (""); ++ return 0; ++ } ++ + /* Split the 64 bits of the mantissa into three 24-bit integers + stored in a double array. */ + exp = j0 - 23; +diff --git a/sysdeps/ieee754/ldbl-96/test-sinl-pseudo.c b/sysdeps/ieee754/ldbl-96/test-sinl-pseudo.c +new file mode 100644 +index 0000000..f59b977 +--- /dev/null ++++ b/sysdeps/ieee754/ldbl-96/test-sinl-pseudo.c +@@ -0,0 +1,41 @@ ++/* Test sinl for pseudo-zeros and unnormals for ldbl-96 (bug 25487). ++ Copyright (C) 2020 Free Software Foundation, Inc. ++ This file is part of the GNU C Library. ++ ++ The GNU C Library is free software; you can redistribute it and/or ++ modify it under the terms of the GNU Lesser General Public ++ License as published by the Free Software Foundation; either ++ version 2.1 of the License, or (at your option) any later version. ++ ++ The GNU C Library is distributed in the hope that it will be useful, ++ but WITHOUT ANY WARRANTY; without even the implied warranty of ++ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU ++ Lesser General Public License for more details. ++ ++ You should have received a copy of the GNU Lesser General Public ++ License along with the GNU C Library; if not, see ++ . */ ++ ++#include ++#include ++#include ++ ++static int ++do_test (void) ++{ ++ for (int i = 0; i < 64; i++) ++ { ++ uint64_t sig = i == 63 ? 0 : 1ULL << i; ++ long double ld; ++ SET_LDOUBLE_WORDS (ld, 0x4141, ++ sig >> 32, sig & 0xffffffffULL); ++ /* The requirement is that no stack overflow occurs when the ++ pseudo-zero or unnormal goes through range reduction. */ ++ volatile long double ldr; ++ ldr = sinl (ld); ++ (void) ldr; ++ } ++ return 0; ++} ++ ++#include diff --git a/meta/recipes-core/glibc/glibc_2.31.bb b/meta/recipes-core/glibc/glibc_2.31.bb index 2032311b27..6dd9415f6b 100644 --- a/meta/recipes-core/glibc/glibc_2.31.bb +++ b/meta/recipes-core/glibc/glibc_2.31.bb @@ -40,6 +40,7 @@ SRC_URI = "${GLIBC_GIT_URI};branch=${SRCBRANCH};name=glibc \ file://0027-intl-Emit-no-lines-in-bison-generated-files.patch \ file://0028-inject-file-assembly-directives.patch \ file://0029-locale-prevent-maybe-uninitialized-errors-with-Os-BZ.patch \ + file://CVE-2020-10029.patch \ " S = "${WORKDIR}/git" B = "${WORKDIR}/build-${TARGET_SYS}" -- 2.23.0 From zhixiong.chi at windriver.com Mon Mar 9 07:43:44 2020 From: zhixiong.chi at windriver.com (Zhixiong Chi) Date: Mon, 9 Mar 2020 00:43:44 -0700 Subject: [OE-core] [zeus][PATCH] glibc: CVE-2020-10029 Message-ID: <20200309074344.39208-1-zhixiong.chi@windriver.com> Backport the CVE patch from upstream: [https://sourceware.org/git/gitweb.cgi?p=glibc.git; a=patch;h=9333498794cde1d5cca518badf79533a24114b6f] Signed-off-by: Zhixiong Chi --- .../glibc/glibc/CVE-2020-10029.patch | 128 ++++++++++++++++++ meta/recipes-core/glibc/glibc_2.30.bb | 1 + 2 files changed, 129 insertions(+) create mode 100644 meta/recipes-core/glibc/glibc/CVE-2020-10029.patch diff --git a/meta/recipes-core/glibc/glibc/CVE-2020-10029.patch b/meta/recipes-core/glibc/glibc/CVE-2020-10029.patch new file mode 100644 index 0000000000..606b691bcf --- /dev/null +++ b/meta/recipes-core/glibc/glibc/CVE-2020-10029.patch @@ -0,0 +1,128 @@ +From ce265ec5bc25ec35fba53807abac1b0c8469895e Mon Sep 17 00:00:00 2001 +From: Joseph Myers +Date: Wed, 12 Feb 2020 23:31:56 +0000 +Subject: [PATCH] Avoid ldbl-96 stack corruption from range reduction of + + pseudo-zero (bug 25487). + +Bug 25487 reports stack corruption in ldbl-96 sinl on a pseudo-zero +argument (an representation where all the significand bits, including +the explicit high bit, are zero, but the exponent is not zero, which +is not a valid representation for the long double type). + +Although this is not a valid long double representation, existing +practice in this area (see bug 4586, originally marked invalid but +subsequently fixed) is that we still seek to avoid invalid memory +accesses as a result, in case of programs that treat arbitrary binary +data as long double representations, although the invalid +representations of the ldbl-96 format do not need to be consistently +handled the same as any particular valid representation. + +This patch makes the range reduction detect pseudo-zero and unnormal +representations that would otherwise go to __kernel_rem_pio2, and +returns a NaN for them instead of continuing with the range reduction +process. (Pseudo-zero and unnormal representations whose unbiased +exponent is less than -1 have already been safely returned from the +function before this point without going through the rest of range +reduction.) Pseudo-zero representations would previously result in +the value passed to __kernel_rem_pio2 being all-zero, which is +definitely unsafe; unnormal representations would previously result in +a value passed whose high bit is zero, which might well be unsafe +since that is not a form of input expected by __kernel_rem_pio2. + +Tested for x86_64. + +CVE: CVE-2020-10029 +Upstream-Status: Backport [https://sourceware.org/git/gitweb.cgi?p=glibc.git; +a=patch;h=9333498794cde1d5cca518badf79533a24114b6f] +Signed-off-by: Zhixiong Chi + +--- + sysdeps/ieee754/ldbl-96/Makefile | 3 ++- + sysdeps/ieee754/ldbl-96/e_rem_pio2l.c | 12 +++++++++ + sysdeps/ieee754/ldbl-96/test-sinl-pseudo.c | 41 ++++++++++++++++++++++++++++++ + 3 files changed, 55 insertions(+), 1 deletion(-) + create mode 100644 sysdeps/ieee754/ldbl-96/test-sinl-pseudo.c + +diff --git a/sysdeps/ieee754/ldbl-96/Makefile b/sysdeps/ieee754/ldbl-96/Makefile +index b103254..052c1c7 100644 +--- a/sysdeps/ieee754/ldbl-96/Makefile ++++ b/sysdeps/ieee754/ldbl-96/Makefile +@@ -17,5 +17,6 @@ + # . + + ifeq ($(subdir),math) +-tests += test-canonical-ldbl-96 test-totalorderl-ldbl-96 ++tests += test-canonical-ldbl-96 test-totalorderl-ldbl-96 test-sinl-pseudo ++CFLAGS-test-sinl-pseudo.c += -fstack-protector-all + endif +diff --git a/sysdeps/ieee754/ldbl-96/e_rem_pio2l.c b/sysdeps/ieee754/ldbl-96/e_rem_pio2l.c +index 805de22..1aeccb4 100644 +--- a/sysdeps/ieee754/ldbl-96/e_rem_pio2l.c ++++ b/sysdeps/ieee754/ldbl-96/e_rem_pio2l.c +@@ -210,6 +210,18 @@ __ieee754_rem_pio2l (long double x, long double *y) + return 0; + } + ++ if ((i0 & 0x80000000) == 0) ++ { ++ /* Pseudo-zero and unnormal representations are not valid ++ representations of long double. We need to avoid stack ++ corruption in __kernel_rem_pio2, which expects input in a ++ particular normal form, but those representations do not need ++ to be consistently handled like any particular floating-point ++ value. */ ++ y[1] = y[0] = __builtin_nanl (""); ++ return 0; ++ } ++ + /* Split the 64 bits of the mantissa into three 24-bit integers + stored in a double array. */ + exp = j0 - 23; +diff --git a/sysdeps/ieee754/ldbl-96/test-sinl-pseudo.c b/sysdeps/ieee754/ldbl-96/test-sinl-pseudo.c +new file mode 100644 +index 0000000..f59b977 +--- /dev/null ++++ b/sysdeps/ieee754/ldbl-96/test-sinl-pseudo.c +@@ -0,0 +1,41 @@ ++/* Test sinl for pseudo-zeros and unnormals for ldbl-96 (bug 25487). ++ Copyright (C) 2020 Free Software Foundation, Inc. ++ This file is part of the GNU C Library. ++ ++ The GNU C Library is free software; you can redistribute it and/or ++ modify it under the terms of the GNU Lesser General Public ++ License as published by the Free Software Foundation; either ++ version 2.1 of the License, or (at your option) any later version. ++ ++ The GNU C Library is distributed in the hope that it will be useful, ++ but WITHOUT ANY WARRANTY; without even the implied warranty of ++ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU ++ Lesser General Public License for more details. ++ ++ You should have received a copy of the GNU Lesser General Public ++ License along with the GNU C Library; if not, see ++ . */ ++ ++#include ++#include ++#include ++ ++static int ++do_test (void) ++{ ++ for (int i = 0; i < 64; i++) ++ { ++ uint64_t sig = i == 63 ? 0 : 1ULL << i; ++ long double ld; ++ SET_LDOUBLE_WORDS (ld, 0x4141, ++ sig >> 32, sig & 0xffffffffULL); ++ /* The requirement is that no stack overflow occurs when the ++ pseudo-zero or unnormal goes through range reduction. */ ++ volatile long double ldr; ++ ldr = sinl (ld); ++ (void) ldr; ++ } ++ return 0; ++} ++ ++#include diff --git a/meta/recipes-core/glibc/glibc_2.30.bb b/meta/recipes-core/glibc/glibc_2.30.bb index 7913bc2812..c9e44a396d 100644 --- a/meta/recipes-core/glibc/glibc_2.30.bb +++ b/meta/recipes-core/glibc/glibc_2.30.bb @@ -42,6 +42,7 @@ SRC_URI = "${GLIBC_GIT_URI};branch=${SRCBRANCH};name=glibc \ file://0027-inject-file-assembly-directives.patch \ file://0028-locale-prevent-maybe-uninitialized-errors-with-Os-BZ.patch \ file://CVE-2019-19126.patch \ + file://CVE-2020-10029.patch \ " S = "${WORKDIR}/git" B = "${WORKDIR}/build-${TARGET_SYS}" -- 2.23.0 From ayoub.zaki at embexus.com Mon Mar 9 07:29:20 2020 From: ayoub.zaki at embexus.com (Ayoub Zaki) Date: Mon, 9 Mar 2020 08:29:20 +0100 Subject: [OE-core] [Openembedded-architecture] Does YP provide security support for stable and LTS branches? In-Reply-To: <20200309002308.GD1425@localhost> References: <20200304113217.GB7923@localhost> <20200304140109.GC7923@localhost> <20200304172415.GA29456@localhost> <01b3bb37-f65f-8048-1a27-b859b62d7f98@gmail.com> <20200306100422.GA17785@localhost> <877e317932176664bc7b0120439c56d4dda791af.camel@linuxfoundation.org> <20200308214610.GB1425@localhost> <20200309002308.GD1425@localhost> Message-ID: Hello, On 09.03.20 01:23, Adrian Bunk wrote: > On Sun, Mar 08, 2020 at 11:08:08PM +0100, Alexander Kanavin wrote: >> On Sun, 8 Mar 2020 at 22:46, Adrian Bunk wrote: >> >>> It is on YP to make it clear to users whether or not Yocto comes with >>> the same set of security guarantees as distributions like Ubuntu or >>> Debian. >>> If it is the duty of every user of Yocto to track and fix CVEs, >>> then this has to be stated clearly instead of implying the opposite. >>> This gives users the opportunity to mitigate, instead of unknowingly >>> shipping insecure products. >>> >> Do you have any actual evidence for actual users shipping insecure products >> because they mistakenly believe Yocto takes care of security for them? > Nothing to discuss in public. > >> This >> has been the situation from the start of the project, certainly this was >> the case 5 years ago when I joined it, and the only person ever to make an >> issue out of it is you. Everyone else seems to understand the deal they're >> getting by using Yocto without a commercial support contract. >> ... > You are saying that 'track and fix CVEs' is on users. > Let's check what YP is telling users. > > Click on the "Is Yocto Project for you?" link on the YP frontpage: > > https://www.yoctoproject.org/is-yocto-project-for-you/ > 13. Yocto Project follows a strict release schedule incorporating > security patches in all supported releases. This predictability is > crucial for projects that are based on Yocto Project and allows the > development teams to plan their activities. Developers can choose which > Yocto Project branch on which to base their activities as a function of > their needs. The development branch will ensure access to the latest > features while the stable branches will reduce the pace of changes. CVEs > (common vulnerabilities and exposures) issues are supported for the > latest 2 releases. Adrian is making a point here, The Yocto Project by claiming that it supports security patches for Stable releases is misleading the Users! I work with different customers and some of them think that by using and pulling the latest releases they will get the CVEs automatically fixed! YP should state that CLEARLY! Of course it will impact the choice of going with Yocto or Not ( probably NOT in this case). > > >> Alex > cu > Adrian Mit freundlichen Gr??en / Kind regards -- Ayoub Zaki Embedded Systems Consultant Vaihinger Stra?e 2/1 D-71634 Ludwigsburg Mobile : +4917662901545 Email : ayoub.zaki at embexus.com Homepage : https://embexus.com VAT No. : DE313902634 From toshikazu-n at nec.com Mon Mar 9 07:35:07 2020 From: toshikazu-n at nec.com (Toshikazu Nakayama) Date: Mon, 9 Mar 2020 16:35:07 +0900 Subject: [OE-core] [RFC PATCH 0/2] Proposal vuln-cve.bbclass about plug and call style CVE task Message-ID: <1583739309-11200-1-git-send-email-toshikazu-n@nec.com> To give any extensibility about CVE task in OE-Core with introducing plug and call style CVE task execution in patch set. If pluggable CVE frameworks will provide from OE-Core for embedded people include Linux distributors, CVE tool makers, embedded product maintainers or developers, they may get chance of implementing plugins which are available for their localized schema(secure development or long term maintenance). In preparation for this submission, I implement two bbclasses with learning from cve-check.bbclass about CVE tasks or license/license_image.bbclass about sstate/manifest tasks. I also read README.OE-Core about how to submit patch. Tests by decomposing cve-check's functions and mapping to plugin framework variables have been succeeded 'bitbake core-image-sato' at 'master' with the almost same result as cve-check's. If there is something missing in the way of my contacts, please let me know. Or if possible, please review or give comments. Regards, Toshikazu. Toshikazu Nakayama (2): vuln-cve: vulnerability task with plug and call style vuln-cve_image: rootfs manifest about vulnerability meta/classes/vuln-cve.bbclass | 299 ++++++++++++++++++++++++++++++++++++ meta/classes/vuln-cve_image.bbclass | 111 +++++++++++++ 2 files changed, 410 insertions(+) create mode 100644 meta/classes/vuln-cve.bbclass create mode 100644 meta/classes/vuln-cve_image.bbclass -- 2.7.4 From toshikazu-n at nec.com Mon Mar 9 07:35:09 2020 From: toshikazu-n at nec.com (Toshikazu Nakayama) Date: Mon, 9 Mar 2020 16:35:09 +0900 Subject: [OE-core] [RFC PATCH 2/2] vuln-cve_image: rootfs manifest about vulnerability In-Reply-To: <1583739309-11200-1-git-send-email-toshikazu-n@nec.com> References: <1583739309-11200-1-git-send-email-toshikazu-n@nec.com> Message-ID: <1583739309-11200-3-git-send-email-toshikazu-n@nec.com> A rootfs post command function vuln_cve_make_manifests() generates some manifests about CVE_REPORTS list variable where files are generated in per package task. A vuln_cve_make_manifests() gather these files about installed packages in image from sstate directory to deploy manifest files specified in CVE_MANIFEST to CVE_MANIFEST_DIR. If CVE_MANIFEST_POPULATES is valid, vuln_cve_make_manifests() populate manifest with "No vulnerability task support packages" which are installed but not inherit vuln-cve and populate package contents with name, version and installed package names. And for the image recipe itself, prepare VULNFUNC_IMAGE_CLASS plugin which may append summary header as image manifest such as CVE database freshness which is inserted at the top of manifest files. Signed-off-by: Toshikazu Nakayama --- meta/classes/vuln-cve.bbclass | 18 +++++- meta/classes/vuln-cve_image.bbclass | 111 ++++++++++++++++++++++++++++++++++++ 2 files changed, 127 insertions(+), 2 deletions(-) create mode 100644 meta/classes/vuln-cve_image.bbclass diff --git a/meta/classes/vuln-cve.bbclass b/meta/classes/vuln-cve.bbclass index 0c7b78c..f916aa8 100644 --- a/meta/classes/vuln-cve.bbclass +++ b/meta/classes/vuln-cve.bbclass @@ -171,12 +171,24 @@ VULNFUNC_JUDGE_CVE = 'list' VULNFUNC_JUDGE_CVE = "" VULNFUNC_REPORT_CVE[type] = 'list' VULNFUNC_REPORT_CVE = "" +VULNFUNC_IMAGE_CLASS[type] = 'list' +VULNFUNC_IMAGE_CLASS = "" python do_vulnerability() { + g = globals() + manifest = d.getVar('CVE_MANIFEST_DIR', True) + if manifest: + # inherit vuln-cve_image from image recipe + image = d.getVar('IMAGE_BASENAME', True) + destdir = os.path.join(d.getVar('VULNSTATEDIR', True), image) + bb.utils.mkdirhier(destdir) + for func in d.getVar('VULNFUNC_IMAGE_CLASS', True).split() or "": + if func in g: + g[func](d, destdir) + return + pn = d.getVar('PN', True) destdir = os.path.join(d.getVar('VULNSTATEDIR', True), pn) bb.utils.mkdirhier(destdir) - g = globals() - cvelist = [] # Gather potential CVE list by using CPE matching for scan in (d.getVar('VULNFUNC_SCAN_CVE', True) or "").split(): @@ -272,6 +284,8 @@ do_vulnerability[sstate-outputdirs] = "${VULN_CVE_DIRECTORY}" do_vulnerability[dir] = "${VULNSTATEDIR}/${PN}" do_vulnerability[cleandirs] = "${VULNSTATEDIR}" do_vulnerability[nostamp] = "1" +# Raising for global "INHERIT += vuln-cve" variable usage. +IMAGE_CLASSES_append = " vuln-cve_image" python do_vulnerability_setscene() { sstate_setscene(d) diff --git a/meta/classes/vuln-cve_image.bbclass b/meta/classes/vuln-cve_image.bbclass new file mode 100644 index 0000000..46cfdb3 --- /dev/null +++ b/meta/classes/vuln-cve_image.bbclass @@ -0,0 +1,111 @@ +# This class deploy CVE manifest for installed packages in rootfs +CVE_REPORTS[type] = 'list' +CVE_CREATE_MANIFEST ??= "1" +CVE_REPORTS ?= "cve.summary cve.patchlist" +CVE_MANIFEST[cve.summary] = "${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.cve.sumary" +CVE_MANIFEST[cve.patchlist] = "${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.cve.patchlist" +CVE_MANIFEST_DIR ?= "${DEPLOY_DIR_IMAGE}" +CVE_MANIFEST_POPULATES ??= "" + +# If image build without INHERIT usage but inherit vuln-cve_image in recipe. +inherit vuln-cve +python vuln_cve_make_manifests() { + vulnstatedir = d.getVar('VULN_CVE_DIRECTORY', True) + destdir = d.getVar('CVE_MANIFEST_DIR', True) + bb.utils.mkdirhier(destdir) + + from oe.rootfs import image_list_installed_packages + pkg_type = d.getVar('PACKAGE_CLASSES', True).replace("package_", "").split()[0] + pkg_dic = {} + notask = [] + def is_notask(sstatedir): + if not os.path.exists(sstatedir): + return True + try: + import time + from datetime import datetime + elapsed = time.time() - os.path.getctime(sstatedir) + if elapsed >= 5 * 60 * 60: + # If package quit to inherit vuln-cve but not cleansstate yet, + # rootfs task can not detect it immediately. + # As results, manifest includes such package unfortunately. + # + # If sstate-dir stamp elapsed more than 5 hours from created, + # forced clean sstate-dir to exclude it from manifest. + bb.warn("%s got staled about vulnerability sstate, " + "force to exclude from manifest" % pn) + bb.utils.remove(sstatedir, recurse=True) + return True + except OSError: + pass + return False + + for pkg in image_list_installed_packages(d): + pkg_info = os.path.join(d.getVar('PKGDATA_DIR', True), + 'runtime-reverse', pkg) + pkgdata = oe.packagedata.read_pkgdatafile(pkg_info) + pkg_name = os.path.basename(os.readlink(pkg_info)) + pn = pkgdata['PN'] + if is_notask(os.path.join(vulnstatedir, pn)): + if not pn in notask: + notask.append(pn) + continue + elif pn in pkg_dic: + if pkg_name in pkg_dic[pn][pkg_type]: + continue + pkg_dic[pn][pkg_type].append(pkg_name) + continue + pkg_dic[pn] = {} + pkg_dic[pn]['pv'] = pkgdata['PV'] + pkg_dic[pn][pkg_type] = [ pkg_name ] + pkg_dic[pn]['ssdir'] = os.path.join(vulnstatedir, pn) + + from datetime import datetime + time_now = "%s" % datetime.now() + image = d.getVar('IMAGE_BASENAME', True) + image_sstate = os.path.join(vulnstatedir, image) + link_name = d.getVar("IMAGE_LINK_NAME") + do_populates = d.getVar('CVE_MANIFEST_POPULATES', True) + for rep in d.getVar('CVE_REPORTS', True).split(): + manifest = d.getVarFlag('CVE_MANIFEST', rep, True) + manifest = os.path.join(destdir, manifest) + manifest_link = os.path.join(destdir, "%s.%s" % (link_name, rep)) + if os.path.exists(os.path.realpath(manifest_link)): + bb.utils.remove(os.path.realpath(manifest_link)) + bb.utils.remove(manifest_link) + # Header for this image + desc = [] + if (os.path.exists(os.path.join(image_sstate, rep))): + # Insert private header if prepared for this manifest. + with open(os.path.join(image_sstate, rep), "r") as r: + desc.append(r.read()) + else: + desc.append("%s: generated at %s\n" % (image, time_now)) + if do_populates and len(notask) > 0: + notask = sorted(notask) + desc.append("\n") + desc.append("No vulnerability task support packages\n") + import textwrap + excludes = textwrap.wrap("[%s]" % ', '.join(notask), 76) + desc.append(" %s\n" % '\n '.join(excludes)) + with open(manifest, 'w') as m: + m.write("%s\n" % ''.join(desc)) + desc.clear() + for pn in sorted(pkg_dic): + write_msg = "" + if do_populates: + write_msg += "%s <%s> %s(%s)\n" % (pn, pkg_dic[pn]['pv'], pkg_type, + ', '.join(pkg_dic[pn][pkg_type])) + if os.path.exists(os.path.join(pkg_dic[pn]['ssdir'], rep)): + with open(os.path.join(pkg_dic[pn]['ssdir'], rep), "r") as r: + write_msg += r.read() + if not write_msg: + continue + desc.append(write_msg) + with open(manifest, 'a') as m: + m.write("%s" % '\n'.join(desc)) + os.symlink(os.path.basename(manifest), manifest_link) + bb.plain("Image CVE report (%s) stored in: %s" % (rep, manifest)) +} +ROOTFS_POSTPROCESS_COMMAND_prepend = "${@'vuln_cve_make_manifests; ' if d.getVar('CVE_CREATE_MANIFEST') == '1' else ''}" +do_rootfs[recrdeptask] += "${@'do_vulnerability' if d.getVar('CVE_CREATE_MANIFEST') == '1' else ''}" -- 2.7.4 From toshikazu-n at nec.com Mon Mar 9 07:35:08 2020 From: toshikazu-n at nec.com (Toshikazu Nakayama) Date: Mon, 9 Mar 2020 16:35:08 +0900 Subject: [OE-core] [RFC PATCH 1/2] vuln-cve: vulnerability task with plug and call style In-Reply-To: <1583739309-11200-1-git-send-email-toshikazu-n@nec.com> References: <1583739309-11200-1-git-send-email-toshikazu-n@nec.com> Message-ID: <1583739309-11200-2-git-send-email-toshikazu-n@nec.com> A do_vulnerability() which can run CVE tasks plugged by function variables VULNFUNC_SCAN_CVE, VULNFUNC_JUDGE_CVE and VULNFUNC_REPORT_CVE. Variable VULNFUNC_SCAN_CVE is used for the purpose of CVE search based on CPE (Common Platform Enumeration). A do_vulnerability() decides two CVE statements 'Patched' or 'Unpatched' which are coming from the result of CVE patch searching. However, do_vulnerability() allows VULNFUNC_JUDGE_CVE to change statements. Then plugged function can check CVE statement moreover by using private knowledge information. Now plugged functions are only called for 'Unpatched'. Variable VULNFUNC_REPORT_CVE is used to generate each task's reports. Here are also implemented following CVE functions. cve_assemble_cpe() Assemble CPE (Common Platform Enumeration) from recipe variables. Assembled CPE list is tossed to functions in VULNFUNC_SCAN_CVE. cve_number_sort() Sort CVE with 11 digits CVE number (If shorter than 11, fill with zero). This can be formatted reports with sorted CVE entries within per package. cve_make_git_commitlist() Track accumulated git repository commits from base revision to HEAD and search CVE number in commit log to gather CVE corresponding commits. Gathered commits are compared with CVE number found by VULNFUNC_SCAN_CVE and judge 'Patched' or 'Unpatched'. For example, Linux kernel 5.2 which has been introduced in "linux-yocto: introduce 5.2 recipes" with commit IDs in SRCREV_machine_${MACHINE}s. If set those SRCREV commit IDs to CVE_SRCREV_${MACHINE}s, this function will search CVE kernel commit from CVE_SRCREV to HEAD. cve_make_patchlist() Find CVE patches from every layer SRC_URI directory. Gathered patches are compared with CVE number found by VULNFUNC_SCAN_CVE and judge 'Patched' or 'Unpatched'. This function do the same things as get_patches_cves() which is implemented at meta/cve-check.bbclass. cve_trim_upon_dirs() Trim upper directory path than layer directory to make formatted reports. This is used to specify patch or git repository containing places. Finally vulnerability task publishes per package "vulnerability.summary" and "vulnerability.patchlist" reports. First one is reporting CVE number list and their judgement, second one is reporting only about 'Patched' with their patch or commit information to be found out. Signed-off-by: Toshikazu Nakayama --- meta/classes/vuln-cve.bbclass | 285 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 285 insertions(+) create mode 100644 meta/classes/vuln-cve.bbclass diff --git a/meta/classes/vuln-cve.bbclass b/meta/classes/vuln-cve.bbclass new file mode 100644 index 0000000..0c7b78c --- /dev/null +++ b/meta/classes/vuln-cve.bbclass @@ -0,0 +1,285 @@ +# vulnerability tasks about CVE. + +CPE23[application] = "cpe:2.3:a:" +CPE23[OperatingSystem] = "cpe:2.3:o:" +CPE23[hardware] = "cpe:2.3:h:" +CVE_PART ?= "application" +CVE_VENDOR ??= "${BPN}" +CVE_PRODUCT ??= "${BPN}" +CVE_VERSION ??= "${PV}" +CVE_VERSION_DEPTH ?= "" +## Sub CVE functions +def cve_assemble_cpe(d, vendor_string=None, product_only=False): + """ + Assemble CPE version 2.3 format from corresponding variables. + """ + # Examples for CPE assembler usage (strongly match to CPEv2.3 assignment). + # - apache2 [CVE_VENDOR=apache/CVE_PRODUCT=http_server] + # => cpe:2.3:a:apache:http_server:${PV}: + # - binutils_2.32.0 [CVE_VENDOR=gnu/CVE_VERSION_DEPTH=2] + # => cpe:2.3:a:gnu:binutils:2.32: + # - perl+pathtools_3.73 [CVE_VENDOR=perl/CVE_PRODUCT+=pathtools/ + # CVE_VERSION[pathtools]=3.73] + # => cpe:2.3:a:perl:perl:${PV}:*, cpe:2.3:a:perl:pathtools:3.73:* + # - krb5 [CVE_VENDOR=mit/CVE_PRODUCT='kerberos kerberos_5'/ + # CVE_VERSION[kerberos]=5-${PV}/CVE_VERSION[kerberos_5]=${PV}] + # => cpe:2.3:a:mit:kerberos_5:${PV}:*, cpe:2.3:a:mit:kerberos:5-${PV}:* + # + # Usage about vendor_string or product_only. + # - bash in wrlinux_rcpl-9.0.0.10 [vendor_string=wrlinux/product_only=True] + # => cpe:2.3:a:wrlinux:bash: + # => cpe:2.3:a:wrlinux:bash:9.0.0.10 + # This CPE is not for OE-Core common but for local product's knowledge. + part = d.getVar('CVE_PART', True) + try: + part = d.getVarFlag('CPE23', part, True) + except: + bb.fatal("Unknown CPE target syntax [%s]" % part) + if vendor_string: + vendor = vendor_string + else: + vendor = d.getVar('CVE_VENDOR', True) + cpes = [] + for product in d.getVar('CVE_PRODUCT', True).split(): + if ":" in product: + # Taking care of CVE_PRODUCT format's compatibility + # Priority setting: vendor_string > CVE_PRODUCT > CVE_VENDOR + if not vendor_string: + (vendor, product) = product.split(":", 1) + else: + product = product.split(":", 1)[1] + if product_only: + cpe = "%s%s:%s" % (part, vendor, product) + cpes.append(cpe) + continue + verlist = d.getVarFlag('CVE_VERSION', product, True) + if not verlist: + verlist = d.getVar('CVE_VERSION', True) + for version in verlist.split(): + version = version.split("+git")[0] + depth = d.getVarFlag('CVE_VERSION_DEPTH', product, True) + if not depth: + depth = d.getVar('CVE_VERSION_DEPTH', True) + if depth: + vers = version.split('.') + version = vers[0] + for i in range(1, int(depth)): + version = "%s.%s" % (version, vers[i]) + version = version.lower().replace("-p", ":p") + cpe = "%s%s:%s:%s:*" % (part, vendor, product, version) + cpes.append(cpe) + return cpes + +def cve_number_sort(cveid): + (head, year, number) = list(cveid.split('-')) + return year + number.zfill(7) + +# CVE patch file or git commit +def cve_make_git_commitlist(d, fr, to="HEAD"): + """ + Pick git commit ids about CVE fix from source repository as possible. + """ + if not fr: + return [] + s = d.expand('${S}') + cmd = "cd %s; git whatchanged %s..%s | grep -w ^commit" % (s, fr, to) + (retval, commitlist) = oe.utils.getstatusoutput(cmd) + if retval: + return [] + import re + cve_match = re.compile("CVE\-\d{4}\-\d+") + commits = [] + for commit in commitlist.split("\n"): + meta = commit.split()[1] + cmd = "cd %s; git log -1 %s" % (s, meta) + (retval, commitlog) = oe.utils.getstatusoutput(cmd) + if retval: + continue + cves = [] + for match in cve_match.finditer(commitlog): + for cve in commitlog[match.start():match.end()].split(): + cves.append(cve) + cves = list(set(cves)) + if len(cves) > 0: + shortlog = commitlog.split('\n')[4].strip() + # Marking + d.setVarFlag('CVE_PATCH_TYPE', meta, 'gitmeta') + d.setVarFlag('CVE_PATCH_NAME', meta, shortlog) + d.setVarFlag('CVE_PATCH_WHEREIS', meta, s) + d.setVarFlag('CVE_PATCH_ATTR', meta, meta) + d.setVarFlag('CVE_PATCH_CVES', meta, cves) + commits.append(meta) + return commits + +def cve_make_patchlist(d): + import bb.utils + import re + cve_match = re.compile("CVE:( CVE\-\d{4}\-\d+)+") + cve_file_name_match = re.compile(".*([Cc][Vv][Ee]\-\d{4}\-\d+)") + patches = [] + for url in bb.utils.exec_flat_python_func('src_patches', d): + cves = [] + abspatch = bb.fetch.decodeurl(url)[2] + fname_match = cve_file_name_match.search(abspatch) + if fname_match: + cve = fname_match.group(1).upper() + cves.append(cve) + with open(abspatch, "r", encoding="utf-8") as f: + try: + patch_text = f.read() + except UnicodeDecodeError: + f.close() + with open(patch_file, "r", encoding="iso8859-1") as f: + patch_text = f.read() + # Search for one or more "CVE: " lines + for match in cve_match.finditer(patch_text): + # Get only the CVEs without the "CVE: " tag + for cve in patch_text[match.start()+5:match.end()].split(): + cves.append(cve) + cves = list(set(cves)) + if len(cves) > 0: + md5 = bb.utils.md5_file(abspatch) + patch = os.path.basename(abspatch) + # Marking + d.setVarFlag('CVE_PATCH_TYPE', patch, 'diff') + d.setVarFlag('CVE_PATCH_NAME', patch, patch) + d.setVarFlag('CVE_PATCH_WHEREIS', patch, os.path.dirname(abspatch)) + d.setVarFlag('CVE_PATCH_ATTR', patch, md5) + d.setVarFlag('CVE_PATCH_CVES', patch, cves) + patches.append(patch) + return patches + +def cve_trim_upon_dirs(d, path): + if path.startswith('/'): + items = (path.lstrip('/')).split('/') + else: + items = path.split('/') + layerdir = "" + layers = d.getVar('BBLAYERS', True).split() + for item in items: + layerdir += "/%s" % item + if layerdir in layers: + path = "%s" % item + path.replace(layerdir, '', 1) + break + return path + +## Main task +# Append functions to these variables from its anonymous() in foo.bbclass. +VULNFUNC_SCAN_CVE[type] = 'list' +VULNFUNC_SCAN_CVE = "" +VULNFUNC_JUDGE_CVE = 'list' +VULNFUNC_JUDGE_CVE = "" +VULNFUNC_REPORT_CVE[type] = 'list' +VULNFUNC_REPORT_CVE = "" +python do_vulnerability() { + pn = d.getVar('PN', True) + destdir = os.path.join(d.getVar('VULNSTATEDIR', True), pn) + bb.utils.mkdirhier(destdir) + g = globals() + + cvelist = [] + # Gather potential CVE list by using CPE matching + for scan in (d.getVar('VULNFUNC_SCAN_CVE', True) or "").split(): + if scan in g: + cves = g[scan](d, cve_assemble_cpe(d), destdir) + if len(cves) > 0: + cvelist.extend(cves) + if not cvelist: + return + # Remove duplicated CVEs and sort. + cvelist = list(set(cvelist)) + cvelist = sorted(cvelist, key=cve_number_sort) + + # Gather CVE patches which are going to be applied. + patchlist = [] + if d.getVar('CVE_SRCREV', True): + commits = cve_make_git_commitlist(d, d.getVar('CVE_SRCREV', True)) + if commits: + patchlist.extend(commits) + patches = cve_make_patchlist(d) + if patches: + patchlist.extend(patches) + + # Whether detected CVE is 'Patched' or 'Unpatched' or 'Something by foo's'. + for cveid in cvelist: + cves = [] + for patch in patchlist: + if cveid in d.getVarFlag('CVE_PATCH_CVES', patch, True): + # patch is applied for cveid, populate CVE patch information. + patch_type = d.getVarFlag('CVE_PATCH_TYPE', patch, True) + patch_name = d.getVarFlag('CVE_PATCH_NAME', patch, True) + patch_whereis = d.getVarFlag('CVE_PATCH_WHEREIS', patch, True) + patch_whereis = cve_trim_upon_dirs(d, patch_whereis) + patch_attr = d.getVarFlag('CVE_PATCH_ATTR', patch, True) + if patch_type == 'gitmeta': + cves.append("Commit-log %s" % patch_name) + cves.append(" commitID %s" % patch_attr) + cves.append(" git repository %s" % (patch_whereis)) + cves.append('=' * 60) + else: + cves.append("Patch-name %s" % patch_name) + cves.append(" md5sum %s" % patch_attr) + cves.append(" layer at %s" % patch_whereis) + cves.append('=' * 60) + if len(cves) > 0: + # Patch set for cveid is delivered by. + d.setVarFlag('CVEJUDGE', cveid, "Patched") + d.setVarFlag('CVEDESC', cveid, '\n '.join(cves)) + else: + # Patch set is not found out, set unpatched. + d.setVarFlag('CVEJUDGE', cveid, "Unpatched") + # Try plugin function to resolve CVEJUDGE by using other ways. + for judge in (d.getVar('VULNFUNC_JUDGE_CVE', True) or "").split(): + if judge in g: + g[judge](d, cveid) + continue + + # Make vulnerability report files. + for cveid in cvelist: + with open(os.path.join(destdir, 'cve.summary'), "a") as s: + s.write("%s: %s\n" % (cveid, d.getVarFlag('CVEJUDGE', cveid, True))) + if d.getVarFlag('CVEJUDGE', cveid, True) == "Patched": + with open(os.path.join(destdir, 'cve.patchlist'), "a") as p: + msg = "<%s>\n" % cveid + if d.getVarFlag('CVEDESC', cveid, True): + msg += " %s\n" % d.getVarFlag('CVEDESC', cveid, True) + p.write(msg) + # Make appendix report files. + for report in (d.getVar('VULNFUNC_REPORT_CVE', True) or "").split(): + if report in g: + g[report](d, destdir, cvelist) +} +addtask do_vulnerability after do_patch before do_build +# Some vulnerability plugged tasks tend to prefer calling after do_install +# if called functions require build configuration or binary in their purpose. +# Those are guaranteed after compile($B)/install($D) sections have been done. +# If wants, bbclass can replace task position in its anonymous() constructor. +# For example, foo wants to do_vulnerability after do_install. +# foo.bbclass: __anonymous() +# 1) bb.build.deltask('vulnerability', d) +# 2) bb.build.addtask('vulnerability', None, "do_install", d) +# Note that replacing all thing after build forced, that'll meet unrecoverable +# fatal exception. +# "The file %s is installed by both libgcc and libgcc-initial, aborting" +# This proposal can not guarantee such risks under build dependencies, +# libgcc is staying in blacklist of after do_install() at this moment. + +VULN_CVE_DIRECTORY = "${DEPLOY_DIR}/vuln-cve" +VULNSTATEDIR = "${WORKDIR}/vuln-cve-destdir" +SSTATETASKS += "do_vulnerability" +do_vulnerability[sstate-inputdirs] = "${VULNSTATEDIR}" +do_vulnerability[sstate-outputdirs] = "${VULN_CVE_DIRECTORY}" +do_vulnerability[dir] = "${VULNSTATEDIR}/${PN}" +do_vulnerability[cleandirs] = "${VULNSTATEDIR}" +do_vulnerability[nostamp] = "1" + +python do_vulnerability_setscene() { + sstate_setscene(d) +} +addtask do_vulnerability_setscene +python __anonymous() { + # Exclude possible unnecessary recipes. + pn = d.getVar('PN', True) + if pn.endswith("-native") or pn.startswith("nativesdk-") or "-cross-" in pn or "-crosssdk" in pn: + bb.build.deltask('vulnerability', d) +} -- 2.7.4 From andrej.valek at siemens.com Mon Mar 9 08:05:35 2020 From: andrej.valek at siemens.com (Andrej Valek) Date: Mon, 9 Mar 2020 09:05:35 +0100 Subject: [OE-core] [PATCH 0/2] Extensible SDK improvements In-Reply-To: References: <20200306153234.23875-1-andrej.valek@siemens.com> Message-ID: Hello Richard, I can try to explain it in some examples. I would like to add some extra (dynamic) variables into local.conf in eSDK mode. I have found, that there are 2 possibilities (in populate_sdk_ext.bbclass) sdk-extra.conf and sdk_extraconf. - sdk-extra.conf - You have to have handle own function to write into sdk-extra.conf. I think, this is not the right way for me. - sdk_extraconf - This variable is fine, but there are some restrictions. There is no easy way to add multiple variables including values. I would like to have: aaa = "valueA" bbb = "valueB" in local.conf file. 1. sdk_extraconf = 'aaa = "valueA"\nbbb = "valueB"' - this will write aaa = "valueA"\nbbb = "valueB" 2. python copy_buildsystem_prepend() { d.setVar('sdk_extraconf','aaa = "valueA"\nbbb = "valueB"') } - This will write exactly, what you want, but you have to have an copy_buildsystem_prepend and mentioned all variables with values defined in your class/recipe. 3. sdk_extraconf = "# My notes about local.conf" - Yes, you can write some string into local.conf with this way. So I have founded an way, how to add multiple variables without explicitly specifying their values. # format variables for sdk_extraconf def write_sdk_vars(d): return '\n' + '\n'.join([var + ' = "' + d.getVar(var) + '"' for var in d.getVar('SDK_EXTRACONF_VARS').split()]) SDK_EXTRACONF_VARS = "aaa bbb" sdk_extraconf_append = " ${@write_sdk_vars(d)}" It will do exactly what I want, but this way is little bit nasty. So I have created a more complex solution for community usage. I think, this patch adds more functionality also for other projects. They can add only variables into list and the class will handle all the rest. Is it enough for the explanation? Regards, Andrej On 2020-03-06 18:16, Richard Purdie wrote: > On Fri, 2020-03-06 at 16:32 +0100, Andrej Valek wrote: >> "add option to append lines into local.conf": >> - What about dropping "sdk_extraconf"? > > I'm curious what you didn't find useful about the other format and why > this version is better? > > Cheers, > > Richard > From alex.kanavin at gmail.com Mon Mar 9 09:53:07 2020 From: alex.kanavin at gmail.com (Alexander Kanavin) Date: Mon, 9 Mar 2020 10:53:07 +0100 Subject: [OE-core] [Openembedded-architecture] Does YP provide security support for stable and LTS branches? In-Reply-To: References: <20200304113217.GB7923@localhost> <20200304140109.GC7923@localhost> <20200304172415.GA29456@localhost> <01b3bb37-f65f-8048-1a27-b859b62d7f98@gmail.com> <20200306100422.GA17785@localhost> <877e317932176664bc7b0120439c56d4dda791af.camel@linuxfoundation.org> <20200308214610.GB1425@localhost> <20200309002308.GD1425@localhost> Message-ID: The intent is to say that security patches are eligible for inclusion into stable release updates (while e.g. version updates are not). If the wording is vague, it can be improved. I tend to agree that there has to be a more clear message that users must set up their own security process or pay someone to do it (especially considering that most products involve a lot more 3rd party layers and not just oe-core). Some of the fixing work can be reused from upstream but there is no promise that it covers everything. Alex On Mon 9. Mar 2020 at 8.45, Ayoub Zaki wrote: > Hello, > > On 09.03.20 01:23, Adrian Bunk wrote: > > On Sun, Mar 08, 2020 at 11:08:08PM +0100, Alexander Kanavin wrote: > >> On Sun, 8 Mar 2020 at 22:46, Adrian Bunk wrote: > >> > >>> It is on YP to make it clear to users whether or not Yocto comes with > >>> the same set of security guarantees as distributions like Ubuntu or > >>> Debian. > >>> If it is the duty of every user of Yocto to track and fix CVEs, > >>> then this has to be stated clearly instead of implying the opposite. > >>> This gives users the opportunity to mitigate, instead of unknowingly > >>> shipping insecure products. > >>> > >> Do you have any actual evidence for actual users shipping insecure > products > >> because they mistakenly believe Yocto takes care of security for them? > > Nothing to discuss in public. > > > >> This > >> has been the situation from the start of the project, certainly this was > >> the case 5 years ago when I joined it, and the only person ever to make > an > >> issue out of it is you. Everyone else seems to understand the deal > they're > >> getting by using Yocto without a commercial support contract. > >> ... > > You are saying that 'track and fix CVEs' is on users. > > Let's check what YP is telling users. > > > > Click on the "Is Yocto Project for you?" link on the YP frontpage: > > > > https://www.yoctoproject.org/is-yocto-project-for-you/ > > 13. Yocto Project follows a strict release schedule incorporating > > security patches in all supported releases. This predictability is > > crucial for projects that are based on Yocto Project and allows the > > development teams to plan their activities. Developers can choose which > > Yocto Project branch on which to base their activities as a function of > > their needs. The development branch will ensure access to the latest > > features while the stable branches will reduce the pace of changes. CVEs > > (common vulnerabilities and exposures) issues are supported for the > > latest 2 releases. > > > Adrian is making a point here, The Yocto Project by claiming that it > supports security patches for Stable releases is misleading the Users! > > I work with different customers and some of them think that by using and > pulling the latest releases they will get the CVEs automatically fixed! > > YP should state that CLEARLY! Of course it will impact the choice of > going with Yocto or Not ( probably NOT in this case). > > > > > > >> Alex > > cu > > Adrian > > Mit freundlichen Gr??en / Kind regards > > -- > Ayoub Zaki > Embedded Systems Consultant > > Vaihinger Stra?e 2/1 > D-71634 Ludwigsburg > > > Mobile : +4917662901545 > Email : ayoub.zaki at embexus.com > Homepage : https://embexus.com > VAT No. : DE313902634 > > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core at lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core > -------------- next part -------------- An HTML attachment was scrubbed... URL: From persaur at gmail.com Mon Mar 9 10:01:21 2020 From: persaur at gmail.com (Rich Persaud) Date: Mon, 9 Mar 2020 06:01:21 -0400 Subject: [OE-core] [Openembedded-architecture] Does YP provide security support for stable and LTS branches? Message-ID: ? On Mar 9, 2020, at 03:45, Ayoub Zaki wrote: >> Nothing to discuss in public. >> >>> This >>> has been the situation from the start of the project, certainly this was >>> the case 5 years ago when I joined it, and the only person ever to make an >>> issue out of it is you. Everyone else seems to understand the deal they're >>> getting by using Yocto without a commercial support contract. >>> ... >> You are saying that 'track and fix CVEs' is on users. >> Let's check what YP is telling users. >> >> Click on the "Is Yocto Project for you?" link on the YP frontpage: >> >> https://www.yoctoproject.org/is-yocto-project-for-you/ >> 13. Yocto Project follows a strict release schedule incorporating >> security patches in all supported releases. This predictability is >> crucial for projects that are based on Yocto Project and allows the >> development teams to plan their activities. Developers can choose which >> Yocto Project branch on which to base their activities as a function of >> their needs. The development branch will ensure access to the latest >> features while the stable branches will reduce the pace of changes. CVEs >> (common vulnerabilities and exposures) issues are supported for the >> latest 2 releases. > > > Adrian is making a point here, The Yocto Project by claiming that it supports security patches for Stable releases is misleading the Users! > > I work with different customers and some of them think that by using and pulling the latest releases they will get the CVEs automatically fixed! > > YP should state that CLEARLY! Of course it will impact the choice of going with Yocto or Not ( probably NOT in this case). Would the Yocto mailing list [1] be a good venue to reach the maintainers of the Yocto website? There are now a handful of OE-arch / OE-core threads on this topic, which could be consolidated into a single thread on the Yocto list, where participants can act on recommendations. Rich [1] https://lists.yoctoproject.org/g/yocto -------------- next part -------------- An HTML attachment was scrubbed... URL: From persaur at gmail.com Mon Mar 9 10:01:47 2020 From: persaur at gmail.com (Rich Persaud) Date: Mon, 9 Mar 2020 06:01:47 -0400 Subject: [OE-core] [Openembedded-architecture] buildtools-extended-tarball wrapping builds Message-ID: <0C4A6E55-81B1-4AC1-B143-19AED076F2F4@gmail.com> On Mar 7, 2020, at 11:17, Richard Purdie wrote: > ?Hi, > > I just wanted to mention that we now have the ability to wrap builds on > specific workers with specific buildtools tarballs. > > Currently this functionality is in master, we do have the option of > porting the helper code to other stable branches. > > We have had multiple issues, with the infrastucture internal url/cert > handling, git/cert environment issues, an issue with eSDK testing (next > has a fix in testing), the crypt fix already submitted (meaning M2's > tarball doesn't help) and so on, I'm hoping we've gotten to the bottom > of those. > > This does mean we could drop gcc 4.8/4.9 support if we wanted to and > rely on the tarball support for centos7/debian8. I'm torn on that, we > are still missing: > > a) Support for wrapping a build with buildtools more auotmatically > (like we do with uninative) > > b) documentation of buildtools-extended-tarball This would be valuable to wrap older Haskell [1] and Ocaml [2] compilers, which are often challenging to support with newer versions of OE. I've tested buildtools-extended-tarball with an OpenXT build, but we would need to use an older tarball for the Haskell/Ocaml native compilers. Rich [1] https://github.com/OpenXT/meta-openxt-haskell-platform [2] https://github.com/OpenXT/meta-openxt-ocaml-platform -------------- next part -------------- An HTML attachment was scrubbed... URL: From bunk at stusta.de Mon Mar 9 10:52:40 2020 From: bunk at stusta.de (Adrian Bunk) Date: Mon, 9 Mar 2020 12:52:40 +0200 Subject: [OE-core] [Openembedded-architecture] buildtools-extended-tarball wrapping builds In-Reply-To: References: Message-ID: <20200309105240.GA2477@localhost> On Sat, Mar 07, 2020 at 04:17:28PM +0000, Richard Purdie wrote: >... > This does mean we could drop gcc 4.8/4.9 support if we wanted to and > rely on the tarball support for centos7/debian8. >... Debian 8 - will have LTS support ending at the end of June, and - ships Python 3.4, which is no longer supported by bitbake. 3 months ago Yocto master stopped working on Debian 8, and as expected noone complained. > Cheers, > > Richard cu Adrian From richard.purdie at linuxfoundation.org Mon Mar 9 11:41:13 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Mon, 09 Mar 2020 11:41:13 +0000 Subject: [OE-core] [Openembedded-architecture] buildtools-extended-tarball wrapping builds In-Reply-To: <20200309105240.GA2477@localhost> References: <20200309105240.GA2477@localhost> Message-ID: On Mon, 2020-03-09 at 12:52 +0200, Adrian Bunk wrote: > On Sat, Mar 07, 2020 at 04:17:28PM +0000, Richard Purdie wrote: > > ... > > This does mean we could drop gcc 4.8/4.9 support if we wanted to > > and > > rely on the tarball support for centos7/debian8. > > ... > > Debian 8 > - will have LTS support ending at the end of June, and > - ships Python 3.4, which is no longer supported by bitbake. > > 3 months ago Yocto master stopped working on Debian 8, > and as expected noone complained. We still have one debian8 autobuilder worker: https://autobuilder.yoctoproject.org/typhoon/#/workers/9 and with buildtools tarball it works 'fine'. Cheers, Richard From wallinux at gmail.com Mon Mar 9 11:48:21 2020 From: wallinux at gmail.com (Anders Wallin) Date: Mon, 9 Mar 2020 12:48:21 +0100 Subject: [OE-core] [PATCH v2] babeltrace2: added first version, 2.0.1 In-Reply-To: References: <20200305120629.329-1-wallinux@gmail.com> Message-ID: I will check/fix it Anders Wallin On Sat, Mar 7, 2020 at 3:17 PM Khem Raj wrote: > I am seeing a QA textrel issue with clang/arm > > http://errors.yoctoproject.org/Errors/Details/393983/ > > On Thu, Mar 5, 2020 at 4:07 AM Anders Wallin wrote: > > > > Babeltrace 1 vs. Babeltrace 2 > > > > The Babeltrace project exists since 2010. In 2020, Babeltrace 2 was > released. > > Babeltrace 2 is a complete rewrite of the library, Python bindings, and > CLI. It > > is plugin based and offers much more features and potential than > Babeltrace 1. > > > > Because Babeltrace 2 is still a young released project, some > distributions still > > provide packages for the Babeltrace 1 project. Both projects can coexist > on the > > same system as there are no common installed files. > > > > Signed-off-by: Anders Wallin > > --- > > meta/conf/distro/include/distro_alias.inc | 1 + > > meta/conf/distro/include/maintainers.inc | 1 + > > .../distro/include/ptest-packagelists.inc | 1 + > > .../packagegroup-core-tools-profile.bb | 2 + > > ...not-run-test-applications-from-.libs.patch | 28 ++++++ > > .../lttng/babeltrace2/run-ptest | 9 ++ > > .../recipes-kernel/lttng/babeltrace2_2.0.1.bb | 92 +++++++++++++++++++ > > 7 files changed, 134 insertions(+) > > create mode 100644 > meta/recipes-kernel/lttng/babeltrace2/0001-tests-do-not-run-test-applications-from-.libs.patch > > create mode 100755 meta/recipes-kernel/lttng/babeltrace2/run-ptest > > create mode 100644 meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb > > > > diff --git a/meta/conf/distro/include/distro_alias.inc > b/meta/conf/distro/include/distro_alias.inc > > index 79ebcaee29..0e4a9a9f8f 100644 > > --- a/meta/conf/distro/include/distro_alias.inc > > +++ b/meta/conf/distro/include/distro_alias.inc > > @@ -15,6 +15,7 @@ DISTRO_PN_ALIAS_pn-alsa-utils-scripts = "OE-Core" > > DISTRO_PN_ALIAS_pn-atk = "Fedora=atk OpenSuSE=atk" > > DISTRO_PN_ALIAS_pn-avahi-ui = "Ubuntu=avahi-discover > Debian=avahi-discover" > > DISTRO_PN_ALIAS_pn-babeltrace = "OSPDT" > > +DISTRO_PN_ALIAS_pn-babeltrace2 = "OSPDT" > > DISTRO_PN_ALIAS_pn-bjam = "OpenSuSE=boost-jam Debian=bjam" > > DISTRO_PN_ALIAS_pn-blktool = "Debian=blktool Mandriva=blktool" > > DISTRO_PN_ALIAS_pn-bluez5 = "Fedora=bluez Opensuse=bluez" > > diff --git a/meta/conf/distro/include/maintainers.inc > b/meta/conf/distro/include/maintainers.inc > > index 10095ffe76..adb18228e7 100644 > > --- a/meta/conf/distro/include/maintainers.inc > > +++ b/meta/conf/distro/include/maintainers.inc > > @@ -59,6 +59,7 @@ RECIPE_MAINTAINER_pn-automake = "Robert Yang < > liezhi.yang at windriver.com>" > > RECIPE_MAINTAINER_pn-avahi = "Yi Zhao " > > RECIPE_MAINTAINER_pn-avahi-ui = "Yi Zhao " > > RECIPE_MAINTAINER_pn-babeltrace = "Alexander Kanavin < > alex.kanavin at gmail.com>" > > +RECIPE_MAINTAINER_pn-babeltrace2 = "Alexander Kanavin < > alex.kanavin at gmail.com>" > > RECIPE_MAINTAINER_pn-base-files = "Anuj Mittal " > > RECIPE_MAINTAINER_pn-base-passwd = "Anuj Mittal >" > > RECIPE_MAINTAINER_pn-bash = "Hongxu Jia " > > diff --git a/meta/conf/distro/include/ptest-packagelists.inc > b/meta/conf/distro/include/ptest-packagelists.inc > > index 4afac58e3a..d6f3aafc7f 100644 > > --- a/meta/conf/distro/include/ptest-packagelists.inc > > +++ b/meta/conf/distro/include/ptest-packagelists.inc > > @@ -64,6 +64,7 @@ PTESTS_FAST = "\ > > > > PTESTS_SLOW = "\ > > babeltrace-ptest \ > > + babeltrace2-ptest \ > > busybox-ptest \ > > dbus-test-ptest \ > > e2fsprogs-ptest \ > > diff --git a/meta/recipes-core/packagegroups/ > packagegroup-core-tools-profile.bb b/meta/recipes-core/packagegroups/ > packagegroup-core-tools-profile.bb > > index 984c2fac92..ac180b542a 100644 > > --- a/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb > > +++ b/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb > > @@ -46,6 +46,7 @@ LTTNGMODULES = "lttng-modules" > > LTTNGMODULES_arc = "" > > > > BABELTRACE = "babeltrace" > > +BABELTRACE2 = "babeltrace2" > > > > # valgrind does not work on the following configurations/architectures > > > > @@ -69,6 +70,7 @@ RDEPENDS_${PN} = "\ > > ${LTTNGTOOLS} \ > > ${LTTNGMODULES} \ > > ${BABELTRACE} \ > > + ${BABELTRACE2} \ > > ${SYSTEMTAP} \ > > ${VALGRIND} \ > > " > > diff --git > a/meta/recipes-kernel/lttng/babeltrace2/0001-tests-do-not-run-test-applications-from-.libs.patch > b/meta/recipes-kernel/lttng/babeltrace2/0001-tests-do-not-run-test-applications-from-.libs.patch > > new file mode 100644 > > index 0000000000..805dde8064 > > --- /dev/null > > +++ > b/meta/recipes-kernel/lttng/babeltrace2/0001-tests-do-not-run-test-applications-from-.libs.patch > > @@ -0,0 +1,28 @@ > > +From 582713cc9a013481eeef253195d644020f637ec4 Mon Sep 17 00:00:00 2001 > > +Message-Id: < > 582713cc9a013481eeef253195d644020f637ec4.1583403622.git.wallinux at gmail.com > > > > +From: Anders Wallin > > +Date: Thu, 5 Mar 2020 11:20:04 +0100 > > +Subject: [PATCH] tests: do not run test applications from .libs > > + > > +Cross compile specific change > > + > > +Upstream-Status: Inappropriate [oe-core specific] > > + > > +Signed-off-by: Anders Wallin > > +--- > > + tests/lib/test_plugin | 2 +- > > + 1 file changed, 1 insertion(+), 1 deletion(-) > > + > > +diff --git a/tests/lib/test_plugin b/tests/lib/test_plugin > > +index 652c90cc..1f817c50 100755 > > +--- a/tests/lib/test_plugin > > ++++ b/tests/lib/test_plugin > > +@@ -26,4 +26,4 @@ fi > > + # shellcheck source=../utils/utils.sh > > + source "$UTILSSH" > > + > > +-"${BT_TESTS_BUILDDIR}/lib/plugin" > "${BT_TESTS_BUILDDIR}/lib/test-plugin-plugins/.libs" > > ++"${BT_TESTS_BUILDDIR}/lib/plugin" > "${BT_TESTS_BUILDDIR}/lib/test-plugin-plugins" > > +-- > > +2.25.1 > > + > > diff --git a/meta/recipes-kernel/lttng/babeltrace2/run-ptest > b/meta/recipes-kernel/lttng/babeltrace2/run-ptest > > new file mode 100755 > > index 0000000000..72fe223436 > > --- /dev/null > > +++ b/meta/recipes-kernel/lttng/babeltrace2/run-ptest > > @@ -0,0 +1,9 @@ > > +#!/bin/sh > > +# use target=recheck if you want to recheck failing tests > > +[ "$target" = "" ] && target=check > > + > > +# Without --ignore-exit, the tap harness causes any FAILs within a > > +# test plan to raise ERRORs; this is just noise. > > +makeargs="LOG_DRIVER_FLAGS=--ignore-exit abs_top_srcdir=$PWD > abs_top_builddir=$PWD GREP=grep SED=sed PYTHON=python3" > > + > > +exec make -C tests -k -s $makeargs $target 2>/dev/null > > diff --git a/meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb > b/meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb > > new file mode 100644 > > index 0000000000..16953d6807 > > --- /dev/null > > +++ b/meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb > > @@ -0,0 +1,92 @@ > > +SUMMARY = "Babeltrace2 - Trace Format Babel Tower" > > +DESCRIPTION = "Babeltrace provides trace read and write libraries in > host side, as well as a trace converter, which used to convert LTTng 2.0 > traces into human-readable log." > > +HOMEPAGE = "http://babeltrace.org/" > > +BUGTRACKER = "https://bugs.lttng.org/projects/babeltrace" > > +LICENSE = "MIT & GPLv2 & LGPLv2.1 & BSD-2-Clause" > > +LIC_FILES_CHKSUM = "file://LICENSE;md5=a6a458c13f18385b7bc5069a6d7b176e" > > + > > +DEPENDS = "glib-2.0 util-linux popt bison-native flex-native" > > + > > +SRC_URI = "git:// > git.linuxfoundation.org/diamon/babeltrace.git;branch=stable-2.0 \ > > + file://run-ptest \ > > + > file://0001-tests-do-not-run-test-applications-from-.libs.patch \ > > + " > > +SRCREV = "06df58f89ee51b1a2c6a2c187ec3f15691633910" > > +UPSTREAM_CHECK_GITTAGREGEX = "v(?P2(\.\d+)+)$" > > + > > +S = "${WORKDIR}/git" > > + > > +inherit autotools pkgconfig ptest > > + > > +EXTRA_OECONF = "--disable-debug-info" > > + > > +PACKAGECONFIG ??= "manpages" > > +PACKAGECONFIG[manpages] = ", --disable-man-pages, asciidoc-native > xmlto-native" > > + > > +FILES_${PN}-staticdev += "${libdir}/babeltrace2/plugins/*.a" > > +FILES_${PN} += "${libdir}/babeltrace2/plugins/*.so" > > + > > +ASNEEDED = "" > > + > > +RDEPENDS_${PN}-ptest += "bash gawk python3" > > + > > +do_compile_ptest () { > > + make -C tests all > > +} > > + > > +do_install_ptest () { > > + install -d "${D}${PTEST_PATH}/tests" > > + > > + # Copy required files from source directory > > + for d in $(find "${S}/tests" -type d -printf '%P ') ; do > > + install -d "${D}${PTEST_PATH}/tests/$d" > > + find "${S}/tests/$d" -maxdepth 1 -executable -type f \ > > + -exec install -t "${D}${PTEST_PATH}/tests/$d" {} + > > + find "${S}/tests/$d" -maxdepth 1 -name *.sh \ > > + -exec install -t "${D}${PTEST_PATH}/tests/$d" {} \; > > + find "${S}/tests/$d" -maxdepth 1 -name *.py \ > > + -exec install -t "${D}${PTEST_PATH}/tests/$d" {} \; > > + find "${S}/tests/$d" -maxdepth 1 -name *.expect \ > > + -exec install -t "${D}${PTEST_PATH}/tests/$d" {} \; > > + done > > + install -d "${D}${PTEST_PATH}/tests/data/ctf-traces/" > > + cp -a ${S}/tests/data/ctf-traces/* > ${D}${PTEST_PATH}/tests/data/ctf-traces/ > > + > > + # Copy the tests directory tree and the executables and > > + # Makefiles found within. > > + install -D "${B}/tests/Makefile" "${D}${PTEST_PATH}/tests/" > > + for d in $(find "${B}/tests" -type d -not -name .libs -printf '%P > ') ; do > > + install -d "${D}${PTEST_PATH}/tests/$d" > > + find "${B}/tests/$d" -maxdepth 1 -executable -type f \ > > + -exec install -t "${D}${PTEST_PATH}/tests/$d" {} + > > + test -r "${B}/tests/$d/Makefile" && \ > > + install -t "${D}${PTEST_PATH}/tests/$d" > "${B}/tests/$d/Makefile" > > + find "${B}/tests/$d" -maxdepth 1 -name *.sh \ > > + -exec install -t "${D}${PTEST_PATH}/tests/$d" {} \; > > + done > > + > > + for d in $(find "${B}/tests" -type d -name .libs -printf '%P ') ; do > > + for f in $(find "${B}/tests/$d" -maxdepth 1 -executable -type f > -printf '%P ') ; do > > + cp ${B}/tests/$d/$f ${D}${PTEST_PATH}/tests/`dirname $d`/$f > > + done > > + done > > + > > + # Prevent attempts to update Makefiles during test runs, and > > + # silence "Making check in $SUBDIR" messages. > > + find "${D}${PTEST_PATH}" -name Makefile -type f -exec \ > > + sed -i \ > > + -e '/Makefile:/,/^$/d' \ > > + -e '/%: %.in/,/^$/d' \ > > + -e '/echo "Making $$target in $$subdir"; \\/d' \ > > + -e 's/^srcdir = \(.*\)/srcdir = ./' \ > > + -e 's/^builddir = \(.*\)/builddir = ./' \ > > + -e 's/^all-am:.*/all-am:/' \ > > + {} + > > + > > + # Substitute links to installed binaries. > > + install -d "${D}${PTEST_PATH}/src/cli/" > > + ln -s "${bindir}/babeltrace2" ${D}${PTEST_PATH}/src/cli/ > > + > > + # Remove architechture specific testfiles > > + rm -rf > ${D}${PTEST_PATH}/tests/data/plugins/flt.lttng-utils.debug-info/* > > +} > > -- > > 2.25.1 > > > > -- > > _______________________________________________ > > Openembedded-core mailing list > > Openembedded-core at lists.openembedded.org > > http://lists.openembedded.org/mailman/listinfo/openembedded-core > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bunk at stusta.de Mon Mar 9 12:08:06 2020 From: bunk at stusta.de (Adrian Bunk) Date: Mon, 9 Mar 2020 14:08:06 +0200 Subject: [OE-core] [Openembedded-architecture] buildtools-extended-tarball wrapping builds In-Reply-To: References: <20200309105240.GA2477@localhost> Message-ID: <20200309120806.GB2477@localhost> On Mon, Mar 09, 2020 at 11:41:13AM +0000, Richard Purdie wrote: > On Mon, 2020-03-09 at 12:52 +0200, Adrian Bunk wrote: > > On Sat, Mar 07, 2020 at 04:17:28PM +0000, Richard Purdie wrote: > > > ... > > > This does mean we could drop gcc 4.8/4.9 support if we wanted to > > > and > > > rely on the tarball support for centos7/debian8. > > > ... > > > > Debian 8 > > - will have LTS support ending at the end of June, and > > - ships Python 3.4, which is no longer supported by bitbake. > > > > 3 months ago Yocto master stopped working on Debian 8, > > and as expected noone complained. > > We still have one debian8 autobuilder worker: > > https://autobuilder.yoctoproject.org/typhoon/#/workers/9 > > and with buildtools tarball it works 'fine'. Ah right, buildtools tarball ships python3. So yes, this invalidates my second point. > Cheers, > > Richard cu Adrian From richard.purdie at linuxfoundation.org Mon Mar 9 12:45:36 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Mon, 09 Mar 2020 12:45:36 +0000 Subject: [OE-core] [Openembedded-architecture] Does YP provide security support for stable and LTS branches? In-Reply-To: References: <20200304113217.GB7923@localhost> <20200304140109.GC7923@localhost> <20200304172415.GA29456@localhost> <01b3bb37-f65f-8048-1a27-b859b62d7f98@gmail.com> <20200306100422.GA17785@localhost> <877e317932176664bc7b0120439c56d4dda791af.camel@linuxfoundation.org> <20200308214610.GB1425@localhost> <20200309002308.GD1425@localhost> Message-ID: <7146d504e980757c2aea543626defbbd0e5037d1.camel@linuxfoundation.org> On Mon, 2020-03-09 at 08:29 +0100, Ayoub Zaki wrote: > On 09.03.20 01:23, Adrian Bunk wrote: > > On Sun, Mar 08, 2020 at 11:08:08PM +0100, Alexander Kanavin wrote: > > > On Sun, 8 Mar 2020 at 22:46, Adrian Bunk wrote: > > https://www.yoctoproject.org/is-yocto-project-for-you/ > > 13. Yocto Project follows a strict release schedule incorporating > > security patches in all supported releases. This predictability is > > crucial for projects that are based on Yocto Project and allows the > > development teams to plan their activities. Developers can choose > > which > > Yocto Project branch on which to base their activities as a > > function of > > their needs. The development branch will ensure access to the > > latest > > features while the stable branches will reduce the pace of changes. > > CVEs > > (common vulnerabilities and exposures) issues are supported for the > > latest 2 releases. > > Adrian is making a point here, The Yocto Project by claiming that it > supports security patches for Stable releases is misleading the > Users! > > I work with different customers and some of them think that by using > and pulling the latest releases they will get the CVEs automatically > fixed! If you use our latest codebase then you get the latest usptream versions and hence, yes, you get the fixes. It does depend what "latest" means in the contents of your comments above. For the stable series we're putting in a commitment to review and include CVE fixes which are submitted to us. We have a pretty good track record of having them submitted and included. That said, we cannot write a guarantee than all CVE fixes will be included, we're an open source project, not a company with an engineering team or a project with the scale of say Debian. > YP should state that CLEARLY! Of course it will impact the choice of > going with Yocto or Not ( probably NOT in this case). I agree we have to set realistic expectations, not entirely sure how to do that but hope the above clarifies whilst we try and update the docs/web pages and so on. Cheers, Richard From pbarker at konsulko.com Mon Mar 9 14:21:34 2020 From: pbarker at konsulko.com (Paul Barker) Date: Mon, 9 Mar 2020 14:21:34 +0000 Subject: [OE-core] [PATCH 0/5] Archiver and externalsrc fixes Message-ID: <20200309142139.15741-1-pbarker@konsulko.com> These changes fix the archival of git submodules, do_deploy_archives dependencies and externalsrc support for the kernel. The gitsm archiver fix is independent of the patch sent to bitbake - the patch here fixes the generation of archives for git submodules, the separate bitbake patch fixes the use of gitsm shallow mirror tarballs whether generated by the archiver or just by copying them from DL_DIR. I know we're in feature freeze but all of these patches fix specific errors which exist on both zeus and master. I recommend backporting all of these to zeus once committed to master. Paul Barker (5): archiver.bbclass: Handle gitsm URLs in the mirror archiver archiver.bbclass: Make do_deploy_archives a recursive dependency kernelsrc.bbclass: Fix externalsrc support perf: Fix externalsrc support kernel-yocto.bbclass: Support config fragments with externalsrc meta/classes/archiver.bbclass | 35 +++++++++++++++++++++++++------ meta/classes/kernel-yocto.bbclass | 3 ++- meta/classes/kernelsrc.bbclass | 2 +- meta/recipes-kernel/perf/perf.bb | 2 +- 4 files changed, 33 insertions(+), 9 deletions(-) -- 2.20.1 From pbarker at konsulko.com Mon Mar 9 14:21:35 2020 From: pbarker at konsulko.com (Paul Barker) Date: Mon, 9 Mar 2020 14:21:35 +0000 Subject: [OE-core] [PATCH 1/5] archiver.bbclass: Handle gitsm URLs in the mirror archiver In-Reply-To: <20200309142139.15741-1-pbarker@konsulko.com> References: <20200309142139.15741-1-pbarker@konsulko.com> Message-ID: <20200309142139.15741-2-pbarker@konsulko.com> To fully archive a `gitsm://` entry in SRC_URI we need to also capture the submodules recursively. If shallow mirror tarballs are found, they must be temporarily extracted so that the submodules can be determined. Signed-off-by: Paul Barker --- meta/classes/archiver.bbclass | 31 ++++++++++++++++++++++++++----- 1 file changed, 26 insertions(+), 5 deletions(-) diff --git a/meta/classes/archiver.bbclass b/meta/classes/archiver.bbclass index 013195df7d..fef7ad4f62 100644 --- a/meta/classes/archiver.bbclass +++ b/meta/classes/archiver.bbclass @@ -306,7 +306,7 @@ python do_ar_configured() { } python do_ar_mirror() { - import subprocess + import shutil, subprocess, tempfile src_uri = (d.getVar('SRC_URI') or '').split() if len(src_uri) == 0: @@ -337,12 +337,10 @@ python do_ar_mirror() { bb.utils.mkdirhier(destdir) - fetcher = bb.fetch2.Fetch(src_uri, d) - - for url in fetcher.urls: + def archive_url(fetcher, url): if is_excluded(url): bb.note('Skipping excluded url: %s' % (url)) - continue + return bb.note('Archiving url: %s' % (url)) ud = fetcher.ud[url] @@ -376,6 +374,29 @@ python do_ar_mirror() { bb.note('Copying source mirror') cmd = 'cp -fpPRH %s %s' % (localpath, destdir) subprocess.check_call(cmd, shell=True) + + if url.startswith('gitsm://'): + def archive_submodule(ud, url, module, modpath, workdir, d): + url += ";bareclone=1;nobranch=1" + newfetch = bb.fetch2.Fetch([url], d, cache=False) + + for url in newfetch.urls: + archive_url(newfetch, url) + + # If we're using a shallow mirror tarball it needs to be unpacked + # temporarily so that we can examine the .gitmodules file + if ud.shallow and os.path.exists(ud.fullshallow) and ud.method.need_update(ud, d): + tmpdir = tempfile.mkdtemp(dir=d.getVar("DL_DIR")) + subprocess.check_call("tar -xzf %s" % ud.fullshallow, cwd=tmpdir, shell=True) + ud.method.process_submodules(ud, tmpdir, archive_submodule, d) + shutil.rmtree(tmpdir) + else: + ud.method.process_submodules(ud, ud.clonedir, archive_submodule, d) + + fetcher = bb.fetch2.Fetch(src_uri, d, cache=False) + + for url in fetcher.urls: + archive_url(fetcher, url) } def exclude_useless_paths(tarinfo): -- 2.20.1 From pbarker at konsulko.com Mon Mar 9 14:21:36 2020 From: pbarker at konsulko.com (Paul Barker) Date: Mon, 9 Mar 2020 14:21:36 +0000 Subject: [OE-core] [PATCH 2/5] archiver.bbclass: Make do_deploy_archives a recursive dependency In-Reply-To: <20200309142139.15741-1-pbarker@konsulko.com> References: <20200309142139.15741-1-pbarker@konsulko.com> Message-ID: <20200309142139.15741-3-pbarker@konsulko.com> To ensure that archives are captured for all dependencies of a typical bitbake build we add do_deploy_archives to the list of recursive dependencies of do_build. Without this, archives may be missed for recipes such as gcc-source which do not create packages or populate a sysroot. do_deploy_archives is also added to the recursive dependencies of do_populate_sdk so that all sources required for an SDK can be captured. Signed-off-by: Paul Barker --- meta/classes/archiver.bbclass | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/meta/classes/archiver.bbclass b/meta/classes/archiver.bbclass index fef7ad4f62..c11d36d708 100644 --- a/meta/classes/archiver.bbclass +++ b/meta/classes/archiver.bbclass @@ -604,7 +604,9 @@ addtask do_ar_configured after do_unpack_and_patch addtask do_ar_mirror after do_fetch addtask do_dumpdata addtask do_ar_recipe -addtask do_deploy_archives before do_build +addtask do_deploy_archives +do_build[recrdeptask] += "do_deploy_archives" +do_populate_sdk[recrdeptask] += "do_deploy_archives" python () { # Add tasks in the correct order, specifically for linux-yocto to avoid race condition. -- 2.20.1 From pbarker at konsulko.com Mon Mar 9 14:21:37 2020 From: pbarker at konsulko.com (Paul Barker) Date: Mon, 9 Mar 2020 14:21:37 +0000 Subject: [OE-core] [PATCH 3/5] kernelsrc.bbclass: Fix externalsrc support In-Reply-To: <20200309142139.15741-1-pbarker@konsulko.com> References: <20200309142139.15741-1-pbarker@konsulko.com> Message-ID: <20200309142139.15741-4-pbarker@konsulko.com> When the externalsrc class is used the tasks listed in SRCTREECOVEREDTASKS are deleted to prevent them being executed. If externalsrc is used for the kernel then this will include virtual/kernel:do_patch. We can depend on do_shared_workdir instead as this will survive when externalsrc is used. Signed-off-by: Paul Barker --- meta/classes/kernelsrc.bbclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/classes/kernelsrc.bbclass b/meta/classes/kernelsrc.bbclass index 675d40ec9a..a951ba3325 100644 --- a/meta/classes/kernelsrc.bbclass +++ b/meta/classes/kernelsrc.bbclass @@ -1,7 +1,7 @@ S = "${STAGING_KERNEL_DIR}" deltask do_fetch deltask do_unpack -do_patch[depends] += "virtual/kernel:do_patch" +do_patch[depends] += "virtual/kernel:do_shared_workdir" do_patch[noexec] = "1" do_package[depends] += "virtual/kernel:do_populate_sysroot" KERNEL_VERSION = "${@get_kernelversion_file("${STAGING_KERNEL_BUILDDIR}")}" -- 2.20.1 From pbarker at konsulko.com Mon Mar 9 14:21:38 2020 From: pbarker at konsulko.com (Paul Barker) Date: Mon, 9 Mar 2020 14:21:38 +0000 Subject: [OE-core] [PATCH 4/5] perf: Fix externalsrc support In-Reply-To: <20200309142139.15741-1-pbarker@konsulko.com> References: <20200309142139.15741-1-pbarker@konsulko.com> Message-ID: <20200309142139.15741-5-pbarker@konsulko.com> When the externalsrc class is used the tasks listed in SRCTREECOVEREDTASKS are deleted to prevent them being executed. If externalsrc is used for the kernel then this will include virtual/kernel:do_patch. We can depend on do_shared_workdir instead as this will survive when externalsrc is used. Signed-off-by: Paul Barker --- meta/recipes-kernel/perf/perf.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/perf.bb index 10a5b88260..e005eb082b 100644 --- a/meta/recipes-kernel/perf/perf.bb +++ b/meta/recipes-kernel/perf/perf.bb @@ -52,7 +52,7 @@ export PYTHON_SITEPACKAGES_DIR #kernel 3.1+ supports WERROR to disable warnings as errors export WERROR = "0" -do_populate_lic[depends] += "virtual/kernel:do_patch" +do_populate_lic[depends] += "virtual/kernel:do_shared_workdir" # needed for building the tools/perf Perl binding include ${@bb.utils.contains('PACKAGECONFIG', 'scripting', 'perf-perl.inc', '', d)} -- 2.20.1 From pbarker at konsulko.com Mon Mar 9 14:21:39 2020 From: pbarker at konsulko.com (Paul Barker) Date: Mon, 9 Mar 2020 14:21:39 +0000 Subject: [OE-core] [PATCH 5/5] kernel-yocto.bbclass: Support config fragments with externalsrc In-Reply-To: <20200309142139.15741-1-pbarker@konsulko.com> References: <20200309142139.15741-1-pbarker@konsulko.com> Message-ID: <20200309142139.15741-6-pbarker@konsulko.com> The merging of config fragments is performend in the do_kernel_configme task and so config fragments will not be supported when this task is removed from the dependency tree. kernel-yocto adds additional tasks which may modify the source directory to SRCTREECOVEREDTASKS so that they are removed when using externalsrc. However, do_kernel_configme should be safe to use, the only modification to the source tree is the potential creation of the '.kernel-meta' directory and the '.metadir' file. Signed-off-by: Paul Barker --- meta/classes/kernel-yocto.bbclass | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/meta/classes/kernel-yocto.bbclass b/meta/classes/kernel-yocto.bbclass index d71ce212a8..6792c9a233 100644 --- a/meta/classes/kernel-yocto.bbclass +++ b/meta/classes/kernel-yocto.bbclass @@ -1,5 +1,5 @@ # remove tasks that modify the source tree in case externalsrc is inherited -SRCTREECOVEREDTASKS += "do_kernel_configme do_validate_branches do_kernel_configcheck do_kernel_checkout do_fetch do_unpack do_patch" +SRCTREECOVEREDTASKS += "do_validate_branches do_kernel_configcheck do_kernel_checkout do_fetch do_unpack do_patch" PATCH_GIT_USER_EMAIL ?= "kernel-yocto at oe" PATCH_GIT_USER_NAME ?= "OpenEmbedded" @@ -325,6 +325,7 @@ do_validate_branches[depends] = "kern-tools-native:do_populate_sysroot" do_kernel_configme[depends] += "virtual/${TARGET_PREFIX}binutils:do_populate_sysroot" do_kernel_configme[depends] += "virtual/${TARGET_PREFIX}gcc:do_populate_sysroot" do_kernel_configme[depends] += "bc-native:do_populate_sysroot bison-native:do_populate_sysroot" +do_kernel_configme[depends] += "kern-tools-native:do_populate_sysroot" do_kernel_configme[dirs] += "${S} ${B}" do_kernel_configme() { # translate the kconfig_mode into something that merge_config.sh -- 2.20.1 From alex.kiernan at gmail.com Mon Mar 9 15:18:26 2020 From: alex.kiernan at gmail.com (Alex Kiernan) Date: Mon, 9 Mar 2020 15:18:26 +0000 Subject: [OE-core] psplash activation state w/ systemd Message-ID: I've a branch with systemd 245 on it which fails testing because psplash gets restarted all the time. But ignoring the systemd 245 piece, it looks to me like psplash could be restarted under systemd 244 too as the main process exits and our units aren't marked RemainAfterExit. I haven't figured out what's triggering it in 245 and not 244, but I suspect it's something similar to this: https://github.com/systemd/systemd/commit/9fd32ff7d363945fbf8fdae0128702b995127558 Given where we are in the release cycle and how painful psplash has obviously been, I'm inclined to leave it until after dunfell ships and then do it as part of the whole 245 upgrade? Equally if you see psplash flapping during tests, it's almost certainly this problem. -- Alex Kiernan From raj.khem at gmail.com Mon Mar 9 15:20:09 2020 From: raj.khem at gmail.com (Khem Raj) Date: Mon, 9 Mar 2020 08:20:09 -0700 Subject: [OE-core] [PATCH 1/2] glibc: Explicitly disable msgfmt In-Reply-To: References: <20200307223748.1178851-1-richard.purdie@linuxfoundation.org> Message-ID: On Sun, Mar 8, 2020 at 12:18 AM Richard Purdie wrote: > > On Sat, 2020-03-07 at 20:17 -0800, Khem Raj wrote: > > On Sat, Mar 7, 2020 at 2:37 PM Richard Purdie > > wrote: > > > If configure is rerun it finds msgfmt from gettext-native which is > > > installed > > > during package_write_ipk|deb and means builds are not determinisic. > > > > > > Whether msgfmt is needed is debatable (libc.mo files arne't > > > generated without > > > it) however we should at least be consistent which this patch > > > ensures. > > > > > > > I think we could turn it into a packageconfig and add depending on > > gettext-native in knob, keep the knob disabled by default. While > > dont think translation files will be commonly installed on systems OE > > targets but its seems limiting if we simply disable it. > > Keep in mind that currently in any build from scratch it is disabled. > This patch doesn't regress anything, it just ensures builds are > reproducible. Yes I understand that, I was just wondering if its going to cause problems for folks who has been relying on this behavior > > I agree if anyone wants it, we can add a PACKAGECONFIG. > perhaps acceptable for now. > Cheers, > > Richard > From codrin.ciubotariu at microchip.com Mon Mar 9 15:58:36 2020 From: codrin.ciubotariu at microchip.com (Codrin Ciubotariu) Date: Mon, 9 Mar 2020 17:58:36 +0200 Subject: [OE-core] [PATCH] p11-kit: Add nativesdk variant Message-ID: <20200309155836.30846-1-codrin.ciubotariu@microchip.com> The nativesdk variant is needed by the buildtools-tarball, when p11-kit feature is enabled for gnutls. The error message is: Missing or unbuildable dependency chain was: ['buildtools-tarball', 'nativesdk-wget', 'nativesdk-gnutls', 'nativesdk-p11-kit'] Signed-off-by: Codrin Ciubotariu Cc: Alexander Kanavin --- meta/recipes-support/p11-kit/p11-kit_0.23.16.1.bb | 2 ++ 1 file changed, 2 insertions(+) diff --git a/meta/recipes-support/p11-kit/p11-kit_0.23.16.1.bb b/meta/recipes-support/p11-kit/p11-kit_0.23.16.1.bb index 54455da1bb..995df29947 100644 --- a/meta/recipes-support/p11-kit/p11-kit_0.23.16.1.bb +++ b/meta/recipes-support/p11-kit/p11-kit_0.23.16.1.bb @@ -44,3 +44,5 @@ FILES_${PN} += " \ # PN contains p11-kit-proxy.so, a symlink to a loadable module INSANE_SKIP_${PN} = "dev-so" + +BBCLASSEXTEND = "nativesdk" -- 2.17.1 From patchwork at patchwork.openembedded.org Mon Mar 9 16:32:17 2020 From: patchwork at patchwork.openembedded.org (Patchwork) Date: Mon, 09 Mar 2020 16:32:17 -0000 Subject: [OE-core] =?utf-8?q?=E2=9C=97_patchtest=3A_failure_for_p11-kit=3A?= =?utf-8?q?_Add_nativesdk_variant?= In-Reply-To: <20200309155836.30846-1-codrin.ciubotariu@microchip.com> References: <20200309155836.30846-1-codrin.ciubotariu@microchip.com> Message-ID: <20200309163217.2276.8873@do> == Series Details == Series: p11-kit: Add nativesdk variant Revision: 1 URL : https://patchwork.openembedded.org/series/23169/ 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 fix Rebase your series on top of targeted branch Targeted branch master (currently at 5d579fc2fe) If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core at 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 From sjolley.yp.pm at gmail.com Mon Mar 9 17:23:59 2020 From: sjolley.yp.pm at gmail.com (sjolley.yp.pm at gmail.com) Date: Mon, 9 Mar 2020 10:23:59 -0700 Subject: [OE-core] Yocto Project Newcomer & Unassigned Bugs - Help Needed Message-ID: <05e501d5f637$858d6cd0$90a84670$@gmail.com> All, The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on the triage page under the appropriate heading: https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs The idea is these bugs should be straight forward for a person to help work on who doesn't have deep experience with the project. If anyone can help, please take ownership of the bug and send patches! If anyone needs help/advice there are people on irc who can likely do so, or some of the more experienced contributors will likely be happy to help too. Also, the triage team meets weekly and does its best to handle the bugs reported into the Bugzilla. The number of people attending that meeting has fallen, as have the number of people available to help fix bugs. One of the things we hear users report is they don't know how to help. We (the triage team) are therefore going to start reporting out the currently 292 unassigned or newcomer bugs. We're hoping people may be able to spare some time now and again to help out with these. Bugs are split into two types, "true bugs" where things don't work as they should and "enhancements" which are features we'd want to add to the system. There are also roughly four different "priority" classes right now, "3.1", "3.2, "3.99" and "Future", the more pressing/urgent issues being in "3.1" and then "3.2". Please review this link and if a bug is something you would be able to help with either take ownership of the bug, or send me (sjolley.yp.pm at gmail.com ) an e-mail with the bug number you would like and I will assign it to you (please make sure you have a Bugzilla account). The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer _Bugs Thanks, Stephen K. Jolley Yocto Project Program Manager * Cell: (208) 244-4460 * Email: sjolley.yp.pm at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From codrin.ciubotariu at microchip.com Mon Mar 9 17:55:35 2020 From: codrin.ciubotariu at microchip.com (Codrin Ciubotariu) Date: Mon, 9 Mar 2020 19:55:35 +0200 Subject: [OE-core] [PATCH v2] p11-kit: Add nativesdk variant Message-ID: <20200309175535.349-1-codrin.ciubotariu@microchip.com> The nativesdk variant is needed by the buildtools-tarball, when p11-kit feature is enabled for gnutls. The error message is: Missing or unbuildable dependency chain was: ['buildtools-tarball', 'nativesdk-wget', 'nativesdk-gnutls', 'nativesdk-p11-kit'] Signed-off-by: Codrin Ciubotariu Cc: Alexander Kanavin --- Changes in v2: - rebased on top of master branch meta/recipes-support/p11-kit/p11-kit_0.23.20.bb | 2 ++ 1 file changed, 2 insertions(+) diff --git a/meta/recipes-support/p11-kit/p11-kit_0.23.20.bb b/meta/recipes-support/p11-kit/p11-kit_0.23.20.bb index 54b8cc6a70..4ba93f998a 100644 --- a/meta/recipes-support/p11-kit/p11-kit_0.23.20.bb +++ b/meta/recipes-support/p11-kit/p11-kit_0.23.20.bb @@ -25,3 +25,5 @@ FILES_${PN} += " \ # PN contains p11-kit-proxy.so, a symlink to a loadable module INSANE_SKIP_${PN} = "dev-so" + +BBCLASSEXTEND = "nativesdk" -- 2.17.1 From randy.macleod at windriver.com Mon Mar 9 18:11:51 2020 From: randy.macleod at windriver.com (Randy MacLeod) Date: Mon, 9 Mar 2020 14:11:51 -0400 Subject: [OE-core] [PATCH v6] expat: Added ptest In-Reply-To: References: <20200212121911.4752-1-oleksandr.s.popovych@globallogic.com> Message-ID: <81b5c6d4-ad7c-e0bd-bf74-a25f5e274664@windriver.com> On 2020-03-06 8:24 a.m., Oleksandr Popovych wrote: > Hello, Randy Hi, Back from a holiday so my reply was delayed. > > On Wed, Feb 12, 2020 at 7:17 PM Randy MacLeod > wrote: >> >> On 2/12/20 7:19 AM, Oleksandr Popovych via Openembedded-core wrote: >>> For ptest support for this package several additional patches and >>> run-ptest script were added and recipe was changed. >>> >>> Signed-off-by: Oleksandr Popovych >>> --- >>> ...d-Makefile-targets-for-ptest-support.patch | 40 ++++++++++++++ >>> ...ort-for-ptests-in-form-of-new-target.patch | 33 ++++++++++++ >>> ...ed-suitable-format-of-tests-in-ptest.patch | 52 +++++++++++++++++++ >>> meta/recipes-core/expat/expat/run-ptest | 3 ++ >>> meta/recipes-core/expat/expat_2.2.9.bb | 12 ++++- >>> 5 files changed, 139 insertions(+), 1 deletion(-) >>> create mode 100644 meta/recipes-core/expat/expat/0001-expat-Added-Makefile-targets-for-ptest-support.patch >>> create mode 100644 meta/recipes-core/expat/expat/0002-expat-Added-support-for-ptests-in-form-of-new-target.patch >>> create mode 100644 meta/recipes-core/expat/expat/0003-expat-Added-suitable-format-of-tests-in-ptest.patch >>> create mode 100644 meta/recipes-core/expat/expat/run-ptest >>> >>> diff --git a/meta/recipes-core/expat/expat/0001-expat-Added-Makefile-targets-for-ptest-support.patch b/meta/recipes-core/expat/expat/0001-expat-Added-Makefile-targets-for-ptest-support.patch >>> new file mode 100644 >>> index 0000000000..de213b4bc5 >>> --- /dev/null >>> +++ b/meta/recipes-core/expat/expat/0001-expat-Added-Makefile-targets-for-ptest-support.patch >>> @@ -0,0 +1,40 @@ >>> +From e306bd4849f61f50dad1f5d29fb650c347d78ad6 Mon Sep 17 00:00:00 2001 >>> +From: Oleksandr Popovych >>> +Date: Thu, 6 Feb 2020 13:41:45 +0200 >>> +Subject: [PATCH 1/3] expat: Added Makefile targets for ptest support >>> + >>> +install-ptest, runtests and check tagrets are added. >>> + >>> +Upstream-Status: Inappropriate [oe-core specific] >>> + >>> +Signed-off-by: Oleksandr Popovych >>> +--- >>> + Makefile.am | 15 +++++++++++++++ >>> + 1 file changed, 15 insertions(+) >>> + >>> +diff --git a/Makefile.am b/Makefile.am >>> +index 5e1d37d..c63b44a 100644 >>> +--- a/Makefile.am >>> ++++ b/Makefile.am >>> +@@ -152,3 +152,18 @@ qa: >>> + QA_COMPILER=clang QA_SANITIZER=memory ./qa.sh >>> + QA_COMPILER=clang QA_SANITIZER=undefined ./qa.sh >>> + QA_COMPILER=gcc QA_PROCESSOR=gcov ./qa.sh >>> ++ >>> ++.PHONY: install-ptest >>> ++install-ptest: >> >> if you call this, install-test and don't change the behaviour used when >> testing self-hosted development, then perhaps >> the upstream will accept the changes. >> >>> ++ echo $(S) >>> ++ (if [ -d tests/.libs ] ; then cd tests/.libs; fi; \ >>> ++ install runtests runtestspp $(DESTDIR)) >>> ++ cp Makefile $(DESTDIR) >>> ++ sed -i -e 's|^Makefile:|_Makefile:|' $(DESTDIR)/Makefile >>> ++ >>> ++.PHONY: runtests >>> ++runtests: >>> ++ @echo "C variant of tests:" >>> ++ @$(CHECKER) ./runtests$(EXEEXT) -q >>> ++ @echo "C++ variant of tests:" >>> ++ @$(CHECKER) ./runtestspp$(EXEEXT) -q >>> +-- >>> +2.17.1 >>> + >>> diff --git a/meta/recipes-core/expat/expat/0002-expat-Added-support-for-ptests-in-form-of-new-target.patch b/meta/recipes-core/expat/expat/0002-expat-Added-support-for-ptests-in-form-of-new-target.patch >>> new file mode 100644 >>> index 0000000000..26ae144a37 >>> --- /dev/null >>> +++ b/meta/recipes-core/expat/expat/0002-expat-Added-support-for-ptests-in-form-of-new-target.patch >>> @@ -0,0 +1,33 @@ >>> +From 9a5085243b632a777f55269f7f6d2e40dd73a7bc Mon Sep 17 00:00:00 2001 >>> +From: Oleksandr Popovych >>> +Date: Thu, 6 Feb 2020 13:43:57 +0200 >>> +Subject: [PATCH 2/3] expat: Added support for ptests in form of new target >>> + >>> +configure.am file changed, according to this advice: >>> +https://wiki.yoctoproject.org/wiki/Ptest#Building_the_test_suite >>> + >>> +Upstream-Status: Inappropriate [oe-core specific] >>> + >>> +Signed-off-by: Oleksandr Popovych >>> +--- >>> + configure.ac | 4 ++-- >>> + 1 file changed, 2 insertions(+), 2 deletions(-) >>> + >>> +diff --git a/configure.ac b/configure.ac >>> +index d58ac03..8e6b41e 100644 >>> +--- a/configure.ac >>> ++++ b/configure.ac >>> +@@ -34,8 +34,8 @@ AC_CONFIG_SRCDIR([Makefile.in]) >>> + AC_CONFIG_AUX_DIR([conftools]) >>> + AC_CONFIG_MACRO_DIR([m4]) >>> + AC_CANONICAL_HOST >>> +-AM_INIT_AUTOMAKE >>> +- >>> ++AM_INIT_AUTOMAKE([serial-tests]) >>> ++AM_EXTRA_RECURSIVE_TARGETS([buildtest-TESTS]) >> >> >> Cross-compiling is increasingly common. >> Upstream might accept you changes to split up >> building, installing and running tests. >> > > According to this information: > https://github.com/libexpat/libexpat/issues/330 > Autotools that are used for building this library are going to become > deprecated, and library maintainers are planning to switch on CMake > instead. > Latest release already has CMake build system support. This system is > still experimental, but it already has split up building and running > tests (installation can be implemented in recipe). > With migration on CMake there will no be reason for upstreaming > changes for potentially deprecated feature. Agreed. > But... > cmake-native package has expat-native as RDEPENDS. That creates a > dependency loop between this packages. I was able to fix it by > splitting recipes for expat and expat-native, and build expat with > CMake and expat-native with autotools... Ah, thanks for the background info. I guess that works, I haven't dealt with such problems in a while so go for it unless someone else replies. > > So does expat recipe need to be rewritten on cmake-based building? And > how can such dependency loop be solved properly, if recipe need to be > changed? I can think about it more later in the week once I'm caught up on other things. Meanwhile, take a look for 'dependency loop' in oe-core's git log for examples of how people have dealt with this problem. > >> >> Same goes for the PASS/ FAIL printfs below. >> > > According to conversation about my changes offer: > https://github.com/libexpat/libexpat/issues/382 > maintainers would rather be interested in changing testing framework > on more functional and adapting their tests for it than making changes > in the current one. So my patches are not suitable for upstreaming. Sigh, okay. :) > And I see several ways for solving this situation: > - discard patches and rewrite run-tests script and recipe without > making any changes in the code (So patches are not required, but tests > output will be reduced to 2 lines: "PASS/FAIL/SKIP: runtests" and > "PASS/FAIL/SKIP: runtestspp" because there are 2 testing executables) > - leave patches marked as "Inappropriate" (maybe with reason updating) > - accept expat maintainers offer and change their current testing > framework "... to something C-based, existing, capable, > self-contained, and integrate it into both the CMake and Autotools > build systems while we have both...". (This requires a lot of time, > efforts and experience, but will be acceptable for upstreaming) > > So should I try to implement and upstream changes of expat testing > framework, or I can leave this for somebody else? Given all the work you have put into expat, and that upstream is changing, I think you should submit v7 with a brief summary of what you have learned. We're also in the M4 stage of the 3.1 release so adding ptests now is appealing to me at least. > >> >> Working with upstream takes a bit more time but if we >> don't have to carry patches for years, it's worth it. >> >> Finally, how about adding the test results in the long log >> with info about the image and machine used? The time >> needed to run the tests will be useful to determine if these >> ptests can be added to: >> >> meta/conf/distro/include/ptest-packagelists.inc >> >> and you could do that if the tests run in < 30 seconds in qemux86-64 >> with kvm support. >> > > CMake based building system of this library uses such tool like CTest. > This tool can run built tests, show their output and write it to log > file simultaneously with time tracking of tests` execution. > This can be additional "pros" for migration on CMake-based build > system, of course with adding one additional RDEPENS-ptest value for > package. Let's leave that until the upstream declares CMake to be the default. Thanks for your work on this Oleksandr, let's hope that v7 gets merged. ../Randy > >> >> Thanks, >> >> ../Randy >> >>> + >>> + dnl >>> + dnl Increment LIBREVISION if source code has changed at all >>> +-- >>> +2.17.1 >>> + >>> diff --git a/meta/recipes-core/expat/expat/0003-expat-Added-suitable-format-of-tests-in-ptest.patch b/meta/recipes-core/expat/expat/0003-expat-Added-suitable-format-of-tests-in-ptest.patch >>> new file mode 100644 >>> index 0000000000..9a85a26117 >>> --- /dev/null >>> +++ b/meta/recipes-core/expat/expat/0003-expat-Added-suitable-format-of-tests-in-ptest.patch >>> @@ -0,0 +1,52 @@ >>> +From 825f344543676fc3314f4e074163fd638db8e8f9 Mon Sep 17 00:00:00 2001 >>> +From: Oleksandr Popovych >>> +Date: Thu, 6 Feb 2020 13:44:56 +0200 >>> +Subject: [PATCH 3/3] expat: Added suitable format of tests in ptest >>> + >>> +Some changes in testcases code were applied for testcase engine. >>> +This was just adding of message outputs in "RESULT: TESTNAME" form... >>> + >>> +Upstream-Status: Inappropriate [oe-core specific] >>> + >>> +Signed-off-by: Oleksandr Popovych >>> +--- >>> + tests/minicheck.c | 4 ++++ >>> + 1 file changed, 4 insertions(+) >>> + >>> +diff --git a/tests/minicheck.c b/tests/minicheck.c >>> +index a5a1efb..b39cda9 100644 >>> +--- a/tests/minicheck.c >>> ++++ b/tests/minicheck.c >>> +@@ -164,6 +164,7 @@ srunner_run_all(SRunner *runner, int verbosity) { >>> + if (tc->setup != NULL) { >>> + /* setup */ >>> + if (setjmp(env)) { >>> ++ printf("SKIP: %s\n", _check_current_function); >>> + add_failure(runner, verbosity); >>> + continue; >>> + } >>> +@@ -171,6 +172,7 @@ srunner_run_all(SRunner *runner, int verbosity) { >>> + } >>> + /* test */ >>> + if (setjmp(env)) { >>> ++ printf("FAIL: %s\n", _check_current_function); >>> + add_failure(runner, verbosity); >>> + continue; >>> + } >>> +@@ -179,11 +181,13 @@ srunner_run_all(SRunner *runner, int verbosity) { >>> + /* teardown */ >>> + if (tc->teardown != NULL) { >>> + if (setjmp(env)) { >>> ++ printf("PASS: %s\n", _check_current_function); >>> + add_failure(runner, verbosity); >>> + continue; >>> + } >>> + tc->teardown(); >>> + } >>> ++ printf("PASS: %s\n", _check_current_function); >>> + } >>> + tc = tc->next_tcase; >>> + } >>> +-- >>> +2.17.1 >>> + >>> diff --git a/meta/recipes-core/expat/expat/run-ptest b/meta/recipes-core/expat/expat/run-ptest >>> new file mode 100644 >>> index 0000000000..df994c0838 >>> --- /dev/null >>> +++ b/meta/recipes-core/expat/expat/run-ptest >>> @@ -0,0 +1,3 @@ >>> +#!/bin/bash >>> + >>> +make -k runtests >>> diff --git a/meta/recipes-core/expat/expat_2.2.9.bb b/meta/recipes-core/expat/expat_2.2.9.bb >>> index 8f3db41352..420ffddc80 100644 >>> --- a/meta/recipes-core/expat/expat_2.2.9.bb >>> +++ b/meta/recipes-core/expat/expat_2.2.9.bb >>> @@ -8,15 +8,25 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=5b8620d98e49772d95fc1d291c26aa79" >>> >>> SRC_URI = "${SOURCEFORGE_MIRROR}/expat/expat-${PV}.tar.bz2 \ >>> file://libtool-tag.patch \ >>> + file://0001-expat-Added-Makefile-targets-for-ptest-support.patch \ >>> + file://0002-expat-Added-support-for-ptests-in-form-of-new-target.patch \ >>> + file://0003-expat-Added-suitable-format-of-tests-in-ptest.patch \ >>> + file://run-ptest \ >>> " >>> >>> SRC_URI[md5sum] = "875a2c2ff3e8eb9e5a5cd62db2033ab5" >>> SRC_URI[sha256sum] = "f1063084dc4302a427dabcca499c8312b3a32a29b7d2506653ecc8f950a9a237" >>> >>> -inherit autotools lib_package >>> +inherit autotools ptest lib_package >>> + >>> +RDEPENDS_${PN}-ptest += "make bash" >>> >>> do_configure_prepend () { >>> rm -f ${S}/conftools/libtool.m4 >>> } >>> >>> +do_compile_ptest() { >>> + oe_runmake buildtest-TESTS >>> +} >>> + >>> BBCLASSEXTEND = "native nativesdk" >> >> >> -- >> # Randy MacLeod >> # Wind River Linux >> > > Thank you for your attention > -- # Randy MacLeod # Wind River Linux From rp at stacktrust.org Mon Mar 9 22:44:57 2020 From: rp at stacktrust.org (Rich Persaud) Date: Mon, 9 Mar 2020 18:44:57 -0400 Subject: [OE-core] [PATCH] grub-efi-cfg: enable per-label APPEND override Message-ID: <20200309224457.16708-1-rp@stacktrust.org> For legacy bios boot configurations, syslinux supports multiple labels with per-label APPEND definitions. grub-efi-cfg supports multiple labels, but only a single APPEND definition. Enable optional per-label APPEND definitions for grub EFI, with variable names prefixed by "grub_" to isolate grub definitions from syslinux defintions. Example use from an ISO image recipe that inherits grub-efi-cfg: LABELS_LIVE="foo bar" APPEND_grub_foo = "linuxcmdline" No change in behavior for those using APPEND without overrides. Signed-off-by: Rich Persaud --- meta/classes/grub-efi-cfg.bbclass | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/meta/classes/grub-efi-cfg.bbclass b/meta/classes/grub-efi-cfg.bbclass index 8b5ff20c72..3a2cdd698b 100644 --- a/meta/classes/grub-efi-cfg.bbclass +++ b/meta/classes/grub-efi-cfg.bbclass @@ -88,6 +88,12 @@ python build_efi_cfg() { for label in labels.split(): localdata = d.createCopy() + overrides = localdata.getVar('OVERRIDES') + if not overrides: + bb.fatal('OVERRIDES not defined') + + localdata.setVar('OVERRIDES', 'grub_' + label + ':' + overrides) + for btype in btypes: cfgfile.write('\nmenuentry \'%s%s\'{\n' % (label, btype[0])) lb = label -- 2.20.1 From rp at stacktrust.org Mon Mar 9 22:55:07 2020 From: rp at stacktrust.org (Rich Persaud) Date: Mon, 9 Mar 2020 18:55:07 -0400 Subject: [OE-core] [PATCH] image-live: multiconfig ISO generation Message-ID: <20200309225507.29578-1-rp@stacktrust.org> When a target is specified for INITRD_IMAGE_LIVE, a task dependency is added for do_image_complete. At present, image-live initrd will not accept multiconfig dependency targets. If BBMULTICONFIG is non-empty and INITRD_IMAGE_LIVE is a multiconfig target, use mcdepends instead of depends. The packaging recipe must also override machine-specific path construction of INITRD_LIVE. Required to build an ISO with mixed machine types, a primary use case for multiconfig. This is a minimal fix to make multiconfig ISOs possible. Signed-off-by: Rich Persaud --- meta/classes/image-live.bbclass | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/meta/classes/image-live.bbclass b/meta/classes/image-live.bbclass index 54058b350d..1afd48005a 100644 --- a/meta/classes/image-live.bbclass +++ b/meta/classes/image-live.bbclass @@ -50,11 +50,14 @@ IMAGE_TYPES_MASKED += "live hddimg iso" python() { image_b = d.getVar('IMAGE_BASENAME') initrd_i = d.getVar('INITRD_IMAGE_LIVE') + depends_type = ('mcdepends' if (d.getVar('BBMULTICONFIG') + and initrd_i.count(':') == 3) + else 'depends') if image_b == initrd_i: bb.error('INITRD_IMAGE_LIVE %s cannot use image live, hddimg or iso.' % initrd_i) bb.fatal('Check IMAGE_FSTYPES and INITRAMFS_FSTYPES settings.') elif initrd_i: - d.appendVarFlag('do_bootimg', 'depends', ' %s:do_image_complete' % initrd_i) + d.appendVarFlag('do_bootimg', depends_type, ' %s:do_image_complete' % initrd_i) } HDDDIR = "${S}/hddimg" -- 2.20.1 From raj.khem at gmail.com Mon Mar 9 23:44:53 2020 From: raj.khem at gmail.com (Khem Raj) Date: Mon, 9 Mar 2020 16:44:53 -0700 Subject: [OE-core] [PATCH 1/2] ruby: Use arm32 for coroutines on 32bit-arm Message-ID: <20200309234454.1387958-1-raj.khem@gmail.com> in 2.7 [2] ruby enabled ucontext for coroutines on arm32 but it does not work for musl since it uses glibc specific functions e.g. getcontext/swapcontext/swapcontext also see [1] This patch reverts back to using arm32 implementation for coroutines on arm [1] https://bugs.ruby-lang.org/issues/16455#change-83442 [2] https://github.com/ruby/ruby/commit/6c6bf9ffcbfeb8be9d9c342e7604b74ec819e88a#diff-7fccec8474e2184cd2518046bf39d54cL10 Signed-off-by: Khem Raj --- meta/recipes-devtools/ruby/ruby_2.7.0.bb | 2 ++ 1 file changed, 2 insertions(+) diff --git a/meta/recipes-devtools/ruby/ruby_2.7.0.bb b/meta/recipes-devtools/ruby/ruby_2.7.0.bb index 268b4bebd9..884bb0ef44 100644 --- a/meta/recipes-devtools/ruby/ruby_2.7.0.bb +++ b/meta/recipes-devtools/ruby/ruby_2.7.0.bb @@ -25,6 +25,8 @@ EXTRA_OECONF = "\ --with-pkg-config=pkg-config \ " +EXTRA_OECONF_append_arm_libc-musl = " --with-coroutine=arm32" + do_install() { oe_runmake 'DESTDIR=${D}' install } -- 2.25.1 From raj.khem at gmail.com Mon Mar 9 23:44:54 2020 From: raj.khem at gmail.com (Khem Raj) Date: Mon, 9 Mar 2020 16:44:54 -0700 Subject: [OE-core] [PATCH 2/2] valgrind: Fix timerfb syscall test to be 64bit time_t safe In-Reply-To: <20200309234454.1387958-1-raj.khem@gmail.com> References: <20200309234454.1387958-1-raj.khem@gmail.com> Message-ID: <20200309234454.1387958-2-raj.khem@gmail.com> This helps compile the testcase with musl on 32bit arches Signed-off-by: Khem Raj --- ...check-tests-Fix-timerfd-syscall-test.patch | 210 ++++++++++++++++++ .../valgrind/valgrind_3.15.0.bb | 1 + 2 files changed, 211 insertions(+) create mode 100644 meta/recipes-devtools/valgrind/valgrind/0001-memcheck-tests-Fix-timerfd-syscall-test.patch diff --git a/meta/recipes-devtools/valgrind/valgrind/0001-memcheck-tests-Fix-timerfd-syscall-test.patch b/meta/recipes-devtools/valgrind/valgrind/0001-memcheck-tests-Fix-timerfd-syscall-test.patch new file mode 100644 index 0000000000..d1d96a0eff --- /dev/null +++ b/meta/recipes-devtools/valgrind/valgrind/0001-memcheck-tests-Fix-timerfd-syscall-test.patch @@ -0,0 +1,210 @@ +From 5d411fd147d652e9d7bb259f4048693c6e4742aa Mon Sep 17 00:00:00 2001 +From: Khem Raj +Date: Mon, 9 Mar 2020 16:30:19 -0700 +Subject: [PATCH] memcheck/tests: Fix timerfd syscall test + +modern libc provides these functions, moreover this also ensures that we +are 64bit time_t safe. Fallback to existing definitions if libc does not +have the implementation or syscall is not defined + +Upstream-Status: Submitted [https://sourceforge.net/p/valgrind/mailman/message/36943866/] +Signed-off-by: Khem Raj +--- + config.h | 9 +++++++++ + config.h.in | 9 +++++++++ + configure | 3 +++ + configure.ac | 3 +++ + memcheck/tests/linux/timerfd-syscall.c | 10 ++++++++-- + 5 files changed, 32 insertions(+), 2 deletions(-) + +--- a/config.h ++++ b/config.h +@@ -47,20 +47,20 @@ + /* #undef ENABLE_LTO */ + + /* path to GDB */ +-#define GDB_PATH "/usr/bin/gdb" ++#define GDB_PATH "/no/gdb/was/found/at/configure/time" + + /* Define to 1 if index() and strlen() have been optimized heavily (x86 glibc + >= 2.12) */ +-#define GLIBC_MANDATORY_INDEX_AND_STRLEN_REDIRECT 1 ++/* #undef GLIBC_MANDATORY_INDEX_AND_STRLEN_REDIRECT */ + + /* Define to 1 if strlen() has been optimized heavily (amd64 glibc >= 2.10) */ +-#define GLIBC_MANDATORY_STRLEN_REDIRECT 1 ++/* #undef GLIBC_MANDATORY_STRLEN_REDIRECT */ + + /* Define to 1 if you have the header file. */ + #define HAVE_ASM_UNISTD_H 1 + + /* Define to 1 if as supports fxsave64/fxrstor64. */ +-#define HAVE_AS_AMD64_FXSAVE64 1 ++/* #undef HAVE_AS_AMD64_FXSAVE64 */ + + /* Define to 1 if as supports floating point phased out category. */ + /* #undef HAVE_AS_PPC_FPPO */ +@@ -92,7 +92,7 @@ + #define HAVE_CLOCK_MONOTONIC 1 + + /* Define to 1 if you have a dlinfo that can do RTLD_DI_TLS_MODID. */ +-#define HAVE_DLINFO_RTLD_DI_TLS_MODID 1 ++/* #undef HAVE_DLINFO_RTLD_DI_TLS_MODID */ + + /* Define to 1 if the system has the type `Elf32_Chdr'. */ + #define HAVE_ELF32_CHDR 1 +@@ -134,7 +134,7 @@ + /* #undef HAVE_LIBSCF */ + + /* Define to 1 if you have the `mallinfo' function. */ +-#define HAVE_MALLINFO 1 ++/* #undef HAVE_MALLINFO */ + + /* Define to 1 if you have the `memchr' function. */ + #define HAVE_MEMCHR 1 +@@ -176,26 +176,26 @@ + /* #undef HAVE_PTHREAD_CREATE_GLIBC_2_0 */ + + /* Define to 1 if you have the `PTHREAD_MUTEX_ADAPTIVE_NP' constant. */ +-#define HAVE_PTHREAD_MUTEX_ADAPTIVE_NP 1 ++/* #undef HAVE_PTHREAD_MUTEX_ADAPTIVE_NP */ + + /* Define to 1 if you have the `PTHREAD_MUTEX_ERRORCHECK_NP' constant. */ +-#define HAVE_PTHREAD_MUTEX_ERRORCHECK_NP 1 ++/* #undef HAVE_PTHREAD_MUTEX_ERRORCHECK_NP */ + + /* Define to 1 if you have the `PTHREAD_MUTEX_RECURSIVE_NP' constant. */ +-#define HAVE_PTHREAD_MUTEX_RECURSIVE_NP 1 ++/* #undef HAVE_PTHREAD_MUTEX_RECURSIVE_NP */ + + /* Define to 1 if you have the `pthread_mutex_timedlock' function. */ + #define HAVE_PTHREAD_MUTEX_TIMEDLOCK 1 + + /* Define to 1 if pthread_mutex_t has a member __data.__kind. */ +-#define HAVE_PTHREAD_MUTEX_T__DATA__KIND 1 ++/* #undef HAVE_PTHREAD_MUTEX_T__DATA__KIND */ + + /* Define to 1 if pthread_mutex_t has a member called __m_kind. */ + /* #undef HAVE_PTHREAD_MUTEX_T__M_KIND */ + + /* Define to 1 if you have the `PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP' + constant. */ +-#define HAVE_PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP 1 ++/* #undef HAVE_PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP */ + + /* Define to 1 if you have the `pthread_rwlock_t' type. */ + #define HAVE_PTHREAD_RWLOCK_T 1 +@@ -213,7 +213,7 @@ + #define HAVE_PTHREAD_SPIN_LOCK 1 + + /* Define to 1 if you have the `pthread_yield' function. */ +-#define HAVE_PTHREAD_YIELD 1 ++/* #undef HAVE_PTHREAD_YIELD */ + + /* Define to 1 if you have the `PTRACE_GETREGS' ptrace request. */ + #define HAVE_PTRACE_GETREGS 1 +@@ -309,7 +309,16 @@ + #define HAVE_SYS_TYPES_H 1 + + /* Define to 1 if defines struct user_regs_struct */ +-#define HAVE_SYS_USER_REGS 1 ++/* #undef HAVE_SYS_USER_REGS */ ++ ++/* Define to 1 if you have the `timerfd_create' function. */ ++#define HAVE_TIMERFD_CREATE 1 ++ ++/* Define to 1 if you have the `timerfd_gettime' function. */ ++#define HAVE_TIMERFD_GETTIME 1 ++ ++/* Define to 1 if you have the `timerfd_settime' function. */ ++#define HAVE_TIMERFD_SETTIME 1 + + /* can use __thread to define thread-local variables */ + #define HAVE_TLS 1 +@@ -324,7 +333,7 @@ + #define HAVE_UTIMENSAT 1 + + /* Define to 1 if you're using Musl libc */ +-/* #undef MUSL_LIBC */ ++#define MUSL_LIBC 1 + + /* Name of package */ + #define PACKAGE "valgrind" +--- a/config.h.in ++++ b/config.h.in +@@ -310,6 +310,15 @@ + /* Define to 1 if defines struct user_regs_struct */ + #undef HAVE_SYS_USER_REGS + ++/* Define to 1 if you have the `timerfd_create' function. */ ++#undef HAVE_TIMERFD_CREATE ++ ++/* Define to 1 if you have the `timerfd_gettime' function. */ ++#undef HAVE_TIMERFD_GETTIME ++ ++/* Define to 1 if you have the `timerfd_settime' function. */ ++#undef HAVE_TIMERFD_SETTIME ++ + /* can use __thread to define thread-local variables */ + #undef HAVE_TLS + +--- a/configure.ac ++++ b/configure.ac +@@ -4169,6 +4169,9 @@ AC_CHECK_FUNCS([ \ + strrchr \ + strstr \ + syscall \ ++ timerfd_create \ ++ timerfd_gettime \ ++ timerfd_settime \ + utimensat \ + process_vm_readv \ + process_vm_writev \ +--- a/memcheck/tests/linux/timerfd-syscall.c ++++ b/memcheck/tests/linux/timerfd-syscall.c +@@ -54,7 +54,7 @@ + * timerfd_* system call numbers introduced in 2.6.23. These constants are + * not yet in the glibc 2.7 headers, that is why they are defined here. + */ +-#ifndef __NR_timerfd_create ++#if !defined(__NR_timerfd_create) && !defined(HAVE_TIMERFD_CREATE) + #if defined(__x86_64__) + #define __NR_timerfd_create 283 + #elif defined(__i386__) +@@ -68,7 +68,7 @@ + #endif + #endif + +-#ifndef __NR_timerfd_settime ++#if !defined(__NR_timerfd_settime) && !defined(HAVE_TIMERFD_SETTIME) + #if defined(__x86_64__) + #define __NR_timerfd_settime 286 + #define __NR_timerfd_gettime 287 +@@ -127,21 +127,27 @@ void set_timespec(struct timespec *tmr, + tmr->tv_nsec = (long) (1000ULL * (ustime % 1000000ULL)); + } + ++#if !defined(HAVE_TIMERFD_CREATE) + int timerfd_create(int clockid, int flags) + { + return syscall(__NR_timerfd_create, clockid, flags); + } ++#endif + ++#if !defined(HAVE_TIMERFD_SETTIME) + int timerfd_settime(int ufc, int flags, const struct itimerspec *utmr, + struct itimerspec *otmr) + { + return syscall(__NR_timerfd_settime, ufc, flags, utmr, otmr); + } ++#endif + ++#if !defined(HAVE_TIMERFD_GETTIME) + int timerfd_gettime(int ufc, struct itimerspec *otmr) + { + return syscall(__NR_timerfd_gettime, ufc, otmr); + } ++#endif + + long waittmr(int tfd, int timeo) + { diff --git a/meta/recipes-devtools/valgrind/valgrind_3.15.0.bb b/meta/recipes-devtools/valgrind/valgrind_3.15.0.bb index 1475ff841e..7954437a1a 100644 --- a/meta/recipes-devtools/valgrind/valgrind_3.15.0.bb +++ b/meta/recipes-devtools/valgrind/valgrind_3.15.0.bb @@ -41,6 +41,7 @@ SRC_URI = "https://sourceware.org/pub/valgrind/valgrind-${PV}.tar.bz2 \ file://s390x_vec_op_t.patch \ file://0001-none-tests-fdleak_cmsg.stderr.exp-adjust-tmp-paths.patch \ file://0001-tests-Make-pthread_detatch-call-portable-across-plat.patch \ + file://0001-memcheck-tests-Fix-timerfd-syscall-test.patch \ " SRC_URI[md5sum] = "46e5fbdcbc3502a5976a317a0860a975" SRC_URI[sha256sum] = "417c7a9da8f60dd05698b3a7bc6002e4ef996f14c13f0ff96679a16873e78ab1" -- 2.25.1 From raj.khem at gmail.com Mon Mar 9 23:47:09 2020 From: raj.khem at gmail.com (Khem Raj) Date: Mon, 9 Mar 2020 16:47:09 -0700 Subject: [OE-core] [PATCH] dbus-test: Replace cp -a with portable options Message-ID: <20200309234709.1463471-1-raj.khem@gmail.com> -a option is linux specific Errors like below are fixed when -a is used bus/connection.h is owned by uid 1000, which is the same as t he user running bitbake. This may be due to host contamination Signed-off-by: Khem Raj --- meta/recipes-core/dbus/dbus-test_1.12.16.bb | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/recipes-core/dbus/dbus-test_1.12.16.bb b/meta/recipes-core/dbus/dbus-test_1.12.16.bb index bea0e74ed0..91e2ba69d2 100644 --- a/meta/recipes-core/dbus/dbus-test_1.12.16.bb +++ b/meta/recipes-core/dbus/dbus-test_1.12.16.bb @@ -70,11 +70,11 @@ do_install_ptest() { install ${B}/test/test-segfault ${D}${PTEST_PATH}/test - cp -r ${B}/test/data ${D}${PTEST_PATH}/test + cp -R --no-dereference --preserve=mode,links ${B}/test/data ${D}${PTEST_PATH}/test install ${B}/dbus/.libs/test-dbus ${D}${PTEST_PATH}/test install -d ${D}${PTEST_PATH}/test/.libs - cp -a ${B}/dbus/.libs/*.so* ${D}${PTEST_PATH}/test/.libs + cp -R --no-dereference --preserve=mode,links ${B}/dbus/.libs/*.so* ${D}${PTEST_PATH}/test/.libs # Remove build host references... find "${D}${PTEST_PATH}/test/data" \( -name *.service -o -name *.conf -o -name "*.aaprofile" \) -type f -exec \ -- 2.25.1 From armccurdy at gmail.com Mon Mar 9 23:52:17 2020 From: armccurdy at gmail.com (Andre McCurdy) Date: Mon, 9 Mar 2020 16:52:17 -0700 Subject: [OE-core] [PATCH 1/2] ruby: Use arm32 for coroutines on 32bit-arm In-Reply-To: <20200309234454.1387958-1-raj.khem@gmail.com> References: <20200309234454.1387958-1-raj.khem@gmail.com> Message-ID: On Mon, Mar 9, 2020 at 4:44 PM Khem Raj wrote: > > in 2.7 [2] ruby enabled ucontext for coroutines on arm32 but it does not > work for musl since it uses glibc specific functions e.g. > getcontext/swapcontext/swapcontext also see [1] > > This patch reverts back to using arm32 implementation for coroutines on > arm > > [1] https://bugs.ruby-lang.org/issues/16455#change-83442 > [2] https://github.com/ruby/ruby/commit/6c6bf9ffcbfeb8be9d9c342e7604b74ec819e88a#diff-7fccec8474e2184cd2518046bf39d54cL10 > > Signed-off-by: Khem Raj > --- > meta/recipes-devtools/ruby/ruby_2.7.0.bb | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/meta/recipes-devtools/ruby/ruby_2.7.0.bb b/meta/recipes-devtools/ruby/ruby_2.7.0.bb > index 268b4bebd9..884bb0ef44 100644 > --- a/meta/recipes-devtools/ruby/ruby_2.7.0.bb > +++ b/meta/recipes-devtools/ruby/ruby_2.7.0.bb > @@ -25,6 +25,8 @@ EXTRA_OECONF = "\ > --with-pkg-config=pkg-config \ > " > > +EXTRA_OECONF_append_arm_libc-musl = " --with-coroutine=arm32" Generally any _arm over-ride should either be duplicated for _armeb too (or the commit message should explain why the over-ride is specific to little endian ARM only). > do_install() { > oe_runmake 'DESTDIR=${D}' install > } > -- > 2.25.1 > > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core at lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core From armccurdy at gmail.com Tue Mar 10 00:00:19 2020 From: armccurdy at gmail.com (Andre McCurdy) Date: Mon, 9 Mar 2020 17:00:19 -0700 Subject: [OE-core] [PATCH] dbus-test: Replace cp -a with portable options In-Reply-To: <20200309234709.1463471-1-raj.khem@gmail.com> References: <20200309234709.1463471-1-raj.khem@gmail.com> Message-ID: On Mon, Mar 9, 2020 at 4:47 PM Khem Raj wrote: > > -a option is linux specific Is it? > Errors like below are fixed when -a is used Do you mean the errors are fixed when -a is _not_ used ? Either way, the key fix here looks to be effectively removing --preserve=ownership from the cp command, not somehow making the cp command line arguments more portable as the subject implies. There are many similar fixes already in oe-core and meta-oe. > bus/connection.h is owned by uid 1000, which is the same as t > he user running bitbake. This may be due to host contamination > > Signed-off-by: Khem Raj > --- > meta/recipes-core/dbus/dbus-test_1.12.16.bb | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/meta/recipes-core/dbus/dbus-test_1.12.16.bb b/meta/recipes-core/dbus/dbus-test_1.12.16.bb > index bea0e74ed0..91e2ba69d2 100644 > --- a/meta/recipes-core/dbus/dbus-test_1.12.16.bb > +++ b/meta/recipes-core/dbus/dbus-test_1.12.16.bb > @@ -70,11 +70,11 @@ do_install_ptest() { > > install ${B}/test/test-segfault ${D}${PTEST_PATH}/test > > - cp -r ${B}/test/data ${D}${PTEST_PATH}/test > + cp -R --no-dereference --preserve=mode,links ${B}/test/data ${D}${PTEST_PATH}/test > install ${B}/dbus/.libs/test-dbus ${D}${PTEST_PATH}/test > > install -d ${D}${PTEST_PATH}/test/.libs > - cp -a ${B}/dbus/.libs/*.so* ${D}${PTEST_PATH}/test/.libs > + cp -R --no-dereference --preserve=mode,links ${B}/dbus/.libs/*.so* ${D}${PTEST_PATH}/test/.libs > > # Remove build host references... > find "${D}${PTEST_PATH}/test/data" \( -name *.service -o -name *.conf -o -name "*.aaprofile" \) -type f -exec \ > -- > 2.25.1 > > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core at lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core From raj.khem at gmail.com Tue Mar 10 00:33:27 2020 From: raj.khem at gmail.com (Khem Raj) Date: Mon, 9 Mar 2020 17:33:27 -0700 Subject: [OE-core] [PATCH 1/2] ruby: Use arm32 for coroutines on 32bit-arm In-Reply-To: References: <20200309234454.1387958-1-raj.khem@gmail.com> Message-ID: <07048b68-f3c4-5196-ec72-63a5aeddccd7@gmail.com> On 3/9/20 4:52 PM, Andre McCurdy wrote: > On Mon, Mar 9, 2020 at 4:44 PM Khem Raj wrote: >> >> in 2.7 [2] ruby enabled ucontext for coroutines on arm32 but it does not >> work for musl since it uses glibc specific functions e.g. >> getcontext/swapcontext/swapcontext also see [1] >> >> This patch reverts back to using arm32 implementation for coroutines on >> arm >> >> [1] https://bugs.ruby-lang.org/issues/16455#change-83442 >> [2] https://github.com/ruby/ruby/commit/6c6bf9ffcbfeb8be9d9c342e7604b74ec819e88a#diff-7fccec8474e2184cd2518046bf39d54cL10 >> >> Signed-off-by: Khem Raj >> --- >> meta/recipes-devtools/ruby/ruby_2.7.0.bb | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/meta/recipes-devtools/ruby/ruby_2.7.0.bb b/meta/recipes-devtools/ruby/ruby_2.7.0.bb >> index 268b4bebd9..884bb0ef44 100644 >> --- a/meta/recipes-devtools/ruby/ruby_2.7.0.bb >> +++ b/meta/recipes-devtools/ruby/ruby_2.7.0.bb >> @@ -25,6 +25,8 @@ EXTRA_OECONF = "\ >> --with-pkg-config=pkg-config \ >> " >> >> +EXTRA_OECONF_append_arm_libc-musl = " --with-coroutine=arm32" > > Generally any _arm over-ride should either be duplicated for _armeb > too (or the commit message should explain why the over-ride is > specific to little endian ARM only). its just that I did not test it on armeb, and its assembly piece which would need some testing on BE before it is enabled. > >> do_install() { >> oe_runmake 'DESTDIR=${D}' install >> } >> -- >> 2.25.1 >> >> -- >> _______________________________________________ >> Openembedded-core mailing list >> Openembedded-core at lists.openembedded.org >> http://lists.openembedded.org/mailman/listinfo/openembedded-core -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From armccurdy at gmail.com Tue Mar 10 01:11:16 2020 From: armccurdy at gmail.com (Andre McCurdy) Date: Mon, 9 Mar 2020 18:11:16 -0700 Subject: [OE-core] [PATCH 1/2] ruby: Use arm32 for coroutines on 32bit-arm In-Reply-To: <07048b68-f3c4-5196-ec72-63a5aeddccd7@gmail.com> References: <20200309234454.1387958-1-raj.khem@gmail.com> <07048b68-f3c4-5196-ec72-63a5aeddccd7@gmail.com> Message-ID: On Mon, Mar 9, 2020 at 5:33 PM Khem Raj wrote: > > On 3/9/20 4:52 PM, Andre McCurdy wrote: > > On Mon, Mar 9, 2020 at 4:44 PM Khem Raj wrote: > >> > >> in 2.7 [2] ruby enabled ucontext for coroutines on arm32 but it does not > >> work for musl since it uses glibc specific functions e.g. > >> getcontext/swapcontext/swapcontext also see [1] > >> > >> This patch reverts back to using arm32 implementation for coroutines on > >> arm > >> > >> [1] https://bugs.ruby-lang.org/issues/16455#change-83442 > >> [2] https://github.com/ruby/ruby/commit/6c6bf9ffcbfeb8be9d9c342e7604b74ec819e88a#diff-7fccec8474e2184cd2518046bf39d54cL10 > >> > >> Signed-off-by: Khem Raj > >> --- > >> meta/recipes-devtools/ruby/ruby_2.7.0.bb | 2 ++ > >> 1 file changed, 2 insertions(+) > >> > >> diff --git a/meta/recipes-devtools/ruby/ruby_2.7.0.bb b/meta/recipes-devtools/ruby/ruby_2.7.0.bb > >> index 268b4bebd9..884bb0ef44 100644 > >> --- a/meta/recipes-devtools/ruby/ruby_2.7.0.bb > >> +++ b/meta/recipes-devtools/ruby/ruby_2.7.0.bb > >> @@ -25,6 +25,8 @@ EXTRA_OECONF = "\ > >> --with-pkg-config=pkg-config \ > >> " > >> > >> +EXTRA_OECONF_append_arm_libc-musl = " --with-coroutine=arm32" > > > > Generally any _arm over-ride should either be duplicated for _armeb > > too (or the commit message should explain why the over-ride is > > specific to little endian ARM only). > > its just that I did not test it on armeb, and its assembly piece which > would need some testing on BE before it is enabled. The default should be to keep arm and armeb in sync, unless there's a clear reason not to. If you want to test big endian ARM then that's great, but if you don't then just keeping the two targets in sync is better than leaving big endian ARM unfixed _and_ untested. > >> do_install() {> >> oe_runmake 'DESTDIR=${D}' install > >> } > >> -- > >> 2.25.1 > >> > >> -- > >> _______________________________________________ > >> Openembedded-core mailing list > >> Openembedded-core at lists.openembedded.org > >> http://lists.openembedded.org/mailman/listinfo/openembedded-core > From raj.khem at gmail.com Tue Mar 10 01:15:42 2020 From: raj.khem at gmail.com (Khem Raj) Date: Mon, 9 Mar 2020 18:15:42 -0700 Subject: [OE-core] [PATCH V2 1/3] ruby: Use arm32 for coroutines on 32bit-arm Message-ID: <20200310011544.3022342-1-raj.khem@gmail.com> in 2.7 [2] ruby enabled ucontext for coroutines on arm32 but it does not work for musl since it uses glibc specific functions e.g. getcontext/swapcontext/swapcontext also see [1] This patch reverts back to using arm32 implementation for coroutines on arm [1] https://bugs.ruby-lang.org/issues/16455#change-83442 [2] https://github.com/ruby/ruby/commit/6c6bf9ffcbfeb8be9d9c342e7604b74ec819e88a#diff-7fccec8474e2184cd2518046bf39d54cL10 Signed-off-by: Khem Raj --- v2: No change meta/recipes-devtools/ruby/ruby_2.7.0.bb | 2 ++ 1 file changed, 2 insertions(+) diff --git a/meta/recipes-devtools/ruby/ruby_2.7.0.bb b/meta/recipes-devtools/ruby/ruby_2.7.0.bb index 268b4bebd9..884bb0ef44 100644 --- a/meta/recipes-devtools/ruby/ruby_2.7.0.bb +++ b/meta/recipes-devtools/ruby/ruby_2.7.0.bb @@ -25,6 +25,8 @@ EXTRA_OECONF = "\ --with-pkg-config=pkg-config \ " +EXTRA_OECONF_append_arm_libc-musl = " --with-coroutine=arm32" + do_install() { oe_runmake 'DESTDIR=${D}' install } -- 2.25.1 From raj.khem at gmail.com Tue Mar 10 01:15:43 2020 From: raj.khem at gmail.com (Khem Raj) Date: Mon, 9 Mar 2020 18:15:43 -0700 Subject: [OE-core] [PATCH V2 2/3] valgrind: Fix timerfd syscall test to be 64bit time_t safe In-Reply-To: <20200310011544.3022342-1-raj.khem@gmail.com> References: <20200310011544.3022342-1-raj.khem@gmail.com> Message-ID: <20200310011544.3022342-2-raj.khem@gmail.com> This helps compile the testcase with musl on 32bit arches Signed-off-by: Khem Raj --- v2: Use header check instead of function checks ...check-tests-Fix-timerfd-syscall-test.patch | 98 +++++++++++++++++++ .../valgrind/valgrind_3.15.0.bb | 1 + 2 files changed, 99 insertions(+) create mode 100644 meta/recipes-devtools/valgrind/valgrind/0001-memcheck-tests-Fix-timerfd-syscall-test.patch diff --git a/meta/recipes-devtools/valgrind/valgrind/0001-memcheck-tests-Fix-timerfd-syscall-test.patch b/meta/recipes-devtools/valgrind/valgrind/0001-memcheck-tests-Fix-timerfd-syscall-test.patch new file mode 100644 index 0000000000..15fbbe954f --- /dev/null +++ b/meta/recipes-devtools/valgrind/valgrind/0001-memcheck-tests-Fix-timerfd-syscall-test.patch @@ -0,0 +1,98 @@ +From 5d411fd147d652e9d7bb259f4048693c6e4742aa Mon Sep 17 00:00:00 2001 +From: Khem Raj +Date: Mon, 9 Mar 2020 16:30:19 -0700 +Subject: [PATCH] memcheck/tests: Fix timerfd syscall test + +modern libc provides these functions, moreover this also ensures that we +are 64bit time_t safe. Fallback to existing definitions if libc does not +have the implementation or syscall is not defined + +Upstream-Status: Submitted [https://sourceforge.net/p/valgrind/mailman/message/36943897/] +Signed-off-by: Khem Raj +--- + config.h.in | 9 +++++++++ + configure.ac | 3 +++ + memcheck/tests/linux/timerfd-syscall.c | 10 ++++++++-- + 5 files changed, 32 insertions(+), 2 deletions(-) + +--- a/config.h.in ++++ b/config.h.in +@@ -301,6 +301,9 @@ + /* Define to 1 if you have the header file. */ + #undef HAVE_SYS_SYSNVL_H + ++/* Define to 1 if you have the header file. */ ++#undef HAVE_SYS_TIMERFD_H ++ + /* Define to 1 if you have the header file. */ + #undef HAVE_SYS_TIME_H + +--- a/configure.ac ++++ b/configure.ac +@@ -4098,6 +4098,7 @@ AC_CHECK_HEADERS([ \ + sys/syscall.h \ + sys/sysnvl.h \ + sys/time.h \ ++ sys/timerfd.h \ + sys/types.h \ + ]) + +--- a/memcheck/tests/linux/timerfd-syscall.c ++++ b/memcheck/tests/linux/timerfd-syscall.c +@@ -45,6 +45,9 @@ + #if defined(HAVE_SYS_TIME_H) + #include + #endif ++#if defined(HAVE_SYS_TIMERFD_H) ++#include ++#endif + #if defined(HAVE_SYS_TYPES_H) + #include + #endif +@@ -54,7 +57,8 @@ + * timerfd_* system call numbers introduced in 2.6.23. These constants are + * not yet in the glibc 2.7 headers, that is why they are defined here. + */ +-#ifndef __NR_timerfd_create ++#if !defined(HAVE_SYS_TIMERFD_H) ++#if !defined(__NR_timerfd_create) + #if defined(__x86_64__) + #define __NR_timerfd_create 283 + #elif defined(__i386__) +@@ -67,8 +71,10 @@ + #error Cannot detect your architecture! + #endif + #endif ++#endif + +-#ifndef __NR_timerfd_settime ++#if !defined(HAVE_SYS_TIMERFD_H) ++#if !defined(__NR_timerfd_settime) + #if defined(__x86_64__) + #define __NR_timerfd_settime 286 + #define __NR_timerfd_gettime 287 +@@ -85,7 +91,7 @@ + #error Cannot detect your architecture! + #endif + #endif +- ++#endif + + + /* Definitions from include/linux/timerfd.h */ +@@ -127,6 +133,7 @@ void set_timespec(struct timespec *tmr, + tmr->tv_nsec = (long) (1000ULL * (ustime % 1000000ULL)); + } + ++#if !defined(HAVE_SYS_TIMERFD_H) + int timerfd_create(int clockid, int flags) + { + return syscall(__NR_timerfd_create, clockid, flags); +@@ -142,6 +149,7 @@ int timerfd_gettime(int ufc, struct itim + { + return syscall(__NR_timerfd_gettime, ufc, otmr); + } ++#endif + + long waittmr(int tfd, int timeo) + { diff --git a/meta/recipes-devtools/valgrind/valgrind_3.15.0.bb b/meta/recipes-devtools/valgrind/valgrind_3.15.0.bb index 1475ff841e..7954437a1a 100644 --- a/meta/recipes-devtools/valgrind/valgrind_3.15.0.bb +++ b/meta/recipes-devtools/valgrind/valgrind_3.15.0.bb @@ -41,6 +41,7 @@ SRC_URI = "https://sourceware.org/pub/valgrind/valgrind-${PV}.tar.bz2 \ file://s390x_vec_op_t.patch \ file://0001-none-tests-fdleak_cmsg.stderr.exp-adjust-tmp-paths.patch \ file://0001-tests-Make-pthread_detatch-call-portable-across-plat.patch \ + file://0001-memcheck-tests-Fix-timerfd-syscall-test.patch \ " SRC_URI[md5sum] = "46e5fbdcbc3502a5976a317a0860a975" SRC_URI[sha256sum] = "417c7a9da8f60dd05698b3a7bc6002e4ef996f14c13f0ff96679a16873e78ab1" -- 2.25.1 From raj.khem at gmail.com Tue Mar 10 01:15:44 2020 From: raj.khem at gmail.com (Khem Raj) Date: Mon, 9 Mar 2020 18:15:44 -0700 Subject: [OE-core] [PATCH V2 3/3] dbus-test: Replace cp -a/-r with portable options In-Reply-To: <20200310011544.3022342-1-raj.khem@gmail.com> References: <20200310011544.3022342-1-raj.khem@gmail.com> Message-ID: <20200310011544.3022342-3-raj.khem@gmail.com> -r are not posix defined and -a leaks UID of build user into target Errors like below are fixed when -a is used bus/connection.h is owned by uid 1000, which is the same as t he user running bitbake. This may be due to host contamination Signed-off-by: Khem Raj --- v2: Improve commit message for clear reason for change meta/recipes-core/dbus/dbus-test_1.12.16.bb | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/recipes-core/dbus/dbus-test_1.12.16.bb b/meta/recipes-core/dbus/dbus-test_1.12.16.bb index bea0e74ed0..91e2ba69d2 100644 --- a/meta/recipes-core/dbus/dbus-test_1.12.16.bb +++ b/meta/recipes-core/dbus/dbus-test_1.12.16.bb @@ -70,11 +70,11 @@ do_install_ptest() { install ${B}/test/test-segfault ${D}${PTEST_PATH}/test - cp -r ${B}/test/data ${D}${PTEST_PATH}/test + cp -R --no-dereference --preserve=mode,links ${B}/test/data ${D}${PTEST_PATH}/test install ${B}/dbus/.libs/test-dbus ${D}${PTEST_PATH}/test install -d ${D}${PTEST_PATH}/test/.libs - cp -a ${B}/dbus/.libs/*.so* ${D}${PTEST_PATH}/test/.libs + cp -R --no-dereference --preserve=mode,links ${B}/dbus/.libs/*.so* ${D}${PTEST_PATH}/test/.libs # Remove build host references... find "${D}${PTEST_PATH}/test/data" \( -name *.service -o -name *.conf -o -name "*.aaprofile" \) -type f -exec \ -- 2.25.1 From raj.khem at gmail.com Tue Mar 10 01:19:38 2020 From: raj.khem at gmail.com (Khem Raj) Date: Mon, 9 Mar 2020 18:19:38 -0700 Subject: [OE-core] [PATCH V3] ruby: Use arm32 for coroutines on 32bit-arm Message-ID: <20200310011938.3027897-1-raj.khem@gmail.com> in 2.7 [2] ruby enabled ucontext for coroutines on arm32 but it does not work for musl since it uses glibc specific functions e.g. getcontext/swapcontext/swapcontext also see [1] This patch reverts back to using arm32 implementation for coroutines on arm [1] https://bugs.ruby-lang.org/issues/16455#change-83442 [2] https://github.com/ruby/ruby/commit/6c6bf9ffcbfeb8be9d9c342e7604b74ec819e88a#diff-7fccec8474e2184cd2518046bf39d54cL10 Signed-off-by: Khem Raj --- v2: No change v3: Include armeb as well meta/recipes-devtools/ruby/ruby_2.7.0.bb | 3 +++ 1 file changed, 3 insertions(+) diff --git a/meta/recipes-devtools/ruby/ruby_2.7.0.bb b/meta/recipes-devtools/ruby/ruby_2.7.0.bb index 268b4bebd9..44c76161d5 100644 --- a/meta/recipes-devtools/ruby/ruby_2.7.0.bb +++ b/meta/recipes-devtools/ruby/ruby_2.7.0.bb @@ -25,6 +25,9 @@ EXTRA_OECONF = "\ --with-pkg-config=pkg-config \ " +EXTRA_OECONF_append_libc-musl_arm = " --with-coroutine=arm32" +EXTRA_OECONF_append_libc-musl_armeb = " --with-coroutine=arm32" + do_install() { oe_runmake 'DESTDIR=${D}' install } -- 2.25.1 From richard.purdie at linuxfoundation.org Tue Mar 10 08:32:52 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Tue, 10 Mar 2020 08:32:52 +0000 Subject: [OE-core] [PATCH V2 3/3] dbus-test: Replace cp -a/-r with portable options In-Reply-To: <20200310011544.3022342-3-raj.khem@gmail.com> References: <20200310011544.3022342-1-raj.khem@gmail.com> <20200310011544.3022342-3-raj.khem@gmail.com> Message-ID: <9ed228f70b3728e140aa5a539bab07759d6d9914.camel@linuxfoundation.org> On Mon, 2020-03-09 at 18:15 -0700, Khem Raj wrote: > -r are not posix defined and -a leaks UID of > build user into target > > Errors like below are fixed when -a is used > > bus/connection.h is owned by uid 1000, which is the same as t > he user running bitbake. This may be due to host contamination > > Signed-off-by: Khem Raj > --- > v2: Improve commit message for clear reason for change > > meta/recipes-core/dbus/dbus-test_1.12.16.bb | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/meta/recipes-core/dbus/dbus-test_1.12.16.bb b/meta/recipes-core/dbus/dbus-test_1.12.16.bb > index bea0e74ed0..91e2ba69d2 100644 > --- a/meta/recipes-core/dbus/dbus-test_1.12.16.bb > +++ b/meta/recipes-core/dbus/dbus-test_1.12.16.bb > @@ -70,11 +70,11 @@ do_install_ptest() { > > install ${B}/test/test-segfault ${D}${PTEST_PATH}/test > > - cp -r ${B}/test/data ${D}${PTEST_PATH}/test > + cp -R --no-dereference --preserve=mode,links ${B}/test/data ${D}${PTEST_PATH}/test > install ${B}/dbus/.libs/test-dbus ${D}${PTEST_PATH}/test > > install -d ${D}${PTEST_PATH}/test/.libs > - cp -a ${B}/dbus/.libs/*.so* ${D}${PTEST_PATH}/test/.libs > + cp -R --no-dereference --preserve=mode,links ${B}/dbus/.libs/*.so* ${D}${PTEST_PATH}/test/.libs > > # Remove build host references... > find "${D}${PTEST_PATH}/test/data" \( -name *.service -o -name *.conf -o -name "*.aaprofile" \) -type f -exec \ I still want to understand why only you are seeing this first. The implication is that we have to change most uses of "cp -r" for "cp -R --no-dereference --preserve=mode,links " in OE-Core and every other OE layer. If we have to do that, fine, but I do want to understand what set of circumstances triggers the issue first. Cheers, Richard From jupiter.hce at gmail.com Tue Mar 10 09:23:37 2020 From: jupiter.hce at gmail.com (JH) Date: Tue, 10 Mar 2020 20:23:37 +1100 Subject: [OE-core] What is the Yocto / OE recipe for u-boot-fw-utils how can append it? Message-ID: Hi, I could not find u-boot-fw-utils recipe from OE git repository, when I added it to build package, it did build u-boot-fw-utils/1_2019.07-r0 from git://git.denx.de/u-boot.git, but I could not make a bbapend to it as I don't know what is the bb name. Appreciate your help and advice. Thank you. Kind regards, - jh From quentin.schulz at streamunlimited.com Tue Mar 10 09:29:21 2020 From: quentin.schulz at streamunlimited.com (Quentin Schulz) Date: Tue, 10 Mar 2020 10:29:21 +0100 Subject: [OE-core] [yocto] What is the Yocto / OE recipe for u-boot-fw-utils how can append it? In-Reply-To: References: Message-ID: <20200310092921.ezmnfiwemhcyno6a@qschulz> Hi JH, On Tue, Mar 10, 2020 at 08:23:37PM +1100, JH wrote: > Hi, > > I could not find u-boot-fw-utils recipe from OE git repository, when I > added it to build package, it did build u-boot-fw-utils/1_2019.07-r0 > from git://git.denx.de/u-boot.git, but I could not make a bbapend to > it as I don't know what is the bb name. > It was recently changed to libubootenv IIRC. Are you sure it was taken from u-boot git repo? In zeus you have both available if you have meta-swupdate layer but u-boot-fw-utils is still present in openembedded-core. In master, only libubootenv exists in openembedded-core. Are you using master for poky/openembedded? FWIW, what a recipe provides either at runtime or at buildtime is (R)PROVIDES, c.f.: http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-bsp/u-boot/libubootenv_0.2.bb?h=master Quentin From liezhi.yang at windriver.com Tue Mar 10 10:31:56 2020 From: liezhi.yang at windriver.com (Robert Yang) Date: Tue, 10 Mar 2020 18:31:56 +0800 Subject: [OE-core] [PATCH] e2fsprogs: update to 1.45.5 In-Reply-To: References: <20200224031226.6965-1-akuster808@gmail.com> <1f5759550013cdb49ebfb34194863af3d9dbcf6c.camel@linuxfoundation.org> <89e6bbf2-51ca-4dcf-46b3-e484d228f579@windriver.com> Message-ID: <258aff3b-11f8-dae7-0b2f-6ac15145dd90@windriver.com> Hi Armin, On 2/24/20 11:19 PM, akuster808 wrote: > > > On 2/24/20 3:13 AM, Robert Yang wrote: >> >> On 2/24/20 6:23 PM, Richard Purdie wrote: >>> On Sun, 2020-02-23 at 19:12 -0800, Armin Kuster wrote: >>>> Dropping patch 0001-misc-create_inode.c-set-dir-s-mode- >>>> correctly.patch as upstream has not been accepted for over 2 years >>>> and we should not carry it if upstream has not taking it after all >>>> that time. >>> >>> Looking at the patch, this worries me a lot. Why have upstream not >>> taken it? Did they say it was incorrect? >> >> I can't find any records about it, maybe I didn't send it because of >> some reason. >> >> We still need it. I refreshed the patch and sent to upstream. >> >> @Armin, The refreshed patch is in the attachment. > > Will do. thanks for the feedback. Seems that e2fsprogs didn't update to 1.45.5. After I sent the patch to upstream, they fixed the issue in another way: https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/?id=f106b01c98d7abc12af39aad4024f17ffa14dc06 If you upgrade it to 1.45.5, you can use the upstream patch to replace the current one, but if you don't upgrade it, I'm leaning to keep the current patch since some context are different. // Robert > > - armin >> >> // Robert >> >>> >>> We wrote the original code to handle offline root here so its entirely >>> possible this is a value issue and we'll break filesystems if we don't >>> have that patch :( >>> >>> I can't take a change like this without more info, CVE or not. >> >>> >>> Cheers, >>> >>> Richard >>> >>> >>>> Includes: CVE-2019-5188 >>>> >>>> see http://e2fsprogs.sourceforge.net/e2fsprogs-release.html#1.45.5 >>>> for more information. >>>> >>>> Signed-off-by: Armin Kuster >>>> --- >>>> ? ...ate_inode.c-set-dir-s-mode-correctly.patch | 41 --------------- >>>> ---- >>>> ? ...2fsprogs_1.45.4.bb => e2fsprogs_1.45.5.bb} |? 3 +- >>>> ? 2 files changed, 1 insertion(+), 43 deletions(-) >>>> ? delete mode 100644 meta/recipes-devtools/e2fsprogs/e2fsprogs/0001- >>>> misc-create_inode.c-set-dir-s-mode-correctly.patch >>>> ? rename meta/recipes-devtools/e2fsprogs/{e2fsprogs_1.45.4.bb => >>>> e2fsprogs_1.45.5.bb} (97%) >>>> >>>> diff --git a/meta/recipes-devtools/e2fsprogs/e2fsprogs/0001-misc- >>>> create_inode.c-set-dir-s-mode-correctly.patch b/meta/recipes- >>>> devtools/e2fsprogs/e2fsprogs/0001-misc-create_inode.c-set-dir-s-mode- >>>> correctly.patch >>>> deleted file mode 100644 >>>> index fc4a5409860..00000000000 >>>> --- a/meta/recipes-devtools/e2fsprogs/e2fsprogs/0001-misc- >>>> create_inode.c-set-dir-s-mode-correctly.patch >>>> +++ /dev/null >>>> @@ -1,41 +0,0 @@ >>>> -From f6d188580c2c9599319076fee22f2424652c711c Mon Sep 17 00:00:00 >>>> 2001 >>>> -From: Robert Yang >>>> -Date: Wed, 13 Sep 2017 19:55:35 -0700 >>>> -Subject: [PATCH] misc/create_inode.c: set dir's mode correctly >>>> - >>>> -The dir's mode has been set by ext2fs_mkdir() with umask, so >>>> -reset it to the source's mode in set_inode_extra(). >>>> - >>>> -Fixed when source dir's mode is 521, but tarball would be 721, this >>>> was >>>> -incorrect. >>>> - >>>> -Upstream-Status: Submitted >>>> - >>>> -Signed-off-by: Robert Yang >>>> ---- >>>> - misc/create_inode.c | 9 ++++++++- >>>> - 1 file changed, 8 insertions(+), 1 deletion(-) >>>> - >>>> -diff --git a/misc/create_inode.c b/misc/create_inode.c >>>> -index 8ce3faf..50fbaa8 100644 >>>> ---- a/misc/create_inode.c >>>> -+++ b/misc/create_inode.c >>>> -@@ -116,7 +116,14 @@ static errcode_t set_inode_extra(ext2_filsys >>>> fs, ext2_ino_t ino, >>>> - >>>> -???? inode.i_uid = st->st_uid; >>>> -???? inode.i_gid = st->st_gid; >>>> --??? inode.i_mode |= st->st_mode; >>>> -+??? /* >>>> -+???? * The dir's mode has been set by ext2fs_mkdir() with umask, so >>>> -+???? * reset it to the source's mode >>>> -+???? */ >>>> -+??? if S_ISDIR(st->st_mode) >>>> -+??????? inode.i_mode = LINUX_S_IFDIR | st->st_mode; >>>> -+??? else >>>> -+??????? inode.i_mode |= st->st_mode; >>>> -???? inode.i_atime = st->st_atime; >>>> -???? inode.i_mtime = st->st_mtime; >>>> -???? inode.i_ctime = st->st_ctime; >>>> --- >>>> -2.10.2 >>>> - >>>> diff --git a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.45.4.bb >>>> b/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.45.5.bb >>>> similarity index 97% >>>> rename from meta/recipes-devtools/e2fsprogs/e2fsprogs_1.45.4.bb >>>> rename to meta/recipes-devtools/e2fsprogs/e2fsprogs_1.45.5.bb >>>> index 6e69eea21c3..7cd42b8137a 100644 >>>> --- a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.45.4.bb >>>> +++ b/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.45.5.bb >>>> @@ -4,7 +4,6 @@ SRC_URI += "file://remove.ldconfig.call.patch \ >>>> ???????????? file://run-ptest \ >>>> ???????????? file://ptest.patch \ >>>> ???????????? file://mkdir_p.patch \ >>>> -?????????? file://0001-misc-create_inode.c-set-dir-s-mode- >>>> correctly.patch \ >>>> ???????????? file://0001-configure.ac-correct-AM_GNU_GETTEXT.patch \ >>>> ???????????? file://0001-intl-do-not-try-to-use-gettext-defines-that- >>>> no-longe.patch \ >>>> ???????????? " >>>> @@ -13,7 +12,7 @@ SRC_URI_append_class-native = " >>>> file://e2fsprogs-fix-missing-check-for-permissio >>>> ????????????????????????????????? file://quiet-debugfs.patch \ >>>> ? " >>>> ? -SRCREV = "984ff8d6a0a1d5dc300505f67b38ed5047d51dac" >>>> +SRCREV = "c2b1ec5fbc99ab8a2b71dae45d486b3ea004f618" >>>> ? UPSTREAM_CHECK_GITTAGREGEX = "v(?P\d+\.\d+(\.\d+)*)$" >>>> ? ? EXTRA_OECONF += "--libdir=${base_libdir} >>>> --sbindir=${base_sbindir} \ >>>> -- >>>> 2.17.1 >>>> >>> >>> > > From Mikko.Rapeli at bmw.de Tue Mar 10 12:26:47 2020 From: Mikko.Rapeli at bmw.de (Mikko.Rapeli at bmw.de) Date: Tue, 10 Mar 2020 12:26:47 +0000 Subject: [OE-core] how to cleanly centralize a zillion BBCLASSEXTEND += "nativesdk" settings? In-Reply-To: <20200302074035.Horde.5xguZSt_-_Yd241eE1Zo8Pb@crashcourse.ca> References: <20200302074035.Horde.5xguZSt_-_Yd241eE1Zo8Pb@crashcourse.ca> Message-ID: <20200310122646.GW104502@korppu> On Mon, Mar 02, 2020 at 07:40:35AM -0500, rpjday at crashcourse.ca wrote: > layer i'm currently perusing has many, many bbappend files, of which > quite a number are nothing more than the single line: > > BBCLASSEXTEND += "nativesdk" > > literally, at least a hundred append files are like that. so rather > than clutter up the layer with all those trivial .bbappend files, > can one cram all that into a single .conf file? as i read it, can i > do something like: > > BBCLASSEXTEND_append_pn-pkg1 = " nativesdk" > BBCLASSEXTEND_append_pn-pkg2 = " nativesdk" > ... and on and on ... > > and toss all that into a distro.conf file or something? > > and even if that works, is it considered good coding style? FWIW, I have the same problem. Solution until now is large number of bbappends for adding native and nativesdk support. -Mikko From richard.purdie at linuxfoundation.org Tue Mar 10 13:03:18 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Tue, 10 Mar 2020 13:03:18 +0000 Subject: [OE-core] [PATCH] oeqa/selftest: Ensure buildtools in environment variables isn't replaced Message-ID: <20200310130318.27749-1-richard.purdie@linuxfoundation.org> This avoids the seeing broken replacements like: oe-selftest-centos/build/build-st-926tools/sysroots/x86_64-pokysdk-linux/etc/ssl/certs/ca-certificates.crt which understandably break builds. Signed-off-by: Richard Purdie --- meta/lib/oeqa/selftest/context.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/lib/oeqa/selftest/context.py b/meta/lib/oeqa/selftest/context.py index 409698d57ce..48ec5d419c7 100644 --- a/meta/lib/oeqa/selftest/context.py +++ b/meta/lib/oeqa/selftest/context.py @@ -46,7 +46,7 @@ class OESelftestTestContext(OETestContext): oe.path.copytree(selftestdir, newselftestdir) for e in os.environ: - if builddir in os.environ[e]: + if builddir + "/" in os.environ[e] or os.environ[e].endswith(builddir): os.environ[e] = os.environ[e].replace(builddir, newbuilddir) subprocess.check_output("git init; git add *; git commit -a -m 'initial'", cwd=newselftestdir, shell=True) -- 2.25.0 From rbilovol at cisco.com Tue Mar 10 14:44:08 2020 From: rbilovol at cisco.com (Ruslan Bilovol) Date: Tue, 10 Mar 2020 16:44:08 +0200 Subject: [OE-core] [PATCH RESEND] openssl: pass PERL=perl environment variable to configurator In-Reply-To: References: <20200305115333.31139-1-rbilovol@cisco.com> Message-ID: <26d3e02c-0dd3-9bcf-fe48-d51ca7e57ea0@cisco.com> On 3/7/20 12:19 AM, Martin Jansa wrote: > This breaks c_rehash calls from dash (works fine with bash) Yes, we use bach during our builds > > dash doesn't like > #!perl > shebang, would > PERL="/usr/bin/env perl" > work for you? > > But unfortunately?just passing PERL like this doesn't pass do_configure: > Creating Makefile > sh: 1: /usr/bin/env perl: not found > WARNING: exit code 1 from a shell command. > > But passing it as: > HASHBANGPERL="/usr/bin/env perl" PERL=perl > seems to work. Will check this suggestion Thanks, Ruslan > > On Thu, Mar 5, 2020 at 12:55 PM Ruslan Bilovol via Openembedded-core > > wrote: > > In our build environment we use wrapper script > for perl in non-standard configuration with > extra variables set (provided by custom > buildtools-tarball). > > In this case openssl fails to build because > by default it's Configure script detects and uses > perl executable directly (with absolute path) > obviously missing extra settings from wrapper > script. > > Pass PERL=perl environment variable to Configure, > so it won't try to use perl executable directly > but will use what is provided from environment. > > Signed-off-by: Ruslan Bilovol > > --- > ?meta/recipes-connectivity/openssl/openssl_1.1.1d.bb > | 2 +- > ?1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb > > b/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb > > index c2ba005f47..d4871fe973 100644 > --- a/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb > > +++ b/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb > > @@ -123,7 +123,7 @@ do_configure () { > ? ? ? ? fi > ? ? ? ? # WARNING: do not set compiler/linker flags (-I/-D etc.) in > EXTRA_OECONF, as they will fully replace the > ? ? ? ? # environment variables set by bitbake. Adjust the > environment variables instead. > -? ? ? ?PERL5LIB="${S}/external/perl/Text-Template-1.46/lib/" \ > +? ? ? ?PERL=perl > PERL5LIB="${S}/external/perl/Text-Template-1.46/lib/" \ > ? ? ? ? perl ${S}/Configure ${EXTRA_OECONF} > ${PACKAGECONFIG_CONFARGS} --prefix=$useprefix > --openssldir=${libdir}/ssl-1.1 --libdir=${libdir} $target > ? ? ? ? perl ${B}/configdata.pm --dump > ?} > -- > 2.17.1 > > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core at lists.openembedded.org > > http://lists.openembedded.org/mailman/listinfo/openembedded-core > From sjolley.yp.pm at gmail.com Tue Mar 10 14:45:11 2020 From: sjolley.yp.pm at gmail.com (sjolley.yp.pm at gmail.com) Date: Tue, 10 Mar 2020 07:45:11 -0700 Subject: [OE-core] Yocto Project Status WW10'20 Message-ID: <00d301d5f6ea$811bf190$8353d4b0$@gmail.com> Current Dev Position: YP 3.1 M3 - At Feature Freeze, build pending Next Deadline: YP 3.1 M3 build date 2/24/2020 Next Team Meetings: * Bug Triage meeting Thursday Mar. 12th at 7:30am PDT ( https://zoom.us/j/454367603) * Monthly Project Meeting Tuesday Apr. 7th at 8am PDT ( https://zoom.us/j/990892712) * Weekly Engineering Sync Tuesday Mar. 10th at 8am PDT ( https://zoom.us/j/990892712) * Twitch - See http://www.twitch.tv/letoatreidesthe2nd Key Status/Updates: * YP 3.1 has been announced as an LTS release: https://www.yoctoproject.org/yocto-project-long-term-support-announced/ * We are now past M3 feature freeze. The blocking issues continue to reduce, thanks to everyone who has contributed fixes. The remaining issues are: * continued minor bugs with buildtools tarball integration * coreutils ptest blocked on reproducibility issues with gcc-plugins * SystemExit() intermittent selftest failure * pseudo sysroot high priority bug * There are significant changes proposed to bitbake's logging structure to address concerns raised by hashequiv changes. These are currently in testing and are likely to become part of M3 given the timing, wider review is welcome. * Recipe upgrades are now unlikely to be merged into 3.1 as we focus on stabilizing and bug fixing for the release * Autobuilder build results continue to be a concern as we're not getting green builds very often due to multiple varied issues. YP 3.1 Milestone Dates: * YP 3.1 M3 build date 2/24/2020 * YP 3.1 M3 release date 3/6/2020 * YP 3.1 M4 build date 3/30/2020 * YP 3.1 M4 release date 4/24/2020 Planned upcoming dot releases: * YP 3.0.3 build date 5/4/2020 * YP 3.0.3 release date 5/15/2020 * YP 2.7.4 build date 5/18/2020 * YP 2.7.4 release date 5/29/2020 Tracking Metrics: * WDD 2703 (last week 2720) ( https://wiki.yoctoproject.org/charts/combo.html) * Poky Patch Metrics * Total patches found: 1354 (last week 1346) * Patches in the Pending State: 541 (40%) [last week 539 (40%)] The Yocto Project's technical governance is through its Technical Steering Committee, more information is available at: https://wiki.yoctoproject.org/wiki/TSC 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 * Cell: (208) 244-4460 * Email: sjolley.yp.pm at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ross at burtonini.com Tue Mar 10 16:11:48 2020 From: ross at burtonini.com (Ross Burton) Date: Tue, 10 Mar 2020 16:11:48 +0000 Subject: [OE-core] [Openembedded-architecture] Does YP provide security support for stable and LTS branches? In-Reply-To: References: <20200304113217.GB7923@localhost> <20200304140109.GC7923@localhost> <20200304172415.GA29456@localhost> <01b3bb37-f65f-8048-1a27-b859b62d7f98@gmail.com> <20200306100422.GA17785@localhost> <877e317932176664bc7b0120439c56d4dda791af.camel@linuxfoundation.org> <20200308214610.GB1425@localhost> <20200309002308.GD1425@localhost> Message-ID: On Mon, 9 Mar 2020 at 07:45, Ayoub Zaki wrote: > Adrian is making a point here, The Yocto Project by claiming that it > supports security patches for Stable releases is misleading the Users! > > I work with different customers and some of them think that by using and > pulling the latest releases they will get the CVEs automatically fixed! > > YP should state that CLEARLY! Of course it will impact the choice of > going with Yocto or Not ( probably NOT in this case). What would the alternative to Yocto be, and what is their security policy? Does e.g. buildroot commit to fixing every known security issue (which is more than just known CVEs) in their releases? Ross From alex.kanavin at gmail.com Tue Mar 10 19:43:28 2020 From: alex.kanavin at gmail.com (Alexander Kanavin) Date: Tue, 10 Mar 2020 20:43:28 +0100 Subject: [OE-core] [PATCH] libdnf: fix upstream version check Message-ID: <20200310194328.8131-1-alex.kanavin@gmail.com> Signed-off-by: Alexander Kanavin --- meta/recipes-devtools/libdnf/libdnf_0.28.1.bb | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/recipes-devtools/libdnf/libdnf_0.28.1.bb b/meta/recipes-devtools/libdnf/libdnf_0.28.1.bb index 163a2eec26..cc2ceb8816 100644 --- a/meta/recipes-devtools/libdnf/libdnf_0.28.1.bb +++ b/meta/recipes-devtools/libdnf/libdnf_0.28.1.bb @@ -12,6 +12,7 @@ SRC_URI = "git://github.com/rpm-software-management/libdnf \ " SRCREV = "751f89045b80d58c0d05800f74357cf78cdf7e77" +UPSTREAM_CHECK_GITTAGREGEX = "(?P\d+(\.\d+)+)" S = "${WORKDIR}/git" -- 2.25.1 From ayoub.zaki at embexus.com Tue Mar 10 19:45:58 2020 From: ayoub.zaki at embexus.com (Ayoub Zaki) Date: Tue, 10 Mar 2020 20:45:58 +0100 Subject: [OE-core] [Openembedded-architecture] Does YP provide security support for stable and LTS branches? In-Reply-To: References: <20200304113217.GB7923@localhost> <20200304140109.GC7923@localhost> <20200304172415.GA29456@localhost> <01b3bb37-f65f-8048-1a27-b859b62d7f98@gmail.com> <20200306100422.GA17785@localhost> <877e317932176664bc7b0120439c56d4dda791af.camel@linuxfoundation.org> <20200308214610.GB1425@localhost> <20200309002308.GD1425@localhost> Message-ID: <1c4e1685-7b74-0dea-e08f-4887fca9eb66@embexus.com> Hi, On 10.03.20 17:11, Ross Burton wrote: > On Mon, 9 Mar 2020 at 07:45, Ayoub Zaki wrote: >> Adrian is making a point here, The Yocto Project by claiming that it >> supports security patches for Stable releases is misleading the Users! >> >> I work with different customers and some of them think that by using and >> pulling the latest releases they will get the CVEs automatically fixed! >> >> YP should state that CLEARLY! Of course it will impact the choice of >> going with Yocto or Not ( probably NOT in this case). > What would the alternative to Yocto be, and what is their security > policy? Does e.g. buildroot commit to fixing every known security > issue (which is more than just known CVEs) in their releases? Security patches support is definitely for many companies a knock-out criterion. Probably in this case Debian or a commercial OSes like Qnx would be a choice for who can afford it. Mit freundlichen Gr??en / Kind regards -- Ayoub Zaki Embedded Systems Consultant Vaihinger Stra?e 2/1 D-71634 Ludwigsburg Mobile : +4917662901545 Email : ayoub.zaki at embexus.com Homepage : https://embexus.com VAT No. : DE313902634 -------------- next part -------------- An HTML attachment was scrubbed... URL: From brgl at bgdev.pl Tue Mar 10 21:23:15 2020 From: brgl at bgdev.pl (Bartosz Golaszewski) Date: Tue, 10 Mar 2020 22:23:15 +0100 Subject: [OE-core] Solving a circular dependency issue between the main image and initramfs Message-ID: Hi, I've been struggling for a while now trying to fix a circular dependency issue when the initramfs image needs to access an image file generated by the main (for lack of a better term) image recipe. I've tried to fix our downstream layer only to come to the conclusion that some things must probably be modified upstream to make sense. Unfortunately when trying different solutions I always arrive at some kind of circular dependency with the current task order. My use-case is the following: I'd like to use dm-verity to protect the rootfs from tampering as part of the verified boot flow. At boot-time the rootfs partition is mapped using veritysetup from a trusted initramfs stored in a signed fitImage. This initramfs also contains the root verity hash while the rest of the hash tree is stored on a different partition. The dm-verity meta data is generated from a class[1] I wrote with the aim of upstreaming it to meta-security as an image conversion of ext[234] and btrfs images. For the sake of clarity of the example let's assume we're generating an ext4 image for core-image-full-cmdline and set INITRAMFS_IMAGE to "dm-verity-image-initramfs". The veritysetup conversion becomes part of the core-image-full-cmdline:do_image_ext4 task, while dm-verity-image-initramfs:do_rootfs needs to depend on core-image-full-cmdline:do_image_ext4 as it needs to compute the hashes based on the block device image. It cannot however depend on core-image-full-cmdline:do_image_complete as it depends on many tasks (e.g. kernel and u-boot tasks) that would inevitably lead to a circular dependency. The output files from recipes inheriting image.bbclass are not deployed before do_image_complete nor is anything done in do_install or do_populate_sysroot (these tasks are flagged noexec or deleted), so I cannot access them from dm-verity-image-initramfs:do_rootfs. As a workaround in the downstream layer I've been manually putting the verity meta data into the DEPLOY_DIR_IMAGE from core-image-full-cmdline:do_image_ext4 but this obviously isn't correct as far as the deploy class and sstate are concerned. Now the question is: how do I approach it so that I can eventually make it part of upstream meta-security? Do I implement do_install in image.bbclass so that initramfs can depend on core-image-full-cmdline:do_populate_sysroot and have the artifacts installed locally? But this would mean that the initramfs recipe deploys the main image artifact. Should we deploy the images earlier (before do_image_complete) for the initramfs recipe to fetch from DEPLOY_DIR_IMAGE? Any other ideas? Best regards, Bartosz Golaszewski [1] https://github.com/brgl/meta-security/blob/topic/verity-et-al/classes/dm-verity-img.bbclass From jpewhacker at gmail.com Tue Mar 10 21:29:34 2020 From: jpewhacker at gmail.com (Joshua Watt) Date: Tue, 10 Mar 2020 16:29:34 -0500 Subject: [OE-core] [PATCH] image-live: multiconfig ISO generation In-Reply-To: <20200309225507.29578-1-rp@stacktrust.org> References: <20200309225507.29578-1-rp@stacktrust.org> Message-ID: <435df8e7-f4b2-65b7-0a5f-ba8b228a4c7e@gmail.com> On 3/9/20 5:55 PM, Rich Persaud wrote: > When a target is specified for INITRD_IMAGE_LIVE, a task dependency is > added for do_image_complete. At present, image-live initrd will not > accept multiconfig dependency targets. Can you give an example? That might help with understanding what this is supposed to do. > > If BBMULTICONFIG is non-empty and INITRD_IMAGE_LIVE is a multiconfig > target, use mcdepends instead of depends. The packaging recipe must > also override machine-specific path construction of INITRD_LIVE. > > Required to build an ISO with mixed machine types, a primary use case > for multiconfig. This is a minimal fix to make multiconfig ISOs > possible. > > Signed-off-by: Rich Persaud > --- > meta/classes/image-live.bbclass | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/meta/classes/image-live.bbclass b/meta/classes/image-live.bbclass > index 54058b350d..1afd48005a 100644 > --- a/meta/classes/image-live.bbclass > +++ b/meta/classes/image-live.bbclass > @@ -50,11 +50,14 @@ IMAGE_TYPES_MASKED += "live hddimg iso" > python() { > image_b = d.getVar('IMAGE_BASENAME') > initrd_i = d.getVar('INITRD_IMAGE_LIVE') > + depends_type = ('mcdepends' if (d.getVar('BBMULTICONFIG') > + and initrd_i.count(':') == 3) > + else 'depends') Potentially, this could be simplified: ?depends_type = 'mcdepends' if initrd_i.startswith('mc:') else 'depends' ? > if image_b == initrd_i: > bb.error('INITRD_IMAGE_LIVE %s cannot use image live, hddimg or iso.' % initrd_i) > bb.fatal('Check IMAGE_FSTYPES and INITRAMFS_FSTYPES settings.') > elif initrd_i: > - d.appendVarFlag('do_bootimg', 'depends', ' %s:do_image_complete' % initrd_i) > + d.appendVarFlag('do_bootimg', depends_type, ' %s:do_image_complete' % initrd_i) > } > > HDDDIR = "${S}/hddimg" From ayoub.zaki at embexus.com Tue Mar 10 21:33:05 2020 From: ayoub.zaki at embexus.com (Ayoub Zaki) Date: Tue, 10 Mar 2020 22:33:05 +0100 Subject: [OE-core] Solving a circular dependency issue between the main image and initramfs In-Reply-To: References: Message-ID: Hi, On 10.03.20 22:23, Bartosz Golaszewski wrote: > Hi, > > I've been struggling for a while now trying to fix a circular > dependency issue when the initramfs image needs to access an image > file generated by the main (for lack of a better term) image recipe. > > I've tried to fix our downstream layer only to come to the conclusion > that some things must probably be modified upstream to make sense. > Unfortunately when trying different solutions I always arrive at some > kind of circular dependency with the current task order. > > My use-case is the following: > > I'd like to use dm-verity to protect the rootfs from tampering as part > of the verified boot flow. At boot-time the rootfs partition is mapped > using veritysetup from a trusted initramfs stored in a signed > fitImage. This initramfs also contains the root verity hash while the > rest of the hash tree is stored on a different partition. > > The dm-verity meta data is generated from a class[1] I wrote with the > aim of upstreaming it to meta-security as an image conversion of > ext[234] and btrfs images. > > For the sake of clarity of the example let's assume we're generating > an ext4 image for core-image-full-cmdline and set INITRAMFS_IMAGE to > "dm-verity-image-initramfs". > > The veritysetup conversion becomes part of the > core-image-full-cmdline:do_image_ext4 task, while > dm-verity-image-initramfs:do_rootfs needs to depend on > core-image-full-cmdline:do_image_ext4 as it needs to compute the > hashes based on the block device image. It cannot however depend on > core-image-full-cmdline:do_image_complete as it depends on many tasks > (e.g. kernel and u-boot tasks) that would inevitably lead to a > circular dependency. > > The output files from recipes inheriting image.bbclass are not > deployed before do_image_complete nor is anything done in do_install > or do_populate_sysroot (these tasks are flagged noexec or deleted), so > I cannot access them from dm-verity-image-initramfs:do_rootfs. > > As a workaround in the downstream layer I've been manually putting the > verity meta data into the DEPLOY_DIR_IMAGE from > core-image-full-cmdline:do_image_ext4 but this obviously isn't correct > as far as the deploy class and sstate are concerned. > > Now the question is: how do I approach it so that I can eventually > make it part of upstream meta-security? > > Do I implement do_install in image.bbclass so that initramfs can > depend on core-image-full-cmdline:do_populate_sysroot and have the > artifacts installed locally? But this would mean that the initramfs > recipe deploys the main image artifact. Should we deploy the images > earlier (before do_image_complete) for the initramfs recipe to fetch > from DEPLOY_DIR_IMAGE? Any other ideas? I think that best thing is to implement the dm-verity stuffs as a wic plugin, check this example: https://github.com/intel/intel-iot-refkit/blob/master/meta-refkit-core/scripts/lib/wic/plugins/source/dm-verity.py > [1] https://github.com/brgl/meta-security/blob/topic/verity-et-al/classes/dm-verity-img.bbclass Mit freundlichen Gr??en / Kind regards -- Ayoub Zaki Embedded Systems Consultant Vaihinger Stra?e 2/1 D-71634 Ludwigsburg Mobile : +4917662901545 Email : ayoub.zaki at embexus.com Homepage : https://embexus.com VAT No. : DE313902634 From christopher.w.clark at gmail.com Tue Mar 10 21:55:13 2020 From: christopher.w.clark at gmail.com (christopher.w.clark at gmail.com) Date: Tue, 10 Mar 2020 14:55:13 -0700 Subject: [OE-core] [PATCH] image-prelink: remove assumption of sysconfdir presence Message-ID: <20200310215513.13900-1-christopher.w.clark@gmail.com> From: Christopher Clark If sysconfdir is not present in the image filesystem then the temporary creation of a prelink.conf will fail. Fix this by creating sysconfdir temporarily if needed beforehand and then remove any directories that were created afterwards. fixes: OpenXT OXT-1751 Signed-off-by: Christopher Clark --- meta/classes/image-prelink.bbclass | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/meta/classes/image-prelink.bbclass b/meta/classes/image-prelink.bbclass index 04dd57c940..ebf6e6d7ee 100644 --- a/meta/classes/image-prelink.bbclass +++ b/meta/classes/image-prelink.bbclass @@ -17,6 +17,16 @@ prelink_image () { pre_prelink_size=`du -ks ${IMAGE_ROOTFS} | awk '{size = $1 ; print size }'` echo "Size before prelinking $pre_prelink_size." + # The filesystem may not contain sysconfdir so establish what is present + # to enable cleanup after temporary creation of sysconfdir if needed + presentdir="${IMAGE_ROOTFS}${sysconfdir}" + while [ "${IMAGE_ROOTFS}" != "${presentdir}" ] ; do + [ ! -d "${presentdir}" ] || break + presentdir=`dirname "${presentdir}"` + done + + mkdir -p "${IMAGE_ROOTFS}${sysconfdir}" + # We need a prelink conf on the filesystem, add one if it's missing if [ ! -e ${IMAGE_ROOTFS}${sysconfdir}/prelink.conf ]; then cp ${STAGING_ETCDIR_NATIVE}/prelink.conf \ @@ -59,6 +69,13 @@ prelink_image () { rm $ldsoconf fi + # Remove any directories temporarily created for sysconfdir + cleanupdir="${IMAGE_ROOTFS}${sysconfdir}" + while [ "${presentdir}" != "${cleanupdir}" ] ; do + rmdir "${cleanupdir}" + cleanupdir=`dirname ${cleanupdir}` + done + pre_prelink_size=`du -ks ${IMAGE_ROOTFS} | awk '{size = $1 ; print size }'` echo "Size after prelinking $pre_prelink_size." } -- 2.17.1 From brgl at bgdev.pl Tue Mar 10 22:02:51 2020 From: brgl at bgdev.pl (Bartosz Golaszewski) Date: Tue, 10 Mar 2020 23:02:51 +0100 Subject: [OE-core] Solving a circular dependency issue between the main image and initramfs In-Reply-To: References: Message-ID: wt., 10 mar 2020 o 22:33 Ayoub Zaki napisa?(a): > > > > > Do I implement do_install in image.bbclass so that initramfs can > > depend on core-image-full-cmdline:do_populate_sysroot and have the > > artifacts installed locally? But this would mean that the initramfs > > recipe deploys the main image artifact. Should we deploy the images > > earlier (before do_image_complete) for the initramfs recipe to fetch > > from DEPLOY_DIR_IMAGE? Any other ideas? > > > I think that best thing is to implement the dm-verity stuffs as a wic > plugin, check this example: > > > https://github.com/intel/intel-iot-refkit/blob/master/meta-refkit-core/scripts/lib/wic/plugins/source/dm-verity.py > This doesn't look like a correct solution. For starters: not every platform uses wic. The platform I'm aiming this at uses fastboot and requires separate images for each partition. This plugin also seems to be unnecessarily complicated with additional signature for the verity hash tree. This is not needed as long as the root hash comes from a secure place - which it does in my case: the fitImage containing the initramfs is signed and the key is appended to u-boot's DTB. When do_image_wic starts, u-boot and initramfs assembly are long completed - another reason for not using a wic plugin. Best regards, Bartosz Golaszewski From ayoub.zaki at embexus.com Tue Mar 10 22:54:53 2020 From: ayoub.zaki at embexus.com (Ayoub Zaki) Date: Tue, 10 Mar 2020 23:54:53 +0100 Subject: [OE-core] Solving a circular dependency issue between the main image and initramfs In-Reply-To: References: Message-ID: On 10.03.20 23:02, Bartosz Golaszewski wrote: > wt., 10 mar 2020 o 22:33 Ayoub Zaki napisa?(a): >>> Do I implement do_install in image.bbclass so that initramfs can >>> depend on core-image-full-cmdline:do_populate_sysroot and have the >>> artifacts installed locally? But this would mean that the initramfs >>> recipe deploys the main image artifact. Should we deploy the images >>> earlier (before do_image_complete) for the initramfs recipe to fetch >>> from DEPLOY_DIR_IMAGE? Any other ideas? >> >> I think that best thing is to implement the dm-verity stuffs as a wic >> plugin, check this example: >> >> >> https://github.com/intel/intel-iot-refkit/blob/master/meta-refkit-core/scripts/lib/wic/plugins/source/dm-verity.py >> > This doesn't look like a correct solution. For starters: not every > platform uses wic. The platform I'm aiming this at uses fastboot and > requires separate images for each partition. My proposition was refering to your example : https://github.com/brgl/meta-security/commit/83c8e8fba6988249c9d351aa2ad6e02a71b010df#diff-33f7c29b373860ec45379a5f2dc42a75 your are trying to include the dm-verity conversion output to your wic wks using the following: part / --source rawcopy --ondisk mmcblk --sourceparams="file=${IMGDEPLOYDIR}/${DM_VERITY_IMAGE}-${MACHINE}.${DM_VERITY_TYPE}" In this case you will definitely stuck in a circular dependency unless using a Wic plugin. > > This plugin also seems to be unnecessarily complicated with additional > signature for the verity hash tree. This is not needed as long as the > root hash comes from a secure place - which it does in my case: the > fitImage containing the initramfs is signed and the key is appended to > u-boot's DTB. When do_image_wic starts, u-boot and initramfs assembly > are long completed - another reason for not using a wic plugin. I was referring to the plugin not the implementation which does not work anyway... Mit freundlichen Gr??en / Kind regards -- Ayoub Zaki Embedded Systems Consultant Vaihinger Stra?e 2/1 D-71634 Ludwigsburg Mobile : +4917662901545 Email : ayoub.zaki at embexus.com Homepage : https://embexus.com VAT No. : DE313902634 -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard.purdie at linuxfoundation.org Tue Mar 10 23:16:38 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Tue, 10 Mar 2020 23:16:38 +0000 Subject: [OE-core] [PATCH 1/5] archiver.bbclass: Handle gitsm URLs in the mirror archiver In-Reply-To: <20200309142139.15741-2-pbarker@konsulko.com> References: <20200309142139.15741-1-pbarker@konsulko.com> <20200309142139.15741-2-pbarker@konsulko.com> Message-ID: On Mon, 2020-03-09 at 14:21 +0000, Paul Barker wrote: > To fully archive a `gitsm://` entry in SRC_URI we need to also capture > the submodules recursively. If shallow mirror tarballs are found, they > must be temporarily extracted so that the submodules can be determined. > > Signed-off-by: Paul Barker > --- > meta/classes/archiver.bbclass | 31 ++++++++++++++++++++++++++----- > 1 file changed, 26 insertions(+), 5 deletions(-) > > diff --git a/meta/classes/archiver.bbclass b/meta/classes/archiver.bbclass > index 013195df7d..fef7ad4f62 100644 > --- a/meta/classes/archiver.bbclass > +++ b/meta/classes/archiver.bbclass > @@ -306,7 +306,7 @@ python do_ar_configured() { > } > > python do_ar_mirror() { > - import subprocess > + import shutil, subprocess, tempfile > > src_uri = (d.getVar('SRC_URI') or '').split() > if len(src_uri) == 0: > @@ -337,12 +337,10 @@ python do_ar_mirror() { > > bb.utils.mkdirhier(destdir) > > - fetcher = bb.fetch2.Fetch(src_uri, d) > - > - for url in fetcher.urls: > + def archive_url(fetcher, url): > if is_excluded(url): > bb.note('Skipping excluded url: %s' % (url)) > - continue > + return > > bb.note('Archiving url: %s' % (url)) > ud = fetcher.ud[url] > @@ -376,6 +374,29 @@ python do_ar_mirror() { > bb.note('Copying source mirror') > cmd = 'cp -fpPRH %s %s' % (localpath, destdir) > subprocess.check_call(cmd, shell=True) > + > + if url.startswith('gitsm://'): > + def archive_submodule(ud, url, module, modpath, workdir, d): > + url += ";bareclone=1;nobranch=1" > + newfetch = bb.fetch2.Fetch([url], d, cache=False) > + > + for url in newfetch.urls: > + archive_url(newfetch, url) > + > + # If we're using a shallow mirror tarball it needs to be unpacked > + # temporarily so that we can examine the .gitmodules file > + if ud.shallow and os.path.exists(ud.fullshallow) and ud.method.need_update(ud, d): > + tmpdir = tempfile.mkdtemp(dir=d.getVar("DL_DIR")) > + subprocess.check_call("tar -xzf %s" % ud.fullshallow, cwd=tmpdir, shell=True) > + ud.method.process_submodules(ud, tmpdir, archive_submodule, d) > + shutil.rmtree(tmpdir) > + else: > + ud.method.process_submodules(ud, ud.clonedir, archive_submodule, d) > + > + fetcher = bb.fetch2.Fetch(src_uri, d, cache=False) > + > + for url in fetcher.urls: > + archive_url(fetcher, url) > } I can't help feeling that this is basically a sign the fetcher is broken. What should really happen here is that there should be a method in the fetcher we call into. Instead we're teaching code how to hack around the fetcher. Would it be possible to add some API we could call into here and maintain integrity of the fetcher API? Cheers, Richard From richard.purdie at linuxfoundation.org Tue Mar 10 23:18:33 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Tue, 10 Mar 2020 23:18:33 +0000 Subject: [OE-core] [PATCH 2/5] archiver.bbclass: Make do_deploy_archives a recursive dependency In-Reply-To: <20200309142139.15741-3-pbarker@konsulko.com> References: <20200309142139.15741-1-pbarker@konsulko.com> <20200309142139.15741-3-pbarker@konsulko.com> Message-ID: On Mon, 2020-03-09 at 14:21 +0000, Paul Barker wrote: > To ensure that archives are captured for all dependencies of a typical > bitbake build we add do_deploy_archives to the list of recursive > dependencies of do_build. Without this, archives may be missed for > recipes such as gcc-source which do not create packages or populate a > sysroot. > > do_deploy_archives is also added to the recursive dependencies of > do_populate_sdk so that all sources required for an SDK can be captured. > > Signed-off-by: Paul Barker > --- > meta/classes/archiver.bbclass | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/meta/classes/archiver.bbclass b/meta/classes/archiver.bbclass > index fef7ad4f62..c11d36d708 100644 > --- a/meta/classes/archiver.bbclass > +++ b/meta/classes/archiver.bbclass > @@ -604,7 +604,9 @@ addtask do_ar_configured after do_unpack_and_patch > addtask do_ar_mirror after do_fetch > addtask do_dumpdata > addtask do_ar_recipe > -addtask do_deploy_archives before do_build > +addtask do_deploy_archives > +do_build[recrdeptask] += "do_deploy_archives" > +do_populate_sdk[recrdeptask] += "do_deploy_archives" We implemented the --runall option to bitbake to try and avoid having recrdeptask versions of most tasks. Does that not work here? It should also work for the SDK I think? Cheers, Richard From richard.purdie at linuxfoundation.org Tue Mar 10 23:28:09 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Tue, 10 Mar 2020 23:28:09 +0000 Subject: [OE-core] [PATCH 1/6] gcc: don't ship build host information in the target gcc-plugins package Message-ID: <20200310232814.48572-1-richard.purdie@linuxfoundation.org> From: Ross Burton The build host configuration isn't reproducible as it varies depending on the gcc version of the build host. This information isn't useful on the target anyway so remove it. Signed-off-by: Richard Purdie --- meta/recipes-devtools/gcc/gcc-target.inc | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/meta/recipes-devtools/gcc/gcc-target.inc b/meta/recipes-devtools/gcc/gcc-target.inc index 18d078db0af..204f9475fc5 100644 --- a/meta/recipes-devtools/gcc/gcc-target.inc +++ b/meta/recipes-devtools/gcc/gcc-target.inc @@ -179,6 +179,10 @@ do_install () { # Cleanup manpages.. rm -rf ${D}${mandir}/man7 + # Don't package details about the build host + rm -f ${D}${libdir}/gcc/${TARGET_SYS}/${BINV}/plugin/include/auto-build.h + rm -f ${D}${libdir}/gcc/${TARGET_SYS}/${BINV}/plugin/include/bconfig.h + cd ${D}${bindir} # We care about g++ not c++ -- 2.25.0 From richard.purdie at linuxfoundation.org Tue Mar 10 23:28:10 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Tue, 10 Mar 2020 23:28:10 +0000 Subject: [OE-core] [PATCH 2/6] gcc: strip line numbers from generated code in gcc-plugins on target In-Reply-To: <20200310232814.48572-1-richard.purdie@linuxfoundation.org> References: <20200310232814.48572-1-richard.purdie@linuxfoundation.org> Message-ID: <20200310232814.48572-2-richard.purdie@linuxfoundation.org> From: Ross Burton The line numbers are influenced by the gcc version on the host used to generate the code. Remove these to ensure the shipped source code is the same. Signed-off-by: Richard Purdie --- meta/recipes-devtools/gcc/gcc-9.2.inc | 1 + .../gcc/gcc-9.2/gen-no-line-numbers.patch | 170 ++++++++++++++++++ 2 files changed, 171 insertions(+) create mode 100644 meta/recipes-devtools/gcc/gcc-9.2/gen-no-line-numbers.patch diff --git a/meta/recipes-devtools/gcc/gcc-9.2.inc b/meta/recipes-devtools/gcc/gcc-9.2.inc index 2bae85afe3a..2368f358675 100644 --- a/meta/recipes-devtools/gcc/gcc-9.2.inc +++ b/meta/recipes-devtools/gcc/gcc-9.2.inc @@ -70,6 +70,7 @@ SRC_URI = "\ file://CVE-2019-15847_2.patch \ file://CVE-2019-15847_3.patch \ file://re-PR-target-91102-aarch64-ICE-on-Linux-kernel-with-.patch \ + file://gen-no-line-numbers.patch \ " S = "${TMPDIR}/work-shared/gcc-${PV}-${PR}/gcc-${PV}" SRC_URI[md5sum] = "3818ad8600447f05349098232c2ddc78" diff --git a/meta/recipes-devtools/gcc/gcc-9.2/gen-no-line-numbers.patch b/meta/recipes-devtools/gcc/gcc-9.2/gen-no-line-numbers.patch new file mode 100644 index 00000000000..8e2c3f58095 --- /dev/null +++ b/meta/recipes-devtools/gcc/gcc-9.2/gen-no-line-numbers.patch @@ -0,0 +1,170 @@ +Inserting line numbers into generated code means its not always reproducible wth +differing versions of host gcc. Void the issue by not adding these. + +Upstream-Status: Inappropriate [OE Reproducibility specific] +Signed-off-by: Richard Purdie + +diff --git a/gcc/gengtype.c b/gcc/gengtype.c +index 53317337c..bbb261516 100644 +--- a/gcc/gengtype.c ++++ b/gcc/gengtype.c +@@ -991,7 +991,7 @@ create_field_at (pair_p next, type_p type, const char *name, options_p opt, + /* Create a fake field with the given type and name. NEXT is the next + field in the chain. */ + #define create_field(next,type,name) \ +- create_field_all (next,type,name, 0, this_file, __LINE__) ++ create_field_all (next,type,name, 0, this_file, 0) + + /* Like create_field, but the field is only valid when condition COND + is true. */ +@@ -1024,7 +1024,7 @@ create_optional_field_ (pair_p next, type_p type, const char *name, + } + + #define create_optional_field(next,type,name,cond) \ +- create_optional_field_(next,type,name,cond,__LINE__) ++ create_optional_field_(next,type,name,cond,0) + + /* Reverse a linked list of 'struct pair's in place. */ + pair_p +@@ -5186,7 +5186,7 @@ main (int argc, char **argv) + /* These types are set up with #define or else outside of where + we can see them. We should initialize them before calling + read_input_list. */ +-#define POS_HERE(Call) do { pos.file = this_file; pos.line = __LINE__; \ ++#define POS_HERE(Call) do { pos.file = this_file; pos.line = 0; \ + Call;} while (0) + POS_HERE (do_scalar_typedef ("CUMULATIVE_ARGS", &pos)); + POS_HERE (do_scalar_typedef ("REAL_VALUE_TYPE", &pos)); +diff --git a/gcc/genmodes.c b/gcc/genmodes.c +index f33eefa24..07bef9eeb 100644 +--- a/gcc/genmodes.c ++++ b/gcc/genmodes.c +@@ -429,7 +429,7 @@ complete_all_modes (void) + } + + /* For each mode in class CLASS, construct a corresponding complex mode. */ +-#define COMPLEX_MODES(C) make_complex_modes (MODE_##C, __FILE__, __LINE__) ++#define COMPLEX_MODES(C) make_complex_modes (MODE_##C, __FILE__, 0) + static void + make_complex_modes (enum mode_class cl, + const char *file, unsigned int line) +@@ -487,7 +487,7 @@ make_complex_modes (enum mode_class cl, + /* For all modes in class CL, construct vector modes of width + WIDTH, having as many components as necessary. */ + #define VECTOR_MODES_WITH_PREFIX(PREFIX, C, W) \ +- make_vector_modes (MODE_##C, #PREFIX, W, __FILE__, __LINE__) ++ make_vector_modes (MODE_##C, #PREFIX, W, __FILE__, 0) + #define VECTOR_MODES(C, W) VECTOR_MODES_WITH_PREFIX (V, C, W) + static void ATTRIBUTE_UNUSED + make_vector_modes (enum mode_class cl, const char *prefix, unsigned int width, +@@ -538,7 +538,7 @@ make_vector_modes (enum mode_class cl, const char *prefix, unsigned int width, + /* Create a vector of booleans called NAME with COUNT elements and + BYTESIZE bytes in total. */ + #define VECTOR_BOOL_MODE(NAME, COUNT, BYTESIZE) \ +- make_vector_bool_mode (#NAME, COUNT, BYTESIZE, __FILE__, __LINE__) ++ make_vector_bool_mode (#NAME, COUNT, BYTESIZE, __FILE__, 0) + static void ATTRIBUTE_UNUSED + make_vector_bool_mode (const char *name, unsigned int count, + unsigned int bytesize, const char *file, +@@ -560,7 +560,7 @@ make_vector_bool_mode (const char *name, unsigned int count, + /* Input. */ + + #define _SPECIAL_MODE(C, N) \ +- make_special_mode (MODE_##C, #N, __FILE__, __LINE__) ++ make_special_mode (MODE_##C, #N, __FILE__, 0) + #define RANDOM_MODE(N) _SPECIAL_MODE (RANDOM, N) + #define CC_MODE(N) _SPECIAL_MODE (CC, N) + +@@ -573,7 +573,7 @@ make_special_mode (enum mode_class cl, const char *name, + + #define INT_MODE(N, Y) FRACTIONAL_INT_MODE (N, -1U, Y) + #define FRACTIONAL_INT_MODE(N, B, Y) \ +- make_int_mode (#N, B, Y, __FILE__, __LINE__) ++ make_int_mode (#N, B, Y, __FILE__, 0) + + static void + make_int_mode (const char *name, +@@ -586,16 +586,16 @@ make_int_mode (const char *name, + } + + #define FRACT_MODE(N, Y, F) \ +- make_fixed_point_mode (MODE_FRACT, #N, Y, 0, F, __FILE__, __LINE__) ++ make_fixed_point_mode (MODE_FRACT, #N, Y, 0, F, __FILE__, 0) + + #define UFRACT_MODE(N, Y, F) \ +- make_fixed_point_mode (MODE_UFRACT, #N, Y, 0, F, __FILE__, __LINE__) ++ make_fixed_point_mode (MODE_UFRACT, #N, Y, 0, F, __FILE__, 0) + + #define ACCUM_MODE(N, Y, I, F) \ +- make_fixed_point_mode (MODE_ACCUM, #N, Y, I, F, __FILE__, __LINE__) ++ make_fixed_point_mode (MODE_ACCUM, #N, Y, I, F, __FILE__, 0) + + #define UACCUM_MODE(N, Y, I, F) \ +- make_fixed_point_mode (MODE_UACCUM, #N, Y, I, F, __FILE__, __LINE__) ++ make_fixed_point_mode (MODE_UACCUM, #N, Y, I, F, __FILE__, 0) + + /* Create a fixed-point mode by setting CL, NAME, BYTESIZE, IBIT, FBIT, + FILE, and LINE. */ +@@ -616,7 +616,7 @@ make_fixed_point_mode (enum mode_class cl, + + #define FLOAT_MODE(N, Y, F) FRACTIONAL_FLOAT_MODE (N, -1U, Y, F) + #define FRACTIONAL_FLOAT_MODE(N, B, Y, F) \ +- make_float_mode (#N, B, Y, #F, __FILE__, __LINE__) ++ make_float_mode (#N, B, Y, #F, __FILE__, 0) + + static void + make_float_mode (const char *name, +@@ -633,7 +633,7 @@ make_float_mode (const char *name, + #define DECIMAL_FLOAT_MODE(N, Y, F) \ + FRACTIONAL_DECIMAL_FLOAT_MODE (N, -1U, Y, F) + #define FRACTIONAL_DECIMAL_FLOAT_MODE(N, B, Y, F) \ +- make_decimal_float_mode (#N, B, Y, #F, __FILE__, __LINE__) ++ make_decimal_float_mode (#N, B, Y, #F, __FILE__, 0) + + static void + make_decimal_float_mode (const char *name, +@@ -648,7 +648,7 @@ make_decimal_float_mode (const char *name, + } + + #define RESET_FLOAT_FORMAT(N, F) \ +- reset_float_format (#N, #F, __FILE__, __LINE__) ++ reset_float_format (#N, #F, __FILE__, 0) + static void ATTRIBUTE_UNUSED + reset_float_format (const char *name, const char *format, + const char *file, unsigned int line) +@@ -669,7 +669,7 @@ reset_float_format (const char *name, const char *format, + + /* __intN support. */ + #define INT_N(M,PREC) \ +- make_int_n (#M, PREC, __FILE__, __LINE__) ++ make_int_n (#M, PREC, __FILE__, 0) + static void ATTRIBUTE_UNUSED + make_int_n (const char *m, int bitsize, + const char *file, unsigned int line) +@@ -698,7 +698,7 @@ make_int_n (const char *m, int bitsize, + /* Partial integer modes are specified by relation to a full integer + mode. */ + #define PARTIAL_INT_MODE(M,PREC,NAME) \ +- make_partial_integer_mode (#M, #NAME, PREC, __FILE__, __LINE__) ++ make_partial_integer_mode (#M, #NAME, PREC, __FILE__, 0) + static void ATTRIBUTE_UNUSED + make_partial_integer_mode (const char *base, const char *name, + unsigned int precision, +@@ -725,7 +725,7 @@ make_partial_integer_mode (const char *base, const char *name, + /* A single vector mode can be specified by naming its component + mode and the number of components. */ + #define VECTOR_MODE(C, M, N) \ +- make_vector_mode (MODE_##C, #M, N, __FILE__, __LINE__); ++ make_vector_mode (MODE_##C, #M, N, __FILE__, 0); + static void ATTRIBUTE_UNUSED + make_vector_mode (enum mode_class bclass, + const char *base, +@@ -768,7 +768,7 @@ make_vector_mode (enum mode_class bclass, + + /* Adjustability. */ + #define _ADD_ADJUST(A, M, X, C1, C2) \ +- new_adjust (#M, &adj_##A, #A, #X, MODE_##C1, MODE_##C2, __FILE__, __LINE__) ++ new_adjust (#M, &adj_##A, #A, #X, MODE_##C1, MODE_##C2, __FILE__, 0) + + #define ADJUST_NUNITS(M, X) _ADD_ADJUST (nunits, M, X, RANDOM, RANDOM) + #define ADJUST_BYTESIZE(M, X) _ADD_ADJUST (bytesize, M, X, RANDOM, RANDOM) -- 2.25.0 From richard.purdie at linuxfoundation.org Tue Mar 10 23:28:11 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Tue, 10 Mar 2020 23:28:11 +0000 Subject: [OE-core] [PATCH 3/6] oeqa/testsdk: Use original PATH In-Reply-To: <20200310232814.48572-1-richard.purdie@linuxfoundation.org> References: <20200310232814.48572-1-richard.purdie@linuxfoundation.org> Message-ID: <20200310232814.48572-3-richard.purdie@linuxfoundation.org> We want to test the SDK with PATH from the original host, not with our own tools injected via HOSTTOOLS. It even uses some tools which aren't in HOSTTOOLS. This is necessary after changing the SDK to not reset PATH to the system default which is bad for other reasons and brings the testing into sync with that change. Signed-off-by: Richard Purdie --- meta/lib/oeqa/sdkext/testsdk.py | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/meta/lib/oeqa/sdkext/testsdk.py b/meta/lib/oeqa/sdkext/testsdk.py index 785b5dda53a..c5c46df6cda 100644 --- a/meta/lib/oeqa/sdkext/testsdk.py +++ b/meta/lib/oeqa/sdkext/testsdk.py @@ -25,11 +25,8 @@ class TestSDKExt(TestSDKBase): subprocesstweak.errors_have_output() - # extensible sdk can be contaminated if native programs are - # in PATH, i.e. use perl-native instead of eSDK one. - paths_to_avoid = [d.getVar('STAGING_DIR'), - d.getVar('BASE_WORKDIR')] - os.environ['PATH'] = avoid_paths_in_environ(paths_to_avoid) + # We need the original PATH for testing the eSDK, not with our manipulations + os.environ['PATH'] = d.getVar("BB_ORIGENV", False).getVar("PATH") tcname = d.expand("${SDK_DEPLOY}/${TOOLCHAINEXT_OUTPUTNAME}.sh") if not os.path.exists(tcname): -- 2.25.0 From richard.purdie at linuxfoundation.org Tue Mar 10 23:28:12 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Tue, 10 Mar 2020 23:28:12 +0000 Subject: [OE-core] [PATCH 4/6] files/toolchain-shar-extract.sh: Rework PATH cleaning In-Reply-To: <20200310232814.48572-1-richard.purdie@linuxfoundation.org> References: <20200310232814.48572-1-richard.purdie@linuxfoundation.org> Message-ID: <20200310232814.48572-4-richard.purdie@linuxfoundation.org> Trying to create a clean PATH breaks cases where we install a buildtools tarball on hosts to provide newer versions of gcc. Rework the fix for #8698 to clean up directories in PATH which don't exist isntead. Do it with python as the shell version was too fraught with corner cases. Signed-off-by: Richard Purdie --- meta/files/toolchain-shar-extract.sh | 11 +++-------- 1 file changed, 3 insertions(+), 8 deletions(-) diff --git a/meta/files/toolchain-shar-extract.sh b/meta/files/toolchain-shar-extract.sh index 4c4b4deb4cf..2e0fe94963f 100644 --- a/meta/files/toolchain-shar-extract.sh +++ b/meta/files/toolchain-shar-extract.sh @@ -1,13 +1,8 @@ #!/bin/sh -[ -z "$ENVCLEANED" ] && exec /usr/bin/env -i ENVCLEANED=1 HOME="$HOME" \ - LC_ALL=en_US.UTF-8 \ - TERM=$TERM \ - ICECC_PATH="$ICECC_PATH" \ - http_proxy="$http_proxy" https_proxy="$https_proxy" ftp_proxy="$ftp_proxy" \ - no_proxy="$no_proxy" all_proxy="$all_proxy" GIT_PROXY_COMMAND="$GIT_PROXY_COMMAND" "$0" "$@" -[ -f /etc/environment ] && . /etc/environment -export PATH=`echo "$PATH" | sed -e 's/:\.//' -e 's/::/:/'` +export LC_ALL=en_US.UTF-8 +# Remove invalid PATH elements first (maybe from a previously setup toolchain now deleted +PATH=`python3 -c 'import os; print(":".join(e for e in os.environ["PATH"].split(":") if os.path.exists(e)))'` tweakpath () { case ":${PATH}:" in -- 2.25.0 From richard.purdie at linuxfoundation.org Tue Mar 10 23:28:13 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Tue, 10 Mar 2020 23:28:13 +0000 Subject: [OE-core] [PATCH 5/6] glibc: Update nativesdk locale relocation patch In-Reply-To: <20200310232814.48572-1-richard.purdie@linuxfoundation.org> References: <20200310232814.48572-1-richard.purdie@linuxfoundation.org> Message-ID: <20200310232814.48572-5-richard.purdie@linuxfoundation.org> The locale binary reported incorrect locale lists in relocated toolchains as some path references were not relocated by this patch. Fix this missing relocations so the locale binary correctly reports the locales. Signed-off-by: Richard Purdie --- ...Make-relocatable-install-for-locales.patch | 62 ++++++++++++++----- 1 file changed, 47 insertions(+), 15 deletions(-) diff --git a/meta/recipes-core/glibc/glibc/0007-nativesdk-glibc-Make-relocatable-install-for-locales.patch b/meta/recipes-core/glibc/glibc/0007-nativesdk-glibc-Make-relocatable-install-for-locales.patch index d9985c2fdc8..27cd17cdcdf 100644 --- a/meta/recipes-core/glibc/glibc/0007-nativesdk-glibc-Make-relocatable-install-for-locales.patch +++ b/meta/recipes-core/glibc/glibc/0007-nativesdk-glibc-Make-relocatable-install-for-locales.patch @@ -17,11 +17,11 @@ Signed-off-by: Khem Raj locale/localeinfo.h | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) -diff --git a/locale/findlocale.c b/locale/findlocale.c -index 9cd3b71a6d..84272310e0 100644 ---- a/locale/findlocale.c -+++ b/locale/findlocale.c -@@ -56,7 +56,7 @@ struct __locale_data *const _nl_C[] attribute_hidden = +Index: git/locale/findlocale.c +=================================================================== +--- git.orig/locale/findlocale.c ++++ git/locale/findlocale.c +@@ -56,7 +56,7 @@ struct __locale_data *const _nl_C[] attr which are somehow addressed. */ struct loaded_l10nfile *_nl_locale_file_list[__LC_LAST]; @@ -30,7 +30,7 @@ index 9cd3b71a6d..84272310e0 100644 /* Checks if the name is actually present, that is, not NULL and not empty. */ -@@ -166,7 +166,7 @@ _nl_find_locale (const char *locale_path, size_t locale_path_len, +@@ -166,7 +166,7 @@ _nl_find_locale (const char *locale_path /* Nothing in the archive. Set the default path to search below. */ locale_path = _nl_default_locale_path; @@ -39,10 +39,10 @@ index 9cd3b71a6d..84272310e0 100644 } else /* We really have to load some data. First see whether the name is -diff --git a/locale/loadarchive.c b/locale/loadarchive.c -index ba0fe45648..9737fd4cda 100644 ---- a/locale/loadarchive.c -+++ b/locale/loadarchive.c +Index: git/locale/loadarchive.c +=================================================================== +--- git.orig/locale/loadarchive.c ++++ git/locale/loadarchive.c @@ -42,7 +42,7 @@ @@ -52,11 +52,11 @@ index ba0fe45648..9737fd4cda 100644 /* Size of initial mapping window, optimal if large enough to cover the header plus the initial locale. */ -diff --git a/locale/localeinfo.h b/locale/localeinfo.h -index 1bfe22aa7f..fdc283c69a 100644 ---- a/locale/localeinfo.h -+++ b/locale/localeinfo.h -@@ -331,7 +331,7 @@ _nl_lookup_word (locale_t l, int category, int item) +Index: git/locale/localeinfo.h +=================================================================== +--- git.orig/locale/localeinfo.h ++++ git/locale/localeinfo.h +@@ -331,7 +331,7 @@ _nl_lookup_word (locale_t l, int categor } /* Default search path if no LOCPATH environment variable. */ @@ -65,3 +65,35 @@ index 1bfe22aa7f..fdc283c69a 100644 /* Load the locale data for CATEGORY from the file specified by *NAME. If *NAME is "", use environment variables as specified by POSIX, and +Index: git/locale/programs/locale.c +=================================================================== +--- git.orig/locale/programs/locale.c ++++ git/locale/programs/locale.c +@@ -632,6 +632,7 @@ nameentcmp (const void *a, const void *b + ((const struct nameent *) b)->name); + } + ++static char _write_archive_locales_path[4096] attribute_hidden __attribute__ ((section (".gccrelocprefix"))) = ARCHIVE_NAME; + + static int + write_archive_locales (void **all_datap, char *linebuf) +@@ -645,7 +646,7 @@ write_archive_locales (void **all_datap, + int fd, ret = 0; + uint32_t cnt; + +- fd = open64 (ARCHIVE_NAME, O_RDONLY); ++ fd = open64 (_write_archive_locales_path, O_RDONLY); + if (fd < 0) + return 0; + +@@ -700,8 +701,8 @@ write_archive_locales (void **all_datap, + if (cnt) + putchar_unlocked ('\n'); + +- printf ("locale: %-15.15s archive: " ARCHIVE_NAME "\n%s\n", +- names[cnt].name, linebuf); ++ printf ("locale: %-15.15s archive: %s\n%s\n", ++ names[cnt].name, _write_archive_locales_path, linebuf); + + locrec = (struct locrecent *) (addr + names[cnt].locrec_offset); + -- 2.25.0 From richard.purdie at linuxfoundation.org Tue Mar 10 23:28:14 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Tue, 10 Mar 2020 23:28:14 +0000 Subject: [OE-core] [PATCH 6/6] buildtools-extended-tarball: Add locale command In-Reply-To: <20200310232814.48572-1-richard.purdie@linuxfoundation.org> References: <20200310232814.48572-1-richard.purdie@linuxfoundation.org> Message-ID: <20200310232814.48572-6-richard.purdie@linuxfoundation.org> The eSDK installation code checks installed locales with the locale command which is from glibc-utils. Add this so that we find the correct locales from the buildtools. Signed-off-by: Richard Purdie --- meta/recipes-core/meta/buildtools-extended-tarball.bb | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/recipes-core/meta/buildtools-extended-tarball.bb b/meta/recipes-core/meta/buildtools-extended-tarball.bb index 4a79b09fda9..dd780c5d57e 100644 --- a/meta/recipes-core/meta/buildtools-extended-tarball.bb +++ b/meta/recipes-core/meta/buildtools-extended-tarball.bb @@ -25,6 +25,7 @@ TOOLCHAIN_HOST_TASK += "\ nativesdk-libstdc++-dev \ nativesdk-libtool \ nativesdk-pkgconfig \ + nativesdk-glibc-utils \ nativesdk-libxcrypt-dev \ " -- 2.25.0 From rp at stacktrust.org Wed Mar 11 00:24:35 2020 From: rp at stacktrust.org (Rich Persaud) Date: Tue, 10 Mar 2020 20:24:35 -0400 Subject: [OE-core] [PATCH] image-live: multiconfig ISO generation In-Reply-To: <435df8e7-f4b2-65b7-0a5f-ba8b228a4c7e@gmail.com> References: <435df8e7-f4b2-65b7-0a5f-ba8b228a4c7e@gmail.com> Message-ID: On Mar 10, 2020, at 17:29, Joshua Watt wrote: > ? >> On 3/9/20 5:55 PM, Rich Persaud wrote: >> When a target is specified for INITRD_IMAGE_LIVE, a task dependency is >> added for do_image_complete. At present, image-live initrd will not >> accept multiconfig dependency targets. > > Can you give an example? That might help with understanding what this is supposed to do. Any initrd with a machine type that is different from the "machine type" of the ISO image, which may itself be a composite image of multiple machine types, e.g. virtual machines with logical property variances rather than physical architecture changes. The traditional notion of ISO "machine type" is already suspect in a multiconfig scenario, and need not imply that the initrd has an identical machine type. For the purpose of this patch, let's assume an ISO could be built with different initramfs versions for testing, each with a different machine type. More generally, image-live translates the presence of an initrd to a recipe dependency which assumes a singleconfig target. This capability can be extended to multiconfig targets, if they are to be first-class targets throughout bitbake. If not, we can document a whitelist of bitbake features where multiconfig targets are permitted. >> If BBMULTICONFIG is non-empty and INITRD_IMAGE_LIVE is a multiconfig >> target, use mcdepends instead of depends. The packaging recipe must >> also override machine-specific path construction of INITRD_LIVE. >> >> Required to build an ISO with mixed machine types, a primary use case >> for multiconfig. This is a minimal fix to make multiconfig ISOs >> possible. >> >> Signed-off-by: Rich Persaud >> --- >> meta/classes/image-live.bbclass | 5 ++++- >> 1 file changed, 4 insertions(+), 1 deletion(-) >> >> diff --git a/meta/classes/image-live.bbclass b/meta/classes/image-live.bbclass >> index 54058b350d..1afd48005a 100644 >> --- a/meta/classes/image-live.bbclass >> +++ b/meta/classes/image-live.bbclass >> @@ -50,11 +50,14 @@ IMAGE_TYPES_MASKED += "live hddimg iso" >> python() { >> image_b = d.getVar('IMAGE_BASENAME') >> initrd_i = d.getVar('INITRD_IMAGE_LIVE') >> + depends_type = ('mcdepends' if (d.getVar('BBMULTICONFIG') >> + and initrd_i.count(':') == 3) >> + else 'depends') > > Potentially, this could be simplified: > > depends_type = 'mcdepends' if initrd_i.startswith('mc:') else 'depends' > > ? Yes, if this is the agreed-upon standard definition of a multiconfig target, which should perhaps be a reusable validation function? If a singleconfig target is specified for mcdepends, bitbake prints an error message which cites three colons in the target definition, as the minimum requirement for a multiconfig target. I haven't traced the code which generates that error, or tested an mcdepends target which has three colons but does not begin with 'mc'. There must be several places which need to perform this validation, it would be good to share a common function/snippet. > >> if image_b == initrd_i: >> bb.error('INITRD_IMAGE_LIVE %s cannot use image live, hddimg or iso.' % initrd_i) >> bb.fatal('Check IMAGE_FSTYPES and INITRAMFS_FSTYPES settings.') >> elif initrd_i: >> - d.appendVarFlag('do_bootimg', 'depends', ' %s:do_image_complete' % initrd_i) >> + d.appendVarFlag('do_bootimg', depends_type, ' %s:do_image_complete' % initrd_i) >> } >> HDDDIR = "${S}/hddimg" > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core at lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core From changqing.li at windriver.com Wed Mar 11 02:13:23 2020 From: changqing.li at windriver.com (changqing.li at windriver.com) Date: Wed, 11 Mar 2020 10:13:23 +0800 Subject: [OE-core] [PATCH 1/2] parselogs.py: update network interface related messages Message-ID: <1583892804-385900-1-git-send-email-changqing.li@windriver.com> From: Changqing Li along with systemd upgrade, error message related change network interface have changed, update it. Signed-off-by: Changqing Li --- meta/lib/oeqa/runtime/cases/parselogs.py | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/meta/lib/oeqa/runtime/cases/parselogs.py b/meta/lib/oeqa/runtime/cases/parselogs.py index 6444fe8..6e22520 100644 --- a/meta/lib/oeqa/runtime/cases/parselogs.py +++ b/meta/lib/oeqa/runtime/cases/parselogs.py @@ -55,7 +55,8 @@ common_errors = [ "Failed to read /var/lib/nfs/statd/state: Success", "error retry time-out =", "logind: cannot setup systemd-logind helper (-61), using legacy fallback", - "Error changing net interface name 'eth0' to ", + "Failed to rename network interface", + "Failed to process device, ignoring: Device or resource busy", "Cannot find a map file", "[rdrand]: Initialization Failed" ] -- 2.7.4 From changqing.li at windriver.com Wed Mar 11 02:13:24 2020 From: changqing.li at windriver.com (changqing.li at windriver.com) Date: Wed, 11 Mar 2020 10:13:24 +0800 Subject: [OE-core] [PATCH 2/2] parselogs.py: whitelist more xserver related error In-Reply-To: <1583892804-385900-1-git-send-email-changqing.li@windriver.com> References: <1583892804-385900-1-git-send-email-changqing.li@windriver.com> Message-ID: <1583892804-385900-2-git-send-email-changqing.li@windriver.com> From: Changqing Li With default config, these errors always exist for core-image-sato, and xserver-nodm.server start successfully, these errors are not critially. If set default syslog to rsyslog, all these errors will go into daemon.log and user.log, then test_parselog will fail, so whitelist these errors Signed-off-by: Changqing Li --- meta/lib/oeqa/runtime/cases/parselogs.py | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/meta/lib/oeqa/runtime/cases/parselogs.py b/meta/lib/oeqa/runtime/cases/parselogs.py index 6e22520..2a5e5c6 100644 --- a/meta/lib/oeqa/runtime/cases/parselogs.py +++ b/meta/lib/oeqa/runtime/cases/parselogs.py @@ -58,7 +58,15 @@ common_errors = [ "Failed to rename network interface", "Failed to process device, ignoring: Device or resource busy", "Cannot find a map file", - "[rdrand]: Initialization Failed" + "[rdrand]: Initialization Failed", + "libGL error:", + "[pulseaudio] authkey.c: Failed to open cookie file", + "[pulseaudio] authkey.c: Failed to load authentication key", + "FBIOPUT_VSCREENINFO failed, double buffering disabled", + "xserver-nodm.service: Failed with result 'exit-code'", + "xinit: server error", + "matchbox-wm: X error warning", + "X11 cannot support keycodes above 255" ] video_related = [ @@ -86,6 +94,8 @@ qemux86_common = [ 'tsc: HPET/PMTIMER calibration failed', "modeset(0): Failed to initialize the DRI2 extension", "glamor initialization failed", + "xf86OpenConsole: Switching VT failed", + "Fatal server error:", ] + common_errors ignore_errors = { -- 2.7.4 From akuster808 at gmail.com Wed Mar 11 02:26:01 2020 From: akuster808 at gmail.com (Armin Kuster) Date: Tue, 10 Mar 2020 19:26:01 -0700 Subject: [OE-core] [zeus 00/16] Patch review Message-ID: Please review this next set and have comments back by Friday The following changes since commit c78140941f8a98e013932023a63501ba3b7e975a: linux-yocto/5.2: update to v5.2.32 (2020-02-28 11:54:08 +0800) are available in the Git repository at: git://git.openembedded.org/openembedded-core-contrib stable/zeus-nut2 http://cgit.openembedded.org/openembedded-core-contrib/log/?h=stable/zeus-nut2 Armin Kuster (2): cve-check: fail gracefully when file not found wic/engine: lets display an error not a traceback Bruce Ashfield (1): linux-yocto/5.2: backport perf build fix for latest binutils Chee Yang Lee (2): cve-check: show whitelisted status cve-check: fix ValueError Khem Raj (1): valgrind: Fix build with -fno-common Lee Chee Yang (1): virglrenderer: fix multiple CVEs Mark Hatle (1): gcc-cross-canadian: A missing space in an append caused an invalid option Michael Halstead (1): yocto-uninative.inc: version 2.8 updates glibc to 2.31 Nathan Rossi (2): gcc-cross.inc: Prevent native sysroot from leaking into configargs.h gcc-target.inc: Prevent sysroot from leaking into configargs.h Ovidiu Panait (1): dhcp: Fix REQUIRE(ctx->running) assertion triggered on SIGTERM/SIGINT Rahul Chauhan (1): ruby: fix CVE-2019-16254 Richard Purdie (2): dummy-sdk-package: Add DUMMYPROVIDES_PACKAGES maintainers: Add entry for buildtools-extended-tarball Zhixiong Chi (1): glibc: CVE-2020-10029 meta/classes/cve-check.bbclass | 25 ++- meta/conf/distro/include/maintainers.inc | 1 + meta/conf/distro/include/yocto-uninative.inc | 10 +- ...s-running-prior-to-calling-isc_app_c.patch | 165 ++++++++++++++++++ ...ed-shutdown-log-statment-to-dhcrelay.patch | 29 +++ .../dhcp/0003-Addressed-review-comment.patch | 31 ++++ meta/recipes-connectivity/dhcp/dhcp_4.4.1.bb | 3 + .../glibc/glibc/CVE-2020-10029.patch | 128 ++++++++++++++ meta/recipes-core/glibc/glibc_2.30.bb | 1 + meta/recipes-core/meta/dummy-sdk-package.inc | 3 + .../meta/nativesdk-buildtools-perl-dummy.bb | 5 +- .../meta/nativesdk-sdk-provides-dummy.bb | 5 +- .../meta/target-sdk-provides-dummy.bb | 1 - .../gcc/gcc-cross-canadian.inc | 4 +- meta/recipes-devtools/gcc/gcc-cross.inc | 7 + meta/recipes-devtools/gcc/gcc-runtime.inc | 4 - meta/recipes-devtools/gcc/gcc-target.inc | 8 + .../ruby/ruby/fix-CVE-2019-16254.patch | 106 +++++++++++ meta/recipes-devtools/ruby/ruby_2.5.5.bb | 1 + .../valgrind/valgrind/s390x_vec_op_t.patch | 19 ++ .../valgrind/valgrind_3.15.0.bb | 1 + .../virglrenderer/CVE-2019-18390.patch | 66 +++++++ .../virglrenderer/CVE-2019-18391.patch | 51 ++++++ .../virglrenderer/CVE-2020-8002.patch | 39 +++++ .../virglrenderer/virglrenderer_0.8.0.bb | 3 + .../linux/linux-yocto-rt_5.2.bb | 2 +- .../linux/linux-yocto-tiny_5.2.bb | 4 +- meta/recipes-kernel/linux/linux-yocto_5.2.bb | 18 +- scripts/lib/wic/engine.py | 5 +- 29 files changed, 710 insertions(+), 35 deletions(-) create mode 100644 meta/recipes-connectivity/dhcp/dhcp/0001-Ensure-context-is-running-prior-to-calling-isc_app_c.patch create mode 100644 meta/recipes-connectivity/dhcp/dhcp/0002-Added-shutdown-log-statment-to-dhcrelay.patch create mode 100644 meta/recipes-connectivity/dhcp/dhcp/0003-Addressed-review-comment.patch create mode 100644 meta/recipes-core/glibc/glibc/CVE-2020-10029.patch create mode 100644 meta/recipes-devtools/ruby/ruby/fix-CVE-2019-16254.patch create mode 100644 meta/recipes-devtools/valgrind/valgrind/s390x_vec_op_t.patch create mode 100644 meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2019-18390.patch create mode 100644 meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2019-18391.patch create mode 100644 meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2020-8002.patch -- 2.17.1 From akuster808 at gmail.com Wed Mar 11 02:26:02 2020 From: akuster808 at gmail.com (Armin Kuster) Date: Tue, 10 Mar 2020 19:26:02 -0700 Subject: [OE-core] [zeus 01/16] yocto-uninative.inc: version 2.8 updates glibc to 2.31 In-Reply-To: References: Message-ID: <2da4ee30335d0b127b79a6eedad68c8559606c57.1583893499.git.akuster808@gmail.com> From: Michael Halstead Allow sstate use in Tumbleweed and other distros as they update glibc. Signed-off-by: Richard Purdie (cherry picked from commit ccb374c279b260b1fd3460f6bfd1567240816055) Signed-off-by: Armin Kuster --- meta/conf/distro/include/yocto-uninative.inc | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/meta/conf/distro/include/yocto-uninative.inc b/meta/conf/distro/include/yocto-uninative.inc index ad75d3e2a3..889695eae3 100644 --- a/meta/conf/distro/include/yocto-uninative.inc +++ b/meta/conf/distro/include/yocto-uninative.inc @@ -6,9 +6,9 @@ # to the distro running on the build machine. # -UNINATIVE_MAXGLIBCVERSION = "2.30" +UNINATIVE_MAXGLIBCVERSION = "2.31" -UNINATIVE_URL ?= "http://downloads.yoctoproject.org/releases/uninative/2.7/" -UNINATIVE_CHECKSUM[aarch64] ?= "e76a45886ee8a0b3904b761c17ac8ff91edf9811ee455f1832d10763ba794dfc" -UNINATIVE_CHECKSUM[i686] ?= "810d027dfb1c7675226afbcec07808770516c969ee7378f6d8240281083f8924" -UNINATIVE_CHECKSUM[x86_64] ?= "9498d8bba047499999a7310ac2576d0796461184965351a56f6d32c888a1f216" +UNINATIVE_URL ?= "http://downloads.yoctoproject.org/releases/uninative/2.8/" +UNINATIVE_CHECKSUM[aarch64] ?= "989187344bf9539b464fb7ed9c223e51f4bdb4c7a677d2c314e6fed393176efe" +UNINATIVE_CHECKSUM[i686] ?= "cc3e45bc8594488b407363e3fa9af5a099279dab2703c64342098719bd674990" +UNINATIVE_CHECKSUM[x86_64] ?= "a09922172c3a439105e0ae6b943daad2d83505b17da0aba97961ff433b8c21ab" -- 2.17.1 From akuster808 at gmail.com Wed Mar 11 02:26:03 2020 From: akuster808 at gmail.com (Armin Kuster) Date: Tue, 10 Mar 2020 19:26:03 -0700 Subject: [OE-core] [zeus 02/16] linux-yocto/5.2: backport perf build fix for latest binutils In-Reply-To: References: Message-ID: From: Bruce Ashfield [ Author: Changbin Du Date: Tue Jan 28 23:29:38 2020 +0800 perf: Make perf able to build with latest libbfd libbfd has changed the bfd_section_* macros to inline functions bfd_section_ since 2019-09-18. See below two commits: o http://www.sourceware.org/ml/gdb-cvs/2019-09/msg00064.html o https://www.sourceware.org/ml/gdb-cvs/2019-09/msg00072.html This fix make perf able to build with both old and new libbfd. Signed-off-by: Changbin Du Acked-by: Jiri Olsa Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/20200128152938.31413-1-changbin.du at gmail.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Bruce Ashfield ] Signed-off-by: Bruce Ashfield Signed-off-by: Richard Purdie (cherry picked from commit 14a338dbbe2da5a022a916081b3aab9c7472c3ce) Signed-off-by: Armin Kuster --- .../recipes-kernel/linux/linux-yocto-rt_5.2.bb | 2 +- .../linux/linux-yocto-tiny_5.2.bb | 4 ++-- meta/recipes-kernel/linux/linux-yocto_5.2.bb | 18 +++++++++--------- 3 files changed, 12 insertions(+), 12 deletions(-) diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.2.bb b/meta/recipes-kernel/linux/linux-yocto-rt_5.2.bb index 441545f55e..a23a5e6f93 100644 --- a/meta/recipes-kernel/linux/linux-yocto-rt_5.2.bb +++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.2.bb @@ -11,7 +11,7 @@ python () { raise bb.parse.SkipRecipe("Set PREFERRED_PROVIDER_virtual/kernel to linux-yocto-rt to enable it") } -SRCREV_machine ?= "b18bde6f0d8d1a5710cec9792372c03543cf0be9" +SRCREV_machine ?= "78e147f949b5b18524aa7bd72f1cc8f7ae8039f8" SRCREV_meta ?= "bb2776d6beaae64b1a0fc902b64376f082085498" SRC_URI = "git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \ diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_5.2.bb b/meta/recipes-kernel/linux/linux-yocto-tiny_5.2.bb index 6d49e00e21..ac9904f415 100644 --- a/meta/recipes-kernel/linux/linux-yocto-tiny_5.2.bb +++ b/meta/recipes-kernel/linux/linux-yocto-tiny_5.2.bb @@ -15,8 +15,8 @@ DEPENDS += "openssl-native util-linux-native" KMETA = "kernel-meta" KCONF_BSP_AUDIT_LEVEL = "2" -SRCREV_machine_qemuarm ?= "ed1c3b7ad8221ba4e20ce7e4e4f6a73afd5015d4" -SRCREV_machine ?= "c926964d00caf714f42878535af8c7374452072d" +SRCREV_machine_qemuarm ?= "e0a3a01b24070b15121e938ea19755091bf0d662" +SRCREV_machine ?= "73b12de4c879e4569bef3b2d0ee9c783a9788b27" SRCREV_meta ?= "bb2776d6beaae64b1a0fc902b64376f082085498" PV = "${LINUX_VERSION}+git${SRCPV}" diff --git a/meta/recipes-kernel/linux/linux-yocto_5.2.bb b/meta/recipes-kernel/linux/linux-yocto_5.2.bb index 44516dcacb..eab142e1c6 100644 --- a/meta/recipes-kernel/linux/linux-yocto_5.2.bb +++ b/meta/recipes-kernel/linux/linux-yocto_5.2.bb @@ -12,15 +12,15 @@ KBRANCH_qemux86 ?= "v5.2/standard/base" KBRANCH_qemux86-64 ?= "v5.2/standard/base" KBRANCH_qemumips64 ?= "v5.2/standard/mti-malta64" -SRCREV_machine_qemuarm ?= "1ed2236e622e5b79d910fc1db37ec6eec5a94fdc" -SRCREV_machine_qemuarm64 ?= "c926964d00caf714f42878535af8c7374452072d" -SRCREV_machine_qemumips ?= "e669e4307d07072458904ac0fda56f7192e2880d" -SRCREV_machine_qemuppc ?= "c926964d00caf714f42878535af8c7374452072d" -SRCREV_machine_qemuriscv64 ?= "c926964d00caf714f42878535af8c7374452072d" -SRCREV_machine_qemux86 ?= "c926964d00caf714f42878535af8c7374452072d" -SRCREV_machine_qemux86-64 ?= "c926964d00caf714f42878535af8c7374452072d" -SRCREV_machine_qemumips64 ?= "217cada95bbe7eb4c3a6d40ee141ea4cea3bc1b6" -SRCREV_machine ?= "c926964d00caf714f42878535af8c7374452072d" +SRCREV_machine_qemuarm ?= "fdb7cd1bb5e4238e5b3d120ce9db31119ec2b5ee" +SRCREV_machine_qemuarm64 ?= "73b12de4c879e4569bef3b2d0ee9c783a9788b27" +SRCREV_machine_qemumips ?= "eb7faee13cfce200e9add4ba1852a3fe5d8b92e6" +SRCREV_machine_qemuppc ?= "73b12de4c879e4569bef3b2d0ee9c783a9788b27" +SRCREV_machine_qemuriscv64 ?= "73b12de4c879e4569bef3b2d0ee9c783a9788b27" +SRCREV_machine_qemux86 ?= "73b12de4c879e4569bef3b2d0ee9c783a9788b27" +SRCREV_machine_qemux86-64 ?= "73b12de4c879e4569bef3b2d0ee9c783a9788b27" +SRCREV_machine_qemumips64 ?= "8e3bfeb7e9b5aa92c5bea941d361ff5b081a2aaa" +SRCREV_machine ?= "73b12de4c879e4569bef3b2d0ee9c783a9788b27" SRCREV_meta ?= "bb2776d6beaae64b1a0fc902b64376f082085498" # remap qemuarm to qemuarma15 for the 5.2 kernel -- 2.17.1 From akuster808 at gmail.com Wed Mar 11 02:26:04 2020 From: akuster808 at gmail.com (Armin Kuster) Date: Tue, 10 Mar 2020 19:26:04 -0700 Subject: [OE-core] [zeus 03/16] cve-check: fail gracefully when file not found In-Reply-To: References: Message-ID: With out these changes, a traceback displayed when a file is listed in the SRC_URI but the file does not exist. raise FileNotFoundError and print the patch then mark the task as failed. Signed-off-by: Armin Kuster Signed-off-by: Ross Burton (cherry picked from commit d4926c11a4ab9148bdb640a9367c9e1891491a5b) Signed-off-by: Armin Kuster --- meta/classes/cve-check.bbclass | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass index 01b3637469..74124364b2 100644 --- a/meta/classes/cve-check.bbclass +++ b/meta/classes/cve-check.bbclass @@ -52,7 +52,10 @@ python do_cve_check () { """ if os.path.exists(d.getVar("CVE_CHECK_DB_FILE")): - patched_cves = get_patches_cves(d) + try: + patched_cves = get_patches_cves(d) + except FileNotFoundError: + bb.fatal("Failure in searching patches") patched, unpatched = check_cves(d, patched_cves) if patched or unpatched: cve_data = get_cve_info(d, patched + unpatched) @@ -129,6 +132,10 @@ def get_patches_cves(d): for url in src_patches(d): patch_file = bb.fetch.decodeurl(url)[2] + if not os.path.isfile(patch_file): + bb.error("File Not found: %s" % patch_file) + raise FileNotFoundError + # Check patch file name for CVE ID fname_match = cve_file_name_match.search(patch_file) if fname_match: -- 2.17.1 From akuster808 at gmail.com Wed Mar 11 02:26:05 2020 From: akuster808 at gmail.com (Armin Kuster) Date: Tue, 10 Mar 2020 19:26:05 -0700 Subject: [OE-core] [zeus 04/16] dummy-sdk-package: Add DUMMYPROVIDES_PACKAGES In-Reply-To: References: Message-ID: From: Richard Purdie We're about to need to use this variable in the main include file so restructure the users of it to all set it appropriately. Signed-off-by: Richard Purdie (cherry picked from commit 4a247e7c961286cbed73b6dc0f4074ecf856402a) Signed-off-by: Armin Kuster --- meta/recipes-core/meta/dummy-sdk-package.inc | 3 +++ meta/recipes-core/meta/nativesdk-buildtools-perl-dummy.bb | 5 ++++- meta/recipes-core/meta/nativesdk-sdk-provides-dummy.bb | 5 ++++- meta/recipes-core/meta/target-sdk-provides-dummy.bb | 1 - 4 files changed, 11 insertions(+), 3 deletions(-) diff --git a/meta/recipes-core/meta/dummy-sdk-package.inc b/meta/recipes-core/meta/dummy-sdk-package.inc index 4d653706b1..0d15a37c35 100644 --- a/meta/recipes-core/meta/dummy-sdk-package.inc +++ b/meta/recipes-core/meta/dummy-sdk-package.inc @@ -17,6 +17,9 @@ ALLOW_EMPTY_${PN} = "1" PR[vardeps] += "DUMMYPROVIDES" +DUMMYPROVIDES_PACKAGES ??= "" +DUMMYPROVIDES += "${@' '.join([multilib_pkg_extend(d, pkg) for pkg in d.getVar('DUMMYPROVIDES_PACKAGES').split()])}" + python populate_packages_prepend() { p = d.getVar("PN") d.appendVar("RPROVIDES_%s" % p, "${DUMMYPROVIDES}") diff --git a/meta/recipes-core/meta/nativesdk-buildtools-perl-dummy.bb b/meta/recipes-core/meta/nativesdk-buildtools-perl-dummy.bb index 6a8748acdf..5bc11b9daf 100644 --- a/meta/recipes-core/meta/nativesdk-buildtools-perl-dummy.bb +++ b/meta/recipes-core/meta/nativesdk-buildtools-perl-dummy.bb @@ -1,6 +1,6 @@ DUMMYARCH = "buildtools-dummy-${SDKPKGSUFFIX}" -DUMMYPROVIDES = "\ +DUMMYPROVIDES_PACKAGES = "\ nativesdk-perl \ nativesdk-libxml-parser-perl \ nativesdk-perl-module-bytes \ @@ -21,6 +21,9 @@ DUMMYPROVIDES = "\ nativesdk-perl-module-posix \ nativesdk-perl-module-thread-queue \ nativesdk-perl-module-threads \ +" + +DUMMYPROVIDES = "\ /usr/bin/perl \ " diff --git a/meta/recipes-core/meta/nativesdk-sdk-provides-dummy.bb b/meta/recipes-core/meta/nativesdk-sdk-provides-dummy.bb index b891efa5ef..29f4dd3633 100644 --- a/meta/recipes-core/meta/nativesdk-sdk-provides-dummy.bb +++ b/meta/recipes-core/meta/nativesdk-sdk-provides-dummy.bb @@ -1,10 +1,13 @@ DUMMYARCH = "sdk-provides-dummy-${SDKPKGSUFFIX}" +DUMMYPROVIDES_PACKAGES = "\ + pkgconfig \ +" + # Add /bin/sh? DUMMYPROVIDES = "\ /bin/bash \ /usr/bin/env \ - pkgconfig \ libGL.so()(64bit) \ libGL.so \ " diff --git a/meta/recipes-core/meta/target-sdk-provides-dummy.bb b/meta/recipes-core/meta/target-sdk-provides-dummy.bb index 87b8bfab9c..e3beeb796c 100644 --- a/meta/recipes-core/meta/target-sdk-provides-dummy.bb +++ b/meta/recipes-core/meta/target-sdk-provides-dummy.bb @@ -48,7 +48,6 @@ DUMMYPROVIDES_PACKAGES = "\ " DUMMYPROVIDES = "\ - ${@' '.join([multilib_pkg_extend(d, pkg) for pkg in d.getVar('DUMMYPROVIDES_PACKAGES').split()])} \ /bin/sh \ /bin/bash \ /usr/bin/env \ -- 2.17.1 From akuster808 at gmail.com Wed Mar 11 02:26:06 2020 From: akuster808 at gmail.com (Armin Kuster) Date: Tue, 10 Mar 2020 19:26:06 -0700 Subject: [OE-core] [zeus 05/16] wic/engine: lets display an error not a traceback In-Reply-To: References: Message-ID: <29a1d9bed5bf7ed024870a0323f9afdf88346e4d.1583893499.git.akuster808@gmail.com> If the requested partition does not exist in this request "wic ls {path}:pnum" display a nice message not a trackback Also fix displaying the pnum and not "%s" Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie (cherry picked from commit 15d1722950a22649905cf8a5789d3cfe48a2a892) Signed-off-by: Armin Kuster --- scripts/lib/wic/engine.py | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/scripts/lib/wic/engine.py b/scripts/lib/wic/engine.py index 18776fa8a0..4ccca482e7 100644 --- a/scripts/lib/wic/engine.py +++ b/scripts/lib/wic/engine.py @@ -290,7 +290,7 @@ class Disk: def _get_part_image(self, pnum): if pnum not in self.partitions: - raise WicError("Partition %s is not in the image") + raise WicError("Partition %s is not in the image" % pnum) part = self.partitions[pnum] # check if fstype is supported for fstype in self.fstypes: @@ -313,6 +313,9 @@ class Disk: seek=self.partitions[pnum].start) def dir(self, pnum, path): + if pnum not in self.partitions: + raise WicError("Partition %s is not in the image" % pnum) + if self.partitions[pnum].fstype.startswith('ext'): return exec_cmd("{} {} -R 'ls -l {}'".format(self.debugfs, self._get_part_image(pnum), -- 2.17.1 From akuster808 at gmail.com Wed Mar 11 02:26:07 2020 From: akuster808 at gmail.com (Armin Kuster) Date: Tue, 10 Mar 2020 19:26:07 -0700 Subject: [OE-core] [zeus 06/16] valgrind: Fix build with -fno-common In-Reply-To: References: Message-ID: <350496c3c0b80835cb5311aa6dbc91e4ee7b5935.1583893499.git.akuster808@gmail.com> From: Khem Raj Signed-off-by: Khem Raj Signed-off-by: Richard Purdie (cherry picked from commit 14f14eccf176539493fbfe710b66704feb7710da) Signed-off-by: Armin Kuster --- .../valgrind/valgrind/s390x_vec_op_t.patch | 19 +++++++++++++++++++ .../valgrind/valgrind_3.15.0.bb | 1 + 2 files changed, 20 insertions(+) create mode 100644 meta/recipes-devtools/valgrind/valgrind/s390x_vec_op_t.patch diff --git a/meta/recipes-devtools/valgrind/valgrind/s390x_vec_op_t.patch b/meta/recipes-devtools/valgrind/valgrind/s390x_vec_op_t.patch new file mode 100644 index 0000000000..eea671da0a --- /dev/null +++ b/meta/recipes-devtools/valgrind/valgrind/s390x_vec_op_t.patch @@ -0,0 +1,19 @@ +s390x_vec_op_t is not needed anywhere, only elements of enum are accessed +removing it ensures that valgrind can be built with -fno-common option + +Fixes +ld: ../../VEX/libvex-amd64-linux.a(libvex_amd64_linux_a-guest_s390_helpers.o):/usr/src/debug/valgrind/3.15.0-r0/build/VEX/../../valgrind-3.15.0/VEX/priv/guest_s390_defs.h:289: multiple definition of `s390x_vec_op_t'; ../../VEX/libvexmultiarch-amd64-linux.a(libvexmultiarch_amd64_linux_a-multiarch_main_main.o):/usr/src/debug/valgrind/3.15.0-r0/build/VEX/../../valgrind-3.15.0/VEX/priv/guest_s390_defs.h:289: first defined here + +Upstream-Status: Pending +Signed-off-by: Khem Raj +--- a/VEX/priv/guest_s390_defs.h ++++ b/VEX/priv/guest_s390_defs.h +@@ -286,7 +286,7 @@ enum { + S390_VEC_OP_VFCHE = 18, + S390_VEC_OP_VFTCI = 19, + S390_VEC_OP_LAST = 20 // supposed to be the last element in enum +-} s390x_vec_op_t; ++}; + + /* Arguments of s390x_dirtyhelper_vec_op(...) which are packed into one + ULong variable. diff --git a/meta/recipes-devtools/valgrind/valgrind_3.15.0.bb b/meta/recipes-devtools/valgrind/valgrind_3.15.0.bb index 63f972945d..aedaab27b3 100644 --- a/meta/recipes-devtools/valgrind/valgrind_3.15.0.bb +++ b/meta/recipes-devtools/valgrind/valgrind_3.15.0.bb @@ -40,6 +40,7 @@ SRC_URI = "https://sourceware.org/pub/valgrind/valgrind-${PV}.tar.bz2 \ file://0001-valgrind-filter_xml_frames-do-not-filter-usr.patch \ file://0002-valgrind-adjust-std_list-expected-output.patch \ file://0001-adjust-path-filter-for-2-memcheck-tests.patch \ + file://s390x_vec_op_t.patch \ " SRC_URI[md5sum] = "46e5fbdcbc3502a5976a317a0860a975" SRC_URI[sha256sum] = "417c7a9da8f60dd05698b3a7bc6002e4ef996f14c13f0ff96679a16873e78ab1" -- 2.17.1 From akuster808 at gmail.com Wed Mar 11 02:26:08 2020 From: akuster808 at gmail.com (Armin Kuster) Date: Tue, 10 Mar 2020 19:26:08 -0700 Subject: [OE-core] [zeus 07/16] gcc-cross-canadian: A missing space in an append caused an invalid option In-Reply-To: References: Message-ID: From: Mark Hatle When configuring the cross-candian toolchain for a non-linux target system, the resulting gcc configuration included: --enable-initfini-array--without-headers these should have been two separate options. Signed-off-by: Mark Hatle Signed-off-by: Richard Purdie (cherry picked from commit 7b52893632dae7bc9ac75dddc7ad625e19f41050) Signed-off-by: Armin Kuster --- meta/recipes-devtools/gcc/gcc-cross-canadian.inc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/recipes-devtools/gcc/gcc-cross-canadian.inc b/meta/recipes-devtools/gcc/gcc-cross-canadian.inc index f14cbf7152..4aac345bec 100644 --- a/meta/recipes-devtools/gcc/gcc-cross-canadian.inc +++ b/meta/recipes-devtools/gcc/gcc-cross-canadian.inc @@ -158,7 +158,7 @@ SYSTEMLIBS1 = "${target_libdir}/" EXTRA_OECONF += "--enable-poison-system-directories" EXTRA_OECONF_remove_elf = "--with-sysroot=/not/exist" EXTRA_OECONF_remove_eabi = "--with-sysroot=/not/exist" -EXTRA_OECONF_append_elf = "--without-headers --with-newlib" -EXTRA_OECONF_append_eabi = "--without-headers --with-newlib" +EXTRA_OECONF_append_elf = " --without-headers --with-newlib" +EXTRA_OECONF_append_eabi = " --without-headers --with-newlib" # gcc 4.7 needs -isystem export ARCH_FLAGS_FOR_TARGET = "--sysroot=${STAGING_DIR_TARGET} -isystem=${target_includedir}" -- 2.17.1 From akuster808 at gmail.com Wed Mar 11 02:26:09 2020 From: akuster808 at gmail.com (Armin Kuster) Date: Tue, 10 Mar 2020 19:26:09 -0700 Subject: [OE-core] [zeus 08/16] gcc-cross.inc: Prevent native sysroot from leaking into configargs.h In-Reply-To: References: Message-ID: <102fe8f850f97c7a588ee342846b4c10b8603b0d.1583893499.git.akuster808@gmail.com> From: Nathan Rossi Prevent the native(sdk) sysroot path from leaking into configargs.h. The configargs.h header is intended to be static and unchanged as the content is used as a means of determining that a gcc plugin is built for the same gcc. This also effects the output of 'gcc --version'. Due to per recipe sysroots and staging, the sysroot path would be replaced with the sysroot local to the recipe thus changing the content of configargs.h. The sysroot path is replaced with a generic "/host" prefix which represents the host sysroot (e.g. native or nativesdk). Signed-off-by: Nathan Rossi Signed-off-by: Ross Burton (cherry picked from commit 84a78f46d59447eeec3d69532a7506148f64c979) Signed-off-by: Armin Kuster --- meta/recipes-devtools/gcc/gcc-cross.inc | 7 +++++++ meta/recipes-devtools/gcc/gcc-runtime.inc | 4 ---- 2 files changed, 7 insertions(+), 4 deletions(-) diff --git a/meta/recipes-devtools/gcc/gcc-cross.inc b/meta/recipes-devtools/gcc/gcc-cross.inc index 8855bb1f34..06ba3ccd15 100644 --- a/meta/recipes-devtools/gcc/gcc-cross.inc +++ b/meta/recipes-devtools/gcc/gcc-cross.inc @@ -61,6 +61,13 @@ do_compile () { export CXXFLAGS_FOR_TARGET="${TARGET_CXXFLAGS}" export LDFLAGS_FOR_TARGET="${TARGET_LDFLAGS}" + # Prevent native/host sysroot path from being used in configargs.h header, + # as it will be rewritten when used by other sysroots preventing support + # for gcc plugins + oe_runmake configure-gcc + sed -i 's@${STAGING_DIR_TARGET}@/host at g' ${B}/gcc/configargs.h + sed -i 's@${STAGING_DIR_HOST}@/host at g' ${B}/gcc/configargs.h + oe_runmake all-host configure-target-libgcc (cd ${B}/${TARGET_SYS}/libgcc; oe_runmake enable-execute-stack.c unwind.h md-unwind-support.h sfp-machine.h gthr-default.h) # now generate script to drive testing diff --git a/meta/recipes-devtools/gcc/gcc-runtime.inc b/meta/recipes-devtools/gcc/gcc-runtime.inc index 2da3c02ef0..536b18d97f 100644 --- a/meta/recipes-devtools/gcc/gcc-runtime.inc +++ b/meta/recipes-devtools/gcc/gcc-runtime.inc @@ -302,10 +302,6 @@ do_check() { # HACK: this works around the configure setting CXX with -nostd* args sed -i 's/-nostdinc++ -nostdlib++//g' $(find ${B} -name testsuite_flags | head -1) - # HACK: this works around the de-stashing changes to configargs.h, as well as recipe-sysroot changing the content - sed -i '/static const char configuration_arguments/d' ${B}/gcc/configargs.h - ${CC} -v 2>&1 | grep "^Configured with:" | \ - sed 's/Configured with: \(.*\)/static const char configuration_arguments[] = "\1";/g' >> ${B}/gcc/configargs.h if [ "${TOOLCHAIN_TEST_TARGET}" = "user" ]; then # qemu user has issues allocating large amounts of memory -- 2.17.1 From akuster808 at gmail.com Wed Mar 11 02:26:10 2020 From: akuster808 at gmail.com (Armin Kuster) Date: Tue, 10 Mar 2020 19:26:10 -0700 Subject: [OE-core] [zeus 09/16] gcc-target.inc: Prevent sysroot from leaking into configargs.h In-Reply-To: References: Message-ID: <2f4428d8a7af49b7f251e863b7d4f21301ed1c43.1583893499.git.akuster808@gmail.com> From: Nathan Rossi Prevent the full recipe-sysroot path from leaking into configargs.h. The configargs.h header is intended to be static and unchanged as the content is used as a means of determining that a gcc plugin is built for the same gcc. This also effects the output of 'gcc -v'. Due to per recipe sysroots and staging, the sysroot path would be replaced with the sysroot local to the recipe thus changing the content of configargs.h. This change also improves gcc binary reproducibility. The sysroot path is replaced with the base target root "/". Signed-off-by: Nathan Rossi Signed-off-by: Richard Purdie (cherry picked from commit b8d6e2ab68ee5e341fe970b191bfd334e6d2c40b) Signed-off-by: Armin Kuster --- meta/recipes-devtools/gcc/gcc-target.inc | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/meta/recipes-devtools/gcc/gcc-target.inc b/meta/recipes-devtools/gcc/gcc-target.inc index bdc6ff658f..987e88d32c 100644 --- a/meta/recipes-devtools/gcc/gcc-target.inc +++ b/meta/recipes-devtools/gcc/gcc-target.inc @@ -137,6 +137,14 @@ FILES_${PN}-doc = "\ " do_compile () { + # Prevent full target sysroot path from being used in configargs.h header, + # as it will be rewritten when used by other sysroots preventing support + # for gcc plugins. Additionally the path is embeddeded into the output + # binary, this prevents building a reproducible binary. + oe_runmake configure-gcc + sed -i 's@${STAGING_DIR_TARGET}@/@g' ${B}/gcc/configargs.h + sed -i 's@${STAGING_DIR_HOST}@/@g' ${B}/gcc/configargs.h + oe_runmake all-host } -- 2.17.1 From akuster808 at gmail.com Wed Mar 11 02:26:11 2020 From: akuster808 at gmail.com (Armin Kuster) Date: Tue, 10 Mar 2020 19:26:11 -0700 Subject: [OE-core] [zeus 10/16] ruby: fix CVE-2019-16254 In-Reply-To: References: Message-ID: From: Rahul Chauhan Signed-off-by: Rahul Chauhan Signed-off-by: Anuj Mittal --- .../ruby/ruby/fix-CVE-2019-16254.patch | 106 ++++++++++++++++++ meta/recipes-devtools/ruby/ruby_2.5.5.bb | 1 + 2 files changed, 107 insertions(+) create mode 100644 meta/recipes-devtools/ruby/ruby/fix-CVE-2019-16254.patch diff --git a/meta/recipes-devtools/ruby/ruby/fix-CVE-2019-16254.patch b/meta/recipes-devtools/ruby/ruby/fix-CVE-2019-16254.patch new file mode 100644 index 0000000000..704c850c50 --- /dev/null +++ b/meta/recipes-devtools/ruby/ruby/fix-CVE-2019-16254.patch @@ -0,0 +1,106 @@ +From 18d5289b4579822e391b3f5c16541e6552e9f06c Mon Sep 17 00:00:00 2001 +From: Yusuke Endoh +Date: Tue, 1 Oct 2019 12:29:18 +0900 +Subject: [PATCH] WEBrick: prevent response splitting and header injection + +This is a follow up to d9d4a28f1cdd05a0e8dabb36d747d40bbcc30f16. +The commit prevented CRLR, but did not address an isolated CR or an +isolated LF. + +Upstream-Status: Backport https://github.com/ruby/ruby/commit/3ce238b5f9795581eb84114dcfbdf4aa086bfecc +CVE: CVE-2019-16254 + +Co-Authored-By: NARUSE, Yui +Signed-off-by: Rahul Chauhan +--- + lib/webrick/httpresponse.rb | 3 ++- + test/webrick/test_httpresponse.rb | 46 +++++++++++++++++++++++++++++++++++++-- + 2 files changed, 46 insertions(+), 3 deletions(-) + +diff --git a/lib/webrick/httpresponse.rb b/lib/webrick/httpresponse.rb +index 6d77692..d26324c 100644 +--- a/lib/webrick/httpresponse.rb ++++ b/lib/webrick/httpresponse.rb +@@ -367,7 +367,8 @@ def set_error(ex, backtrace=false) + private + + def check_header(header_value) +- if header_value =~ /\r\n/ ++ header_value = header_value.to_s ++ if /[\r\n]/ =~ header_value + raise InvalidHeader + else + header_value +diff --git a/test/webrick/test_httpresponse.rb b/test/webrick/test_httpresponse.rb +index 6263e0a..24a6968 100644 +--- a/test/webrick/test_httpresponse.rb ++++ b/test/webrick/test_httpresponse.rb +@@ -29,7 +29,7 @@ def setup + @res.keep_alive = true + end + +- def test_prevent_response_splitting_headers ++ def test_prevent_response_splitting_headers_crlf + res['X-header'] = "malicious\r\nCookie: hack" + io = StringIO.new + res.send_response io +@@ -39,7 +39,7 @@ def test_prevent_response_splitting_headers + refute_match 'hack', io.string + end + +- def test_prevent_response_splitting_cookie_headers ++ def test_prevent_response_splitting_cookie_headers_crlf + user_input = "malicious\r\nCookie: hack" + res.cookies << WEBrick::Cookie.new('author', user_input) + io = StringIO.new +@@ -50,6 +50,48 @@ def test_prevent_response_splitting_cookie_headers + refute_match 'hack', io.string + end + ++ def test_prevent_response_splitting_headers_cr ++ res['X-header'] = "malicious\rCookie: hack" ++ io = StringIO.new ++ res.send_response io ++ io.rewind ++ res = Net::HTTPResponse.read_new(Net::BufferedIO.new(io)) ++ assert_equal '500', res.code ++ refute_match 'hack', io.string ++ end ++ ++ def test_prevent_response_splitting_cookie_headers_cr ++ user_input = "malicious\rCookie: hack" ++ res.cookies << WEBrick::Cookie.new('author', user_input) ++ io = StringIO.new ++ res.send_response io ++ io.rewind ++ res = Net::HTTPResponse.read_new(Net::BufferedIO.new(io)) ++ assert_equal '500', res.code ++ refute_match 'hack', io.string ++ end ++ ++ def test_prevent_response_splitting_headers_lf ++ res['X-header'] = "malicious\nCookie: hack" ++ io = StringIO.new ++ res.send_response io ++ io.rewind ++ res = Net::HTTPResponse.read_new(Net::BufferedIO.new(io)) ++ assert_equal '500', res.code ++ refute_match 'hack', io.string ++ end ++ ++ def test_prevent_response_splitting_cookie_headers_lf ++ user_input = "malicious\nCookie: hack" ++ res.cookies << WEBrick::Cookie.new('author', user_input) ++ io = StringIO.new ++ res.send_response io ++ io.rewind ++ res = Net::HTTPResponse.read_new(Net::BufferedIO.new(io)) ++ assert_equal '500', res.code ++ refute_match 'hack', io.string ++ end ++ + def test_304_does_not_log_warning + res.status = 304 + res.setup_header +-- +2.7.4 diff --git a/meta/recipes-devtools/ruby/ruby_2.5.5.bb b/meta/recipes-devtools/ruby/ruby_2.5.5.bb index 223b0371eb..58bb97f4bd 100644 --- a/meta/recipes-devtools/ruby/ruby_2.5.5.bb +++ b/meta/recipes-devtools/ruby/ruby_2.5.5.bb @@ -3,6 +3,7 @@ require ruby.inc SRC_URI += " \ file://0001-configure.ac-check-finite-isinf-isnan-as-macros-firs.patch \ file://run-ptest \ + file://fix-CVE-2019-16254.patch \ " SRC_URI[md5sum] = "7e156fb526b8f4bb1b30a3dd8a7ce400" -- 2.17.1 From akuster808 at gmail.com Wed Mar 11 02:26:12 2020 From: akuster808 at gmail.com (Armin Kuster) Date: Tue, 10 Mar 2020 19:26:12 -0700 Subject: [OE-core] [zeus 11/16] dhcp: Fix REQUIRE(ctx->running) assertion triggered on SIGTERM/SIGINT In-Reply-To: References: Message-ID: <62fffe05ff3fd69ed7bb4d23748035b74445dcf6.1583893499.git.akuster808@gmail.com> From: Ovidiu Panait Closed a small window of time between the installation of graceful shutdown signal handlers and application context startup, during which the receipt of shutdown signal would cause a REQUIRE() assertion to occur. Note this issue is only visible when compiling with ENABLE_GENTLE_SHUTDOWN defined. Reference: https://gitlab.isc.org/isc-projects/dhcp/issues/53 Upstream patches: https://gitlab.isc.org/isc-projects/dhcp/commit/ce117de7a1ed3c4911b4009c1cc23fba85370a26 https://gitlab.isc.org/isc-projects/dhcp/commit/dbd36dfa82956b53683462afadfabb1b33fa3dd1 https://gitlab.isc.org/isc-projects/dhcp/commit/95944cab6035d20be270eec01254c7bb867ec705 Signed-off-by: Ovidiu Panait Signed-off-by: Anuj Mittal --- ...s-running-prior-to-calling-isc_app_c.patch | 165 ++++++++++++++++++ ...ed-shutdown-log-statment-to-dhcrelay.patch | 29 +++ .../dhcp/0003-Addressed-review-comment.patch | 31 ++++ meta/recipes-connectivity/dhcp/dhcp_4.4.1.bb | 3 + 4 files changed, 228 insertions(+) create mode 100644 meta/recipes-connectivity/dhcp/dhcp/0001-Ensure-context-is-running-prior-to-calling-isc_app_c.patch create mode 100644 meta/recipes-connectivity/dhcp/dhcp/0002-Added-shutdown-log-statment-to-dhcrelay.patch create mode 100644 meta/recipes-connectivity/dhcp/dhcp/0003-Addressed-review-comment.patch diff --git a/meta/recipes-connectivity/dhcp/dhcp/0001-Ensure-context-is-running-prior-to-calling-isc_app_c.patch b/meta/recipes-connectivity/dhcp/dhcp/0001-Ensure-context-is-running-prior-to-calling-isc_app_c.patch new file mode 100644 index 0000000000..34b2ae1e5c --- /dev/null +++ b/meta/recipes-connectivity/dhcp/dhcp/0001-Ensure-context-is-running-prior-to-calling-isc_app_c.patch @@ -0,0 +1,165 @@ +From f369dbb9e67eb5ef336944af63039b6d8f838384 Mon Sep 17 00:00:00 2001 +From: Thomas Markwalder +Date: Thu, 12 Sep 2019 10:35:46 -0400 +Subject: [PATCH 1/3] Ensure context is running prior to calling + isc_app_ctxsuspend + +Add a release note. + +includes/omapip/isclib.h + Added actx_running flag to global context, dhcp_gbl_ctx + +omapip/isclib.c + set_ctx_running() - new function used as the ctxonrun callback + + dhcp_context_create() - installs set_ctx_running callback + + dhcp_signal_handler() - modified to use act_running flag to + determine is context is running and should be suspended + +Upstream-Status: Backport [https://gitlab.isc.org/isc-projects/dhcp.git] + +Signed-off-by: Ovidiu Panait +--- + RELNOTES | 7 +++++ + includes/omapip/isclib.h | 3 ++- + omapip/isclib.c | 57 +++++++++++++++++++++++++++++++++------- + 3 files changed, 57 insertions(+), 10 deletions(-) + +diff --git a/RELNOTES b/RELNOTES +index f10305d..1730473 100644 +--- a/RELNOTES ++++ b/RELNOTES +@@ -6,6 +6,13 @@ + + NEW FEATURES + ++- Closed a small window of time between the installation of graceful ++ shutdown signal handlers and application context startup, during which ++ the receipt of shutdown signal would cause a REQUIRE() assertion to ++ occur. Note this issue is only visible when compiling with ++ ENABLE_GENTLE_SHUTDOWN defined. ++ [Gitlab #53,!18 git TBD] ++ + Please note that that ISC DHCP is now licensed under the Mozilla Public License, + MPL 2.0. Please see https://www.mozilla.org/en-US/MPL/2.0/ to read the MPL 2.0 + license terms. +diff --git a/includes/omapip/isclib.h b/includes/omapip/isclib.h +index 6c20584..af6a6fc 100644 +--- a/includes/omapip/isclib.h ++++ b/includes/omapip/isclib.h +@@ -94,7 +94,8 @@ + typedef struct dhcp_context { + isc_mem_t *mctx; + isc_appctx_t *actx; +- int actx_started; ++ int actx_started; // ISC_TRUE if ctxstart has been called ++ int actx_running; // ISC_TRUE if ctxrun has been called + isc_taskmgr_t *taskmgr; + isc_task_t *task; + isc_socketmgr_t *socketmgr; +diff --git a/omapip/isclib.c b/omapip/isclib.c +index ce4b4a1..73e017c 100644 +--- a/omapip/isclib.c ++++ b/omapip/isclib.c +@@ -134,6 +134,35 @@ handle_signal(int sig, void (*handler)(int)) { + } + } + ++/* Callback passed to isc_app_ctxonrun ++ * ++ * BIND9 context code will invoke this handler once the context has ++ * entered the running state. We use it to set a global marker so that ++ * we can tell if the context is running. Several of the isc_app_ ++ * calls REQUIRE that the context is running and we need a way to ++ * know that. ++ * ++ * We also check to see if we received a shutdown signal prior to ++ * the context entering the run state. If we did, then we can just ++ * simply shut the context down now. This closes the relatively ++ * small window between start up and entering run via the call ++ * to dispatch(). ++ * ++ */ ++static void ++set_ctx_running(isc_task_t *task, isc_event_t *event) { ++ task = task; // unused; ++ dhcp_gbl_ctx.actx_running = ISC_TRUE; ++ ++ if (shutdown_signal) { ++ // We got signaled shutdown before we entered running state. ++ // Now that we've reached running state, shut'er down. ++ isc_app_ctxsuspend(dhcp_gbl_ctx.actx); ++ } ++ ++ isc_event_free(&event); ++} ++ + isc_result_t + dhcp_context_create(int flags, + struct in_addr *local4, +@@ -141,6 +170,9 @@ dhcp_context_create(int flags, + isc_result_t result; + + if ((flags & DHCP_CONTEXT_PRE_DB) != 0) { ++ dhcp_gbl_ctx.actx_started = ISC_FALSE; ++ dhcp_gbl_ctx.actx_running = ISC_FALSE; ++ + /* + * Set up the error messages, this isn't the right place + * for this call but it is convienent for now. +@@ -204,15 +236,24 @@ dhcp_context_create(int flags, + if (result != ISC_R_SUCCESS) + goto cleanup; + +- result = isc_task_create(dhcp_gbl_ctx.taskmgr, 0, &dhcp_gbl_ctx.task); ++ result = isc_task_create(dhcp_gbl_ctx.taskmgr, 0, ++ &dhcp_gbl_ctx.task); + if (result != ISC_R_SUCCESS) + goto cleanup; + + result = isc_app_ctxstart(dhcp_gbl_ctx.actx); + if (result != ISC_R_SUCCESS) +- return (result); ++ goto cleanup; ++ + dhcp_gbl_ctx.actx_started = ISC_TRUE; + ++ // Install the onrun callback. ++ result = isc_app_ctxonrun(dhcp_gbl_ctx.actx, dhcp_gbl_ctx.mctx, ++ dhcp_gbl_ctx.task, set_ctx_running, ++ dhcp_gbl_ctx.actx); ++ if (result != ISC_R_SUCCESS) ++ goto cleanup; ++ + /* Not all OSs support suppressing SIGPIPE through socket + * options, so set the sigal action to be ignore. This allows + * broken connections to fail gracefully with EPIPE on writes */ +@@ -335,19 +376,17 @@ isclib_make_dst_key(char *inname, + * @param signal signal code that we received + */ + void dhcp_signal_handler(int signal) { +- isc_appctx_t *ctx = dhcp_gbl_ctx.actx; +- int prev = shutdown_signal; +- +- if (prev != 0) { ++ if (shutdown_signal != 0) { + /* Already in shutdown. */ + return; + } ++ + /* Possible race but does it matter? */ + shutdown_signal = signal; + +- /* Use reload (aka suspend) for easier dispatch() reenter. */ +- if (ctx && ctx->methods && ctx->methods->ctxsuspend) { +- (void) isc_app_ctxsuspend(ctx); ++ /* If the application context is running tell it to shut down */ ++ if (dhcp_gbl_ctx.actx_running == ISC_TRUE) { ++ (void) isc_app_ctxsuspend(dhcp_gbl_ctx.actx); + } + } + +-- +2.23.0 + diff --git a/meta/recipes-connectivity/dhcp/dhcp/0002-Added-shutdown-log-statment-to-dhcrelay.patch b/meta/recipes-connectivity/dhcp/dhcp/0002-Added-shutdown-log-statment-to-dhcrelay.patch new file mode 100644 index 0000000000..78b2b74f45 --- /dev/null +++ b/meta/recipes-connectivity/dhcp/dhcp/0002-Added-shutdown-log-statment-to-dhcrelay.patch @@ -0,0 +1,29 @@ +From adcd34ae1f56b16d7e9696d980332b4cf6c7ce91 Mon Sep 17 00:00:00 2001 +From: Thomas Markwalder +Date: Fri, 13 Sep 2019 15:03:31 -0400 +Subject: [PATCH 2/3] Added shutdown log statment to dhcrelay + +Upstream-Status: Backport [https://gitlab.isc.org/isc-projects/dhcp.git] + +Signed-off-by: Ovidiu Panait +--- + relay/dhcrelay.c | 3 +++ + 1 file changed, 3 insertions(+) + +diff --git a/relay/dhcrelay.c b/relay/dhcrelay.c +index d8caaaf..4bd1d47 100644 +--- a/relay/dhcrelay.c ++++ b/relay/dhcrelay.c +@@ -2076,6 +2076,9 @@ dhcp_set_control_state(control_object_state_t oldstate, + if (newstate != server_shutdown) + return ISC_R_SUCCESS; + ++ /* Log shutdown on signal. */ ++ log_info("Received signal %d, initiating shutdown.", shutdown_signal); ++ + if (no_pid_file == ISC_FALSE) + (void) unlink(path_dhcrelay_pid); + +-- +2.23.0 + diff --git a/meta/recipes-connectivity/dhcp/dhcp/0003-Addressed-review-comment.patch b/meta/recipes-connectivity/dhcp/dhcp/0003-Addressed-review-comment.patch new file mode 100644 index 0000000000..a51b6cf526 --- /dev/null +++ b/meta/recipes-connectivity/dhcp/dhcp/0003-Addressed-review-comment.patch @@ -0,0 +1,31 @@ +From e4b54b4d676783152d487103714cba2913661ef8 Mon Sep 17 00:00:00 2001 +From: Thomas Markwalder +Date: Wed, 6 Nov 2019 15:53:50 -0500 +Subject: [PATCH 3/3] Addressed review comment. + +omapip/isclib.c + Added use of IGNORE_UNUSED() + +Upstream-Status: Backport [https://gitlab.isc.org/isc-projects/dhcp.git] + +Signed-off-by: Ovidiu Panait +--- + omapip/isclib.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/omapip/isclib.c b/omapip/isclib.c +index 73e017c..1d52463 100644 +--- a/omapip/isclib.c ++++ b/omapip/isclib.c +@@ -151,7 +151,7 @@ handle_signal(int sig, void (*handler)(int)) { + */ + static void + set_ctx_running(isc_task_t *task, isc_event_t *event) { +- task = task; // unused; ++ IGNORE_UNUSED(task); + dhcp_gbl_ctx.actx_running = ISC_TRUE; + + if (shutdown_signal) { +-- +2.23.0 + diff --git a/meta/recipes-connectivity/dhcp/dhcp_4.4.1.bb b/meta/recipes-connectivity/dhcp/dhcp_4.4.1.bb index 275961a603..ddc8b60254 100644 --- a/meta/recipes-connectivity/dhcp/dhcp_4.4.1.bb +++ b/meta/recipes-connectivity/dhcp/dhcp_4.4.1.bb @@ -11,6 +11,9 @@ SRC_URI += "file://0001-define-macro-_PATH_DHCPD_CONF-and-_PATH_DHCLIENT_CON.pat file://0013-fixup_use_libbind.patch \ file://0001-master-Added-includes-of-new-BIND9-compatibility-hea.patch \ file://0001-Fix-a-NSUPDATE-compiling-issue.patch \ + file://0001-Ensure-context-is-running-prior-to-calling-isc_app_c.patch \ + file://0002-Added-shutdown-log-statment-to-dhcrelay.patch \ + file://0003-Addressed-review-comment.patch \ " SRC_URI[md5sum] = "18c7f4dcbb0a63df25098216d47b1ede" -- 2.17.1 From akuster808 at gmail.com Wed Mar 11 02:26:13 2020 From: akuster808 at gmail.com (Armin Kuster) Date: Tue, 10 Mar 2020 19:26:13 -0700 Subject: [OE-core] [zeus 12/16] virglrenderer: fix multiple CVEs In-Reply-To: References: Message-ID: <27ebe3b9c6954ee3be12f328f9cec58620930d02.1583893499.git.akuster808@gmail.com> From: Lee Chee Yang fix these CVE: CVE-2019-18390 CVE-2019-18391 CVE-2020-8002 Signed-off-by: Lee Chee Yang Signed-off-by: Anuj Mittal --- .../virglrenderer/CVE-2019-18390.patch | 66 +++++++++++++++++++ .../virglrenderer/CVE-2019-18391.patch | 51 ++++++++++++++ .../virglrenderer/CVE-2020-8002.patch | 39 +++++++++++ .../virglrenderer/virglrenderer_0.8.0.bb | 3 + 4 files changed, 159 insertions(+) create mode 100644 meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2019-18390.patch create mode 100644 meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2019-18391.patch create mode 100644 meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2020-8002.patch diff --git a/meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2019-18390.patch b/meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2019-18390.patch new file mode 100644 index 0000000000..ad61c95be3 --- /dev/null +++ b/meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2019-18390.patch @@ -0,0 +1,66 @@ +From 24f67de7a9088a873844a39be03cee6882260ac9 Mon Sep 17 00:00:00 2001 +From: Gert Wollny +Date: Mon, 7 Oct 2019 10:59:56 +0200 +Subject: [PATCH] vrend: check info formats in blits + +Closes #141 +Closes #142 + +v2 : drop colon in error description (Emil) + +Signed-off-by: Gert Wollny +Reviewed-by: Emil Velikov + +Upstream-Status: Backport +[https://gitlab.freedesktop.org/virgl/virglrenderer/commit/24f67de7a9088a873844a39be03cee6882260ac9] +CVE: CVE-2019-18390 +Signed-off-by: Lee Chee Yang +--- + src/virgl_hw.h | 1 + + src/vrend_renderer.c | 11 +++++++++++ + 2 files changed, 12 insertions(+) + +diff --git a/src/virgl_hw.h b/src/virgl_hw.h +index 145780bf..5ccf3073 100644 +--- a/src/virgl_hw.h ++++ b/src/virgl_hw.h +@@ -426,6 +426,7 @@ enum virgl_ctx_errors { + VIRGL_ERROR_CTX_ILLEGAL_CMD_BUFFER, + VIRGL_ERROR_CTX_GLES_HAVE_TES_BUT_MISS_TCS, + VIRGL_ERROR_GL_ANY_SAMPLES_PASSED, ++ VIRGL_ERROR_CTX_ILLEGAL_FORMAT, + }; + + #define VIRGL_RESOURCE_Y_0_TOP (1 << 0) +diff --git a/src/vrend_renderer.c b/src/vrend_renderer.c +index 14fefb38..aa6a89c1 100644 +--- a/src/vrend_renderer.c ++++ b/src/vrend_renderer.c +@@ -758,6 +758,7 @@ static const char *vrend_ctx_error_strings[] = { + [VIRGL_ERROR_CTX_ILLEGAL_CMD_BUFFER] = "Illegal command buffer", + [VIRGL_ERROR_CTX_GLES_HAVE_TES_BUT_MISS_TCS] = "On GLES context and shader program has tesselation evaluation shader but no tesselation control shader", + [VIRGL_ERROR_GL_ANY_SAMPLES_PASSED] = "Query for ANY_SAMPLES_PASSED not supported", ++ [VIRGL_ERROR_CTX_ILLEGAL_FORMAT] = "Illegal format ID", + }; + + static void __report_context_error(const char *fname, struct vrend_context *ctx, +@@ -8492,6 +8493,16 @@ void vrend_renderer_blit(struct vrend_context *ctx, + if (ctx->in_error) + return; + ++ if (!info->src.format || (enum virgl_formats)info->src.format >= VIRGL_FORMAT_MAX) { ++ report_context_error(ctx, VIRGL_ERROR_CTX_ILLEGAL_FORMAT, info->src.format); ++ return; ++ } ++ ++ if (!info->dst.format || (enum virgl_formats)info->dst.format >= VIRGL_FORMAT_MAX) { ++ report_context_error(ctx, VIRGL_ERROR_CTX_ILLEGAL_FORMAT, info->dst.format); ++ return; ++ } ++ + if (info->render_condition_enable == false) + vrend_pause_render_condition(ctx, true); + +-- +2.24.1 + diff --git a/meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2019-18391.patch b/meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2019-18391.patch new file mode 100644 index 0000000000..cc641d8293 --- /dev/null +++ b/meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2019-18391.patch @@ -0,0 +1,51 @@ +From 2abeb1802e3c005b17a7123e382171b3fb665971 Mon Sep 17 00:00:00 2001 +From: Gert Wollny +Date: Tue, 8 Oct 2019 17:27:01 +0200 +Subject: [PATCH] vrend: check that the transfer iov holds enough data for the + data upload + +Closes #140 + +Signed-off-by: Gert Wollny +Reviewed-by: Emil Velikov + +Upstream-Status: Backport +[https://gitlab.freedesktop.org/virgl/virglrenderer/commit/2abeb1802e3c005b17a7123e382171b3fb665971] +CVE: CVE-2019-18391 +Signed-off-by: Lee Chee Yang +--- + src/vrend_renderer.c | 11 +++++++++-- + 1 file changed, 9 insertions(+), 2 deletions(-) + +diff --git a/src/vrend_renderer.c b/src/vrend_renderer.c +index 694e1d0e..fe23846b 100644 +--- a/src/vrend_renderer.c ++++ b/src/vrend_renderer.c +@@ -7005,15 +7005,22 @@ static int vrend_renderer_transfer_write_iov(struct vrend_context *ctx, + invert = true; + } + ++ send_size = util_format_get_nblocks(res->base.format, info->box->width, ++ info->box->height) * elsize; ++ if (res->target == GL_TEXTURE_3D || ++ res->target == GL_TEXTURE_2D_ARRAY || ++ res->target == GL_TEXTURE_CUBE_MAP_ARRAY) ++ send_size *= info->box->depth; ++ + if (need_temp) { +- send_size = util_format_get_nblocks(res->base.format, info->box->width, +- info->box->height) * elsize * info->box->depth; + data = malloc(send_size); + if (!data) + return ENOMEM; + read_transfer_data(iov, num_iovs, data, res->base.format, info->offset, + stride, layer_stride, info->box, invert); + } else { ++ if (send_size > iov[0].iov_len - info->offset) ++ return EINVAL; + data = (char*)iov[0].iov_base + info->offset; + } + +-- +2.24.1 + diff --git a/meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2020-8002.patch b/meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2020-8002.patch new file mode 100644 index 0000000000..925f2c8eb0 --- /dev/null +++ b/meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2020-8002.patch @@ -0,0 +1,39 @@ +From 63bcca251f093d83da7e290ab4bbd38ae69089b5 Mon Sep 17 00:00:00 2001 +From: Gert Wollny +Date: Wed, 15 Jan 2020 13:43:58 +0100 +Subject: [PATCH] vrend: Don't try launching a grid if no CS is available + +Closes #155 + +Signed-off-by: Gert Wollny +Reviewed-by: Gurchetan Singh + +Upstream-Status: Backport +[https://gitlab.freedesktop.org/virgl/virglrenderer/-/commit/63bcca251f093d83da7e290ab4bbd38ae69089b5.patch] +CVE: CVE-2020-8002 +Signed-off-by: Lee Chee Yang +--- + src/vrend_renderer.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +diff --git a/src/vrend_renderer.c b/src/vrend_renderer.c +index a054bad8..2280fc43 100644 +--- a/src/vrend_renderer.c ++++ b/src/vrend_renderer.c +@@ -4604,6 +4604,13 @@ void vrend_launch_grid(struct vrend_context *ctx, + } + ctx->sub->shader_dirty = true; + } ++ ++ if (!ctx->sub->prog) { ++ vrend_printf("%s: Skipping compute shader execution due to missing shaders: %s\n", ++ __func__, ctx->debug_name); ++ return; ++ } ++ + vrend_use_program(ctx, ctx->sub->prog->id); + + vrend_draw_bind_ubo_shader(ctx, PIPE_SHADER_COMPUTE, 0); +-- +2.24.1 + diff --git a/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.0.bb b/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.0.bb index d2b11c103a..e91ccc6c57 100644 --- a/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.0.bb +++ b/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.0.bb @@ -8,6 +8,9 @@ DEPENDS = "libdrm mesa libepoxy" SRCREV = "48cc96c9aebb9d0164830a157efc8916f08f00c0" SRC_URI = "git://anongit.freedesktop.org/virglrenderer \ file://0001-gallium-Expand-libc-check-to-be-platform-OS-check.patch \ + file://CVE-2019-18390.patch \ + file://CVE-2019-18391.patch \ + file://CVE-2020-8002.patch \ " S = "${WORKDIR}/git" -- 2.17.1 From akuster808 at gmail.com Wed Mar 11 02:26:14 2020 From: akuster808 at gmail.com (Armin Kuster) Date: Tue, 10 Mar 2020 19:26:14 -0700 Subject: [OE-core] [zeus 13/16] maintainers: Add entry for buildtools-extended-tarball In-Reply-To: References: Message-ID: <1f903d76e50cb613e5cfe4f3eb00529b2443eb62.1583893499.git.akuster808@gmail.com> From: Richard Purdie Signed-off-by: Richard Purdie (cherry picked from commit 61d4d3d5a9f27e0fbf1d7ed6db818a779643b8f3) Signed-off-by: Armin Kuster --- meta/conf/distro/include/maintainers.inc | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/conf/distro/include/maintainers.inc b/meta/conf/distro/include/maintainers.inc index ab0c6c5541..7494873190 100644 --- a/meta/conf/distro/include/maintainers.inc +++ b/meta/conf/distro/include/maintainers.inc @@ -82,6 +82,7 @@ RECIPE_MAINTAINER_pn-build-appliance-image = "Richard Purdie References: Message-ID: From: Zhixiong Chi Backport the CVE patch from upstream: [https://sourceware.org/git/gitweb.cgi?p=glibc.git; a=patch;h=9333498794cde1d5cca518badf79533a24114b6f] Signed-off-by: Zhixiong Chi Signed-off-by: Armin Kuster --- .../glibc/glibc/CVE-2020-10029.patch | 128 ++++++++++++++++++ meta/recipes-core/glibc/glibc_2.30.bb | 1 + 2 files changed, 129 insertions(+) create mode 100644 meta/recipes-core/glibc/glibc/CVE-2020-10029.patch diff --git a/meta/recipes-core/glibc/glibc/CVE-2020-10029.patch b/meta/recipes-core/glibc/glibc/CVE-2020-10029.patch new file mode 100644 index 0000000000..606b691bcf --- /dev/null +++ b/meta/recipes-core/glibc/glibc/CVE-2020-10029.patch @@ -0,0 +1,128 @@ +From ce265ec5bc25ec35fba53807abac1b0c8469895e Mon Sep 17 00:00:00 2001 +From: Joseph Myers +Date: Wed, 12 Feb 2020 23:31:56 +0000 +Subject: [PATCH] Avoid ldbl-96 stack corruption from range reduction of + + pseudo-zero (bug 25487). + +Bug 25487 reports stack corruption in ldbl-96 sinl on a pseudo-zero +argument (an representation where all the significand bits, including +the explicit high bit, are zero, but the exponent is not zero, which +is not a valid representation for the long double type). + +Although this is not a valid long double representation, existing +practice in this area (see bug 4586, originally marked invalid but +subsequently fixed) is that we still seek to avoid invalid memory +accesses as a result, in case of programs that treat arbitrary binary +data as long double representations, although the invalid +representations of the ldbl-96 format do not need to be consistently +handled the same as any particular valid representation. + +This patch makes the range reduction detect pseudo-zero and unnormal +representations that would otherwise go to __kernel_rem_pio2, and +returns a NaN for them instead of continuing with the range reduction +process. (Pseudo-zero and unnormal representations whose unbiased +exponent is less than -1 have already been safely returned from the +function before this point without going through the rest of range +reduction.) Pseudo-zero representations would previously result in +the value passed to __kernel_rem_pio2 being all-zero, which is +definitely unsafe; unnormal representations would previously result in +a value passed whose high bit is zero, which might well be unsafe +since that is not a form of input expected by __kernel_rem_pio2. + +Tested for x86_64. + +CVE: CVE-2020-10029 +Upstream-Status: Backport [https://sourceware.org/git/gitweb.cgi?p=glibc.git; +a=patch;h=9333498794cde1d5cca518badf79533a24114b6f] +Signed-off-by: Zhixiong Chi + +--- + sysdeps/ieee754/ldbl-96/Makefile | 3 ++- + sysdeps/ieee754/ldbl-96/e_rem_pio2l.c | 12 +++++++++ + sysdeps/ieee754/ldbl-96/test-sinl-pseudo.c | 41 ++++++++++++++++++++++++++++++ + 3 files changed, 55 insertions(+), 1 deletion(-) + create mode 100644 sysdeps/ieee754/ldbl-96/test-sinl-pseudo.c + +diff --git a/sysdeps/ieee754/ldbl-96/Makefile b/sysdeps/ieee754/ldbl-96/Makefile +index b103254..052c1c7 100644 +--- a/sysdeps/ieee754/ldbl-96/Makefile ++++ b/sysdeps/ieee754/ldbl-96/Makefile +@@ -17,5 +17,6 @@ + # . + + ifeq ($(subdir),math) +-tests += test-canonical-ldbl-96 test-totalorderl-ldbl-96 ++tests += test-canonical-ldbl-96 test-totalorderl-ldbl-96 test-sinl-pseudo ++CFLAGS-test-sinl-pseudo.c += -fstack-protector-all + endif +diff --git a/sysdeps/ieee754/ldbl-96/e_rem_pio2l.c b/sysdeps/ieee754/ldbl-96/e_rem_pio2l.c +index 805de22..1aeccb4 100644 +--- a/sysdeps/ieee754/ldbl-96/e_rem_pio2l.c ++++ b/sysdeps/ieee754/ldbl-96/e_rem_pio2l.c +@@ -210,6 +210,18 @@ __ieee754_rem_pio2l (long double x, long double *y) + return 0; + } + ++ if ((i0 & 0x80000000) == 0) ++ { ++ /* Pseudo-zero and unnormal representations are not valid ++ representations of long double. We need to avoid stack ++ corruption in __kernel_rem_pio2, which expects input in a ++ particular normal form, but those representations do not need ++ to be consistently handled like any particular floating-point ++ value. */ ++ y[1] = y[0] = __builtin_nanl (""); ++ return 0; ++ } ++ + /* Split the 64 bits of the mantissa into three 24-bit integers + stored in a double array. */ + exp = j0 - 23; +diff --git a/sysdeps/ieee754/ldbl-96/test-sinl-pseudo.c b/sysdeps/ieee754/ldbl-96/test-sinl-pseudo.c +new file mode 100644 +index 0000000..f59b977 +--- /dev/null ++++ b/sysdeps/ieee754/ldbl-96/test-sinl-pseudo.c +@@ -0,0 +1,41 @@ ++/* Test sinl for pseudo-zeros and unnormals for ldbl-96 (bug 25487). ++ Copyright (C) 2020 Free Software Foundation, Inc. ++ This file is part of the GNU C Library. ++ ++ The GNU C Library is free software; you can redistribute it and/or ++ modify it under the terms of the GNU Lesser General Public ++ License as published by the Free Software Foundation; either ++ version 2.1 of the License, or (at your option) any later version. ++ ++ The GNU C Library is distributed in the hope that it will be useful, ++ but WITHOUT ANY WARRANTY; without even the implied warranty of ++ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU ++ Lesser General Public License for more details. ++ ++ You should have received a copy of the GNU Lesser General Public ++ License along with the GNU C Library; if not, see ++ . */ ++ ++#include ++#include ++#include ++ ++static int ++do_test (void) ++{ ++ for (int i = 0; i < 64; i++) ++ { ++ uint64_t sig = i == 63 ? 0 : 1ULL << i; ++ long double ld; ++ SET_LDOUBLE_WORDS (ld, 0x4141, ++ sig >> 32, sig & 0xffffffffULL); ++ /* The requirement is that no stack overflow occurs when the ++ pseudo-zero or unnormal goes through range reduction. */ ++ volatile long double ldr; ++ ldr = sinl (ld); ++ (void) ldr; ++ } ++ return 0; ++} ++ ++#include diff --git a/meta/recipes-core/glibc/glibc_2.30.bb b/meta/recipes-core/glibc/glibc_2.30.bb index 7913bc2812..c9e44a396d 100644 --- a/meta/recipes-core/glibc/glibc_2.30.bb +++ b/meta/recipes-core/glibc/glibc_2.30.bb @@ -42,6 +42,7 @@ SRC_URI = "${GLIBC_GIT_URI};branch=${SRCBRANCH};name=glibc \ file://0027-inject-file-assembly-directives.patch \ file://0028-locale-prevent-maybe-uninitialized-errors-with-Os-BZ.patch \ file://CVE-2019-19126.patch \ + file://CVE-2020-10029.patch \ " S = "${WORKDIR}/git" B = "${WORKDIR}/build-${TARGET_SYS}" -- 2.17.1 From akuster808 at gmail.com Wed Mar 11 02:26:16 2020 From: akuster808 at gmail.com (Armin Kuster) Date: Tue, 10 Mar 2020 19:26:16 -0700 Subject: [OE-core] [zeus 15/16] cve-check: show whitelisted status In-Reply-To: References: Message-ID: From: Chee Yang Lee change whitelisted CVE status from "Patched" to "Whitelisted". [Yocto #13687] Signed-off-by: Chee Yang Lee Signed-off-by: Richard Purdie (cherry picked from commit 181bdd670492525f9488d52c3ebb9a1b142e35ea) Signed-off-by: Armin Kuster --- meta/classes/cve-check.bbclass | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass index 74124364b2..7f98da60f1 100644 --- a/meta/classes/cve-check.bbclass +++ b/meta/classes/cve-check.bbclass @@ -56,10 +56,10 @@ python do_cve_check () { patched_cves = get_patches_cves(d) except FileNotFoundError: bb.fatal("Failure in searching patches") - patched, unpatched = check_cves(d, patched_cves) + whitelisted, patched, unpatched = check_cves(d, patched_cves) if patched or unpatched: cve_data = get_cve_info(d, patched + unpatched) - cve_write_data(d, patched, unpatched, cve_data) + cve_write_data(d, patched, unpatched, whitelisted, cve_data) else: bb.note("No CVE database found, skipping CVE check") @@ -263,7 +263,7 @@ def check_cves(d, patched_cves): conn.close() - return (list(patched_cves), cves_unpatched) + return (list(cve_whitelist), list(patched_cves), cves_unpatched) def get_cve_info(d, cves): """ @@ -287,7 +287,7 @@ def get_cve_info(d, cves): conn.close() return cve_data -def cve_write_data(d, patched, unpatched, cve_data): +def cve_write_data(d, patched, unpatched, whitelisted, cve_data): """ Write CVE information in WORKDIR; and to CVE_CHECK_DIR, and CVE manifest if enabled. @@ -303,7 +303,9 @@ def cve_write_data(d, patched, unpatched, cve_data): write_string += "PACKAGE NAME: %s\n" % d.getVar("PN") write_string += "PACKAGE VERSION: %s\n" % d.getVar("PV") write_string += "CVE: %s\n" % cve - if cve in patched: + if cve in whitelisted: + write_string += "CVE STATUS: Whitelisted\n" + elif cve in patched: write_string += "CVE STATUS: Patched\n" else: unpatched_cves.append(cve) -- 2.17.1 From akuster808 at gmail.com Wed Mar 11 02:26:17 2020 From: akuster808 at gmail.com (Armin Kuster) Date: Tue, 10 Mar 2020 19:26:17 -0700 Subject: [OE-core] [zeus 16/16] cve-check: fix ValueError In-Reply-To: References: Message-ID: <2ccf28a773fb1416ecd9b10f98b59a6d34beffd8.1583893499.git.akuster808@gmail.com> From: Chee Yang Lee fix below error for whitelisted recipe and recipe skip cve check. Error: The stack trace of python calls that resulted in this exception/failure was: File: 'exec_python_func() autogenerated', lineno: 2, function: 0001: *** 0002:do_cve_check(d) 0003: File: '/poky-master/meta/classes/cve-check.bbclass', lineno: 59, function: do_cve_check 0055: try: 0056: patched_cves = get_patches_cves(d) 0057: except FileNotFoundError: 0058: bb.fatal("Failure in searching patches") *** 0059: whitelisted, patched, unpatched = check_cves(d, patched_cves) 0060: if patched or unpatched: 0061: cve_data = get_cve_info(d, patched + unpatched) 0062: cve_write_data(d, patched, unpatched, whitelisted, cve_data) 0063: else: Exception: ValueError: not enough values to unpack (expected 3, got 2) Signed-off-by: Chee Yang Lee Signed-off-by: Richard Purdie (cherry picked from commit 64a362bd2dd0b4f3165d5162adbc600826af66f8) Signed-off-by: Armin Kuster --- meta/classes/cve-check.bbclass | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass index 7f98da60f1..5d84b93d71 100644 --- a/meta/classes/cve-check.bbclass +++ b/meta/classes/cve-check.bbclass @@ -179,13 +179,13 @@ def check_cves(d, patched_cves): products = d.getVar("CVE_PRODUCT").split() # If this has been unset then we're not scanning for CVEs here (for example, image recipes) if not products: - return ([], []) + return ([], [], []) pv = d.getVar("CVE_VERSION").split("+git")[0] # If the recipe has been whitlisted we return empty lists if d.getVar("PN") in d.getVar("CVE_CHECK_PN_WHITELIST").split(): bb.note("Recipe has been whitelisted, skipping check") - return ([], []) + return ([], [], []) old_cve_whitelist = d.getVar("CVE_CHECK_CVE_WHITELIST") if old_cve_whitelist: -- 2.17.1 From yi.zhao at windriver.com Wed Mar 11 03:38:19 2020 From: yi.zhao at windriver.com (Yi Zhao) Date: Wed, 11 Mar 2020 11:38:19 +0800 Subject: [OE-core] [PATCH] nfs-utils: fix do_package error when enable PACKAGECONFIG[nfsv4] Message-ID: <20200311033819.15438-1-yi.zhao@windriver.com> Fixes: ERROR: nfs-utils-2.4.3-r0 do_package: QA Issue: nfs-utils: Files/directories were installed but not shipped in any package: /usr/lib/libnfsidmap/nsswitch.so /usr/lib/libnfsidmap/static.so Please set FILES such that these items are packaged. Alternatively if they are unneeded, avoid installing them or delete them within do_install. nfs-utils: 2 installed and not shipped files. [installed-vs-shipped] Signed-off-by: Yi Zhao --- meta/recipes-connectivity/nfs-utils/nfs-utils_2.4.3.bb | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/meta/recipes-connectivity/nfs-utils/nfs-utils_2.4.3.bb b/meta/recipes-connectivity/nfs-utils/nfs-utils_2.4.3.bb index 42a4ba3dbd..9bdb6f4ae4 100644 --- a/meta/recipes-connectivity/nfs-utils/nfs-utils_2.4.3.bb +++ b/meta/recipes-connectivity/nfs-utils/nfs-utils_2.4.3.bb @@ -67,9 +67,9 @@ PACKAGECONFIG_remove_libc-musl = "tcp-wrappers" PACKAGECONFIG[tcp-wrappers] = "--with-tcp-wrappers,--without-tcp-wrappers,tcp-wrappers" PACKAGECONFIG[ipv6] = "--enable-ipv6,--disable-ipv6," # libdevmapper is available in meta-oe -PACKAGECONFIG[nfsv41] = "--enable-nfsv41,--disable-nfsv41,libdevmapper" -# keyutils is available in meta-security -PACKAGECONFIG[nfsv4] = "--enable-nfsv4,--disable-nfsv4,keyutils" +PACKAGECONFIG[nfsv41] = "--enable-nfsv41,--disable-nfsv41,libdevmapper,libdevmapper" +# keyutils is available in meta-oe +PACKAGECONFIG[nfsv4] = "--enable-nfsv4,--disable-nfsv4,keyutils,python3-core" PACKAGES =+ "${PN}-client ${PN}-mount ${PN}-stats" @@ -94,7 +94,9 @@ FILES_${PN}-mount = "${base_sbindir}/*mount.nfs*" FILES_${PN}-stats = "${sbindir}/mountstats ${sbindir}/nfsiostat" RDEPENDS_${PN}-stats = "python3-core" -FILES_${PN} += "${systemd_unitdir}" +FILES_${PN}-staticdev += "${libdir}/libnfsidmap/*.a" + +FILES_${PN} += "${systemd_unitdir} ${libdir}/libnfsidmap/" do_configure_prepend() { sed -i -e 's,sbindir = /sbin,sbindir = ${base_sbindir},g' \ -- 2.17.1 From zangrc.fnst at cn.fujitsu.com Wed Mar 11 06:04:06 2020 From: zangrc.fnst at cn.fujitsu.com (zangrc) Date: Wed, 11 Mar 2020 14:04:06 +0800 Subject: [OE-core] CVE related consulting on linux-yocto on zeus branch Message-ID: Hello, our team is currently working on CVE-related work. I would like to ask if the zeus branch of yocto has an update plan for linux-yocto in the near future. If not, can we submit a CVE-related patch for the linux-yocto of the zeus branch. ?-- Best Regards! Zang Ruochen From chee.yang.lee at intel.com Wed Mar 11 06:47:35 2020 From: chee.yang.lee at intel.com (chee.yang.lee at intel.com) Date: Wed, 11 Mar 2020 14:47:35 +0800 Subject: [OE-core] [PATCH][zeus 1/2] qemu: fix CVE-2019-20382 Message-ID: <1583909256-28697-1-git-send-email-chee.yang.lee@intel.com> From: Lee Chee Yang Signed-off-by: Lee Chee Yang --- meta/recipes-devtools/qemu/qemu.inc | 1 + .../qemu/qemu/CVE-2019-20382.patch | 1018 ++++++++++++++++++++ 2 files changed, 1019 insertions(+) create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2019-20382.patch diff --git a/meta/recipes-devtools/qemu/qemu.inc b/meta/recipes-devtools/qemu/qemu.inc index d394db8..f451017 100644 --- a/meta/recipes-devtools/qemu/qemu.inc +++ b/meta/recipes-devtools/qemu/qemu.inc @@ -30,6 +30,7 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \ file://CVE-2019-15890.patch \ file://CVE-2019-12068.patch \ file://CVE-2020-1711.patch \ + file://CVE-2019-20382.patch \ " UPSTREAM_CHECK_REGEX = "qemu-(?P\d+(\.\d+)+)\.tar" diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2019-20382.patch b/meta/recipes-devtools/qemu/qemu/CVE-2019-20382.patch new file mode 100644 index 0000000..183d100 --- /dev/null +++ b/meta/recipes-devtools/qemu/qemu/CVE-2019-20382.patch @@ -0,0 +1,1018 @@ +From 6bf21f3d83e95bcc4ba35a7a07cc6655e8b010b0 Mon Sep 17 00:00:00 2001 +From: Li Qiang +Date: Sat, 31 Aug 2019 08:39:22 -0700 +Subject: [PATCH] vnc: fix memory leak when vnc disconnect + +Currently when qemu receives a vnc connect, it creates a 'VncState' to +represent this connection. In 'vnc_worker_thread_loop' it creates a +local 'VncState'. The connection 'VcnState' and local 'VncState' exchange +data in 'vnc_async_encoding_start' and 'vnc_async_encoding_end'. +In 'zrle_compress_data' it calls 'deflateInit2' to allocate the libz library +opaque data. The 'VncState' used in 'zrle_compress_data' is the local +'VncState'. In 'vnc_zrle_clear' it calls 'deflateEnd' to free the libz +library opaque data. The 'VncState' used in 'vnc_zrle_clear' is the connection +'VncState'. In currently implementation there will be a memory leak when the +vnc disconnect. Following is the asan output backtrack: + +Direct leak of 29760 byte(s) in 5 object(s) allocated from: + 0 0xffffa67ef3c3 in __interceptor_calloc (/lib64/libasan.so.4+0xd33c3) + 1 0xffffa65071cb in g_malloc0 (/lib64/libglib-2.0.so.0+0x571cb) + 2 0xffffa5e968f7 in deflateInit2_ (/lib64/libz.so.1+0x78f7) + 3 0xaaaacec58613 in zrle_compress_data ui/vnc-enc-zrle.c:87 + 4 0xaaaacec58613 in zrle_send_framebuffer_update ui/vnc-enc-zrle.c:344 + 5 0xaaaacec34e77 in vnc_send_framebuffer_update ui/vnc.c:919 + 6 0xaaaacec5e023 in vnc_worker_thread_loop ui/vnc-jobs.c:271 + 7 0xaaaacec5e5e7 in vnc_worker_thread ui/vnc-jobs.c:340 + 8 0xaaaacee4d3c3 in qemu_thread_start util/qemu-thread-posix.c:502 + 9 0xffffa544e8bb in start_thread (/lib64/libpthread.so.0+0x78bb) + 10 0xffffa53965cb in thread_start (/lib64/libc.so.6+0xd55cb) + +This is because the opaque allocated in 'deflateInit2' is not freed in +'deflateEnd'. The reason is that the 'deflateEnd' calls 'deflateStateCheck' +and in the latter will check whether 's->strm != strm'(libz's data structure). +This check will be true so in 'deflateEnd' it just return 'Z_STREAM_ERROR' and +not free the data allocated in 'deflateInit2'. + +The reason this happens is that the 'VncState' contains the whole 'VncZrle', +so when calling 'deflateInit2', the 's->strm' will be the local address. +So 's->strm != strm' will be true. + +To fix this issue, we need to make 'zrle' of 'VncState' to be a pointer. +Then the connection 'VncState' and local 'VncState' exchange mechanism will +work as expection. The 'tight' of 'VncState' has the same issue, let's also turn +it to a pointer. + +Reported-by: Ying Fang +Signed-off-by: Li Qiang +Message-id: 20190831153922.121308-1-liq3ea at 163.com +Signed-off-by: Gerd Hoffmann + +Upstream-Status: Backport [https://git.qemu.org/?p=qemu.git;a=commit;h=6bf21f3d83e95bcc4ba35a7a07cc6655e8b010b0] +CVE: CVE-2019-20382 +Signed-off-by: Lee Chee Yang + +--- + ui/vnc-enc-tight.c | 219 +++++++++++++++++++++++++------------------------- + ui/vnc-enc-zlib.c | 11 +-- + ui/vnc-enc-zrle.c | 68 ++++++++-------- + ui/vnc-enc-zrle.inc.c | 2 +- + ui/vnc.c | 28 ++++--- + ui/vnc.h | 4 +- + 6 files changed, 170 insertions(+), 162 deletions(-) + +diff --git a/ui/vnc-enc-tight.c b/ui/vnc-enc-tight.c +index 9084c22..1e08518 100644 +--- a/ui/vnc-enc-tight.c ++++ b/ui/vnc-enc-tight.c +@@ -116,7 +116,7 @@ static int send_png_rect(VncState *vs, int x, int y, int w, int h, + + static bool tight_can_send_png_rect(VncState *vs, int w, int h) + { +- if (vs->tight.type != VNC_ENCODING_TIGHT_PNG) { ++ if (vs->tight->type != VNC_ENCODING_TIGHT_PNG) { + return false; + } + +@@ -144,7 +144,7 @@ tight_detect_smooth_image24(VncState *vs, int w, int h) + int pixels = 0; + int pix, left[3]; + unsigned int errors; +- unsigned char *buf = vs->tight.tight.buffer; ++ unsigned char *buf = vs->tight->tight.buffer; + + /* + * If client is big-endian, color samples begin from the second +@@ -215,7 +215,7 @@ tight_detect_smooth_image24(VncState *vs, int w, int h) + int pixels = 0; \ + int sample, sum, left[3]; \ + unsigned int errors; \ +- unsigned char *buf = vs->tight.tight.buffer; \ ++ unsigned char *buf = vs->tight->tight.buffer; \ + \ + endian = 0; /* FIXME */ \ + \ +@@ -296,8 +296,8 @@ static int + tight_detect_smooth_image(VncState *vs, int w, int h) + { + unsigned int errors; +- int compression = vs->tight.compression; +- int quality = vs->tight.quality; ++ int compression = vs->tight->compression; ++ int quality = vs->tight->quality; + + if (!vs->vd->lossy) { + return 0; +@@ -309,7 +309,7 @@ tight_detect_smooth_image(VncState *vs, int w, int h) + return 0; + } + +- if (vs->tight.quality != (uint8_t)-1) { ++ if (vs->tight->quality != (uint8_t)-1) { + if (w * h < VNC_TIGHT_JPEG_MIN_RECT_SIZE) { + return 0; + } +@@ -320,9 +320,9 @@ tight_detect_smooth_image(VncState *vs, int w, int h) + } + + if (vs->client_pf.bytes_per_pixel == 4) { +- if (vs->tight.pixel24) { ++ if (vs->tight->pixel24) { + errors = tight_detect_smooth_image24(vs, w, h); +- if (vs->tight.quality != (uint8_t)-1) { ++ if (vs->tight->quality != (uint8_t)-1) { + return (errors < tight_conf[quality].jpeg_threshold24); + } + return (errors < tight_conf[compression].gradient_threshold24); +@@ -352,7 +352,7 @@ tight_detect_smooth_image(VncState *vs, int w, int h) + uint##bpp##_t c0, c1, ci; \ + int i, n0, n1; \ + \ +- data = (uint##bpp##_t *)vs->tight.tight.buffer; \ ++ data = (uint##bpp##_t *)vs->tight->tight.buffer; \ + \ + c0 = data[0]; \ + i = 1; \ +@@ -423,9 +423,9 @@ static int tight_fill_palette(VncState *vs, int x, int y, + { + int max; + +- max = count / tight_conf[vs->tight.compression].idx_max_colors_divisor; ++ max = count / tight_conf[vs->tight->compression].idx_max_colors_divisor; + if (max < 2 && +- count >= tight_conf[vs->tight.compression].mono_min_rect_size) { ++ count >= tight_conf[vs->tight->compression].mono_min_rect_size) { + max = 2; + } + if (max >= 256) { +@@ -558,7 +558,7 @@ tight_filter_gradient24(VncState *vs, uint8_t *buf, int w, int h) + int x, y, c; + + buf32 = (uint32_t *)buf; +- memset(vs->tight.gradient.buffer, 0, w * 3 * sizeof(int)); ++ memset(vs->tight->gradient.buffer, 0, w * 3 * sizeof(int)); + + if (1 /* FIXME */) { + shift[0] = vs->client_pf.rshift; +@@ -575,7 +575,7 @@ tight_filter_gradient24(VncState *vs, uint8_t *buf, int w, int h) + upper[c] = 0; + here[c] = 0; + } +- prev = (int *)vs->tight.gradient.buffer; ++ prev = (int *)vs->tight->gradient.buffer; + for (x = 0; x < w; x++) { + pix32 = *buf32++; + for (c = 0; c < 3; c++) { +@@ -615,7 +615,7 @@ tight_filter_gradient24(VncState *vs, uint8_t *buf, int w, int h) + int prediction; \ + int x, y, c; \ + \ +- memset (vs->tight.gradient.buffer, 0, w * 3 * sizeof(int)); \ ++ memset(vs->tight->gradient.buffer, 0, w * 3 * sizeof(int)); \ + \ + endian = 0; /* FIXME */ \ + \ +@@ -631,7 +631,7 @@ tight_filter_gradient24(VncState *vs, uint8_t *buf, int w, int h) + upper[c] = 0; \ + here[c] = 0; \ + } \ +- prev = (int *)vs->tight.gradient.buffer; \ ++ prev = (int *)vs->tight->gradient.buffer; \ + for (x = 0; x < w; x++) { \ + pix = *buf; \ + if (endian) { \ +@@ -785,7 +785,7 @@ static void extend_solid_area(VncState *vs, int x, int y, int w, int h, + static int tight_init_stream(VncState *vs, int stream_id, + int level, int strategy) + { +- z_streamp zstream = &vs->tight.stream[stream_id]; ++ z_streamp zstream = &vs->tight->stream[stream_id]; + + if (zstream->opaque == NULL) { + int err; +@@ -803,15 +803,15 @@ static int tight_init_stream(VncState *vs, int stream_id, + return -1; + } + +- vs->tight.levels[stream_id] = level; ++ vs->tight->levels[stream_id] = level; + zstream->opaque = vs; + } + +- if (vs->tight.levels[stream_id] != level) { ++ if (vs->tight->levels[stream_id] != level) { + if (deflateParams(zstream, level, strategy) != Z_OK) { + return -1; + } +- vs->tight.levels[stream_id] = level; ++ vs->tight->levels[stream_id] = level; + } + return 0; + } +@@ -839,11 +839,11 @@ static void tight_send_compact_size(VncState *vs, size_t len) + static int tight_compress_data(VncState *vs, int stream_id, size_t bytes, + int level, int strategy) + { +- z_streamp zstream = &vs->tight.stream[stream_id]; ++ z_streamp zstream = &vs->tight->stream[stream_id]; + int previous_out; + + if (bytes < VNC_TIGHT_MIN_TO_COMPRESS) { +- vnc_write(vs, vs->tight.tight.buffer, vs->tight.tight.offset); ++ vnc_write(vs, vs->tight->tight.buffer, vs->tight->tight.offset); + return bytes; + } + +@@ -852,13 +852,13 @@ static int tight_compress_data(VncState *vs, int stream_id, size_t bytes, + } + + /* reserve memory in output buffer */ +- buffer_reserve(&vs->tight.zlib, bytes + 64); ++ buffer_reserve(&vs->tight->zlib, bytes + 64); + + /* set pointers */ +- zstream->next_in = vs->tight.tight.buffer; +- zstream->avail_in = vs->tight.tight.offset; +- zstream->next_out = vs->tight.zlib.buffer + vs->tight.zlib.offset; +- zstream->avail_out = vs->tight.zlib.capacity - vs->tight.zlib.offset; ++ zstream->next_in = vs->tight->tight.buffer; ++ zstream->avail_in = vs->tight->tight.offset; ++ zstream->next_out = vs->tight->zlib.buffer + vs->tight->zlib.offset; ++ zstream->avail_out = vs->tight->zlib.capacity - vs->tight->zlib.offset; + previous_out = zstream->avail_out; + zstream->data_type = Z_BINARY; + +@@ -868,14 +868,14 @@ static int tight_compress_data(VncState *vs, int stream_id, size_t bytes, + return -1; + } + +- vs->tight.zlib.offset = vs->tight.zlib.capacity - zstream->avail_out; ++ vs->tight->zlib.offset = vs->tight->zlib.capacity - zstream->avail_out; + /* ...how much data has actually been produced by deflate() */ + bytes = previous_out - zstream->avail_out; + + tight_send_compact_size(vs, bytes); +- vnc_write(vs, vs->tight.zlib.buffer, bytes); ++ vnc_write(vs, vs->tight->zlib.buffer, bytes); + +- buffer_reset(&vs->tight.zlib); ++ buffer_reset(&vs->tight->zlib); + + return bytes; + } +@@ -927,16 +927,17 @@ static int send_full_color_rect(VncState *vs, int x, int y, int w, int h) + + vnc_write_u8(vs, stream << 4); /* no flushing, no filter */ + +- if (vs->tight.pixel24) { +- tight_pack24(vs, vs->tight.tight.buffer, w * h, &vs->tight.tight.offset); ++ if (vs->tight->pixel24) { ++ tight_pack24(vs, vs->tight->tight.buffer, w * h, ++ &vs->tight->tight.offset); + bytes = 3; + } else { + bytes = vs->client_pf.bytes_per_pixel; + } + + bytes = tight_compress_data(vs, stream, w * h * bytes, +- tight_conf[vs->tight.compression].raw_zlib_level, +- Z_DEFAULT_STRATEGY); ++ tight_conf[vs->tight->compression].raw_zlib_level, ++ Z_DEFAULT_STRATEGY); + + return (bytes >= 0); + } +@@ -947,14 +948,14 @@ static int send_solid_rect(VncState *vs) + + vnc_write_u8(vs, VNC_TIGHT_FILL << 4); /* no flushing, no filter */ + +- if (vs->tight.pixel24) { +- tight_pack24(vs, vs->tight.tight.buffer, 1, &vs->tight.tight.offset); ++ if (vs->tight->pixel24) { ++ tight_pack24(vs, vs->tight->tight.buffer, 1, &vs->tight->tight.offset); + bytes = 3; + } else { + bytes = vs->client_pf.bytes_per_pixel; + } + +- vnc_write(vs, vs->tight.tight.buffer, bytes); ++ vnc_write(vs, vs->tight->tight.buffer, bytes); + return 1; + } + +@@ -963,7 +964,7 @@ static int send_mono_rect(VncState *vs, int x, int y, + { + ssize_t bytes; + int stream = 1; +- int level = tight_conf[vs->tight.compression].mono_zlib_level; ++ int level = tight_conf[vs->tight->compression].mono_zlib_level; + + #ifdef CONFIG_VNC_PNG + if (tight_can_send_png_rect(vs, w, h)) { +@@ -991,26 +992,26 @@ static int send_mono_rect(VncState *vs, int x, int y, + uint32_t buf[2] = {bg, fg}; + size_t ret = sizeof (buf); + +- if (vs->tight.pixel24) { ++ if (vs->tight->pixel24) { + tight_pack24(vs, (unsigned char*)buf, 2, &ret); + } + vnc_write(vs, buf, ret); + +- tight_encode_mono_rect32(vs->tight.tight.buffer, w, h, bg, fg); ++ tight_encode_mono_rect32(vs->tight->tight.buffer, w, h, bg, fg); + break; + } + case 2: + vnc_write(vs, &bg, 2); + vnc_write(vs, &fg, 2); +- tight_encode_mono_rect16(vs->tight.tight.buffer, w, h, bg, fg); ++ tight_encode_mono_rect16(vs->tight->tight.buffer, w, h, bg, fg); + break; + default: + vnc_write_u8(vs, bg); + vnc_write_u8(vs, fg); +- tight_encode_mono_rect8(vs->tight.tight.buffer, w, h, bg, fg); ++ tight_encode_mono_rect8(vs->tight->tight.buffer, w, h, bg, fg); + break; + } +- vs->tight.tight.offset = bytes; ++ vs->tight->tight.offset = bytes; + + bytes = tight_compress_data(vs, stream, bytes, level, Z_DEFAULT_STRATEGY); + return (bytes >= 0); +@@ -1040,7 +1041,7 @@ static void write_palette(int idx, uint32_t color, void *opaque) + static bool send_gradient_rect(VncState *vs, int x, int y, int w, int h) + { + int stream = 3; +- int level = tight_conf[vs->tight.compression].gradient_zlib_level; ++ int level = tight_conf[vs->tight->compression].gradient_zlib_level; + ssize_t bytes; + + if (vs->client_pf.bytes_per_pixel == 1) { +@@ -1050,23 +1051,23 @@ static bool send_gradient_rect(VncState *vs, int x, int y, int w, int h) + vnc_write_u8(vs, (stream | VNC_TIGHT_EXPLICIT_FILTER) << 4); + vnc_write_u8(vs, VNC_TIGHT_FILTER_GRADIENT); + +- buffer_reserve(&vs->tight.gradient, w * 3 * sizeof (int)); ++ buffer_reserve(&vs->tight->gradient, w * 3 * sizeof(int)); + +- if (vs->tight.pixel24) { +- tight_filter_gradient24(vs, vs->tight.tight.buffer, w, h); ++ if (vs->tight->pixel24) { ++ tight_filter_gradient24(vs, vs->tight->tight.buffer, w, h); + bytes = 3; + } else if (vs->client_pf.bytes_per_pixel == 4) { +- tight_filter_gradient32(vs, (uint32_t *)vs->tight.tight.buffer, w, h); ++ tight_filter_gradient32(vs, (uint32_t *)vs->tight->tight.buffer, w, h); + bytes = 4; + } else { +- tight_filter_gradient16(vs, (uint16_t *)vs->tight.tight.buffer, w, h); ++ tight_filter_gradient16(vs, (uint16_t *)vs->tight->tight.buffer, w, h); + bytes = 2; + } + +- buffer_reset(&vs->tight.gradient); ++ buffer_reset(&vs->tight->gradient); + + bytes = w * h * bytes; +- vs->tight.tight.offset = bytes; ++ vs->tight->tight.offset = bytes; + + bytes = tight_compress_data(vs, stream, bytes, + level, Z_FILTERED); +@@ -1077,7 +1078,7 @@ static int send_palette_rect(VncState *vs, int x, int y, + int w, int h, VncPalette *palette) + { + int stream = 2; +- int level = tight_conf[vs->tight.compression].idx_zlib_level; ++ int level = tight_conf[vs->tight->compression].idx_zlib_level; + int colors; + ssize_t bytes; + +@@ -1104,12 +1105,12 @@ static int send_palette_rect(VncState *vs, int x, int y, + palette_iter(palette, write_palette, &priv); + vnc_write(vs, header, sizeof(header)); + +- if (vs->tight.pixel24) { ++ if (vs->tight->pixel24) { + tight_pack24(vs, vs->output.buffer + old_offset, colors, &offset); + vs->output.offset = old_offset + offset; + } + +- tight_encode_indexed_rect32(vs->tight.tight.buffer, w * h, palette); ++ tight_encode_indexed_rect32(vs->tight->tight.buffer, w * h, palette); + break; + } + case 2: +@@ -1119,7 +1120,7 @@ static int send_palette_rect(VncState *vs, int x, int y, + + palette_iter(palette, write_palette, &priv); + vnc_write(vs, header, sizeof(header)); +- tight_encode_indexed_rect16(vs->tight.tight.buffer, w * h, palette); ++ tight_encode_indexed_rect16(vs->tight->tight.buffer, w * h, palette); + break; + } + default: +@@ -1127,7 +1128,7 @@ static int send_palette_rect(VncState *vs, int x, int y, + break; + } + bytes = w * h; +- vs->tight.tight.offset = bytes; ++ vs->tight->tight.offset = bytes; + + bytes = tight_compress_data(vs, stream, bytes, + level, Z_DEFAULT_STRATEGY); +@@ -1146,7 +1147,7 @@ static int send_palette_rect(VncState *vs, int x, int y, + static void jpeg_init_destination(j_compress_ptr cinfo) + { + VncState *vs = cinfo->client_data; +- Buffer *buffer = &vs->tight.jpeg; ++ Buffer *buffer = &vs->tight->jpeg; + + cinfo->dest->next_output_byte = (JOCTET *)buffer->buffer + buffer->offset; + cinfo->dest->free_in_buffer = (size_t)(buffer->capacity - buffer->offset); +@@ -1156,7 +1157,7 @@ static void jpeg_init_destination(j_compress_ptr cinfo) + static boolean jpeg_empty_output_buffer(j_compress_ptr cinfo) + { + VncState *vs = cinfo->client_data; +- Buffer *buffer = &vs->tight.jpeg; ++ Buffer *buffer = &vs->tight->jpeg; + + buffer->offset = buffer->capacity; + buffer_reserve(buffer, 2048); +@@ -1168,7 +1169,7 @@ static boolean jpeg_empty_output_buffer(j_compress_ptr cinfo) + static void jpeg_term_destination(j_compress_ptr cinfo) + { + VncState *vs = cinfo->client_data; +- Buffer *buffer = &vs->tight.jpeg; ++ Buffer *buffer = &vs->tight->jpeg; + + buffer->offset = buffer->capacity - cinfo->dest->free_in_buffer; + } +@@ -1187,7 +1188,7 @@ static int send_jpeg_rect(VncState *vs, int x, int y, int w, int h, int quality) + return send_full_color_rect(vs, x, y, w, h); + } + +- buffer_reserve(&vs->tight.jpeg, 2048); ++ buffer_reserve(&vs->tight->jpeg, 2048); + + cinfo.err = jpeg_std_error(&jerr); + jpeg_create_compress(&cinfo); +@@ -1222,9 +1223,9 @@ static int send_jpeg_rect(VncState *vs, int x, int y, int w, int h, int quality) + + vnc_write_u8(vs, VNC_TIGHT_JPEG << 4); + +- tight_send_compact_size(vs, vs->tight.jpeg.offset); +- vnc_write(vs, vs->tight.jpeg.buffer, vs->tight.jpeg.offset); +- buffer_reset(&vs->tight.jpeg); ++ tight_send_compact_size(vs, vs->tight->jpeg.offset); ++ vnc_write(vs, vs->tight->jpeg.buffer, vs->tight->jpeg.offset); ++ buffer_reset(&vs->tight->jpeg); + + return 1; + } +@@ -1240,7 +1241,7 @@ static void write_png_palette(int idx, uint32_t pix, void *opaque) + VncState *vs = priv->vs; + png_colorp color = &priv->png_palette[idx]; + +- if (vs->tight.pixel24) ++ if (vs->tight->pixel24) + { + color->red = (pix >> vs->client_pf.rshift) & vs->client_pf.rmax; + color->green = (pix >> vs->client_pf.gshift) & vs->client_pf.gmax; +@@ -1267,10 +1268,10 @@ static void png_write_data(png_structp png_ptr, png_bytep data, + { + VncState *vs = png_get_io_ptr(png_ptr); + +- buffer_reserve(&vs->tight.png, vs->tight.png.offset + length); +- memcpy(vs->tight.png.buffer + vs->tight.png.offset, data, length); ++ buffer_reserve(&vs->tight->png, vs->tight->png.offset + length); ++ memcpy(vs->tight->png.buffer + vs->tight->png.offset, data, length); + +- vs->tight.png.offset += length; ++ vs->tight->png.offset += length; + } + + static void png_flush_data(png_structp png_ptr) +@@ -1295,8 +1296,8 @@ static int send_png_rect(VncState *vs, int x, int y, int w, int h, + png_infop info_ptr; + png_colorp png_palette = NULL; + pixman_image_t *linebuf; +- int level = tight_png_conf[vs->tight.compression].png_zlib_level; +- int filters = tight_png_conf[vs->tight.compression].png_filters; ++ int level = tight_png_conf[vs->tight->compression].png_zlib_level; ++ int filters = tight_png_conf[vs->tight->compression].png_filters; + uint8_t *buf; + int dy; + +@@ -1340,21 +1341,23 @@ static int send_png_rect(VncState *vs, int x, int y, int w, int h, + png_set_PLTE(png_ptr, info_ptr, png_palette, palette_size(palette)); + + if (vs->client_pf.bytes_per_pixel == 4) { +- tight_encode_indexed_rect32(vs->tight.tight.buffer, w * h, palette); ++ tight_encode_indexed_rect32(vs->tight->tight.buffer, w * h, ++ palette); + } else { +- tight_encode_indexed_rect16(vs->tight.tight.buffer, w * h, palette); ++ tight_encode_indexed_rect16(vs->tight->tight.buffer, w * h, ++ palette); + } + } + + png_write_info(png_ptr, info_ptr); + +- buffer_reserve(&vs->tight.png, 2048); ++ buffer_reserve(&vs->tight->png, 2048); + linebuf = qemu_pixman_linebuf_create(PIXMAN_BE_r8g8b8, w); + buf = (uint8_t *)pixman_image_get_data(linebuf); + for (dy = 0; dy < h; dy++) + { + if (color_type == PNG_COLOR_TYPE_PALETTE) { +- memcpy(buf, vs->tight.tight.buffer + (dy * w), w); ++ memcpy(buf, vs->tight->tight.buffer + (dy * w), w); + } else { + qemu_pixman_linebuf_fill(linebuf, vs->vd->server, w, x, y + dy); + } +@@ -1372,27 +1375,27 @@ static int send_png_rect(VncState *vs, int x, int y, int w, int h, + + vnc_write_u8(vs, VNC_TIGHT_PNG << 4); + +- tight_send_compact_size(vs, vs->tight.png.offset); +- vnc_write(vs, vs->tight.png.buffer, vs->tight.png.offset); +- buffer_reset(&vs->tight.png); ++ tight_send_compact_size(vs, vs->tight->png.offset); ++ vnc_write(vs, vs->tight->png.buffer, vs->tight->png.offset); ++ buffer_reset(&vs->tight->png); + return 1; + } + #endif /* CONFIG_VNC_PNG */ + + static void vnc_tight_start(VncState *vs) + { +- buffer_reset(&vs->tight.tight); ++ buffer_reset(&vs->tight->tight); + + // make the output buffer be the zlib buffer, so we can compress it later +- vs->tight.tmp = vs->output; +- vs->output = vs->tight.tight; ++ vs->tight->tmp = vs->output; ++ vs->output = vs->tight->tight; + } + + static void vnc_tight_stop(VncState *vs) + { + // switch back to normal output/zlib buffers +- vs->tight.tight = vs->output; +- vs->output = vs->tight.tmp; ++ vs->tight->tight = vs->output; ++ vs->output = vs->tight->tmp; + } + + static int send_sub_rect_nojpeg(VncState *vs, int x, int y, int w, int h, +@@ -1426,9 +1429,9 @@ static int send_sub_rect_jpeg(VncState *vs, int x, int y, int w, int h, + int ret; + + if (colors == 0) { +- if (force || (tight_jpeg_conf[vs->tight.quality].jpeg_full && ++ if (force || (tight_jpeg_conf[vs->tight->quality].jpeg_full && + tight_detect_smooth_image(vs, w, h))) { +- int quality = tight_conf[vs->tight.quality].jpeg_quality; ++ int quality = tight_conf[vs->tight->quality].jpeg_quality; + + ret = send_jpeg_rect(vs, x, y, w, h, quality); + } else { +@@ -1440,9 +1443,9 @@ static int send_sub_rect_jpeg(VncState *vs, int x, int y, int w, int h, + ret = send_mono_rect(vs, x, y, w, h, bg, fg); + } else if (colors <= 256) { + if (force || (colors > 96 && +- tight_jpeg_conf[vs->tight.quality].jpeg_idx && ++ tight_jpeg_conf[vs->tight->quality].jpeg_idx && + tight_detect_smooth_image(vs, w, h))) { +- int quality = tight_conf[vs->tight.quality].jpeg_quality; ++ int quality = tight_conf[vs->tight->quality].jpeg_quality; + + ret = send_jpeg_rect(vs, x, y, w, h, quality); + } else { +@@ -1480,20 +1483,20 @@ static int send_sub_rect(VncState *vs, int x, int y, int w, int h) + qemu_thread_atexit_add(&vnc_tight_cleanup_notifier); + } + +- vnc_framebuffer_update(vs, x, y, w, h, vs->tight.type); ++ vnc_framebuffer_update(vs, x, y, w, h, vs->tight->type); + + vnc_tight_start(vs); + vnc_raw_send_framebuffer_update(vs, x, y, w, h); + vnc_tight_stop(vs); + + #ifdef CONFIG_VNC_JPEG +- if (!vs->vd->non_adaptive && vs->tight.quality != (uint8_t)-1) { ++ if (!vs->vd->non_adaptive && vs->tight->quality != (uint8_t)-1) { + double freq = vnc_update_freq(vs, x, y, w, h); + +- if (freq < tight_jpeg_conf[vs->tight.quality].jpeg_freq_min) { ++ if (freq < tight_jpeg_conf[vs->tight->quality].jpeg_freq_min) { + allow_jpeg = false; + } +- if (freq >= tight_jpeg_conf[vs->tight.quality].jpeg_freq_threshold) { ++ if (freq >= tight_jpeg_conf[vs->tight->quality].jpeg_freq_threshold) { + force_jpeg = true; + vnc_sent_lossy_rect(vs, x, y, w, h); + } +@@ -1503,7 +1506,7 @@ static int send_sub_rect(VncState *vs, int x, int y, int w, int h) + colors = tight_fill_palette(vs, x, y, w * h, &bg, &fg, color_count_palette); + + #ifdef CONFIG_VNC_JPEG +- if (allow_jpeg && vs->tight.quality != (uint8_t)-1) { ++ if (allow_jpeg && vs->tight->quality != (uint8_t)-1) { + ret = send_sub_rect_jpeg(vs, x, y, w, h, bg, fg, colors, + color_count_palette, force_jpeg); + } else { +@@ -1520,7 +1523,7 @@ static int send_sub_rect(VncState *vs, int x, int y, int w, int h) + + static int send_sub_rect_solid(VncState *vs, int x, int y, int w, int h) + { +- vnc_framebuffer_update(vs, x, y, w, h, vs->tight.type); ++ vnc_framebuffer_update(vs, x, y, w, h, vs->tight->type); + + vnc_tight_start(vs); + vnc_raw_send_framebuffer_update(vs, x, y, w, h); +@@ -1538,8 +1541,8 @@ static int send_rect_simple(VncState *vs, int x, int y, int w, int h, + int rw, rh; + int n = 0; + +- max_size = tight_conf[vs->tight.compression].max_rect_size; +- max_width = tight_conf[vs->tight.compression].max_rect_width; ++ max_size = tight_conf[vs->tight->compression].max_rect_size; ++ max_width = tight_conf[vs->tight->compression].max_rect_width; + + if (split && (w > max_width || w * h > max_size)) { + max_sub_width = (w > max_width) ? max_width : w; +@@ -1648,16 +1651,16 @@ static int tight_send_framebuffer_update(VncState *vs, int x, int y, + + if (vs->client_pf.bytes_per_pixel == 4 && vs->client_pf.rmax == 0xFF && + vs->client_pf.bmax == 0xFF && vs->client_pf.gmax == 0xFF) { +- vs->tight.pixel24 = true; ++ vs->tight->pixel24 = true; + } else { +- vs->tight.pixel24 = false; ++ vs->tight->pixel24 = false; + } + + #ifdef CONFIG_VNC_JPEG +- if (vs->tight.quality != (uint8_t)-1) { ++ if (vs->tight->quality != (uint8_t)-1) { + double freq = vnc_update_freq(vs, x, y, w, h); + +- if (freq > tight_jpeg_conf[vs->tight.quality].jpeg_freq_threshold) { ++ if (freq > tight_jpeg_conf[vs->tight->quality].jpeg_freq_threshold) { + return send_rect_simple(vs, x, y, w, h, false); + } + } +@@ -1669,8 +1672,8 @@ static int tight_send_framebuffer_update(VncState *vs, int x, int y, + + /* Calculate maximum number of rows in one non-solid rectangle. */ + +- max_rows = tight_conf[vs->tight.compression].max_rect_size; +- max_rows /= MIN(tight_conf[vs->tight.compression].max_rect_width, w); ++ max_rows = tight_conf[vs->tight->compression].max_rect_size; ++ max_rows /= MIN(tight_conf[vs->tight->compression].max_rect_width, w); + + return find_large_solid_color_rect(vs, x, y, w, h, max_rows); + } +@@ -1678,33 +1681,33 @@ static int tight_send_framebuffer_update(VncState *vs, int x, int y, + int vnc_tight_send_framebuffer_update(VncState *vs, int x, int y, + int w, int h) + { +- vs->tight.type = VNC_ENCODING_TIGHT; ++ vs->tight->type = VNC_ENCODING_TIGHT; + return tight_send_framebuffer_update(vs, x, y, w, h); + } + + int vnc_tight_png_send_framebuffer_update(VncState *vs, int x, int y, + int w, int h) + { +- vs->tight.type = VNC_ENCODING_TIGHT_PNG; ++ vs->tight->type = VNC_ENCODING_TIGHT_PNG; + return tight_send_framebuffer_update(vs, x, y, w, h); + } + + void vnc_tight_clear(VncState *vs) + { + int i; +- for (i=0; itight.stream); i++) { +- if (vs->tight.stream[i].opaque) { +- deflateEnd(&vs->tight.stream[i]); ++ for (i = 0; i < ARRAY_SIZE(vs->tight->stream); i++) { ++ if (vs->tight->stream[i].opaque) { ++ deflateEnd(&vs->tight->stream[i]); + } + } + +- buffer_free(&vs->tight.tight); +- buffer_free(&vs->tight.zlib); +- buffer_free(&vs->tight.gradient); ++ buffer_free(&vs->tight->tight); ++ buffer_free(&vs->tight->zlib); ++ buffer_free(&vs->tight->gradient); + #ifdef CONFIG_VNC_JPEG +- buffer_free(&vs->tight.jpeg); ++ buffer_free(&vs->tight->jpeg); + #endif + #ifdef CONFIG_VNC_PNG +- buffer_free(&vs->tight.png); ++ buffer_free(&vs->tight->png); + #endif + } +diff --git a/ui/vnc-enc-zlib.c b/ui/vnc-enc-zlib.c +index 33e9df2..900ae5b 100644 +--- a/ui/vnc-enc-zlib.c ++++ b/ui/vnc-enc-zlib.c +@@ -76,7 +76,8 @@ static int vnc_zlib_stop(VncState *vs) + zstream->zalloc = vnc_zlib_zalloc; + zstream->zfree = vnc_zlib_zfree; + +- err = deflateInit2(zstream, vs->tight.compression, Z_DEFLATED, MAX_WBITS, ++ err = deflateInit2(zstream, vs->tight->compression, Z_DEFLATED, ++ MAX_WBITS, + MAX_MEM_LEVEL, Z_DEFAULT_STRATEGY); + + if (err != Z_OK) { +@@ -84,16 +85,16 @@ static int vnc_zlib_stop(VncState *vs) + return -1; + } + +- vs->zlib.level = vs->tight.compression; ++ vs->zlib.level = vs->tight->compression; + zstream->opaque = vs; + } + +- if (vs->tight.compression != vs->zlib.level) { +- if (deflateParams(zstream, vs->tight.compression, ++ if (vs->tight->compression != vs->zlib.level) { ++ if (deflateParams(zstream, vs->tight->compression, + Z_DEFAULT_STRATEGY) != Z_OK) { + return -1; + } +- vs->zlib.level = vs->tight.compression; ++ vs->zlib.level = vs->tight->compression; + } + + // reserve memory in output buffer +diff --git a/ui/vnc-enc-zrle.c b/ui/vnc-enc-zrle.c +index 7493a84..17fd28a 100644 +--- a/ui/vnc-enc-zrle.c ++++ b/ui/vnc-enc-zrle.c +@@ -37,18 +37,18 @@ static const int bits_per_packed_pixel[] = { + + static void vnc_zrle_start(VncState *vs) + { +- buffer_reset(&vs->zrle.zrle); ++ buffer_reset(&vs->zrle->zrle); + + /* make the output buffer be the zlib buffer, so we can compress it later */ +- vs->zrle.tmp = vs->output; +- vs->output = vs->zrle.zrle; ++ vs->zrle->tmp = vs->output; ++ vs->output = vs->zrle->zrle; + } + + static void vnc_zrle_stop(VncState *vs) + { + /* switch back to normal output/zlib buffers */ +- vs->zrle.zrle = vs->output; +- vs->output = vs->zrle.tmp; ++ vs->zrle->zrle = vs->output; ++ vs->output = vs->zrle->tmp; + } + + static void *zrle_convert_fb(VncState *vs, int x, int y, int w, int h, +@@ -56,24 +56,24 @@ static void *zrle_convert_fb(VncState *vs, int x, int y, int w, int h, + { + Buffer tmp; + +- buffer_reset(&vs->zrle.fb); +- buffer_reserve(&vs->zrle.fb, w * h * bpp + bpp); ++ buffer_reset(&vs->zrle->fb); ++ buffer_reserve(&vs->zrle->fb, w * h * bpp + bpp); + + tmp = vs->output; +- vs->output = vs->zrle.fb; ++ vs->output = vs->zrle->fb; + + vnc_raw_send_framebuffer_update(vs, x, y, w, h); + +- vs->zrle.fb = vs->output; ++ vs->zrle->fb = vs->output; + vs->output = tmp; +- return vs->zrle.fb.buffer; ++ return vs->zrle->fb.buffer; + } + + static int zrle_compress_data(VncState *vs, int level) + { +- z_streamp zstream = &vs->zrle.stream; ++ z_streamp zstream = &vs->zrle->stream; + +- buffer_reset(&vs->zrle.zlib); ++ buffer_reset(&vs->zrle->zlib); + + if (zstream->opaque != vs) { + int err; +@@ -93,13 +93,13 @@ static int zrle_compress_data(VncState *vs, int level) + } + + /* reserve memory in output buffer */ +- buffer_reserve(&vs->zrle.zlib, vs->zrle.zrle.offset + 64); ++ buffer_reserve(&vs->zrle->zlib, vs->zrle->zrle.offset + 64); + + /* set pointers */ +- zstream->next_in = vs->zrle.zrle.buffer; +- zstream->avail_in = vs->zrle.zrle.offset; +- zstream->next_out = vs->zrle.zlib.buffer + vs->zrle.zlib.offset; +- zstream->avail_out = vs->zrle.zlib.capacity - vs->zrle.zlib.offset; ++ zstream->next_in = vs->zrle->zrle.buffer; ++ zstream->avail_in = vs->zrle->zrle.offset; ++ zstream->next_out = vs->zrle->zlib.buffer + vs->zrle->zlib.offset; ++ zstream->avail_out = vs->zrle->zlib.capacity - vs->zrle->zlib.offset; + zstream->data_type = Z_BINARY; + + /* start encoding */ +@@ -108,8 +108,8 @@ static int zrle_compress_data(VncState *vs, int level) + return -1; + } + +- vs->zrle.zlib.offset = vs->zrle.zlib.capacity - zstream->avail_out; +- return vs->zrle.zlib.offset; ++ vs->zrle->zlib.offset = vs->zrle->zlib.capacity - zstream->avail_out; ++ return vs->zrle->zlib.offset; + } + + /* Try to work out whether to use RLE and/or a palette. We do this by +@@ -259,14 +259,14 @@ static int zrle_send_framebuffer_update(VncState *vs, int x, int y, + size_t bytes; + int zywrle_level; + +- if (vs->zrle.type == VNC_ENCODING_ZYWRLE) { +- if (!vs->vd->lossy || vs->tight.quality == (uint8_t)-1 +- || vs->tight.quality == 9) { ++ if (vs->zrle->type == VNC_ENCODING_ZYWRLE) { ++ if (!vs->vd->lossy || vs->tight->quality == (uint8_t)-1 ++ || vs->tight->quality == 9) { + zywrle_level = 0; +- vs->zrle.type = VNC_ENCODING_ZRLE; +- } else if (vs->tight.quality < 3) { ++ vs->zrle->type = VNC_ENCODING_ZRLE; ++ } else if (vs->tight->quality < 3) { + zywrle_level = 3; +- } else if (vs->tight.quality < 6) { ++ } else if (vs->tight->quality < 6) { + zywrle_level = 2; + } else { + zywrle_level = 1; +@@ -337,30 +337,30 @@ static int zrle_send_framebuffer_update(VncState *vs, int x, int y, + + vnc_zrle_stop(vs); + bytes = zrle_compress_data(vs, Z_DEFAULT_COMPRESSION); +- vnc_framebuffer_update(vs, x, y, w, h, vs->zrle.type); ++ vnc_framebuffer_update(vs, x, y, w, h, vs->zrle->type); + vnc_write_u32(vs, bytes); +- vnc_write(vs, vs->zrle.zlib.buffer, vs->zrle.zlib.offset); ++ vnc_write(vs, vs->zrle->zlib.buffer, vs->zrle->zlib.offset); + return 1; + } + + int vnc_zrle_send_framebuffer_update(VncState *vs, int x, int y, int w, int h) + { +- vs->zrle.type = VNC_ENCODING_ZRLE; ++ vs->zrle->type = VNC_ENCODING_ZRLE; + return zrle_send_framebuffer_update(vs, x, y, w, h); + } + + int vnc_zywrle_send_framebuffer_update(VncState *vs, int x, int y, int w, int h) + { +- vs->zrle.type = VNC_ENCODING_ZYWRLE; ++ vs->zrle->type = VNC_ENCODING_ZYWRLE; + return zrle_send_framebuffer_update(vs, x, y, w, h); + } + + void vnc_zrle_clear(VncState *vs) + { +- if (vs->zrle.stream.opaque) { +- deflateEnd(&vs->zrle.stream); ++ if (vs->zrle->stream.opaque) { ++ deflateEnd(&vs->zrle->stream); + } +- buffer_free(&vs->zrle.zrle); +- buffer_free(&vs->zrle.fb); +- buffer_free(&vs->zrle.zlib); ++ buffer_free(&vs->zrle->zrle); ++ buffer_free(&vs->zrle->fb); ++ buffer_free(&vs->zrle->zlib); + } +diff --git a/ui/vnc-enc-zrle.inc.c b/ui/vnc-enc-zrle.inc.c +index abf6b86..c107d8a 100644 +--- a/ui/vnc-enc-zrle.inc.c ++++ b/ui/vnc-enc-zrle.inc.c +@@ -96,7 +96,7 @@ static void ZRLE_ENCODE(VncState *vs, int x, int y, int w, int h, + static void ZRLE_ENCODE_TILE(VncState *vs, ZRLE_PIXEL *data, int w, int h, + int zywrle_level) + { +- VncPalette *palette = &vs->zrle.palette; ++ VncPalette *palette = &vs->zrle->palette; + + int runs = 0; + int single_pixels = 0; +diff --git a/ui/vnc.c b/ui/vnc.c +index bc43c4c..87b8045 100644 +--- a/ui/vnc.c ++++ b/ui/vnc.c +@@ -1307,6 +1307,8 @@ void vnc_disconnect_finish(VncState *vs) + object_unref(OBJECT(vs->sioc)); + vs->sioc = NULL; + vs->magic = 0; ++ g_free(vs->zrle); ++ g_free(vs->tight); + g_free(vs); + } + +@@ -2058,8 +2060,8 @@ static void set_encodings(VncState *vs, int32_t *encodings, size_t n_encodings) + + vs->features = 0; + vs->vnc_encoding = 0; +- vs->tight.compression = 9; +- vs->tight.quality = -1; /* Lossless by default */ ++ vs->tight->compression = 9; ++ vs->tight->quality = -1; /* Lossless by default */ + vs->absolute = -1; + + /* +@@ -2127,11 +2129,11 @@ static void set_encodings(VncState *vs, int32_t *encodings, size_t n_encodings) + vs->features |= VNC_FEATURE_LED_STATE_MASK; + break; + case VNC_ENCODING_COMPRESSLEVEL0 ... VNC_ENCODING_COMPRESSLEVEL0 + 9: +- vs->tight.compression = (enc & 0x0F); ++ vs->tight->compression = (enc & 0x0F); + break; + case VNC_ENCODING_QUALITYLEVEL0 ... VNC_ENCODING_QUALITYLEVEL0 + 9: + if (vs->vd->lossy) { +- vs->tight.quality = (enc & 0x0F); ++ vs->tight->quality = (enc & 0x0F); + } + break; + default: +@@ -3034,6 +3036,8 @@ static void vnc_connect(VncDisplay *vd, QIOChannelSocket *sioc, + int i; + + trace_vnc_client_connect(vs, sioc); ++ vs->zrle = g_new0(VncZrle, 1); ++ vs->tight = g_new0(VncTight, 1); + vs->magic = VNC_MAGIC; + vs->sioc = sioc; + object_ref(OBJECT(vs->sioc)); +@@ -3045,19 +3049,19 @@ static void vnc_connect(VncDisplay *vd, QIOChannelSocket *sioc, + buffer_init(&vs->output, "vnc-output/%p", sioc); + buffer_init(&vs->jobs_buffer, "vnc-jobs_buffer/%p", sioc); + +- buffer_init(&vs->tight.tight, "vnc-tight/%p", sioc); +- buffer_init(&vs->tight.zlib, "vnc-tight-zlib/%p", sioc); +- buffer_init(&vs->tight.gradient, "vnc-tight-gradient/%p", sioc); ++ buffer_init(&vs->tight->tight, "vnc-tight/%p", sioc); ++ buffer_init(&vs->tight->zlib, "vnc-tight-zlib/%p", sioc); ++ buffer_init(&vs->tight->gradient, "vnc-tight-gradient/%p", sioc); + #ifdef CONFIG_VNC_JPEG +- buffer_init(&vs->tight.jpeg, "vnc-tight-jpeg/%p", sioc); ++ buffer_init(&vs->tight->jpeg, "vnc-tight-jpeg/%p", sioc); + #endif + #ifdef CONFIG_VNC_PNG +- buffer_init(&vs->tight.png, "vnc-tight-png/%p", sioc); ++ buffer_init(&vs->tight->png, "vnc-tight-png/%p", sioc); + #endif + buffer_init(&vs->zlib.zlib, "vnc-zlib/%p", sioc); +- buffer_init(&vs->zrle.zrle, "vnc-zrle/%p", sioc); +- buffer_init(&vs->zrle.fb, "vnc-zrle-fb/%p", sioc); +- buffer_init(&vs->zrle.zlib, "vnc-zrle-zlib/%p", sioc); ++ buffer_init(&vs->zrle->zrle, "vnc-zrle/%p", sioc); ++ buffer_init(&vs->zrle->fb, "vnc-zrle-fb/%p", sioc); ++ buffer_init(&vs->zrle->zlib, "vnc-zrle-zlib/%p", sioc); + + if (skipauth) { + vs->auth = VNC_AUTH_NONE; +diff --git a/ui/vnc.h b/ui/vnc.h +index 8643860..fea79c2 100644 +--- a/ui/vnc.h ++++ b/ui/vnc.h +@@ -338,10 +338,10 @@ struct VncState + /* Encoding specific, if you add something here, don't forget to + * update vnc_async_encoding_start() + */ +- VncTight tight; ++ VncTight *tight; + VncZlib zlib; + VncHextile hextile; +- VncZrle zrle; ++ VncZrle *zrle; + VncZywrle zywrle; + + Notifier mouse_mode_notifier; +-- +1.8.3.1 -- 2.7.4 From chee.yang.lee at intel.com Wed Mar 11 06:47:36 2020 From: chee.yang.lee at intel.com (chee.yang.lee at intel.com) Date: Wed, 11 Mar 2020 14:47:36 +0800 Subject: [OE-core] [PATCH][zeus 2/2] libpcre2: fix CVE-2019-20454 In-Reply-To: <1583909256-28697-1-git-send-email-chee.yang.lee@intel.com> References: <1583909256-28697-1-git-send-email-chee.yang.lee@intel.com> Message-ID: <1583909256-28697-2-git-send-email-chee.yang.lee@intel.com> From: Lee Chee Yang Signed-off-by: Lee Chee Yang --- .../libpcre/libpcre2/CVE-2019-20454.patch | 19 +++++++++++++++++++ meta/recipes-support/libpcre/libpcre2_10.33.bb | 1 + 2 files changed, 20 insertions(+) create mode 100644 meta/recipes-support/libpcre/libpcre2/CVE-2019-20454.patch diff --git a/meta/recipes-support/libpcre/libpcre2/CVE-2019-20454.patch b/meta/recipes-support/libpcre/libpcre2/CVE-2019-20454.patch new file mode 100644 index 0000000..51f95a7 --- /dev/null +++ b/meta/recipes-support/libpcre/libpcre2/CVE-2019-20454.patch @@ -0,0 +1,19 @@ +Upstream-Status: Backport [https://vcs.pcre.org/pcre2/code/trunk/src/pcre2_jit_compile.c?r1=1092&r2=1091&pathrev=1092] +CVE: CVE-2020-8002 +Signed-off-by: Lee Chee Yang + +--- pcre2-10.30/src/pcre2_jit_compile.c 2019/05/13 16:26:17 1091 ++++ pcre2-10.30/src/pcre2_jit_compile.c 2019/05/13 16:38:18 1092 +@@ -8571,7 +8571,10 @@ + PCRE2_SPTR bptr; + uint32_t c; + +-GETCHARINC(c, cc); ++/* Patch by PH */ ++/* GETCHARINC(c, cc); */ ++ ++c = *cc++; + #if PCRE2_CODE_UNIT_WIDTH == 32 + if (c >= 0x110000) + return NULL; + diff --git a/meta/recipes-support/libpcre/libpcre2_10.33.bb b/meta/recipes-support/libpcre/libpcre2_10.33.bb index 50b2675..1020df9 100644 --- a/meta/recipes-support/libpcre/libpcre2_10.33.bb +++ b/meta/recipes-support/libpcre/libpcre2_10.33.bb @@ -12,6 +12,7 @@ LIC_FILES_CHKSUM = "file://LICENCE;md5=b1588d3bb4cb0e1f5a597d908f8c5b37" SRC_URI = "https://ftp.pcre.org/pub/pcre/pcre2-${PV}.tar.bz2 \ file://pcre-cross.patch \ + file://CVE-2019-20454.patch \ " SRC_URI[md5sum] = "80b355f2dce909a2e2424f5c79eddb44" -- 2.7.4 From bunk at stusta.de Wed Mar 11 07:51:33 2020 From: bunk at stusta.de (Adrian Bunk) Date: Wed, 11 Mar 2020 09:51:33 +0200 Subject: [OE-core] [zeus 06/16] valgrind: Fix build with -fno-common In-Reply-To: <350496c3c0b80835cb5311aa6dbc91e4ee7b5935.1583893499.git.akuster808@gmail.com> References: <350496c3c0b80835cb5311aa6dbc91e4ee7b5935.1583893499.git.akuster808@gmail.com> Message-ID: <20200311075133.GA30580@localhost> This patch is required for switching to gcc 10 (which changes the default to -fno-common) in Yocto 3.2. AFAIK there is no benefit in backporting it to older releases. cu Adrian From brgl at bgdev.pl Wed Mar 11 08:03:06 2020 From: brgl at bgdev.pl (Bartosz Golaszewski) Date: Wed, 11 Mar 2020 09:03:06 +0100 Subject: [OE-core] Solving a circular dependency issue between the main image and initramfs In-Reply-To: References: Message-ID: wt., 10 mar 2020 o 23:54 Ayoub Zaki napisa?(a): > > > On 10.03.20 23:02, Bartosz Golaszewski wrote: > > wt., 10 mar 2020 o 22:33 Ayoub Zaki napisa?(a): > > Do I implement do_install in image.bbclass so that initramfs can > depend on core-image-full-cmdline:do_populate_sysroot and have the > artifacts installed locally? But this would mean that the initramfs > recipe deploys the main image artifact. Should we deploy the images > earlier (before do_image_complete) for the initramfs recipe to fetch > from DEPLOY_DIR_IMAGE? Any other ideas? > > I think that best thing is to implement the dm-verity stuffs as a wic > plugin, check this example: > > > https://github.com/intel/intel-iot-refkit/blob/master/meta-refkit-core/scripts/lib/wic/plugins/source/dm-verity.py > > This doesn't look like a correct solution. For starters: not every > platform uses wic. The platform I'm aiming this at uses fastboot and > requires separate images for each partition. > > > My proposition was refering to your example : > The example is there just to include support for one of the reference boards - BBB in this case. The initramfs itself as well as the rest should be generic though. > > https://github.com/brgl/meta-security/commit/83c8e8fba6988249c9d351aa2ad6e02a71b010df#diff-33f7c29b373860ec45379a5f2dc42a75 > > > your are trying to include the dm-verity conversion output to your wic wks using the following: > > > part / --source rawcopy --ondisk mmcblk --sourceparams="file=${IMGDEPLOYDIR}/${DM_VERITY_IMAGE}-${MACHINE}.${DM_VERITY_TYPE}" > > > In this case you will definitely stuck in a circular dependency unless using a Wic plugin. > Actually this isn't a problem. The dm-verity class makes do_image_wic depend on do_image_ext[234] and do_image_btrfs and since do_image_wic is part of the same recipe, we can fetch the image from IMGDEPLOYDIR before it's deployed. Best regards, Bartosz Golaszewski From richard.purdie at linuxfoundation.org Wed Mar 11 08:26:28 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Wed, 11 Mar 2020 08:26:28 +0000 Subject: [OE-core] [PATCH 2/2] parselogs.py: whitelist more xserver related error In-Reply-To: <1583892804-385900-2-git-send-email-changqing.li@windriver.com> References: <1583892804-385900-1-git-send-email-changqing.li@windriver.com> <1583892804-385900-2-git-send-email-changqing.li@windriver.com> Message-ID: On Wed, 2020-03-11 at 10:13 +0800, changqing.li at windriver.com wrote: > From: Changqing Li > > With default config, these errors always exist for > core-image-sato, and xserver-nodm.server start successfully, > these errors are not critially. > > If set default syslog to rsyslog, all these errors > will go into daemon.log and user.log, then test_parselog > will fail, so whitelist these errors > > Signed-off-by: Changqing Li > --- > meta/lib/oeqa/runtime/cases/parselogs.py | 12 +++++++++++- > 1 file changed, 11 insertions(+), 1 deletion(-) > > diff --git a/meta/lib/oeqa/runtime/cases/parselogs.py > b/meta/lib/oeqa/runtime/cases/parselogs.py > index 6e22520..2a5e5c6 100644 > --- a/meta/lib/oeqa/runtime/cases/parselogs.py > +++ b/meta/lib/oeqa/runtime/cases/parselogs.py > @@ -58,7 +58,15 @@ common_errors = [ > "Failed to rename network interface", > "Failed to process device, ignoring: Device or resource busy", > "Cannot find a map file", > - "[rdrand]: Initialization Failed" > + "[rdrand]: Initialization Failed", > + "libGL error:", > + "[pulseaudio] authkey.c: Failed to open cookie file", > + "[pulseaudio] authkey.c: Failed to load authentication key", > + "FBIOPUT_VSCREENINFO failed, double buffering disabled", > + "xserver-nodm.service: Failed with result 'exit-code'", > + "xinit: server error", > + "matchbox-wm: X error warning", > + "X11 cannot support keycodes above 255" > ] > > video_related = [ > @@ -86,6 +94,8 @@ qemux86_common = [ > 'tsc: HPET/PMTIMER calibration failed', > "modeset(0): Failed to initialize the DRI2 extension", > "glamor initialization failed", > + "xf86OpenConsole: Switching VT failed", > + "Fatal server error:", "Fatal server error" means the server didn't start correctly? I doubt we want to whitelist that one. With several of these you're right, they have been on the console for a while and I'm worried that a) we don't see them in the logs and b) the errors are occurring at all, we should really fix some of them, not "hide" them. Can we fix any of them rather than whitelisting? If we really do want to "hide" them, I think at the very least we need open bugs for some of them so we can track and fix the underlying problems. We need the bugs open before any patch can merge. Cheers, Richard From wallinux at gmail.com Wed Mar 11 09:40:15 2020 From: wallinux at gmail.com (Anders Wallin) Date: Wed, 11 Mar 2020 10:40:15 +0100 Subject: [OE-core] [PATCH] lttng-ust: update to 2.11.1 Message-ID: <20200311094015.14893-1-wallinux@gmail.com> Signed-off-by: Anders Wallin --- .../lttng/{lttng-ust_2.11.0.bb => lttng-ust_2.11.1.bb} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename meta/recipes-kernel/lttng/{lttng-ust_2.11.0.bb => lttng-ust_2.11.1.bb} (93%) diff --git a/meta/recipes-kernel/lttng/lttng-ust_2.11.0.bb b/meta/recipes-kernel/lttng/lttng-ust_2.11.1.bb similarity index 93% rename from meta/recipes-kernel/lttng/lttng-ust_2.11.0.bb rename to meta/recipes-kernel/lttng/lttng-ust_2.11.1.bb index 0e03a31652..3bd0dfad61 100644 --- a/meta/recipes-kernel/lttng/lttng-ust_2.11.0.bb +++ b/meta/recipes-kernel/lttng/lttng-ust_2.11.1.bb @@ -31,8 +31,8 @@ SRC_URI = "https://lttng.org/files/lttng-ust/lttng-ust-${PV}.tar.bz2 \ file://0001-python-lttngust-Makefile.am-Add-install-lib-to-setup.patch \ " -SRC_URI[md5sum] = "99823cfeb76562d753ffe67880e9cc59" -SRC_URI[sha256sum] = "683280cfe5e12021e64c32cef9eeb0128f1f23dec32ba28adb5a2074be37c4d8" +SRC_URI[md5sum] = "7de04a8ff1f0a4effa09a42620ec4081" +SRC_URI[sha256sum] = "7fbab963d60741ffd4d8dd0a246f6cf168cdfe3b2385798bd90550f5f0bba869" CVE_PRODUCT = "ust" -- 2.25.1 From bunk at stusta.de Wed Mar 11 09:49:19 2020 From: bunk at stusta.de (Adrian Bunk) Date: Wed, 11 Mar 2020 11:49:19 +0200 Subject: [OE-core] [zeus][PATCH v2] sqlite: fix numerous CVEs Message-ID: <20200311094919.12275-1-bunk@stusta.de> From: Ross Burton Fix the following CVEs: - CVE-2019-19244 - CVE-2019-19923 - CVE-2019-19924 - CVE-2019-19925 - CVE-2019-19926 - CVE-2019-19959 - CVE-2019-20218 Signed-off-by: Ross Burton Signed-off-by: Richard Purdie [ removed the CVE-2019-19880 fix that did not apply cleanly ] Signed-off-by: Adrian Bunk --- .../sqlite/sqlite3/CVE-2019-19244.patch | 33 ++++++++++ .../sqlite/sqlite3/CVE-2019-19923.patch | 50 ++++++++++++++ .../sqlite/sqlite3/CVE-2019-19924.patch | 65 +++++++++++++++++++ .../sqlite/sqlite3/CVE-2019-19925.patch | 33 ++++++++++ .../sqlite/sqlite3/CVE-2019-19926.patch | 31 +++++++++ .../sqlite/sqlite3/CVE-2019-19959.patch | 46 +++++++++++++ .../sqlite/sqlite3/CVE-2019-20218.patch | 31 +++++++++ meta/recipes-support/sqlite/sqlite3_3.29.0.bb | 10 ++- 8 files changed, 298 insertions(+), 1 deletion(-) create mode 100644 meta/recipes-support/sqlite/sqlite3/CVE-2019-19244.patch create mode 100644 meta/recipes-support/sqlite/sqlite3/CVE-2019-19923.patch create mode 100644 meta/recipes-support/sqlite/sqlite3/CVE-2019-19924.patch create mode 100644 meta/recipes-support/sqlite/sqlite3/CVE-2019-19925.patch create mode 100644 meta/recipes-support/sqlite/sqlite3/CVE-2019-19926.patch create mode 100644 meta/recipes-support/sqlite/sqlite3/CVE-2019-19959.patch create mode 100644 meta/recipes-support/sqlite/sqlite3/CVE-2019-20218.patch diff --git a/meta/recipes-support/sqlite/sqlite3/CVE-2019-19244.patch b/meta/recipes-support/sqlite/sqlite3/CVE-2019-19244.patch new file mode 100644 index 0000000000..3f70979acc --- /dev/null +++ b/meta/recipes-support/sqlite/sqlite3/CVE-2019-19244.patch @@ -0,0 +1,33 @@ +CVE: CVE-2019-19244 +Upstream-Status: Backport +Signed-off-by: Ross Burton + +From 0f690d4ae5ffe656762fdbb7f36cc4c2dcbb2d9d Mon Sep 17 00:00:00 2001 +From: dan +Date: Fri, 22 Nov 2019 10:14:01 +0000 +Subject: [PATCH] Fix a crash that could occur if a sub-select that uses both + DISTINCT and window functions also used an ORDER BY that is the same as its + select list. + +Amalgamation version of the patch: +FossilOrigin-Name: bcdd66c1691955c697f3d756c2b035acfe98f6aad72e90b0021bab6e9023b3ba +--- + sqlite3.c | 5 +++-- + sqlite3.h | 2 +- + 2 files changed, 4 insertions(+), 3 deletions(-) + +diff --git a/sqlite3.c b/sqlite3.c +index 8fd740b..db1c649 100644 +--- a/sqlite3.c ++++ b/sqlite3.c +@@ -131679,6 +131679,7 @@ SQLITE_PRIVATE int sqlite3Select( + */ + if( (p->selFlags & (SF_Distinct|SF_Aggregate))==SF_Distinct + && sqlite3ExprListCompare(sSort.pOrderBy, pEList, -1)==0 ++ && p->pWin==0 + ){ + p->selFlags &= ~SF_Distinct; + pGroupBy = p->pGroupBy = sqlite3ExprListDup(db, pEList, 0); +-- +2.24.1 + diff --git a/meta/recipes-support/sqlite/sqlite3/CVE-2019-19923.patch b/meta/recipes-support/sqlite/sqlite3/CVE-2019-19923.patch new file mode 100644 index 0000000000..b1b866b250 --- /dev/null +++ b/meta/recipes-support/sqlite/sqlite3/CVE-2019-19923.patch @@ -0,0 +1,50 @@ +CVE: CVE-2019-19923 +Upstream-Status: Backport +Signed-off-by: Ross Burton + +From b64463719dc53bde98b0ce3930b10a32560c3a02 Mon Sep 17 00:00:00 2001 +From: "D. Richard Hipp" +Date: Wed, 18 Dec 2019 20:51:58 +0000 +Subject: [PATCH] Continue to back away from the LEFT JOIN optimization of + check-in [41c27bc0ff1d3135] by disallowing query flattening if the outer + query is DISTINCT. Without this fix, if an index scan is run on the table + within the view on the right-hand side of the LEFT JOIN, stale result + registers might be accessed yielding incorrect results, and/or an + OP_IfNullRow opcode might be invoked on the un-opened table, resulting in a + NULL-pointer dereference. This problem was found by the Yongheng and Rui + fuzzer. + +FossilOrigin-Name: 862974312edf00e9d1068115d1a39b7235b7db68b6d86b81d38a12f025a4748e +--- + sqlite3.c | 10 +++++++--- + 1 file changed, 7 insertions(+), 3 deletions(-) + +diff --git a/sqlite3.c b/sqlite3.c +index d29da07..5bc06c8 100644 +--- a/sqlite3.c ++++ b/sqlite3.c +@@ -129216,6 +129216,7 @@ static void substSelect( + ** (3b) the FROM clause of the subquery may not contain a virtual + ** table and + ** (3c) the outer query may not be an aggregate. ++** (3d) the outer query may not be DISTINCT. + ** + ** (4) The subquery can not be DISTINCT. + ** +@@ -129412,8 +129413,11 @@ static int flattenSubquery( + */ + if( (pSubitem->fg.jointype & JT_OUTER)!=0 ){ + isLeftJoin = 1; +- if( pSubSrc->nSrc>1 || isAgg || IsVirtual(pSubSrc->a[0].pTab) ){ +- /* (3a) (3c) (3b) */ ++ if( pSubSrc->nSrc>1 /* (3a) */ ++ || isAgg /* (3b) */ ++ || IsVirtual(pSubSrc->a[0].pTab) /* (3c) */ ++ || (p->selFlags & SF_Distinct)!=0 /* (3d) */ ++ ){ + return 0; + } + } +-- +2.24.1 + diff --git a/meta/recipes-support/sqlite/sqlite3/CVE-2019-19924.patch b/meta/recipes-support/sqlite/sqlite3/CVE-2019-19924.patch new file mode 100644 index 0000000000..80d5edbb0c --- /dev/null +++ b/meta/recipes-support/sqlite/sqlite3/CVE-2019-19924.patch @@ -0,0 +1,65 @@ +CVE: CVE-2019-19924 +Upstream-Status: Backport +Signed-off-by: Ross Burton + +From 854fe21e8a987f84da81f6bb9e90abc5355c6621 Mon Sep 17 00:00:00 2001 +From: "D. Richard Hipp" +Date: Thu, 19 Dec 2019 20:37:32 +0000 +Subject: [PATCH] When an error occurs while rewriting the parser tree for + window functions in the sqlite3WindowRewrite() routine, make sure that + pParse->nErr is set, and make sure that this shuts down any subsequent code + generation that might depend on the transformations that were implemented. + This fixes a problem discovered by the Yongheng and Rui fuzzer. + +Amalgamation format of backported patch +FossilOrigin-Name: e2bddcd4c55ba3cbe0130332679ff4b048630d0ced9a8899982edb5a3569ba7f +--- + sqlite3.c | 16 +++++++++++----- + sqlite3.h | 2 +- + 2 files changed, 12 insertions(+), 6 deletions(-) + +diff --git a/sqlite3.c b/sqlite3.c +index 408ec4c..857c28e 100644 +--- a/sqlite3.c ++++ b/sqlite3.c +@@ -77798,7 +77798,8 @@ SQLITE_PRIVATE void sqlite3VdbeSetP4KeyInfo(Parse *pParse, Index *pIdx){ + */ + static void vdbeVComment(Vdbe *p, const char *zFormat, va_list ap){ + assert( p->nOp>0 || p->aOp==0 ); +- assert( p->aOp==0 || p->aOp[p->nOp-1].zComment==0 || p->db->mallocFailed ); ++ assert( p->aOp==0 || p->aOp[p->nOp-1].zComment==0 || p->db->mallocFailed ++ || p->pParse->nErr>0 ); + if( p->nOp ){ + assert( p->aOp ); + sqlite3DbFree(p->db, p->aOp[p->nOp-1].zComment); +@@ -97872,6 +97873,7 @@ static int codeCompare( + int addr; + CollSeq *p4; + ++ if( pParse->nErr ) return 0; + p4 = sqlite3BinaryCompareCollSeq(pParse, pLeft, pRight); + p5 = binaryCompareP5(pLeft, pRight, jumpIfNull); + addr = sqlite3VdbeAddOp4(pParse->pVdbe, opcode, in2, dest, in1, +@@ -147627,7 +147629,7 @@ SQLITE_PRIVATE int sqlite3WindowRewrite(Parse *pParse, Select *p){ + + pTab = sqlite3DbMallocZero(db, sizeof(Table)); + if( pTab==0 ){ +- return SQLITE_NOMEM; ++ return sqlite3ErrorToParser(db, SQLITE_NOMEM); + } + + p->pSrc = 0; +@@ -147731,6 +147733,10 @@ SQLITE_PRIVATE int sqlite3WindowRewrite(Parse *pParse, Select *p){ + sqlite3DbFree(db, pTab); + } + ++ if( rc && pParse->nErr==0 ){ ++ assert( pParse->db->mallocFailed ); ++ return sqlite3ErrorToParser(pParse->db, SQLITE_NOMEM); ++ } + return rc; + } + +-- +2.24.1 + diff --git a/meta/recipes-support/sqlite/sqlite3/CVE-2019-19925.patch b/meta/recipes-support/sqlite/sqlite3/CVE-2019-19925.patch new file mode 100644 index 0000000000..ffc2c6afff --- /dev/null +++ b/meta/recipes-support/sqlite/sqlite3/CVE-2019-19925.patch @@ -0,0 +1,33 @@ +CVE: CVE-2019-19925 +Upstream-Status: Backport +Signed-off-by: Ross Burton + +From e92580434d2cdca228649d32f76167492de4f512 Mon Sep 17 00:00:00 2001 +From: "D. Richard Hipp" +Date: Thu, 19 Dec 2019 15:15:40 +0000 +Subject: [PATCH] Fix the zipfile extension so that INSERT works even if the + pathname of the file being inserted is a NULL. Bug discovered by the + Yongheng and Rui fuzzer. + +FossilOrigin-Name: a80f84b511231204658304226de3e075a55afc2e3f39ac063716f7a57f585c06 +--- + shell.c | 1 + + sqlite3.c | 4 ++-- + sqlite3.h | 2 +- + 3 files changed, 4 insertions(+), 3 deletions(-) + +diff --git a/shell.c b/shell.c +index 053180c..404a8d4 100644 +--- a/shell.c ++++ b/shell.c +@@ -5827,6 +5827,7 @@ static int zipfileUpdate( + + if( rc==SQLITE_OK ){ + zPath = (const char*)sqlite3_value_text(apVal[2]); ++ if( zPath==0 ) zPath = ""; + nPath = (int)strlen(zPath); + mTime = zipfileGetTime(apVal[4]); + } +-- +2.24.1 + diff --git a/meta/recipes-support/sqlite/sqlite3/CVE-2019-19926.patch b/meta/recipes-support/sqlite/sqlite3/CVE-2019-19926.patch new file mode 100644 index 0000000000..92bc7908bc --- /dev/null +++ b/meta/recipes-support/sqlite/sqlite3/CVE-2019-19926.patch @@ -0,0 +1,31 @@ +CVE: CVE-2019-19926 +Upstream-Status: Backport +Signed-off-by: Ross Burton + +From 4165b1e1e0001165ace9051a70f938099505eadc Mon Sep 17 00:00:00 2001 +From: "D. Richard Hipp" +Date: Thu, 19 Dec 2019 22:08:19 +0000 +Subject: [PATCH] Continuation of [e2bddcd4c55ba3cb]: Add another spot where it + is necessary to abort early due to prior errors in sqlite3WindowRewrite(). + +FossilOrigin-Name: cba2a2a44cdf138a629109bb0ad088ed4ef67fc66bed3e0373554681a39615d2 +--- + sqlite3.c | 7 ++++--- + sqlite3.h | 2 +- + 2 files changed, 5 insertions(+), 4 deletions(-) + +diff --git a/sqlite3.c b/sqlite3.c +index 857c28e..19a474d 100644 +--- a/sqlite3.c ++++ b/sqlite3.c +@@ -128427,6 +128427,7 @@ static int multiSelect( + } + #endif + } ++ if( pParse->nErr ) goto multi_select_end; + + /* Compute collating sequences used by + ** temporary tables needed to implement the compound select. +-- +2.24.1 + diff --git a/meta/recipes-support/sqlite/sqlite3/CVE-2019-19959.patch b/meta/recipes-support/sqlite/sqlite3/CVE-2019-19959.patch new file mode 100644 index 0000000000..cba8ec9d30 --- /dev/null +++ b/meta/recipes-support/sqlite/sqlite3/CVE-2019-19959.patch @@ -0,0 +1,46 @@ +CVE: CVE-2019-19959 +Upstream-Status: Backport +Signed-off-by: Ross Burton + +From f83f7e8141ee7cbbf7f2dc8985279a7372b259b6 Mon Sep 17 00:00:00 2001 +From: "D. Richard Hipp" +Date: Mon, 23 Dec 2019 21:04:33 +0000 +Subject: [PATCH] Fix the zipfile() function in the zipfile extension so that + it is able to deal with goofy filenames that contain embedded zeros. + +FossilOrigin-Name: cc0fb00a128fd0773db5ff7891f7aa577a3671d570166d2cbb30df922344adcf +--- + shell.c | 4 ++-- + sqlite3.c | 4 ++-- + sqlite3.h | 2 +- + 3 files changed, 5 insertions(+), 5 deletions(-) + +diff --git a/shell.c b/shell.c +index 404a8d4..48065e9 100644 +--- a/shell.c ++++ b/shell.c +@@ -5841,7 +5841,7 @@ static int zipfileUpdate( + zFree = sqlite3_mprintf("%s/", zPath); + if( zFree==0 ){ rc = SQLITE_NOMEM; } + zPath = (const char*)zFree; +- nPath++; ++ nPath = (int)strlen(zPath); + } + } + +@@ -6242,11 +6242,11 @@ void zipfileStep(sqlite3_context *pCtx, int nVal, sqlite3_value **apVal){ + }else{ + if( zName[nName-1]!='/' ){ + zName = zFree = sqlite3_mprintf("%s/", zName); +- nName++; + if( zName==0 ){ + rc = SQLITE_NOMEM; + goto zipfile_step_out; + } ++ nName = (int)strlen(zName); + }else{ + while( nName>1 && zName[nName-2]=='/' ) nName--; + } +-- +2.24.1 + diff --git a/meta/recipes-support/sqlite/sqlite3/CVE-2019-20218.patch b/meta/recipes-support/sqlite/sqlite3/CVE-2019-20218.patch new file mode 100644 index 0000000000..fb6cd6df2d --- /dev/null +++ b/meta/recipes-support/sqlite/sqlite3/CVE-2019-20218.patch @@ -0,0 +1,31 @@ +CVE: CVE-2019-20218 +Upstream-Status: Backport +Signed-off-by: Ross Burton + +From 6bbd76d34f29f61483791231f2ce579dcadab8a5 Mon Sep 17 00:00:00 2001 +From: Dan Kennedy +Date: Fri, 27 Dec 2019 20:54:42 +0000 +Subject: [PATCH] Do not attempt to unwind the WITH stack in the Parse object + following an error. This fixes a separate case to [de6e6d68]. + +FossilOrigin-Name: d29edef93451cc67a5d69c1cce1b1832d9ca8fff1f600afdd51338b74d077b92 +--- + sqlite3.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/sqlite3.c b/sqlite3.c +index 5bc06c8..408ec4c 100644 +--- a/sqlite3.c ++++ b/sqlite3.c +@@ -130570,7 +130570,7 @@ static int selectExpander(Walker *pWalker, Select *p){ + + /* Process NATURAL keywords, and ON and USING clauses of joins. + */ +- if( db->mallocFailed || sqliteProcessJoin(pParse, p) ){ ++ if( pParse->nErr || db->mallocFailed || sqliteProcessJoin(pParse, p) ){ + return WRC_Abort; + } + +-- +2.24.1 + diff --git a/meta/recipes-support/sqlite/sqlite3_3.29.0.bb b/meta/recipes-support/sqlite/sqlite3_3.29.0.bb index 34066fbe89..cf3b179845 100644 --- a/meta/recipes-support/sqlite/sqlite3_3.29.0.bb +++ b/meta/recipes-support/sqlite/sqlite3_3.29.0.bb @@ -4,6 +4,14 @@ LICENSE = "PD" LIC_FILES_CHKSUM = "file://sqlite3.h;endline=11;md5=786d3dc581eff03f4fd9e4a77ed00c66" SRC_URI = "http://www.sqlite.org/2019/sqlite-autoconf-${SQLITE_PV}.tar.gz \ - file://0001-Fix-CVE-2019-16168.patch" + file://0001-Fix-CVE-2019-16168.patch \ + file://CVE-2019-19244.patch \ + file://CVE-2019-19923.patch \ + file://CVE-2019-19924.patch \ + file://CVE-2019-19925.patch \ + file://CVE-2019-19926.patch \ + file://CVE-2019-19959.patch \ + file://CVE-2019-20218.patch \ +" SRC_URI[md5sum] = "8f3dfe83387e62ecb91c7c5c09c688dc" SRC_URI[sha256sum] = "8e7c1e2950b5b04c5944a981cb31fffbf9d2ddda939d536838ebc854481afd5b" -- 2.17.1 From pbarker at konsulko.com Wed Mar 11 11:31:22 2020 From: pbarker at konsulko.com (Paul Barker) Date: Wed, 11 Mar 2020 11:31:22 +0000 Subject: [OE-core] [PATCH 1/5] archiver.bbclass: Handle gitsm URLs in the mirror archiver In-Reply-To: References: <20200309142139.15741-1-pbarker@konsulko.com> <20200309142139.15741-2-pbarker@konsulko.com> Message-ID: <20200311113122.48437206@ub1910> On Tue, 10 Mar 2020 23:16:38 +0000 Richard Purdie wrote: > On Mon, 2020-03-09 at 14:21 +0000, Paul Barker wrote: > > To fully archive a `gitsm://` entry in SRC_URI we need to also capture > > the submodules recursively. If shallow mirror tarballs are found, they > > must be temporarily extracted so that the submodules can be determined. > > > > Signed-off-by: Paul Barker > > --- > > meta/classes/archiver.bbclass | 31 ++++++++++++++++++++++++++----- > > 1 file changed, 26 insertions(+), 5 deletions(-) > > > > diff --git a/meta/classes/archiver.bbclass b/meta/classes/archiver.bbclass > > index 013195df7d..fef7ad4f62 100644 > > --- a/meta/classes/archiver.bbclass > > +++ b/meta/classes/archiver.bbclass > > @@ -306,7 +306,7 @@ python do_ar_configured() { > > } > > > > python do_ar_mirror() { > > - import subprocess > > + import shutil, subprocess, tempfile > > > > src_uri = (d.getVar('SRC_URI') or '').split() > > if len(src_uri) == 0: > > @@ -337,12 +337,10 @@ python do_ar_mirror() { > > > > bb.utils.mkdirhier(destdir) > > > > - fetcher = bb.fetch2.Fetch(src_uri, d) > > - > > - for url in fetcher.urls: > > + def archive_url(fetcher, url): > > if is_excluded(url): > > bb.note('Skipping excluded url: %s' % (url)) > > - continue > > + return > > > > bb.note('Archiving url: %s' % (url)) > > ud = fetcher.ud[url] > > @@ -376,6 +374,29 @@ python do_ar_mirror() { > > bb.note('Copying source mirror') > > cmd = 'cp -fpPRH %s %s' % (localpath, destdir) > > subprocess.check_call(cmd, shell=True) > > + > > + if url.startswith('gitsm://'): > > + def archive_submodule(ud, url, module, modpath, workdir, d): > > + url += ";bareclone=1;nobranch=1" > > + newfetch = bb.fetch2.Fetch([url], d, cache=False) > > + > > + for url in newfetch.urls: > > + archive_url(newfetch, url) > > + > > + # If we're using a shallow mirror tarball it needs to be unpacked > > + # temporarily so that we can examine the .gitmodules file > > + if ud.shallow and os.path.exists(ud.fullshallow) and ud.method.need_update(ud, d): > > + tmpdir = tempfile.mkdtemp(dir=d.getVar("DL_DIR")) > > + subprocess.check_call("tar -xzf %s" % ud.fullshallow, cwd=tmpdir, shell=True) > > + ud.method.process_submodules(ud, tmpdir, archive_submodule, d) > > + shutil.rmtree(tmpdir) > > + else: > > + ud.method.process_submodules(ud, ud.clonedir, archive_submodule, d) > > + > > + fetcher = bb.fetch2.Fetch(src_uri, d, cache=False) > > + > > + for url in fetcher.urls: > > + archive_url(fetcher, url) > > } > > I can't help feeling that this is basically a sign the fetcher is > broken. > > What should really happen here is that there should be a method in the > fetcher we call into. > > Instead we're teaching code how to hack around the fetcher. Would it be > possible to add some API we could call into here and maintain integrity > of the fetcher API? This is gitsm-specific so the process_submodules method is probably the correct fetcher API. We need to call back into an archiver-supplied function for each submodule that is found. I guess process_submodules could do the temporary unpacking of the shallow archive and then this code would be simplified. Is that what you had in mind? -- Paul Barker Konsulko Group From trevor.gamblin at windriver.com Wed Mar 11 11:32:35 2020 From: trevor.gamblin at windriver.com (Trevor Gamblin) Date: Wed, 11 Mar 2020 04:32:35 -0700 Subject: [OE-core] [PATCH 2/2 v5] ptest-packagelists.inc: add coreutils to SLOW In-Reply-To: <20200311113235.61655-1-trevor.gamblin@windriver.com> References: <20200311113235.61655-1-trevor.gamblin@windriver.com> Message-ID: <20200311113235.61655-3-trevor.gamblin@windriver.com> Signed-off-by: Trevor Gamblin --- meta/conf/distro/include/ptest-packagelists.inc | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/conf/distro/include/ptest-packagelists.inc b/meta/conf/distro/include/ptest-packagelists.inc index d6f3aafc7f..c13ff724b1 100644 --- a/meta/conf/distro/include/ptest-packagelists.inc +++ b/meta/conf/distro/include/ptest-packagelists.inc @@ -66,6 +66,7 @@ PTESTS_SLOW = "\ babeltrace-ptest \ babeltrace2-ptest \ busybox-ptest \ + coreutils-ptest \ dbus-test-ptest \ e2fsprogs-ptest \ glib-2.0-ptest \ -- 2.17.1 From trevor.gamblin at windriver.com Wed Mar 11 11:32:33 2020 From: trevor.gamblin at windriver.com (Trevor Gamblin) Date: Wed, 11 Mar 2020 04:32:33 -0700 Subject: [OE-core] [PATCH 0/2 v5] coreutils: add ptest support Message-ID: <20200311113235.61655-1-trevor.gamblin@windriver.com> Note that this patch set does not include Richard's "coreutils hack" patch, so that will have to be added on top (as discussed in #yocto). Sample test results: core-image-minimal: MACHINE | PASS | FAIL | SKIP | TOTAL | TIME (m) | qemux86-64 | 470 | 0 | 144 | 614 | 2.5 | qemuarm64 | 470 | 0 | 144 | 614 | 51 | core-image-sato: MACHINE | PASS | FAIL | SKIP | TOTAL | Time (m) | qemux86-64 | 472 | 0 | 142 | 614 | 2.4 | qemuarm64 | 472 | 0 | 142 | 614 | 52 | Trevor Gamblin (2): coreutils: add ptest ptest-packagelists.inc: add coreutils to SLOW .../distro/include/ptest-packagelists.inc | 1 + .../coreutils/coreutils/run-ptest | 17 +++++++ meta/recipes-core/coreutils/coreutils_8.31.bb | 44 +++++++++++++++++++ 3 files changed, 62 insertions(+) create mode 100755 meta/recipes-core/coreutils/coreutils/run-ptest -- 2.17.1 From trevor.gamblin at windriver.com Wed Mar 11 11:32:34 2020 From: trevor.gamblin at windriver.com (Trevor Gamblin) Date: Wed, 11 Mar 2020 04:32:34 -0700 Subject: [OE-core] [PATCH 1/2 v5] coreutils: add ptest In-Reply-To: <20200311113235.61655-1-trevor.gamblin@windriver.com> References: <20200311113235.61655-1-trevor.gamblin@windriver.com> Message-ID: <20200311113235.61655-2-trevor.gamblin@windriver.com> coreutils has a large number of tests, including some added by the Makefile flags RUN_EXPENSIVE_TESTS and RUN_VERY_EXPENSIVE_TESTS that significantly increase runtime (and that have been disabled). Note that the coreutils ptest directory is given blanket permissions at runtime with chmod -R 777 to ensure that the user created for the tests will be able to run the test scripts and create the necessary files in the process. There is still room to improve the results of this ptest without the aforementioned additions. Of the tests marked SKIP, there are 30 tests that are currently counted as SKIP because they require sudo permissions, and another 21 that require membership in multiple user groups. It is important to know that coreutils has tests for both root and non-root users. Testing showed that 42 tests are skipped when running as root versus 30 when running as a non-root user, so the decision was made to run the suite as the latter. Additionally, gdb, valgrind, and strace could be included in the RDEPENDS list to increase pass rate, but their total contribution is 13 tests, so they were omitted to reduce image size. Finally, note that at least one ptest (misc/head-write-error.sh) is prone to ERROR on builds of core-image-minimal if extra space is not provided with IMAGE_ROOTFS_EXTRA_SPACE. Signed-off-by: Trevor Gamblin --- .../coreutils/coreutils/run-ptest | 17 ++++++++ meta/recipes-core/coreutils/coreutils_8.31.bb | 40 +++++++++++++++++++ 2 files changed, 57 insertions(+) create mode 100755 meta/recipes-core/coreutils/coreutils/run-ptest diff --git a/meta/recipes-core/coreutils/coreutils/run-ptest b/meta/recipes-core/coreutils/coreutils/run-ptest new file mode 100755 index 0000000000..6d4a7b365d --- /dev/null +++ b/meta/recipes-core/coreutils/coreutils/run-ptest @@ -0,0 +1,17 @@ +#!/bin/sh + +# remove any stale lock files so that the calls to groupadd/useradd don't stop +# the ptest if re-using the same image +rm -rf /etc/passwd.lock /etc/group.lock /etc/gshadow.lock + +COREUTILSLIB=@libdir@/coreutils +LOG="${COREUTILSLIB}/ptest/coreutils_ptest_$(date +%Y%m%d-%H%M%S).log" +USERNAME="tester" +groupadd ugroup1 +groupadd ugroup2 +useradd -G ugroup1,ugroup2 $USERNAME || echo "user $USERNAME already exists" + +su tester -c "cd ${COREUTILSLIB}/ptest && make check-TESTS top_srcdir=. srcdir=." 2>&1 | tee -a ${LOG} +userdel $USERNAME +groupdel ugroup1 +groupdel ugroup2 diff --git a/meta/recipes-core/coreutils/coreutils_8.31.bb b/meta/recipes-core/coreutils/coreutils_8.31.bb index 57b2c1bdba..cba0bfe15c 100644 --- a/meta/recipes-core/coreutils/coreutils_8.31.bb +++ b/meta/recipes-core/coreutils/coreutils_8.31.bb @@ -18,6 +18,7 @@ SRC_URI = "${GNU_MIRROR}/coreutils/${BP}.tar.xz \ file://0001-uname-report-processor-and-hardware-correctly.patch \ file://disable-ls-output-quoting.patch \ file://0001-local.mk-fix-cross-compiling-problem.patch \ + file://run-ptest \ " SRC_URI_append_libc-musl = "file://strtod_fix_clash_with_strtold.patch" @@ -143,3 +144,42 @@ python __anonymous() { } BBCLASSEXTEND = "native nativesdk" + +inherit ptest + +RDEPENDS_${PN}-ptest += "bash findutils gawk liberror-perl libmodule-build-perl make perl perl-module-file-stat python3-core sed shadow" + +do_install_ptest () { + install -d ${D}${PTEST_PATH}/tests + cp -r ${S}/tests/* ${D}${PTEST_PATH}/tests + sed -i 's/ginstall/install/g' `grep -R ginstall ${D}${PTEST_PATH}/tests | awk -F: '{print $1}' | uniq` + install -d ${D}${PTEST_PATH}/build-aux + install ${S}/build-aux/test-driver ${D}${PTEST_PATH}/build-aux/ + cp ${B}/Makefile ${D}${PTEST_PATH}/ + cp ${S}/init.cfg ${D}${PTEST_PATH}/ + cp -r ${B}/src ${D}${PTEST_PATH}/ + cp -r ${S}/src/*.c ${D}${PTEST_PATH}/src + sed -i '/^VPATH/s/= .*$/= ./g' ${D}${PTEST_PATH}/Makefile + sed -i '/^PROGRAMS/s/^/#/g' ${D}${PTEST_PATH}/Makefile + sed -i '/^Makefile: /s/^.*$/Makefile:/g' ${D}${PTEST_PATH}/Makefile + sed -i '/^abs_srcdir/s/= .*$/= \$\{PWD\}/g' ${D}${PTEST_PATH}/Makefile + sed -i '/^abs_top_builddir/s/= .*$/= \$\{PWD\}/g' ${D}${PTEST_PATH}/Makefile + sed -i '/^abs_top_srcdir/s/= .*$/= \$\{PWD\}/g' ${D}${PTEST_PATH}/Makefile + sed -i '/^built_programs/s/ginstall/install/g' ${D}${PTEST_PATH}/Makefile + chmod -R 777 ${D}${PTEST_PATH} + + # Disable subcase stty-pairs.sh, it will cause test framework hang + sed -i '/stty-pairs.sh/d' ${D}${PTEST_PATH}/Makefile + + # Disable subcase tail-2/assert.sh as it has issues on 32-bit systems + sed -i '/assert.sh/d' ${D}${PTEST_PATH}/Makefile + + # Tweak test d_type-check to use python3 instead of python + sed -i "1s at .*@#!/usr/bin/python3@" ${D}${PTEST_PATH}/tests/d_type-check + install ${B}/src/getlimits ${D}/${bindir} + + # handle multilib + sed -i s:@libdir@:${libdir}:g ${D}${PTEST_PATH}/run-ptest +} + +FILES_${PN}-ptest += "${bindir}/getlimits" -- 2.17.1 From richard.purdie at linuxfoundation.org Wed Mar 11 11:38:44 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Wed, 11 Mar 2020 11:38:44 +0000 Subject: [OE-core] [PATCH 1/5] archiver.bbclass: Handle gitsm URLs in the mirror archiver In-Reply-To: <20200311113122.48437206@ub1910> References: <20200309142139.15741-1-pbarker@konsulko.com> <20200309142139.15741-2-pbarker@konsulko.com> <20200311113122.48437206@ub1910> Message-ID: <1d5f679e2c28e2858b098fde142760edcf0c2708.camel@linuxfoundation.org> On Wed, 2020-03-11 at 11:31 +0000, Paul Barker wrote: > On Tue, 10 Mar 2020 23:16:38 +0000 > Richard Purdie wrote: > > > On Mon, 2020-03-09 at 14:21 +0000, Paul Barker wrote: > > > To fully archive a `gitsm://` entry in SRC_URI we need to also capture > > > the submodules recursively. If shallow mirror tarballs are found, they > > > must be temporarily extracted so that the submodules can be determined. > > > > > > Signed-off-by: Paul Barker > > > --- > > > meta/classes/archiver.bbclass | 31 ++++++++++++++++++++++++++----- > > > 1 file changed, 26 insertions(+), 5 deletions(-) > > > > > > diff --git a/meta/classes/archiver.bbclass b/meta/classes/archiver.bbclass > > > index 013195df7d..fef7ad4f62 100644 > > > --- a/meta/classes/archiver.bbclass > > > +++ b/meta/classes/archiver.bbclass > > > @@ -306,7 +306,7 @@ python do_ar_configured() { > > > } > > > > > > python do_ar_mirror() { > > > - import subprocess > > > + import shutil, subprocess, tempfile > > > > > > src_uri = (d.getVar('SRC_URI') or '').split() > > > if len(src_uri) == 0: > > > @@ -337,12 +337,10 @@ python do_ar_mirror() { > > > > > > bb.utils.mkdirhier(destdir) > > > > > > - fetcher = bb.fetch2.Fetch(src_uri, d) > > > - > > > - for url in fetcher.urls: > > > + def archive_url(fetcher, url): > > > if is_excluded(url): > > > bb.note('Skipping excluded url: %s' % (url)) > > > - continue > > > + return > > > > > > bb.note('Archiving url: %s' % (url)) > > > ud = fetcher.ud[url] > > > @@ -376,6 +374,29 @@ python do_ar_mirror() { > > > bb.note('Copying source mirror') > > > cmd = 'cp -fpPRH %s %s' % (localpath, destdir) > > > subprocess.check_call(cmd, shell=True) > > > + > > > + if url.startswith('gitsm://'): > > > + def archive_submodule(ud, url, module, modpath, workdir, d): > > > + url += ";bareclone=1;nobranch=1" > > > + newfetch = bb.fetch2.Fetch([url], d, cache=False) > > > + > > > + for url in newfetch.urls: > > > + archive_url(newfetch, url) > > > + > > > + # If we're using a shallow mirror tarball it needs to be unpacked > > > + # temporarily so that we can examine the .gitmodules file > > > + if ud.shallow and os.path.exists(ud.fullshallow) and ud.method.need_update(ud, d): > > > + tmpdir = tempfile.mkdtemp(dir=d.getVar("DL_DIR")) > > > + subprocess.check_call("tar -xzf %s" % ud.fullshallow, cwd=tmpdir, shell=True) > > > + ud.method.process_submodules(ud, tmpdir, archive_submodule, d) > > > + shutil.rmtree(tmpdir) > > > + else: > > > + ud.method.process_submodules(ud, ud.clonedir, archive_submodule, d) > > > + > > > + fetcher = bb.fetch2.Fetch(src_uri, d, cache=False) > > > + > > > + for url in fetcher.urls: > > > + archive_url(fetcher, url) > > > } > > > > I can't help feeling that this is basically a sign the fetcher is > > broken. > > > > What should really happen here is that there should be a method in the > > fetcher we call into. > > > > Instead we're teaching code how to hack around the fetcher. Would it be > > possible to add some API we could call into here and maintain integrity > > of the fetcher API? > > This is gitsm-specific so the process_submodules method is probably the > correct fetcher API. We need to call back into an archiver-supplied function > for each submodule that is found. > > I guess process_submodules could do the temporary unpacking of the shallow > archive and then this code would be simplified. Is that what you had in mind? Nearly. The "operation" here is similar to "download" or "unpack" but amounts to "make a mirror copy". Should the fetcher have such a method, which would then have the fetcher implementation details in the fetchers themselves? Cheers, Richard From pbarker at konsulko.com Wed Mar 11 11:40:28 2020 From: pbarker at konsulko.com (Paul Barker) Date: Wed, 11 Mar 2020 11:40:28 +0000 Subject: [OE-core] [PATCH 2/5] archiver.bbclass: Make do_deploy_archives a recursive dependency In-Reply-To: References: <20200309142139.15741-1-pbarker@konsulko.com> <20200309142139.15741-3-pbarker@konsulko.com> Message-ID: <20200311114028.31344b22@ub1910> On Tue, 10 Mar 2020 23:18:33 +0000 Richard Purdie wrote: > On Mon, 2020-03-09 at 14:21 +0000, Paul Barker wrote: > > To ensure that archives are captured for all dependencies of a typical > > bitbake build we add do_deploy_archives to the list of recursive > > dependencies of do_build. Without this, archives may be missed for > > recipes such as gcc-source which do not create packages or populate a > > sysroot. > > > > do_deploy_archives is also added to the recursive dependencies of > > do_populate_sdk so that all sources required for an SDK can be captured. > > > > Signed-off-by: Paul Barker > > --- > > meta/classes/archiver.bbclass | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/meta/classes/archiver.bbclass b/meta/classes/archiver.bbclass > > index fef7ad4f62..c11d36d708 100644 > > --- a/meta/classes/archiver.bbclass > > +++ b/meta/classes/archiver.bbclass > > @@ -604,7 +604,9 @@ addtask do_ar_configured after do_unpack_and_patch > > addtask do_ar_mirror after do_fetch > > addtask do_dumpdata > > addtask do_ar_recipe > > -addtask do_deploy_archives before do_build > > +addtask do_deploy_archives > > +do_build[recrdeptask] += "do_deploy_archives" > > +do_populate_sdk[recrdeptask] += "do_deploy_archives" > > We implemented the --runall option to bitbake to try and avoid having > recrdeptask versions of most tasks. Does that not work here? It should > also work for the SDK I think? If the archiver is enabled, its tasks should be in the dependency tree of whatever you're building so that you don't need to invoke bitbake twice to produce the required artifacts. For images that's the way the archiver has always worked, if it's enabled then you just need to do `bitbake image` to build the image and deploy the source archives. This change just extends that behaviour to cover other things we can build and ensures that we don't miss sources for recipes like gcc-source. -- Paul Barker Konsulko Group From richard.purdie at linuxfoundation.org Wed Mar 11 11:44:21 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Wed, 11 Mar 2020 11:44:21 +0000 Subject: [OE-core] [PATCH] coreutils: Fix -dev package dependencies Message-ID: <20200311114421.65442-1-richard.purdie@linuxfoundation.org> The new ptest dependencies present some challenges, in particular libmodule-build-perl which effectively depends on gcc. In multilib images, this results in both libXX-gcc-symlinks and libYY-gcc-symlinks being installed which conflict. This also makes little sense. The easiest way to fix this is to disable the automatic -dev package dependencies and manually specify the correct ones. Signed-off-by: Richard Purdie --- meta/recipes-core/coreutils/coreutils_8.31.bb | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/meta/recipes-core/coreutils/coreutils_8.31.bb b/meta/recipes-core/coreutils/coreutils_8.31.bb index cba0bfe15cc..eac016319eb 100644 --- a/meta/recipes-core/coreutils/coreutils_8.31.bb +++ b/meta/recipes-core/coreutils/coreutils_8.31.bb @@ -149,6 +149,10 @@ inherit ptest RDEPENDS_${PN}-ptest += "bash findutils gawk liberror-perl libmodule-build-perl make perl perl-module-file-stat python3-core sed shadow" +# -dev automatic dependencies fails as we don't want libmodule-build-perl-dev, its too heavy +RRECOMMENDS_coreutils-dev[nodeprrecs] = "1" +RRECOMMENDS_coreutils-dev = "acl-dev attr-dev gmp-dev libcap-dev bash-dev findutils-dev gawk-dev shadow-dev" + do_install_ptest () { install -d ${D}${PTEST_PATH}/tests cp -r ${S}/tests/* ${D}${PTEST_PATH}/tests -- 2.25.0 From pbarker at konsulko.com Wed Mar 11 11:50:25 2020 From: pbarker at konsulko.com (Paul Barker) Date: Wed, 11 Mar 2020 11:50:25 +0000 Subject: [OE-core] [PATCH 1/5] archiver.bbclass: Handle gitsm URLs in the mirror archiver In-Reply-To: <1d5f679e2c28e2858b098fde142760edcf0c2708.camel@linuxfoundation.org> References: <20200309142139.15741-1-pbarker@konsulko.com> <20200309142139.15741-2-pbarker@konsulko.com> <20200311113122.48437206@ub1910> <1d5f679e2c28e2858b098fde142760edcf0c2708.camel@linuxfoundation.org> Message-ID: <20200311115025.56045856@ub1910> On Wed, 11 Mar 2020 11:38:44 +0000 Richard Purdie wrote: > On Wed, 2020-03-11 at 11:31 +0000, Paul Barker wrote: > > On Tue, 10 Mar 2020 23:16:38 +0000 > > Richard Purdie wrote: > > > > > On Mon, 2020-03-09 at 14:21 +0000, Paul Barker wrote: > > > > To fully archive a `gitsm://` entry in SRC_URI we need to also capture > > > > the submodules recursively. If shallow mirror tarballs are found, they > > > > must be temporarily extracted so that the submodules can be determined. > > > > > > > > Signed-off-by: Paul Barker > > > > --- > > > > meta/classes/archiver.bbclass | 31 ++++++++++++++++++++++++++----- > > > > 1 file changed, 26 insertions(+), 5 deletions(-) > > > > > > > > diff --git a/meta/classes/archiver.bbclass b/meta/classes/archiver.bbclass > > > > index 013195df7d..fef7ad4f62 100644 > > > > --- a/meta/classes/archiver.bbclass > > > > +++ b/meta/classes/archiver.bbclass > > > > @@ -306,7 +306,7 @@ python do_ar_configured() { > > > > } > > > > > > > > python do_ar_mirror() { > > > > - import subprocess > > > > + import shutil, subprocess, tempfile > > > > > > > > src_uri = (d.getVar('SRC_URI') or '').split() > > > > if len(src_uri) == 0: > > > > @@ -337,12 +337,10 @@ python do_ar_mirror() { > > > > > > > > bb.utils.mkdirhier(destdir) > > > > > > > > - fetcher = bb.fetch2.Fetch(src_uri, d) > > > > - > > > > - for url in fetcher.urls: > > > > + def archive_url(fetcher, url): > > > > if is_excluded(url): > > > > bb.note('Skipping excluded url: %s' % (url)) > > > > - continue > > > > + return > > > > > > > > bb.note('Archiving url: %s' % (url)) > > > > ud = fetcher.ud[url] > > > > @@ -376,6 +374,29 @@ python do_ar_mirror() { > > > > bb.note('Copying source mirror') > > > > cmd = 'cp -fpPRH %s %s' % (localpath, destdir) > > > > subprocess.check_call(cmd, shell=True) > > > > + > > > > + if url.startswith('gitsm://'): > > > > + def archive_submodule(ud, url, module, modpath, workdir, d): > > > > + url += ";bareclone=1;nobranch=1" > > > > + newfetch = bb.fetch2.Fetch([url], d, cache=False) > > > > + > > > > + for url in newfetch.urls: > > > > + archive_url(newfetch, url) > > > > + > > > > + # If we're using a shallow mirror tarball it needs to be unpacked > > > > + # temporarily so that we can examine the .gitmodules file > > > > + if ud.shallow and os.path.exists(ud.fullshallow) and ud.method.need_update(ud, d): > > > > + tmpdir = tempfile.mkdtemp(dir=d.getVar("DL_DIR")) > > > > + subprocess.check_call("tar -xzf %s" % ud.fullshallow, cwd=tmpdir, shell=True) > > > > + ud.method.process_submodules(ud, tmpdir, archive_submodule, d) > > > > + shutil.rmtree(tmpdir) > > > > + else: > > > > + ud.method.process_submodules(ud, ud.clonedir, archive_submodule, d) > > > > + > > > > + fetcher = bb.fetch2.Fetch(src_uri, d, cache=False) > > > > + > > > > + for url in fetcher.urls: > > > > + archive_url(fetcher, url) > > > > } > > > > > > I can't help feeling that this is basically a sign the fetcher is > > > broken. > > > > > > What should really happen here is that there should be a method in the > > > fetcher we call into. > > > > > > Instead we're teaching code how to hack around the fetcher. Would it be > > > possible to add some API we could call into here and maintain integrity > > > of the fetcher API? > > > > This is gitsm-specific so the process_submodules method is probably the > > correct fetcher API. We need to call back into an archiver-supplied function > > for each submodule that is found. > > > > I guess process_submodules could do the temporary unpacking of the shallow > > archive and then this code would be simplified. Is that what you had in mind? > > > Nearly. The "operation" here is similar to "download" or "unpack" but > amounts to "make a mirror copy". Should the fetcher have such a method, > which would then have the fetcher implementation details in the > fetchers themselves? I structured things this way after the discussions we've had previously about not wanting to add too many new code paths to the fetcher. I'd also like to keep the logic in a bbclass as much as possible so that it can be more easily carried as a local backport to earlier Yocto Project releases. I do see your point though, this is liable to grow warts over time as special cases are added for different fetchers. The cause of the warts here is that the gitsm fetcher downloads and creates mirror tarballs for sources which aren't listed in SRC_URI. The archiver would be simpler if we could assume that all sources are included in SRC_URI. Perhaps the solution is not to add a "make a mirror copy" API but instead add an "expand SRC_URI with any dependencies" API that the archiver can call before it iterates over the list of sources. -- Paul Barker Konsulko Group From richard.purdie at linuxfoundation.org Wed Mar 11 11:53:04 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Wed, 11 Mar 2020 11:53:04 +0000 Subject: [OE-core] [PATCH 1/5] archiver.bbclass: Handle gitsm URLs in the mirror archiver In-Reply-To: <20200311115025.56045856@ub1910> References: <20200309142139.15741-1-pbarker@konsulko.com> <20200309142139.15741-2-pbarker@konsulko.com> <20200311113122.48437206@ub1910> <1d5f679e2c28e2858b098fde142760edcf0c2708.camel@linuxfoundation.org> <20200311115025.56045856@ub1910> Message-ID: <05d49916fe80df0b5e085113873d678c10270f40.camel@linuxfoundation.org> On Wed, 2020-03-11 at 11:50 +0000, Paul Barker wrote: > I structured things this way after the discussions we've had previously about > not wanting to add too many new code paths to the fetcher. I'd also like to > keep the logic in a bbclass as much as possible so that it can be more easily > carried as a local backport to earlier Yocto Project releases. > > I do see your point though, this is liable to grow warts over time as special > cases are added for different fetchers. I appreciate the previous discussions, but yes, this is my concern. > The cause of the warts here is that the gitsm fetcher downloads and creates > mirror tarballs for sources which aren't listed in SRC_URI. The archiver > would be simpler if we could assume that all sources are included in SRC_URI. > Perhaps the solution is not to add a "make a mirror copy" API but instead add > an "expand SRC_URI with any dependencies" API that the archiver can call > before it iterates over the list of sources. Yes, that sounds like good insight into the real issue and would make sense, I think that would improve things and alleviate my concerns. Cheers, Richard From patchwork at patchwork.openembedded.org Wed Mar 11 12:02:32 2020 From: patchwork at patchwork.openembedded.org (Patchwork) Date: Wed, 11 Mar 2020 12:02:32 -0000 Subject: [OE-core] =?utf-8?q?=E2=9C=97_patchtest=3A_failure_for_coreutils?= =?utf-8?q?=3A_Fix_-dev_package_dependencies?= In-Reply-To: <20200311114421.65442-1-richard.purdie@linuxfoundation.org> References: <20200311114421.65442-1-richard.purdie@linuxfoundation.org> Message-ID: <20200311120232.2276.15029@do> == Series Details == Series: coreutils: Fix -dev package dependencies Revision: 1 URL : https://patchwork.openembedded.org/series/23199/ 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 fix Rebase your series on top of targeted branch Targeted branch master (currently at 04ee0e8b95) If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core at 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 From bruce.ashfield at gmail.com Wed Mar 11 12:36:09 2020 From: bruce.ashfield at gmail.com (Bruce Ashfield) Date: Wed, 11 Mar 2020 08:36:09 -0400 Subject: [OE-core] CVE related consulting on linux-yocto on zeus branch In-Reply-To: References: Message-ID: On Wed, Mar 11, 2020 at 2:02 AM zangrc wrote: > > > Hello, > > > our team is currently working on CVE-related work. I would like to ask > if the zeus branch of yocto has an update plan for linux-yocto in the > near future. If not, can we submit a CVE-related patch for the > linux-yocto of the zeus branch. If it is part of -stable, then yes, it will be integrated into any of the active upstream kernels. If it is in 5.2, we also have a -stable process for those kernels as well. If it doesn't fall into those categories, then send any patches (against the kernel itself) to the linux-yocto mailing list, do not send them as patches to the linux-yocto recipe itself. Cheers, Bruce > > -- > Best Regards! > Zang Ruochen > > > -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II From mingli.yu at windriver.com Wed Mar 11 13:49:33 2020 From: mingli.yu at windriver.com (mingli.yu at windriver.com) Date: Wed, 11 Mar 2020 21:49:33 +0800 Subject: [OE-core] [PATCH] babeltrace2: initialize the other_entry pointer Message-ID: <1583934573-94011-1-git-send-email-mingli.yu@windriver.com> From: Mingli Yu When add below line to local.conf to enable debug build: DEBUG_BUILD = "1" There comes below failure when run "bitbake babeltrace2" | ../../../../../git/src/plugins/ctf/fs-src/fs.c: In function 'ds_index_insert_ds_index_entry_sorted': | ../../../../../git/src/plugins/ctf/fs-src/fs.c:702:5: error: 'other_entry' may be used uninitialized in this function [-Werror=maybe-uninitialized] | 702 | !ds_index_entries_equal(entry, other_entry)) { So initialize the other_entry pointer to fix the above error. Signed-off-by: Mingli Yu --- .../0001-fs.c-initialize-other_entry.patch | 33 ++++++++++++++++++++++ meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb | 1 + 2 files changed, 34 insertions(+) create mode 100644 meta/recipes-kernel/lttng/babeltrace2/0001-fs.c-initialize-other_entry.patch diff --git a/meta/recipes-kernel/lttng/babeltrace2/0001-fs.c-initialize-other_entry.patch b/meta/recipes-kernel/lttng/babeltrace2/0001-fs.c-initialize-other_entry.patch new file mode 100644 index 0000000..b56b3bd --- /dev/null +++ b/meta/recipes-kernel/lttng/babeltrace2/0001-fs.c-initialize-other_entry.patch @@ -0,0 +1,33 @@ +From 42dae692b9057d03ce9a0651f061472e9dd90130 Mon Sep 17 00:00:00 2001 +From: Mingli Yu +Date: Wed, 11 Mar 2020 08:44:42 +0000 +Subject: [PATCH] fs.c: initialize the other_entry variable + +Initialize the pointer other_entry to fix the below error: +| ../../../../../git/src/plugins/ctf/fs-src/fs.c: In function 'ds_index_insert_ds_index_entry_sorted': +| ../../../../../git/src/plugins/ctf/fs-src/fs.c:702:5: error: 'other_entry' may be used uninitialized in this function [-Werror=maybe-uninitialized] +| 702 | !ds_index_entries_equal(entry, other_entry)) { + +Upstream-Status: Submitted [https://lists.lttng.org/pipermail/lttng-dev/2020-March/029549.html] + +Signed-off-by: Mingli Yu +--- + src/plugins/ctf/fs-src/fs.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/src/plugins/ctf/fs-src/fs.c b/src/plugins/ctf/fs-src/fs.c +index e87523a3..a6b5315f 100644 +--- a/src/plugins/ctf/fs-src/fs.c ++++ b/src/plugins/ctf/fs-src/fs.c +@@ -680,7 +680,7 @@ void ds_index_insert_ds_index_entry_sorted( + struct ctf_fs_ds_index_entry *entry) + { + guint i; +- struct ctf_fs_ds_index_entry *other_entry; ++ struct ctf_fs_ds_index_entry *other_entry = NULL; + + /* Find the spot where to insert this index entry. */ + for (i = 0; i < index->entries->len; i++) { +-- +2.24.1 + diff --git a/meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb b/meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb index 16953d6..c027d8b 100644 --- a/meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb +++ b/meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb @@ -10,6 +10,7 @@ DEPENDS = "glib-2.0 util-linux popt bison-native flex-native" SRC_URI = "git://git.linuxfoundation.org/diamon/babeltrace.git;branch=stable-2.0 \ file://run-ptest \ file://0001-tests-do-not-run-test-applications-from-.libs.patch \ + file://0001-fs.c-initialize-other_entry.patch \ " SRCREV = "06df58f89ee51b1a2c6a2c187ec3f15691633910" UPSTREAM_CHECK_GITTAGREGEX = "v(?P2(\.\d+)+)$" -- 2.7.4 From ross at burtonini.com Wed Mar 11 14:53:39 2020 From: ross at burtonini.com (Ross Burton) Date: Wed, 11 Mar 2020 14:53:39 +0000 Subject: [OE-core] [Openembedded-architecture] Does YP provide security support for stable and LTS branches? In-Reply-To: <1c4e1685-7b74-0dea-e08f-4887fca9eb66@embexus.com> References: <20200304113217.GB7923@localhost> <20200304140109.GC7923@localhost> <20200304172415.GA29456@localhost> <01b3bb37-f65f-8048-1a27-b859b62d7f98@gmail.com> <20200306100422.GA17785@localhost> <877e317932176664bc7b0120439c56d4dda791af.camel@linuxfoundation.org> <20200308214610.GB1425@localhost> <20200309002308.GD1425@localhost> <1c4e1685-7b74-0dea-e08f-4887fca9eb66@embexus.com> Message-ID: On Tue, 10 Mar 2020 at 19:45, Ayoub Zaki wrote: > Security patches support is definitely for many companies a knock-out criterion. > Probably in this case Debian or a commercial OSes like Qnx would be a choice for who can afford it. If someone is using Yocto commercially and willing to pay money, then they are entirely welcome to use a OSV such as Mentor/Wind River/Montavista/etc who *will* make firm commitments on security issues. Ross From sakib.sajal at windriver.com Wed Mar 11 14:58:38 2020 From: sakib.sajal at windriver.com (Sakib Sajal) Date: Wed, 11 Mar 2020 07:58:38 -0700 Subject: [OE-core] [meta-oe][PATCH] openjpeg: Fix CVE-2020-6851 Message-ID: <20200311145838.129361-1-sakib.sajal@windriver.com> From: Yue Tao Backport patch from upstream to fix heap-based buffer overflow Signed-off-by: Yue Tao Signed-off-by: Sakib Sajal --- .../openjpeg/openjpeg/CVE-2020-6851.patch | 32 +++++++++++++++++++ .../openjpeg/openjpeg_2.3.1.bb | 1 + 2 files changed, 33 insertions(+) create mode 100644 meta-oe/recipes-graphics/openjpeg/openjpeg/CVE-2020-6851.patch diff --git a/meta-oe/recipes-graphics/openjpeg/openjpeg/CVE-2020-6851.patch b/meta-oe/recipes-graphics/openjpeg/openjpeg/CVE-2020-6851.patch new file mode 100644 index 000000000..9f2fc901f --- /dev/null +++ b/meta-oe/recipes-graphics/openjpeg/openjpeg/CVE-2020-6851.patch @@ -0,0 +1,32 @@ +From 024b8407392cb0b82b04b58ed256094ed5799e04 Mon Sep 17 00:00:00 2001 +From: Even Rouault +Date: Sat, 11 Jan 2020 01:51:19 +0100 +Subject: [PATCH] opj_j2k_update_image_dimensions(): reject images whose + coordinates are beyond INT_MAX (fixes #1228) + +--- + src/lib/openjp2/j2k.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +diff --git a/src/lib/openjp2/j2k.c b/src/lib/openjp2/j2k.c +index 14f6ff41..922550eb 100644 +--- a/src/lib/openjp2/j2k.c ++++ b/src/lib/openjp2/j2k.c +@@ -9236,6 +9236,14 @@ static OPJ_BOOL opj_j2k_update_image_dim + l_img_comp = p_image->comps; + for (it_comp = 0; it_comp < p_image->numcomps; ++it_comp) { + OPJ_INT32 l_h, l_w; ++ if (p_image->x0 > (OPJ_UINT32)INT_MAX || ++ p_image->y0 > (OPJ_UINT32)INT_MAX || ++ p_image->x1 > (OPJ_UINT32)INT_MAX || ++ p_image->y1 > (OPJ_UINT32)INT_MAX) { ++ opj_event_msg(p_manager, EVT_ERROR, ++ "Image coordinates above INT_MAX are not supported\n"); ++ return OPJ_FALSE; ++ } + + l_img_comp->x0 = (OPJ_UINT32)opj_int_ceildiv((OPJ_INT32)p_image->x0, + (OPJ_INT32)l_img_comp->dx); +-- +2.17.1 + diff --git a/meta-oe/recipes-graphics/openjpeg/openjpeg_2.3.1.bb b/meta-oe/recipes-graphics/openjpeg/openjpeg_2.3.1.bb index ffd4099b4..4045148dd 100644 --- a/meta-oe/recipes-graphics/openjpeg/openjpeg_2.3.1.bb +++ b/meta-oe/recipes-graphics/openjpeg/openjpeg_2.3.1.bb @@ -8,6 +8,7 @@ DEPENDS = "libpng tiff lcms zlib" SRC_URI = " \ git://github.com/uclouvain/openjpeg.git \ file://0002-Do-not-ask-cmake-to-export-binaries-they-don-t-make-.patch \ + file://CVE-2020-6851.patch \ " SRCREV = "57096325457f96d8cd07bd3af04fe81d7a2ba788" S = "${WORKDIR}/git" -- 2.24.1 From patchwork at patchwork.openembedded.org Wed Mar 11 15:02:33 2020 From: patchwork at patchwork.openembedded.org (Patchwork) Date: Wed, 11 Mar 2020 15:02:33 -0000 Subject: [OE-core] =?utf-8?q?=E2=9C=97_patchtest=3A_failure_for_openjpeg?= =?utf-8?q?=3A_Fix_CVE-2020-6851?= In-Reply-To: <20200311145838.129361-1-sakib.sajal@windriver.com> References: <20200311145838.129361-1-sakib.sajal@windriver.com> Message-ID: <20200311150233.2277.74214@do> == Series Details == Series: openjpeg: Fix CVE-2020-6851 Revision: 1 URL : https://patchwork.openembedded.org/series/23201/ 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: * Patch [meta-oe] openjpeg: Fix CVE-2020-6851 Issue Series sent to the wrong mailing list [test_target_mailing_list] Suggested fix Check the project's README (meta-oe) and send the patch to the indicated list * Issue Series does not apply on top of target branch [test_series_merge_on_head] Suggested fix Rebase your series on top of targeted branch Targeted branch master (currently at baecda5b32) * Patch [meta-oe] openjpeg: Fix CVE-2020-6851 Issue Missing or incorrectly formatted CVE tag in included patch file [test_cve_tag_format] Suggested fix Correct or include the CVE tag on cve patch with format: "CVE: CVE-YYYY-XXXX" * Issue A patch file has been added, but does not have a Signed-off-by tag [test_signed_off_by_presence] Suggested fix Sign off the added patch file (meta-oe/recipes-graphics/openjpeg/openjpeg/CVE-2020-6851.patch) * Issue Added patch file is missing Upstream-Status in the header [test_upstream_status_presence_format] Suggested fix Add Upstream-Status: to the header of meta-oe/recipes-graphics/openjpeg/openjpeg/CVE-2020-6851.patch Standard format Upstream-Status: Valid status Pending, Accepted, Backport, Denied, Inappropriate [reason], Submitted [where] If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core at 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 From sk at typedivision.de Wed Mar 11 16:36:49 2020 From: sk at typedivision.de (Stefan Kral) Date: Wed, 11 Mar 2020 17:36:49 +0100 Subject: [OE-core] [PATCH] oeqa/runtime/context.py: fix typo Message-ID: <20200311163649.78011-1-sk@typedivision.de> Signed-off-by: Stefan Kral --- meta/lib/oeqa/runtime/context.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/lib/oeqa/runtime/context.py b/meta/lib/oeqa/runtime/context.py index 2ecb1a8f01..101434a595 100644 --- a/meta/lib/oeqa/runtime/context.py +++ b/meta/lib/oeqa/runtime/context.py @@ -77,7 +77,7 @@ class OERuntimeTestContextExecutor(OETestContextExecutor): runtime_group.add_argument('--packages-manifest', action='store', default=self.default_manifest, - help="Package manifest of the image under testi, default: %s" \ + help="Package manifest of the image under test, default: %s" \ % self.default_manifest) runtime_group.add_argument('--extract-dir', action='store', @@ -184,7 +184,7 @@ class OERuntimeTestContextExecutor(OETestContextExecutor): except: obj = None return obj - + @staticmethod def readPackagesManifest(manifest): if not manifest or not os.path.exists(manifest): -- 2.17.2 (Apple Git-113) From sk at typedivision.de Wed Mar 11 16:37:30 2020 From: sk at typedivision.de (Stefan Kral) Date: Wed, 11 Mar 2020 17:37:30 +0100 Subject: [OE-core] [PATCH] oeqa: enable testresults.json for testexport Message-ID: <20200311163730.78078-1-sk@typedivision.de> Add the option --json-result-dir to oeqa core context to enable testresults.json creation for test runs via testexport. Eg. oe-test runtime --json-result-dir . Signed-off-by: Stefan Kral --- meta/lib/oeqa/core/context.py | 30 +++++++++++++++++++++++++++++- meta/lib/oeqa/core/runner.py | 13 ++++++++++--- 2 files changed, 39 insertions(+), 4 deletions(-) diff --git a/meta/lib/oeqa/core/context.py b/meta/lib/oeqa/core/context.py index 16320af115..b9a28ce319 100644 --- a/meta/lib/oeqa/core/context.py +++ b/meta/lib/oeqa/core/context.py @@ -116,6 +116,9 @@ class OETestContextExecutor(object): default=self.default_output_log, help="results output log, default: %s" % self.default_output_log) + self.parser.add_argument('--json-result-dir', action='store', + help="json result output dir, create testresults.json here if set") + group = self.parser.add_mutually_exclusive_group() group.add_argument('--run-tests', action='store', nargs='+', default=self.default_tests, @@ -178,6 +181,22 @@ class OETestContextExecutor(object): self.module_paths = args.CASES_PATHS + def _get_json_result_dir(self, args): + return args.json_result_dir + + def _get_configuration(self): + td = self.tc_kwargs['init']['td'] + configuration = {'TEST_TYPE': self.name, + 'MACHINE': td.get("MACHINE"), + 'DISTRO': td.get("DISTRO"), + 'IMAGE_BASENAME': td.get("IMAGE_BASENAME"), + 'DATETIME': td.get("DATETIME")} + return configuration + + def _get_result_id(self, configuration): + return '%s_%s_%s_%s' % (configuration['TEST_TYPE'], configuration['IMAGE_BASENAME'], + configuration['MACHINE'], configuration['DATETIME']) + def _pre_run(self): pass @@ -196,7 +215,16 @@ class OETestContextExecutor(object): else: self._pre_run() rc = self.tc.runTests(**self.tc_kwargs['run']) - rc.logDetails() + + json_result_dir = self._get_json_result_dir(args) + if json_result_dir: + configuration = self._get_configuration() + rc.logDetails(json_result_dir, + configuration, + self._get_result_id(configuration)) + else: + rc.logDetails() + rc.logSummary(self.name) output_link = os.path.join(os.path.dirname(args.output_log), diff --git a/meta/lib/oeqa/core/runner.py b/meta/lib/oeqa/core/runner.py index f656e1a9c5..fc3872aa73 100644 --- a/meta/lib/oeqa/core/runner.py +++ b/meta/lib/oeqa/core/runner.py @@ -319,10 +319,17 @@ class OETestResultJSONHelper(object): the_file.write(file_content) def dump_testresult_file(self, write_dir, configuration, result_id, test_result): - bb.utils.mkdirhier(write_dir) - lf = bb.utils.lockfile(os.path.join(write_dir, 'jsontestresult.lock')) + try: + import bb + has_bb = True + lf = bb.utils.lockfile(os.path.join(write_dir, 'jsontestresult.lock')) + bb.utils.mkdirhier(write_dir, exist_ok=True) + except ImportError: + has_bb = False + os.makedirs(write_dir) test_results = self._get_existing_testresults_if_available(write_dir) test_results[result_id] = {'configuration': configuration, 'result': test_result} json_testresults = json.dumps(test_results, sort_keys=True, indent=4) self._write_file(write_dir, self.testresult_filename, json_testresults) - bb.utils.unlockfile(lf) + if has_bb: + bb.utils.unlockfile(lf) -- 2.17.2 (Apple Git-113) From pjtexier at koncepto.io Wed Mar 11 16:38:38 2020 From: pjtexier at koncepto.io (Pierre-Jean Texier) Date: Wed, 11 Mar 2020 17:38:38 +0100 Subject: [OE-core] [PATCH] curl: upgrade 7.69.0 -> 7.69.1 Message-ID: <1583944718-9485-1-git-send-email-pjtexier@koncepto.io> Contains a number of fixes for issues discovered post-7.69.0. For details, see full changelog: https://curl.haxx.se/changes.html#7_69_1 Signed-off-by: Pierre-Jean Texier --- meta/recipes-support/curl/{curl_7.69.0.bb => curl_7.69.1.bb} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename meta/recipes-support/curl/{curl_7.69.0.bb => curl_7.69.1.bb} (95%) diff --git a/meta/recipes-support/curl/curl_7.69.0.bb b/meta/recipes-support/curl/curl_7.69.1.bb similarity index 95% rename from meta/recipes-support/curl/curl_7.69.0.bb rename to meta/recipes-support/curl/curl_7.69.1.bb index cf4f4bc..49e180c 100644 --- a/meta/recipes-support/curl/curl_7.69.0.bb +++ b/meta/recipes-support/curl/curl_7.69.1.bb @@ -9,8 +9,8 @@ SRC_URI = "http://curl.haxx.se/download/curl-${PV}.tar.bz2 \ file://0001-replace-krb5-config-with-pkg-config.patch \ " -SRC_URI[md5sum] = "04eb86d1138c2ff3dbfd497f7de85daa" -SRC_URI[sha256sum] = "668d451108a7316cff040b23c79bc766e7ed84122074e44f662b8982f2e76739" +SRC_URI[md5sum] = "ec5fc263f898a3dfef08e805f1ecca42" +SRC_URI[sha256sum] = "2ff5e5bd507adf6aa88ff4bbafd4c7af464867ffb688be93b9930717a56c4de8" CVE_PRODUCT = "curl libcurl" inherit autotools pkgconfig binconfig multilib_header -- 2.7.4 From domarys.correa at ossystems.com.br Wed Mar 11 16:52:21 2020 From: domarys.correa at ossystems.com.br (Domarys Correa) Date: Wed, 11 Mar 2020 13:52:21 -0300 Subject: [OE-core] [PATCH] weston-init: Allow use of weston without input devices Message-ID: <20200311165221.23475-1-domarys.correa@ossystems.com.br> Don't force users to have input device in your targets. As the default option require-input is set to true, Weston only starts if we have a device in /dev/input/event* and this not a requirement for all applications, e.g. kiosk browser. Signed-off-by: Domarys Correa --- meta/recipes-graphics/wayland/weston-init/weston.ini | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/meta/recipes-graphics/wayland/weston-init/weston.ini b/meta/recipes-graphics/wayland/weston-init/weston.ini index 1eecf48bc1..1e6dff68fd 100644 --- a/meta/recipes-graphics/wayland/weston-init/weston.ini +++ b/meta/recipes-graphics/wayland/weston-init/weston.ini @@ -1,9 +1,10 @@ # configuration file for Weston -#[core] +[core] #modules=xwayland.so,cms-colord.so #shell=desktop-shell.so #gbm-format=xrgb2101010 +require-input=false #[shell] #background-image=/usr/share/backgrounds/gnome/Aqua.jpg -- 2.17.1 From richard.purdie at linuxfoundation.org Wed Mar 11 17:20:33 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Wed, 11 Mar 2020 17:20:33 +0000 Subject: [OE-core] psplash activation state w/ systemd In-Reply-To: References: Message-ID: <5e5adb83812fe98a76b8207588325f7996e33c85.camel@linuxfoundation.org> On Mon, 2020-03-09 at 15:18 +0000, Alex Kiernan wrote: > I've a branch with systemd 245 on it which fails testing because > psplash gets restarted all the time. > > But ignoring the systemd 245 piece, it looks to me like psplash could > be restarted under systemd 244 too as the main process exits and our > units aren't marked RemainAfterExit. I haven't figured out what's > triggering it in 245 and not 244, but I suspect it's something > similar > to this: > > https://github.com/systemd/systemd/commit/9fd32ff7d363945fbf8fdae0128702b995127558 > > Given where we are in the release cycle and how painful psplash has > obviously been, I'm inclined to leave it until after dunfell ships > and then do it as part of the whole 245 upgrade? > > Equally if you see psplash flapping during tests, it's almost > certainly this problem. Thanks for the report. The weird thing is that master is working with this as far as I can see, certainly no test failures since the last fix I pushed a few days ago. Is there some specific change to the unit files we should make? I'm a little reluctant to pull this out now given we feel like we're close to it working. Cheers, Richard From raj.khem at gmail.com Wed Mar 11 17:20:53 2020 From: raj.khem at gmail.com (Khem Raj) Date: Wed, 11 Mar 2020 10:20:53 -0700 Subject: [OE-core] [PATCH 2/6] gcc: strip line numbers from generated code in gcc-plugins on target In-Reply-To: <20200310232814.48572-2-richard.purdie@linuxfoundation.org> References: <20200310232814.48572-1-richard.purdie@linuxfoundation.org> <20200310232814.48572-2-richard.purdie@linuxfoundation.org> Message-ID: <4d7b32fb-2163-92dc-f3e3-219eacbc4782@gmail.com> On 3/10/20 4:28 PM, Richard Purdie wrote: > From: Ross Burton > > The line numbers are influenced by the gcc version on the host used to generate > the code. Remove these to ensure the shipped source code is the same. > Please send this paatch to gcc mailing lists for review, I am not sure if this will cause regressions for plugin writers since it does not seem simple debug info that it is adding, and external plugins might rely on this information. While I understand it might solve our usecaase its a kind of patch that I worry about to carry out of tree. > Signed-off-by: Richard Purdie > --- > meta/recipes-devtools/gcc/gcc-9.2.inc | 1 + > .../gcc/gcc-9.2/gen-no-line-numbers.patch | 170 ++++++++++++++++++ > 2 files changed, 171 insertions(+) > create mode 100644 meta/recipes-devtools/gcc/gcc-9.2/gen-no-line-numbers.patch > > diff --git a/meta/recipes-devtools/gcc/gcc-9.2.inc b/meta/recipes-devtools/gcc/gcc-9.2.inc > index 2bae85afe3a..2368f358675 100644 > --- a/meta/recipes-devtools/gcc/gcc-9.2.inc > +++ b/meta/recipes-devtools/gcc/gcc-9.2.inc > @@ -70,6 +70,7 @@ SRC_URI = "\ > file://CVE-2019-15847_2.patch \ > file://CVE-2019-15847_3.patch \ > file://re-PR-target-91102-aarch64-ICE-on-Linux-kernel-with-.patch \ > + file://gen-no-line-numbers.patch \ > " > S = "${TMPDIR}/work-shared/gcc-${PV}-${PR}/gcc-${PV}" > SRC_URI[md5sum] = "3818ad8600447f05349098232c2ddc78" > diff --git a/meta/recipes-devtools/gcc/gcc-9.2/gen-no-line-numbers.patch b/meta/recipes-devtools/gcc/gcc-9.2/gen-no-line-numbers.patch > new file mode 100644 > index 00000000000..8e2c3f58095 > --- /dev/null > +++ b/meta/recipes-devtools/gcc/gcc-9.2/gen-no-line-numbers.patch > @@ -0,0 +1,170 @@ > +Inserting line numbers into generated code means its not always reproducible wth > +differing versions of host gcc. Void the issue by not adding these. > + > +Upstream-Status: Inappropriate [OE Reproducibility specific] > +Signed-off-by: Richard Purdie > + > +diff --git a/gcc/gengtype.c b/gcc/gengtype.c > +index 53317337c..bbb261516 100644 > +--- a/gcc/gengtype.c > ++++ b/gcc/gengtype.c > +@@ -991,7 +991,7 @@ create_field_at (pair_p next, type_p type, const char *name, options_p opt, > + /* Create a fake field with the given type and name. NEXT is the next > + field in the chain. */ > + #define create_field(next,type,name) \ > +- create_field_all (next,type,name, 0, this_file, __LINE__) > ++ create_field_all (next,type,name, 0, this_file, 0) > + > + /* Like create_field, but the field is only valid when condition COND > + is true. */ > +@@ -1024,7 +1024,7 @@ create_optional_field_ (pair_p next, type_p type, const char *name, > + } > + > + #define create_optional_field(next,type,name,cond) \ > +- create_optional_field_(next,type,name,cond,__LINE__) > ++ create_optional_field_(next,type,name,cond,0) > + > + /* Reverse a linked list of 'struct pair's in place. */ > + pair_p > +@@ -5186,7 +5186,7 @@ main (int argc, char **argv) > + /* These types are set up with #define or else outside of where > + we can see them. We should initialize them before calling > + read_input_list. */ > +-#define POS_HERE(Call) do { pos.file = this_file; pos.line = __LINE__; \ > ++#define POS_HERE(Call) do { pos.file = this_file; pos.line = 0; \ > + Call;} while (0) > + POS_HERE (do_scalar_typedef ("CUMULATIVE_ARGS", &pos)); > + POS_HERE (do_scalar_typedef ("REAL_VALUE_TYPE", &pos)); > +diff --git a/gcc/genmodes.c b/gcc/genmodes.c > +index f33eefa24..07bef9eeb 100644 > +--- a/gcc/genmodes.c > ++++ b/gcc/genmodes.c > +@@ -429,7 +429,7 @@ complete_all_modes (void) > + } > + > + /* For each mode in class CLASS, construct a corresponding complex mode. */ > +-#define COMPLEX_MODES(C) make_complex_modes (MODE_##C, __FILE__, __LINE__) > ++#define COMPLEX_MODES(C) make_complex_modes (MODE_##C, __FILE__, 0) > + static void > + make_complex_modes (enum mode_class cl, > + const char *file, unsigned int line) > +@@ -487,7 +487,7 @@ make_complex_modes (enum mode_class cl, > + /* For all modes in class CL, construct vector modes of width > + WIDTH, having as many components as necessary. */ > + #define VECTOR_MODES_WITH_PREFIX(PREFIX, C, W) \ > +- make_vector_modes (MODE_##C, #PREFIX, W, __FILE__, __LINE__) > ++ make_vector_modes (MODE_##C, #PREFIX, W, __FILE__, 0) > + #define VECTOR_MODES(C, W) VECTOR_MODES_WITH_PREFIX (V, C, W) > + static void ATTRIBUTE_UNUSED > + make_vector_modes (enum mode_class cl, const char *prefix, unsigned int width, > +@@ -538,7 +538,7 @@ make_vector_modes (enum mode_class cl, const char *prefix, unsigned int width, > + /* Create a vector of booleans called NAME with COUNT elements and > + BYTESIZE bytes in total. */ > + #define VECTOR_BOOL_MODE(NAME, COUNT, BYTESIZE) \ > +- make_vector_bool_mode (#NAME, COUNT, BYTESIZE, __FILE__, __LINE__) > ++ make_vector_bool_mode (#NAME, COUNT, BYTESIZE, __FILE__, 0) > + static void ATTRIBUTE_UNUSED > + make_vector_bool_mode (const char *name, unsigned int count, > + unsigned int bytesize, const char *file, > +@@ -560,7 +560,7 @@ make_vector_bool_mode (const char *name, unsigned int count, > + /* Input. */ > + > + #define _SPECIAL_MODE(C, N) \ > +- make_special_mode (MODE_##C, #N, __FILE__, __LINE__) > ++ make_special_mode (MODE_##C, #N, __FILE__, 0) > + #define RANDOM_MODE(N) _SPECIAL_MODE (RANDOM, N) > + #define CC_MODE(N) _SPECIAL_MODE (CC, N) > + > +@@ -573,7 +573,7 @@ make_special_mode (enum mode_class cl, const char *name, > + > + #define INT_MODE(N, Y) FRACTIONAL_INT_MODE (N, -1U, Y) > + #define FRACTIONAL_INT_MODE(N, B, Y) \ > +- make_int_mode (#N, B, Y, __FILE__, __LINE__) > ++ make_int_mode (#N, B, Y, __FILE__, 0) > + > + static void > + make_int_mode (const char *name, > +@@ -586,16 +586,16 @@ make_int_mode (const char *name, > + } > + > + #define FRACT_MODE(N, Y, F) \ > +- make_fixed_point_mode (MODE_FRACT, #N, Y, 0, F, __FILE__, __LINE__) > ++ make_fixed_point_mode (MODE_FRACT, #N, Y, 0, F, __FILE__, 0) > + > + #define UFRACT_MODE(N, Y, F) \ > +- make_fixed_point_mode (MODE_UFRACT, #N, Y, 0, F, __FILE__, __LINE__) > ++ make_fixed_point_mode (MODE_UFRACT, #N, Y, 0, F, __FILE__, 0) > + > + #define ACCUM_MODE(N, Y, I, F) \ > +- make_fixed_point_mode (MODE_ACCUM, #N, Y, I, F, __FILE__, __LINE__) > ++ make_fixed_point_mode (MODE_ACCUM, #N, Y, I, F, __FILE__, 0) > + > + #define UACCUM_MODE(N, Y, I, F) \ > +- make_fixed_point_mode (MODE_UACCUM, #N, Y, I, F, __FILE__, __LINE__) > ++ make_fixed_point_mode (MODE_UACCUM, #N, Y, I, F, __FILE__, 0) > + > + /* Create a fixed-point mode by setting CL, NAME, BYTESIZE, IBIT, FBIT, > + FILE, and LINE. */ > +@@ -616,7 +616,7 @@ make_fixed_point_mode (enum mode_class cl, > + > + #define FLOAT_MODE(N, Y, F) FRACTIONAL_FLOAT_MODE (N, -1U, Y, F) > + #define FRACTIONAL_FLOAT_MODE(N, B, Y, F) \ > +- make_float_mode (#N, B, Y, #F, __FILE__, __LINE__) > ++ make_float_mode (#N, B, Y, #F, __FILE__, 0) > + > + static void > + make_float_mode (const char *name, > +@@ -633,7 +633,7 @@ make_float_mode (const char *name, > + #define DECIMAL_FLOAT_MODE(N, Y, F) \ > + FRACTIONAL_DECIMAL_FLOAT_MODE (N, -1U, Y, F) > + #define FRACTIONAL_DECIMAL_FLOAT_MODE(N, B, Y, F) \ > +- make_decimal_float_mode (#N, B, Y, #F, __FILE__, __LINE__) > ++ make_decimal_float_mode (#N, B, Y, #F, __FILE__, 0) > + > + static void > + make_decimal_float_mode (const char *name, > +@@ -648,7 +648,7 @@ make_decimal_float_mode (const char *name, > + } > + > + #define RESET_FLOAT_FORMAT(N, F) \ > +- reset_float_format (#N, #F, __FILE__, __LINE__) > ++ reset_float_format (#N, #F, __FILE__, 0) > + static void ATTRIBUTE_UNUSED > + reset_float_format (const char *name, const char *format, > + const char *file, unsigned int line) > +@@ -669,7 +669,7 @@ reset_float_format (const char *name, const char *format, > + > + /* __intN support. */ > + #define INT_N(M,PREC) \ > +- make_int_n (#M, PREC, __FILE__, __LINE__) > ++ make_int_n (#M, PREC, __FILE__, 0) > + static void ATTRIBUTE_UNUSED > + make_int_n (const char *m, int bitsize, > + const char *file, unsigned int line) > +@@ -698,7 +698,7 @@ make_int_n (const char *m, int bitsize, > + /* Partial integer modes are specified by relation to a full integer > + mode. */ > + #define PARTIAL_INT_MODE(M,PREC,NAME) \ > +- make_partial_integer_mode (#M, #NAME, PREC, __FILE__, __LINE__) > ++ make_partial_integer_mode (#M, #NAME, PREC, __FILE__, 0) > + static void ATTRIBUTE_UNUSED > + make_partial_integer_mode (const char *base, const char *name, > + unsigned int precision, > +@@ -725,7 +725,7 @@ make_partial_integer_mode (const char *base, const char *name, > + /* A single vector mode can be specified by naming its component > + mode and the number of components. */ > + #define VECTOR_MODE(C, M, N) \ > +- make_vector_mode (MODE_##C, #M, N, __FILE__, __LINE__); > ++ make_vector_mode (MODE_##C, #M, N, __FILE__, 0); > + static void ATTRIBUTE_UNUSED > + make_vector_mode (enum mode_class bclass, > + const char *base, > +@@ -768,7 +768,7 @@ make_vector_mode (enum mode_class bclass, > + > + /* Adjustability. */ > + #define _ADD_ADJUST(A, M, X, C1, C2) \ > +- new_adjust (#M, &adj_##A, #A, #X, MODE_##C1, MODE_##C2, __FILE__, __LINE__) > ++ new_adjust (#M, &adj_##A, #A, #X, MODE_##C1, MODE_##C2, __FILE__, 0) > + > + #define ADJUST_NUNITS(M, X) _ADD_ADJUST (nunits, M, X, RANDOM, RANDOM) > + #define ADJUST_BYTESIZE(M, X) _ADD_ADJUST (bytesize, M, X, RANDOM, RANDOM) > From alex.kanavin at gmail.com Wed Mar 11 17:22:02 2020 From: alex.kanavin at gmail.com (Alexander Kanavin) Date: Wed, 11 Mar 2020 18:22:02 +0100 Subject: [OE-core] [PATCH] weston-init: Allow use of weston without input devices In-Reply-To: <20200311165221.23475-1-domarys.correa@ossystems.com.br> References: <20200311165221.23475-1-domarys.correa@ossystems.com.br> Message-ID: I do not think we should be overriding upstream defaults like this. If your use case is different, you can always provide a custom weston.ini through a bbappend. Alex On Wed, 11 Mar 2020 at 17:52, Domarys Correa < domarys.correa at ossystems.com.br> wrote: > Don't force users to have input device in your targets. As the default > option require-input is set to true, Weston only starts if we have a > device in /dev/input/event* and this not a requirement for all > applications, > e.g. kiosk browser. > > Signed-off-by: Domarys Correa > --- > meta/recipes-graphics/wayland/weston-init/weston.ini | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/meta/recipes-graphics/wayland/weston-init/weston.ini > b/meta/recipes-graphics/wayland/weston-init/weston.ini > index 1eecf48bc1..1e6dff68fd 100644 > --- a/meta/recipes-graphics/wayland/weston-init/weston.ini > +++ b/meta/recipes-graphics/wayland/weston-init/weston.ini > @@ -1,9 +1,10 @@ > # configuration file for Weston > > -#[core] > +[core] > #modules=xwayland.so,cms-colord.so > #shell=desktop-shell.so > #gbm-format=xrgb2101010 > +require-input=false > > #[shell] > #background-image=/usr/share/backgrounds/gnome/Aqua.jpg > -- > 2.17.1 > > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core at lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core > -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard.purdie at linuxfoundation.org Wed Mar 11 17:22:26 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Wed, 11 Mar 2020 17:22:26 +0000 Subject: [OE-core] [PATCH] oeqa: enable testresults.json for testexport In-Reply-To: <20200311163730.78078-1-sk@typedivision.de> References: <20200311163730.78078-1-sk@typedivision.de> Message-ID: On Wed, 2020-03-11 at 17:37 +0100, Stefan Kral wrote: > Add the option --json-result-dir to oeqa core context to enable > testresults.json creation for test runs via testexport. > > Eg. oe-test runtime --json-result-dir . > > Signed-off-by: Stefan Kral Out of interest are you actively using testexport? I've been wondering if we should remove that support as it does complicate the code a lot and ironically, isn't well tested. Cheers, Richard From alex.kiernan at gmail.com Wed Mar 11 17:27:33 2020 From: alex.kiernan at gmail.com (Alex Kiernan) Date: Wed, 11 Mar 2020 17:27:33 +0000 Subject: [OE-core] psplash activation state w/ systemd In-Reply-To: <5e5adb83812fe98a76b8207588325f7996e33c85.camel@linuxfoundation.org> References: <5e5adb83812fe98a76b8207588325f7996e33c85.camel@linuxfoundation.org> Message-ID: On Wed, Mar 11, 2020 at 5:20 PM Richard Purdie wrote: > > On Mon, 2020-03-09 at 15:18 +0000, Alex Kiernan wrote: > > I've a branch with systemd 245 on it which fails testing because > > psplash gets restarted all the time. > > > > But ignoring the systemd 245 piece, it looks to me like psplash could > > be restarted under systemd 244 too as the main process exits and our > > units aren't marked RemainAfterExit. I haven't figured out what's > > triggering it in 245 and not 244, but I suspect it's something > > similar > > to this: > > > > https://github.com/systemd/systemd/commit/9fd32ff7d363945fbf8fdae0128702b995127558 > > > > Given where we are in the release cycle and how painful psplash has > > obviously been, I'm inclined to leave it until after dunfell ships > > and then do it as part of the whole 245 upgrade? > > > > Equally if you see psplash flapping during tests, it's almost > > certainly this problem. > > Thanks for the report. The weird thing is that master is working with > this as far as I can see, certainly no test failures since the last fix > I pushed a few days ago. > > Is there some specific change to the unit files we should make? I'm a > little reluctant to pull this out now given we feel like we're close to > it working. > It's basically trivial (add RemainAfterExit=yes to both units), but as you say, given where we are and it appears to work, I don't think now's the time to do it. I suspect something's changed in 245 which makes it far more likely that you see units retriggered, but I can't for the life of me work out which commit it is (I should stop trying to do it by inspection and bisect it out...). -- Alex Kiernan From richard.purdie at linuxfoundation.org Wed Mar 11 17:27:49 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Wed, 11 Mar 2020 17:27:49 +0000 Subject: [OE-core] [PATCH 2/6] gcc: strip line numbers from generated code in gcc-plugins on target In-Reply-To: <4d7b32fb-2163-92dc-f3e3-219eacbc4782@gmail.com> References: <20200310232814.48572-1-richard.purdie@linuxfoundation.org> <20200310232814.48572-2-richard.purdie@linuxfoundation.org> <4d7b32fb-2163-92dc-f3e3-219eacbc4782@gmail.com> Message-ID: <65455f6a8ad443729e919704ef3a9d425b5cb6ac.camel@linuxfoundation.org> On Wed, 2020-03-11 at 10:20 -0700, Khem Raj wrote: > > On 3/10/20 4:28 PM, Richard Purdie wrote: > > From: Ross Burton > > > > The line numbers are influenced by the gcc version on the host used > > to generate > > the code. Remove these to ensure the shipped source code is the > > same. > > > > Please send this paatch to gcc mailing lists for review, I am not > sure if this will cause regressions for plugin writers since it does > not seem simple debug info that it is adding, and external plugins > might rely on this information. While I understand it might solve > our usecaase its a kind of patch that I worry about to carry out of > tree. I very much doubt upstream are going to accept anything like it unfortunately. Whilst much of the information is useful to plugins, I'm struggling to see how/why they'd use line numbers outside of debug information so I've assumed so far they're just that - for debug. DO you know of it being used in other ways? Cheers, Richard From raj.khem at gmail.com Wed Mar 11 17:29:30 2020 From: raj.khem at gmail.com (Khem Raj) Date: Wed, 11 Mar 2020 10:29:30 -0700 Subject: [OE-core] [PATCH 2/6] gcc: strip line numbers from generated code in gcc-plugins on target In-Reply-To: <65455f6a8ad443729e919704ef3a9d425b5cb6ac.camel@linuxfoundation.org> References: <20200310232814.48572-1-richard.purdie@linuxfoundation.org> <20200310232814.48572-2-richard.purdie@linuxfoundation.org> <4d7b32fb-2163-92dc-f3e3-219eacbc4782@gmail.com> <65455f6a8ad443729e919704ef3a9d425b5cb6ac.camel@linuxfoundation.org> Message-ID: <7af79336-fdd9-0690-7552-7aac0b056903@gmail.com> On 3/11/20 10:27 AM, Richard Purdie wrote: > On Wed, 2020-03-11 at 10:20 -0700, Khem Raj wrote: >> >> On 3/10/20 4:28 PM, Richard Purdie wrote: >>> From: Ross Burton >>> >>> The line numbers are influenced by the gcc version on the host used >>> to generate >>> the code. Remove these to ensure the shipped source code is the >>> same. >>> >> >> Please send this paatch to gcc mailing lists for review, I am not >> sure if this will cause regressions for plugin writers since it does >> not seem simple debug info that it is adding, and external plugins >> might rely on this information. While I understand it might solve >> our usecaase its a kind of patch that I worry about to carry out of >> tree. > > I very much doubt upstream are going to accept anything like it > unfortunately. Whilst much of the information is useful to plugins, I'm > struggling to see how/why they'd use line numbers outside of debug > information so I've assumed so far they're just that - for debug. DO > you know of it being used in other ways? > I am not looking for them to integrate it as it is, but to get reviews if this is something we are not setting ourselves for more trouble by doing this. Since lot of plugin writers will be there and can give useful feedback. > Cheers, > > Richard > From raj.khem at gmail.com Wed Mar 11 17:40:38 2020 From: raj.khem at gmail.com (Khem Raj) Date: Wed, 11 Mar 2020 10:40:38 -0700 Subject: [OE-core] [PATCH 5/6] glibc: Update nativesdk locale relocation patch In-Reply-To: <20200310232814.48572-5-richard.purdie@linuxfoundation.org> References: <20200310232814.48572-1-richard.purdie@linuxfoundation.org> <20200310232814.48572-5-richard.purdie@linuxfoundation.org> Message-ID: <2b8111a2-1722-5d2a-0942-aad6555a08f8@gmail.com> On 3/10/20 4:28 PM, Richard Purdie wrote: > The locale binary reported incorrect locale lists in relocated toolchains > as some path references were not relocated by this patch. Fix this missing > relocations so the locale binary correctly reports the locales. > > Signed-off-by: Richard Purdie > --- > ...Make-relocatable-install-for-locales.patch | 62 ++++++++++++++----- > 1 file changed, 47 insertions(+), 15 deletions(-) > > diff --git a/meta/recipes-core/glibc/glibc/0007-nativesdk-glibc-Make-relocatable-install-for-locales.patch b/meta/recipes-core/glibc/glibc/0007-nativesdk-glibc-Make-relocatable-install-for-locales.patch > index d9985c2fdc8..27cd17cdcdf 100644 > --- a/meta/recipes-core/glibc/glibc/0007-nativesdk-glibc-Make-relocatable-install-for-locales.patch > +++ b/meta/recipes-core/glibc/glibc/0007-nativesdk-glibc-Make-relocatable-install-for-locales.patch > @@ -17,11 +17,11 @@ Signed-off-by: Khem Raj > locale/localeinfo.h | 2 +- > 3 files changed, 4 insertions(+), 4 deletions(-) > > -diff --git a/locale/findlocale.c b/locale/findlocale.c > -index 9cd3b71a6d..84272310e0 100644 > ---- a/locale/findlocale.c > -+++ b/locale/findlocale.c > -@@ -56,7 +56,7 @@ struct __locale_data *const _nl_C[] attribute_hidden = > +Index: git/locale/findlocale.c > +=================================================================== > +--- git.orig/locale/findlocale.c > ++++ git/locale/findlocale.c > +@@ -56,7 +56,7 @@ struct __locale_data *const _nl_C[] attr > which are somehow addressed. */ > struct loaded_l10nfile *_nl_locale_file_list[__LC_LAST]; > > @@ -30,7 +30,7 @@ index 9cd3b71a6d..84272310e0 100644 > > /* Checks if the name is actually present, that is, not NULL and not > empty. */ > -@@ -166,7 +166,7 @@ _nl_find_locale (const char *locale_path, size_t locale_path_len, > +@@ -166,7 +166,7 @@ _nl_find_locale (const char *locale_path > > /* Nothing in the archive. Set the default path to search below. */ > locale_path = _nl_default_locale_path; > @@ -39,10 +39,10 @@ index 9cd3b71a6d..84272310e0 100644 > } > else > /* We really have to load some data. First see whether the name is > -diff --git a/locale/loadarchive.c b/locale/loadarchive.c > -index ba0fe45648..9737fd4cda 100644 > ---- a/locale/loadarchive.c > -+++ b/locale/loadarchive.c > +Index: git/locale/loadarchive.c > +=================================================================== > +--- git.orig/locale/loadarchive.c > ++++ git/locale/loadarchive.c > @@ -42,7 +42,7 @@ > > > @@ -52,11 +52,11 @@ index ba0fe45648..9737fd4cda 100644 > > /* Size of initial mapping window, optimal if large enough to > cover the header plus the initial locale. */ > -diff --git a/locale/localeinfo.h b/locale/localeinfo.h > -index 1bfe22aa7f..fdc283c69a 100644 > ---- a/locale/localeinfo.h > -+++ b/locale/localeinfo.h > -@@ -331,7 +331,7 @@ _nl_lookup_word (locale_t l, int category, int item) > +Index: git/locale/localeinfo.h > +=================================================================== > +--- git.orig/locale/localeinfo.h > ++++ git/locale/localeinfo.h > +@@ -331,7 +331,7 @@ _nl_lookup_word (locale_t l, int categor > } > > /* Default search path if no LOCPATH environment variable. */ > @@ -65,3 +65,35 @@ index 1bfe22aa7f..fdc283c69a 100644 > > /* Load the locale data for CATEGORY from the file specified by *NAME. > If *NAME is "", use environment variables as specified by POSIX, and > +Index: git/locale/programs/locale.c > +=================================================================== > +--- git.orig/locale/programs/locale.c > ++++ git/locale/programs/locale.c > +@@ -632,6 +632,7 @@ nameentcmp (const void *a, const void *b > + ((const struct nameent *) b)->name); > + } > + > ++static char _write_archive_locales_path[4096] attribute_hidden __attribute__ ((section (".gccrelocprefix"))) = ARCHIVE_NAME; is this .gccrelocprefix limited to nativesdk case in general ? I think this binds us into gcc quite a bit, so I would like to see if we can do it more generic ways which can work for say clang as well. > + > + static int > + write_archive_locales (void **all_datap, char *linebuf) > +@@ -645,7 +646,7 @@ write_archive_locales (void **all_datap, > + int fd, ret = 0; > + uint32_t cnt; > + > +- fd = open64 (ARCHIVE_NAME, O_RDONLY); > ++ fd = open64 (_write_archive_locales_path, O_RDONLY); > + if (fd < 0) > + return 0; > + > +@@ -700,8 +701,8 @@ write_archive_locales (void **all_datap, > + if (cnt) > + putchar_unlocked ('\n'); > + > +- printf ("locale: %-15.15s archive: " ARCHIVE_NAME "\n%s\n", > +- names[cnt].name, linebuf); > ++ printf ("locale: %-15.15s archive: %s\n%s\n", > ++ names[cnt].name, _write_archive_locales_path, linebuf); > + > + locrec = (struct locrecent *) (addr + names[cnt].locrec_offset); > + > From otavio.salvador at ossystems.com.br Wed Mar 11 18:19:34 2020 From: otavio.salvador at ossystems.com.br (Otavio Salvador) Date: Wed, 11 Mar 2020 15:19:34 -0300 Subject: [OE-core] [PATCH] weston-init: Allow use of weston without input devices In-Reply-To: References: <20200311165221.23475-1-domarys.correa@ossystems.com.br> Message-ID: Hello Alex, On Wed, Mar 11, 2020 at 2:22 PM Alexander Kanavin wrote: > I do not think we should be overriding upstream defaults like this. If your use case is different, you can always provide a custom weston.ini through a bbappend. I'd like to argue why, in this case, it makes sense. The weston is getting more and more adoption and often we use it on devices that do not have keyboard and mouse connected. The default configuration file, on OE-Core, should be adequate for common use cases as we see on embedded devices and failing to start just because we lack input devices is far from user-friendly. We do have a bbappend our multiple customer layers and as it has become common we'd like to upstream it as we used quite some time to understand why it was failing when we first faced it. -- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 From raj.khem at gmail.com Wed Mar 11 18:29:43 2020 From: raj.khem at gmail.com (Khem Raj) Date: Wed, 11 Mar 2020 11:29:43 -0700 Subject: [OE-core] [PATCH] coreutils: Fix -dev package dependencies In-Reply-To: <20200311114421.65442-1-richard.purdie@linuxfoundation.org> References: <20200311114421.65442-1-richard.purdie@linuxfoundation.org> Message-ID: <53da03e4-b7e4-8882-3d10-ff27a051f07b@gmail.com> On 3/11/20 4:44 AM, Richard Purdie wrote: > The new ptest dependencies present some challenges, in particular libmodule-build-perl > which effectively depends on gcc. In multilib images, this results in both > libXX-gcc-symlinks and libYY-gcc-symlinks being installed which conflict. This also > makes little sense. > > The easiest way to fix this is to disable the automatic -dev package dependencies > and manually specify the correct ones. > > Signed-off-by: Richard Purdie > --- > meta/recipes-core/coreutils/coreutils_8.31.bb | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/meta/recipes-core/coreutils/coreutils_8.31.bb b/meta/recipes-core/coreutils/coreutils_8.31.bb > index cba0bfe15cc..eac016319eb 100644 > --- a/meta/recipes-core/coreutils/coreutils_8.31.bb > +++ b/meta/recipes-core/coreutils/coreutils_8.31.bb > @@ -149,6 +149,10 @@ inherit ptest > > RDEPENDS_${PN}-ptest += "bash findutils gawk liberror-perl libmodule-build-perl make perl perl-module-file-stat python3-core sed shadow" > > +# -dev automatic dependencies fails as we don't want libmodule-build-perl-dev, its too heavy > +RRECOMMENDS_coreutils-dev[nodeprrecs] = "1" > +RRECOMMENDS_coreutils-dev = "acl-dev attr-dev gmp-dev libcap-dev bash-dev findutils-dev gawk-dev shadow-dev" > + this also means that any indirect dependency in future has to be added here manually right ? or will that situation never happen, if it will then perhaps a note in comments might be useful about that > do_install_ptest () { > install -d ${D}${PTEST_PATH}/tests > cp -r ${S}/tests/* ${D}${PTEST_PATH}/tests > From richard.purdie at linuxfoundation.org Wed Mar 11 18:31:51 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Wed, 11 Mar 2020 18:31:51 +0000 Subject: [OE-core] [PATCH] coreutils: Fix -dev package dependencies In-Reply-To: <53da03e4-b7e4-8882-3d10-ff27a051f07b@gmail.com> References: <20200311114421.65442-1-richard.purdie@linuxfoundation.org> <53da03e4-b7e4-8882-3d10-ff27a051f07b@gmail.com> Message-ID: <52dc073deff28f726b7b9f451640a673009df419.camel@linuxfoundation.org> On Wed, 2020-03-11 at 11:29 -0700, Khem Raj wrote: > > On 3/11/20 4:44 AM, Richard Purdie wrote: > > The new ptest dependencies present some challenges, in particular > > libmodule-build-perl > > which effectively depends on gcc. In multilib images, this results > > in both > > libXX-gcc-symlinks and libYY-gcc-symlinks being installed which > > conflict. This also > > makes little sense. > > > > The easiest way to fix this is to disable the automatic -dev > > package dependencies > > and manually specify the correct ones. > > > > Signed-off-by: Richard Purdie > > --- > > meta/recipes-core/coreutils/coreutils_8.31.bb | 4 ++++ > > 1 file changed, 4 insertions(+) > > > > diff --git a/meta/recipes-core/coreutils/coreutils_8.31.bb > > b/meta/recipes-core/coreutils/coreutils_8.31.bb > > index cba0bfe15cc..eac016319eb 100644 > > --- a/meta/recipes-core/coreutils/coreutils_8.31.bb > > +++ b/meta/recipes-core/coreutils/coreutils_8.31.bb > > @@ -149,6 +149,10 @@ inherit ptest > > > > RDEPENDS_${PN}-ptest += "bash findutils gawk liberror-perl > > libmodule-build-perl make perl perl-module-file-stat python3-core > > sed shadow" > > > > +# -dev automatic dependencies fails as we don't want libmodule- > > build-perl-dev, its too heavy > > +RRECOMMENDS_coreutils-dev[nodeprrecs] = "1" > > +RRECOMMENDS_coreutils-dev = "acl-dev attr-dev gmp-dev libcap-dev > > bash-dev findutils-dev gawk-dev shadow-dev" > > + > > this also means that any indirect dependency in future has to be > added here manually right ? or will that situation never happen, if > it will then perhaps a note in comments might be useful about that If DEPENDS change, we may need to tweak this, yes. The whole -dev thing has a bug open about reworking it and its a mess already so this is really a bandaid for now. I'd rather have this and coreutils-ptest than not have the ptests. I'm trying to be pragmatic about it! :) Cheers, Richard From alex.kanavin at gmail.com Wed Mar 11 18:39:56 2020 From: alex.kanavin at gmail.com (Alexander Kanavin) Date: Wed, 11 Mar 2020 19:39:56 +0100 Subject: [OE-core] [PATCH] weston-init: Allow use of weston without input devices In-Reply-To: References: <20200311165221.23475-1-domarys.correa@ossystems.com.br> Message-ID: But shouldn?t you take it all the way upstream then and change the default there? My concern is that we currently ship a blank configuration and rely on defaults and auto-discovery; I wouldn?t want to erode that with all sorts of customizations. Alex On Wed 11. Mar 2020 at 19.19, Otavio Salvador < otavio.salvador at ossystems.com.br> wrote: > Hello Alex, > > On Wed, Mar 11, 2020 at 2:22 PM Alexander Kanavin > wrote: > > I do not think we should be overriding upstream defaults like this. If > your use case is different, you can always provide a custom weston.ini > through a bbappend. > > I'd like to argue why, in this case, it makes sense. > > The weston is getting more and more adoption and often we use it on > devices that do not have keyboard and mouse connected. The default > configuration file, on OE-Core, should be adequate for common use > cases as we see on embedded devices and failing to start just because > we lack input devices is far from user-friendly. > > We do have a bbappend our multiple customer layers and as it has > become common we'd like to upstream it as we used quite some time to > understand why it was failing when we first faced it. > > -- > Otavio Salvador O.S. Systems > http://www.ossystems.com.br http://code.ossystems.com.br > Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raj.khem at gmail.com Wed Mar 11 18:41:32 2020 From: raj.khem at gmail.com (Khem Raj) Date: Wed, 11 Mar 2020 11:41:32 -0700 Subject: [OE-core] [PATCH] weston-init: Allow use of weston without input devices In-Reply-To: References: <20200311165221.23475-1-domarys.correa@ossystems.com.br> Message-ID: Hi Alex On 3/11/20 10:22 AM, Alexander Kanavin wrote: > I do not think we should be overriding upstream defaults like this. If > your use case is different, you can always provide a custom weston.ini > through a bbappend. > I share your sentiments and we should be vigilant, however in this case I think it makes sense especially when we are doing testing on remote units or emulators on server farms which may have no input devices connected. I filed a bug recently on YP bugzilla [1] which is very related to what this patch it fixing. In embedded case I think its more common to not have attached input devices [1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=13828 From raj.khem at gmail.com Wed Mar 11 18:42:52 2020 From: raj.khem at gmail.com (Khem Raj) Date: Wed, 11 Mar 2020 11:42:52 -0700 Subject: [OE-core] [PATCH] coreutils: Fix -dev package dependencies In-Reply-To: <52dc073deff28f726b7b9f451640a673009df419.camel@linuxfoundation.org> References: <20200311114421.65442-1-richard.purdie@linuxfoundation.org> <53da03e4-b7e4-8882-3d10-ff27a051f07b@gmail.com> <52dc073deff28f726b7b9f451640a673009df419.camel@linuxfoundation.org> Message-ID: On 3/11/20 11:31 AM, Richard Purdie wrote: > On Wed, 2020-03-11 at 11:29 -0700, Khem Raj wrote: >> >> On 3/11/20 4:44 AM, Richard Purdie wrote: >>> The new ptest dependencies present some challenges, in particular >>> libmodule-build-perl >>> which effectively depends on gcc. In multilib images, this results >>> in both >>> libXX-gcc-symlinks and libYY-gcc-symlinks being installed which >>> conflict. This also >>> makes little sense. >>> >>> The easiest way to fix this is to disable the automatic -dev >>> package dependencies >>> and manually specify the correct ones. >>> >>> Signed-off-by: Richard Purdie >>> --- >>> meta/recipes-core/coreutils/coreutils_8.31.bb | 4 ++++ >>> 1 file changed, 4 insertions(+) >>> >>> diff --git a/meta/recipes-core/coreutils/coreutils_8.31.bb >>> b/meta/recipes-core/coreutils/coreutils_8.31.bb >>> index cba0bfe15cc..eac016319eb 100644 >>> --- a/meta/recipes-core/coreutils/coreutils_8.31.bb >>> +++ b/meta/recipes-core/coreutils/coreutils_8.31.bb >>> @@ -149,6 +149,10 @@ inherit ptest >>> >>> RDEPENDS_${PN}-ptest += "bash findutils gawk liberror-perl >>> libmodule-build-perl make perl perl-module-file-stat python3-core >>> sed shadow" >>> >>> +# -dev automatic dependencies fails as we don't want libmodule- >>> build-perl-dev, its too heavy >>> +RRECOMMENDS_coreutils-dev[nodeprrecs] = "1" >>> +RRECOMMENDS_coreutils-dev = "acl-dev attr-dev gmp-dev libcap-dev >>> bash-dev findutils-dev gawk-dev shadow-dev" >>> + >> >> this also means that any indirect dependency in future has to be >> added here manually right ? or will that situation never happen, if >> it will then perhaps a note in comments might be useful about that > > If DEPENDS change, we may need to tweak this, yes. > > The whole -dev thing has a bug open about reworking it and its a mess > already so this is really a bandaid for now. > > I'd rather have this and coreutils-ptest than not have the ptests. > > I'm trying to be pragmatic about it! :) I think change is fine, I am just thinking if we will assist keeping it sane with a comment, until dev package logic is reworked. > > Cheers, > > Richard > From raj.khem at gmail.com Wed Mar 11 19:12:58 2020 From: raj.khem at gmail.com (Khem Raj) Date: Wed, 11 Mar 2020 12:12:58 -0700 Subject: [OE-core] [zeus 06/16] valgrind: Fix build with -fno-common In-Reply-To: <20200311075133.GA30580@localhost> References: <350496c3c0b80835cb5311aa6dbc91e4ee7b5935.1583893499.git.akuster808@gmail.com> <20200311075133.GA30580@localhost> Message-ID: <762da0f1-58a0-ae85-936d-43bf2ceb27c2@gmail.com> On 3/11/20 12:51 AM, Adrian Bunk wrote: > This patch is required for switching to gcc 10 (which changes the > default to -fno-common) in Yocto 3.2. > > AFAIK there is no benefit in backporting it to older releases. > I tend to agree. > cu > Adrian > From sk at typedivision.de Wed Mar 11 20:38:00 2020 From: sk at typedivision.de (Stefan Kral) Date: Wed, 11 Mar 2020 21:38:00 +0100 Subject: [OE-core] [PATCH] oeqa: enable testresults.json for testexport In-Reply-To: References: <20200311163730.78078-1-sk@typedivision.de> Message-ID: Hi Richard, I just started to evaluate the use of testexport. If you think about removing that feature, what is the preferred way to test a deployed target image? The idea here is to have two separate pipelines: 1. build - a target-image-test (same as target-image but additional test facilities enabled, like ptest) - the testexport output 2. test - fetch build results and install the target-image-test to the real hardware - run the exported runtime tests (host and target based cases) - check/save the generated testresults.json BR Stefan Am 11.03.20 um 18:22 schrieb Richard Purdie: > On Wed, 2020-03-11 at 17:37 +0100, Stefan Kral wrote: >> Add the option --json-result-dir to oeqa core context to enable >> testresults.json creation for test runs via testexport. >> >> Eg. oe-test runtime --json-result-dir . >> >> Signed-off-by: Stefan Kral > Out of interest are you actively using testexport? I've been wondering > if we should remove that support as it does complicate the code a lot > and ironically, isn't well tested. > > Cheers, > > Richard > From alex.kanavin at gmail.com Wed Mar 11 20:46:19 2020 From: alex.kanavin at gmail.com (Alexander Kanavin) Date: Wed, 11 Mar 2020 21:46:19 +0100 Subject: [OE-core] [PATCH] oeqa: enable testresults.json for testexport In-Reply-To: References: <20200311163730.78078-1-sk@typedivision.de> Message-ID: On Wed, 11 Mar 2020 at 21:38, Stefan Kral wrote: > I just started to evaluate the use of testexport. > > If you think about removing that feature, what is the preferred way to > test a deployed target image? > The idea here is to have two separate pipelines: > > 1. build > - a target-image-test (same as target-image but additional test > facilities enabled, like ptest) > - the testexport output > > 2. test > - fetch build results and install the target-image-test to the real > hardware > - run the exported runtime tests (host and target based cases) > - check/save the generated testresults.json > You can do all of these in a single pipeline using testimage: 1. built target-image-test 2. flash target-image-test to real hardware 3. bitbake -c testimage target-image-test (set TEST_TARGET to 'simpleremote', and ip/port for ssh access in local.conf) Is there a reason you need two pipelines? Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From sk at typedivision.de Wed Mar 11 21:27:09 2020 From: sk at typedivision.de (Stefan Kral) Date: Wed, 11 Mar 2020 22:27:09 +0100 Subject: [OE-core] [PATCH] oeqa: enable testresults.json for testexport In-Reply-To: References: <20200311163730.78078-1-sk@typedivision.de> Message-ID: <3b553c8a-4c08-cb95-923c-7f03cb6d01aa@typedivision.de> Am 11.03.20 um 21:46 schrieb Alexander Kanavin: > On Wed, 11 Mar 2020 at 21:38, Stefan Kral > wrote: > > I just started to evaluate the use of testexport. > > If you think about removing that feature, what is the preferred > way to > test a deployed target image? > The idea here is to have two separate pipelines: > > 1. build > - a target-image-test (same as target-image but additional test > facilities enabled, like ptest) > - the testexport output > > 2. test > - fetch build results and install the target-image-test to the > real hardware > - run the exported runtime tests (host and target based cases) > - check/save the generated testresults.json > > > You can do all of these in a single pipeline using testimage: > > 1. built target-image-test > 2. flash target-image-test to real hardware > 3. bitbake -c testimage target-image-test (set TEST_TARGET to > 'simpleremote', and ip/port for ssh access in local.conf) > > Is there a reason you need two pipelines? > > Alex Doing build and test in one pipeline turns out to be more complicated due to: - build machine may be different from test machine (with access to hardware) - build the image is a one time job, tests may have to be repeated reproducibly - executing long running tests slows down image creation (for development) - tests on dedicated hardware should be runable asynchronously when hw is available Running tests by bitbake -c testimage could be an option but to provide a full repo/bitbake/cache setup to run test cases sounds not as easy as having just python installed. And for that, testexport does its job quite well. Btw. have you ever thought about to integrate/support some external test framework (like robot framework)? Stefan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpuhlman at mvista.com Wed Mar 11 22:22:48 2020 From: jpuhlman at mvista.com (Jeremy A. Puhlman) Date: Wed, 11 Mar 2020 15:22:48 -0700 Subject: [OE-core] [PATCH 1/2] babletrace2: make manpages multilib identical Message-ID: <20200311222249.29880-1-jpuhlman@mvista.com> From: Jeremy Puhlman Signed-off-by: Jeremy A. Puhlman --- .../0001-Make-manpages-multilib-identical.patch | 28 ++++++++++++++++++++++ meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb | 1 + 2 files changed, 29 insertions(+) create mode 100644 meta/recipes-kernel/lttng/babeltrace2/0001-Make-manpages-multilib-identical.patch diff --git a/meta/recipes-kernel/lttng/babeltrace2/0001-Make-manpages-multilib-identical.patch b/meta/recipes-kernel/lttng/babeltrace2/0001-Make-manpages-multilib-identical.patch new file mode 100644 index 0000000000..2401b176e6 --- /dev/null +++ b/meta/recipes-kernel/lttng/babeltrace2/0001-Make-manpages-multilib-identical.patch @@ -0,0 +1,28 @@ +From 56986190e4b0c10945ce6aaa7ca10d6bd8a26a39 Mon Sep 17 00:00:00 2001 +From: Jeremy Puhlman +Date: Mon, 9 Mar 2020 21:10:35 +0000 +Subject: [PATCH] Make manpages multilib identical + +Upstream-Status: Pending +Signed-off-by: Jeremy Puhlman +--- + doc/man/asciidoc-attrs.conf.in | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/doc/man/asciidoc-attrs.conf.in b/doc/man/asciidoc-attrs.conf.in +index ad1183f1..e11c7031 100644 +--- a/doc/man/asciidoc-attrs.conf.in ++++ b/doc/man/asciidoc-attrs.conf.in +@@ -1,7 +1,7 @@ + [attributes] + # default values +-system_plugin_path="@LIBDIR@/babeltrace2/plugins" +-system_plugin_provider_path="@LIBDIR@/babeltrace2/plugin-providers" ++system_plugin_path="@prefix@/lib*/babeltrace2/plugins" ++system_plugin_provider_path="@prefix@/lib*/babeltrace2/plugin-providers" + babeltrace_version="@PACKAGE_VERSION@" + enable_debug_info="@ENABLE_DEBUG_INFO_VAL@" + defrdport=5344 +-- +2.24.1 + diff --git a/meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb b/meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb index 16953d6807..61bc7f5e6b 100644 --- a/meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb +++ b/meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb @@ -10,6 +10,7 @@ DEPENDS = "glib-2.0 util-linux popt bison-native flex-native" SRC_URI = "git://git.linuxfoundation.org/diamon/babeltrace.git;branch=stable-2.0 \ file://run-ptest \ file://0001-tests-do-not-run-test-applications-from-.libs.patch \ + file://0001-Make-manpages-multilib-identical.patch \ " SRCREV = "06df58f89ee51b1a2c6a2c187ec3f15691633910" UPSTREAM_CHECK_GITTAGREGEX = "v(?P2(\.\d+)+)$" -- 2.13.3 From jpuhlman at mvista.com Wed Mar 11 22:22:49 2020 From: jpuhlman at mvista.com (Jeremy A. Puhlman) Date: Wed, 11 Mar 2020 15:22:49 -0700 Subject: [OE-core] [PATCH 2/2] glib-2.0: Correct multilib conflict In-Reply-To: <20200311222249.29880-1-jpuhlman@mvista.com> References: <20200311222249.29880-1-jpuhlman@mvista.com> Message-ID: <20200311222249.29880-2-jpuhlman@mvista.com> From: Jeremy Puhlman Signed-off-by: Jeremy A. Puhlman --- meta/recipes-core/glib-2.0/glib.inc | 3 +++ 1 file changed, 3 insertions(+) diff --git a/meta/recipes-core/glib-2.0/glib.inc b/meta/recipes-core/glib-2.0/glib.inc index 23c347dbf7..edecc51fdb 100644 --- a/meta/recipes-core/glib-2.0/glib.inc +++ b/meta/recipes-core/glib-2.0/glib.inc @@ -128,6 +128,9 @@ do_install_append_class-target () { rm ${D}${datadir}/installed-tests/glib/gdbus-serialization.test fi fi + if test "x${MLPREFIX}" != "x"; then + mv ${D}${datadir}/installed-tests/glib/static-link.test ${D}${datadir}/installed-tests/glib/${MLPREFIX}static-link.test + fi } # As we do not build python3 for windows, makes no sense to ship the script that's using it -- 2.13.3 From jpuhlman at mvista.com Wed Mar 11 22:25:41 2020 From: jpuhlman at mvista.com (Jeremy A. Puhlman) Date: Wed, 11 Mar 2020 15:25:41 -0700 Subject: [OE-core] [PATCH 1/6] strace: Fix reproducibility issues Message-ID: <20200311222546.30284-1-jpuhlman@mvista.com> From: Jeremy Puhlman gen_tests script encodes its full path to itself in each script Signed-off-by: Jeremy A. Puhlman --- .../0001-strace-fix-reproducibilty-issues.patch | 39 ++++++++++++++++++++++ meta/recipes-devtools/strace/strace_5.5.bb | 1 + 2 files changed, 40 insertions(+) create mode 100644 meta/recipes-devtools/strace/strace/0001-strace-fix-reproducibilty-issues.patch diff --git a/meta/recipes-devtools/strace/strace/0001-strace-fix-reproducibilty-issues.patch b/meta/recipes-devtools/strace/strace/0001-strace-fix-reproducibilty-issues.patch new file mode 100644 index 0000000000..c4c176e6bc --- /dev/null +++ b/meta/recipes-devtools/strace/strace/0001-strace-fix-reproducibilty-issues.patch @@ -0,0 +1,39 @@ +From 6309792c49ca900cec6a7f1dc5b51bf75b629e11 Mon Sep 17 00:00:00 2001 +From: Jeremy Puhlman +Date: Wed, 11 Mar 2020 19:56:55 +0000 +Subject: [PATCH] strace: fix reproducibilty issues + +The full path to the gen_tests.sh script is encoded in the tests + +Upstream-Status: Pending + +Signed-off-by: Jeremy Puhlman +--- + tests/gen_tests.sh | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/tests/gen_tests.sh b/tests/gen_tests.sh +index 5e1e7c9..1e65eac 100755 +--- a/tests/gen_tests.sh ++++ b/tests/gen_tests.sh +@@ -46,7 +46,7 @@ while read -r name arg0 args; do { + + hdr="\ + #!/bin/sh -efu +-# Generated by $0 from $input ($name $arg0 $args); do not edit." ++# Generated by $(basename $0) from $input ($name $arg0 $args); do not edit." + + case "$arg0" in + +*) +@@ -80,7 +80,7 @@ while read -r name arg0 args; do { + + if [ -n "$names" ]; then + { +- printf '# Generated by %s from %s; do not edit.\n' "$0" "$input" ++ printf '# Generated by %s from %s; do not edit.\n' "$(basename $0)" "$input" + printf 'GEN_TESTS =' + printf ' %s.gen.test' $names + echo +-- +2.24.1 + diff --git a/meta/recipes-devtools/strace/strace_5.5.bb b/meta/recipes-devtools/strace/strace_5.5.bb index 6e7d63949d..ae552da028 100644 --- a/meta/recipes-devtools/strace/strace_5.5.bb +++ b/meta/recipes-devtools/strace/strace_5.5.bb @@ -13,6 +13,7 @@ SRC_URI = "https://strace.io/files/${PV}/strace-${PV}.tar.xz \ file://0001-caps-abbrev.awk-fix-gawk-s-path.patch \ file://ptest-spacesave.patch \ file://uintptr_t.patch \ + file://0001-strace-fix-reproducibilty-issues.patch \ " SRC_URI[md5sum] = "dbce2e84632b39a4ed86b9fc60447af9" SRC_URI[sha256sum] = "9f58958c8e59ea62293d907d10572e352b582bd7948ed21aa28ebb47e5bf30ff" -- 2.13.3 From jpuhlman at mvista.com Wed Mar 11 22:25:42 2020 From: jpuhlman at mvista.com (Jeremy A. Puhlman) Date: Wed, 11 Mar 2020 15:25:42 -0700 Subject: [OE-core] [PATCH 2/6] qemu: Fix reproducibilty issues In-Reply-To: <20200311222546.30284-1-jpuhlman@mvista.com> References: <20200311222546.30284-1-jpuhlman@mvista.com> Message-ID: <20200311222546.30284-2-jpuhlman@mvista.com> From: Jeremy Puhlman tests/qemu-iotests/common.env is generated from configure which we pass ${HOSTTOOLS_DIR}/python3 as our python to use, which gets copied into the ptests. Correct python3 path. Signed-off-by: Jeremy A. Puhlman --- meta/recipes-devtools/qemu/qemu.inc | 2 ++ 1 file changed, 2 insertions(+) diff --git a/meta/recipes-devtools/qemu/qemu.inc b/meta/recipes-devtools/qemu/qemu.inc index f3342eaf28..e6dbc6d05a 100644 --- a/meta/recipes-devtools/qemu/qemu.inc +++ b/meta/recipes-devtools/qemu/qemu.inc @@ -56,6 +56,8 @@ do_install_ptest() { # Don't check the file genreated by configure sed -i -e '/wildcard config-host.mak/d' \ -e '$ {/endif/d}' ${D}${PTEST_PATH}/tests/Makefile.include + sed -i -e 's,${HOSTTOOLS_DIR}/python3,${bindir}/python3,' \ + ${D}/${PTEST_PATH}/tests/qemu-iotests/common.env } # QEMU_TARGETS is overridable variable -- 2.13.3 From jpuhlman at mvista.com Wed Mar 11 22:25:43 2020 From: jpuhlman at mvista.com (Jeremy A. Puhlman) Date: Wed, 11 Mar 2020 15:25:43 -0700 Subject: [OE-core] [PATCH 3/6] ltp: fix reproducibilty issues In-Reply-To: <20200311222546.30284-1-jpuhlman@mvista.com> References: <20200311222546.30284-1-jpuhlman@mvista.com> Message-ID: <20200311222546.30284-3-jpuhlman@mvista.com> From: Jeremy Puhlman Man pages are copied in to the target filesystem from the configured build, which leaks paths in to the work directory Signed-off-by: Jeremy A. Puhlman --- meta/recipes-extended/ltp/ltp_20200120.bb | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/meta/recipes-extended/ltp/ltp_20200120.bb b/meta/recipes-extended/ltp/ltp_20200120.bb index 5be9489a75..3e6cbc63f3 100644 --- a/meta/recipes-extended/ltp/ltp_20200120.bb +++ b/meta/recipes-extended/ltp/ltp_20200120.bb @@ -68,6 +68,12 @@ do_install(){ # Copy POSIX test suite into ${D}/opt/ltp/testcases by manual cp -r testcases/open_posix_testsuite ${D}/opt/ltp/testcases + + # Makefile were configured in the build system + find ${D}${prefix} -name Makefile | xargs -n 1 sed -i \ + -e 's@[^ ]*-fdebug-prefix-map=[^ "]*@@g' \ + -e 's@[^ ]*-fmacro-prefix-map=[^ "]*@@g' \ + -e 's@[^ ]*--sysroot=[^ "]*@@g' } RDEPENDS_${PN} = "\ -- 2.13.3 From jpuhlman at mvista.com Wed Mar 11 22:25:44 2020 From: jpuhlman at mvista.com (Jeremy A. Puhlman) Date: Wed, 11 Mar 2020 15:25:44 -0700 Subject: [OE-core] [PATCH 4/6] gtk-doc: Fix reproducibity issues In-Reply-To: <20200311222546.30284-1-jpuhlman@mvista.com> References: <20200311222546.30284-1-jpuhlman@mvista.com> Message-ID: <20200311222546.30284-4-jpuhlman@mvista.com> From: Jeremy Puhlman path to pkg-config and python3 encoded in scripts Signed-off-by: Jeremy A. Puhlman --- meta/recipes-gnome/gtk-doc/gtk-doc_1.32.bb | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/meta/recipes-gnome/gtk-doc/gtk-doc_1.32.bb b/meta/recipes-gnome/gtk-doc/gtk-doc_1.32.bb index 50d4d99722..b508e62741 100644 --- a/meta/recipes-gnome/gtk-doc/gtk-doc_1.32.bb +++ b/meta/recipes-gnome/gtk-doc/gtk-doc_1.32.bb @@ -36,6 +36,17 @@ do_configure_prepend() { sed -i -e 's,^JH_CHECK_XML_CATALOG.*,,' ${S}/configure.ac } +do_install_append () { + # configure values for python3 and pkg-config encoded in scripts + for fn in ${bindir}/gtkdoc-depscan \ + ${bindir}/gtkdoc-mkhtml2 \ + ${datadir}/gtk-doc/python/gtkdoc/config.py; do + sed -e 's,${RECIPE_SYSROOT_NATIVE}/usr/bin/pkg-config,${bindir}/pkg-config,' \ + -e 's,${HOSTTOOLS_DIR}/python3,${bindir}/python3,' \ + -i ${D}$fn + done +} + FILES_${PN} += "${datadir}/sgml" FILES_${PN}-dev += "${libdir}/cmake" FILES_${PN}-doc = "" @@ -48,3 +59,4 @@ gtkdoc_makefiles_sysroot_preprocess() { -e "s|GTKDOC_RUN =.*|GTKDOC_RUN = \$(top_builddir)/gtkdoc-qemuwrapper|" \ ${SYSROOT_DESTDIR}${datadir}/gtk-doc/data/gtk-doc*make } + -- 2.13.3 From jpuhlman at mvista.com Wed Mar 11 22:25:45 2020 From: jpuhlman at mvista.com (Jeremy A. Puhlman) Date: Wed, 11 Mar 2020 15:25:45 -0700 Subject: [OE-core] [PATCH 5/6] dnf: fix reproducibilty issue In-Reply-To: <20200311222546.30284-1-jpuhlman@mvista.com> References: <20200311222546.30284-1-jpuhlman@mvista.com> Message-ID: <20200311222546.30284-5-jpuhlman@mvista.com> From: Jeremy Puhlman Script points to native python3 Signed-off-by: Jeremy A. Puhlman --- ...001-set-python-path-for-completion_helper.patch | 24 ++++++++++++++++++++++ meta/recipes-devtools/dnf/dnf_4.2.2.bb | 1 + 2 files changed, 25 insertions(+) create mode 100644 meta/recipes-devtools/dnf/dnf/0001-set-python-path-for-completion_helper.patch diff --git a/meta/recipes-devtools/dnf/dnf/0001-set-python-path-for-completion_helper.patch b/meta/recipes-devtools/dnf/dnf/0001-set-python-path-for-completion_helper.patch new file mode 100644 index 0000000000..448f6408bc --- /dev/null +++ b/meta/recipes-devtools/dnf/dnf/0001-set-python-path-for-completion_helper.patch @@ -0,0 +1,24 @@ +From 7e79b3b67fd5cecd7380e7e365fd88eca63b5bfa Mon Sep 17 00:00:00 2001 +From: Jeremy Puhlman +Date: Wed, 11 Mar 2020 22:10:02 +0000 +Subject: [PATCH] set python path for completion_helper + +Upstream-Status: Inappropriate [oe-core specific] +Signed-off-by: Jeremy Puhlman +--- + dnf/cli/completion_helper.py.in | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/dnf/cli/completion_helper.py.in b/dnf/cli/completion_helper.py.in +index 351226759..2835cd3b6 100644 +--- a/dnf/cli/completion_helper.py.in ++++ b/dnf/cli/completion_helper.py.in +@@ -1,4 +1,4 @@ +-#!@PYTHON_EXECUTABLE@ ++#!/usr/bin/env python3 + # + # This file is part of dnf. + # +-- +2.23.0 + diff --git a/meta/recipes-devtools/dnf/dnf_4.2.2.bb b/meta/recipes-devtools/dnf/dnf_4.2.2.bb index 5244e10cfc..a046ffc05d 100644 --- a/meta/recipes-devtools/dnf/dnf_4.2.2.bb +++ b/meta/recipes-devtools/dnf/dnf_4.2.2.bb @@ -14,6 +14,7 @@ SRC_URI = "git://github.com/rpm-software-management/dnf.git \ file://0029-Do-not-set-PYTHON_INSTALL_DIR-by-running-python.patch \ file://0030-Run-python-scripts-using-env.patch \ file://Fix-SyntaxWarning.patch \ + file://0001-set-python-path-for-completion_helper.patch \ " SRCREV = "9947306a55271b8b7c9e2b6e3b7d582885b6045d" -- 2.13.3 From jpuhlman at mvista.com Wed Mar 11 22:25:46 2020 From: jpuhlman at mvista.com (Jeremy A. Puhlman) Date: Wed, 11 Mar 2020 15:25:46 -0700 Subject: [OE-core] [PATCH 6/6] boost: fix reproducibilty issues In-Reply-To: <20200311222546.30284-1-jpuhlman@mvista.com> References: <20200311222546.30284-1-jpuhlman@mvista.com> Message-ID: <20200311222546.30284-6-jpuhlman@mvista.com> From: Jeremy Puhlman fix cmake file references of image dir path Signed-off-by: Jeremy A. Puhlman --- meta/recipes-support/boost/boost.inc | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/meta/recipes-support/boost/boost.inc b/meta/recipes-support/boost/boost.inc index e15dce4e1d..8eb9494381 100644 --- a/meta/recipes-support/boost/boost.inc +++ b/meta/recipes-support/boost/boost.inc @@ -202,6 +202,11 @@ do_install() { fi done + # Cmake files reference full paths to image + find ${D}${libdir}/cmake -type f | \ + grep 'cmake$' | \ + xargs -n 1 sed -e 's,${D}${libdir}/cmake,${libdir}/cmake,' -i + } BBCLASSEXTEND = "native nativesdk" -- 2.13.3 From mingli.yu at windriver.com Thu Mar 12 03:21:12 2020 From: mingli.yu at windriver.com (mingli.yu at windriver.com) Date: Thu, 12 Mar 2020 11:21:12 +0800 Subject: [OE-core] [PATCH] netbase: use snapshot.debian.org Message-ID: <1583983272-116095-1-git-send-email-mingli.yu@windriver.com> From: Mingli Yu Use snapshot.debian.org as the previous URL only stores the latest source file and fails to locate the source tar file if we don't upgrade timely. Signed-off-by: Mingli Yu --- meta/recipes-core/netbase/netbase_6.1.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-core/netbase/netbase_6.1.bb b/meta/recipes-core/netbase/netbase_6.1.bb index bc0049c..57faf3d 100644 --- a/meta/recipes-core/netbase/netbase_6.1.bb +++ b/meta/recipes-core/netbase/netbase_6.1.bb @@ -6,7 +6,7 @@ LICENSE = "GPLv2" LIC_FILES_CHKSUM = "file://debian/copyright;md5=3dd6192d306f582dee7687da3d8748ab" PE = "1" -SRC_URI = "${DEBIAN_MIRROR}/main/n/${BPN}/${BPN}_${PV}.tar.xz" +SRC_URI = "http://snapshot.debian.org/archive/debian/20200311T090704Z/pool/main/n/${BPN}/${BPN}_${PV}.tar.xz" SRC_URI[md5sum] = "e5871a3a5c8390557b8033cf19316a55" SRC_URI[sha256sum] = "084d743bd84d4d9380bac4c71c51e57406dce44f5a69289bb823c903e9b035d8" -- 2.7.4 From zangrc.fnst at cn.fujitsu.com Thu Mar 12 06:16:59 2020 From: zangrc.fnst at cn.fujitsu.com (zangrc) Date: Thu, 12 Mar 2020 14:16:59 +0800 Subject: [OE-core] CVE related consulting on linux-yocto on zeus branch In-Reply-To: References: Message-ID: Our team plans to submit CVE-related patches that are not included in -stable, but we found that the current version of the linux-yocto recipe is lower than the linux-yocto git repository. On which version should we make the patch. On 3/11/20 8:36 PM, Bruce Ashfield wrote: > On Wed, Mar 11, 2020 at 2:02 AM zangrc wrote: >> >> Hello, >> >> >> our team is currently working on CVE-related work. I would like to ask >> if the zeus branch of yocto has an update plan for linux-yocto in the >> near future. If not, can we submit a CVE-related patch for the >> linux-yocto of the zeus branch. > If it is part of -stable, then yes, it will be integrated into any of > the active upstream kernels. If it is in 5.2, we also have a -stable > process for those kernels as well. > > If it doesn't fall into those categories, then send any patches > (against the kernel itself) to the linux-yocto mailing list, do not > send them as patches to the linux-yocto recipe itself. > > Cheers, > > Bruce > >> -- >> Best Regards! >> Zang Ruochen >> >> >> > From raj.khem at gmail.com Thu Mar 12 07:50:14 2020 From: raj.khem at gmail.com (Khem Raj) Date: Thu, 12 Mar 2020 00:50:14 -0700 Subject: [OE-core] [PATCH] oeqa/qemuarm64: Ignore logind: failed to get session seat Message-ID: <20200312075014.3313451-1-raj.khem@gmail.com> When booting weston images this error is seen commonly, but Qemu boots the image fine, session seat error is thrown by libweston perhaps using --seat option or setting XDG_SEAT variable in weston.ini could fix it [YOCTO #13828] Signed-off-by: Khem Raj --- meta/lib/oeqa/runtime/cases/parselogs.py | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/lib/oeqa/runtime/cases/parselogs.py b/meta/lib/oeqa/runtime/cases/parselogs.py index 6444fe814c..cc4f5f8c78 100644 --- a/meta/lib/oeqa/runtime/cases/parselogs.py +++ b/meta/lib/oeqa/runtime/cases/parselogs.py @@ -131,6 +131,7 @@ ignore_errors = { '(EE) Server terminated with error (1). Closing log file.', 'dmi: Firmware registration failed.', 'irq: type mismatch, failed to map hwirq-27 for /intc', + 'logind: failed to get session seat', ] + common_errors, 'intel-core2-32' : [ 'ACPI: No _BQC method, cannot determine initial brightness', -- 2.25.1 From alex.kanavin at gmail.com Thu Mar 12 08:23:50 2020 From: alex.kanavin at gmail.com (Alexander Kanavin) Date: Thu, 12 Mar 2020 09:23:50 +0100 Subject: [OE-core] [PATCH] oeqa: enable testresults.json for testexport In-Reply-To: <3b553c8a-4c08-cb95-923c-7f03cb6d01aa@typedivision.de> References: <20200311163730.78078-1-sk@typedivision.de> <3b553c8a-4c08-cb95-923c-7f03cb6d01aa@typedivision.de> Message-ID: On Wed, 11 Mar 2020 at 22:27, Stefan Kral wrote: > Doing build and test in one pipeline turns out to be more complicated due > to: > > - build machine may be different from test machine (with access to > hardware) > - build the image is a one time job, tests may have to be repeated > reproducibly > - executing long running tests slows down image creation (for development) > - tests on dedicated hardware should be runable asynchronously when hw is > available > > Running tests by bitbake -c testimage could be an option but to provide a > full repo/bitbake/cache setup to run test cases sounds not as easy as > having just python installed. And for that, testexport does its job quite > well. > > Btw. have you ever thought about to integrate/support some external test > framework (like robot framework)? > Core project does all testing on qemu (using direct testimage); there are no resources to set up testing on real hardware. So those scenarios aren't well supported or tested, but patches/proposals welcome :) Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.kanavin at gmail.com Thu Mar 12 08:25:46 2020 From: alex.kanavin at gmail.com (Alexander Kanavin) Date: Thu, 12 Mar 2020 09:25:46 +0100 Subject: [OE-core] [PATCH] netbase: use snapshot.debian.org In-Reply-To: <1583983272-116095-1-git-send-email-mingli.yu@windriver.com> References: <1583983272-116095-1-git-send-email-mingli.yu@windriver.com> Message-ID: On Thu, 12 Mar 2020 at 04:22, wrote: > -SRC_URI = "${DEBIAN_MIRROR}/main/n/${BPN}/${BPN}_${PV}.tar.xz" > +SRC_URI = " > http://snapshot.debian.org/archive/debian/20200311T090704Z/pool/main/n/${BPN}/${BPN}_${PV}.tar.xz > " > This will break version checks and automated upgrades. Is it possible to build from git instead? Specifically: https://salsa.debian.org/md/netbase Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.kiernan at gmail.com Thu Mar 12 09:07:40 2020 From: alex.kiernan at gmail.com (Alex Kiernan) Date: Thu, 12 Mar 2020 09:07:40 +0000 Subject: [OE-core] psplash activation state w/ systemd In-Reply-To: References: <5e5adb83812fe98a76b8207588325f7996e33c85.camel@linuxfoundation.org> Message-ID: On Wed, Mar 11, 2020 at 5:27 PM Alex Kiernan wrote: > > On Wed, Mar 11, 2020 at 5:20 PM Richard Purdie > wrote: > > > > On Mon, 2020-03-09 at 15:18 +0000, Alex Kiernan wrote: > > > I've a branch with systemd 245 on it which fails testing because > > > psplash gets restarted all the time. > > > > > > But ignoring the systemd 245 piece, it looks to me like psplash could > > > be restarted under systemd 244 too as the main process exits and our > > > units aren't marked RemainAfterExit. I haven't figured out what's > > > triggering it in 245 and not 244, but I suspect it's something > > > similar > > > to this: > > > > > > https://github.com/systemd/systemd/commit/9fd32ff7d363945fbf8fdae0128702b995127558 > > > > > > Given where we are in the release cycle and how painful psplash has > > > obviously been, I'm inclined to leave it until after dunfell ships > > > and then do it as part of the whole 245 upgrade? > > > > > > Equally if you see psplash flapping during tests, it's almost > > > certainly this problem. > > > > Thanks for the report. The weird thing is that master is working with > > this as far as I can see, certainly no test failures since the last fix > > I pushed a few days ago. > > > > Is there some specific change to the unit files we should make? I'm a > > little reluctant to pull this out now given we feel like we're close to > > it working. > > > > It's basically trivial (add RemainAfterExit=yes to both units), but as > you say, given where we are and it appears to work, I don't think > now's the time to do it. > > I suspect something's changed in 245 which makes it far more likely > that you see units retriggered, but I can't for the life of me work > out which commit it is (I should stop trying to do it by inspection > and bisect it out...). > Looks like it's: https://github.com/systemd/systemd/commit/097537f07a2fab3cb73aef7bc59f2a66aa93f533 which I found via: https://github.com/systemd/systemd/issues/15091 Definitely ignore this issue for now... I suspect we do actually want the RemainAfterExit, but for now wait and watch where upstream systemd ends up on this seems like the sensible approach. -- Alex Kiernan From richard.purdie at linuxfoundation.org Thu Mar 12 09:12:08 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Thu, 12 Mar 2020 09:12:08 +0000 Subject: [OE-core] [PATCH] oeqa: enable testresults.json for testexport In-Reply-To: <20200311163730.78078-1-sk@typedivision.de> References: <20200311163730.78078-1-sk@typedivision.de> Message-ID: On Wed, 2020-03-11 at 17:37 +0100, Stefan Kral wrote: > Add the option --json-result-dir to oeqa core context to enable > testresults.json creation for test runs via testexport. > > Eg. oe-test runtime --json-result-dir . > > Signed-off-by: Stefan Kral > --- > meta/lib/oeqa/core/context.py | 30 +++++++++++++++++++++++++++++- > meta/lib/oeqa/core/runner.py | 13 ++++++++++--- > 2 files changed, 39 insertions(+), 4 deletions(-) > > diff --git a/meta/lib/oeqa/core/context.py b/meta/lib/oeqa/core/context.py > index 16320af115..b9a28ce319 100644 > --- a/meta/lib/oeqa/core/context.py > +++ b/meta/lib/oeqa/core/context.py > @@ -116,6 +116,9 @@ class OETestContextExecutor(object): > default=self.default_output_log, > help="results output log, default: %s" % self.default_output_log) > > + self.parser.add_argument('--json-result-dir', action='store', > + help="json result output dir, create testresults.json here if set") > + > group = self.parser.add_mutually_exclusive_group() > group.add_argument('--run-tests', action='store', nargs='+', > default=self.default_tests, > @@ -178,6 +181,22 @@ class OETestContextExecutor(object): > > self.module_paths = args.CASES_PATHS > > + def _get_json_result_dir(self, args): > + return args.json_result_dir > + > + def _get_configuration(self): > + td = self.tc_kwargs['init']['td'] > + configuration = {'TEST_TYPE': self.name, > + 'MACHINE': td.get("MACHINE"), > + 'DISTRO': td.get("DISTRO"), > + 'IMAGE_BASENAME': td.get("IMAGE_BASENAME"), > + 'DATETIME': td.get("DATETIME")} > + return configuration > + > + def _get_result_id(self, configuration): > + return '%s_%s_%s_%s' % (configuration['TEST_TYPE'], configuration['IMAGE_BASENAME'], > + configuration['MACHINE'], configuration['DATETIME']) > + > def _pre_run(self): > pass > > @@ -196,7 +215,16 @@ class OETestContextExecutor(object): > else: > self._pre_run() > rc = self.tc.runTests(**self.tc_kwargs['run']) > - rc.logDetails() > + > + json_result_dir = self._get_json_result_dir(args) > + if json_result_dir: > + configuration = self._get_configuration() > + rc.logDetails(json_result_dir, > + configuration, > + self._get_result_id(configuration)) > + else: > + rc.logDetails() > + > rc.logSummary(self.name) > > output_link = os.path.join(os.path.dirname(args.output_log), > diff --git a/meta/lib/oeqa/core/runner.py b/meta/lib/oeqa/core/runner.py > index f656e1a9c5..fc3872aa73 100644 > --- a/meta/lib/oeqa/core/runner.py > +++ b/meta/lib/oeqa/core/runner.py > @@ -319,10 +319,17 @@ class OETestResultJSONHelper(object): > the_file.write(file_content) > > def dump_testresult_file(self, write_dir, configuration, result_id, test_result): > - bb.utils.mkdirhier(write_dir) > - lf = bb.utils.lockfile(os.path.join(write_dir, 'jsontestresult.lock')) > + try: > + import bb > + has_bb = True > + lf = bb.utils.lockfile(os.path.join(write_dir, 'jsontestresult.lock')) > + bb.utils.mkdirhier(write_dir, exist_ok=True) This threw errors under testing since mkdirhier doesn't have an exist_ok parameter. The ordering is also reversed, we should mkdir, then lock. > + except ImportError: > + has_bb = False > + os.makedirs(write_dir) I suspect the parameter was meant to go here. I've added a fix to -next for this. Cheers, Richard From stefan.ghinea at windriver.com Thu Mar 12 09:23:22 2020 From: stefan.ghinea at windriver.com (Stefan Ghinea) Date: Thu, 12 Mar 2020 11:23:22 +0200 Subject: [OE-core] [PATCH] [zeus] aspell: CVE-2019-20433 Message-ID: <20200312092322.28506-1-stefan.ghinea@windriver.com> libaspell.a in GNU Aspell before 0.60.8 has a buffer over-read for a string ending with a single '\0' byte, if the encoding is set to ucs-2 or ucs-4 outside of the application, as demonstrated by the ASPELL_CONF environment variable. References: https://nvd.nist.gov/vuln/detail/CVE-2019-20433 Upstream patches: https://github.com/GNUAspell/aspell/commit/de29341638833ba7717bd6b5e6850998454b044b https://github.com/GNUAspell/aspell/commit/cefd447e5528b08bb0cd6656bc52b4255692cefc Signed-off-by: Stefan Ghinea --- .../aspell/aspell/CVE-2019-20433-0001.patch | 999 ++++++++++++++++++ .../aspell/aspell/CVE-2019-20433-0002.patch | 68 ++ meta/recipes-support/aspell/aspell_0.60.7.bb | 2 + 3 files changed, 1069 insertions(+) create mode 100644 meta/recipes-support/aspell/aspell/CVE-2019-20433-0001.patch create mode 100644 meta/recipes-support/aspell/aspell/CVE-2019-20433-0002.patch diff --git a/meta/recipes-support/aspell/aspell/CVE-2019-20433-0001.patch b/meta/recipes-support/aspell/aspell/CVE-2019-20433-0001.patch new file mode 100644 index 0000000000..fd68461e32 --- /dev/null +++ b/meta/recipes-support/aspell/aspell/CVE-2019-20433-0001.patch @@ -0,0 +1,999 @@ +From de29341638833ba7717bd6b5e6850998454b044b Mon Sep 17 00:00:00 2001 +From: Kevin Atkinson +Date: Sat, 17 Aug 2019 17:06:53 -0400 +Subject: [PATCH 1/2] Don't allow null-terminated UCS-2/4 strings using the + original API. + +Detect if the encoding is UCS-2/4 and the length is -1 in affected API +functions and refuse to convert the string. If the string ends up +being converted somehow, abort with an error message in DecodeDirect +and ConvDirect. To convert a null terminated string in +Decode/ConvDirect, a negative number corresponding to the width of the +underlying character type for the encoding is expected; for example, +if the encoding is "ucs-2" then a the size is expected to be -2. + +Also fix a 1-3 byte over-read in DecodeDirect when reading UCS-2/4 +strings when a size is provided (found by OSS-Fuzz). + +Also fix a bug in DecodeDirect that caused DocumentChecker to return +the wrong offsets when working with UCS-2/4 strings. + +CVE: CVE-2019-20433 +Upstream-Status: Backport [https://github.com/GNUAspell/aspell/commit/de29341638833ba7717bd6b5e6850998454b044b] + +[SG: - adjusted context + - discarded test changes as test framework is not available + - discarded manual entry changes for features that aren't backported] +Signed-off-by: Stefan Ghinea +--- + auto/MkSrc/CcHelper.pm | 99 ++++++++++++++++++++++++++++++++++--- + auto/MkSrc/Create.pm | 5 +- + auto/MkSrc/Info.pm | 5 +- + auto/MkSrc/ProcCc.pm | 24 +++++---- + auto/MkSrc/ProcImpl.pm | 57 +++++++++++++++------ + auto/MkSrc/Read.pm | 4 +- + auto/mk-src.in | 44 +++++++++++++++-- + common/convert.cpp | 39 ++++++++++++--- + common/convert.hpp | 38 +++++++++++++- + common/document_checker.cpp | 17 ++++++- + common/document_checker.hpp | 1 + + common/version.cpp | 15 ++++-- + configure.ac | 8 +++ + manual/aspell.texi | 58 ++++++++++++++++------ + manual/readme.texi | 70 +++++++++++++++++++++----- + 15 files changed, 409 insertions(+), 75 deletions(-) + +diff --git a/auto/MkSrc/CcHelper.pm b/auto/MkSrc/CcHelper.pm +index f2de991..0044335 100644 +--- a/auto/MkSrc/CcHelper.pm ++++ b/auto/MkSrc/CcHelper.pm +@@ -10,8 +10,8 @@ BEGIN { + use Exporter; + our @ISA = qw(Exporter); + our @EXPORT = qw(to_c_return_type c_error_cond +- to_type_name make_desc make_func call_func +- make_c_method call_c_method form_c_method ++ to_type_name make_desc make_func call_func get_c_func_name ++ make_c_method make_wide_macro call_c_method form_c_method + make_cxx_method); + } + +@@ -90,6 +90,69 @@ sub make_func ( $ \@ $ ; \% ) { + ')')); + } + ++=item make_wide_version NAME @TYPES PARMS ; %ACCUM ++ ++Creates the wide character version of the function if needed ++ ++=cut ++ ++sub make_wide_version ( $ \@ $ ; \% ) { ++ my ($name, $d, $p, $accum) = @_; ++ my @d = @$d; ++ shift @d; ++ return '' unless grep {$_->{type} eq 'encoded string'} @d; ++ $accum->{sys_headers}{'stddef.h'} = true; ++ $accum->{suffix}[5] = <<'---'; ++ ++/******************* private implemantion details *********************/ ++ ++#ifdef __cplusplus ++# define aspell_cast_(type, expr) (static_cast(expr)) ++# define aspell_cast_from_wide_(str) (static_cast(str)) ++#else ++# define aspell_cast_(type, expr) ((type)(expr)) ++# define aspell_cast_from_wide_(str) ((const char *)(str)) ++#endif ++--- ++ my @parms = map {$_->{type} eq 'encoded string' ++ ? ($_->{name}, $_->{name}.'_size') ++ : $_->{name}} @d; ++ $name = to_lower $name; ++ $accum->{suffix}[0] = <<'---'; ++/**********************************************************************/ ++ ++#ifdef ASPELL_ENCODE_SETTING_SECURE ++--- ++ $accum->{suffix}[2] = "#endif\n"; ++ my @args = map {$_->{type} eq 'encoded string' ++ ? ($_->{name}, "$_->{name}_size", '-1') ++ : $_->{name}} @d; ++ $accum->{suffix}[1] .= ++ (join '', ++ "#define $name", ++ '(', join(', ', @parms), ')', ++ "\\\n ", ++ $name, '_wide', ++ '(', join(', ', @args), ')', ++ "\n"); ++ @args = map {$_->{type} eq 'encoded string' ++ ? ("aspell_cast_from_wide_($_->{name})", ++ "$_->{name}_size*aspell_cast_(int,sizeof(*($_->{name})))", ++ "sizeof(*($_->{name}))") ++ : $_->{name}} @d; ++ return (join '', ++ "\n", ++ "/* version of $name that is safe to use with (null terminated) wide characters */\n", ++ '#define ', ++ $name, '_w', ++ '(', join(', ', @parms), ')', ++ "\\\n ", ++ $name, '_wide', ++ '(', join(', ', @args), ')', ++ "\n"); ++} ++ ++ + =item call_func NAME @TYPES PARMS ; %ACCUM + + Return a string to call a func. Will prefix the function with return +@@ -103,7 +166,6 @@ Parms can be any of: + + sub call_func ( $ \@ $ ; \% ) { + my ($name, $d, $p, $accum) = @_; +- $accum = {} unless defined $accum; + my @d = @$d; + my $func_ret = to_type_name(shift @d, {%$p,pos=>'return'}, %$accum); + return (join '', +@@ -148,8 +210,14 @@ sub to_type_name ( $ $ ; \% ) { + my $name = $t->{name}; + my $type = $t->{type}; + +- return ( (to_type_name {%$d, type=>'string'}, $p, %$accum) , +- (to_type_name {%$d, type=>'int', name=>"$d->{name}_size"}, $p, %$accum) ) ++ if ($name eq 'encoded string' && $is_cc && $pos eq 'parm') { ++ my @types = ((to_type_name {%$d, type=>($p->{wide}?'const void pointer':'string')}, $p, %$accum), ++ (to_type_name {%$d, type=>'int', name=>"$d->{name}_size"}, $p, %$accum)); ++ push @types, (to_type_name {%$d, type=>'int', name=>"$d->{name}_type_width"}, $p, %$accum) if $p->{wide}; ++ return @types; ++ } ++ return ( (to_type_name {%$d, type=>($p->{wide}?'const void pointer':'string')}, $p, %$accum) , ++ (to_type_name {%$d, type=>'int', name=>"$d->{name}_size"}, $p, %$accum) ) + if $name eq 'encoded string' && $is_cc && $pos eq 'parm'; + + my $str; +@@ -174,7 +242,7 @@ sub to_type_name ( $ $ ; \% ) { + $str .= "String"; + } + } elsif ($name eq 'encoded string') { +- $str .= "const char *"; ++ $str .= $p->{wide} ? "const void *" : "const char *"; + } elsif ($name eq '') { + $str .= "void"; + } elsif ($name eq 'bool' && $is_cc) { +@@ -186,7 +254,7 @@ sub to_type_name ( $ $ ; \% ) { + if ($t->{pointer}) { + $accum->{types}->{$name} = $t; + } else { +- $accum->{headers}->{$t->{created_in}} = true; ++ $accum->{headers}->{$t->{created_in}} = true unless $mode eq 'cc'; + } + $str .= "$c_type Aspell" if $mode eq 'cc'; + $str .= to_mixed($name); +@@ -214,6 +282,7 @@ sub to_type_name ( $ $ ; \% ) { + return $str; + } + ++ + =item make_desc DESC ; LEVEL + + Make a C comment out of DESC optionally indenting it LEVEL spaces. +@@ -286,6 +355,7 @@ sub form_c_method ($ $ $ ; \% ) + } else { + $func = "aspell $class $name"; + } ++ $func .= " wide" if $p->{wide}; + if (exists $d->{'const'}) { + splice @data, 1, 0, {type => "const $class", name=> $this_name}; + } else { +@@ -306,6 +376,21 @@ sub make_c_method ($ $ $ ; \%) + return &make_func(@ret); + } + ++sub get_c_func_name ($ $ $) ++{ ++ my @ret = &form_c_method(@_); ++ return undef unless @ret > 0; ++ return to_lower $ret[0]; ++} ++ ++sub make_wide_macro ($ $ $ ; \%) ++{ ++ my @ret = &form_c_method(@_); ++ return undef unless @ret > 0; ++ my $str = &make_wide_version(@ret); ++ return $str; ++} ++ + sub call_c_method ($ $ $ ; \%) + { + my @ret = &form_c_method(@_); +diff --git a/auto/MkSrc/Create.pm b/auto/MkSrc/Create.pm +index d39b60e..630ede5 100644 +--- a/auto/MkSrc/Create.pm ++++ b/auto/MkSrc/Create.pm +@@ -77,8 +77,10 @@ sub create_cc_file ( % ) { + $file .= "#include \"aspell.h\"\n" if $p{type} eq 'cxx'; + $file .= "#include \"settings.h\"\n" if $p{type} eq 'native_impl' && $p{name} eq 'errors'; + $file .= "#include \"gettext.h\"\n" if $p{type} eq 'native_impl' && $p{name} eq 'errors'; ++ $file .= cmap {"#include <$_>\n"} sort keys %{$accum{sys_headers}}; + $file .= cmap {"#include \"".to_lower($_).".hpp\"\n"} sort keys %{$accum{headers}}; +- $file .= "#ifdef __cplusplus\nextern \"C\" {\n#endif\n" if $p{header} && !$p{cxx}; ++ $file .= "\n#ifdef __cplusplus\nextern \"C\" {\n#endif\n" if $p{header} && !$p{cxx}; ++ $file .= join('', grep {defined $_} @{$accum{prefix}}); + $file .= "\nnamespace $p{namespace} {\n\n" if $p{cxx}; + if (defined $info{forward}{proc}{$p{type}}) { + my @types = sort {$a->{name} cmp $b->{name}} (values %{$accum{types}}); +@@ -86,6 +88,7 @@ sub create_cc_file ( % ) { + } + $file .= "\n"; + $file .= $body; ++ $file .= join('', grep {defined $_} @{$accum{suffix}}); + $file .= "\n\n}\n\n" if $p{cxx}; + $file .= "#ifdef __cplusplus\n}\n#endif\n" if $p{header} && !$p{cxx}; + $file .= "#endif /* $hm */\n" if $p{header}; +diff --git a/auto/MkSrc/Info.pm b/auto/MkSrc/Info.pm +index c644028..ace8e21 100644 +--- a/auto/MkSrc/Info.pm ++++ b/auto/MkSrc/Info.pm +@@ -60,6 +60,7 @@ each proc sub should take the following argv + the object from which it is a member of + no native: do not attempt to create a native implementation + treat as object: treat as a object rather than a pointer ++ no conv: do not converted an encoded string + + The %info structure is initialized as follows: + +@@ -104,8 +105,8 @@ The %info structure is initialized as follows: + errors => {}, # possible errors + method => { + # A class method +- options => ['desc', 'posib err', 'c func', 'const', +- 'c only', 'c impl', 'cxx impl'], ++ options => ['desc', 'posib err', 'c func', 'const', 'no conv', 'on conv error', ++ 'c only', 'c impl', 'cxx impl', 'cc extra'], + groups => undef}, + constructor => { + # A class constructor +diff --git a/auto/MkSrc/ProcCc.pm b/auto/MkSrc/ProcCc.pm +index 47c4338..98cc435 100644 +--- a/auto/MkSrc/ProcCc.pm ++++ b/auto/MkSrc/ProcCc.pm +@@ -23,7 +23,7 @@ use MkSrc::Info; + sub make_c_object ( $ @ ); + + $info{group}{proc}{cc} = sub { +- my ($data) = @_; ++ my ($data, at rest) = @_; + my $ret; + my $stars = (70 - length $data->{name})/2; + $ret .= "/"; +@@ -33,14 +33,14 @@ $info{group}{proc}{cc} = sub { + $ret .= "/\n"; + foreach my $d (@{$data->{data}}) { + $ret .= "\n\n"; +- $ret .= $info{$d->{type}}{proc}{cc}->($d); ++ $ret .= $info{$d->{type}}{proc}{cc}->($d, at rest); + } + $ret .= "\n\n"; + return $ret; + }; + + $info{enum}{proc}{cc} = sub { +- my ($d) = @_; ++ my ($d, at rest) = @_; + my $n = "Aspell".to_mixed($d->{name}); + return ("\n". + make_desc($d->{desc}). +@@ -58,21 +58,26 @@ $info{struct}{proc}{cc} = sub { + }; + + $info{union}{proc}{cc} = sub { +- return make_c_object "union", $_[0]; ++ return make_c_object "union", @_; + }; + + $info{class}{proc}{cc} = sub { +- my ($d) = @_; ++ my ($d,$accum) = @_; + my $class = $d->{name}; + my $classname = "Aspell".to_mixed($class); + my $ret = ""; + $ret .= "typedef struct $classname $classname;\n\n"; + foreach (@{$d->{data}}) { +- my $s = make_c_method($class, $_, {mode=>'cc'}); ++ my $s = make_c_method($class, $_, {mode=>'cc'}, %$accum); + next unless defined $s; + $ret .= "\n"; + $ret .= make_desc($_->{desc}); +- $ret .= make_c_method($class, $_, {mode=>'cc'}).";\n"; ++ $ret .= make_c_method($class, $_, {mode=>'cc'}, %$accum).";\n"; ++ if (grep {$_->{type} eq 'encoded string'} @{$_->{data}}) { ++ $ret .= make_c_method($class, $_, {mode=>'cc', wide=>true}, %$accum).";\n"; ++ $ret .= make_wide_macro($class, $_, {mode=>'cc'}, %$accum); ++ } ++ $ret .= "\n".$_->{'cc extra'}."\n" if defined $_->{'cc extra'}; + } + $ret .= "\n"; + return $ret; +@@ -105,7 +110,8 @@ $info{errors}{proc}{cc} = sub { + }; + + sub make_c_object ( $ @ ) { +- my ($t, $d) = @_; ++ my ($t, $d, $accum) = @_; ++ $accum = {} unless defined $accum; + my $struct; + $struct .= "Aspell"; + $struct .= to_mixed($d->{name}); +@@ -120,7 +126,7 @@ sub make_c_object ( $ @ ) { + "\n};\n"), + "typedef $t $struct $struct;", + join ("\n", +- map {make_c_method($d->{name}, $_, {mode=>'cc'}).";"} ++ map {make_c_method($d->{name}, $_, {mode=>'cc'}, %$accum).";"} + grep {$_->{type} eq 'method'} + @{$d->{data}}) + )."\n"; +diff --git a/auto/MkSrc/ProcImpl.pm b/auto/MkSrc/ProcImpl.pm +index b8628fd..3d0f220 100644 +--- a/auto/MkSrc/ProcImpl.pm ++++ b/auto/MkSrc/ProcImpl.pm +@@ -45,10 +45,13 @@ $info{class}{proc}{impl} = sub { + foreach (grep {$_ ne ''} split /\s*,\s*/, $data->{'c impl headers'}) { + $accum->{headers}{$_} = true; + } +- foreach my $d (@{$data->{data}}) { ++ my @d = @{$data->{data}}; ++ while (@d) { ++ my $d = shift @d; ++ my $need_wide = false; + next unless one_of $d->{type}, qw(method constructor destructor); + my @parms = @{$d->{data}} if exists $d->{data}; +- my $m = make_c_method $data->{name}, $d, {mode=>'cc_cxx', use_name=>true}, %$accum; ++ my $m = make_c_method $data->{name}, $d, {mode=>'cc_cxx', use_name=>true, wide=>$d->{wide}}, %$accum; + next unless defined $m; + $ret .= "extern \"C\" $m\n"; + $ret .= "{\n"; +@@ -57,24 +60,49 @@ $info{class}{proc}{impl} = sub { + } else { + if ($d->{type} eq 'method') { + my $ret_type = shift @parms; +- my $ret_native = to_type_name $ret_type, {mode=>'native_no_err', pos=>'return'}, %$accum; ++ my $ret_native = to_type_name $ret_type, {mode=>'native_no_err', pos=>'return', wide=>$d->{wide}}, %$accum; + my $snum = 0; ++ my $call_fun = $d->{name}; ++ my @call_parms; + foreach (@parms) { + my $n = to_lower($_->{name}); +- if ($_->{type} eq 'encoded string') { +- $accum->{headers}{'mutable string'} = true; +- $accum->{headers}{'convert'} = true; +- $ret .= " ths->temp_str_$snum.clear();\n"; +- $ret .= " ths->to_internal_->convert($n, ${n}_size, ths->temp_str_$snum);\n"; +- $ret .= " unsigned int s$snum = ths->temp_str_$snum.size();\n"; +- $_ = "MutableString(ths->temp_str_$snum.mstr(), s$snum)"; +- $snum++; ++ if ($_->{type} eq 'encoded string' && !exists($d->{'no conv'})) { ++ $need_wide = true unless $d->{wide}; ++ die unless exists $d->{'posib err'}; ++ $accum->{headers}{'mutable string'} = true; ++ $accum->{headers}{'convert'} = true; ++ my $name = get_c_func_name $data->{name}, $d, {mode=>'cc_cxx', use_name=>true, wide=>$d->{wide}}; ++ $ret .= " ths->temp_str_$snum.clear();\n"; ++ if ($d->{wide}) { ++ $ret .= " ${n}_size = get_correct_size(\"$name\", ths->to_internal_->in_type_width(), ${n}_size, ${n}_type_width);\n"; ++ } else { ++ $ret .= " PosibErr ${n}_fixed_size = get_correct_size(\"$name\", ths->to_internal_->in_type_width(), ${n}_size);\n"; ++ if (exists($d->{'on conv error'})) { ++ $ret .= " if (${n}_fixed_size.get_err()) {\n"; ++ $ret .= " ".$d->{'on conv error'}."\n"; ++ $ret .= " } else {\n"; ++ $ret .= " ${n}_size = ${n}_fixed_size;\n"; ++ $ret .= " }\n"; ++ } else { ++ $ret .= " ths->err_.reset(${n}_fixed_size.release_err());\n"; ++ $ret .= " if (ths->err_ != 0) return ".(c_error_cond $ret_type).";\n"; ++ } ++ } ++ $ret .= " ths->to_internal_->convert($n, ${n}_size, ths->temp_str_$snum);\n"; ++ $ret .= " unsigned int s$snum = ths->temp_str_$snum.size();\n"; ++ push @call_parms, "MutableString(ths->temp_str_$snum.mstr(), s$snum)"; ++ $snum++; ++ } elsif ($_->{type} eq 'encoded string') { ++ $need_wide = true unless $d->{wide}; ++ push @call_parms, $n, "${n}_size"; ++ push @call_parms, "${n}_type_width" if $d->{wide}; ++ $call_fun .= " wide" if $d->{wide}; + } else { +- $_ = $n; ++ push @call_parms, $n; + } + } +- my $parms = '('.(join ', ', @parms).')'; +- my $exp = "ths->".to_lower($d->{name})."$parms"; ++ my $parms = '('.(join ', ', @call_parms).')'; ++ my $exp = "ths->".to_lower($call_fun)."$parms"; + if (exists $d->{'posib err'}) { + $accum->{headers}{'posib err'} = true; + $ret .= " PosibErr<$ret_native> ret = $exp;\n"; +@@ -118,6 +146,7 @@ $info{class}{proc}{impl} = sub { + } + } + $ret .= "}\n\n"; ++ unshift @d,{%$d, wide=>true} if $need_wide; + } + return $ret; + }; +diff --git a/auto/MkSrc/Read.pm b/auto/MkSrc/Read.pm +index 4b3d1d0..4bf640e 100644 +--- a/auto/MkSrc/Read.pm ++++ b/auto/MkSrc/Read.pm +@@ -88,13 +88,13 @@ sub advance ( ) { + $in_pod = $1 if $line =~ /^\=(\w+)/; + $line = '' if $in_pod; + $in_pod = undef if $in_pod && $in_pod eq 'cut'; +- $line =~ s/\#.*$//; ++ $line =~ s/(? "%expression" is not a valid regular expression. + parms => expression ++ + } + group: speller + { +@@ -650,6 +651,7 @@ class: speller + posib err + desc => Returns 0 if it is not in the dictionary, + 1 if it is, or -1 on error. ++ on conv error => return 0; + / + bool + encoded string: word +@@ -715,6 +717,8 @@ class: speller + desc => Return NULL on error. + The word list returned by suggest is only + valid until the next call to suggest. ++ on conv error => ++ word = NULL; word_size = 0; + / + const word list + encoded string: word +@@ -840,7 +844,6 @@ class: document checker + void + + method: process +- + desc => Process a string. + The string passed in should only be split on + white space characters. Furthermore, between +@@ -849,10 +852,10 @@ class: document checker + in the document. Passing in strings out of + order, skipping strings or passing them in + more than once may lead to undefined results. ++ no conv + / + void +- string: str +- int: size ++ encoded string: str + + method: next misspelling + +@@ -860,9 +863,23 @@ class: document checker + processed string. If there are no more + misspelled words, then token.word will be + NULL and token.size will be 0 ++ cc extra => ++ \#define aspell_document_checker_next_misspelling_w(type, ths) \\ ++ aspell_document_checker_next_misspelling_adj(ths, sizeof(type)) + / + token object + ++ method: next misspelling adj ++ desc => internal: do not use ++ c impl => ++ Token res = ths->next_misspelling(); ++ res.offset /= type_width; ++ res.len /= type_width; ++ return res; ++ / ++ token object ++ int: type_width ++ + method: filter + + desc => Returns the underlying filter class. +@@ -922,9 +939,30 @@ class: string enumeration + ths->from_internal_->append_null(ths->temp_str); + return ths->temp_str.data(); + \} ++ cc extra => ++ \#define aspell_string_enumeration_next_w(type, ths) \\ ++ aspell_cast_(const type *, aspell_string_enumeration_next_wide(ths, sizeof(type))) + / + const string + ++ method: next wide ++ c impl => ++ const char * s = ths->next(); ++ if (s == 0) { ++ return s; ++ } else if (ths->from_internal_ == 0) \{ ++ assert(type_width == 1); ++ return s; ++ \} else \{ ++ assert(type_width == ths->from_internal_->out_type_width()); ++ ths->temp_str.clear(); ++ ths->from_internal_->convert(s,-1,ths->temp_str); ++ ths->from_internal_->append_null(ths->temp_str); ++ return ths->temp_str.data(); ++ \} ++ / ++ const void pointer ++ int: type_width + } + group: info + { +diff --git a/common/convert.cpp b/common/convert.cpp +index 1add95a..7ae0317 100644 +--- a/common/convert.cpp ++++ b/common/convert.cpp +@@ -541,18 +541,25 @@ namespace acommon { + // Trivial Conversion + // + ++ const char * unsupported_null_term_wide_string_msg = ++ "Null-terminated wide-character strings unsupported when used this way."; ++ + template + struct DecodeDirect : public Decode + { ++ DecodeDirect() {type_width = sizeof(Chr);} + void decode(const char * in0, int size, FilterCharVector & out) const { + const Chr * in = reinterpret_cast(in0); +- if (size == -1) { ++ if (size == -sizeof(Chr)) { + for (;*in; ++in) +- out.append(*in); ++ out.append(*in, sizeof(Chr)); ++ } else if (size <= -1) { ++ fprintf(stderr, "%s\n", unsupported_null_term_wide_string_msg); ++ abort(); + } else { +- const Chr * stop = reinterpret_cast(in0 +size); ++ const Chr * stop = reinterpret_cast(in0) + size/sizeof(Chr); + for (;in != stop; ++in) +- out.append(*in); ++ out.append(*in, sizeof(Chr)); + } + } + PosibErr decode_ec(const char * in0, int size, +@@ -565,6 +572,7 @@ namespace acommon { + template + struct EncodeDirect : public Encode + { ++ EncodeDirect() {type_width = sizeof(Chr);} + void encode(const FilterChar * in, const FilterChar * stop, + CharVector & out) const { + for (; in != stop; ++in) { +@@ -594,11 +602,15 @@ namespace acommon { + template + struct ConvDirect : public DirectConv + { ++ ConvDirect() {type_width = sizeof(Chr);} + void convert(const char * in0, int size, CharVector & out) const { +- if (size == -1) { ++ if (size == -sizeof(Chr)) { + const Chr * in = reinterpret_cast(in0); + for (;*in != 0; ++in) + out.append(in, sizeof(Chr)); ++ } else if (size <= -1) { ++ fprintf(stderr, "%s\n", unsupported_null_term_wide_string_msg); ++ abort(); + } else { + out.append(in0, size); + } +@@ -1121,5 +1133,20 @@ namespace acommon { + } + return 0; + } +- ++ ++ PosibErr unsupported_null_term_wide_string_err_(const char * func) { ++ static bool reported_to_stderr = false; ++ PosibErr err = make_err(other_error, unsupported_null_term_wide_string_msg); ++ if (!reported_to_stderr) { ++ CERR.printf("ERROR: %s: %s\n", func, unsupported_null_term_wide_string_msg); ++ reported_to_stderr = true; ++ } ++ return err; ++ } ++ ++ void unsupported_null_term_wide_string_abort_(const char * func) { ++ CERR.printf("%s: %s\n", unsupported_null_term_wide_string_msg); ++ abort(); ++ } ++ + } +diff --git a/common/convert.hpp b/common/convert.hpp +index 76332ee..c948973 100644 +--- a/common/convert.hpp ++++ b/common/convert.hpp +@@ -7,6 +7,8 @@ + #ifndef ASPELL_CONVERT__HPP + #define ASPELL_CONVERT__HPP + ++#include "settings.h" ++ + #include "string.hpp" + #include "posib_err.hpp" + #include "char_vector.hpp" +@@ -25,8 +27,9 @@ namespace acommon { + typedef const Config CacheConfig; + typedef const char * CacheKey; + String key; ++ int type_width; // type width in bytes + bool cache_key_eq(const char * l) const {return key == l;} +- ConvBase() {} ++ ConvBase() : type_width(1) {} + private: + ConvBase(const ConvBase &); + void operator=(const ConvBase &); +@@ -56,6 +59,8 @@ namespace acommon { + virtual ~Encode() {} + }; + struct DirectConv { // convert directly from in_code to out_code. ++ int type_width; // type width in bytes ++ DirectConv() : type_width(1) {} + // should not take ownership of decode and encode. + // decode and encode guaranteed to stick around for the life + // of the object. +@@ -126,6 +131,9 @@ namespace acommon { + const char * in_code() const {return decode_->key.c_str();} + const char * out_code() const {return encode_->key.c_str();} + ++ int in_type_width() const {return decode_->type_width;} ++ int out_type_width() const {return encode_->type_width;} ++ + void append_null(CharVector & out) const + { + const char nul[4] = {0,0,0,0}; // 4 should be enough +@@ -191,6 +199,10 @@ namespace acommon { + } + } + ++ void convert(const void * in, int size, CharVector & out) { ++ convert(static_cast(in), size, out); ++ } ++ + void generic_convert(const char * in, int size, CharVector & out); + + }; +@@ -412,6 +424,30 @@ namespace acommon { + return operator()(str, str + byte_size);} + }; + ++#ifdef SLOPPY_NULL_TERM_STRINGS ++ static const bool sloppy_null_term_strings = true; ++#else ++ static const bool sloppy_null_term_strings = false; ++#endif ++ ++ PosibErr unsupported_null_term_wide_string_err_(const char * func); ++ void unsupported_null_term_wide_string_abort_(const char * func); ++ ++ static inline PosibErr get_correct_size(const char * func, int conv_type_width, int size) { ++ if (sloppy_null_term_strings && size <= -1) ++ return -conv_type_width; ++ if (size <= -1 && -conv_type_width != size) ++ return unsupported_null_term_wide_string_err_(func); ++ return size; ++ } ++ static inline int get_correct_size(const char * func, int conv_type_width, int size, int type_width) { ++ if ((sloppy_null_term_strings || type_width <= -1) && size <= -1) ++ return -conv_type_width; ++ if (size <= -1 && conv_type_width != type_width) ++ unsupported_null_term_wide_string_abort_(func); ++ return size; ++ } ++ + } + + #endif +diff --git a/common/document_checker.cpp b/common/document_checker.cpp +index 5e510c4..0ccf1cd 100644 +--- a/common/document_checker.cpp ++++ b/common/document_checker.cpp +@@ -44,7 +44,9 @@ namespace acommon { + void DocumentChecker::process(const char * str, int size) + { + proc_str_.clear(); +- conv_->decode(str, size, proc_str_); ++ PosibErr fixed_size = get_correct_size("aspell_document_checker_process", conv_->in_type_width(), size); ++ if (!fixed_size.has_err()) ++ conv_->decode(str, fixed_size, proc_str_); + proc_str_.append(0); + FilterChar * begin = proc_str_.pbegin(); + FilterChar * end = proc_str_.pend() - 1; +@@ -53,6 +55,19 @@ namespace acommon { + tokenizer_->reset(begin, end); + } + ++ void DocumentChecker::process_wide(const void * str, int size, int type_width) ++ { ++ proc_str_.clear(); ++ int fixed_size = get_correct_size("aspell_document_checker_process", conv_->in_type_width(), size, type_width); ++ conv_->decode(static_cast(str), fixed_size, proc_str_); ++ proc_str_.append(0); ++ FilterChar * begin = proc_str_.pbegin(); ++ FilterChar * end = proc_str_.pend() - 1; ++ if (filter_) ++ filter_->process(begin, end); ++ tokenizer_->reset(begin, end); ++ } ++ + Token DocumentChecker::next_misspelling() + { + bool correct; +diff --git a/common/document_checker.hpp b/common/document_checker.hpp +index d35bb88..11a3c73 100644 +--- a/common/document_checker.hpp ++++ b/common/document_checker.hpp +@@ -36,6 +36,7 @@ namespace acommon { + PosibErr setup(Tokenizer *, Speller *, Filter *); + void reset(); + void process(const char * str, int size); ++ void process_wide(const void * str, int size, int type_width); + Token next_misspelling(); + + Filter * filter() {return filter_;} +diff --git a/common/version.cpp b/common/version.cpp +index 414d938..9e60b75 100644 +--- a/common/version.cpp ++++ b/common/version.cpp +@@ -1,8 +1,17 @@ + #include "settings.h" + +-extern "C" const char * aspell_version_string() { + #ifdef NDEBUG +- return VERSION " NDEBUG"; ++# define NDEBUG_STR " NDEBUG" ++#else ++# define NDEBUG_STR ++#endif ++ ++#ifdef SLOPPY_NULL_TERM_STRINGS ++# define SLOPPY_STR " SLOPPY" ++#else ++# define SLOPPY_STR + #endif +- return VERSION; ++ ++extern "C" const char * aspell_version_string() { ++ return VERSION NDEBUG_STR SLOPPY_STR; + } +diff --git a/configure.ac b/configure.ac +index 60e3b39..a5d51e3 100644 +--- a/configure.ac ++++ b/configure.ac +@@ -73,6 +73,9 @@ AC_ARG_ENABLE(filter-version-control, + AC_ARG_ENABLE(32-bit-hash-fun, + AS_HELP_STRING([--enable-32-bit-hash-fun],[use 32-bit hash function for compiled dictionaries])) + ++AC_ARG_ENABLE(sloppy-null-term-strings, ++ AS_HELP_STRING([--enable-sloppy-null-term-strings],[allows allow null terminated UCS-2 and UCS-4 strings])) ++ + AC_ARG_ENABLE(pspell-compatibility, + AS_HELP_STRING([--disable-pspell-compatibility],[don't install pspell compatibility libraries])) + +@@ -141,6 +144,11 @@ then + AC_DEFINE(USE_32_BIT_HASH_FUN, 1, [Defined if 32-bit hash function should be used for compiled dictionaries.]) + fi + ++if test "$enable_sloppy_null_term_strings" = "yes" ++then ++ AC_DEFINE(SLOPPY_NULL_TERM_STRINGS, 1, [Defined if null-terminated UCS-2 and UCS-4 strings should always be allowed.]) ++fi ++ + AM_CONDITIONAL(PSPELL_COMPATIBILITY, + [test "$enable_pspell_compatibility" != "no"]) + AM_CONDITIONAL(INCREMENTED_SONAME, +diff --git a/manual/aspell.texi b/manual/aspell.texi +index 45fa091..f400e06 100644 +--- a/manual/aspell.texi ++++ b/manual/aspell.texi +@@ -158,7 +158,8 @@ Installing + + * Generic Install Instructions:: + * HTML Manuals and "make clean":: +-* Curses Notes:: ++* Curses Notes:: ++* Upgrading from Aspell 0.60.7:: + * Loadable Filter Notes:: + * Upgrading from Aspell 0.50:: + * Upgrading from Aspell .33/Pspell .12:: +@@ -2206,18 +2207,26 @@ int correct = aspell_speller_check(spell_checker, @var{word}, @var{size}); + @end smallexample + + @noindent +- at var{word} is expected to be a @code{const char *} character +-string. If the encoding is set to be @code{ucs-2} or +- at code{ucs-4} @var{word} is expected to be a cast +-from either @code{const u16int *} or @code{const u32int *} +-respectively. @code{u16int} and @code{u32int} are generally +- at code{unsigned short} and @code{unsigned int} respectively. +- at var{size} is the length of the string or @code{-1} if the string +-is null terminated. If the string is a cast from @code{const u16int +-*} or @code{const u32int *} then @code{@i{size}} is the amount of +-space in bytes the string takes up after being cast to @code{const +-char *} and not the true size of the string. @code{sspell_speller_check} +-will return @code{0} if it is not found and non-zero otherwise. ++ at var{word} is expected to be a @code{const char *} character string. ++ at var{size} is the length of the string or @code{-1} if the string is ++null terminated. @code{aspell_speller_check} will return @code{0} if it is not found ++and non-zero otherwise. ++ ++If you are using the @code{ucs-2} or @code{ucs-4} encoding then the ++string is expected to be either a 2 or 4 byte wide integer ++(respectively) and the @code{_w} macro vesion should be used: ++ ++ at smallexample ++int correct = aspell_speller_check_w(spell_checker, @var{word}, @var{size}); ++ at end smallexample ++ ++The macro will cast the string to to the correct type and convert ++ at var{size} into bytes for you and then a call the special wide version of the ++function that will make sure the encoding is correct for the type ++passed in. For compatibility with older versions of Aspell the normal ++non-wide functions can still be used provided that the size of the ++string, in bytes, is also passed in. Null terminated @code{ucs-2} or ++ at code{ucs-4} are no longer supported when using the non-wide functions. + + If the word is not correct, then the @code{suggest} method can be used + to come up with likely replacements. +@@ -2236,7 +2245,28 @@ delete_aspell_string_enumeration(elements); + + Notice how @code{elements} is deleted but @code{suggestions} is not. + The value returned by @code{suggestions} is only valid to the next +-call to @code{suggest}. Once a replacement is made the ++call to @code{suggest}. ++ ++If you are using the @code{ucs-2} or @code{ucs-4} encoding then, in ++addition to using the @code{_w} macro for the @code{suggest} method, you ++should also use the @code{_w} macro with the @code{next} method which ++will cast the string to the correct type for you. For example, if you ++are using the @code{ucs-2} encoding and the string is a @code{const ++uint16_t *} then you should use: ++ ++ at smallexample ++AspellWordList * suggestions = aspell_speller_suggest_w(spell_checker, ++ @var{word}, @var{size}); ++AspellStringEnumeration * elements = aspell_word_list_elements(suggestions); ++const uint16_t * word; ++while ( (word = aspell_string_enumeration_next_w(uint16_t, aspell_elements)) != NULL ) ++@{ ++ // add to suggestion list ++@} ++delete_aspell_string_enumeration(elements); ++ at end smallexample ++ ++Once a replacement is made the + @code{store_repl} method should be used to communicate the replacement + pair back to the spell checker (for the reason, @pxref{Notes on + Storing Replacement Pairs}). Its usage is as follows: +diff --git a/manual/readme.texi b/manual/readme.texi +index 669ab8e..531721f 100644 +--- a/manual/readme.texi ++++ b/manual/readme.texi +@@ -15,15 +15,16 @@ The latest version can always be found at GNU Aspell's home page at + @uref{http://aspell.net}. + + @menu +-* Generic Install Instructions:: +-* HTML Manuals and "make clean":: +-* Curses Notes:: +-* Loadable Filter Notes:: +-* Using 32-Bit Dictionaries on a 64-Bit System:: +-* Upgrading from Aspell 0.50:: +-* Upgrading from Aspell .33/Pspell .12:: +-* Upgrading from a Pre-0.50 snapshot:: +-* WIN32 Notes:: ++* Generic Install Instructions:: ++* HTML Manuals and "make clean":: ++* Curses Notes:: ++* Upgrading from Aspell 0.60.7:: ++* Loadable Filter Notes:: ++* Using 32-Bit Dictionaries on a 64-Bit System:: ++* Upgrading from Aspell 0.50:: ++* Upgrading from Aspell .33/Pspell .12:: ++* Upgrading from a Pre-0.50 snapshot:: ++* WIN32 Notes:: + @end menu + + @node Generic Install Instructions +@@ -121,17 +122,62 @@ In addition your system must also support the @code{mblen} function. + Although this function was defined in the ISO C89 standard (ANSI + X3.159-1989), not all systems have it. + ++ at node Upgrading from Aspell 0.60.7 ++ at appendixsec Upgrading from Aspell 0.60.7 ++ ++To prevent a potentially unbounded buffer over-read, Aspell no longer ++supports null-terminated UCS-2 and UCS-4 encoded strings with the ++original C API. Null-termianted 8-bit or UTF-8 encoded strings are ++still supported, as are UCS-2 and UCS-4 encoded strings when the ++length is passed in. ++ ++As of Aspell 0.60.8 a function from the original API that expects an ++encoded string as a parameter will return meaningless results (or an ++error code) if string is null terminated and the encoding is set to ++ at code{ucs-2} or @code{ucs-4}. In addition, a single: ++ at example ++ERROR: aspell_speller_check: Null-terminated wide-character strings unsupported when used this way. ++ at end example ++will be printed to standard error the first time one of those ++functions is called. ++ ++Application that use null-terminated UCS-2/4 strings should either (1) ++use the interface intended for working with wide-characters ++(@xref{Through the C API}); or (2) define ++ at code{ASPELL_ENCODE_SETTING_SECURE} before including @code{aspell.h}. ++In the latter case is is important that the application explicitly ++sets the encoding to a known value. Defining ++ at code{ASPELL_ENCODE_SETTING_SECURE} and not setting the encoding ++explicitly or allowing user of the application to set the encoding ++could result in an unbounded buffer over-read. ++ ++If it is necessary to preserve binary compatibility with older ++versions of Aspell, the easiest thing would be to determine the length ++of the UCS-2/4 string---in bytes---and pass that in. Due to an ++implemenation detail, existing API functions can be made to work with ++null-terminated UCS-2/4 strings safely by passing in either @code{-2} ++or @code{-4} (corresponding to the width of the character type) as the ++size. Doing so, however, will cause a buffer over-read for unpatched ++version of Aspell. To avoid this it will be necessary to parse the ++version string to determine the correct value to use. However, no ++official support will be provided for the latter method. ++ ++If the application can not be recompiled, then Aspell can be configured ++to preserve the old behavior by passing ++ at option{--enable-sloppy-null-term-strings} to @command{configure}. When Aspell ++is compiled this way the version string will include the string ++ at samp{ SLOPPY}. ++ + @node Loadable Filter Notes + @appendixsec Loadable Filter Notes +- ++ + Support for being able to load additional filter modules at run-time + has only been verified to work on Linux platforms. If you get linker + errors when trying to use a filter, then it is likely that loadable + filter support is not working yet on your platform. Thus, in order to + get Aspell to work correctly you will need to avoid compiling the + filters as individual modules by using the +- at option{--enable-compile-in-filters} when configuring Aspell with +- at command{./configure}. ++ at option{--enable-compile-in-filters} @command{configure} option. + + @node Using 32-Bit Dictionaries on a 64-Bit System + @appendixsec Using 32-Bit Dictionaries on a 64-Bit System +-- +2.17.1 + diff --git a/meta/recipes-support/aspell/aspell/CVE-2019-20433-0002.patch b/meta/recipes-support/aspell/aspell/CVE-2019-20433-0002.patch new file mode 100644 index 0000000000..9569ddeebe --- /dev/null +++ b/meta/recipes-support/aspell/aspell/CVE-2019-20433-0002.patch @@ -0,0 +1,68 @@ +From cefd447e5528b08bb0cd6656bc52b4255692cefc Mon Sep 17 00:00:00 2001 +From: Kevin Atkinson +Date: Sat, 17 Aug 2019 20:25:21 -0400 +Subject: [PATCH 2/2] Increment library version to reflect API changes. + +CVE: CVE-2019-20433 +Upstream-Status: Backport [https://github.com/GNUAspell/aspell/commit/cefd447e5528b08bb0cd6656bc52b4255692cefc] + +Signed-off-by: Stefan Ghinea +--- + Makefile.am | 31 +++++++++++++++++-------------- + 1 file changed, 17 insertions(+), 14 deletions(-) + +diff --git a/Makefile.am b/Makefile.am +index 7e15851..19dc044 100644 +--- a/Makefile.am ++++ b/Makefile.am +@@ -94,18 +94,25 @@ libaspell_la_SOURCES =\ + + libaspell_la_LIBADD = $(LTLIBINTL) $(PTHREAD_LIB) + +-## Libtool to so name +-## C:R:A => (C-A).(A).(R) +-## 16:5:0 => 16.0.5 +-## 16:5:1 => 15.1.5 +-## 18:0:2 => 16.2.0 +-## 17:0:2 => 15.2.0 +- ++## The version string is current[:revision[:age]] ++## ++## Before a release that has changed the source code at all ++## increment revision. ++## ++## After merging changes that have changed the API in a backwards ++## comptable way set revision to 0 and bump both current and age. ++## ++## Do not change the API in a backwards incompatible way. ++## ++## See "Libtool: Updating version info" ++## (https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html) ++## for more into ++## + if INCREMENTED_SONAME +-libaspell_la_LDFLAGS = -version-info 18:0:2 -no-undefined ++libaspell_la_LDFLAGS = -version-info 19:0:3 -no-undefined + else + ## Use C-1:R:A +-libaspell_la_LDFLAGS = -version-info 17:0:2 -no-undefined ++libaspell_la_LDFLAGS = -version-info 18:0:3 -no-undefined + endif + + if PSPELL_COMPATIBILITY +@@ -113,11 +120,7 @@ libpspell_la_SOURCES = lib/dummy.cpp + + libpspell_la_LIBADD = libaspell.la + +-if INCREMENTED_SONAME +-libpspell_la_LDFLAGS = -version-info 18:0:2 -no-undefined +-else +-libpspell_la_LDFLAGS = -version-info 17:0:2 -no-undefined +-endif ++libpspell_la_LDFLAGS = $(libaspell_la_LDFLAGS) + + endif + +-- +2.17.1 + diff --git a/meta/recipes-support/aspell/aspell_0.60.7.bb b/meta/recipes-support/aspell/aspell_0.60.7.bb index b565cb3c6e..1e104c263c 100644 --- a/meta/recipes-support/aspell/aspell_0.60.7.bb +++ b/meta/recipes-support/aspell/aspell_0.60.7.bb @@ -8,6 +8,8 @@ PR = "r1" SRC_URI = "${GNU_MIRROR}/aspell/aspell-${PV}.tar.gz \ file://0001-Fix-various-bugs-found-by-OSS-Fuze.patch \ + file://CVE-2019-20433-0001.patch \ + file://CVE-2019-20433-0002.patch \ " SRC_URI[md5sum] = "8ef2252609c511cd2bb26f3a3932ef28" SRC_URI[sha256sum] = "5ca8fc8cb0370cc6c9eb5b64c6d1bc5d57b3750dbf17887726c3407d833b70e4" -- 2.17.1 From anuj.mittal at intel.com Thu Mar 12 12:25:21 2020 From: anuj.mittal at intel.com (Mittal, Anuj) Date: Thu, 12 Mar 2020 12:25:21 +0000 Subject: [OE-core] [PATCH] [zeus] aspell: CVE-2019-20433 In-Reply-To: <20200312092322.28506-1-stefan.ghinea@windriver.com> References: <20200312092322.28506-1-stefan.ghinea@windriver.com> Message-ID: <67257554ffe08ac11b8f1cf3da115ba5a7e35fbd.camel@intel.com> It looks like this is changing the API. I wonder if this would need any other change or break something elsewhere in OE-core, meta-oe? http://aspell.net/buffer-overread-ucs.txt Thanks, Anuj On Thu, 2020-03-12 at 11:23 +0200, Stefan Ghinea wrote: > libaspell.a in GNU Aspell before 0.60.8 has a buffer over-read for a > string > ending with a single '\0' byte, if the encoding is set to ucs-2 or > ucs-4 > outside of the application, as demonstrated by the ASPELL_CONF > environment > variable. > > References: > https://nvd.nist.gov/vuln/detail/CVE-2019-20433 > > Upstream patches: > https://github.com/GNUAspell/aspell/commit/de29341638833ba7717bd6b5e6850998454b044b > https://github.com/GNUAspell/aspell/commit/cefd447e5528b08bb0cd6656bc52b4255692cefc > > Signed-off-by: Stefan Ghinea > --- > .../aspell/aspell/CVE-2019-20433-0001.patch | 999 > ++++++++++++++++++ > .../aspell/aspell/CVE-2019-20433-0002.patch | 68 ++ > meta/recipes-support/aspell/aspell_0.60.7.bb | 2 + > 3 files changed, 1069 insertions(+) > create mode 100644 meta/recipes-support/aspell/aspell/CVE-2019- > 20433-0001.patch > create mode 100644 meta/recipes-support/aspell/aspell/CVE-2019- > 20433-0002.patch > > diff --git a/meta/recipes-support/aspell/aspell/CVE-2019-20433- > 0001.patch b/meta/recipes-support/aspell/aspell/CVE-2019-20433- > 0001.patch > new file mode 100644 > index 0000000000..fd68461e32 > --- /dev/null > +++ b/meta/recipes-support/aspell/aspell/CVE-2019-20433-0001.patch > @@ -0,0 +1,999 @@ > +From de29341638833ba7717bd6b5e6850998454b044b Mon Sep 17 00:00:00 > 2001 > +From: Kevin Atkinson > +Date: Sat, 17 Aug 2019 17:06:53 -0400 > +Subject: [PATCH 1/2] Don't allow null-terminated UCS-2/4 strings > using the > + original API. > + > +Detect if the encoding is UCS-2/4 and the length is -1 in affected > API > +functions and refuse to convert the string. If the string ends up > +being converted somehow, abort with an error message in DecodeDirect > +and ConvDirect. To convert a null terminated string in > +Decode/ConvDirect, a negative number corresponding to the width of > the > +underlying character type for the encoding is expected; for example, > +if the encoding is "ucs-2" then a the size is expected to be -2. > + > +Also fix a 1-3 byte over-read in DecodeDirect when reading UCS-2/4 > +strings when a size is provided (found by OSS-Fuzz). > + > +Also fix a bug in DecodeDirect that caused DocumentChecker to return > +the wrong offsets when working with UCS-2/4 strings. > + > +CVE: CVE-2019-20433 > +Upstream-Status: Backport [ > https://github.com/GNUAspell/aspell/commit/de29341638833ba7717bd6b5e6850998454b044b > ] > + > +[SG: - adjusted context > + - discarded test changes as test framework is not available > + - discarded manual entry changes for features that aren't > backported] > +Signed-off-by: Stefan Ghinea > +--- > + auto/MkSrc/CcHelper.pm | 99 > ++++++++++++++++++++++++++++++++++--- > + auto/MkSrc/Create.pm | 5 +- > + auto/MkSrc/Info.pm | 5 +- > + auto/MkSrc/ProcCc.pm | 24 +++++---- > + auto/MkSrc/ProcImpl.pm | 57 +++++++++++++++------ > + auto/MkSrc/Read.pm | 4 +- > + auto/mk-src.in | 44 +++++++++++++++-- > + common/convert.cpp | 39 ++++++++++++--- > + common/convert.hpp | 38 +++++++++++++- > + common/document_checker.cpp | 17 ++++++- > + common/document_checker.hpp | 1 + > + common/version.cpp | 15 ++++-- > + configure.ac | 8 +++ > + manual/aspell.texi | 58 ++++++++++++++++------ > + manual/readme.texi | 70 +++++++++++++++++++++----- > + 15 files changed, 409 insertions(+), 75 deletions(-) > + > +diff --git a/auto/MkSrc/CcHelper.pm b/auto/MkSrc/CcHelper.pm > +index f2de991..0044335 100644 > +--- a/auto/MkSrc/CcHelper.pm > ++++ b/auto/MkSrc/CcHelper.pm > +@@ -10,8 +10,8 @@ BEGIN { > + use Exporter; > + our @ISA = qw(Exporter); > + our @EXPORT = qw(to_c_return_type c_error_cond > +- to_type_name make_desc make_func call_func > +- make_c_method call_c_method form_c_method > ++ to_type_name make_desc make_func call_func > get_c_func_name > ++ make_c_method make_wide_macro call_c_method > form_c_method > + make_cxx_method); > + } > + > +@@ -90,6 +90,69 @@ sub make_func ( $ \@ $ ; \% ) { > + ')')); > + } > + > ++=item make_wide_version NAME @TYPES PARMS ; %ACCUM > ++ > ++Creates the wide character version of the function if needed > ++ > ++=cut > ++ > ++sub make_wide_version ( $ \@ $ ; \% ) { > ++ my ($name, $d, $p, $accum) = @_; > ++ my @d = @$d; > ++ shift @d; > ++ return '' unless grep {$_->{type} eq 'encoded string'} @d; > ++ $accum->{sys_headers}{'stddef.h'} = true; > ++ $accum->{suffix}[5] = <<'---'; > ++ > ++/******************* private implemantion details > *********************/ > ++ > ++#ifdef __cplusplus > ++# define aspell_cast_(type, expr) (static_cast(expr)) > ++# define aspell_cast_from_wide_(str) (static_cast *>(str)) > ++#else > ++# define aspell_cast_(type, expr) ((type)(expr)) > ++# define aspell_cast_from_wide_(str) ((const char *)(str)) > ++#endif > ++--- > ++ my @parms = map {$_->{type} eq 'encoded string' > ++ ? ($_->{name}, $_->{name}.'_size') > ++ : $_->{name}} @d; > ++ $name = to_lower $name; > ++ $accum->{suffix}[0] = <<'---'; > ++/****************************************************************** > ****/ > ++ > ++#ifdef ASPELL_ENCODE_SETTING_SECURE > ++--- > ++ $accum->{suffix}[2] = "#endif\n"; > ++ my @args = map {$_->{type} eq 'encoded string' > ++ ? ($_->{name}, "$_->{name}_size", '-1') > ++ : $_->{name}} @d; > ++ $accum->{suffix}[1] .= > ++ (join '', > ++ "#define $name", > ++ '(', join(', ', @parms), ')', > ++ "\\\n ", > ++ $name, '_wide', > ++ '(', join(', ', @args), ')', > ++ "\n"); > ++ @args = map {$_->{type} eq 'encoded string' > ++ ? ("aspell_cast_from_wide_($_->{name})", > ++ "$_- > >{name}_size*aspell_cast_(int,sizeof(*($_->{name})))", > ++ "sizeof(*($_->{name}))") > ++ : $_->{name}} @d; > ++ return (join '', > ++ "\n", > ++ "/* version of $name that is safe to use with (null > terminated) wide characters */\n", > ++ '#define ', > ++ $name, '_w', > ++ '(', join(', ', @parms), ')', > ++ "\\\n ", > ++ $name, '_wide', > ++ '(', join(', ', @args), ')', > ++ "\n"); > ++} > ++ > ++ > + =item call_func NAME @TYPES PARMS ; %ACCUM > + > + Return a string to call a func. Will prefix the function with > return > +@@ -103,7 +166,6 @@ Parms can be any of: > + > + sub call_func ( $ \@ $ ; \% ) { > + my ($name, $d, $p, $accum) = @_; > +- $accum = {} unless defined $accum; > + my @d = @$d; > + my $func_ret = to_type_name(shift @d, {%$p,pos=>'return'}, > %$accum); > + return (join '', > +@@ -148,8 +210,14 @@ sub to_type_name ( $ $ ; \% ) { > + my $name = $t->{name}; > + my $type = $t->{type}; > + > +- return ( (to_type_name {%$d, type=>'string'}, $p, %$accum) , > +- (to_type_name {%$d, type=>'int', name=>"$d->{name}_size"}, > $p, %$accum) ) > ++ if ($name eq 'encoded string' && $is_cc && $pos eq 'parm') { > ++ my @types = ((to_type_name {%$d, type=>($p->{wide}?'const void > pointer':'string')}, $p, %$accum), > ++ (to_type_name {%$d, type=>'int', name=>"$d- > >{name}_size"}, $p, %$accum)); > ++ push @types, (to_type_name {%$d, type=>'int', name=>"$d- > >{name}_type_width"}, $p, %$accum) if $p->{wide}; > ++ return @types; > ++ } > ++ return ( (to_type_name {%$d, type=>($p->{wide}?'const void > pointer':'string')}, $p, %$accum) , > ++ (to_type_name {%$d, type=>'int', name=>"$d- > >{name}_size"}, $p, %$accum) ) > + if $name eq 'encoded string' && $is_cc && $pos eq 'parm'; > + > + my $str; > +@@ -174,7 +242,7 @@ sub to_type_name ( $ $ ; \% ) { > + $str .= "String"; > + } > + } elsif ($name eq 'encoded string') { > +- $str .= "const char *"; > ++ $str .= $p->{wide} ? "const void *" : "const char *"; > + } elsif ($name eq '') { > + $str .= "void"; > + } elsif ($name eq 'bool' && $is_cc) { > +@@ -186,7 +254,7 @@ sub to_type_name ( $ $ ; \% ) { > + if ($t->{pointer}) { > + $accum->{types}->{$name} = $t; > + } else { > +- $accum->{headers}->{$t->{created_in}} = true; > ++ $accum->{headers}->{$t->{created_in}} = true unless $mode > eq 'cc'; > + } > + $str .= "$c_type Aspell" if $mode eq 'cc'; > + $str .= to_mixed($name); > +@@ -214,6 +282,7 @@ sub to_type_name ( $ $ ; \% ) { > + return $str; > + } > + > ++ > + =item make_desc DESC ; LEVEL > + > + Make a C comment out of DESC optionally indenting it LEVEL spaces. > +@@ -286,6 +355,7 @@ sub form_c_method ($ $ $ ; \% ) > + } else { > + $func = "aspell $class $name"; > + } > ++ $func .= " wide" if $p->{wide}; > + if (exists $d->{'const'}) { > + splice @data, 1, 0, {type => "const $class", name=> > $this_name}; > + } else { > +@@ -306,6 +376,21 @@ sub make_c_method ($ $ $ ; \%) > + return &make_func(@ret); > + } > + > ++sub get_c_func_name ($ $ $) > ++{ > ++ my @ret = &form_c_method(@_); > ++ return undef unless @ret > 0; > ++ return to_lower $ret[0]; > ++} > ++ > ++sub make_wide_macro ($ $ $ ; \%) > ++{ > ++ my @ret = &form_c_method(@_); > ++ return undef unless @ret > 0; > ++ my $str = &make_wide_version(@ret); > ++ return $str; > ++} > ++ > + sub call_c_method ($ $ $ ; \%) > + { > + my @ret = &form_c_method(@_); > +diff --git a/auto/MkSrc/Create.pm b/auto/MkSrc/Create.pm > +index d39b60e..630ede5 100644 > +--- a/auto/MkSrc/Create.pm > ++++ b/auto/MkSrc/Create.pm > +@@ -77,8 +77,10 @@ sub create_cc_file ( % ) { > + $file .= "#include \"aspell.h\"\n" if $p{type} eq 'cxx'; > + $file .= "#include \"settings.h\"\n" if $p{type} eq 'native_impl' > && $p{name} eq 'errors'; > + $file .= "#include \"gettext.h\"\n" if $p{type} eq 'native_impl' > && $p{name} eq 'errors'; > ++ $file .= cmap {"#include <$_>\n"} sort keys > %{$accum{sys_headers}}; > + $file .= cmap {"#include \"".to_lower($_).".hpp\"\n"} sort keys > %{$accum{headers}}; > +- $file .= "#ifdef __cplusplus\nextern \"C\" {\n#endif\n" if > $p{header} && !$p{cxx}; > ++ $file .= "\n#ifdef __cplusplus\nextern \"C\" {\n#endif\n" if > $p{header} && !$p{cxx}; > ++ $file .= join('', grep {defined $_} @{$accum{prefix}}); > + $file .= "\nnamespace $p{namespace} {\n\n" if $p{cxx}; > + if (defined $info{forward}{proc}{$p{type}}) { > + my @types = sort {$a->{name} cmp $b->{name}} (values > %{$accum{types}}); > +@@ -86,6 +88,7 @@ sub create_cc_file ( % ) { > + } > + $file .= "\n"; > + $file .= $body; > ++ $file .= join('', grep {defined $_} @{$accum{suffix}}); > + $file .= "\n\n}\n\n" if $p{cxx}; > + $file .= "#ifdef __cplusplus\n}\n#endif\n" if $p{header} && > !$p{cxx}; > + $file .= "#endif /* $hm */\n" if $p{header}; > +diff --git a/auto/MkSrc/Info.pm b/auto/MkSrc/Info.pm > +index c644028..ace8e21 100644 > +--- a/auto/MkSrc/Info.pm > ++++ b/auto/MkSrc/Info.pm > +@@ -60,6 +60,7 @@ each proc sub should take the following argv > + the object from which it is a member of > + no native: do not attempt to create a native implementation > + treat as object: treat as a object rather than a pointer > ++ no conv: do not converted an encoded string > + > + The %info structure is initialized as follows: > + > +@@ -104,8 +105,8 @@ The %info structure is initialized as follows: > + errors => {}, # possible errors > + method => { > + # A class method > +- options => ['desc', 'posib err', 'c func', 'const', > +- 'c only', 'c impl', 'cxx impl'], > ++ options => ['desc', 'posib err', 'c func', 'const', 'no conv', > 'on conv error', > ++ 'c only', 'c impl', 'cxx impl', 'cc extra'], > + groups => undef}, > + constructor => { > + # A class constructor > +diff --git a/auto/MkSrc/ProcCc.pm b/auto/MkSrc/ProcCc.pm > +index 47c4338..98cc435 100644 > +--- a/auto/MkSrc/ProcCc.pm > ++++ b/auto/MkSrc/ProcCc.pm > +@@ -23,7 +23,7 @@ use MkSrc::Info; > + sub make_c_object ( $ @ ); > + > + $info{group}{proc}{cc} = sub { > +- my ($data) = @_; > ++ my ($data, at rest) = @_; > + my $ret; > + my $stars = (70 - length $data->{name})/2; > + $ret .= "/"; > +@@ -33,14 +33,14 @@ $info{group}{proc}{cc} = sub { > + $ret .= "/\n"; > + foreach my $d (@{$data->{data}}) { > + $ret .= "\n\n"; > +- $ret .= $info{$d->{type}}{proc}{cc}->($d); > ++ $ret .= $info{$d->{type}}{proc}{cc}->($d, at rest); > + } > + $ret .= "\n\n"; > + return $ret; > + }; > + > + $info{enum}{proc}{cc} = sub { > +- my ($d) = @_; > ++ my ($d, at rest) = @_; > + my $n = "Aspell".to_mixed($d->{name}); > + return ("\n". > + make_desc($d->{desc}). > +@@ -58,21 +58,26 @@ $info{struct}{proc}{cc} = sub { > + }; > + > + $info{union}{proc}{cc} = sub { > +- return make_c_object "union", $_[0]; > ++ return make_c_object "union", @_; > + }; > + > + $info{class}{proc}{cc} = sub { > +- my ($d) = @_; > ++ my ($d,$accum) = @_; > + my $class = $d->{name}; > + my $classname = "Aspell".to_mixed($class); > + my $ret = ""; > + $ret .= "typedef struct $classname $classname;\n\n"; > + foreach (@{$d->{data}}) { > +- my $s = make_c_method($class, $_, {mode=>'cc'}); > ++ my $s = make_c_method($class, $_, {mode=>'cc'}, %$accum); > + next unless defined $s; > + $ret .= "\n"; > + $ret .= make_desc($_->{desc}); > +- $ret .= make_c_method($class, $_, {mode=>'cc'}).";\n"; > ++ $ret .= make_c_method($class, $_, {mode=>'cc'}, %$accum).";\n"; > ++ if (grep {$_->{type} eq 'encoded string'} @{$_->{data}}) { > ++ $ret .= make_c_method($class, $_, {mode=>'cc', wide=>true}, > %$accum).";\n"; > ++ $ret .= make_wide_macro($class, $_, {mode=>'cc'}, %$accum); > ++ } > ++ $ret .= "\n".$_->{'cc extra'}."\n" if defined $_->{'cc extra'}; > + } > + $ret .= "\n"; > + return $ret; > +@@ -105,7 +110,8 @@ $info{errors}{proc}{cc} = sub { > + }; > + > + sub make_c_object ( $ @ ) { > +- my ($t, $d) = @_; > ++ my ($t, $d, $accum) = @_; > ++ $accum = {} unless defined $accum; > + my $struct; > + $struct .= "Aspell"; > + $struct .= to_mixed($d->{name}); > +@@ -120,7 +126,7 @@ sub make_c_object ( $ @ ) { > + "\n};\n"), > + "typedef $t $struct $struct;", > + join ("\n", > +- map {make_c_method($d->{name}, $_, {mode=>'cc'}).";"} > ++ map {make_c_method($d->{name}, $_, {mode=>'cc'}, > %$accum).";"} > + grep {$_->{type} eq 'method'} > + @{$d->{data}}) > + )."\n"; > +diff --git a/auto/MkSrc/ProcImpl.pm b/auto/MkSrc/ProcImpl.pm > +index b8628fd..3d0f220 100644 > +--- a/auto/MkSrc/ProcImpl.pm > ++++ b/auto/MkSrc/ProcImpl.pm > +@@ -45,10 +45,13 @@ $info{class}{proc}{impl} = sub { > + foreach (grep {$_ ne ''} split /\s*,\s*/, $data->{'c impl > headers'}) { > + $accum->{headers}{$_} = true; > + } > +- foreach my $d (@{$data->{data}}) { > ++ my @d = @{$data->{data}}; > ++ while (@d) { > ++ my $d = shift @d; > ++ my $need_wide = false; > + next unless one_of $d->{type}, qw(method constructor > destructor); > + my @parms = @{$d->{data}} if exists $d->{data}; > +- my $m = make_c_method $data->{name}, $d, {mode=>'cc_cxx', > use_name=>true}, %$accum; > ++ my $m = make_c_method $data->{name}, $d, {mode=>'cc_cxx', > use_name=>true, wide=>$d->{wide}}, %$accum; > + next unless defined $m; > + $ret .= "extern \"C\" $m\n"; > + $ret .= "{\n"; > +@@ -57,24 +60,49 @@ $info{class}{proc}{impl} = sub { > + } else { > + if ($d->{type} eq 'method') { > + my $ret_type = shift @parms; > +- my $ret_native = to_type_name $ret_type, > {mode=>'native_no_err', pos=>'return'}, %$accum; > ++ my $ret_native = to_type_name $ret_type, > {mode=>'native_no_err', pos=>'return', wide=>$d->{wide}}, %$accum; > + my $snum = 0; > ++ my $call_fun = $d->{name}; > ++ my @call_parms; > + foreach (@parms) { > + my $n = to_lower($_->{name}); > +- if ($_->{type} eq 'encoded string') { > +- $accum->{headers}{'mutable string'} = true; > +- $accum->{headers}{'convert'} = true; > +- $ret .= " ths->temp_str_$snum.clear();\n"; > +- $ret .= " ths->to_internal_->convert($n, ${n}_size, ths- > >temp_str_$snum);\n"; > +- $ret .= " unsigned int s$snum = ths- > >temp_str_$snum.size();\n"; > +- $_ = "MutableString(ths->temp_str_$snum.mstr(), s$snum)"; > +- $snum++; > ++ if ($_->{type} eq 'encoded string' && !exists($d->{'no > conv'})) { > ++ $need_wide = true unless $d->{wide}; > ++ die unless exists $d->{'posib err'}; > ++ $accum->{headers}{'mutable string'} = true; > ++ $accum->{headers}{'convert'} = true; > ++ my $name = get_c_func_name $data->{name}, $d, > {mode=>'cc_cxx', use_name=>true, wide=>$d->{wide}}; > ++ $ret .= " ths->temp_str_$snum.clear();\n"; > ++ if ($d->{wide}) { > ++ $ret .= " ${n}_size = get_correct_size(\"$name\", > ths->to_internal_->in_type_width(), ${n}_size, ${n}_type_width);\n"; > ++ } else { > ++ $ret .= " PosibErr ${n}_fixed_size = > get_correct_size(\"$name\", ths->to_internal_->in_type_width(), > ${n}_size);\n"; > ++ if (exists($d->{'on conv error'})) { > ++ $ret .= " if (${n}_fixed_size.get_err()) {\n"; > ++ $ret .= " ".$d->{'on conv error'}."\n"; > ++ $ret .= " } else {\n"; > ++ $ret .= " ${n}_size = ${n}_fixed_size;\n"; > ++ $ret .= " }\n"; > ++ } else { > ++ $ret .= " ths- > >err_.reset(${n}_fixed_size.release_err());\n"; > ++ $ret .= " if (ths->err_ != 0) return > ".(c_error_cond $ret_type).";\n"; > ++ } > ++ } > ++ $ret .= " ths->to_internal_->convert($n, ${n}_size, > ths->temp_str_$snum);\n"; > ++ $ret .= " unsigned int s$snum = ths- > >temp_str_$snum.size();\n"; > ++ push @call_parms, "MutableString(ths- > >temp_str_$snum.mstr(), s$snum)"; > ++ $snum++; > ++ } elsif ($_->{type} eq 'encoded string') { > ++ $need_wide = true unless $d->{wide}; > ++ push @call_parms, $n, "${n}_size"; > ++ push @call_parms, "${n}_type_width" if $d->{wide}; > ++ $call_fun .= " wide" if $d->{wide}; > + } else { > +- $_ = $n; > ++ push @call_parms, $n; > + } > + } > +- my $parms = '('.(join ', ', @parms).')'; > +- my $exp = "ths->".to_lower($d->{name})."$parms"; > ++ my $parms = '('.(join ', ', @call_parms).')'; > ++ my $exp = "ths->".to_lower($call_fun)."$parms"; > + if (exists $d->{'posib err'}) { > + $accum->{headers}{'posib err'} = true; > + $ret .= " PosibErr<$ret_native> ret = $exp;\n"; > +@@ -118,6 +146,7 @@ $info{class}{proc}{impl} = sub { > + } > + } > + $ret .= "}\n\n"; > ++ unshift @d,{%$d, wide=>true} if $need_wide; > + } > + return $ret; > + }; > +diff --git a/auto/MkSrc/Read.pm b/auto/MkSrc/Read.pm > +index 4b3d1d0..4bf640e 100644 > +--- a/auto/MkSrc/Read.pm > ++++ b/auto/MkSrc/Read.pm > +@@ -88,13 +88,13 @@ sub advance ( ) { > + $in_pod = $1 if $line =~ /^\=(\w+)/; > + $line = '' if $in_pod; > + $in_pod = undef if $in_pod && $in_pod eq 'cut'; > +- $line =~ s/\#.*$//; > ++ $line =~ s/(? + $line =~ s/^(\t*)//; > + $level = $base_level + length($1); > + $line =~ s/\s*$//; > + ++$base_level if $line =~ s/^\{$//; > + --$base_level if $line =~ s/^\}$//; > +- $line =~ s/\\([{}])/$1/g; > ++ $line =~ s/\\([{}#\\])/$1/g; > + } while ($line eq ''); > + #print "$level:$line\n"; > + } > +diff --git a/auto/mk-src.in b/auto/mk-src.in > +index 0e7833a..eb3353f 100644 > +--- a/auto/mk-src.in > ++++ b/auto/mk-src.in > +@@ -608,6 +608,7 @@ errors: > + invalid expression > + mesg => "%expression" is not a valid regular > expression. > + parms => expression > ++ > + } > + group: speller > + { > +@@ -650,6 +651,7 @@ class: speller > + posib err > + desc => Returns 0 if it is not in the dictionary, > + 1 if it is, or -1 on error. > ++ on conv error => return 0; > + / > + bool > + encoded string: word > +@@ -715,6 +717,8 @@ class: speller > + desc => Return NULL on error. > + The word list returned by suggest is only > + valid until the next call to suggest. > ++ on conv error => > ++ word = NULL; word_size = 0; > + / > + const word list > + encoded string: word > +@@ -840,7 +844,6 @@ class: document checker > + void > + > + method: process > +- > + desc => Process a string. > + The string passed in should only be split on > + white space characters. Furthermore, between > +@@ -849,10 +852,10 @@ class: document checker > + in the document. Passing in strings out of > + order, skipping strings or passing them in > + more than once may lead to undefined results. > ++ no conv > + / > + void > +- string: str > +- int: size > ++ encoded string: str > + > + method: next misspelling > + > +@@ -860,9 +863,23 @@ class: document checker > + processed string. If there are no more > + misspelled words, then token.word will be > + NULL and token.size will be 0 > ++ cc extra => > ++ \#define > aspell_document_checker_next_misspelling_w(type, ths) \\ > ++ aspell_document_checker_next_misspelling_ad > j(ths, sizeof(type)) > + / > + token object > + > ++ method: next misspelling adj > ++ desc => internal: do not use > ++ c impl => > ++ Token res = ths->next_misspelling(); > ++ res.offset /= type_width; > ++ res.len /= type_width; > ++ return res; > ++ / > ++ token object > ++ int: type_width > ++ > + method: filter > + > + desc => Returns the underlying filter class. > +@@ -922,9 +939,30 @@ class: string enumeration > + ths->from_internal_->append_null(ths- > >temp_str); > + return ths->temp_str.data(); > + \} > ++ cc extra => > ++ \#define aspell_string_enumeration_next_w(type, > ths) \\ > ++ aspell_cast_(const type *, > aspell_string_enumeration_next_wide(ths, sizeof(type))) > + / > + const string > + > ++ method: next wide > ++ c impl => > ++ const char * s = ths->next(); > ++ if (s == 0) { > ++ return s; > ++ } else if (ths->from_internal_ == 0) \{ > ++ assert(type_width == 1); > ++ return s; > ++ \} else \{ > ++ assert(type_width == ths->from_internal_- > >out_type_width()); > ++ ths->temp_str.clear(); > ++ ths->from_internal_->convert(s,-1,ths- > >temp_str); > ++ ths->from_internal_->append_null(ths- > >temp_str); > ++ return ths->temp_str.data(); > ++ \} > ++ / > ++ const void pointer > ++ int: type_width > + } > + group: info > + { > +diff --git a/common/convert.cpp b/common/convert.cpp > +index 1add95a..7ae0317 100644 > +--- a/common/convert.cpp > ++++ b/common/convert.cpp > +@@ -541,18 +541,25 @@ namespace acommon { > + // Trivial Conversion > + // > + > ++ const char * unsupported_null_term_wide_string_msg = > ++ "Null-terminated wide-character strings unsupported when used > this way."; > ++ > + template > + struct DecodeDirect : public Decode > + { > ++ DecodeDirect() {type_width = sizeof(Chr);} > + void decode(const char * in0, int size, FilterCharVector & out) > const { > + const Chr * in = reinterpret_cast(in0); > +- if (size == -1) { > ++ if (size == -sizeof(Chr)) { > + for (;*in; ++in) > +- out.append(*in); > ++ out.append(*in, sizeof(Chr)); > ++ } else if (size <= -1) { > ++ fprintf(stderr, "%s\n", > unsupported_null_term_wide_string_msg); > ++ abort(); > + } else { > +- const Chr * stop = reinterpret_cast(in0 > +size); > ++ const Chr * stop = reinterpret_cast(in0) + > size/sizeof(Chr); > + for (;in != stop; ++in) > +- out.append(*in); > ++ out.append(*in, sizeof(Chr)); > + } > + } > + PosibErr decode_ec(const char * in0, int size, > +@@ -565,6 +572,7 @@ namespace acommon { > + template > + struct EncodeDirect : public Encode > + { > ++ EncodeDirect() {type_width = sizeof(Chr);} > + void encode(const FilterChar * in, const FilterChar * stop, > + CharVector & out) const { > + for (; in != stop; ++in) { > +@@ -594,11 +602,15 @@ namespace acommon { > + template > + struct ConvDirect : public DirectConv > + { > ++ ConvDirect() {type_width = sizeof(Chr);} > + void convert(const char * in0, int size, CharVector & out) > const { > +- if (size == -1) { > ++ if (size == -sizeof(Chr)) { > + const Chr * in = reinterpret_cast(in0); > + for (;*in != 0; ++in) > + out.append(in, sizeof(Chr)); > ++ } else if (size <= -1) { > ++ fprintf(stderr, "%s\n", > unsupported_null_term_wide_string_msg); > ++ abort(); > + } else { > + out.append(in0, size); > + } > +@@ -1121,5 +1133,20 @@ namespace acommon { > + } > + return 0; > + } > +- > ++ > ++ PosibErr unsupported_null_term_wide_string_err_(const char > * func) { > ++ static bool reported_to_stderr = false; > ++ PosibErr err = make_err(other_error, > unsupported_null_term_wide_string_msg); > ++ if (!reported_to_stderr) { > ++ CERR.printf("ERROR: %s: %s\n", func, > unsupported_null_term_wide_string_msg); > ++ reported_to_stderr = true; > ++ } > ++ return err; > ++ } > ++ > ++ void unsupported_null_term_wide_string_abort_(const char * func) > { > ++ CERR.printf("%s: %s\n", unsupported_null_term_wide_string_msg); > ++ abort(); > ++ } > ++ > + } > +diff --git a/common/convert.hpp b/common/convert.hpp > +index 76332ee..c948973 100644 > +--- a/common/convert.hpp > ++++ b/common/convert.hpp > +@@ -7,6 +7,8 @@ > + #ifndef ASPELL_CONVERT__HPP > + #define ASPELL_CONVERT__HPP > + > ++#include "settings.h" > ++ > + #include "string.hpp" > + #include "posib_err.hpp" > + #include "char_vector.hpp" > +@@ -25,8 +27,9 @@ namespace acommon { > + typedef const Config CacheConfig; > + typedef const char * CacheKey; > + String key; > ++ int type_width; // type width in bytes > + bool cache_key_eq(const char * l) const {return key == l;} > +- ConvBase() {} > ++ ConvBase() : type_width(1) {} > + private: > + ConvBase(const ConvBase &); > + void operator=(const ConvBase &); > +@@ -56,6 +59,8 @@ namespace acommon { > + virtual ~Encode() {} > + }; > + struct DirectConv { // convert directly from in_code to out_code. > ++ int type_width; // type width in bytes > ++ DirectConv() : type_width(1) {} > + // should not take ownership of decode and encode. > + // decode and encode guaranteed to stick around for the life > + // of the object. > +@@ -126,6 +131,9 @@ namespace acommon { > + const char * in_code() const {return decode_->key.c_str();} > + const char * out_code() const {return encode_->key.c_str();} > + > ++ int in_type_width() const {return decode_->type_width;} > ++ int out_type_width() const {return encode_->type_width;} > ++ > + void append_null(CharVector & out) const > + { > + const char nul[4] = {0,0,0,0}; // 4 should be enough > +@@ -191,6 +199,10 @@ namespace acommon { > + } > + } > + > ++ void convert(const void * in, int size, CharVector & out) { > ++ convert(static_cast(in), size, out); > ++ } > ++ > + void generic_convert(const char * in, int size, CharVector & > out); > + > + }; > +@@ -412,6 +424,30 @@ namespace acommon { > + return operator()(str, str + byte_size);} > + }; > + > ++#ifdef SLOPPY_NULL_TERM_STRINGS > ++ static const bool sloppy_null_term_strings = true; > ++#else > ++ static const bool sloppy_null_term_strings = false; > ++#endif > ++ > ++ PosibErr unsupported_null_term_wide_string_err_(const char > * func); > ++ void unsupported_null_term_wide_string_abort_(const char * func); > ++ > ++ static inline PosibErr get_correct_size(const char * func, > int conv_type_width, int size) { > ++ if (sloppy_null_term_strings && size <= -1) > ++ return -conv_type_width; > ++ if (size <= -1 && -conv_type_width != size) > ++ return unsupported_null_term_wide_string_err_(func); > ++ return size; > ++ } > ++ static inline int get_correct_size(const char * func, int > conv_type_width, int size, int type_width) { > ++ if ((sloppy_null_term_strings || type_width <= -1) && size <= > -1) > ++ return -conv_type_width; > ++ if (size <= -1 && conv_type_width != type_width) > ++ unsupported_null_term_wide_string_abort_(func); > ++ return size; > ++ } > ++ > + } > + > + #endif > +diff --git a/common/document_checker.cpp > b/common/document_checker.cpp > +index 5e510c4..0ccf1cd 100644 > +--- a/common/document_checker.cpp > ++++ b/common/document_checker.cpp > +@@ -44,7 +44,9 @@ namespace acommon { > + void DocumentChecker::process(const char * str, int size) > + { > + proc_str_.clear(); > +- conv_->decode(str, size, proc_str_); > ++ PosibErr fixed_size = > get_correct_size("aspell_document_checker_process", conv_- > >in_type_width(), size); > ++ if (!fixed_size.has_err()) > ++ conv_->decode(str, fixed_size, proc_str_); > + proc_str_.append(0); > + FilterChar * begin = proc_str_.pbegin(); > + FilterChar * end = proc_str_.pend() - 1; > +@@ -53,6 +55,19 @@ namespace acommon { > + tokenizer_->reset(begin, end); > + } > + > ++ void DocumentChecker::process_wide(const void * str, int size, > int type_width) > ++ { > ++ proc_str_.clear(); > ++ int fixed_size = > get_correct_size("aspell_document_checker_process", conv_- > >in_type_width(), size, type_width); > ++ conv_->decode(static_cast(str), fixed_size, > proc_str_); > ++ proc_str_.append(0); > ++ FilterChar * begin = proc_str_.pbegin(); > ++ FilterChar * end = proc_str_.pend() - 1; > ++ if (filter_) > ++ filter_->process(begin, end); > ++ tokenizer_->reset(begin, end); > ++ } > ++ > + Token DocumentChecker::next_misspelling() > + { > + bool correct; > +diff --git a/common/document_checker.hpp > b/common/document_checker.hpp > +index d35bb88..11a3c73 100644 > +--- a/common/document_checker.hpp > ++++ b/common/document_checker.hpp > +@@ -36,6 +36,7 @@ namespace acommon { > + PosibErr setup(Tokenizer *, Speller *, Filter *); > + void reset(); > + void process(const char * str, int size); > ++ void process_wide(const void * str, int size, int type_width); > + Token next_misspelling(); > + > + Filter * filter() {return filter_;} > +diff --git a/common/version.cpp b/common/version.cpp > +index 414d938..9e60b75 100644 > +--- a/common/version.cpp > ++++ b/common/version.cpp > +@@ -1,8 +1,17 @@ > + #include "settings.h" > + > +-extern "C" const char * aspell_version_string() { > + #ifdef NDEBUG > +- return VERSION " NDEBUG"; > ++# define NDEBUG_STR " NDEBUG" > ++#else > ++# define NDEBUG_STR > ++#endif > ++ > ++#ifdef SLOPPY_NULL_TERM_STRINGS > ++# define SLOPPY_STR " SLOPPY" > ++#else > ++# define SLOPPY_STR > + #endif > +- return VERSION; > ++ > ++extern "C" const char * aspell_version_string() { > ++ return VERSION NDEBUG_STR SLOPPY_STR; > + } > +diff --git a/configure.ac b/configure.ac > +index 60e3b39..a5d51e3 100644 > +--- a/configure.ac > ++++ b/configure.ac > +@@ -73,6 +73,9 @@ AC_ARG_ENABLE(filter-version-control, > + AC_ARG_ENABLE(32-bit-hash-fun, > + AS_HELP_STRING([--enable-32-bit-hash-fun],[use 32-bit hash > function for compiled dictionaries])) > + > ++AC_ARG_ENABLE(sloppy-null-term-strings, > ++ AS_HELP_STRING([--enable-sloppy-null-term-strings],[allows allow > null terminated UCS-2 and UCS-4 strings])) > ++ > + AC_ARG_ENABLE(pspell-compatibility, > + AS_HELP_STRING([--disable-pspell-compatibility],[don't install > pspell compatibility libraries])) > + > +@@ -141,6 +144,11 @@ then > + AC_DEFINE(USE_32_BIT_HASH_FUN, 1, [Defined if 32-bit hash > function should be used for compiled dictionaries.]) > + fi > + > ++if test "$enable_sloppy_null_term_strings" = "yes" > ++then > ++ AC_DEFINE(SLOPPY_NULL_TERM_STRINGS, 1, [Defined if null- > terminated UCS-2 and UCS-4 strings should always be allowed.]) > ++fi > ++ > + AM_CONDITIONAL(PSPELL_COMPATIBILITY, > + [test "$enable_pspell_compatibility" != "no"]) > + AM_CONDITIONAL(INCREMENTED_SONAME, > +diff --git a/manual/aspell.texi b/manual/aspell.texi > +index 45fa091..f400e06 100644 > +--- a/manual/aspell.texi > ++++ b/manual/aspell.texi > +@@ -158,7 +158,8 @@ Installing > + > + * Generic Install Instructions:: > + * HTML Manuals and "make clean":: > +-* Curses Notes:: > ++* Curses Notes:: > ++* Upgrading from Aspell 0.60.7:: > + * Loadable Filter Notes:: > + * Upgrading from Aspell 0.50:: > + * Upgrading from Aspell .33/Pspell .12:: > +@@ -2206,18 +2207,26 @@ int correct = > aspell_speller_check(spell_checker, @var{word}, @var{size}); > + @end smallexample > + > + @noindent > +- at var{word} is expected to be a @code{const char *} character > +-string. If the encoding is set to be @code{ucs-2} or > +- at code{ucs-4} @var{word} is expected to be a cast > +-from either @code{const u16int *} or @code{const u32int *} > +-respectively. @code{u16int} and @code{u32int} are generally > +- at code{unsigned short} and @code{unsigned int} respectively. > +- at var{size} is the length of the string or @code{-1} if the string > +-is null terminated. If the string is a cast from @code{const > u16int > +-*} or @code{const u32int *} then @code{@i{size}} is the amount of > +-space in bytes the string takes up after being cast to @code{const > +-char *} and not the true size of the > string. @code{sspell_speller_check} > +-will return @code{0} if it is not found and non-zero otherwise. > ++ at var{word} is expected to be a @code{const char *} character > string. > ++ at var{size} is the length of the string or @code{-1} if the string > is > ++null terminated. @code{aspell_speller_check} will return @code{0} > if it is not found > ++and non-zero otherwise. > ++ > ++If you are using the @code{ucs-2} or @code{ucs-4} encoding then the > ++string is expected to be either a 2 or 4 byte wide integer > ++(respectively) and the @code{_w} macro vesion should be used: > ++ > ++ at smallexample > ++int correct = aspell_speller_check_w(spell_checker, @var{word}, > @var{size}); > ++ at end smallexample > ++ > ++The macro will cast the string to to the correct type and convert > ++ at var{size} into bytes for you and then a call the special wide > version of the > ++function that will make sure the encoding is correct for the type > ++passed in. For compatibility with older versions of Aspell the > normal > ++non-wide functions can still be used provided that the size of the > ++string, in bytes, is also passed in. Null terminated @code{ucs-2} > or > ++ at code{ucs-4} are no longer supported when using the non-wide > functions. > + > + If the word is not correct, then the @code{suggest} method can be > used > + to come up with likely replacements. > +@@ -2236,7 +2245,28 @@ delete_aspell_string_enumeration(elements); > + > + Notice how @code{elements} is deleted but @code{suggestions} is > not. > + The value returned by @code{suggestions} is only valid to the next > +-call to @code{suggest}. Once a replacement is made the > ++call to @code{suggest}. > ++ > ++If you are using the @code{ucs-2} or @code{ucs-4} encoding then, in > ++addition to using the @code{_w} macro for the @code{suggest} > method, you > ++should also use the @code{_w} macro with the @code{next} method > which > ++will cast the string to the correct type for you. For example, if > you > ++are using the @code{ucs-2} encoding and the string is a @code{const > ++uint16_t *} then you should use: > ++ > ++ at smallexample > ++AspellWordList * suggestions = > aspell_speller_suggest_w(spell_checker, > ++ @var{word}, > @var{size}); > ++AspellStringEnumeration * elements = > aspell_word_list_elements(suggestions); > ++const uint16_t * word; > ++while ( (word = aspell_string_enumeration_next_w(uint16_t, > aspell_elements)) != NULL ) > ++@{ > ++ // add to suggestion list > ++@} > ++delete_aspell_string_enumeration(elements); > ++ at end smallexample > ++ > ++Once a replacement is made the > + @code{store_repl} method should be used to communicate the > replacement > + pair back to the spell checker (for the reason, @pxref{Notes on > + Storing Replacement Pairs}). Its usage is as follows: > +diff --git a/manual/readme.texi b/manual/readme.texi > +index 669ab8e..531721f 100644 > +--- a/manual/readme.texi > ++++ b/manual/readme.texi > +@@ -15,15 +15,16 @@ The latest version can always be found at GNU > Aspell's home page at > + @uref{http://aspell.net}. > + > + @menu > +-* Generic Install Instructions:: > +-* HTML Manuals and "make clean":: > +-* Curses Notes:: > +-* Loadable Filter Notes:: > +-* Using 32-Bit Dictionaries on a 64-Bit System:: > +-* Upgrading from Aspell 0.50:: > +-* Upgrading from Aspell .33/Pspell .12:: > +-* Upgrading from a Pre-0.50 snapshot:: > +-* WIN32 Notes:: > ++* Generic Install Instructions:: > ++* HTML Manuals and "make clean":: > ++* Curses Notes:: > ++* Upgrading from Aspell 0.60.7:: > ++* Loadable Filter Notes:: > ++* Using 32-Bit Dictionaries on a 64-Bit System:: > ++* Upgrading from Aspell 0.50:: > ++* Upgrading from Aspell .33/Pspell .12:: > ++* Upgrading from a Pre-0.50 snapshot:: > ++* WIN32 Notes:: > + @end menu > + > + @node Generic Install Instructions > +@@ -121,17 +122,62 @@ In addition your system must also support the > @code{mblen} function. > + Although this function was defined in the ISO C89 standard (ANSI > + X3.159-1989), not all systems have it. > + > ++ at node Upgrading from Aspell 0.60.7 > ++ at appendixsec Upgrading from Aspell 0.60.7 > ++ > ++To prevent a potentially unbounded buffer over-read, Aspell no > longer > ++supports null-terminated UCS-2 and UCS-4 encoded strings with the > ++original C API. Null-termianted 8-bit or UTF-8 encoded strings are > ++still supported, as are UCS-2 and UCS-4 encoded strings when the > ++length is passed in. > ++ > ++As of Aspell 0.60.8 a function from the original API that expects > an > ++encoded string as a parameter will return meaningless results (or > an > ++error code) if string is null terminated and the encoding is set to > ++ at code{ucs-2} or @code{ucs-4}. In addition, a single: > ++ at example > ++ERROR: aspell_speller_check: Null-terminated wide-character strings > unsupported when used this way. > ++ at end example > ++will be printed to standard error the first time one of those > ++functions is called. > ++ > ++Application that use null-terminated UCS-2/4 strings should either > (1) > ++use the interface intended for working with wide-characters > ++(@xref{Through the C API}); or (2) define > ++ at code{ASPELL_ENCODE_SETTING_SECURE} before including > @code{aspell.h}. > ++In the latter case is is important that the application explicitly > ++sets the encoding to a known value. Defining > ++ at code{ASPELL_ENCODE_SETTING_SECURE} and not setting the encoding > ++explicitly or allowing user of the application to set the encoding > ++could result in an unbounded buffer over-read. > ++ > ++If it is necessary to preserve binary compatibility with older > ++versions of Aspell, the easiest thing would be to determine the > length > ++of the UCS-2/4 string---in bytes---and pass that in. Due to an > ++implemenation detail, existing API functions can be made to work > with > ++null-terminated UCS-2/4 strings safely by passing in either @code{- > 2} > ++or @code{-4} (corresponding to the width of the character type) as > the > ++size. Doing so, however, will cause a buffer over-read for > unpatched > ++version of Aspell. To avoid this it will be necessary to parse the > ++version string to determine the correct value to use. However, no > ++official support will be provided for the latter method. > ++ > ++If the application can not be recompiled, then Aspell can be > configured > ++to preserve the old behavior by passing > ++ at option{--enable-sloppy-null-term-strings} to > @command{configure}. When Aspell > ++is compiled this way the version string will include the string > ++ at samp{ SLOPPY}. > ++ > + @node Loadable Filter Notes > + @appendixsec Loadable Filter Notes > +- > ++ > + Support for being able to load additional filter modules at run- > time > + has only been verified to work on Linux platforms. If you get > linker > + errors when trying to use a filter, then it is likely that loadable > + filter support is not working yet on your platform. Thus, in order > to > + get Aspell to work correctly you will need to avoid compiling the > + filters as individual modules by using the > +- at option{--enable-compile-in-filters} when configuring Aspell with > +- at command{./configure}. > ++ at option{--enable-compile-in-filters} @command{configure} option. > + > + @node Using 32-Bit Dictionaries on a 64-Bit System > + @appendixsec Using 32-Bit Dictionaries on a 64-Bit System > +-- > +2.17.1 > + > diff --git a/meta/recipes-support/aspell/aspell/CVE-2019-20433- > 0002.patch b/meta/recipes-support/aspell/aspell/CVE-2019-20433- > 0002.patch > new file mode 100644 > index 0000000000..9569ddeebe > --- /dev/null > +++ b/meta/recipes-support/aspell/aspell/CVE-2019-20433-0002.patch > @@ -0,0 +1,68 @@ > +From cefd447e5528b08bb0cd6656bc52b4255692cefc Mon Sep 17 00:00:00 > 2001 > +From: Kevin Atkinson > +Date: Sat, 17 Aug 2019 20:25:21 -0400 > +Subject: [PATCH 2/2] Increment library version to reflect API > changes. > + > +CVE: CVE-2019-20433 > +Upstream-Status: Backport [ > https://github.com/GNUAspell/aspell/commit/cefd447e5528b08bb0cd6656bc52b4255692cefc > ] > + > +Signed-off-by: Stefan Ghinea > +--- > + Makefile.am | 31 +++++++++++++++++-------------- > + 1 file changed, 17 insertions(+), 14 deletions(-) > + > +diff --git a/Makefile.am b/Makefile.am > +index 7e15851..19dc044 100644 > +--- a/Makefile.am > ++++ b/Makefile.am > +@@ -94,18 +94,25 @@ libaspell_la_SOURCES =\ > + > + libaspell_la_LIBADD = $(LTLIBINTL) $(PTHREAD_LIB) > + > +-## Libtool to so name > +-## C:R:A => (C-A).(A).(R) > +-## 16:5:0 => 16.0.5 > +-## 16:5:1 => 15.1.5 > +-## 18:0:2 => 16.2.0 > +-## 17:0:2 => 15.2.0 > +- > ++## The version string is current[:revision[:age]] > ++## > ++## Before a release that has changed the source code at all > ++## increment revision. > ++## > ++## After merging changes that have changed the API in a backwards > ++## comptable way set revision to 0 and bump both current and age. > ++## > ++## Do not change the API in a backwards incompatible way. > ++## > ++## See "Libtool: Updating version info" > ++## ( > https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html > ) > ++## for more into > ++## > + if INCREMENTED_SONAME > +-libaspell_la_LDFLAGS = -version-info 18:0:2 -no-undefined > ++libaspell_la_LDFLAGS = -version-info 19:0:3 -no-undefined > + else > + ## Use C-1:R:A > +-libaspell_la_LDFLAGS = -version-info 17:0:2 -no-undefined > ++libaspell_la_LDFLAGS = -version-info 18:0:3 -no-undefined > + endif > + > + if PSPELL_COMPATIBILITY > +@@ -113,11 +120,7 @@ libpspell_la_SOURCES = lib/dummy.cpp > + > + libpspell_la_LIBADD = libaspell.la > + > +-if INCREMENTED_SONAME > +-libpspell_la_LDFLAGS = -version-info 18:0:2 -no-undefined > +-else > +-libpspell_la_LDFLAGS = -version-info 17:0:2 -no-undefined > +-endif > ++libpspell_la_LDFLAGS = $(libaspell_la_LDFLAGS) > + > + endif > + > +-- > +2.17.1 > + > diff --git a/meta/recipes-support/aspell/aspell_0.60.7.bb > b/meta/recipes-support/aspell/aspell_0.60.7.bb > index b565cb3c6e..1e104c263c 100644 > --- a/meta/recipes-support/aspell/aspell_0.60.7.bb > +++ b/meta/recipes-support/aspell/aspell_0.60.7.bb > @@ -8,6 +8,8 @@ PR = "r1" > > SRC_URI = "${GNU_MIRROR}/aspell/aspell-${PV}.tar.gz \ > file://0001-Fix-various-bugs-found-by-OSS-Fuze.patch \ > + file://CVE-2019-20433-0001.patch \ > + file://CVE-2019-20433-0002.patch \ > " > SRC_URI[md5sum] = "8ef2252609c511cd2bb26f3a3932ef28" > SRC_URI[sha256sum] = > "5ca8fc8cb0370cc6c9eb5b64c6d1bc5d57b3750dbf17887726c3407d833b70e4" > -- > 2.17.1 > From Mikko.Rapeli at bmw.de Thu Mar 12 12:34:19 2020 From: Mikko.Rapeli at bmw.de (Mikko.Rapeli at bmw.de) Date: Thu, 12 Mar 2020 12:34:19 +0000 Subject: [OE-core] [PATCH] [zeus] aspell: CVE-2019-20433 In-Reply-To: <67257554ffe08ac11b8f1cf3da115ba5a7e35fbd.camel@intel.com> References: <20200312092322.28506-1-stefan.ghinea@windriver.com> <67257554ffe08ac11b8f1cf3da115ba5a7e35fbd.camel@intel.com> Message-ID: <20200312123418.GR104502@korppu> On Thu, Mar 12, 2020 at 12:25:21PM +0000, Mittal, Anuj wrote: > It looks like this is changing the API. I wonder if this would need any > other change or break something elsewhere in OE-core, meta-oe? > > http://aspell.net/buffer-overread-ucs.txt Debian classified issues as minor and fixed only by updating to 0.60.8: https://security-tracker.debian.org/tracker/CVE-2019-20433 https://metadata.ftp-master.debian.org/changelogs//main/a/aspell/aspell_0.60.8-1_changelog Maybe whitelist for stable branches and update to new version on master? Cheers, -Mikko From bruce.ashfield at gmail.com Thu Mar 12 12:39:18 2020 From: bruce.ashfield at gmail.com (Bruce Ashfield) Date: Thu, 12 Mar 2020 08:39:18 -0400 Subject: [OE-core] CVE related consulting on linux-yocto on zeus branch In-Reply-To: References: Message-ID: On Thu, Mar 12, 2020 at 2:28 AM zangrc wrote: > > Our team plans to submit CVE-related patches that are not included in > -stable, but we found that the current version of the linux-yocto recipe > is lower than the linux-yocto git repository. On which version should we > make the patch. Send patches against the latest linux-yocto kernel tree, following the upstream kernel process. Also, consider nominating the patches for upstream -stable as well (but we can still integrate them to linux-yocto first). I can generate SRCREV bumps for the actual recipes, for the stable branches, after that. Cheers, Bruce > > On 3/11/20 8:36 PM, Bruce Ashfield wrote: > > On Wed, Mar 11, 2020 at 2:02 AM zangrc wrote: > >> > >> Hello, > >> > >> > >> our team is currently working on CVE-related work. I would like to ask > >> if the zeus branch of yocto has an update plan for linux-yocto in the > >> near future. If not, can we submit a CVE-related patch for the > >> linux-yocto of the zeus branch. > > If it is part of -stable, then yes, it will be integrated into any of > > the active upstream kernels. If it is in 5.2, we also have a -stable > > process for those kernels as well. > > > > If it doesn't fall into those categories, then send any patches > > (against the kernel itself) to the linux-yocto mailing list, do not > > send them as patches to the linux-yocto recipe itself. > > > > Cheers, > > > > Bruce > > > >> -- > >> Best Regards! > >> Zang Ruochen > >> > >> > >> > > > > -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II From bunk at stusta.de Thu Mar 12 12:49:08 2020 From: bunk at stusta.de (Adrian Bunk) Date: Thu, 12 Mar 2020 14:49:08 +0200 Subject: [OE-core] [PATCH] [zeus] aspell: CVE-2019-20433 In-Reply-To: <20200312123418.GR104502@korppu> References: <20200312092322.28506-1-stefan.ghinea@windriver.com> <67257554ffe08ac11b8f1cf3da115ba5a7e35fbd.camel@intel.com> <20200312123418.GR104502@korppu> Message-ID: <20200312124908.GA21921@localhost> On Thu, Mar 12, 2020 at 12:34:19PM +0000, Mikko.Rapeli at bmw.de wrote: > On Thu, Mar 12, 2020 at 12:25:21PM +0000, Mittal, Anuj wrote: > > It looks like this is changing the API. I wonder if this would need any > > other change or break something elsewhere in OE-core, meta-oe? > > > > http://aspell.net/buffer-overread-ucs.txt > > Debian classified issues as minor and fixed only by updating > to 0.60.8: > > https://security-tracker.debian.org/tracker/CVE-2019-20433 > > https://metadata.ftp-master.debian.org/changelogs//main/a/aspell/aspell_0.60.8-1_changelog > > Maybe whitelist for stable branches and update to new version on master? master already has the new version. IMHO whitelisting is wrong unless there would be a clear and documented policy what kind of vulnerabilities are getting whitelisted. But even then "Base Score: 9.1 CRITICAL"[1] would make whitelisting unlikely in this case. > Cheers, > > -Mikko cu Adrian [1] https://nvd.nist.gov/vuln/detail/CVE-2019-20433 From rpjday at crashcourse.ca Thu Mar 12 12:56:08 2020 From: rpjday at crashcourse.ca (rpjday at crashcourse.ca) Date: Thu, 12 Mar 2020 08:56:08 -0400 Subject: [OE-core] simplest command to display which layers are applying the same patch? Message-ID: <20200312085608.Horde.kbPh9KWkZJR4Zi-lry-_TrN@crashcourse.ca> just got from colleague a miniscule snippet of build output: ERROR: openssl-1.0.2u-r0 do_patch: Command Error: 'quilt --quiltrc ... snip ... Output: Patch Use-SHA256-not-MD5-as-default-digest.patch is already applied; check your series file the problem seems obvious ... more than one layer being pulled into the build is trying to apply the same patch to that version of openssl. i don't have access to that build system, but i'm not surprised as it appears that at least three layers (oe-core, vendor, and wind river linux fixes layer) all supply that very patch. what is the simplest command from way back in "morty" that could display something as clear as, "layer A already applied this patch, now layer B is trying to apply it as well?" if it's in the log file, i can just point the person at that, short of getting access to the build system and finding it myself. thank you kindly. rday From alex.kanavin at gmail.com Thu Mar 12 13:09:23 2020 From: alex.kanavin at gmail.com (Alexander Kanavin) Date: Thu, 12 Mar 2020 14:09:23 +0100 Subject: [OE-core] simplest command to display which layers are applying the same patch? In-Reply-To: <20200312085608.Horde.kbPh9KWkZJR4Zi-lry-_TrN@crashcourse.ca> References: <20200312085608.Horde.kbPh9KWkZJR4Zi-lry-_TrN@crashcourse.ca> Message-ID: I think 'bitbake -e recipe', and then searching for SRC_URI in it should show which layer applies which patch. Alex On Thu, 12 Mar 2020 at 13:56, wrote: > just got from colleague a miniscule snippet of build output: > > ERROR: openssl-1.0.2u-r0 do_patch: Command Error: 'quilt --quiltrc ... > snip ... > Output: Patch Use-SHA256-not-MD5-as-default-digest.patch is already > applied; check your series file > > the problem seems obvious ... more than one layer being pulled > into the build is trying to apply the same patch to that version > of openssl. > > i don't have access to that build system, but i'm not surprised > as it appears that at least three layers (oe-core, vendor, and > wind river linux fixes layer) all supply that very patch. > > what is the simplest command from way back in "morty" that > could display something as clear as, "layer A already applied > this patch, now layer B is trying to apply it as well?" > > if it's in the log file, i can just point the person at that, > short of getting access to the build system and finding it > myself. thank you kindly. > > rday > > > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core at lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anuj.mittal at intel.com Thu Mar 12 13:04:53 2020 From: anuj.mittal at intel.com (Mittal, Anuj) Date: Thu, 12 Mar 2020 13:04:53 +0000 Subject: [OE-core] [PATCH] [zeus] aspell: CVE-2019-20433 In-Reply-To: <20200312123418.GR104502@korppu> References: <20200312092322.28506-1-stefan.ghinea@windriver.com> <67257554ffe08ac11b8f1cf3da115ba5a7e35fbd.camel@intel.com> <20200312123418.GR104502@korppu> Message-ID: > -----Original Message----- > From: Mikko.Rapeli at bmw.de > Sent: Thursday, March 12, 2020 08:34 PM > To: Mittal, Anuj > Cc: openembedded-core at lists.openembedded.org; stefan.ghinea at windriver.com > Subject: Re: [OE-core] [PATCH] [zeus] aspell: CVE-2019-20433 > > On Thu, Mar 12, 2020 at 12:25:21PM +0000, Mittal, Anuj wrote: > > It looks like this is changing the API. I wonder if this would need > > any other change or break something elsewhere in OE-core, meta-oe? > > > > http://aspell.net/buffer-overread-ucs.txt > > Debian classified issues as minor and fixed only by updating to 0.60.8: They were applied to 0.60.7: https://salsa.debian.org/debian/aspell/-/commit/ab3214b1e758646c5a995d277ac80f6d04566149 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935128 I think that "minor" categorization is for versions where it wasn't fixed. The NVD severity at the top says medium and it has been assigned a score of 9.1. > > https://security-tracker.debian.org/tracker/CVE-2019-20433 > > https://metadata.ftp-master.debian.org/changelogs//main/a/aspell/aspell_0.60.8- > 1_changelog > > Maybe whitelist for stable branches and update to new version on master? > Whitelisting doesn't sound the right thing to do here especially since this is a valid problem. Thanks, Anuj From rpjday at crashcourse.ca Thu Mar 12 13:24:06 2020 From: rpjday at crashcourse.ca (rpjday at crashcourse.ca) Date: Thu, 12 Mar 2020 09:24:06 -0400 Subject: [OE-core] simplest command to display which layers are applying the same patch? In-Reply-To: References: <20200312085608.Horde.kbPh9KWkZJR4Zi-lry-_TrN@crashcourse.ca> Message-ID: <20200312092406.Horde.dKGE_j40Nb1uLkJiJ77C4ZG@crashcourse.ca> Ah, I was just playing with a build of my own (which works so I can't replicate the error), but if I "bitbake -e openssl", then I can obviously see all the operations that go into constructing the SRC_URI, along with the layers that contribute to that expansion, so I am assuming that, even if more than one layer tries to apply the same patch, all those SRC_URI values will be properly appended, in the sense of a duplicate patch will occur twice in the final value of SRC_URI, yes? And only when do_patch() kicks in will the duplicate patch generate a patch error, correct? That seems pretty straightforward, as long as I'm understanding the process here. Thanks again. rday Quoting Alexander Kanavin : > I think 'bitbake -e recipe', and then searching for SRC_URI in it should > show which layer applies which patch. > > Alex > > On Thu, 12 Mar 2020 at 13:56, wrote: > >> just got from colleague a miniscule snippet of build output: >> >> ERROR: openssl-1.0.2u-r0 do_patch: Command Error: 'quilt --quiltrc ... >> snip ... >> Output: Patch Use-SHA256-not-MD5-as-default-digest.patch is already >> applied; check your series file >> >> the problem seems obvious ... more than one layer being pulled >> into the build is trying to apply the same patch to that version >> of openssl. >> >> i don't have access to that build system, but i'm not surprised >> as it appears that at least three layers (oe-core, vendor, and >> wind river linux fixes layer) all supply that very patch. >> >> what is the simplest command from way back in "morty" that >> could display something as clear as, "layer A already applied >> this patch, now layer B is trying to apply it as well?" >> >> if it's in the log file, i can just point the person at that, >> short of getting access to the build system and finding it >> myself. thank you kindly. >> >> rday >> >> >> -- >> _______________________________________________ >> Openembedded-core mailing list >> Openembedded-core at lists.openembedded.org >> http://lists.openembedded.org/mailman/listinfo/openembedded-core >> From Mikko.Rapeli at bmw.de Thu Mar 12 13:25:18 2020 From: Mikko.Rapeli at bmw.de (Mikko.Rapeli at bmw.de) Date: Thu, 12 Mar 2020 13:25:18 +0000 Subject: [OE-core] [PATCH] [zeus] aspell: CVE-2019-20433 In-Reply-To: <20200312124908.GA21921@localhost> Message-ID: <20200312132517.GV104502@korppu> Yes, you are correct. White listing isn't right either. -Mikko From jonathan.rajotte-julien at efficios.com Thu Mar 12 14:25:24 2020 From: jonathan.rajotte-julien at efficios.com (Jonathan Rajotte-Julien) Date: Thu, 12 Mar 2020 10:25:24 -0400 Subject: [OE-core] [PATCH 1/2] babletrace2: make manpages multilib identical In-Reply-To: <20200311222249.29880-1-jpuhlman@mvista.com> References: <20200311222249.29880-1-jpuhlman@mvista.com> Message-ID: <20200312142524.GB30953@joraj-alpa> Hi Is this something upstream (lttng-dev mailing list) should be interested in? Cheers On Wed, Mar 11, 2020 at 03:22:48PM -0700, Jeremy A. Puhlman wrote: > From: Jeremy Puhlman > > Signed-off-by: Jeremy A. Puhlman > --- > .../0001-Make-manpages-multilib-identical.patch | 28 ++++++++++++++++++++++ > meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb | 1 + > 2 files changed, 29 insertions(+) > create mode 100644 meta/recipes-kernel/lttng/babeltrace2/0001-Make-manpages-multilib-identical.patch > > diff --git a/meta/recipes-kernel/lttng/babeltrace2/0001-Make-manpages-multilib-identical.patch b/meta/recipes-kernel/lttng/babeltrace2/0001-Make-manpages-multilib-identical.patch > new file mode 100644 > index 0000000000..2401b176e6 > --- /dev/null > +++ b/meta/recipes-kernel/lttng/babeltrace2/0001-Make-manpages-multilib-identical.patch > @@ -0,0 +1,28 @@ > +From 56986190e4b0c10945ce6aaa7ca10d6bd8a26a39 Mon Sep 17 00:00:00 2001 > +From: Jeremy Puhlman > +Date: Mon, 9 Mar 2020 21:10:35 +0000 > +Subject: [PATCH] Make manpages multilib identical > + > +Upstream-Status: Pending > +Signed-off-by: Jeremy Puhlman > +--- > + doc/man/asciidoc-attrs.conf.in | 4 ++-- > + 1 file changed, 2 insertions(+), 2 deletions(-) > + > +diff --git a/doc/man/asciidoc-attrs.conf.in b/doc/man/asciidoc-attrs.conf.in > +index ad1183f1..e11c7031 100644 > +--- a/doc/man/asciidoc-attrs.conf.in > ++++ b/doc/man/asciidoc-attrs.conf.in > +@@ -1,7 +1,7 @@ > + [attributes] > + # default values > +-system_plugin_path="@LIBDIR@/babeltrace2/plugins" > +-system_plugin_provider_path="@LIBDIR@/babeltrace2/plugin-providers" > ++system_plugin_path="@prefix@/lib*/babeltrace2/plugins" > ++system_plugin_provider_path="@prefix@/lib*/babeltrace2/plugin-providers" > + babeltrace_version="@PACKAGE_VERSION@" > + enable_debug_info="@ENABLE_DEBUG_INFO_VAL@" > + defrdport=5344 > +-- > +2.24.1 > + > diff --git a/meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb b/meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb > index 16953d6807..61bc7f5e6b 100644 > --- a/meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb > +++ b/meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb > @@ -10,6 +10,7 @@ DEPENDS = "glib-2.0 util-linux popt bison-native flex-native" > SRC_URI = "git://git.linuxfoundation.org/diamon/babeltrace.git;branch=stable-2.0 \ > file://run-ptest \ > file://0001-tests-do-not-run-test-applications-from-.libs.patch \ > + file://0001-Make-manpages-multilib-identical.patch \ > " > SRCREV = "06df58f89ee51b1a2c6a2c187ec3f15691633910" > UPSTREAM_CHECK_GITTAGREGEX = "v(?P2(\.\d+)+)$" > -- > 2.13.3 > > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core at lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- Jonathan Rajotte-Julien EfficiOS From rpjday at crashcourse.ca Thu Mar 12 14:30:03 2020 From: rpjday at crashcourse.ca (rpjday at crashcourse.ca) Date: Thu, 12 Mar 2020 10:30:03 -0400 Subject: [OE-core] simplest command to display which layers are applying the same patch? In-Reply-To: References: <20200312085608.Horde.kbPh9KWkZJR4Zi-lry-_TrN@crashcourse.ca> Message-ID: <20200312103003.Horde.-mn1W9NE8YAc6sk0SRLY8bj@crashcourse.ca> Quoting Alexander Kanavin : > I think 'bitbake -e recipe', and then searching for SRC_URI in it should > show which layer applies which patch. ... snip ... I *think* I know what might be happening here, and I'd like to verify some suspicions about how recipes are selected and patches are applied. (Writing this in real time so I hope I don't screw up.) Imagine I've checked out oe-core, which supplies recipe file fubar_1.0.bb, but it becomes obvious that there is a bug, for which there is an obvious patch I can apply internally. So I fire up a fubar bbappend file, which does nothing but extend SRC_URI to apply the patch, call it fubar.patch. (Remember, this patching is all internal, in my vendor layer.) *However*, being a bit lazy, rather than create fubar_1.0.bbappend, I slack off and create simply fubar_1.%.bbappend. (I suspect you see where I'm going with this.) Now the good folks at OE get around to updating oe-core, and part of that update is to add that patch to SRC_URI of fubar_1.1.bb (along with the patch file fubar.patch, of course). Now, because that is a more recent version of fubar, that is the recipe file that should be selected. *However*, if I interpret this correctly, first, I have fubar_1.1.bb applying fubar.patch, but because I am also defining a layer which contains the append file fubar_1.%.bbappend, that append file will also try to apply the same patch, which of course should not work properly. (Am I correct in my thinking so far?) If I'm explaining this correctly, then the fault naturally lies with me for being sloppily ambiguous with my append file and not locking it to fubar_1.0, but allowing it to be applied against all fubar_1.x recipes. In short, when I inevitably get the error of "Patch already applied," it is entirely my fault for being sloppy. I'm trying to verify this as I am now aware that a *lot* of append files in the vendor layer in question are similarly ambiguous. Does this make sense? rday From jonathan.rajotte-julien at efficios.com Thu Mar 12 14:33:04 2020 From: jonathan.rajotte-julien at efficios.com (Jonathan Rajotte-Julien) Date: Thu, 12 Mar 2020 10:33:04 -0400 Subject: [OE-core] [PATCH] babeltrace2: initialize the other_entry pointer In-Reply-To: <1583934573-94011-1-git-send-email-mingli.yu@windriver.com> References: <1583934573-94011-1-git-send-email-mingli.yu@windriver.com> Message-ID: <20200312143304.GC30953@joraj-alpa> Hi Mingli, Thanks for also posting this on the lttng-dev mailing list. I'm sure we can get this in fairly quickly upstream. This is more a question for Richard and other core members of oe, is this kind of patch pertinent for upstream oe considering it is only silencing a warning (based on [1])? [1] https://lists.lttng.org/pipermail/lttng-dev/2020-March/029550.html On Wed, Mar 11, 2020 at 09:49:33PM +0800, mingli.yu at windriver.com wrote: > From: Mingli Yu > > When add below line to local.conf to enable debug build: > > DEBUG_BUILD = "1" > > There comes below failure when run "bitbake babeltrace2" > | ../../../../../git/src/plugins/ctf/fs-src/fs.c: In function 'ds_index_insert_ds_index_entry_sorted': > | ../../../../../git/src/plugins/ctf/fs-src/fs.c:702:5: error: 'other_entry' may be used uninitialized in this function [-Werror=maybe-uninitialized] > | 702 | !ds_index_entries_equal(entry, other_entry)) { > > So initialize the other_entry pointer to fix the above error. > > Signed-off-by: Mingli Yu > --- > .../0001-fs.c-initialize-other_entry.patch | 33 ++++++++++++++++++++++ > meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb | 1 + > 2 files changed, 34 insertions(+) > create mode 100644 meta/recipes-kernel/lttng/babeltrace2/0001-fs.c-initialize-other_entry.patch > > diff --git a/meta/recipes-kernel/lttng/babeltrace2/0001-fs.c-initialize-other_entry.patch b/meta/recipes-kernel/lttng/babeltrace2/0001-fs.c-initialize-other_entry.patch > new file mode 100644 > index 0000000..b56b3bd > --- /dev/null > +++ b/meta/recipes-kernel/lttng/babeltrace2/0001-fs.c-initialize-other_entry.patch > @@ -0,0 +1,33 @@ > +From 42dae692b9057d03ce9a0651f061472e9dd90130 Mon Sep 17 00:00:00 2001 > +From: Mingli Yu > +Date: Wed, 11 Mar 2020 08:44:42 +0000 > +Subject: [PATCH] fs.c: initialize the other_entry variable > + > +Initialize the pointer other_entry to fix the below error: > +| ../../../../../git/src/plugins/ctf/fs-src/fs.c: In function 'ds_index_insert_ds_index_entry_sorted': > +| ../../../../../git/src/plugins/ctf/fs-src/fs.c:702:5: error: 'other_entry' may be used uninitialized in this function [-Werror=maybe-uninitialized] > +| 702 | !ds_index_entries_equal(entry, other_entry)) { > + > +Upstream-Status: Submitted [https://lists.lttng.org/pipermail/lttng-dev/2020-March/029549.html] > + > +Signed-off-by: Mingli Yu > +--- > + src/plugins/ctf/fs-src/fs.c | 2 +- > + 1 file changed, 1 insertion(+), 1 deletion(-) > + > +diff --git a/src/plugins/ctf/fs-src/fs.c b/src/plugins/ctf/fs-src/fs.c > +index e87523a3..a6b5315f 100644 > +--- a/src/plugins/ctf/fs-src/fs.c > ++++ b/src/plugins/ctf/fs-src/fs.c > +@@ -680,7 +680,7 @@ void ds_index_insert_ds_index_entry_sorted( > + struct ctf_fs_ds_index_entry *entry) > + { > + guint i; > +- struct ctf_fs_ds_index_entry *other_entry; > ++ struct ctf_fs_ds_index_entry *other_entry = NULL; > + > + /* Find the spot where to insert this index entry. */ > + for (i = 0; i < index->entries->len; i++) { > +-- > +2.24.1 > + > diff --git a/meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb b/meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb > index 16953d6..c027d8b 100644 > --- a/meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb > +++ b/meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb > @@ -10,6 +10,7 @@ DEPENDS = "glib-2.0 util-linux popt bison-native flex-native" > SRC_URI = "git://git.linuxfoundation.org/diamon/babeltrace.git;branch=stable-2.0 \ > file://run-ptest \ > file://0001-tests-do-not-run-test-applications-from-.libs.patch \ > + file://0001-fs.c-initialize-other_entry.patch \ > " > SRCREV = "06df58f89ee51b1a2c6a2c187ec3f15691633910" > UPSTREAM_CHECK_GITTAGREGEX = "v(?P2(\.\d+)+)$" > -- > 2.7.4 > > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core at lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- Jonathan Rajotte-Julien EfficiOS From stefan.ghinea at windriver.com Thu Mar 12 14:35:47 2020 From: stefan.ghinea at windriver.com (Stefan Robert Ghinea) Date: Thu, 12 Mar 2020 16:35:47 +0200 Subject: [OE-core] [PATCH] [zeus] aspell: CVE-2019-20433 In-Reply-To: <67257554ffe08ac11b8f1cf3da115ba5a7e35fbd.camel@intel.com> References: <20200312092322.28506-1-stefan.ghinea@windriver.com> <67257554ffe08ac11b8f1cf3da115ba5a7e35fbd.camel@intel.com> Message-ID: <26a1f113-7348-ba43-837d-32858939ca0d@windriver.com> I looked for dependent packages in oe-core and in meta-oe with grep and found only enchant and enchant2 although I was able to build both of them having the aspell patch applied. Best regards, Stefan Ghinea On 3/12/20 14:25, Mittal, Anuj wrote: > It looks like this is changing the API. I wonder if this would need any > other change or break something elsewhere in OE-core, meta-oe? > > http://aspell.net/buffer-overread-ucs.txt > > Thanks, > > Anuj > > On Thu, 2020-03-12 at 11:23 +0200, Stefan Ghinea wrote: >> libaspell.a in GNU Aspell before 0.60.8 has a buffer over-read for a >> string >> ending with a single '\0' byte, if the encoding is set to ucs-2 or >> ucs-4 >> outside of the application, as demonstrated by the ASPELL_CONF >> environment >> variable. >> >> References: >> https://nvd.nist.gov/vuln/detail/CVE-2019-20433 >> >> Upstream patches: >> https://github.com/GNUAspell/aspell/commit/de29341638833ba7717bd6b5e6850998454b044b >> https://github.com/GNUAspell/aspell/commit/cefd447e5528b08bb0cd6656bc52b4255692cefc >> >> Signed-off-by: Stefan Ghinea >> --- >> .../aspell/aspell/CVE-2019-20433-0001.patch | 999 >> ++++++++++++++++++ >> .../aspell/aspell/CVE-2019-20433-0002.patch | 68 ++ >> meta/recipes-support/aspell/aspell_0.60.7.bb | 2 + >> 3 files changed, 1069 insertions(+) >> create mode 100644 meta/recipes-support/aspell/aspell/CVE-2019- >> 20433-0001.patch >> create mode 100644 meta/recipes-support/aspell/aspell/CVE-2019- >> 20433-0002.patch >> >> diff --git a/meta/recipes-support/aspell/aspell/CVE-2019-20433- >> 0001.patch b/meta/recipes-support/aspell/aspell/CVE-2019-20433- >> 0001.patch >> new file mode 100644 >> index 0000000000..fd68461e32 >> --- /dev/null >> +++ b/meta/recipes-support/aspell/aspell/CVE-2019-20433-0001.patch >> @@ -0,0 +1,999 @@ >> +From de29341638833ba7717bd6b5e6850998454b044b Mon Sep 17 00:00:00 >> 2001 >> +From: Kevin Atkinson >> +Date: Sat, 17 Aug 2019 17:06:53 -0400 >> +Subject: [PATCH 1/2] Don't allow null-terminated UCS-2/4 strings >> using the >> + original API. >> + >> +Detect if the encoding is UCS-2/4 and the length is -1 in affected >> API >> +functions and refuse to convert the string. If the string ends up >> +being converted somehow, abort with an error message in DecodeDirect >> +and ConvDirect. To convert a null terminated string in >> +Decode/ConvDirect, a negative number corresponding to the width of >> the >> +underlying character type for the encoding is expected; for example, >> +if the encoding is "ucs-2" then a the size is expected to be -2. >> + >> +Also fix a 1-3 byte over-read in DecodeDirect when reading UCS-2/4 >> +strings when a size is provided (found by OSS-Fuzz). >> + >> +Also fix a bug in DecodeDirect that caused DocumentChecker to return >> +the wrong offsets when working with UCS-2/4 strings. >> + >> +CVE: CVE-2019-20433 >> +Upstream-Status: Backport [ >> https://github.com/GNUAspell/aspell/commit/de29341638833ba7717bd6b5e6850998454b044b >> ] >> + >> +[SG: - adjusted context >> + - discarded test changes as test framework is not available >> + - discarded manual entry changes for features that aren't >> backported] >> +Signed-off-by: Stefan Ghinea >> +--- >> + auto/MkSrc/CcHelper.pm | 99 >> ++++++++++++++++++++++++++++++++++--- >> + auto/MkSrc/Create.pm | 5 +- >> + auto/MkSrc/Info.pm | 5 +- >> + auto/MkSrc/ProcCc.pm | 24 +++++---- >> + auto/MkSrc/ProcImpl.pm | 57 +++++++++++++++------ >> + auto/MkSrc/Read.pm | 4 +- >> + auto/mk-src.in | 44 +++++++++++++++-- >> + common/convert.cpp | 39 ++++++++++++--- >> + common/convert.hpp | 38 +++++++++++++- >> + common/document_checker.cpp | 17 ++++++- >> + common/document_checker.hpp | 1 + >> + common/version.cpp | 15 ++++-- >> + configure.ac | 8 +++ >> + manual/aspell.texi | 58 ++++++++++++++++------ >> + manual/readme.texi | 70 +++++++++++++++++++++----- >> + 15 files changed, 409 insertions(+), 75 deletions(-) >> + >> +diff --git a/auto/MkSrc/CcHelper.pm b/auto/MkSrc/CcHelper.pm >> +index f2de991..0044335 100644 >> +--- a/auto/MkSrc/CcHelper.pm >> ++++ b/auto/MkSrc/CcHelper.pm >> +@@ -10,8 +10,8 @@ BEGIN { >> + use Exporter; >> + our @ISA = qw(Exporter); >> + our @EXPORT = qw(to_c_return_type c_error_cond >> +- to_type_name make_desc make_func call_func >> +- make_c_method call_c_method form_c_method >> ++ to_type_name make_desc make_func call_func >> get_c_func_name >> ++ make_c_method make_wide_macro call_c_method >> form_c_method >> + make_cxx_method); >> + } >> + >> +@@ -90,6 +90,69 @@ sub make_func ( $ \@ $ ; \% ) { >> + ')')); >> + } >> + >> ++=item make_wide_version NAME @TYPES PARMS ; %ACCUM >> ++ >> ++Creates the wide character version of the function if needed >> ++ >> ++=cut >> ++ >> ++sub make_wide_version ( $ \@ $ ; \% ) { >> ++ my ($name, $d, $p, $accum) = @_; >> ++ my @d = @$d; >> ++ shift @d; >> ++ return '' unless grep {$_->{type} eq 'encoded string'} @d; >> ++ $accum->{sys_headers}{'stddef.h'} = true; >> ++ $accum->{suffix}[5] = <<'---'; >> ++ >> ++/******************* private implemantion details >> *********************/ >> ++ >> ++#ifdef __cplusplus >> ++# define aspell_cast_(type, expr) (static_cast(expr)) >> ++# define aspell_cast_from_wide_(str) (static_cast> *>(str)) >> ++#else >> ++# define aspell_cast_(type, expr) ((type)(expr)) >> ++# define aspell_cast_from_wide_(str) ((const char *)(str)) >> ++#endif >> ++--- >> ++ my @parms = map {$_->{type} eq 'encoded string' >> ++ ? ($_->{name}, $_->{name}.'_size') >> ++ : $_->{name}} @d; >> ++ $name = to_lower $name; >> ++ $accum->{suffix}[0] = <<'---'; >> ++/****************************************************************** >> ****/ >> ++ >> ++#ifdef ASPELL_ENCODE_SETTING_SECURE >> ++--- >> ++ $accum->{suffix}[2] = "#endif\n"; >> ++ my @args = map {$_->{type} eq 'encoded string' >> ++ ? ($_->{name}, "$_->{name}_size", '-1') >> ++ : $_->{name}} @d; >> ++ $accum->{suffix}[1] .= >> ++ (join '', >> ++ "#define $name", >> ++ '(', join(', ', @parms), ')', >> ++ "\\\n ", >> ++ $name, '_wide', >> ++ '(', join(', ', @args), ')', >> ++ "\n"); >> ++ @args = map {$_->{type} eq 'encoded string' >> ++ ? ("aspell_cast_from_wide_($_->{name})", >> ++ "$_- >>> {name}_size*aspell_cast_(int,sizeof(*($_->{name})))", >> ++ "sizeof(*($_->{name}))") >> ++ : $_->{name}} @d; >> ++ return (join '', >> ++ "\n", >> ++ "/* version of $name that is safe to use with (null >> terminated) wide characters */\n", >> ++ '#define ', >> ++ $name, '_w', >> ++ '(', join(', ', @parms), ')', >> ++ "\\\n ", >> ++ $name, '_wide', >> ++ '(', join(', ', @args), ')', >> ++ "\n"); >> ++} >> ++ >> ++ >> + =item call_func NAME @TYPES PARMS ; %ACCUM >> + >> + Return a string to call a func. Will prefix the function with >> return >> +@@ -103,7 +166,6 @@ Parms can be any of: >> + >> + sub call_func ( $ \@ $ ; \% ) { >> + my ($name, $d, $p, $accum) = @_; >> +- $accum = {} unless defined $accum; >> + my @d = @$d; >> + my $func_ret = to_type_name(shift @d, {%$p,pos=>'return'}, >> %$accum); >> + return (join '', >> +@@ -148,8 +210,14 @@ sub to_type_name ( $ $ ; \% ) { >> + my $name = $t->{name}; >> + my $type = $t->{type}; >> + >> +- return ( (to_type_name {%$d, type=>'string'}, $p, %$accum) , >> +- (to_type_name {%$d, type=>'int', name=>"$d->{name}_size"}, >> $p, %$accum) ) >> ++ if ($name eq 'encoded string' && $is_cc && $pos eq 'parm') { >> ++ my @types = ((to_type_name {%$d, type=>($p->{wide}?'const void >> pointer':'string')}, $p, %$accum), >> ++ (to_type_name {%$d, type=>'int', name=>"$d- >>> {name}_size"}, $p, %$accum)); >> ++ push @types, (to_type_name {%$d, type=>'int', name=>"$d- >>> {name}_type_width"}, $p, %$accum) if $p->{wide}; >> ++ return @types; >> ++ } >> ++ return ( (to_type_name {%$d, type=>($p->{wide}?'const void >> pointer':'string')}, $p, %$accum) , >> ++ (to_type_name {%$d, type=>'int', name=>"$d- >>> {name}_size"}, $p, %$accum) ) >> + if $name eq 'encoded string' && $is_cc && $pos eq 'parm'; >> + >> + my $str; >> +@@ -174,7 +242,7 @@ sub to_type_name ( $ $ ; \% ) { >> + $str .= "String"; >> + } >> + } elsif ($name eq 'encoded string') { >> +- $str .= "const char *"; >> ++ $str .= $p->{wide} ? "const void *" : "const char *"; >> + } elsif ($name eq '') { >> + $str .= "void"; >> + } elsif ($name eq 'bool' && $is_cc) { >> +@@ -186,7 +254,7 @@ sub to_type_name ( $ $ ; \% ) { >> + if ($t->{pointer}) { >> + $accum->{types}->{$name} = $t; >> + } else { >> +- $accum->{headers}->{$t->{created_in}} = true; >> ++ $accum->{headers}->{$t->{created_in}} = true unless $mode >> eq 'cc'; >> + } >> + $str .= "$c_type Aspell" if $mode eq 'cc'; >> + $str .= to_mixed($name); >> +@@ -214,6 +282,7 @@ sub to_type_name ( $ $ ; \% ) { >> + return $str; >> + } >> + >> ++ >> + =item make_desc DESC ; LEVEL >> + >> + Make a C comment out of DESC optionally indenting it LEVEL spaces. >> +@@ -286,6 +355,7 @@ sub form_c_method ($ $ $ ; \% ) >> + } else { >> + $func = "aspell $class $name"; >> + } >> ++ $func .= " wide" if $p->{wide}; >> + if (exists $d->{'const'}) { >> + splice @data, 1, 0, {type => "const $class", name=> >> $this_name}; >> + } else { >> +@@ -306,6 +376,21 @@ sub make_c_method ($ $ $ ; \%) >> + return &make_func(@ret); >> + } >> + >> ++sub get_c_func_name ($ $ $) >> ++{ >> ++ my @ret = &form_c_method(@_); >> ++ return undef unless @ret > 0; >> ++ return to_lower $ret[0]; >> ++} >> ++ >> ++sub make_wide_macro ($ $ $ ; \%) >> ++{ >> ++ my @ret = &form_c_method(@_); >> ++ return undef unless @ret > 0; >> ++ my $str = &make_wide_version(@ret); >> ++ return $str; >> ++} >> ++ >> + sub call_c_method ($ $ $ ; \%) >> + { >> + my @ret = &form_c_method(@_); >> +diff --git a/auto/MkSrc/Create.pm b/auto/MkSrc/Create.pm >> +index d39b60e..630ede5 100644 >> +--- a/auto/MkSrc/Create.pm >> ++++ b/auto/MkSrc/Create.pm >> +@@ -77,8 +77,10 @@ sub create_cc_file ( % ) { >> + $file .= "#include \"aspell.h\"\n" if $p{type} eq 'cxx'; >> + $file .= "#include \"settings.h\"\n" if $p{type} eq 'native_impl' >> && $p{name} eq 'errors'; >> + $file .= "#include \"gettext.h\"\n" if $p{type} eq 'native_impl' >> && $p{name} eq 'errors'; >> ++ $file .= cmap {"#include <$_>\n"} sort keys >> %{$accum{sys_headers}}; >> + $file .= cmap {"#include \"".to_lower($_).".hpp\"\n"} sort keys >> %{$accum{headers}}; >> +- $file .= "#ifdef __cplusplus\nextern \"C\" {\n#endif\n" if >> $p{header} && !$p{cxx}; >> ++ $file .= "\n#ifdef __cplusplus\nextern \"C\" {\n#endif\n" if >> $p{header} && !$p{cxx}; >> ++ $file .= join('', grep {defined $_} @{$accum{prefix}}); >> + $file .= "\nnamespace $p{namespace} {\n\n" if $p{cxx}; >> + if (defined $info{forward}{proc}{$p{type}}) { >> + my @types = sort {$a->{name} cmp $b->{name}} (values >> %{$accum{types}}); >> +@@ -86,6 +88,7 @@ sub create_cc_file ( % ) { >> + } >> + $file .= "\n"; >> + $file .= $body; >> ++ $file .= join('', grep {defined $_} @{$accum{suffix}}); >> + $file .= "\n\n}\n\n" if $p{cxx}; >> + $file .= "#ifdef __cplusplus\n}\n#endif\n" if $p{header} && >> !$p{cxx}; >> + $file .= "#endif /* $hm */\n" if $p{header}; >> +diff --git a/auto/MkSrc/Info.pm b/auto/MkSrc/Info.pm >> +index c644028..ace8e21 100644 >> +--- a/auto/MkSrc/Info.pm >> ++++ b/auto/MkSrc/Info.pm >> +@@ -60,6 +60,7 @@ each proc sub should take the following argv >> + the object from which it is a member of >> + no native: do not attempt to create a native implementation >> + treat as object: treat as a object rather than a pointer >> ++ no conv: do not converted an encoded string >> + >> + The %info structure is initialized as follows: >> + >> +@@ -104,8 +105,8 @@ The %info structure is initialized as follows: >> + errors => {}, # possible errors >> + method => { >> + # A class method >> +- options => ['desc', 'posib err', 'c func', 'const', >> +- 'c only', 'c impl', 'cxx impl'], >> ++ options => ['desc', 'posib err', 'c func', 'const', 'no conv', >> 'on conv error', >> ++ 'c only', 'c impl', 'cxx impl', 'cc extra'], >> + groups => undef}, >> + constructor => { >> + # A class constructor >> +diff --git a/auto/MkSrc/ProcCc.pm b/auto/MkSrc/ProcCc.pm >> +index 47c4338..98cc435 100644 >> +--- a/auto/MkSrc/ProcCc.pm >> ++++ b/auto/MkSrc/ProcCc.pm >> +@@ -23,7 +23,7 @@ use MkSrc::Info; >> + sub make_c_object ( $ @ ); >> + >> + $info{group}{proc}{cc} = sub { >> +- my ($data) = @_; >> ++ my ($data, at rest) = @_; >> + my $ret; >> + my $stars = (70 - length $data->{name})/2; >> + $ret .= "/"; >> +@@ -33,14 +33,14 @@ $info{group}{proc}{cc} = sub { >> + $ret .= "/\n"; >> + foreach my $d (@{$data->{data}}) { >> + $ret .= "\n\n"; >> +- $ret .= $info{$d->{type}}{proc}{cc}->($d); >> ++ $ret .= $info{$d->{type}}{proc}{cc}->($d, at rest); >> + } >> + $ret .= "\n\n"; >> + return $ret; >> + }; >> + >> + $info{enum}{proc}{cc} = sub { >> +- my ($d) = @_; >> ++ my ($d, at rest) = @_; >> + my $n = "Aspell".to_mixed($d->{name}); >> + return ("\n". >> + make_desc($d->{desc}). >> +@@ -58,21 +58,26 @@ $info{struct}{proc}{cc} = sub { >> + }; >> + >> + $info{union}{proc}{cc} = sub { >> +- return make_c_object "union", $_[0]; >> ++ return make_c_object "union", @_; >> + }; >> + >> + $info{class}{proc}{cc} = sub { >> +- my ($d) = @_; >> ++ my ($d,$accum) = @_; >> + my $class = $d->{name}; >> + my $classname = "Aspell".to_mixed($class); >> + my $ret = ""; >> + $ret .= "typedef struct $classname $classname;\n\n"; >> + foreach (@{$d->{data}}) { >> +- my $s = make_c_method($class, $_, {mode=>'cc'}); >> ++ my $s = make_c_method($class, $_, {mode=>'cc'}, %$accum); >> + next unless defined $s; >> + $ret .= "\n"; >> + $ret .= make_desc($_->{desc}); >> +- $ret .= make_c_method($class, $_, {mode=>'cc'}).";\n"; >> ++ $ret .= make_c_method($class, $_, {mode=>'cc'}, %$accum).";\n"; >> ++ if (grep {$_->{type} eq 'encoded string'} @{$_->{data}}) { >> ++ $ret .= make_c_method($class, $_, {mode=>'cc', wide=>true}, >> %$accum).";\n"; >> ++ $ret .= make_wide_macro($class, $_, {mode=>'cc'}, %$accum); >> ++ } >> ++ $ret .= "\n".$_->{'cc extra'}."\n" if defined $_->{'cc extra'}; >> + } >> + $ret .= "\n"; >> + return $ret; >> +@@ -105,7 +110,8 @@ $info{errors}{proc}{cc} = sub { >> + }; >> + >> + sub make_c_object ( $ @ ) { >> +- my ($t, $d) = @_; >> ++ my ($t, $d, $accum) = @_; >> ++ $accum = {} unless defined $accum; >> + my $struct; >> + $struct .= "Aspell"; >> + $struct .= to_mixed($d->{name}); >> +@@ -120,7 +126,7 @@ sub make_c_object ( $ @ ) { >> + "\n};\n"), >> + "typedef $t $struct $struct;", >> + join ("\n", >> +- map {make_c_method($d->{name}, $_, {mode=>'cc'}).";"} >> ++ map {make_c_method($d->{name}, $_, {mode=>'cc'}, >> %$accum).";"} >> + grep {$_->{type} eq 'method'} >> + @{$d->{data}}) >> + )."\n"; >> +diff --git a/auto/MkSrc/ProcImpl.pm b/auto/MkSrc/ProcImpl.pm >> +index b8628fd..3d0f220 100644 >> +--- a/auto/MkSrc/ProcImpl.pm >> ++++ b/auto/MkSrc/ProcImpl.pm >> +@@ -45,10 +45,13 @@ $info{class}{proc}{impl} = sub { >> + foreach (grep {$_ ne ''} split /\s*,\s*/, $data->{'c impl >> headers'}) { >> + $accum->{headers}{$_} = true; >> + } >> +- foreach my $d (@{$data->{data}}) { >> ++ my @d = @{$data->{data}}; >> ++ while (@d) { >> ++ my $d = shift @d; >> ++ my $need_wide = false; >> + next unless one_of $d->{type}, qw(method constructor >> destructor); >> + my @parms = @{$d->{data}} if exists $d->{data}; >> +- my $m = make_c_method $data->{name}, $d, {mode=>'cc_cxx', >> use_name=>true}, %$accum; >> ++ my $m = make_c_method $data->{name}, $d, {mode=>'cc_cxx', >> use_name=>true, wide=>$d->{wide}}, %$accum; >> + next unless defined $m; >> + $ret .= "extern \"C\" $m\n"; >> + $ret .= "{\n"; >> +@@ -57,24 +60,49 @@ $info{class}{proc}{impl} = sub { >> + } else { >> + if ($d->{type} eq 'method') { >> + my $ret_type = shift @parms; >> +- my $ret_native = to_type_name $ret_type, >> {mode=>'native_no_err', pos=>'return'}, %$accum; >> ++ my $ret_native = to_type_name $ret_type, >> {mode=>'native_no_err', pos=>'return', wide=>$d->{wide}}, %$accum; >> + my $snum = 0; >> ++ my $call_fun = $d->{name}; >> ++ my @call_parms; >> + foreach (@parms) { >> + my $n = to_lower($_->{name}); >> +- if ($_->{type} eq 'encoded string') { >> +- $accum->{headers}{'mutable string'} = true; >> +- $accum->{headers}{'convert'} = true; >> +- $ret .= " ths->temp_str_$snum.clear();\n"; >> +- $ret .= " ths->to_internal_->convert($n, ${n}_size, ths- >>> temp_str_$snum);\n"; >> +- $ret .= " unsigned int s$snum = ths- >>> temp_str_$snum.size();\n"; >> +- $_ = "MutableString(ths->temp_str_$snum.mstr(), s$snum)"; >> +- $snum++; >> ++ if ($_->{type} eq 'encoded string' && !exists($d->{'no >> conv'})) { >> ++ $need_wide = true unless $d->{wide}; >> ++ die unless exists $d->{'posib err'}; >> ++ $accum->{headers}{'mutable string'} = true; >> ++ $accum->{headers}{'convert'} = true; >> ++ my $name = get_c_func_name $data->{name}, $d, >> {mode=>'cc_cxx', use_name=>true, wide=>$d->{wide}}; >> ++ $ret .= " ths->temp_str_$snum.clear();\n"; >> ++ if ($d->{wide}) { >> ++ $ret .= " ${n}_size = get_correct_size(\"$name\", >> ths->to_internal_->in_type_width(), ${n}_size, ${n}_type_width);\n"; >> ++ } else { >> ++ $ret .= " PosibErr ${n}_fixed_size = >> get_correct_size(\"$name\", ths->to_internal_->in_type_width(), >> ${n}_size);\n"; >> ++ if (exists($d->{'on conv error'})) { >> ++ $ret .= " if (${n}_fixed_size.get_err()) {\n"; >> ++ $ret .= " ".$d->{'on conv error'}."\n"; >> ++ $ret .= " } else {\n"; >> ++ $ret .= " ${n}_size = ${n}_fixed_size;\n"; >> ++ $ret .= " }\n"; >> ++ } else { >> ++ $ret .= " ths- >>> err_.reset(${n}_fixed_size.release_err());\n"; >> ++ $ret .= " if (ths->err_ != 0) return >> ".(c_error_cond $ret_type).";\n"; >> ++ } >> ++ } >> ++ $ret .= " ths->to_internal_->convert($n, ${n}_size, >> ths->temp_str_$snum);\n"; >> ++ $ret .= " unsigned int s$snum = ths- >>> temp_str_$snum.size();\n"; >> ++ push @call_parms, "MutableString(ths- >>> temp_str_$snum.mstr(), s$snum)"; >> ++ $snum++; >> ++ } elsif ($_->{type} eq 'encoded string') { >> ++ $need_wide = true unless $d->{wide}; >> ++ push @call_parms, $n, "${n}_size"; >> ++ push @call_parms, "${n}_type_width" if $d->{wide}; >> ++ $call_fun .= " wide" if $d->{wide}; >> + } else { >> +- $_ = $n; >> ++ push @call_parms, $n; >> + } >> + } >> +- my $parms = '('.(join ', ', @parms).')'; >> +- my $exp = "ths->".to_lower($d->{name})."$parms"; >> ++ my $parms = '('.(join ', ', @call_parms).')'; >> ++ my $exp = "ths->".to_lower($call_fun)."$parms"; >> + if (exists $d->{'posib err'}) { >> + $accum->{headers}{'posib err'} = true; >> + $ret .= " PosibErr<$ret_native> ret = $exp;\n"; >> +@@ -118,6 +146,7 @@ $info{class}{proc}{impl} = sub { >> + } >> + } >> + $ret .= "}\n\n"; >> ++ unshift @d,{%$d, wide=>true} if $need_wide; >> + } >> + return $ret; >> + }; >> +diff --git a/auto/MkSrc/Read.pm b/auto/MkSrc/Read.pm >> +index 4b3d1d0..4bf640e 100644 >> +--- a/auto/MkSrc/Read.pm >> ++++ b/auto/MkSrc/Read.pm >> +@@ -88,13 +88,13 @@ sub advance ( ) { >> + $in_pod = $1 if $line =~ /^\=(\w+)/; >> + $line = '' if $in_pod; >> + $in_pod = undef if $in_pod && $in_pod eq 'cut'; >> +- $line =~ s/\#.*$//; >> ++ $line =~ s/(?> + $line =~ s/^(\t*)//; >> + $level = $base_level + length($1); >> + $line =~ s/\s*$//; >> + ++$base_level if $line =~ s/^\{$//; >> + --$base_level if $line =~ s/^\}$//; >> +- $line =~ s/\\([{}])/$1/g; >> ++ $line =~ s/\\([{}#\\])/$1/g; >> + } while ($line eq ''); >> + #print "$level:$line\n"; >> + } >> +diff --git a/auto/mk-src.in b/auto/mk-src.in >> +index 0e7833a..eb3353f 100644 >> +--- a/auto/mk-src.in >> ++++ b/auto/mk-src.in >> +@@ -608,6 +608,7 @@ errors: >> + invalid expression >> + mesg => "%expression" is not a valid regular >> expression. >> + parms => expression >> ++ >> + } >> + group: speller >> + { >> +@@ -650,6 +651,7 @@ class: speller >> + posib err >> + desc => Returns 0 if it is not in the dictionary, >> + 1 if it is, or -1 on error. >> ++ on conv error => return 0; >> + / >> + bool >> + encoded string: word >> +@@ -715,6 +717,8 @@ class: speller >> + desc => Return NULL on error. >> + The word list returned by suggest is only >> + valid until the next call to suggest. >> ++ on conv error => >> ++ word = NULL; word_size = 0; >> + / >> + const word list >> + encoded string: word >> +@@ -840,7 +844,6 @@ class: document checker >> + void >> + >> + method: process >> +- >> + desc => Process a string. >> + The string passed in should only be split on >> + white space characters. Furthermore, between >> +@@ -849,10 +852,10 @@ class: document checker >> + in the document. Passing in strings out of >> + order, skipping strings or passing them in >> + more than once may lead to undefined results. >> ++ no conv >> + / >> + void >> +- string: str >> +- int: size >> ++ encoded string: str >> + >> + method: next misspelling >> + >> +@@ -860,9 +863,23 @@ class: document checker >> + processed string. If there are no more >> + misspelled words, then token.word will be >> + NULL and token.size will be 0 >> ++ cc extra => >> ++ \#define >> aspell_document_checker_next_misspelling_w(type, ths) \\ >> ++ aspell_document_checker_next_misspelling_ad >> j(ths, sizeof(type)) >> + / >> + token object >> + >> ++ method: next misspelling adj >> ++ desc => internal: do not use >> ++ c impl => >> ++ Token res = ths->next_misspelling(); >> ++ res.offset /= type_width; >> ++ res.len /= type_width; >> ++ return res; >> ++ / >> ++ token object >> ++ int: type_width >> ++ >> + method: filter >> + >> + desc => Returns the underlying filter class. >> +@@ -922,9 +939,30 @@ class: string enumeration >> + ths->from_internal_->append_null(ths- >>> temp_str); >> + return ths->temp_str.data(); >> + \} >> ++ cc extra => >> ++ \#define aspell_string_enumeration_next_w(type, >> ths) \\ >> ++ aspell_cast_(const type *, >> aspell_string_enumeration_next_wide(ths, sizeof(type))) >> + / >> + const string >> + >> ++ method: next wide >> ++ c impl => >> ++ const char * s = ths->next(); >> ++ if (s == 0) { >> ++ return s; >> ++ } else if (ths->from_internal_ == 0) \{ >> ++ assert(type_width == 1); >> ++ return s; >> ++ \} else \{ >> ++ assert(type_width == ths->from_internal_- >>> out_type_width()); >> ++ ths->temp_str.clear(); >> ++ ths->from_internal_->convert(s,-1,ths- >>> temp_str); >> ++ ths->from_internal_->append_null(ths- >>> temp_str); >> ++ return ths->temp_str.data(); >> ++ \} >> ++ / >> ++ const void pointer >> ++ int: type_width >> + } >> + group: info >> + { >> +diff --git a/common/convert.cpp b/common/convert.cpp >> +index 1add95a..7ae0317 100644 >> +--- a/common/convert.cpp >> ++++ b/common/convert.cpp >> +@@ -541,18 +541,25 @@ namespace acommon { >> + // Trivial Conversion >> + // >> + >> ++ const char * unsupported_null_term_wide_string_msg = >> ++ "Null-terminated wide-character strings unsupported when used >> this way."; >> ++ >> + template >> + struct DecodeDirect : public Decode >> + { >> ++ DecodeDirect() {type_width = sizeof(Chr);} >> + void decode(const char * in0, int size, FilterCharVector & out) >> const { >> + const Chr * in = reinterpret_cast(in0); >> +- if (size == -1) { >> ++ if (size == -sizeof(Chr)) { >> + for (;*in; ++in) >> +- out.append(*in); >> ++ out.append(*in, sizeof(Chr)); >> ++ } else if (size <= -1) { >> ++ fprintf(stderr, "%s\n", >> unsupported_null_term_wide_string_msg); >> ++ abort(); >> + } else { >> +- const Chr * stop = reinterpret_cast(in0 >> +size); >> ++ const Chr * stop = reinterpret_cast(in0) + >> size/sizeof(Chr); >> + for (;in != stop; ++in) >> +- out.append(*in); >> ++ out.append(*in, sizeof(Chr)); >> + } >> + } >> + PosibErr decode_ec(const char * in0, int size, >> +@@ -565,6 +572,7 @@ namespace acommon { >> + template >> + struct EncodeDirect : public Encode >> + { >> ++ EncodeDirect() {type_width = sizeof(Chr);} >> + void encode(const FilterChar * in, const FilterChar * stop, >> + CharVector & out) const { >> + for (; in != stop; ++in) { >> +@@ -594,11 +602,15 @@ namespace acommon { >> + template >> + struct ConvDirect : public DirectConv >> + { >> ++ ConvDirect() {type_width = sizeof(Chr);} >> + void convert(const char * in0, int size, CharVector & out) >> const { >> +- if (size == -1) { >> ++ if (size == -sizeof(Chr)) { >> + const Chr * in = reinterpret_cast(in0); >> + for (;*in != 0; ++in) >> + out.append(in, sizeof(Chr)); >> ++ } else if (size <= -1) { >> ++ fprintf(stderr, "%s\n", >> unsupported_null_term_wide_string_msg); >> ++ abort(); >> + } else { >> + out.append(in0, size); >> + } >> +@@ -1121,5 +1133,20 @@ namespace acommon { >> + } >> + return 0; >> + } >> +- >> ++ >> ++ PosibErr unsupported_null_term_wide_string_err_(const char >> * func) { >> ++ static bool reported_to_stderr = false; >> ++ PosibErr err = make_err(other_error, >> unsupported_null_term_wide_string_msg); >> ++ if (!reported_to_stderr) { >> ++ CERR.printf("ERROR: %s: %s\n", func, >> unsupported_null_term_wide_string_msg); >> ++ reported_to_stderr = true; >> ++ } >> ++ return err; >> ++ } >> ++ >> ++ void unsupported_null_term_wide_string_abort_(const char * func) >> { >> ++ CERR.printf("%s: %s\n", unsupported_null_term_wide_string_msg); >> ++ abort(); >> ++ } >> ++ >> + } >> +diff --git a/common/convert.hpp b/common/convert.hpp >> +index 76332ee..c948973 100644 >> +--- a/common/convert.hpp >> ++++ b/common/convert.hpp >> +@@ -7,6 +7,8 @@ >> + #ifndef ASPELL_CONVERT__HPP >> + #define ASPELL_CONVERT__HPP >> + >> ++#include "settings.h" >> ++ >> + #include "string.hpp" >> + #include "posib_err.hpp" >> + #include "char_vector.hpp" >> +@@ -25,8 +27,9 @@ namespace acommon { >> + typedef const Config CacheConfig; >> + typedef const char * CacheKey; >> + String key; >> ++ int type_width; // type width in bytes >> + bool cache_key_eq(const char * l) const {return key == l;} >> +- ConvBase() {} >> ++ ConvBase() : type_width(1) {} >> + private: >> + ConvBase(const ConvBase &); >> + void operator=(const ConvBase &); >> +@@ -56,6 +59,8 @@ namespace acommon { >> + virtual ~Encode() {} >> + }; >> + struct DirectConv { // convert directly from in_code to out_code. >> ++ int type_width; // type width in bytes >> ++ DirectConv() : type_width(1) {} >> + // should not take ownership of decode and encode. >> + // decode and encode guaranteed to stick around for the life >> + // of the object. >> +@@ -126,6 +131,9 @@ namespace acommon { >> + const char * in_code() const {return decode_->key.c_str();} >> + const char * out_code() const {return encode_->key.c_str();} >> + >> ++ int in_type_width() const {return decode_->type_width;} >> ++ int out_type_width() const {return encode_->type_width;} >> ++ >> + void append_null(CharVector & out) const >> + { >> + const char nul[4] = {0,0,0,0}; // 4 should be enough >> +@@ -191,6 +199,10 @@ namespace acommon { >> + } >> + } >> + >> ++ void convert(const void * in, int size, CharVector & out) { >> ++ convert(static_cast(in), size, out); >> ++ } >> ++ >> + void generic_convert(const char * in, int size, CharVector & >> out); >> + >> + }; >> +@@ -412,6 +424,30 @@ namespace acommon { >> + return operator()(str, str + byte_size);} >> + }; >> + >> ++#ifdef SLOPPY_NULL_TERM_STRINGS >> ++ static const bool sloppy_null_term_strings = true; >> ++#else >> ++ static const bool sloppy_null_term_strings = false; >> ++#endif >> ++ >> ++ PosibErr unsupported_null_term_wide_string_err_(const char >> * func); >> ++ void unsupported_null_term_wide_string_abort_(const char * func); >> ++ >> ++ static inline PosibErr get_correct_size(const char * func, >> int conv_type_width, int size) { >> ++ if (sloppy_null_term_strings && size <= -1) >> ++ return -conv_type_width; >> ++ if (size <= -1 && -conv_type_width != size) >> ++ return unsupported_null_term_wide_string_err_(func); >> ++ return size; >> ++ } >> ++ static inline int get_correct_size(const char * func, int >> conv_type_width, int size, int type_width) { >> ++ if ((sloppy_null_term_strings || type_width <= -1) && size <= >> -1) >> ++ return -conv_type_width; >> ++ if (size <= -1 && conv_type_width != type_width) >> ++ unsupported_null_term_wide_string_abort_(func); >> ++ return size; >> ++ } >> ++ >> + } >> + >> + #endif >> +diff --git a/common/document_checker.cpp >> b/common/document_checker.cpp >> +index 5e510c4..0ccf1cd 100644 >> +--- a/common/document_checker.cpp >> ++++ b/common/document_checker.cpp >> +@@ -44,7 +44,9 @@ namespace acommon { >> + void DocumentChecker::process(const char * str, int size) >> + { >> + proc_str_.clear(); >> +- conv_->decode(str, size, proc_str_); >> ++ PosibErr fixed_size = >> get_correct_size("aspell_document_checker_process", conv_- >>> in_type_width(), size); >> ++ if (!fixed_size.has_err()) >> ++ conv_->decode(str, fixed_size, proc_str_); >> + proc_str_.append(0); >> + FilterChar * begin = proc_str_.pbegin(); >> + FilterChar * end = proc_str_.pend() - 1; >> +@@ -53,6 +55,19 @@ namespace acommon { >> + tokenizer_->reset(begin, end); >> + } >> + >> ++ void DocumentChecker::process_wide(const void * str, int size, >> int type_width) >> ++ { >> ++ proc_str_.clear(); >> ++ int fixed_size = >> get_correct_size("aspell_document_checker_process", conv_- >>> in_type_width(), size, type_width); >> ++ conv_->decode(static_cast(str), fixed_size, >> proc_str_); >> ++ proc_str_.append(0); >> ++ FilterChar * begin = proc_str_.pbegin(); >> ++ FilterChar * end = proc_str_.pend() - 1; >> ++ if (filter_) >> ++ filter_->process(begin, end); >> ++ tokenizer_->reset(begin, end); >> ++ } >> ++ >> + Token DocumentChecker::next_misspelling() >> + { >> + bool correct; >> +diff --git a/common/document_checker.hpp >> b/common/document_checker.hpp >> +index d35bb88..11a3c73 100644 >> +--- a/common/document_checker.hpp >> ++++ b/common/document_checker.hpp >> +@@ -36,6 +36,7 @@ namespace acommon { >> + PosibErr setup(Tokenizer *, Speller *, Filter *); >> + void reset(); >> + void process(const char * str, int size); >> ++ void process_wide(const void * str, int size, int type_width); >> + Token next_misspelling(); >> + >> + Filter * filter() {return filter_;} >> +diff --git a/common/version.cpp b/common/version.cpp >> +index 414d938..9e60b75 100644 >> +--- a/common/version.cpp >> ++++ b/common/version.cpp >> +@@ -1,8 +1,17 @@ >> + #include "settings.h" >> + >> +-extern "C" const char * aspell_version_string() { >> + #ifdef NDEBUG >> +- return VERSION " NDEBUG"; >> ++# define NDEBUG_STR " NDEBUG" >> ++#else >> ++# define NDEBUG_STR >> ++#endif >> ++ >> ++#ifdef SLOPPY_NULL_TERM_STRINGS >> ++# define SLOPPY_STR " SLOPPY" >> ++#else >> ++# define SLOPPY_STR >> + #endif >> +- return VERSION; >> ++ >> ++extern "C" const char * aspell_version_string() { >> ++ return VERSION NDEBUG_STR SLOPPY_STR; >> + } >> +diff --git a/configure.ac b/configure.ac >> +index 60e3b39..a5d51e3 100644 >> +--- a/configure.ac >> ++++ b/configure.ac >> +@@ -73,6 +73,9 @@ AC_ARG_ENABLE(filter-version-control, >> + AC_ARG_ENABLE(32-bit-hash-fun, >> + AS_HELP_STRING([--enable-32-bit-hash-fun],[use 32-bit hash >> function for compiled dictionaries])) >> + >> ++AC_ARG_ENABLE(sloppy-null-term-strings, >> ++ AS_HELP_STRING([--enable-sloppy-null-term-strings],[allows allow >> null terminated UCS-2 and UCS-4 strings])) >> ++ >> + AC_ARG_ENABLE(pspell-compatibility, >> + AS_HELP_STRING([--disable-pspell-compatibility],[don't install >> pspell compatibility libraries])) >> + >> +@@ -141,6 +144,11 @@ then >> + AC_DEFINE(USE_32_BIT_HASH_FUN, 1, [Defined if 32-bit hash >> function should be used for compiled dictionaries.]) >> + fi >> + >> ++if test "$enable_sloppy_null_term_strings" = "yes" >> ++then >> ++ AC_DEFINE(SLOPPY_NULL_TERM_STRINGS, 1, [Defined if null- >> terminated UCS-2 and UCS-4 strings should always be allowed.]) >> ++fi >> ++ >> + AM_CONDITIONAL(PSPELL_COMPATIBILITY, >> + [test "$enable_pspell_compatibility" != "no"]) >> + AM_CONDITIONAL(INCREMENTED_SONAME, >> +diff --git a/manual/aspell.texi b/manual/aspell.texi >> +index 45fa091..f400e06 100644 >> +--- a/manual/aspell.texi >> ++++ b/manual/aspell.texi >> +@@ -158,7 +158,8 @@ Installing >> + >> + * Generic Install Instructions:: >> + * HTML Manuals and "make clean":: >> +-* Curses Notes:: >> ++* Curses Notes:: >> ++* Upgrading from Aspell 0.60.7:: >> + * Loadable Filter Notes:: >> + * Upgrading from Aspell 0.50:: >> + * Upgrading from Aspell .33/Pspell .12:: >> +@@ -2206,18 +2207,26 @@ int correct = >> aspell_speller_check(spell_checker, @var{word}, @var{size}); >> + @end smallexample >> + >> + @noindent >> +- at var{word} is expected to be a @code{const char *} character >> +-string. If the encoding is set to be @code{ucs-2} or >> +- at code{ucs-4} @var{word} is expected to be a cast >> +-from either @code{const u16int *} or @code{const u32int *} >> +-respectively. @code{u16int} and @code{u32int} are generally >> +- at code{unsigned short} and @code{unsigned int} respectively. >> +- at var{size} is the length of the string or @code{-1} if the string >> +-is null terminated. If the string is a cast from @code{const >> u16int >> +-*} or @code{const u32int *} then @code{@i{size}} is the amount of >> +-space in bytes the string takes up after being cast to @code{const >> +-char *} and not the true size of the >> string. @code{sspell_speller_check} >> +-will return @code{0} if it is not found and non-zero otherwise. >> ++ at var{word} is expected to be a @code{const char *} character >> string. >> ++ at var{size} is the length of the string or @code{-1} if the string >> is >> ++null terminated. @code{aspell_speller_check} will return @code{0} >> if it is not found >> ++and non-zero otherwise. >> ++ >> ++If you are using the @code{ucs-2} or @code{ucs-4} encoding then the >> ++string is expected to be either a 2 or 4 byte wide integer >> ++(respectively) and the @code{_w} macro vesion should be used: >> ++ >> ++ at smallexample >> ++int correct = aspell_speller_check_w(spell_checker, @var{word}, >> @var{size}); >> ++ at end smallexample >> ++ >> ++The macro will cast the string to to the correct type and convert >> ++ at var{size} into bytes for you and then a call the special wide >> version of the >> ++function that will make sure the encoding is correct for the type >> ++passed in. For compatibility with older versions of Aspell the >> normal >> ++non-wide functions can still be used provided that the size of the >> ++string, in bytes, is also passed in. Null terminated @code{ucs-2} >> or >> ++ at code{ucs-4} are no longer supported when using the non-wide >> functions. >> + >> + If the word is not correct, then the @code{suggest} method can be >> used >> + to come up with likely replacements. >> +@@ -2236,7 +2245,28 @@ delete_aspell_string_enumeration(elements); >> + >> + Notice how @code{elements} is deleted but @code{suggestions} is >> not. >> + The value returned by @code{suggestions} is only valid to the next >> +-call to @code{suggest}. Once a replacement is made the >> ++call to @code{suggest}. >> ++ >> ++If you are using the @code{ucs-2} or @code{ucs-4} encoding then, in >> ++addition to using the @code{_w} macro for the @code{suggest} >> method, you >> ++should also use the @code{_w} macro with the @code{next} method >> which >> ++will cast the string to the correct type for you. For example, if >> you >> ++are using the @code{ucs-2} encoding and the string is a @code{const >> ++uint16_t *} then you should use: >> ++ >> ++ at smallexample >> ++AspellWordList * suggestions = >> aspell_speller_suggest_w(spell_checker, >> ++ @var{word}, >> @var{size}); >> ++AspellStringEnumeration * elements = >> aspell_word_list_elements(suggestions); >> ++const uint16_t * word; >> ++while ( (word = aspell_string_enumeration_next_w(uint16_t, >> aspell_elements)) != NULL ) >> ++@{ >> ++ // add to suggestion list >> ++@} >> ++delete_aspell_string_enumeration(elements); >> ++ at end smallexample >> ++ >> ++Once a replacement is made the >> + @code{store_repl} method should be used to communicate the >> replacement >> + pair back to the spell checker (for the reason, @pxref{Notes on >> + Storing Replacement Pairs}). Its usage is as follows: >> +diff --git a/manual/readme.texi b/manual/readme.texi >> +index 669ab8e..531721f 100644 >> +--- a/manual/readme.texi >> ++++ b/manual/readme.texi >> +@@ -15,15 +15,16 @@ The latest version can always be found at GNU >> Aspell's home page at >> + @uref{http://aspell.net}. >> + >> + @menu >> +-* Generic Install Instructions:: >> +-* HTML Manuals and "make clean":: >> +-* Curses Notes:: >> +-* Loadable Filter Notes:: >> +-* Using 32-Bit Dictionaries on a 64-Bit System:: >> +-* Upgrading from Aspell 0.50:: >> +-* Upgrading from Aspell .33/Pspell .12:: >> +-* Upgrading from a Pre-0.50 snapshot:: >> +-* WIN32 Notes:: >> ++* Generic Install Instructions:: >> ++* HTML Manuals and "make clean":: >> ++* Curses Notes:: >> ++* Upgrading from Aspell 0.60.7:: >> ++* Loadable Filter Notes:: >> ++* Using 32-Bit Dictionaries on a 64-Bit System:: >> ++* Upgrading from Aspell 0.50:: >> ++* Upgrading from Aspell .33/Pspell .12:: >> ++* Upgrading from a Pre-0.50 snapshot:: >> ++* WIN32 Notes:: >> + @end menu >> + >> + @node Generic Install Instructions >> +@@ -121,17 +122,62 @@ In addition your system must also support the >> @code{mblen} function. >> + Although this function was defined in the ISO C89 standard (ANSI >> + X3.159-1989), not all systems have it. >> + >> ++ at node Upgrading from Aspell 0.60.7 >> ++ at appendixsec Upgrading from Aspell 0.60.7 >> ++ >> ++To prevent a potentially unbounded buffer over-read, Aspell no >> longer >> ++supports null-terminated UCS-2 and UCS-4 encoded strings with the >> ++original C API. Null-termianted 8-bit or UTF-8 encoded strings are >> ++still supported, as are UCS-2 and UCS-4 encoded strings when the >> ++length is passed in. >> ++ >> ++As of Aspell 0.60.8 a function from the original API that expects >> an >> ++encoded string as a parameter will return meaningless results (or >> an >> ++error code) if string is null terminated and the encoding is set to >> ++ at code{ucs-2} or @code{ucs-4}. In addition, a single: >> ++ at example >> ++ERROR: aspell_speller_check: Null-terminated wide-character strings >> unsupported when used this way. >> ++ at end example >> ++will be printed to standard error the first time one of those >> ++functions is called. >> ++ >> ++Application that use null-terminated UCS-2/4 strings should either >> (1) >> ++use the interface intended for working with wide-characters >> ++(@xref{Through the C API}); or (2) define >> ++ at code{ASPELL_ENCODE_SETTING_SECURE} before including >> @code{aspell.h}. >> ++In the latter case is is important that the application explicitly >> ++sets the encoding to a known value. Defining >> ++ at code{ASPELL_ENCODE_SETTING_SECURE} and not setting the encoding >> ++explicitly or allowing user of the application to set the encoding >> ++could result in an unbounded buffer over-read. >> ++ >> ++If it is necessary to preserve binary compatibility with older >> ++versions of Aspell, the easiest thing would be to determine the >> length >> ++of the UCS-2/4 string---in bytes---and pass that in. Due to an >> ++implemenation detail, existing API functions can be made to work >> with >> ++null-terminated UCS-2/4 strings safely by passing in either @code{- >> 2} >> ++or @code{-4} (corresponding to the width of the character type) as >> the >> ++size. Doing so, however, will cause a buffer over-read for >> unpatched >> ++version of Aspell. To avoid this it will be necessary to parse the >> ++version string to determine the correct value to use. However, no >> ++official support will be provided for the latter method. >> ++ >> ++If the application can not be recompiled, then Aspell can be >> configured >> ++to preserve the old behavior by passing >> ++ at option{--enable-sloppy-null-term-strings} to >> @command{configure}. When Aspell >> ++is compiled this way the version string will include the string >> ++ at samp{ SLOPPY}. >> ++ >> + @node Loadable Filter Notes >> + @appendixsec Loadable Filter Notes >> +- >> ++ >> + Support for being able to load additional filter modules at run- >> time >> + has only been verified to work on Linux platforms. If you get >> linker >> + errors when trying to use a filter, then it is likely that loadable >> + filter support is not working yet on your platform. Thus, in order >> to >> + get Aspell to work correctly you will need to avoid compiling the >> + filters as individual modules by using the >> +- at option{--enable-compile-in-filters} when configuring Aspell with >> +- at command{./configure}. >> ++ at option{--enable-compile-in-filters} @command{configure} option. >> + >> + @node Using 32-Bit Dictionaries on a 64-Bit System >> + @appendixsec Using 32-Bit Dictionaries on a 64-Bit System >> +-- >> +2.17.1 >> + >> diff --git a/meta/recipes-support/aspell/aspell/CVE-2019-20433- >> 0002.patch b/meta/recipes-support/aspell/aspell/CVE-2019-20433- >> 0002.patch >> new file mode 100644 >> index 0000000000..9569ddeebe >> --- /dev/null >> +++ b/meta/recipes-support/aspell/aspell/CVE-2019-20433-0002.patch >> @@ -0,0 +1,68 @@ >> +From cefd447e5528b08bb0cd6656bc52b4255692cefc Mon Sep 17 00:00:00 >> 2001 >> +From: Kevin Atkinson >> +Date: Sat, 17 Aug 2019 20:25:21 -0400 >> +Subject: [PATCH 2/2] Increment library version to reflect API >> changes. >> + >> +CVE: CVE-2019-20433 >> +Upstream-Status: Backport [ >> https://github.com/GNUAspell/aspell/commit/cefd447e5528b08bb0cd6656bc52b4255692cefc >> ] >> + >> +Signed-off-by: Stefan Ghinea >> +--- >> + Makefile.am | 31 +++++++++++++++++-------------- >> + 1 file changed, 17 insertions(+), 14 deletions(-) >> + >> +diff --git a/Makefile.am b/Makefile.am >> +index 7e15851..19dc044 100644 >> +--- a/Makefile.am >> ++++ b/Makefile.am >> +@@ -94,18 +94,25 @@ libaspell_la_SOURCES =\ >> + >> + libaspell_la_LIBADD = $(LTLIBINTL) $(PTHREAD_LIB) >> + >> +-## Libtool to so name >> +-## C:R:A => (C-A).(A).(R) >> +-## 16:5:0 => 16.0.5 >> +-## 16:5:1 => 15.1.5 >> +-## 18:0:2 => 16.2.0 >> +-## 17:0:2 => 15.2.0 >> +- >> ++## The version string is current[:revision[:age]] >> ++## >> ++## Before a release that has changed the source code at all >> ++## increment revision. >> ++## >> ++## After merging changes that have changed the API in a backwards >> ++## comptable way set revision to 0 and bump both current and age. >> ++## >> ++## Do not change the API in a backwards incompatible way. >> ++## >> ++## See "Libtool: Updating version info" >> ++## ( >> https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html >> ) >> ++## for more into >> ++## >> + if INCREMENTED_SONAME >> +-libaspell_la_LDFLAGS = -version-info 18:0:2 -no-undefined >> ++libaspell_la_LDFLAGS = -version-info 19:0:3 -no-undefined >> + else >> + ## Use C-1:R:A >> +-libaspell_la_LDFLAGS = -version-info 17:0:2 -no-undefined >> ++libaspell_la_LDFLAGS = -version-info 18:0:3 -no-undefined >> + endif >> + >> + if PSPELL_COMPATIBILITY >> +@@ -113,11 +120,7 @@ libpspell_la_SOURCES = lib/dummy.cpp >> + >> + libpspell_la_LIBADD = libaspell.la >> + >> +-if INCREMENTED_SONAME >> +-libpspell_la_LDFLAGS = -version-info 18:0:2 -no-undefined >> +-else >> +-libpspell_la_LDFLAGS = -version-info 17:0:2 -no-undefined >> +-endif >> ++libpspell_la_LDFLAGS = $(libaspell_la_LDFLAGS) >> + >> + endif >> + >> +-- >> +2.17.1 >> + >> diff --git a/meta/recipes-support/aspell/aspell_0.60.7.bb >> b/meta/recipes-support/aspell/aspell_0.60.7.bb >> index b565cb3c6e..1e104c263c 100644 >> --- a/meta/recipes-support/aspell/aspell_0.60.7.bb >> +++ b/meta/recipes-support/aspell/aspell_0.60.7.bb >> @@ -8,6 +8,8 @@ PR = "r1" >> >> SRC_URI = "${GNU_MIRROR}/aspell/aspell-${PV}.tar.gz \ >> file://0001-Fix-various-bugs-found-by-OSS-Fuze.patch \ >> + file://CVE-2019-20433-0001.patch \ >> + file://CVE-2019-20433-0002.patch \ >> " >> SRC_URI[md5sum] = "8ef2252609c511cd2bb26f3a3932ef28" >> SRC_URI[sha256sum] = >> "5ca8fc8cb0370cc6c9eb5b64c6d1bc5d57b3750dbf17887726c3407d833b70e4" >> -- >> 2.17.1 >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpuhlman at mvista.com Thu Mar 12 14:36:42 2020 From: jpuhlman at mvista.com (Jeremy A. Puhlman) Date: Thu, 12 Mar 2020 07:36:42 -0700 Subject: [OE-core] [PATCH 1/2] babletrace2: make manpages multilib identical In-Reply-To: <20200312142524.GB30953@joraj-alpa> References: <20200311222249.29880-1-jpuhlman@mvista.com> <20200312142524.GB30953@joraj-alpa> Message-ID: <8c0b99cd-8a2e-c4f0-8be1-a91b0fbf9699@mvista.com> Maybe. They may want it to be altered depending on their preference for how to express the system libdir. I have pushed similar to other projects and gotten a mixed bag of responses. I haven't tried to push it yet, but its in my queue. On 3/12/2020 7:25 AM, Jonathan Rajotte-Julien wrote: > Hi > > Is this something upstream (lttng-dev mailing list) should be interested in? > > Cheers > > On Wed, Mar 11, 2020 at 03:22:48PM -0700, Jeremy A. Puhlman wrote: >> From: Jeremy Puhlman >> >> Signed-off-by: Jeremy A. Puhlman >> --- >> .../0001-Make-manpages-multilib-identical.patch | 28 ++++++++++++++++++++++ >> meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb | 1 + >> 2 files changed, 29 insertions(+) >> create mode 100644 meta/recipes-kernel/lttng/babeltrace2/0001-Make-manpages-multilib-identical.patch >> >> diff --git a/meta/recipes-kernel/lttng/babeltrace2/0001-Make-manpages-multilib-identical.patch b/meta/recipes-kernel/lttng/babeltrace2/0001-Make-manpages-multilib-identical.patch >> new file mode 100644 >> index 0000000000..2401b176e6 >> --- /dev/null >> +++ b/meta/recipes-kernel/lttng/babeltrace2/0001-Make-manpages-multilib-identical.patch >> @@ -0,0 +1,28 @@ >> +From 56986190e4b0c10945ce6aaa7ca10d6bd8a26a39 Mon Sep 17 00:00:00 2001 >> +From: Jeremy Puhlman >> +Date: Mon, 9 Mar 2020 21:10:35 +0000 >> +Subject: [PATCH] Make manpages multilib identical >> + >> +Upstream-Status: Pending >> +Signed-off-by: Jeremy Puhlman >> +--- >> + doc/man/asciidoc-attrs.conf.in | 4 ++-- >> + 1 file changed, 2 insertions(+), 2 deletions(-) >> + >> +diff --git a/doc/man/asciidoc-attrs.conf.in b/doc/man/asciidoc-attrs.conf.in >> +index ad1183f1..e11c7031 100644 >> +--- a/doc/man/asciidoc-attrs.conf.in >> ++++ b/doc/man/asciidoc-attrs.conf.in >> +@@ -1,7 +1,7 @@ >> + [attributes] >> + # default values >> +-system_plugin_path="@LIBDIR@/babeltrace2/plugins" >> +-system_plugin_provider_path="@LIBDIR@/babeltrace2/plugin-providers" >> ++system_plugin_path="@prefix@/lib*/babeltrace2/plugins" >> ++system_plugin_provider_path="@prefix@/lib*/babeltrace2/plugin-providers" >> + babeltrace_version="@PACKAGE_VERSION@" >> + enable_debug_info="@ENABLE_DEBUG_INFO_VAL@" >> + defrdport=5344 >> +-- >> +2.24.1 >> + >> diff --git a/meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb b/meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb >> index 16953d6807..61bc7f5e6b 100644 >> --- a/meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb >> +++ b/meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb >> @@ -10,6 +10,7 @@ DEPENDS = "glib-2.0 util-linux popt bison-native flex-native" >> SRC_URI = "git://git.linuxfoundation.org/diamon/babeltrace.git;branch=stable-2.0 \ >> file://run-ptest \ >> file://0001-tests-do-not-run-test-applications-from-.libs.patch \ >> + file://0001-Make-manpages-multilib-identical.patch \ >> " >> SRCREV = "06df58f89ee51b1a2c6a2c187ec3f15691633910" >> UPSTREAM_CHECK_GITTAGREGEX = "v(?P2(\.\d+)+)$" >> -- >> 2.13.3 >> >> -- >> _______________________________________________ >> Openembedded-core mailing list >> Openembedded-core at lists.openembedded.org >> http://lists.openembedded.org/mailman/listinfo/openembedded-core -- Jeremy A. Puhlman jpuhlman at mvista.com From quentin.schulz at streamunlimited.com Thu Mar 12 14:42:26 2020 From: quentin.schulz at streamunlimited.com (Quentin Schulz) Date: Thu, 12 Mar 2020 15:42:26 +0100 Subject: [OE-core] simplest command to display which layers are applying the same patch? In-Reply-To: <20200312103003.Horde.-mn1W9NE8YAc6sk0SRLY8bj@crashcourse.ca> References: <20200312085608.Horde.kbPh9KWkZJR4Zi-lry-_TrN@crashcourse.ca> <20200312103003.Horde.-mn1W9NE8YAc6sk0SRLY8bj@crashcourse.ca> Message-ID: <20200312144226.7adjcwooxip2rj3d@qschulz> Hi, On Thu, Mar 12, 2020 at 10:30:03AM -0400, rpjday at crashcourse.ca wrote: > > Quoting Alexander Kanavin : > > > I think 'bitbake -e recipe', and then searching for SRC_URI in it should > > show which layer applies which patch. > > ... snip ... > > I *think* I know what might be happening here, and I'd like to verify > some suspicions about how recipes are selected and patches are applied. > (Writing this in real time so I hope I don't screw up.) > > Imagine I've checked out oe-core, which supplies recipe file fubar_1.0.bb, > but it becomes obvious that there is a bug, for which there is an obvious > patch I can apply internally. So I fire up a fubar bbappend file, which > does nothing but extend SRC_URI to apply the patch, call it fubar.patch. > (Remember, this patching is all internal, in my vendor layer.) > > *However*, being a bit lazy, rather than create fubar_1.0.bbappend, I > slack off and create simply fubar_1.%.bbappend. (I suspect you see > where I'm going with this.) > > Now the good folks at OE get around to updating oe-core, and part of > that update is to add that patch to SRC_URI of fubar_1.1.bb (along > with the patch file fubar.patch, of course). Now, because that is > a more recent version of fubar, that is the recipe file that should > be selected. > > *However*, if I interpret this correctly, first, I have fubar_1.1.bb > applying fubar.patch, but because I am also defining a layer which > contains the append file fubar_1.%.bbappend, that append file will > also try to apply the same patch, which of course should not work > properly. (Am I correct in my thinking so far?) > AFAIK, yes. > If I'm explaining this correctly, then the fault naturally lies with > me for being sloppily ambiguous with my append file and not locking > it to fubar_1.0, but allowing it to be applied against all fubar_1.x > recipes. In short, when I inevitably get the error of "Patch already > applied," it is entirely my fault for being sloppy. > > I'm trying to verify this as I am now aware that a *lot* of append > files in the vendor layer in question are similarly ambiguous. > Does this make sense? > AFAIK, yes. I think you can check on which recipe a bbappend applies with: bitbake-layers show-appends . Don't forget to set the machine correctly because if your recipe has a MACHINE_COMPATIBLE which does not contain your machine, your recipe is "silently" omitted. If you ommit the recipe from the aforementioned command, you'll get all appends for all recipes (and you can see some are marked as "skipped" even though they are listed). Hope this helps. Quentin From schnitzeltony at gmail.com Thu Mar 12 14:43:31 2020 From: schnitzeltony at gmail.com (=?UTF-8?q?Andreas=20M=C3=BCller?=) Date: Thu, 12 Mar 2020 15:43:31 +0100 Subject: [OE-core] [PATCH] libsdl2: upgrade 2.0.10 -> 2.0.12 Message-ID: <20200312144331.6334-1-schnitzeltony@gmail.com> * checked all hunks: backported patches can go * for machines with neon in TUNE_FEATURES enable new configure option --enable-arm-neon. If enabled, license must be extended to MIT * license checksum changed by copyright year Signed-off-by: Andreas M?ller --- ...alidate-image-size-when-loading-BMP-.patch | 34 ------------ ...for-build-dir-when-building-version-.patch | 53 ------------------- ...DL-fails-to-compile-with-Mesa-Master.patch | 41 -------------- .../{libsdl2_2.0.10.bb => libsdl2_2.0.12.bb} | 15 +++--- 4 files changed, 9 insertions(+), 134 deletions(-) delete mode 100644 meta/recipes-graphics/libsdl2/libsdl2/0001-Fixed-bug-4538-validate-image-size-when-loading-BMP-.patch delete mode 100644 meta/recipes-graphics/libsdl2/libsdl2/0001-configure-check-for-build-dir-when-building-version-.patch delete mode 100644 meta/recipes-graphics/libsdl2/libsdl2/0002-Fixed-bug-4797-SDL-fails-to-compile-with-Mesa-Master.patch rename meta/recipes-graphics/libsdl2/{libsdl2_2.0.10.bb => libsdl2_2.0.12.bb} (81%) diff --git a/meta/recipes-graphics/libsdl2/libsdl2/0001-Fixed-bug-4538-validate-image-size-when-loading-BMP-.patch b/meta/recipes-graphics/libsdl2/libsdl2/0001-Fixed-bug-4538-validate-image-size-when-loading-BMP-.patch deleted file mode 100644 index 674decccbb..0000000000 --- a/meta/recipes-graphics/libsdl2/libsdl2/0001-Fixed-bug-4538-validate-image-size-when-loading-BMP-.patch +++ /dev/null @@ -1,34 +0,0 @@ -From 85138c1ec673e05263ae666baf61f79384daf7e0 Mon Sep 17 00:00:00 2001 -From: Sam Lantinga -Date: Tue, 30 Jul 2019 11:00:00 -0700 -Subject: [PATCH] Fixed bug 4538 - validate image size when loading BMP files - -Upstream-Status: Backport -[https://hg.libsdl.org/SDL/rev/e7ba650a643a] - -CVE: CVE-2019-13616 - -Signed-off-by: Yi Zhao ---- - src/video/SDL_bmp.c | 5 +++++ - 1 file changed, 5 insertions(+) - -diff --git a/src/video/SDL_bmp.c b/src/video/SDL_bmp.c -index 0b68918..a06b0c9 100644 ---- a/src/video/SDL_bmp.c -+++ b/src/video/SDL_bmp.c -@@ -226,6 +226,11 @@ SDL_LoadBMP_RW(SDL_RWops * src, int freesrc) - SDL_RWseek(src, (biSize - headerSize), RW_SEEK_CUR); - } - } -+ if (biWidth <= 0 || biHeight == 0) { -+ SDL_SetError("BMP file with bad dimensions (%dx%d)", biWidth, biHeight); -+ was_error = SDL_TRUE; -+ goto done; -+ } - if (biHeight < 0) { - topDown = SDL_TRUE; - biHeight = -biHeight; --- -2.7.4 - diff --git a/meta/recipes-graphics/libsdl2/libsdl2/0001-configure-check-for-build-dir-when-building-version-.patch b/meta/recipes-graphics/libsdl2/libsdl2/0001-configure-check-for-build-dir-when-building-version-.patch deleted file mode 100644 index b383bd6548..0000000000 --- a/meta/recipes-graphics/libsdl2/libsdl2/0001-configure-check-for-build-dir-when-building-version-.patch +++ /dev/null @@ -1,53 +0,0 @@ -# HG changeset patch -# User Anuj Mittal -# Date 1573631462 -10800 -# Node ID 1fb1880d5edfc7c5a370846e13f90b260263627c -# Parent 007002587d5d34d781c2b628c05e992e0ac5f52d -configure: check for build dir when building version res (fix bug #4858) -Fixes a race where we try to build version res file in build directory -before it has even been created. Prevents errors like: - -/bin/bash ../SDL2-2.0.10/build-scripts/updaterev.sh -/bin/bash ../SDL2-2.0.10/build-scripts/mkinstalldirs build -mkdir -p -- build -x86_64-pokysdk-mingw32-windres --include-dir=/home/pokybuild/yocto-worker/meta-mingw/build/build/tmp/work/x86_64-nativesdk-mingw32-pokysdk-mingw32/nativesdk-libsdl2/2.0.10-r0/recipe-sysroot/opt/poky/3.0/sysroots/x86_64-pokysdk-mingw32/usr/include ../SDL2-2.0.10/src/main/windows/version.rc build/version.o -x86_64-pokysdk-mingw32-windres: build/version.o: No such file or directory -Makefile:692: recipe for target 'build/version.o' failed -make: *** [build/version.o] Error 1 -make: *** Waiting for unfinished jobs.... -touch build/.created -WARNING: exit code 1 from a shell command. - -Extension of fix: -https://hg.libsdl.org/SDL/rev/99d8b18acf8a - -Upstream-Status: Backport -Signed-off-by: Anuj Mittal ---- - configure.ac | 2 +- - 1 file changed, 1 insertion(+), 1 deletion(-) - -diff -r 007002587d5d -r 1fb1880d5edf configure ---- a/configure Tue Nov 12 17:24:37 2019 -0500 -+++ b/configure Wed Nov 13 10:51:02 2019 +0300 -@@ -25493,7 +25493,7 @@ - VERSION_DEPENDS=`echo $VERSION_SOURCES` - VERSION_OBJECTS=`echo "$VERSION_OBJECTS" | sed 's,[^ ]*/\([^ ]*\)\.rc,$(objects)/\1.o,g'` - VERSION_DEPENDS=`echo "$VERSION_DEPENDS" | sed "s,\\([^ ]*\\)/\\([^ ]*\\)\\.rc,\\\\ --\\$(objects)/\\2.o: \\1/\\2.rc\\\\ -+\\$(objects)/\\2.o: \\1/\\2.rc \\$(objects)/.created\\\\ - \\$(WINDRES) \\$< \\$@,g"` - - SDLMAIN_OBJECTS=`echo $SDLMAIN_SOURCES` -diff -r 007002587d5d -r 1fb1880d5edf configure.ac ---- a/configure.ac Tue Nov 12 17:24:37 2019 -0500 -+++ b/configure.ac Wed Nov 13 10:51:02 2019 +0300 -@@ -4177,7 +4177,7 @@ - VERSION_DEPENDS=`echo $VERSION_SOURCES` - VERSION_OBJECTS=`echo "$VERSION_OBJECTS" | sed 's,[[^ ]]*/\([[^ ]]*\)\.rc,$(objects)/\1.o,g'` - VERSION_DEPENDS=`echo "$VERSION_DEPENDS" | sed "s,\\([[^ ]]*\\)/\\([[^ ]]*\\)\\.rc,\\\\ --\\$(objects)/\\2.o: \\1/\\2.rc\\\\ -+\\$(objects)/\\2.o: \\1/\\2.rc \\$(objects)/.created\\\\ - \\$(WINDRES) \\$< \\$@,g"` - - SDLMAIN_OBJECTS=`echo $SDLMAIN_SOURCES` diff --git a/meta/recipes-graphics/libsdl2/libsdl2/0002-Fixed-bug-4797-SDL-fails-to-compile-with-Mesa-Master.patch b/meta/recipes-graphics/libsdl2/libsdl2/0002-Fixed-bug-4797-SDL-fails-to-compile-with-Mesa-Master.patch deleted file mode 100644 index 8f5b6a0cef..0000000000 --- a/meta/recipes-graphics/libsdl2/libsdl2/0002-Fixed-bug-4797-SDL-fails-to-compile-with-Mesa-Master.patch +++ /dev/null @@ -1,41 +0,0 @@ -# HG changeset patch -# User Sylvain Becker -# Date 1570898876 -7200 -# Sat Oct 12 18:47:56 2019 +0200 -# Node ID 369b01006eb2f6fd563f7c315d29ae3fe503c432 -# Parent 4cbaffd0083b8cd17070dbd9d4ab1ce0fa9fca2d -Fixed bug 4797 - SDL fails to compile with Mesa Master (thanks Michael Olbrich!) - -fix building with Mesa 19.2 - -With Mesa 19.2 building fails with: - -/include/GLES/gl.h:63:25: error: conflicting types for 'GLsizeiptr' - -The same type is defined in include/SDL_opengl.h for OpenGL and the two -headers should not be included at the same time. -This was just never noticed because the same header guard '__gl_h_' was -used. This was changed in Mesa. The result is this error. - -Fix this the same way GLES2 already handles this: Don't include the GLES -header when the OpenGL header was already included. -(https://hg.libsdl.org/SDL/rev/a60b3c292f0f) - -Upstream-Status: Backport [https://hg.libsdl.org/SDL/rev/369b01006eb2] -Signed-off-by: Alistair Francis - -diff --git a/src/video/SDL_video.c b/src/video/SDL_video.c ---- a/src/video/SDL_video.c -+++ b/src/video/SDL_video.c -@@ -37,9 +37,9 @@ - #include "SDL_opengl.h" - #endif /* SDL_VIDEO_OPENGL */ - --#if SDL_VIDEO_OPENGL_ES -+#if SDL_VIDEO_OPENGL_ES && !SDL_VIDEO_OPENGL - #include "SDL_opengles.h" --#endif /* SDL_VIDEO_OPENGL_ES */ -+#endif /* SDL_VIDEO_OPENGL_ES && !SDL_VIDEO_OPENGL */ - - /* GL and GLES2 headers conflict on Linux 32 bits */ - #if SDL_VIDEO_OPENGL_ES2 && !SDL_VIDEO_OPENGL diff --git a/meta/recipes-graphics/libsdl2/libsdl2_2.0.10.bb b/meta/recipes-graphics/libsdl2/libsdl2_2.0.12.bb similarity index 81% rename from meta/recipes-graphics/libsdl2/libsdl2_2.0.10.bb rename to meta/recipes-graphics/libsdl2/libsdl2_2.0.12.bb index 413f53476a..c1c941e452 100644 --- a/meta/recipes-graphics/libsdl2/libsdl2_2.0.10.bb +++ b/meta/recipes-graphics/libsdl2/libsdl2_2.0.12.bb @@ -8,21 +8,22 @@ BUGTRACKER = "http://bugzilla.libsdl.org/" SECTION = "libs" LICENSE = "Zlib" -LIC_FILES_CHKSUM = "file://COPYING.txt;md5=504a9454ceb89fd75a2583473b11409e" +LIC_FILES_CHKSUM = "file://COPYING.txt;md5=2d4af6adb4d89aad0cdedbcc18c9a32f" + +# arm-neon adds MIT license +LICENSE_append = " ${@bb.utils.contains('PACKAGECONFIG', 'arm-neon', '& MIT', '', d)}" +LIC_FILES_CHKSUM_append = " ${@bb.utils.contains('PACKAGECONFIG', 'arm-neon', 'file://src/video/arm/pixman-arm-neon-asm.h;md5=9a9cc1e51abbf1da58f4d9528ec9d49b;beginline=1;endline=24', '', d)}" PROVIDES = "virtual/libsdl2" SRC_URI = "http://www.libsdl.org/release/SDL2-${PV}.tar.gz \ file://more-gen-depends.patch \ - file://0001-Fixed-bug-4538-validate-image-size-when-loading-BMP-.patch \ - file://0002-Fixed-bug-4797-SDL-fails-to-compile-with-Mesa-Master.patch \ - file://0001-configure-check-for-build-dir-when-building-version-.patch \ " S = "${WORKDIR}/SDL2-${PV}" -SRC_URI[md5sum] = "5a2114f2a6f348bdab5bf52b994811db" -SRC_URI[sha256sum] = "b4656c13a1f0d0023ae2f4a9cf08ec92fffb464e0f24238337784159b8b91d57" +SRC_URI[md5sum] = "783b6f2df8ff02b19bb5ce492b99c8ff" +SRC_URI[sha256sum] = "349268f695c02efbc9b9148a70b85e58cefbbf704abd3e91be654db7f1e2c863" inherit autotools lib_package binconfig-disabled pkgconfig @@ -50,8 +51,10 @@ PACKAGECONFIG ??= " \ ${PACKAGECONFIG_GL} \ ${@bb.utils.filter('DISTRO_FEATURES', 'alsa directfb pulseaudio x11', d)} \ ${@bb.utils.contains('DISTRO_FEATURES', 'wayland', 'wayland gles2', '', d)} \ + ${@bb.utils.contains("TUNE_FEATURES", "neon","arm-neon","",d)} \ " PACKAGECONFIG[alsa] = "--enable-alsa --disable-alsatest,--disable-alsa,alsa-lib," +PACKAGECONFIG[arm-neon] = "--enable-arm-neon,--disable-arm-neon" PACKAGECONFIG[directfb] = "--enable-video-directfb,--disable-video-directfb,directfb" PACKAGECONFIG[gles2] = "--enable-video-opengles,--disable-video-opengles,virtual/libgles2" PACKAGECONFIG[jack] = "--enable-jack,--disable-jack,jack" -- 2.21.1 From Peter.Marko at siemens.com Thu Mar 12 15:21:54 2020 From: Peter.Marko at siemens.com (Marko, Peter) Date: Thu, 12 Mar 2020 15:21:54 +0000 Subject: [OE-core] runqemu nographic and hvc0 Message-ID: Hi, I'm trying to boot my own qemu image on zeus branch with "runqemu nographic /path/to/extracted/rootfs" but I have problem that console is flooded with process '/sbin/getty 115200 hvc0' (pid 383) exited. Scheduling for restart. starting pid 385, tty '': '/sbin/getty 115200 hvc0' I'm using yocto qemuarm kernel and qemuarm machine (but it's the same with qemuarm64). Basically qemuarm machine has SERIAL_CONSOLES ?= "115200;ttyAMA0 115200;hvc0" which is transferred to /etc/inittab, however hvc0 device does not exist after booting in nographic mode. What kind of configuration am I missing in my image? I think that might be the graphic console which does not exist in nographic mode? Is there a way to get rid of this problem without breaking graphic mode console? Thanks, Peter From raj.khem at gmail.com Thu Mar 12 16:06:04 2020 From: raj.khem at gmail.com (Khem Raj) Date: Thu, 12 Mar 2020 09:06:04 -0700 Subject: [OE-core] [PATCH] netbase: use snapshot.debian.org In-Reply-To: References: <1583983272-116095-1-git-send-email-mingli.yu@windriver.com> Message-ID: <35d02004-68f2-eac7-16e5-8e51d98d7a1d@gmail.com> On 3/12/20 1:25 AM, Alexander Kanavin wrote: > On Thu, 12 Mar 2020 at 04:22, > wrote: > > -SRC_URI = "${DEBIAN_MIRROR}/main/n/${BPN}/${BPN}_${PV}.tar.xz" > +SRC_URI = > "http://snapshot.debian.org/archive/debian/20200311T090704Z/pool/main/n/${BPN}/${BPN}_${PV}.tar.xz > " > > > This will break version checks and automated upgrades. Is it possible to > build from git instead? > Specifically: https://salsa.debian.org/md/netbase That repo is debian build metadata sources for netbase. > > Alex > From raj.khem at gmail.com Thu Mar 12 16:13:08 2020 From: raj.khem at gmail.com (Khem Raj) Date: Thu, 12 Mar 2020 09:13:08 -0700 Subject: [OE-core] runqemu nographic and hvc0 In-Reply-To: References: Message-ID: <80a2ec8e-cb96-9e2c-77e4-64fc2d5163dc@gmail.com> On 3/12/20 8:21 AM, Marko, Peter wrote: > Hi, > > I'm trying to boot my own qemu image on zeus branch with "runqemu nographic /path/to/extracted/rootfs" but I have problem that console is flooded with > process '/sbin/getty 115200 hvc0' (pid 383) exited. Scheduling for restart. > starting pid 385, tty '': '/sbin/getty 115200 hvc0' > I'm using yocto qemuarm kernel and qemuarm machine (but it's the same with qemuarm64). > > Basically qemuarm machine has > SERIAL_CONSOLES ?= "115200;ttyAMA0 115200;hvc0" > which is transferred to /etc/inittab, however hvc0 device does not exist after booting in nographic mode. > > What kind of configuration am I missing in my image? > I think that might be the graphic console which does not exist in nographic mode? that is correct > Is there a way to get rid of this problem without breaking graphic mode console? I did not find one, it particularly happens with busybox init. > > Thanks, > Peter > From alex.kanavin at gmail.com Thu Mar 12 16:25:24 2020 From: alex.kanavin at gmail.com (Alexander Kanavin) Date: Thu, 12 Mar 2020 17:25:24 +0100 Subject: [OE-core] [PATCH] netbase: use snapshot.debian.org In-Reply-To: <35d02004-68f2-eac7-16e5-8e51d98d7a1d@gmail.com> References: <1583983272-116095-1-git-send-email-mingli.yu@windriver.com> <35d02004-68f2-eac7-16e5-8e51d98d7a1d@gmail.com> Message-ID: On Thu, 12 Mar 2020 at 17:08, Khem Raj wrote: > > This will break version checks and automated upgrades. Is it possible to > > build from git instead? > > Specifically: https://salsa.debian.org/md/netbase > > That repo is debian build metadata sources for netbase. > Nope. It is the actual sources too, in etc/. Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From armccurdy at gmail.com Thu Mar 12 16:44:46 2020 From: armccurdy at gmail.com (Andre McCurdy) Date: Thu, 12 Mar 2020 09:44:46 -0700 Subject: [OE-core] runqemu nographic and hvc0 In-Reply-To: <80a2ec8e-cb96-9e2c-77e4-64fc2d5163dc@gmail.com> References: <80a2ec8e-cb96-9e2c-77e4-64fc2d5163dc@gmail.com> Message-ID: On Thu, Mar 12, 2020 at 9:13 AM Khem Raj wrote: > On 3/12/20 8:21 AM, Marko, Peter wrote: > > Hi, > > > > I'm trying to boot my own qemu image on zeus branch with "runqemu nographic /path/to/extracted/rootfs" but I have problem that console is flooded with > > process '/sbin/getty 115200 hvc0' (pid 383) exited. Scheduling for restart. > > starting pid 385, tty '': '/sbin/getty 115200 hvc0' > > I'm using yocto qemuarm kernel and qemuarm machine (but it's the same with qemuarm64). > > > > Basically qemuarm machine has > > SERIAL_CONSOLES ?= "115200;ttyAMA0 115200;hvc0" > > which is transferred to /etc/inittab, however hvc0 device does not exist after booting in nographic mode. > > > > What kind of configuration am I missing in my image? > > I think that might be the graphic console which does not exist in nographic mode? > > that is correct > > > Is there a way to get rid of this problem without breaking graphic mode console? > > I did not find one, it particularly happens with busybox init. I don't know what the proper fix is, but changing SERIAL_CONSOLES to "115200;ttyAMA0" avoids the issue. I've changed the machine config directly but you could probably also use the _qemuarm over-ride to set SERIAL_CONSOLES from local.conf, etc, e.g.: SERIAL_CONSOLES_qemuarm = "115200;ttyAMA0" From armccurdy at gmail.com Thu Mar 12 17:15:59 2020 From: armccurdy at gmail.com (Andre McCurdy) Date: Thu, 12 Mar 2020 10:15:59 -0700 Subject: [OE-core] simplest command to display which layers are applying the same patch? In-Reply-To: <20200312103003.Horde.-mn1W9NE8YAc6sk0SRLY8bj@crashcourse.ca> References: <20200312085608.Horde.kbPh9KWkZJR4Zi-lry-_TrN@crashcourse.ca> <20200312103003.Horde.-mn1W9NE8YAc6sk0SRLY8bj@crashcourse.ca> Message-ID: On Thu, Mar 12, 2020 at 7:30 AM wrote: > Quoting Alexander Kanavin : > > > I think 'bitbake -e recipe', and then searching for SRC_URI in it should > > show which layer applies which patch. > > ... snip ... > > I *think* I know what might be happening here, and I'd like to verify > some suspicions about how recipes are selected and patches are applied. > (Writing this in real time so I hope I don't screw up.) > > Imagine I've checked out oe-core, which supplies recipe file fubar_1.0.bb, > but it becomes obvious that there is a bug, for which there is an obvious > patch I can apply internally. So I fire up a fubar bbappend file, which > does nothing but extend SRC_URI to apply the patch, call it fubar.patch. > (Remember, this patching is all internal, in my vendor layer.) > > *However*, being a bit lazy, rather than create fubar_1.0.bbappend, I > slack off and create simply fubar_1.%.bbappend. (I suspect you see > where I'm going with this.) > > Now the good folks at OE get around to updating oe-core, and part of > that update is to add that patch to SRC_URI of fubar_1.1.bb (along > with the patch file fubar.patch, of course). Now, because that is > a more recent version of fubar, that is the recipe file that should > be selected. > > *However*, if I interpret this correctly, first, I have fubar_1.1.bb > applying fubar.patch, but because I am also defining a layer which > contains the append file fubar_1.%.bbappend, that append file will > also try to apply the same patch, which of course should not work > properly. (Am I correct in my thinking so far?) > > If I'm explaining this correctly, then the fault naturally lies with > me for being sloppily ambiguous with my append file and not locking > it to fubar_1.0, but allowing it to be applied against all fubar_1.x > recipes. In short, when I inevitably get the error of "Patch already > applied," it is entirely my fault for being sloppy. Not really. Upstream oe-core could equally well have added the patch to fubar_1.0.bb, so using a version specific .bbappend doesn't give any guarantees that you don't try to apply the same patch twice. > I'm trying to verify this as I am now aware that a *lot* of append> files in the vendor layer in question are similarly ambiguous. > Does this make sense? There are two approaches to applying fixes to upstream layers such as oe-core. One is to create a separate layer containing .bbappend files, the other is to maintain your own fork of the upstream repo. Both approaches work but maintaining your own fork has a number of advantages: - Any changes you make are easier to submit upstream (since you are always creating patches against the upstream repo) - You can directly cherry pick upstream fixes or version updates for specific recipes you care about - If necessary, you can easily revert upstream changes - If you rebase to a new upstream release, there's a good chance that cherrypicked upstream backports magically disappear with no effort on your part - If you rebase to an new upstream release, you get a clear warning (merge conflict) if a change you've made conflicts with a change upstream - Some changes are much more difficult to make via .bbappends but easy to make directly in the original meta layer (e.g. try adding a patch to gcc) Maintaining your own fork of an upstream meta layer may not be for everyone, but for the situations you've been describing recently (ie where you have a large number of .bbappends for oe-core which you want to migrate to a new OE release) it may be the better approach. From raj.khem at gmail.com Thu Mar 12 18:05:16 2020 From: raj.khem at gmail.com (Khem Raj) Date: Thu, 12 Mar 2020 11:05:16 -0700 Subject: [OE-core] [PATCH] netbase: use snapshot.debian.org In-Reply-To: References: <1583983272-116095-1-git-send-email-mingli.yu@windriver.com> <35d02004-68f2-eac7-16e5-8e51d98d7a1d@gmail.com> Message-ID: On Thu, Mar 12, 2020 at 9:25 AM Alexander Kanavin wrote: > > On Thu, 12 Mar 2020 at 17:08, Khem Raj wrote: >> >> > This will break version checks and automated upgrades. Is it possible to >> > build from git instead? >> > Specifically: https://salsa.debian.org/md/netbase >> >> That repo is debian build metadata sources for netbase. > > > Nope. It is the actual sources too, in etc/. > Right, I oversaw that, perhaps git fetch with right SHA1 for release tag might be ok to use > Alex From raj.khem at gmail.com Thu Mar 12 18:06:28 2020 From: raj.khem at gmail.com (Khem Raj) Date: Thu, 12 Mar 2020 11:06:28 -0700 Subject: [OE-core] runqemu nographic and hvc0 In-Reply-To: References: <80a2ec8e-cb96-9e2c-77e4-64fc2d5163dc@gmail.com> Message-ID: On Thu, Mar 12, 2020 at 9:44 AM Andre McCurdy wrote: > > On Thu, Mar 12, 2020 at 9:13 AM Khem Raj wrote: > > On 3/12/20 8:21 AM, Marko, Peter wrote: > > > Hi, > > > > > > I'm trying to boot my own qemu image on zeus branch with "runqemu nographic /path/to/extracted/rootfs" but I have problem that console is flooded with > > > process '/sbin/getty 115200 hvc0' (pid 383) exited. Scheduling for restart. > > > starting pid 385, tty '': '/sbin/getty 115200 hvc0' > > > I'm using yocto qemuarm kernel and qemuarm machine (but it's the same with qemuarm64). > > > > > > Basically qemuarm machine has > > > SERIAL_CONSOLES ?= "115200;ttyAMA0 115200;hvc0" > > > which is transferred to /etc/inittab, however hvc0 device does not exist after booting in nographic mode. > > > > > > What kind of configuration am I missing in my image? > > > I think that might be the graphic console which does not exist in nographic mode? > > > > that is correct > > > > > Is there a way to get rid of this problem without breaking graphic mode console? > > > > I did not find one, it particularly happens with busybox init. > > I don't know what the proper fix is, but changing SERIAL_CONSOLES to > "115200;ttyAMA0" avoids the issue. > > I've changed the machine config directly but you could probably also > use the _qemuarm over-ride to set SERIAL_CONSOLES from local.conf, > etc, e.g.: > > SERIAL_CONSOLES_qemuarm = "115200;ttyAMA0" that made -ctestimage fail last time when I tried it but havent tried it lately maybe things are better From randy.macleod at windriver.com Thu Mar 12 20:53:31 2020 From: randy.macleod at windriver.com (Randy MacLeod) Date: Thu, 12 Mar 2020 16:53:31 -0400 Subject: [OE-core] [PATCH] qemu: fix CVE-2020-7039 In-Reply-To: <1582781146-253903-1-git-send-email-changqing.li@windriver.com> References: <1582781146-253903-1-git-send-email-changqing.li@windriver.com> Message-ID: <6830c57f-37de-dc1a-ba80-5a4217644060@windriver.com> On 2020-02-27 12:25 a.m., changqing.li at windriver.com wrote: > From: Changqing Li > > Signed-off-by: Changqing Li > --- > meta/recipes-devtools/qemu/qemu.inc | 3 + > .../qemu/qemu/CVE-2020-7039-1.patch | 44 +++++++++++++++ > .../qemu/qemu/CVE-2020-7039-2.patch | 59 ++++++++++++++++++++ > .../qemu/qemu/CVE-2020-7039-3.patch | 64 ++++++++++++++++++++++ > 4 files changed, 170 insertions(+) > create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2020-7039-1.patch > create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2020-7039-2.patch > create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2020-7039-3.patch > LGTM, I don't see it in master or master-next. NVD gives this defect a 'critical' score so it would be good to get it tested and merged. https://nvd.nist.gov/vuln/detail/CVE-2020-7039 -- # Randy MacLeod # Wind River Linux From raj.khem at gmail.com Thu Mar 12 20:54:32 2020 From: raj.khem at gmail.com (Khem Raj) Date: Thu, 12 Mar 2020 13:54:32 -0700 Subject: [OE-core] [PATCH 05/13] weston-init: use the drm/kms backend rather than fbdev one for qemux86 machines In-Reply-To: <20200219194752.7967-5-alex.kanavin@gmail.com> References: <20200219194752.7967-1-alex.kanavin@gmail.com> <20200219194752.7967-5-alex.kanavin@gmail.com> Message-ID: On Wed, Feb 19, 2020 at 11:49 AM Alexander Kanavin wrote: > > The fbdev backend is not documented, and not the default; > as the emulated hardware in qemu now supports DRM/KMS > (both std and virtio), we should align with upstream default > and vast majority of users. Empty init file will cause > weston to default to the KMS backend. > > Note that 3D acceleration via virgl is not required; the backend > renders fine via the software driver in mesa. However, kvm > is more or less required to keep the UI responsive. > > Also, other qemu targets (mips and arm in particular) continue > to use the fbdev backend, as in the absence of kvm, the performance > of software GL paths falls to unacceptable level. > drm backend change did not work directly with musl, I will send a patch to enable WESTON_DISABLE_ATOMIC when launching weston which should fix the launch errors seen [18:58:45.628] launching '/usr/libexec/weston-desktop-shell' [18:58:45.737] atomic: couldn't commit new state: Invalid argument [18:58:45.737] repaint-flush failed: Invalid argument > Signed-off-by: Alexander Kanavin > --- > meta/recipes-graphics/wayland/weston-init/qemux86-64/weston.ini | 0 > meta/recipes-graphics/wayland/weston-init/qemux86/weston.ini | 0 > 2 files changed, 0 insertions(+), 0 deletions(-) > create mode 100644 meta/recipes-graphics/wayland/weston-init/qemux86-64/weston.ini > create mode 100644 meta/recipes-graphics/wayland/weston-init/qemux86/weston.ini > > diff --git a/meta/recipes-graphics/wayland/weston-init/qemux86-64/weston.ini b/meta/recipes-graphics/wayland/weston-init/qemux86-64/weston.ini > new file mode 100644 > index 0000000000..e69de29bb2 > diff --git a/meta/recipes-graphics/wayland/weston-init/qemux86/weston.ini b/meta/recipes-graphics/wayland/weston-init/qemux86/weston.ini > new file mode 100644 > index 0000000000..e69de29bb2 > -- > 2.25.0 > > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core at lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core From akuster808 at gmail.com Thu Mar 12 21:21:41 2020 From: akuster808 at gmail.com (akuster808) Date: Thu, 12 Mar 2020 14:21:41 -0700 Subject: [OE-core] [PATCH] qemu: fix CVE-2020-7039 In-Reply-To: <6830c57f-37de-dc1a-ba80-5a4217644060@windriver.com> References: <1582781146-253903-1-git-send-email-changqing.li@windriver.com> <6830c57f-37de-dc1a-ba80-5a4217644060@windriver.com> Message-ID: <411a9ec9-9426-4083-e232-48ae750846c2@gmail.com> Randy, On 3/12/20 1:53 PM, Randy MacLeod wrote: > On 2020-02-27 12:25 a.m., changqing.li at windriver.com wrote: >> From: Changqing Li This does not apply cleanly to current master.? it needs to be rebased ( suspect qemu: update Xen packages names for the xen-tools recipe). Do know if it is in contrib branch some where so I he rebase myself? - armin >> >> Signed-off-by: Changqing Li >> --- >> ? meta/recipes-devtools/qemu/qemu.inc??????????????? |? 3 + >> ? .../qemu/qemu/CVE-2020-7039-1.patch??????????????? | 44 >> +++++++++++++++ >> ? .../qemu/qemu/CVE-2020-7039-2.patch??????????????? | 59 >> ++++++++++++++++++++ >> ? .../qemu/qemu/CVE-2020-7039-3.patch??????????????? | 64 >> ++++++++++++++++++++++ >> ? 4 files changed, 170 insertions(+) >> ? create mode 100644 >> meta/recipes-devtools/qemu/qemu/CVE-2020-7039-1.patch >> ? create mode 100644 >> meta/recipes-devtools/qemu/qemu/CVE-2020-7039-2.patch >> ? create mode 100644 >> meta/recipes-devtools/qemu/qemu/CVE-2020-7039-3.patch >> > > LGTM, I don't see it in master or master-next. > > NVD gives this defect a 'critical' score so it would be good to get > it tested and merged. > https://nvd.nist.gov/vuln/detail/CVE-2020-7039 > From akuster808 at gmail.com Thu Mar 12 21:28:58 2020 From: akuster808 at gmail.com (akuster808) Date: Thu, 12 Mar 2020 14:28:58 -0700 Subject: [OE-core] [PATCH] qemu: fix CVE-2020-7039 In-Reply-To: <6830c57f-37de-dc1a-ba80-5a4217644060@windriver.com> References: <1582781146-253903-1-git-send-email-changqing.li@windriver.com> <6830c57f-37de-dc1a-ba80-5a4217644060@windriver.com> Message-ID: <1f976d97-3c96-3234-7e4f-79e8fe8f1800@gmail.com> On 3/12/20 1:53 PM, Randy MacLeod wrote: > On 2020-02-27 12:25 a.m., changqing.li at windriver.com wrote: >> From: Changqing Li got it fixed up. its sitting @ http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=akuster/master-next_qemu_fix I will through it at the AB so will let RP decide if he want to take it before M3 - Armin >> >> Signed-off-by: Changqing Li >> --- >> ? meta/recipes-devtools/qemu/qemu.inc??????????????? |? 3 + >> ? .../qemu/qemu/CVE-2020-7039-1.patch??????????????? | 44 >> +++++++++++++++ >> ? .../qemu/qemu/CVE-2020-7039-2.patch??????????????? | 59 >> ++++++++++++++++++++ >> ? .../qemu/qemu/CVE-2020-7039-3.patch??????????????? | 64 >> ++++++++++++++++++++++ >> ? 4 files changed, 170 insertions(+) >> ? create mode 100644 >> meta/recipes-devtools/qemu/qemu/CVE-2020-7039-1.patch >> ? create mode 100644 >> meta/recipes-devtools/qemu/qemu/CVE-2020-7039-2.patch >> ? create mode 100644 >> meta/recipes-devtools/qemu/qemu/CVE-2020-7039-3.patch >> > > LGTM, I don't see it in master or master-next. > > NVD gives this defect a 'critical' score so it would be good to get > it tested and merged. > https://nvd.nist.gov/vuln/detail/CVE-2020-7039 > From richard.purdie at linuxfoundation.org Thu Mar 12 22:50:06 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Thu, 12 Mar 2020 22:50:06 +0000 Subject: [OE-core] [PATCH] scripts/oe-buildenv-internal: Add BB_LOGCONFIG Message-ID: <20200312225006.127745-1-richard.purdie@linuxfoundation.org> We should allow the logging configurations to be specificed from the environment, for example for autobuilder setups. Signed-off-by: Richard Purdie --- scripts/oe-buildenv-internal | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/scripts/oe-buildenv-internal b/scripts/oe-buildenv-internal index c17cf4da711..8cbe34669da 100755 --- a/scripts/oe-buildenv-internal +++ b/scripts/oe-buildenv-internal @@ -106,7 +106,8 @@ BB_ENV_EXTRAWHITE_OE="MACHINE DISTRO TCMODE TCLIBC HTTP_PROXY http_proxy \ HTTPS_PROXY https_proxy FTP_PROXY ftp_proxy FTPS_PROXY ftps_proxy ALL_PROXY \ all_proxy NO_PROXY no_proxy SSH_AGENT_PID SSH_AUTH_SOCK BB_SRCREV_POLICY \ SDKMACHINE BB_NUMBER_THREADS BB_NO_NETWORK PARALLEL_MAKE GIT_PROXY_COMMAND \ -SOCKS5_PASSWD SOCKS5_USER SCREENDIR STAMPS_DIR BBPATH_EXTRA BB_SETSCENE_ENFORCE" +SOCKS5_PASSWD SOCKS5_USER SCREENDIR STAMPS_DIR BBPATH_EXTRA BB_SETSCENE_ENFORCE \ +BB_LOGCONFIG" BB_ENV_EXTRAWHITE="$(echo $BB_ENV_EXTRAWHITE $BB_ENV_EXTRAWHITE_OE | tr ' ' '\n' | LC_ALL=C sort --unique | tr '\n' ' ')" -- 2.25.0 From raj.khem at gmail.com Thu Mar 12 23:02:37 2020 From: raj.khem at gmail.com (Khem Raj) Date: Thu, 12 Mar 2020 16:02:37 -0700 Subject: [OE-core] [PATCH] musl: removes aliases for glibc provided libraries Message-ID: <20200312230238.413509-1-raj.khem@gmail.com> From: Jan Kaisrlik Based on the recommendation in musl mailing list[1] All symlinks have been removed from musl recipe. [1]: https://www.openwall.com/lists/musl/2020/03/10/11 Signed-off-by: Jan Kaisrlik Signed-off-by: Khem Raj --- meta/recipes-core/musl/musl_git.bb | 15 +-------------- 1 file changed, 1 insertion(+), 14 deletions(-) diff --git a/meta/recipes-core/musl/musl_git.bb b/meta/recipes-core/musl/musl_git.bb index afc8446547..f4fbb03092 100644 --- a/meta/recipes-core/musl/musl_git.bb +++ b/meta/recipes-core/musl/musl_git.bb @@ -66,24 +66,11 @@ do_install() { rm -f ${D}${bindir}/ldd ${D}${GLIBC_LDSO} lnr ${D}${libdir}/libc.so ${D}${bindir}/ldd lnr ${D}${libdir}/libc.so ${D}${GLIBC_LDSO} - for l in crypt dl m pthread resolv rt util xnet - do - ln -sf libc.so ${D}${libdir}/lib$l.so - done - for i in libc.so.6 libcrypt.so.1 libdl.so.2 libm.so.6 libpthread.so.0 libresolv.so.2 librt.so.1 libutil.so.1; do - ln -sf libc.so ${D}${libdir}/$i - done } PACKAGES =+ "${PN}-glibc-compat" -FILES_${PN}-glibc-compat += "\ - ${libdir}/libc.so.6 ${libdir}/libcrypt.so.1 \ - ${libdir}/libdl.so.2 ${libdir}/libm.so.6 \ - ${libdir}/libpthread.so.0 ${libdir}/libresolv.so.2 \ - ${libdir}/librt.so.1 ${libdir}/libutil.so.1 \ - ${GLIBC_LDSO} \ - " +FILES_${PN}-glibc-compat += "${GLIBC_LDSO}" RDEPENDS_${PN}-dev += "linux-libc-headers-dev bsd-headers-dev libssp-nonshared-staticdev" RPROVIDES_${PN}-dev += "libc-dev virtual-libc-dev" -- 2.25.1 From raj.khem at gmail.com Thu Mar 12 23:02:38 2020 From: raj.khem at gmail.com (Khem Raj) Date: Thu, 12 Mar 2020 16:02:38 -0700 Subject: [OE-core] [PATCH] weston-init: Launch weston with WESTON_DISABLE_ATOMIC on musl/x86 In-Reply-To: <20200312230238.413509-1-raj.khem@gmail.com> References: <20200312230238.413509-1-raj.khem@gmail.com> Message-ID: <20200312230238.413509-2-raj.khem@gmail.com> Since we enabled drm/kms backend for qemux86, it does not work with musl fdbdev worked ok, we see this error [18:58:45.628] launching '/usr/libexec/weston-desktop-shell' [18:58:45.737] atomic: couldn't commit new state: Invalid argument [18:58:45.737] repaint-flush failed: Invalid argument There seems to be some problem with atomics in libdrm, until that gets diagnosed, simple solution is to not use it on musl when drm backend is used thats why WESTON_DISABLE_ATOMIC=Y is set in environment file for such cases Signed-off-by: Khem Raj --- meta/recipes-graphics/wayland/weston-init.bb | 14 ++++++++++++-- .../wayland/weston-init/weston.env | 0 2 files changed, 12 insertions(+), 2 deletions(-) create mode 100644 meta/recipes-graphics/wayland/weston-init/weston.env diff --git a/meta/recipes-graphics/wayland/weston-init.bb b/meta/recipes-graphics/wayland/weston-init.bb index e3e739e2b7..40aa76295f 100644 --- a/meta/recipes-graphics/wayland/weston-init.bb +++ b/meta/recipes-graphics/wayland/weston-init.bb @@ -5,6 +5,7 @@ LIC_FILES_CHKSUM = "file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384 PACKAGE_ARCH = "${MACHINE_ARCH}" SRC_URI = "file://init \ + file://weston.env \ file://weston.ini \ file://weston at .service \ file://71-weston-drm.rules \ @@ -15,6 +16,7 @@ S = "${WORKDIR}" do_install() { install -Dm755 ${WORKDIR}/init ${D}/${sysconfdir}/init.d/weston install -D -p -m0644 ${WORKDIR}/weston.ini ${D}${sysconfdir}/xdg/weston/weston.ini + install -Dm644 ${WORKDIR}/weston.env ${D}${sysconfdir}/default/weston # Install Weston systemd service and accompanying udev rule install -D -p -m0644 ${WORKDIR}/weston at .service ${D}${systemd_system_unitdir}/weston at .service @@ -30,6 +32,14 @@ do_install() { sed -i 's, at LOCALSTATEDIR@,${localstatedir},g' ${D}${bindir}/weston-start } +do_install_append_libc-musl_qemux86() { + echo "WESTON_DISABLE_ATOMIC=Y" >> ${D}${sysconfdir}/default/weston +} + +do_install_append_libc-musl_qemux86-64() { + echo "WESTON_DISABLE_ATOMIC=Y" >> ${D}${sysconfdir}/default/weston +} + inherit update-rc.d features_check systemd # rdepends on weston which depends on virtual/egl @@ -40,9 +50,9 @@ RDEPENDS_${PN} = "weston kbd" INITSCRIPT_NAME = "weston" INITSCRIPT_PARAMS = "start 9 5 2 . stop 20 0 1 6 ." -FILES_${PN} += "${sysconfdir}/xdg/weston/weston.ini ${systemd_system_unitdir}/weston at .service" +FILES_${PN} += "${sysconfdir}/xdg/weston/weston.ini ${systemd_system_unitdir}/weston at .service ${sysconfdir}/default/weston" -CONFFILES_${PN} += "${sysconfdir}/xdg/weston/weston.ini" +CONFFILES_${PN} += "${sysconfdir}/xdg/weston/weston.ini ${sysconfdir}/default/weston" SYSTEMD_SERVICE_${PN} = "weston@%i.service" SYSTEMD_AUTO_ENABLE = "disable" diff --git a/meta/recipes-graphics/wayland/weston-init/weston.env b/meta/recipes-graphics/wayland/weston-init/weston.env new file mode 100644 index 0000000000..e69de29bb2 -- 2.25.1 From raj.khem at gmail.com Thu Mar 12 23:08:40 2020 From: raj.khem at gmail.com (Khem Raj) Date: Thu, 12 Mar 2020 16:08:40 -0700 Subject: [OE-core] [PATCH] gcc: Upgrade to 9.3 bugfix release Message-ID: <20200312230840.751166-1-raj.khem@gmail.com> This brings ~157 bugfixes [1] to gcc-9 with no features Drop backports which are already part of the release now [1] https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&list_id=260610&resolution=FIXED&target_milestone=9.3 Signed-off-by: Khem Raj --- meta/conf/distro/include/maintainers.inc | 2 +- ...libsanitizer-build-with-master-glibc.patch | 70 --- .../gcc/gcc-9.2/CVE-2019-15847_1.patch | 521 ------------------ .../gcc/gcc-9.2/CVE-2019-15847_2.patch | 77 --- .../gcc/gcc-9.2/CVE-2019-15847_3.patch | 62 --- .../gcc/{gcc-9.2.inc => gcc-9.3.inc} | 22 +- ...0001-gcc-4.3.1-ARCH_FLAGS_FOR_TARGET.patch | 6 +- .../0002-gcc-poison-system-directories.patch | 24 +- ...-gcc-4.3.3-SYSROOT_CFLAGS_FOR_TARGET.patch | 6 +- .../0004-64-bit-multilib-hack.patch | 6 +- .../0005-optional-libstdc.patch | 12 +- .../0006-COLLECT_GCC_OPTIONS.patch | 6 +- ...ts.h-in-B-instead-of-S-and-t-oe-in-B.patch | 14 +- .../0008-fortran-cross-compile-hack.patch | 6 +- .../0009-cpp-honor-sysroot.patch | 6 +- .../0010-MIPS64-Default-to-N64-ABI.patch | 8 +- ...AMIC_LINKER-and-UCLIBC_DYNAMIC_LINKE.patch | 7 +- ...gcc-Fix-argument-list-too-long-error.patch | 10 +- .../0013-Disable-sdt.patch | 20 +- .../{gcc-9.2 => gcc-9.3}/0014-libtool.patch | 6 +- ...s-fix-v4bx-to-linker-to-support-EABI.patch | 6 +- ...-config-files-from-B-instead-of-usin.patch | 14 +- ...ir-from-.la-which-usually-points-to-.patch | 6 +- .../0018-export-CPP.patch | 6 +- ...e-target-gcc-headers-can-be-included.patch | 19 +- ...ild-with-disable-dependency-tracking.patch | 6 +- ...t-directory-during-relink-if-inst_pr.patch | 6 +- ...IR-replacement-instead-of-hardcoding.patch | 6 +- ...23-aarch64-Add-support-for-musl-ldso.patch | 6 +- ...-fix-libcc1-s-install-path-and-rpath.patch | 6 +- ...le-sysroot-support-for-nativesdk-gcc.patch | 187 +------ ...sroot-gcc-version-specific-dirs-with.patch | 12 +- ...ous-_FOR_BUILD-and-related-variables.patch | 14 +- ...028-nios2-Define-MUSL_DYNAMIC_LINKER.patch | 6 +- ...d-to-link-commandline-for-musl-targe.patch | 6 +- .../0030-ldbl128-config.patch} | 16 +- ...using-LDFLAGS-not-just-SHLIB_LDFLAGS.patch | 6 +- ...as-for-__cpu_indicator_init-instead-.patch | 10 +- .../0033-sync-gcc-stddef.h-with-musl.patch | 6 +- ...-fault-in-precompiled-header-generat.patch | 6 +- .../0035-Fix-for-testsuite-failure.patch | 6 +- ...Re-introduce-spe-commandline-options.patch | 6 +- ...eck-zero-value-in-simple_object_elf.patch} | 24 +- ...-Do-not-use-__LINE__-for-maintainin.patch} | 21 +- ...nds-Don-t-match-user-defined-regs-o.patch} | 15 +- ...adian_9.2.bb => gcc-cross-canadian_9.3.bb} | 0 .../{gcc-cross_9.2.bb => gcc-cross_9.3.bb} | 0 ...cc-crosssdk_9.2.bb => gcc-crosssdk_9.3.bb} | 0 ...{gcc-runtime_9.2.bb => gcc-runtime_9.3.bb} | 0 ...anitizers_9.2.bb => gcc-sanitizers_9.3.bb} | 0 .../{gcc-source_9.2.bb => gcc-source_9.3.bb} | 0 .../gcc/{gcc_9.2.bb => gcc_9.3.bb} | 0 ...c-initial_9.2.bb => libgcc-initial_9.3.bb} | 0 .../gcc/{libgcc_9.2.bb => libgcc_9.3.bb} | 0 ...{libgfortran_9.2.bb => libgfortran_9.3.bb} | 0 55 files changed, 238 insertions(+), 1075 deletions(-) delete mode 100644 meta/recipes-devtools/gcc/gcc-9.2/0037-Fix-up-libsanitizer-build-with-master-glibc.patch delete mode 100644 meta/recipes-devtools/gcc/gcc-9.2/CVE-2019-15847_1.patch delete mode 100644 meta/recipes-devtools/gcc/gcc-9.2/CVE-2019-15847_2.patch delete mode 100644 meta/recipes-devtools/gcc/gcc-9.2/CVE-2019-15847_3.patch rename meta/recipes-devtools/gcc/{gcc-9.2.inc => gcc-9.3.inc} (87%) rename meta/recipes-devtools/gcc/{gcc-9.2 => gcc-9.3}/0001-gcc-4.3.1-ARCH_FLAGS_FOR_TARGET.patch (89%) rename meta/recipes-devtools/gcc/{gcc-9.2 => gcc-9.3}/0002-gcc-poison-system-directories.patch (92%) rename meta/recipes-devtools/gcc/{gcc-9.2 => gcc-9.3}/0003-gcc-4.3.3-SYSROOT_CFLAGS_FOR_TARGET.patch (95%) rename meta/recipes-devtools/gcc/{gcc-9.2 => gcc-9.3}/0004-64-bit-multilib-hack.patch (98%) rename meta/recipes-devtools/gcc/{gcc-9.2 => gcc-9.3}/0005-optional-libstdc.patch (94%) rename meta/recipes-devtools/gcc/{gcc-9.2 => gcc-9.3}/0006-COLLECT_GCC_OPTIONS.patch (89%) rename meta/recipes-devtools/gcc/{gcc-9.2 => gcc-9.3}/0007-Use-the-defaults.h-in-B-instead-of-S-and-t-oe-in-B.patch (91%) rename meta/recipes-devtools/gcc/{gcc-9.2 => gcc-9.3}/0008-fortran-cross-compile-hack.patch (91%) rename meta/recipes-devtools/gcc/{gcc-9.2 => gcc-9.3}/0009-cpp-honor-sysroot.patch (94%) rename meta/recipes-devtools/gcc/{gcc-9.2 => gcc-9.3}/0010-MIPS64-Default-to-N64-ABI.patch (89%) rename meta/recipes-devtools/gcc/{gcc-9.2 => gcc-9.3}/0011-Define-GLIBC_DYNAMIC_LINKER-and-UCLIBC_DYNAMIC_LINKE.patch (98%) rename meta/recipes-devtools/gcc/{gcc-9.2 => gcc-9.3}/0012-gcc-Fix-argument-list-too-long-error.patch (85%) rename meta/recipes-devtools/gcc/{gcc-9.2 => gcc-9.3}/0013-Disable-sdt.patch (89%) rename meta/recipes-devtools/gcc/{gcc-9.2 => gcc-9.3}/0014-libtool.patch (91%) rename meta/recipes-devtools/gcc/{gcc-9.2 => gcc-9.3}/0015-gcc-armv4-pass-fix-v4bx-to-linker-to-support-EABI.patch (91%) rename meta/recipes-devtools/gcc/{gcc-9.2 => gcc-9.3}/0016-Use-the-multilib-config-files-from-B-instead-of-usin.patch (89%) rename meta/recipes-devtools/gcc/{gcc-9.2 => gcc-9.3}/0017-Avoid-using-libdir-from-.la-which-usually-points-to-.patch (84%) rename meta/recipes-devtools/gcc/{gcc-9.2 => gcc-9.3}/0018-export-CPP.patch (95%) rename meta/recipes-devtools/gcc/{gcc-9.2 => gcc-9.3}/0019-Ensure-target-gcc-headers-can-be-included.patch (80%) rename meta/recipes-devtools/gcc/{gcc-9.2 => gcc-9.3}/0020-gcc-4.8-won-t-build-with-disable-dependency-tracking.patch (92%) rename meta/recipes-devtools/gcc/{gcc-9.2 => gcc-9.3}/0021-Don-t-search-host-directory-during-relink-if-inst_pr.patch (87%) rename meta/recipes-devtools/gcc/{gcc-9.2 => gcc-9.3}/0022-Use-SYSTEMLIBS_DIR-replacement-instead-of-hardcoding.patch (86%) rename meta/recipes-devtools/gcc/{gcc-9.2 => gcc-9.3}/0023-aarch64-Add-support-for-musl-ldso.patch (87%) rename meta/recipes-devtools/gcc/{gcc-9.2 => gcc-9.3}/0024-libcc1-fix-libcc1-s-install-path-and-rpath.patch (93%) rename meta/recipes-devtools/gcc/{gcc-9.2 => gcc-9.3}/0025-handle-sysroot-support-for-nativesdk-gcc.patch (55%) rename meta/recipes-devtools/gcc/{gcc-9.2 => gcc-9.3}/0026-Search-target-sysroot-gcc-version-specific-dirs-with.patch (90%) rename meta/recipes-devtools/gcc/{gcc-9.2 => gcc-9.3}/0027-Fix-various-_FOR_BUILD-and-related-variables.patch (94%) rename meta/recipes-devtools/gcc/{gcc-9.2 => gcc-9.3}/0028-nios2-Define-MUSL_DYNAMIC_LINKER.patch (84%) rename meta/recipes-devtools/gcc/{gcc-9.2 => gcc-9.3}/0029-Add-ssp_nonshared-to-link-commandline-for-musl-targe.patch (95%) rename meta/recipes-devtools/gcc/{gcc-9.2/0030-libgcc-Add-knob-to-use-ldbl-128-on-ppc.patch => gcc-9.3/0030-ldbl128-config.patch} (84%) rename meta/recipes-devtools/gcc/{gcc-9.2 => gcc-9.3}/0031-Link-libgcc-using-LDFLAGS-not-just-SHLIB_LDFLAGS.patch (86%) rename meta/recipes-devtools/gcc/{gcc-9.2 => gcc-9.3}/0032-libgcc_s-Use-alias-for-__cpu_indicator_init-instead-.patch (92%) rename meta/recipes-devtools/gcc/{gcc-9.2 => gcc-9.3}/0033-sync-gcc-stddef.h-with-musl.patch (95%) rename meta/recipes-devtools/gcc/{gcc-9.2 => gcc-9.3}/0034-fix-segmentation-fault-in-precompiled-header-generat.patch (93%) rename meta/recipes-devtools/gcc/{gcc-9.2 => gcc-9.3}/0035-Fix-for-testsuite-failure.patch (98%) rename meta/recipes-devtools/gcc/{gcc-9.2 => gcc-9.3}/0036-Re-introduce-spe-commandline-options.patch (88%) rename meta/recipes-devtools/gcc/{gcc-9.2/CVE-2019-14250.patch => gcc-9.3/0037-CVE-2019-14250-Check-zero-value-in-simple_object_elf.patch} (59%) rename meta/recipes-devtools/gcc/{gcc-9.2/gen-no-line-numbers.patch => gcc-9.3/0038-gentypes-genmodes-Do-not-use-__LINE__-for-maintainin.patch} (93%) rename meta/recipes-devtools/gcc/{gcc-9.2/re-PR-target-91102-aarch64-ICE-on-Linux-kernel-with-.patch => gcc-9.3/0039-process_alt_operands-Don-t-match-user-defined-regs-o.patch} (88%) rename meta/recipes-devtools/gcc/{gcc-cross-canadian_9.2.bb => gcc-cross-canadian_9.3.bb} (100%) rename meta/recipes-devtools/gcc/{gcc-cross_9.2.bb => gcc-cross_9.3.bb} (100%) rename meta/recipes-devtools/gcc/{gcc-crosssdk_9.2.bb => gcc-crosssdk_9.3.bb} (100%) rename meta/recipes-devtools/gcc/{gcc-runtime_9.2.bb => gcc-runtime_9.3.bb} (100%) rename meta/recipes-devtools/gcc/{gcc-sanitizers_9.2.bb => gcc-sanitizers_9.3.bb} (100%) rename meta/recipes-devtools/gcc/{gcc-source_9.2.bb => gcc-source_9.3.bb} (100%) rename meta/recipes-devtools/gcc/{gcc_9.2.bb => gcc_9.3.bb} (100%) rename meta/recipes-devtools/gcc/{libgcc-initial_9.2.bb => libgcc-initial_9.3.bb} (100%) rename meta/recipes-devtools/gcc/{libgcc_9.2.bb => libgcc_9.3.bb} (100%) rename meta/recipes-devtools/gcc/{libgfortran_9.2.bb => libgfortran_9.3.bb} (100%) diff --git a/meta/conf/distro/include/maintainers.inc b/meta/conf/distro/include/maintainers.inc index 33f8044470..40e90f782b 100644 --- a/meta/conf/distro/include/maintainers.inc +++ b/meta/conf/distro/include/maintainers.inc @@ -194,7 +194,7 @@ RECIPE_MAINTAINER_pn-gcc-cross-canadian-${TRANSLATED_TARGET_ARCH} = "Khem Raj -Date: Sun, 22 Dec 2019 02:58:24 +0000 -Subject: [PATCH] Fix up libsanitizer build with master glibc - -2019-11-26 Jakub Jelinek - - PR sanitizer/92154 - * sanitizer_common/sanitizer_platform_limits_posix.h: Cherry-pick - llvm-project revision 947f9692440836dcb8d88b74b69dd379d85974ce. - * sanitizer_common/sanitizer_platform_limits_posix.cpp: Likewise. - -Upstream-Status: Backport [https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=b02486e0951bc0ed38310a03be73e479fc6f3e7a;hp=3feeac76ffc38427de2d7d086e2928e63eee2d44] -Signed-off-by: Auto Builder ---- - .../sanitizer_platform_limits_posix.cc | 5 +++-- - .../sanitizer_platform_limits_posix.h | 15 +-------------- - 2 files changed, 4 insertions(+), 16 deletions(-) - -diff --git a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc -index 6cd4a5bac..d823a1219 100644 ---- a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc -+++ b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc -@@ -1156,8 +1156,9 @@ CHECK_SIZE_AND_OFFSET(ipc_perm, uid); - CHECK_SIZE_AND_OFFSET(ipc_perm, gid); - CHECK_SIZE_AND_OFFSET(ipc_perm, cuid); - CHECK_SIZE_AND_OFFSET(ipc_perm, cgid); --#if !defined(__aarch64__) || !SANITIZER_LINUX || __GLIBC_PREREQ (2, 21) --/* On aarch64 glibc 2.20 and earlier provided incorrect mode field. */ -+#if !SANITIZER_LINUX || __GLIBC_PREREQ (2, 31) -+/* glibc 2.30 and earlier provided 16-bit mode field instead of 32-bit -+ on many architectures. */ - CHECK_SIZE_AND_OFFSET(ipc_perm, mode); - #endif - -diff --git a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h -index 73af92af1..6a673a7c9 100644 ---- a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h -+++ b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h -@@ -211,26 +211,13 @@ namespace __sanitizer { - u64 __unused1; - u64 __unused2; - #elif defined(__sparc__) --#if defined(__arch64__) - unsigned mode; -- unsigned short __pad1; --#else -- unsigned short __pad1; -- unsigned short mode; - unsigned short __pad2; --#endif - unsigned short __seq; - unsigned long long __unused1; - unsigned long long __unused2; --#elif defined(__mips__) || defined(__aarch64__) || defined(__s390x__) -- unsigned int mode; -- unsigned short __seq; -- unsigned short __pad1; -- unsigned long __unused1; -- unsigned long __unused2; - #else -- unsigned short mode; -- unsigned short __pad1; -+ unsigned int mode; - unsigned short __seq; - unsigned short __pad2; - #if defined(__x86_64__) && !defined(_LP64) --- -2.17.1 - diff --git a/meta/recipes-devtools/gcc/gcc-9.2/CVE-2019-15847_1.patch b/meta/recipes-devtools/gcc/gcc-9.2/CVE-2019-15847_1.patch deleted file mode 100644 index 227fd47c95..0000000000 --- a/meta/recipes-devtools/gcc/gcc-9.2/CVE-2019-15847_1.patch +++ /dev/null @@ -1,521 +0,0 @@ -From 8c61566116d23063ff597271884f8e00d94ab1a1 Mon Sep 17 00:00:00 2001 -From: segher -Date: Fri, 30 Aug 2019 13:48:48 +0000 -Subject: [PATCH] Backport from trunk 2019-08-22 Segher Boessenkool - - - * config/rs6000/altivec.md (unspec): Delete UNSPEC_DARN, UNSPEC_DARN_32, - UNSPEC_DARN_RAW, UNSPEC_CMPRB, UNSPEC_CMPRB2, UNSPEC_CMPEQB; move to... - * config/rs6000/rs6000.md (unspec): ... here. - * config/rs6000/altivec.md (darn_32, darn_raw, darn, cmprb, - *cmprb_internal, setb_signed, setb_unsigned, cmprb2, *cmprb2_internal, - cmpeqb, *cmpeqb_internal): Delete, move to... - * config/rs6000/rs6000.md (darn_32, darn_raw, darn, cmprb, - *cmprb_internal, setb_signed, setb_unsigned, cmprb2, *cmprb2_internal, - cmpeqb, *cmpeqb_internal): ... here. - - -git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-9-branch at 275170 138bc75d-0d04-0410-961f-82ee72b054a4 - -Upstream-Status: Backport -CVE: CVE-2019-15847 p1 -Affects <= 9.2.0 -Dropped Changelog changes -Signed-off-by: Armin Kuster - ---- - gcc/config/rs6000/altivec.md | 223 ---------------------------------- - gcc/config/rs6000/rs6000.md | 224 +++++++++++++++++++++++++++++++++++ - 3 files changed, 239 insertions(+), 223 deletions(-) - -Index: gcc-9.2.0/gcc/config/rs6000/altivec.md -=================================================================== ---- gcc-9.2.0.orig/gcc/config/rs6000/altivec.md -+++ gcc-9.2.0/gcc/config/rs6000/altivec.md -@@ -80,9 +80,6 @@ - UNSPEC_VUPKHPX - UNSPEC_VUPKLPX - UNSPEC_CONVERT_4F32_8I16 -- UNSPEC_DARN -- UNSPEC_DARN_32 -- UNSPEC_DARN_RAW - UNSPEC_DST - UNSPEC_DSTT - UNSPEC_DSTST -@@ -161,9 +158,6 @@ - UNSPEC_BCDADD - UNSPEC_BCDSUB - UNSPEC_BCD_OVERFLOW -- UNSPEC_CMPRB -- UNSPEC_CMPRB2 -- UNSPEC_CMPEQB - UNSPEC_VRLMI - UNSPEC_VRLNM - ]) -@@ -4101,223 +4095,6 @@ - "bcd. %0,%1,%2,%3" - [(set_attr "type" "vecsimple")]) - --(define_insn "darn_32" -- [(set (match_operand:SI 0 "register_operand" "=r") -- (unspec:SI [(const_int 0)] UNSPEC_DARN_32))] -- "TARGET_P9_MISC" -- "darn %0,0" -- [(set_attr "type" "integer")]) -- --(define_insn "darn_raw" -- [(set (match_operand:DI 0 "register_operand" "=r") -- (unspec:DI [(const_int 0)] UNSPEC_DARN_RAW))] -- "TARGET_P9_MISC && TARGET_64BIT" -- "darn %0,2" -- [(set_attr "type" "integer")]) -- --(define_insn "darn" -- [(set (match_operand:DI 0 "register_operand" "=r") -- (unspec:DI [(const_int 0)] UNSPEC_DARN))] -- "TARGET_P9_MISC && TARGET_64BIT" -- "darn %0,1" -- [(set_attr "type" "integer")]) -- --;; Test byte within range. --;; --;; The bytes of operand 1 are organized as xx:xx:xx:vv, where xx --;; represents a byte whose value is ignored in this context and --;; vv, the least significant byte, holds the byte value that is to --;; be tested for membership within the range specified by operand 2. --;; The bytes of operand 2 are organized as xx:xx:hi:lo. --;; --;; Return in target register operand 0 a value of 1 if lo <= vv and --;; vv <= hi. Otherwise, set register operand 0 to 0. --;; --;; Though the instructions to which this expansion maps operate on --;; 64-bit registers, the current implementation only operates on --;; SI-mode operands as the high-order bits provide no information --;; that is not already available in the low-order bits. To avoid the --;; costs of data widening operations, future enhancements might allow --;; DI mode for operand 0 and/or might allow operand 1 to be QI mode. --(define_expand "cmprb" -- [(set (match_dup 3) -- (unspec:CC [(match_operand:SI 1 "gpc_reg_operand" "r") -- (match_operand:SI 2 "gpc_reg_operand" "r")] -- UNSPEC_CMPRB)) -- (set (match_operand:SI 0 "gpc_reg_operand" "=r") -- (if_then_else:SI (lt (match_dup 3) -- (const_int 0)) -- (const_int -1) -- (if_then_else (gt (match_dup 3) -- (const_int 0)) -- (const_int 1) -- (const_int 0))))] -- "TARGET_P9_MISC" --{ -- operands[3] = gen_reg_rtx (CCmode); --}) -- --;; The bytes of operand 1 are organized as xx:xx:xx:vv, where xx --;; represents a byte whose value is ignored in this context and --;; vv, the least significant byte, holds the byte value that is to --;; be tested for membership within the range specified by operand 2. --;; The bytes of operand 2 are organized as xx:xx:hi:lo. --;; --;; Set bit 1 (the GT bit, 0x4) of CR register operand 0 to 1 if --;; lo <= vv and vv <= hi. Otherwise, set the GT bit to 0. The other --;; 3 bits of the target CR register are all set to 0. --(define_insn "*cmprb_internal" -- [(set (match_operand:CC 0 "cc_reg_operand" "=y") -- (unspec:CC [(match_operand:SI 1 "gpc_reg_operand" "r") -- (match_operand:SI 2 "gpc_reg_operand" "r")] -- UNSPEC_CMPRB))] -- "TARGET_P9_MISC" -- "cmprb %0,0,%1,%2" -- [(set_attr "type" "logical")]) -- --;; Set operand 0 register to -1 if the LT bit (0x8) of condition --;; register operand 1 is on. Otherwise, set operand 0 register to 1 --;; if the GT bit (0x4) of condition register operand 1 is on. --;; Otherwise, set operand 0 to 0. Note that the result stored into --;; register operand 0 is non-zero iff either the LT or GT bits are on --;; within condition register operand 1. --(define_insn "setb_signed" -- [(set (match_operand:SI 0 "gpc_reg_operand" "=r") -- (if_then_else:SI (lt (match_operand:CC 1 "cc_reg_operand" "y") -- (const_int 0)) -- (const_int -1) -- (if_then_else (gt (match_dup 1) -- (const_int 0)) -- (const_int 1) -- (const_int 0))))] -- "TARGET_P9_MISC" -- "setb %0,%1" -- [(set_attr "type" "logical")]) -- --(define_insn "setb_unsigned" -- [(set (match_operand:SI 0 "gpc_reg_operand" "=r") -- (if_then_else:SI (ltu (match_operand:CCUNS 1 "cc_reg_operand" "y") -- (const_int 0)) -- (const_int -1) -- (if_then_else (gtu (match_dup 1) -- (const_int 0)) -- (const_int 1) -- (const_int 0))))] -- "TARGET_P9_MISC" -- "setb %0,%1" -- [(set_attr "type" "logical")]) -- --;; Test byte within two ranges. --;; --;; The bytes of operand 1 are organized as xx:xx:xx:vv, where xx --;; represents a byte whose value is ignored in this context and --;; vv, the least significant byte, holds the byte value that is to --;; be tested for membership within the range specified by operand 2. --;; The bytes of operand 2 are organized as hi_1:lo_1:hi_2:lo_2. --;; --;; Return in target register operand 0 a value of 1 if (lo_1 <= vv and --;; vv <= hi_1) or if (lo_2 <= vv and vv <= hi_2). Otherwise, set register --;; operand 0 to 0. --;; --;; Though the instructions to which this expansion maps operate on --;; 64-bit registers, the current implementation only operates on --;; SI-mode operands as the high-order bits provide no information --;; that is not already available in the low-order bits. To avoid the --;; costs of data widening operations, future enhancements might allow --;; DI mode for operand 0 and/or might allow operand 1 to be QI mode. --(define_expand "cmprb2" -- [(set (match_dup 3) -- (unspec:CC [(match_operand:SI 1 "gpc_reg_operand" "r") -- (match_operand:SI 2 "gpc_reg_operand" "r")] -- UNSPEC_CMPRB2)) -- (set (match_operand:SI 0 "gpc_reg_operand" "=r") -- (if_then_else:SI (lt (match_dup 3) -- (const_int 0)) -- (const_int -1) -- (if_then_else (gt (match_dup 3) -- (const_int 0)) -- (const_int 1) -- (const_int 0))))] -- "TARGET_P9_MISC" --{ -- operands[3] = gen_reg_rtx (CCmode); --}) -- --;; The bytes of operand 1 are organized as xx:xx:xx:vv, where xx --;; represents a byte whose value is ignored in this context and --;; vv, the least significant byte, holds the byte value that is to --;; be tested for membership within the ranges specified by operand 2. --;; The bytes of operand 2 are organized as hi_1:lo_1:hi_2:lo_2. --;; --;; Set bit 1 (the GT bit, 0x4) of CR register operand 0 to 1 if --;; (lo_1 <= vv and vv <= hi_1) or if (lo_2 <= vv and vv <= hi_2). --;; Otherwise, set the GT bit to 0. The other 3 bits of the target --;; CR register are all set to 0. --(define_insn "*cmprb2_internal" -- [(set (match_operand:CC 0 "cc_reg_operand" "=y") -- (unspec:CC [(match_operand:SI 1 "gpc_reg_operand" "r") -- (match_operand:SI 2 "gpc_reg_operand" "r")] -- UNSPEC_CMPRB2))] -- "TARGET_P9_MISC" -- "cmprb %0,1,%1,%2" -- [(set_attr "type" "logical")]) -- --;; Test byte membership within set of 8 bytes. --;; --;; The bytes of operand 1 are organized as xx:xx:xx:vv, where xx --;; represents a byte whose value is ignored in this context and --;; vv, the least significant byte, holds the byte value that is to --;; be tested for membership within the set specified by operand 2. --;; The bytes of operand 2 are organized as e0:e1:e2:e3:e4:e5:e6:e7. --;; --;; Return in target register operand 0 a value of 1 if vv equals one --;; of the values e0, e1, e2, e3, e4, e5, e6, or e7. Otherwise, set --;; register operand 0 to 0. Note that the 8 byte values held within --;; operand 2 need not be unique. --;; --;; Though the instructions to which this expansion maps operate on --;; 64-bit registers, the current implementation requires that operands --;; 0 and 1 have mode SI as the high-order bits provide no information --;; that is not already available in the low-order bits. To avoid the --;; costs of data widening operations, future enhancements might allow --;; DI mode for operand 0 and/or might allow operand 1 to be QI mode. --(define_expand "cmpeqb" -- [(set (match_dup 3) -- (unspec:CC [(match_operand:SI 1 "gpc_reg_operand" "r") -- (match_operand:DI 2 "gpc_reg_operand" "r")] -- UNSPEC_CMPEQB)) -- (set (match_operand:SI 0 "gpc_reg_operand" "=r") -- (if_then_else:SI (lt (match_dup 3) -- (const_int 0)) -- (const_int -1) -- (if_then_else (gt (match_dup 3) -- (const_int 0)) -- (const_int 1) -- (const_int 0))))] -- "TARGET_P9_MISC && TARGET_64BIT" --{ -- operands[3] = gen_reg_rtx (CCmode); --}) -- --;; The bytes of operand 1 are organized as xx:xx:xx:vv, where xx --;; represents a byte whose value is ignored in this context and --;; vv, the least significant byte, holds the byte value that is to --;; be tested for membership within the set specified by operand 2. --;; The bytes of operand 2 are organized as e0:e1:e2:e3:e4:e5:e6:e7. --;; --;; Set bit 1 (the GT bit, 0x4) of CR register operand 0 to 1 if vv --;; equals one of the values e0, e1, e2, e3, e4, e5, e6, or e7. Otherwise, --;; set the GT bit to zero. The other 3 bits of the target CR register --;; are all set to 0. --(define_insn "*cmpeqb_internal" -- [(set (match_operand:CC 0 "cc_reg_operand" "=y") -- (unspec:CC [(match_operand:SI 1 "gpc_reg_operand" "r") -- (match_operand:DI 2 "gpc_reg_operand" "r")] -- UNSPEC_CMPEQB))] -- "TARGET_P9_MISC && TARGET_64BIT" -- "cmpeqb %0,%1,%2" -- [(set_attr "type" "logical")]) -- - (define_expand "bcd_" - [(parallel [(set (reg:CCFP CR6_REGNO) - (compare:CCFP -Index: gcc-9.2.0/gcc/config/rs6000/rs6000.md -=================================================================== ---- gcc-9.2.0.orig/gcc/config/rs6000/rs6000.md -+++ gcc-9.2.0/gcc/config/rs6000/rs6000.md -@@ -137,6 +137,12 @@ - UNSPEC_LSQ - UNSPEC_FUSION_GPR - UNSPEC_STACK_CHECK -+ UNSPEC_DARN -+ UNSPEC_DARN_32 -+ UNSPEC_DARN_RAW -+ UNSPEC_CMPRB -+ UNSPEC_CMPRB2 -+ UNSPEC_CMPEQB - UNSPEC_ADD_ROUND_TO_ODD - UNSPEC_SUB_ROUND_TO_ODD - UNSPEC_MUL_ROUND_TO_ODD -@@ -14322,7 +14328,225 @@ - "xscmpuqp %0,%1,%2" - [(set_attr "type" "veccmp") - (set_attr "size" "128")]) -+ -+;; Miscellaneous ISA 3.0 (power9) instructions -+ -+(define_insn "darn_32" -+ [(set (match_operand:SI 0 "register_operand" "=r") -+ (unspec:SI [(const_int 0)] UNSPEC_DARN_32))] -+ "TARGET_P9_MISC" -+ "darn %0,0" -+ [(set_attr "type" "integer")]) -+ -+(define_insn "darn_raw" -+ [(set (match_operand:DI 0 "register_operand" "=r") -+ (unspec:DI [(const_int 0)] UNSPEC_DARN_RAW))] -+ "TARGET_P9_MISC && TARGET_64BIT" -+ "darn %0,2" -+ [(set_attr "type" "integer")]) -+ -+(define_insn "darn" -+ [(set (match_operand:DI 0 "register_operand" "=r") -+ (unspec:DI [(const_int 0)] UNSPEC_DARN))] -+ "TARGET_P9_MISC && TARGET_64BIT" -+ "darn %0,1" -+ [(set_attr "type" "integer")]) -+ -+;; Test byte within range. -+;; -+;; The bytes of operand 1 are organized as xx:xx:xx:vv, where xx -+;; represents a byte whose value is ignored in this context and -+;; vv, the least significant byte, holds the byte value that is to -+;; be tested for membership within the range specified by operand 2. -+;; The bytes of operand 2 are organized as xx:xx:hi:lo. -+;; -+;; Return in target register operand 0 a value of 1 if lo <= vv and -+;; vv <= hi. Otherwise, set register operand 0 to 0. -+;; -+;; Though the instructions to which this expansion maps operate on -+;; 64-bit registers, the current implementation only operates on -+;; SI-mode operands as the high-order bits provide no information -+;; that is not already available in the low-order bits. To avoid the -+;; costs of data widening operations, future enhancements might allow -+;; DI mode for operand 0 and/or might allow operand 1 to be QI mode. -+(define_expand "cmprb" -+ [(set (match_dup 3) -+ (unspec:CC [(match_operand:SI 1 "gpc_reg_operand" "r") -+ (match_operand:SI 2 "gpc_reg_operand" "r")] -+ UNSPEC_CMPRB)) -+ (set (match_operand:SI 0 "gpc_reg_operand" "=r") -+ (if_then_else:SI (lt (match_dup 3) -+ (const_int 0)) -+ (const_int -1) -+ (if_then_else (gt (match_dup 3) -+ (const_int 0)) -+ (const_int 1) -+ (const_int 0))))] -+ "TARGET_P9_MISC" -+{ -+ operands[3] = gen_reg_rtx (CCmode); -+}) -+ -+;; The bytes of operand 1 are organized as xx:xx:xx:vv, where xx -+;; represents a byte whose value is ignored in this context and -+;; vv, the least significant byte, holds the byte value that is to -+;; be tested for membership within the range specified by operand 2. -+;; The bytes of operand 2 are organized as xx:xx:hi:lo. -+;; -+;; Set bit 1 (the GT bit, 0x4) of CR register operand 0 to 1 if -+;; lo <= vv and vv <= hi. Otherwise, set the GT bit to 0. The other -+;; 3 bits of the target CR register are all set to 0. -+(define_insn "*cmprb_internal" -+ [(set (match_operand:CC 0 "cc_reg_operand" "=y") -+ (unspec:CC [(match_operand:SI 1 "gpc_reg_operand" "r") -+ (match_operand:SI 2 "gpc_reg_operand" "r")] -+ UNSPEC_CMPRB))] -+ "TARGET_P9_MISC" -+ "cmprb %0,0,%1,%2" -+ [(set_attr "type" "logical")]) -+ -+;; Set operand 0 register to -1 if the LT bit (0x8) of condition -+;; register operand 1 is on. Otherwise, set operand 0 register to 1 -+;; if the GT bit (0x4) of condition register operand 1 is on. -+;; Otherwise, set operand 0 to 0. Note that the result stored into -+;; register operand 0 is non-zero iff either the LT or GT bits are on -+;; within condition register operand 1. -+(define_insn "setb_signed" -+ [(set (match_operand:SI 0 "gpc_reg_operand" "=r") -+ (if_then_else:SI (lt (match_operand:CC 1 "cc_reg_operand" "y") -+ (const_int 0)) -+ (const_int -1) -+ (if_then_else (gt (match_dup 1) -+ (const_int 0)) -+ (const_int 1) -+ (const_int 0))))] -+ "TARGET_P9_MISC" -+ "setb %0,%1" -+ [(set_attr "type" "logical")]) - -+(define_insn "setb_unsigned" -+ [(set (match_operand:SI 0 "gpc_reg_operand" "=r") -+ (if_then_else:SI (ltu (match_operand:CCUNS 1 "cc_reg_operand" "y") -+ (const_int 0)) -+ (const_int -1) -+ (if_then_else (gtu (match_dup 1) -+ (const_int 0)) -+ (const_int 1) -+ (const_int 0))))] -+ "TARGET_P9_MISC" -+ "setb %0,%1" -+ [(set_attr "type" "logical")]) -+ -+;; Test byte within two ranges. -+;; -+;; The bytes of operand 1 are organized as xx:xx:xx:vv, where xx -+;; represents a byte whose value is ignored in this context and -+;; vv, the least significant byte, holds the byte value that is to -+;; be tested for membership within the range specified by operand 2. -+;; The bytes of operand 2 are organized as hi_1:lo_1:hi_2:lo_2. -+;; -+;; Return in target register operand 0 a value of 1 if (lo_1 <= vv and -+;; vv <= hi_1) or if (lo_2 <= vv and vv <= hi_2). Otherwise, set register -+;; operand 0 to 0. -+;; -+;; Though the instructions to which this expansion maps operate on -+;; 64-bit registers, the current implementation only operates on -+;; SI-mode operands as the high-order bits provide no information -+;; that is not already available in the low-order bits. To avoid the -+;; costs of data widening operations, future enhancements might allow -+;; DI mode for operand 0 and/or might allow operand 1 to be QI mode. -+(define_expand "cmprb2" -+ [(set (match_dup 3) -+ (unspec:CC [(match_operand:SI 1 "gpc_reg_operand" "r") -+ (match_operand:SI 2 "gpc_reg_operand" "r")] -+ UNSPEC_CMPRB2)) -+ (set (match_operand:SI 0 "gpc_reg_operand" "=r") -+ (if_then_else:SI (lt (match_dup 3) -+ (const_int 0)) -+ (const_int -1) -+ (if_then_else (gt (match_dup 3) -+ (const_int 0)) -+ (const_int 1) -+ (const_int 0))))] -+ "TARGET_P9_MISC" -+{ -+ operands[3] = gen_reg_rtx (CCmode); -+}) -+ -+;; The bytes of operand 1 are organized as xx:xx:xx:vv, where xx -+;; represents a byte whose value is ignored in this context and -+;; vv, the least significant byte, holds the byte value that is to -+;; be tested for membership within the ranges specified by operand 2. -+;; The bytes of operand 2 are organized as hi_1:lo_1:hi_2:lo_2. -+;; -+;; Set bit 1 (the GT bit, 0x4) of CR register operand 0 to 1 if -+;; (lo_1 <= vv and vv <= hi_1) or if (lo_2 <= vv and vv <= hi_2). -+;; Otherwise, set the GT bit to 0. The other 3 bits of the target -+;; CR register are all set to 0. -+(define_insn "*cmprb2_internal" -+ [(set (match_operand:CC 0 "cc_reg_operand" "=y") -+ (unspec:CC [(match_operand:SI 1 "gpc_reg_operand" "r") -+ (match_operand:SI 2 "gpc_reg_operand" "r")] -+ UNSPEC_CMPRB2))] -+ "TARGET_P9_MISC" -+ "cmprb %0,1,%1,%2" -+ [(set_attr "type" "logical")]) -+ -+;; Test byte membership within set of 8 bytes. -+;; -+;; The bytes of operand 1 are organized as xx:xx:xx:vv, where xx -+;; represents a byte whose value is ignored in this context and -+;; vv, the least significant byte, holds the byte value that is to -+;; be tested for membership within the set specified by operand 2. -+;; The bytes of operand 2 are organized as e0:e1:e2:e3:e4:e5:e6:e7. -+;; -+;; Return in target register operand 0 a value of 1 if vv equals one -+;; of the values e0, e1, e2, e3, e4, e5, e6, or e7. Otherwise, set -+;; register operand 0 to 0. Note that the 8 byte values held within -+;; operand 2 need not be unique. -+;; -+;; Though the instructions to which this expansion maps operate on -+;; 64-bit registers, the current implementation requires that operands -+;; 0 and 1 have mode SI as the high-order bits provide no information -+;; that is not already available in the low-order bits. To avoid the -+;; costs of data widening operations, future enhancements might allow -+;; DI mode for operand 0 and/or might allow operand 1 to be QI mode. -+(define_expand "cmpeqb" -+ [(set (match_dup 3) -+ (unspec:CC [(match_operand:SI 1 "gpc_reg_operand" "r") -+ (match_operand:DI 2 "gpc_reg_operand" "r")] -+ UNSPEC_CMPEQB)) -+ (set (match_operand:SI 0 "gpc_reg_operand" "=r") -+ (if_then_else:SI (lt (match_dup 3) -+ (const_int 0)) -+ (const_int -1) -+ (if_then_else (gt (match_dup 3) -+ (const_int 0)) -+ (const_int 1) -+ (const_int 0))))] -+ "TARGET_P9_MISC && TARGET_64BIT" -+{ -+ operands[3] = gen_reg_rtx (CCmode); -+}) -+ -+;; The bytes of operand 1 are organized as xx:xx:xx:vv, where xx -+;; represents a byte whose value is ignored in this context and -+;; vv, the least significant byte, holds the byte value that is to -+;; be tested for membership within the set specified by operand 2. -+;; The bytes of operand 2 are organized as e0:e1:e2:e3:e4:e5:e6:e7. -+;; -+;; Set bit 1 (the GT bit, 0x4) of CR register operand 0 to 1 if vv -+;; equals one of the values e0, e1, e2, e3, e4, e5, e6, or e7. Otherwise, -+;; set the GT bit to zero. The other 3 bits of the target CR register -+;; are all set to 0. -+(define_insn "*cmpeqb_internal" -+ [(set (match_operand:CC 0 "cc_reg_operand" "=y") -+ (unspec:CC [(match_operand:SI 1 "gpc_reg_operand" "r") -+ (match_operand:DI 2 "gpc_reg_operand" "r")] -+ UNSPEC_CMPEQB))] -+ "TARGET_P9_MISC && TARGET_64BIT" -+ "cmpeqb %0,%1,%2" -+ [(set_attr "type" "logical")]) - - - (include "sync.md") diff --git a/meta/recipes-devtools/gcc/gcc-9.2/CVE-2019-15847_2.patch b/meta/recipes-devtools/gcc/gcc-9.2/CVE-2019-15847_2.patch deleted file mode 100644 index de7a83c23f..0000000000 --- a/meta/recipes-devtools/gcc/gcc-9.2/CVE-2019-15847_2.patch +++ /dev/null @@ -1,77 +0,0 @@ -From 87bc784a7ca3a43182f7272241597a50d7491342 Mon Sep 17 00:00:00 2001 -From: segher -Date: Fri, 30 Aug 2019 13:51:26 +0000 -Subject: [PATCH] Backport from trunk 2019-08-22 Segher Boessenkool - - - PR target/91481 - * config/rs6000/rs6000.md (unspec): Delete UNSPEC_DARN, UNSPEC_DARN_32, - and UNSPEC_DARN_RAW. - (unspecv): New enumerator values UNSPECV_DARN, UNSPECV_DARN_32, and - UNSPECV_DARN_RAW. - (darn_32): Use an unspec_volatile, and UNSPECV_DARN_32. - (darn_raw): Use an unspec_volatile, and UNSPECV_DARN_RAW. - (darn): Use an unspec_volatile, and UNSPECV_DARN. - - -git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-9-branch at 275175 138bc75d-0d04-0410-961f-82ee72b054a4 - -Upstream-Status: Backport -CVE: CVE-2019-15847 p2 -Affects <= 9.2.0 -Dropped Changelog changes -Signed-off-by: Armin Kuster - ---- - gcc/config/rs6000/rs6000.md | 12 ++++++------ - 2 files changed, 20 insertions(+), 6 deletions(-) - -Index: gcc-9.2.0/gcc/config/rs6000/rs6000.md -=================================================================== ---- gcc-9.2.0.orig/gcc/config/rs6000/rs6000.md -+++ gcc-9.2.0/gcc/config/rs6000/rs6000.md -@@ -137,9 +137,6 @@ - UNSPEC_LSQ - UNSPEC_FUSION_GPR - UNSPEC_STACK_CHECK -- UNSPEC_DARN -- UNSPEC_DARN_32 -- UNSPEC_DARN_RAW - UNSPEC_CMPRB - UNSPEC_CMPRB2 - UNSPEC_CMPEQB -@@ -170,6 +167,9 @@ - UNSPECV_EH_RR ; eh_reg_restore - UNSPECV_ISYNC ; isync instruction - UNSPECV_MFTB ; move from time base -+ UNSPECV_DARN ; darn 1 (deliver a random number) -+ UNSPECV_DARN_32 ; darn 2 -+ UNSPECV_DARN_RAW ; darn 0 - UNSPECV_NLGR ; non-local goto receiver - UNSPECV_MFFS ; Move from FPSCR - UNSPECV_MFFSL ; Move from FPSCR light instruction version -@@ -14333,21 +14333,21 @@ - - (define_insn "darn_32" - [(set (match_operand:SI 0 "register_operand" "=r") -- (unspec:SI [(const_int 0)] UNSPEC_DARN_32))] -+ (unspec_volatile:SI [(const_int 0)] UNSPECV_DARN_32))] - "TARGET_P9_MISC" - "darn %0,0" - [(set_attr "type" "integer")]) - - (define_insn "darn_raw" - [(set (match_operand:DI 0 "register_operand" "=r") -- (unspec:DI [(const_int 0)] UNSPEC_DARN_RAW))] -+ (unspec_volatile:DI [(const_int 0)] UNSPECV_DARN_RAW))] - "TARGET_P9_MISC && TARGET_64BIT" - "darn %0,2" - [(set_attr "type" "integer")]) - - (define_insn "darn" - [(set (match_operand:DI 0 "register_operand" "=r") -- (unspec:DI [(const_int 0)] UNSPEC_DARN))] -+ (unspec_volatile:DI [(const_int 0)] UNSPECV_DARN))] - "TARGET_P9_MISC && TARGET_64BIT" - "darn %0,1" - [(set_attr "type" "integer")]) diff --git a/meta/recipes-devtools/gcc/gcc-9.2/CVE-2019-15847_3.patch b/meta/recipes-devtools/gcc/gcc-9.2/CVE-2019-15847_3.patch deleted file mode 100644 index ba7130ca7d..0000000000 --- a/meta/recipes-devtools/gcc/gcc-9.2/CVE-2019-15847_3.patch +++ /dev/null @@ -1,62 +0,0 @@ -From dc4c8dd9dbe70740ec7a684b0f35620249fb036a Mon Sep 17 00:00:00 2001 -From: segher -Date: Fri, 30 Aug 2019 13:53:11 +0000 -Subject: [PATCH] Backport from trunk 2019-08-23 Segher Boessenkool - - -gcc/testsuite/ - PR target/91481 - * gcc.target/powerpc/darn-3.c: New testcase. - - -git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-9-branch at 275176 138bc75d-0d04-0410-961f-82ee72b054a4 - -Upstream-Status: Backport -CVE: CVE-2019-15847 p3 -Affects <= 9.2.0 -Dropped Changelog changes -Signed-off-by: Armin Kuster - ---- - gcc/testsuite/ChangeLog | 6 ++++++ - gcc/testsuite/gcc.target/powerpc/darn-3.c | 16 ++++++++++++++++ - 2 files changed, 22 insertions(+) - create mode 100644 gcc/testsuite/gcc.target/powerpc/darn-3.c - -Index: gcc-9.2.0/gcc/testsuite/gcc.target/powerpc/darn-3.c -=================================================================== ---- /dev/null -+++ gcc-9.2.0/gcc/testsuite/gcc.target/powerpc/darn-3.c -@@ -0,0 +1,16 @@ -+/* { dg-do compile { target { powerpc*-*-* } } } */ -+/* { dg-skip-if "" { powerpc*-*-aix* } } */ -+/* { dg-options "-O2 -mdejagnu-cpu=power9" } */ -+ -+static int darn32(void) { return __builtin_darn_32(); } -+ -+int four(void) -+{ -+ int sum = 0; -+ int i; -+ for (i = 0; i < 4; i++) -+ sum += darn32(); -+ return sum; -+} -+ -+/* { dg-final { scan-assembler-times {(?n)\mdarn .*,0\M} 4 } } */ -Index: gcc-9.2.0/gcc/testsuite/ChangeLog -=================================================================== ---- gcc-9.2.0.orig/gcc/testsuite/ChangeLog -+++ gcc-9.2.0/gcc/testsuite/ChangeLog -@@ -1,3 +1,11 @@ -+2019-08-30 Segher Boessenkool -+ -+ Backport from trunk -+ 2019-08-23 Segher Boessenkool -+ -+ PR target/91481 -+ * gcc.target/powerpc/darn-3.c: New testcase. -+ - 2019-08-12 Release Manager - - * GCC 9.2.0 released. diff --git a/meta/recipes-devtools/gcc/gcc-9.2.inc b/meta/recipes-devtools/gcc/gcc-9.3.inc similarity index 87% rename from meta/recipes-devtools/gcc/gcc-9.2.inc rename to meta/recipes-devtools/gcc/gcc-9.3.inc index 2368f35867..b0411078d3 100644 --- a/meta/recipes-devtools/gcc/gcc-9.2.inc +++ b/meta/recipes-devtools/gcc/gcc-9.3.inc @@ -2,13 +2,13 @@ require gcc-common.inc # Third digit in PV should be incremented after a minor release -PV = "9.2.0" +PV = "9.3.0" # BINV should be incremented to a revision after a minor gcc release -BINV = "9.2.0" +BINV = "9.3.0" -FILESEXTRAPATHS =. "${FILE_DIRNAME}/gcc-9.2:${FILE_DIRNAME}/gcc-9.2/backport:" +FILESEXTRAPATHS =. "${FILE_DIRNAME}/gcc-9.3:${FILE_DIRNAME}/gcc-9.3/backport:" DEPENDS =+ "mpfr gmp libmpc zlib flex-native" NATIVEDEPS = "mpfr-native gmp-native libmpc-native zlib-native flex-native" @@ -57,25 +57,19 @@ SRC_URI = "\ file://0027-Fix-various-_FOR_BUILD-and-related-variables.patch \ file://0028-nios2-Define-MUSL_DYNAMIC_LINKER.patch \ file://0029-Add-ssp_nonshared-to-link-commandline-for-musl-targe.patch \ - file://0030-libgcc-Add-knob-to-use-ldbl-128-on-ppc.patch \ + file://0030-ldbl128-config.patch \ file://0031-Link-libgcc-using-LDFLAGS-not-just-SHLIB_LDFLAGS.patch \ file://0032-libgcc_s-Use-alias-for-__cpu_indicator_init-instead-.patch \ file://0033-sync-gcc-stddef.h-with-musl.patch \ file://0034-fix-segmentation-fault-in-precompiled-header-generat.patch \ file://0035-Fix-for-testsuite-failure.patch \ file://0036-Re-introduce-spe-commandline-options.patch \ - file://0037-Fix-up-libsanitizer-build-with-master-glibc.patch \ - file://CVE-2019-14250.patch \ - file://CVE-2019-15847_1.patch \ - file://CVE-2019-15847_2.patch \ - file://CVE-2019-15847_3.patch \ - file://re-PR-target-91102-aarch64-ICE-on-Linux-kernel-with-.patch \ - file://gen-no-line-numbers.patch \ + file://0037-CVE-2019-14250-Check-zero-value-in-simple_object_elf.patch \ + file://0038-gentypes-genmodes-Do-not-use-__LINE__-for-maintainin.patch \ + file://0039-process_alt_operands-Don-t-match-user-defined-regs-o.patch \ " S = "${TMPDIR}/work-shared/gcc-${PV}-${PR}/gcc-${PV}" -SRC_URI[md5sum] = "3818ad8600447f05349098232c2ddc78" -SRC_URI[sha256sum] = "ea6ef08f121239da5695f76c9b33637a118dcf63e24164422231917fa61fb206" - +SRC_URI[sha256sum] = "71e197867611f6054aa1119b13a0c0abac12834765fe2d81f35ac57f84f742d1" # For dev release snapshotting #S = "${TMPDIR}/work-shared/gcc-${PV}-${PR}/official-gcc-${RELEASE}" #B = "${WORKDIR}/gcc-${PV}/build.${HOST_SYS}.${TARGET_SYS}" diff --git a/meta/recipes-devtools/gcc/gcc-9.2/0001-gcc-4.3.1-ARCH_FLAGS_FOR_TARGET.patch b/meta/recipes-devtools/gcc/gcc-9.3/0001-gcc-4.3.1-ARCH_FLAGS_FOR_TARGET.patch similarity index 89% rename from meta/recipes-devtools/gcc/gcc-9.2/0001-gcc-4.3.1-ARCH_FLAGS_FOR_TARGET.patch rename to meta/recipes-devtools/gcc/gcc-9.3/0001-gcc-4.3.1-ARCH_FLAGS_FOR_TARGET.patch index 9065c304b5..0d9222df17 100644 --- a/meta/recipes-devtools/gcc/gcc-9.2/0001-gcc-4.3.1-ARCH_FLAGS_FOR_TARGET.patch +++ b/meta/recipes-devtools/gcc/gcc-9.3/0001-gcc-4.3.1-ARCH_FLAGS_FOR_TARGET.patch @@ -1,7 +1,7 @@ -From 863325ec3c6eb4987be63509ac407b2d13617342 Mon Sep 17 00:00:00 2001 +From 02b1789dbbb184726782b5038a4dd96515ec790c Mon Sep 17 00:00:00 2001 From: Khem Raj Date: Fri, 29 Mar 2013 08:37:11 +0400 -Subject: [PATCH 01/36] gcc-4.3.1: ARCH_FLAGS_FOR_TARGET +Subject: [PATCH 01/39] gcc-4.3.1: ARCH_FLAGS_FOR_TARGET Signed-off-by: Khem Raj @@ -38,5 +38,5 @@ index 9db4fd14aa2..aad93c4d183 100644 *" newlib "*) case " $target_configargs " in -- -2.22.1 +2.25.1 diff --git a/meta/recipes-devtools/gcc/gcc-9.2/0002-gcc-poison-system-directories.patch b/meta/recipes-devtools/gcc/gcc-9.3/0002-gcc-poison-system-directories.patch similarity index 92% rename from meta/recipes-devtools/gcc/gcc-9.2/0002-gcc-poison-system-directories.patch rename to meta/recipes-devtools/gcc/gcc-9.3/0002-gcc-poison-system-directories.patch index a1116e7509..f427ee67c1 100644 --- a/meta/recipes-devtools/gcc/gcc-9.2/0002-gcc-poison-system-directories.patch +++ b/meta/recipes-devtools/gcc/gcc-9.3/0002-gcc-poison-system-directories.patch @@ -1,7 +1,7 @@ -From 68e78bc15de215fa15c7d8b56bd2e2b0539b34fa Mon Sep 17 00:00:00 2001 +From 5368cd0293ce50a69ced6e4b25ba6c8d8e014256 Mon Sep 17 00:00:00 2001 From: Khem Raj Date: Fri, 29 Mar 2013 08:59:00 +0400 -Subject: [PATCH 02/36] gcc: poison-system-directories +Subject: [PATCH 02/39] gcc: poison-system-directories Add /sw/include and /opt/include based on the original zecke-no-host-includes.patch patch. The original patch checked for @@ -58,10 +58,10 @@ index a718ceaf3da..5713342efb1 100644 optimizer and back end) to be checked for dynamic type safety at runtime. This is quite expensive. */ diff --git a/gcc/configure b/gcc/configure -index 481071b4265..a6ea3a8a84c 100755 +index a065ba23728..2e26dd33310 100755 --- a/gcc/configure +++ b/gcc/configure -@@ -995,6 +995,7 @@ with_system_zlib +@@ -996,6 +996,7 @@ with_system_zlib enable_maintainer_mode enable_link_mutex enable_version_specific_runtime_libs @@ -69,7 +69,7 @@ index 481071b4265..a6ea3a8a84c 100755 enable_plugin enable_host_shared enable_libquadmath_support -@@ -1748,6 +1749,8 @@ Optional Features: +@@ -1749,6 +1750,8 @@ Optional Features: --enable-version-specific-runtime-libs specify that runtime libraries should be installed in a compiler-specific directory @@ -78,7 +78,7 @@ index 481071b4265..a6ea3a8a84c 100755 --enable-plugin enable plugin support --enable-host-shared build host code as shared libraries --disable-libquadmath-support -@@ -29750,6 +29753,19 @@ if test "${enable_version_specific_runtime_libs+set}" = set; then : +@@ -29753,6 +29756,19 @@ if test "${enable_version_specific_runtime_libs+set}" = set; then : fi @@ -99,10 +99,10 @@ index 481071b4265..a6ea3a8a84c 100755 diff --git a/gcc/configure.ac b/gcc/configure.ac -index ce2825580c6..d42bbd4fd1c 100644 +index 3a7251102ef..12d1d04e645 100644 --- a/gcc/configure.ac +++ b/gcc/configure.ac -@@ -6378,6 +6378,16 @@ AC_ARG_ENABLE(version-specific-runtime-libs, +@@ -6380,6 +6380,16 @@ AC_ARG_ENABLE(version-specific-runtime-libs, [specify that runtime libraries should be installed in a compiler-specific directory])]) @@ -120,10 +120,10 @@ index ce2825580c6..d42bbd4fd1c 100644 AC_SUBST(subdirs) AC_SUBST(srcdir) diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi -index 6ef36ce02aa..09414d8cc05 100644 +index 0ab6c9c6449..c3d3d51a28f 100644 --- a/gcc/doc/invoke.texi +++ b/gcc/doc/invoke.texi -@@ -332,6 +332,7 @@ Objective-C and Objective-C++ Dialects}. +@@ -333,6 +333,7 @@ Objective-C and Objective-C++ Dialects}. -Wpacked -Wpacked-bitfield-compat -Wpacked-not-aligned -Wpadded @gol -Wparentheses -Wno-pedantic-ms-format @gol -Wplacement-new -Wplacement-new=@var{n} @gol @@ -131,7 +131,7 @@ index 6ef36ce02aa..09414d8cc05 100644 -Wpointer-arith -Wpointer-compare -Wno-pointer-to-int-cast @gol -Wno-pragmas -Wno-prio-ctor-dtor -Wredundant-decls @gol -Wrestrict -Wno-return-local-addr @gol -@@ -6289,6 +6290,14 @@ made up of data only and thus requires no special treatment. But, for +@@ -6290,6 +6291,14 @@ made up of data only and thus requires no special treatment. But, for most targets, it is made up of code and thus requires the stack to be made executable in order for the program to work properly. @@ -199,5 +199,5 @@ index bcbe2082905..5752298bbf2 100644 /* Use given -I paths for #include "..." but not #include <...>, and -- -2.22.1 +2.25.1 diff --git a/meta/recipes-devtools/gcc/gcc-9.2/0003-gcc-4.3.3-SYSROOT_CFLAGS_FOR_TARGET.patch b/meta/recipes-devtools/gcc/gcc-9.3/0003-gcc-4.3.3-SYSROOT_CFLAGS_FOR_TARGET.patch similarity index 95% rename from meta/recipes-devtools/gcc/gcc-9.2/0003-gcc-4.3.3-SYSROOT_CFLAGS_FOR_TARGET.patch rename to meta/recipes-devtools/gcc/gcc-9.3/0003-gcc-4.3.3-SYSROOT_CFLAGS_FOR_TARGET.patch index 23039d2123..23ec5bce03 100644 --- a/meta/recipes-devtools/gcc/gcc-9.2/0003-gcc-4.3.3-SYSROOT_CFLAGS_FOR_TARGET.patch +++ b/meta/recipes-devtools/gcc/gcc-9.3/0003-gcc-4.3.3-SYSROOT_CFLAGS_FOR_TARGET.patch @@ -1,7 +1,7 @@ -From f8d60c4114acb92361c7b2f4a4561d4661e8da9d Mon Sep 17 00:00:00 2001 +From df90dbdba7a85c20bad95de71525f0f400a849d2 Mon Sep 17 00:00:00 2001 From: Khem Raj Date: Fri, 29 Mar 2013 09:08:31 +0400 -Subject: [PATCH 03/36] gcc-4.3.3: SYSROOT_CFLAGS_FOR_TARGET +Subject: [PATCH 03/39] gcc-4.3.3: SYSROOT_CFLAGS_FOR_TARGET Before committing, I noticed that PR/32161 was marked as a dup of PR/32009, but my previous patch did not fix it. @@ -69,5 +69,5 @@ index b121088d778..93aae5bb26f 100755 # the named directory are copied to $(tooldir)/sys-include. if test x"${with_headers}" != x && test x"${with_headers}" != xno ; then -- -2.22.1 +2.25.1 diff --git a/meta/recipes-devtools/gcc/gcc-9.2/0004-64-bit-multilib-hack.patch b/meta/recipes-devtools/gcc/gcc-9.3/0004-64-bit-multilib-hack.patch similarity index 98% rename from meta/recipes-devtools/gcc/gcc-9.2/0004-64-bit-multilib-hack.patch rename to meta/recipes-devtools/gcc/gcc-9.3/0004-64-bit-multilib-hack.patch index a79c40c1aa..17ec8986c1 100644 --- a/meta/recipes-devtools/gcc/gcc-9.2/0004-64-bit-multilib-hack.patch +++ b/meta/recipes-devtools/gcc/gcc-9.3/0004-64-bit-multilib-hack.patch @@ -1,7 +1,7 @@ -From c2081c51db589471ea713870c72f13999abda815 Mon Sep 17 00:00:00 2001 +From 2e00d0a9a809153f693659e977c1e0550665e65c Mon Sep 17 00:00:00 2001 From: Khem Raj Date: Fri, 29 Mar 2013 09:10:06 +0400 -Subject: [PATCH 04/36] 64-bit multilib hack. +Subject: [PATCH 04/39] 64-bit multilib hack. GCC has internal multilib handling code but it assumes a very specific rigid directory layout. The build system implementation of multilib layout is very generic and allows @@ -115,5 +115,5 @@ index f3c6e2be1d9..bd0393155fa 100644 rs6000-linux.o: $(srcdir)/config/rs6000/rs6000-linux.c $(COMPILE) $< -- -2.22.1 +2.25.1 diff --git a/meta/recipes-devtools/gcc/gcc-9.2/0005-optional-libstdc.patch b/meta/recipes-devtools/gcc/gcc-9.3/0005-optional-libstdc.patch similarity index 94% rename from meta/recipes-devtools/gcc/gcc-9.2/0005-optional-libstdc.patch rename to meta/recipes-devtools/gcc/gcc-9.3/0005-optional-libstdc.patch index f4fac91467..3c28aeac63 100644 --- a/meta/recipes-devtools/gcc/gcc-9.2/0005-optional-libstdc.patch +++ b/meta/recipes-devtools/gcc/gcc-9.3/0005-optional-libstdc.patch @@ -1,7 +1,7 @@ -From e7e504f4a90cfa395e7f8ee779f8c3ed687802ca Mon Sep 17 00:00:00 2001 +From 435e45592e944018f33bff32f1202b0872a23141 Mon Sep 17 00:00:00 2001 From: Khem Raj Date: Fri, 29 Mar 2013 09:12:56 +0400 -Subject: [PATCH 05/36] optional libstdc +Subject: [PATCH 05/39] optional libstdc gcc-runtime builds libstdc++ separately from gcc-cross-*. Its configure tests using g++ will not run correctly since by default the linker will try to link against libstdc++ @@ -52,7 +52,7 @@ index 6c4574a837d..0e2657f00ee 100644 library = -1; break; diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi -index 09414d8cc05..a43969bc9f0 100644 +index c3d3d51a28f..2f7ffe456c3 100644 --- a/gcc/doc/invoke.texi +++ b/gcc/doc/invoke.texi @@ -228,6 +228,9 @@ in the following sections. @@ -65,7 +65,7 @@ index 09414d8cc05..a43969bc9f0 100644 -fext-numeric-literals @gol -Wabi=@var{n} -Wabi-tag -Wconversion-null -Wctor-dtor-privacy @gol -Wdelete-non-virtual-dtor -Wdeprecated-copy -Wdeprecated-copy-dtor @gol -@@ -538,7 +541,7 @@ Objective-C and Objective-C++ Dialects}. +@@ -539,7 +542,7 @@ Objective-C and Objective-C++ Dialects}. -pie -pthread -r -rdynamic @gol -s -static -static-pie -static-libgcc -static-libstdc++ @gol -static-libasan -static-libtsan -static-liblsan -static-libubsan @gol @@ -74,7 +74,7 @@ index 09414d8cc05..a43969bc9f0 100644 -T @var{script} -Wl, at var{option} -Xlinker @var{option} @gol -u @var{symbol} -z @var{keyword}} -@@ -13312,6 +13315,33 @@ Specify that the program entry point is @var{entry}. The argument is +@@ -13321,6 +13324,33 @@ Specify that the program entry point is @var{entry}. The argument is interpreted by the linker; the GNU linker accepts either a symbol name or an address. @@ -121,5 +121,5 @@ index a2601a6bb06..cd6c6fc95db 100644 #endif -- -2.22.1 +2.25.1 diff --git a/meta/recipes-devtools/gcc/gcc-9.2/0006-COLLECT_GCC_OPTIONS.patch b/meta/recipes-devtools/gcc/gcc-9.3/0006-COLLECT_GCC_OPTIONS.patch similarity index 89% rename from meta/recipes-devtools/gcc/gcc-9.2/0006-COLLECT_GCC_OPTIONS.patch rename to meta/recipes-devtools/gcc/gcc-9.3/0006-COLLECT_GCC_OPTIONS.patch index 9f7e603f8c..906f3a7317 100644 --- a/meta/recipes-devtools/gcc/gcc-9.2/0006-COLLECT_GCC_OPTIONS.patch +++ b/meta/recipes-devtools/gcc/gcc-9.3/0006-COLLECT_GCC_OPTIONS.patch @@ -1,7 +1,7 @@ -From b9260cd3ac26b0302824ed466a548464c864d95f Mon Sep 17 00:00:00 2001 +From c99684477ec66f290ec74efe732acd3c24db7dcc Mon Sep 17 00:00:00 2001 From: Khem Raj Date: Fri, 29 Mar 2013 09:16:28 +0400 -Subject: [PATCH 06/36] COLLECT_GCC_OPTIONS +Subject: [PATCH 06/39] COLLECT_GCC_OPTIONS This patch adds --sysroot into COLLECT_GCC_OPTIONS which is used to invoke collect2. @@ -34,5 +34,5 @@ index cd6c6fc95db..7da9c5d457b 100644 { const char *const *args; -- -2.22.1 +2.25.1 diff --git a/meta/recipes-devtools/gcc/gcc-9.2/0007-Use-the-defaults.h-in-B-instead-of-S-and-t-oe-in-B.patch b/meta/recipes-devtools/gcc/gcc-9.3/0007-Use-the-defaults.h-in-B-instead-of-S-and-t-oe-in-B.patch similarity index 91% rename from meta/recipes-devtools/gcc/gcc-9.2/0007-Use-the-defaults.h-in-B-instead-of-S-and-t-oe-in-B.patch rename to meta/recipes-devtools/gcc/gcc-9.3/0007-Use-the-defaults.h-in-B-instead-of-S-and-t-oe-in-B.patch index 28f8fc2674..68a876cb95 100644 --- a/meta/recipes-devtools/gcc/gcc-9.2/0007-Use-the-defaults.h-in-B-instead-of-S-and-t-oe-in-B.patch +++ b/meta/recipes-devtools/gcc/gcc-9.3/0007-Use-the-defaults.h-in-B-instead-of-S-and-t-oe-in-B.patch @@ -1,7 +1,7 @@ -From 88e728dad53d48c4a19f15e19f66fd23f4820b4a Mon Sep 17 00:00:00 2001 +From d6f4edaab0ad0e742fb1e3a6f76908a2ac9927d5 Mon Sep 17 00:00:00 2001 From: Khem Raj Date: Fri, 29 Mar 2013 09:17:25 +0400 -Subject: [PATCH 07/36] Use the defaults.h in ${B} instead of ${S}, and t-oe in +Subject: [PATCH 07/39] Use the defaults.h in ${B} instead of ${S}, and t-oe in ${B} Use the defaults.h in ${B} instead of ${S}, and t-oe in ${B}, so that @@ -27,7 +27,7 @@ Signed-off-by: Hongxu Jia 4 files changed, 7 insertions(+), 7 deletions(-) diff --git a/gcc/Makefile.in b/gcc/Makefile.in -index 5f43d9de00e..41f0f592ff4 100644 +index abae872cd63..fef6c4c61e3 100644 --- a/gcc/Makefile.in +++ b/gcc/Makefile.in @@ -540,7 +540,7 @@ TARGET_SYSTEM_ROOT = @TARGET_SYSTEM_ROOT@ @@ -40,10 +40,10 @@ index 5f43d9de00e..41f0f592ff4 100644 TM_MULTILIB_CONFIG=@TM_MULTILIB_CONFIG@ TM_MULTILIB_EXCEPTIONS_CONFIG=@TM_MULTILIB_EXCEPTIONS_CONFIG@ diff --git a/gcc/configure b/gcc/configure -index a6ea3a8a84c..e3bcf8abe9a 100755 +index 2e26dd33310..ed7931daed3 100755 --- a/gcc/configure +++ b/gcc/configure -@@ -12341,8 +12341,8 @@ for f in $tm_file; do +@@ -12342,8 +12342,8 @@ for f in $tm_file; do tm_include_list="${tm_include_list} $f" ;; defaults.h ) @@ -55,7 +55,7 @@ index a6ea3a8a84c..e3bcf8abe9a 100755 * ) tm_file_list="${tm_file_list} \$(srcdir)/config/$f" diff --git a/gcc/configure.ac b/gcc/configure.ac -index d42bbd4fd1c..2ebc377a74d 100644 +index 12d1d04e645..e0500e30d50 100644 --- a/gcc/configure.ac +++ b/gcc/configure.ac @@ -1968,8 +1968,8 @@ for f in $tm_file; do @@ -92,5 +92,5 @@ index 308b87d0cc1..19068cbc24a 100644 # Add multiple inclusion protection guard, part two. -- -2.22.1 +2.25.1 diff --git a/meta/recipes-devtools/gcc/gcc-9.2/0008-fortran-cross-compile-hack.patch b/meta/recipes-devtools/gcc/gcc-9.3/0008-fortran-cross-compile-hack.patch similarity index 91% rename from meta/recipes-devtools/gcc/gcc-9.2/0008-fortran-cross-compile-hack.patch rename to meta/recipes-devtools/gcc/gcc-9.3/0008-fortran-cross-compile-hack.patch index 24e3abe0bb..6acd2b0cf9 100644 --- a/meta/recipes-devtools/gcc/gcc-9.2/0008-fortran-cross-compile-hack.patch +++ b/meta/recipes-devtools/gcc/gcc-9.3/0008-fortran-cross-compile-hack.patch @@ -1,7 +1,7 @@ -From 010f09f2963ede24e85134e5fab2fa627a9afa05 Mon Sep 17 00:00:00 2001 +From 2c514ada36ffbf70177909f633e9f68811de61e0 Mon Sep 17 00:00:00 2001 From: Khem Raj Date: Fri, 29 Mar 2013 09:20:01 +0400 -Subject: [PATCH 08/36] fortran cross-compile hack. +Subject: [PATCH 08/39] fortran cross-compile hack. * Fortran would have searched for arm-angstrom-gnueabi-gfortran but would have used used gfortan. For gcc_4.2.2.bb we want to use the gfortran compiler from our cross @@ -42,5 +42,5 @@ index 7cfce28ab69..6cd515ee1a4 100644 # extra LD Flags which are required for targets -- -2.22.1 +2.25.1 diff --git a/meta/recipes-devtools/gcc/gcc-9.2/0009-cpp-honor-sysroot.patch b/meta/recipes-devtools/gcc/gcc-9.3/0009-cpp-honor-sysroot.patch similarity index 94% rename from meta/recipes-devtools/gcc/gcc-9.2/0009-cpp-honor-sysroot.patch rename to meta/recipes-devtools/gcc/gcc-9.3/0009-cpp-honor-sysroot.patch index 6af0a0124a..5a9e527606 100644 --- a/meta/recipes-devtools/gcc/gcc-9.2/0009-cpp-honor-sysroot.patch +++ b/meta/recipes-devtools/gcc/gcc-9.3/0009-cpp-honor-sysroot.patch @@ -1,7 +1,7 @@ -From 45e9cd39d9c62454d46b9e9473a0c1034ceca15d Mon Sep 17 00:00:00 2001 +From 0a7c03a9cf925ba09a510a32e684f01ec5a50650 Mon Sep 17 00:00:00 2001 From: Khem Raj Date: Fri, 29 Mar 2013 09:22:00 +0400 -Subject: [PATCH 09/36] cpp: honor sysroot. +Subject: [PATCH 09/39] cpp: honor sysroot. Currently, if the gcc toolchain is relocated and installed from sstate, then you try and compile preprocessed source (.i or .ii files), the compiler will try and access the builtin sysroot location @@ -50,5 +50,5 @@ index 7da9c5d457b..4e7c45b268c 100644 {"@assembler", "%{!M:%{!MM:%{!E:%{!S:as %(asm_debug) %(asm_options) %i %A }}}}", 0, 0, 0}, -- -2.22.1 +2.25.1 diff --git a/meta/recipes-devtools/gcc/gcc-9.2/0010-MIPS64-Default-to-N64-ABI.patch b/meta/recipes-devtools/gcc/gcc-9.3/0010-MIPS64-Default-to-N64-ABI.patch similarity index 89% rename from meta/recipes-devtools/gcc/gcc-9.2/0010-MIPS64-Default-to-N64-ABI.patch rename to meta/recipes-devtools/gcc/gcc-9.3/0010-MIPS64-Default-to-N64-ABI.patch index bc0c6d5bed..a8103b951e 100644 --- a/meta/recipes-devtools/gcc/gcc-9.2/0010-MIPS64-Default-to-N64-ABI.patch +++ b/meta/recipes-devtools/gcc/gcc-9.3/0010-MIPS64-Default-to-N64-ABI.patch @@ -1,7 +1,7 @@ -From 1ff4108d707b34e399e9dc418ad1ecc42f72676d Mon Sep 17 00:00:00 2001 +From 374aab6a88200fbd7343467d97f7ee6455bbce61 Mon Sep 17 00:00:00 2001 From: Khem Raj Date: Fri, 29 Mar 2013 09:23:08 +0400 -Subject: [PATCH 10/36] MIPS64: Default to N64 ABI +Subject: [PATCH 10/39] MIPS64: Default to N64 ABI MIPS64 defaults to n32 ABI, this patch makes it so that it defaults to N64 ABI @@ -14,7 +14,7 @@ Upstream-Status: Inappropriate [OE config specific] 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/gcc/config.gcc b/gcc/config.gcc -index ddd3b8f4d9d..fdfc0bd3e82 100644 +index b2282ecdf0b..69c0e4a005b 100644 --- a/gcc/config.gcc +++ b/gcc/config.gcc @@ -2282,29 +2282,29 @@ mips*-*-linux*) # Linux MIPS, either endian. @@ -53,5 +53,5 @@ index ddd3b8f4d9d..fdfc0bd3e82 100644 ;; esac -- -2.22.1 +2.25.1 diff --git a/meta/recipes-devtools/gcc/gcc-9.2/0011-Define-GLIBC_DYNAMIC_LINKER-and-UCLIBC_DYNAMIC_LINKE.patch b/meta/recipes-devtools/gcc/gcc-9.3/0011-Define-GLIBC_DYNAMIC_LINKER-and-UCLIBC_DYNAMIC_LINKE.patch similarity index 98% rename from meta/recipes-devtools/gcc/gcc-9.2/0011-Define-GLIBC_DYNAMIC_LINKER-and-UCLIBC_DYNAMIC_LINKE.patch rename to meta/recipes-devtools/gcc/gcc-9.3/0011-Define-GLIBC_DYNAMIC_LINKER-and-UCLIBC_DYNAMIC_LINKE.patch index 66fb24d4cd..d9d563d0f7 100644 --- a/meta/recipes-devtools/gcc/gcc-9.2/0011-Define-GLIBC_DYNAMIC_LINKER-and-UCLIBC_DYNAMIC_LINKE.patch +++ b/meta/recipes-devtools/gcc/gcc-9.3/0011-Define-GLIBC_DYNAMIC_LINKER-and-UCLIBC_DYNAMIC_LINKE.patch @@ -1,7 +1,7 @@ -From 72fc3975bcd720b2f8040fa87cd23d3db4c5975a Mon Sep 17 00:00:00 2001 +From dcd7891d6aea5327969132fea6ca4c199f14e985 Mon Sep 17 00:00:00 2001 From: Khem Raj Date: Fri, 29 Mar 2013 09:24:50 +0400 -Subject: [PATCH] Define GLIBC_DYNAMIC_LINKER and UCLIBC_DYNAMIC_LINKER +Subject: [PATCH 11/39] Define GLIBC_DYNAMIC_LINKER and UCLIBC_DYNAMIC_LINKER relative to SYSTEMLIBS_DIR This patch defines GLIBC_DYNAMIC_LINKER and UCLIBC_DYNAMIC_LINKER @@ -241,3 +241,6 @@ index 789d1df4bd5..b920c680fb1 100644 #ifdef SPARC_BI_ARCH +-- +2.25.1 + diff --git a/meta/recipes-devtools/gcc/gcc-9.2/0012-gcc-Fix-argument-list-too-long-error.patch b/meta/recipes-devtools/gcc/gcc-9.3/0012-gcc-Fix-argument-list-too-long-error.patch similarity index 85% rename from meta/recipes-devtools/gcc/gcc-9.2/0012-gcc-Fix-argument-list-too-long-error.patch rename to meta/recipes-devtools/gcc/gcc-9.3/0012-gcc-Fix-argument-list-too-long-error.patch index 60539795c5..9d98878096 100644 --- a/meta/recipes-devtools/gcc/gcc-9.2/0012-gcc-Fix-argument-list-too-long-error.patch +++ b/meta/recipes-devtools/gcc/gcc-9.3/0012-gcc-Fix-argument-list-too-long-error.patch @@ -1,7 +1,7 @@ -From 2cb227cd8069c73242286f64183fb203f8d2618a Mon Sep 17 00:00:00 2001 +From faa0f712a67005ef0260f95eebe7c7c57a6f8360 Mon Sep 17 00:00:00 2001 From: Khem Raj Date: Fri, 29 Mar 2013 09:26:37 +0400 -Subject: [PATCH 12/36] gcc: Fix argument list too long error. +Subject: [PATCH 12/39] gcc: Fix argument list too long error. There would be an "Argument list too long" error when the build directory is longer than 200, this is caused by: @@ -23,10 +23,10 @@ Upstream-Status: Pending 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/Makefile.in b/gcc/Makefile.in -index 41f0f592ff4..0064a282488 100644 +index fef6c4c61e3..57cf7804f0a 100644 --- a/gcc/Makefile.in +++ b/gcc/Makefile.in -@@ -3537,7 +3537,7 @@ install-plugin: installdirs lang.install-plugin s-header-vars install-gengtype +@@ -3538,7 +3538,7 @@ install-plugin: installdirs lang.install-plugin s-header-vars install-gengtype # We keep the directory structure for files in config or c-family and .def # files. All other files are flattened to a single directory. $(mkinstalldirs) $(DESTDIR)$(plugin_includedir) @@ -36,5 +36,5 @@ index 41f0f592ff4..0064a282488 100644 for file in $$headers; do \ if [ -f $$file ] ; then \ -- -2.22.1 +2.25.1 diff --git a/meta/recipes-devtools/gcc/gcc-9.2/0013-Disable-sdt.patch b/meta/recipes-devtools/gcc/gcc-9.3/0013-Disable-sdt.patch similarity index 89% rename from meta/recipes-devtools/gcc/gcc-9.2/0013-Disable-sdt.patch rename to meta/recipes-devtools/gcc/gcc-9.3/0013-Disable-sdt.patch index a21a63c617..455858354f 100644 --- a/meta/recipes-devtools/gcc/gcc-9.2/0013-Disable-sdt.patch +++ b/meta/recipes-devtools/gcc/gcc-9.3/0013-Disable-sdt.patch @@ -1,7 +1,7 @@ -From aea5ffa9d704f4eb8fa93366884d3c26a1dbec49 Mon Sep 17 00:00:00 2001 +From 4df5a747265983092afd6fbc5329dd808cc1da3c Mon Sep 17 00:00:00 2001 From: Khem Raj Date: Fri, 29 Mar 2013 09:28:10 +0400 -Subject: [PATCH 13/36] Disable sdt. +Subject: [PATCH 13/39] Disable sdt. We don't list dtrace in DEPENDS so we shouldn't be depending on this header. It may or may not exist from preivous builds though. To be determinstic, disable @@ -25,10 +25,10 @@ Upstream-Status: Inappropriate [hack] 4 files changed, 19 insertions(+), 19 deletions(-) diff --git a/gcc/configure b/gcc/configure -index e3bcf8abe9a..1f1d22ca666 100755 +index ed7931daed3..52f52b0ec86 100755 --- a/gcc/configure +++ b/gcc/configure -@@ -29332,12 +29332,12 @@ fi +@@ -29333,12 +29333,12 @@ fi { $as_echo "$as_me:${as_lineno-$LINENO}: checking sys/sdt.h in the target C library" >&5 $as_echo_n "checking sys/sdt.h in the target C library... " >&6; } have_sys_sdt_h=no @@ -48,7 +48,7 @@ index e3bcf8abe9a..1f1d22ca666 100755 $as_echo "$have_sys_sdt_h" >&6; } diff --git a/gcc/configure.ac b/gcc/configure.ac -index 2ebc377a74d..ddc85197588 100644 +index e0500e30d50..242ad28ec83 100644 --- a/gcc/configure.ac +++ b/gcc/configure.ac @@ -5995,15 +5995,15 @@ fi @@ -77,10 +77,10 @@ index 2ebc377a74d..ddc85197588 100644 # Check if TFmode long double should be used by default or not. # Some glibc targets used DFmode long double, but with glibc 2.4 diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure -index 5acf79cba54..191bc6c5796 100755 +index 1225edc596b..3b89b880fc8 100755 --- a/libstdc++-v3/configure +++ b/libstdc++-v3/configure -@@ -22085,11 +22085,11 @@ ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5' +@@ -22325,11 +22325,11 @@ ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5' ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5' ac_compiler_gnu=$ac_cv_c_compiler_gnu @@ -96,10 +96,10 @@ index 5acf79cba54..191bc6c5796 100755 $as_echo "$glibcxx_cv_sys_sdt_h" >&6; } diff --git a/libstdc++-v3/configure.ac b/libstdc++-v3/configure.ac -index dadd8827b49..6b1ce9957d3 100644 +index d8455e41574..844cf1acbce 100644 --- a/libstdc++-v3/configure.ac +++ b/libstdc++-v3/configure.ac -@@ -230,7 +230,7 @@ GLIBCXX_CHECK_SC_NPROCESSORS_ONLN +@@ -232,7 +232,7 @@ GLIBCXX_CHECK_SC_NPROCESSORS_ONLN GLIBCXX_CHECK_SC_NPROC_ONLN GLIBCXX_CHECK_PTHREADS_NUM_PROCESSORS_NP GLIBCXX_CHECK_SYSCTL_HW_NCPU @@ -109,5 +109,5 @@ index dadd8827b49..6b1ce9957d3 100644 # Check for available headers. AC_CHECK_HEADERS([endian.h execinfo.h float.h fp.h ieeefp.h inttypes.h \ -- -2.22.1 +2.25.1 diff --git a/meta/recipes-devtools/gcc/gcc-9.2/0014-libtool.patch b/meta/recipes-devtools/gcc/gcc-9.3/0014-libtool.patch similarity index 91% rename from meta/recipes-devtools/gcc/gcc-9.2/0014-libtool.patch rename to meta/recipes-devtools/gcc/gcc-9.3/0014-libtool.patch index 7a8f3afecf..2953859238 100644 --- a/meta/recipes-devtools/gcc/gcc-9.2/0014-libtool.patch +++ b/meta/recipes-devtools/gcc/gcc-9.3/0014-libtool.patch @@ -1,7 +1,7 @@ -From 6c4d0c303ebc3e1c7e554d54a8bb807d77ed41fd Mon Sep 17 00:00:00 2001 +From 34977d994666a90983c96a9240dfa3540562da35 Mon Sep 17 00:00:00 2001 From: Khem Raj Date: Fri, 29 Mar 2013 09:29:11 +0400 -Subject: [PATCH 14/36] libtool +Subject: [PATCH 14/39] libtool libstdc++ from gcc-runtime gets created with -rpath=/usr/lib/../lib for qemux86-64 when running on am x86_64 build host. @@ -38,5 +38,5 @@ index 79f9ba89af5..8e222f7c16b 100644 oldlibs= if test -z "$rpath"; then -- -2.22.1 +2.25.1 diff --git a/meta/recipes-devtools/gcc/gcc-9.2/0015-gcc-armv4-pass-fix-v4bx-to-linker-to-support-EABI.patch b/meta/recipes-devtools/gcc/gcc-9.3/0015-gcc-armv4-pass-fix-v4bx-to-linker-to-support-EABI.patch similarity index 91% rename from meta/recipes-devtools/gcc/gcc-9.2/0015-gcc-armv4-pass-fix-v4bx-to-linker-to-support-EABI.patch rename to meta/recipes-devtools/gcc/gcc-9.3/0015-gcc-armv4-pass-fix-v4bx-to-linker-to-support-EABI.patch index d06ae27028..d4445244e2 100644 --- a/meta/recipes-devtools/gcc/gcc-9.2/0015-gcc-armv4-pass-fix-v4bx-to-linker-to-support-EABI.patch +++ b/meta/recipes-devtools/gcc/gcc-9.3/0015-gcc-armv4-pass-fix-v4bx-to-linker-to-support-EABI.patch @@ -1,7 +1,7 @@ -From c5662ff1e7dea2291b9cb7a83cfff3001dd31f53 Mon Sep 17 00:00:00 2001 +From 4558ba7fa020c111f9a204021a418c0ce55d77f9 Mon Sep 17 00:00:00 2001 From: Khem Raj Date: Fri, 29 Mar 2013 09:30:32 +0400 -Subject: [PATCH 15/36] gcc: armv4: pass fix-v4bx to linker to support EABI. +Subject: [PATCH 15/39] gcc: armv4: pass fix-v4bx to linker to support EABI. The LINK_SPEC for linux gets overwritten by linux-eabi.h which means the value of TARGET_FIX_V4BX_SPEC gets lost and as a result @@ -39,5 +39,5 @@ index e4ade2e2ab0..108863f69d2 100644 LINUX_TARGET_LINK_SPEC " " ANDROID_LINK_SPEC) -- -2.22.1 +2.25.1 diff --git a/meta/recipes-devtools/gcc/gcc-9.2/0016-Use-the-multilib-config-files-from-B-instead-of-usin.patch b/meta/recipes-devtools/gcc/gcc-9.3/0016-Use-the-multilib-config-files-from-B-instead-of-usin.patch similarity index 89% rename from meta/recipes-devtools/gcc/gcc-9.2/0016-Use-the-multilib-config-files-from-B-instead-of-usin.patch rename to meta/recipes-devtools/gcc/gcc-9.3/0016-Use-the-multilib-config-files-from-B-instead-of-usin.patch index 310caec4a1..6f0833ccda 100644 --- a/meta/recipes-devtools/gcc/gcc-9.2/0016-Use-the-multilib-config-files-from-B-instead-of-usin.patch +++ b/meta/recipes-devtools/gcc/gcc-9.3/0016-Use-the-multilib-config-files-from-B-instead-of-usin.patch @@ -1,7 +1,7 @@ -From e3b693b9d6dc9496f7c98a13b28182d23084215c Mon Sep 17 00:00:00 2001 +From 7effc632d65c2d72bf6fa32a219ec2f82fef9405 Mon Sep 17 00:00:00 2001 From: Khem Raj Date: Fri, 29 Mar 2013 09:33:04 +0400 -Subject: [PATCH 16/36] Use the multilib config files from ${B} instead of +Subject: [PATCH 16/39] Use the multilib config files from ${B} instead of using the ones from ${S} Use the multilib config files from ${B} instead of using the ones from ${S} @@ -18,10 +18,10 @@ Upstream-Status: Inappropriate [configuration] 2 files changed, 36 insertions(+), 8 deletions(-) diff --git a/gcc/configure b/gcc/configure -index 1f1d22ca666..911de2cf017 100755 +index 52f52b0ec86..a5f208af7cf 100755 --- a/gcc/configure +++ b/gcc/configure -@@ -12321,10 +12321,20 @@ done +@@ -12322,10 +12322,20 @@ done tmake_file_= for f in ${tmake_file} do @@ -46,7 +46,7 @@ index 1f1d22ca666..911de2cf017 100755 done tmake_file="${tmake_file_}" -@@ -12335,6 +12345,10 @@ tm_file_list="options.h" +@@ -12336,6 +12346,10 @@ tm_file_list="options.h" tm_include_list="options.h insn-constants.h" for f in $tm_file; do case $f in @@ -58,7 +58,7 @@ index 1f1d22ca666..911de2cf017 100755 f=`echo $f | sed 's/^..//'` tm_file_list="${tm_file_list} $f" diff --git a/gcc/configure.ac b/gcc/configure.ac -index ddc85197588..b413ae9bf25 100644 +index 242ad28ec83..b7a7ead1c02 100644 --- a/gcc/configure.ac +++ b/gcc/configure.ac @@ -1948,10 +1948,20 @@ done @@ -98,5 +98,5 @@ index ddc85197588..b413ae9bf25 100644 f=`echo $f | sed 's/^..//'` tm_file_list="${tm_file_list} $f" -- -2.22.1 +2.25.1 diff --git a/meta/recipes-devtools/gcc/gcc-9.2/0017-Avoid-using-libdir-from-.la-which-usually-points-to-.patch b/meta/recipes-devtools/gcc/gcc-9.3/0017-Avoid-using-libdir-from-.la-which-usually-points-to-.patch similarity index 84% rename from meta/recipes-devtools/gcc/gcc-9.2/0017-Avoid-using-libdir-from-.la-which-usually-points-to-.patch rename to meta/recipes-devtools/gcc/gcc-9.3/0017-Avoid-using-libdir-from-.la-which-usually-points-to-.patch index ad1d1d4eb0..96da013bf2 100644 --- a/meta/recipes-devtools/gcc/gcc-9.2/0017-Avoid-using-libdir-from-.la-which-usually-points-to-.patch +++ b/meta/recipes-devtools/gcc/gcc-9.3/0017-Avoid-using-libdir-from-.la-which-usually-points-to-.patch @@ -1,7 +1,7 @@ -From 09d9ccc1d471020949d1285a5276f17504fd60dd Mon Sep 17 00:00:00 2001 +From a2b2bf77621f344a849e55ab179ece8587d19234 Mon Sep 17 00:00:00 2001 From: Khem Raj Date: Fri, 20 Feb 2015 09:39:38 +0000 -Subject: [PATCH 17/36] Avoid using libdir from .la which usually points to a +Subject: [PATCH 17/39] Avoid using libdir from .la which usually points to a host path Upstream-Status: Inappropriate [embedded specific] @@ -27,5 +27,5 @@ index 8e222f7c16b..0a93b4e5c3b 100644 absdir="$libdir" fi -- -2.22.1 +2.25.1 diff --git a/meta/recipes-devtools/gcc/gcc-9.2/0018-export-CPP.patch b/meta/recipes-devtools/gcc/gcc-9.3/0018-export-CPP.patch similarity index 95% rename from meta/recipes-devtools/gcc/gcc-9.2/0018-export-CPP.patch rename to meta/recipes-devtools/gcc/gcc-9.3/0018-export-CPP.patch index 0f728ec542..2385099c25 100644 --- a/meta/recipes-devtools/gcc/gcc-9.2/0018-export-CPP.patch +++ b/meta/recipes-devtools/gcc/gcc-9.3/0018-export-CPP.patch @@ -1,7 +1,7 @@ -From 987338cd847a723de533bb317e452a60b1e52165 Mon Sep 17 00:00:00 2001 +From cafb6a621c05c1f238679d52fc026446f38c8af5 Mon Sep 17 00:00:00 2001 From: Khem Raj Date: Fri, 20 Feb 2015 09:40:59 +0000 -Subject: [PATCH 18/36] export CPP +Subject: [PATCH 18/39] export CPP The OE environment sets and exports CPP as being the target gcc. When building gcc-cross-canadian for a mingw targetted sdk, the following can be found @@ -49,5 +49,5 @@ index 64e091ba71d..255822e3f27 100644 CONFIG_SHELL="$(SHELL)"; export CONFIG_SHELL; \ CXX="$(CXX_FOR_BUILD)"; export CXX; \ -- -2.22.1 +2.25.1 diff --git a/meta/recipes-devtools/gcc/gcc-9.2/0019-Ensure-target-gcc-headers-can-be-included.patch b/meta/recipes-devtools/gcc/gcc-9.3/0019-Ensure-target-gcc-headers-can-be-included.patch similarity index 80% rename from meta/recipes-devtools/gcc/gcc-9.2/0019-Ensure-target-gcc-headers-can-be-included.patch rename to meta/recipes-devtools/gcc/gcc-9.3/0019-Ensure-target-gcc-headers-can-be-included.patch index 53f9e99d07..e0129d1f96 100644 --- a/meta/recipes-devtools/gcc/gcc-9.2/0019-Ensure-target-gcc-headers-can-be-included.patch +++ b/meta/recipes-devtools/gcc/gcc-9.3/0019-Ensure-target-gcc-headers-can-be-included.patch @@ -1,7 +1,7 @@ -From d27ba49e2e5c608c43265462d6831363cc7f565b Mon Sep 17 00:00:00 2001 +From 182057b80891edc0e8d46835e2d8bfd28330a55a Mon Sep 17 00:00:00 2001 From: Khem Raj Date: Fri, 20 Feb 2015 10:25:11 +0000 -Subject: [PATCH 19/36] Ensure target gcc headers can be included +Subject: [PATCH 19/39] Ensure target gcc headers can be included There are a few headers installed as part of the OpenEmbedded gcc-runtime target (omp.h, ssp/*.h). Being installed from a recipe @@ -18,10 +18,10 @@ Signed-off-by: Khem Raj --- gcc/Makefile.in | 2 ++ gcc/cppdefault.c | 4 ++++ - gcc/defaults.h | 9 +++++++++ - gcc/gcc.c | 7 ------- - 4 files changed, 15 insertions(+), 7 deletions(-) + 2 files changed, 6 insertions(+) +diff --git a/gcc/Makefile.in b/gcc/Makefile.in +index 57cf7804f0a..7772342ad5e 100644 --- a/gcc/Makefile.in +++ b/gcc/Makefile.in @@ -618,6 +618,7 @@ libexecdir = @libexecdir@ @@ -32,7 +32,7 @@ Signed-off-by: Khem Raj # Directory in which the compiler finds executables libexecsubdir = $(libexecdir)/gcc/$(real_target_noncanonical)/$(version)$(accel_dir_suffix) # Directory in which all plugin resources are installed -@@ -2866,6 +2867,7 @@ CFLAGS-intl.o += -DLOCALEDIR=\"$(localed +@@ -2867,6 +2868,7 @@ CFLAGS-intl.o += -DLOCALEDIR=\"$(localedir)\" PREPROCESSOR_DEFINES = \ -DGCC_INCLUDE_DIR=\"$(libsubdir)/include\" \ @@ -40,9 +40,11 @@ Signed-off-by: Khem Raj -DFIXED_INCLUDE_DIR=\"$(libsubdir)/include-fixed\" \ -DGPLUSPLUS_INCLUDE_DIR=\"$(gcc_gxx_include_dir)\" \ -DGPLUSPLUS_INCLUDE_DIR_ADD_SYSROOT=$(gcc_gxx_include_dir_add_sysroot) \ +diff --git a/gcc/cppdefault.c b/gcc/cppdefault.c +index c4796385643..980e2bd47a7 100644 --- a/gcc/cppdefault.c +++ b/gcc/cppdefault.c -@@ -59,6 +59,10 @@ const struct default_include cpp_include +@@ -59,6 +59,10 @@ const struct default_include cpp_include_defaults[] /* This is the dir for gcc's private headers. */ { GCC_INCLUDE_DIR, "GCC", 0, 0, 0, 0 }, #endif @@ -53,3 +55,6 @@ Signed-off-by: Khem Raj #ifdef LOCAL_INCLUDE_DIR /* /usr/local/include comes before the fixincluded header files. */ { LOCAL_INCLUDE_DIR, 0, 0, 1, 1, 2 }, +-- +2.25.1 + diff --git a/meta/recipes-devtools/gcc/gcc-9.2/0020-gcc-4.8-won-t-build-with-disable-dependency-tracking.patch b/meta/recipes-devtools/gcc/gcc-9.3/0020-gcc-4.8-won-t-build-with-disable-dependency-tracking.patch similarity index 92% rename from meta/recipes-devtools/gcc/gcc-9.2/0020-gcc-4.8-won-t-build-with-disable-dependency-tracking.patch rename to meta/recipes-devtools/gcc/gcc-9.3/0020-gcc-4.8-won-t-build-with-disable-dependency-tracking.patch index b0f96d06d4..1d2182140f 100644 --- a/meta/recipes-devtools/gcc/gcc-9.2/0020-gcc-4.8-won-t-build-with-disable-dependency-tracking.patch +++ b/meta/recipes-devtools/gcc/gcc-9.3/0020-gcc-4.8-won-t-build-with-disable-dependency-tracking.patch @@ -1,7 +1,7 @@ -From 83bcd4cc47ae63971c888c117abd00dfd506532c Mon Sep 17 00:00:00 2001 +From a4740f1290e6a602fbbfa27b863be2e3b2675685 Mon Sep 17 00:00:00 2001 From: Khem Raj Date: Fri, 20 Feb 2015 11:17:19 +0000 -Subject: [PATCH 20/36] gcc 4.8+ won't build with --disable-dependency-tracking +Subject: [PATCH 20/39] gcc 4.8+ won't build with --disable-dependency-tracking since the *.Ppo files don't get created unless --enable-dependency-tracking is true. @@ -50,5 +50,5 @@ index 29324e3e0ac..d5cdb4259ef 100644 M_IFUNC = $(if $(PAT_S),$(IFUNC_DEF) $(IFUNC_OPT)) M_FILE = $(PAT_BASE)_n.c -- -2.22.1 +2.25.1 diff --git a/meta/recipes-devtools/gcc/gcc-9.2/0021-Don-t-search-host-directory-during-relink-if-inst_pr.patch b/meta/recipes-devtools/gcc/gcc-9.3/0021-Don-t-search-host-directory-during-relink-if-inst_pr.patch similarity index 87% rename from meta/recipes-devtools/gcc/gcc-9.2/0021-Don-t-search-host-directory-during-relink-if-inst_pr.patch rename to meta/recipes-devtools/gcc/gcc-9.3/0021-Don-t-search-host-directory-during-relink-if-inst_pr.patch index f36ca29b9e..e363c7d445 100644 --- a/meta/recipes-devtools/gcc/gcc-9.2/0021-Don-t-search-host-directory-during-relink-if-inst_pr.patch +++ b/meta/recipes-devtools/gcc/gcc-9.3/0021-Don-t-search-host-directory-during-relink-if-inst_pr.patch @@ -1,7 +1,7 @@ -From 667cc8d43e8fb4ac09654ee408da482f96b09580 Mon Sep 17 00:00:00 2001 +From f3edad81d80dde5d64bf77e6abafda54db10b824 Mon Sep 17 00:00:00 2001 From: Khem Raj Date: Tue, 3 Mar 2015 08:21:19 +0000 -Subject: [PATCH 21/36] Don't search host directory during "relink" if +Subject: [PATCH 21/39] Don't search host directory during "relink" if $inst_prefix is provided http://lists.gnu.org/archive/html/libtool-patches/2011-01/msg00026.html @@ -34,5 +34,5 @@ index 0a93b4e5c3b..6de6ed2f9a0 100644 esac fi -- -2.22.1 +2.25.1 diff --git a/meta/recipes-devtools/gcc/gcc-9.2/0022-Use-SYSTEMLIBS_DIR-replacement-instead-of-hardcoding.patch b/meta/recipes-devtools/gcc/gcc-9.3/0022-Use-SYSTEMLIBS_DIR-replacement-instead-of-hardcoding.patch similarity index 86% rename from meta/recipes-devtools/gcc/gcc-9.2/0022-Use-SYSTEMLIBS_DIR-replacement-instead-of-hardcoding.patch rename to meta/recipes-devtools/gcc/gcc-9.3/0022-Use-SYSTEMLIBS_DIR-replacement-instead-of-hardcoding.patch index d5b9150023..846c0de5e8 100644 --- a/meta/recipes-devtools/gcc/gcc-9.2/0022-Use-SYSTEMLIBS_DIR-replacement-instead-of-hardcoding.patch +++ b/meta/recipes-devtools/gcc/gcc-9.3/0022-Use-SYSTEMLIBS_DIR-replacement-instead-of-hardcoding.patch @@ -1,7 +1,7 @@ -From 279c4de48e3fd61e2f268787ed3f1d69ed9224f8 Mon Sep 17 00:00:00 2001 +From b8ea2c2c7d33376f5dd651646c7e822000e47749 Mon Sep 17 00:00:00 2001 From: Khem Raj Date: Tue, 28 Apr 2015 23:15:27 -0700 -Subject: [PATCH 22/36] Use SYSTEMLIBS_DIR replacement instead of hardcoding +Subject: [PATCH 22/39] Use SYSTEMLIBS_DIR replacement instead of hardcoding base_libdir Upstream-Status: Pending @@ -25,5 +25,5 @@ index 5e8b34ded03..7e628bf661e 100644 #undef MUSL_DYNAMIC_LINKER #define MUSL_DYNAMIC_LINKER "/lib/ld-musl-aarch64%{mbig-endian:_be}%{mabi=ilp32:_ilp32}.so.1" -- -2.22.1 +2.25.1 diff --git a/meta/recipes-devtools/gcc/gcc-9.2/0023-aarch64-Add-support-for-musl-ldso.patch b/meta/recipes-devtools/gcc/gcc-9.3/0023-aarch64-Add-support-for-musl-ldso.patch similarity index 87% rename from meta/recipes-devtools/gcc/gcc-9.2/0023-aarch64-Add-support-for-musl-ldso.patch rename to meta/recipes-devtools/gcc/gcc-9.3/0023-aarch64-Add-support-for-musl-ldso.patch index f811306c31..102d6fc742 100644 --- a/meta/recipes-devtools/gcc/gcc-9.2/0023-aarch64-Add-support-for-musl-ldso.patch +++ b/meta/recipes-devtools/gcc/gcc-9.3/0023-aarch64-Add-support-for-musl-ldso.patch @@ -1,7 +1,7 @@ -From 1277d12058334087443828dfd57d44e3b1dfcc9a Mon Sep 17 00:00:00 2001 +From 8645b57e7c0dfd93afee5caeaa534c714f449ba1 Mon Sep 17 00:00:00 2001 From: Khem Raj Date: Tue, 28 Apr 2015 23:18:39 -0700 -Subject: [PATCH 23/36] aarch64: Add support for musl ldso +Subject: [PATCH 23/39] aarch64: Add support for musl ldso Upstream-Status: Pending @@ -24,5 +24,5 @@ index 7e628bf661e..1717cbe5471 100644 #undef ASAN_CC1_SPEC #define ASAN_CC1_SPEC "%{%:sanitize(address):-funwind-tables}" -- -2.22.1 +2.25.1 diff --git a/meta/recipes-devtools/gcc/gcc-9.2/0024-libcc1-fix-libcc1-s-install-path-and-rpath.patch b/meta/recipes-devtools/gcc/gcc-9.3/0024-libcc1-fix-libcc1-s-install-path-and-rpath.patch similarity index 93% rename from meta/recipes-devtools/gcc/gcc-9.2/0024-libcc1-fix-libcc1-s-install-path-and-rpath.patch rename to meta/recipes-devtools/gcc/gcc-9.3/0024-libcc1-fix-libcc1-s-install-path-and-rpath.patch index 298b0962f6..443e0a2ca6 100644 --- a/meta/recipes-devtools/gcc/gcc-9.2/0024-libcc1-fix-libcc1-s-install-path-and-rpath.patch +++ b/meta/recipes-devtools/gcc/gcc-9.3/0024-libcc1-fix-libcc1-s-install-path-and-rpath.patch @@ -1,7 +1,7 @@ -From 4a0487ad75accd780dd155aa59086cc4b11cfc47 Mon Sep 17 00:00:00 2001 +From b1666565e4e133ee41f32fa8032165bcb06afe9a Mon Sep 17 00:00:00 2001 From: Robert Yang Date: Sun, 5 Jul 2015 20:25:18 -0700 -Subject: [PATCH 24/36] libcc1: fix libcc1's install path and rpath +Subject: [PATCH 24/39] libcc1: fix libcc1's install path and rpath * Install libcc1.so and libcc1plugin.so into $(libexecdir)/gcc/$(target_noncanonical)/$(gcc_version), as what we @@ -50,5 +50,5 @@ index 7104b649026..2103c477468 100644 @ENABLE_PLUGIN_TRUE at cc1lib_LTLIBRARIES = libcc1.la shared_source = callbacks.cc callbacks.hh connection.cc connection.hh \ -- -2.22.1 +2.25.1 diff --git a/meta/recipes-devtools/gcc/gcc-9.2/0025-handle-sysroot-support-for-nativesdk-gcc.patch b/meta/recipes-devtools/gcc/gcc-9.3/0025-handle-sysroot-support-for-nativesdk-gcc.patch similarity index 55% rename from meta/recipes-devtools/gcc/gcc-9.2/0025-handle-sysroot-support-for-nativesdk-gcc.patch rename to meta/recipes-devtools/gcc/gcc-9.3/0025-handle-sysroot-support-for-nativesdk-gcc.patch index 2e7a444b58..c81a532c8f 100644 --- a/meta/recipes-devtools/gcc/gcc-9.2/0025-handle-sysroot-support-for-nativesdk-gcc.patch +++ b/meta/recipes-devtools/gcc/gcc-9.3/0025-handle-sysroot-support-for-nativesdk-gcc.patch @@ -1,7 +1,7 @@ -From a183c82ea2af934a8d30055a791dc1d80c9067a9 Mon Sep 17 00:00:00 2001 +From 7d614a84709d7dc4a2529c3d529e2da8541f9fd4 Mon Sep 17 00:00:00 2001 From: Khem Raj Date: Mon, 7 Dec 2015 23:39:54 +0000 -Subject: [PATCH 25/36] handle sysroot support for nativesdk-gcc +Subject: [PATCH 25/39] handle sysroot support for nativesdk-gcc Being able to build a nativesdk gcc is useful, particularly in cases where the host compiler may be of an incompatible version (or a 32 @@ -24,32 +24,22 @@ Upstream-Status: Inappropriate RP 2015/7/28 Signed-off-by: Khem Raj - -Added PREFIXVAR and EXEC_PREFIXVAR to support runtime relocation. Without -these as part of the gccrelocprefix the system can't do runtime relocation -if the executable is moved. (These paths were missed in the original -implementation.) - -Signed-off-by: Mark Hatle --- - c-family/c-opts.c | 4 +-- - cppdefault.c | 63 +++++++++++++++++++++++++++++++++--------------------- - cppdefault.h | 13 ++++------- - gcc.c | 20 ++++++++++++----- - incpath.c | 12 +++++----- - prefix.c | 4 +-- - 6 files changed, 68 insertions(+), 48 deletions(-) + gcc/cppdefault.c | 50 +++++++++++++++++++++++++++++++++++------------- + gcc/cppdefault.h | 3 ++- + gcc/gcc.c | 20 +++++++++++++------ + 3 files changed, 53 insertions(+), 20 deletions(-) -Index: gcc-9.2.0/gcc/cppdefault.c -=================================================================== ---- gcc-9.2.0.orig/gcc/cppdefault.c -+++ gcc-9.2.0/gcc/cppdefault.c +diff --git a/gcc/cppdefault.c b/gcc/cppdefault.c +index 980e2bd47a7..39b6059efdc 100644 +--- a/gcc/cppdefault.c ++++ b/gcc/cppdefault.c @@ -35,6 +35,30 @@ # undef CROSS_INCLUDE_DIR #endif +static char GPLUSPLUS_INCLUDE_DIRVAR[4096] __attribute__ ((section (".gccrelocprefix"))) = GPLUSPLUS_INCLUDE_DIR; -+char GCC_INCLUDE_DIRVAR[4096] __attribute__ ((section (".gccrelocprefix"))) = GCC_INCLUDE_DIR; ++static char GCC_INCLUDE_DIRVAR[4096] __attribute__ ((section (".gccrelocprefix"))) = GCC_INCLUDE_DIR; +static char GPLUSPLUS_TOOL_INCLUDE_DIRVAR[4096] __attribute__ ((section (".gccrelocprefix"))) = GPLUSPLUS_TOOL_INCLUDE_DIR; +static char GPLUSPLUS_BACKWARD_INCLUDE_DIRVAR[4096] __attribute__ ((section (".gccrelocprefix"))) = GPLUSPLUS_BACKWARD_INCLUDE_DIR; +static char STANDARD_STARTFILE_PREFIX_2VAR[4096] __attribute__ ((section (".gccrelocprefix"))) = STANDARD_STARTFILE_PREFIX_2 GCC_INCLUDE_SUBDIR_TARGET; @@ -75,7 +65,7 @@ Index: gcc-9.2.0/gcc/cppdefault.c const struct default_include cpp_include_defaults[] #ifdef INCLUDE_DEFAULTS = INCLUDE_DEFAULTS; -@@ -42,38 +66,38 @@ const struct default_include cpp_include +@@ -42,38 +66,38 @@ const struct default_include cpp_include_defaults[] = { #ifdef GPLUSPLUS_INCLUDE_DIR /* Pick up GNU C++ generic include files. */ @@ -123,7 +113,7 @@ Index: gcc-9.2.0/gcc/cppdefault.c /* A multilib suffix needs adding if different multilibs use different headers. */ #ifdef SYSROOT_HEADERS_SUFFIX_SPEC -@@ -85,33 +109,24 @@ const struct default_include cpp_include +@@ -85,16 +109,16 @@ const struct default_include cpp_include_defaults[] #endif #ifdef CROSS_INCLUDE_DIR /* One place the target system's headers might be. */ @@ -144,29 +134,10 @@ Index: gcc-9.2.0/gcc/cppdefault.c #endif { 0, 0, 0, 0, 0, 0 } }; - #endif /* no INCLUDE_DEFAULTS */ - --#ifdef GCC_INCLUDE_DIR --const char cpp_GCC_INCLUDE_DIR[] = GCC_INCLUDE_DIR; --const size_t cpp_GCC_INCLUDE_DIR_len = sizeof GCC_INCLUDE_DIR - 8; --#else --const char cpp_GCC_INCLUDE_DIR[] = ""; --const size_t cpp_GCC_INCLUDE_DIR_len = 0; --#endif -- - /* The configured prefix. */ --const char cpp_PREFIX[] = PREFIX; --const size_t cpp_PREFIX_len = sizeof PREFIX - 1; --const char cpp_EXEC_PREFIX[] = STANDARD_EXEC_PREFIX; -+char PREFIXVAR[4096] __attribute__ ((section (".gccrelocprefix"))) = PREFIX; -+char EXEC_PREFIXVAR[4096] __attribute__ ((section (".gccrelocprefix"))) = STANDARD_EXEC_PREFIX; - - /* This value is set by cpp_relocated at runtime */ - const char *gcc_exec_prefix; -Index: gcc-9.2.0/gcc/cppdefault.h -=================================================================== ---- gcc-9.2.0.orig/gcc/cppdefault.h -+++ gcc-9.2.0/gcc/cppdefault.h +diff --git a/gcc/cppdefault.h b/gcc/cppdefault.h +index e2d96f1e760..29fa5f815c8 100644 +--- a/gcc/cppdefault.h ++++ b/gcc/cppdefault.h @@ -33,7 +33,8 @@ struct default_include @@ -177,31 +148,10 @@ Index: gcc-9.2.0/gcc/cppdefault.h const char *const component; /* The component containing the directory (see update_path in prefix.c) */ const char cplusplus; /* Only look here if we're compiling C++. */ -@@ -50,17 +51,13 @@ struct default_include - }; - - extern const struct default_include cpp_include_defaults[]; --extern const char cpp_GCC_INCLUDE_DIR[]; --extern const size_t cpp_GCC_INCLUDE_DIR_len; -+extern char GCC_INCLUDE_DIRVAR[] __attribute__ ((section (".gccrelocprefix"))); - - /* The configure-time prefix, i.e., the value supplied as the argument - to --prefix=. */ --extern const char cpp_PREFIX[]; -+extern char PREFIXVAR[] __attribute__ ((section (".gccrelocprefix"))); - /* The length of the configure-time prefix. */ --extern const size_t cpp_PREFIX_len; --/* The configure-time execution prefix. This is typically the lib/gcc -- subdirectory of cpp_PREFIX. */ --extern const char cpp_EXEC_PREFIX[]; -+extern char EXEC_PREFIXVAR[] __attribute__ ((section (".gccrelocprefix"))); - /* The run-time execution prefix. This is typically the lib/gcc - subdirectory of the actual installation. */ - extern const char *gcc_exec_prefix; -Index: gcc-9.2.0/gcc/gcc.c -=================================================================== ---- gcc-9.2.0.orig/gcc/gcc.c -+++ gcc-9.2.0/gcc/gcc.c +diff --git a/gcc/gcc.c b/gcc/gcc.c +index 4e7c45b268c..59fb64f5fd5 100644 +--- a/gcc/gcc.c ++++ b/gcc/gcc.c @@ -253,6 +253,8 @@ FILE *report_times_to_file = NULL; #endif static const char *target_system_root = DEFAULT_TARGET_SYSTEM_ROOT; @@ -211,7 +161,7 @@ Index: gcc-9.2.0/gcc/gcc.c /* Nonzero means pass the updated target_system_root to the compiler. */ static int target_system_root_changed; -@@ -527,6 +529,7 @@ or with constant text in a single argume +@@ -527,6 +529,7 @@ or with constant text in a single argument. %G process LIBGCC_SPEC as a spec. %R Output the concatenation of target_system_root and target_sysroot_suffix. @@ -234,7 +184,7 @@ Index: gcc-9.2.0/gcc/gcc.c /* For native compilers, these are well-known paths containing components that may be provided by the system. For cross -@@ -1511,9 +1514,9 @@ static const char *const standard_startf +@@ -1511,9 +1514,9 @@ static const char *const standard_startfile_prefix = STANDARD_STARTFILE_PREFIX; static const char *md_exec_prefix = MD_EXEC_PREFIX; static const char *md_startfile_prefix = MD_STARTFILE_PREFIX; static const char *md_startfile_prefix_1 = MD_STARTFILE_PREFIX_1; @@ -246,7 +196,7 @@ Index: gcc-9.2.0/gcc/gcc.c = STANDARD_STARTFILE_PREFIX_2; /* A relative path to be used in finding the location of tools -@@ -5922,6 +5925,11 @@ do_spec_1 (const char *spec, int inswitc +@@ -5922,6 +5925,11 @@ do_spec_1 (const char *spec, int inswitch, const char *soft_matched_part) } break; @@ -258,89 +208,6 @@ Index: gcc-9.2.0/gcc/gcc.c case 'S': value = do_spec_1 (startfile_spec, 0, NULL); if (value != 0) -Index: gcc-9.2.0/gcc/c-family/c-opts.c -=================================================================== ---- gcc-9.2.0.orig/gcc/c-family/c-opts.c -+++ gcc-9.2.0/gcc/c-family/c-opts.c -@@ -1382,8 +1382,8 @@ add_prefixed_path (const char *suffix, i - size_t prefix_len, suffix_len; - - suffix_len = strlen (suffix); -- prefix = iprefix ? iprefix : cpp_GCC_INCLUDE_DIR; -- prefix_len = iprefix ? strlen (iprefix) : cpp_GCC_INCLUDE_DIR_len; -+ prefix = iprefix ? iprefix : GCC_INCLUDE_DIRVAR; -+ prefix_len = iprefix ? strlen (iprefix) : strlen(GCC_INCLUDE_DIRVAR) - 7; - - path = (char *) xmalloc (prefix_len + suffix_len + 1); - memcpy (path, prefix, prefix_len); -Index: gcc-9.2.0/gcc/incpath.c -=================================================================== ---- gcc-9.2.0.orig/gcc/incpath.c -+++ gcc-9.2.0/gcc/incpath.c -@@ -131,7 +131,7 @@ add_standard_paths (const char *sysroot, - int relocated = cpp_relocated (); - size_t len; - -- if (iprefix && (len = cpp_GCC_INCLUDE_DIR_len) != 0) -+ if (iprefix && (len = strlen(GCC_INCLUDE_DIRVAR) - 7) != 0) - { - /* Look for directories that start with the standard prefix. - "Translate" them, i.e. replace /usr/local/lib/gcc... with -@@ -145,7 +145,7 @@ add_standard_paths (const char *sysroot, - now. */ - if (sysroot && p->add_sysroot) - continue; -- if (!filename_ncmp (p->fname, cpp_GCC_INCLUDE_DIR, len)) -+ if (!filename_ncmp (p->fname, GCC_INCLUDE_DIRVAR, len)) - { - char *str = concat (iprefix, p->fname + len, NULL); - if (p->multilib == 1 && imultilib) -@@ -185,7 +185,7 @@ add_standard_paths (const char *sysroot, - free (sysroot_no_trailing_dir_separator); - } - else if (!p->add_sysroot && relocated -- && !filename_ncmp (p->fname, cpp_PREFIX, cpp_PREFIX_len)) -+ && !filename_ncmp (p->fname, PREFIXVAR, strlen(PREFIXVAR))) - { - static const char *relocated_prefix; - char *ostr; -@@ -202,12 +202,12 @@ add_standard_paths (const char *sysroot, - dummy = concat (gcc_exec_prefix, "dummy", NULL); - relocated_prefix - = make_relative_prefix (dummy, -- cpp_EXEC_PREFIX, -- cpp_PREFIX); -+ EXEC_PREFIXVAR, -+ PREFIXVAR); - free (dummy); - } - ostr = concat (relocated_prefix, -- p->fname + cpp_PREFIX_len, -+ p->fname + strlen(PREFIXVAR), - NULL); - str = update_path (ostr, p->component); - free (ostr); -Index: gcc-9.2.0/gcc/prefix.c -=================================================================== ---- gcc-9.2.0.orig/gcc/prefix.c -+++ gcc-9.2.0/gcc/prefix.c -@@ -72,7 +72,9 @@ License along with GCC; see the file COP - #include "prefix.h" - #include "common/common-target.h" - --static const char *std_prefix = PREFIX; -+static const char PREFIXVAR[4096] __attribute__ ((section (".gccrelocprefix"))) = PREFIX; -+ -+static const char *std_prefix = PREFIXVAR; - - static const char *get_key_value (char *); - static char *translate_name (char *); -@@ -212,7 +214,7 @@ translate_name (char *name) - prefix = getenv (key); - - if (prefix == 0) -- prefix = PREFIX; -+ prefix = PREFIXVAR; - - /* We used to strip trailing DIR_SEPARATORs here, but that can - sometimes yield a result with no separator when one was coded +-- +2.25.1 + diff --git a/meta/recipes-devtools/gcc/gcc-9.2/0026-Search-target-sysroot-gcc-version-specific-dirs-with.patch b/meta/recipes-devtools/gcc/gcc-9.3/0026-Search-target-sysroot-gcc-version-specific-dirs-with.patch similarity index 90% rename from meta/recipes-devtools/gcc/gcc-9.2/0026-Search-target-sysroot-gcc-version-specific-dirs-with.patch rename to meta/recipes-devtools/gcc/gcc-9.3/0026-Search-target-sysroot-gcc-version-specific-dirs-with.patch index fde206eb71..abfa7516da 100644 --- a/meta/recipes-devtools/gcc/gcc-9.2/0026-Search-target-sysroot-gcc-version-specific-dirs-with.patch +++ b/meta/recipes-devtools/gcc/gcc-9.3/0026-Search-target-sysroot-gcc-version-specific-dirs-with.patch @@ -1,7 +1,7 @@ -From dab4db14e319f3239a2b4c7d1fbf2971936e27ba Mon Sep 17 00:00:00 2001 +From 6c39a22c3e85d20dee9e2fc2274e95da980de4d0 Mon Sep 17 00:00:00 2001 From: Khem Raj Date: Mon, 7 Dec 2015 23:41:45 +0000 -Subject: [PATCH 26/36] Search target sysroot gcc version specific dirs with +Subject: [PATCH 26/39] Search target sysroot gcc version specific dirs with multilib. We install the gcc libraries (such as crtbegin.p) into @@ -51,10 +51,10 @@ Signed-off-by: Khem Raj 1 file changed, 28 insertions(+), 1 deletion(-) diff --git a/gcc/gcc.c b/gcc/gcc.c -index db0e2934038..1c21d1b08eb 100644 +index 59fb64f5fd5..3e79da4238c 100644 --- a/gcc/gcc.c +++ b/gcc/gcc.c -@@ -2610,7 +2610,7 @@ for_each_path (const struct path_prefix *paths, +@@ -2617,7 +2617,7 @@ for_each_path (const struct path_prefix *paths, if (path == NULL) { len = paths->max_len + extra_space + 1; @@ -63,7 +63,7 @@ index db0e2934038..1c21d1b08eb 100644 path = XNEWVEC (char, len); } -@@ -2622,6 +2622,33 @@ for_each_path (const struct path_prefix *paths, +@@ -2629,6 +2629,33 @@ for_each_path (const struct path_prefix *paths, /* Look first in MACHINE/VERSION subdirectory. */ if (!skip_multi_dir) { @@ -98,5 +98,5 @@ index db0e2934038..1c21d1b08eb 100644 ret = callback (path, callback_info); if (ret) -- -2.22.1 +2.25.1 diff --git a/meta/recipes-devtools/gcc/gcc-9.2/0027-Fix-various-_FOR_BUILD-and-related-variables.patch b/meta/recipes-devtools/gcc/gcc-9.3/0027-Fix-various-_FOR_BUILD-and-related-variables.patch similarity index 94% rename from meta/recipes-devtools/gcc/gcc-9.2/0027-Fix-various-_FOR_BUILD-and-related-variables.patch rename to meta/recipes-devtools/gcc/gcc-9.3/0027-Fix-various-_FOR_BUILD-and-related-variables.patch index 5d89e8e7e2..ae8acc7f13 100644 --- a/meta/recipes-devtools/gcc/gcc-9.2/0027-Fix-various-_FOR_BUILD-and-related-variables.patch +++ b/meta/recipes-devtools/gcc/gcc-9.3/0027-Fix-various-_FOR_BUILD-and-related-variables.patch @@ -1,7 +1,7 @@ -From 8e84bb09d2b7a60487a30e438bb109f31c2c254b Mon Sep 17 00:00:00 2001 +From 07db34b16b6c8e3d948b417f2fc052500ffb77d3 Mon Sep 17 00:00:00 2001 From: Khem Raj Date: Mon, 7 Dec 2015 23:42:45 +0000 -Subject: [PATCH 27/36] Fix various _FOR_BUILD and related variables +Subject: [PATCH 27/39] Fix various _FOR_BUILD and related variables When doing a FOR_BUILD thing, you have to override CFLAGS with CFLAGS_FOR_BUILD. And if you use C++, you also have to override @@ -94,7 +94,7 @@ index 41cae58a267..d3f6b79acdc 100644 CFLAGS="$(CFLAGS)"; export CFLAGS; \ CONFIG_SHELL="$(SHELL)"; export CONFIG_SHELL; \ diff --git a/gcc/Makefile.in b/gcc/Makefile.in -index 21472745c2c..8c93f03ffdc 100644 +index 7772342ad5e..02fec881b6d 100644 --- a/gcc/Makefile.in +++ b/gcc/Makefile.in @@ -805,7 +805,7 @@ BUILD_LDFLAGS=@BUILD_LDFLAGS@ @@ -107,10 +107,10 @@ index 21472745c2c..8c93f03ffdc 100644 # Actual name to use when installing a native compiler. GCC_INSTALL_NAME := $(shell echo gcc|sed '$(program_transform_name)') diff --git a/gcc/configure b/gcc/configure -index 911de2cf017..325ace34cdf 100755 +index a5f208af7cf..0788b7bf0b5 100755 --- a/gcc/configure +++ b/gcc/configure -@@ -11965,7 +11965,7 @@ else +@@ -11966,7 +11966,7 @@ else CC="${CC_FOR_BUILD}" CFLAGS="${CFLAGS_FOR_BUILD}" \ CXX="${CXX_FOR_BUILD}" CXXFLAGS="${CXXFLAGS_FOR_BUILD}" \ LD="${LD_FOR_BUILD}" LDFLAGS="${LDFLAGS_FOR_BUILD}" \ @@ -120,7 +120,7 @@ index 911de2cf017..325ace34cdf 100755 --enable-languages=${enable_languages-all} \ --target=$target_alias --host=$build_alias --build=$build_alias diff --git a/gcc/configure.ac b/gcc/configure.ac -index b413ae9bf25..72a6c95121b 100644 +index b7a7ead1c02..5ab50fae0f3 100644 --- a/gcc/configure.ac +++ b/gcc/configure.ac @@ -1743,7 +1743,7 @@ else @@ -133,5 +133,5 @@ index b413ae9bf25..72a6c95121b 100644 --enable-languages=${enable_languages-all} \ --target=$target_alias --host=$build_alias --build=$build_alias -- -2.22.1 +2.25.1 diff --git a/meta/recipes-devtools/gcc/gcc-9.2/0028-nios2-Define-MUSL_DYNAMIC_LINKER.patch b/meta/recipes-devtools/gcc/gcc-9.3/0028-nios2-Define-MUSL_DYNAMIC_LINKER.patch similarity index 84% rename from meta/recipes-devtools/gcc/gcc-9.2/0028-nios2-Define-MUSL_DYNAMIC_LINKER.patch rename to meta/recipes-devtools/gcc/gcc-9.3/0028-nios2-Define-MUSL_DYNAMIC_LINKER.patch index 84d92a337e..52a5d97aef 100644 --- a/meta/recipes-devtools/gcc/gcc-9.2/0028-nios2-Define-MUSL_DYNAMIC_LINKER.patch +++ b/meta/recipes-devtools/gcc/gcc-9.3/0028-nios2-Define-MUSL_DYNAMIC_LINKER.patch @@ -1,7 +1,7 @@ -From 5647f773e28b528a67800ef06ca44730f9f5dc7e Mon Sep 17 00:00:00 2001 +From 59543e897eb35194fb47288f7762e40a18fff611 Mon Sep 17 00:00:00 2001 From: Khem Raj Date: Tue, 2 Feb 2016 10:26:10 -0800 -Subject: [PATCH 28/36] nios2: Define MUSL_DYNAMIC_LINKER +Subject: [PATCH 28/39] nios2: Define MUSL_DYNAMIC_LINKER Upstream-Status: Pending @@ -24,5 +24,5 @@ index 698734add35..eeee60ecfea 100644 #undef LINK_SPEC #define LINK_SPEC LINK_SPEC_ENDIAN \ -- -2.22.1 +2.25.1 diff --git a/meta/recipes-devtools/gcc/gcc-9.2/0029-Add-ssp_nonshared-to-link-commandline-for-musl-targe.patch b/meta/recipes-devtools/gcc/gcc-9.3/0029-Add-ssp_nonshared-to-link-commandline-for-musl-targe.patch similarity index 95% rename from meta/recipes-devtools/gcc/gcc-9.2/0029-Add-ssp_nonshared-to-link-commandline-for-musl-targe.patch rename to meta/recipes-devtools/gcc/gcc-9.3/0029-Add-ssp_nonshared-to-link-commandline-for-musl-targe.patch index d19e5a08b9..bfa7e19dd0 100644 --- a/meta/recipes-devtools/gcc/gcc-9.2/0029-Add-ssp_nonshared-to-link-commandline-for-musl-targe.patch +++ b/meta/recipes-devtools/gcc/gcc-9.3/0029-Add-ssp_nonshared-to-link-commandline-for-musl-targe.patch @@ -1,7 +1,7 @@ -From 474043ca7a064ca7b0a32308a0ed6f7c546f17b2 Mon Sep 17 00:00:00 2001 +From 8df99af0a65ef740bcf2b7dc9a109cc57f15c3aa Mon Sep 17 00:00:00 2001 From: Khem Raj Date: Tue, 27 Jun 2017 18:10:54 -0700 -Subject: [PATCH 29/36] Add ssp_nonshared to link commandline for musl targets +Subject: [PATCH 29/39] Add ssp_nonshared to link commandline for musl targets when -fstack-protector options are enabled we need to link with ssp_shared on musl since it does not provide @@ -83,5 +83,5 @@ index 45a9a7cae59..d1e88a40e82 100644 %{!static-pie: \ %{rdynamic:-export-dynamic} \ -- -2.22.1 +2.25.1 diff --git a/meta/recipes-devtools/gcc/gcc-9.2/0030-libgcc-Add-knob-to-use-ldbl-128-on-ppc.patch b/meta/recipes-devtools/gcc/gcc-9.3/0030-ldbl128-config.patch similarity index 84% rename from meta/recipes-devtools/gcc/gcc-9.2/0030-libgcc-Add-knob-to-use-ldbl-128-on-ppc.patch rename to meta/recipes-devtools/gcc/gcc-9.3/0030-ldbl128-config.patch index 38eab5a083..f8e8c07f62 100644 --- a/meta/recipes-devtools/gcc/gcc-9.2/0030-libgcc-Add-knob-to-use-ldbl-128-on-ppc.patch +++ b/meta/recipes-devtools/gcc/gcc-9.3/0030-ldbl128-config.patch @@ -1,7 +1,7 @@ -From 47467f3ab0fb2f2fcede81060fe8bb339d0909eb Mon Sep 17 00:00:00 2001 +From 1bfae624b27ea4a1f5c5a92050d741b511e7b3d5 Mon Sep 17 00:00:00 2001 From: Szabolcs Nagy Date: Wed, 28 Feb 2018 00:54:05 +0000 -Subject: [PATCH 10/12] ldbl128 config +Subject: [PATCH 30/39] ldbl128 config Upstream-Status: Pending @@ -12,10 +12,10 @@ Signed-off-by: Khem Raj 2 files changed, 27 insertions(+), 2 deletions(-) diff --git a/gcc/configure b/gcc/configure -index 6121e163259..07ff8597d48 100755 +index 0788b7bf0b5..eb1a45bb263 100755 --- a/gcc/configure +++ b/gcc/configure -@@ -29309,6 +29309,15 @@ if test "${with_long_double_128+set}" = set; then : +@@ -29370,6 +29370,15 @@ if test "${with_long_double_128+set}" = set; then : withval=$with_long_double_128; gcc_cv_target_ldbl128="$with_long_double_128" else @@ -31,7 +31,7 @@ index 6121e163259..07ff8597d48 100755 if test $glibc_version_major -gt 2 \ || ( test $glibc_version_major -eq 2 && test $glibc_version_minor -ge 4 ); then : gcc_cv_target_ldbl128=yes -@@ -29320,6 +29329,10 @@ else +@@ -29381,6 +29390,10 @@ else && gcc_cv_target_ldbl128=yes fi @@ -43,10 +43,10 @@ index 6121e163259..07ff8597d48 100755 ;; diff --git a/gcc/configure.ac b/gcc/configure.ac -index b066cc609e1..6c15ed898c0 100644 +index 5ab50fae0f3..7ffe35ee1c3 100644 --- a/gcc/configure.ac +++ b/gcc/configure.ac -@@ -5971,13 +5971,25 @@ case "$target" in +@@ -6030,13 +6030,25 @@ case "$target" in AC_ARG_WITH(long-double-128, [AS_HELP_STRING([--with-long-double-128], [use 128-bit long double by default])], @@ -75,5 +75,5 @@ index b066cc609e1..6c15ed898c0 100644 esac if test x$gcc_cv_target_ldbl128 = xyes; then -- -2.17.1 +2.25.1 diff --git a/meta/recipes-devtools/gcc/gcc-9.2/0031-Link-libgcc-using-LDFLAGS-not-just-SHLIB_LDFLAGS.patch b/meta/recipes-devtools/gcc/gcc-9.3/0031-Link-libgcc-using-LDFLAGS-not-just-SHLIB_LDFLAGS.patch similarity index 86% rename from meta/recipes-devtools/gcc/gcc-9.2/0031-Link-libgcc-using-LDFLAGS-not-just-SHLIB_LDFLAGS.patch rename to meta/recipes-devtools/gcc/gcc-9.3/0031-Link-libgcc-using-LDFLAGS-not-just-SHLIB_LDFLAGS.patch index dc2141d70c..60a29fc94d 100644 --- a/meta/recipes-devtools/gcc/gcc-9.2/0031-Link-libgcc-using-LDFLAGS-not-just-SHLIB_LDFLAGS.patch +++ b/meta/recipes-devtools/gcc/gcc-9.3/0031-Link-libgcc-using-LDFLAGS-not-just-SHLIB_LDFLAGS.patch @@ -1,7 +1,7 @@ -From 266dcc78e4d9d38de2809118977d97dc9270cf1f Mon Sep 17 00:00:00 2001 +From 31d008f5573627c6192ce9fcf729f0be464a7cf5 Mon Sep 17 00:00:00 2001 From: Khem Raj Date: Wed, 4 May 2016 21:11:34 -0700 -Subject: [PATCH 31/36] Link libgcc using LDFLAGS, not just SHLIB_LDFLAGS +Subject: [PATCH 31/39] Link libgcc using LDFLAGS, not just SHLIB_LDFLAGS Upstream-Status: Pending @@ -25,5 +25,5 @@ index 099bf23e62f..436b277a79f 100644 $(SHLIB_OBJS) $(SHLIB_LC) && \ rm -f $(SHLIB_DIR)/$(SHLIB_SOLINK) && \ -- -2.22.1 +2.25.1 diff --git a/meta/recipes-devtools/gcc/gcc-9.2/0032-libgcc_s-Use-alias-for-__cpu_indicator_init-instead-.patch b/meta/recipes-devtools/gcc/gcc-9.3/0032-libgcc_s-Use-alias-for-__cpu_indicator_init-instead-.patch similarity index 92% rename from meta/recipes-devtools/gcc/gcc-9.2/0032-libgcc_s-Use-alias-for-__cpu_indicator_init-instead-.patch rename to meta/recipes-devtools/gcc/gcc-9.3/0032-libgcc_s-Use-alias-for-__cpu_indicator_init-instead-.patch index 8dde016ce5..6f048dab82 100644 --- a/meta/recipes-devtools/gcc/gcc-9.2/0032-libgcc_s-Use-alias-for-__cpu_indicator_init-instead-.patch +++ b/meta/recipes-devtools/gcc/gcc-9.3/0032-libgcc_s-Use-alias-for-__cpu_indicator_init-instead-.patch @@ -1,7 +1,7 @@ -From 9975b6ed3570bbf7c7d2d82f4d5f733d24ccacf5 Mon Sep 17 00:00:00 2001 +From 761fa6e3e37608cfd1b288e721a2ff89288cd6aa Mon Sep 17 00:00:00 2001 From: Szabolcs Nagy Date: Sat, 24 Oct 2015 20:09:53 +0000 -Subject: [PATCH 32/36] libgcc_s: Use alias for __cpu_indicator_init instead of +Subject: [PATCH 32/39] libgcc_s: Use alias for __cpu_indicator_init instead of symver Adapter from @@ -39,10 +39,10 @@ Signed-off-by: Khem Raj 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c -index 2b37296e537..dd380ddba88 100644 +index 1bca5a7eea6..096c4bc8e25 100644 --- a/gcc/config/i386/i386.c +++ b/gcc/config/i386/i386.c -@@ -36658,10 +36658,10 @@ ix86_expand_builtin (tree exp, rtx target, rtx subtarget, +@@ -36685,10 +36685,10 @@ ix86_expand_builtin (tree exp, rtx target, rtx subtarget, { case IX86_BUILTIN_CPU_INIT: { @@ -82,5 +82,5 @@ index 8506a635790..564296f788e 100644 +HOST_LIBGCC2_CFLAGS += -mlong-double-80 $(CET_FLAGS) CRTSTUFF_T_CFLAGS += $(CET_FLAGS) -- -2.22.1 +2.25.1 diff --git a/meta/recipes-devtools/gcc/gcc-9.2/0033-sync-gcc-stddef.h-with-musl.patch b/meta/recipes-devtools/gcc/gcc-9.3/0033-sync-gcc-stddef.h-with-musl.patch similarity index 95% rename from meta/recipes-devtools/gcc/gcc-9.2/0033-sync-gcc-stddef.h-with-musl.patch rename to meta/recipes-devtools/gcc/gcc-9.3/0033-sync-gcc-stddef.h-with-musl.patch index b99ac429a0..f080b0596f 100644 --- a/meta/recipes-devtools/gcc/gcc-9.2/0033-sync-gcc-stddef.h-with-musl.patch +++ b/meta/recipes-devtools/gcc/gcc-9.3/0033-sync-gcc-stddef.h-with-musl.patch @@ -1,7 +1,7 @@ -From 39e2f61d262f9f6c7a91068998dea80791ef665e Mon Sep 17 00:00:00 2001 +From 126e342fb39d7af70c1e5a6df8ffafc8dfc3bf08 Mon Sep 17 00:00:00 2001 From: Khem Raj Date: Fri, 3 Feb 2017 12:56:00 -0800 -Subject: [PATCH 33/36] sync gcc stddef.h with musl +Subject: [PATCH 33/39] sync gcc stddef.h with musl musl defines ptrdiff_t size_t and wchar_t so dont define them here if musl is definining them @@ -87,5 +87,5 @@ index da692e1c01a..9a00c261adb 100644 #endif /* _STDDEF_H or __need_wchar_t. */ -- -2.22.1 +2.25.1 diff --git a/meta/recipes-devtools/gcc/gcc-9.2/0034-fix-segmentation-fault-in-precompiled-header-generat.patch b/meta/recipes-devtools/gcc/gcc-9.3/0034-fix-segmentation-fault-in-precompiled-header-generat.patch similarity index 93% rename from meta/recipes-devtools/gcc/gcc-9.2/0034-fix-segmentation-fault-in-precompiled-header-generat.patch rename to meta/recipes-devtools/gcc/gcc-9.3/0034-fix-segmentation-fault-in-precompiled-header-generat.patch index 06a3c9f884..3b7ccb3e3d 100644 --- a/meta/recipes-devtools/gcc/gcc-9.2/0034-fix-segmentation-fault-in-precompiled-header-generat.patch +++ b/meta/recipes-devtools/gcc/gcc-9.3/0034-fix-segmentation-fault-in-precompiled-header-generat.patch @@ -1,7 +1,7 @@ -From aaa896a57b0004a74c1d474e74b21f41147a65cb Mon Sep 17 00:00:00 2001 +From d26fa9ededccc7e1ec47ead7f18afc80971483a3 Mon Sep 17 00:00:00 2001 From: Juro Bystricky Date: Mon, 19 Mar 2018 22:31:20 -0700 -Subject: [PATCH 34/36] fix segmentation fault in precompiled header generation +Subject: [PATCH 34/39] fix segmentation fault in precompiled header generation Prevent a segmentation fault which occurs when using incorrect structure trying to access name of some named operators, such as @@ -56,5 +56,5 @@ index eedfcbb3146..15040a1b1f0 100644 buffer = _cpp_spell_ident_ucns (buffer, token->val.node.node); break; -- -2.22.1 +2.25.1 diff --git a/meta/recipes-devtools/gcc/gcc-9.2/0035-Fix-for-testsuite-failure.patch b/meta/recipes-devtools/gcc/gcc-9.3/0035-Fix-for-testsuite-failure.patch similarity index 98% rename from meta/recipes-devtools/gcc/gcc-9.2/0035-Fix-for-testsuite-failure.patch rename to meta/recipes-devtools/gcc/gcc-9.3/0035-Fix-for-testsuite-failure.patch index 7470cbfcfc..5e199fbcfd 100644 --- a/meta/recipes-devtools/gcc/gcc-9.2/0035-Fix-for-testsuite-failure.patch +++ b/meta/recipes-devtools/gcc/gcc-9.3/0035-Fix-for-testsuite-failure.patch @@ -1,7 +1,7 @@ -From 0f9d449c739df03782ce9d29f6b68d9af976a607 Mon Sep 17 00:00:00 2001 +From fb5bdf8f8527228d587e8af9fc700e5164b3c18c Mon Sep 17 00:00:00 2001 From: RAGHUNATH LOLUR Date: Wed, 6 Dec 2017 22:52:26 -0800 -Subject: [PATCH 35/36] Fix for testsuite failure +Subject: [PATCH 35/39] Fix for testsuite failure 2017-11-16 Raghunath Lolur @@ -254,5 +254,5 @@ index 6cda1534311..26e37f5b8ba 100644 __attribute__((vector_size((elcount)*sizeof(type)))) type -- -2.22.1 +2.25.1 diff --git a/meta/recipes-devtools/gcc/gcc-9.2/0036-Re-introduce-spe-commandline-options.patch b/meta/recipes-devtools/gcc/gcc-9.3/0036-Re-introduce-spe-commandline-options.patch similarity index 88% rename from meta/recipes-devtools/gcc/gcc-9.2/0036-Re-introduce-spe-commandline-options.patch rename to meta/recipes-devtools/gcc/gcc-9.3/0036-Re-introduce-spe-commandline-options.patch index 4dbcd98945..825e070aa3 100644 --- a/meta/recipes-devtools/gcc/gcc-9.2/0036-Re-introduce-spe-commandline-options.patch +++ b/meta/recipes-devtools/gcc/gcc-9.3/0036-Re-introduce-spe-commandline-options.patch @@ -1,7 +1,7 @@ -From 71e99c2b58a9eb00cdd65a04aeb6fb78227e3297 Mon Sep 17 00:00:00 2001 +From dc23cabac6a7b2ca85b02d2a58a8916c98f382e0 Mon Sep 17 00:00:00 2001 From: Khem Raj Date: Wed, 6 Jun 2018 12:10:22 -0700 -Subject: [PATCH 36/36] Re-introduce spe commandline options +Subject: [PATCH 36/39] Re-introduce spe commandline options This should ensure that we keep accepting spe options @@ -37,5 +37,5 @@ index f4b5c91e11f..69869350fce 100644 Target RejectNegative Var(rs6000_altivec_abi) Save Use the AltiVec ABI extensions. -- -2.22.1 +2.25.1 diff --git a/meta/recipes-devtools/gcc/gcc-9.2/CVE-2019-14250.patch b/meta/recipes-devtools/gcc/gcc-9.3/0037-CVE-2019-14250-Check-zero-value-in-simple_object_elf.patch similarity index 59% rename from meta/recipes-devtools/gcc/gcc-9.2/CVE-2019-14250.patch rename to meta/recipes-devtools/gcc/gcc-9.3/0037-CVE-2019-14250-Check-zero-value-in-simple_object_elf.patch index 65ea34558a..f268a4eb58 100644 --- a/meta/recipes-devtools/gcc/gcc-9.2/CVE-2019-14250.patch +++ b/meta/recipes-devtools/gcc/gcc-9.3/0037-CVE-2019-14250-Check-zero-value-in-simple_object_elf.patch @@ -1,7 +1,10 @@ -From 517b211a3d78366ca8d5929f580e8ca72fd2c004 Mon Sep 17 00:00:00 2001 +From ac4af583bd59f6631671ad4abf985799ce4a53d9 Mon Sep 17 00:00:00 2001 From: rguenth Date: Thu, 25 Jul 2019 10:46:54 +0000 -Subject: [PATCH] 2019-07-25 Richard Biener +Subject: [PATCH 37/39] CVE-2019-14250: Check zero value in + simple_object_elf_match + +2019-07-25 Richard Biener PR lto/90924 Backport from mainline @@ -10,7 +13,6 @@ Subject: [PATCH] 2019-07-25 Richard Biener * simple-object-elf.c (simple_object_elf_match): Check zero value shstrndx. - git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-9-branch at 273793 138bc75d-0d04-0410-961f-82ee72b054a4 Upstream-Status: Backport @@ -18,16 +20,15 @@ Affectes: < 9.2 CVE: CVE-2019-14250 Dropped changelog Signed-off-by: Armin Kuster - --- libiberty/simple-object-elf.c | 8 ++++++++ - 2 files changed, 17 insertions(+) + 1 file changed, 8 insertions(+) -Index: gcc-9.2.0/libiberty/simple-object-elf.c -=================================================================== ---- gcc-9.2.0.orig/libiberty/simple-object-elf.c -+++ gcc-9.2.0/libiberty/simple-object-elf.c -@@ -557,6 +557,14 @@ simple_object_elf_match (unsigned char h +diff --git a/libiberty/simple-object-elf.c b/libiberty/simple-object-elf.c +index 3d49f339631..c00cebdb6c7 100644 +--- a/libiberty/simple-object-elf.c ++++ b/libiberty/simple-object-elf.c +@@ -557,6 +557,14 @@ simple_object_elf_match (unsigned char header[SIMPLE_OBJECT_MATCH_HEADER_LEN], return NULL; } @@ -42,3 +43,6 @@ Index: gcc-9.2.0/libiberty/simple-object-elf.c return (void *) eor; } +-- +2.25.1 + diff --git a/meta/recipes-devtools/gcc/gcc-9.2/gen-no-line-numbers.patch b/meta/recipes-devtools/gcc/gcc-9.3/0038-gentypes-genmodes-Do-not-use-__LINE__-for-maintainin.patch similarity index 93% rename from meta/recipes-devtools/gcc/gcc-9.2/gen-no-line-numbers.patch rename to meta/recipes-devtools/gcc/gcc-9.3/0038-gentypes-genmodes-Do-not-use-__LINE__-for-maintainin.patch index 8e2c3f5809..a79fc03d15 100644 --- a/meta/recipes-devtools/gcc/gcc-9.2/gen-no-line-numbers.patch +++ b/meta/recipes-devtools/gcc/gcc-9.3/0038-gentypes-genmodes-Do-not-use-__LINE__-for-maintainin.patch @@ -1,11 +1,23 @@ -Inserting line numbers into generated code means its not always reproducible wth +From 075e0929e04913538391052c32178b6a14ef0ae3 Mon Sep 17 00:00:00 2001 +From: Khem Raj +Date: Thu, 12 Mar 2020 14:41:40 -0700 +Subject: [PATCH 38/39] gentypes/genmodes: Do not use __LINE__ for maintaining + reproducibility + +Inserting line numbers into generated code means its not always reproducible wth differing versions of host gcc. Void the issue by not adding these. Upstream-Status: Inappropriate [OE Reproducibility specific] + Signed-off-by: Richard Purdie +Signed-off-by: Khem Raj +--- + gcc/gengtype.c | 6 +++--- + gcc/genmodes.c | 32 ++++++++++++++++---------------- + 2 files changed, 19 insertions(+), 19 deletions(-) diff --git a/gcc/gengtype.c b/gcc/gengtype.c -index 53317337c..bbb261516 100644 +index 53317337cf8..bbb26151671 100644 --- a/gcc/gengtype.c +++ b/gcc/gengtype.c @@ -991,7 +991,7 @@ create_field_at (pair_p next, type_p type, const char *name, options_p opt, @@ -36,7 +48,7 @@ index 53317337c..bbb261516 100644 POS_HERE (do_scalar_typedef ("CUMULATIVE_ARGS", &pos)); POS_HERE (do_scalar_typedef ("REAL_VALUE_TYPE", &pos)); diff --git a/gcc/genmodes.c b/gcc/genmodes.c -index f33eefa24..07bef9eeb 100644 +index f33eefa2494..07bef9eebe2 100644 --- a/gcc/genmodes.c +++ b/gcc/genmodes.c @@ -429,7 +429,7 @@ complete_all_modes (void) @@ -168,3 +180,6 @@ index f33eefa24..07bef9eeb 100644 #define ADJUST_NUNITS(M, X) _ADD_ADJUST (nunits, M, X, RANDOM, RANDOM) #define ADJUST_BYTESIZE(M, X) _ADD_ADJUST (bytesize, M, X, RANDOM, RANDOM) +-- +2.25.1 + diff --git a/meta/recipes-devtools/gcc/gcc-9.2/re-PR-target-91102-aarch64-ICE-on-Linux-kernel-with-.patch b/meta/recipes-devtools/gcc/gcc-9.3/0039-process_alt_operands-Don-t-match-user-defined-regs-o.patch similarity index 88% rename from meta/recipes-devtools/gcc/gcc-9.2/re-PR-target-91102-aarch64-ICE-on-Linux-kernel-with-.patch rename to meta/recipes-devtools/gcc/gcc-9.3/0039-process_alt_operands-Don-t-match-user-defined-regs-o.patch index c37e0bb9dd..b69114d1e5 100644 --- a/meta/recipes-devtools/gcc/gcc-9.2/re-PR-target-91102-aarch64-ICE-on-Linux-kernel-with-.patch +++ b/meta/recipes-devtools/gcc/gcc-9.3/0039-process_alt_operands-Don-t-match-user-defined-regs-o.patch @@ -1,8 +1,10 @@ -From efb0ee06f5c0186c2d1442ecd4dbbd55dbd97b44 Mon Sep 17 00:00:00 2001 +From e75bcc2ec4f1e7e081ce18713f0a25913ba15340 Mon Sep 17 00:00:00 2001 From: Vladimir Makarov Date: Wed, 10 Jul 2019 16:07:10 +0000 -Subject: [PATCH] re PR target/91102 (aarch64 ICE on Linux kernel with -Os - starting with r270266) +Subject: [PATCH 39/39] process_alt_operands: Don't match user defined regs + only if they are early clobbers + +PR target/91102 (aarch64 ICE on Linux kernel with -Os starting with r270266) 2019-07-10 Vladimir Makarov @@ -26,7 +28,7 @@ Signed-off-by: Taras Kondratiuk create mode 100644 gcc/testsuite/gcc.target/aarch64/pr91102.c diff --git a/gcc/lra-constraints.c b/gcc/lra-constraints.c -index cf33da8013e4..6382dbf852b6 100644 +index cf33da8013e..6382dbf852b 100644 --- a/gcc/lra-constraints.c +++ b/gcc/lra-constraints.c @@ -2172,8 +2172,9 @@ process_alt_operands (int only_alternative) @@ -63,7 +65,7 @@ index cf33da8013e4..6382dbf852b6 100644 if (curr_alt[m] == NO_REGS) diff --git a/gcc/testsuite/gcc.target/aarch64/pr91102.c b/gcc/testsuite/gcc.target/aarch64/pr91102.c new file mode 100644 -index 000000000000..70b99045a48e +index 00000000000..70b99045a48 --- /dev/null +++ b/gcc/testsuite/gcc.target/aarch64/pr91102.c @@ -0,0 +1,26 @@ @@ -93,3 +95,6 @@ index 000000000000..70b99045a48e + b.h = foo (b.h, c.h); + } +} +-- +2.25.1 + diff --git a/meta/recipes-devtools/gcc/gcc-cross-canadian_9.2.bb b/meta/recipes-devtools/gcc/gcc-cross-canadian_9.3.bb similarity index 100% rename from meta/recipes-devtools/gcc/gcc-cross-canadian_9.2.bb rename to meta/recipes-devtools/gcc/gcc-cross-canadian_9.3.bb diff --git a/meta/recipes-devtools/gcc/gcc-cross_9.2.bb b/meta/recipes-devtools/gcc/gcc-cross_9.3.bb similarity index 100% rename from meta/recipes-devtools/gcc/gcc-cross_9.2.bb rename to meta/recipes-devtools/gcc/gcc-cross_9.3.bb diff --git a/meta/recipes-devtools/gcc/gcc-crosssdk_9.2.bb b/meta/recipes-devtools/gcc/gcc-crosssdk_9.3.bb similarity index 100% rename from meta/recipes-devtools/gcc/gcc-crosssdk_9.2.bb rename to meta/recipes-devtools/gcc/gcc-crosssdk_9.3.bb diff --git a/meta/recipes-devtools/gcc/gcc-runtime_9.2.bb b/meta/recipes-devtools/gcc/gcc-runtime_9.3.bb similarity index 100% rename from meta/recipes-devtools/gcc/gcc-runtime_9.2.bb rename to meta/recipes-devtools/gcc/gcc-runtime_9.3.bb diff --git a/meta/recipes-devtools/gcc/gcc-sanitizers_9.2.bb b/meta/recipes-devtools/gcc/gcc-sanitizers_9.3.bb similarity index 100% rename from meta/recipes-devtools/gcc/gcc-sanitizers_9.2.bb rename to meta/recipes-devtools/gcc/gcc-sanitizers_9.3.bb diff --git a/meta/recipes-devtools/gcc/gcc-source_9.2.bb b/meta/recipes-devtools/gcc/gcc-source_9.3.bb similarity index 100% rename from meta/recipes-devtools/gcc/gcc-source_9.2.bb rename to meta/recipes-devtools/gcc/gcc-source_9.3.bb diff --git a/meta/recipes-devtools/gcc/gcc_9.2.bb b/meta/recipes-devtools/gcc/gcc_9.3.bb similarity index 100% rename from meta/recipes-devtools/gcc/gcc_9.2.bb rename to meta/recipes-devtools/gcc/gcc_9.3.bb diff --git a/meta/recipes-devtools/gcc/libgcc-initial_9.2.bb b/meta/recipes-devtools/gcc/libgcc-initial_9.3.bb similarity index 100% rename from meta/recipes-devtools/gcc/libgcc-initial_9.2.bb rename to meta/recipes-devtools/gcc/libgcc-initial_9.3.bb diff --git a/meta/recipes-devtools/gcc/libgcc_9.2.bb b/meta/recipes-devtools/gcc/libgcc_9.3.bb similarity index 100% rename from meta/recipes-devtools/gcc/libgcc_9.2.bb rename to meta/recipes-devtools/gcc/libgcc_9.3.bb diff --git a/meta/recipes-devtools/gcc/libgfortran_9.2.bb b/meta/recipes-devtools/gcc/libgfortran_9.3.bb similarity index 100% rename from meta/recipes-devtools/gcc/libgfortran_9.2.bb rename to meta/recipes-devtools/gcc/libgfortran_9.3.bb -- 2.25.1 From anuj.mittal at intel.com Fri Mar 13 01:09:38 2020 From: anuj.mittal at intel.com (Anuj Mittal) Date: Fri, 13 Mar 2020 09:09:38 +0800 Subject: [OE-core] [PATCH 1/2] bluez: fix CVE-2020-0556 Message-ID: <20200313010939.586772-1-anuj.mittal@intel.com> It was discovered that BlueZ's HID and HOGP profiles implementations don't specifically require bonding between the device and the host. This creates an opportunity for an malicious device to connect to a target host to either impersonate an existing HID device without security or to cause an SDP or GATT service discovery to take place which would allow HID reports to be injected to the input subsystem from a non-bonded source. Signed-off-by: Anuj Mittal --- meta/recipes-connectivity/bluez5/bluez5.inc | 2 + .../bluez5/bluez5/CVE-2020-0556-1.patch | 35 +++++ .../bluez5/bluez5/CVE-2020-0556-2.patch | 143 ++++++++++++++++++ 3 files changed, 180 insertions(+) create mode 100644 meta/recipes-connectivity/bluez5/bluez5/CVE-2020-0556-1.patch create mode 100644 meta/recipes-connectivity/bluez5/bluez5/CVE-2020-0556-2.patch diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc b/meta/recipes-connectivity/bluez5/bluez5.inc index 150d909d73..708fa1ccec 100644 --- a/meta/recipes-connectivity/bluez5/bluez5.inc +++ b/meta/recipes-connectivity/bluez5/bluez5.inc @@ -52,6 +52,8 @@ SRC_URI = "${KERNELORG_MIRROR}/linux/bluetooth/bluez-${PV}.tar.xz \ ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', '', 'file://0001-Allow-using-obexd-without-systemd-in-the-user-sessio.patch', d)} \ file://0001-tests-add-a-target-for-building-tests-without-runnin.patch \ file://0001-test-gatt-Fix-hung-issue.patch \ + file://CVE-2020-0556-1.patch \ + file://CVE-2020-0556-2.patch \ " S = "${WORKDIR}/bluez-${PV}" diff --git a/meta/recipes-connectivity/bluez5/bluez5/CVE-2020-0556-1.patch b/meta/recipes-connectivity/bluez5/bluez5/CVE-2020-0556-1.patch new file mode 100644 index 0000000000..a6bf31e14b --- /dev/null +++ b/meta/recipes-connectivity/bluez5/bluez5/CVE-2020-0556-1.patch @@ -0,0 +1,35 @@ +From 8cdbd3b09f29da29374e2f83369df24228da0ad1 Mon Sep 17 00:00:00 2001 +From: Alain Michaud +Date: Tue, 10 Mar 2020 02:35:16 +0000 +Subject: [PATCH 1/2] HOGP must only accept data from bonded devices. + +HOGP 1.0 Section 6.1 establishes that the HOGP must require bonding. + +Reference: +https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00352.htm + +Upstream-Status: Backport [https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=8cdbd3b09f29da29374e2f83369df24228da0ad1] +Signed-off-by: Anuj Mittal +CVE: CVE-2020-0556 +--- + profiles/input/hog.c | 4 ++++ + 1 file changed, 4 insertions(+) + +diff --git a/profiles/input/hog.c b/profiles/input/hog.c +index 83c017dcb..dfac68921 100644 +--- a/profiles/input/hog.c ++++ b/profiles/input/hog.c +@@ -186,6 +186,10 @@ static int hog_accept(struct btd_service *service) + return -EINVAL; + } + ++ /* HOGP 1.0 Section 6.1 requires bonding */ ++ if (!device_is_bonded(device, btd_device_get_bdaddr_type(device))) ++ return -ECONNREFUSED; ++ + /* TODO: Replace GAttrib with bt_gatt_client */ + bt_hog_attach(dev->hog, attrib); + +-- +2.24.1 + diff --git a/meta/recipes-connectivity/bluez5/bluez5/CVE-2020-0556-2.patch b/meta/recipes-connectivity/bluez5/bluez5/CVE-2020-0556-2.patch new file mode 100644 index 0000000000..8acb2f15ec --- /dev/null +++ b/meta/recipes-connectivity/bluez5/bluez5/CVE-2020-0556-2.patch @@ -0,0 +1,143 @@ +From 3cccdbab2324086588df4ccf5f892fb3ce1f1787 Mon Sep 17 00:00:00 2001 +From: Alain Michaud +Date: Tue, 10 Mar 2020 02:35:18 +0000 +Subject: [PATCH 2/2] HID accepts bonded device connections only. + +This change adds a configuration for platforms to choose a more secure +posture for the HID profile. While some older mice are known to not +support pairing or encryption, some platform may choose a more secure +posture by requiring the device to be bonded and require the +connection to be encrypted when bonding is required. + +Reference: +https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00352.html + +Upstream-Status: Backport [https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=3cccdbab2324086588df4ccf5f892fb3ce1f1787] +Signed-off-by: Anuj Mittal +CVE: CVE-2020-0556 + +--- + profiles/input/device.c | 23 ++++++++++++++++++++++- + profiles/input/device.h | 1 + + profiles/input/input.conf | 8 ++++++++ + profiles/input/manager.c | 13 ++++++++++++- + 4 files changed, 43 insertions(+), 2 deletions(-) + +diff --git a/profiles/input/device.c b/profiles/input/device.c +index 2cb3811c8..d89da2d7c 100644 +--- a/profiles/input/device.c ++++ b/profiles/input/device.c +@@ -92,6 +92,7 @@ struct input_device { + + static int idle_timeout = 0; + static bool uhid_enabled = false; ++static bool classic_bonded_only = false; + + void input_set_idle_timeout(int timeout) + { +@@ -103,6 +104,11 @@ void input_enable_userspace_hid(bool state) + uhid_enabled = state; + } + ++void input_set_classic_bonded_only(bool state) ++{ ++ classic_bonded_only = state; ++} ++ + static void input_device_enter_reconnect_mode(struct input_device *idev); + static int connection_disconnect(struct input_device *idev, uint32_t flags); + +@@ -970,8 +976,18 @@ static int hidp_add_connection(struct input_device *idev) + if (device_name_known(idev->device)) + device_get_name(idev->device, req->name, sizeof(req->name)); + ++ /* Make sure the device is bonded if required */ ++ if (classic_bonded_only && !device_is_bonded(idev->device, ++ btd_device_get_bdaddr_type(idev->device))) { ++ error("Rejected connection from !bonded device %s", dst_addr); ++ goto cleanup; ++ } ++ + /* Encryption is mandatory for keyboards */ +- if (req->subclass & 0x40) { ++ /* Some platforms may choose to require encryption for all devices */ ++ /* Note that this only matters for pre 2.1 devices as otherwise the */ ++ /* device is encrypted by default by the lower layers */ ++ if (classic_bonded_only || req->subclass & 0x40) { + if (!bt_io_set(idev->intr_io, &gerr, + BT_IO_OPT_SEC_LEVEL, BT_IO_SEC_MEDIUM, + BT_IO_OPT_INVALID)) { +@@ -1203,6 +1219,11 @@ static void input_device_enter_reconnect_mode(struct input_device *idev) + DBG("path=%s reconnect_mode=%s", idev->path, + reconnect_mode_to_string(idev->reconnect_mode)); + ++ /* Make sure the device is bonded if required */ ++ if (classic_bonded_only && !device_is_bonded(idev->device, ++ btd_device_get_bdaddr_type(idev->device))) ++ return; ++ + /* Only attempt an auto-reconnect when the device is required to + * accept reconnections from the host. + */ +diff --git a/profiles/input/device.h b/profiles/input/device.h +index 51a9aee18..3044db673 100644 +--- a/profiles/input/device.h ++++ b/profiles/input/device.h +@@ -29,6 +29,7 @@ struct input_conn; + + void input_set_idle_timeout(int timeout); + void input_enable_userspace_hid(bool state); ++void input_set_classic_bonded_only(bool state); + + int input_device_register(struct btd_service *service); + void input_device_unregister(struct btd_service *service); +diff --git a/profiles/input/input.conf b/profiles/input/input.conf +index 3e1d65aae..166aff4a4 100644 +--- a/profiles/input/input.conf ++++ b/profiles/input/input.conf +@@ -11,3 +11,11 @@ + # Enable HID protocol handling in userspace input profile + # Defaults to false (HIDP handled in HIDP kernel module) + #UserspaceHID=true ++ ++# Limit HID connections to bonded devices ++# The HID Profile does not specify that devices must be bonded, however some ++# platforms may want to make sure that input connections only come from bonded ++# device connections. Several older mice have been known for not supporting ++# pairing/encryption. ++# Defaults to false to maximize device compatibility. ++#ClassicBondedOnly=true +diff --git a/profiles/input/manager.c b/profiles/input/manager.c +index 1d31b0652..5cd27b839 100644 +--- a/profiles/input/manager.c ++++ b/profiles/input/manager.c +@@ -96,7 +96,7 @@ static int input_init(void) + config = load_config_file(CONFIGDIR "/input.conf"); + if (config) { + int idle_timeout; +- gboolean uhid_enabled; ++ gboolean uhid_enabled, classic_bonded_only; + + idle_timeout = g_key_file_get_integer(config, "General", + "IdleTimeout", &err); +@@ -114,6 +114,17 @@ static int input_init(void) + input_enable_userspace_hid(uhid_enabled); + } else + g_clear_error(&err); ++ ++ classic_bonded_only = g_key_file_get_boolean(config, "General", ++ "ClassicBondedOnly", &err); ++ ++ if (!err) { ++ DBG("input.conf: ClassicBondedOnly=%s", ++ classic_bonded_only ? "true" : "false"); ++ input_set_classic_bonded_only(classic_bonded_only); ++ } else ++ g_clear_error(&err); ++ + } + + btd_profile_register(&input_profile); +-- +2.24.1 + -- 2.24.1 From anuj.mittal at intel.com Fri Mar 13 01:09:39 2020 From: anuj.mittal at intel.com (Anuj Mittal) Date: Fri, 13 Mar 2020 09:09:39 +0800 Subject: [OE-core] [PATCH 2/2] binutils: fix CVE-2020-0551 In-Reply-To: <20200313010939.586772-1-anuj.mittal@intel.com> References: <20200313010939.586772-1-anuj.mittal@intel.com> Message-ID: <20200313010939.586772-2-anuj.mittal@intel.com> Signed-off-by: Anuj Mittal --- .../binutils/binutils-2.34.inc | 1 + .../binutils/binutils/CVE-2020-0551.patch | 549 ++++++++++++++++++ 2 files changed, 550 insertions(+) create mode 100644 meta/recipes-devtools/binutils/binutils/CVE-2020-0551.patch diff --git a/meta/recipes-devtools/binutils/binutils-2.34.inc b/meta/recipes-devtools/binutils/binutils-2.34.inc index eaaa5ed2ac..ed9f902fd2 100644 --- a/meta/recipes-devtools/binutils/binutils-2.34.inc +++ b/meta/recipes-devtools/binutils/binutils-2.34.inc @@ -40,6 +40,7 @@ SRC_URI = "\ file://0013-fix-the-incorrect-assembling-for-ppc-wait-mnemonic.patch \ file://0014-Detect-64-bit-MIPS-targets.patch \ file://0015-sync-with-OE-libtool-changes.patch \ + file://CVE-2020-0551.patch \ " S = "${WORKDIR}/git" diff --git a/meta/recipes-devtools/binutils/binutils/CVE-2020-0551.patch b/meta/recipes-devtools/binutils/binutils/CVE-2020-0551.patch new file mode 100644 index 0000000000..53e3caf445 --- /dev/null +++ b/meta/recipes-devtools/binutils/binutils/CVE-2020-0551.patch @@ -0,0 +1,549 @@ +From ae531041c7c5956672342f89c486a011c84f027f Mon Sep 17 00:00:00 2001 +From: "H.J. Lu" +Date: Wed, 11 Mar 2020 09:46:19 -0700 +Subject: [PATCH 1/1] i386: Generate lfence with load/indirect branch/ret + [CVE-2020-0551] + +Add 3 command-line options to generate lfence for load, indirect near +branch and ret to help mitigate: + +https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00334.html +http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-0551 + +1. -mlfence-after-load=[no|yes]: + -mlfence-after-load=yes generates lfence after load instructions. +2. -mlfence-before-indirect-branch=[none|all|memory|register]: + a. -mlfence-before-indirect-branch=all generates lfence before indirect + near branches via register and a warning before indirect near branches + via memory. + b. -mlfence-before-indirect-branch=memory issue a warning before + indirect near branches via memory. + c. -mlfence-before-indirect-branch=register generates lfence before + indirect near branches via register. +Note that lfence won't be generated before indirect near branches via +register with -mlfence-after-load=yes since lfence will be generated +after loading branch target register. +3. -mlfence-before-ret=[none|or|not] + a. -mlfence-before-ret=or generates or with lfence before ret. + b. -mlfence-before-ret=not generates not with lfence before ret. + +A warning will be issued and lfence won't be generated before indirect +near branch and ret if the previous item is a prefix or a constant +directive, which may be used to hardcode an instruction, since there +is no clear instruction boundary. + + * config/tc-i386.c (lfence_after_load): New. + (lfence_before_indirect_branch_kind): New. + (lfence_before_indirect_branch): New. + (lfence_before_ret_kind): New. + (lfence_before_ret): New. + (last_insn): New. + (load_insn_p): New. + (insert_lfence_after): New. + (insert_lfence_before): New. + (md_assemble): Call insert_lfence_before and insert_lfence_after. + Set last_insn. + (OPTION_MLFENCE_AFTER_LOAD): New. + (OPTION_MLFENCE_BEFORE_INDIRECT_BRANCH): New. + (OPTION_MLFENCE_BEFORE_RET): New. + (md_longopts): Add -mlfence-after-load=, + -mlfence-before-indirect-branch= and -mlfence-before-ret=. + (md_parse_option): Handle -mlfence-after-load=, + -mlfence-before-indirect-branch= and -mlfence-before-ret=. + (md_show_usage): Display -mlfence-after-load=, + -mlfence-before-indirect-branch= and -mlfence-before-ret=. + (i386_cons_align): New. + * config/tc-i386.h (i386_cons_align): New. + (md_cons_align): New. + * doc/c-i386.texi: Document -mlfence-after-load=, + -mlfence-before-indirect-branch= and -mlfence-before-ret=. + +Signed-off-by: Anuj Mittal +Upstream-Status: Backport [https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=ae531041c7c5956672342f89c486a011c84f027f] +CVE: CVE-2020-0551 +--- +diff --git a/gas/config/tc-i386.c b/gas/config/tc-i386.c +index b020f39c863..09063f784b7 100644 +--- a/gas/config/tc-i386.c ++++ b/gas/config/tc-i386.c +@@ -629,7 +629,29 @@ static int omit_lock_prefix = 0; + "lock addl $0, (%{re}sp)". */ + static int avoid_fence = 0; + +-/* Type of the previous instruction. */ ++/* 1 if lfence should be inserted after every load. */ ++static int lfence_after_load = 0; ++ ++/* Non-zero if lfence should be inserted before indirect branch. */ ++static enum lfence_before_indirect_branch_kind ++ { ++ lfence_branch_none = 0, ++ lfence_branch_register, ++ lfence_branch_memory, ++ lfence_branch_all ++ } ++lfence_before_indirect_branch; ++ ++/* Non-zero if lfence should be inserted before ret. */ ++static enum lfence_before_ret_kind ++ { ++ lfence_before_ret_none = 0, ++ lfence_before_ret_not, ++ lfence_before_ret_or ++ } ++lfence_before_ret; ++ ++/* Types of previous instruction is .byte or prefix. */ + static struct + { + segT seg; +@@ -4311,6 +4333,283 @@ optimize_encoding (void) + } + } + ++/* Return non-zero for load instruction. */ ++ ++static int ++load_insn_p (void) ++{ ++ unsigned int dest; ++ int any_vex_p = is_any_vex_encoding (&i.tm); ++ unsigned int base_opcode = i.tm.base_opcode | 1; ++ ++ if (!any_vex_p) ++ { ++ /* lea */ ++ if (i.tm.base_opcode == 0x8d) ++ return 0; ++ ++ /* pop */ ++ if ((i.tm.base_opcode & ~7) == 0x58 ++ || (i.tm.base_opcode == 0x8f && i.tm.extension_opcode == 0)) ++ return 1; ++ ++ /* movs, cmps, lods, scas. */ ++ if ((i.tm.base_opcode | 0xb) == 0xaf) ++ return 1; ++ ++ /* outs */ ++ if (base_opcode == 0x6f) ++ return 1; ++ } ++ ++ /* No memory operand. */ ++ if (!i.mem_operands) ++ return 0; ++ ++ if (any_vex_p) ++ { ++ /* vldmxcsr. */ ++ if (i.tm.base_opcode == 0xae ++ && i.tm.opcode_modifier.vex ++ && i.tm.opcode_modifier.vexopcode == VEX0F ++ && i.tm.extension_opcode == 2) ++ return 1; ++ } ++ else ++ { ++ /* test, not, neg, mul, imul, div, idiv. */ ++ if ((i.tm.base_opcode == 0xf6 || i.tm.base_opcode == 0xf7) ++ && i.tm.extension_opcode != 1) ++ return 1; ++ ++ /* inc, dec. */ ++ if (base_opcode == 0xff && i.tm.extension_opcode <= 1) ++ return 1; ++ ++ /* add, or, adc, sbb, and, sub, xor, cmp. */ ++ if (i.tm.base_opcode >= 0x80 && i.tm.base_opcode <= 0x83) ++ return 1; ++ ++ /* bt, bts, btr, btc. */ ++ if (i.tm.base_opcode == 0xfba ++ && (i.tm.extension_opcode >= 4 && i.tm.extension_opcode <= 7)) ++ return 1; ++ ++ /* rol, ror, rcl, rcr, shl/sal, shr, sar. */ ++ if ((base_opcode == 0xc1 ++ || (i.tm.base_opcode >= 0xd0 && i.tm.base_opcode <= 0xd3)) ++ && i.tm.extension_opcode != 6) ++ return 1; ++ ++ /* cmpxchg8b, cmpxchg16b, xrstors. */ ++ if (i.tm.base_opcode == 0xfc7 ++ && (i.tm.extension_opcode == 1 || i.tm.extension_opcode == 3)) ++ return 1; ++ ++ /* fxrstor, ldmxcsr, xrstor. */ ++ if (i.tm.base_opcode == 0xfae ++ && (i.tm.extension_opcode == 1 ++ || i.tm.extension_opcode == 2 ++ || i.tm.extension_opcode == 5)) ++ return 1; ++ ++ /* lgdt, lidt, lmsw. */ ++ if (i.tm.base_opcode == 0xf01 ++ && (i.tm.extension_opcode == 2 ++ || i.tm.extension_opcode == 3 ++ || i.tm.extension_opcode == 6)) ++ return 1; ++ ++ /* vmptrld */ ++ if (i.tm.base_opcode == 0xfc7 ++ && i.tm.extension_opcode == 6) ++ return 1; ++ ++ /* Check for x87 instructions. */ ++ if (i.tm.base_opcode >= 0xd8 && i.tm.base_opcode <= 0xdf) ++ { ++ /* Skip fst, fstp, fstenv, fstcw. */ ++ if (i.tm.base_opcode == 0xd9 ++ && (i.tm.extension_opcode == 2 ++ || i.tm.extension_opcode == 3 ++ || i.tm.extension_opcode == 6 ++ || i.tm.extension_opcode == 7)) ++ return 0; ++ ++ /* Skip fisttp, fist, fistp, fstp. */ ++ if (i.tm.base_opcode == 0xdb ++ && (i.tm.extension_opcode == 1 ++ || i.tm.extension_opcode == 2 ++ || i.tm.extension_opcode == 3 ++ || i.tm.extension_opcode == 7)) ++ return 0; ++ ++ /* Skip fisttp, fst, fstp, fsave, fstsw. */ ++ if (i.tm.base_opcode == 0xdd ++ && (i.tm.extension_opcode == 1 ++ || i.tm.extension_opcode == 2 ++ || i.tm.extension_opcode == 3 ++ || i.tm.extension_opcode == 6 ++ || i.tm.extension_opcode == 7)) ++ return 0; ++ ++ /* Skip fisttp, fist, fistp, fbstp, fistp. */ ++ if (i.tm.base_opcode == 0xdf ++ && (i.tm.extension_opcode == 1 ++ || i.tm.extension_opcode == 2 ++ || i.tm.extension_opcode == 3 ++ || i.tm.extension_opcode == 6 ++ || i.tm.extension_opcode == 7)) ++ return 0; ++ ++ return 1; ++ } ++ } ++ ++ dest = i.operands - 1; ++ ++ /* Check fake imm8 operand and 3 source operands. */ ++ if ((i.tm.opcode_modifier.immext ++ || i.tm.opcode_modifier.vexsources == VEX3SOURCES) ++ && i.types[dest].bitfield.imm8) ++ dest--; ++ ++ /* add, or, adc, sbb, and, sub, xor, cmp, test, xchg, xadd */ ++ if (!any_vex_p ++ && (base_opcode == 0x1 ++ || base_opcode == 0x9 ++ || base_opcode == 0x11 ++ || base_opcode == 0x19 ++ || base_opcode == 0x21 ++ || base_opcode == 0x29 ++ || base_opcode == 0x31 ++ || base_opcode == 0x39 ++ || (i.tm.base_opcode >= 0x84 && i.tm.base_opcode <= 0x87) ++ || base_opcode == 0xfc1)) ++ return 1; ++ ++ /* Check for load instruction. */ ++ return (i.types[dest].bitfield.class != ClassNone ++ || i.types[dest].bitfield.instance == Accum); ++} ++ ++/* Output lfence, 0xfaee8, after instruction. */ ++ ++static void ++insert_lfence_after (void) ++{ ++ if (lfence_after_load && load_insn_p ()) ++ { ++ char *p = frag_more (3); ++ *p++ = 0xf; ++ *p++ = 0xae; ++ *p = 0xe8; ++ } ++} ++ ++/* Output lfence, 0xfaee8, before instruction. */ ++ ++static void ++insert_lfence_before (void) ++{ ++ char *p; ++ ++ if (is_any_vex_encoding (&i.tm)) ++ return; ++ ++ if (i.tm.base_opcode == 0xff ++ && (i.tm.extension_opcode == 2 || i.tm.extension_opcode == 4)) ++ { ++ /* Insert lfence before indirect branch if needed. */ ++ ++ if (lfence_before_indirect_branch == lfence_branch_none) ++ return; ++ ++ if (i.operands != 1) ++ abort (); ++ ++ if (i.reg_operands == 1) ++ { ++ /* Indirect branch via register. Don't insert lfence with ++ -mlfence-after-load=yes. */ ++ if (lfence_after_load ++ || lfence_before_indirect_branch == lfence_branch_memory) ++ return; ++ } ++ else if (i.mem_operands == 1 ++ && lfence_before_indirect_branch != lfence_branch_register) ++ { ++ as_warn (_("indirect `%s` with memory operand should be avoided"), ++ i.tm.name); ++ return; ++ } ++ else ++ return; ++ ++ if (last_insn.kind != last_insn_other ++ && last_insn.seg == now_seg) ++ { ++ as_warn_where (last_insn.file, last_insn.line, ++ _("`%s` skips -mlfence-before-indirect-branch on `%s`"), ++ last_insn.name, i.tm.name); ++ return; ++ } ++ ++ p = frag_more (3); ++ *p++ = 0xf; ++ *p++ = 0xae; ++ *p = 0xe8; ++ return; ++ } ++ ++ /* Output or/not and lfence before ret. */ ++ if (lfence_before_ret != lfence_before_ret_none ++ && (i.tm.base_opcode == 0xc2 ++ || i.tm.base_opcode == 0xc3 ++ || i.tm.base_opcode == 0xca ++ || i.tm.base_opcode == 0xcb)) ++ { ++ if (last_insn.kind != last_insn_other ++ && last_insn.seg == now_seg) ++ { ++ as_warn_where (last_insn.file, last_insn.line, ++ _("`%s` skips -mlfence-before-ret on `%s`"), ++ last_insn.name, i.tm.name); ++ return; ++ } ++ if (lfence_before_ret == lfence_before_ret_or) ++ { ++ /* orl: 0x830c2400. */ ++ p = frag_more ((flag_code == CODE_64BIT ? 1 : 0) + 4 + 3); ++ if (flag_code == CODE_64BIT) ++ *p++ = 0x48; ++ *p++ = 0x83; ++ *p++ = 0xc; ++ *p++ = 0x24; ++ *p++ = 0x0; ++ } ++ else ++ { ++ p = frag_more ((flag_code == CODE_64BIT ? 2 : 0) + 6 + 3); ++ /* notl: 0xf71424. */ ++ if (flag_code == CODE_64BIT) ++ *p++ = 0x48; ++ *p++ = 0xf7; ++ *p++ = 0x14; ++ *p++ = 0x24; ++ /* notl: 0xf71424. */ ++ if (flag_code == CODE_64BIT) ++ *p++ = 0x48; ++ *p++ = 0xf7; ++ *p++ = 0x14; ++ *p++ = 0x24; ++ } ++ *p++ = 0xf; ++ *p++ = 0xae; ++ *p = 0xe8; ++ } ++} ++ + /* This is the guts of the machine-dependent assembler. LINE points to a + machine dependent instruction. This function is supposed to emit + the frags/bytes it assembles to. */ +@@ -4628,9 +4927,13 @@ md_assemble (char *line) + if (i.rex != 0) + add_prefix (REX_OPCODE | i.rex); + ++ insert_lfence_before (); ++ + /* We are ready to output the insn. */ + output_insn (); + ++ insert_lfence_after (); ++ + last_insn.seg = now_seg; + + if (i.tm.opcode_modifier.isprefix) +@@ -12250,6 +12553,9 @@ const char *md_shortopts = "qnO::"; + #define OPTION_MALIGN_BRANCH_PREFIX_SIZE (OPTION_MD_BASE + 28) + #define OPTION_MALIGN_BRANCH (OPTION_MD_BASE + 29) + #define OPTION_MBRANCHES_WITH_32B_BOUNDARIES (OPTION_MD_BASE + 30) ++#define OPTION_MLFENCE_AFTER_LOAD (OPTION_MD_BASE + 31) ++#define OPTION_MLFENCE_BEFORE_INDIRECT_BRANCH (OPTION_MD_BASE + 32) ++#define OPTION_MLFENCE_BEFORE_RET (OPTION_MD_BASE + 33) + + struct option md_longopts[] = + { +@@ -12289,6 +12595,10 @@ struct option md_longopts[] = + {"malign-branch-prefix-size", required_argument, NULL, OPTION_MALIGN_BRANCH_PREFIX_SIZE}, + {"malign-branch", required_argument, NULL, OPTION_MALIGN_BRANCH}, + {"mbranches-within-32B-boundaries", no_argument, NULL, OPTION_MBRANCHES_WITH_32B_BOUNDARIES}, ++ {"mlfence-after-load", required_argument, NULL, OPTION_MLFENCE_AFTER_LOAD}, ++ {"mlfence-before-indirect-branch", required_argument, NULL, ++ OPTION_MLFENCE_BEFORE_INDIRECT_BRANCH}, ++ {"mlfence-before-ret", required_argument, NULL, OPTION_MLFENCE_BEFORE_RET}, + {"mamd64", no_argument, NULL, OPTION_MAMD64}, + {"mintel64", no_argument, NULL, OPTION_MINTEL64}, + {NULL, no_argument, NULL, 0} +@@ -12668,6 +12978,41 @@ md_parse_option (int c, const char *arg) + as_fatal (_("invalid -mfence-as-lock-add= option: `%s'"), arg); + break; + ++ case OPTION_MLFENCE_AFTER_LOAD: ++ if (strcasecmp (arg, "yes") == 0) ++ lfence_after_load = 1; ++ else if (strcasecmp (arg, "no") == 0) ++ lfence_after_load = 0; ++ else ++ as_fatal (_("invalid -mlfence-after-load= option: `%s'"), arg); ++ break; ++ ++ case OPTION_MLFENCE_BEFORE_INDIRECT_BRANCH: ++ if (strcasecmp (arg, "all") == 0) ++ lfence_before_indirect_branch = lfence_branch_all; ++ else if (strcasecmp (arg, "memory") == 0) ++ lfence_before_indirect_branch = lfence_branch_memory; ++ else if (strcasecmp (arg, "register") == 0) ++ lfence_before_indirect_branch = lfence_branch_register; ++ else if (strcasecmp (arg, "none") == 0) ++ lfence_before_indirect_branch = lfence_branch_none; ++ else ++ as_fatal (_("invalid -mlfence-before-indirect-branch= option: `%s'"), ++ arg); ++ break; ++ ++ case OPTION_MLFENCE_BEFORE_RET: ++ if (strcasecmp (arg, "or") == 0) ++ lfence_before_ret = lfence_before_ret_or; ++ else if (strcasecmp (arg, "not") == 0) ++ lfence_before_ret = lfence_before_ret_not; ++ else if (strcasecmp (arg, "none") == 0) ++ lfence_before_ret = lfence_before_ret_none; ++ else ++ as_fatal (_("invalid -mlfence-before-ret= option: `%s'"), ++ arg); ++ break; ++ + case OPTION_MRELAX_RELOCATIONS: + if (strcasecmp (arg, "yes") == 0) + generate_relax_relocations = 1; +@@ -13025,6 +13370,15 @@ md_show_usage (FILE *stream) + -mbranches-within-32B-boundaries\n\ + align branches within 32 byte boundary\n")); + fprintf (stream, _("\ ++ -mlfence-after-load=[no|yes] (default: no)\n\ ++ generate lfence after load\n")); ++ fprintf (stream, _("\ ++ -mlfence-before-indirect-branch=[none|all|register|memory] (default: none)\n\ ++ generate lfence before indirect near branch\n")); ++ fprintf (stream, _("\ ++ -mlfence-before-ret=[none|or|not] (default: none)\n\ ++ generate lfence before ret\n")); ++ fprintf (stream, _("\ + -mamd64 accept only AMD64 ISA [default]\n")); + fprintf (stream, _("\ + -mintel64 accept only Intel64 ISA\n")); +@@ -13254,6 +13608,16 @@ i386_cons_align (int ignore ATTRIBUTE_UNUSED) + last_insn.kind = last_insn_directive; + last_insn.name = "constant directive"; + last_insn.file = as_where (&last_insn.line); ++ if (lfence_before_ret != lfence_before_ret_none) ++ { ++ if (lfence_before_indirect_branch != lfence_branch_none) ++ as_warn (_("constant directive skips -mlfence-before-ret " ++ "and -mlfence-before-indirect-branch")); ++ else ++ as_warn (_("constant directive skips -mlfence-before-ret")); ++ } ++ else if (lfence_before_indirect_branch != lfence_branch_none) ++ as_warn (_("constant directive skips -mlfence-before-indirect-branch")); + } + } + +diff --git a/gas/doc/c-i386.texi b/gas/doc/c-i386.texi +index c536759cb38..1dd99f91bb0 100644 +--- a/gas/doc/c-i386.texi ++++ b/gas/doc/c-i386.texi +@@ -464,6 +464,49 @@ on an instruction. It is equivalent to + @option{-malign-branch-prefix-size=5}. + The default doesn't align branches. + ++ at cindex @samp{-mlfence-after-load=} option, i386 ++ at cindex @samp{-mlfence-after-load=} option, x86-64 ++ at item -mlfence-after-load=@var{no} ++ at itemx -mlfence-after-load=@var{yes} ++These options control whether the assembler should generate lfence ++after load instructions. @option{-mlfence-after-load=@var{yes}} will ++generate lfence. @option{-mlfence-after-load=@var{no}} will not generate ++lfence, which is the default. ++ ++ at cindex @samp{-mlfence-before-indirect-branch=} option, i386 ++ at cindex @samp{-mlfence-before-indirect-branch=} option, x86-64 ++ at item -mlfence-before-indirect-branch=@var{none} ++ at item -mlfence-before-indirect-branch=@var{all} ++ at item -mlfence-before-indirect-branch=@var{register} ++ at itemx -mlfence-before-indirect-branch=@var{memory} ++These options control whether the assembler should generate lfence ++after indirect near branch instructions. ++ at option{-mlfence-before-indirect-branch=@var{all}} will generate lfence ++after indirect near branch via register and issue a warning before ++indirect near branch via memory. ++ at option{-mlfence-before-indirect-branch=@var{register}} will generate ++lfence after indirect near branch via register. ++ at option{-mlfence-before-indirect-branch=@var{memory}} will issue a ++warning before indirect near branch via memory. ++ at option{-mlfence-before-indirect-branch=@var{none}} will not generate ++lfence nor issue warning, which is the default. Note that lfence won't ++be generated before indirect near branch via register with ++ at option{-mlfence-after-load=@var{yes}} since lfence will be generated ++after loading branch target register. ++ ++ at cindex @samp{-mlfence-before-ret=} option, i386 ++ at cindex @samp{-mlfence-before-ret=} option, x86-64 ++ at item -mlfence-before-ret=@var{none} ++ at item -mlfence-before-ret=@var{or} ++ at itemx -mlfence-before-ret=@var{not} ++These options control whether the assembler should generate lfence ++before ret. @option{-mlfence-before-ret=@var{or}} will generate ++generate or instruction with lfence. ++ at option{-mlfence-before-ret=@var{not}} will generate not instruction ++with lfence. ++ at option{-mlfence-before-ret=@var{none}} will not generate lfence, ++which is the default. ++ + @cindex @samp{-mx86-used-note=} option, i386 + @cindex @samp{-mx86-used-note=} option, x86-64 + @item -mx86-used-note=@var{no} +-- +2.18.2 -- 2.24.1 From changqing.li at windriver.com Fri Mar 13 04:38:35 2020 From: changqing.li at windriver.com (Changqing Li) Date: Fri, 13 Mar 2020 12:38:35 +0800 Subject: [OE-core] [PATCH 2/2] parselogs.py: whitelist more xserver related error In-Reply-To: References: <1583892804-385900-1-git-send-email-changqing.li@windriver.com> <1583892804-385900-2-git-send-email-changqing.li@windriver.com> Message-ID: <51213a60-f041-3b60-1340-2dbea8adbb2a@windriver.com> On 3/11/20 4:26 PM, Richard Purdie wrote: > On Wed, 2020-03-11 at 10:13 +0800, changqing.li at windriver.com wrote: >> From: Changqing Li >> >> With default config, these errors always exist for >> core-image-sato, and xserver-nodm.server start successfully, >> these errors are not critially. >> >> If set default syslog to rsyslog, all these errors >> will go into daemon.log and user.log, then test_parselog >> will fail, so whitelist these errors >> >> Signed-off-by: Changqing Li >> --- >> meta/lib/oeqa/runtime/cases/parselogs.py | 12 +++++++++++- >> 1 file changed, 11 insertions(+), 1 deletion(-) >> >> diff --git a/meta/lib/oeqa/runtime/cases/parselogs.py >> b/meta/lib/oeqa/runtime/cases/parselogs.py >> index 6e22520..2a5e5c6 100644 >> --- a/meta/lib/oeqa/runtime/cases/parselogs.py >> +++ b/meta/lib/oeqa/runtime/cases/parselogs.py >> @@ -58,7 +58,15 @@ common_errors = [ >> "Failed to rename network interface", >> "Failed to process device, ignoring: Device or resource busy", >> "Cannot find a map file", >> - "[rdrand]: Initialization Failed" >> + "[rdrand]: Initialization Failed", >> + "libGL error:", >> + "[pulseaudio] authkey.c: Failed to open cookie file", >> + "[pulseaudio] authkey.c: Failed to load authentication key", >> + "FBIOPUT_VSCREENINFO failed, double buffering disabled", >> + "xserver-nodm.service: Failed with result 'exit-code'", >> + "xinit: server error", >> + "matchbox-wm: X error warning", >> + "X11 cannot support keycodes above 255" >> ] >> >> video_related = [ >> @@ -86,6 +94,8 @@ qemux86_common = [ >> 'tsc: HPET/PMTIMER calibration failed', >> "modeset(0): Failed to initialize the DRI2 extension", >> "glamor initialization failed", >> + "xf86OpenConsole: Switching VT failed", >> + "Fatal server error:", > "Fatal server error" means the server didn't start correctly? I doubt > we want to whitelist that one. > > With several of these you're right, they have been on the console for a > while and I'm worried that a) we don't see them in the logs and b) the > errors are occurring at all, we should really fix some of them, not > "hide" them. > > Can we fix any of them rather than whitelisting? > > If we really do want to "hide" them, I think at the very least we need > open bugs for some of them so we can track and fix the underlying > problems. We need the bugs open before any patch can merge. > > Cheers, > > Richard Thanks. I will do more research about this. > > > > > From wangmy at cn.fujitsu.com Fri Mar 13 11:11:06 2020 From: wangmy at cn.fujitsu.com (Wang Mingyu) Date: Fri, 13 Mar 2020 04:11:06 -0700 Subject: [OE-core] [PATCH] base-passwd: LICENSE changed to GPLv2 Message-ID: <1584097866-54513-1-git-send-email-wangmy@cn.fujitsu.com> Signed-off-by: Wang Mingyu --- meta/recipes-core/base-passwd/base-passwd_3.5.29.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb b/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb index d1aab09181..d01cd7e297 100644 --- a/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb +++ b/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb @@ -1,7 +1,7 @@ SUMMARY = "Base system master password/group files" DESCRIPTION = "The master copies of the user database files (/etc/passwd and /etc/group). The update-passwd tool is also provided to keep the system databases synchronized with these master files." SECTION = "base" -LICENSE = "GPLv2+" +LICENSE = "GPLv2" LIC_FILES_CHKSUM = "file://COPYING;md5=eb723b61539feef013de476e68b5c50a" RECIPE_NO_UPDATE_REASON = "Version 3.5.38 requires cdebconf for update-passwd utility" -- 2.17.1 From richard.purdie at linuxfoundation.org Fri Mar 13 07:09:36 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Fri, 13 Mar 2020 07:09:36 +0000 Subject: [OE-core] [PATCH] base-passwd: LICENSE changed to GPLv2 In-Reply-To: <1584097866-54513-1-git-send-email-wangmy@cn.fujitsu.com> References: <1584097866-54513-1-git-send-email-wangmy@cn.fujitsu.com> Message-ID: <44535d2e53175baa8b7b7969fa9276e924a43fca.camel@linuxfoundation.org> On Fri, 2020-03-13 at 04:11 -0700, Wang Mingyu wrote: > Signed-off-by: Wang Mingyu > --- > meta/recipes-core/base-passwd/base-passwd_3.5.29.bb | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb > b/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb > index d1aab09181..d01cd7e297 100644 > --- a/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb > +++ b/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb > @@ -1,7 +1,7 @@ > SUMMARY = "Base system master password/group files" > DESCRIPTION = "The master copies of the user database files > (/etc/passwd and /etc/group). The update-passwd tool is also > provided to keep the system databases synchronized with these master > files." > SECTION = "base" > -LICENSE = "GPLv2+" > +LICENSE = "GPLv2" > LIC_FILES_CHKSUM = > "file://COPYING;md5=eb723b61539feef013de476e68b5c50a" Why? The license file didn't change. This needs an explanation. Cheers, Richard From richard.purdie at linuxfoundation.org Fri Mar 13 07:22:03 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Fri, 13 Mar 2020 07:22:03 +0000 Subject: [OE-core] [PATCH 1/2] babletrace2: make manpages multilib identical In-Reply-To: <20200312142524.GB30953@joraj-alpa> References: <20200311222249.29880-1-jpuhlman@mvista.com> <20200312142524.GB30953@joraj-alpa> Message-ID: On Thu, 2020-03-12 at 10:25 -0400, Jonathan Rajotte-Julien wrote: > Is this something upstream (lttng-dev mailing list) should be > interested in? Its a tough one as the man page is technically correct but the references give us a challenge in packaging it. I can therefore understand upstreams not accepting changes like this but if they were open to some kind of tweak it does help us not have to have patches... Cheers, Richard > Cheers > > On Wed, Mar 11, 2020 at 03:22:48PM -0700, Jeremy A. Puhlman wrote: > > From: Jeremy Puhlman > > > > Signed-off-by: Jeremy A. Puhlman > > --- > > .../0001-Make-manpages-multilib-identical.patch | 28 > > ++++++++++++++++++++++ > > meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb | 1 + > > 2 files changed, 29 insertions(+) > > create mode 100644 meta/recipes-kernel/lttng/babeltrace2/0001- > > Make-manpages-multilib-identical.patch > > > > diff --git a/meta/recipes-kernel/lttng/babeltrace2/0001-Make- > > manpages-multilib-identical.patch b/meta/recipes- > > kernel/lttng/babeltrace2/0001-Make-manpages-multilib- > > identical.patch > > new file mode 100644 > > index 0000000000..2401b176e6 > > --- /dev/null > > +++ b/meta/recipes-kernel/lttng/babeltrace2/0001-Make-manpages- > > multilib-identical.patch > > @@ -0,0 +1,28 @@ > > +From 56986190e4b0c10945ce6aaa7ca10d6bd8a26a39 Mon Sep 17 00:00:00 > > 2001 > > +From: Jeremy Puhlman > > +Date: Mon, 9 Mar 2020 21:10:35 +0000 > > +Subject: [PATCH] Make manpages multilib identical > > + > > +Upstream-Status: Pending > > +Signed-off-by: Jeremy Puhlman > > +--- > > + doc/man/asciidoc-attrs.conf.in | 4 ++-- > > + 1 file changed, 2 insertions(+), 2 deletions(-) > > + > > +diff --git a/doc/man/asciidoc-attrs.conf.in b/doc/man/asciidoc- > > attrs.conf.in > > +index ad1183f1..e11c7031 100644 > > +--- a/doc/man/asciidoc-attrs.conf.in > > ++++ b/doc/man/asciidoc-attrs.conf.in > > +@@ -1,7 +1,7 @@ > > + [attributes] > > + # default values > > +-system_plugin_path="@LIBDIR@/babeltrace2/plugins" > > +-system_plugin_provider_path="@LIBDIR@/babeltrace2/plugin- > > providers" > > ++system_plugin_path="@prefix@/lib*/babeltrace2/plugins" > > ++system_plugin_provider_path="@prefix@/lib*/babeltrace2/plugin- > > providers" > > + babeltrace_version="@PACKAGE_VERSION@" > > + enable_debug_info="@ENABLE_DEBUG_INFO_VAL@" > > + defrdport=5344 > > +-- > > From bunk at stusta.de Fri Mar 13 08:15:16 2020 From: bunk at stusta.de (Adrian Bunk) Date: Fri, 13 Mar 2020 10:15:16 +0200 Subject: [OE-core] [PATCH] gcc: Upgrade to 9.3 bugfix release In-Reply-To: <20200312230840.751166-1-raj.khem@gmail.com> References: <20200312230840.751166-1-raj.khem@gmail.com> Message-ID: <20200313081516.GA24555@localhost> On Thu, Mar 12, 2020 at 04:08:40PM -0700, Khem Raj wrote: >... > ...le-sysroot-support-for-nativesdk-gcc.patch | 187 +------ >... Why was part of this patch removed? cu Adrian From jupiter.hce at gmail.com Fri Mar 13 09:15:17 2020 From: jupiter.hce at gmail.com (JH) Date: Fri, 13 Mar 2020 20:15:17 +1100 Subject: [OE-core] menuconf u-boot Message-ID: Hi, I tried to run bitbake -c menuconfig u-boot, it popped up a terminal u-boot-imx configuration: make: *** No rule make target 'menuconfig'. Stop. Command failed. Press any key to continue... How can I run menuconfig u-boot? Thank you. Kind regards, - jh From eichest at gmail.com Fri Mar 13 11:09:07 2020 From: eichest at gmail.com (eichest at gmail.com) Date: Fri, 13 Mar 2020 12:09:07 +0100 Subject: [OE-core] [PATCH] initramfs-framework: fix boothang when console=null Message-ID: <20200313110907.8700-1-stefan.eichenberger@toradex.com> From: Stefan Eichenberger If console=null systemd-udevd throws an assertion which prevents the system from booting. This patch redirects stdin, stdout and stderr to /dev/null in case that the console can't be opened so that udevd still boots. A systemd issue was reported here. However, they will not fix this specific use-case: https://github.com/systemd/systemd/issues/13332 Signed-off-by: Stefan Eichenberger --- meta/recipes-core/initrdscripts/initramfs-framework/udev | 3 +++ 1 file changed, 3 insertions(+) diff --git a/meta/recipes-core/initrdscripts/initramfs-framework/udev b/meta/recipes-core/initrdscripts/initramfs-framework/udev index 87551ff4a9..4898b89246 100644 --- a/meta/recipes-core/initrdscripts/initramfs-framework/udev +++ b/meta/recipes-core/initrdscripts/initramfs-framework/udev @@ -41,6 +41,9 @@ udev_run() { mkdir -p /run mkdir -p /var/run + # Workaround if console=null, systemd-udevd needs valid stdin, stdout and stderr to work + sh -c "exec 4< /dev/console" || { exec 0> /dev/null; exec 1> /dev/null; exec 2> /dev/null; } + $_UDEV_DAEMON --daemon udevadm trigger --action=add udevadm settle -- 2.17.1 From trevor.gamblin at windriver.com Fri Mar 13 11:27:20 2020 From: trevor.gamblin at windriver.com (Trevor Gamblin) Date: Fri, 13 Mar 2020 04:27:20 -0700 Subject: [OE-core] [PATCH] python: upgrade 3.8.1 -> 3.8.2 Message-ID: <20200313112720.151263-1-trevor.gamblin@windriver.com> THE LICENSE checksum changed in this update due to copyright notice added for 2020. Signed-off-by: Trevor Gamblin --- .../python/{python3_3.8.1.bb => python3_3.8.2.bb} | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) rename meta/recipes-devtools/python/{python3_3.8.1.bb => python3_3.8.2.bb} (98%) diff --git a/meta/recipes-devtools/python/python3_3.8.1.bb b/meta/recipes-devtools/python/python3_3.8.2.bb similarity index 98% rename from meta/recipes-devtools/python/python3_3.8.1.bb rename to meta/recipes-devtools/python/python3_3.8.2.bb index 5e3c29cb4c..fc01935948 100644 --- a/meta/recipes-devtools/python/python3_3.8.1.bb +++ b/meta/recipes-devtools/python/python3_3.8.2.bb @@ -3,7 +3,7 @@ HOMEPAGE = "http://www.python.org" LICENSE = "PSFv2" SECTION = "devel/python" -LIC_FILES_CHKSUM = "file://LICENSE;md5=e466242989bd33c1bd2b6a526a742498" +LIC_FILES_CHKSUM = "file://LICENSE;md5=203a6dbc802ee896020a47161e759642" SRC_URI = "http://www.python.org/ftp/python/${PV}/Python-${PV}.tar.xz \ file://run-ptest \ @@ -40,8 +40,8 @@ SRC_URI_append_class-native = " \ file://0001-Don-t-search-system-for-headers-libraries.patch \ " -SRC_URI[md5sum] = "b3fb85fd479c0bf950c626ef80cacb57" -SRC_URI[sha256sum] = "75894117f6db7051c1b34f37410168844bbb357c139a8a10a352e9bf8be594e8" +SRC_URI[md5sum] = "e9d6ebc92183a177b8e8a58cad5b8d67" +SRC_URI[sha256sum] = "2646e7dc233362f59714c6193017bb2d6f7b38d6ab4a0cb5fbac5c36c4d845df" # exclude pre-releases for both python 2.x and 3.x UPSTREAM_CHECK_REGEX = "[Pp]ython-(?P\d+(\.\d+)+).tar" -- 2.17.1 From wallinux at gmail.com Fri Mar 13 12:14:58 2020 From: wallinux at gmail.com (Anders Wallin) Date: Fri, 13 Mar 2020 13:14:58 +0100 Subject: [OE-core] [PATCH] babeltrace2: updated to 2.0.2 Message-ID: <20200313121458.32066-1-wallinux@gmail.com> Signed-off-by: Anders Wallin --- .../lttng/{babeltrace2_2.0.1.bb => babeltrace2_2.0.2.bb} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename meta/recipes-kernel/lttng/{babeltrace2_2.0.1.bb => babeltrace2_2.0.2.bb} (98%) diff --git a/meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb b/meta/recipes-kernel/lttng/babeltrace2_2.0.2.bb similarity index 98% rename from meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb rename to meta/recipes-kernel/lttng/babeltrace2_2.0.2.bb index e71ac1ad57..0791c654f9 100644 --- a/meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb +++ b/meta/recipes-kernel/lttng/babeltrace2_2.0.2.bb @@ -13,7 +13,7 @@ SRC_URI = "git://git.linuxfoundation.org/diamon/babeltrace.git;branch=stable-2.0 file://0001-Make-manpages-multilib-identical.patch \ file://0001-fs.c-initialize-other_entry.patch \ " -SRCREV = "06df58f89ee51b1a2c6a2c187ec3f15691633910" +SRCREV = "33003c352ed56aa49e0b3df272bbab6fac36cae8" UPSTREAM_CHECK_GITTAGREGEX = "v(?P2(\.\d+)+)$" S = "${WORKDIR}/git" -- 2.25.1 From richard.purdie at linuxfoundation.org Fri Mar 13 12:27:54 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Fri, 13 Mar 2020 12:27:54 +0000 Subject: [OE-core] [PATCH] gcc: Upgrade to 9.3 bugfix release In-Reply-To: <20200313081516.GA24555@localhost> References: <20200312230840.751166-1-raj.khem@gmail.com> <20200313081516.GA24555@localhost> Message-ID: <8f52d0044ca78ef655eec2113fca67eeed7f6963.camel@linuxfoundation.org> On Fri, 2020-03-13 at 10:15 +0200, Adrian Bunk wrote: > On Thu, Mar 12, 2020 at 04:08:40PM -0700, Khem Raj wrote: > > ... > > ...le-sysroot-support-for-nativesdk-gcc.patch | 187 +------ > > ... > > Why was part of this patch removed? It looked like this commit was dropped: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=5507707f0d36a612992758dabd58d68a72ab0cfc unintentionally. I've added it back into the patch in master-next. Cheers, Richard From richard.purdie at linuxfoundation.org Fri Mar 13 13:40:36 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Fri, 13 Mar 2020 13:40:36 +0000 Subject: [OE-core] [PATCH] babeltrace2: initialize the other_entry pointer In-Reply-To: <20200312143304.GC30953@joraj-alpa> References: <1583934573-94011-1-git-send-email-mingli.yu@windriver.com> <20200312143304.GC30953@joraj-alpa> Message-ID: <280c60ac662ccfe0388f43718309aca1cf03a87f.camel@linuxfoundation.org> On Thu, 2020-03-12 at 10:33 -0400, Jonathan Rajotte-Julien wrote: > Hi Mingli, > > Thanks for also posting this on the lttng-dev mailing list. I'm sure > we can get > this in fairly quickly upstream. > > This is more a question for Richard and other core members of oe, is > this kind of patch pertinent for upstream oe considering it is only > silencing a warning (based on [1])? > > [1] > https://lists.lttng.org/pipermail/lttng-dev/2020-March/029550.html I took it based on the fact it was submitted upstream and I thought it was fixing some kind potential data init issue. If it is just a compiler warning then my opinion of it at this point in the release cycle would be quite different. It does show the importance of commit descriptions. It was tested and merged so I'll leave it but you make some good points. Cheers, Richard From raj.khem at gmail.com Fri Mar 13 13:57:43 2020 From: raj.khem at gmail.com (Khem Raj) Date: Fri, 13 Mar 2020 06:57:43 -0700 Subject: [OE-core] [PATCH] gcc: Upgrade to 9.3 bugfix release In-Reply-To: <8f52d0044ca78ef655eec2113fca67eeed7f6963.camel@linuxfoundation.org> References: <20200312230840.751166-1-raj.khem@gmail.com> <20200313081516.GA24555@localhost> <8f52d0044ca78ef655eec2113fca67eeed7f6963.camel@linuxfoundation.org> Message-ID: On Fri, Mar 13, 2020 at 5:27 AM Richard Purdie wrote: > > On Fri, 2020-03-13 at 10:15 +0200, Adrian Bunk wrote: > > On Thu, Mar 12, 2020 at 04:08:40PM -0700, Khem Raj wrote: > > > ... > > > ...le-sysroot-support-for-nativesdk-gcc.patch | 187 +------ > > > ... > > > > Why was part of this patch removed? > > It looked like this commit was dropped: > > http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=5507707f0d36a612992758dabd58d68a72ab0cfc > yeah my rebase missed this since it was a recent change. Thanks for catching this > unintentionally. I've added it back into the patch in master-next. > > Cheers, > > Richard > > > From raj.khem at gmail.com Fri Mar 13 14:42:21 2020 From: raj.khem at gmail.com (Khem Raj) Date: Fri, 13 Mar 2020 07:42:21 -0700 Subject: [OE-core] [PATCH 2/2] binutils: fix CVE-2020-0551 In-Reply-To: <20200313010939.586772-2-anuj.mittal@intel.com> References: <20200313010939.586772-1-anuj.mittal@intel.com> <20200313010939.586772-2-anuj.mittal@intel.com> Message-ID: Please backport the tests patch [1] as well along with this [1] https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=97b4a8f744f437fa35afbe20f53e657e9de957cd On 3/12/20 6:09 PM, Anuj Mittal wrote: > Signed-off-by: Anuj Mittal > --- > .../binutils/binutils-2.34.inc | 1 + > .../binutils/binutils/CVE-2020-0551.patch | 549 ++++++++++++++++++ > 2 files changed, 550 insertions(+) > create mode 100644 meta/recipes-devtools/binutils/binutils/CVE-2020-0551.patch > > diff --git a/meta/recipes-devtools/binutils/binutils-2.34.inc b/meta/recipes-devtools/binutils/binutils-2.34.inc > index eaaa5ed2ac..ed9f902fd2 100644 > --- a/meta/recipes-devtools/binutils/binutils-2.34.inc > +++ b/meta/recipes-devtools/binutils/binutils-2.34.inc > @@ -40,6 +40,7 @@ SRC_URI = "\ > file://0013-fix-the-incorrect-assembling-for-ppc-wait-mnemonic.patch \ > file://0014-Detect-64-bit-MIPS-targets.patch \ > file://0015-sync-with-OE-libtool-changes.patch \ > + file://CVE-2020-0551.patch \ > " > S = "${WORKDIR}/git" > > diff --git a/meta/recipes-devtools/binutils/binutils/CVE-2020-0551.patch b/meta/recipes-devtools/binutils/binutils/CVE-2020-0551.patch > new file mode 100644 > index 0000000000..53e3caf445 > --- /dev/null > +++ b/meta/recipes-devtools/binutils/binutils/CVE-2020-0551.patch > @@ -0,0 +1,549 @@ > +From ae531041c7c5956672342f89c486a011c84f027f Mon Sep 17 00:00:00 2001 > +From: "H.J. Lu" > +Date: Wed, 11 Mar 2020 09:46:19 -0700 > +Subject: [PATCH 1/1] i386: Generate lfence with load/indirect branch/ret > + [CVE-2020-0551] > + > +Add 3 command-line options to generate lfence for load, indirect near > +branch and ret to help mitigate: > + > +https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00334.html > +http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-0551 > + > +1. -mlfence-after-load=[no|yes]: > + -mlfence-after-load=yes generates lfence after load instructions. > +2. -mlfence-before-indirect-branch=[none|all|memory|register]: > + a. -mlfence-before-indirect-branch=all generates lfence before indirect > + near branches via register and a warning before indirect near branches > + via memory. > + b. -mlfence-before-indirect-branch=memory issue a warning before > + indirect near branches via memory. > + c. -mlfence-before-indirect-branch=register generates lfence before > + indirect near branches via register. > +Note that lfence won't be generated before indirect near branches via > +register with -mlfence-after-load=yes since lfence will be generated > +after loading branch target register. > +3. -mlfence-before-ret=[none|or|not] > + a. -mlfence-before-ret=or generates or with lfence before ret. > + b. -mlfence-before-ret=not generates not with lfence before ret. > + > +A warning will be issued and lfence won't be generated before indirect > +near branch and ret if the previous item is a prefix or a constant > +directive, which may be used to hardcode an instruction, since there > +is no clear instruction boundary. > + > + * config/tc-i386.c (lfence_after_load): New. > + (lfence_before_indirect_branch_kind): New. > + (lfence_before_indirect_branch): New. > + (lfence_before_ret_kind): New. > + (lfence_before_ret): New. > + (last_insn): New. > + (load_insn_p): New. > + (insert_lfence_after): New. > + (insert_lfence_before): New. > + (md_assemble): Call insert_lfence_before and insert_lfence_after. > + Set last_insn. > + (OPTION_MLFENCE_AFTER_LOAD): New. > + (OPTION_MLFENCE_BEFORE_INDIRECT_BRANCH): New. > + (OPTION_MLFENCE_BEFORE_RET): New. > + (md_longopts): Add -mlfence-after-load=, > + -mlfence-before-indirect-branch= and -mlfence-before-ret=. > + (md_parse_option): Handle -mlfence-after-load=, > + -mlfence-before-indirect-branch= and -mlfence-before-ret=. > + (md_show_usage): Display -mlfence-after-load=, > + -mlfence-before-indirect-branch= and -mlfence-before-ret=. > + (i386_cons_align): New. > + * config/tc-i386.h (i386_cons_align): New. > + (md_cons_align): New. > + * doc/c-i386.texi: Document -mlfence-after-load=, > + -mlfence-before-indirect-branch= and -mlfence-before-ret=. > + > +Signed-off-by: Anuj Mittal > +Upstream-Status: Backport [https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=ae531041c7c5956672342f89c486a011c84f027f] > +CVE: CVE-2020-0551 > +--- > +diff --git a/gas/config/tc-i386.c b/gas/config/tc-i386.c > +index b020f39c863..09063f784b7 100644 > +--- a/gas/config/tc-i386.c > ++++ b/gas/config/tc-i386.c > +@@ -629,7 +629,29 @@ static int omit_lock_prefix = 0; > + "lock addl $0, (%{re}sp)". */ > + static int avoid_fence = 0; > + > +-/* Type of the previous instruction. */ > ++/* 1 if lfence should be inserted after every load. */ > ++static int lfence_after_load = 0; > ++ > ++/* Non-zero if lfence should be inserted before indirect branch. */ > ++static enum lfence_before_indirect_branch_kind > ++ { > ++ lfence_branch_none = 0, > ++ lfence_branch_register, > ++ lfence_branch_memory, > ++ lfence_branch_all > ++ } > ++lfence_before_indirect_branch; > ++ > ++/* Non-zero if lfence should be inserted before ret. */ > ++static enum lfence_before_ret_kind > ++ { > ++ lfence_before_ret_none = 0, > ++ lfence_before_ret_not, > ++ lfence_before_ret_or > ++ } > ++lfence_before_ret; > ++ > ++/* Types of previous instruction is .byte or prefix. */ > + static struct > + { > + segT seg; > +@@ -4311,6 +4333,283 @@ optimize_encoding (void) > + } > + } > + > ++/* Return non-zero for load instruction. */ > ++ > ++static int > ++load_insn_p (void) > ++{ > ++ unsigned int dest; > ++ int any_vex_p = is_any_vex_encoding (&i.tm); > ++ unsigned int base_opcode = i.tm.base_opcode | 1; > ++ > ++ if (!any_vex_p) > ++ { > ++ /* lea */ > ++ if (i.tm.base_opcode == 0x8d) > ++ return 0; > ++ > ++ /* pop */ > ++ if ((i.tm.base_opcode & ~7) == 0x58 > ++ || (i.tm.base_opcode == 0x8f && i.tm.extension_opcode == 0)) > ++ return 1; > ++ > ++ /* movs, cmps, lods, scas. */ > ++ if ((i.tm.base_opcode | 0xb) == 0xaf) > ++ return 1; > ++ > ++ /* outs */ > ++ if (base_opcode == 0x6f) > ++ return 1; > ++ } > ++ > ++ /* No memory operand. */ > ++ if (!i.mem_operands) > ++ return 0; > ++ > ++ if (any_vex_p) > ++ { > ++ /* vldmxcsr. */ > ++ if (i.tm.base_opcode == 0xae > ++ && i.tm.opcode_modifier.vex > ++ && i.tm.opcode_modifier.vexopcode == VEX0F > ++ && i.tm.extension_opcode == 2) > ++ return 1; > ++ } > ++ else > ++ { > ++ /* test, not, neg, mul, imul, div, idiv. */ > ++ if ((i.tm.base_opcode == 0xf6 || i.tm.base_opcode == 0xf7) > ++ && i.tm.extension_opcode != 1) > ++ return 1; > ++ > ++ /* inc, dec. */ > ++ if (base_opcode == 0xff && i.tm.extension_opcode <= 1) > ++ return 1; > ++ > ++ /* add, or, adc, sbb, and, sub, xor, cmp. */ > ++ if (i.tm.base_opcode >= 0x80 && i.tm.base_opcode <= 0x83) > ++ return 1; > ++ > ++ /* bt, bts, btr, btc. */ > ++ if (i.tm.base_opcode == 0xfba > ++ && (i.tm.extension_opcode >= 4 && i.tm.extension_opcode <= 7)) > ++ return 1; > ++ > ++ /* rol, ror, rcl, rcr, shl/sal, shr, sar. */ > ++ if ((base_opcode == 0xc1 > ++ || (i.tm.base_opcode >= 0xd0 && i.tm.base_opcode <= 0xd3)) > ++ && i.tm.extension_opcode != 6) > ++ return 1; > ++ > ++ /* cmpxchg8b, cmpxchg16b, xrstors. */ > ++ if (i.tm.base_opcode == 0xfc7 > ++ && (i.tm.extension_opcode == 1 || i.tm.extension_opcode == 3)) > ++ return 1; > ++ > ++ /* fxrstor, ldmxcsr, xrstor. */ > ++ if (i.tm.base_opcode == 0xfae > ++ && (i.tm.extension_opcode == 1 > ++ || i.tm.extension_opcode == 2 > ++ || i.tm.extension_opcode == 5)) > ++ return 1; > ++ > ++ /* lgdt, lidt, lmsw. */ > ++ if (i.tm.base_opcode == 0xf01 > ++ && (i.tm.extension_opcode == 2 > ++ || i.tm.extension_opcode == 3 > ++ || i.tm.extension_opcode == 6)) > ++ return 1; > ++ > ++ /* vmptrld */ > ++ if (i.tm.base_opcode == 0xfc7 > ++ && i.tm.extension_opcode == 6) > ++ return 1; > ++ > ++ /* Check for x87 instructions. */ > ++ if (i.tm.base_opcode >= 0xd8 && i.tm.base_opcode <= 0xdf) > ++ { > ++ /* Skip fst, fstp, fstenv, fstcw. */ > ++ if (i.tm.base_opcode == 0xd9 > ++ && (i.tm.extension_opcode == 2 > ++ || i.tm.extension_opcode == 3 > ++ || i.tm.extension_opcode == 6 > ++ || i.tm.extension_opcode == 7)) > ++ return 0; > ++ > ++ /* Skip fisttp, fist, fistp, fstp. */ > ++ if (i.tm.base_opcode == 0xdb > ++ && (i.tm.extension_opcode == 1 > ++ || i.tm.extension_opcode == 2 > ++ || i.tm.extension_opcode == 3 > ++ || i.tm.extension_opcode == 7)) > ++ return 0; > ++ > ++ /* Skip fisttp, fst, fstp, fsave, fstsw. */ > ++ if (i.tm.base_opcode == 0xdd > ++ && (i.tm.extension_opcode == 1 > ++ || i.tm.extension_opcode == 2 > ++ || i.tm.extension_opcode == 3 > ++ || i.tm.extension_opcode == 6 > ++ || i.tm.extension_opcode == 7)) > ++ return 0; > ++ > ++ /* Skip fisttp, fist, fistp, fbstp, fistp. */ > ++ if (i.tm.base_opcode == 0xdf > ++ && (i.tm.extension_opcode == 1 > ++ || i.tm.extension_opcode == 2 > ++ || i.tm.extension_opcode == 3 > ++ || i.tm.extension_opcode == 6 > ++ || i.tm.extension_opcode == 7)) > ++ return 0; > ++ > ++ return 1; > ++ } > ++ } > ++ > ++ dest = i.operands - 1; > ++ > ++ /* Check fake imm8 operand and 3 source operands. */ > ++ if ((i.tm.opcode_modifier.immext > ++ || i.tm.opcode_modifier.vexsources == VEX3SOURCES) > ++ && i.types[dest].bitfield.imm8) > ++ dest--; > ++ > ++ /* add, or, adc, sbb, and, sub, xor, cmp, test, xchg, xadd */ > ++ if (!any_vex_p > ++ && (base_opcode == 0x1 > ++ || base_opcode == 0x9 > ++ || base_opcode == 0x11 > ++ || base_opcode == 0x19 > ++ || base_opcode == 0x21 > ++ || base_opcode == 0x29 > ++ || base_opcode == 0x31 > ++ || base_opcode == 0x39 > ++ || (i.tm.base_opcode >= 0x84 && i.tm.base_opcode <= 0x87) > ++ || base_opcode == 0xfc1)) > ++ return 1; > ++ > ++ /* Check for load instruction. */ > ++ return (i.types[dest].bitfield.class != ClassNone > ++ || i.types[dest].bitfield.instance == Accum); > ++} > ++ > ++/* Output lfence, 0xfaee8, after instruction. */ > ++ > ++static void > ++insert_lfence_after (void) > ++{ > ++ if (lfence_after_load && load_insn_p ()) > ++ { > ++ char *p = frag_more (3); > ++ *p++ = 0xf; > ++ *p++ = 0xae; > ++ *p = 0xe8; > ++ } > ++} > ++ > ++/* Output lfence, 0xfaee8, before instruction. */ > ++ > ++static void > ++insert_lfence_before (void) > ++{ > ++ char *p; > ++ > ++ if (is_any_vex_encoding (&i.tm)) > ++ return; > ++ > ++ if (i.tm.base_opcode == 0xff > ++ && (i.tm.extension_opcode == 2 || i.tm.extension_opcode == 4)) > ++ { > ++ /* Insert lfence before indirect branch if needed. */ > ++ > ++ if (lfence_before_indirect_branch == lfence_branch_none) > ++ return; > ++ > ++ if (i.operands != 1) > ++ abort (); > ++ > ++ if (i.reg_operands == 1) > ++ { > ++ /* Indirect branch via register. Don't insert lfence with > ++ -mlfence-after-load=yes. */ > ++ if (lfence_after_load > ++ || lfence_before_indirect_branch == lfence_branch_memory) > ++ return; > ++ } > ++ else if (i.mem_operands == 1 > ++ && lfence_before_indirect_branch != lfence_branch_register) > ++ { > ++ as_warn (_("indirect `%s` with memory operand should be avoided"), > ++ i.tm.name); > ++ return; > ++ } > ++ else > ++ return; > ++ > ++ if (last_insn.kind != last_insn_other > ++ && last_insn.seg == now_seg) > ++ { > ++ as_warn_where (last_insn.file, last_insn.line, > ++ _("`%s` skips -mlfence-before-indirect-branch on `%s`"), > ++ last_insn.name, i.tm.name); > ++ return; > ++ } > ++ > ++ p = frag_more (3); > ++ *p++ = 0xf; > ++ *p++ = 0xae; > ++ *p = 0xe8; > ++ return; > ++ } > ++ > ++ /* Output or/not and lfence before ret. */ > ++ if (lfence_before_ret != lfence_before_ret_none > ++ && (i.tm.base_opcode == 0xc2 > ++ || i.tm.base_opcode == 0xc3 > ++ || i.tm.base_opcode == 0xca > ++ || i.tm.base_opcode == 0xcb)) > ++ { > ++ if (last_insn.kind != last_insn_other > ++ && last_insn.seg == now_seg) > ++ { > ++ as_warn_where (last_insn.file, last_insn.line, > ++ _("`%s` skips -mlfence-before-ret on `%s`"), > ++ last_insn.name, i.tm.name); > ++ return; > ++ } > ++ if (lfence_before_ret == lfence_before_ret_or) > ++ { > ++ /* orl: 0x830c2400. */ > ++ p = frag_more ((flag_code == CODE_64BIT ? 1 : 0) + 4 + 3); > ++ if (flag_code == CODE_64BIT) > ++ *p++ = 0x48; > ++ *p++ = 0x83; > ++ *p++ = 0xc; > ++ *p++ = 0x24; > ++ *p++ = 0x0; > ++ } > ++ else > ++ { > ++ p = frag_more ((flag_code == CODE_64BIT ? 2 : 0) + 6 + 3); > ++ /* notl: 0xf71424. */ > ++ if (flag_code == CODE_64BIT) > ++ *p++ = 0x48; > ++ *p++ = 0xf7; > ++ *p++ = 0x14; > ++ *p++ = 0x24; > ++ /* notl: 0xf71424. */ > ++ if (flag_code == CODE_64BIT) > ++ *p++ = 0x48; > ++ *p++ = 0xf7; > ++ *p++ = 0x14; > ++ *p++ = 0x24; > ++ } > ++ *p++ = 0xf; > ++ *p++ = 0xae; > ++ *p = 0xe8; > ++ } > ++} > ++ > + /* This is the guts of the machine-dependent assembler. LINE points to a > + machine dependent instruction. This function is supposed to emit > + the frags/bytes it assembles to. */ > +@@ -4628,9 +4927,13 @@ md_assemble (char *line) > + if (i.rex != 0) > + add_prefix (REX_OPCODE | i.rex); > + > ++ insert_lfence_before (); > ++ > + /* We are ready to output the insn. */ > + output_insn (); > + > ++ insert_lfence_after (); > ++ > + last_insn.seg = now_seg; > + > + if (i.tm.opcode_modifier.isprefix) > +@@ -12250,6 +12553,9 @@ const char *md_shortopts = "qnO::"; > + #define OPTION_MALIGN_BRANCH_PREFIX_SIZE (OPTION_MD_BASE + 28) > + #define OPTION_MALIGN_BRANCH (OPTION_MD_BASE + 29) > + #define OPTION_MBRANCHES_WITH_32B_BOUNDARIES (OPTION_MD_BASE + 30) > ++#define OPTION_MLFENCE_AFTER_LOAD (OPTION_MD_BASE + 31) > ++#define OPTION_MLFENCE_BEFORE_INDIRECT_BRANCH (OPTION_MD_BASE + 32) > ++#define OPTION_MLFENCE_BEFORE_RET (OPTION_MD_BASE + 33) > + > + struct option md_longopts[] = > + { > +@@ -12289,6 +12595,10 @@ struct option md_longopts[] = > + {"malign-branch-prefix-size", required_argument, NULL, OPTION_MALIGN_BRANCH_PREFIX_SIZE}, > + {"malign-branch", required_argument, NULL, OPTION_MALIGN_BRANCH}, > + {"mbranches-within-32B-boundaries", no_argument, NULL, OPTION_MBRANCHES_WITH_32B_BOUNDARIES}, > ++ {"mlfence-after-load", required_argument, NULL, OPTION_MLFENCE_AFTER_LOAD}, > ++ {"mlfence-before-indirect-branch", required_argument, NULL, > ++ OPTION_MLFENCE_BEFORE_INDIRECT_BRANCH}, > ++ {"mlfence-before-ret", required_argument, NULL, OPTION_MLFENCE_BEFORE_RET}, > + {"mamd64", no_argument, NULL, OPTION_MAMD64}, > + {"mintel64", no_argument, NULL, OPTION_MINTEL64}, > + {NULL, no_argument, NULL, 0} > +@@ -12668,6 +12978,41 @@ md_parse_option (int c, const char *arg) > + as_fatal (_("invalid -mfence-as-lock-add= option: `%s'"), arg); > + break; > + > ++ case OPTION_MLFENCE_AFTER_LOAD: > ++ if (strcasecmp (arg, "yes") == 0) > ++ lfence_after_load = 1; > ++ else if (strcasecmp (arg, "no") == 0) > ++ lfence_after_load = 0; > ++ else > ++ as_fatal (_("invalid -mlfence-after-load= option: `%s'"), arg); > ++ break; > ++ > ++ case OPTION_MLFENCE_BEFORE_INDIRECT_BRANCH: > ++ if (strcasecmp (arg, "all") == 0) > ++ lfence_before_indirect_branch = lfence_branch_all; > ++ else if (strcasecmp (arg, "memory") == 0) > ++ lfence_before_indirect_branch = lfence_branch_memory; > ++ else if (strcasecmp (arg, "register") == 0) > ++ lfence_before_indirect_branch = lfence_branch_register; > ++ else if (strcasecmp (arg, "none") == 0) > ++ lfence_before_indirect_branch = lfence_branch_none; > ++ else > ++ as_fatal (_("invalid -mlfence-before-indirect-branch= option: `%s'"), > ++ arg); > ++ break; > ++ > ++ case OPTION_MLFENCE_BEFORE_RET: > ++ if (strcasecmp (arg, "or") == 0) > ++ lfence_before_ret = lfence_before_ret_or; > ++ else if (strcasecmp (arg, "not") == 0) > ++ lfence_before_ret = lfence_before_ret_not; > ++ else if (strcasecmp (arg, "none") == 0) > ++ lfence_before_ret = lfence_before_ret_none; > ++ else > ++ as_fatal (_("invalid -mlfence-before-ret= option: `%s'"), > ++ arg); > ++ break; > ++ > + case OPTION_MRELAX_RELOCATIONS: > + if (strcasecmp (arg, "yes") == 0) > + generate_relax_relocations = 1; > +@@ -13025,6 +13370,15 @@ md_show_usage (FILE *stream) > + -mbranches-within-32B-boundaries\n\ > + align branches within 32 byte boundary\n")); > + fprintf (stream, _("\ > ++ -mlfence-after-load=[no|yes] (default: no)\n\ > ++ generate lfence after load\n")); > ++ fprintf (stream, _("\ > ++ -mlfence-before-indirect-branch=[none|all|register|memory] (default: none)\n\ > ++ generate lfence before indirect near branch\n")); > ++ fprintf (stream, _("\ > ++ -mlfence-before-ret=[none|or|not] (default: none)\n\ > ++ generate lfence before ret\n")); > ++ fprintf (stream, _("\ > + -mamd64 accept only AMD64 ISA [default]\n")); > + fprintf (stream, _("\ > + -mintel64 accept only Intel64 ISA\n")); > +@@ -13254,6 +13608,16 @@ i386_cons_align (int ignore ATTRIBUTE_UNUSED) > + last_insn.kind = last_insn_directive; > + last_insn.name = "constant directive"; > + last_insn.file = as_where (&last_insn.line); > ++ if (lfence_before_ret != lfence_before_ret_none) > ++ { > ++ if (lfence_before_indirect_branch != lfence_branch_none) > ++ as_warn (_("constant directive skips -mlfence-before-ret " > ++ "and -mlfence-before-indirect-branch")); > ++ else > ++ as_warn (_("constant directive skips -mlfence-before-ret")); > ++ } > ++ else if (lfence_before_indirect_branch != lfence_branch_none) > ++ as_warn (_("constant directive skips -mlfence-before-indirect-branch")); > + } > + } > + > +diff --git a/gas/doc/c-i386.texi b/gas/doc/c-i386.texi > +index c536759cb38..1dd99f91bb0 100644 > +--- a/gas/doc/c-i386.texi > ++++ b/gas/doc/c-i386.texi > +@@ -464,6 +464,49 @@ on an instruction. It is equivalent to > + @option{-malign-branch-prefix-size=5}. > + The default doesn't align branches. > + > ++ at cindex @samp{-mlfence-after-load=} option, i386 > ++ at cindex @samp{-mlfence-after-load=} option, x86-64 > ++ at item -mlfence-after-load=@var{no} > ++ at itemx -mlfence-after-load=@var{yes} > ++These options control whether the assembler should generate lfence > ++after load instructions. @option{-mlfence-after-load=@var{yes}} will > ++generate lfence. @option{-mlfence-after-load=@var{no}} will not generate > ++lfence, which is the default. > ++ > ++ at cindex @samp{-mlfence-before-indirect-branch=} option, i386 > ++ at cindex @samp{-mlfence-before-indirect-branch=} option, x86-64 > ++ at item -mlfence-before-indirect-branch=@var{none} > ++ at item -mlfence-before-indirect-branch=@var{all} > ++ at item -mlfence-before-indirect-branch=@var{register} > ++ at itemx -mlfence-before-indirect-branch=@var{memory} > ++These options control whether the assembler should generate lfence > ++after indirect near branch instructions. > ++ at option{-mlfence-before-indirect-branch=@var{all}} will generate lfence > ++after indirect near branch via register and issue a warning before > ++indirect near branch via memory. > ++ at option{-mlfence-before-indirect-branch=@var{register}} will generate > ++lfence after indirect near branch via register. > ++ at option{-mlfence-before-indirect-branch=@var{memory}} will issue a > ++warning before indirect near branch via memory. > ++ at option{-mlfence-before-indirect-branch=@var{none}} will not generate > ++lfence nor issue warning, which is the default. Note that lfence won't > ++be generated before indirect near branch via register with > ++ at option{-mlfence-after-load=@var{yes}} since lfence will be generated > ++after loading branch target register. > ++ > ++ at cindex @samp{-mlfence-before-ret=} option, i386 > ++ at cindex @samp{-mlfence-before-ret=} option, x86-64 > ++ at item -mlfence-before-ret=@var{none} > ++ at item -mlfence-before-ret=@var{or} > ++ at itemx -mlfence-before-ret=@var{not} > ++These options control whether the assembler should generate lfence > ++before ret. @option{-mlfence-before-ret=@var{or}} will generate > ++generate or instruction with lfence. > ++ at option{-mlfence-before-ret=@var{not}} will generate not instruction > ++with lfence. > ++ at option{-mlfence-before-ret=@var{none}} will not generate lfence, > ++which is the default. > ++ > + @cindex @samp{-mx86-used-note=} option, i386 > + @cindex @samp{-mx86-used-note=} option, x86-64 > + @item -mx86-used-note=@var{no} > +-- > +2.18.2 > From oleksandr.s.popovych at globallogic.com Fri Mar 13 15:18:41 2020 From: oleksandr.s.popovych at globallogic.com (Oleksandr Popovych) Date: Fri, 13 Mar 2020 17:18:41 +0200 Subject: [OE-core] [PATCH v7] expat: Added ptest Message-ID: <20200313151841.11613-1-oleksandr.s.popovych@globallogic.com> For ptest support for expat package: - expat_2.2.9.bb recipe was switched on cmake-based building system to avoid cahnges in autotools build system which considered in upstream as deprecated (https://github.com/libexpat/libexpat/issues/330). - expat_2.2.9.bb recipe was divided into expat_2.2.9.bb recipe which is switched on cmake-based build system and expat-native_2.2.9.bb recipe which is left with autotools build system. This solves problem with dependency loop between cmake-native and expat-native packages. Without this split, because expat-native package is listed in DEPENDS for cmake-native package, next dependency loop appears: Dependency loop #1 found: Task .../meta/recipes-devtools/cmake/cmake-native_3.16.1.bb:do_compile (dependent Tasks ['cmake-native_3.16.1.bb:do_configure']) Task .../meta/recipes-devtools/cmake/cmake-native_3.16.1.bb:do_install (dependent Tasks ['cmake-native_3.16.1.bb:do_compile']) Task .../meta/recipes-devtools/cmake/cmake-native_3.16.1.bb:do_populate_sysroot (dependent Tasks ['cmake-native_3.16.1.bb:do_install']) Task virtual:native:.../meta/recipes-core/expat/expat_2.2.9.bb:do_prepare_recipe_sysroot (dependent Tasks ['ninja_1.10.0.bb:do_populate_sysroot', 'cmake-native_3.16.1.bb:do_populate_sysroot', 'expat_2.2.9.bb:do_fetch']) Task virtual:native:.../meta/recipes-core/expat/expat_2.2.9.bb:do_configure (dependent Tasks ['expat_2.2.9.bb:do_prepare_recipe_sysroot', 'expat_2.2.9.bb:do_deploy_source_date_epoch', 'expat_2.2.9.bb:do_generate_toolchain_file', 'expat_2.2.9.bb:do_patch']) Task virtual:native:.../meta/recipes-core/expat/expat_2.2.9.bb:do_compile (dependent Tasks ['expat_2.2.9.bb:do_configure']) Task virtual:native:.../meta/recipes-core/expat/expat_2.2.9.bb:do_install (dependent Tasks ['expat_2.2.9.bb:do_compile']) Task virtual:native:.../meta/recipes-core/expat/expat_2.2.9.bb:do_populate_sysroot (dependent Tasks ['expat_2.2.9.bb:do_install']) Task .../meta/recipes-devtools/cmake/cmake-native_3.16.1.bb:do_prepare_recipe_sysroot (dependent Tasks ['expat_2.2.9.bb:do_populate_sysroot', 'zlib_1.2.11.bb:do_populate_sysroot', 'bzip2_1.0.8.bb:do_populate_sysroot', 'xz_5.2.4.bb:do_populate_sysroot', 'ncurses_6.2.bb:do_populate_sysroot', 'curl_7.69.0.bb:do_populate_sysroot', 'cmake-native_3.16.1.bb:do_fetch']) Task .../meta/recipes-devtools/cmake/cmake-native_3.16.1.bb:do_configure (dependent Tasks ['cmake-native_3.16.1.bb:do_deploy_source_date_epoch', 'cmake-native_3.16.1.bb:do_patch', 'cmake-native_3.16.1.bb:do_prepare_recipe_sysroot']) - run-ptest script that initalizes testing, copies testing executables' output to log file and measures execution time of each testing executable was added. - patch that implements output of each testcase result in testing exectutable was added. Signed-off-by: Oleksandr Popovych --- meta/recipes-core/expat/expat-native_2.2.9.bb | 20 +++++ .../0001-Add-output-of-tests-result.patch | 84 +++++++++++++++++++ meta/recipes-core/expat/expat/run-ptest | 24 ++++++ meta/recipes-core/expat/expat_2.2.9.bb | 14 +++- 4 files changed, 138 insertions(+), 4 deletions(-) create mode 100644 meta/recipes-core/expat/expat-native_2.2.9.bb create mode 100644 meta/recipes-core/expat/expat/0001-Add-output-of-tests-result.patch create mode 100644 meta/recipes-core/expat/expat/run-ptest diff --git a/meta/recipes-core/expat/expat-native_2.2.9.bb b/meta/recipes-core/expat/expat-native_2.2.9.bb new file mode 100644 index 0000000000..c5dbb09ee2 --- /dev/null +++ b/meta/recipes-core/expat/expat-native_2.2.9.bb @@ -0,0 +1,20 @@ +SUMMARY = "A stream-oriented XML parser library" +DESCRIPTION = "Expat is an XML parser library written in C. It is a stream-oriented parser in which an application registers handlers for things the parser might find in the XML document (like start tags)" +HOMEPAGE = "http://expat.sourceforge.net/" +SECTION = "libs" +LICENSE = "MIT" + +LIC_FILES_CHKSUM = "file://COPYING;md5=5b8620d98e49772d95fc1d291c26aa79" + +SRC_URI = "${SOURCEFORGE_MIRROR}/expat/expat-${PV}.tar.bz2 \ + file://libtool-tag.patch \ + " + +SRC_URI[md5sum] = "875a2c2ff3e8eb9e5a5cd62db2033ab5" +SRC_URI[sha256sum] = "f1063084dc4302a427dabcca499c8312b3a32a29b7d2506653ecc8f950a9a237" + +inherit autotools lib_package native + +do_configure_prepend () { + rm -f ${S}/conftools/libtool.m4 +} diff --git a/meta/recipes-core/expat/expat/0001-Add-output-of-tests-result.patch b/meta/recipes-core/expat/expat/0001-Add-output-of-tests-result.patch new file mode 100644 index 0000000000..c78fd2bbef --- /dev/null +++ b/meta/recipes-core/expat/expat/0001-Add-output-of-tests-result.patch @@ -0,0 +1,84 @@ +From aa84835a00bfd65e784d58411e76f60658e939dc Mon Sep 17 00:00:00 2001 +From: Oleksandr Popovych +Date: Tue, 18 Feb 2020 19:04:55 +0200 +Subject: [PATCH] Add output of tests result + +Added console output of testing results in form 'RESULT: TEST_NAME'. + +Changed verbose mode of test application set by '-v' ('--verbose') +argument to CK_NORMAL. +Added new supported argument '-vv' ('--extra-verbose') that changes +verbose mode of test application to CK_VERBOSE. Results of each test +are shown in output only if this mode is set. + +Upstream-Status: Denied + +This patch changes potentially deprecated feature that shoud be changed +in upstream. [https://github.com/libexpat/libexpat/issues/382] + +Signed-off-by: Oleksandr Popovych +--- + tests/minicheck.c | 10 +++++++++- + tests/runtests.c | 4 +++- + 2 files changed, 12 insertions(+), 2 deletions(-) + +diff --git a/expat/tests/minicheck.c b/expat/tests/minicheck.c +index a5a1efb..94fa412 100644 +--- a/tests/minicheck.c ++++ b/tests/minicheck.c +@@ -164,6 +164,8 @@ srunner_run_all(SRunner *runner, int verbosity) { + if (tc->setup != NULL) { + /* setup */ + if (setjmp(env)) { ++ if (verbosity >= CK_VERBOSE) ++ printf("SKIP: %s\n", _check_current_function); + add_failure(runner, verbosity); + continue; + } +@@ -171,6 +173,8 @@ srunner_run_all(SRunner *runner, int verbosity) { + } + /* test */ + if (setjmp(env)) { ++ if (verbosity >= CK_VERBOSE) ++ printf("FAIL: %s\n", _check_current_function); + add_failure(runner, verbosity); + continue; + } +@@ -178,12 +182,16 @@ srunner_run_all(SRunner *runner, int verbosity) { + + /* teardown */ + if (tc->teardown != NULL) { +- if (setjmp(env)) { ++ if (setjmp(env)) { ++ if (verbosity >= CK_VERBOSE) ++ printf("PASS: %s\n", _check_current_function); + add_failure(runner, verbosity); + continue; + } + tc->teardown(); + } ++ if (verbosity >= CK_VERBOSE) ++ printf("PASS: %s\n", _check_current_function); + } + tc = tc->next_tcase; + } +diff --git a/tests/runtests.c b/expat/tests/runtests.c +index 7791fe0..75724e5 100644 +--- a/tests/runtests.c ++++ b/tests/runtests.c +@@ -11619,9 +11619,11 @@ main(int argc, char *argv[]) { + for (i = 1; i < argc; ++i) { + char *opt = argv[i]; + if (strcmp(opt, "-v") == 0 || strcmp(opt, "--verbose") == 0) +- verbosity = CK_VERBOSE; ++ verbosity = CK_NORMAL; + else if (strcmp(opt, "-q") == 0 || strcmp(opt, "--quiet") == 0) + verbosity = CK_SILENT; ++ else if (strcmp(opt, "-vv") == 0 || strcmp(opt, "--extra-verbose") == 0) ++ verbosity = CK_VERBOSE; + else { + fprintf(stderr, "runtests: unknown option '%s'\n", opt); + return 2; +-- +2.17.1 + diff --git a/meta/recipes-core/expat/expat/run-ptest b/meta/recipes-core/expat/expat/run-ptest new file mode 100644 index 0000000000..7bc81eba8a --- /dev/null +++ b/meta/recipes-core/expat/expat/run-ptest @@ -0,0 +1,24 @@ +#!/bin/bash + +output=${1:-"expat_tests.log"} # default log file + +# logging function +function testCheck() { + testExec="$1" + shift + echo && echo ${testExec} && ./${testExec} "$@" + error=$? + result=$([[ ${error} -eq 0 ]] && echo "PASS" || echo "FAIL") + echo "${result}: ${testExec}" && echo "============================" +} + +export output +export -f testCheck +TIME=$(which time) + +echo "Architecture: $(uname -m)" > ${output} +echo "Image: $(uname -sr)" >> ${output} +${TIME} -f 'Execution time: %e s' bash -c "testCheck runtests -vv" |& tee -a ${output} +${TIME} -f 'Execution time: %e s' bash -c "testCheck runtestspp -vv" |& tee -a ${output} +echo + diff --git a/meta/recipes-core/expat/expat_2.2.9.bb b/meta/recipes-core/expat/expat_2.2.9.bb index 8f3db41352..a0224c627e 100644 --- a/meta/recipes-core/expat/expat_2.2.9.bb +++ b/meta/recipes-core/expat/expat_2.2.9.bb @@ -8,15 +8,21 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=5b8620d98e49772d95fc1d291c26aa79" SRC_URI = "${SOURCEFORGE_MIRROR}/expat/expat-${PV}.tar.bz2 \ file://libtool-tag.patch \ + file://run-ptest \ + file://0001-Add-output-of-tests-result.patch \ " SRC_URI[md5sum] = "875a2c2ff3e8eb9e5a5cd62db2033ab5" SRC_URI[sha256sum] = "f1063084dc4302a427dabcca499c8312b3a32a29b7d2506653ecc8f950a9a237" -inherit autotools lib_package +RDEPENDS_${PN}-ptest += "bash" -do_configure_prepend () { - rm -f ${S}/conftools/libtool.m4 +#S = "${WORKDIR}" + +inherit cmake lib_package ptest + +do_install_ptest_class-target() { + install -m 755 ${B}/tests/* ${D}${PTEST_PATH} } -BBCLASSEXTEND = "native nativesdk" +BBCLASSEXTEND += "nativesdk" -- 2.17.1 From richard.purdie at linuxfoundation.org Fri Mar 13 16:10:22 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Fri, 13 Mar 2020 16:10:22 +0000 Subject: [OE-core] [PATCH] musl: removes aliases for glibc provided libraries In-Reply-To: <20200312230238.413509-1-raj.khem@gmail.com> References: <20200312230238.413509-1-raj.khem@gmail.com> Message-ID: <0aaac991c5634577b000a3e62f0ec5e59ddf0e1b.camel@linuxfoundation.org> On Thu, 2020-03-12 at 16:02 -0700, Khem Raj wrote: > From: Jan Kaisrlik > > Based on the recommendation in musl mailing list[1] All symlinks have > been removed from musl recipe. > > [1]: https://www.openwall.com/lists/musl/2020/03/10/11 > > Signed-off-by: Jan Kaisrlik > Signed-off-by: Khem Raj > --- > meta/recipes-core/musl/musl_git.bb | 15 +-------------- > 1 file changed, 1 insertion(+), 14 deletions(-) Breaks SDK tests: https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/1697 Cheers, Richard From richard.purdie at linuxfoundation.org Fri Mar 13 16:11:20 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Fri, 13 Mar 2020 16:11:20 +0000 Subject: [OE-core] [PATCH] musl: removes aliases for glibc provided libraries In-Reply-To: <0aaac991c5634577b000a3e62f0ec5e59ddf0e1b.camel@linuxfoundation.org> References: <20200312230238.413509-1-raj.khem@gmail.com> <0aaac991c5634577b000a3e62f0ec5e59ddf0e1b.camel@linuxfoundation.org> Message-ID: <73540320e37a4fb6868b4625abc823f8ba53223f.camel@linuxfoundation.org> On Fri, 2020-03-13 at 16:10 +0000, Richard Purdie wrote: > On Thu, 2020-03-12 at 16:02 -0700, Khem Raj wrote: > > From: Jan Kaisrlik > > > > Based on the recommendation in musl mailing list[1] All symlinks > > have > > been removed from musl recipe. > > > > [1]: https://www.openwall.com/lists/musl/2020/03/10/11 > > > > Signed-off-by: Jan Kaisrlik > > Signed-off-by: Khem Raj > > --- > > meta/recipes-core/musl/musl_git.bb | 15 +-------------- > > 1 file changed, 1 insertion(+), 14 deletions(-) > > Breaks SDK tests: > > https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/1697 I mean on target toolchain tests... Cheers, Richard From denis at denix.org Fri Mar 13 16:40:14 2020 From: denis at denix.org (Denys Dmytriyenko) Date: Fri, 13 Mar 2020 12:40:14 -0400 Subject: [OE-core] [yocto] menuconf u-boot In-Reply-To: References: Message-ID: <20200313164014.GN1578@denix.org> What's u-boot-imx? It's definitely not in openembedded-core, so there's no reason to cross-post there. If google doesn't help, it's recommended to post such specific questions to the corresponding mailing list for the layer this recipe comes from. If it's not clear where the recipe comes from, Layer Index can help: https://layers.openembedded.org/ Thanks. -- Denys On Fri, Mar 13, 2020 at 08:15:17PM +1100, JH wrote: > Hi, > > I tried to run bitbake -c menuconfig u-boot, it popped up a terminal > u-boot-imx configuration: > > make: *** No rule make target 'menuconfig'. Stop. > Command failed. > Press any key to continue... > > How can I run menuconfig u-boot? > > Thank you. > > Kind regards, > > - jh > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > > View/Reply Online (#48751): https://lists.yoctoproject.org/g/yocto/message/48751 > Mute This Topic: https://lists.yoctoproject.org/mt/71921973/3617104 > Group Owner: yocto+owner at lists.yoctoproject.org > Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [denis at denix.org] > -=-=-=-=-=-=-=-=-=-=-=- From akuster808 at gmail.com Fri Mar 13 18:03:29 2020 From: akuster808 at gmail.com (akuster808) Date: Fri, 13 Mar 2020 11:03:29 -0700 Subject: [OE-core] Thud community support Message-ID: The Poky thud branch is now under 'Community support' and is seeking a maintainer to continue supporting the following repos for the thud release: bitbake, core, meta-yocto and yocto-docs. There will be no more point releases. see https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS#Maintainer_Procedures? to get an idea on what is expected. The one thing we (YP) don't know is if there will be AutoBuilder resources available.? Please contact me or Richard regarding that statement. If no one steps up by April 24th (six weeks -ish from now), Thud will be moved to EOL status. - Armin From andrey.z at gmail.com Fri Mar 13 18:07:34 2020 From: andrey.z at gmail.com (Andrey Zhizhikin) Date: Fri, 13 Mar 2020 19:07:34 +0100 Subject: [OE-core] [yocto] menuconf u-boot In-Reply-To: <20200313164014.GN1578@denix.org> References: <20200313164014.GN1578@denix.org> Message-ID: JH, Please refer to my replies to Denys, cross-posting to unrelated lists is generally not a good idea. On Fri, Mar 13, 2020 at 5:40 PM Denys Dmytriyenko wrote: > > What's u-boot-imx? This is U-Boot fork for NXP devices (former Freescale), which is not maintained by OE-Core. > > It's definitely not in openembedded-core, so there's no reason to cross-post > there. > > If google doesn't help, it's recommended to post such specific questions to > the corresponding mailing list for the layer this recipe comes from. The correct mailing list would be meta-freescale at yoctoproject.org and JH already had some questions posted there. > > If it's not clear where the recipe comes from, Layer Index can help: > https://layers.openembedded.org/ > > Thanks. > > -- > Denys > > > On Fri, Mar 13, 2020 at 08:15:17PM +1100, JH wrote: > > Hi, > > > > I tried to run bitbake -c menuconfig u-boot, it popped up a terminal > > u-boot-imx configuration: It is not clear which yocto branch/machine you're trying to build here. If you provide more details - then there is a bigger chance that people would step in to assist you. > > > > make: *** No rule make target 'menuconfig'. Stop. > > Command failed. > > Press any key to continue... > > > > How can I run menuconfig u-boot? I've tried it now on the [master] branch of yocto for imx8mmevk machine - it is building OK and I have the menuconfig from u-boot-imx. Hence, please refer to my point above regarding more pre-information on the issue. > > > > Thank you. > > > > Kind regards, > > > > - jh > > > -=-=-=-=-=-=-=-=-=-=-=- > > Links: You receive all messages sent to this group. > > > > View/Reply Online (#48751): https://lists.yoctoproject.org/g/yocto/message/48751 > > Mute This Topic: https://lists.yoctoproject.org/mt/71921973/3617104 > > Group Owner: yocto+owner at lists.yoctoproject.org > > Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [denis at denix.org] > > -=-=-=-=-=-=-=-=-=-=-=- > > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core at lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- Regards, Andrey. From denis at denix.org Fri Mar 13 18:15:44 2020 From: denis at denix.org (Denys Dmytriyenko) Date: Fri, 13 Mar 2020 14:15:44 -0400 Subject: [OE-core] [yocto] menuconf u-boot In-Reply-To: References: <20200313164014.GN1578@denix.org> Message-ID: <20200313181544.GO1578@denix.org> On Fri, Mar 13, 2020 at 07:07:34PM +0100, Andrey Zhizhikin wrote: > JH, > > Please refer to my replies to Denys, cross-posting to unrelated lists > is generally not a good idea. > > On Fri, Mar 13, 2020 at 5:40 PM Denys Dmytriyenko wrote: > > > > What's u-boot-imx? > > This is U-Boot fork for NXP devices (former Freescale), This was a rhetorical question - no answer was required. > which is not maintained by OE-Core. Exactly my point. > > It's definitely not in openembedded-core, so there's no reason to cross-post > > there. > > > > If google doesn't help, it's recommended to post such specific questions to > > the corresponding mailing list for the layer this recipe comes from. > > The correct mailing list would be meta-freescale at yoctoproject.org and > JH already had some questions posted there. > > > > > If it's not clear where the recipe comes from, Layer Index can help: > > https://layers.openembedded.org/ > > > > Thanks. > > > > -- > > Denys > > > > > > On Fri, Mar 13, 2020 at 08:15:17PM +1100, JH wrote: > > > Hi, > > > > > > I tried to run bitbake -c menuconfig u-boot, it popped up a terminal > > > u-boot-imx configuration: > > It is not clear which yocto branch/machine you're trying to build > here. If you provide more details - then there is a bigger chance that > people would step in to assist you. > > > > > > > make: *** No rule make target 'menuconfig'. Stop. > > > Command failed. > > > Press any key to continue... > > > > > > How can I run menuconfig u-boot? > > I've tried it now on the [master] branch of yocto for imx8mmevk > machine - it is building OK and I have the menuconfig from u-boot-imx. > Hence, please refer to my point above regarding more pre-information > on the issue. > > > > > > > Thank you. > > > > > > Kind regards, > > > > > > - jh > > > > > -=-=-=-=-=-=-=-=-=-=-=- > > > Links: You receive all messages sent to this group. > > > > > > View/Reply Online (#48751): https://lists.yoctoproject.org/g/yocto/message/48751 > > > Mute This Topic: https://lists.yoctoproject.org/mt/71921973/3617104 > > > Group Owner: yocto+owner at lists.yoctoproject.org > > > Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [denis at denix.org] > > > -=-=-=-=-=-=-=-=-=-=-=- > > > > -- > > _______________________________________________ > > Openembedded-core mailing list > > Openembedded-core at lists.openembedded.org > > http://lists.openembedded.org/mailman/listinfo/openembedded-core > > > > -- > Regards, > Andrey. > From andrey.z at gmail.com Fri Mar 13 18:21:02 2020 From: andrey.z at gmail.com (Andrey Zhizhikin) Date: Fri, 13 Mar 2020 19:21:02 +0100 Subject: [OE-core] [yocto] menuconf u-boot In-Reply-To: <20200313181544.GO1578@denix.org> References: <20200313164014.GN1578@denix.org> <20200313181544.GO1578@denix.org> Message-ID: On Fri, Mar 13, 2020 at 7:15 PM Denys Dmytriyenko wrote: > > On Fri, Mar 13, 2020 at 07:07:34PM +0100, Andrey Zhizhikin wrote: > > JH, > > > > Please refer to my replies to Denys, cross-posting to unrelated lists > > is generally not a good idea. > > > > On Fri, Mar 13, 2020 at 5:40 PM Denys Dmytriyenko wrote: > > > > > > What's u-boot-imx? > > > > This is U-Boot fork for NXP devices (former Freescale), > > This was a rhetorical question - no answer was required. That was mainly addressed to JH. :) > > > > which is not maintained by OE-Core. > > Exactly my point. > > > > > It's definitely not in openembedded-core, so there's no reason to cross-post > > > there. > > > > > > If google doesn't help, it's recommended to post such specific questions to > > > the corresponding mailing list for the layer this recipe comes from. > > > > The correct mailing list would be meta-freescale at yoctoproject.org and > > JH already had some questions posted there. > > > > > > > > If it's not clear where the recipe comes from, Layer Index can help: > > > https://layers.openembedded.org/ > > > > > > Thanks. > > > > > > -- > > > Denys > > > > > > > > > On Fri, Mar 13, 2020 at 08:15:17PM +1100, JH wrote: > > > > Hi, > > > > > > > > I tried to run bitbake -c menuconfig u-boot, it popped up a terminal > > > > u-boot-imx configuration: > > > > It is not clear which yocto branch/machine you're trying to build > > here. If you provide more details - then there is a bigger chance that > > people would step in to assist you. > > > > > > > > > > make: *** No rule make target 'menuconfig'. Stop. > > > > Command failed. > > > > Press any key to continue... > > > > > > > > How can I run menuconfig u-boot? > > > > I've tried it now on the [master] branch of yocto for imx8mmevk > > machine - it is building OK and I have the menuconfig from u-boot-imx. > > Hence, please refer to my point above regarding more pre-information > > on the issue. > > > > > > > > > > Thank you. > > > > > > > > Kind regards, > > > > > > > > - jh > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- > > > > Links: You receive all messages sent to this group. > > > > > > > > View/Reply Online (#48751): https://lists.yoctoproject.org/g/yocto/message/48751 > > > > Mute This Topic: https://lists.yoctoproject.org/mt/71921973/3617104 > > > > Group Owner: yocto+owner at lists.yoctoproject.org > > > > Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [denis at denix.org] > > > > -=-=-=-=-=-=-=-=-=-=-=- > > > > > > -- > > > _______________________________________________ > > > Openembedded-core mailing list > > > Openembedded-core at lists.openembedded.org > > > http://lists.openembedded.org/mailman/listinfo/openembedded-core > > > > > > > > -- > > Regards, > > Andrey. > > -- Regards, Andrey. From raj.khem at gmail.com Fri Mar 13 18:36:10 2020 From: raj.khem at gmail.com (Khem Raj) Date: Fri, 13 Mar 2020 11:36:10 -0700 Subject: [OE-core] [PATCH] musl: removes aliases for glibc provided libraries In-Reply-To: <0aaac991c5634577b000a3e62f0ec5e59ddf0e1b.camel@linuxfoundation.org> References: <20200312230238.413509-1-raj.khem@gmail.com> <0aaac991c5634577b000a3e62f0ec5e59ddf0e1b.camel@linuxfoundation.org> Message-ID: <306503fb-9025-42f2-181f-7982b632cf65@gmail.com> On 3/13/20 9:10 AM, Richard Purdie wrote: > On Thu, 2020-03-12 at 16:02 -0700, Khem Raj wrote: >> From: Jan Kaisrlik >> >> Based on the recommendation in musl mailing list[1] All symlinks have >> been removed from musl recipe. >> >> [1]: https://www.openwall.com/lists/musl/2020/03/10/11 >> >> Signed-off-by: Jan Kaisrlik >> Signed-off-by: Khem Raj >> --- >> meta/recipes-core/musl/musl_git.bb | 15 +-------------- >> 1 file changed, 1 insertion(+), 14 deletions(-) > > Breaks SDK tests: > > https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/1697 > yeah its failing a simple test to link with -lm but this works ok on my end here, so I wonder whats different on AB ? > Cheers, > > Richard > From raj.khem at gmail.com Fri Mar 13 19:44:51 2020 From: raj.khem at gmail.com (Khem Raj) Date: Fri, 13 Mar 2020 12:44:51 -0700 Subject: [OE-core] [PATCH V2] musl: removes aliases for glibc provided libraries Message-ID: <20200313194451.1324565-1-raj.khem@gmail.com> From: Jan Kaisrlik Based on the recommendation in musl mailing list[1] All symlinks have been removed from musl recipe. Move stub libraries into -dev package having them treated as normal .a which they are not, is not correct and packages shoves them into static archives, which are not installed on target usually unless asked for this should help in linking with -lm, -lpthread etc. on target [1]: https://www.openwall.com/lists/musl/2020/03/10/11 Signed-off-by: Jan Kaisrlik Signed-off-by: Khem Raj --- v2: Fix -lm linking problem reported on AB tests meta/recipes-core/musl/musl_git.bb | 21 +++++++-------------- 1 file changed, 7 insertions(+), 14 deletions(-) diff --git a/meta/recipes-core/musl/musl_git.bb b/meta/recipes-core/musl/musl_git.bb index afc8446547..2a15a78cd5 100644 --- a/meta/recipes-core/musl/musl_git.bb +++ b/meta/recipes-core/musl/musl_git.bb @@ -66,27 +66,20 @@ do_install() { rm -f ${D}${bindir}/ldd ${D}${GLIBC_LDSO} lnr ${D}${libdir}/libc.so ${D}${bindir}/ldd lnr ${D}${libdir}/libc.so ${D}${GLIBC_LDSO} - for l in crypt dl m pthread resolv rt util xnet - do - ln -sf libc.so ${D}${libdir}/lib$l.so - done - for i in libc.so.6 libcrypt.so.1 libdl.so.2 libm.so.6 libpthread.so.0 libresolv.so.2 librt.so.1 libutil.so.1; do - ln -sf libc.so ${D}${libdir}/$i - done } PACKAGES =+ "${PN}-glibc-compat" -FILES_${PN}-glibc-compat += "\ - ${libdir}/libc.so.6 ${libdir}/libcrypt.so.1 \ - ${libdir}/libdl.so.2 ${libdir}/libm.so.6 \ - ${libdir}/libpthread.so.0 ${libdir}/libresolv.so.2 \ - ${libdir}/librt.so.1 ${libdir}/libutil.so.1 \ - ${GLIBC_LDSO} \ - " +FILES_${PN}-glibc-compat += "${GLIBC_LDSO}" +FILES_${PN}-staticdev = "${libdir}/libc.a" +FILES_${PN}-dev =+ "${libdir}/libcrypt.a ${libdir}/libdl.a ${libdir}/libm.a \ + ${libdir}/libpthread.a ${libdir}/libresolv.a \ + ${libdir}/librt.a ${libdir}/libutil.a ${libdir}/libxnet.a \ + " RDEPENDS_${PN}-dev += "linux-libc-headers-dev bsd-headers-dev libssp-nonshared-staticdev" RPROVIDES_${PN}-dev += "libc-dev virtual-libc-dev" RPROVIDES_${PN} += "ldd libsegfault rtld(GNU_HASH)" LEAD_SONAME = "libc.so" +INSANE_SKIP_${PN}-dev = "staticdev" -- 2.25.1 From akuster808 at gmail.com Fri Mar 13 21:47:20 2020 From: akuster808 at gmail.com (akuster808) Date: Fri, 13 Mar 2020 14:47:20 -0700 Subject: [OE-core] [PATCH] qemu: fix CVE-2020-7039 In-Reply-To: <6830c57f-37de-dc1a-ba80-5a4217644060@windriver.com> References: <1582781146-253903-1-git-send-email-changqing.li@windriver.com> <6830c57f-37de-dc1a-ba80-5a4217644060@windriver.com> Message-ID: On 3/12/20 1:53 PM, Randy MacLeod wrote: > On 2020-02-27 12:25 a.m., changqing.li at windriver.com wrote: >> From: Changqing Li >> >> Signed-off-by: Changqing Li >> --- >> ? meta/recipes-devtools/qemu/qemu.inc??????????????? |? 3 + >> ? .../qemu/qemu/CVE-2020-7039-1.patch??????????????? | 44 >> +++++++++++++++ >> ? .../qemu/qemu/CVE-2020-7039-2.patch??????????????? | 59 >> ++++++++++++++++++++ >> ? .../qemu/qemu/CVE-2020-7039-3.patch??????????????? | 64 >> ++++++++++++++++++++++ >> ? 4 files changed, 170 insertions(+) >> ? create mode 100644 >> meta/recipes-devtools/qemu/qemu/CVE-2020-7039-1.patch >> ? create mode 100644 >> meta/recipes-devtools/qemu/qemu/CVE-2020-7039-2.patch >> ? create mode 100644 >> meta/recipes-devtools/qemu/qemu/CVE-2020-7039-3.patch >> > FYI, now in master https://git.openembedded.org/openembedded-core/commit/?id=5ea3d9d83ed695827634e3216664c13fcff6d48a > LGTM, I don't see it in master or master-next. > > NVD gives this defect a 'critical' score so it would be good to get > it tested and merged. > https://nvd.nist.gov/vuln/detail/CVE-2020-7039 > From jpuhlman at mvista.com Fri Mar 13 22:55:22 2020 From: jpuhlman at mvista.com (Jeremy A. Puhlman) Date: Fri, 13 Mar 2020 15:55:22 -0700 Subject: [OE-core] [PATCH] ltp: make multilib installable. Message-ID: <20200313225522.24175-1-jpuhlman@mvista.com> From: Jeremy Puhlman Many of ltp's tests are of syscalls and libc content. Enable installing mulitpule abi's. Use prefix consistently rather then hardcoded /opt/ltp everywhere. Signed-off-by: Jeremy A. Puhlman --- meta/recipes-extended/ltp/ltp_20200120.bb | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/meta/recipes-extended/ltp/ltp_20200120.bb b/meta/recipes-extended/ltp/ltp_20200120.bb index 3e6cbc63f3..deac3917d7 100644 --- a/meta/recipes-extended/ltp/ltp_20200120.bb +++ b/meta/recipes-extended/ltp/ltp_20200120.bb @@ -45,8 +45,8 @@ inherit autotools-brokensep TARGET_CC_ARCH += "${LDFLAGS}" -export prefix = "/opt/ltp" -export exec_prefix = "/opt/ltp" +export prefix = "/opt/${PN}" +export exec_prefix = "/opt/${PN}" PACKAGECONFIG[numa] = "--with-numa, --without-numa, numactl," EXTRA_AUTORECONF += "-I ${S}/testcases/realtime/m4" @@ -55,7 +55,7 @@ EXTRA_OECONF = " --with-power-management-testsuite --with-realtime-testsuite --w EXTRA_OECONF += " --without-tirpc " do_install(){ - install -d ${D}/opt/ltp/ + install -d ${D}${prefix}/ oe_runmake DESTDIR=${D} SKIP_IDCHECK=1 install # fixup not deploy STPfailure_report.pl to avoid confusing about it fails to run @@ -64,10 +64,10 @@ do_install(){ # runs on the OSDL's Scaleable Test Platform (STP) and it mainly accesses # http://khack.osdl.org to retrieve ltp test results run on # OSDL's Scaleable Test Platform, but now http://khack.osdl.org unaccessible - rm -rf ${D}/opt/ltp/bin/STPfailure_report.pl + rm -rf ${D}${prefix}/bin/STPfailure_report.pl - # Copy POSIX test suite into ${D}/opt/ltp/testcases by manual - cp -r testcases/open_posix_testsuite ${D}/opt/ltp/testcases + # Copy POSIX test suite into ${D}${prefix}/testcases by manual + cp -r testcases/open_posix_testsuite ${D}${prefix}/testcases # Makefile were configured in the build system find ${D}${prefix} -name Makefile | xargs -n 1 sed -i \ @@ -101,10 +101,10 @@ RDEPENDS_${PN} = "\ tar \ " -FILES_${PN} += "/opt/ltp/* /opt/ltp/runtest/* /opt/ltp/scenario_groups/* /opt/ltp/testcases/bin/* /opt/ltp/testcases/bin/*/bin/* /opt/ltp/testscripts/* /opt/ltp/testcases/open_posix_testsuite/* /opt/ltp/testcases/open_posix_testsuite/conformance/* /opt/ltp/testcases/open_posix_testsuite/Documentation/* /opt/ltp/testcases/open_posix_testsuite/functional/* /opt/ltp/testcases/open_posix_testsuite/include/* /opt/ltp/testcases/open_posix_testsuite/scripts/* /opt/ltp/testcases/open_posix_testsuite/stress/* /opt/ltp/testcases/open_posix_testsuite/tools/* /opt/ltp/testcases/data/nm01/lib.a /opt/ltp/lib/libmem.a" +FILES_${PN} += "${prefix}/* ${prefix}/runtest/* ${prefix}/scenario_groups/* ${prefix}/testcases/bin/* ${prefix}/testcases/bin/*/bin/* ${prefix}/testscripts/* ${prefix}/testcases/open_posix_testsuite/* ${prefix}/testcases/open_posix_testsuite/conformance/* ${prefix}/testcases/open_posix_testsuite/Documentation/* ${prefix}/testcases/open_posix_testsuite/functional/* ${prefix}/testcases/open_posix_testsuite/include/* ${prefix}/testcases/open_posix_testsuite/scripts/* ${prefix}/testcases/open_posix_testsuite/stress/* ${prefix}/testcases/open_posix_testsuite/tools/* ${prefix}/testcases/data/nm01/lib.a ${prefix}/lib/libmem.a" # Avoid stripping some generated binaries otherwise some of the ltp tests such as ldd01 & nm01 fail -INHIBIT_PACKAGE_STRIP_FILES = "/opt/ltp/testcases/bin/nm01 /opt/ltp/testcases/bin/ldd01" +INHIBIT_PACKAGE_STRIP_FILES = "${prefix}/testcases/bin/nm01 ${prefix}/testcases/bin/ldd01" INSANE_SKIP_${PN} += "already-stripped staticdev" # Avoid file dependency scans, as LTP checks for things that may or may not -- 2.13.3 From mhalstead at linuxfoundation.org Fri Mar 13 23:58:30 2020 From: mhalstead at linuxfoundation.org (Michael Halstead) Date: Fri, 13 Mar 2020 16:58:30 -0700 Subject: [OE-core] Mailing list platform change March 20th Message-ID: We are moving our lists from Mailman to Groups.io. E-mail to lists will be delayed during the move window. We are aiming to complete the migration during business hours in the Pacific time zone. A new account will be created for you on the Groups.io platform if you don't already have one. You can read more about the change on the wiki: https://www.openembedded.org/wiki/GroupsMigration If there are serious issues we will rollback the changes. We will e-mail all lists when work is complete. -- Michael Halstead Linux Foundation / Yocto Project Systems Operations Engineer -------------- next part -------------- An HTML attachment was scrubbed... URL: From wangmy at cn.fujitsu.com Sat Mar 14 04:49:45 2020 From: wangmy at cn.fujitsu.com (Wang, Mingyu) Date: Sat, 14 Mar 2020 04:49:45 +0000 Subject: [OE-core] [PATCH] base-passwd: LICENSE changed to GPLv2 In-Reply-To: <44535d2e53175baa8b7b7969fa9276e924a43fca.camel@linuxfoundation.org> References: <1584097866-54513-1-git-send-email-wangmy@cn.fujitsu.com> <44535d2e53175baa8b7b7969fa9276e924a43fca.camel@linuxfoundation.org> Message-ID: <6aff6b44d0d9458992b5467336ceac82@G08CNEXMBPEKD05.g08.fujitsu.local> Hi, Richard > Why? The license file didn't change. This needs an explanation. 1. For base-passwd, I think that it's gpl-2.0-only since it is declared as "gpl-2" in debian/copyright, not "gpl-2 or later" License: GPL-2 On Debian and Debian-based systems, a copy of the GNU General Public License version 2 is available in /usr/share/common-licenses/GPL-2. 2.GPLv2 constant: > 9. The Free Software Foundation may publish revised and/or new versions > of the General Public License from time to time. Such new versions will > be similar in spirit to the present version, but may differ in detail to > address new problems or concerns. > > Each version is given a distinguishing version number. If the Program > specifies a version number of this License which applies to it and "any > later version", you have the option of following the terms and conditions > either of that version or of any later version published by the Free > Software Foundation. If the Program does not specify a version number of > this License, you may choose any version ever published by the Free Software > Foundation. The license would be GPLv2+, only when license name is "gpl-2 or later". 3. The bb file of libcomps contains the following contents: LICENSE = "GPLv2" The "COPYING? file from libcomps and base-passwd are the same, So it seems that the package LICENSE fields of the same copyright declaration are not unified. By wangmy -----Original Message----- From: Richard Purdie [mailto:richard.purdie at linuxfoundation.org] Sent: Friday, March 13, 2020 3:10 PM To: Wang, Mingyu/? ?? ; openembedded-core at lists.openembedded.org Subject: Re: [OE-core] [PATCH] base-passwd: LICENSE changed to GPLv2 On Fri, 2020-03-13 at 04:11 -0700, Wang Mingyu wrote: > Signed-off-by: Wang Mingyu > --- > meta/recipes-core/base-passwd/base-passwd_3.5.29.bb | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb > b/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb > index d1aab09181..d01cd7e297 100644 > --- a/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb > +++ b/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb > @@ -1,7 +1,7 @@ > SUMMARY = "Base system master password/group files" > DESCRIPTION = "The master copies of the user database files > (/etc/passwd and /etc/group). The update-passwd tool is also provided > to keep the system databases synchronized with these master files." > SECTION = "base" > -LICENSE = "GPLv2+" > +LICENSE = "GPLv2" > LIC_FILES_CHKSUM = > "file://COPYING;md5=eb723b61539feef013de476e68b5c50a" Why? The license file didn't change. This needs an explanation. Cheers, Richard From yanfei.xu at windriver.com Sat Mar 14 11:04:03 2020 From: yanfei.xu at windriver.com (yanfei.xu at windriver.com) Date: Sat, 14 Mar 2020 19:04:03 +0800 Subject: [OE-core] [PATCH] Fix lttng-modules build failure on some versions of kernel Message-ID: <20200314110403.17437-1-yanfei.xu@windriver.com> From: Yanfei Xu Fix lttng-modules build failure on some versions of the kernel that between 4.19.103 and 4.20.0 between 5.4.19 and 5.5.0 between 5.5.3 and 5.6.0 greater than or equal to 5.6.0 ---------Error messages------------- build_default_image_feature_list8/intel-x86-64-standard-glibc-std-OE/build/tmp-glibc/work/intel_x86_64-wrs-linux/lttng-modules/2.11.1+gitAUTOINC+6ad0e68b43-r0/git/probes/lttng-probe-kvm-x86-mmu.c:39: | /buildarea1/WRL1019_Regression/qemu_build/build_dir_nxt/intel-x86-64/03032007-build_default_image_feature_list8/intel-x86-64-standard-glibc-std-OE/build/tmp-glibc/work/intel_x86_64-wrs-linux/lttng-modules/2.11.1+gitAUTOINC+6ad0e68b43-r0/git/probes/../probes/lttng-tracepoint-event-impl.h:130:6: error: conflicting types for 'trace_fast_page_fault' | 130 | void trace_##_name(_proto); | | ^~~~~~ | /buildarea1/WRL1019_Regression/qemu_build/build_dir_nxt/intel-x86-64/03032007-build_default_image_feature_list8/intel-x86-64-standard-glibc-std-OE/build/tmp-glibc/work/intel_x86_64-wrs-linux/lttng-modules/2.11.1+gitAUTOINC+6ad0e68b43-r0/git/probes/../probes/lttng-tracepoint-event-impl.h:42:2: note: in expansion of macro 'LTTNG_TRACEPOINT_EVENT_INSTANCE_MAP' ------------------------------------ Signed-off-by: Yanfei Xu --- ...-Use-gpa_t-for-cr2-gpa-to-fix-TDP-support.patch | 97 ++++++++++++++++++++++ meta/recipes-kernel/lttng/lttng-modules_2.11.1.bb | 1 + 2 files changed, 98 insertions(+) create mode 100644 meta/recipes-kernel/lttng/lttng-modules/0001-fix-KVM-x86-Use-gpa_t-for-cr2-gpa-to-fix-TDP-support.patch diff --git a/meta/recipes-kernel/lttng/lttng-modules/0001-fix-KVM-x86-Use-gpa_t-for-cr2-gpa-to-fix-TDP-support.patch b/meta/recipes-kernel/lttng/lttng-modules/0001-fix-KVM-x86-Use-gpa_t-for-cr2-gpa-to-fix-TDP-support.patch new file mode 100644 index 0000000..1fd3609 --- /dev/null +++ b/meta/recipes-kernel/lttng/lttng-modules/0001-fix-KVM-x86-Use-gpa_t-for-cr2-gpa-to-fix-TDP-support.patch @@ -0,0 +1,97 @@ +From 175c0c3c2ee8aae7a1185f591988f02e0e3be103 Mon Sep 17 00:00:00 2001 +From: Michael Jeanson +Date: Tue, 11 Feb 2020 14:41:29 -0500 +Subject: [PATCH] fix: KVM: x86: Use gpa_t for cr2/gpa to fix TDP support on + 32-bit (v5.6) + +See upstream commit : + + commit 736c291c9f36b07f8889c61764c28edce20e715d + Author: Sean Christopherson + Date: Fri Dec 6 15:57:14 2019 -0800 + + KVM: x86: Use gpa_t for cr2/gpa to fix TDP support on 32-bit KVM + + Convert a plethora of parameters and variables in the MMU and page fault + flows from type gva_t to gpa_t to properly handle TDP on 32-bit KVM. + + Thanks to PSE and PAE paging, 32-bit kernels can access 64-bit physical + addresses. When TDP is enabled, the fault address is a guest physical + address and thus can be a 64-bit value, even when both KVM and its guest + are using 32-bit virtual addressing, e.g. VMX's VMCS.GUEST_PHYSICAL is a + 64-bit field, not a natural width field. + + Using a gva_t for the fault address means KVM will incorrectly drop the + upper 32-bits of the GPA. Ditto for gva_to_gpa() when it is used to + translate L2 GPAs to L1 GPAs. + + Opportunistically rename variables and parameters to better reflect the + dual address modes, e.g. use "cr2_or_gpa" for fault addresses and plain + "addr" instead of "vaddr" when the address may be either a GVA or an L2 + GPA. Similarly, use "gpa" in the nonpaging_page_fault() flows to avoid + a confusing "gpa_t gva" declaration; this also sets the stage for a + future patch to combing nonpaging_page_fault() and tdp_page_fault() with + minimal churn. + + Sprinkle in a few comments to document flows where an address is known + to be a GVA and thus can be safely truncated to a 32-bit value. Add + WARNs in kvm_handle_page_fault() and FNAME(gva_to_gpa_nested)() to help + document such cases and detect bugs. + +Signed-off-by: Michael Jeanson +Signed-off-by: Mathieu Desnoyers + +Upstream-Status: Backport [https://github.com/lttng/lttng-modules/commit/175c0c3c2ee8aae7a1185f591988f02e0e3be103] +Signed-off-by: Yanfei Xu + +--- + .../lttng-module/arch/x86/kvm/mmutrace.h | 26 +++++++++++++++++++ + 1 file changed, 26 insertions(+) + +diff --git a/instrumentation/events/lttng-module/arch/x86/kvm/mmutrace.h b/instrumentation/events/lttng-module/arch/x86/kvm/mmutrace.h +index e25a774..dd0c679 100644 +--- a/instrumentation/events/lttng-module/arch/x86/kvm/mmutrace.h ++++ b/instrumentation/events/lttng-module/arch/x86/kvm/mmutrace.h +@@ -214,6 +214,30 @@ LTTNG_TRACEPOINT_EVENT_MAP( + ) + ) + ++#if (LINUX_VERSION_CODE >= KERNEL_VERSION(5,6,0) || \ ++ LTTNG_KERNEL_RANGE(4,19,103, 4,20,0) || \ ++ LTTNG_KERNEL_RANGE(5,4,19, 5,5,0) || \ ++ LTTNG_KERNEL_RANGE(5,5,3, 5,6,0)) ++LTTNG_TRACEPOINT_EVENT_MAP( ++ fast_page_fault, ++ ++ kvm_mmu_fast_page_fault, ++ ++ TP_PROTO(struct kvm_vcpu *vcpu, gpa_t cr2_or_gpa, u32 error_code, ++ u64 *sptep, u64 old_spte, bool retry), ++ TP_ARGS(vcpu, cr2_or_gpa, error_code, sptep, old_spte, retry), ++ ++ TP_FIELDS( ++ ctf_integer(int, vcpu_id, vcpu->vcpu_id) ++ ctf_integer(gpa_t, cr2_or_gpa, cr2_or_gpa) ++ ctf_integer(u32, error_code, error_code) ++ ctf_integer_hex(u64 *, sptep, sptep) ++ ctf_integer(u64, old_spte, old_spte) ++ ctf_integer(u64, new_spte, *sptep) ++ ctf_integer(bool, retry, retry) ++ ) ++) ++#else + LTTNG_TRACEPOINT_EVENT_MAP( + fast_page_fault, + +@@ -233,6 +257,8 @@ LTTNG_TRACEPOINT_EVENT_MAP( + ctf_integer(bool, retry, retry) + ) + ) ++#endif ++ + #endif /* LTTNG_TRACE_KVM_MMU_H */ + + #undef TRACE_INCLUDE_PATH +-- +2.18.1 + diff --git a/meta/recipes-kernel/lttng/lttng-modules_2.11.1.bb b/meta/recipes-kernel/lttng/lttng-modules_2.11.1.bb index c833ff7..db0888a 100644 --- a/meta/recipes-kernel/lttng/lttng-modules_2.11.1.bb +++ b/meta/recipes-kernel/lttng/lttng-modules_2.11.1.bb @@ -11,6 +11,7 @@ COMPATIBLE_HOST = '(x86_64|i.86|powerpc|aarch64|mips|nios2|arm|riscv).*-linux' SRC_URI = "https://lttng.org/files/${BPN}/${BPN}-${PV}.tar.bz2 \ file://Makefile-Do-not-fail-if-CONFIG_TRACEPOINTS-is-not-en.patch \ file://BUILD_RUNTIME_BUG_ON-vs-gcc7.patch \ + file://0001-fix-KVM-x86-Use-gpa_t-for-cr2-gpa-to-fix-TDP-support.patch \ " SRC_URI[md5sum] = "0d964723c8765b39835e5e6efc60a604" -- 2.7.4 From bunk at stusta.de Sat Mar 14 11:20:08 2020 From: bunk at stusta.de (Adrian Bunk) Date: Sat, 14 Mar 2020 13:20:08 +0200 Subject: [OE-core] [PATCH] Fix lttng-modules build failure on some versions of kernel In-Reply-To: <20200314110403.17437-1-yanfei.xu@windriver.com> References: <20200314110403.17437-1-yanfei.xu@windriver.com> Message-ID: <20200314112008.GA27595@localhost> On Sat, Mar 14, 2020 at 07:04:03PM +0800, yanfei.xu at windriver.com wrote: >... > ...-Use-gpa_t-for-cr2-gpa-to-fix-TDP-support.patch | 97 ++++++++++++++++++++++ > meta/recipes-kernel/lttng/lttng-modules_2.11.1.bb | 1 + > 2 files changed, 98 insertions(+) >... > +Upstream-Status: Backport [https://github.com/lttng/lttng-modules/commit/175c0c3c2ee8aae7a1185f591988f02e0e3be103] >... Could you submit an update to 2.11.2 instead? This is a bugfix-only update that also fixes a dozen other issues. Thanks Adrian From patchwork at patchwork.openembedded.org Sat Mar 14 11:32:17 2020 From: patchwork at patchwork.openembedded.org (Patchwork) Date: Sat, 14 Mar 2020 11:32:17 -0000 Subject: [OE-core] =?utf-8?q?=E2=9C=97_patchtest=3A_failure_for_Fix_lttng-?= =?utf-8?q?modules_build_failure_on_some_versions_of_kernel?= In-Reply-To: <20200314110403.17437-1-yanfei.xu@windriver.com> References: <20200314110403.17437-1-yanfei.xu@windriver.com> Message-ID: <20200314113217.2276.35492@do> == Series Details == Series: Fix lttng-modules build failure on some versions of kernel Revision: 1 URL : https://patchwork.openembedded.org/series/23236/ 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: * Patch Fix lttng-modules build failure on some versions of kernel Issue Shortlog does not follow expected format [test_shortlog_format] Suggested fix Commit shortlog (first line of commit message) should follow the format ": " If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core at 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 From wenlin.kang at windriver.com Sat Mar 14 12:19:23 2020 From: wenlin.kang at windriver.com (Wenlin Kang) Date: Sat, 14 Mar 2020 05:19:23 -0700 Subject: [OE-core] [zeus][PATCH] libarchive: Fix CVE-2020-9308 Message-ID: <20200314121923.78526-1-wenlin.kang@windriver.com> Fix CVE-2020-9308 Signed-off-by: Wenlin Kang --- ...ct-files-that-declare-invalid-header.patch | 124 ++++++++++++++++++ .../libarchive/libarchive_3.4.0.bb | 1 + 2 files changed, 125 insertions(+) create mode 100644 meta/recipes-extended/libarchive/libarchive/0001-RAR5-reader-reject-files-that-declare-invalid-header.patch diff --git a/meta/recipes-extended/libarchive/libarchive/0001-RAR5-reader-reject-files-that-declare-invalid-header.patch b/meta/recipes-extended/libarchive/libarchive/0001-RAR5-reader-reject-files-that-declare-invalid-header.patch new file mode 100644 index 0000000000..a84c1f1f76 --- /dev/null +++ b/meta/recipes-extended/libarchive/libarchive/0001-RAR5-reader-reject-files-that-declare-invalid-header.patch @@ -0,0 +1,124 @@ +From c1fe0a8cc8dde8ba3eae3d17e34060d2d6e4eb96 Mon Sep 17 00:00:00 2001 +From: Grzegorz Antoniak +Date: Sun, 2 Feb 2020 08:04:41 +0100 +Subject: [PATCH] RAR5 reader: reject files that declare invalid header flags + +One of the fields in RAR5's base block structure is the size of the +header. Some invalid files declare a 0 header size setting, which can +confuse the unpacker. Minimum header size for RAR5 base blocks is 7 +bytes (4 bytes for CRC, and 3 bytes for the rest), so block size of 0 +bytes should be rejected at header parsing stage. + +The fix adds an error condition if header size of 0 bytes is detected. +In this case, the unpacker will not attempt to unpack the file, as the +header is corrupted. + +The commit also adds OSSFuzz #20459 sample to test further regressions +in this area. + +Upstream-Status: Backport[https://github.com/libarchive/libarchive/commit/94821008d6eea81e315c5881cdf739202961040a] +CVE: CVE-2020-9308 + +Signed-off-by: Wenlin Kang +--- + Makefile.am | 1 + + libarchive/archive_read_support_format_rar5.c | 17 +++++++++++++++-- + libarchive/test/test_read_format_rar5.c | 15 +++++++++++++++ + ...d_format_rar5_block_size_is_too_small.rar.uu | 8 ++++++++ + 4 files changed, 39 insertions(+), 2 deletions(-) + create mode 100644 libarchive/test/test_read_format_rar5_block_size_is_too_small.rar.uu + +diff --git a/Makefile.am b/Makefile.am +index da78b24..01abf20 100644 +--- a/Makefile.am ++++ b/Makefile.am +@@ -863,6 +863,7 @@ libarchive_test_EXTRA_DIST=\ + libarchive/test/test_read_format_rar5_symlink.rar.uu \ + libarchive/test/test_read_format_rar5_truncated_huff.rar.uu \ + libarchive/test/test_read_format_rar5_win32.rar.uu \ ++ libarchive/test/test_read_format_rar5_block_size_is_too_small.rar.uu \ + libarchive/test/test_read_format_raw.bufr.uu \ + libarchive/test/test_read_format_raw.data.gz.uu \ + libarchive/test/test_read_format_raw.data.Z.uu \ +diff --git a/libarchive/archive_read_support_format_rar5.c b/libarchive/archive_read_support_format_rar5.c +index 7c24627..f73393c 100644 +--- a/libarchive/archive_read_support_format_rar5.c ++++ b/libarchive/archive_read_support_format_rar5.c +@@ -2034,6 +2034,8 @@ static int scan_for_signature(struct archive_read* a); + static int process_base_block(struct archive_read* a, + struct archive_entry* entry) + { ++ const size_t SMALLEST_RAR5_BLOCK_SIZE = 3; ++ + struct rar5* rar = get_context(a); + uint32_t hdr_crc, computed_crc; + size_t raw_hdr_size = 0, hdr_size_len, hdr_size; +@@ -2057,15 +2059,26 @@ static int process_base_block(struct archive_read* a, + return ARCHIVE_EOF; + } + ++ hdr_size = raw_hdr_size + hdr_size_len; ++ + /* Sanity check, maximum header size for RAR5 is 2MB. */ +- if(raw_hdr_size > (2 * 1024 * 1024)) { ++ if(hdr_size > (2 * 1024 * 1024)) { + archive_set_error(&a->archive, ARCHIVE_ERRNO_FILE_FORMAT, + "Base block header is too large"); + + return ARCHIVE_FATAL; + } + +- hdr_size = raw_hdr_size + hdr_size_len; ++ /* Additional sanity checks to weed out invalid files. */ ++ if(raw_hdr_size == 0 || hdr_size_len == 0 || ++ hdr_size < SMALLEST_RAR5_BLOCK_SIZE) ++ { ++ archive_set_error(&a->archive, ARCHIVE_ERRNO_FILE_FORMAT, ++ "Too small block encountered (%ld bytes)", ++ raw_hdr_size); ++ ++ return ARCHIVE_FATAL; ++ } + + /* Read the whole header data into memory, maximum memory use here is + * 2MB. */ +diff --git a/libarchive/test/test_read_format_rar5.c b/libarchive/test/test_read_format_rar5.c +index 1408f37..32e7ed8 100644 +--- a/libarchive/test/test_read_format_rar5.c ++++ b/libarchive/test/test_read_format_rar5.c +@@ -1194,3 +1194,18 @@ DEFINE_TEST(test_read_format_rar5_fileattr) + + EPILOGUE(); + } ++ ++DEFINE_TEST(test_read_format_rar5_block_size_is_too_small) ++{ ++ char buf[4096]; ++ PROLOGUE("test_read_format_rar5_block_size_is_too_small.rar"); ++ ++ /* This file is damaged, so those functions should return failure. ++ * Additionally, SIGSEGV shouldn't be raised during execution ++ * of those functions. */ ++ ++ assertA(archive_read_next_header(a, &ae) != ARCHIVE_OK); ++ assertA(archive_read_data(a, buf, sizeof(buf)) <= 0); ++ ++ EPILOGUE(); ++} +diff --git a/libarchive/test/test_read_format_rar5_block_size_is_too_small.rar.uu b/libarchive/test/test_read_format_rar5_block_size_is_too_small.rar.uu +new file mode 100644 +index 0000000..5cad219 +--- /dev/null ++++ b/libarchive/test/test_read_format_rar5_block_size_is_too_small.rar.uu +@@ -0,0 +1,8 @@ ++begin 644 test_read_format_rar5_block_size_is_too_small.rar ++M4F%R(1H'`0"-[P+2``+'(!P,("`@N`,!`B`@("`@("`@("`@("`@("#_("`@ ++M("`@("`@("`@((:Q;2!4-'-^4B`!((WO`M(``O\@$/\@-R`@("`@("`@("`@ ++M``X@("`@("`@____("`@("`@(/\@("`@("`@("`@("#_(+6U,2"UM;6UM[CU ++M)B`@*(0G(`!.`#D\3R``(/__(,+_````-0#_($&%*/HE=C+N`"```"```"`D ++J`)$#("#_("#__P`@__\@_R#_("`@("`@("#_("#__R`@(/__("#__R`" ++` ++end +-- +2.23.0 + diff --git a/meta/recipes-extended/libarchive/libarchive_3.4.0.bb b/meta/recipes-extended/libarchive/libarchive_3.4.0.bb index c196382b07..db45ccf654 100644 --- a/meta/recipes-extended/libarchive/libarchive_3.4.0.bb +++ b/meta/recipes-extended/libarchive/libarchive_3.4.0.bb @@ -33,6 +33,7 @@ EXTRA_OECONF += "--enable-largefile" SRC_URI = "http://libarchive.org/downloads/libarchive-${PV}.tar.gz \ file://CVE-2019-19221.patch \ + file://0001-RAR5-reader-reject-files-that-declare-invalid-header.patch \ " SRC_URI[md5sum] = "6046396255bd7cf6d0f6603a9bda39ac" -- 2.23.0 From daisuke.yamane at cybertrust.co.jp Sat Mar 14 13:09:42 2020 From: daisuke.yamane at cybertrust.co.jp (Daisuke Yamane) Date: Sat, 14 Mar 2020 13:09:42 +0000 Subject: [OE-core] [PATCH] selftest/package: Add test to ensure ownership is preserved Message-ID: <1584191382-14094-1-git-send-email-daisuke.yamane@cybertrust.co.jp> Yocto Bug: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13806 Add test_preserve_ownership to selftest/package. This test creates a file, a directory and a symbolic link and changes ownership, then compares with them installed in rootfs to ensure ownership is preserved. [Test without a commit 'bitbake: lib/bb/utils.py: Preserve ownership of symlink'] | 2020-03-14 10:01:14,519 - oe-selftest - INFO - test_preserve_ownership (package.PackageTests) | 2020-03-14 10:56:44,612 - oe-selftest - INFO - Check ownership of /etc/selftest-chown/file | 2020-03-14 10:56:44,770 - oe-selftest - INFO - Check ownership of /etc/selftest-chown/dir | 2020-03-14 10:56:44,822 - oe-selftest - INFO - Check ownership of /etc/selftest-chown/symlink | 2020-03-14 10:56:44,879 - oe-selftest - ERROR - Incrrect ownership /etc/selftest-chown/symlink [root:root] | 2020-03-14 10:56:45,884 - oe-selftest - INFO - ... FAIL [Test with a commit 'bitbake: lib/bb/utils.py: Preserve ownership of symlink'] | 2020-03-14 10:58:49,599 - oe-selftest - INFO - test_preserve_ownership (package.PackageTests) | 2020-03-14 11:51:39,947 - oe-selftest - INFO - Check ownership of /etc/selftest-chown/file | 2020-03-14 11:51:40,013 - oe-selftest - INFO - Check ownership of /etc/selftest-chown/dir | 2020-03-14 11:51:40,063 - oe-selftest - INFO - Check ownership of /etc/selftest-chown/symlink | 2020-03-14 11:51:41,118 - oe-selftest - INFO - ... ok Signed-off-by: Daisuke Yamane --- .../recipes-test/selftest-chown/selftest-chown.bb | 25 ++++++++++++++++++++++ meta/lib/oeqa/selftest/cases/package.py | 23 ++++++++++++++++++++ 2 files changed, 48 insertions(+) create mode 100644 meta-selftest/recipes-test/selftest-chown/selftest-chown.bb diff --git a/meta-selftest/recipes-test/selftest-chown/selftest-chown.bb b/meta-selftest/recipes-test/selftest-chown/selftest-chown.bb new file mode 100644 index 0000000..87bf943 --- /dev/null +++ b/meta-selftest/recipes-test/selftest-chown/selftest-chown.bb @@ -0,0 +1,25 @@ +SUMMARY = "selftest chown" +LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302" + +LICENSE = "MIT" + +S = "${WORKDIR}" + +inherit useradd allarch + +USERADD_PACKAGES = "${PN}" +USERADD_PARAM_${PN} = "-u 1234 -M test" +TESTDIR = "${D}${sysconfdir}/selftest-chown" + +do_install() { + install -d ${TESTDIR} + install -d ${TESTDIR}/dir + touch ${TESTDIR}/file + ln -s ./file ${TESTDIR}/symlink + + chown test:test ${TESTDIR}/file + chown -R test:test ${TESTDIR}/dir + chown -h test:test ${TESTDIR}/symlink +} + +FILES_${PN} = "${sysconfdir}/selftest-chown/*" diff --git a/meta/lib/oeqa/selftest/cases/package.py b/meta/lib/oeqa/selftest/cases/package.py index b87f8dc..3010b1a 100644 --- a/meta/lib/oeqa/selftest/cases/package.py +++ b/meta/lib/oeqa/selftest/cases/package.py @@ -148,3 +148,26 @@ class PackageTests(OESelftestTestCase): '/usr/libexec/hello4']: if not gdbtest(qemu, binary): self.fail('GDB %s failed' % binary) + + def test_preserve_ownership(self): + import os, stat, oe.cachedpath + features = 'IMAGE_INSTALL_append = " selftest-chown"\n' + self.write_config(features) + bitbake("core-image-minimal") + + sysconfdir = get_bb_var('sysconfdir', 'selftest-chown') + def check_ownership(qemu, gid, uid, path): + self.logger.info("Check ownership of %s", path) + status, output = qemu.run_serial(r'/bin/stat -c "%U %G" ' + path, timeout=60) + output = output.split(" ") + if output[0] != uid or output[1] != gid : + self.logger.error("Incrrect ownership %s [%s:%s]", path, output[0], output[1]) + return False + return True + + with runqemu('core-image-minimal') as qemu: + for path in [ sysconfdir + "/selftest-chown/file", + sysconfdir + "/selftest-chown/dir", + sysconfdir + "/selftest-chown/symlink"]: + if not check_ownership(qemu, "test", "test", path): + self.fail('Test ownership %s failed' % path) -- 2.7.4 From raj.khem at gmail.com Sat Mar 14 16:07:06 2020 From: raj.khem at gmail.com (Khem Raj) Date: Sat, 14 Mar 2020 09:07:06 -0700 Subject: [OE-core] [PATCH] bison: Update to 3.5.3 Message-ID: <20200314160706.2796013-1-raj.khem@gmail.com> bugfix release [1] [1] https://lists.gnu.org/archive/html/bison-announce/2020-03/msg00000.html Signed-off-by: Khem Raj --- .../recipes-devtools/bison/{bison_3.5.2.bb => bison_3.5.3.bb} | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) rename meta/recipes-devtools/bison/{bison_3.5.2.bb => bison_3.5.3.bb} (90%) diff --git a/meta/recipes-devtools/bison/bison_3.5.2.bb b/meta/recipes-devtools/bison/bison_3.5.3.bb similarity index 90% rename from meta/recipes-devtools/bison/bison_3.5.2.bb rename to meta/recipes-devtools/bison/bison_3.5.3.bb index b5b4a8ef76..09e4b18f9e 100644 --- a/meta/recipes-devtools/bison/bison_3.5.2.bb +++ b/meta/recipes-devtools/bison/bison_3.5.3.bb @@ -13,13 +13,11 @@ SRC_URI = "${GNU_MIRROR}/bison/bison-${PV}.tar.xz \ file://dont-depend-on-help2man.patch.patch \ file://add-with-bisonlocaledir.patch \ " +SRC_URI[sha256sum] = "2bf85b5f88a5f2fa8069aed2a2dfc3a9f8d15a97e59c713e3906e5fdd982a7c4" # No point in hardcoding path to m4, just use PATH EXTRA_OECONF += "M4=m4" -SRC_URI[md5sum] = "49fc2cf23e31e697d5072835e1662a97" -SRC_URI[sha256sum] = "24e273db9eb6da8bbb6f0648284d0724a5cbd6268a163db402f961350a4e50dd" - inherit autotools gettext texinfo # The automatic m4 path detection gets confused, so force the right value -- 2.25.1 From akuster808 at gmail.com Sat Mar 14 18:27:00 2020 From: akuster808 at gmail.com (akuster808) Date: Sat, 14 Mar 2020 11:27:00 -0700 Subject: [OE-core] [PATCH] bison: Update to 3.5.3 In-Reply-To: <20200314160706.2796013-1-raj.khem@gmail.com> References: <20200314160706.2796013-1-raj.khem@gmail.com> Message-ID: <247f037c-10bd-0eac-68d9-09155b51c81f@gmail.com> On 3/14/20 9:07 AM, Khem Raj wrote: > bugfix release [1] > > [1] https://lists.gnu.org/archive/html/bison-announce/2020-03/msg00000.html does this fix the issue you reported on IRC? > > Signed-off-by: Khem Raj > --- > .../recipes-devtools/bison/{bison_3.5.2.bb => bison_3.5.3.bb} | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > rename meta/recipes-devtools/bison/{bison_3.5.2.bb => bison_3.5.3.bb} (90%) > > diff --git a/meta/recipes-devtools/bison/bison_3.5.2.bb b/meta/recipes-devtools/bison/bison_3.5.3.bb > similarity index 90% > rename from meta/recipes-devtools/bison/bison_3.5.2.bb > rename to meta/recipes-devtools/bison/bison_3.5.3.bb > index b5b4a8ef76..09e4b18f9e 100644 > --- a/meta/recipes-devtools/bison/bison_3.5.2.bb > +++ b/meta/recipes-devtools/bison/bison_3.5.3.bb > @@ -13,13 +13,11 @@ SRC_URI = "${GNU_MIRROR}/bison/bison-${PV}.tar.xz \ > file://dont-depend-on-help2man.patch.patch \ > file://add-with-bisonlocaledir.patch \ > " > +SRC_URI[sha256sum] = "2bf85b5f88a5f2fa8069aed2a2dfc3a9f8d15a97e59c713e3906e5fdd982a7c4" no md5sum ? - armin > > # No point in hardcoding path to m4, just use PATH > EXTRA_OECONF += "M4=m4" > > -SRC_URI[md5sum] = "49fc2cf23e31e697d5072835e1662a97" > -SRC_URI[sha256sum] = "24e273db9eb6da8bbb6f0648284d0724a5cbd6268a163db402f961350a4e50dd" > - > inherit autotools gettext texinfo > > # The automatic m4 path detection gets confused, so force the right value From bunk at stusta.de Sat Mar 14 18:55:10 2020 From: bunk at stusta.de (Adrian Bunk) Date: Sat, 14 Mar 2020 20:55:10 +0200 Subject: [OE-core] [PATCH] bison: Update to 3.5.3 In-Reply-To: <247f037c-10bd-0eac-68d9-09155b51c81f@gmail.com> References: <20200314160706.2796013-1-raj.khem@gmail.com> <247f037c-10bd-0eac-68d9-09155b51c81f@gmail.com> Message-ID: <20200314185510.GA7258@localhost> On Sat, Mar 14, 2020 at 11:27:00AM -0700, akuster808 wrote: > On 3/14/20 9:07 AM, Khem Raj wrote: >... > > " > > +SRC_URI[sha256sum] = "2bf85b5f88a5f2fa8069aed2a2dfc3a9f8d15a97e59c713e3906e5fdd982a7c4" > no md5sum ? https://git.openembedded.org/bitbake/commit/?id=47f0c849ed13ba554d9523b926d92405e8251702 > - armin cu Adrian From git at andred.net Sat Mar 14 19:40:38 2020 From: git at andred.net (=?UTF-8?q?Andr=C3=A9=20Draszik?=) Date: Sat, 14 Mar 2020 19:40:38 +0000 Subject: [OE-core] [PATCH] python-numpy: incompatible with armv4 and armv5 Message-ID: <20200314194038.5051-1-git@andred.net> Just throws lots of compiler errors regarding the floating point macros, similar to the ones mentioned in commit 3e40a1d230a9 ("boost: fix mips soft float compilation") commit 7e712e1831f8 in poky. Just disable, to avoid frustration. Signed-off-by: Andr? Draszik --- meta/recipes-devtools/python-numpy/python-numpy.inc | 3 +++ 1 file changed, 3 insertions(+) diff --git a/meta/recipes-devtools/python-numpy/python-numpy.inc b/meta/recipes-devtools/python-numpy/python-numpy.inc index 8413434af9..66fd589e8c 100644 --- a/meta/recipes-devtools/python-numpy/python-numpy.inc +++ b/meta/recipes-devtools/python-numpy/python-numpy.inc @@ -50,3 +50,6 @@ RDEPENDS_${PN} = "${PYTHON_PN}-unittest \ RDEPENDS_${PN}_class-native = "" BBCLASSEXTEND = "native nativesdk" + +COMPATIBLE_HOST_armv4 = "null" +COMPATIBLE_HOST_armv5 = "null" -- 2.23.0.rc1 From bunk at stusta.de Sat Mar 14 20:32:18 2020 From: bunk at stusta.de (Adrian Bunk) Date: Sat, 14 Mar 2020 22:32:18 +0200 Subject: [OE-core] [PATCH] python-numpy: incompatible with armv4 and armv5 In-Reply-To: <20200314194038.5051-1-git@andred.net> References: <20200314194038.5051-1-git@andred.net> Message-ID: <20200314203218.GB10881@localhost> On Sat, Mar 14, 2020 at 07:40:38PM +0000, Andr? Draszik wrote: > Just throws lots of compiler errors regarding the floating point macros, > similar to the ones mentioned in commit 3e40a1d230a9 > ("boost: fix mips soft float compilation") commit 7e712e1831f8 in > poky. > > Just disable, to avoid frustration. >... > +COMPATIBLE_HOST_armv4 = "null" > +COMPATIBLE_HOST_armv5 = "null" >... Builds for me for qemuarmv5. cu Adrian From raj.khem at gmail.com Sat Mar 14 20:33:07 2020 From: raj.khem at gmail.com (Khem Raj) Date: Sat, 14 Mar 2020 13:33:07 -0700 Subject: [OE-core] [PATCH] bison: Update to 3.5.3 In-Reply-To: <247f037c-10bd-0eac-68d9-09155b51c81f@gmail.com> References: <20200314160706.2796013-1-raj.khem@gmail.com> <247f037c-10bd-0eac-68d9-09155b51c81f@gmail.com> Message-ID: On Sat, Mar 14, 2020 at 11:27 AM akuster808 wrote: > > > On 3/14/20 9:07 AM, Khem Raj wrote: > > bugfix release [1] > > > > [1] > https://lists.gnu.org/archive/html/bison-announce/2020-03/msg00000.html > > does this fix the issue you reported on IRC? No sadly it does not I am still trying to see what can fix it it?s a race that is very consistent on first build from scratch but a rebuild fixes it > > > > > Signed-off-by: Khem Raj > > --- > > .../recipes-devtools/bison/{bison_3.5.2.bb => bison_3.5.3.bb} | 4 +--- > > 1 file changed, 1 insertion(+), 3 deletions(-) > > rename meta/recipes-devtools/bison/{bison_3.5.2.bb => bison_3.5.3.bb} > (90%) > > > > diff --git a/meta/recipes-devtools/bison/bison_3.5.2.bb > b/meta/recipes-devtools/bison/bison_3.5.3.bb > > similarity index 90% > > rename from meta/recipes-devtools/bison/bison_3.5.2.bb > > rename to meta/recipes-devtools/bison/bison_3.5.3.bb > > index b5b4a8ef76..09e4b18f9e 100644 > > --- a/meta/recipes-devtools/bison/bison_3.5.2.bb > > +++ b/meta/recipes-devtools/bison/bison_3.5.3.bb > > @@ -13,13 +13,11 @@ SRC_URI = "${GNU_MIRROR}/bison/bison-${PV}.tar.xz \ > > file://dont-depend-on-help2man.patch.patch \ > > file://add-with-bisonlocaledir.patch \ > > " > > +SRC_URI[sha256sum] = > "2bf85b5f88a5f2fa8069aed2a2dfc3a9f8d15a97e59c713e3906e5fdd982a7c4" > no md5sum ? > > - armin > > > > # No point in hardcoding path to m4, just use PATH > > EXTRA_OECONF += "M4=m4" > > > > -SRC_URI[md5sum] = "49fc2cf23e31e697d5072835e1662a97" > > -SRC_URI[sha256sum] = > "24e273db9eb6da8bbb6f0648284d0724a5cbd6268a163db402f961350a4e50dd" > > - > > inherit autotools gettext texinfo > > > > # The automatic m4 path detection gets confused, so force the right > value > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alhe at linux.microsoft.com Sun Mar 15 06:13:11 2020 From: alhe at linux.microsoft.com (Alejandro Hernandez Samaniego) Date: Sat, 14 Mar 2020 23:13:11 -0700 Subject: [OE-core] [PATCH] Windows: Enable Windows builds under WSLv2 and warn accordingly Message-ID: <20200315061311.19344-1-alhe@linux.microsoft.com> Due to the architectural changes between Windows Subsystem for Linux v2, and WSL v1 it should now be possible to run bitbake on the several distros offered through the Microsoft Store. WSLv2 is available on Windows 10 build number > 18917 The current build number may be checked by opening a cmd prompt on Windows and running: C:\Users\myuser>ver Microsoft Windows [Version 10.0.19041.113] If a distro has already been installed via the Microsoft Store, then we can check which WSL version its using by opening a Windows Powershell (notice this is a powershell and not a cmd prompt): C:\WINDOWS\system32> wsl -l -v NAME STATE VERSION * Ubuntu Running 2 Debian Stopped 1 In this case it shows two distros installed, Ubuntu running WSLv2 and Debian running WSLv1 To change the version of WSL being used by a certain distro run: C:\WINDOWS\system32> wsl --set-version 2 e.g C:\WINDOWS\system32> wsl --set-version Debian 2 For more information on installing WSLv2 please look at: https://docs.microsoft.com/en-us/windows/wsl/wsl2-install There are some caveats related to the way storage is handled by WSLv2 though, and at this point these have to be managed by the user manually, the storage space used by WSL is not reflected immediately and since bitbake heavily uses storage, after several builds this can prove to be a bit of an issue. WSLv2 uses a VHDX file for storage, this issue can be easily avoided by optimizing this file every now and then, this can be done via the following: 1.- Find the location of your VHDX file: - Get the distro app package directory. - Open Windows Powershell as Administrator and run: Get-AppxPackage -Name "**" | Select PackageFamilyName e.g.: PS C:\WINDOWS\system32> Get-AppxPackage -Name "*Ubuntu*" | Select PackageFamilyName PackageFamilyName ----------------- CanonicalGroupLimited.UbuntuonWindows_79abcdefgh Replace the PackageFamilyName (and your user) on the following path: C:\Users\\AppData\Local\Packages\\LocalState\ e.g. ls C:\Users\\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79abcdefgh\LocalState\ Mode LastWriteTime Length Name -a---- 3/14/2020 9:52 PM 57418973184 ext4.vhdx The VHDX file path is: C:\Users\\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79abcdefgh\LocalState\ext4.vhdx 2.- Optimize your VHDX file (Also on Powershell): - Make sure WSL is shutdown wsl --shutdown - Optimize it optimize-vhd -Path C:\Users\\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79abcdefgh\LocalState\ext4.vhdx -Mode full A progress bar should be shown while optimizing the VHDX file. As an example, after building core-image-sato, removing the TMPDIR did not reflect any changes on Windows Explorer for storage space being used, after optimizing the VHDX file, 14 extra GB were shown as free. So, as long as the the user optimizes its storage, the builds should run smoothly. This patch warns the user that is running bitbake under WSLv2, that they should optimize the VHDX file eventually to avoid storage issues. The same check previoulsy used for WSLv1 works for WSLv2, checking for the kernel version: WSLv1: Linux version 4.4.0-19041-Microsoft (Microsoft at Microsoft.com) WSLv2: Linux version 4.19.84-microsoft-standard (oe-user at oe-host) Builds have been tested under Ubuntu and Debian distros offered and installed through the Microsoft Store, and other distros should be able to run builds just as fine. Performance wise, using the same hardware, and same configuration a comparison between builds using native Linux vs WSLv2 for the following targets has been performed: - core-image-minimal - core-image-sato - core-image-sato-sdk - meta-toolchain No real evidence of any performance changes could be found, with WSLv2 builds running even faster in some cases. Running a recently built image can be done just as smoothly, if using "nographic" as argument for runqemu, or if its a graphical image, installing an X server and running runqemu runs just as fine. Happy bitbaking. Signed-off-by: Alejandro Hernandez Samaniego Signed-off-by: Alejandro Hernandez Samaniego --- meta/classes/sanity.bbclass | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass index cca5cdad17..2729983077 100644 --- a/meta/classes/sanity.bbclass +++ b/meta/classes/sanity.bbclass @@ -511,14 +511,20 @@ def check_make_version(sanity_data): return None -# Check if we're running on WSL (Windows Subsystem for Linux). Its known not to -# work but we should tell the user that upfront. +# Check if we're running on WSL (Windows Subsystem for Linux). +# WSLv1 is known not to work but WSLv2 should work properly as +# long as the VHDX file is optimized often, let the user know +# upfront. +# More information on installing WSLv2 at: +# https://docs.microsoft.com/en-us/windows/wsl/wsl2-install def check_wsl(d): with open("/proc/version", "r") as f: verdata = f.readlines() for l in verdata: if "Microsoft" in l: - return "OpenEmbedded doesn't work under WSL at this time, sorry" + return "OpenEmbedded doesn't work under WSLv1, please upgrade to WSLv2 if you want to run builds on Windows" + elif "microsoft" in l: + bb.warn("You are running bitbake under WSLv2, this works properly but you should optimize your VHDX file eventually to avoid running out of storage space") return None # Tar version 1.24 and onwards handle overwriting symlinks correctly -- 2.17.1 From raj.khem at gmail.com Sun Mar 15 04:29:47 2020 From: raj.khem at gmail.com (Khem Raj) Date: Sat, 14 Mar 2020 21:29:47 -0700 Subject: [OE-core] [PATCH] bison: Reset load average settings if specified in environment Message-ID: <20200315042947.3257882-1-raj.khem@gmail.com> In some cases, we run into parallel build failures where BUILT_SOURCES is skipped, as a result required header files are not generated and the build fails with missing header errors like ../bison-3.5.2/lib/uniwidth/width.c:21:10: fatal error: uniwidth.h: No such file or directory #include "uniwidth.h" ^~~~~~~~~~~~ compilation terminated. BUILT_SOURCES should be built automatically with `make all` [1] therefore ensure that make is invoked with `all` target bison-native parallel build fails when -l is passed globally from build environment, errors like below due to race starts to show up Therefore removes a previous load limit if set [1] https://www.gnu.org/software/automake/manual/html_node/Built-Sources-Example.html#Built-Sources-Example Signed-off-by: Khem Raj --- meta/recipes-devtools/bison/bison_3.5.3.bb | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/meta/recipes-devtools/bison/bison_3.5.3.bb b/meta/recipes-devtools/bison/bison_3.5.3.bb index 09e4b18f9e..27e09434f8 100644 --- a/meta/recipes-devtools/bison/bison_3.5.3.bb +++ b/meta/recipes-devtools/bison/bison_3.5.3.bb @@ -18,6 +18,12 @@ SRC_URI[sha256sum] = "2bf85b5f88a5f2fa8069aed2a2dfc3a9f8d15a97e59c713e3906e5fdd9 # No point in hardcoding path to m4, just use PATH EXTRA_OECONF += "M4=m4" +# Reset any loadavg set via environment, it breaks parallel build +# | ../bison-3.5.2/lib/uniwidth/width.c:21:10: fatal error: uniwidth.h: No such file or directory +# | #include "uniwidth.h" +# | ^~~~~~~~~~~~ +EXTRA_OEMAKE_append = " -l" + inherit autotools gettext texinfo # The automatic m4 path detection gets confused, so force the right value -- 2.25.1 From patchwork at patchwork.openembedded.org Sun Mar 15 04:32:41 2020 From: patchwork at patchwork.openembedded.org (Patchwork) Date: Sun, 15 Mar 2020 04:32:41 -0000 Subject: [OE-core] =?utf-8?q?=E2=9C=97_patchtest=3A_failure_for_bison=3A_R?= =?utf-8?q?eset_load_average_settings_if_specified_in_environment?= In-Reply-To: <20200315042947.3257882-1-raj.khem@gmail.com> References: <20200315042947.3257882-1-raj.khem@gmail.com> Message-ID: <20200315043241.2277.40824@do> == Series Details == Series: bison: Reset load average settings if specified in environment Revision: 1 URL : https://patchwork.openembedded.org/series/23244/ 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 fix Rebase your series on top of targeted branch Targeted branch master (currently at b1ae2178fa) If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core at 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 From alex.kanavin at gmail.com Sun Mar 15 05:38:27 2020 From: alex.kanavin at gmail.com (Alexander Kanavin) Date: Sun, 15 Mar 2020 06:38:27 +0100 Subject: [OE-core] [PATCH] bison: Reset load average settings if specified in environment In-Reply-To: <20200315042947.3257882-1-raj.khem@gmail.com> References: <20200315042947.3257882-1-raj.khem@gmail.com> Message-ID: Shouldn?t the race be fixed? This might still happen because -j still parallelises the build,no? Alex On Sun 15. Mar 2020 at 5.30, Khem Raj wrote: > In some cases, we run into parallel build failures where BUILT_SOURCES > is skipped, as a result required header files are not generated and the > build fails with missing header errors like > > ../bison-3.5.2/lib/uniwidth/width.c:21:10: fatal error: uniwidth.h: No > such file or directory > #include "uniwidth.h" > ^~~~~~~~~~~~ > compilation terminated. > > BUILT_SOURCES should be built automatically with `make all` [1] therefore > ensure that make is invoked with `all` target > > bison-native parallel build fails when -l is passed globally from > build environment, errors like below due to race starts to show up > > Therefore removes a previous load limit if set > > [1] > https://www.gnu.org/software/automake/manual/html_node/Built-Sources-Example.html#Built-Sources-Example > > Signed-off-by: Khem Raj > --- > meta/recipes-devtools/bison/bison_3.5.3.bb | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/meta/recipes-devtools/bison/bison_3.5.3.bb > b/meta/recipes-devtools/bison/bison_3.5.3.bb > index 09e4b18f9e..27e09434f8 100644 > --- a/meta/recipes-devtools/bison/bison_3.5.3.bb > +++ b/meta/recipes-devtools/bison/bison_3.5.3.bb > @@ -18,6 +18,12 @@ SRC_URI[sha256sum] = > "2bf85b5f88a5f2fa8069aed2a2dfc3a9f8d15a97e59c713e3906e5fdd9 > # No point in hardcoding path to m4, just use PATH > EXTRA_OECONF += "M4=m4" > > +# Reset any loadavg set via environment, it breaks parallel build > +# | ../bison-3.5.2/lib/uniwidth/width.c:21:10: fatal error: uniwidth.h: > No such file or directory > +# | #include "uniwidth.h" > +# | ^~~~~~~~~~~~ > +EXTRA_OEMAKE_append = " -l" > + > inherit autotools gettext texinfo > > # The automatic m4 path detection gets confused, so force the right value > -- > 2.25.1 > > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core at lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raj.khem at gmail.com Sun Mar 15 07:52:25 2020 From: raj.khem at gmail.com (Khem Raj) Date: Sun, 15 Mar 2020 00:52:25 -0700 Subject: [OE-core] [PATCH] bison: Reset load average settings if specified in environment In-Reply-To: References: <20200315042947.3257882-1-raj.khem@gmail.com> Message-ID: On Sat, Mar 14, 2020 at 10:38 PM Alexander Kanavin wrote: > Shouldn?t the race be fixed? This might still happen because -j still > parallelises the build,no? > It perhaps is a make bug which only triggers with -j and -l being both present it?s perhaps easily reproducible using these together on bison builds As such I don?t see anything wrong with bison makery > Alex > > On Sun 15. Mar 2020 at 5.30, Khem Raj wrote: > >> In some cases, we run into parallel build failures where BUILT_SOURCES >> is skipped, as a result required header files are not generated and the >> build fails with missing header errors like >> >> ../bison-3.5.2/lib/uniwidth/width.c:21:10: fatal error: uniwidth.h: No >> such file or directory >> #include "uniwidth.h" >> ^~~~~~~~~~~~ >> compilation terminated. >> >> BUILT_SOURCES should be built automatically with `make all` [1] therefore >> ensure that make is invoked with `all` target >> >> bison-native parallel build fails when -l is passed globally from >> build environment, errors like below due to race starts to show up >> >> Therefore removes a previous load limit if set >> >> [1] >> https://www.gnu.org/software/automake/manual/html_node/Built-Sources-Example.html#Built-Sources-Example >> >> Signed-off-by: Khem Raj >> --- >> meta/recipes-devtools/bison/bison_3.5.3.bb | 6 ++++++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/meta/recipes-devtools/bison/bison_3.5.3.bb >> b/meta/recipes-devtools/bison/bison_3.5.3.bb >> index 09e4b18f9e..27e09434f8 100644 >> --- a/meta/recipes-devtools/bison/bison_3.5.3.bb >> +++ b/meta/recipes-devtools/bison/bison_3.5.3.bb >> @@ -18,6 +18,12 @@ SRC_URI[sha256sum] = >> "2bf85b5f88a5f2fa8069aed2a2dfc3a9f8d15a97e59c713e3906e5fdd9 >> # No point in hardcoding path to m4, just use PATH >> EXTRA_OECONF += "M4=m4" >> >> +# Reset any loadavg set via environment, it breaks parallel build >> +# | ../bison-3.5.2/lib/uniwidth/width.c:21:10: fatal error: uniwidth.h: >> No such file or directory >> +# | #include "uniwidth.h" >> +# | ^~~~~~~~~~~~ >> +EXTRA_OEMAKE_append = " -l" >> + >> inherit autotools gettext texinfo >> >> # The automatic m4 path detection gets confused, so force the right value >> -- >> 2.25.1 >> >> -- >> _______________________________________________ >> Openembedded-core mailing list >> Openembedded-core at lists.openembedded.org >> http://lists.openembedded.org/mailman/listinfo/openembedded-core >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard.purdie at linuxfoundation.org Sun Mar 15 11:48:47 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Sun, 15 Mar 2020 11:48:47 +0000 Subject: [OE-core] [PATCH] Windows: Enable Windows builds under WSLv2 and warn accordingly In-Reply-To: <20200315061311.19344-1-alhe@linux.microsoft.com> References: <20200315061311.19344-1-alhe@linux.microsoft.com> Message-ID: On Sat, 2020-03-14 at 23:13 -0700, Alejandro Hernandez Samaniego wrote: > Due to the architectural changes between Windows Subsystem for Linux > v2, and WSL v1 it should now be possible to run bitbake on the > several distros offered through the Microsoft Store. > > WSLv2 is available on Windows 10 build number > 18917 > > The current build number may be checked by opening a cmd prompt on > Windows and running: > > C:\Users\myuser>ver > > Microsoft Windows [Version 10.0.19041.113] Thanks, this is useful information. How much of our system works on WSL2? runqemu? testimage? eSDK? virtgl? Is anything known not to work? This email implies everything works? My big worry here is that we have a set subset of bugs which only occur on WSL2. We're struggling with the bug reports we have today, adding in a whole new set with no help to support that is a concern. Is this for 3.1 LTS? Are Microsoft going to be able to help us in any way? How "official" is this change? > > if "Microsoft" in l: > - return "OpenEmbedded doesn't work under WSL at this time, sorry" > + return "OpenEmbedded doesn't work under WSLv1, please upgrade to WSLv2 if you want to run builds on Windows" > + elif "microsoft" in l: > + bb.warn("You are running bitbake under WSLv2, this works properly but you should optimize your VHDX file eventually to avoid running out of storage space") > return None > > # Tar version 1.24 and onwards handle overwriting symlinks correctly Is Microsoft vs microsoft the best check we can have? Should we be checking the version specifically? Cheers, Richard From richard.purdie at linuxfoundation.org Sun Mar 15 12:30:22 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Sun, 15 Mar 2020 12:30:22 +0000 Subject: [OE-core] [PATCH] base-passwd: LICENSE changed to GPLv2 In-Reply-To: <6aff6b44d0d9458992b5467336ceac82@G08CNEXMBPEKD05.g08.fujitsu.local> References: <1584097866-54513-1-git-send-email-wangmy@cn.fujitsu.com> <44535d2e53175baa8b7b7969fa9276e924a43fca.camel@linuxfoundation.org> <6aff6b44d0d9458992b5467336ceac82@G08CNEXMBPEKD05.g08.fujitsu.local> Message-ID: <7a2ed63ed53af8e472dde821cb5a416bf04140d4.camel@linuxfoundation.org> On Sat, 2020-03-14 at 04:49 +0000, Wang, Mingyu wrote: > Hi, > Richard > > > Why? The license file didn't change. This needs an explanation. > > 1. For base-passwd, I think that it's gpl-2.0-only since it is > declared as "gpl-2" in debian/copyright, not "gpl-2 or later" > > License: GPL-2 > On Debian and Debian-based systems, a copy of the GNU General Public > License version 2 is available in /usr/share/common-licenses/GPL-2. > > 2.GPLv2 constant: > > 9. The Free Software Foundation may publish revised and/or new > > versions > > of the General Public License from time to time. Such new versions > > will > > be similar in spirit to the present version, but may differ in > > detail to > > address new problems or concerns. > > > > Each version is given a distinguishing version number. If the > > Program > > specifies a version number of this License which applies to it and > > "any > > later version", you have the option of following the terms and > > conditions > > either of that version or of any later version published by the > > Free > > Software Foundation. If the Program does not specify a version > > number of > > this License, you may choose any version ever published by the Free > > Software > > Foundation. > The license would be GPLv2+, only when license name is "gpl-2 or > later". > > 3. The bb file of libcomps contains the following contents: > LICENSE = "GPLv2" > The "COPYING? file from libcomps and base-passwd are the same, > So it seems that the package LICENSE fields of the same copyright > declaration are not unified. Thanks. Can you resend this patch with an explanation in the commit message please? It can just be something like: "The source code such as update-passwd.c states the license to be under GPL v2 only and does not contain the "or later" clause so correct the recipe LICENSE field to match". Cheers, Richard From bunk at stusta.de Sun Mar 15 13:10:05 2020 From: bunk at stusta.de (Adrian Bunk) Date: Sun, 15 Mar 2020 15:10:05 +0200 Subject: [OE-core] [PATCH] bison: Reset load average settings if specified in environment In-Reply-To: References: <20200315042947.3257882-1-raj.khem@gmail.com> Message-ID: <20200315131005.GA31660@localhost> On Sun, Mar 15, 2020 at 12:52:25AM -0700, Khem Raj wrote: > On Sat, Mar 14, 2020 at 10:38 PM Alexander Kanavin > wrote: > > > Shouldn?t the race be fixed? This might still happen because -j still > > parallelises the build,no? > > It perhaps is a make bug which only triggers with -j and -l being both > present it?s perhaps easily reproducible using these together on bison > builds > As such I don?t see anything wrong with bison makery This is the second bison-native problem in addition to https://bugzilla.yoctoproject.org/show_bug.cgi?id=13825 It is possible that the gnulib issue was a red herring and it is actually is a parallel build issue, but both being in bison-native does point more towards a problem specific to bison. cu Adrian From bunk at stusta.de Sun Mar 15 18:04:24 2020 From: bunk at stusta.de (Adrian Bunk) Date: Sun, 15 Mar 2020 20:04:24 +0200 Subject: [OE-core] [zeus][PATCH] python3: Upgrade 3.7.6 -> 3.7.7 Message-ID: <20200315180424.25494-1-bunk@stusta.de> THE LICENSE checksum changed in this update due to copyright notice added for 2020. Signed-off-by: Adrian Bunk --- .../python/{python3_3.7.6.bb => python3_3.7.7.bb} | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) rename meta/recipes-devtools/python/{python3_3.7.6.bb => python3_3.7.7.bb} (98%) diff --git a/meta/recipes-devtools/python/python3_3.7.6.bb b/meta/recipes-devtools/python/python3_3.7.7.bb similarity index 98% rename from meta/recipes-devtools/python/python3_3.7.6.bb rename to meta/recipes-devtools/python/python3_3.7.7.bb index b33b7028d4..823eb2f8fd 100644 --- a/meta/recipes-devtools/python/python3_3.7.6.bb +++ b/meta/recipes-devtools/python/python3_3.7.7.bb @@ -3,7 +3,7 @@ HOMEPAGE = "http://www.python.org" LICENSE = "PSFv2" SECTION = "devel/python" -LIC_FILES_CHKSUM = "file://LICENSE;md5=e466242989bd33c1bd2b6a526a742498" +LIC_FILES_CHKSUM = "file://LICENSE;md5=203a6dbc802ee896020a47161e759642" SRC_URI = "http://www.python.org/ftp/python/${PV}/Python-${PV}.tar.xz \ file://run-ptest \ @@ -38,8 +38,8 @@ SRC_URI_append_class-nativesdk = " \ file://0001-main.c-if-OEPYTHON3HOME-is-set-use-instead-of-PYTHON.patch \ " -SRC_URI[md5sum] = "c08fbee72ad5c2c95b0f4e44bf6fd72c" -SRC_URI[sha256sum] = "55a2cce72049f0794e9a11a84862e9039af9183603b78bc60d89539f82cf533f" +SRC_URI[md5sum] = "172c650156f7bea68ce31b2fd01fa766" +SRC_URI[sha256sum] = "06a0a9f1bf0d8cd1e4121194d666c4e28ddae4dd54346de6c343206599f02136" # exclude pre-releases for both python 2.x and 3.x UPSTREAM_CHECK_REGEX = "[Pp]ython-(?P\d+(\.\d+)+).tar" -- 2.17.1 From bunk at stusta.de Sun Mar 15 18:08:40 2020 From: bunk at stusta.de (Adrian Bunk) Date: Sun, 15 Mar 2020 20:08:40 +0200 Subject: [OE-core] [warrior][PATCH 1/2] openssl10: Add CVE_PRODUCT Message-ID: <20200315180841.3730-1-bunk@stusta.de> Signed-off-by: Adrian Bunk --- meta/recipes-connectivity/openssl/openssl10_1.0.2r.bb | 2 ++ 1 file changed, 2 insertions(+) diff --git a/meta/recipes-connectivity/openssl/openssl10_1.0.2r.bb b/meta/recipes-connectivity/openssl/openssl10_1.0.2r.bb index 87df4f517a..7e2b884856 100644 --- a/meta/recipes-connectivity/openssl/openssl10_1.0.2r.bb +++ b/meta/recipes-connectivity/openssl/openssl10_1.0.2r.bb @@ -60,6 +60,8 @@ S = "${WORKDIR}/openssl-${PV}" UPSTREAM_CHECK_REGEX = "openssl-(?P1\.0.+)\.tar" +CVE_PRODUCT = "openssl:openssl" + inherit pkgconfig siteinfo multilib_header ptest manpages PACKAGECONFIG ?= "cryptodev-linux" -- 2.17.1 From bunk at stusta.de Sun Mar 15 18:08:41 2020 From: bunk at stusta.de (Adrian Bunk) Date: Sun, 15 Mar 2020 20:08:41 +0200 Subject: [OE-core] [warrior][PATCH 2/2] openssl10: Upgrade 1.0.2r -> 1.0.2u In-Reply-To: <20200315180841.3730-1-bunk@stusta.de> References: <20200315180841.3730-1-bunk@stusta.de> Message-ID: <20200315180841.3730-2-bunk@stusta.de> Signed-off-by: Adrian Bunk --- .../openssl/{openssl10_1.0.2r.bb => openssl10_1.0.2u.bb} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename meta/recipes-connectivity/openssl/{openssl10_1.0.2r.bb => openssl10_1.0.2u.bb} (98%) diff --git a/meta/recipes-connectivity/openssl/openssl10_1.0.2r.bb b/meta/recipes-connectivity/openssl/openssl10_1.0.2u.bb similarity index 98% rename from meta/recipes-connectivity/openssl/openssl10_1.0.2r.bb rename to meta/recipes-connectivity/openssl/openssl10_1.0.2u.bb index 7e2b884856..c5a00066ba 100644 --- a/meta/recipes-connectivity/openssl/openssl10_1.0.2r.bb +++ b/meta/recipes-connectivity/openssl/openssl10_1.0.2u.bb @@ -53,8 +53,8 @@ SRC_URI_append_class-nativesdk = " \ file://environment.d-openssl.sh \ " -SRC_URI[md5sum] = "0d2baaf04c56d542f6cc757b9c2a2aac" -SRC_URI[sha256sum] = "ae51d08bba8a83958e894946f15303ff894d75c2b8bbd44a852b64e3fe11d0d6" +SRC_URI[md5sum] = "cdc2638f789ecc2db2c91488265686c1" +SRC_URI[sha256sum] = "ecd0c6ffb493dd06707d38b14bb4d8c2288bb7033735606569d8f90f89669d16" S = "${WORKDIR}/openssl-${PV}" -- 2.17.1 From akuster808 at gmail.com Sun Mar 15 18:11:42 2020 From: akuster808 at gmail.com (Armin Kuster) Date: Sun, 15 Mar 2020 11:11:42 -0700 Subject: [OE-core] [zeus 00/16] pull request Message-ID: Please merge these changes to zeus The following changes since commit c78140941f8a98e013932023a63501ba3b7e975a: linux-yocto/5.2: update to v5.2.32 (2020-02-28 11:54:08 +0800) are available in the Git repository at: git://git.openembedded.org/openembedded-core-contrib stable/zeus-next http://cgit.openembedded.org/openembedded-core-contrib/log/?h=stable/zeus-next Armin Kuster (2): cve-check: fail gracefully when file not found wic/engine: lets display an error not a traceback Bruce Ashfield (1): linux-yocto/5.2: backport perf build fix for latest binutils Chee Yang Lee (2): cve-check: show whitelisted status cve-check: fix ValueError Khem Raj (1): valgrind: Fix build with -fno-common Lee Chee Yang (1): virglrenderer: fix multiple CVEs Mark Hatle (1): gcc-cross-canadian: A missing space in an append caused an invalid option Michael Halstead (1): yocto-uninative.inc: version 2.8 updates glibc to 2.31 Nathan Rossi (2): gcc-cross.inc: Prevent native sysroot from leaking into configargs.h gcc-target.inc: Prevent sysroot from leaking into configargs.h Ovidiu Panait (1): dhcp: Fix REQUIRE(ctx->running) assertion triggered on SIGTERM/SIGINT Rahul Chauhan (1): ruby: fix CVE-2019-16254 Richard Purdie (2): dummy-sdk-package: Add DUMMYPROVIDES_PACKAGES maintainers: Add entry for buildtools-extended-tarball Zhixiong Chi (1): glibc: CVE-2020-10029 meta/classes/cve-check.bbclass | 25 ++- meta/conf/distro/include/maintainers.inc | 1 + meta/conf/distro/include/yocto-uninative.inc | 10 +- ...s-running-prior-to-calling-isc_app_c.patch | 165 ++++++++++++++++++ ...ed-shutdown-log-statment-to-dhcrelay.patch | 29 +++ .../dhcp/0003-Addressed-review-comment.patch | 31 ++++ meta/recipes-connectivity/dhcp/dhcp_4.4.1.bb | 3 + .../glibc/glibc/CVE-2020-10029.patch | 128 ++++++++++++++ meta/recipes-core/glibc/glibc_2.30.bb | 1 + meta/recipes-core/meta/dummy-sdk-package.inc | 3 + .../meta/nativesdk-buildtools-perl-dummy.bb | 5 +- .../meta/nativesdk-sdk-provides-dummy.bb | 5 +- .../meta/target-sdk-provides-dummy.bb | 1 - .../gcc/gcc-cross-canadian.inc | 4 +- meta/recipes-devtools/gcc/gcc-cross.inc | 7 + meta/recipes-devtools/gcc/gcc-runtime.inc | 4 - meta/recipes-devtools/gcc/gcc-target.inc | 8 + .../ruby/ruby/fix-CVE-2019-16254.patch | 106 +++++++++++ meta/recipes-devtools/ruby/ruby_2.5.5.bb | 1 + .../valgrind/valgrind/s390x_vec_op_t.patch | 19 ++ .../valgrind/valgrind_3.15.0.bb | 1 + .../virglrenderer/CVE-2019-18390.patch | 66 +++++++ .../virglrenderer/CVE-2019-18391.patch | 51 ++++++ .../virglrenderer/CVE-2020-8002.patch | 39 +++++ .../virglrenderer/virglrenderer_0.8.0.bb | 3 + .../linux/linux-yocto-rt_5.2.bb | 2 +- .../linux/linux-yocto-tiny_5.2.bb | 4 +- meta/recipes-kernel/linux/linux-yocto_5.2.bb | 18 +- scripts/lib/wic/engine.py | 5 +- 29 files changed, 710 insertions(+), 35 deletions(-) create mode 100644 meta/recipes-connectivity/dhcp/dhcp/0001-Ensure-context-is-running-prior-to-calling-isc_app_c.patch create mode 100644 meta/recipes-connectivity/dhcp/dhcp/0002-Added-shutdown-log-statment-to-dhcrelay.patch create mode 100644 meta/recipes-connectivity/dhcp/dhcp/0003-Addressed-review-comment.patch create mode 100644 meta/recipes-core/glibc/glibc/CVE-2020-10029.patch create mode 100644 meta/recipes-devtools/ruby/ruby/fix-CVE-2019-16254.patch create mode 100644 meta/recipes-devtools/valgrind/valgrind/s390x_vec_op_t.patch create mode 100644 meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2019-18390.patch create mode 100644 meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2019-18391.patch create mode 100644 meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2020-8002.patch -- 2.17.1 From akuster808 at gmail.com Sun Mar 15 18:11:43 2020 From: akuster808 at gmail.com (Armin Kuster) Date: Sun, 15 Mar 2020 11:11:43 -0700 Subject: [OE-core] [zeus 01/16] yocto-uninative.inc: version 2.8 updates glibc to 2.31 In-Reply-To: References: Message-ID: <2da4ee30335d0b127b79a6eedad68c8559606c57.1584295805.git.akuster808@gmail.com> From: Michael Halstead Allow sstate use in Tumbleweed and other distros as they update glibc. Signed-off-by: Richard Purdie (cherry picked from commit ccb374c279b260b1fd3460f6bfd1567240816055) Signed-off-by: Armin Kuster --- meta/conf/distro/include/yocto-uninative.inc | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/meta/conf/distro/include/yocto-uninative.inc b/meta/conf/distro/include/yocto-uninative.inc index ad75d3e2a3..889695eae3 100644 --- a/meta/conf/distro/include/yocto-uninative.inc +++ b/meta/conf/distro/include/yocto-uninative.inc @@ -6,9 +6,9 @@ # to the distro running on the build machine. # -UNINATIVE_MAXGLIBCVERSION = "2.30" +UNINATIVE_MAXGLIBCVERSION = "2.31" -UNINATIVE_URL ?= "http://downloads.yoctoproject.org/releases/uninative/2.7/" -UNINATIVE_CHECKSUM[aarch64] ?= "e76a45886ee8a0b3904b761c17ac8ff91edf9811ee455f1832d10763ba794dfc" -UNINATIVE_CHECKSUM[i686] ?= "810d027dfb1c7675226afbcec07808770516c969ee7378f6d8240281083f8924" -UNINATIVE_CHECKSUM[x86_64] ?= "9498d8bba047499999a7310ac2576d0796461184965351a56f6d32c888a1f216" +UNINATIVE_URL ?= "http://downloads.yoctoproject.org/releases/uninative/2.8/" +UNINATIVE_CHECKSUM[aarch64] ?= "989187344bf9539b464fb7ed9c223e51f4bdb4c7a677d2c314e6fed393176efe" +UNINATIVE_CHECKSUM[i686] ?= "cc3e45bc8594488b407363e3fa9af5a099279dab2703c64342098719bd674990" +UNINATIVE_CHECKSUM[x86_64] ?= "a09922172c3a439105e0ae6b943daad2d83505b17da0aba97961ff433b8c21ab" -- 2.17.1 From akuster808 at gmail.com Sun Mar 15 18:11:44 2020 From: akuster808 at gmail.com (Armin Kuster) Date: Sun, 15 Mar 2020 11:11:44 -0700 Subject: [OE-core] [zeus 02/16] linux-yocto/5.2: backport perf build fix for latest binutils In-Reply-To: References: Message-ID: From: Bruce Ashfield [ Author: Changbin Du Date: Tue Jan 28 23:29:38 2020 +0800 perf: Make perf able to build with latest libbfd libbfd has changed the bfd_section_* macros to inline functions bfd_section_ since 2019-09-18. See below two commits: o http://www.sourceware.org/ml/gdb-cvs/2019-09/msg00064.html o https://www.sourceware.org/ml/gdb-cvs/2019-09/msg00072.html This fix make perf able to build with both old and new libbfd. Signed-off-by: Changbin Du Acked-by: Jiri Olsa Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/20200128152938.31413-1-changbin.du at gmail.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Bruce Ashfield ] Signed-off-by: Bruce Ashfield Signed-off-by: Richard Purdie (cherry picked from commit 14a338dbbe2da5a022a916081b3aab9c7472c3ce) Signed-off-by: Armin Kuster --- .../recipes-kernel/linux/linux-yocto-rt_5.2.bb | 2 +- .../linux/linux-yocto-tiny_5.2.bb | 4 ++-- meta/recipes-kernel/linux/linux-yocto_5.2.bb | 18 +++++++++--------- 3 files changed, 12 insertions(+), 12 deletions(-) diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.2.bb b/meta/recipes-kernel/linux/linux-yocto-rt_5.2.bb index 441545f55e..a23a5e6f93 100644 --- a/meta/recipes-kernel/linux/linux-yocto-rt_5.2.bb +++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.2.bb @@ -11,7 +11,7 @@ python () { raise bb.parse.SkipRecipe("Set PREFERRED_PROVIDER_virtual/kernel to linux-yocto-rt to enable it") } -SRCREV_machine ?= "b18bde6f0d8d1a5710cec9792372c03543cf0be9" +SRCREV_machine ?= "78e147f949b5b18524aa7bd72f1cc8f7ae8039f8" SRCREV_meta ?= "bb2776d6beaae64b1a0fc902b64376f082085498" SRC_URI = "git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \ diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_5.2.bb b/meta/recipes-kernel/linux/linux-yocto-tiny_5.2.bb index 6d49e00e21..ac9904f415 100644 --- a/meta/recipes-kernel/linux/linux-yocto-tiny_5.2.bb +++ b/meta/recipes-kernel/linux/linux-yocto-tiny_5.2.bb @@ -15,8 +15,8 @@ DEPENDS += "openssl-native util-linux-native" KMETA = "kernel-meta" KCONF_BSP_AUDIT_LEVEL = "2" -SRCREV_machine_qemuarm ?= "ed1c3b7ad8221ba4e20ce7e4e4f6a73afd5015d4" -SRCREV_machine ?= "c926964d00caf714f42878535af8c7374452072d" +SRCREV_machine_qemuarm ?= "e0a3a01b24070b15121e938ea19755091bf0d662" +SRCREV_machine ?= "73b12de4c879e4569bef3b2d0ee9c783a9788b27" SRCREV_meta ?= "bb2776d6beaae64b1a0fc902b64376f082085498" PV = "${LINUX_VERSION}+git${SRCPV}" diff --git a/meta/recipes-kernel/linux/linux-yocto_5.2.bb b/meta/recipes-kernel/linux/linux-yocto_5.2.bb index 44516dcacb..eab142e1c6 100644 --- a/meta/recipes-kernel/linux/linux-yocto_5.2.bb +++ b/meta/recipes-kernel/linux/linux-yocto_5.2.bb @@ -12,15 +12,15 @@ KBRANCH_qemux86 ?= "v5.2/standard/base" KBRANCH_qemux86-64 ?= "v5.2/standard/base" KBRANCH_qemumips64 ?= "v5.2/standard/mti-malta64" -SRCREV_machine_qemuarm ?= "1ed2236e622e5b79d910fc1db37ec6eec5a94fdc" -SRCREV_machine_qemuarm64 ?= "c926964d00caf714f42878535af8c7374452072d" -SRCREV_machine_qemumips ?= "e669e4307d07072458904ac0fda56f7192e2880d" -SRCREV_machine_qemuppc ?= "c926964d00caf714f42878535af8c7374452072d" -SRCREV_machine_qemuriscv64 ?= "c926964d00caf714f42878535af8c7374452072d" -SRCREV_machine_qemux86 ?= "c926964d00caf714f42878535af8c7374452072d" -SRCREV_machine_qemux86-64 ?= "c926964d00caf714f42878535af8c7374452072d" -SRCREV_machine_qemumips64 ?= "217cada95bbe7eb4c3a6d40ee141ea4cea3bc1b6" -SRCREV_machine ?= "c926964d00caf714f42878535af8c7374452072d" +SRCREV_machine_qemuarm ?= "fdb7cd1bb5e4238e5b3d120ce9db31119ec2b5ee" +SRCREV_machine_qemuarm64 ?= "73b12de4c879e4569bef3b2d0ee9c783a9788b27" +SRCREV_machine_qemumips ?= "eb7faee13cfce200e9add4ba1852a3fe5d8b92e6" +SRCREV_machine_qemuppc ?= "73b12de4c879e4569bef3b2d0ee9c783a9788b27" +SRCREV_machine_qemuriscv64 ?= "73b12de4c879e4569bef3b2d0ee9c783a9788b27" +SRCREV_machine_qemux86 ?= "73b12de4c879e4569bef3b2d0ee9c783a9788b27" +SRCREV_machine_qemux86-64 ?= "73b12de4c879e4569bef3b2d0ee9c783a9788b27" +SRCREV_machine_qemumips64 ?= "8e3bfeb7e9b5aa92c5bea941d361ff5b081a2aaa" +SRCREV_machine ?= "73b12de4c879e4569bef3b2d0ee9c783a9788b27" SRCREV_meta ?= "bb2776d6beaae64b1a0fc902b64376f082085498" # remap qemuarm to qemuarma15 for the 5.2 kernel -- 2.17.1 From akuster808 at gmail.com Sun Mar 15 18:11:45 2020 From: akuster808 at gmail.com (Armin Kuster) Date: Sun, 15 Mar 2020 11:11:45 -0700 Subject: [OE-core] [zeus 03/16] cve-check: fail gracefully when file not found In-Reply-To: References: Message-ID: With out these changes, a traceback displayed when a file is listed in the SRC_URI but the file does not exist. raise FileNotFoundError and print the patch then mark the task as failed. Signed-off-by: Armin Kuster Signed-off-by: Ross Burton (cherry picked from commit d4926c11a4ab9148bdb640a9367c9e1891491a5b) Signed-off-by: Armin Kuster --- meta/classes/cve-check.bbclass | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass index 01b3637469..74124364b2 100644 --- a/meta/classes/cve-check.bbclass +++ b/meta/classes/cve-check.bbclass @@ -52,7 +52,10 @@ python do_cve_check () { """ if os.path.exists(d.getVar("CVE_CHECK_DB_FILE")): - patched_cves = get_patches_cves(d) + try: + patched_cves = get_patches_cves(d) + except FileNotFoundError: + bb.fatal("Failure in searching patches") patched, unpatched = check_cves(d, patched_cves) if patched or unpatched: cve_data = get_cve_info(d, patched + unpatched) @@ -129,6 +132,10 @@ def get_patches_cves(d): for url in src_patches(d): patch_file = bb.fetch.decodeurl(url)[2] + if not os.path.isfile(patch_file): + bb.error("File Not found: %s" % patch_file) + raise FileNotFoundError + # Check patch file name for CVE ID fname_match = cve_file_name_match.search(patch_file) if fname_match: -- 2.17.1 From akuster808 at gmail.com Sun Mar 15 18:11:46 2020 From: akuster808 at gmail.com (Armin Kuster) Date: Sun, 15 Mar 2020 11:11:46 -0700 Subject: [OE-core] [zeus 04/16] dummy-sdk-package: Add DUMMYPROVIDES_PACKAGES In-Reply-To: References: Message-ID: From: Richard Purdie We're about to need to use this variable in the main include file so restructure the users of it to all set it appropriately. Signed-off-by: Richard Purdie (cherry picked from commit 4a247e7c961286cbed73b6dc0f4074ecf856402a) Signed-off-by: Armin Kuster --- meta/recipes-core/meta/dummy-sdk-package.inc | 3 +++ meta/recipes-core/meta/nativesdk-buildtools-perl-dummy.bb | 5 ++++- meta/recipes-core/meta/nativesdk-sdk-provides-dummy.bb | 5 ++++- meta/recipes-core/meta/target-sdk-provides-dummy.bb | 1 - 4 files changed, 11 insertions(+), 3 deletions(-) diff --git a/meta/recipes-core/meta/dummy-sdk-package.inc b/meta/recipes-core/meta/dummy-sdk-package.inc index 4d653706b1..0d15a37c35 100644 --- a/meta/recipes-core/meta/dummy-sdk-package.inc +++ b/meta/recipes-core/meta/dummy-sdk-package.inc @@ -17,6 +17,9 @@ ALLOW_EMPTY_${PN} = "1" PR[vardeps] += "DUMMYPROVIDES" +DUMMYPROVIDES_PACKAGES ??= "" +DUMMYPROVIDES += "${@' '.join([multilib_pkg_extend(d, pkg) for pkg in d.getVar('DUMMYPROVIDES_PACKAGES').split()])}" + python populate_packages_prepend() { p = d.getVar("PN") d.appendVar("RPROVIDES_%s" % p, "${DUMMYPROVIDES}") diff --git a/meta/recipes-core/meta/nativesdk-buildtools-perl-dummy.bb b/meta/recipes-core/meta/nativesdk-buildtools-perl-dummy.bb index 6a8748acdf..5bc11b9daf 100644 --- a/meta/recipes-core/meta/nativesdk-buildtools-perl-dummy.bb +++ b/meta/recipes-core/meta/nativesdk-buildtools-perl-dummy.bb @@ -1,6 +1,6 @@ DUMMYARCH = "buildtools-dummy-${SDKPKGSUFFIX}" -DUMMYPROVIDES = "\ +DUMMYPROVIDES_PACKAGES = "\ nativesdk-perl \ nativesdk-libxml-parser-perl \ nativesdk-perl-module-bytes \ @@ -21,6 +21,9 @@ DUMMYPROVIDES = "\ nativesdk-perl-module-posix \ nativesdk-perl-module-thread-queue \ nativesdk-perl-module-threads \ +" + +DUMMYPROVIDES = "\ /usr/bin/perl \ " diff --git a/meta/recipes-core/meta/nativesdk-sdk-provides-dummy.bb b/meta/recipes-core/meta/nativesdk-sdk-provides-dummy.bb index b891efa5ef..29f4dd3633 100644 --- a/meta/recipes-core/meta/nativesdk-sdk-provides-dummy.bb +++ b/meta/recipes-core/meta/nativesdk-sdk-provides-dummy.bb @@ -1,10 +1,13 @@ DUMMYARCH = "sdk-provides-dummy-${SDKPKGSUFFIX}" +DUMMYPROVIDES_PACKAGES = "\ + pkgconfig \ +" + # Add /bin/sh? DUMMYPROVIDES = "\ /bin/bash \ /usr/bin/env \ - pkgconfig \ libGL.so()(64bit) \ libGL.so \ " diff --git a/meta/recipes-core/meta/target-sdk-provides-dummy.bb b/meta/recipes-core/meta/target-sdk-provides-dummy.bb index 87b8bfab9c..e3beeb796c 100644 --- a/meta/recipes-core/meta/target-sdk-provides-dummy.bb +++ b/meta/recipes-core/meta/target-sdk-provides-dummy.bb @@ -48,7 +48,6 @@ DUMMYPROVIDES_PACKAGES = "\ " DUMMYPROVIDES = "\ - ${@' '.join([multilib_pkg_extend(d, pkg) for pkg in d.getVar('DUMMYPROVIDES_PACKAGES').split()])} \ /bin/sh \ /bin/bash \ /usr/bin/env \ -- 2.17.1 From akuster808 at gmail.com Sun Mar 15 18:11:47 2020 From: akuster808 at gmail.com (Armin Kuster) Date: Sun, 15 Mar 2020 11:11:47 -0700 Subject: [OE-core] [zeus 05/16] wic/engine: lets display an error not a traceback In-Reply-To: References: Message-ID: <29a1d9bed5bf7ed024870a0323f9afdf88346e4d.1584295805.git.akuster808@gmail.com> If the requested partition does not exist in this request "wic ls {path}:pnum" display a nice message not a trackback Also fix displaying the pnum and not "%s" Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie (cherry picked from commit 15d1722950a22649905cf8a5789d3cfe48a2a892) Signed-off-by: Armin Kuster --- scripts/lib/wic/engine.py | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/scripts/lib/wic/engine.py b/scripts/lib/wic/engine.py index 18776fa8a0..4ccca482e7 100644 --- a/scripts/lib/wic/engine.py +++ b/scripts/lib/wic/engine.py @@ -290,7 +290,7 @@ class Disk: def _get_part_image(self, pnum): if pnum not in self.partitions: - raise WicError("Partition %s is not in the image") + raise WicError("Partition %s is not in the image" % pnum) part = self.partitions[pnum] # check if fstype is supported for fstype in self.fstypes: @@ -313,6 +313,9 @@ class Disk: seek=self.partitions[pnum].start) def dir(self, pnum, path): + if pnum not in self.partitions: + raise WicError("Partition %s is not in the image" % pnum) + if self.partitions[pnum].fstype.startswith('ext'): return exec_cmd("{} {} -R 'ls -l {}'".format(self.debugfs, self._get_part_image(pnum), -- 2.17.1 From akuster808 at gmail.com Sun Mar 15 18:11:48 2020 From: akuster808 at gmail.com (Armin Kuster) Date: Sun, 15 Mar 2020 11:11:48 -0700 Subject: [OE-core] [zeus 06/16] valgrind: Fix build with -fno-common In-Reply-To: References: Message-ID: <350496c3c0b80835cb5311aa6dbc91e4ee7b5935.1584295805.git.akuster808@gmail.com> From: Khem Raj Signed-off-by: Khem Raj Signed-off-by: Richard Purdie (cherry picked from commit 14f14eccf176539493fbfe710b66704feb7710da) Signed-off-by: Armin Kuster --- .../valgrind/valgrind/s390x_vec_op_t.patch | 19 +++++++++++++++++++ .../valgrind/valgrind_3.15.0.bb | 1 + 2 files changed, 20 insertions(+) create mode 100644 meta/recipes-devtools/valgrind/valgrind/s390x_vec_op_t.patch diff --git a/meta/recipes-devtools/valgrind/valgrind/s390x_vec_op_t.patch b/meta/recipes-devtools/valgrind/valgrind/s390x_vec_op_t.patch new file mode 100644 index 0000000000..eea671da0a --- /dev/null +++ b/meta/recipes-devtools/valgrind/valgrind/s390x_vec_op_t.patch @@ -0,0 +1,19 @@ +s390x_vec_op_t is not needed anywhere, only elements of enum are accessed +removing it ensures that valgrind can be built with -fno-common option + +Fixes +ld: ../../VEX/libvex-amd64-linux.a(libvex_amd64_linux_a-guest_s390_helpers.o):/usr/src/debug/valgrind/3.15.0-r0/build/VEX/../../valgrind-3.15.0/VEX/priv/guest_s390_defs.h:289: multiple definition of `s390x_vec_op_t'; ../../VEX/libvexmultiarch-amd64-linux.a(libvexmultiarch_amd64_linux_a-multiarch_main_main.o):/usr/src/debug/valgrind/3.15.0-r0/build/VEX/../../valgrind-3.15.0/VEX/priv/guest_s390_defs.h:289: first defined here + +Upstream-Status: Pending +Signed-off-by: Khem Raj +--- a/VEX/priv/guest_s390_defs.h ++++ b/VEX/priv/guest_s390_defs.h +@@ -286,7 +286,7 @@ enum { + S390_VEC_OP_VFCHE = 18, + S390_VEC_OP_VFTCI = 19, + S390_VEC_OP_LAST = 20 // supposed to be the last element in enum +-} s390x_vec_op_t; ++}; + + /* Arguments of s390x_dirtyhelper_vec_op(...) which are packed into one + ULong variable. diff --git a/meta/recipes-devtools/valgrind/valgrind_3.15.0.bb b/meta/recipes-devtools/valgrind/valgrind_3.15.0.bb index 63f972945d..aedaab27b3 100644 --- a/meta/recipes-devtools/valgrind/valgrind_3.15.0.bb +++ b/meta/recipes-devtools/valgrind/valgrind_3.15.0.bb @@ -40,6 +40,7 @@ SRC_URI = "https://sourceware.org/pub/valgrind/valgrind-${PV}.tar.bz2 \ file://0001-valgrind-filter_xml_frames-do-not-filter-usr.patch \ file://0002-valgrind-adjust-std_list-expected-output.patch \ file://0001-adjust-path-filter-for-2-memcheck-tests.patch \ + file://s390x_vec_op_t.patch \ " SRC_URI[md5sum] = "46e5fbdcbc3502a5976a317a0860a975" SRC_URI[sha256sum] = "417c7a9da8f60dd05698b3a7bc6002e4ef996f14c13f0ff96679a16873e78ab1" -- 2.17.1 From akuster808 at gmail.com Sun Mar 15 18:11:49 2020 From: akuster808 at gmail.com (Armin Kuster) Date: Sun, 15 Mar 2020 11:11:49 -0700 Subject: [OE-core] [zeus 07/16] gcc-cross-canadian: A missing space in an append caused an invalid option In-Reply-To: References: Message-ID: From: Mark Hatle When configuring the cross-candian toolchain for a non-linux target system, the resulting gcc configuration included: --enable-initfini-array--without-headers these should have been two separate options. Signed-off-by: Mark Hatle Signed-off-by: Richard Purdie (cherry picked from commit 7b52893632dae7bc9ac75dddc7ad625e19f41050) Signed-off-by: Armin Kuster --- meta/recipes-devtools/gcc/gcc-cross-canadian.inc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/recipes-devtools/gcc/gcc-cross-canadian.inc b/meta/recipes-devtools/gcc/gcc-cross-canadian.inc index f14cbf7152..4aac345bec 100644 --- a/meta/recipes-devtools/gcc/gcc-cross-canadian.inc +++ b/meta/recipes-devtools/gcc/gcc-cross-canadian.inc @@ -158,7 +158,7 @@ SYSTEMLIBS1 = "${target_libdir}/" EXTRA_OECONF += "--enable-poison-system-directories" EXTRA_OECONF_remove_elf = "--with-sysroot=/not/exist" EXTRA_OECONF_remove_eabi = "--with-sysroot=/not/exist" -EXTRA_OECONF_append_elf = "--without-headers --with-newlib" -EXTRA_OECONF_append_eabi = "--without-headers --with-newlib" +EXTRA_OECONF_append_elf = " --without-headers --with-newlib" +EXTRA_OECONF_append_eabi = " --without-headers --with-newlib" # gcc 4.7 needs -isystem export ARCH_FLAGS_FOR_TARGET = "--sysroot=${STAGING_DIR_TARGET} -isystem=${target_includedir}" -- 2.17.1 From akuster808 at gmail.com Sun Mar 15 18:11:50 2020 From: akuster808 at gmail.com (Armin Kuster) Date: Sun, 15 Mar 2020 11:11:50 -0700 Subject: [OE-core] [zeus 08/16] gcc-cross.inc: Prevent native sysroot from leaking into configargs.h In-Reply-To: References: Message-ID: <102fe8f850f97c7a588ee342846b4c10b8603b0d.1584295805.git.akuster808@gmail.com> From: Nathan Rossi Prevent the native(sdk) sysroot path from leaking into configargs.h. The configargs.h header is intended to be static and unchanged as the content is used as a means of determining that a gcc plugin is built for the same gcc. This also effects the output of 'gcc --version'. Due to per recipe sysroots and staging, the sysroot path would be replaced with the sysroot local to the recipe thus changing the content of configargs.h. The sysroot path is replaced with a generic "/host" prefix which represents the host sysroot (e.g. native or nativesdk). Signed-off-by: Nathan Rossi Signed-off-by: Ross Burton (cherry picked from commit 84a78f46d59447eeec3d69532a7506148f64c979) Signed-off-by: Armin Kuster --- meta/recipes-devtools/gcc/gcc-cross.inc | 7 +++++++ meta/recipes-devtools/gcc/gcc-runtime.inc | 4 ---- 2 files changed, 7 insertions(+), 4 deletions(-) diff --git a/meta/recipes-devtools/gcc/gcc-cross.inc b/meta/recipes-devtools/gcc/gcc-cross.inc index 8855bb1f34..06ba3ccd15 100644 --- a/meta/recipes-devtools/gcc/gcc-cross.inc +++ b/meta/recipes-devtools/gcc/gcc-cross.inc @@ -61,6 +61,13 @@ do_compile () { export CXXFLAGS_FOR_TARGET="${TARGET_CXXFLAGS}" export LDFLAGS_FOR_TARGET="${TARGET_LDFLAGS}" + # Prevent native/host sysroot path from being used in configargs.h header, + # as it will be rewritten when used by other sysroots preventing support + # for gcc plugins + oe_runmake configure-gcc + sed -i 's@${STAGING_DIR_TARGET}@/host at g' ${B}/gcc/configargs.h + sed -i 's@${STAGING_DIR_HOST}@/host at g' ${B}/gcc/configargs.h + oe_runmake all-host configure-target-libgcc (cd ${B}/${TARGET_SYS}/libgcc; oe_runmake enable-execute-stack.c unwind.h md-unwind-support.h sfp-machine.h gthr-default.h) # now generate script to drive testing diff --git a/meta/recipes-devtools/gcc/gcc-runtime.inc b/meta/recipes-devtools/gcc/gcc-runtime.inc index 2da3c02ef0..536b18d97f 100644 --- a/meta/recipes-devtools/gcc/gcc-runtime.inc +++ b/meta/recipes-devtools/gcc/gcc-runtime.inc @@ -302,10 +302,6 @@ do_check() { # HACK: this works around the configure setting CXX with -nostd* args sed -i 's/-nostdinc++ -nostdlib++//g' $(find ${B} -name testsuite_flags | head -1) - # HACK: this works around the de-stashing changes to configargs.h, as well as recipe-sysroot changing the content - sed -i '/static const char configuration_arguments/d' ${B}/gcc/configargs.h - ${CC} -v 2>&1 | grep "^Configured with:" | \ - sed 's/Configured with: \(.*\)/static const char configuration_arguments[] = "\1";/g' >> ${B}/gcc/configargs.h if [ "${TOOLCHAIN_TEST_TARGET}" = "user" ]; then # qemu user has issues allocating large amounts of memory -- 2.17.1 From akuster808 at gmail.com Sun Mar 15 18:11:51 2020 From: akuster808 at gmail.com (Armin Kuster) Date: Sun, 15 Mar 2020 11:11:51 -0700 Subject: [OE-core] [zeus 09/16] gcc-target.inc: Prevent sysroot from leaking into configargs.h In-Reply-To: References: Message-ID: <2f4428d8a7af49b7f251e863b7d4f21301ed1c43.1584295805.git.akuster808@gmail.com> From: Nathan Rossi Prevent the full recipe-sysroot path from leaking into configargs.h. The configargs.h header is intended to be static and unchanged as the content is used as a means of determining that a gcc plugin is built for the same gcc. This also effects the output of 'gcc -v'. Due to per recipe sysroots and staging, the sysroot path would be replaced with the sysroot local to the recipe thus changing the content of configargs.h. This change also improves gcc binary reproducibility. The sysroot path is replaced with the base target root "/". Signed-off-by: Nathan Rossi Signed-off-by: Richard Purdie (cherry picked from commit b8d6e2ab68ee5e341fe970b191bfd334e6d2c40b) Signed-off-by: Armin Kuster --- meta/recipes-devtools/gcc/gcc-target.inc | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/meta/recipes-devtools/gcc/gcc-target.inc b/meta/recipes-devtools/gcc/gcc-target.inc index bdc6ff658f..987e88d32c 100644 --- a/meta/recipes-devtools/gcc/gcc-target.inc +++ b/meta/recipes-devtools/gcc/gcc-target.inc @@ -137,6 +137,14 @@ FILES_${PN}-doc = "\ " do_compile () { + # Prevent full target sysroot path from being used in configargs.h header, + # as it will be rewritten when used by other sysroots preventing support + # for gcc plugins. Additionally the path is embeddeded into the output + # binary, this prevents building a reproducible binary. + oe_runmake configure-gcc + sed -i 's@${STAGING_DIR_TARGET}@/@g' ${B}/gcc/configargs.h + sed -i 's@${STAGING_DIR_HOST}@/@g' ${B}/gcc/configargs.h + oe_runmake all-host } -- 2.17.1 From akuster808 at gmail.com Sun Mar 15 18:11:52 2020 From: akuster808 at gmail.com (Armin Kuster) Date: Sun, 15 Mar 2020 11:11:52 -0700 Subject: [OE-core] [zeus 10/16] ruby: fix CVE-2019-16254 In-Reply-To: References: Message-ID: From: Rahul Chauhan Signed-off-by: Rahul Chauhan Signed-off-by: Anuj Mittal --- .../ruby/ruby/fix-CVE-2019-16254.patch | 106 ++++++++++++++++++ meta/recipes-devtools/ruby/ruby_2.5.5.bb | 1 + 2 files changed, 107 insertions(+) create mode 100644 meta/recipes-devtools/ruby/ruby/fix-CVE-2019-16254.patch diff --git a/meta/recipes-devtools/ruby/ruby/fix-CVE-2019-16254.patch b/meta/recipes-devtools/ruby/ruby/fix-CVE-2019-16254.patch new file mode 100644 index 0000000000..704c850c50 --- /dev/null +++ b/meta/recipes-devtools/ruby/ruby/fix-CVE-2019-16254.patch @@ -0,0 +1,106 @@ +From 18d5289b4579822e391b3f5c16541e6552e9f06c Mon Sep 17 00:00:00 2001 +From: Yusuke Endoh +Date: Tue, 1 Oct 2019 12:29:18 +0900 +Subject: [PATCH] WEBrick: prevent response splitting and header injection + +This is a follow up to d9d4a28f1cdd05a0e8dabb36d747d40bbcc30f16. +The commit prevented CRLR, but did not address an isolated CR or an +isolated LF. + +Upstream-Status: Backport https://github.com/ruby/ruby/commit/3ce238b5f9795581eb84114dcfbdf4aa086bfecc +CVE: CVE-2019-16254 + +Co-Authored-By: NARUSE, Yui +Signed-off-by: Rahul Chauhan +--- + lib/webrick/httpresponse.rb | 3 ++- + test/webrick/test_httpresponse.rb | 46 +++++++++++++++++++++++++++++++++++++-- + 2 files changed, 46 insertions(+), 3 deletions(-) + +diff --git a/lib/webrick/httpresponse.rb b/lib/webrick/httpresponse.rb +index 6d77692..d26324c 100644 +--- a/lib/webrick/httpresponse.rb ++++ b/lib/webrick/httpresponse.rb +@@ -367,7 +367,8 @@ def set_error(ex, backtrace=false) + private + + def check_header(header_value) +- if header_value =~ /\r\n/ ++ header_value = header_value.to_s ++ if /[\r\n]/ =~ header_value + raise InvalidHeader + else + header_value +diff --git a/test/webrick/test_httpresponse.rb b/test/webrick/test_httpresponse.rb +index 6263e0a..24a6968 100644 +--- a/test/webrick/test_httpresponse.rb ++++ b/test/webrick/test_httpresponse.rb +@@ -29,7 +29,7 @@ def setup + @res.keep_alive = true + end + +- def test_prevent_response_splitting_headers ++ def test_prevent_response_splitting_headers_crlf + res['X-header'] = "malicious\r\nCookie: hack" + io = StringIO.new + res.send_response io +@@ -39,7 +39,7 @@ def test_prevent_response_splitting_headers + refute_match 'hack', io.string + end + +- def test_prevent_response_splitting_cookie_headers ++ def test_prevent_response_splitting_cookie_headers_crlf + user_input = "malicious\r\nCookie: hack" + res.cookies << WEBrick::Cookie.new('author', user_input) + io = StringIO.new +@@ -50,6 +50,48 @@ def test_prevent_response_splitting_cookie_headers + refute_match 'hack', io.string + end + ++ def test_prevent_response_splitting_headers_cr ++ res['X-header'] = "malicious\rCookie: hack" ++ io = StringIO.new ++ res.send_response io ++ io.rewind ++ res = Net::HTTPResponse.read_new(Net::BufferedIO.new(io)) ++ assert_equal '500', res.code ++ refute_match 'hack', io.string ++ end ++ ++ def test_prevent_response_splitting_cookie_headers_cr ++ user_input = "malicious\rCookie: hack" ++ res.cookies << WEBrick::Cookie.new('author', user_input) ++ io = StringIO.new ++ res.send_response io ++ io.rewind ++ res = Net::HTTPResponse.read_new(Net::BufferedIO.new(io)) ++ assert_equal '500', res.code ++ refute_match 'hack', io.string ++ end ++ ++ def test_prevent_response_splitting_headers_lf ++ res['X-header'] = "malicious\nCookie: hack" ++ io = StringIO.new ++ res.send_response io ++ io.rewind ++ res = Net::HTTPResponse.read_new(Net::BufferedIO.new(io)) ++ assert_equal '500', res.code ++ refute_match 'hack', io.string ++ end ++ ++ def test_prevent_response_splitting_cookie_headers_lf ++ user_input = "malicious\nCookie: hack" ++ res.cookies << WEBrick::Cookie.new('author', user_input) ++ io = StringIO.new ++ res.send_response io ++ io.rewind ++ res = Net::HTTPResponse.read_new(Net::BufferedIO.new(io)) ++ assert_equal '500', res.code ++ refute_match 'hack', io.string ++ end ++ + def test_304_does_not_log_warning + res.status = 304 + res.setup_header +-- +2.7.4 diff --git a/meta/recipes-devtools/ruby/ruby_2.5.5.bb b/meta/recipes-devtools/ruby/ruby_2.5.5.bb index 223b0371eb..58bb97f4bd 100644 --- a/meta/recipes-devtools/ruby/ruby_2.5.5.bb +++ b/meta/recipes-devtools/ruby/ruby_2.5.5.bb @@ -3,6 +3,7 @@ require ruby.inc SRC_URI += " \ file://0001-configure.ac-check-finite-isinf-isnan-as-macros-firs.patch \ file://run-ptest \ + file://fix-CVE-2019-16254.patch \ " SRC_URI[md5sum] = "7e156fb526b8f4bb1b30a3dd8a7ce400" -- 2.17.1 From akuster808 at gmail.com Sun Mar 15 18:11:53 2020 From: akuster808 at gmail.com (Armin Kuster) Date: Sun, 15 Mar 2020 11:11:53 -0700 Subject: [OE-core] [zeus 11/16] dhcp: Fix REQUIRE(ctx->running) assertion triggered on SIGTERM/SIGINT In-Reply-To: References: Message-ID: <62fffe05ff3fd69ed7bb4d23748035b74445dcf6.1584295805.git.akuster808@gmail.com> From: Ovidiu Panait Closed a small window of time between the installation of graceful shutdown signal handlers and application context startup, during which the receipt of shutdown signal would cause a REQUIRE() assertion to occur. Note this issue is only visible when compiling with ENABLE_GENTLE_SHUTDOWN defined. Reference: https://gitlab.isc.org/isc-projects/dhcp/issues/53 Upstream patches: https://gitlab.isc.org/isc-projects/dhcp/commit/ce117de7a1ed3c4911b4009c1cc23fba85370a26 https://gitlab.isc.org/isc-projects/dhcp/commit/dbd36dfa82956b53683462afadfabb1b33fa3dd1 https://gitlab.isc.org/isc-projects/dhcp/commit/95944cab6035d20be270eec01254c7bb867ec705 Signed-off-by: Ovidiu Panait Signed-off-by: Anuj Mittal --- ...s-running-prior-to-calling-isc_app_c.patch | 165 ++++++++++++++++++ ...ed-shutdown-log-statment-to-dhcrelay.patch | 29 +++ .../dhcp/0003-Addressed-review-comment.patch | 31 ++++ meta/recipes-connectivity/dhcp/dhcp_4.4.1.bb | 3 + 4 files changed, 228 insertions(+) create mode 100644 meta/recipes-connectivity/dhcp/dhcp/0001-Ensure-context-is-running-prior-to-calling-isc_app_c.patch create mode 100644 meta/recipes-connectivity/dhcp/dhcp/0002-Added-shutdown-log-statment-to-dhcrelay.patch create mode 100644 meta/recipes-connectivity/dhcp/dhcp/0003-Addressed-review-comment.patch diff --git a/meta/recipes-connectivity/dhcp/dhcp/0001-Ensure-context-is-running-prior-to-calling-isc_app_c.patch b/meta/recipes-connectivity/dhcp/dhcp/0001-Ensure-context-is-running-prior-to-calling-isc_app_c.patch new file mode 100644 index 0000000000..34b2ae1e5c --- /dev/null +++ b/meta/recipes-connectivity/dhcp/dhcp/0001-Ensure-context-is-running-prior-to-calling-isc_app_c.patch @@ -0,0 +1,165 @@ +From f369dbb9e67eb5ef336944af63039b6d8f838384 Mon Sep 17 00:00:00 2001 +From: Thomas Markwalder +Date: Thu, 12 Sep 2019 10:35:46 -0400 +Subject: [PATCH 1/3] Ensure context is running prior to calling + isc_app_ctxsuspend + +Add a release note. + +includes/omapip/isclib.h + Added actx_running flag to global context, dhcp_gbl_ctx + +omapip/isclib.c + set_ctx_running() - new function used as the ctxonrun callback + + dhcp_context_create() - installs set_ctx_running callback + + dhcp_signal_handler() - modified to use act_running flag to + determine is context is running and should be suspended + +Upstream-Status: Backport [https://gitlab.isc.org/isc-projects/dhcp.git] + +Signed-off-by: Ovidiu Panait +--- + RELNOTES | 7 +++++ + includes/omapip/isclib.h | 3 ++- + omapip/isclib.c | 57 +++++++++++++++++++++++++++++++++------- + 3 files changed, 57 insertions(+), 10 deletions(-) + +diff --git a/RELNOTES b/RELNOTES +index f10305d..1730473 100644 +--- a/RELNOTES ++++ b/RELNOTES +@@ -6,6 +6,13 @@ + + NEW FEATURES + ++- Closed a small window of time between the installation of graceful ++ shutdown signal handlers and application context startup, during which ++ the receipt of shutdown signal would cause a REQUIRE() assertion to ++ occur. Note this issue is only visible when compiling with ++ ENABLE_GENTLE_SHUTDOWN defined. ++ [Gitlab #53,!18 git TBD] ++ + Please note that that ISC DHCP is now licensed under the Mozilla Public License, + MPL 2.0. Please see https://www.mozilla.org/en-US/MPL/2.0/ to read the MPL 2.0 + license terms. +diff --git a/includes/omapip/isclib.h b/includes/omapip/isclib.h +index 6c20584..af6a6fc 100644 +--- a/includes/omapip/isclib.h ++++ b/includes/omapip/isclib.h +@@ -94,7 +94,8 @@ + typedef struct dhcp_context { + isc_mem_t *mctx; + isc_appctx_t *actx; +- int actx_started; ++ int actx_started; // ISC_TRUE if ctxstart has been called ++ int actx_running; // ISC_TRUE if ctxrun has been called + isc_taskmgr_t *taskmgr; + isc_task_t *task; + isc_socketmgr_t *socketmgr; +diff --git a/omapip/isclib.c b/omapip/isclib.c +index ce4b4a1..73e017c 100644 +--- a/omapip/isclib.c ++++ b/omapip/isclib.c +@@ -134,6 +134,35 @@ handle_signal(int sig, void (*handler)(int)) { + } + } + ++/* Callback passed to isc_app_ctxonrun ++ * ++ * BIND9 context code will invoke this handler once the context has ++ * entered the running state. We use it to set a global marker so that ++ * we can tell if the context is running. Several of the isc_app_ ++ * calls REQUIRE that the context is running and we need a way to ++ * know that. ++ * ++ * We also check to see if we received a shutdown signal prior to ++ * the context entering the run state. If we did, then we can just ++ * simply shut the context down now. This closes the relatively ++ * small window between start up and entering run via the call ++ * to dispatch(). ++ * ++ */ ++static void ++set_ctx_running(isc_task_t *task, isc_event_t *event) { ++ task = task; // unused; ++ dhcp_gbl_ctx.actx_running = ISC_TRUE; ++ ++ if (shutdown_signal) { ++ // We got signaled shutdown before we entered running state. ++ // Now that we've reached running state, shut'er down. ++ isc_app_ctxsuspend(dhcp_gbl_ctx.actx); ++ } ++ ++ isc_event_free(&event); ++} ++ + isc_result_t + dhcp_context_create(int flags, + struct in_addr *local4, +@@ -141,6 +170,9 @@ dhcp_context_create(int flags, + isc_result_t result; + + if ((flags & DHCP_CONTEXT_PRE_DB) != 0) { ++ dhcp_gbl_ctx.actx_started = ISC_FALSE; ++ dhcp_gbl_ctx.actx_running = ISC_FALSE; ++ + /* + * Set up the error messages, this isn't the right place + * for this call but it is convienent for now. +@@ -204,15 +236,24 @@ dhcp_context_create(int flags, + if (result != ISC_R_SUCCESS) + goto cleanup; + +- result = isc_task_create(dhcp_gbl_ctx.taskmgr, 0, &dhcp_gbl_ctx.task); ++ result = isc_task_create(dhcp_gbl_ctx.taskmgr, 0, ++ &dhcp_gbl_ctx.task); + if (result != ISC_R_SUCCESS) + goto cleanup; + + result = isc_app_ctxstart(dhcp_gbl_ctx.actx); + if (result != ISC_R_SUCCESS) +- return (result); ++ goto cleanup; ++ + dhcp_gbl_ctx.actx_started = ISC_TRUE; + ++ // Install the onrun callback. ++ result = isc_app_ctxonrun(dhcp_gbl_ctx.actx, dhcp_gbl_ctx.mctx, ++ dhcp_gbl_ctx.task, set_ctx_running, ++ dhcp_gbl_ctx.actx); ++ if (result != ISC_R_SUCCESS) ++ goto cleanup; ++ + /* Not all OSs support suppressing SIGPIPE through socket + * options, so set the sigal action to be ignore. This allows + * broken connections to fail gracefully with EPIPE on writes */ +@@ -335,19 +376,17 @@ isclib_make_dst_key(char *inname, + * @param signal signal code that we received + */ + void dhcp_signal_handler(int signal) { +- isc_appctx_t *ctx = dhcp_gbl_ctx.actx; +- int prev = shutdown_signal; +- +- if (prev != 0) { ++ if (shutdown_signal != 0) { + /* Already in shutdown. */ + return; + } ++ + /* Possible race but does it matter? */ + shutdown_signal = signal; + +- /* Use reload (aka suspend) for easier dispatch() reenter. */ +- if (ctx && ctx->methods && ctx->methods->ctxsuspend) { +- (void) isc_app_ctxsuspend(ctx); ++ /* If the application context is running tell it to shut down */ ++ if (dhcp_gbl_ctx.actx_running == ISC_TRUE) { ++ (void) isc_app_ctxsuspend(dhcp_gbl_ctx.actx); + } + } + +-- +2.23.0 + diff --git a/meta/recipes-connectivity/dhcp/dhcp/0002-Added-shutdown-log-statment-to-dhcrelay.patch b/meta/recipes-connectivity/dhcp/dhcp/0002-Added-shutdown-log-statment-to-dhcrelay.patch new file mode 100644 index 0000000000..78b2b74f45 --- /dev/null +++ b/meta/recipes-connectivity/dhcp/dhcp/0002-Added-shutdown-log-statment-to-dhcrelay.patch @@ -0,0 +1,29 @@ +From adcd34ae1f56b16d7e9696d980332b4cf6c7ce91 Mon Sep 17 00:00:00 2001 +From: Thomas Markwalder +Date: Fri, 13 Sep 2019 15:03:31 -0400 +Subject: [PATCH 2/3] Added shutdown log statment to dhcrelay + +Upstream-Status: Backport [https://gitlab.isc.org/isc-projects/dhcp.git] + +Signed-off-by: Ovidiu Panait +--- + relay/dhcrelay.c | 3 +++ + 1 file changed, 3 insertions(+) + +diff --git a/relay/dhcrelay.c b/relay/dhcrelay.c +index d8caaaf..4bd1d47 100644 +--- a/relay/dhcrelay.c ++++ b/relay/dhcrelay.c +@@ -2076,6 +2076,9 @@ dhcp_set_control_state(control_object_state_t oldstate, + if (newstate != server_shutdown) + return ISC_R_SUCCESS; + ++ /* Log shutdown on signal. */ ++ log_info("Received signal %d, initiating shutdown.", shutdown_signal); ++ + if (no_pid_file == ISC_FALSE) + (void) unlink(path_dhcrelay_pid); + +-- +2.23.0 + diff --git a/meta/recipes-connectivity/dhcp/dhcp/0003-Addressed-review-comment.patch b/meta/recipes-connectivity/dhcp/dhcp/0003-Addressed-review-comment.patch new file mode 100644 index 0000000000..a51b6cf526 --- /dev/null +++ b/meta/recipes-connectivity/dhcp/dhcp/0003-Addressed-review-comment.patch @@ -0,0 +1,31 @@ +From e4b54b4d676783152d487103714cba2913661ef8 Mon Sep 17 00:00:00 2001 +From: Thomas Markwalder +Date: Wed, 6 Nov 2019 15:53:50 -0500 +Subject: [PATCH 3/3] Addressed review comment. + +omapip/isclib.c + Added use of IGNORE_UNUSED() + +Upstream-Status: Backport [https://gitlab.isc.org/isc-projects/dhcp.git] + +Signed-off-by: Ovidiu Panait +--- + omapip/isclib.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/omapip/isclib.c b/omapip/isclib.c +index 73e017c..1d52463 100644 +--- a/omapip/isclib.c ++++ b/omapip/isclib.c +@@ -151,7 +151,7 @@ handle_signal(int sig, void (*handler)(int)) { + */ + static void + set_ctx_running(isc_task_t *task, isc_event_t *event) { +- task = task; // unused; ++ IGNORE_UNUSED(task); + dhcp_gbl_ctx.actx_running = ISC_TRUE; + + if (shutdown_signal) { +-- +2.23.0 + diff --git a/meta/recipes-connectivity/dhcp/dhcp_4.4.1.bb b/meta/recipes-connectivity/dhcp/dhcp_4.4.1.bb index 275961a603..ddc8b60254 100644 --- a/meta/recipes-connectivity/dhcp/dhcp_4.4.1.bb +++ b/meta/recipes-connectivity/dhcp/dhcp_4.4.1.bb @@ -11,6 +11,9 @@ SRC_URI += "file://0001-define-macro-_PATH_DHCPD_CONF-and-_PATH_DHCLIENT_CON.pat file://0013-fixup_use_libbind.patch \ file://0001-master-Added-includes-of-new-BIND9-compatibility-hea.patch \ file://0001-Fix-a-NSUPDATE-compiling-issue.patch \ + file://0001-Ensure-context-is-running-prior-to-calling-isc_app_c.patch \ + file://0002-Added-shutdown-log-statment-to-dhcrelay.patch \ + file://0003-Addressed-review-comment.patch \ " SRC_URI[md5sum] = "18c7f4dcbb0a63df25098216d47b1ede" -- 2.17.1 From akuster808 at gmail.com Sun Mar 15 18:11:54 2020 From: akuster808 at gmail.com (Armin Kuster) Date: Sun, 15 Mar 2020 11:11:54 -0700 Subject: [OE-core] [zeus 12/16] virglrenderer: fix multiple CVEs In-Reply-To: References: Message-ID: <27ebe3b9c6954ee3be12f328f9cec58620930d02.1584295805.git.akuster808@gmail.com> From: Lee Chee Yang fix these CVE: CVE-2019-18390 CVE-2019-18391 CVE-2020-8002 Signed-off-by: Lee Chee Yang Signed-off-by: Anuj Mittal --- .../virglrenderer/CVE-2019-18390.patch | 66 +++++++++++++++++++ .../virglrenderer/CVE-2019-18391.patch | 51 ++++++++++++++ .../virglrenderer/CVE-2020-8002.patch | 39 +++++++++++ .../virglrenderer/virglrenderer_0.8.0.bb | 3 + 4 files changed, 159 insertions(+) create mode 100644 meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2019-18390.patch create mode 100644 meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2019-18391.patch create mode 100644 meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2020-8002.patch diff --git a/meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2019-18390.patch b/meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2019-18390.patch new file mode 100644 index 0000000000..ad61c95be3 --- /dev/null +++ b/meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2019-18390.patch @@ -0,0 +1,66 @@ +From 24f67de7a9088a873844a39be03cee6882260ac9 Mon Sep 17 00:00:00 2001 +From: Gert Wollny +Date: Mon, 7 Oct 2019 10:59:56 +0200 +Subject: [PATCH] vrend: check info formats in blits + +Closes #141 +Closes #142 + +v2 : drop colon in error description (Emil) + +Signed-off-by: Gert Wollny +Reviewed-by: Emil Velikov + +Upstream-Status: Backport +[https://gitlab.freedesktop.org/virgl/virglrenderer/commit/24f67de7a9088a873844a39be03cee6882260ac9] +CVE: CVE-2019-18390 +Signed-off-by: Lee Chee Yang +--- + src/virgl_hw.h | 1 + + src/vrend_renderer.c | 11 +++++++++++ + 2 files changed, 12 insertions(+) + +diff --git a/src/virgl_hw.h b/src/virgl_hw.h +index 145780bf..5ccf3073 100644 +--- a/src/virgl_hw.h ++++ b/src/virgl_hw.h +@@ -426,6 +426,7 @@ enum virgl_ctx_errors { + VIRGL_ERROR_CTX_ILLEGAL_CMD_BUFFER, + VIRGL_ERROR_CTX_GLES_HAVE_TES_BUT_MISS_TCS, + VIRGL_ERROR_GL_ANY_SAMPLES_PASSED, ++ VIRGL_ERROR_CTX_ILLEGAL_FORMAT, + }; + + #define VIRGL_RESOURCE_Y_0_TOP (1 << 0) +diff --git a/src/vrend_renderer.c b/src/vrend_renderer.c +index 14fefb38..aa6a89c1 100644 +--- a/src/vrend_renderer.c ++++ b/src/vrend_renderer.c +@@ -758,6 +758,7 @@ static const char *vrend_ctx_error_strings[] = { + [VIRGL_ERROR_CTX_ILLEGAL_CMD_BUFFER] = "Illegal command buffer", + [VIRGL_ERROR_CTX_GLES_HAVE_TES_BUT_MISS_TCS] = "On GLES context and shader program has tesselation evaluation shader but no tesselation control shader", + [VIRGL_ERROR_GL_ANY_SAMPLES_PASSED] = "Query for ANY_SAMPLES_PASSED not supported", ++ [VIRGL_ERROR_CTX_ILLEGAL_FORMAT] = "Illegal format ID", + }; + + static void __report_context_error(const char *fname, struct vrend_context *ctx, +@@ -8492,6 +8493,16 @@ void vrend_renderer_blit(struct vrend_context *ctx, + if (ctx->in_error) + return; + ++ if (!info->src.format || (enum virgl_formats)info->src.format >= VIRGL_FORMAT_MAX) { ++ report_context_error(ctx, VIRGL_ERROR_CTX_ILLEGAL_FORMAT, info->src.format); ++ return; ++ } ++ ++ if (!info->dst.format || (enum virgl_formats)info->dst.format >= VIRGL_FORMAT_MAX) { ++ report_context_error(ctx, VIRGL_ERROR_CTX_ILLEGAL_FORMAT, info->dst.format); ++ return; ++ } ++ + if (info->render_condition_enable == false) + vrend_pause_render_condition(ctx, true); + +-- +2.24.1 + diff --git a/meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2019-18391.patch b/meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2019-18391.patch new file mode 100644 index 0000000000..cc641d8293 --- /dev/null +++ b/meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2019-18391.patch @@ -0,0 +1,51 @@ +From 2abeb1802e3c005b17a7123e382171b3fb665971 Mon Sep 17 00:00:00 2001 +From: Gert Wollny +Date: Tue, 8 Oct 2019 17:27:01 +0200 +Subject: [PATCH] vrend: check that the transfer iov holds enough data for the + data upload + +Closes #140 + +Signed-off-by: Gert Wollny +Reviewed-by: Emil Velikov + +Upstream-Status: Backport +[https://gitlab.freedesktop.org/virgl/virglrenderer/commit/2abeb1802e3c005b17a7123e382171b3fb665971] +CVE: CVE-2019-18391 +Signed-off-by: Lee Chee Yang +--- + src/vrend_renderer.c | 11 +++++++++-- + 1 file changed, 9 insertions(+), 2 deletions(-) + +diff --git a/src/vrend_renderer.c b/src/vrend_renderer.c +index 694e1d0e..fe23846b 100644 +--- a/src/vrend_renderer.c ++++ b/src/vrend_renderer.c +@@ -7005,15 +7005,22 @@ static int vrend_renderer_transfer_write_iov(struct vrend_context *ctx, + invert = true; + } + ++ send_size = util_format_get_nblocks(res->base.format, info->box->width, ++ info->box->height) * elsize; ++ if (res->target == GL_TEXTURE_3D || ++ res->target == GL_TEXTURE_2D_ARRAY || ++ res->target == GL_TEXTURE_CUBE_MAP_ARRAY) ++ send_size *= info->box->depth; ++ + if (need_temp) { +- send_size = util_format_get_nblocks(res->base.format, info->box->width, +- info->box->height) * elsize * info->box->depth; + data = malloc(send_size); + if (!data) + return ENOMEM; + read_transfer_data(iov, num_iovs, data, res->base.format, info->offset, + stride, layer_stride, info->box, invert); + } else { ++ if (send_size > iov[0].iov_len - info->offset) ++ return EINVAL; + data = (char*)iov[0].iov_base + info->offset; + } + +-- +2.24.1 + diff --git a/meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2020-8002.patch b/meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2020-8002.patch new file mode 100644 index 0000000000..925f2c8eb0 --- /dev/null +++ b/meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2020-8002.patch @@ -0,0 +1,39 @@ +From 63bcca251f093d83da7e290ab4bbd38ae69089b5 Mon Sep 17 00:00:00 2001 +From: Gert Wollny +Date: Wed, 15 Jan 2020 13:43:58 +0100 +Subject: [PATCH] vrend: Don't try launching a grid if no CS is available + +Closes #155 + +Signed-off-by: Gert Wollny +Reviewed-by: Gurchetan Singh + +Upstream-Status: Backport +[https://gitlab.freedesktop.org/virgl/virglrenderer/-/commit/63bcca251f093d83da7e290ab4bbd38ae69089b5.patch] +CVE: CVE-2020-8002 +Signed-off-by: Lee Chee Yang +--- + src/vrend_renderer.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +diff --git a/src/vrend_renderer.c b/src/vrend_renderer.c +index a054bad8..2280fc43 100644 +--- a/src/vrend_renderer.c ++++ b/src/vrend_renderer.c +@@ -4604,6 +4604,13 @@ void vrend_launch_grid(struct vrend_context *ctx, + } + ctx->sub->shader_dirty = true; + } ++ ++ if (!ctx->sub->prog) { ++ vrend_printf("%s: Skipping compute shader execution due to missing shaders: %s\n", ++ __func__, ctx->debug_name); ++ return; ++ } ++ + vrend_use_program(ctx, ctx->sub->prog->id); + + vrend_draw_bind_ubo_shader(ctx, PIPE_SHADER_COMPUTE, 0); +-- +2.24.1 + diff --git a/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.0.bb b/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.0.bb index d2b11c103a..e91ccc6c57 100644 --- a/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.0.bb +++ b/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.0.bb @@ -8,6 +8,9 @@ DEPENDS = "libdrm mesa libepoxy" SRCREV = "48cc96c9aebb9d0164830a157efc8916f08f00c0" SRC_URI = "git://anongit.freedesktop.org/virglrenderer \ file://0001-gallium-Expand-libc-check-to-be-platform-OS-check.patch \ + file://CVE-2019-18390.patch \ + file://CVE-2019-18391.patch \ + file://CVE-2020-8002.patch \ " S = "${WORKDIR}/git" -- 2.17.1 From akuster808 at gmail.com Sun Mar 15 18:11:55 2020 From: akuster808 at gmail.com (Armin Kuster) Date: Sun, 15 Mar 2020 11:11:55 -0700 Subject: [OE-core] [zeus 13/16] maintainers: Add entry for buildtools-extended-tarball In-Reply-To: References: Message-ID: <1f903d76e50cb613e5cfe4f3eb00529b2443eb62.1584295805.git.akuster808@gmail.com> From: Richard Purdie Signed-off-by: Richard Purdie (cherry picked from commit 61d4d3d5a9f27e0fbf1d7ed6db818a779643b8f3) Signed-off-by: Armin Kuster --- meta/conf/distro/include/maintainers.inc | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/conf/distro/include/maintainers.inc b/meta/conf/distro/include/maintainers.inc index ab0c6c5541..7494873190 100644 --- a/meta/conf/distro/include/maintainers.inc +++ b/meta/conf/distro/include/maintainers.inc @@ -82,6 +82,7 @@ RECIPE_MAINTAINER_pn-build-appliance-image = "Richard Purdie References: Message-ID: From: Zhixiong Chi Backport the CVE patch from upstream: [https://sourceware.org/git/gitweb.cgi?p=glibc.git; a=patch;h=9333498794cde1d5cca518badf79533a24114b6f] Signed-off-by: Zhixiong Chi Signed-off-by: Armin Kuster --- .../glibc/glibc/CVE-2020-10029.patch | 128 ++++++++++++++++++ meta/recipes-core/glibc/glibc_2.30.bb | 1 + 2 files changed, 129 insertions(+) create mode 100644 meta/recipes-core/glibc/glibc/CVE-2020-10029.patch diff --git a/meta/recipes-core/glibc/glibc/CVE-2020-10029.patch b/meta/recipes-core/glibc/glibc/CVE-2020-10029.patch new file mode 100644 index 0000000000..606b691bcf --- /dev/null +++ b/meta/recipes-core/glibc/glibc/CVE-2020-10029.patch @@ -0,0 +1,128 @@ +From ce265ec5bc25ec35fba53807abac1b0c8469895e Mon Sep 17 00:00:00 2001 +From: Joseph Myers +Date: Wed, 12 Feb 2020 23:31:56 +0000 +Subject: [PATCH] Avoid ldbl-96 stack corruption from range reduction of + + pseudo-zero (bug 25487). + +Bug 25487 reports stack corruption in ldbl-96 sinl on a pseudo-zero +argument (an representation where all the significand bits, including +the explicit high bit, are zero, but the exponent is not zero, which +is not a valid representation for the long double type). + +Although this is not a valid long double representation, existing +practice in this area (see bug 4586, originally marked invalid but +subsequently fixed) is that we still seek to avoid invalid memory +accesses as a result, in case of programs that treat arbitrary binary +data as long double representations, although the invalid +representations of the ldbl-96 format do not need to be consistently +handled the same as any particular valid representation. + +This patch makes the range reduction detect pseudo-zero and unnormal +representations that would otherwise go to __kernel_rem_pio2, and +returns a NaN for them instead of continuing with the range reduction +process. (Pseudo-zero and unnormal representations whose unbiased +exponent is less than -1 have already been safely returned from the +function before this point without going through the rest of range +reduction.) Pseudo-zero representations would previously result in +the value passed to __kernel_rem_pio2 being all-zero, which is +definitely unsafe; unnormal representations would previously result in +a value passed whose high bit is zero, which might well be unsafe +since that is not a form of input expected by __kernel_rem_pio2. + +Tested for x86_64. + +CVE: CVE-2020-10029 +Upstream-Status: Backport [https://sourceware.org/git/gitweb.cgi?p=glibc.git; +a=patch;h=9333498794cde1d5cca518badf79533a24114b6f] +Signed-off-by: Zhixiong Chi + +--- + sysdeps/ieee754/ldbl-96/Makefile | 3 ++- + sysdeps/ieee754/ldbl-96/e_rem_pio2l.c | 12 +++++++++ + sysdeps/ieee754/ldbl-96/test-sinl-pseudo.c | 41 ++++++++++++++++++++++++++++++ + 3 files changed, 55 insertions(+), 1 deletion(-) + create mode 100644 sysdeps/ieee754/ldbl-96/test-sinl-pseudo.c + +diff --git a/sysdeps/ieee754/ldbl-96/Makefile b/sysdeps/ieee754/ldbl-96/Makefile +index b103254..052c1c7 100644 +--- a/sysdeps/ieee754/ldbl-96/Makefile ++++ b/sysdeps/ieee754/ldbl-96/Makefile +@@ -17,5 +17,6 @@ + # . + + ifeq ($(subdir),math) +-tests += test-canonical-ldbl-96 test-totalorderl-ldbl-96 ++tests += test-canonical-ldbl-96 test-totalorderl-ldbl-96 test-sinl-pseudo ++CFLAGS-test-sinl-pseudo.c += -fstack-protector-all + endif +diff --git a/sysdeps/ieee754/ldbl-96/e_rem_pio2l.c b/sysdeps/ieee754/ldbl-96/e_rem_pio2l.c +index 805de22..1aeccb4 100644 +--- a/sysdeps/ieee754/ldbl-96/e_rem_pio2l.c ++++ b/sysdeps/ieee754/ldbl-96/e_rem_pio2l.c +@@ -210,6 +210,18 @@ __ieee754_rem_pio2l (long double x, long double *y) + return 0; + } + ++ if ((i0 & 0x80000000) == 0) ++ { ++ /* Pseudo-zero and unnormal representations are not valid ++ representations of long double. We need to avoid stack ++ corruption in __kernel_rem_pio2, which expects input in a ++ particular normal form, but those representations do not need ++ to be consistently handled like any particular floating-point ++ value. */ ++ y[1] = y[0] = __builtin_nanl (""); ++ return 0; ++ } ++ + /* Split the 64 bits of the mantissa into three 24-bit integers + stored in a double array. */ + exp = j0 - 23; +diff --git a/sysdeps/ieee754/ldbl-96/test-sinl-pseudo.c b/sysdeps/ieee754/ldbl-96/test-sinl-pseudo.c +new file mode 100644 +index 0000000..f59b977 +--- /dev/null ++++ b/sysdeps/ieee754/ldbl-96/test-sinl-pseudo.c +@@ -0,0 +1,41 @@ ++/* Test sinl for pseudo-zeros and unnormals for ldbl-96 (bug 25487). ++ Copyright (C) 2020 Free Software Foundation, Inc. ++ This file is part of the GNU C Library. ++ ++ The GNU C Library is free software; you can redistribute it and/or ++ modify it under the terms of the GNU Lesser General Public ++ License as published by the Free Software Foundation; either ++ version 2.1 of the License, or (at your option) any later version. ++ ++ The GNU C Library is distributed in the hope that it will be useful, ++ but WITHOUT ANY WARRANTY; without even the implied warranty of ++ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU ++ Lesser General Public License for more details. ++ ++ You should have received a copy of the GNU Lesser General Public ++ License along with the GNU C Library; if not, see ++ . */ ++ ++#include ++#include ++#include ++ ++static int ++do_test (void) ++{ ++ for (int i = 0; i < 64; i++) ++ { ++ uint64_t sig = i == 63 ? 0 : 1ULL << i; ++ long double ld; ++ SET_LDOUBLE_WORDS (ld, 0x4141, ++ sig >> 32, sig & 0xffffffffULL); ++ /* The requirement is that no stack overflow occurs when the ++ pseudo-zero or unnormal goes through range reduction. */ ++ volatile long double ldr; ++ ldr = sinl (ld); ++ (void) ldr; ++ } ++ return 0; ++} ++ ++#include diff --git a/meta/recipes-core/glibc/glibc_2.30.bb b/meta/recipes-core/glibc/glibc_2.30.bb index 7913bc2812..c9e44a396d 100644 --- a/meta/recipes-core/glibc/glibc_2.30.bb +++ b/meta/recipes-core/glibc/glibc_2.30.bb @@ -42,6 +42,7 @@ SRC_URI = "${GLIBC_GIT_URI};branch=${SRCBRANCH};name=glibc \ file://0027-inject-file-assembly-directives.patch \ file://0028-locale-prevent-maybe-uninitialized-errors-with-Os-BZ.patch \ file://CVE-2019-19126.patch \ + file://CVE-2020-10029.patch \ " S = "${WORKDIR}/git" B = "${WORKDIR}/build-${TARGET_SYS}" -- 2.17.1 From akuster808 at gmail.com Sun Mar 15 18:11:57 2020 From: akuster808 at gmail.com (Armin Kuster) Date: Sun, 15 Mar 2020 11:11:57 -0700 Subject: [OE-core] [zeus 15/16] cve-check: show whitelisted status In-Reply-To: References: Message-ID: From: Chee Yang Lee change whitelisted CVE status from "Patched" to "Whitelisted". [Yocto #13687] Signed-off-by: Chee Yang Lee Signed-off-by: Richard Purdie (cherry picked from commit 181bdd670492525f9488d52c3ebb9a1b142e35ea) Signed-off-by: Armin Kuster --- meta/classes/cve-check.bbclass | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass index 74124364b2..7f98da60f1 100644 --- a/meta/classes/cve-check.bbclass +++ b/meta/classes/cve-check.bbclass @@ -56,10 +56,10 @@ python do_cve_check () { patched_cves = get_patches_cves(d) except FileNotFoundError: bb.fatal("Failure in searching patches") - patched, unpatched = check_cves(d, patched_cves) + whitelisted, patched, unpatched = check_cves(d, patched_cves) if patched or unpatched: cve_data = get_cve_info(d, patched + unpatched) - cve_write_data(d, patched, unpatched, cve_data) + cve_write_data(d, patched, unpatched, whitelisted, cve_data) else: bb.note("No CVE database found, skipping CVE check") @@ -263,7 +263,7 @@ def check_cves(d, patched_cves): conn.close() - return (list(patched_cves), cves_unpatched) + return (list(cve_whitelist), list(patched_cves), cves_unpatched) def get_cve_info(d, cves): """ @@ -287,7 +287,7 @@ def get_cve_info(d, cves): conn.close() return cve_data -def cve_write_data(d, patched, unpatched, cve_data): +def cve_write_data(d, patched, unpatched, whitelisted, cve_data): """ Write CVE information in WORKDIR; and to CVE_CHECK_DIR, and CVE manifest if enabled. @@ -303,7 +303,9 @@ def cve_write_data(d, patched, unpatched, cve_data): write_string += "PACKAGE NAME: %s\n" % d.getVar("PN") write_string += "PACKAGE VERSION: %s\n" % d.getVar("PV") write_string += "CVE: %s\n" % cve - if cve in patched: + if cve in whitelisted: + write_string += "CVE STATUS: Whitelisted\n" + elif cve in patched: write_string += "CVE STATUS: Patched\n" else: unpatched_cves.append(cve) -- 2.17.1 From akuster808 at gmail.com Sun Mar 15 18:11:58 2020 From: akuster808 at gmail.com (Armin Kuster) Date: Sun, 15 Mar 2020 11:11:58 -0700 Subject: [OE-core] [zeus 16/16] cve-check: fix ValueError In-Reply-To: References: Message-ID: <2ccf28a773fb1416ecd9b10f98b59a6d34beffd8.1584295805.git.akuster808@gmail.com> From: Chee Yang Lee fix below error for whitelisted recipe and recipe skip cve check. Error: The stack trace of python calls that resulted in this exception/failure was: File: 'exec_python_func() autogenerated', lineno: 2, function: 0001: *** 0002:do_cve_check(d) 0003: File: '/poky-master/meta/classes/cve-check.bbclass', lineno: 59, function: do_cve_check 0055: try: 0056: patched_cves = get_patches_cves(d) 0057: except FileNotFoundError: 0058: bb.fatal("Failure in searching patches") *** 0059: whitelisted, patched, unpatched = check_cves(d, patched_cves) 0060: if patched or unpatched: 0061: cve_data = get_cve_info(d, patched + unpatched) 0062: cve_write_data(d, patched, unpatched, whitelisted, cve_data) 0063: else: Exception: ValueError: not enough values to unpack (expected 3, got 2) Signed-off-by: Chee Yang Lee Signed-off-by: Richard Purdie (cherry picked from commit 64a362bd2dd0b4f3165d5162adbc600826af66f8) Signed-off-by: Armin Kuster --- meta/classes/cve-check.bbclass | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass index 7f98da60f1..5d84b93d71 100644 --- a/meta/classes/cve-check.bbclass +++ b/meta/classes/cve-check.bbclass @@ -179,13 +179,13 @@ def check_cves(d, patched_cves): products = d.getVar("CVE_PRODUCT").split() # If this has been unset then we're not scanning for CVEs here (for example, image recipes) if not products: - return ([], []) + return ([], [], []) pv = d.getVar("CVE_VERSION").split("+git")[0] # If the recipe has been whitlisted we return empty lists if d.getVar("PN") in d.getVar("CVE_CHECK_PN_WHITELIST").split(): bb.note("Recipe has been whitelisted, skipping check") - return ([], []) + return ([], [], []) old_cve_whitelist = d.getVar("CVE_CHECK_CVE_WHITELIST") if old_cve_whitelist: -- 2.17.1 From bunk at stusta.de Sun Mar 15 18:13:08 2020 From: bunk at stusta.de (Adrian Bunk) Date: Sun, 15 Mar 2020 20:13:08 +0200 Subject: [OE-core] [warrior][PATCH 3/3] gnupg: upgrade 2.2.16 -> 2.2.17 In-Reply-To: <20200315181308.12792-1-bunk@stusta.de> References: <20200315181308.12792-1-bunk@stusta.de> Message-ID: <20200315181308.12792-3-bunk@stusta.de> From: Anuj Mittal Also fixes CVE-2019-13050. Announcement: https://lists.gnupg.org/pipermail/gnupg-announce/2019q3/000439.html (From OE-Core rev: c6e46323f0d62daf8bd424e642581fdcba920ef7) Signed-off-by: Anuj Mittal Signed-off-by: Richard Purdie Signed-off-by: Adrian Bunk --- .../gnupg/{gnupg_2.2.16.bb => gnupg_2.2.17.bb} | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) rename meta/recipes-support/gnupg/{gnupg_2.2.16.bb => gnupg_2.2.17.bb} (92%) diff --git a/meta/recipes-support/gnupg/gnupg_2.2.16.bb b/meta/recipes-support/gnupg/gnupg_2.2.17.bb similarity index 92% rename from meta/recipes-support/gnupg/gnupg_2.2.16.bb rename to meta/recipes-support/gnupg/gnupg_2.2.17.bb index cb7c6c5c62..e5456dd9b9 100644 --- a/meta/recipes-support/gnupg/gnupg_2.2.16.bb +++ b/meta/recipes-support/gnupg/gnupg_2.2.17.bb @@ -19,9 +19,8 @@ SRC_URI = "${GNUPG_MIRROR}/${BPN}/${BPN}-${PV}.tar.bz2 \ SRC_URI_append_class-native = " file://0001-configure.ac-use-a-custom-value-for-the-location-of-.patch \ file://relocate.patch" - -SRC_URI[md5sum] = "d90e186df1c06845880ea58a318f070b" -SRC_URI[sha256sum] = "6cbe8d454bf5dc204621eed3016d721b66298fa95363395bb8eeceb1d2fd14cb" +SRC_URI[md5sum] = "1ba2d9b70c377f8e967742064c27a19c" +SRC_URI[sha256sum] = "afa262868e39b651a2db4c071fba90415154243e83a830ca00516f9a807fd514" EXTRA_OECONF = "--disable-ldap \ --disable-ccid-driver \ -- 2.17.1 From bunk at stusta.de Sun Mar 15 18:13:06 2020 From: bunk at stusta.de (Adrian Bunk) Date: Sun, 15 Mar 2020 20:13:06 +0200 Subject: [OE-core] [warrior][PATCH 1/3] gnupg: update to 2.2.15 Message-ID: <20200315181308.12792-1-bunk@stusta.de> From: Oleksandr Kravchuk (From OE-Core rev: e60b3994d4bc282191302e1fd9b7d2106ee2f6cb) Signed-off-by: Oleksandr Kravchuk Signed-off-by: Richard Purdie Signed-off-by: Adrian Bunk --- ...01-Woverride-init-is-not-needed-with-gcc-9.patch | 13 ++++++++----- .../gnupg/{gnupg_2.2.13.bb => gnupg_2.2.15.bb} | 4 ++-- 2 files changed, 10 insertions(+), 7 deletions(-) rename meta/recipes-support/gnupg/{gnupg_2.2.13.bb => gnupg_2.2.15.bb} (93%) diff --git a/meta/recipes-support/gnupg/gnupg/0001-Woverride-init-is-not-needed-with-gcc-9.patch b/meta/recipes-support/gnupg/gnupg/0001-Woverride-init-is-not-needed-with-gcc-9.patch index 4a280f9d5c..83195b5bd4 100644 --- a/meta/recipes-support/gnupg/gnupg/0001-Woverride-init-is-not-needed-with-gcc-9.patch +++ b/meta/recipes-support/gnupg/gnupg/0001-Woverride-init-is-not-needed-with-gcc-9.patch @@ -1,4 +1,4 @@ -From 0df5800cc2e720aad883a517f7d24a9722fe5845 Mon Sep 17 00:00:00 2001 +From e3adc816d2d56dd929016073937ba24e01e03cb8 Mon Sep 17 00:00:00 2001 From: Khem Raj Date: Thu, 20 Dec 2018 17:37:48 -0800 Subject: [PATCH] Woverride-init is not needed with gcc 9 @@ -17,15 +17,18 @@ Signed-off-by: Khem Raj 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dirmngr/dns.h b/dirmngr/dns.h -index 30d0b45..98fe412 100644 +index 024d6dcc8..c6e141e16 100644 --- a/dirmngr/dns.h +++ b/dirmngr/dns.h -@@ -154,7 +154,7 @@ DNS_PUBLIC int *dns_debug_p(void); +@@ -139,7 +139,7 @@ DNS_PUBLIC int *dns_debug_p(void); + #define DNS_PRAGMA_QUIET _Pragma("clang diagnostic ignored \"-Winitializer-overrides\"") + #define DNS_PRAGMA_POP _Pragma("clang diagnostic pop") - #define dns_quietinit(...) \ - DNS_PRAGMA_PUSH DNS_PRAGMA_QUIET __VA_ARGS__ DNS_PRAGMA_POP -#elif (__GNUC__ == 4 && __GNUC_MINOR__ >= 6) || __GNUC__ > 4 +#elif (__GNUC__ == 4 && __GNUC_MINOR__ >= 6) || (__GNUC__ > 4 && __GNUC__ < 9) #define DNS_PRAGMA_PUSH _Pragma("GCC diagnostic push") #define DNS_PRAGMA_QUIET _Pragma("GCC diagnostic ignored \"-Woverride-init\"") #define DNS_PRAGMA_POP _Pragma("GCC diagnostic pop") +-- +2.17.1 + diff --git a/meta/recipes-support/gnupg/gnupg_2.2.13.bb b/meta/recipes-support/gnupg/gnupg_2.2.15.bb similarity index 93% rename from meta/recipes-support/gnupg/gnupg_2.2.13.bb rename to meta/recipes-support/gnupg/gnupg_2.2.15.bb index 3ce2a38c0e..06a257333d 100644 --- a/meta/recipes-support/gnupg/gnupg_2.2.13.bb +++ b/meta/recipes-support/gnupg/gnupg_2.2.15.bb @@ -20,8 +20,8 @@ SRC_URI_append_class-native = " file://0001-configure.ac-use-a-custom-value-for- file://relocate.patch" -SRC_URI[md5sum] = "563b959d0c3856e34526e9ca51c80d7b" -SRC_URI[sha256sum] = "76c787a955f9e6e0ead47c9be700bfb9d454f955a7b7c7e697aa719bac7b11d8" +SRC_URI[md5sum] = "3ab87e377aa0af2f463649515bf66508" +SRC_URI[sha256sum] = "cb8ce298d7b36558ffc48aec961b14c830ff1783eef7a623411188b5e0f5d454" EXTRA_OECONF = "--disable-ldap \ --disable-ccid-driver \ -- 2.17.1 From bunk at stusta.de Sun Mar 15 18:13:07 2020 From: bunk at stusta.de (Adrian Bunk) Date: Sun, 15 Mar 2020 20:13:07 +0200 Subject: [OE-core] [warrior][PATCH 2/3] gnupg: upgrade 2.2.15 -> 2.2.16 In-Reply-To: <20200315181308.12792-1-bunk@stusta.de> References: <20200315181308.12792-1-bunk@stusta.de> Message-ID: <20200315181308.12792-2-bunk@stusta.de> From: Zang Ruochen (From OE-Core rev: 825be9d66ae9f503f1dd2dce0fac530554057613) Signed-off-by: Zang Ruochen Signed-off-by: Richard Purdie Signed-off-by: Adrian Bunk --- .../gnupg/{gnupg_2.2.15.bb => gnupg_2.2.16.bb} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename meta/recipes-support/gnupg/{gnupg_2.2.15.bb => gnupg_2.2.16.bb} (93%) diff --git a/meta/recipes-support/gnupg/gnupg_2.2.15.bb b/meta/recipes-support/gnupg/gnupg_2.2.16.bb similarity index 93% rename from meta/recipes-support/gnupg/gnupg_2.2.15.bb rename to meta/recipes-support/gnupg/gnupg_2.2.16.bb index 06a257333d..cb7c6c5c62 100644 --- a/meta/recipes-support/gnupg/gnupg_2.2.15.bb +++ b/meta/recipes-support/gnupg/gnupg_2.2.16.bb @@ -20,8 +20,8 @@ SRC_URI_append_class-native = " file://0001-configure.ac-use-a-custom-value-for- file://relocate.patch" -SRC_URI[md5sum] = "3ab87e377aa0af2f463649515bf66508" -SRC_URI[sha256sum] = "cb8ce298d7b36558ffc48aec961b14c830ff1783eef7a623411188b5e0f5d454" +SRC_URI[md5sum] = "d90e186df1c06845880ea58a318f070b" +SRC_URI[sha256sum] = "6cbe8d454bf5dc204621eed3016d721b66298fa95363395bb8eeceb1d2fd14cb" EXTRA_OECONF = "--disable-ldap \ --disable-ccid-driver \ -- 2.17.1 From bunk at stusta.de Sun Mar 15 18:14:05 2020 From: bunk at stusta.de (Adrian Bunk) Date: Sun, 15 Mar 2020 20:14:05 +0200 Subject: [OE-core] [warrior][PATCH] python3: Upgrade 3.7.6 -> 3.7.7 Message-ID: <20200315181405.12903-1-bunk@stusta.de> THE LICENSE checksum changed in this update due to copyright notice added for 2020. Signed-off-by: Adrian Bunk --- .../python/{python3_3.7.6.bb => python3_3.7.7.bb} | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) rename meta/recipes-devtools/python/{python3_3.7.6.bb => python3_3.7.7.bb} (98%) diff --git a/meta/recipes-devtools/python/python3_3.7.6.bb b/meta/recipes-devtools/python/python3_3.7.7.bb similarity index 98% rename from meta/recipes-devtools/python/python3_3.7.6.bb rename to meta/recipes-devtools/python/python3_3.7.7.bb index 3efd3bcac8..114cf2fe09 100644 --- a/meta/recipes-devtools/python/python3_3.7.6.bb +++ b/meta/recipes-devtools/python/python3_3.7.7.bb @@ -3,7 +3,7 @@ HOMEPAGE = "http://www.python.org" LICENSE = "PSFv2" SECTION = "devel/python" -LIC_FILES_CHKSUM = "file://LICENSE;md5=e466242989bd33c1bd2b6a526a742498" +LIC_FILES_CHKSUM = "file://LICENSE;md5=203a6dbc802ee896020a47161e759642" SRC_URI = "http://www.python.org/ftp/python/${PV}/Python-${PV}.tar.xz \ file://run-ptest \ @@ -38,8 +38,8 @@ SRC_URI_append_class-nativesdk = " \ file://0001-main.c-if-OEPYTHON3HOME-is-set-use-instead-of-PYTHON.patch \ " -SRC_URI[md5sum] = "c08fbee72ad5c2c95b0f4e44bf6fd72c" -SRC_URI[sha256sum] = "55a2cce72049f0794e9a11a84862e9039af9183603b78bc60d89539f82cf533f" +SRC_URI[md5sum] = "172c650156f7bea68ce31b2fd01fa766" +SRC_URI[sha256sum] = "06a0a9f1bf0d8cd1e4121194d666c4e28ddae4dd54346de6c343206599f02136" # exclude pre-releases for both python 2.x and 3.x UPSTREAM_CHECK_REGEX = "[Pp]ython-(?P\d+(\.\d+)+).tar" -- 2.17.1 From akuster808 at gmail.com Sun Mar 15 18:56:09 2020 From: akuster808 at gmail.com (akuster808) Date: Sun, 15 Mar 2020 11:56:09 -0700 Subject: [OE-core] [warrior][PATCH 3/3] gnupg: upgrade 2.2.16 -> 2.2.17 In-Reply-To: <20200315181308.12792-3-bunk@stusta.de> References: <20200315181308.12792-1-bunk@stusta.de> <20200315181308.12792-3-bunk@stusta.de> Message-ID: <51a214de-d173-1dcd-061d-7e127487e364@gmail.com> On 3/15/20 11:13 AM, Adrian Bunk wrote: > From: Anuj Mittal > > Also fixes CVE-2019-13050. Announcement: > > https://lists.gnupg.org/pipermail/gnupg-announce/2019q3/000439.html > > (From OE-Core rev: c6e46323f0d62daf8bd424e642581fdcba920ef7) > > Signed-off-by: Anuj Mittal > Signed-off-by: Richard Purdie > Signed-off-by: Adrian Bunk are these bug fix only updates? > --- > .../gnupg/{gnupg_2.2.16.bb => gnupg_2.2.17.bb} | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > rename meta/recipes-support/gnupg/{gnupg_2.2.16.bb => gnupg_2.2.17.bb} (92%) > > diff --git a/meta/recipes-support/gnupg/gnupg_2.2.16.bb b/meta/recipes-support/gnupg/gnupg_2.2.17.bb > similarity index 92% > rename from meta/recipes-support/gnupg/gnupg_2.2.16.bb > rename to meta/recipes-support/gnupg/gnupg_2.2.17.bb > index cb7c6c5c62..e5456dd9b9 100644 > --- a/meta/recipes-support/gnupg/gnupg_2.2.16.bb > +++ b/meta/recipes-support/gnupg/gnupg_2.2.17.bb > @@ -19,9 +19,8 @@ SRC_URI = "${GNUPG_MIRROR}/${BPN}/${BPN}-${PV}.tar.bz2 \ > SRC_URI_append_class-native = " file://0001-configure.ac-use-a-custom-value-for-the-location-of-.patch \ > file://relocate.patch" > > - > -SRC_URI[md5sum] = "d90e186df1c06845880ea58a318f070b" > -SRC_URI[sha256sum] = "6cbe8d454bf5dc204621eed3016d721b66298fa95363395bb8eeceb1d2fd14cb" > +SRC_URI[md5sum] = "1ba2d9b70c377f8e967742064c27a19c" > +SRC_URI[sha256sum] = "afa262868e39b651a2db4c071fba90415154243e83a830ca00516f9a807fd514" > > EXTRA_OECONF = "--disable-ldap \ > --disable-ccid-driver \ From bunk at stusta.de Sun Mar 15 19:07:53 2020 From: bunk at stusta.de (Adrian Bunk) Date: Sun, 15 Mar 2020 21:07:53 +0200 Subject: [OE-core] [warrior][PATCH 3/3] gnupg: upgrade 2.2.16 -> 2.2.17 In-Reply-To: <51a214de-d173-1dcd-061d-7e127487e364@gmail.com> References: <20200315181308.12792-1-bunk@stusta.de> <20200315181308.12792-3-bunk@stusta.de> <51a214de-d173-1dcd-061d-7e127487e364@gmail.com> Message-ID: <20200315190753.GA14992@localhost> On Sun, Mar 15, 2020 at 11:56:09AM -0700, akuster808 wrote: > > > On 3/15/20 11:13 AM, Adrian Bunk wrote: > > From: Anuj Mittal > > > > Also fixes CVE-2019-13050. Announcement: > > > > https://lists.gnupg.org/pipermail/gnupg-announce/2019q3/000439.html > > > > (From OE-Core rev: c6e46323f0d62daf8bd424e642581fdcba920ef7) > > > > Signed-off-by: Anuj Mittal > > Signed-off-by: Richard Purdie > > Signed-off-by: Adrian Bunk > > are these bug fix only updates? Mostly just bugfixes, no major functionality changes. Backporting only the bugfixes gives you a patch list like Debian stable: https://sources.debian.org/src/gnupg2/2.2.12-1+deb10u1/debian/patches/series/ cu Adrian From richard.purdie at linuxfoundation.org Sun Mar 15 22:14:06 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Sun, 15 Mar 2020 22:14:06 +0000 Subject: [OE-core] [PATCH] bison: Reset load average settings if specified in environment In-Reply-To: <20200315042947.3257882-1-raj.khem@gmail.com> References: <20200315042947.3257882-1-raj.khem@gmail.com> Message-ID: On Sat, 2020-03-14 at 21:29 -0700, Khem Raj wrote: > In some cases, we run into parallel build failures where > BUILT_SOURCES > is skipped, as a result required header files are not generated and > the > build fails with missing header errors like > > ../bison-3.5.2/lib/uniwidth/width.c:21:10: fatal error: uniwidth.h: > No such file or directory > #include "uniwidth.h" > ^~~~~~~~~~~~ > compilation terminated. > > BUILT_SOURCES should be built automatically with `make all` [1] > therefore > ensure that make is invoked with `all` target > > bison-native parallel build fails when -l is passed globally from > build environment, errors like below due to race starts to show up > > Therefore removes a previous load limit if set > > [1] > https://www.gnu.org/software/automake/manual/html_node/Built-Sources-Example.html#Built-Sources-Example I'm not sure I understand this. We've seen a failure on our ubuntu1604 performance tester which I think is the same bug as this. The environment on that machine doesn't change, so how/where is this -l option coming from? I suspect there is some issue we're not quite getting to still :( Cheers, Richard From richard.purdie at linuxfoundation.org Sun Mar 15 22:19:43 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Sun, 15 Mar 2020 22:19:43 +0000 Subject: [OE-core] [PATCH] scripts/pybootchartgui: Fix to work with python 3.8 Message-ID: <20200315221943.187279-1-richard.purdie@linuxfoundation.org> time.clock() was removed in python 3.8, use one of its recommended replacements to fix failures on python 3.8 systems. Signed-off-by: Richard Purdie --- scripts/pybootchartgui/pybootchartgui/parsing.py | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/scripts/pybootchartgui/pybootchartgui/parsing.py b/scripts/pybootchartgui/pybootchartgui/parsing.py index ef2d3d309ca..b42dac6b888 100644 --- a/scripts/pybootchartgui/pybootchartgui/parsing.py +++ b/scripts/pybootchartgui/pybootchartgui/parsing.py @@ -18,7 +18,7 @@ import string import re import sys import tarfile -from time import clock +import time from collections import defaultdict from functools import reduce @@ -723,7 +723,7 @@ def get_num_cpus(headers): def _do_parse(writer, state, filename, file): writer.info("parsing '%s'" % filename) - t1 = clock() + t1 = time.process_time() name = os.path.basename(filename) if name == "proc_diskstats.log": state.disk_stats = _parse_proc_disk_stat_log(file) @@ -743,7 +743,7 @@ def _do_parse(writer, state, filename, file): state.monitor_disk = _parse_monitor_disk_log(file) elif not filename.endswith('.log'): _parse_bitbake_buildstats(writer, state, filename, file) - t2 = clock() + t2 = time.process_time() writer.info(" %s seconds" % str(t2-t1)) return state -- 2.25.0 From raj.khem at gmail.com Sun Mar 15 22:23:46 2020 From: raj.khem at gmail.com (Khem Raj) Date: Sun, 15 Mar 2020 15:23:46 -0700 Subject: [OE-core] [PATCH] bison: Reset load average settings if specified in environment In-Reply-To: References: <20200315042947.3257882-1-raj.khem@gmail.com> Message-ID: On Sun, Mar 15, 2020 at 3:14 PM Richard Purdie wrote: > > On Sat, 2020-03-14 at 21:29 -0700, Khem Raj wrote: > > In some cases, we run into parallel build failures where > > BUILT_SOURCES > > is skipped, as a result required header files are not generated and > > the > > build fails with missing header errors like > > > > ../bison-3.5.2/lib/uniwidth/width.c:21:10: fatal error: uniwidth.h: > > No such file or directory > > #include "uniwidth.h" > > ^~~~~~~~~~~~ > > compilation terminated. > > > > BUILT_SOURCES should be built automatically with `make all` [1] > > therefore > > ensure that make is invoked with `all` target > > > > bison-native parallel build fails when -l is passed globally from > > build environment, errors like below due to race starts to show up > > > > Therefore removes a previous load limit if set > > > > [1] > > https://www.gnu.org/software/automake/manual/html_node/Built-Sources-Example.html#Built-Sources-Example > > I'm not sure I understand this. We've seen a failure on our ubuntu1604 > performance tester which I think is the same bug as this. The > environment on that machine doesn't change, so how/where is this -l > option coming from? > >From custom distro global settings for EXTRA_OEMAKE > I suspect there is some issue we're not quite getting to still :( > its well reproducible now with -j and -l together on our builders, From what I see in makefiles bison is doing right thing in using BUILT_SOURCES so I suspect it could be make acting in a certain way when those options are present. our custom settings use -l options globally in EXTRA_OEMAKE this is to let machines with certain configurations build when machines are shared, we don't want a given build to use all resources on box. Yes one could say why not do something else to limit the resources build uses but this is a global setting that works well This patch just ensures that any -l setting passed from environment is cleaned up and reset. So for general case it will be a noop. > Cheers, > > Richard > From richard.purdie at linuxfoundation.org Sun Mar 15 22:25:55 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Sun, 15 Mar 2020 22:25:55 +0000 Subject: [OE-core] [PATCH] bison: Reset load average settings if specified in environment In-Reply-To: References: <20200315042947.3257882-1-raj.khem@gmail.com> Message-ID: <3d626d46a2cf1cb10d0ae41444db96a65e65e201.camel@linuxfoundation.org> On Sun, 2020-03-15 at 15:23 -0700, Khem Raj wrote: > On Sun, Mar 15, 2020 at 3:14 PM Richard Purdie > wrote: > > On Sat, 2020-03-14 at 21:29 -0700, Khem Raj wrote: > > > In some cases, we run into parallel build failures where > > > BUILT_SOURCES > > > is skipped, as a result required header files are not generated and > > > the > > > build fails with missing header errors like > > > > > > ../bison-3.5.2/lib/uniwidth/width.c:21:10: fatal error: uniwidth.h: > > > No such file or directory > > > #include "uniwidth.h" > > > ^~~~~~~~~~~~ > > > compilation terminated. > > > > > > BUILT_SOURCES should be built automatically with `make all` [1] > > > therefore > > > ensure that make is invoked with `all` target > > > > > > bison-native parallel build fails when -l is passed globally from > > > build environment, errors like below due to race starts to show up > > > > > > Therefore removes a previous load limit if set > > > > > > [1] > > > https://www.gnu.org/software/automake/manual/html_node/Built-Sources-Example.html#Built-Sources-Example > > > > I'm not sure I understand this. We've seen a failure on our ubuntu1604 > > performance tester which I think is the same bug as this. The > > environment on that machine doesn't change, so how/where is this -l > > option coming from? > > > > From custom distro global settings for EXTRA_OEMAKE > > > I suspect there is some issue we're not quite getting to still :( > > > its well reproducible now with -j and -l together on our builders, From what > I see in makefiles bison is doing right thing in using BUILT_SOURCES so > I suspect it could be make acting in a certain way when those options > are present. > > our custom settings use -l options globally in EXTRA_OEMAKE > this is to let machines with certain configurations build when machines are > shared, we don't want a given build to use all resources on box. Yes one > could say why not do something else to limit the resources build uses but > this is a global setting that works well > > This patch just ensures that any -l setting passed from environment is > cleaned up and reset. So for general case it will be a noop. Ok, that explains your failure but not the one on our performance testing worker :/. Cheers, Richard From patchwork at patchwork.openembedded.org Sun Mar 15 22:32:33 2020 From: patchwork at patchwork.openembedded.org (Patchwork) Date: Sun, 15 Mar 2020 22:32:33 -0000 Subject: [OE-core] =?utf-8?q?=E2=9C=97_patchtest=3A_failure_for_scripts/py?= =?utf-8?q?bootchartgui=3A_Fix_to_work_with_python_3=2E8?= In-Reply-To: <20200315221943.187279-1-richard.purdie@linuxfoundation.org> References: <20200315221943.187279-1-richard.purdie@linuxfoundation.org> Message-ID: <20200315223233.2274.99991@do> == Series Details == Series: scripts/pybootchartgui: Fix to work with python 3.8 Revision: 1 URL : https://patchwork.openembedded.org/series/23252/ 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 fix Rebase your series on top of targeted branch Targeted branch master (currently at ebe7767d8a) If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core at 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 From raj.khem at gmail.com Sun Mar 15 22:40:33 2020 From: raj.khem at gmail.com (Khem Raj) Date: Sun, 15 Mar 2020 15:40:33 -0700 Subject: [OE-core] [PATCH] bison: Reset load average settings if specified in environment In-Reply-To: <3d626d46a2cf1cb10d0ae41444db96a65e65e201.camel@linuxfoundation.org> References: <20200315042947.3257882-1-raj.khem@gmail.com> <3d626d46a2cf1cb10d0ae41444db96a65e65e201.camel@linuxfoundation.org> Message-ID: On Sun, Mar 15, 2020 at 3:25 PM Richard Purdie < richard.purdie at linuxfoundation.org> wrote: > On Sun, 2020-03-15 at 15:23 -0700, Khem Raj wrote: > > On Sun, Mar 15, 2020 at 3:14 PM Richard Purdie > > wrote: > > > On Sat, 2020-03-14 at 21:29 -0700, Khem Raj wrote: > > > > In some cases, we run into parallel build failures where > > > > BUILT_SOURCES > > > > is skipped, as a result required header files are not generated and > > > > the > > > > build fails with missing header errors like > > > > > > > > ../bison-3.5.2/lib/uniwidth/width.c:21:10: fatal error: uniwidth.h: > > > > No such file or directory > > > > #include "uniwidth.h" > > > > ^~~~~~~~~~~~ > > > > compilation terminated. > > > > > > > > BUILT_SOURCES should be built automatically with `make all` [1] > > > > therefore > > > > ensure that make is invoked with `all` target > > > > > > > > bison-native parallel build fails when -l is passed globally from > > > > build environment, errors like below due to race starts to show up > > > > > > > > Therefore removes a previous load limit if set > > > > > > > > [1] > > > > > https://www.gnu.org/software/automake/manual/html_node/Built-Sources-Example.html#Built-Sources-Example > > > > > > I'm not sure I understand this. We've seen a failure on our ubuntu1604 > > > performance tester which I think is the same bug as this. The > > > environment on that machine doesn't change, so how/where is this -l > > > option coming from? > > > > > > > From custom distro global settings for EXTRA_OEMAKE > > > > > I suspect there is some issue we're not quite getting to still :( > > > > > its well reproducible now with -j and -l together on our builders, From > what > > I see in makefiles bison is doing right thing in using BUILT_SOURCES so > > I suspect it could be make acting in a certain way when those options > > are present. > > > > our custom settings use -l options globally in EXTRA_OEMAKE > > this is to let machines with certain configurations build when machines > are > > shared, we don't want a given build to use all resources on box. Yes one > > could say why not do something else to limit the resources build uses but > > this is a global setting that works well > > > > This patch just ensures that any -l setting passed from environment is > > cleaned up and reset. So for general case it will be a noop. > > Ok, that explains your failure but not the one on our performance > testing worker :/. What errors do you see on perf testing worker is it exactly same ? > > > Cheers, > > Richard > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anuj.mittal at intel.com Sun Mar 15 23:11:02 2020 From: anuj.mittal at intel.com (Mittal, Anuj) Date: Sun, 15 Mar 2020 23:11:02 +0000 Subject: [OE-core] [zeus 00/16] pull request In-Reply-To: References: Message-ID: <78e9dd3291fa0d4de450b5952b57e1a037644a3d.camel@intel.com> Hi Armin, On Sun, 2020-03-15 at 11:11 -0700, Armin Kuster wrote: > Khem Raj (1): > valgrind: Fix build with -fno-common > This isn't present in stable/zeus-next. Should this pull request be updated? > Lee Chee Yang (1): > virglrenderer: fix multiple CVEs > > Mark Hatle (1): > gcc-cross-canadian: A missing space in an append caused an invalid > option > > Michael Halstead (1): > yocto-uninative.inc: version 2.8 updates glibc to 2.31 > > Nathan Rossi (2): > gcc-cross.inc: Prevent native sysroot from leaking into > configargs.h > gcc-target.inc: Prevent sysroot from leaking into configargs.h > > Ovidiu Panait (1): > dhcp: Fix REQUIRE(ctx->running) assertion triggered on > SIGTERM/SIGINT > > Rahul Chauhan (1): > ruby: fix CVE-2019-16254 > > Richard Purdie (2): > dummy-sdk-package: Add DUMMYPROVIDES_PACKAGES > maintainers: Add entry for buildtools-extended-tarball > Since there is no recipe, this is probably unnecessary? Thanks, Anuj From akuster808 at gmail.com Sun Mar 15 23:37:56 2020 From: akuster808 at gmail.com (akuster808) Date: Sun, 15 Mar 2020 16:37:56 -0700 Subject: [OE-core] [zeus 00/16] pull request In-Reply-To: <78e9dd3291fa0d4de450b5952b57e1a037644a3d.camel@intel.com> References: <78e9dd3291fa0d4de450b5952b57e1a037644a3d.camel@intel.com> Message-ID: <1035874e-551d-8733-f203-f018d11ea81f@gmail.com> On 3/15/20 4:11 PM, Mittal, Anuj wrote: > Hi Armin, > > On Sun, 2020-03-15 at 11:11 -0700, Armin Kuster wrote: >> Khem Raj (1): >> valgrind: Fix build with -fno-common >> > This isn't present in stable/zeus-next. Should this pull request be > updated? I forgot to remove it before sending the pull request. folks had issues with it. - armin >> Lee Chee Yang (1): >> virglrenderer: fix multiple CVEs >> >> Mark Hatle (1): >> gcc-cross-canadian: A missing space in an append caused an invalid >> option >> >> Michael Halstead (1): >> yocto-uninative.inc: version 2.8 updates glibc to 2.31 >> >> Nathan Rossi (2): >> gcc-cross.inc: Prevent native sysroot from leaking into >> configargs.h >> gcc-target.inc: Prevent sysroot from leaking into configargs.h >> >> Ovidiu Panait (1): >> dhcp: Fix REQUIRE(ctx->running) assertion triggered on >> SIGTERM/SIGINT >> >> Rahul Chauhan (1): >> ruby: fix CVE-2019-16254 >> >> Richard Purdie (2): >> dummy-sdk-package: Add DUMMYPROVIDES_PACKAGES >> maintainers: Add entry for buildtools-extended-tarball >> > Since there is no recipe, this is probably unnecessary? > > Thanks, > > Anuj From wangmy at cn.fujitsu.com Mon Mar 16 07:39:34 2020 From: wangmy at cn.fujitsu.com (Wang Mingyu) Date: Mon, 16 Mar 2020 00:39:34 -0700 Subject: [OE-core] [PATCH] libical: upgrade 3.0.7 -> 3.0.8 Message-ID: <1584344377-112331-1-git-send-email-wangmy@cn.fujitsu.com> Signed-off-by: Wang Mingyu --- .../libical/{libical_3.0.7.bb => libical_3.0.8.bb} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename meta/recipes-support/libical/{libical_3.0.7.bb => libical_3.0.8.bb} (93%) diff --git a/meta/recipes-support/libical/libical_3.0.7.bb b/meta/recipes-support/libical/libical_3.0.8.bb similarity index 93% rename from meta/recipes-support/libical/libical_3.0.7.bb rename to meta/recipes-support/libical/libical_3.0.8.bb index a50473e9ec..efb9433412 100644 --- a/meta/recipes-support/libical/libical_3.0.7.bb +++ b/meta/recipes-support/libical/libical_3.0.8.bb @@ -12,8 +12,8 @@ SRC_URI = " \ https://github.com/${BPN}/${BPN}/releases/download/v${PV}/${BP}.tar.gz \ file://0001-Use-our-hand-build-native-src-generator.patch \ " -SRC_URI[md5sum] = "8a5d07a7fba9e73a85e67f76258bf042" -SRC_URI[sha256sum] = "0abe66df1ea826e57db7f281c704ede834c84139012e6c686ea7adafd4e763fc" +SRC_URI[md5sum] = "41bd1f1fcdcb4779cea478bb55cf07bf" +SRC_URI[sha256sum] = "09fecacaf75ba5a242159e3a9758a5446b5ce4d0ab684f98a7040864e1d1286f" UPSTREAM_CHECK_URI = "https://github.com/libical/libical/releases" inherit cmake pkgconfig -- 2.17.1 From wangmy at cn.fujitsu.com Mon Mar 16 07:39:35 2020 From: wangmy at cn.fujitsu.com (Wang Mingyu) Date: Mon, 16 Mar 2020 00:39:35 -0700 Subject: [OE-core] [PATCH] libinput: update 1.15.2 -> 1.15.3 In-Reply-To: <1584344377-112331-1-git-send-email-wangmy@cn.fujitsu.com> References: <1584344377-112331-1-git-send-email-wangmy@cn.fujitsu.com> Message-ID: <1584344377-112331-2-git-send-email-wangmy@cn.fujitsu.com> Signed-off-by: Wang Mingyu --- .../wayland/{libinput_1.15.2.bb => libinput_1.15.3.bb} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename meta/recipes-graphics/wayland/{libinput_1.15.2.bb => libinput_1.15.3.bb} (90%) diff --git a/meta/recipes-graphics/wayland/libinput_1.15.2.bb b/meta/recipes-graphics/wayland/libinput_1.15.3.bb similarity index 90% rename from meta/recipes-graphics/wayland/libinput_1.15.2.bb rename to meta/recipes-graphics/wayland/libinput_1.15.3.bb index 810532774e..7817d59b5f 100644 --- a/meta/recipes-graphics/wayland/libinput_1.15.2.bb +++ b/meta/recipes-graphics/wayland/libinput_1.15.3.bb @@ -15,8 +15,8 @@ DEPENDS = "libevdev udev mtdev" SRC_URI = "http://www.freedesktop.org/software/${BPN}/${BP}.tar.xz \ file://determinism.patch \ " -SRC_URI[md5sum] = "eb6bd2907ad33d53954d70dfb881a643" -SRC_URI[sha256sum] = "971c3fbfb624f95c911adeb2803c372e4e3647d1b98f278f660051f834597747" +SRC_URI[md5sum] = "6fbea8d51d9194d7ba33f96d7c4cee56" +SRC_URI[sha256sum] = "5b12427dd50489c2b41b04ae2ca54e31a112a33cb861f00ccd15a2ad7a88694d" UPSTREAM_CHECK_REGEX = "libinput-(?P\d+\.\d+\.(?!9\d+)\d+)" -- 2.17.1 From wangmy at cn.fujitsu.com Mon Mar 16 07:39:36 2020 From: wangmy at cn.fujitsu.com (Wang Mingyu) Date: Mon, 16 Mar 2020 00:39:36 -0700 Subject: [OE-core] [PATCH] librepo: upgrade 1.11.2 -> 1.11.3 In-Reply-To: <1584344377-112331-1-git-send-email-wangmy@cn.fujitsu.com> References: <1584344377-112331-1-git-send-email-wangmy@cn.fujitsu.com> Message-ID: <1584344377-112331-3-git-send-email-wangmy@cn.fujitsu.com> Signed-off-by: Wang Mingyu --- .../librepo/{librepo_1.11.2.bb => librepo_1.11.3.bb} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename meta/recipes-devtools/librepo/{librepo_1.11.2.bb => librepo_1.11.3.bb} (93%) diff --git a/meta/recipes-devtools/librepo/librepo_1.11.2.bb b/meta/recipes-devtools/librepo/librepo_1.11.3.bb similarity index 93% rename from meta/recipes-devtools/librepo/librepo_1.11.2.bb rename to meta/recipes-devtools/librepo/librepo_1.11.3.bb index 6a0a59f865..3e745314a8 100644 --- a/meta/recipes-devtools/librepo/librepo_1.11.2.bb +++ b/meta/recipes-devtools/librepo/librepo_1.11.3.bb @@ -8,7 +8,7 @@ SRC_URI = "git://github.com/rpm-software-management/librepo.git \ file://0004-Set-gpgme-variables-with-pkg-config-not-with-cmake-m.patch \ " -SRCREV = "67c2d1f83f1bf87be3f26ba730fce7fbdf0c9fba" +SRCREV = "59b3f76ca6e79786a213cda72ecafa232d30553f" S = "${WORKDIR}/git" -- 2.17.1 From wangmy at cn.fujitsu.com Mon Mar 16 07:39:37 2020 From: wangmy at cn.fujitsu.com (Wang Mingyu) Date: Mon, 16 Mar 2020 00:39:37 -0700 Subject: [OE-core] [PATCH] xcb-proto: upgrade 1.13 -> 1.14 In-Reply-To: <1584344377-112331-1-git-send-email-wangmy@cn.fujitsu.com> References: <1584344377-112331-1-git-send-email-wangmy@cn.fujitsu.com> Message-ID: <1584344377-112331-4-git-send-email-wangmy@cn.fujitsu.com> Signed-off-by: Wang Mingyu --- .../xorg-proto/{xcb-proto_1.13.bb => xcb-proto_1.14.bb} | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) rename meta/recipes-graphics/xorg-proto/{xcb-proto_1.13.bb => xcb-proto_1.14.bb} (82%) diff --git a/meta/recipes-graphics/xorg-proto/xcb-proto_1.13.bb b/meta/recipes-graphics/xorg-proto/xcb-proto_1.14.bb similarity index 82% rename from meta/recipes-graphics/xorg-proto/xcb-proto_1.13.bb rename to meta/recipes-graphics/xorg-proto/xcb-proto_1.14.bb index 7467090920..563143f070 100644 --- a/meta/recipes-graphics/xorg-proto/xcb-proto_1.13.bb +++ b/meta/recipes-graphics/xorg-proto/xcb-proto_1.14.bb @@ -11,9 +11,9 @@ LICENSE = "MIT" LIC_FILES_CHKSUM = "file://COPYING;md5=d763b081cb10c223435b01e00dc0aba7 \ file://src/dri2.xml;beginline=2;endline=28;md5=f8763b13ff432e8597e0d610cf598e65" -SRC_URI = "http://xcb.freedesktop.org/dist/${BP}.tar.bz2" -SRC_URI[md5sum] = "abe9aa4886138150bbc04ae4f29b90e3" -SRC_URI[sha256sum] = "7b98721e669be80284e9bbfeab02d2d0d54cd11172b72271e47a2fe875e2bde1" +SRC_URI = "http://xcb.freedesktop.org/dist/${BP}.tar.gz" +SRC_URI[md5sum] = "b3e265a6b42d994e3d811a5d0b9ca924" +SRC_URI[sha256sum] = "1c3fa23d091fb5e4f1e9bf145a902161cec00d260fabf880a7a248b02ab27031" inherit autotools pkgconfig python3native -- 2.17.1 From jacob.kroon at gmail.com Mon Mar 16 09:05:49 2020 From: jacob.kroon at gmail.com (Jacob Kroon) Date: Mon, 16 Mar 2020 10:05:49 +0100 Subject: [OE-core] How to skip building kernel modules Message-ID: <74a48760-cfec-a2ff-e50b-ebd5d70ae8d8@gmail.com> Hi, I'm using the linux-yocto kernel recipes together with additional kernel config fragments that I append in our custom distro layer. All required functionality is built into the kernel, so we don't install any kernel modules on target. What would be the correct way to save compilation time and skip building/packaging the kernel modules ? Do I need to provide a custom defconfig that explicitly disables all modules ? I can monkey-patch oe-core with the attached patch in order to achieve that goal, but I'm guessing something like this wouldn't be suitable for upstreaming ? Cheers, Jacob -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Handle-KERNEL_MODULES.patch Type: text/x-patch Size: 1251 bytes Desc: not available URL: From alex.kanavin at gmail.com Mon Mar 16 09:12:49 2020 From: alex.kanavin at gmail.com (Alexander Kanavin) Date: Mon, 16 Mar 2020 10:12:49 +0100 Subject: [OE-core] How to skip building kernel modules In-Reply-To: <74a48760-cfec-a2ff-e50b-ebd5d70ae8d8@gmail.com> References: <74a48760-cfec-a2ff-e50b-ebd5d70ae8d8@gmail.com> Message-ID: The way I read kernel.bbclass, you need to set CONFIG_MODULES=n in your configuration through some mechanism; then they'll be skipped altogether. Alex On Mon, 16 Mar 2020 at 10:06, Jacob Kroon wrote: > Hi, > > I'm using the linux-yocto kernel recipes together with additional kernel > config fragments that I append in our custom distro layer. All required > functionality is built into the kernel, so we don't install any kernel > modules on target. > > What would be the correct way to save compilation time and skip > building/packaging the kernel modules ? Do I need to provide a custom > defconfig that explicitly disables all modules ? > > I can monkey-patch oe-core with the attached patch in order to achieve > that goal, but I'm guessing something like this wouldn't be suitable for > upstreaming ? > > Cheers, > Jacob > > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core at lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jacob.kroon at gmail.com Mon Mar 16 09:22:38 2020 From: jacob.kroon at gmail.com (Jacob Kroon) Date: Mon, 16 Mar 2020 10:22:38 +0100 Subject: [OE-core] How to skip building kernel modules In-Reply-To: References: <74a48760-cfec-a2ff-e50b-ebd5d70ae8d8@gmail.com> Message-ID: On 3/16/20 10:12 AM, Alexander Kanavin wrote: > The way I read kernel.bbclass, you need to set CONFIG_MODULES=n in your > configuration through some mechanism; then they'll be skipped altogether. > > Alex > Yeah, I should have mentioned, setting CONFIG_MODULES=n in a config fragment causes all modules to be built into the kernel, which is not what I want. I've also tried setting do_compile_kernelmodules[noexec] = "1" but that breaks do_install() /Jacob > On Mon, 16 Mar 2020 at 10:06, Jacob Kroon > wrote: > > Hi, > > I'm using the linux-yocto kernel recipes together with additional > kernel > config fragments that I append in our custom distro layer. All required > functionality is built into the kernel, so we don't install any kernel > modules on target. > > What would be the correct way to save compilation time and skip > building/packaging the kernel modules ? Do I need to provide a custom > defconfig that explicitly disables all modules ? > > I can monkey-patch oe-core with the attached patch in order to achieve > that goal, but I'm guessing something like this wouldn't be suitable > for > upstreaming ? > > Cheers, > Jacob > > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core at lists.openembedded.org > > http://lists.openembedded.org/mailman/listinfo/openembedded-core > From mingli.yu at windriver.com Mon Mar 16 09:24:13 2020 From: mingli.yu at windriver.com (mingli.yu at windriver.com) Date: Mon, 16 Mar 2020 17:24:13 +0800 Subject: [OE-core] [PATCH] netbase: use git fetcher Message-ID: <1584350653-141457-1-git-send-email-mingli.yu@windriver.com> From: Mingli Yu Use git repo as the the previous URL only stores the latest source file and fails to locate the source tar file if we don't upgrade timely. Signed-off-by: Mingli Yu --- meta/recipes-core/netbase/netbase_6.1.bb | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/meta/recipes-core/netbase/netbase_6.1.bb b/meta/recipes-core/netbase/netbase_6.1.bb index bc0049c..c13685e 100644 --- a/meta/recipes-core/netbase/netbase_6.1.bb +++ b/meta/recipes-core/netbase/netbase_6.1.bb @@ -6,10 +6,10 @@ LICENSE = "GPLv2" LIC_FILES_CHKSUM = "file://debian/copyright;md5=3dd6192d306f582dee7687da3d8748ab" PE = "1" -SRC_URI = "${DEBIAN_MIRROR}/main/n/${BPN}/${BPN}_${PV}.tar.xz" +SRC_URI = "git://salsa.debian.org/md/netbase.git;protocol=https" +SRCREV = "0fc1e4ce39328f7388badace0aaf7b7294d5ed61" -SRC_URI[md5sum] = "e5871a3a5c8390557b8033cf19316a55" -SRC_URI[sha256sum] = "084d743bd84d4d9380bac4c71c51e57406dce44f5a69289bb823c903e9b035d8" +S = "${WORKDIR}/git" UPSTREAM_CHECK_URI = "${DEBIAN_MIRROR}/main/n/netbase/" do_install () { -- 2.7.4 From brgl at bgdev.pl Mon Mar 16 10:48:39 2020 From: brgl at bgdev.pl (Bartosz Golaszewski) Date: Mon, 16 Mar 2020 11:48:39 +0100 Subject: [OE-core] Solving a circular dependency issue between the main image and initramfs In-Reply-To: References: Message-ID: wt., 10 mar 2020 o 22:23 Bartosz Golaszewski napisa?(a): > > Hi, > > I've been struggling for a while now trying to fix a circular > dependency issue when the initramfs image needs to access an image > file generated by the main (for lack of a better term) image recipe. > > I've tried to fix our downstream layer only to come to the conclusion > that some things must probably be modified upstream to make sense. > Unfortunately when trying different solutions I always arrive at some > kind of circular dependency with the current task order. > > My use-case is the following: > > I'd like to use dm-verity to protect the rootfs from tampering as part > of the verified boot flow. At boot-time the rootfs partition is mapped > using veritysetup from a trusted initramfs stored in a signed > fitImage. This initramfs also contains the root verity hash while the > rest of the hash tree is stored on a different partition. > > The dm-verity meta data is generated from a class[1] I wrote with the > aim of upstreaming it to meta-security as an image conversion of > ext[234] and btrfs images. > > For the sake of clarity of the example let's assume we're generating > an ext4 image for core-image-full-cmdline and set INITRAMFS_IMAGE to > "dm-verity-image-initramfs". > > The veritysetup conversion becomes part of the > core-image-full-cmdline:do_image_ext4 task, while > dm-verity-image-initramfs:do_rootfs needs to depend on > core-image-full-cmdline:do_image_ext4 as it needs to compute the > hashes based on the block device image. It cannot however depend on > core-image-full-cmdline:do_image_complete as it depends on many tasks > (e.g. kernel and u-boot tasks) that would inevitably lead to a > circular dependency. > > The output files from recipes inheriting image.bbclass are not > deployed before do_image_complete nor is anything done in do_install > or do_populate_sysroot (these tasks are flagged noexec or deleted), so > I cannot access them from dm-verity-image-initramfs:do_rootfs. > > As a workaround in the downstream layer I've been manually putting the > verity meta data into the DEPLOY_DIR_IMAGE from > core-image-full-cmdline:do_image_ext4 but this obviously isn't correct > as far as the deploy class and sstate are concerned. > > Now the question is: how do I approach it so that I can eventually > make it part of upstream meta-security? > > Do I implement do_install in image.bbclass so that initramfs can > depend on core-image-full-cmdline:do_populate_sysroot and have the > artifacts installed locally? But this would mean that the initramfs > recipe deploys the main image artifact. Should we deploy the images > earlier (before do_image_complete) for the initramfs recipe to fetch > from DEPLOY_DIR_IMAGE? Any other ideas? > > Best regards, > Bartosz Golaszewski > > [1] https://github.com/brgl/meta-security/blob/topic/verity-et-al/classes/dm-verity-img.bbclass There has been no relevant feedback, but I've been experimenting with various things. I think that the best approach would be to make image artifacts installable into dependant recipes' sysroots (in /usr/share/images/). This way the initramfs recipe could calculate the dm-verity hashes from the resulting ext4 image before it gets deployed. We could also modify the kernel recipe to not fetch the initramfs image from the shared directory but instead have it installed in its sysroot. For this I tried to re-enable the do_install task in image.bbclass. Unfortunately either I'm doing something wrong or standard tasks are subject to different rules when it comes to dependencies. I've been so far unable to make do_install depend on any image tasks (i.e. make do_install depend on do_image_ext4/wic etc.) no matter if I use do_install[depends] or addtask or appropriate helpers from python. Unfortunately I've been unable to find any information on that in the manual. Is there some trick to changing the dependencies of standard tasks? Bartosz From richard.purdie at linuxfoundation.org Mon Mar 16 11:01:46 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Mon, 16 Mar 2020 11:01:46 +0000 Subject: [OE-core] Solving a circular dependency issue between the main image and initramfs In-Reply-To: References: Message-ID: On Mon, 2020-03-16 at 11:48 +0100, Bartosz Golaszewski wrote: > There has been no relevant feedback, but I've been experimenting with > various things. I think that the best approach would be to make image > artifacts installable into dependant recipes' sysroots (in > /usr/share/images/). This way the initramfs recipe could calculate > the > dm-verity hashes from the resulting ext4 image before it gets > deployed. We could also modify the kernel recipe to not fetch the > initramfs image from the shared directory but instead have it > installed in its sysroot. > > For this I tried to re-enable the do_install task in image.bbclass. > Unfortunately either I'm doing something wrong or standard tasks are > subject to different rules when it comes to dependencies. I've been > so > far unable to make do_install depend on any image tasks (i.e. make > do_install depend on do_image_ext4/wic etc.) no matter if I use > do_install[depends] or addtask or appropriate helpers from python. > Unfortunately I've been unable to find any information on that in the > manual. > > Is there some trick to changing the dependencies of standard tasks? I don't know how exactly you're configuring the system but it should be possible to have the main rootfs built first, adding in the signing, then have the initramfs depend on that. I can understand some circular dependencies could creep in as many configurations have the initramfs as part of the main image but if you don't configure that, you shouldn't see those dependencies. I do fear your "re-enable" do_install route isn't going to get you where you want to be. Can you give a simple example of how you reproduce the circular dependencies with standard poky or oe-core? That might let others give comment more easily. Cheers, Richard From andrej.valek at siemens.com Mon Mar 16 12:41:25 2020 From: andrej.valek at siemens.com (Andrej Valek) Date: Mon, 16 Mar 2020 13:41:25 +0100 Subject: [OE-core] [PATCH 0/2] Extensible SDK improvements In-Reply-To: References: <20200306153234.23875-1-andrej.valek@siemens.com> Message-ID: <51dd6bcf-a496-1f0e-5489-471864eba300@siemens.com> Hello Richard, Did you have some time to take a look on it? It would be really helpful to have this feature in. As I said I am trying to use this functionality for write some extra variables into local.conf only in eSDK case. I am using a custom oe-init-buildenv script, means that not all cases are covered by the general one. Thank you, Andrej On 2020-03-09 09:05, Andrej Valek wrote: > Hello Richard, > > I can try to explain it in some examples. > > I would like to add some extra (dynamic) variables into local.conf in > eSDK mode. I have found, that there are 2 possibilities (in > populate_sdk_ext.bbclass) sdk-extra.conf and sdk_extraconf. > > - sdk-extra.conf > - You have to have handle own function to write into sdk-extra.conf. I > think, this is not the right way for me. > - sdk_extraconf > - This variable is fine, but there are some restrictions. There is no > easy way to add multiple variables including values. > > I would like to have: > aaa = "valueA" > bbb = "valueB" > in local.conf file. > > 1. sdk_extraconf = 'aaa = "valueA"\nbbb = "valueB"' > - this will write aaa = "valueA"\nbbb = "valueB" > 2. python copy_buildsystem_prepend() { > d.setVar('sdk_extraconf','aaa = "valueA"\nbbb = "valueB"') > } > - This will write exactly, what you want, but you have to have an > copy_buildsystem_prepend and mentioned all variables with values defined > in your class/recipe. > 3. sdk_extraconf = "# My notes about local.conf" > - Yes, you can write some string into local.conf with this way. > > So I have founded an way, how to add multiple variables without > explicitly specifying their values. > > # format variables for sdk_extraconf > def write_sdk_vars(d): > return '\n' + '\n'.join([var + ' = "' + d.getVar(var) + '"' for var in > d.getVar('SDK_EXTRACONF_VARS').split()]) > > SDK_EXTRACONF_VARS = "aaa bbb" > sdk_extraconf_append = " ${@write_sdk_vars(d)}" > > It will do exactly what I want, but this way is little bit nasty. So I > have created a more complex solution for community usage. > I think, this patch adds more functionality also for other projects. > They can add only variables into list and the class will handle all the > rest. > > Is it enough for the explanation? > > Regards, > Andrej > > On 2020-03-06 18:16, Richard Purdie wrote: >> On Fri, 2020-03-06 at 16:32 +0100, Andrej Valek wrote: >>> "add option to append lines into local.conf": >>> - What about dropping "sdk_extraconf"? >> >> I'm curious what you didn't find useful about the other format and why >> this version is better? >> >> Cheers, >> >> Richard >> From richard.purdie at linuxfoundation.org Mon Mar 16 13:07:45 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Mon, 16 Mar 2020 13:07:45 +0000 Subject: [OE-core] [PATCH 0/2] Extensible SDK improvements In-Reply-To: References: <20200306153234.23875-1-andrej.valek@siemens.com> Message-ID: Hi Andrej, On Mon, 2020-03-09 at 09:05 +0100, Andrej Valek wrote: > I can try to explain it in some examples. > > I would like to add some extra (dynamic) variables into local.conf in > eSDK mode. I have found, that there are 2 possibilities (in > populate_sdk_ext.bbclass) sdk-extra.conf and sdk_extraconf. > > - sdk-extra.conf > - You have to have handle own function to write into sdk-extra.conf. > I > think, this is not the right way for me. > - sdk_extraconf > - This variable is fine, but there are some restrictions. There is > no > easy way to add multiple variables including values. > > I would like to have: > aaa = "valueA" > bbb = "valueB" > in local.conf file. > > 1. sdk_extraconf = 'aaa = "valueA"\nbbb = "valueB"' > - this will write aaa = "valueA"\nbbb = "valueB" > 2. python copy_buildsystem_prepend() { > d.setVar('sdk_extraconf','aaa = "valueA"\nbbb = "valueB"') > } > - This will write exactly, what you want, but you have to have an > copy_buildsystem_prepend and mentioned all variables with values > defined in your class/recipe. Why do you have to set this in a copy_buildsystem_prepend ? Shouldn't setting the variable in your distro config or class or somewhere else work? > 3. sdk_extraconf = "# My notes about local.conf" > - Yes, you can write some string into local.conf with this way. I suspect you can also do: sdk_extraconf () { # My notes about local.conf aaa = "valueA" bbb = "valueB" } or something like that, I admit I've not tested it though. > So I have founded an way, how to add multiple variables without > explicitly specifying their values. > > # format variables for sdk_extraconf > def write_sdk_vars(d): > return '\n' + '\n'.join([var + ' = "' + d.getVar(var) + '"' for var > in > d.getVar('SDK_EXTRACONF_VARS').split()]) > > SDK_EXTRACONF_VARS = "aaa bbb" > sdk_extraconf_append = " ${@write_sdk_vars(d)}" > > It will do exactly what I want, but this way is little bit nasty. So > I have created a more complex solution for community usage. > I think, this patch adds more functionality also for other projects. > They can add only variables into list and the class will handle all > the > rest. I do see the problem with expansion. I suspect the code in populate_sdk_ext should be: extraconf = (d.getVar('sdk_extraconf', False) or '').strip() instead of: extraconf = (d.getVar('sdk_extraconf') or '').strip() so that variables can be used as part of the expressions. It may be our change to the defaults for getVar messed this up, or it may be we just didn't correctly predict this problem. > Is it enough for the explanation? It helps, yes, thanks. What I don't want to do is add multiple confusing mechanisms which do approximately the same thing slightly differently. I'd much prefer one mechanism most people can use. As such the original proposal still concerns me. I'd prefer to tweak one of the existing ones (even merge them!) rather than add a third slightly different one. I do also still think some (but not all) of what you're describing should be in your distro/classes rather than local.conf. Is there a way we can improve the current code rather than adding more options. Would the expansion change be enough? Cheers, Richard From jonathan.rajotte-julien at efficios.com Mon Mar 16 13:17:04 2020 From: jonathan.rajotte-julien at efficios.com (Jonathan Rajotte-Julien) Date: Mon, 16 Mar 2020 09:17:04 -0400 Subject: [OE-core] [PATCH 1/2] babletrace2: make manpages multilib identical In-Reply-To: References: <20200311222249.29880-1-jpuhlman@mvista.com> <20200312142524.GB30953@joraj-alpa> Message-ID: <20200316131704.GA5753@joraj-alpa> On Fri, Mar 13, 2020 at 07:22:03AM +0000, Richard Purdie wrote: > On Thu, 2020-03-12 at 10:25 -0400, Jonathan Rajotte-Julien wrote: > > Is this something upstream (lttng-dev mailing list) should be > > interested in? > > Its a tough one as the man page is technically correct but the > references give us a challenge in packaging it. I can therefore > understand upstreams not accepting changes like this but if they were > open to some kind of tweak it does help us not have to have patches... Jeremy does plan to send us a version for upstream (bt2) someday, or at least start the discussion on how to help yocto packaging on that end. We will see how we can make everyone happy then. Cheers -- Jonathan Rajotte-Julien EfficiOS From ernst.sjostrand at verisure.com Mon Mar 16 14:02:56 2020 From: ernst.sjostrand at verisure.com (=?utf-8?B?RXJuc3QgU2rDtnN0cmFuZA==?=) Date: Mon, 16 Mar 2020 14:02:56 +0000 Subject: [OE-core] Solving a circular dependency issue between the main image and initramfs In-Reply-To: References: Message-ID: Hi! I have done something very similar, here's what I did. My ramdisk is just a vanilla cpio. My kernel is just vanilla zImage. My main image does "inherit magic" and magic.bbclass does something like this, where create_custom_fitimage has a lot of kernel-fitimage.bbclass copied out. do_magic () { create_custom_fitimage install fitImage.bin ${IMAGE_ROOTFS}/boot/fitImage } do_magic[depends] += "my-ramdisk:do_image_complete virtual/kernel" addtask magic before do_image after do_pre_image_task It does read a lot of stuff from deploy but so does the main kernel-fitimage.bbclass so I don't think that's a problem. Regards //Ernst On Tue, 2020-03-10 at 22:23 +0100, Bartosz Golaszewski wrote: Hi, I've been struggling for a while now trying to fix a circular dependency issue when the initramfs image needs to access an image file generated by the main (for lack of a better term) image recipe. I've tried to fix our downstream layer only to come to the conclusion that some things must probably be modified upstream to make sense. Unfortunately when trying different solutions I always arrive at some kind of circular dependency with the current task order. My use-case is the following: I'd like to use dm-verity to protect the rootfs from tampering as part of the verified boot flow. At boot-time the rootfs partition is mapped using veritysetup from a trusted initramfs stored in a signed fitImage. This initramfs also contains the root verity hash while the rest of the hash tree is stored on a different partition. The dm-verity meta data is generated from a class[1] I wrote with the aim of upstreaming it to meta-security as an image conversion of ext[234] and btrfs images. For the sake of clarity of the example let's assume we're generating an ext4 image for core-image-full-cmdline and set INITRAMFS_IMAGE to "dm-verity-image-initramfs". The veritysetup conversion becomes part of the core-image-full-cmdline:do_image_ext4 task, while dm-verity-image-initramfs:do_rootfs needs to depend on core-image-full-cmdline:do_image_ext4 as it needs to compute the hashes based on the block device image. It cannot however depend on core-image-full-cmdline:do_image_complete as it depends on many tasks (e.g. kernel and u-boot tasks) that would inevitably lead to a circular dependency. The output files from recipes inheriting image.bbclass are not deployed before do_image_complete nor is anything done in do_install or do_populate_sysroot (these tasks are flagged noexec or deleted), so I cannot access them from dm-verity-image-initramfs:do_rootfs. As a workaround in the downstream layer I've been manually putting the verity meta data into the DEPLOY_DIR_IMAGE from core-image-full-cmdline:do_image_ext4 but this obviously isn't correct as far as the deploy class and sstate are concerned. Now the question is: how do I approach it so that I can eventually make it part of upstream meta-security? Do I implement do_install in image.bbclass so that initramfs can depend on core-image-full-cmdline:do_populate_sysroot and have the artifacts installed locally? But this would mean that the initramfs recipe deploys the main image artifact. Should we deploy the images earlier (before do_image_complete) for the initramfs recipe to fetch from DEPLOY_DIR_IMAGE? Any other ideas? Best regards, Bartosz Golaszewski [1] https://urldefense.com/v3/__https://github.com/brgl/meta-security/blob/topic/verity-et-al/classes/dm-verity-img.bbclass__;!!BFCLnRDDbM3FOmw!txpeOwM3etV4NJvGfflIsSW7V8RsvhhLNrDSJLj0iliKoiEm8Iu2Tf0NDsJyJVDxIcZFIg$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrei at gherzan.ro Mon Mar 16 15:28:20 2020 From: andrei at gherzan.ro (Andrei Gherzan) Date: Mon, 16 Mar 2020 15:28:20 +0000 Subject: [OE-core] [PATCH] wic/bootimg-efi: Respect fixed partition size Message-ID: <20200316152820.23437-1-andrei@gherzan.ro> Signed-off-by: Andrei Gherzan --- scripts/lib/wic/plugins/source/bootimg-efi.py | 21 +++++++++++-------- 1 file changed, 12 insertions(+), 9 deletions(-) diff --git a/scripts/lib/wic/plugins/source/bootimg-efi.py b/scripts/lib/wic/plugins/source/bootimg-efi.py index 2cfdc10ecd..6c3d7b8491 100644 --- a/scripts/lib/wic/plugins/source/bootimg-efi.py +++ b/scripts/lib/wic/plugins/source/bootimg-efi.py @@ -263,19 +263,22 @@ class BootimgEFIPlugin(SourcePlugin): cp_cmd = "cp %s %s/" % (startup, hdddir) exec_cmd(cp_cmd, True) - du_cmd = "du -bks %s" % hdddir - out = exec_cmd(du_cmd) - blocks = int(out.split()[0]) + if part.fixed-size: + blocks = part.fixed_size + else: + du_cmd = "du -bks %s" % hdddir + out = exec_cmd(du_cmd) + blocks = int(out.split()[0]) - extra_blocks = part.get_extra_block_count(blocks) + extra_blocks = part.get_extra_block_count(blocks) - if extra_blocks < BOOTDD_EXTRA_SPACE: - extra_blocks = BOOTDD_EXTRA_SPACE + if extra_blocks < BOOTDD_EXTRA_SPACE: + extra_blocks = BOOTDD_EXTRA_SPACE - blocks += extra_blocks + blocks += extra_blocks - logger.debug("Added %d extra blocks to %s to get to %d total blocks", - extra_blocks, part.mountpoint, blocks) + logger.debug("Added %d extra blocks to %s to get to %d total blocks", + extra_blocks, part.mountpoint, blocks) # dosfs image, created by mkdosfs bootimg = "%s/boot.img" % cr_workdir -- 2.17.1 From anuj.mittal at intel.com Mon Mar 16 16:30:58 2020 From: anuj.mittal at intel.com (Anuj Mittal) Date: Tue, 17 Mar 2020 00:30:58 +0800 Subject: [OE-core] [PATCH][zeus 0/7] zeus review Message-ID: This series includes some CVE fixes for zeus. Please review. Thanks, Anuj The following changes since commit d8cfc309f9dd0dc8904ab18e5898770502ee2540: cve-check: fix ValueError (2020-03-15 13:33:19 -0700) are available in the Git repository at: git://push.openembedded.org/openembedded-core-contrib anujm/zeus Adrian Bunk (1): python3: Upgrade 3.7.6 -> 3.7.7 Anuj Mittal (1): bluez: fix CVE-2020-0556 Lee Chee Yang (2): qemu: fix CVE-2019-20382 libpcre2: fix CVE-2019-20454 Ross Burton (1): sqlite: fix numerous CVEs Stefan Ghinea (1): aspell: CVE-2019-20433 Wenlin Kang (1): libarchive: Fix CVE-2020-9308 meta/recipes-connectivity/bluez5/bluez5.inc | 2 + .../bluez5/bluez5/CVE-2020-0556-1.patch | 35 + .../bluez5/bluez5/CVE-2020-0556-2.patch | 143 +++ .../{python3_3.7.6.bb => python3_3.7.7.bb} | 6 +- meta/recipes-devtools/qemu/qemu.inc | 1 + .../qemu/qemu/CVE-2019-20382.patch | 1018 +++++++++++++++++ ...ct-files-that-declare-invalid-header.patch | 124 ++ .../libarchive/libarchive_3.4.0.bb | 1 + .../aspell/aspell/CVE-2019-20433-0001.patch | 999 ++++++++++++++++ .../aspell/aspell/CVE-2019-20433-0002.patch | 68 ++ meta/recipes-support/aspell/aspell_0.60.7.bb | 2 + .../libpcre/libpcre2/CVE-2019-20454.patch | 19 + .../recipes-support/libpcre/libpcre2_10.33.bb | 1 + .../sqlite/sqlite3/CVE-2019-19244.patch | 33 + .../sqlite/sqlite3/CVE-2019-19923.patch | 50 + .../sqlite/sqlite3/CVE-2019-19924.patch | 65 ++ .../sqlite/sqlite3/CVE-2019-19925.patch | 33 + .../sqlite/sqlite3/CVE-2019-19926.patch | 31 + .../sqlite/sqlite3/CVE-2019-19959.patch | 46 + .../sqlite/sqlite3/CVE-2019-20218.patch | 31 + meta/recipes-support/sqlite/sqlite3_3.29.0.bb | 10 +- 21 files changed, 2714 insertions(+), 4 deletions(-) create mode 100644 meta/recipes-connectivity/bluez5/bluez5/CVE-2020-0556-1.patch create mode 100644 meta/recipes-connectivity/bluez5/bluez5/CVE-2020-0556-2.patch rename meta/recipes-devtools/python/{python3_3.7.6.bb => python3_3.7.7.bb} (98%) create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2019-20382.patch create mode 100644 meta/recipes-extended/libarchive/libarchive/0001-RAR5-reader-reject-files-that-declare-invalid-header.patch create mode 100644 meta/recipes-support/aspell/aspell/CVE-2019-20433-0001.patch create mode 100644 meta/recipes-support/aspell/aspell/CVE-2019-20433-0002.patch create mode 100644 meta/recipes-support/libpcre/libpcre2/CVE-2019-20454.patch create mode 100644 meta/recipes-support/sqlite/sqlite3/CVE-2019-19244.patch create mode 100644 meta/recipes-support/sqlite/sqlite3/CVE-2019-19923.patch create mode 100644 meta/recipes-support/sqlite/sqlite3/CVE-2019-19924.patch create mode 100644 meta/recipes-support/sqlite/sqlite3/CVE-2019-19925.patch create mode 100644 meta/recipes-support/sqlite/sqlite3/CVE-2019-19926.patch create mode 100644 meta/recipes-support/sqlite/sqlite3/CVE-2019-19959.patch create mode 100644 meta/recipes-support/sqlite/sqlite3/CVE-2019-20218.patch -- 2.24.1 From anuj.mittal at intel.com Mon Mar 16 16:30:59 2020 From: anuj.mittal at intel.com (Anuj Mittal) Date: Tue, 17 Mar 2020 00:30:59 +0800 Subject: [OE-core] [PATCH][zeus 1/7] qemu: fix CVE-2019-20382 In-Reply-To: References: Message-ID: From: Lee Chee Yang Signed-off-by: Lee Chee Yang Signed-off-by: Anuj Mittal --- meta/recipes-devtools/qemu/qemu.inc | 1 + .../qemu/qemu/CVE-2019-20382.patch | 1018 +++++++++++++++++ 2 files changed, 1019 insertions(+) create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2019-20382.patch diff --git a/meta/recipes-devtools/qemu/qemu.inc b/meta/recipes-devtools/qemu/qemu.inc index d394db8a41..f451017f6d 100644 --- a/meta/recipes-devtools/qemu/qemu.inc +++ b/meta/recipes-devtools/qemu/qemu.inc @@ -30,6 +30,7 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \ file://CVE-2019-15890.patch \ file://CVE-2019-12068.patch \ file://CVE-2020-1711.patch \ + file://CVE-2019-20382.patch \ " UPSTREAM_CHECK_REGEX = "qemu-(?P\d+(\.\d+)+)\.tar" diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2019-20382.patch b/meta/recipes-devtools/qemu/qemu/CVE-2019-20382.patch new file mode 100644 index 0000000000..183d100398 --- /dev/null +++ b/meta/recipes-devtools/qemu/qemu/CVE-2019-20382.patch @@ -0,0 +1,1018 @@ +From 6bf21f3d83e95bcc4ba35a7a07cc6655e8b010b0 Mon Sep 17 00:00:00 2001 +From: Li Qiang +Date: Sat, 31 Aug 2019 08:39:22 -0700 +Subject: [PATCH] vnc: fix memory leak when vnc disconnect + +Currently when qemu receives a vnc connect, it creates a 'VncState' to +represent this connection. In 'vnc_worker_thread_loop' it creates a +local 'VncState'. The connection 'VcnState' and local 'VncState' exchange +data in 'vnc_async_encoding_start' and 'vnc_async_encoding_end'. +In 'zrle_compress_data' it calls 'deflateInit2' to allocate the libz library +opaque data. The 'VncState' used in 'zrle_compress_data' is the local +'VncState'. In 'vnc_zrle_clear' it calls 'deflateEnd' to free the libz +library opaque data. The 'VncState' used in 'vnc_zrle_clear' is the connection +'VncState'. In currently implementation there will be a memory leak when the +vnc disconnect. Following is the asan output backtrack: + +Direct leak of 29760 byte(s) in 5 object(s) allocated from: + 0 0xffffa67ef3c3 in __interceptor_calloc (/lib64/libasan.so.4+0xd33c3) + 1 0xffffa65071cb in g_malloc0 (/lib64/libglib-2.0.so.0+0x571cb) + 2 0xffffa5e968f7 in deflateInit2_ (/lib64/libz.so.1+0x78f7) + 3 0xaaaacec58613 in zrle_compress_data ui/vnc-enc-zrle.c:87 + 4 0xaaaacec58613 in zrle_send_framebuffer_update ui/vnc-enc-zrle.c:344 + 5 0xaaaacec34e77 in vnc_send_framebuffer_update ui/vnc.c:919 + 6 0xaaaacec5e023 in vnc_worker_thread_loop ui/vnc-jobs.c:271 + 7 0xaaaacec5e5e7 in vnc_worker_thread ui/vnc-jobs.c:340 + 8 0xaaaacee4d3c3 in qemu_thread_start util/qemu-thread-posix.c:502 + 9 0xffffa544e8bb in start_thread (/lib64/libpthread.so.0+0x78bb) + 10 0xffffa53965cb in thread_start (/lib64/libc.so.6+0xd55cb) + +This is because the opaque allocated in 'deflateInit2' is not freed in +'deflateEnd'. The reason is that the 'deflateEnd' calls 'deflateStateCheck' +and in the latter will check whether 's->strm != strm'(libz's data structure). +This check will be true so in 'deflateEnd' it just return 'Z_STREAM_ERROR' and +not free the data allocated in 'deflateInit2'. + +The reason this happens is that the 'VncState' contains the whole 'VncZrle', +so when calling 'deflateInit2', the 's->strm' will be the local address. +So 's->strm != strm' will be true. + +To fix this issue, we need to make 'zrle' of 'VncState' to be a pointer. +Then the connection 'VncState' and local 'VncState' exchange mechanism will +work as expection. The 'tight' of 'VncState' has the same issue, let's also turn +it to a pointer. + +Reported-by: Ying Fang +Signed-off-by: Li Qiang +Message-id: 20190831153922.121308-1-liq3ea at 163.com +Signed-off-by: Gerd Hoffmann + +Upstream-Status: Backport [https://git.qemu.org/?p=qemu.git;a=commit;h=6bf21f3d83e95bcc4ba35a7a07cc6655e8b010b0] +CVE: CVE-2019-20382 +Signed-off-by: Lee Chee Yang + +--- + ui/vnc-enc-tight.c | 219 +++++++++++++++++++++++++------------------------- + ui/vnc-enc-zlib.c | 11 +-- + ui/vnc-enc-zrle.c | 68 ++++++++-------- + ui/vnc-enc-zrle.inc.c | 2 +- + ui/vnc.c | 28 ++++--- + ui/vnc.h | 4 +- + 6 files changed, 170 insertions(+), 162 deletions(-) + +diff --git a/ui/vnc-enc-tight.c b/ui/vnc-enc-tight.c +index 9084c22..1e08518 100644 +--- a/ui/vnc-enc-tight.c ++++ b/ui/vnc-enc-tight.c +@@ -116,7 +116,7 @@ static int send_png_rect(VncState *vs, int x, int y, int w, int h, + + static bool tight_can_send_png_rect(VncState *vs, int w, int h) + { +- if (vs->tight.type != VNC_ENCODING_TIGHT_PNG) { ++ if (vs->tight->type != VNC_ENCODING_TIGHT_PNG) { + return false; + } + +@@ -144,7 +144,7 @@ tight_detect_smooth_image24(VncState *vs, int w, int h) + int pixels = 0; + int pix, left[3]; + unsigned int errors; +- unsigned char *buf = vs->tight.tight.buffer; ++ unsigned char *buf = vs->tight->tight.buffer; + + /* + * If client is big-endian, color samples begin from the second +@@ -215,7 +215,7 @@ tight_detect_smooth_image24(VncState *vs, int w, int h) + int pixels = 0; \ + int sample, sum, left[3]; \ + unsigned int errors; \ +- unsigned char *buf = vs->tight.tight.buffer; \ ++ unsigned char *buf = vs->tight->tight.buffer; \ + \ + endian = 0; /* FIXME */ \ + \ +@@ -296,8 +296,8 @@ static int + tight_detect_smooth_image(VncState *vs, int w, int h) + { + unsigned int errors; +- int compression = vs->tight.compression; +- int quality = vs->tight.quality; ++ int compression = vs->tight->compression; ++ int quality = vs->tight->quality; + + if (!vs->vd->lossy) { + return 0; +@@ -309,7 +309,7 @@ tight_detect_smooth_image(VncState *vs, int w, int h) + return 0; + } + +- if (vs->tight.quality != (uint8_t)-1) { ++ if (vs->tight->quality != (uint8_t)-1) { + if (w * h < VNC_TIGHT_JPEG_MIN_RECT_SIZE) { + return 0; + } +@@ -320,9 +320,9 @@ tight_detect_smooth_image(VncState *vs, int w, int h) + } + + if (vs->client_pf.bytes_per_pixel == 4) { +- if (vs->tight.pixel24) { ++ if (vs->tight->pixel24) { + errors = tight_detect_smooth_image24(vs, w, h); +- if (vs->tight.quality != (uint8_t)-1) { ++ if (vs->tight->quality != (uint8_t)-1) { + return (errors < tight_conf[quality].jpeg_threshold24); + } + return (errors < tight_conf[compression].gradient_threshold24); +@@ -352,7 +352,7 @@ tight_detect_smooth_image(VncState *vs, int w, int h) + uint##bpp##_t c0, c1, ci; \ + int i, n0, n1; \ + \ +- data = (uint##bpp##_t *)vs->tight.tight.buffer; \ ++ data = (uint##bpp##_t *)vs->tight->tight.buffer; \ + \ + c0 = data[0]; \ + i = 1; \ +@@ -423,9 +423,9 @@ static int tight_fill_palette(VncState *vs, int x, int y, + { + int max; + +- max = count / tight_conf[vs->tight.compression].idx_max_colors_divisor; ++ max = count / tight_conf[vs->tight->compression].idx_max_colors_divisor; + if (max < 2 && +- count >= tight_conf[vs->tight.compression].mono_min_rect_size) { ++ count >= tight_conf[vs->tight->compression].mono_min_rect_size) { + max = 2; + } + if (max >= 256) { +@@ -558,7 +558,7 @@ tight_filter_gradient24(VncState *vs, uint8_t *buf, int w, int h) + int x, y, c; + + buf32 = (uint32_t *)buf; +- memset(vs->tight.gradient.buffer, 0, w * 3 * sizeof(int)); ++ memset(vs->tight->gradient.buffer, 0, w * 3 * sizeof(int)); + + if (1 /* FIXME */) { + shift[0] = vs->client_pf.rshift; +@@ -575,7 +575,7 @@ tight_filter_gradient24(VncState *vs, uint8_t *buf, int w, int h) + upper[c] = 0; + here[c] = 0; + } +- prev = (int *)vs->tight.gradient.buffer; ++ prev = (int *)vs->tight->gradient.buffer; + for (x = 0; x < w; x++) { + pix32 = *buf32++; + for (c = 0; c < 3; c++) { +@@ -615,7 +615,7 @@ tight_filter_gradient24(VncState *vs, uint8_t *buf, int w, int h) + int prediction; \ + int x, y, c; \ + \ +- memset (vs->tight.gradient.buffer, 0, w * 3 * sizeof(int)); \ ++ memset(vs->tight->gradient.buffer, 0, w * 3 * sizeof(int)); \ + \ + endian = 0; /* FIXME */ \ + \ +@@ -631,7 +631,7 @@ tight_filter_gradient24(VncState *vs, uint8_t *buf, int w, int h) + upper[c] = 0; \ + here[c] = 0; \ + } \ +- prev = (int *)vs->tight.gradient.buffer; \ ++ prev = (int *)vs->tight->gradient.buffer; \ + for (x = 0; x < w; x++) { \ + pix = *buf; \ + if (endian) { \ +@@ -785,7 +785,7 @@ static void extend_solid_area(VncState *vs, int x, int y, int w, int h, + static int tight_init_stream(VncState *vs, int stream_id, + int level, int strategy) + { +- z_streamp zstream = &vs->tight.stream[stream_id]; ++ z_streamp zstream = &vs->tight->stream[stream_id]; + + if (zstream->opaque == NULL) { + int err; +@@ -803,15 +803,15 @@ static int tight_init_stream(VncState *vs, int stream_id, + return -1; + } + +- vs->tight.levels[stream_id] = level; ++ vs->tight->levels[stream_id] = level; + zstream->opaque = vs; + } + +- if (vs->tight.levels[stream_id] != level) { ++ if (vs->tight->levels[stream_id] != level) { + if (deflateParams(zstream, level, strategy) != Z_OK) { + return -1; + } +- vs->tight.levels[stream_id] = level; ++ vs->tight->levels[stream_id] = level; + } + return 0; + } +@@ -839,11 +839,11 @@ static void tight_send_compact_size(VncState *vs, size_t len) + static int tight_compress_data(VncState *vs, int stream_id, size_t bytes, + int level, int strategy) + { +- z_streamp zstream = &vs->tight.stream[stream_id]; ++ z_streamp zstream = &vs->tight->stream[stream_id]; + int previous_out; + + if (bytes < VNC_TIGHT_MIN_TO_COMPRESS) { +- vnc_write(vs, vs->tight.tight.buffer, vs->tight.tight.offset); ++ vnc_write(vs, vs->tight->tight.buffer, vs->tight->tight.offset); + return bytes; + } + +@@ -852,13 +852,13 @@ static int tight_compress_data(VncState *vs, int stream_id, size_t bytes, + } + + /* reserve memory in output buffer */ +- buffer_reserve(&vs->tight.zlib, bytes + 64); ++ buffer_reserve(&vs->tight->zlib, bytes + 64); + + /* set pointers */ +- zstream->next_in = vs->tight.tight.buffer; +- zstream->avail_in = vs->tight.tight.offset; +- zstream->next_out = vs->tight.zlib.buffer + vs->tight.zlib.offset; +- zstream->avail_out = vs->tight.zlib.capacity - vs->tight.zlib.offset; ++ zstream->next_in = vs->tight->tight.buffer; ++ zstream->avail_in = vs->tight->tight.offset; ++ zstream->next_out = vs->tight->zlib.buffer + vs->tight->zlib.offset; ++ zstream->avail_out = vs->tight->zlib.capacity - vs->tight->zlib.offset; + previous_out = zstream->avail_out; + zstream->data_type = Z_BINARY; + +@@ -868,14 +868,14 @@ static int tight_compress_data(VncState *vs, int stream_id, size_t bytes, + return -1; + } + +- vs->tight.zlib.offset = vs->tight.zlib.capacity - zstream->avail_out; ++ vs->tight->zlib.offset = vs->tight->zlib.capacity - zstream->avail_out; + /* ...how much data has actually been produced by deflate() */ + bytes = previous_out - zstream->avail_out; + + tight_send_compact_size(vs, bytes); +- vnc_write(vs, vs->tight.zlib.buffer, bytes); ++ vnc_write(vs, vs->tight->zlib.buffer, bytes); + +- buffer_reset(&vs->tight.zlib); ++ buffer_reset(&vs->tight->zlib); + + return bytes; + } +@@ -927,16 +927,17 @@ static int send_full_color_rect(VncState *vs, int x, int y, int w, int h) + + vnc_write_u8(vs, stream << 4); /* no flushing, no filter */ + +- if (vs->tight.pixel24) { +- tight_pack24(vs, vs->tight.tight.buffer, w * h, &vs->tight.tight.offset); ++ if (vs->tight->pixel24) { ++ tight_pack24(vs, vs->tight->tight.buffer, w * h, ++ &vs->tight->tight.offset); + bytes = 3; + } else { + bytes = vs->client_pf.bytes_per_pixel; + } + + bytes = tight_compress_data(vs, stream, w * h * bytes, +- tight_conf[vs->tight.compression].raw_zlib_level, +- Z_DEFAULT_STRATEGY); ++ tight_conf[vs->tight->compression].raw_zlib_level, ++ Z_DEFAULT_STRATEGY); + + return (bytes >= 0); + } +@@ -947,14 +948,14 @@ static int send_solid_rect(VncState *vs) + + vnc_write_u8(vs, VNC_TIGHT_FILL << 4); /* no flushing, no filter */ + +- if (vs->tight.pixel24) { +- tight_pack24(vs, vs->tight.tight.buffer, 1, &vs->tight.tight.offset); ++ if (vs->tight->pixel24) { ++ tight_pack24(vs, vs->tight->tight.buffer, 1, &vs->tight->tight.offset); + bytes = 3; + } else { + bytes = vs->client_pf.bytes_per_pixel; + } + +- vnc_write(vs, vs->tight.tight.buffer, bytes); ++ vnc_write(vs, vs->tight->tight.buffer, bytes); + return 1; + } + +@@ -963,7 +964,7 @@ static int send_mono_rect(VncState *vs, int x, int y, + { + ssize_t bytes; + int stream = 1; +- int level = tight_conf[vs->tight.compression].mono_zlib_level; ++ int level = tight_conf[vs->tight->compression].mono_zlib_level; + + #ifdef CONFIG_VNC_PNG + if (tight_can_send_png_rect(vs, w, h)) { +@@ -991,26 +992,26 @@ static int send_mono_rect(VncState *vs, int x, int y, + uint32_t buf[2] = {bg, fg}; + size_t ret = sizeof (buf); + +- if (vs->tight.pixel24) { ++ if (vs->tight->pixel24) { + tight_pack24(vs, (unsigned char*)buf, 2, &ret); + } + vnc_write(vs, buf, ret); + +- tight_encode_mono_rect32(vs->tight.tight.buffer, w, h, bg, fg); ++ tight_encode_mono_rect32(vs->tight->tight.buffer, w, h, bg, fg); + break; + } + case 2: + vnc_write(vs, &bg, 2); + vnc_write(vs, &fg, 2); +- tight_encode_mono_rect16(vs->tight.tight.buffer, w, h, bg, fg); ++ tight_encode_mono_rect16(vs->tight->tight.buffer, w, h, bg, fg); + break; + default: + vnc_write_u8(vs, bg); + vnc_write_u8(vs, fg); +- tight_encode_mono_rect8(vs->tight.tight.buffer, w, h, bg, fg); ++ tight_encode_mono_rect8(vs->tight->tight.buffer, w, h, bg, fg); + break; + } +- vs->tight.tight.offset = bytes; ++ vs->tight->tight.offset = bytes; + + bytes = tight_compress_data(vs, stream, bytes, level, Z_DEFAULT_STRATEGY); + return (bytes >= 0); +@@ -1040,7 +1041,7 @@ static void write_palette(int idx, uint32_t color, void *opaque) + static bool send_gradient_rect(VncState *vs, int x, int y, int w, int h) + { + int stream = 3; +- int level = tight_conf[vs->tight.compression].gradient_zlib_level; ++ int level = tight_conf[vs->tight->compression].gradient_zlib_level; + ssize_t bytes; + + if (vs->client_pf.bytes_per_pixel == 1) { +@@ -1050,23 +1051,23 @@ static bool send_gradient_rect(VncState *vs, int x, int y, int w, int h) + vnc_write_u8(vs, (stream | VNC_TIGHT_EXPLICIT_FILTER) << 4); + vnc_write_u8(vs, VNC_TIGHT_FILTER_GRADIENT); + +- buffer_reserve(&vs->tight.gradient, w * 3 * sizeof (int)); ++ buffer_reserve(&vs->tight->gradient, w * 3 * sizeof(int)); + +- if (vs->tight.pixel24) { +- tight_filter_gradient24(vs, vs->tight.tight.buffer, w, h); ++ if (vs->tight->pixel24) { ++ tight_filter_gradient24(vs, vs->tight->tight.buffer, w, h); + bytes = 3; + } else if (vs->client_pf.bytes_per_pixel == 4) { +- tight_filter_gradient32(vs, (uint32_t *)vs->tight.tight.buffer, w, h); ++ tight_filter_gradient32(vs, (uint32_t *)vs->tight->tight.buffer, w, h); + bytes = 4; + } else { +- tight_filter_gradient16(vs, (uint16_t *)vs->tight.tight.buffer, w, h); ++ tight_filter_gradient16(vs, (uint16_t *)vs->tight->tight.buffer, w, h); + bytes = 2; + } + +- buffer_reset(&vs->tight.gradient); ++ buffer_reset(&vs->tight->gradient); + + bytes = w * h * bytes; +- vs->tight.tight.offset = bytes; ++ vs->tight->tight.offset = bytes; + + bytes = tight_compress_data(vs, stream, bytes, + level, Z_FILTERED); +@@ -1077,7 +1078,7 @@ static int send_palette_rect(VncState *vs, int x, int y, + int w, int h, VncPalette *palette) + { + int stream = 2; +- int level = tight_conf[vs->tight.compression].idx_zlib_level; ++ int level = tight_conf[vs->tight->compression].idx_zlib_level; + int colors; + ssize_t bytes; + +@@ -1104,12 +1105,12 @@ static int send_palette_rect(VncState *vs, int x, int y, + palette_iter(palette, write_palette, &priv); + vnc_write(vs, header, sizeof(header)); + +- if (vs->tight.pixel24) { ++ if (vs->tight->pixel24) { + tight_pack24(vs, vs->output.buffer + old_offset, colors, &offset); + vs->output.offset = old_offset + offset; + } + +- tight_encode_indexed_rect32(vs->tight.tight.buffer, w * h, palette); ++ tight_encode_indexed_rect32(vs->tight->tight.buffer, w * h, palette); + break; + } + case 2: +@@ -1119,7 +1120,7 @@ static int send_palette_rect(VncState *vs, int x, int y, + + palette_iter(palette, write_palette, &priv); + vnc_write(vs, header, sizeof(header)); +- tight_encode_indexed_rect16(vs->tight.tight.buffer, w * h, palette); ++ tight_encode_indexed_rect16(vs->tight->tight.buffer, w * h, palette); + break; + } + default: +@@ -1127,7 +1128,7 @@ static int send_palette_rect(VncState *vs, int x, int y, + break; + } + bytes = w * h; +- vs->tight.tight.offset = bytes; ++ vs->tight->tight.offset = bytes; + + bytes = tight_compress_data(vs, stream, bytes, + level, Z_DEFAULT_STRATEGY); +@@ -1146,7 +1147,7 @@ static int send_palette_rect(VncState *vs, int x, int y, + static void jpeg_init_destination(j_compress_ptr cinfo) + { + VncState *vs = cinfo->client_data; +- Buffer *buffer = &vs->tight.jpeg; ++ Buffer *buffer = &vs->tight->jpeg; + + cinfo->dest->next_output_byte = (JOCTET *)buffer->buffer + buffer->offset; + cinfo->dest->free_in_buffer = (size_t)(buffer->capacity - buffer->offset); +@@ -1156,7 +1157,7 @@ static void jpeg_init_destination(j_compress_ptr cinfo) + static boolean jpeg_empty_output_buffer(j_compress_ptr cinfo) + { + VncState *vs = cinfo->client_data; +- Buffer *buffer = &vs->tight.jpeg; ++ Buffer *buffer = &vs->tight->jpeg; + + buffer->offset = buffer->capacity; + buffer_reserve(buffer, 2048); +@@ -1168,7 +1169,7 @@ static boolean jpeg_empty_output_buffer(j_compress_ptr cinfo) + static void jpeg_term_destination(j_compress_ptr cinfo) + { + VncState *vs = cinfo->client_data; +- Buffer *buffer = &vs->tight.jpeg; ++ Buffer *buffer = &vs->tight->jpeg; + + buffer->offset = buffer->capacity - cinfo->dest->free_in_buffer; + } +@@ -1187,7 +1188,7 @@ static int send_jpeg_rect(VncState *vs, int x, int y, int w, int h, int quality) + return send_full_color_rect(vs, x, y, w, h); + } + +- buffer_reserve(&vs->tight.jpeg, 2048); ++ buffer_reserve(&vs->tight->jpeg, 2048); + + cinfo.err = jpeg_std_error(&jerr); + jpeg_create_compress(&cinfo); +@@ -1222,9 +1223,9 @@ static int send_jpeg_rect(VncState *vs, int x, int y, int w, int h, int quality) + + vnc_write_u8(vs, VNC_TIGHT_JPEG << 4); + +- tight_send_compact_size(vs, vs->tight.jpeg.offset); +- vnc_write(vs, vs->tight.jpeg.buffer, vs->tight.jpeg.offset); +- buffer_reset(&vs->tight.jpeg); ++ tight_send_compact_size(vs, vs->tight->jpeg.offset); ++ vnc_write(vs, vs->tight->jpeg.buffer, vs->tight->jpeg.offset); ++ buffer_reset(&vs->tight->jpeg); + + return 1; + } +@@ -1240,7 +1241,7 @@ static void write_png_palette(int idx, uint32_t pix, void *opaque) + VncState *vs = priv->vs; + png_colorp color = &priv->png_palette[idx]; + +- if (vs->tight.pixel24) ++ if (vs->tight->pixel24) + { + color->red = (pix >> vs->client_pf.rshift) & vs->client_pf.rmax; + color->green = (pix >> vs->client_pf.gshift) & vs->client_pf.gmax; +@@ -1267,10 +1268,10 @@ static void png_write_data(png_structp png_ptr, png_bytep data, + { + VncState *vs = png_get_io_ptr(png_ptr); + +- buffer_reserve(&vs->tight.png, vs->tight.png.offset + length); +- memcpy(vs->tight.png.buffer + vs->tight.png.offset, data, length); ++ buffer_reserve(&vs->tight->png, vs->tight->png.offset + length); ++ memcpy(vs->tight->png.buffer + vs->tight->png.offset, data, length); + +- vs->tight.png.offset += length; ++ vs->tight->png.offset += length; + } + + static void png_flush_data(png_structp png_ptr) +@@ -1295,8 +1296,8 @@ static int send_png_rect(VncState *vs, int x, int y, int w, int h, + png_infop info_ptr; + png_colorp png_palette = NULL; + pixman_image_t *linebuf; +- int level = tight_png_conf[vs->tight.compression].png_zlib_level; +- int filters = tight_png_conf[vs->tight.compression].png_filters; ++ int level = tight_png_conf[vs->tight->compression].png_zlib_level; ++ int filters = tight_png_conf[vs->tight->compression].png_filters; + uint8_t *buf; + int dy; + +@@ -1340,21 +1341,23 @@ static int send_png_rect(VncState *vs, int x, int y, int w, int h, + png_set_PLTE(png_ptr, info_ptr, png_palette, palette_size(palette)); + + if (vs->client_pf.bytes_per_pixel == 4) { +- tight_encode_indexed_rect32(vs->tight.tight.buffer, w * h, palette); ++ tight_encode_indexed_rect32(vs->tight->tight.buffer, w * h, ++ palette); + } else { +- tight_encode_indexed_rect16(vs->tight.tight.buffer, w * h, palette); ++ tight_encode_indexed_rect16(vs->tight->tight.buffer, w * h, ++ palette); + } + } + + png_write_info(png_ptr, info_ptr); + +- buffer_reserve(&vs->tight.png, 2048); ++ buffer_reserve(&vs->tight->png, 2048); + linebuf = qemu_pixman_linebuf_create(PIXMAN_BE_r8g8b8, w); + buf = (uint8_t *)pixman_image_get_data(linebuf); + for (dy = 0; dy < h; dy++) + { + if (color_type == PNG_COLOR_TYPE_PALETTE) { +- memcpy(buf, vs->tight.tight.buffer + (dy * w), w); ++ memcpy(buf, vs->tight->tight.buffer + (dy * w), w); + } else { + qemu_pixman_linebuf_fill(linebuf, vs->vd->server, w, x, y + dy); + } +@@ -1372,27 +1375,27 @@ static int send_png_rect(VncState *vs, int x, int y, int w, int h, + + vnc_write_u8(vs, VNC_TIGHT_PNG << 4); + +- tight_send_compact_size(vs, vs->tight.png.offset); +- vnc_write(vs, vs->tight.png.buffer, vs->tight.png.offset); +- buffer_reset(&vs->tight.png); ++ tight_send_compact_size(vs, vs->tight->png.offset); ++ vnc_write(vs, vs->tight->png.buffer, vs->tight->png.offset); ++ buffer_reset(&vs->tight->png); + return 1; + } + #endif /* CONFIG_VNC_PNG */ + + static void vnc_tight_start(VncState *vs) + { +- buffer_reset(&vs->tight.tight); ++ buffer_reset(&vs->tight->tight); + + // make the output buffer be the zlib buffer, so we can compress it later +- vs->tight.tmp = vs->output; +- vs->output = vs->tight.tight; ++ vs->tight->tmp = vs->output; ++ vs->output = vs->tight->tight; + } + + static void vnc_tight_stop(VncState *vs) + { + // switch back to normal output/zlib buffers +- vs->tight.tight = vs->output; +- vs->output = vs->tight.tmp; ++ vs->tight->tight = vs->output; ++ vs->output = vs->tight->tmp; + } + + static int send_sub_rect_nojpeg(VncState *vs, int x, int y, int w, int h, +@@ -1426,9 +1429,9 @@ static int send_sub_rect_jpeg(VncState *vs, int x, int y, int w, int h, + int ret; + + if (colors == 0) { +- if (force || (tight_jpeg_conf[vs->tight.quality].jpeg_full && ++ if (force || (tight_jpeg_conf[vs->tight->quality].jpeg_full && + tight_detect_smooth_image(vs, w, h))) { +- int quality = tight_conf[vs->tight.quality].jpeg_quality; ++ int quality = tight_conf[vs->tight->quality].jpeg_quality; + + ret = send_jpeg_rect(vs, x, y, w, h, quality); + } else { +@@ -1440,9 +1443,9 @@ static int send_sub_rect_jpeg(VncState *vs, int x, int y, int w, int h, + ret = send_mono_rect(vs, x, y, w, h, bg, fg); + } else if (colors <= 256) { + if (force || (colors > 96 && +- tight_jpeg_conf[vs->tight.quality].jpeg_idx && ++ tight_jpeg_conf[vs->tight->quality].jpeg_idx && + tight_detect_smooth_image(vs, w, h))) { +- int quality = tight_conf[vs->tight.quality].jpeg_quality; ++ int quality = tight_conf[vs->tight->quality].jpeg_quality; + + ret = send_jpeg_rect(vs, x, y, w, h, quality); + } else { +@@ -1480,20 +1483,20 @@ static int send_sub_rect(VncState *vs, int x, int y, int w, int h) + qemu_thread_atexit_add(&vnc_tight_cleanup_notifier); + } + +- vnc_framebuffer_update(vs, x, y, w, h, vs->tight.type); ++ vnc_framebuffer_update(vs, x, y, w, h, vs->tight->type); + + vnc_tight_start(vs); + vnc_raw_send_framebuffer_update(vs, x, y, w, h); + vnc_tight_stop(vs); + + #ifdef CONFIG_VNC_JPEG +- if (!vs->vd->non_adaptive && vs->tight.quality != (uint8_t)-1) { ++ if (!vs->vd->non_adaptive && vs->tight->quality != (uint8_t)-1) { + double freq = vnc_update_freq(vs, x, y, w, h); + +- if (freq < tight_jpeg_conf[vs->tight.quality].jpeg_freq_min) { ++ if (freq < tight_jpeg_conf[vs->tight->quality].jpeg_freq_min) { + allow_jpeg = false; + } +- if (freq >= tight_jpeg_conf[vs->tight.quality].jpeg_freq_threshold) { ++ if (freq >= tight_jpeg_conf[vs->tight->quality].jpeg_freq_threshold) { + force_jpeg = true; + vnc_sent_lossy_rect(vs, x, y, w, h); + } +@@ -1503,7 +1506,7 @@ static int send_sub_rect(VncState *vs, int x, int y, int w, int h) + colors = tight_fill_palette(vs, x, y, w * h, &bg, &fg, color_count_palette); + + #ifdef CONFIG_VNC_JPEG +- if (allow_jpeg && vs->tight.quality != (uint8_t)-1) { ++ if (allow_jpeg && vs->tight->quality != (uint8_t)-1) { + ret = send_sub_rect_jpeg(vs, x, y, w, h, bg, fg, colors, + color_count_palette, force_jpeg); + } else { +@@ -1520,7 +1523,7 @@ static int send_sub_rect(VncState *vs, int x, int y, int w, int h) + + static int send_sub_rect_solid(VncState *vs, int x, int y, int w, int h) + { +- vnc_framebuffer_update(vs, x, y, w, h, vs->tight.type); ++ vnc_framebuffer_update(vs, x, y, w, h, vs->tight->type); + + vnc_tight_start(vs); + vnc_raw_send_framebuffer_update(vs, x, y, w, h); +@@ -1538,8 +1541,8 @@ static int send_rect_simple(VncState *vs, int x, int y, int w, int h, + int rw, rh; + int n = 0; + +- max_size = tight_conf[vs->tight.compression].max_rect_size; +- max_width = tight_conf[vs->tight.compression].max_rect_width; ++ max_size = tight_conf[vs->tight->compression].max_rect_size; ++ max_width = tight_conf[vs->tight->compression].max_rect_width; + + if (split && (w > max_width || w * h > max_size)) { + max_sub_width = (w > max_width) ? max_width : w; +@@ -1648,16 +1651,16 @@ static int tight_send_framebuffer_update(VncState *vs, int x, int y, + + if (vs->client_pf.bytes_per_pixel == 4 && vs->client_pf.rmax == 0xFF && + vs->client_pf.bmax == 0xFF && vs->client_pf.gmax == 0xFF) { +- vs->tight.pixel24 = true; ++ vs->tight->pixel24 = true; + } else { +- vs->tight.pixel24 = false; ++ vs->tight->pixel24 = false; + } + + #ifdef CONFIG_VNC_JPEG +- if (vs->tight.quality != (uint8_t)-1) { ++ if (vs->tight->quality != (uint8_t)-1) { + double freq = vnc_update_freq(vs, x, y, w, h); + +- if (freq > tight_jpeg_conf[vs->tight.quality].jpeg_freq_threshold) { ++ if (freq > tight_jpeg_conf[vs->tight->quality].jpeg_freq_threshold) { + return send_rect_simple(vs, x, y, w, h, false); + } + } +@@ -1669,8 +1672,8 @@ static int tight_send_framebuffer_update(VncState *vs, int x, int y, + + /* Calculate maximum number of rows in one non-solid rectangle. */ + +- max_rows = tight_conf[vs->tight.compression].max_rect_size; +- max_rows /= MIN(tight_conf[vs->tight.compression].max_rect_width, w); ++ max_rows = tight_conf[vs->tight->compression].max_rect_size; ++ max_rows /= MIN(tight_conf[vs->tight->compression].max_rect_width, w); + + return find_large_solid_color_rect(vs, x, y, w, h, max_rows); + } +@@ -1678,33 +1681,33 @@ static int tight_send_framebuffer_update(VncState *vs, int x, int y, + int vnc_tight_send_framebuffer_update(VncState *vs, int x, int y, + int w, int h) + { +- vs->tight.type = VNC_ENCODING_TIGHT; ++ vs->tight->type = VNC_ENCODING_TIGHT; + return tight_send_framebuffer_update(vs, x, y, w, h); + } + + int vnc_tight_png_send_framebuffer_update(VncState *vs, int x, int y, + int w, int h) + { +- vs->tight.type = VNC_ENCODING_TIGHT_PNG; ++ vs->tight->type = VNC_ENCODING_TIGHT_PNG; + return tight_send_framebuffer_update(vs, x, y, w, h); + } + + void vnc_tight_clear(VncState *vs) + { + int i; +- for (i=0; itight.stream); i++) { +- if (vs->tight.stream[i].opaque) { +- deflateEnd(&vs->tight.stream[i]); ++ for (i = 0; i < ARRAY_SIZE(vs->tight->stream); i++) { ++ if (vs->tight->stream[i].opaque) { ++ deflateEnd(&vs->tight->stream[i]); + } + } + +- buffer_free(&vs->tight.tight); +- buffer_free(&vs->tight.zlib); +- buffer_free(&vs->tight.gradient); ++ buffer_free(&vs->tight->tight); ++ buffer_free(&vs->tight->zlib); ++ buffer_free(&vs->tight->gradient); + #ifdef CONFIG_VNC_JPEG +- buffer_free(&vs->tight.jpeg); ++ buffer_free(&vs->tight->jpeg); + #endif + #ifdef CONFIG_VNC_PNG +- buffer_free(&vs->tight.png); ++ buffer_free(&vs->tight->png); + #endif + } +diff --git a/ui/vnc-enc-zlib.c b/ui/vnc-enc-zlib.c +index 33e9df2..900ae5b 100644 +--- a/ui/vnc-enc-zlib.c ++++ b/ui/vnc-enc-zlib.c +@@ -76,7 +76,8 @@ static int vnc_zlib_stop(VncState *vs) + zstream->zalloc = vnc_zlib_zalloc; + zstream->zfree = vnc_zlib_zfree; + +- err = deflateInit2(zstream, vs->tight.compression, Z_DEFLATED, MAX_WBITS, ++ err = deflateInit2(zstream, vs->tight->compression, Z_DEFLATED, ++ MAX_WBITS, + MAX_MEM_LEVEL, Z_DEFAULT_STRATEGY); + + if (err != Z_OK) { +@@ -84,16 +85,16 @@ static int vnc_zlib_stop(VncState *vs) + return -1; + } + +- vs->zlib.level = vs->tight.compression; ++ vs->zlib.level = vs->tight->compression; + zstream->opaque = vs; + } + +- if (vs->tight.compression != vs->zlib.level) { +- if (deflateParams(zstream, vs->tight.compression, ++ if (vs->tight->compression != vs->zlib.level) { ++ if (deflateParams(zstream, vs->tight->compression, + Z_DEFAULT_STRATEGY) != Z_OK) { + return -1; + } +- vs->zlib.level = vs->tight.compression; ++ vs->zlib.level = vs->tight->compression; + } + + // reserve memory in output buffer +diff --git a/ui/vnc-enc-zrle.c b/ui/vnc-enc-zrle.c +index 7493a84..17fd28a 100644 +--- a/ui/vnc-enc-zrle.c ++++ b/ui/vnc-enc-zrle.c +@@ -37,18 +37,18 @@ static const int bits_per_packed_pixel[] = { + + static void vnc_zrle_start(VncState *vs) + { +- buffer_reset(&vs->zrle.zrle); ++ buffer_reset(&vs->zrle->zrle); + + /* make the output buffer be the zlib buffer, so we can compress it later */ +- vs->zrle.tmp = vs->output; +- vs->output = vs->zrle.zrle; ++ vs->zrle->tmp = vs->output; ++ vs->output = vs->zrle->zrle; + } + + static void vnc_zrle_stop(VncState *vs) + { + /* switch back to normal output/zlib buffers */ +- vs->zrle.zrle = vs->output; +- vs->output = vs->zrle.tmp; ++ vs->zrle->zrle = vs->output; ++ vs->output = vs->zrle->tmp; + } + + static void *zrle_convert_fb(VncState *vs, int x, int y, int w, int h, +@@ -56,24 +56,24 @@ static void *zrle_convert_fb(VncState *vs, int x, int y, int w, int h, + { + Buffer tmp; + +- buffer_reset(&vs->zrle.fb); +- buffer_reserve(&vs->zrle.fb, w * h * bpp + bpp); ++ buffer_reset(&vs->zrle->fb); ++ buffer_reserve(&vs->zrle->fb, w * h * bpp + bpp); + + tmp = vs->output; +- vs->output = vs->zrle.fb; ++ vs->output = vs->zrle->fb; + + vnc_raw_send_framebuffer_update(vs, x, y, w, h); + +- vs->zrle.fb = vs->output; ++ vs->zrle->fb = vs->output; + vs->output = tmp; +- return vs->zrle.fb.buffer; ++ return vs->zrle->fb.buffer; + } + + static int zrle_compress_data(VncState *vs, int level) + { +- z_streamp zstream = &vs->zrle.stream; ++ z_streamp zstream = &vs->zrle->stream; + +- buffer_reset(&vs->zrle.zlib); ++ buffer_reset(&vs->zrle->zlib); + + if (zstream->opaque != vs) { + int err; +@@ -93,13 +93,13 @@ static int zrle_compress_data(VncState *vs, int level) + } + + /* reserve memory in output buffer */ +- buffer_reserve(&vs->zrle.zlib, vs->zrle.zrle.offset + 64); ++ buffer_reserve(&vs->zrle->zlib, vs->zrle->zrle.offset + 64); + + /* set pointers */ +- zstream->next_in = vs->zrle.zrle.buffer; +- zstream->avail_in = vs->zrle.zrle.offset; +- zstream->next_out = vs->zrle.zlib.buffer + vs->zrle.zlib.offset; +- zstream->avail_out = vs->zrle.zlib.capacity - vs->zrle.zlib.offset; ++ zstream->next_in = vs->zrle->zrle.buffer; ++ zstream->avail_in = vs->zrle->zrle.offset; ++ zstream->next_out = vs->zrle->zlib.buffer + vs->zrle->zlib.offset; ++ zstream->avail_out = vs->zrle->zlib.capacity - vs->zrle->zlib.offset; + zstream->data_type = Z_BINARY; + + /* start encoding */ +@@ -108,8 +108,8 @@ static int zrle_compress_data(VncState *vs, int level) + return -1; + } + +- vs->zrle.zlib.offset = vs->zrle.zlib.capacity - zstream->avail_out; +- return vs->zrle.zlib.offset; ++ vs->zrle->zlib.offset = vs->zrle->zlib.capacity - zstream->avail_out; ++ return vs->zrle->zlib.offset; + } + + /* Try to work out whether to use RLE and/or a palette. We do this by +@@ -259,14 +259,14 @@ static int zrle_send_framebuffer_update(VncState *vs, int x, int y, + size_t bytes; + int zywrle_level; + +- if (vs->zrle.type == VNC_ENCODING_ZYWRLE) { +- if (!vs->vd->lossy || vs->tight.quality == (uint8_t)-1 +- || vs->tight.quality == 9) { ++ if (vs->zrle->type == VNC_ENCODING_ZYWRLE) { ++ if (!vs->vd->lossy || vs->tight->quality == (uint8_t)-1 ++ || vs->tight->quality == 9) { + zywrle_level = 0; +- vs->zrle.type = VNC_ENCODING_ZRLE; +- } else if (vs->tight.quality < 3) { ++ vs->zrle->type = VNC_ENCODING_ZRLE; ++ } else if (vs->tight->quality < 3) { + zywrle_level = 3; +- } else if (vs->tight.quality < 6) { ++ } else if (vs->tight->quality < 6) { + zywrle_level = 2; + } else { + zywrle_level = 1; +@@ -337,30 +337,30 @@ static int zrle_send_framebuffer_update(VncState *vs, int x, int y, + + vnc_zrle_stop(vs); + bytes = zrle_compress_data(vs, Z_DEFAULT_COMPRESSION); +- vnc_framebuffer_update(vs, x, y, w, h, vs->zrle.type); ++ vnc_framebuffer_update(vs, x, y, w, h, vs->zrle->type); + vnc_write_u32(vs, bytes); +- vnc_write(vs, vs->zrle.zlib.buffer, vs->zrle.zlib.offset); ++ vnc_write(vs, vs->zrle->zlib.buffer, vs->zrle->zlib.offset); + return 1; + } + + int vnc_zrle_send_framebuffer_update(VncState *vs, int x, int y, int w, int h) + { +- vs->zrle.type = VNC_ENCODING_ZRLE; ++ vs->zrle->type = VNC_ENCODING_ZRLE; + return zrle_send_framebuffer_update(vs, x, y, w, h); + } + + int vnc_zywrle_send_framebuffer_update(VncState *vs, int x, int y, int w, int h) + { +- vs->zrle.type = VNC_ENCODING_ZYWRLE; ++ vs->zrle->type = VNC_ENCODING_ZYWRLE; + return zrle_send_framebuffer_update(vs, x, y, w, h); + } + + void vnc_zrle_clear(VncState *vs) + { +- if (vs->zrle.stream.opaque) { +- deflateEnd(&vs->zrle.stream); ++ if (vs->zrle->stream.opaque) { ++ deflateEnd(&vs->zrle->stream); + } +- buffer_free(&vs->zrle.zrle); +- buffer_free(&vs->zrle.fb); +- buffer_free(&vs->zrle.zlib); ++ buffer_free(&vs->zrle->zrle); ++ buffer_free(&vs->zrle->fb); ++ buffer_free(&vs->zrle->zlib); + } +diff --git a/ui/vnc-enc-zrle.inc.c b/ui/vnc-enc-zrle.inc.c +index abf6b86..c107d8a 100644 +--- a/ui/vnc-enc-zrle.inc.c ++++ b/ui/vnc-enc-zrle.inc.c +@@ -96,7 +96,7 @@ static void ZRLE_ENCODE(VncState *vs, int x, int y, int w, int h, + static void ZRLE_ENCODE_TILE(VncState *vs, ZRLE_PIXEL *data, int w, int h, + int zywrle_level) + { +- VncPalette *palette = &vs->zrle.palette; ++ VncPalette *palette = &vs->zrle->palette; + + int runs = 0; + int single_pixels = 0; +diff --git a/ui/vnc.c b/ui/vnc.c +index bc43c4c..87b8045 100644 +--- a/ui/vnc.c ++++ b/ui/vnc.c +@@ -1307,6 +1307,8 @@ void vnc_disconnect_finish(VncState *vs) + object_unref(OBJECT(vs->sioc)); + vs->sioc = NULL; + vs->magic = 0; ++ g_free(vs->zrle); ++ g_free(vs->tight); + g_free(vs); + } + +@@ -2058,8 +2060,8 @@ static void set_encodings(VncState *vs, int32_t *encodings, size_t n_encodings) + + vs->features = 0; + vs->vnc_encoding = 0; +- vs->tight.compression = 9; +- vs->tight.quality = -1; /* Lossless by default */ ++ vs->tight->compression = 9; ++ vs->tight->quality = -1; /* Lossless by default */ + vs->absolute = -1; + + /* +@@ -2127,11 +2129,11 @@ static void set_encodings(VncState *vs, int32_t *encodings, size_t n_encodings) + vs->features |= VNC_FEATURE_LED_STATE_MASK; + break; + case VNC_ENCODING_COMPRESSLEVEL0 ... VNC_ENCODING_COMPRESSLEVEL0 + 9: +- vs->tight.compression = (enc & 0x0F); ++ vs->tight->compression = (enc & 0x0F); + break; + case VNC_ENCODING_QUALITYLEVEL0 ... VNC_ENCODING_QUALITYLEVEL0 + 9: + if (vs->vd->lossy) { +- vs->tight.quality = (enc & 0x0F); ++ vs->tight->quality = (enc & 0x0F); + } + break; + default: +@@ -3034,6 +3036,8 @@ static void vnc_connect(VncDisplay *vd, QIOChannelSocket *sioc, + int i; + + trace_vnc_client_connect(vs, sioc); ++ vs->zrle = g_new0(VncZrle, 1); ++ vs->tight = g_new0(VncTight, 1); + vs->magic = VNC_MAGIC; + vs->sioc = sioc; + object_ref(OBJECT(vs->sioc)); +@@ -3045,19 +3049,19 @@ static void vnc_connect(VncDisplay *vd, QIOChannelSocket *sioc, + buffer_init(&vs->output, "vnc-output/%p", sioc); + buffer_init(&vs->jobs_buffer, "vnc-jobs_buffer/%p", sioc); + +- buffer_init(&vs->tight.tight, "vnc-tight/%p", sioc); +- buffer_init(&vs->tight.zlib, "vnc-tight-zlib/%p", sioc); +- buffer_init(&vs->tight.gradient, "vnc-tight-gradient/%p", sioc); ++ buffer_init(&vs->tight->tight, "vnc-tight/%p", sioc); ++ buffer_init(&vs->tight->zlib, "vnc-tight-zlib/%p", sioc); ++ buffer_init(&vs->tight->gradient, "vnc-tight-gradient/%p", sioc); + #ifdef CONFIG_VNC_JPEG +- buffer_init(&vs->tight.jpeg, "vnc-tight-jpeg/%p", sioc); ++ buffer_init(&vs->tight->jpeg, "vnc-tight-jpeg/%p", sioc); + #endif + #ifdef CONFIG_VNC_PNG +- buffer_init(&vs->tight.png, "vnc-tight-png/%p", sioc); ++ buffer_init(&vs->tight->png, "vnc-tight-png/%p", sioc); + #endif + buffer_init(&vs->zlib.zlib, "vnc-zlib/%p", sioc); +- buffer_init(&vs->zrle.zrle, "vnc-zrle/%p", sioc); +- buffer_init(&vs->zrle.fb, "vnc-zrle-fb/%p", sioc); +- buffer_init(&vs->zrle.zlib, "vnc-zrle-zlib/%p", sioc); ++ buffer_init(&vs->zrle->zrle, "vnc-zrle/%p", sioc); ++ buffer_init(&vs->zrle->fb, "vnc-zrle-fb/%p", sioc); ++ buffer_init(&vs->zrle->zlib, "vnc-zrle-zlib/%p", sioc); + + if (skipauth) { + vs->auth = VNC_AUTH_NONE; +diff --git a/ui/vnc.h b/ui/vnc.h +index 8643860..fea79c2 100644 +--- a/ui/vnc.h ++++ b/ui/vnc.h +@@ -338,10 +338,10 @@ struct VncState + /* Encoding specific, if you add something here, don't forget to + * update vnc_async_encoding_start() + */ +- VncTight tight; ++ VncTight *tight; + VncZlib zlib; + VncHextile hextile; +- VncZrle zrle; ++ VncZrle *zrle; + VncZywrle zywrle; + + Notifier mouse_mode_notifier; +-- +1.8.3.1 -- 2.24.1 From anuj.mittal at intel.com Mon Mar 16 16:31:00 2020 From: anuj.mittal at intel.com (Anuj Mittal) Date: Tue, 17 Mar 2020 00:31:00 +0800 Subject: [OE-core] [PATCH][zeus 2/7] libpcre2: fix CVE-2019-20454 In-Reply-To: References: Message-ID: <8ec7a51da26f07fd43b5e6787b15c8636009b183.1584375668.git.anuj.mittal@intel.com> From: Lee Chee Yang Signed-off-by: Lee Chee Yang Signed-off-by: Anuj Mittal --- .../libpcre/libpcre2/CVE-2019-20454.patch | 19 +++++++++++++++++++ .../recipes-support/libpcre/libpcre2_10.33.bb | 1 + 2 files changed, 20 insertions(+) create mode 100644 meta/recipes-support/libpcre/libpcre2/CVE-2019-20454.patch diff --git a/meta/recipes-support/libpcre/libpcre2/CVE-2019-20454.patch b/meta/recipes-support/libpcre/libpcre2/CVE-2019-20454.patch new file mode 100644 index 0000000000..51f95a7097 --- /dev/null +++ b/meta/recipes-support/libpcre/libpcre2/CVE-2019-20454.patch @@ -0,0 +1,19 @@ +Upstream-Status: Backport [https://vcs.pcre.org/pcre2/code/trunk/src/pcre2_jit_compile.c?r1=1092&r2=1091&pathrev=1092] +CVE: CVE-2020-8002 +Signed-off-by: Lee Chee Yang + +--- pcre2-10.30/src/pcre2_jit_compile.c 2019/05/13 16:26:17 1091 ++++ pcre2-10.30/src/pcre2_jit_compile.c 2019/05/13 16:38:18 1092 +@@ -8571,7 +8571,10 @@ + PCRE2_SPTR bptr; + uint32_t c; + +-GETCHARINC(c, cc); ++/* Patch by PH */ ++/* GETCHARINC(c, cc); */ ++ ++c = *cc++; + #if PCRE2_CODE_UNIT_WIDTH == 32 + if (c >= 0x110000) + return NULL; + diff --git a/meta/recipes-support/libpcre/libpcre2_10.33.bb b/meta/recipes-support/libpcre/libpcre2_10.33.bb index 50b26753b4..1020df99b8 100644 --- a/meta/recipes-support/libpcre/libpcre2_10.33.bb +++ b/meta/recipes-support/libpcre/libpcre2_10.33.bb @@ -12,6 +12,7 @@ LIC_FILES_CHKSUM = "file://LICENCE;md5=b1588d3bb4cb0e1f5a597d908f8c5b37" SRC_URI = "https://ftp.pcre.org/pub/pcre/pcre2-${PV}.tar.bz2 \ file://pcre-cross.patch \ + file://CVE-2019-20454.patch \ " SRC_URI[md5sum] = "80b355f2dce909a2e2424f5c79eddb44" -- 2.24.1 From anuj.mittal at intel.com Mon Mar 16 16:31:01 2020 From: anuj.mittal at intel.com (Anuj Mittal) Date: Tue, 17 Mar 2020 00:31:01 +0800 Subject: [OE-core] [PATCH][zeus 3/7] sqlite: fix numerous CVEs In-Reply-To: References: Message-ID: From: Ross Burton Fix the following CVEs: - CVE-2019-19244 - CVE-2019-19923 - CVE-2019-19924 - CVE-2019-19925 - CVE-2019-19926 - CVE-2019-19959 - CVE-2019-20218 Signed-off-by: Ross Burton Signed-off-by: Richard Purdie [ removed the CVE-2019-19880 fix that did not apply cleanly ] Signed-off-by: Adrian Bunk Signed-off-by: Anuj Mittal --- .../sqlite/sqlite3/CVE-2019-19244.patch | 33 ++++++++++ .../sqlite/sqlite3/CVE-2019-19923.patch | 50 ++++++++++++++ .../sqlite/sqlite3/CVE-2019-19924.patch | 65 +++++++++++++++++++ .../sqlite/sqlite3/CVE-2019-19925.patch | 33 ++++++++++ .../sqlite/sqlite3/CVE-2019-19926.patch | 31 +++++++++ .../sqlite/sqlite3/CVE-2019-19959.patch | 46 +++++++++++++ .../sqlite/sqlite3/CVE-2019-20218.patch | 31 +++++++++ meta/recipes-support/sqlite/sqlite3_3.29.0.bb | 10 ++- 8 files changed, 298 insertions(+), 1 deletion(-) create mode 100644 meta/recipes-support/sqlite/sqlite3/CVE-2019-19244.patch create mode 100644 meta/recipes-support/sqlite/sqlite3/CVE-2019-19923.patch create mode 100644 meta/recipes-support/sqlite/sqlite3/CVE-2019-19924.patch create mode 100644 meta/recipes-support/sqlite/sqlite3/CVE-2019-19925.patch create mode 100644 meta/recipes-support/sqlite/sqlite3/CVE-2019-19926.patch create mode 100644 meta/recipes-support/sqlite/sqlite3/CVE-2019-19959.patch create mode 100644 meta/recipes-support/sqlite/sqlite3/CVE-2019-20218.patch diff --git a/meta/recipes-support/sqlite/sqlite3/CVE-2019-19244.patch b/meta/recipes-support/sqlite/sqlite3/CVE-2019-19244.patch new file mode 100644 index 0000000000..3f70979acc --- /dev/null +++ b/meta/recipes-support/sqlite/sqlite3/CVE-2019-19244.patch @@ -0,0 +1,33 @@ +CVE: CVE-2019-19244 +Upstream-Status: Backport +Signed-off-by: Ross Burton + +From 0f690d4ae5ffe656762fdbb7f36cc4c2dcbb2d9d Mon Sep 17 00:00:00 2001 +From: dan +Date: Fri, 22 Nov 2019 10:14:01 +0000 +Subject: [PATCH] Fix a crash that could occur if a sub-select that uses both + DISTINCT and window functions also used an ORDER BY that is the same as its + select list. + +Amalgamation version of the patch: +FossilOrigin-Name: bcdd66c1691955c697f3d756c2b035acfe98f6aad72e90b0021bab6e9023b3ba +--- + sqlite3.c | 5 +++-- + sqlite3.h | 2 +- + 2 files changed, 4 insertions(+), 3 deletions(-) + +diff --git a/sqlite3.c b/sqlite3.c +index 8fd740b..db1c649 100644 +--- a/sqlite3.c ++++ b/sqlite3.c +@@ -131679,6 +131679,7 @@ SQLITE_PRIVATE int sqlite3Select( + */ + if( (p->selFlags & (SF_Distinct|SF_Aggregate))==SF_Distinct + && sqlite3ExprListCompare(sSort.pOrderBy, pEList, -1)==0 ++ && p->pWin==0 + ){ + p->selFlags &= ~SF_Distinct; + pGroupBy = p->pGroupBy = sqlite3ExprListDup(db, pEList, 0); +-- +2.24.1 + diff --git a/meta/recipes-support/sqlite/sqlite3/CVE-2019-19923.patch b/meta/recipes-support/sqlite/sqlite3/CVE-2019-19923.patch new file mode 100644 index 0000000000..b1b866b250 --- /dev/null +++ b/meta/recipes-support/sqlite/sqlite3/CVE-2019-19923.patch @@ -0,0 +1,50 @@ +CVE: CVE-2019-19923 +Upstream-Status: Backport +Signed-off-by: Ross Burton + +From b64463719dc53bde98b0ce3930b10a32560c3a02 Mon Sep 17 00:00:00 2001 +From: "D. Richard Hipp" +Date: Wed, 18 Dec 2019 20:51:58 +0000 +Subject: [PATCH] Continue to back away from the LEFT JOIN optimization of + check-in [41c27bc0ff1d3135] by disallowing query flattening if the outer + query is DISTINCT. Without this fix, if an index scan is run on the table + within the view on the right-hand side of the LEFT JOIN, stale result + registers might be accessed yielding incorrect results, and/or an + OP_IfNullRow opcode might be invoked on the un-opened table, resulting in a + NULL-pointer dereference. This problem was found by the Yongheng and Rui + fuzzer. + +FossilOrigin-Name: 862974312edf00e9d1068115d1a39b7235b7db68b6d86b81d38a12f025a4748e +--- + sqlite3.c | 10 +++++++--- + 1 file changed, 7 insertions(+), 3 deletions(-) + +diff --git a/sqlite3.c b/sqlite3.c +index d29da07..5bc06c8 100644 +--- a/sqlite3.c ++++ b/sqlite3.c +@@ -129216,6 +129216,7 @@ static void substSelect( + ** (3b) the FROM clause of the subquery may not contain a virtual + ** table and + ** (3c) the outer query may not be an aggregate. ++** (3d) the outer query may not be DISTINCT. + ** + ** (4) The subquery can not be DISTINCT. + ** +@@ -129412,8 +129413,11 @@ static int flattenSubquery( + */ + if( (pSubitem->fg.jointype & JT_OUTER)!=0 ){ + isLeftJoin = 1; +- if( pSubSrc->nSrc>1 || isAgg || IsVirtual(pSubSrc->a[0].pTab) ){ +- /* (3a) (3c) (3b) */ ++ if( pSubSrc->nSrc>1 /* (3a) */ ++ || isAgg /* (3b) */ ++ || IsVirtual(pSubSrc->a[0].pTab) /* (3c) */ ++ || (p->selFlags & SF_Distinct)!=0 /* (3d) */ ++ ){ + return 0; + } + } +-- +2.24.1 + diff --git a/meta/recipes-support/sqlite/sqlite3/CVE-2019-19924.patch b/meta/recipes-support/sqlite/sqlite3/CVE-2019-19924.patch new file mode 100644 index 0000000000..80d5edbb0c --- /dev/null +++ b/meta/recipes-support/sqlite/sqlite3/CVE-2019-19924.patch @@ -0,0 +1,65 @@ +CVE: CVE-2019-19924 +Upstream-Status: Backport +Signed-off-by: Ross Burton + +From 854fe21e8a987f84da81f6bb9e90abc5355c6621 Mon Sep 17 00:00:00 2001 +From: "D. Richard Hipp" +Date: Thu, 19 Dec 2019 20:37:32 +0000 +Subject: [PATCH] When an error occurs while rewriting the parser tree for + window functions in the sqlite3WindowRewrite() routine, make sure that + pParse->nErr is set, and make sure that this shuts down any subsequent code + generation that might depend on the transformations that were implemented. + This fixes a problem discovered by the Yongheng and Rui fuzzer. + +Amalgamation format of backported patch +FossilOrigin-Name: e2bddcd4c55ba3cbe0130332679ff4b048630d0ced9a8899982edb5a3569ba7f +--- + sqlite3.c | 16 +++++++++++----- + sqlite3.h | 2 +- + 2 files changed, 12 insertions(+), 6 deletions(-) + +diff --git a/sqlite3.c b/sqlite3.c +index 408ec4c..857c28e 100644 +--- a/sqlite3.c ++++ b/sqlite3.c +@@ -77798,7 +77798,8 @@ SQLITE_PRIVATE void sqlite3VdbeSetP4KeyInfo(Parse *pParse, Index *pIdx){ + */ + static void vdbeVComment(Vdbe *p, const char *zFormat, va_list ap){ + assert( p->nOp>0 || p->aOp==0 ); +- assert( p->aOp==0 || p->aOp[p->nOp-1].zComment==0 || p->db->mallocFailed ); ++ assert( p->aOp==0 || p->aOp[p->nOp-1].zComment==0 || p->db->mallocFailed ++ || p->pParse->nErr>0 ); + if( p->nOp ){ + assert( p->aOp ); + sqlite3DbFree(p->db, p->aOp[p->nOp-1].zComment); +@@ -97872,6 +97873,7 @@ static int codeCompare( + int addr; + CollSeq *p4; + ++ if( pParse->nErr ) return 0; + p4 = sqlite3BinaryCompareCollSeq(pParse, pLeft, pRight); + p5 = binaryCompareP5(pLeft, pRight, jumpIfNull); + addr = sqlite3VdbeAddOp4(pParse->pVdbe, opcode, in2, dest, in1, +@@ -147627,7 +147629,7 @@ SQLITE_PRIVATE int sqlite3WindowRewrite(Parse *pParse, Select *p){ + + pTab = sqlite3DbMallocZero(db, sizeof(Table)); + if( pTab==0 ){ +- return SQLITE_NOMEM; ++ return sqlite3ErrorToParser(db, SQLITE_NOMEM); + } + + p->pSrc = 0; +@@ -147731,6 +147733,10 @@ SQLITE_PRIVATE int sqlite3WindowRewrite(Parse *pParse, Select *p){ + sqlite3DbFree(db, pTab); + } + ++ if( rc && pParse->nErr==0 ){ ++ assert( pParse->db->mallocFailed ); ++ return sqlite3ErrorToParser(pParse->db, SQLITE_NOMEM); ++ } + return rc; + } + +-- +2.24.1 + diff --git a/meta/recipes-support/sqlite/sqlite3/CVE-2019-19925.patch b/meta/recipes-support/sqlite/sqlite3/CVE-2019-19925.patch new file mode 100644 index 0000000000..ffc2c6afff --- /dev/null +++ b/meta/recipes-support/sqlite/sqlite3/CVE-2019-19925.patch @@ -0,0 +1,33 @@ +CVE: CVE-2019-19925 +Upstream-Status: Backport +Signed-off-by: Ross Burton + +From e92580434d2cdca228649d32f76167492de4f512 Mon Sep 17 00:00:00 2001 +From: "D. Richard Hipp" +Date: Thu, 19 Dec 2019 15:15:40 +0000 +Subject: [PATCH] Fix the zipfile extension so that INSERT works even if the + pathname of the file being inserted is a NULL. Bug discovered by the + Yongheng and Rui fuzzer. + +FossilOrigin-Name: a80f84b511231204658304226de3e075a55afc2e3f39ac063716f7a57f585c06 +--- + shell.c | 1 + + sqlite3.c | 4 ++-- + sqlite3.h | 2 +- + 3 files changed, 4 insertions(+), 3 deletions(-) + +diff --git a/shell.c b/shell.c +index 053180c..404a8d4 100644 +--- a/shell.c ++++ b/shell.c +@@ -5827,6 +5827,7 @@ static int zipfileUpdate( + + if( rc==SQLITE_OK ){ + zPath = (const char*)sqlite3_value_text(apVal[2]); ++ if( zPath==0 ) zPath = ""; + nPath = (int)strlen(zPath); + mTime = zipfileGetTime(apVal[4]); + } +-- +2.24.1 + diff --git a/meta/recipes-support/sqlite/sqlite3/CVE-2019-19926.patch b/meta/recipes-support/sqlite/sqlite3/CVE-2019-19926.patch new file mode 100644 index 0000000000..92bc7908bc --- /dev/null +++ b/meta/recipes-support/sqlite/sqlite3/CVE-2019-19926.patch @@ -0,0 +1,31 @@ +CVE: CVE-2019-19926 +Upstream-Status: Backport +Signed-off-by: Ross Burton + +From 4165b1e1e0001165ace9051a70f938099505eadc Mon Sep 17 00:00:00 2001 +From: "D. Richard Hipp" +Date: Thu, 19 Dec 2019 22:08:19 +0000 +Subject: [PATCH] Continuation of [e2bddcd4c55ba3cb]: Add another spot where it + is necessary to abort early due to prior errors in sqlite3WindowRewrite(). + +FossilOrigin-Name: cba2a2a44cdf138a629109bb0ad088ed4ef67fc66bed3e0373554681a39615d2 +--- + sqlite3.c | 7 ++++--- + sqlite3.h | 2 +- + 2 files changed, 5 insertions(+), 4 deletions(-) + +diff --git a/sqlite3.c b/sqlite3.c +index 857c28e..19a474d 100644 +--- a/sqlite3.c ++++ b/sqlite3.c +@@ -128427,6 +128427,7 @@ static int multiSelect( + } + #endif + } ++ if( pParse->nErr ) goto multi_select_end; + + /* Compute collating sequences used by + ** temporary tables needed to implement the compound select. +-- +2.24.1 + diff --git a/meta/recipes-support/sqlite/sqlite3/CVE-2019-19959.patch b/meta/recipes-support/sqlite/sqlite3/CVE-2019-19959.patch new file mode 100644 index 0000000000..cba8ec9d30 --- /dev/null +++ b/meta/recipes-support/sqlite/sqlite3/CVE-2019-19959.patch @@ -0,0 +1,46 @@ +CVE: CVE-2019-19959 +Upstream-Status: Backport +Signed-off-by: Ross Burton + +From f83f7e8141ee7cbbf7f2dc8985279a7372b259b6 Mon Sep 17 00:00:00 2001 +From: "D. Richard Hipp" +Date: Mon, 23 Dec 2019 21:04:33 +0000 +Subject: [PATCH] Fix the zipfile() function in the zipfile extension so that + it is able to deal with goofy filenames that contain embedded zeros. + +FossilOrigin-Name: cc0fb00a128fd0773db5ff7891f7aa577a3671d570166d2cbb30df922344adcf +--- + shell.c | 4 ++-- + sqlite3.c | 4 ++-- + sqlite3.h | 2 +- + 3 files changed, 5 insertions(+), 5 deletions(-) + +diff --git a/shell.c b/shell.c +index 404a8d4..48065e9 100644 +--- a/shell.c ++++ b/shell.c +@@ -5841,7 +5841,7 @@ static int zipfileUpdate( + zFree = sqlite3_mprintf("%s/", zPath); + if( zFree==0 ){ rc = SQLITE_NOMEM; } + zPath = (const char*)zFree; +- nPath++; ++ nPath = (int)strlen(zPath); + } + } + +@@ -6242,11 +6242,11 @@ void zipfileStep(sqlite3_context *pCtx, int nVal, sqlite3_value **apVal){ + }else{ + if( zName[nName-1]!='/' ){ + zName = zFree = sqlite3_mprintf("%s/", zName); +- nName++; + if( zName==0 ){ + rc = SQLITE_NOMEM; + goto zipfile_step_out; + } ++ nName = (int)strlen(zName); + }else{ + while( nName>1 && zName[nName-2]=='/' ) nName--; + } +-- +2.24.1 + diff --git a/meta/recipes-support/sqlite/sqlite3/CVE-2019-20218.patch b/meta/recipes-support/sqlite/sqlite3/CVE-2019-20218.patch new file mode 100644 index 0000000000..fb6cd6df2d --- /dev/null +++ b/meta/recipes-support/sqlite/sqlite3/CVE-2019-20218.patch @@ -0,0 +1,31 @@ +CVE: CVE-2019-20218 +Upstream-Status: Backport +Signed-off-by: Ross Burton + +From 6bbd76d34f29f61483791231f2ce579dcadab8a5 Mon Sep 17 00:00:00 2001 +From: Dan Kennedy +Date: Fri, 27 Dec 2019 20:54:42 +0000 +Subject: [PATCH] Do not attempt to unwind the WITH stack in the Parse object + following an error. This fixes a separate case to [de6e6d68]. + +FossilOrigin-Name: d29edef93451cc67a5d69c1cce1b1832d9ca8fff1f600afdd51338b74d077b92 +--- + sqlite3.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/sqlite3.c b/sqlite3.c +index 5bc06c8..408ec4c 100644 +--- a/sqlite3.c ++++ b/sqlite3.c +@@ -130570,7 +130570,7 @@ static int selectExpander(Walker *pWalker, Select *p){ + + /* Process NATURAL keywords, and ON and USING clauses of joins. + */ +- if( db->mallocFailed || sqliteProcessJoin(pParse, p) ){ ++ if( pParse->nErr || db->mallocFailed || sqliteProcessJoin(pParse, p) ){ + return WRC_Abort; + } + +-- +2.24.1 + diff --git a/meta/recipes-support/sqlite/sqlite3_3.29.0.bb b/meta/recipes-support/sqlite/sqlite3_3.29.0.bb index 34066fbe89..cf3b179845 100644 --- a/meta/recipes-support/sqlite/sqlite3_3.29.0.bb +++ b/meta/recipes-support/sqlite/sqlite3_3.29.0.bb @@ -4,6 +4,14 @@ LICENSE = "PD" LIC_FILES_CHKSUM = "file://sqlite3.h;endline=11;md5=786d3dc581eff03f4fd9e4a77ed00c66" SRC_URI = "http://www.sqlite.org/2019/sqlite-autoconf-${SQLITE_PV}.tar.gz \ - file://0001-Fix-CVE-2019-16168.patch" + file://0001-Fix-CVE-2019-16168.patch \ + file://CVE-2019-19244.patch \ + file://CVE-2019-19923.patch \ + file://CVE-2019-19924.patch \ + file://CVE-2019-19925.patch \ + file://CVE-2019-19926.patch \ + file://CVE-2019-19959.patch \ + file://CVE-2019-20218.patch \ +" SRC_URI[md5sum] = "8f3dfe83387e62ecb91c7c5c09c688dc" SRC_URI[sha256sum] = "8e7c1e2950b5b04c5944a981cb31fffbf9d2ddda939d536838ebc854481afd5b" -- 2.24.1 From anuj.mittal at intel.com Mon Mar 16 16:31:02 2020 From: anuj.mittal at intel.com (Anuj Mittal) Date: Tue, 17 Mar 2020 00:31:02 +0800 Subject: [OE-core] [PATCH][zeus 4/7] aspell: CVE-2019-20433 In-Reply-To: References: Message-ID: <07dc85604baf696cccf784c909dbad67275ad7b3.1584375668.git.anuj.mittal@intel.com> From: Stefan Ghinea libaspell.a in GNU Aspell before 0.60.8 has a buffer over-read for a string ending with a single '\0' byte, if the encoding is set to ucs-2 or ucs-4 outside of the application, as demonstrated by the ASPELL_CONF environment variable. References: https://nvd.nist.gov/vuln/detail/CVE-2019-20433 Upstream patches: https://github.com/GNUAspell/aspell/commit/de29341638833ba7717bd6b5e6850998454b044b https://github.com/GNUAspell/aspell/commit/cefd447e5528b08bb0cd6656bc52b4255692cefc Signed-off-by: Stefan Ghinea Signed-off-by: Anuj Mittal --- .../aspell/aspell/CVE-2019-20433-0001.patch | 999 ++++++++++++++++++ .../aspell/aspell/CVE-2019-20433-0002.patch | 68 ++ meta/recipes-support/aspell/aspell_0.60.7.bb | 2 + 3 files changed, 1069 insertions(+) create mode 100644 meta/recipes-support/aspell/aspell/CVE-2019-20433-0001.patch create mode 100644 meta/recipes-support/aspell/aspell/CVE-2019-20433-0002.patch diff --git a/meta/recipes-support/aspell/aspell/CVE-2019-20433-0001.patch b/meta/recipes-support/aspell/aspell/CVE-2019-20433-0001.patch new file mode 100644 index 0000000000..fd68461e32 --- /dev/null +++ b/meta/recipes-support/aspell/aspell/CVE-2019-20433-0001.patch @@ -0,0 +1,999 @@ +From de29341638833ba7717bd6b5e6850998454b044b Mon Sep 17 00:00:00 2001 +From: Kevin Atkinson +Date: Sat, 17 Aug 2019 17:06:53 -0400 +Subject: [PATCH 1/2] Don't allow null-terminated UCS-2/4 strings using the + original API. + +Detect if the encoding is UCS-2/4 and the length is -1 in affected API +functions and refuse to convert the string. If the string ends up +being converted somehow, abort with an error message in DecodeDirect +and ConvDirect. To convert a null terminated string in +Decode/ConvDirect, a negative number corresponding to the width of the +underlying character type for the encoding is expected; for example, +if the encoding is "ucs-2" then a the size is expected to be -2. + +Also fix a 1-3 byte over-read in DecodeDirect when reading UCS-2/4 +strings when a size is provided (found by OSS-Fuzz). + +Also fix a bug in DecodeDirect that caused DocumentChecker to return +the wrong offsets when working with UCS-2/4 strings. + +CVE: CVE-2019-20433 +Upstream-Status: Backport [https://github.com/GNUAspell/aspell/commit/de29341638833ba7717bd6b5e6850998454b044b] + +[SG: - adjusted context + - discarded test changes as test framework is not available + - discarded manual entry changes for features that aren't backported] +Signed-off-by: Stefan Ghinea +--- + auto/MkSrc/CcHelper.pm | 99 ++++++++++++++++++++++++++++++++++--- + auto/MkSrc/Create.pm | 5 +- + auto/MkSrc/Info.pm | 5 +- + auto/MkSrc/ProcCc.pm | 24 +++++---- + auto/MkSrc/ProcImpl.pm | 57 +++++++++++++++------ + auto/MkSrc/Read.pm | 4 +- + auto/mk-src.in | 44 +++++++++++++++-- + common/convert.cpp | 39 ++++++++++++--- + common/convert.hpp | 38 +++++++++++++- + common/document_checker.cpp | 17 ++++++- + common/document_checker.hpp | 1 + + common/version.cpp | 15 ++++-- + configure.ac | 8 +++ + manual/aspell.texi | 58 ++++++++++++++++------ + manual/readme.texi | 70 +++++++++++++++++++++----- + 15 files changed, 409 insertions(+), 75 deletions(-) + +diff --git a/auto/MkSrc/CcHelper.pm b/auto/MkSrc/CcHelper.pm +index f2de991..0044335 100644 +--- a/auto/MkSrc/CcHelper.pm ++++ b/auto/MkSrc/CcHelper.pm +@@ -10,8 +10,8 @@ BEGIN { + use Exporter; + our @ISA = qw(Exporter); + our @EXPORT = qw(to_c_return_type c_error_cond +- to_type_name make_desc make_func call_func +- make_c_method call_c_method form_c_method ++ to_type_name make_desc make_func call_func get_c_func_name ++ make_c_method make_wide_macro call_c_method form_c_method + make_cxx_method); + } + +@@ -90,6 +90,69 @@ sub make_func ( $ \@ $ ; \% ) { + ')')); + } + ++=item make_wide_version NAME @TYPES PARMS ; %ACCUM ++ ++Creates the wide character version of the function if needed ++ ++=cut ++ ++sub make_wide_version ( $ \@ $ ; \% ) { ++ my ($name, $d, $p, $accum) = @_; ++ my @d = @$d; ++ shift @d; ++ return '' unless grep {$_->{type} eq 'encoded string'} @d; ++ $accum->{sys_headers}{'stddef.h'} = true; ++ $accum->{suffix}[5] = <<'---'; ++ ++/******************* private implemantion details *********************/ ++ ++#ifdef __cplusplus ++# define aspell_cast_(type, expr) (static_cast(expr)) ++# define aspell_cast_from_wide_(str) (static_cast(str)) ++#else ++# define aspell_cast_(type, expr) ((type)(expr)) ++# define aspell_cast_from_wide_(str) ((const char *)(str)) ++#endif ++--- ++ my @parms = map {$_->{type} eq 'encoded string' ++ ? ($_->{name}, $_->{name}.'_size') ++ : $_->{name}} @d; ++ $name = to_lower $name; ++ $accum->{suffix}[0] = <<'---'; ++/**********************************************************************/ ++ ++#ifdef ASPELL_ENCODE_SETTING_SECURE ++--- ++ $accum->{suffix}[2] = "#endif\n"; ++ my @args = map {$_->{type} eq 'encoded string' ++ ? ($_->{name}, "$_->{name}_size", '-1') ++ : $_->{name}} @d; ++ $accum->{suffix}[1] .= ++ (join '', ++ "#define $name", ++ '(', join(', ', @parms), ')', ++ "\\\n ", ++ $name, '_wide', ++ '(', join(', ', @args), ')', ++ "\n"); ++ @args = map {$_->{type} eq 'encoded string' ++ ? ("aspell_cast_from_wide_($_->{name})", ++ "$_->{name}_size*aspell_cast_(int,sizeof(*($_->{name})))", ++ "sizeof(*($_->{name}))") ++ : $_->{name}} @d; ++ return (join '', ++ "\n", ++ "/* version of $name that is safe to use with (null terminated) wide characters */\n", ++ '#define ', ++ $name, '_w', ++ '(', join(', ', @parms), ')', ++ "\\\n ", ++ $name, '_wide', ++ '(', join(', ', @args), ')', ++ "\n"); ++} ++ ++ + =item call_func NAME @TYPES PARMS ; %ACCUM + + Return a string to call a func. Will prefix the function with return +@@ -103,7 +166,6 @@ Parms can be any of: + + sub call_func ( $ \@ $ ; \% ) { + my ($name, $d, $p, $accum) = @_; +- $accum = {} unless defined $accum; + my @d = @$d; + my $func_ret = to_type_name(shift @d, {%$p,pos=>'return'}, %$accum); + return (join '', +@@ -148,8 +210,14 @@ sub to_type_name ( $ $ ; \% ) { + my $name = $t->{name}; + my $type = $t->{type}; + +- return ( (to_type_name {%$d, type=>'string'}, $p, %$accum) , +- (to_type_name {%$d, type=>'int', name=>"$d->{name}_size"}, $p, %$accum) ) ++ if ($name eq 'encoded string' && $is_cc && $pos eq 'parm') { ++ my @types = ((to_type_name {%$d, type=>($p->{wide}?'const void pointer':'string')}, $p, %$accum), ++ (to_type_name {%$d, type=>'int', name=>"$d->{name}_size"}, $p, %$accum)); ++ push @types, (to_type_name {%$d, type=>'int', name=>"$d->{name}_type_width"}, $p, %$accum) if $p->{wide}; ++ return @types; ++ } ++ return ( (to_type_name {%$d, type=>($p->{wide}?'const void pointer':'string')}, $p, %$accum) , ++ (to_type_name {%$d, type=>'int', name=>"$d->{name}_size"}, $p, %$accum) ) + if $name eq 'encoded string' && $is_cc && $pos eq 'parm'; + + my $str; +@@ -174,7 +242,7 @@ sub to_type_name ( $ $ ; \% ) { + $str .= "String"; + } + } elsif ($name eq 'encoded string') { +- $str .= "const char *"; ++ $str .= $p->{wide} ? "const void *" : "const char *"; + } elsif ($name eq '') { + $str .= "void"; + } elsif ($name eq 'bool' && $is_cc) { +@@ -186,7 +254,7 @@ sub to_type_name ( $ $ ; \% ) { + if ($t->{pointer}) { + $accum->{types}->{$name} = $t; + } else { +- $accum->{headers}->{$t->{created_in}} = true; ++ $accum->{headers}->{$t->{created_in}} = true unless $mode eq 'cc'; + } + $str .= "$c_type Aspell" if $mode eq 'cc'; + $str .= to_mixed($name); +@@ -214,6 +282,7 @@ sub to_type_name ( $ $ ; \% ) { + return $str; + } + ++ + =item make_desc DESC ; LEVEL + + Make a C comment out of DESC optionally indenting it LEVEL spaces. +@@ -286,6 +355,7 @@ sub form_c_method ($ $ $ ; \% ) + } else { + $func = "aspell $class $name"; + } ++ $func .= " wide" if $p->{wide}; + if (exists $d->{'const'}) { + splice @data, 1, 0, {type => "const $class", name=> $this_name}; + } else { +@@ -306,6 +376,21 @@ sub make_c_method ($ $ $ ; \%) + return &make_func(@ret); + } + ++sub get_c_func_name ($ $ $) ++{ ++ my @ret = &form_c_method(@_); ++ return undef unless @ret > 0; ++ return to_lower $ret[0]; ++} ++ ++sub make_wide_macro ($ $ $ ; \%) ++{ ++ my @ret = &form_c_method(@_); ++ return undef unless @ret > 0; ++ my $str = &make_wide_version(@ret); ++ return $str; ++} ++ + sub call_c_method ($ $ $ ; \%) + { + my @ret = &form_c_method(@_); +diff --git a/auto/MkSrc/Create.pm b/auto/MkSrc/Create.pm +index d39b60e..630ede5 100644 +--- a/auto/MkSrc/Create.pm ++++ b/auto/MkSrc/Create.pm +@@ -77,8 +77,10 @@ sub create_cc_file ( % ) { + $file .= "#include \"aspell.h\"\n" if $p{type} eq 'cxx'; + $file .= "#include \"settings.h\"\n" if $p{type} eq 'native_impl' && $p{name} eq 'errors'; + $file .= "#include \"gettext.h\"\n" if $p{type} eq 'native_impl' && $p{name} eq 'errors'; ++ $file .= cmap {"#include <$_>\n"} sort keys %{$accum{sys_headers}}; + $file .= cmap {"#include \"".to_lower($_).".hpp\"\n"} sort keys %{$accum{headers}}; +- $file .= "#ifdef __cplusplus\nextern \"C\" {\n#endif\n" if $p{header} && !$p{cxx}; ++ $file .= "\n#ifdef __cplusplus\nextern \"C\" {\n#endif\n" if $p{header} && !$p{cxx}; ++ $file .= join('', grep {defined $_} @{$accum{prefix}}); + $file .= "\nnamespace $p{namespace} {\n\n" if $p{cxx}; + if (defined $info{forward}{proc}{$p{type}}) { + my @types = sort {$a->{name} cmp $b->{name}} (values %{$accum{types}}); +@@ -86,6 +88,7 @@ sub create_cc_file ( % ) { + } + $file .= "\n"; + $file .= $body; ++ $file .= join('', grep {defined $_} @{$accum{suffix}}); + $file .= "\n\n}\n\n" if $p{cxx}; + $file .= "#ifdef __cplusplus\n}\n#endif\n" if $p{header} && !$p{cxx}; + $file .= "#endif /* $hm */\n" if $p{header}; +diff --git a/auto/MkSrc/Info.pm b/auto/MkSrc/Info.pm +index c644028..ace8e21 100644 +--- a/auto/MkSrc/Info.pm ++++ b/auto/MkSrc/Info.pm +@@ -60,6 +60,7 @@ each proc sub should take the following argv + the object from which it is a member of + no native: do not attempt to create a native implementation + treat as object: treat as a object rather than a pointer ++ no conv: do not converted an encoded string + + The %info structure is initialized as follows: + +@@ -104,8 +105,8 @@ The %info structure is initialized as follows: + errors => {}, # possible errors + method => { + # A class method +- options => ['desc', 'posib err', 'c func', 'const', +- 'c only', 'c impl', 'cxx impl'], ++ options => ['desc', 'posib err', 'c func', 'const', 'no conv', 'on conv error', ++ 'c only', 'c impl', 'cxx impl', 'cc extra'], + groups => undef}, + constructor => { + # A class constructor +diff --git a/auto/MkSrc/ProcCc.pm b/auto/MkSrc/ProcCc.pm +index 47c4338..98cc435 100644 +--- a/auto/MkSrc/ProcCc.pm ++++ b/auto/MkSrc/ProcCc.pm +@@ -23,7 +23,7 @@ use MkSrc::Info; + sub make_c_object ( $ @ ); + + $info{group}{proc}{cc} = sub { +- my ($data) = @_; ++ my ($data, at rest) = @_; + my $ret; + my $stars = (70 - length $data->{name})/2; + $ret .= "/"; +@@ -33,14 +33,14 @@ $info{group}{proc}{cc} = sub { + $ret .= "/\n"; + foreach my $d (@{$data->{data}}) { + $ret .= "\n\n"; +- $ret .= $info{$d->{type}}{proc}{cc}->($d); ++ $ret .= $info{$d->{type}}{proc}{cc}->($d, at rest); + } + $ret .= "\n\n"; + return $ret; + }; + + $info{enum}{proc}{cc} = sub { +- my ($d) = @_; ++ my ($d, at rest) = @_; + my $n = "Aspell".to_mixed($d->{name}); + return ("\n". + make_desc($d->{desc}). +@@ -58,21 +58,26 @@ $info{struct}{proc}{cc} = sub { + }; + + $info{union}{proc}{cc} = sub { +- return make_c_object "union", $_[0]; ++ return make_c_object "union", @_; + }; + + $info{class}{proc}{cc} = sub { +- my ($d) = @_; ++ my ($d,$accum) = @_; + my $class = $d->{name}; + my $classname = "Aspell".to_mixed($class); + my $ret = ""; + $ret .= "typedef struct $classname $classname;\n\n"; + foreach (@{$d->{data}}) { +- my $s = make_c_method($class, $_, {mode=>'cc'}); ++ my $s = make_c_method($class, $_, {mode=>'cc'}, %$accum); + next unless defined $s; + $ret .= "\n"; + $ret .= make_desc($_->{desc}); +- $ret .= make_c_method($class, $_, {mode=>'cc'}).";\n"; ++ $ret .= make_c_method($class, $_, {mode=>'cc'}, %$accum).";\n"; ++ if (grep {$_->{type} eq 'encoded string'} @{$_->{data}}) { ++ $ret .= make_c_method($class, $_, {mode=>'cc', wide=>true}, %$accum).";\n"; ++ $ret .= make_wide_macro($class, $_, {mode=>'cc'}, %$accum); ++ } ++ $ret .= "\n".$_->{'cc extra'}."\n" if defined $_->{'cc extra'}; + } + $ret .= "\n"; + return $ret; +@@ -105,7 +110,8 @@ $info{errors}{proc}{cc} = sub { + }; + + sub make_c_object ( $ @ ) { +- my ($t, $d) = @_; ++ my ($t, $d, $accum) = @_; ++ $accum = {} unless defined $accum; + my $struct; + $struct .= "Aspell"; + $struct .= to_mixed($d->{name}); +@@ -120,7 +126,7 @@ sub make_c_object ( $ @ ) { + "\n};\n"), + "typedef $t $struct $struct;", + join ("\n", +- map {make_c_method($d->{name}, $_, {mode=>'cc'}).";"} ++ map {make_c_method($d->{name}, $_, {mode=>'cc'}, %$accum).";"} + grep {$_->{type} eq 'method'} + @{$d->{data}}) + )."\n"; +diff --git a/auto/MkSrc/ProcImpl.pm b/auto/MkSrc/ProcImpl.pm +index b8628fd..3d0f220 100644 +--- a/auto/MkSrc/ProcImpl.pm ++++ b/auto/MkSrc/ProcImpl.pm +@@ -45,10 +45,13 @@ $info{class}{proc}{impl} = sub { + foreach (grep {$_ ne ''} split /\s*,\s*/, $data->{'c impl headers'}) { + $accum->{headers}{$_} = true; + } +- foreach my $d (@{$data->{data}}) { ++ my @d = @{$data->{data}}; ++ while (@d) { ++ my $d = shift @d; ++ my $need_wide = false; + next unless one_of $d->{type}, qw(method constructor destructor); + my @parms = @{$d->{data}} if exists $d->{data}; +- my $m = make_c_method $data->{name}, $d, {mode=>'cc_cxx', use_name=>true}, %$accum; ++ my $m = make_c_method $data->{name}, $d, {mode=>'cc_cxx', use_name=>true, wide=>$d->{wide}}, %$accum; + next unless defined $m; + $ret .= "extern \"C\" $m\n"; + $ret .= "{\n"; +@@ -57,24 +60,49 @@ $info{class}{proc}{impl} = sub { + } else { + if ($d->{type} eq 'method') { + my $ret_type = shift @parms; +- my $ret_native = to_type_name $ret_type, {mode=>'native_no_err', pos=>'return'}, %$accum; ++ my $ret_native = to_type_name $ret_type, {mode=>'native_no_err', pos=>'return', wide=>$d->{wide}}, %$accum; + my $snum = 0; ++ my $call_fun = $d->{name}; ++ my @call_parms; + foreach (@parms) { + my $n = to_lower($_->{name}); +- if ($_->{type} eq 'encoded string') { +- $accum->{headers}{'mutable string'} = true; +- $accum->{headers}{'convert'} = true; +- $ret .= " ths->temp_str_$snum.clear();\n"; +- $ret .= " ths->to_internal_->convert($n, ${n}_size, ths->temp_str_$snum);\n"; +- $ret .= " unsigned int s$snum = ths->temp_str_$snum.size();\n"; +- $_ = "MutableString(ths->temp_str_$snum.mstr(), s$snum)"; +- $snum++; ++ if ($_->{type} eq 'encoded string' && !exists($d->{'no conv'})) { ++ $need_wide = true unless $d->{wide}; ++ die unless exists $d->{'posib err'}; ++ $accum->{headers}{'mutable string'} = true; ++ $accum->{headers}{'convert'} = true; ++ my $name = get_c_func_name $data->{name}, $d, {mode=>'cc_cxx', use_name=>true, wide=>$d->{wide}}; ++ $ret .= " ths->temp_str_$snum.clear();\n"; ++ if ($d->{wide}) { ++ $ret .= " ${n}_size = get_correct_size(\"$name\", ths->to_internal_->in_type_width(), ${n}_size, ${n}_type_width);\n"; ++ } else { ++ $ret .= " PosibErr ${n}_fixed_size = get_correct_size(\"$name\", ths->to_internal_->in_type_width(), ${n}_size);\n"; ++ if (exists($d->{'on conv error'})) { ++ $ret .= " if (${n}_fixed_size.get_err()) {\n"; ++ $ret .= " ".$d->{'on conv error'}."\n"; ++ $ret .= " } else {\n"; ++ $ret .= " ${n}_size = ${n}_fixed_size;\n"; ++ $ret .= " }\n"; ++ } else { ++ $ret .= " ths->err_.reset(${n}_fixed_size.release_err());\n"; ++ $ret .= " if (ths->err_ != 0) return ".(c_error_cond $ret_type).";\n"; ++ } ++ } ++ $ret .= " ths->to_internal_->convert($n, ${n}_size, ths->temp_str_$snum);\n"; ++ $ret .= " unsigned int s$snum = ths->temp_str_$snum.size();\n"; ++ push @call_parms, "MutableString(ths->temp_str_$snum.mstr(), s$snum)"; ++ $snum++; ++ } elsif ($_->{type} eq 'encoded string') { ++ $need_wide = true unless $d->{wide}; ++ push @call_parms, $n, "${n}_size"; ++ push @call_parms, "${n}_type_width" if $d->{wide}; ++ $call_fun .= " wide" if $d->{wide}; + } else { +- $_ = $n; ++ push @call_parms, $n; + } + } +- my $parms = '('.(join ', ', @parms).')'; +- my $exp = "ths->".to_lower($d->{name})."$parms"; ++ my $parms = '('.(join ', ', @call_parms).')'; ++ my $exp = "ths->".to_lower($call_fun)."$parms"; + if (exists $d->{'posib err'}) { + $accum->{headers}{'posib err'} = true; + $ret .= " PosibErr<$ret_native> ret = $exp;\n"; +@@ -118,6 +146,7 @@ $info{class}{proc}{impl} = sub { + } + } + $ret .= "}\n\n"; ++ unshift @d,{%$d, wide=>true} if $need_wide; + } + return $ret; + }; +diff --git a/auto/MkSrc/Read.pm b/auto/MkSrc/Read.pm +index 4b3d1d0..4bf640e 100644 +--- a/auto/MkSrc/Read.pm ++++ b/auto/MkSrc/Read.pm +@@ -88,13 +88,13 @@ sub advance ( ) { + $in_pod = $1 if $line =~ /^\=(\w+)/; + $line = '' if $in_pod; + $in_pod = undef if $in_pod && $in_pod eq 'cut'; +- $line =~ s/\#.*$//; ++ $line =~ s/(? "%expression" is not a valid regular expression. + parms => expression ++ + } + group: speller + { +@@ -650,6 +651,7 @@ class: speller + posib err + desc => Returns 0 if it is not in the dictionary, + 1 if it is, or -1 on error. ++ on conv error => return 0; + / + bool + encoded string: word +@@ -715,6 +717,8 @@ class: speller + desc => Return NULL on error. + The word list returned by suggest is only + valid until the next call to suggest. ++ on conv error => ++ word = NULL; word_size = 0; + / + const word list + encoded string: word +@@ -840,7 +844,6 @@ class: document checker + void + + method: process +- + desc => Process a string. + The string passed in should only be split on + white space characters. Furthermore, between +@@ -849,10 +852,10 @@ class: document checker + in the document. Passing in strings out of + order, skipping strings or passing them in + more than once may lead to undefined results. ++ no conv + / + void +- string: str +- int: size ++ encoded string: str + + method: next misspelling + +@@ -860,9 +863,23 @@ class: document checker + processed string. If there are no more + misspelled words, then token.word will be + NULL and token.size will be 0 ++ cc extra => ++ \#define aspell_document_checker_next_misspelling_w(type, ths) \\ ++ aspell_document_checker_next_misspelling_adj(ths, sizeof(type)) + / + token object + ++ method: next misspelling adj ++ desc => internal: do not use ++ c impl => ++ Token res = ths->next_misspelling(); ++ res.offset /= type_width; ++ res.len /= type_width; ++ return res; ++ / ++ token object ++ int: type_width ++ + method: filter + + desc => Returns the underlying filter class. +@@ -922,9 +939,30 @@ class: string enumeration + ths->from_internal_->append_null(ths->temp_str); + return ths->temp_str.data(); + \} ++ cc extra => ++ \#define aspell_string_enumeration_next_w(type, ths) \\ ++ aspell_cast_(const type *, aspell_string_enumeration_next_wide(ths, sizeof(type))) + / + const string + ++ method: next wide ++ c impl => ++ const char * s = ths->next(); ++ if (s == 0) { ++ return s; ++ } else if (ths->from_internal_ == 0) \{ ++ assert(type_width == 1); ++ return s; ++ \} else \{ ++ assert(type_width == ths->from_internal_->out_type_width()); ++ ths->temp_str.clear(); ++ ths->from_internal_->convert(s,-1,ths->temp_str); ++ ths->from_internal_->append_null(ths->temp_str); ++ return ths->temp_str.data(); ++ \} ++ / ++ const void pointer ++ int: type_width + } + group: info + { +diff --git a/common/convert.cpp b/common/convert.cpp +index 1add95a..7ae0317 100644 +--- a/common/convert.cpp ++++ b/common/convert.cpp +@@ -541,18 +541,25 @@ namespace acommon { + // Trivial Conversion + // + ++ const char * unsupported_null_term_wide_string_msg = ++ "Null-terminated wide-character strings unsupported when used this way."; ++ + template + struct DecodeDirect : public Decode + { ++ DecodeDirect() {type_width = sizeof(Chr);} + void decode(const char * in0, int size, FilterCharVector & out) const { + const Chr * in = reinterpret_cast(in0); +- if (size == -1) { ++ if (size == -sizeof(Chr)) { + for (;*in; ++in) +- out.append(*in); ++ out.append(*in, sizeof(Chr)); ++ } else if (size <= -1) { ++ fprintf(stderr, "%s\n", unsupported_null_term_wide_string_msg); ++ abort(); + } else { +- const Chr * stop = reinterpret_cast(in0 +size); ++ const Chr * stop = reinterpret_cast(in0) + size/sizeof(Chr); + for (;in != stop; ++in) +- out.append(*in); ++ out.append(*in, sizeof(Chr)); + } + } + PosibErr decode_ec(const char * in0, int size, +@@ -565,6 +572,7 @@ namespace acommon { + template + struct EncodeDirect : public Encode + { ++ EncodeDirect() {type_width = sizeof(Chr);} + void encode(const FilterChar * in, const FilterChar * stop, + CharVector & out) const { + for (; in != stop; ++in) { +@@ -594,11 +602,15 @@ namespace acommon { + template + struct ConvDirect : public DirectConv + { ++ ConvDirect() {type_width = sizeof(Chr);} + void convert(const char * in0, int size, CharVector & out) const { +- if (size == -1) { ++ if (size == -sizeof(Chr)) { + const Chr * in = reinterpret_cast(in0); + for (;*in != 0; ++in) + out.append(in, sizeof(Chr)); ++ } else if (size <= -1) { ++ fprintf(stderr, "%s\n", unsupported_null_term_wide_string_msg); ++ abort(); + } else { + out.append(in0, size); + } +@@ -1121,5 +1133,20 @@ namespace acommon { + } + return 0; + } +- ++ ++ PosibErr unsupported_null_term_wide_string_err_(const char * func) { ++ static bool reported_to_stderr = false; ++ PosibErr err = make_err(other_error, unsupported_null_term_wide_string_msg); ++ if (!reported_to_stderr) { ++ CERR.printf("ERROR: %s: %s\n", func, unsupported_null_term_wide_string_msg); ++ reported_to_stderr = true; ++ } ++ return err; ++ } ++ ++ void unsupported_null_term_wide_string_abort_(const char * func) { ++ CERR.printf("%s: %s\n", unsupported_null_term_wide_string_msg); ++ abort(); ++ } ++ + } +diff --git a/common/convert.hpp b/common/convert.hpp +index 76332ee..c948973 100644 +--- a/common/convert.hpp ++++ b/common/convert.hpp +@@ -7,6 +7,8 @@ + #ifndef ASPELL_CONVERT__HPP + #define ASPELL_CONVERT__HPP + ++#include "settings.h" ++ + #include "string.hpp" + #include "posib_err.hpp" + #include "char_vector.hpp" +@@ -25,8 +27,9 @@ namespace acommon { + typedef const Config CacheConfig; + typedef const char * CacheKey; + String key; ++ int type_width; // type width in bytes + bool cache_key_eq(const char * l) const {return key == l;} +- ConvBase() {} ++ ConvBase() : type_width(1) {} + private: + ConvBase(const ConvBase &); + void operator=(const ConvBase &); +@@ -56,6 +59,8 @@ namespace acommon { + virtual ~Encode() {} + }; + struct DirectConv { // convert directly from in_code to out_code. ++ int type_width; // type width in bytes ++ DirectConv() : type_width(1) {} + // should not take ownership of decode and encode. + // decode and encode guaranteed to stick around for the life + // of the object. +@@ -126,6 +131,9 @@ namespace acommon { + const char * in_code() const {return decode_->key.c_str();} + const char * out_code() const {return encode_->key.c_str();} + ++ int in_type_width() const {return decode_->type_width;} ++ int out_type_width() const {return encode_->type_width;} ++ + void append_null(CharVector & out) const + { + const char nul[4] = {0,0,0,0}; // 4 should be enough +@@ -191,6 +199,10 @@ namespace acommon { + } + } + ++ void convert(const void * in, int size, CharVector & out) { ++ convert(static_cast(in), size, out); ++ } ++ + void generic_convert(const char * in, int size, CharVector & out); + + }; +@@ -412,6 +424,30 @@ namespace acommon { + return operator()(str, str + byte_size);} + }; + ++#ifdef SLOPPY_NULL_TERM_STRINGS ++ static const bool sloppy_null_term_strings = true; ++#else ++ static const bool sloppy_null_term_strings = false; ++#endif ++ ++ PosibErr unsupported_null_term_wide_string_err_(const char * func); ++ void unsupported_null_term_wide_string_abort_(const char * func); ++ ++ static inline PosibErr get_correct_size(const char * func, int conv_type_width, int size) { ++ if (sloppy_null_term_strings && size <= -1) ++ return -conv_type_width; ++ if (size <= -1 && -conv_type_width != size) ++ return unsupported_null_term_wide_string_err_(func); ++ return size; ++ } ++ static inline int get_correct_size(const char * func, int conv_type_width, int size, int type_width) { ++ if ((sloppy_null_term_strings || type_width <= -1) && size <= -1) ++ return -conv_type_width; ++ if (size <= -1 && conv_type_width != type_width) ++ unsupported_null_term_wide_string_abort_(func); ++ return size; ++ } ++ + } + + #endif +diff --git a/common/document_checker.cpp b/common/document_checker.cpp +index 5e510c4..0ccf1cd 100644 +--- a/common/document_checker.cpp ++++ b/common/document_checker.cpp +@@ -44,7 +44,9 @@ namespace acommon { + void DocumentChecker::process(const char * str, int size) + { + proc_str_.clear(); +- conv_->decode(str, size, proc_str_); ++ PosibErr fixed_size = get_correct_size("aspell_document_checker_process", conv_->in_type_width(), size); ++ if (!fixed_size.has_err()) ++ conv_->decode(str, fixed_size, proc_str_); + proc_str_.append(0); + FilterChar * begin = proc_str_.pbegin(); + FilterChar * end = proc_str_.pend() - 1; +@@ -53,6 +55,19 @@ namespace acommon { + tokenizer_->reset(begin, end); + } + ++ void DocumentChecker::process_wide(const void * str, int size, int type_width) ++ { ++ proc_str_.clear(); ++ int fixed_size = get_correct_size("aspell_document_checker_process", conv_->in_type_width(), size, type_width); ++ conv_->decode(static_cast(str), fixed_size, proc_str_); ++ proc_str_.append(0); ++ FilterChar * begin = proc_str_.pbegin(); ++ FilterChar * end = proc_str_.pend() - 1; ++ if (filter_) ++ filter_->process(begin, end); ++ tokenizer_->reset(begin, end); ++ } ++ + Token DocumentChecker::next_misspelling() + { + bool correct; +diff --git a/common/document_checker.hpp b/common/document_checker.hpp +index d35bb88..11a3c73 100644 +--- a/common/document_checker.hpp ++++ b/common/document_checker.hpp +@@ -36,6 +36,7 @@ namespace acommon { + PosibErr setup(Tokenizer *, Speller *, Filter *); + void reset(); + void process(const char * str, int size); ++ void process_wide(const void * str, int size, int type_width); + Token next_misspelling(); + + Filter * filter() {return filter_;} +diff --git a/common/version.cpp b/common/version.cpp +index 414d938..9e60b75 100644 +--- a/common/version.cpp ++++ b/common/version.cpp +@@ -1,8 +1,17 @@ + #include "settings.h" + +-extern "C" const char * aspell_version_string() { + #ifdef NDEBUG +- return VERSION " NDEBUG"; ++# define NDEBUG_STR " NDEBUG" ++#else ++# define NDEBUG_STR ++#endif ++ ++#ifdef SLOPPY_NULL_TERM_STRINGS ++# define SLOPPY_STR " SLOPPY" ++#else ++# define SLOPPY_STR + #endif +- return VERSION; ++ ++extern "C" const char * aspell_version_string() { ++ return VERSION NDEBUG_STR SLOPPY_STR; + } +diff --git a/configure.ac b/configure.ac +index 60e3b39..a5d51e3 100644 +--- a/configure.ac ++++ b/configure.ac +@@ -73,6 +73,9 @@ AC_ARG_ENABLE(filter-version-control, + AC_ARG_ENABLE(32-bit-hash-fun, + AS_HELP_STRING([--enable-32-bit-hash-fun],[use 32-bit hash function for compiled dictionaries])) + ++AC_ARG_ENABLE(sloppy-null-term-strings, ++ AS_HELP_STRING([--enable-sloppy-null-term-strings],[allows allow null terminated UCS-2 and UCS-4 strings])) ++ + AC_ARG_ENABLE(pspell-compatibility, + AS_HELP_STRING([--disable-pspell-compatibility],[don't install pspell compatibility libraries])) + +@@ -141,6 +144,11 @@ then + AC_DEFINE(USE_32_BIT_HASH_FUN, 1, [Defined if 32-bit hash function should be used for compiled dictionaries.]) + fi + ++if test "$enable_sloppy_null_term_strings" = "yes" ++then ++ AC_DEFINE(SLOPPY_NULL_TERM_STRINGS, 1, [Defined if null-terminated UCS-2 and UCS-4 strings should always be allowed.]) ++fi ++ + AM_CONDITIONAL(PSPELL_COMPATIBILITY, + [test "$enable_pspell_compatibility" != "no"]) + AM_CONDITIONAL(INCREMENTED_SONAME, +diff --git a/manual/aspell.texi b/manual/aspell.texi +index 45fa091..f400e06 100644 +--- a/manual/aspell.texi ++++ b/manual/aspell.texi +@@ -158,7 +158,8 @@ Installing + + * Generic Install Instructions:: + * HTML Manuals and "make clean":: +-* Curses Notes:: ++* Curses Notes:: ++* Upgrading from Aspell 0.60.7:: + * Loadable Filter Notes:: + * Upgrading from Aspell 0.50:: + * Upgrading from Aspell .33/Pspell .12:: +@@ -2206,18 +2207,26 @@ int correct = aspell_speller_check(spell_checker, @var{word}, @var{size}); + @end smallexample + + @noindent +- at var{word} is expected to be a @code{const char *} character +-string. If the encoding is set to be @code{ucs-2} or +- at code{ucs-4} @var{word} is expected to be a cast +-from either @code{const u16int *} or @code{const u32int *} +-respectively. @code{u16int} and @code{u32int} are generally +- at code{unsigned short} and @code{unsigned int} respectively. +- at var{size} is the length of the string or @code{-1} if the string +-is null terminated. If the string is a cast from @code{const u16int +-*} or @code{const u32int *} then @code{@i{size}} is the amount of +-space in bytes the string takes up after being cast to @code{const +-char *} and not the true size of the string. @code{sspell_speller_check} +-will return @code{0} if it is not found and non-zero otherwise. ++ at var{word} is expected to be a @code{const char *} character string. ++ at var{size} is the length of the string or @code{-1} if the string is ++null terminated. @code{aspell_speller_check} will return @code{0} if it is not found ++and non-zero otherwise. ++ ++If you are using the @code{ucs-2} or @code{ucs-4} encoding then the ++string is expected to be either a 2 or 4 byte wide integer ++(respectively) and the @code{_w} macro vesion should be used: ++ ++ at smallexample ++int correct = aspell_speller_check_w(spell_checker, @var{word}, @var{size}); ++ at end smallexample ++ ++The macro will cast the string to to the correct type and convert ++ at var{size} into bytes for you and then a call the special wide version of the ++function that will make sure the encoding is correct for the type ++passed in. For compatibility with older versions of Aspell the normal ++non-wide functions can still be used provided that the size of the ++string, in bytes, is also passed in. Null terminated @code{ucs-2} or ++ at code{ucs-4} are no longer supported when using the non-wide functions. + + If the word is not correct, then the @code{suggest} method can be used + to come up with likely replacements. +@@ -2236,7 +2245,28 @@ delete_aspell_string_enumeration(elements); + + Notice how @code{elements} is deleted but @code{suggestions} is not. + The value returned by @code{suggestions} is only valid to the next +-call to @code{suggest}. Once a replacement is made the ++call to @code{suggest}. ++ ++If you are using the @code{ucs-2} or @code{ucs-4} encoding then, in ++addition to using the @code{_w} macro for the @code{suggest} method, you ++should also use the @code{_w} macro with the @code{next} method which ++will cast the string to the correct type for you. For example, if you ++are using the @code{ucs-2} encoding and the string is a @code{const ++uint16_t *} then you should use: ++ ++ at smallexample ++AspellWordList * suggestions = aspell_speller_suggest_w(spell_checker, ++ @var{word}, @var{size}); ++AspellStringEnumeration * elements = aspell_word_list_elements(suggestions); ++const uint16_t * word; ++while ( (word = aspell_string_enumeration_next_w(uint16_t, aspell_elements)) != NULL ) ++@{ ++ // add to suggestion list ++@} ++delete_aspell_string_enumeration(elements); ++ at end smallexample ++ ++Once a replacement is made the + @code{store_repl} method should be used to communicate the replacement + pair back to the spell checker (for the reason, @pxref{Notes on + Storing Replacement Pairs}). Its usage is as follows: +diff --git a/manual/readme.texi b/manual/readme.texi +index 669ab8e..531721f 100644 +--- a/manual/readme.texi ++++ b/manual/readme.texi +@@ -15,15 +15,16 @@ The latest version can always be found at GNU Aspell's home page at + @uref{http://aspell.net}. + + @menu +-* Generic Install Instructions:: +-* HTML Manuals and "make clean":: +-* Curses Notes:: +-* Loadable Filter Notes:: +-* Using 32-Bit Dictionaries on a 64-Bit System:: +-* Upgrading from Aspell 0.50:: +-* Upgrading from Aspell .33/Pspell .12:: +-* Upgrading from a Pre-0.50 snapshot:: +-* WIN32 Notes:: ++* Generic Install Instructions:: ++* HTML Manuals and "make clean":: ++* Curses Notes:: ++* Upgrading from Aspell 0.60.7:: ++* Loadable Filter Notes:: ++* Using 32-Bit Dictionaries on a 64-Bit System:: ++* Upgrading from Aspell 0.50:: ++* Upgrading from Aspell .33/Pspell .12:: ++* Upgrading from a Pre-0.50 snapshot:: ++* WIN32 Notes:: + @end menu + + @node Generic Install Instructions +@@ -121,17 +122,62 @@ In addition your system must also support the @code{mblen} function. + Although this function was defined in the ISO C89 standard (ANSI + X3.159-1989), not all systems have it. + ++ at node Upgrading from Aspell 0.60.7 ++ at appendixsec Upgrading from Aspell 0.60.7 ++ ++To prevent a potentially unbounded buffer over-read, Aspell no longer ++supports null-terminated UCS-2 and UCS-4 encoded strings with the ++original C API. Null-termianted 8-bit or UTF-8 encoded strings are ++still supported, as are UCS-2 and UCS-4 encoded strings when the ++length is passed in. ++ ++As of Aspell 0.60.8 a function from the original API that expects an ++encoded string as a parameter will return meaningless results (or an ++error code) if string is null terminated and the encoding is set to ++ at code{ucs-2} or @code{ucs-4}. In addition, a single: ++ at example ++ERROR: aspell_speller_check: Null-terminated wide-character strings unsupported when used this way. ++ at end example ++will be printed to standard error the first time one of those ++functions is called. ++ ++Application that use null-terminated UCS-2/4 strings should either (1) ++use the interface intended for working with wide-characters ++(@xref{Through the C API}); or (2) define ++ at code{ASPELL_ENCODE_SETTING_SECURE} before including @code{aspell.h}. ++In the latter case is is important that the application explicitly ++sets the encoding to a known value. Defining ++ at code{ASPELL_ENCODE_SETTING_SECURE} and not setting the encoding ++explicitly or allowing user of the application to set the encoding ++could result in an unbounded buffer over-read. ++ ++If it is necessary to preserve binary compatibility with older ++versions of Aspell, the easiest thing would be to determine the length ++of the UCS-2/4 string---in bytes---and pass that in. Due to an ++implemenation detail, existing API functions can be made to work with ++null-terminated UCS-2/4 strings safely by passing in either @code{-2} ++or @code{-4} (corresponding to the width of the character type) as the ++size. Doing so, however, will cause a buffer over-read for unpatched ++version of Aspell. To avoid this it will be necessary to parse the ++version string to determine the correct value to use. However, no ++official support will be provided for the latter method. ++ ++If the application can not be recompiled, then Aspell can be configured ++to preserve the old behavior by passing ++ at option{--enable-sloppy-null-term-strings} to @command{configure}. When Aspell ++is compiled this way the version string will include the string ++ at samp{ SLOPPY}. ++ + @node Loadable Filter Notes + @appendixsec Loadable Filter Notes +- ++ + Support for being able to load additional filter modules at run-time + has only been verified to work on Linux platforms. If you get linker + errors when trying to use a filter, then it is likely that loadable + filter support is not working yet on your platform. Thus, in order to + get Aspell to work correctly you will need to avoid compiling the + filters as individual modules by using the +- at option{--enable-compile-in-filters} when configuring Aspell with +- at command{./configure}. ++ at option{--enable-compile-in-filters} @command{configure} option. + + @node Using 32-Bit Dictionaries on a 64-Bit System + @appendixsec Using 32-Bit Dictionaries on a 64-Bit System +-- +2.17.1 + diff --git a/meta/recipes-support/aspell/aspell/CVE-2019-20433-0002.patch b/meta/recipes-support/aspell/aspell/CVE-2019-20433-0002.patch new file mode 100644 index 0000000000..9569ddeebe --- /dev/null +++ b/meta/recipes-support/aspell/aspell/CVE-2019-20433-0002.patch @@ -0,0 +1,68 @@ +From cefd447e5528b08bb0cd6656bc52b4255692cefc Mon Sep 17 00:00:00 2001 +From: Kevin Atkinson +Date: Sat, 17 Aug 2019 20:25:21 -0400 +Subject: [PATCH 2/2] Increment library version to reflect API changes. + +CVE: CVE-2019-20433 +Upstream-Status: Backport [https://github.com/GNUAspell/aspell/commit/cefd447e5528b08bb0cd6656bc52b4255692cefc] + +Signed-off-by: Stefan Ghinea +--- + Makefile.am | 31 +++++++++++++++++-------------- + 1 file changed, 17 insertions(+), 14 deletions(-) + +diff --git a/Makefile.am b/Makefile.am +index 7e15851..19dc044 100644 +--- a/Makefile.am ++++ b/Makefile.am +@@ -94,18 +94,25 @@ libaspell_la_SOURCES =\ + + libaspell_la_LIBADD = $(LTLIBINTL) $(PTHREAD_LIB) + +-## Libtool to so name +-## C:R:A => (C-A).(A).(R) +-## 16:5:0 => 16.0.5 +-## 16:5:1 => 15.1.5 +-## 18:0:2 => 16.2.0 +-## 17:0:2 => 15.2.0 +- ++## The version string is current[:revision[:age]] ++## ++## Before a release that has changed the source code at all ++## increment revision. ++## ++## After merging changes that have changed the API in a backwards ++## comptable way set revision to 0 and bump both current and age. ++## ++## Do not change the API in a backwards incompatible way. ++## ++## See "Libtool: Updating version info" ++## (https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html) ++## for more into ++## + if INCREMENTED_SONAME +-libaspell_la_LDFLAGS = -version-info 18:0:2 -no-undefined ++libaspell_la_LDFLAGS = -version-info 19:0:3 -no-undefined + else + ## Use C-1:R:A +-libaspell_la_LDFLAGS = -version-info 17:0:2 -no-undefined ++libaspell_la_LDFLAGS = -version-info 18:0:3 -no-undefined + endif + + if PSPELL_COMPATIBILITY +@@ -113,11 +120,7 @@ libpspell_la_SOURCES = lib/dummy.cpp + + libpspell_la_LIBADD = libaspell.la + +-if INCREMENTED_SONAME +-libpspell_la_LDFLAGS = -version-info 18:0:2 -no-undefined +-else +-libpspell_la_LDFLAGS = -version-info 17:0:2 -no-undefined +-endif ++libpspell_la_LDFLAGS = $(libaspell_la_LDFLAGS) + + endif + +-- +2.17.1 + diff --git a/meta/recipes-support/aspell/aspell_0.60.7.bb b/meta/recipes-support/aspell/aspell_0.60.7.bb index b565cb3c6e..1e104c263c 100644 --- a/meta/recipes-support/aspell/aspell_0.60.7.bb +++ b/meta/recipes-support/aspell/aspell_0.60.7.bb @@ -8,6 +8,8 @@ PR = "r1" SRC_URI = "${GNU_MIRROR}/aspell/aspell-${PV}.tar.gz \ file://0001-Fix-various-bugs-found-by-OSS-Fuze.patch \ + file://CVE-2019-20433-0001.patch \ + file://CVE-2019-20433-0002.patch \ " SRC_URI[md5sum] = "8ef2252609c511cd2bb26f3a3932ef28" SRC_URI[sha256sum] = "5ca8fc8cb0370cc6c9eb5b64c6d1bc5d57b3750dbf17887726c3407d833b70e4" -- 2.24.1 From anuj.mittal at intel.com Mon Mar 16 16:31:03 2020 From: anuj.mittal at intel.com (Anuj Mittal) Date: Tue, 17 Mar 2020 00:31:03 +0800 Subject: [OE-core] [PATCH][zeus 5/7] python3: Upgrade 3.7.6 -> 3.7.7 In-Reply-To: References: Message-ID: <3c40cfe7433999272e1698e2c914d6d190f76b63.1584375668.git.anuj.mittal@intel.com> From: Adrian Bunk THE LICENSE checksum changed in this update due to copyright notice added for 2020. Signed-off-by: Adrian Bunk Signed-off-by: Anuj Mittal --- .../python/{python3_3.7.6.bb => python3_3.7.7.bb} | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) rename meta/recipes-devtools/python/{python3_3.7.6.bb => python3_3.7.7.bb} (98%) diff --git a/meta/recipes-devtools/python/python3_3.7.6.bb b/meta/recipes-devtools/python/python3_3.7.7.bb similarity index 98% rename from meta/recipes-devtools/python/python3_3.7.6.bb rename to meta/recipes-devtools/python/python3_3.7.7.bb index b33b7028d4..823eb2f8fd 100644 --- a/meta/recipes-devtools/python/python3_3.7.6.bb +++ b/meta/recipes-devtools/python/python3_3.7.7.bb @@ -3,7 +3,7 @@ HOMEPAGE = "http://www.python.org" LICENSE = "PSFv2" SECTION = "devel/python" -LIC_FILES_CHKSUM = "file://LICENSE;md5=e466242989bd33c1bd2b6a526a742498" +LIC_FILES_CHKSUM = "file://LICENSE;md5=203a6dbc802ee896020a47161e759642" SRC_URI = "http://www.python.org/ftp/python/${PV}/Python-${PV}.tar.xz \ file://run-ptest \ @@ -38,8 +38,8 @@ SRC_URI_append_class-nativesdk = " \ file://0001-main.c-if-OEPYTHON3HOME-is-set-use-instead-of-PYTHON.patch \ " -SRC_URI[md5sum] = "c08fbee72ad5c2c95b0f4e44bf6fd72c" -SRC_URI[sha256sum] = "55a2cce72049f0794e9a11a84862e9039af9183603b78bc60d89539f82cf533f" +SRC_URI[md5sum] = "172c650156f7bea68ce31b2fd01fa766" +SRC_URI[sha256sum] = "06a0a9f1bf0d8cd1e4121194d666c4e28ddae4dd54346de6c343206599f02136" # exclude pre-releases for both python 2.x and 3.x UPSTREAM_CHECK_REGEX = "[Pp]ython-(?P\d+(\.\d+)+).tar" -- 2.24.1 From anuj.mittal at intel.com Mon Mar 16 16:31:04 2020 From: anuj.mittal at intel.com (Anuj Mittal) Date: Tue, 17 Mar 2020 00:31:04 +0800 Subject: [OE-core] [PATCH][zeus 6/7] libarchive: Fix CVE-2020-9308 In-Reply-To: References: Message-ID: <878817358eb7c25ffa48d10dde9475299674a96c.1584375668.git.anuj.mittal@intel.com> From: Wenlin Kang Fix CVE-2020-9308 Signed-off-by: Wenlin Kang Signed-off-by: Anuj Mittal --- ...ct-files-that-declare-invalid-header.patch | 124 ++++++++++++++++++ .../libarchive/libarchive_3.4.0.bb | 1 + 2 files changed, 125 insertions(+) create mode 100644 meta/recipes-extended/libarchive/libarchive/0001-RAR5-reader-reject-files-that-declare-invalid-header.patch diff --git a/meta/recipes-extended/libarchive/libarchive/0001-RAR5-reader-reject-files-that-declare-invalid-header.patch b/meta/recipes-extended/libarchive/libarchive/0001-RAR5-reader-reject-files-that-declare-invalid-header.patch new file mode 100644 index 0000000000..a84c1f1f76 --- /dev/null +++ b/meta/recipes-extended/libarchive/libarchive/0001-RAR5-reader-reject-files-that-declare-invalid-header.patch @@ -0,0 +1,124 @@ +From c1fe0a8cc8dde8ba3eae3d17e34060d2d6e4eb96 Mon Sep 17 00:00:00 2001 +From: Grzegorz Antoniak +Date: Sun, 2 Feb 2020 08:04:41 +0100 +Subject: [PATCH] RAR5 reader: reject files that declare invalid header flags + +One of the fields in RAR5's base block structure is the size of the +header. Some invalid files declare a 0 header size setting, which can +confuse the unpacker. Minimum header size for RAR5 base blocks is 7 +bytes (4 bytes for CRC, and 3 bytes for the rest), so block size of 0 +bytes should be rejected at header parsing stage. + +The fix adds an error condition if header size of 0 bytes is detected. +In this case, the unpacker will not attempt to unpack the file, as the +header is corrupted. + +The commit also adds OSSFuzz #20459 sample to test further regressions +in this area. + +Upstream-Status: Backport[https://github.com/libarchive/libarchive/commit/94821008d6eea81e315c5881cdf739202961040a] +CVE: CVE-2020-9308 + +Signed-off-by: Wenlin Kang +--- + Makefile.am | 1 + + libarchive/archive_read_support_format_rar5.c | 17 +++++++++++++++-- + libarchive/test/test_read_format_rar5.c | 15 +++++++++++++++ + ...d_format_rar5_block_size_is_too_small.rar.uu | 8 ++++++++ + 4 files changed, 39 insertions(+), 2 deletions(-) + create mode 100644 libarchive/test/test_read_format_rar5_block_size_is_too_small.rar.uu + +diff --git a/Makefile.am b/Makefile.am +index da78b24..01abf20 100644 +--- a/Makefile.am ++++ b/Makefile.am +@@ -863,6 +863,7 @@ libarchive_test_EXTRA_DIST=\ + libarchive/test/test_read_format_rar5_symlink.rar.uu \ + libarchive/test/test_read_format_rar5_truncated_huff.rar.uu \ + libarchive/test/test_read_format_rar5_win32.rar.uu \ ++ libarchive/test/test_read_format_rar5_block_size_is_too_small.rar.uu \ + libarchive/test/test_read_format_raw.bufr.uu \ + libarchive/test/test_read_format_raw.data.gz.uu \ + libarchive/test/test_read_format_raw.data.Z.uu \ +diff --git a/libarchive/archive_read_support_format_rar5.c b/libarchive/archive_read_support_format_rar5.c +index 7c24627..f73393c 100644 +--- a/libarchive/archive_read_support_format_rar5.c ++++ b/libarchive/archive_read_support_format_rar5.c +@@ -2034,6 +2034,8 @@ static int scan_for_signature(struct archive_read* a); + static int process_base_block(struct archive_read* a, + struct archive_entry* entry) + { ++ const size_t SMALLEST_RAR5_BLOCK_SIZE = 3; ++ + struct rar5* rar = get_context(a); + uint32_t hdr_crc, computed_crc; + size_t raw_hdr_size = 0, hdr_size_len, hdr_size; +@@ -2057,15 +2059,26 @@ static int process_base_block(struct archive_read* a, + return ARCHIVE_EOF; + } + ++ hdr_size = raw_hdr_size + hdr_size_len; ++ + /* Sanity check, maximum header size for RAR5 is 2MB. */ +- if(raw_hdr_size > (2 * 1024 * 1024)) { ++ if(hdr_size > (2 * 1024 * 1024)) { + archive_set_error(&a->archive, ARCHIVE_ERRNO_FILE_FORMAT, + "Base block header is too large"); + + return ARCHIVE_FATAL; + } + +- hdr_size = raw_hdr_size + hdr_size_len; ++ /* Additional sanity checks to weed out invalid files. */ ++ if(raw_hdr_size == 0 || hdr_size_len == 0 || ++ hdr_size < SMALLEST_RAR5_BLOCK_SIZE) ++ { ++ archive_set_error(&a->archive, ARCHIVE_ERRNO_FILE_FORMAT, ++ "Too small block encountered (%ld bytes)", ++ raw_hdr_size); ++ ++ return ARCHIVE_FATAL; ++ } + + /* Read the whole header data into memory, maximum memory use here is + * 2MB. */ +diff --git a/libarchive/test/test_read_format_rar5.c b/libarchive/test/test_read_format_rar5.c +index 1408f37..32e7ed8 100644 +--- a/libarchive/test/test_read_format_rar5.c ++++ b/libarchive/test/test_read_format_rar5.c +@@ -1194,3 +1194,18 @@ DEFINE_TEST(test_read_format_rar5_fileattr) + + EPILOGUE(); + } ++ ++DEFINE_TEST(test_read_format_rar5_block_size_is_too_small) ++{ ++ char buf[4096]; ++ PROLOGUE("test_read_format_rar5_block_size_is_too_small.rar"); ++ ++ /* This file is damaged, so those functions should return failure. ++ * Additionally, SIGSEGV shouldn't be raised during execution ++ * of those functions. */ ++ ++ assertA(archive_read_next_header(a, &ae) != ARCHIVE_OK); ++ assertA(archive_read_data(a, buf, sizeof(buf)) <= 0); ++ ++ EPILOGUE(); ++} +diff --git a/libarchive/test/test_read_format_rar5_block_size_is_too_small.rar.uu b/libarchive/test/test_read_format_rar5_block_size_is_too_small.rar.uu +new file mode 100644 +index 0000000..5cad219 +--- /dev/null ++++ b/libarchive/test/test_read_format_rar5_block_size_is_too_small.rar.uu +@@ -0,0 +1,8 @@ ++begin 644 test_read_format_rar5_block_size_is_too_small.rar ++M4F%R(1H'`0"-[P+2``+'(!P,("`@N`,!`B`@("`@("`@("`@("`@("#_("`@ ++M("`@("`@("`@((:Q;2!4-'-^4B`!((WO`M(``O\@$/\@-R`@("`@("`@("`@ ++M``X@("`@("`@____("`@("`@(/\@("`@("`@("`@("#_(+6U,2"UM;6UM[CU ++M)B`@*(0G(`!.`#D\3R``(/__(,+_````-0#_($&%*/HE=C+N`"```"```"`D ++J`)$#("#_("#__P`@__\@_R#_("`@("`@("#_("#__R`@(/__("#__R`" ++` ++end +-- +2.23.0 + diff --git a/meta/recipes-extended/libarchive/libarchive_3.4.0.bb b/meta/recipes-extended/libarchive/libarchive_3.4.0.bb index c196382b07..db45ccf654 100644 --- a/meta/recipes-extended/libarchive/libarchive_3.4.0.bb +++ b/meta/recipes-extended/libarchive/libarchive_3.4.0.bb @@ -33,6 +33,7 @@ EXTRA_OECONF += "--enable-largefile" SRC_URI = "http://libarchive.org/downloads/libarchive-${PV}.tar.gz \ file://CVE-2019-19221.patch \ + file://0001-RAR5-reader-reject-files-that-declare-invalid-header.patch \ " SRC_URI[md5sum] = "6046396255bd7cf6d0f6603a9bda39ac" -- 2.24.1 From anuj.mittal at intel.com Mon Mar 16 16:31:05 2020 From: anuj.mittal at intel.com (Anuj Mittal) Date: Tue, 17 Mar 2020 00:31:05 +0800 Subject: [OE-core] [PATCH][zeus 7/7] bluez: fix CVE-2020-0556 In-Reply-To: References: Message-ID: It was discovered that BlueZ's HID and HOGP profiles implementations don't specifically require bonding between the device and the host. This creates an opportunity for an malicious device to connect to a target host to either impersonate an existing HID device without security or to cause an SDP or GATT service discovery to take place which would allow HID reports to be injected to the input subsystem from a non-bonded source. (From OE-Core rev: d598f8eee0741148416e8660e10c716654205cb5) Signed-off-by: Anuj Mittal Signed-off-by: Richard Purdie (cherry picked from commit bed169a07b04a7dc003958fa309e6ff761f85a72) --- meta/recipes-connectivity/bluez5/bluez5.inc | 2 + .../bluez5/bluez5/CVE-2020-0556-1.patch | 35 +++++ .../bluez5/bluez5/CVE-2020-0556-2.patch | 143 ++++++++++++++++++ 3 files changed, 180 insertions(+) create mode 100644 meta/recipes-connectivity/bluez5/bluez5/CVE-2020-0556-1.patch create mode 100644 meta/recipes-connectivity/bluez5/bluez5/CVE-2020-0556-2.patch diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc b/meta/recipes-connectivity/bluez5/bluez5.inc index f582a07e22..75fc2dbf4c 100644 --- a/meta/recipes-connectivity/bluez5/bluez5.inc +++ b/meta/recipes-connectivity/bluez5/bluez5.inc @@ -58,6 +58,8 @@ SRC_URI = "\ file://CVE-2018-10910.patch \ file://gcc9-fixes.patch \ file://0001-tools-Fix-build-after-y2038-changes-in-glibc.patch \ + file://CVE-2020-0556-1.patch \ + file://CVE-2020-0556-2.patch \ " S = "${WORKDIR}/bluez-${PV}" diff --git a/meta/recipes-connectivity/bluez5/bluez5/CVE-2020-0556-1.patch b/meta/recipes-connectivity/bluez5/bluez5/CVE-2020-0556-1.patch new file mode 100644 index 0000000000..a6bf31e14b --- /dev/null +++ b/meta/recipes-connectivity/bluez5/bluez5/CVE-2020-0556-1.patch @@ -0,0 +1,35 @@ +From 8cdbd3b09f29da29374e2f83369df24228da0ad1 Mon Sep 17 00:00:00 2001 +From: Alain Michaud +Date: Tue, 10 Mar 2020 02:35:16 +0000 +Subject: [PATCH 1/2] HOGP must only accept data from bonded devices. + +HOGP 1.0 Section 6.1 establishes that the HOGP must require bonding. + +Reference: +https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00352.htm + +Upstream-Status: Backport [https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=8cdbd3b09f29da29374e2f83369df24228da0ad1] +Signed-off-by: Anuj Mittal +CVE: CVE-2020-0556 +--- + profiles/input/hog.c | 4 ++++ + 1 file changed, 4 insertions(+) + +diff --git a/profiles/input/hog.c b/profiles/input/hog.c +index 83c017dcb..dfac68921 100644 +--- a/profiles/input/hog.c ++++ b/profiles/input/hog.c +@@ -186,6 +186,10 @@ static int hog_accept(struct btd_service *service) + return -EINVAL; + } + ++ /* HOGP 1.0 Section 6.1 requires bonding */ ++ if (!device_is_bonded(device, btd_device_get_bdaddr_type(device))) ++ return -ECONNREFUSED; ++ + /* TODO: Replace GAttrib with bt_gatt_client */ + bt_hog_attach(dev->hog, attrib); + +-- +2.24.1 + diff --git a/meta/recipes-connectivity/bluez5/bluez5/CVE-2020-0556-2.patch b/meta/recipes-connectivity/bluez5/bluez5/CVE-2020-0556-2.patch new file mode 100644 index 0000000000..8acb2f15ec --- /dev/null +++ b/meta/recipes-connectivity/bluez5/bluez5/CVE-2020-0556-2.patch @@ -0,0 +1,143 @@ +From 3cccdbab2324086588df4ccf5f892fb3ce1f1787 Mon Sep 17 00:00:00 2001 +From: Alain Michaud +Date: Tue, 10 Mar 2020 02:35:18 +0000 +Subject: [PATCH 2/2] HID accepts bonded device connections only. + +This change adds a configuration for platforms to choose a more secure +posture for the HID profile. While some older mice are known to not +support pairing or encryption, some platform may choose a more secure +posture by requiring the device to be bonded and require the +connection to be encrypted when bonding is required. + +Reference: +https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00352.html + +Upstream-Status: Backport [https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=3cccdbab2324086588df4ccf5f892fb3ce1f1787] +Signed-off-by: Anuj Mittal +CVE: CVE-2020-0556 + +--- + profiles/input/device.c | 23 ++++++++++++++++++++++- + profiles/input/device.h | 1 + + profiles/input/input.conf | 8 ++++++++ + profiles/input/manager.c | 13 ++++++++++++- + 4 files changed, 43 insertions(+), 2 deletions(-) + +diff --git a/profiles/input/device.c b/profiles/input/device.c +index 2cb3811c8..d89da2d7c 100644 +--- a/profiles/input/device.c ++++ b/profiles/input/device.c +@@ -92,6 +92,7 @@ struct input_device { + + static int idle_timeout = 0; + static bool uhid_enabled = false; ++static bool classic_bonded_only = false; + + void input_set_idle_timeout(int timeout) + { +@@ -103,6 +104,11 @@ void input_enable_userspace_hid(bool state) + uhid_enabled = state; + } + ++void input_set_classic_bonded_only(bool state) ++{ ++ classic_bonded_only = state; ++} ++ + static void input_device_enter_reconnect_mode(struct input_device *idev); + static int connection_disconnect(struct input_device *idev, uint32_t flags); + +@@ -970,8 +976,18 @@ static int hidp_add_connection(struct input_device *idev) + if (device_name_known(idev->device)) + device_get_name(idev->device, req->name, sizeof(req->name)); + ++ /* Make sure the device is bonded if required */ ++ if (classic_bonded_only && !device_is_bonded(idev->device, ++ btd_device_get_bdaddr_type(idev->device))) { ++ error("Rejected connection from !bonded device %s", dst_addr); ++ goto cleanup; ++ } ++ + /* Encryption is mandatory for keyboards */ +- if (req->subclass & 0x40) { ++ /* Some platforms may choose to require encryption for all devices */ ++ /* Note that this only matters for pre 2.1 devices as otherwise the */ ++ /* device is encrypted by default by the lower layers */ ++ if (classic_bonded_only || req->subclass & 0x40) { + if (!bt_io_set(idev->intr_io, &gerr, + BT_IO_OPT_SEC_LEVEL, BT_IO_SEC_MEDIUM, + BT_IO_OPT_INVALID)) { +@@ -1203,6 +1219,11 @@ static void input_device_enter_reconnect_mode(struct input_device *idev) + DBG("path=%s reconnect_mode=%s", idev->path, + reconnect_mode_to_string(idev->reconnect_mode)); + ++ /* Make sure the device is bonded if required */ ++ if (classic_bonded_only && !device_is_bonded(idev->device, ++ btd_device_get_bdaddr_type(idev->device))) ++ return; ++ + /* Only attempt an auto-reconnect when the device is required to + * accept reconnections from the host. + */ +diff --git a/profiles/input/device.h b/profiles/input/device.h +index 51a9aee18..3044db673 100644 +--- a/profiles/input/device.h ++++ b/profiles/input/device.h +@@ -29,6 +29,7 @@ struct input_conn; + + void input_set_idle_timeout(int timeout); + void input_enable_userspace_hid(bool state); ++void input_set_classic_bonded_only(bool state); + + int input_device_register(struct btd_service *service); + void input_device_unregister(struct btd_service *service); +diff --git a/profiles/input/input.conf b/profiles/input/input.conf +index 3e1d65aae..166aff4a4 100644 +--- a/profiles/input/input.conf ++++ b/profiles/input/input.conf +@@ -11,3 +11,11 @@ + # Enable HID protocol handling in userspace input profile + # Defaults to false (HIDP handled in HIDP kernel module) + #UserspaceHID=true ++ ++# Limit HID connections to bonded devices ++# The HID Profile does not specify that devices must be bonded, however some ++# platforms may want to make sure that input connections only come from bonded ++# device connections. Several older mice have been known for not supporting ++# pairing/encryption. ++# Defaults to false to maximize device compatibility. ++#ClassicBondedOnly=true +diff --git a/profiles/input/manager.c b/profiles/input/manager.c +index 1d31b0652..5cd27b839 100644 +--- a/profiles/input/manager.c ++++ b/profiles/input/manager.c +@@ -96,7 +96,7 @@ static int input_init(void) + config = load_config_file(CONFIGDIR "/input.conf"); + if (config) { + int idle_timeout; +- gboolean uhid_enabled; ++ gboolean uhid_enabled, classic_bonded_only; + + idle_timeout = g_key_file_get_integer(config, "General", + "IdleTimeout", &err); +@@ -114,6 +114,17 @@ static int input_init(void) + input_enable_userspace_hid(uhid_enabled); + } else + g_clear_error(&err); ++ ++ classic_bonded_only = g_key_file_get_boolean(config, "General", ++ "ClassicBondedOnly", &err); ++ ++ if (!err) { ++ DBG("input.conf: ClassicBondedOnly=%s", ++ classic_bonded_only ? "true" : "false"); ++ input_set_classic_bonded_only(classic_bonded_only); ++ } else ++ g_clear_error(&err); ++ + } + + btd_profile_register(&input_profile); +-- +2.24.1 + -- 2.24.1 From sjolley.yp.pm at gmail.com Mon Mar 16 16:42:11 2020 From: sjolley.yp.pm at gmail.com (sjolley.yp.pm at gmail.com) Date: Mon, 16 Mar 2020 09:42:11 -0700 Subject: [OE-core] Yocto Project Newcomer & Unassigned Bugs - Help Needed Message-ID: <039001d5fbb1$d7ca9a20$875fce60$@gmail.com> All, The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on the triage page under the appropriate heading: https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs The idea is these bugs should be straight forward for a person to help work on who doesn't have deep experience with the project. If anyone can help, please take ownership of the bug and send patches! If anyone needs help/advice there are people on irc who can likely do so, or some of the more experienced contributors will likely be happy to help too. Also, the triage team meets weekly and does its best to handle the bugs reported into the Bugzilla. The number of people attending that meeting has fallen, as have the number of people available to help fix bugs. One of the things we hear users report is they don't know how to help. We (the triage team) are therefore going to start reporting out the currently 291 unassigned or newcomer bugs. We're hoping people may be able to spare some time now and again to help out with these. Bugs are split into two types, "true bugs" where things don't work as they should and "enhancements" which are features we'd want to add to the system. There are also roughly four different "priority" classes right now, "3.1", "3.2, "3.99" and "Future", the more pressing/urgent issues being in "3.1" and then "3.2". Please review this link and if a bug is something you would be able to help with either take ownership of the bug, or send me (sjolley.yp.pm at gmail.com ) an e-mail with the bug number you would like and I will assign it to you (please make sure you have a Bugzilla account). The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer _Bugs Thanks, Stephen K. Jolley Yocto Project Program Manager * Cell: (208) 244-4460 * Email: sjolley.yp.pm at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From anoo at linux.ibm.com Mon Mar 16 18:09:10 2020 From: anoo at linux.ibm.com (Adriana Kobylak) Date: Mon, 16 Mar 2020 13:09:10 -0500 Subject: [OE-core] [meta-oe][PATCH] bootconfig: Add recipe for bootconfig kernel tool Message-ID: <1584382150-6636-1-git-send-email-anoo@linux.ibm.com> From: Adriana Kobylak The Boot Configuration kernel feature provides a tool named bootconfig to add a config file to an initramfs. Reference: https://github.com/torvalds/linux/blob/master/Documentation/admin-guide/bootconfig.rst Add a recipe to meta-oe/recipes-kernel/ where other kernel tools reside to build it. Add a native option so that this tool can be used during the build process to add the config file to the initramfs which can then be used on a system. Signed-off-by: Adriana Kobylak --- .../recipes-kernel/bootconfig/bootconfig_git.bb | 50 ++++++++++++++++++++++ 1 file changed, 50 insertions(+) create mode 100644 meta-oe/recipes-kernel/bootconfig/bootconfig_git.bb diff --git a/meta-oe/recipes-kernel/bootconfig/bootconfig_git.bb b/meta-oe/recipes-kernel/bootconfig/bootconfig_git.bb new file mode 100644 index 0000000..8b8945e --- /dev/null +++ b/meta-oe/recipes-kernel/bootconfig/bootconfig_git.bb @@ -0,0 +1,50 @@ +SUMMARY = "Boot configuration kernel tool" +DESCRIPTION = "Adds a boot configuration file to the initrd that expands the \ +kernel command line." +LICENSE = "GPLv2" + +inherit kernelsrc kernel-arch + +do_configure[depends] += "virtual/kernel:do_shared_workdir" + +EXTRA_OEMAKE_class-target = '\ + -C ${S}/tools/bootconfig \ + AR="${AR}" \ + ARCH=${ARCH} \ + CC="${CC} ${CFLAGS} ${LDFLAGS}" \ + CROSS=${TARGET_PREFIX} \ + DESTDIR="${D}" \ + LD="${LD}" \ + O=${B} \ +' + +EXTRA_OEMAKE_class-native = '\ + -C ${S}/tools/bootconfig \ + AR="${AR}" \ + ARCH=${ARCH} \ + CC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}" \ + DESTDIR="${D}" \ + LD="${LD}" \ + O=${B} \ +' + +EXTRA_OEMAKE_class-nativesdk = '\ + -C ${S}/tools/bootconfig \ + AR="${AR}" \ + ARCH=${ARCH} \ + CC="${CC} ${CFLAGS} ${LDFLAGS}" \ + CROSS_COMPILE=${HOST_PREFIX} \ + DESTDIR="${D}" \ + LD="${LD}" \ + O=${B} \ +' + +do_compile() { + oe_runmake +} + +do_install() { + oe_runmake install +} + +BBCLASSEXTEND = "native nativesdk" -- 1.8.3.1 From armccurdy at gmail.com Mon Mar 16 18:48:55 2020 From: armccurdy at gmail.com (Andre McCurdy) Date: Mon, 16 Mar 2020 11:48:55 -0700 Subject: [OE-core] [PATCH 1/5] gcc-runtime: apply ARM specific workaround to big-endian ARM too Message-ID: <20200316184859.11635-1-armccurdy@gmail.com> Signed-off-by: Andre McCurdy --- meta/recipes-devtools/gcc/gcc-runtime.inc | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/recipes-devtools/gcc/gcc-runtime.inc b/meta/recipes-devtools/gcc/gcc-runtime.inc index b2c5d43bd4..771f344ac0 100644 --- a/meta/recipes-devtools/gcc/gcc-runtime.inc +++ b/meta/recipes-devtools/gcc/gcc-runtime.inc @@ -20,6 +20,7 @@ EXTRA_OECONF_append_libc-newlib = " --with-newlib" # Disable ifuncs for libatomic on arm conflicts -march/-mcpu EXTRA_OECONF_append_arm = " libat_cv_have_ifunc=no " +EXTRA_OECONF_append_armeb = " libat_cv_have_ifunc=no " # Newlib does not support symbol versioning on libsdtcc++ SYMVERS_CONF_libc-newlib = "" -- 2.24.0 From armccurdy at gmail.com Mon Mar 16 18:48:56 2020 From: armccurdy at gmail.com (Andre McCurdy) Date: Mon, 16 Mar 2020 11:48:56 -0700 Subject: [OE-core] [PATCH 2/5] opkg-utils: remove python scripts etc for the class-target only In-Reply-To: <20200316184859.11635-1-armccurdy@gmail.com> References: <20200316184859.11635-1-armccurdy@gmail.com> Message-ID: <20200316184859.11635-2-armccurdy@gmail.com> OE's packaging functions assume that the opkg-utils python scipts are always provided by opkg-utils-native, so the scripts should be removed for class-target only. Signed-off-by: Andre McCurdy --- meta/recipes-devtools/opkg-utils/opkg-utils_0.4.2.bb | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/meta/recipes-devtools/opkg-utils/opkg-utils_0.4.2.bb b/meta/recipes-devtools/opkg-utils/opkg-utils_0.4.2.bb index eda73db6a4..9315240190 100644 --- a/meta/recipes-devtools/opkg-utils/opkg-utils_0.4.2.bb +++ b/meta/recipes-devtools/opkg-utils/opkg-utils_0.4.2.bb @@ -34,13 +34,13 @@ do_install() { if ! ${@bb.utils.contains('PACKAGECONFIG', 'update-alternatives', 'true', 'false', d)}; then rm -f "${D}${bindir}/update-alternatives" fi - - if ! ${@bb.utils.contains('PACKAGECONFIG', 'python', 'true', 'false', d)}; then - grep -lZ "/usr/bin/env.*python" ${D}${bindir}/* | xargs -0 rm - fi } do_install_append_class-target() { + if ! ${@bb.utils.contains('PACKAGECONFIG', 'python', 'true', 'false', d)}; then + grep -lZ "/usr/bin/env.*python" ${D}${bindir}/* | xargs -0 rm + fi + if [ -e "${D}${bindir}/update-alternatives" ]; then sed -i ${D}${bindir}/update-alternatives -e 's,/usr/bin,${bindir},g; s,/usr/lib,${nonarch_libdir},g' fi -- 2.24.0 From armccurdy at gmail.com Mon Mar 16 18:48:57 2020 From: armccurdy at gmail.com (Andre McCurdy) Date: Mon, 16 Mar 2020 11:48:57 -0700 Subject: [OE-core] [PATCH 3/5] tune-arm1136jf-s.inc: restore vfp to TUNE_FEATURES_tune-arm1136jfs In-Reply-To: <20200316184859.11635-1-armccurdy@gmail.com> References: <20200316184859.11635-1-armccurdy@gmail.com> Message-ID: <20200316184859.11635-3-armccurdy@gmail.com> The change to TUNE_FEATURES_tune-arm1136jfs as part of: https://git.openembedded.org/openembedded-core/commit/?id=ac83d22eb5031f7fdd09d34a1a46d92fd3e39a3c effectively removed both armv6 and vfp, when it should have removed armv6 only. Add vfp back to TUNE_FEATURES_tune-arm1136jfs. Signed-off-by: Andre McCurdy --- meta/conf/machine/include/tune-arm1136jf-s.inc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/conf/machine/include/tune-arm1136jf-s.inc b/meta/conf/machine/include/tune-arm1136jf-s.inc index b25995d495..173cb468ef 100644 --- a/meta/conf/machine/include/tune-arm1136jf-s.inc +++ b/meta/conf/machine/include/tune-arm1136jf-s.inc @@ -10,7 +10,7 @@ AVAILTUNES += "arm1136jfs arm1136jfshf" ARMPKGARCH_tune-arm1136jfs = "arm1136jfs" ARMPKGARCH_tune-arm1136jfshf = "arm1136jfs" # mcpu is used so don't use armv6 as we don't want march -TUNE_FEATURES_tune-arm1136jfs = "arm arm1136jfs" +TUNE_FEATURES_tune-arm1136jfs = "arm vfp arm1136jfs" TUNE_FEATURES_tune-arm1136jfshf = "${TUNE_FEATURES_tune-arm1136jfs} callconvention-hard" PACKAGE_EXTRA_ARCHS_tune-arm1136jfs = "${PACKAGE_EXTRA_ARCHS_tune-armv6} arm1136jfs-vfp" PACKAGE_EXTRA_ARCHS_tune-arm1136jfshf = "${PACKAGE_EXTRA_ARCHS_tune-armv6hf} arm1136jfshf-vfp" -- 2.24.0 From armccurdy at gmail.com Mon Mar 16 18:48:58 2020 From: armccurdy at gmail.com (Andre McCurdy) Date: Mon, 16 Mar 2020 11:48:58 -0700 Subject: [OE-core] [PATCH 4/5] tune-arm1176jz-s.inc: fix typo in PACKAGE_EXTRA_ARCHS_tune-arm1176jzs In-Reply-To: <20200316184859.11635-1-armccurdy@gmail.com> References: <20200316184859.11635-1-armccurdy@gmail.com> Message-ID: <20200316184859.11635-4-armccurdy@gmail.com> Signed-off-by: Andre McCurdy --- meta/conf/machine/include/tune-arm1176jz-s.inc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/conf/machine/include/tune-arm1176jz-s.inc b/meta/conf/machine/include/tune-arm1176jz-s.inc index c741e80521..a63d585698 100644 --- a/meta/conf/machine/include/tune-arm1176jz-s.inc +++ b/meta/conf/machine/include/tune-arm1176jz-s.inc @@ -9,7 +9,7 @@ MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'arm1176jzs', 'armv6: AVAILTUNES += "arm1176jzs" ARMPKGARCH_tune-arm1176jzs = "arm1176jzs" TUNE_FEATURES_tune-arm1176jzs = "arm thumb arm1176jzs" -PACKAGE_EXTRA_ARCHS_tune-arm1176jzs = "${PACKAGE_EXTRA_ARCHS_tune-armv6tb-novfp} arm1176jzs arm1176jzst" +PACKAGE_EXTRA_ARCHS_tune-arm1176jzs = "${PACKAGE_EXTRA_ARCHS_tune-armv6t-novfp} arm1176jzs arm1176jzst" AVAILTUNES += "arm1176jzs-be" ARMPKGARCH_tune-arm1176jzs-be = "${ARMPKGARCH_tune-arm1176jzs}" -- 2.24.0 From armccurdy at gmail.com Mon Mar 16 18:48:59 2020 From: armccurdy at gmail.com (Andre McCurdy) Date: Mon, 16 Mar 2020 11:48:59 -0700 Subject: [OE-core] [PATCH 5/5] qemuarmv5.conf: drop stray comment including tune-arm1136jf-s.inc In-Reply-To: <20200316184859.11635-1-armccurdy@gmail.com> References: <20200316184859.11635-1-armccurdy@gmail.com> Message-ID: <20200316184859.11635-5-armccurdy@gmail.com> An old comment which appears to have been checked in by accident as part of an unrelated change: https://git.openembedded.org/openembedded-core/commit/?id=e9ebcc4c19a624f76051c0a25d9ecf6ac4afb257 Signed-off-by: Andre McCurdy --- meta/conf/machine/qemuarmv5.conf | 1 - 1 file changed, 1 deletion(-) diff --git a/meta/conf/machine/qemuarmv5.conf b/meta/conf/machine/qemuarmv5.conf index 7f72048065..e7f24fe1ea 100644 --- a/meta/conf/machine/qemuarmv5.conf +++ b/meta/conf/machine/qemuarmv5.conf @@ -4,7 +4,6 @@ require conf/machine/include/qemu.inc require conf/machine/include/tune-arm926ejs.inc -#require conf/machine/include/tune-arm1136jf-s.inc KERNEL_IMAGETYPE = "zImage" -- 2.24.0 From raj.khem at gmail.com Mon Mar 16 19:06:28 2020 From: raj.khem at gmail.com (Khem Raj) Date: Mon, 16 Mar 2020 12:06:28 -0700 Subject: [OE-core] [PATCH] oeqa: Extend parselogs to rpi4 Message-ID: <20200316190628.19383-1-raj.khem@gmail.com> rpi had additional diagnostics which should be ignored [1] [1] https://github.com/raspberrypi/linux/issues/3195 Signed-off-by: Khem Raj --- meta/lib/oeqa/runtime/cases/parselogs.py | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/meta/lib/oeqa/runtime/cases/parselogs.py b/meta/lib/oeqa/runtime/cases/parselogs.py index cc4f5f8c78..48712d4dac 100644 --- a/meta/lib/oeqa/runtime/cases/parselogs.py +++ b/meta/lib/oeqa/runtime/cases/parselogs.py @@ -183,6 +183,11 @@ ignore_errors = { 'Failed to make EGL context current', 'glamor initialization failed', ] + common_errors, + 'raspberrypi4-64' : [ + 'bcmgenet fd580000.genet: failed to get enet-eee clock', + 'bcmgenet fd580000.genet: failed to get enet-wol clock', + 'bcmgenet fd580000.genet: failed to get enet clock', + ] + common_errors, } log_locations = ["/var/log/","/var/log/dmesg", "/tmp/dmesg_output.log"] -- 2.25.1 From akuster808 at gmail.com Mon Mar 16 19:12:31 2020 From: akuster808 at gmail.com (akuster808) Date: Mon, 16 Mar 2020 12:12:31 -0700 Subject: [OE-core] [PATCH] oeqa: Extend parselogs to rpi4 In-Reply-To: <20200316190628.19383-1-raj.khem@gmail.com> References: <20200316190628.19383-1-raj.khem@gmail.com> Message-ID: <62485e60-999e-54c6-09a6-590a8a3e2072@gmail.com> On 3/16/20 12:06 PM, Khem Raj wrote: > rpi had additional diagnostics which should be ignored [1] > > [1] https://github.com/raspberrypi/linux/issues/3195 So does this mean OE will take similar patches for every BSP in the world? - armin > > Signed-off-by: Khem Raj > --- > meta/lib/oeqa/runtime/cases/parselogs.py | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/meta/lib/oeqa/runtime/cases/parselogs.py b/meta/lib/oeqa/runtime/cases/parselogs.py > index cc4f5f8c78..48712d4dac 100644 > --- a/meta/lib/oeqa/runtime/cases/parselogs.py > +++ b/meta/lib/oeqa/runtime/cases/parselogs.py > @@ -183,6 +183,11 @@ ignore_errors = { > 'Failed to make EGL context current', > 'glamor initialization failed', > ] + common_errors, > + 'raspberrypi4-64' : [ > + 'bcmgenet fd580000.genet: failed to get enet-eee clock', > + 'bcmgenet fd580000.genet: failed to get enet-wol clock', > + 'bcmgenet fd580000.genet: failed to get enet clock', > + ] + common_errors, > } > > log_locations = ["/var/log/","/var/log/dmesg", "/tmp/dmesg_output.log"] From raj.khem at gmail.com Mon Mar 16 19:17:45 2020 From: raj.khem at gmail.com (Khem Raj) Date: Mon, 16 Mar 2020 12:17:45 -0700 Subject: [OE-core] [PATCH] oeqa: Extend parselogs to rpi4 In-Reply-To: <62485e60-999e-54c6-09a6-590a8a3e2072@gmail.com> References: <20200316190628.19383-1-raj.khem@gmail.com> <62485e60-999e-54c6-09a6-590a8a3e2072@gmail.com> Message-ID: On Mon, Mar 16, 2020 at 12:12 PM akuster808 wrote: > > > > On 3/16/20 12:06 PM, Khem Raj wrote: > > rpi had additional diagnostics which should be ignored [1] > > > > [1] https://github.com/raspberrypi/linux/issues/3195 > > So does this mean OE will take similar patches for every BSP in the world? > suggest a better way and I will do that in BSP layer. > - armin > > > > Signed-off-by: Khem Raj > > --- > > meta/lib/oeqa/runtime/cases/parselogs.py | 5 +++++ > > 1 file changed, 5 insertions(+) > > > > diff --git a/meta/lib/oeqa/runtime/cases/parselogs.py b/meta/lib/oeqa/runtime/cases/parselogs.py > > index cc4f5f8c78..48712d4dac 100644 > > --- a/meta/lib/oeqa/runtime/cases/parselogs.py > > +++ b/meta/lib/oeqa/runtime/cases/parselogs.py > > @@ -183,6 +183,11 @@ ignore_errors = { > > 'Failed to make EGL context current', > > 'glamor initialization failed', > > ] + common_errors, > > + 'raspberrypi4-64' : [ > > + 'bcmgenet fd580000.genet: failed to get enet-eee clock', > > + 'bcmgenet fd580000.genet: failed to get enet-wol clock', > > + 'bcmgenet fd580000.genet: failed to get enet clock', > > + ] + common_errors, > > } > > > > log_locations = ["/var/log/","/var/log/dmesg", "/tmp/dmesg_output.log"] > From git at andred.net Mon Mar 16 20:36:50 2020 From: git at andred.net (=?ISO-8859-1?Q?Andr=E9?= Draszik) Date: Mon, 16 Mar 2020 20:36:50 +0000 Subject: [OE-core] [PATCH] oeqa: Extend parselogs to rpi4 In-Reply-To: References: <20200316190628.19383-1-raj.khem@gmail.com> <62485e60-999e-54c6-09a6-590a8a3e2072@gmail.com> Message-ID: On Mon, 2020-03-16 at 12:17 -0700, Khem Raj wrote: > On Mon, Mar 16, 2020 at 12:12 PM akuster808 wrote: > > > > > > On 3/16/20 12:06 PM, Khem Raj wrote: > > > rpi had additional diagnostics which should be ignored [1] > > > > > > [1] https://github.com/raspberrypi/linux/issues/3195 > > > > So does this mean OE will take similar patches for every BSP in the world? > > > > suggest a better way and I will do that in BSP layer. Not sure about better way, but in my BSP layer I have: layer.conf: ----------- DEFAULT_TEST_SUITES_remove_mx7d = "parselogs" DEFAULT_TEST_SUITES_append_mx7d = " parselogs_mx7bsp" lib/oeqa/runtime/cases/parselogs_mx7bsp.py: ------------------------------------------- from oeqa.runtime.cases.parselogs import * mx7bsp_errors = [ 'list of messages', ] ignore_errors['mymachine'] = mx7bsp_errors + common_errors class ParseLogsTestMX7BSP(ParseLogsTest): pass A. > > > - armin > > > Signed-off-by: Khem Raj > > > --- > > > meta/lib/oeqa/runtime/cases/parselogs.py | 5 +++++ > > > 1 file changed, 5 insertions(+) > > > > > > diff --git a/meta/lib/oeqa/runtime/cases/parselogs.py b/meta/lib/oeqa/runtime/cases/parselogs.py > > > index cc4f5f8c78..48712d4dac 100644 > > > --- a/meta/lib/oeqa/runtime/cases/parselogs.py > > > +++ b/meta/lib/oeqa/runtime/cases/parselogs.py > > > @@ -183,6 +183,11 @@ ignore_errors = { > > > 'Failed to make EGL context current', > > > 'glamor initialization failed', > > > ] + common_errors, > > > + 'raspberrypi4-64' : [ > > > + 'bcmgenet fd580000.genet: failed to get enet-eee clock', > > > + 'bcmgenet fd580000.genet: failed to get enet-wol clock', > > > + 'bcmgenet fd580000.genet: failed to get enet clock', > > > + ] + common_errors, > > > } > > > > > > log_locations = ["/var/log/","/var/log/dmesg", "/tmp/dmesg_output.log"] From raj.khem at gmail.com Mon Mar 16 20:50:17 2020 From: raj.khem at gmail.com (Khem Raj) Date: Mon, 16 Mar 2020 13:50:17 -0700 Subject: [OE-core] [PATCH] oeqa: Extend parselogs to rpi4 In-Reply-To: References: <20200316190628.19383-1-raj.khem@gmail.com> <62485e60-999e-54c6-09a6-590a8a3e2072@gmail.com> Message-ID: On Mon, Mar 16, 2020 at 1:37 PM Andr? Draszik wrote: > > On Mon, 2020-03-16 at 12:17 -0700, Khem Raj wrote: > > On Mon, Mar 16, 2020 at 12:12 PM akuster808 wrote: > > > > > > > > > On 3/16/20 12:06 PM, Khem Raj wrote: > > > > rpi had additional diagnostics which should be ignored [1] > > > > > > > > [1] https://github.com/raspberrypi/linux/issues/3195 > > > > > > So does this mean OE will take similar patches for every BSP in the world? > > > > > > > suggest a better way and I will do that in BSP layer. > > Not sure about better way, but in my BSP layer I have: > thanks it certainly is better than what I have, I will adapt to it > layer.conf: > ----------- > DEFAULT_TEST_SUITES_remove_mx7d = "parselogs" > DEFAULT_TEST_SUITES_append_mx7d = " parselogs_mx7bsp" > > lib/oeqa/runtime/cases/parselogs_mx7bsp.py: > ------------------------------------------- > from oeqa.runtime.cases.parselogs import * > > mx7bsp_errors = [ > 'list of messages', > ] > > ignore_errors['mymachine'] = mx7bsp_errors + common_errors > > class ParseLogsTestMX7BSP(ParseLogsTest): > pass > > > A. > > > > > > - armin > > > > Signed-off-by: Khem Raj > > > > --- > > > > meta/lib/oeqa/runtime/cases/parselogs.py | 5 +++++ > > > > 1 file changed, 5 insertions(+) > > > > > > > > diff --git a/meta/lib/oeqa/runtime/cases/parselogs.py b/meta/lib/oeqa/runtime/cases/parselogs.py > > > > index cc4f5f8c78..48712d4dac 100644 > > > > --- a/meta/lib/oeqa/runtime/cases/parselogs.py > > > > +++ b/meta/lib/oeqa/runtime/cases/parselogs.py > > > > @@ -183,6 +183,11 @@ ignore_errors = { > > > > 'Failed to make EGL context current', > > > > 'glamor initialization failed', > > > > ] + common_errors, > > > > + 'raspberrypi4-64' : [ > > > > + 'bcmgenet fd580000.genet: failed to get enet-eee clock', > > > > + 'bcmgenet fd580000.genet: failed to get enet-wol clock', > > > > + 'bcmgenet fd580000.genet: failed to get enet clock', > > > > + ] + common_errors, > > > > } > > > > > > > > log_locations = ["/var/log/","/var/log/dmesg", "/tmp/dmesg_output.log"] > > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core at lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core From richard.purdie at linuxfoundation.org Mon Mar 16 22:20:08 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Mon, 16 Mar 2020 22:20:08 +0000 Subject: [OE-core] [PATCH] oeqa: Extend parselogs to rpi4 In-Reply-To: References: <20200316190628.19383-1-raj.khem@gmail.com> <62485e60-999e-54c6-09a6-590a8a3e2072@gmail.com> Message-ID: <8eefd1f82f080fd17e2880fd979c87cf3b37090e.camel@linuxfoundation.org> On Mon, 2020-03-16 at 13:50 -0700, Khem Raj wrote: > On Mon, Mar 16, 2020 at 1:37 PM Andr? Draszik wrote: > > On Mon, 2020-03-16 at 12:17 -0700, Khem Raj wrote: > > > On Mon, Mar 16, 2020 at 12:12 PM akuster808 > > > wrote: > > > > > > > > On 3/16/20 12:06 PM, Khem Raj wrote: > > > > > rpi had additional diagnostics which should be ignored [1] > > > > > > > > > > [1] https://github.com/raspberrypi/linux/issues/3195 > > > > > > > > So does this mean OE will take similar patches for every BSP in > > > > the world? > > > > > > > > > > suggest a better way and I will do that in BSP layer. > > > > Not sure about better way, but in my BSP layer I have: > > > > thanks it certainly is better than what I have, I will adapt to it > > > layer.conf: > > ----------- > > DEFAULT_TEST_SUITES_remove_mx7d = "parselogs" > > DEFAULT_TEST_SUITES_append_mx7d = " parselogs_mx7bsp" > > > > lib/oeqa/runtime/cases/parselogs_mx7bsp.py: > > ------------------------------------------- > > from oeqa.runtime.cases.parselogs import * > > > > mx7bsp_errors = [ > > 'list of messages', > > ] > > > > ignore_errors['mymachine'] = mx7bsp_errors + common_errors > > > > class ParseLogsTestMX7BSP(ParseLogsTest): > > pass Its definitely better. I'd also take patches to further improve things to allow easier customisation by BSPs. I did think there was some mechanism but I'm struggling to remember what was intended. Cheers, Richard From raj.khem at gmail.com Mon Mar 16 22:20:56 2020 From: raj.khem at gmail.com (Khem Raj) Date: Mon, 16 Mar 2020 15:20:56 -0700 Subject: [OE-core] [PATCH] gcc-target: Use --with-arch=native for target gcc Message-ID: <20200316222056.2674295-1-raj.khem@gmail.com> This should help gcc detect and use target ISA on x86_64 machines when -march is not used on cmdline [YOCTO #139] Signed-off-by: Khem Raj Cc: Ross Burton --- meta/recipes-devtools/gcc/gcc-target.inc | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/recipes-devtools/gcc/gcc-target.inc b/meta/recipes-devtools/gcc/gcc-target.inc index 7cf819272f..aa274bb936 100644 --- a/meta/recipes-devtools/gcc/gcc-target.inc +++ b/meta/recipes-devtools/gcc/gcc-target.inc @@ -19,6 +19,7 @@ EXTRA_OECONF_append_armv6 = " --with-arch=armv6${ARMFPARCHEXT}" EXTRA_OECONF_append_armv7a = " --with-arch=armv7-a${ARMFPARCHEXT}" EXTRA_OECONF_append_armv7ve = " --with-arch=armv7ve${ARMFPARCHEXT}" EXTRA_OECONF_append_arc = " --with-cpu=${TUNE_PKGARCH}" +EXTRA_OECONF_append_x86-64 = " --with-arch=native" # libcc1 requres gcc_cv_objdump when cross build, but gcc_cv_objdump is # set in subdir gcc, so subdir libcc1 can't use it, export it here to -- 2.25.1 From wangmy at cn.fujitsu.com Tue Mar 17 07:16:48 2020 From: wangmy at cn.fujitsu.com (Wang Mingyu) Date: Tue, 17 Mar 2020 00:16:48 -0700 Subject: [OE-core] [PATCH v2] base-passwd: LICENSE changed to GPLv2 Message-ID: <1584429410-1890-1-git-send-email-wangmy@cn.fujitsu.com> The source code such as update-passwd.c states the license to be under GPL v2 only and does not contain the "or later" clause so correct the recipe LICENSE field to match. Signed-off-by: Wang Mingyu --- meta/recipes-core/base-passwd/base-passwd_3.5.29.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb b/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb index d1aab09181..d01cd7e297 100644 --- a/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb +++ b/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb @@ -1,7 +1,7 @@ SUMMARY = "Base system master password/group files" DESCRIPTION = "The master copies of the user database files (/etc/passwd and /etc/group). The update-passwd tool is also provided to keep the system databases synchronized with these master files." SECTION = "base" -LICENSE = "GPLv2+" +LICENSE = "GPLv2" LIC_FILES_CHKSUM = "file://COPYING;md5=eb723b61539feef013de476e68b5c50a" RECIPE_NO_UPDATE_REASON = "Version 3.5.38 requires cdebconf for update-passwd utility" -- 2.17.1 From wangmy at cn.fujitsu.com Tue Mar 17 07:16:49 2020 From: wangmy at cn.fujitsu.com (Wang Mingyu) Date: Tue, 17 Mar 2020 00:16:49 -0700 Subject: [OE-core] [PATCH] gtk+3: upgrade 3.24.13 -> 3.24.14 In-Reply-To: <1584429410-1890-1-git-send-email-wangmy@cn.fujitsu.com> References: <1584429410-1890-1-git-send-email-wangmy@cn.fujitsu.com> Message-ID: <1584429410-1890-2-git-send-email-wangmy@cn.fujitsu.com> Signed-off-by: Wang Mingyu --- .../recipes-gnome/gtk+/{gtk+3_3.24.13.bb => gtk+3_3.24.14.bb} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename meta/recipes-gnome/gtk+/{gtk+3_3.24.13.bb => gtk+3_3.24.14.bb} (85%) diff --git a/meta/recipes-gnome/gtk+/gtk+3_3.24.13.bb b/meta/recipes-gnome/gtk+/gtk+3_3.24.14.bb similarity index 85% rename from meta/recipes-gnome/gtk+/gtk+3_3.24.13.bb rename to meta/recipes-gnome/gtk+/gtk+3_3.24.14.bb index 025d8870e2..ab1f87c22e 100644 --- a/meta/recipes-gnome/gtk+/gtk+3_3.24.13.bb +++ b/meta/recipes-gnome/gtk+/gtk+3_3.24.14.bb @@ -9,8 +9,8 @@ SRC_URI = "http://ftp.gnome.org/pub/gnome/sources/gtk+/${MAJ_VER}/gtk+-${PV}.tar file://link_fribidi.patch \ file://sort-resources.patch \ " -SRC_URI[md5sum] = "f65515e7bfa2199bd2188e871d69c686" -SRC_URI[sha256sum] = "4c775c38cf1e3c534ef0ca52ca6c7a890fe169981af66141c713e054e68930a9" +SRC_URI[md5sum] = "62e39212fa0a84016a3392a9d291faf8" +SRC_URI[sha256sum] = "1c4d69f93ab884fd80c6b95115bfbc12d51ecd029178b6dad3672fdc5ff91e88" S = "${WORKDIR}/gtk+-${PV}" -- 2.17.1 From wangmy at cn.fujitsu.com Tue Mar 17 07:16:50 2020 From: wangmy at cn.fujitsu.com (Wang Mingyu) Date: Tue, 17 Mar 2020 00:16:50 -0700 Subject: [OE-core] [PATCH] stress-ng: upgrade 0.11.01 -> 0.11.02 In-Reply-To: <1584429410-1890-1-git-send-email-wangmy@cn.fujitsu.com> References: <1584429410-1890-1-git-send-email-wangmy@cn.fujitsu.com> Message-ID: <1584429410-1890-3-git-send-email-wangmy@cn.fujitsu.com> Signed-off-by: Wang Mingyu --- .../stress-ng/{stress-ng_0.11.01.bb => stress-ng_0.11.02.bb} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename meta/recipes-extended/stress-ng/{stress-ng_0.11.01.bb => stress-ng_0.11.02.bb} (83%) diff --git a/meta/recipes-extended/stress-ng/stress-ng_0.11.01.bb b/meta/recipes-extended/stress-ng/stress-ng_0.11.02.bb similarity index 83% rename from meta/recipes-extended/stress-ng/stress-ng_0.11.01.bb rename to meta/recipes-extended/stress-ng/stress-ng_0.11.02.bb index 3486be1b03..e79ee49e24 100644 --- a/meta/recipes-extended/stress-ng/stress-ng_0.11.01.bb +++ b/meta/recipes-extended/stress-ng/stress-ng_0.11.02.bb @@ -8,8 +8,8 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263" SRC_URI = "https://kernel.ubuntu.com/~cking/tarballs/${BPN}/${BP}.tar.xz \ file://0001-Do-not-preserve-ownership-when-installing-example-jo.patch \ " -SRC_URI[md5sum] = "a558fc7fb9d0a851afe6de09080b5401" -SRC_URI[sha256sum] = "9fe19548c87aa1a1b9b2be3b359ec2621b88bcb16998b77527549a7736f65494" +SRC_URI[md5sum] = "a353287968818f7181eae9a90ddc4f25" +SRC_URI[sha256sum] = "ad1a6fca8f90f67a4364aa6ff0c406995960dc4f8689e9d5289fc083e1d8986f" DEPENDS = "coreutils-native" -- 2.17.1 From bluelightning at bluelightning.org Tue Mar 17 02:38:56 2020 From: bluelightning at bluelightning.org (Paul Eggleton) Date: Tue, 17 Mar 2020 15:38:56 +1300 Subject: [OE-core] OpenEmbedded TSC Meeting Minutes 2020-03-17 Message-ID: <22665987.Wx5bFTl31r@linc> OpenEmbedded Technical Steering Committee (TSC) Meeting Minutes 2020-03-17 ========================================================================== Meeting was held in #oe-tsc on Freenode; channel access public. Present: - Richard Purdie (RP) - Joshua Watt (JPEW) - Bruce Ashfield (zeddii) - Paul Eggleton (bluelightning) Apologies: - Martin Jansa (JaMa) Summary: * Need to think about ways to encourage contributions - Make contributions more visible? (see also last meeting's discussion) - Include contributor names in release notes - Response emails to patches / when patch merged? - Ideas / discussion around any barriers to contributing and removing them very welcome Full meeting long ----------------- [11:01] I presume we are meeting now? [11:02] That's the plan [11:03] JaMa doesn't appear to be online, and RP is currently away [11:03] I forgot to send out a reminder today [11:04] I have just pinged RP - I could also text him [11:10] Hi, I'm here now, sorry I'm late [11:10] no worries [11:10] do we have zeddii? [11:11] Not sure. He was on earlier today [11:15] Is there an agenda? [11:15] I must admit I got M3 built and kind of went and "collapsed" ;-) [11:16] I'm not aware of anything [11:16] I did have one item the YP TSC asked me to raise [11:16] Sorry for not officially adding it to the wiki etc [11:16] here. sorry, I was supposed to be on vacation this week, so I removed the meeting from my calendar. [11:17] Basically, it was to ask the OC TSC to consider the resourcing situation we have and to consider what we could do about it. [11:17] zeddii: No problem, we just started [11:17] There are various bodies that are thinking about it (YP TSC, YP board, OE board) but the OE TSC probably also needs to give it some thought [11:19] RP: Ya, make sense. [11:20] Are there any identified reasons why people don't contribute? [11:22] JPEW: In general the pattern seems to be employers expecting someone else to do the core work [11:22] Some things don't have clear return on investment too [11:22] agreed. and agreed. [11:22] which things? [11:23] anything that is mostly refactoring I would imagine [11:23] JPEW: build failure triage (SWAT), bug triage [11:23] things where its day to day monitoring without direct line of sight to a problem they themselves see [11:23] and even things like why a reference kernel, when they don?t use it directly. [11:23] zeddii: right [11:24] also, new feature development like hashequiv [11:24] or as bluelightning says, refactoring or new architectural work [11:25] yup. [11:28] I assume that I either got disconnected, or we are all deep in thought. [11:28] zeddii: The latter :) [11:29] I've spent a lot of time thinking about it and I'm not sure what we can do [11:29] the problem is that only OSVs really care about ?credibility? in the community. if you know what I mean. [11:29] Aside from employeer expectations, any other reasons why people don't participate? [11:29] We have made some changes like newcomer bugs. I also need to send out some kind of summary of the challenges to the wider community. I'm still working on that [11:30] JPEW: there is probably a knowledge barrier too [11:30] I could volunteer some of my time to help someone that actually picked up a new comer bug, but I think that?s probably just a drop in the ocean. [11:30] JPEW: even some of our regular contributors think of bitbake as a blackbox, you're one of the few who doesn't [11:30] zeddii: Not necessarily if you can help someone get interested, it pays dividends :) [11:31] zeddii: lots of small things do grow over time, I am trying to encourage people. Not all will work out but its great to see when people do grow [11:32] that?s what I was wondering, are none of them being picked up, since newcomers don?t know where to start. maybe pairing them up with someone to office advice can help. but maybe that has already been tried (and yes, I know that pulls more time from people that don?t have it, etc). [11:32] I?m throwing my hat into the ring for that. but that implies someone is looking for that kind of help. [11:32] zeddii: That's a good idea. I'd be willing to advise someone fixing a bug also (newcomer or otherwise) [11:32] zeddii: we're seeing poor take up despite what I thought was a good spectrum of bugs there [11:33] Perhaps more of a visibility problem? [11:33] I would note that the we lack YP advocacy people atm too :( [11:33] visibility is definitely part of it [11:34] It's hard being on the inside looking out and trying to figure out how visible you are sometimes [11:34] the newcomer doc on the YP wiki is pretty good I think, but that assumes people find that [11:35] I did just get to it by googling "yocto project contribute" [11:36] Hmm, is it pretty easy to identify new contributers on the ML? [11:37] JPEW: for a person or for a machine? [11:38] person (email address) [11:38] I?m thinking more of companies that use OE, not end users. since getting contributions from each category is quite a different thing. [11:40] zeddii: Sure, but having people in the company that are involved anyway helps [11:40] sometimes :eyeroll: [11:40] JPEW: I mean its easy for a computer to look at an email and see if they've had a patch merged before [11:42] RP: Right. Would it be bad form to send them a message "welcome to the community" message? I've not been doing OSS very long, so I don't know all the edicate [11:42] Thanks for your patch! Here's some other ways you can get involved... [11:42] JPEW: if they were new to OE but an experienced OSS contributor it may seem patronising :/ [11:42] I think it might be nice - you could include "if you don't get a reply in x days here's what to do" [11:43] I wouldn't find it patronising if I was joining a new project, others may differ possibly [11:43] I know I've struggled when joining other projects, people sort of expect you to know what to do / where to look and that's not always easy even if you're experienced with OSS, every project is different [11:44] yah. is it a get started issue, credit issue, or lack of mapping to ROI issue .. hard to say, since we don?t even have that info :( [11:45] zeddii: Hard to operate effectively without data [11:45] I don't have an objection to it [11:45] When do the other TSC's meet [11:46] By the time they sent a contribution they're already part way there though, we may need to find new contributors as well [11:46] JPEW: you mean the YP TSC? [11:46] Ya [11:47] zeddii: the "data" I have says all the above [11:47] I jokingly say that with all of the users of OE, and a fairly narrow set of contributors, I assume that means that they have no issues. which I can?t imagine is the case. [11:47] JPEW: YP TSC meets after the engineering sync tomorrow [11:47] zeddii: most of my data is reading the mailing lists and social media posts from users, new and experienced [11:49] OK. Maybe we can draft up a skeleton e-mail and all look it over (maybe the YP TSC too) [11:49] non-corporate contributions are hard to capture, since they are likely elsewhere for many high level applications. [11:50] JPEW: another thing may be a "your patch has merged" email from patchwork [11:50] RP: Ya that would be good too [11:50] I mean, it would be nice if we went to openembedded.org and saw some logo?s, but I suppose that collides with YP very quickly. and you get a logo if you have a patch in the release ;) [11:51] I also have no objection to that but it needs someone else to own and drive it [11:51] that @gmail.com company could get a big logo! [11:51] patch merged reports was something that was supposed to be added to patchwork a long time ago, unfortunately due to various reasons it never got done :/ [11:51] bluelightning: one idea that did get talked about but probably ironically, not with you was a list of contributors to the release [11:52] hmm, yes, I think maybe it did get mentioned somewhere [11:52] I thought it was a good idea, since then large and small could see their name in ?print? along with a release. [11:52] (ironically as bluelightning ends up writing the release notes) [11:52] but again, time. I can help with that when the time comes. [11:53] at least as far as commits go there are various git stats analysis tools that might be helpful (and don't involve us writing additional code) [11:53] zeddii: the time for that one is now, release is in weeks! [11:53] although yes it would be good to have the info actually in the notes... that should be pretty easy for me to do [11:53] I mean, I get an email from the kernel once and a while trying to figure out who I work for, since @gmail.com ?. so there?s some mappings that can be done on that front as well. [11:54] bluelightning: you can integrate if someone helps too! :) [11:54] bluelightning: if there?s something you think I can do for that, I can help. [11:54] zeddii: thanks - I'll keep that in mind [11:55] I?ll go look at the other release notes to see if I can think of anything else that might be interesting to add. [11:55] i.e. if a release mentioned some steps forward in a vertical that interested some companies, they might be interested to help more in the future, etc. hard to say if its even possible to do that, but its an idea. [11:58] There might be more we could do at conferences and such also... although thats not useful in the short term [11:59] some kind of metrics/lists focused on "first contributions from" might be interesting [12:03] Any other topics? [12:03] Not from me [12:03] I'll put this one on the list for next month so we can see if there are any more ideas in the meantime [12:04] And I'll try to draft some example e-mails [12:04] If people do have ideas, please do feel free to share. I think the project has some challenges ahead (as does the world at large atm :( ) [12:06] OK, supper time for me. [12:06] Bye all [12:07] I'll send out the minutes [12:08] Thanks. Don't forget to link on the wiki: https://www.openembedded.org/wiki/TSC [12:08] ah yes thanks for the reminder, I think I missed that the last couple of times [12:09] Thanks all! From Qi.Chen at windriver.com Tue Mar 17 03:28:43 2020 From: Qi.Chen at windriver.com (Chen Qi) Date: Mon, 16 Mar 2020 20:28:43 -0700 Subject: [OE-core] [PATCH] glib-2.0: fix install error for multilib Message-ID: <20200317032843.118712-1-Qi.Chen@windriver.com> A previous patch adds this `mv' command, but patch file, static-link.test might not even be there. So add a check to avoid do_install error in case of multilib. Signed-off-by: Chen Qi --- meta/recipes-core/glib-2.0/glib.inc | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/meta/recipes-core/glib-2.0/glib.inc b/meta/recipes-core/glib-2.0/glib.inc index edecc51fdb..4f99b86569 100644 --- a/meta/recipes-core/glib-2.0/glib.inc +++ b/meta/recipes-core/glib-2.0/glib.inc @@ -129,7 +129,9 @@ do_install_append_class-target () { fi fi if test "x${MLPREFIX}" != "x"; then - mv ${D}${datadir}/installed-tests/glib/static-link.test ${D}${datadir}/installed-tests/glib/${MLPREFIX}static-link.test + if [ -e ${D}${datadir}/installed-tests/glib/static-link.test ]; then + mv ${D}${datadir}/installed-tests/glib/static-link.test ${D}${datadir}/installed-tests/glib/${MLPREFIX}static-link.test + fi fi } -- 2.21.0 From Qi.Chen at windriver.com Tue Mar 17 03:30:41 2020 From: Qi.Chen at windriver.com (Chen, Qi) Date: Tue, 17 Mar 2020 03:30:41 +0000 Subject: [OE-core] =?gb2312?b?u9i4tDogIFtQQVRDSCAyLzJdIGdsaWItMi4wOiBDb3Jy?= =?gb2312?b?ZWN0IG11bHRpbGliIGNvbmZsaWN0?= In-Reply-To: <20200311222249.29880-2-jpuhlman@mvista.com> References: <20200311222249.29880-1-jpuhlman@mvista.com>, <20200311222249.29880-2-jpuhlman@mvista.com> Message-ID: This patch is causing regression in case of qemuarm64 multilib for me. The static-link.test file is not there, resulting the `mv' command failure. I've sent out a patch to fix this problem, but I don't know what's your environment. So please help review. Regards, Chen Qi ________________________________ ???: openembedded-core-bounces at lists.openembedded.org ?? Jeremy A. Puhlman ????: 2020?3?12? 6:22 ???: openembedded-core at lists.openembedded.org ??: [OE-core] [PATCH 2/2] glib-2.0: Correct multilib conflict From: Jeremy Puhlman Signed-off-by: Jeremy A. Puhlman --- meta/recipes-core/glib-2.0/glib.inc | 3 +++ 1 file changed, 3 insertions(+) diff --git a/meta/recipes-core/glib-2.0/glib.inc b/meta/recipes-core/glib-2.0/glib.inc index 23c347dbf7..edecc51fdb 100644 --- a/meta/recipes-core/glib-2.0/glib.inc +++ b/meta/recipes-core/glib-2.0/glib.inc @@ -128,6 +128,9 @@ do_install_append_class-target () { rm ${D}${datadir}/installed-tests/glib/gdbus-serialization.test fi fi + if test "x${MLPREFIX}" != "x"; then + mv ${D}${datadir}/installed-tests/glib/static-link.test ${D}${datadir}/installed-tests/glib/${MLPREFIX}static-link.test + fi } # As we do not build python3 for windows, makes no sense to ship the script that's using it -- 2.13.3 -- _______________________________________________ Openembedded-core mailing list Openembedded-core at lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpuhlman at mvista.com Tue Mar 17 04:02:48 2020 From: jpuhlman at mvista.com (Jeremy A. Puhlman) Date: Mon, 16 Mar 2020 21:02:48 -0700 Subject: [OE-core] =?utf-8?b?5Zue5aSNOiAgW1BBVENIIDIvMl0gZ2xpYi0yLjA6IENv?= =?utf-8?q?rrect_multilib_conflict?= In-Reply-To: References: <20200311222249.29880-1-jpuhlman@mvista.com> <20200311222249.29880-2-jpuhlman@mvista.com> Message-ID: Just standard x86/i585. What are you using for your mulitlib. ilp32/aarch32/arm7? require conf/multilib.conf MULTILIBS = "multilib:lib32" X86ARCH32 = "i586" DEFAULTTUNE_virtclass-multilib-lib32 = "i586" TARGET_ARCH_virtclass-multilib-lib32 = "i586" TARGET_LD_ARCH_virtclass-multilib-lib32 = "-m elf_i386" ALTBINDIR_SUFFIX_virtclass-multilib-lib32 = "32" What does your -e look like for the recipe that fails? On 3/16/2020 8:30 PM, Chen, Qi wrote: > This patch is causing regression in case of qemuarm64 multilib for me. > The static-link.test file is not there, resulting the `mv' command > failure. I've sent out a patch to fix this problem, but I don't know > what's your environment. So please help review. > > Regards, > Chen Qi > ------------------------------------------------------------------------ > *???:* openembedded-core-bounces at lists.openembedded.org > ?? Jeremy A. > Puhlman > *????:* 2020?3?12? 6:22 > *???:* openembedded-core at lists.openembedded.org > > *??:* [OE-core] [PATCH 2/2] glib-2.0: Correct multilib conflict > From: Jeremy Puhlman > > Signed-off-by: Jeremy A. Puhlman > --- > ?meta/recipes-core/glib-2.0/glib.inc | 3 +++ > ?1 file changed, 3 insertions(+) > > diff --git a/meta/recipes-core/glib-2.0/glib.inc > b/meta/recipes-core/glib-2.0/glib.inc > index 23c347dbf7..edecc51fdb 100644 > --- a/meta/recipes-core/glib-2.0/glib.inc > +++ b/meta/recipes-core/glib-2.0/glib.inc > @@ -128,6 +128,9 @@ do_install_append_class-target () { > ???????????????????????? rm > ${D}${datadir}/installed-tests/glib/gdbus-serialization.test > ???????????????? fi > ???????? fi > +??????? if test "x${MLPREFIX}" != "x"; then > +??????????????? mv > ${D}${datadir}/installed-tests/glib/static-link.test > ${D}${datadir}/installed-tests/glib/${MLPREFIX}static-link.test > +??????? fi > ?} > > ?# As we do not build python3 for windows, makes no sense to ship the > script that's using it > -- > 2.13.3 > > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core at lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core > > > Virus-free. www.avg.com > > > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> -- Jeremy A. Puhlman jpuhlman at mvista.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Qi.Chen at windriver.com Tue Mar 17 04:31:20 2020 From: Qi.Chen at windriver.com (Chen, Qi) Date: Tue, 17 Mar 2020 04:31:20 +0000 Subject: [OE-core] =?gb2312?b?u9i4tDogu9i4tDogIFtQQVRDSCAyLzJdIGdsaWItMi4w?= =?gb2312?b?OiBDb3JyZWN0IG11bHRpbGliIGNvbmZsaWN0?= In-Reply-To: References: <20200311222249.29880-1-jpuhlman@mvista.com> <20200311222249.29880-2-jpuhlman@mvista.com> , Message-ID: MULTILIBS ?= "multilib:lib32" DEFAULTTUNE_virtclass-multilib-lib32 ?= "armv7vethf" I think you can use these two lines to reproduce the problem with multilib enabled. Regards, Chen Qi ________________________________ ???: Jeremy A. Puhlman ????: 2020?3?17? 12:02 ???: Chen, Qi ; openembedded-core at lists.openembedded.org ??: Re: ??: [OE-core] [PATCH 2/2] glib-2.0: Correct multilib conflict Just standard x86/i585. What are you using for your mulitlib. ilp32/aarch32/arm7? require conf/multilib.conf MULTILIBS = "multilib:lib32" X86ARCH32 = "i586" DEFAULTTUNE_virtclass-multilib-lib32 = "i586" TARGET_ARCH_virtclass-multilib-lib32 = "i586" TARGET_LD_ARCH_virtclass-multilib-lib32 = "-m elf_i386" ALTBINDIR_SUFFIX_virtclass-multilib-lib32 = "32" What does your -e look like for the recipe that fails? On 3/16/2020 8:30 PM, Chen, Qi wrote: This patch is causing regression in case of qemuarm64 multilib for me. The static-link.test file is not there, resulting the `mv' command failure. I've sent out a patch to fix this problem, but I don't know what's your environment. So please help review. Regards, Chen Qi ________________________________ ???: openembedded-core-bounces at lists.openembedded.org ?? Jeremy A. Puhlman ????: 2020?3?12? 6:22 ???: openembedded-core at lists.openembedded.org ??: [OE-core] [PATCH 2/2] glib-2.0: Correct multilib conflict From: Jeremy Puhlman Signed-off-by: Jeremy A. Puhlman --- meta/recipes-core/glib-2.0/glib.inc | 3 +++ 1 file changed, 3 insertions(+) diff --git a/meta/recipes-core/glib-2.0/glib.inc b/meta/recipes-core/glib-2.0/glib.inc index 23c347dbf7..edecc51fdb 100644 --- a/meta/recipes-core/glib-2.0/glib.inc +++ b/meta/recipes-core/glib-2.0/glib.inc @@ -128,6 +128,9 @@ do_install_append_class-target () { rm ${D}${datadir}/installed-tests/glib/gdbus-serialization.test fi fi + if test "x${MLPREFIX}" != "x"; then + mv ${D}${datadir}/installed-tests/glib/static-link.test ${D}${datadir}/installed-tests/glib/${MLPREFIX}static-link.test + fi } # As we do not build python3 for windows, makes no sense to ship the script that's using it -- 2.13.3 -- _______________________________________________ Openembedded-core mailing list Openembedded-core at lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core [https://ipmcdn.avast.com/images/icons/icon-envelope-tick-green-avg-v1.png] Virus-free. www.avg.com -- Jeremy A. Puhlman jpuhlman at mvista.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruce.ashfield at gmail.com Tue Mar 17 04:39:16 2020 From: bruce.ashfield at gmail.com (bruce.ashfield at gmail.com) Date: Tue, 17 Mar 2020 00:39:16 -0400 Subject: [OE-core] [PATCH][zeus] linux-yocto/4.19: update to v4.19.107 Message-ID: <20200317043916.47514-1-bruce.ashfield@gmail.com> From: Bruce Ashfield Updating linux-yocto/4.19 to the latest korg -stable release that comprises the following commits: 16ae5406361a crypto: CVE-2019-18808 a083db76118d Linux 4.19.107 cfc30449bbc5 Revert "char/random: silence a lockdep splat with printk()" 8541452acba5 s390/mm: Explicitly compare PAGE_DEFAULT_KEY against zero in storage_key_init_range fee87e931cc5 xen: Enable interrupts when calling _cond_resched() 28a73a946a46 ata: ahci: Add shutdown to freeze hardware resources of ahci 43cac315bec1 rxrpc: Fix call RCU cleanup using non-bh-safe locks acbc5071f073 netfilter: xt_hashlimit: limit the max size of hashtable 5a2972600a2f ALSA: seq: Fix concurrent access to queue current tick/time b105447809b1 ALSA: seq: Avoid concurrent access to queue flags 63495d1e1c7c ALSA: rawmidi: Avoid bit fields for state flags bf3043d27755 bpf, offload: Replace bitwise AND by logical AND in bpf_prog_offload_info_fill 3132696dd748 genirq/proc: Reject invalid affinity masks (again) ba2c07dfa0d8 iommu/vt-d: Fix compile warning from intel-svm.h c0965be4b28b ecryptfs: replace BUG_ON with error handling code 1bae8f424c84 staging: greybus: use after free in gb_audio_manager_remove_all() 568991c91849 staging: rtl8723bs: fix copy of overlapping memory f8e6a3412dc6 usb: dwc2: Fix in ISOC request length checking de8dbb7b02fa usb: gadget: composite: Fix bMaxPower for SuperSpeedPlus 1cad1a6497ec scsi: Revert "target: iscsi: Wait for all commands to finish before freeing a session" c66b2b571211 scsi: Revert "RDMA/isert: Fix a recently introduced regression related to logout" b046c6fec04e Revert "dmaengine: imx-sdma: Fix memory leak" cd26d53a27d6 Btrfs: fix btrfs_wait_ordered_range() so that it waits for all ordered extents 4d886f91ca13 btrfs: do not check delayed items are empty for single transaction cleanup 68b7db197bf8 btrfs: reset fs_root to NULL on error in open_ctree 0ba8e5f347b2 btrfs: fix bytes_may_use underflow in prealloc error condtition e541982a6e5f KVM: apic: avoid calculating pending eoi from an uninitialized val 267eec2d216d KVM: nVMX: handle nested posted interrupts when apicv is disabled for L1 85dd0eb771e8 KVM: nVMX: Check IO instruction VM-exit conditions e5c0857bd5cc KVM: nVMX: Refactor IO bitmap checks into helper function 8cf20fb73e73 ext4: fix race between writepages and enabling EXT4_EXTENTS_FL 48fdbe2a818d ext4: rename s_journal_flag_rwsem to s_writepages_rwsem b7dc081c24db ext4: fix mount failure with quota configured as module 50017cec3dbb ext4: fix potential race between s_flex_groups online resizing and access 7720966a68c8 ext4: fix potential race between s_group_info online resizing and access cc9948abe47b ext4: fix potential race between online resizing and write operations 38884609b8b5 ext4: add cond_resched() to __ext4_find_entry() 9b6e90918bc0 ext4: fix a data race in EXT4_I(inode)->i_disksize 0e3a6e86d43b drm/nouveau/kms/gv100-: Re-set LUT after clearing for modesets da3418ad747f lib/stackdepot.c: fix global out-of-bounds in stack_slabs 56ad5b4b7405 tty: serial: qcom_geni_serial: Fix RX cancel command failure e6ebad85883d tty: serial: qcom_geni_serial: Remove xfer_mode variable 4e438733f727 tty: serial: qcom_geni_serial: Remove set_rfr_wm() and related variables 1cc8834773b2 tty: serial: qcom_geni_serial: Remove use of *_relaxed() and mb() 4d1a94fa6d14 tty: serial: qcom_geni_serial: Remove interrupt storm 0a38fd9326fd tty: serial: qcom_geni_serial: Fix UART hang fe1cfc645845 KVM: x86: don't notify userspace IOAPIC on edge-triggered interrupt EOI ed9e97c35b45 KVM: nVMX: Don't emulate instructions in guest mode 6ca274be314b xhci: apply XHCI_PME_STUCK_QUIRK to Intel Comet Lake platforms 8300ed5a2175 drm/amdgpu/soc15: fix xclk for raven 837ba4829b9f mm/vmscan.c: don't round up scan size for online memory cgroup ea2a11561d01 genirq/irqdomain: Make sure all irq domain flags are distinct 576c04cbbef2 nvme-multipath: Fix memory leak with ana_log_buf e75d2de90b86 mm/memcontrol.c: lost css_put in memcg_expand_shrinker_maps() cf85f00f87db Revert "ipc,sem: remove uneeded sem_undo_list lock usage in exit_sem()" af4693daff1b MAINTAINERS: Update drm/i915 bug filing URL c9ca2010202b serdev: ttyport: restore client ops on deregistration 463a3db812d9 tty: serial: imx: setup the correct sg entry for tx dma 6807593e8edc tty/serial: atmel: manage shutdown in case of RS485 or ISO7816 mode f4e6d51f3f40 serial: 8250: Check UPF_IRQ_SHARED in advance f28ec250579c x86/cpu/amd: Enable the fixed Instructions Retired counter IRPERF 5e5b443ae6cc x86/mce/amd: Fix kobject lifetime 0a3aca3a0f41 x86/mce/amd: Publish the bank pointer only after setup has succeeded 4512119ac90a jbd2: fix ocfs2 corrupt when clearing block group bits 72e2df70fb52 powerpc/tm: Fix clearing MSR[TS] in current when reclaiming on signal delivery e34182fb8a2f staging: rtl8723bs: Fix potential overuse of kernel memory e4770de3ae41 staging: rtl8723bs: Fix potential security hole b4eab56d96f1 staging: rtl8188eu: Fix potential overuse of kernel memory 2a50bd9e2a69 staging: rtl8188eu: Fix potential security hole d59f6a6e35b7 usb: dwc3: gadget: Check for IOC/LST bit in TRB->ctrl fields c787444891a4 usb: dwc2: Fix SET/CLEAR_FEATURE and GET_STATUS flows 8cfda0c9c966 USB: hub: Fix the broken detection of USB3 device in SMSC hub 37d2eb43b64c USB: hub: Don't record a connect-change event during reset-resume babaa26b7c1c USB: Fix novation SourceControl XL after suspend 2debc1717cf2 usb: uas: fix a plug & unplug racing 4db4761cfe15 USB: quirks: blacklist duplicate ep on Sound Devices USBPre2 63d176ed148a USB: core: add endpoint-blacklist quirk d74d5d042d42 usb: host: xhci: update event ring dequeue pointer on purpose 2a2582dc62e9 xhci: Fix memory leak when caching protocol extended capability PSI tables - take 2 7c8cde41a0c3 xhci: fix runtime pm enabling for quirky Intel hosts dce60e7efa97 xhci: Force Maximum Packet size for Full-speed bulk devices to valid range. c7f81d70d7ae ubifs: Fix default compression selection in ubifs 3331e61b23b1 nvme: fix kernel paging oops 2f99d478ddbd xfs: require both realtime inodes to mount b2d84967f076 bcache: do not mark writeback_running too early 6f48e23888b9 bcache: do not check if debug dentry is ERR or NULL explicitly on remove c318f88411a8 rtl818x: fix potential use after free 7cf86c89d7e4 brcmfmac: set SDIO F1 MesBusyCtrl for CYW4373 38b73129c113 brcmfmac: set F2 watermark to 256 for 4373 6138e4b132cd mwifiex: debugfs: correct histogram spacing, formatting 1450ff720076 mwifiex: fix potential NULL dereference and use after free 4912b454e029 arm64: dts: renesas: draak: Fix CVBS input 48d37cc42390 crypto: user - support incremental algorithm dumps 43cd68d7002b s390/zcrypt: make sysfs reset attribute trigger queue reset 5ac0da68eae1 nvme: provide fallback for discard alloc failure d702d7bc7eb4 scsi: qla2xxx: Fix for FC-NVMe discovery for NPIV port 78777dd6174e scsi: qla2xxx: Fix NPIV handling for FC-NVMe 58ab95b03497 scsi: lpfc: Enable Management features for IF_TYPE=6 e772949a3fd6 ACPI / LPSS: Ignore acpi_device_fix_up_power() return value d411bd858447 ARM: ks8695: fix section mismatch warning 22227437ca68 xfs: zero length symlinks are not valid 4d54a7969524 PM / AVS: SmartReflex: NULL check before some freeing functions is not needed d2e3e3c3c14b RDMA/vmw_pvrdma: Use atomic memory allocation in create AH 64694b276d74 arm64: preempt: Fix big-endian when checking preempt count in assembly 2ec103458855 RDMA/hns: Fix the bug while use multi-hop of pbl 60da6da4b511 ARM: OMAP1: fix USB configuration for device-only setups 0086d127f90d platform/x86: mlx-platform: Fix LED configuration 08d8ab9615c5 bus: ti-sysc: Check for no-reset and no-idle flags at the child level 4b40393b5240 arm64: smp: Handle errors reported by the firmware e3d27b94111b arm64: mm: Prevent mismatched 52-bit VA support 57f3359cdabe ARM: dts: Fix hsi gdd range for omap4 9b1f6bde17d6 parisc: Fix HP SDC hpa address output d18f228f504e parisc: Fix serio address output 72a50a1e1c65 ARM: dts: imx53-voipac-dmm-668: Fix memory node duplication bf39f5b323eb ARM: dts: imx25: Fix memory node duplication d2eb50e57a5c ARM: dts: imx27: Fix memory node duplication 54750b6f6671 ARM: dts: imx1: Fix memory node duplication 6aeb6bd0eda6 ARM: dts: imx23: Fix memory node duplication 1694780bd4ca ARM: dts: imx50: Fix memory node duplication 2442b4c0f30a ARM: dts: imx6sl: Fix memory node duplication bae011f4c9a4 ARM: dts: imx6sx: Fix memory node duplication 0990926c9395 ARM: dts: imx6ul: Fix memory node duplication e021f0ccc4fa ARM: dts: imx7: Fix memory node duplication a90469345b26 ARM: dts: imx35: Fix memory node duplication 6bc1e695b4be ARM: dts: imx31: Fix memory node duplication ca02e14bdd7f ARM: dts: imx53: Fix memory node duplication 5a1e6f95733c ARM: dts: imx51: Fix memory node duplication 8c0c8c2a80b2 ARM: debug-imx: only define DEBUG_IMX_UART_PORT if needed dee3f7703207 tracing: Lock event_mutex before synth_event_mutex 67547b9b4660 ARM: dts: Fix up SQ201 flash access ee6d2bedb400 scsi: lpfc: Fix dif and first burst use in write commands 20feb7333049 scsi: lpfc: Fix kernel Oops due to null pring pointers a8c0f6334e56 scsi: target/tcmu: Fix queue_cmd_ring() declaration 480233f89d42 pwm: bcm-iproc: Prevent unloading the driver module while in use 27d22db4ccf1 block: drbd: remove a stray unlock in __drbd_send_protocol() 51a564498cfb mac80211: fix station inactive_time shortly after boot b707e0da2791 net/fq_impl: Switch to kvmalloc() for memory allocation a8a61f82cc9f ceph: return -EINVAL if given fsc mount option on kernel w/o support 0f716cda304b net: mscc: ocelot: fix __ocelot_rmw_ix prototype a30c6e424fdd net: bcmgenet: reapply manual settings to the PHY acd6a29134f0 net: bcmgenet: use RGMII loopback for MAC reset ff3f7465ee98 scripts/gdb: fix debugging modules compiled with hot/cold partitioning 22f4892950b2 ASoC: stm32: sai: add restriction on mmap support 3f034e6889e7 watchdog: meson: Fix the wrong value of left time 7302e7b10855 can: mcp251x: mcp251x_restart_work_handler(): Fix potential force_quit race condition 24e10fc2e0db can: flexcan: increase error counters if skb enqueueing via can_rx_offload_queue_sorted() fails ee7981538293 can: rx-offload: can_rx_offload_irq_offload_fifo(): continue on error 5c8f5485614c can: rx-offload: can_rx_offload_irq_offload_timestamp(): continue on error eca4b786f3bb can: rx-offload: can_rx_offload_offload_one(): use ERR_PTR() to propagate error value in case of errors a85ce0107d6b can: rx-offload: can_rx_offload_offload_one(): increment rx_fifo_errors on queue overflow or OOM b83d4e4899d6 can: rx-offload: can_rx_offload_offload_one(): do not increase the skb_queue beyond skb_queue_len_max 77f94f0d7f52 can: rx-offload: can_rx_offload_queue_tail(): fix error handling, avoid skb mem leak 66e21b7b9251 can: c_can: D_CAN: c_can_chip_config(): perform a sofware reset on open 7559e68ca91f can: peak_usb: report bus recovery as well c5b0bbef4367 bridge: ebtables: don't crash when using dnat target in output chains 2070b33ee987 net: fec: add missed clk_disable_unprepare in remove 28f34294442b clk: ti: clkctrl: Fix failed to enable error with double udelay timeout cb5a4049608c clk: ti: dra7-atl-clock: Remove ti_clk_add_alias call 1677a0e54937 x86/resctrl: Prevent NULL pointer dereference when reading mondata 8ef58b82d1e4 idr: Fix idr_alloc_u32 on 32-bit systems 88358c7610cc idr: Fix integer overflow in idr_for_each_entry a6359d5e2d98 powerpc/bpf: Fix tail call implementation 4665759af735 samples/bpf: fix build by setting HAVE_ATTR_TEST to zero 40c3b8fc47b3 ARM: dts: sun8i-a83t-tbs-a711: Fix WiFi resume from suspend 40017db20bfa clk: sunxi-ng: a80: fix the zero'ing of bits 16 and 18 49ade064ea4b clk: sunxi: Fix operator precedence in sunxi_divs_clk_setup 15fc2f3c64e7 clk: at91: avoid sleeping early 8885552a061b reset: fix reset_control_ops kerneldoc comment a94913c0c8cf ARM: dts: imx6qdl-sabreauto: Fix storm of accelerometer interrupts 5b15b1bf5428 pinctrl: cherryview: Allocate IRQ chip dynamic a0554203bc12 clk: samsung: exynos5420: Preserve PLL configuration during suspend/resume 80e28fa256c9 ASoC: kirkwood: fix device remove ordering 6a7472add344 ASoC: kirkwood: fix external clock probe defer a2c2cf16b059 clk: samsung: exynos5433: Fix error paths 9a5933aa1242 reset: Fix memory leak in reset_control_array_put() e8eb6233be9a ASoC: compress: fix unsigned integer overflow check 7971b7fd5623 ASoC: msm8916-wcd-analog: Fix RX1 selection in RDAC2 MUX daa2c4030510 clocksource/drivers/mediatek: Fix error handling 9c65bb9518ea clk: meson: gxbb: let sar_adc_clk_div set the parent clock rate Signed-off-by: Bruce Ashfield --- .../linux/linux-yocto-rt_4.19.bb | 6 +++--- .../linux/linux-yocto-tiny_4.19.bb | 8 ++++---- meta/recipes-kernel/linux/linux-yocto_4.19.bb | 20 +++++++++---------- 3 files changed, 17 insertions(+), 17 deletions(-) diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb b/meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb index b6e0a1e9e2..93c4472316 100644 --- a/meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb +++ b/meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb @@ -11,13 +11,13 @@ python () { raise bb.parse.SkipRecipe("Set PREFERRED_PROVIDER_virtual/kernel to linux-yocto-rt to enable it") } -SRCREV_machine ?= "2fbf678238302f33b3aec5a2cba829f260744f24" -SRCREV_meta ?= "4f5d761316a9cf14605e5d0cc91b53c1b2e9dc6a" +SRCREV_machine ?= "40e34fdcb540e35b1a97e8e52c11dfe52bd68b16" +SRCREV_meta ?= "7cb520d405cd5ca8f21a333941fbc0861bbb36b0" SRC_URI = "git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \ git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.19;destsuffix=${KMETA}" -LINUX_VERSION ?= "4.19.87" +LINUX_VERSION ?= "4.19.107" LIC_FILES_CHKSUM = "file://COPYING;md5=bbea815ee2795b2f4230826c0c6b8814" diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_4.19.bb b/meta/recipes-kernel/linux/linux-yocto-tiny_4.19.bb index e2626ab4c9..76b2467ef5 100644 --- a/meta/recipes-kernel/linux/linux-yocto-tiny_4.19.bb +++ b/meta/recipes-kernel/linux/linux-yocto-tiny_4.19.bb @@ -6,7 +6,7 @@ KCONFIG_MODE = "--allnoconfig" require recipes-kernel/linux/linux-yocto.inc -LINUX_VERSION ?= "4.19.87" +LINUX_VERSION ?= "4.19.107" LIC_FILES_CHKSUM = "file://COPYING;md5=bbea815ee2795b2f4230826c0c6b8814" DEPENDS += "${@bb.utils.contains('ARCH', 'x86', 'elfutils-native', '', d)}" @@ -15,9 +15,9 @@ DEPENDS += "openssl-native util-linux-native" KMETA = "kernel-meta" KCONF_BSP_AUDIT_LEVEL = "2" -SRCREV_machine_qemuarm ?= "bd239fb802a15c2759ea456dd1f09f5e106fc88a" -SRCREV_machine ?= "b44ad1b1e7c685e75b7788a026a2416edc2ee656" -SRCREV_meta ?= "4f5d761316a9cf14605e5d0cc91b53c1b2e9dc6a" +SRCREV_machine_qemuarm ?= "e2c947b59c650f2aa2f0f88d6af90f9dfb336e04" +SRCREV_machine ?= "16ae5406361af8329b74580697cb738dadeb1ecb" +SRCREV_meta ?= "7cb520d405cd5ca8f21a333941fbc0861bbb36b0" PV = "${LINUX_VERSION}+git${SRCPV}" diff --git a/meta/recipes-kernel/linux/linux-yocto_4.19.bb b/meta/recipes-kernel/linux/linux-yocto_4.19.bb index c6e482a984..6e3b00e0e5 100644 --- a/meta/recipes-kernel/linux/linux-yocto_4.19.bb +++ b/meta/recipes-kernel/linux/linux-yocto_4.19.bb @@ -11,22 +11,22 @@ KBRANCH_qemux86 ?= "v4.19/standard/base" KBRANCH_qemux86-64 ?= "v4.19/standard/base" KBRANCH_qemumips64 ?= "v4.19/standard/mti-malta64" -SRCREV_machine_qemuarm ?= "19fa1657d1d82d01647c6f73a2bbf39305505294" -SRCREV_machine_qemuarm64 ?= "b44ad1b1e7c685e75b7788a026a2416edc2ee656" -SRCREV_machine_qemumips ?= "8fb7ab96b84852ee3d9e1d9d9e7bc35e1249b653" -SRCREV_machine_qemuppc ?= "b44ad1b1e7c685e75b7788a026a2416edc2ee656" -SRCREV_machine_qemux86 ?= "b44ad1b1e7c685e75b7788a026a2416edc2ee656" -SRCREV_machine_qemux86-64 ?= "b44ad1b1e7c685e75b7788a026a2416edc2ee656" -SRCREV_machine_qemumips64 ?= "c8a036abd7d469013dddab15a23e0d2dde1d0000" -SRCREV_machine ?= "b44ad1b1e7c685e75b7788a026a2416edc2ee656" -SRCREV_meta ?= "4f5d761316a9cf14605e5d0cc91b53c1b2e9dc6a" +SRCREV_machine_qemuarm ?= "c8b87f4d12eb957d8a95442a928ef4820037bb55" +SRCREV_machine_qemuarm64 ?= "16ae5406361af8329b74580697cb738dadeb1ecb" +SRCREV_machine_qemumips ?= "94f102eaca76ffdcc3d47ea94b47486d7157c531" +SRCREV_machine_qemuppc ?= "16ae5406361af8329b74580697cb738dadeb1ecb" +SRCREV_machine_qemux86 ?= "16ae5406361af8329b74580697cb738dadeb1ecb" +SRCREV_machine_qemux86-64 ?= "16ae5406361af8329b74580697cb738dadeb1ecb" +SRCREV_machine_qemumips64 ?= "98288b7e79bc8130c2a889d763c9c1aa15ff4939" +SRCREV_machine ?= "16ae5406361af8329b74580697cb738dadeb1ecb" +SRCREV_meta ?= "7cb520d405cd5ca8f21a333941fbc0861bbb36b0" SRC_URI = "git://git.yoctoproject.org/linux-yocto.git;name=machine;branch=${KBRANCH}; \ git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.19;destsuffix=${KMETA} \ " LIC_FILES_CHKSUM = "file://COPYING;md5=bbea815ee2795b2f4230826c0c6b8814" -LINUX_VERSION ?= "4.19.87" +LINUX_VERSION ?= "4.19.107" DEPENDS += "${@bb.utils.contains('ARCH', 'x86', 'elfutils-native', '', d)}" DEPENDS += "openssl-native util-linux-native" -- 2.19.1 From jpuhlman at mvista.com Tue Mar 17 04:58:35 2020 From: jpuhlman at mvista.com (Jeremy A. Puhlman) Date: Mon, 16 Mar 2020 21:58:35 -0700 Subject: [OE-core] =?utf-8?b?5Zue5aSNOiDlm57lpI06ICBbUEFUQ0ggMi8yXSBnbGli?= =?utf-8?q?-2=2E0=3A_Correct_multilib_conflict?= In-Reply-To: References: <20200311222249.29880-1-jpuhlman@mvista.com> <20200311222249.29880-2-jpuhlman@mvista.com> Message-ID: <893056b5-2095-a84e-553b-d6278adfc579@mvista.com> Do you have ptests turned off? Looks like all the test checking is done in do_install rather then do_install_ptest. I think I need to add a check for the existance like the change above the added one. On 3/16/2020 9:31 PM, Chen, Qi wrote: > MULTILIBS ?= "multilib:lib32" > DEFAULTTUNE_virtclass-multilib-lib32 ?= "armv7vethf" > > I think you can use these two lines to reproduce the problem with > multilib enabled. > > Regards, > Chen Qi > ------------------------------------------------------------------------ > *???:* Jeremy A. Puhlman > *????:* 2020?3?17? 12:02 > *???:* Chen, Qi ; > openembedded-core at lists.openembedded.org > > *??:* Re: ??: [OE-core] [PATCH 2/2] glib-2.0: Correct multilib > conflict > Just standard x86/i585. What are you using for your mulitlib. > ilp32/aarch32/arm7? > > require conf/multilib.conf > MULTILIBS = "multilib:lib32" > X86ARCH32 = "i586" > DEFAULTTUNE_virtclass-multilib-lib32 = "i586" > TARGET_ARCH_virtclass-multilib-lib32 = "i586" > TARGET_LD_ARCH_virtclass-multilib-lib32 = "-m elf_i386" > ALTBINDIR_SUFFIX_virtclass-multilib-lib32 = "32" > > What does your -e look like for the recipe that fails? > > On 3/16/2020 8:30 PM, Chen, Qi wrote: >> This patch is causing regression in case of qemuarm64 multilib for >> me. The static-link.test file is not there, resulting the `mv' >> command failure. I've sent out a patch to fix this problem, but I >> don't know what's your environment. So please help review. >> >> Regards, >> Chen Qi >> ------------------------------------------------------------------------ >> *???:* openembedded-core-bounces at lists.openembedded.org >> >> >> ?? Jeremy >> A. Puhlman >> *????:* 2020?3?12? 6:22 >> *???:* openembedded-core at lists.openembedded.org >> >> >> >> *??:* [OE-core] [PATCH 2/2] glib-2.0: Correct multilib conflict >> From: Jeremy Puhlman >> >> Signed-off-by: Jeremy A. Puhlman >> >> --- >> ?meta/recipes-core/glib-2.0/glib.inc | 3 +++ >> ?1 file changed, 3 insertions(+) >> >> diff --git a/meta/recipes-core/glib-2.0/glib.inc >> b/meta/recipes-core/glib-2.0/glib.inc >> index 23c347dbf7..edecc51fdb 100644 >> --- a/meta/recipes-core/glib-2.0/glib.inc >> +++ b/meta/recipes-core/glib-2.0/glib.inc >> @@ -128,6 +128,9 @@ do_install_append_class-target () { >> ???????????????????????? rm >> ${D}${datadir}/installed-tests/glib/gdbus-serialization.test >> ???????????????? fi >> ???????? fi >> +??????? if test "x${MLPREFIX}" != "x"; then >> +??????????????? mv >> ${D}${datadir}/installed-tests/glib/static-link.test >> ${D}${datadir}/installed-tests/glib/${MLPREFIX}static-link.test >> +??????? fi >> ?} >> >> ?# As we do not build python3 for windows, makes no sense to ship the >> script that's using it >> -- >> 2.13.3 >> >> -- >> _______________________________________________ >> Openembedded-core mailing list >> Openembedded-core at lists.openembedded.org >> >> http://lists.openembedded.org/mailman/listinfo/openembedded-core >> >> >> Virus-free. www.avg.com >> >> >> > > -- > Jeremy A. Puhlman > jpuhlman at mvista.com -- Jeremy A. Puhlman jpuhlman at mvista.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Qi.Chen at windriver.com Tue Mar 17 05:21:10 2020 From: Qi.Chen at windriver.com (Chen, Qi) Date: Tue, 17 Mar 2020 05:21:10 +0000 Subject: [OE-core] =?gb2312?b?u9i4tDogu9i4tDogu9i4tDogIFtQQVRDSCAyLzJdIGds?= =?gb2312?b?aWItMi4wOiBDb3JyZWN0IG11bHRpbGliIGNvbmZsaWN0?= In-Reply-To: <893056b5-2095-a84e-553b-d6278adfc579@mvista.com> References: <20200311222249.29880-1-jpuhlman@mvista.com> <20200311222249.29880-2-jpuhlman@mvista.com> , <893056b5-2095-a84e-553b-d6278adfc579@mvista.com> Message-ID: Yes. ptest turned off. Regards, Chen Qi ________________________________ ???: Jeremy A. Puhlman ????: 2020?3?17? 12:58 ???: Chen, Qi ; openembedded-core at lists.openembedded.org ??: Re: ??: ??: [OE-core] [PATCH 2/2] glib-2.0: Correct multilib conflict Do you have ptests turned off? Looks like all the test checking is done in do_install rather then do_install_ptest. I think I need to add a check for the existance like the change above the added one. On 3/16/2020 9:31 PM, Chen, Qi wrote: MULTILIBS ?= "multilib:lib32" DEFAULTTUNE_virtclass-multilib-lib32 ?= "armv7vethf" I think you can use these two lines to reproduce the problem with multilib enabled. Regards, Chen Qi ________________________________ ???: Jeremy A. Puhlman ????: 2020?3?17? 12:02 ???: Chen, Qi ; openembedded-core at lists.openembedded.org ??: Re: ??: [OE-core] [PATCH 2/2] glib-2.0: Correct multilib conflict Just standard x86/i585. What are you using for your mulitlib. ilp32/aarch32/arm7? require conf/multilib.conf MULTILIBS = "multilib:lib32" X86ARCH32 = "i586" DEFAULTTUNE_virtclass-multilib-lib32 = "i586" TARGET_ARCH_virtclass-multilib-lib32 = "i586" TARGET_LD_ARCH_virtclass-multilib-lib32 = "-m elf_i386" ALTBINDIR_SUFFIX_virtclass-multilib-lib32 = "32" What does your -e look like for the recipe that fails? On 3/16/2020 8:30 PM, Chen, Qi wrote: This patch is causing regression in case of qemuarm64 multilib for me. The static-link.test file is not there, resulting the `mv' command failure. I've sent out a patch to fix this problem, but I don't know what's your environment. So please help review. Regards, Chen Qi ________________________________ ???: openembedded-core-bounces at lists.openembedded.org ?? Jeremy A. Puhlman ????: 2020?3?12? 6:22 ???: openembedded-core at lists.openembedded.org ??: [OE-core] [PATCH 2/2] glib-2.0: Correct multilib conflict From: Jeremy Puhlman Signed-off-by: Jeremy A. Puhlman --- meta/recipes-core/glib-2.0/glib.inc | 3 +++ 1 file changed, 3 insertions(+) diff --git a/meta/recipes-core/glib-2.0/glib.inc b/meta/recipes-core/glib-2.0/glib.inc index 23c347dbf7..edecc51fdb 100644 --- a/meta/recipes-core/glib-2.0/glib.inc +++ b/meta/recipes-core/glib-2.0/glib.inc @@ -128,6 +128,9 @@ do_install_append_class-target () { rm ${D}${datadir}/installed-tests/glib/gdbus-serialization.test fi fi + if test "x${MLPREFIX}" != "x"; then + mv ${D}${datadir}/installed-tests/glib/static-link.test ${D}${datadir}/installed-tests/glib/${MLPREFIX}static-link.test + fi } # As we do not build python3 for windows, makes no sense to ship the script that's using it -- 2.13.3 -- _______________________________________________ Openembedded-core mailing list Openembedded-core at lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core [https://ipmcdn.avast.com/images/icons/icon-envelope-tick-green-avg-v1.png] Virus-free. www.avg.com -- Jeremy A. Puhlman jpuhlman at mvista.com -- Jeremy A. Puhlman jpuhlman at mvista.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ticotimo at gmail.com Tue Mar 17 05:37:55 2020 From: ticotimo at gmail.com (Tim Orling) Date: Mon, 16 Mar 2020 22:37:55 -0700 Subject: [OE-core] [PATCH] stress-ng: upgrade 0.11.01 -> 0.11.02 In-Reply-To: <1584429410-1890-3-git-send-email-wangmy@cn.fujitsu.com> References: <1584429410-1890-1-git-send-email-wangmy@cn.fujitsu.com> <1584429410-1890-3-git-send-email-wangmy@cn.fujitsu.com> Message-ID: 0.11.03 is already released. On Mon, Mar 16, 2020 at 6:44 PM Wang Mingyu wrote: > Signed-off-by: Wang Mingyu > --- > .../stress-ng/{stress-ng_0.11.01.bb => stress-ng_0.11.02.bb} | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > rename meta/recipes-extended/stress-ng/{stress-ng_0.11.01.bb => > stress-ng_0.11.02.bb} (83%) > > diff --git a/meta/recipes-extended/stress-ng/stress-ng_0.11.01.bb > b/meta/recipes-extended/stress-ng/stress-ng_0.11.02.bb > similarity index 83% > rename from meta/recipes-extended/stress-ng/stress-ng_0.11.01.bb > rename to meta/recipes-extended/stress-ng/stress-ng_0.11.02.bb > index 3486be1b03..e79ee49e24 100644 > --- a/meta/recipes-extended/stress-ng/stress-ng_0.11.01.bb > +++ b/meta/recipes-extended/stress-ng/stress-ng_0.11.02.bb > @@ -8,8 +8,8 @@ LIC_FILES_CHKSUM = > "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263" > SRC_URI = "https://kernel.ubuntu.com/~cking/tarballs/${BPN}/${BP}.tar.xz > \ > > file://0001-Do-not-preserve-ownership-when-installing-example-jo.patch \ > " > -SRC_URI[md5sum] = "a558fc7fb9d0a851afe6de09080b5401" > -SRC_URI[sha256sum] = > "9fe19548c87aa1a1b9b2be3b359ec2621b88bcb16998b77527549a7736f65494" > +SRC_URI[md5sum] = "a353287968818f7181eae9a90ddc4f25" > +SRC_URI[sha256sum] = > "ad1a6fca8f90f67a4364aa6ff0c406995960dc4f8689e9d5289fc083e1d8986f" > > DEPENDS = "coreutils-native" > > -- > 2.17.1 > > > > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core at lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpuhlman at mvista.com Tue Mar 17 06:03:05 2020 From: jpuhlman at mvista.com (Jeremy A. Puhlman) Date: Mon, 16 Mar 2020 23:03:05 -0700 Subject: [OE-core] [PATCH] glib-2.0: update ptest multilib fix Message-ID: <20200317060305.25237-1-jpuhlman@mvista.com> From: Jeremy Puhlman The updates to the tests are done in do_install instead of do_install_ptest, so the changes need to consider ptest not being turned on. Signed-off-by: Jeremy A. Puhlman --- meta/recipes-core/glib-2.0/glib.inc | 2 ++ 1 file changed, 2 insertions(+) diff --git a/meta/recipes-core/glib-2.0/glib.inc b/meta/recipes-core/glib-2.0/glib.inc index edecc51fdb..7ebed0e5fd 100644 --- a/meta/recipes-core/glib-2.0/glib.inc +++ b/meta/recipes-core/glib-2.0/glib.inc @@ -128,9 +128,11 @@ do_install_append_class-target () { rm ${D}${datadir}/installed-tests/glib/gdbus-serialization.test fi fi + if [ -f ${D}${datadir}/installed-tests/glib/static-link.test ]; then if test "x${MLPREFIX}" != "x"; then mv ${D}${datadir}/installed-tests/glib/static-link.test ${D}${datadir}/installed-tests/glib/${MLPREFIX}static-link.test fi + fi } # As we do not build python3 for windows, makes no sense to ship the script that's using it -- 2.13.3 From jpuhlman at mvista.com Tue Mar 17 06:03:30 2020 From: jpuhlman at mvista.com (Jeremy A. Puhlman) Date: Mon, 16 Mar 2020 23:03:30 -0700 Subject: [OE-core] =?utf-8?b?5Zue5aSNOiDlm57lpI06IOWbnuWkjTogIFtQQVRDSCAy?= =?utf-8?q?/2=5D_glib-2=2E0=3A_Correct_multilib_conflict?= In-Reply-To: References: <20200311222249.29880-1-jpuhlman@mvista.com> <20200311222249.29880-2-jpuhlman@mvista.com> <893056b5-2095-a84e-553b-d6278adfc579@mvista.com> Message-ID: Patch sent to the list. On 3/16/2020 10:21 PM, Chen, Qi wrote: > Yes. ptest turned off. > > Regards, > Chen Qi > ------------------------------------------------------------------------ > *???:* Jeremy A. Puhlman > *????:* 2020?3?17? 12:58 > *???:* Chen, Qi ; > openembedded-core at lists.openembedded.org > > *??:* Re: ??: ??: [OE-core] [PATCH 2/2] glib-2.0: Correct multilib > conflict > Do you have ptests turned off? > Looks like all the test checking is done in do_install rather then > do_install_ptest. I think I need to add a check for the existance like > the change above the added one. > > On 3/16/2020 9:31 PM, Chen, Qi wrote: >> MULTILIBS ?= "multilib:lib32" >> DEFAULTTUNE_virtclass-multilib-lib32 ?= "armv7vethf" >> >> I think you can use these two lines to reproduce the problem with >> multilib enabled. >> >> Regards, >> Chen Qi >> ------------------------------------------------------------------------ >> *???:* Jeremy A. Puhlman >> >> *????:* 2020?3?17? 12:02 >> *???:* Chen, Qi >> ; >> openembedded-core at lists.openembedded.org >> >> >> >> *??:* Re: ??: [OE-core] [PATCH 2/2] glib-2.0: Correct multilib >> conflict >> Just standard x86/i585. What are you using for your mulitlib. >> ilp32/aarch32/arm7? >> >> require conf/multilib.conf >> MULTILIBS = "multilib:lib32" >> X86ARCH32 = "i586" >> DEFAULTTUNE_virtclass-multilib-lib32 = "i586" >> TARGET_ARCH_virtclass-multilib-lib32 = "i586" >> TARGET_LD_ARCH_virtclass-multilib-lib32 = "-m elf_i386" >> ALTBINDIR_SUFFIX_virtclass-multilib-lib32 = "32" >> >> What does your -e look like for the recipe that fails? >> >> On 3/16/2020 8:30 PM, Chen, Qi wrote: >>> This patch is causing regression in case of qemuarm64 multilib for >>> me. The static-link.test file is not there, resulting the `mv' >>> command failure. I've sent out a patch to fix this problem, but I >>> don't know what's your environment. So please help review. >>> >>> Regards, >>> Chen Qi >>> ------------------------------------------------------------------------ >>> *???:* openembedded-core-bounces at lists.openembedded.org >>> >>> >>> ?? Jeremy >>> A. Puhlman >>> *????:* 2020?3?12? 6:22 >>> *???:* openembedded-core at lists.openembedded.org >>> >>> >>> >>> *??:* [OE-core] [PATCH 2/2] glib-2.0: Correct multilib conflict >>> From: Jeremy Puhlman >>> >>> Signed-off-by: Jeremy A. Puhlman >>> >>> --- >>> ?meta/recipes-core/glib-2.0/glib.inc | 3 +++ >>> ?1 file changed, 3 insertions(+) >>> >>> diff --git a/meta/recipes-core/glib-2.0/glib.inc >>> b/meta/recipes-core/glib-2.0/glib.inc >>> index 23c347dbf7..edecc51fdb 100644 >>> --- a/meta/recipes-core/glib-2.0/glib.inc >>> +++ b/meta/recipes-core/glib-2.0/glib.inc >>> @@ -128,6 +128,9 @@ do_install_append_class-target () { >>> ???????????????????????? rm >>> ${D}${datadir}/installed-tests/glib/gdbus-serialization.test >>> ???????????????? fi >>> ???????? fi >>> +??????? if test "x${MLPREFIX}" != "x"; then >>> +??????????????? mv >>> ${D}${datadir}/installed-tests/glib/static-link.test >>> ${D}${datadir}/installed-tests/glib/${MLPREFIX}static-link.test >>> +??????? fi >>> ?} >>> >>> ?# As we do not build python3 for windows, makes no sense to ship >>> the script that's using it >>> -- >>> 2.13.3 >>> >>> -- >>> _______________________________________________ >>> Openembedded-core mailing list >>> Openembedded-core at lists.openembedded.org >>> >>> http://lists.openembedded.org/mailman/listinfo/openembedded-core >>> >>> >>> Virus-free. www.avg.com >>> >>> >>> >> >> -- >> Jeremy A. Puhlman >> jpuhlman at mvista.com > > -- > Jeremy A. Puhlman > jpuhlman at mvista.com -- Jeremy A. Puhlman jpuhlman at mvista.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From raj.khem at gmail.com Tue Mar 17 07:04:15 2020 From: raj.khem at gmail.com (Khem Raj) Date: Tue, 17 Mar 2020 00:04:15 -0700 Subject: [OE-core] [PATCH 0/2] Add multilib support to musl systems Message-ID: <20200317070417.1250936-1-raj.khem@gmail.com> This has been outstanding issue for few releases, this patchset ensures that we can build multilib images with musl too Khem Raj (2): linuxloader: Add get_musl_loader_arch function musl: Add support for multilib meta/classes/linuxloader.bbclass | 29 +++++++++++++++++------------ meta/recipes-core/musl/musl_git.bb | 10 +++++++--- 2 files changed, 24 insertions(+), 15 deletions(-) -- 2.25.1 From raj.khem at gmail.com Tue Mar 17 07:04:16 2020 From: raj.khem at gmail.com (Khem Raj) Date: Tue, 17 Mar 2020 00:04:16 -0700 Subject: [OE-core] [PATCH 1/2] linuxloader: Add get_musl_loader_arch function In-Reply-To: <20200317070417.1250936-1-raj.khem@gmail.com> References: <20200317070417.1250936-1-raj.khem@gmail.com> Message-ID: <20200317070417.1250936-2-raj.khem@gmail.com> get_musl_loader_arch returns the arch part of ldso for musl, this is used in get_musl_loader() as well as independently usable, which is needed for multilib support in musl. Musl stores all ldso in /lib be it multilib or not, therefore do not use base_libdir instead directly use /lib [YOCTO #11971] Signed-off-by: Khem Raj --- meta/classes/linuxloader.bbclass | 29 +++++++++++++++++------------ 1 file changed, 17 insertions(+), 12 deletions(-) diff --git a/meta/classes/linuxloader.bbclass b/meta/classes/linuxloader.bbclass index e2876cec7a..ec0e0556dd 100644 --- a/meta/classes/linuxloader.bbclass +++ b/meta/classes/linuxloader.bbclass @@ -1,27 +1,31 @@ -def get_musl_loader(d): +def get_musl_loader_arch(d): import re - dynamic_loader = None + ldso_arch = None targetarch = d.getVar("TARGET_ARCH") if targetarch.startswith("microblaze"): - dynamic_loader = "${base_libdir}/ld-musl-microblaze${@bb.utils.contains('TUNE_FEATURES', 'bigendian', '', 'el' ,d)}.so.1" + ldso_arch = "microblaze${@bb.utils.contains('TUNE_FEATURES', 'bigendian', '', 'el' ,d)}" elif targetarch.startswith("mips"): - dynamic_loader = "${base_libdir}/ld-musl-mips${ABIEXTENSION}${MIPSPKGSFX_BYTE}${MIPSPKGSFX_R6}${MIPSPKGSFX_ENDIAN}${@['', '-sf'][d.getVar('TARGET_FPU') == 'soft']}.so.1" + ldso_arch = "mips${ABIEXTENSION}${MIPSPKGSFX_BYTE}${MIPSPKGSFX_R6}${MIPSPKGSFX_ENDIAN}${@['', '-sf'][d.getVar('TARGET_FPU') == 'soft']}" elif targetarch == "powerpc": - dynamic_loader = "${base_libdir}/ld-musl-powerpc${@['', '-sf'][d.getVar('TARGET_FPU') == 'soft']}.so.1" + ldso_arch = "powerpc${@['', '-sf'][d.getVar('TARGET_FPU') == 'soft']}" elif targetarch == "powerpc64": - dynamic_loader = "${base_libdir}/ld-musl-powerpc64.so.1" + ldso_arch = "powerpc64" elif targetarch == "x86_64": - dynamic_loader = "${base_libdir}/ld-musl-x86_64.so.1" + ldso_arch = "x86_64" elif re.search("i.86", targetarch): - dynamic_loader = "${base_libdir}/ld-musl-i386.so.1" + ldso_arch = "i386" elif targetarch.startswith("arm"): - dynamic_loader = "${base_libdir}/ld-musl-arm${ARMPKGSFX_ENDIAN}${ARMPKGSFX_EABI}.so.1" + ldso_arch = "arm${ARMPKGSFX_ENDIAN}${ARMPKGSFX_EABI}" elif targetarch.startswith("aarch64"): - dynamic_loader = "${base_libdir}/ld-musl-aarch64${ARMPKGSFX_ENDIAN_64}.so.1" + ldso_arch = "aarch64${ARMPKGSFX_ENDIAN_64}" elif targetarch.startswith("riscv64"): - dynamic_loader = "${base_libdir}/ld-musl-riscv64${@['', '-sf'][d.getVar('TARGET_FPU') == 'soft']}.so.1" - return dynamic_loader + ldso_arch = "riscv64${@['', '-sf'][d.getVar('TARGET_FPU') == 'soft']}" + return ldso_arch + +def get_musl_loader(d): + import re + return "/lib/ld-musl-" + get_musl_loader_arch(d) + ".so.1" def get_glibc_loader(d): import re @@ -62,4 +66,5 @@ def get_linuxloader(d): get_linuxloader[vardepvalue] = "${@get_linuxloader(d)}" get_musl_loader[vardepvalue] = "${@get_musl_loader(d)}" +get_musl_loader_arch[vardepvalue] = "${@get_musl_loader_arch(d)}" get_glibc_loader[vardepvalue] = "${@get_glibc_loader(d)}" -- 2.25.1 From raj.khem at gmail.com Tue Mar 17 07:04:17 2020 From: raj.khem at gmail.com (Khem Raj) Date: Tue, 17 Mar 2020 00:04:17 -0700 Subject: [OE-core] [PATCH 2/2] musl: Add support for multilib In-Reply-To: <20200317070417.1250936-1-raj.khem@gmail.com> References: <20200317070417.1250936-1-raj.khem@gmail.com> Message-ID: <20200317070417.1250936-3-raj.khem@gmail.com> ldso is always stored in /lib regardless of multilib add ld-musl-${MUSL_LDSO_ARCH}.path to aid ldso finding default library loading paths, it helps when using multilib, where system libraries are moved to lib32 or lib64 paths under / or /usr [YOCTO #11971] Signed-off-by: Khem Raj --- meta/recipes-core/musl/musl_git.bb | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/meta/recipes-core/musl/musl_git.bb b/meta/recipes-core/musl/musl_git.bb index 2a15a78cd5..82379fd1c5 100644 --- a/meta/recipes-core/musl/musl_git.bb +++ b/meta/recipes-core/musl/musl_git.bb @@ -29,6 +29,7 @@ DEPENDS = "virtual/${TARGET_PREFIX}binutils \ libssp-nonshared \ " GLIBC_LDSO = "${@get_glibc_loader(d)}" +MUSL_LDSO_ARCH = "${@get_musl_loader_arch(d)}" export CROSS_COMPILE="${TARGET_PREFIX}" @@ -48,7 +49,7 @@ CONFIGUREOPTS = " \ --bindir=${bindir} \ --libdir=${libdir} \ --includedir=${includedir} \ - --syslibdir=${base_libdir} \ + --syslibdir=/lib \ " do_configure() { @@ -61,8 +62,9 @@ do_compile() { do_install() { oe_runmake install DESTDIR='${D}' - - install -d ${D}${bindir} + install -d ${D}${bindir} ${D}${base_libdir} ${D}${sysconfdir} + echo "${base_libdir}" > ${D}${sysconfdir}/ld-musl-${MUSL_LDSO_ARCH}.path + echo "${libdir}" >> ${D}${sysconfdir}/ld-musl-${MUSL_LDSO_ARCH}.path rm -f ${D}${bindir}/ldd ${D}${GLIBC_LDSO} lnr ${D}${libdir}/libc.so ${D}${bindir}/ldd lnr ${D}${libdir}/libc.so ${D}${GLIBC_LDSO} @@ -70,6 +72,7 @@ do_install() { PACKAGES =+ "${PN}-glibc-compat" +FILES_${PN} += "/lib/ld-musl-${MUSL_LDSO_ARCH}.so.1 ${sysconfdir}/ld-musl-${MUSL_LDSO_ARCH}.path" FILES_${PN}-glibc-compat += "${GLIBC_LDSO}" FILES_${PN}-staticdev = "${libdir}/libc.a" FILES_${PN}-dev =+ "${libdir}/libcrypt.a ${libdir}/libdl.a ${libdir}/libm.a \ @@ -83,3 +86,4 @@ RPROVIDES_${PN} += "ldd libsegfault rtld(GNU_HASH)" LEAD_SONAME = "libc.so" INSANE_SKIP_${PN}-dev = "staticdev" +INSANE_SKIP_${PN} = "libdir" -- 2.25.1 From wak at google.com Tue Mar 17 07:14:10 2020 From: wak at google.com (William A. Kennington III) Date: Tue, 17 Mar 2020 00:14:10 -0700 Subject: [OE-core] [oe-core][PATCH] meson: upgrade 0.53.1 -> 0.53.2 Message-ID: <20200317071410.136012-1-wak@google.com> Signed-off-by: William A. Kennington III --- meta/recipes-devtools/meson/meson.inc | 4 ++-- .../meson/{meson_0.53.1.bb => meson_0.53.2.bb} | 0 .../{nativesdk-meson_0.53.1.bb => nativesdk-meson_0.53.2.bb} | 0 3 files changed, 2 insertions(+), 2 deletions(-) rename meta/recipes-devtools/meson/{meson_0.53.1.bb => meson_0.53.2.bb} (100%) rename meta/recipes-devtools/meson/{nativesdk-meson_0.53.1.bb => nativesdk-meson_0.53.2.bb} (100%) diff --git a/meta/recipes-devtools/meson/meson.inc b/meta/recipes-devtools/meson/meson.inc index d391c9cf29..50fb41ac98 100644 --- a/meta/recipes-devtools/meson/meson.inc +++ b/meta/recipes-devtools/meson/meson.inc @@ -17,8 +17,8 @@ SRC_URI = "https://github.com/mesonbuild/meson/releases/download/${PV}/meson-${P file://0001-mesonbuild-environment.py-check-environment-for-vari.patch \ file://0001-modules-python.py-do-not-substitute-python-s-install.patch \ " -SRC_URI[sha256sum] = "ec1ba33eea701baca2c1607dac458152dc8323364a51fdef6babda2623413b04" -SRC_URI[md5sum] = "9bf73f7b5a2426a7c8674a809bb8cae2" +SRC_URI[sha256sum] = "3e8f830f33184397c2eb0b651ec502adb63decb28978bdc84b3558d71284c21f" +SRC_URI[md5sum] = "80303535995fcae72bdb887df102b421" SRC_URI_append_class-native = " \ file://0001-Make-CPU-family-warnings-fatal.patch \ diff --git a/meta/recipes-devtools/meson/meson_0.53.1.bb b/meta/recipes-devtools/meson/meson_0.53.2.bb similarity index 100% rename from meta/recipes-devtools/meson/meson_0.53.1.bb rename to meta/recipes-devtools/meson/meson_0.53.2.bb diff --git a/meta/recipes-devtools/meson/nativesdk-meson_0.53.1.bb b/meta/recipes-devtools/meson/nativesdk-meson_0.53.2.bb similarity index 100% rename from meta/recipes-devtools/meson/nativesdk-meson_0.53.1.bb rename to meta/recipes-devtools/meson/nativesdk-meson_0.53.2.bb -- 2.25.0 From andrej.valek at siemens.com Tue Mar 17 09:05:38 2020 From: andrej.valek at siemens.com (Andrej Valek) Date: Tue, 17 Mar 2020 10:05:38 +0100 Subject: [OE-core] [PATCH 0/2] Extensible SDK improvements In-Reply-To: References: <20200306153234.23875-1-andrej.valek@siemens.com> Message-ID: Hello Richard, Thank you for taking care of it. I didn't know, that is possible to use "functions" in d.getVar case. Yes, I have tested it. And yes, what you have mentioned is working, as we were expecting. I will rather use my mechanism to just fill a list with variables. Then I don't need to take a care, if there are fully expanded it or not. So we can keep like it is. But, yes, a small improvement for someone else could be, that we will put a "False" there, but not for me. Regards, Andrej On 2020-03-16 14:07, Richard Purdie wrote: > Hi Andrej, > > On Mon, 2020-03-09 at 09:05 +0100, Andrej Valek wrote: >> I can try to explain it in some examples. >> >> I would like to add some extra (dynamic) variables into local.conf in >> eSDK mode. I have found, that there are 2 possibilities (in >> populate_sdk_ext.bbclass) sdk-extra.conf and sdk_extraconf. >> >> - sdk-extra.conf >> - You have to have handle own function to write into sdk-extra.conf. >> I >> think, this is not the right way for me. >> - sdk_extraconf >> - This variable is fine, but there are some restrictions. There is >> no >> easy way to add multiple variables including values. >> >> I would like to have: >> aaa = "valueA" >> bbb = "valueB" >> in local.conf file. >> >> 1. sdk_extraconf = 'aaa = "valueA"\nbbb = "valueB"' >> - this will write aaa = "valueA"\nbbb = "valueB" >> 2. python copy_buildsystem_prepend() { >> d.setVar('sdk_extraconf','aaa = "valueA"\nbbb = "valueB"') >> } >> - This will write exactly, what you want, but you have to have an >> copy_buildsystem_prepend and mentioned all variables with values >> defined in your class/recipe. > > Why do you have to set this in a copy_buildsystem_prepend ? Shouldn't > setting the variable in your distro config or class or somewhere else > work? > >> 3. sdk_extraconf = "# My notes about local.conf" >> - Yes, you can write some string into local.conf with this way. > > I suspect you can also do: > > sdk_extraconf () { > # My notes about local.conf > aaa = "valueA" > bbb = "valueB" > } > > or something like that, I admit I've not tested it though. > >> So I have founded an way, how to add multiple variables without >> explicitly specifying their values. >> >> # format variables for sdk_extraconf >> def write_sdk_vars(d): >> return '\n' + '\n'.join([var + ' = "' + d.getVar(var) + '"' for var >> in >> d.getVar('SDK_EXTRACONF_VARS').split()]) >> >> SDK_EXTRACONF_VARS = "aaa bbb" >> sdk_extraconf_append = " ${@write_sdk_vars(d)}" >> >> It will do exactly what I want, but this way is little bit nasty. So >> I have created a more complex solution for community usage. >> I think, this patch adds more functionality also for other projects. >> They can add only variables into list and the class will handle all >> the >> rest. > > I do see the problem with expansion. I suspect the code in > populate_sdk_ext should be: > > extraconf = (d.getVar('sdk_extraconf', False) or '').strip() > instead of: > extraconf = (d.getVar('sdk_extraconf') or '').strip() > > so that variables can be used as part of the expressions. It may be our > change to the defaults for getVar messed this up, or it may be we just > didn't correctly predict this problem. > >> Is it enough for the explanation? > > It helps, yes, thanks. What I don't want to do is add multiple > confusing mechanisms which do approximately the same thing slightly > differently. I'd much prefer one mechanism most people can use. > > As such the original proposal still concerns me. I'd prefer to tweak > one of the existing ones (even merge them!) rather than add a third > slightly different one. > > I do also still think some (but not all) of what you're describing > should be in your distro/classes rather than local.conf. > > Is there a way we can improve the current code rather than adding more > options. Would the expansion change be enough? > > Cheers, > > Richard > > From domarys.correa at ossystems.com.br Tue Mar 17 12:44:54 2020 From: domarys.correa at ossystems.com.br (Domarys Correa) Date: Tue, 17 Mar 2020 09:44:54 -0300 Subject: [OE-core] [PATCH] cmake: Update 3.16.1 -> 3.16.5 Message-ID: <20200317124454.12732-1-domarys.correa@ossystems.com.br> Signed-off-by: Domarys Correa --- .../cmake/{cmake-native_3.16.1.bb => cmake-native_3.16.5.bb} | 0 meta/recipes-devtools/cmake/cmake.inc | 4 ++-- .../cmake/{cmake_3.16.1.bb => cmake_3.16.5.bb} | 0 3 files changed, 2 insertions(+), 2 deletions(-) rename meta/recipes-devtools/cmake/{cmake-native_3.16.1.bb => cmake-native_3.16.5.bb} (100%) rename meta/recipes-devtools/cmake/{cmake_3.16.1.bb => cmake_3.16.5.bb} (100%) diff --git a/meta/recipes-devtools/cmake/cmake-native_3.16.1.bb b/meta/recipes-devtools/cmake/cmake-native_3.16.5.bb similarity index 100% rename from meta/recipes-devtools/cmake/cmake-native_3.16.1.bb rename to meta/recipes-devtools/cmake/cmake-native_3.16.5.bb diff --git a/meta/recipes-devtools/cmake/cmake.inc b/meta/recipes-devtools/cmake/cmake.inc index 9d14c14b54..09949b566c 100644 --- a/meta/recipes-devtools/cmake/cmake.inc +++ b/meta/recipes-devtools/cmake/cmake.inc @@ -22,7 +22,7 @@ SRC_URI = "https://cmake.org/files/v${CMAKE_MAJOR_VERSION}/cmake-${PV}.tar.gz \ file://0004-Fail-silently-if-system-Qt-installation-is-broken.patch \ " -SRC_URI[md5sum] = "142cf11cd9a7c298cf875604cee96434" -SRC_URI[sha256sum] = "a275b3168fa8626eca4465da7bb159ff07c8c6cb0fb7179be59e12cbdfa725fd" +SRC_URI[md5sum] = "d86ccaf3d2462b6b5947919abe5b9f15" +SRC_URI[sha256sum] = "5f760b50b8ecc9c0c37135fae5fbf00a2fef617059aa9d61c1bb91653e5a8bfc" UPSTREAM_CHECK_REGEX = "cmake-(?P\d+(\.\d+)+)\.tar" diff --git a/meta/recipes-devtools/cmake/cmake_3.16.1.bb b/meta/recipes-devtools/cmake/cmake_3.16.5.bb similarity index 100% rename from meta/recipes-devtools/cmake/cmake_3.16.1.bb rename to meta/recipes-devtools/cmake/cmake_3.16.5.bb -- 2.17.1 From otavio.salvador at ossystems.com.br Tue Mar 17 12:49:35 2020 From: otavio.salvador at ossystems.com.br (Otavio Salvador) Date: Tue, 17 Mar 2020 09:49:35 -0300 Subject: [OE-core] [PATCH] cmake: Update 3.16.1 -> 3.16.5 In-Reply-To: <20200317124454.12732-1-domarys.correa@ossystems.com.br> References: <20200317124454.12732-1-domarys.correa@ossystems.com.br> Message-ID: On Tue, Mar 17, 2020 at 9:45 AM Domarys Correa wrote: > > Signed-off-by: Domarys Correa Acked-by: Otavio Salvador -- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 From brgl at bgdev.pl Tue Mar 17 13:26:37 2020 From: brgl at bgdev.pl (Bartosz Golaszewski) Date: Tue, 17 Mar 2020 14:26:37 +0100 Subject: [OE-core] Solving a circular dependency issue between the main image and initramfs In-Reply-To: References: Message-ID: pon., 16 mar 2020 o 12:01 Richard Purdie napisa?(a): > > On Mon, 2020-03-16 at 11:48 +0100, Bartosz Golaszewski wrote: > > There has been no relevant feedback, but I've been experimenting with > > various things. I think that the best approach would be to make image > > artifacts installable into dependant recipes' sysroots (in > > /usr/share/images/). This way the initramfs recipe could calculate > > the > > dm-verity hashes from the resulting ext4 image before it gets > > deployed. We could also modify the kernel recipe to not fetch the > > initramfs image from the shared directory but instead have it > > installed in its sysroot. > > > > For this I tried to re-enable the do_install task in image.bbclass. > > Unfortunately either I'm doing something wrong or standard tasks are > > subject to different rules when it comes to dependencies. I've been > > so > > far unable to make do_install depend on any image tasks (i.e. make > > do_install depend on do_image_ext4/wic etc.) no matter if I use > > do_install[depends] or addtask or appropriate helpers from python. > > Unfortunately I've been unable to find any information on that in the > > manual. > > > > Is there some trick to changing the dependencies of standard tasks? > > I don't know how exactly you're configuring the system but it should be > possible to have the main rootfs built first, adding in the signing, > then have the initramfs depend on that. > I too thought this should be possible with current implementation and yet I've spent so many hours on this to no avail it's not funny. :( > I can understand some circular dependencies could creep in as many > configurations have the initramfs as part of the main image but if you > don't configure that, you shouldn't see those dependencies. > I think there are more problems with this and the main reason is the fact that wic is just a regular image type. I'd argue it should be its own recipe since it can fetch deployed files from multiple recipes (including different images - for instance if we wanted to build a special recovery image that would need to include the main image + minimal rootfs). First: the initramfs recipe needs to access an artifact generated by do_image_ext4 from the main image. If we're not running do_install from image.bbclass (which we currently don't), this can only happen after do_image_complete which does the sstate deployment. So initramfs.do_image_ext4 depends on rootfs.do_image_complete. Next the kernel bbclass needs the initramfs image to assemble the fitimage - so kernel.do_assemble_fitimage_initramfs depends on initramfs.do_image_complete. Next we have the inter-dependencies between the kernel and u-boot because we need to sign the fitImage for dm-verity to make sense. Currently u-boot.do_build depends on kernel.do_deploy. And then the culprit: rootfs.do_image_wic needs to fetch the boot files so it depends on u-boot.do_deploy but rootfs.do_image_complete runs after rootfs.do_image_wic. I guess if we made wic a separate recipe - not just an image type, it could help here. > I do fear your "re-enable" do_install route isn't going to get you > where you want to be. > Why not? This is what currently happens with the dependencies between fitimage <-> u-boot when UBOOT_SIGN_ENABLE is set to "1". U-boot installs the DTB image - that would normally be deployed - into the /usr/share directory of kernel's sysroot. > Can you give a simple example of how you reproduce the circular > dependencies with standard poky or oe-core? That might let others give > comment more easily. > It's very simple: add an initramfs to the recipe (INITRAMFS_IMAGE = "some-image") and add the following to some-image.bb recipe: do_rootfs[depends] += "core-image-minimal:do_image_complete" with the assumption that you're building core-image-minimal. You also need "wic" in IMAGE_FSTYPES. Best regards, Bartosz Golaszewski From quentin.schulz at streamunlimited.com Tue Mar 17 13:45:36 2020 From: quentin.schulz at streamunlimited.com (Quentin Schulz) Date: Tue, 17 Mar 2020 14:45:36 +0100 Subject: [OE-core] Solving a circular dependency issue between the main image and initramfs In-Reply-To: References: Message-ID: <20200317134535.kle77hptmqsj5yf5@qschulz> Hi Bartosz, On Tue, Mar 17, 2020 at 02:26:37PM +0100, Bartosz Golaszewski wrote: > pon., 16 mar 2020 o 12:01 Richard Purdie > napisa?(a): > > > > On Mon, 2020-03-16 at 11:48 +0100, Bartosz Golaszewski wrote: > > > There has been no relevant feedback, but I've been experimenting with > > > various things. I think that the best approach would be to make image > > > artifacts installable into dependant recipes' sysroots (in > > > /usr/share/images/). This way the initramfs recipe could calculate > > > the > > > dm-verity hashes from the resulting ext4 image before it gets > > > deployed. We could also modify the kernel recipe to not fetch the > > > initramfs image from the shared directory but instead have it > > > installed in its sysroot. > > > > > > For this I tried to re-enable the do_install task in image.bbclass. > > > Unfortunately either I'm doing something wrong or standard tasks are > > > subject to different rules when it comes to dependencies. I've been > > > so > > > far unable to make do_install depend on any image tasks (i.e. make > > > do_install depend on do_image_ext4/wic etc.) no matter if I use > > > do_install[depends] or addtask or appropriate helpers from python. > > > Unfortunately I've been unable to find any information on that in the > > > manual. > > > > > > Is there some trick to changing the dependencies of standard tasks? > > > > I don't know how exactly you're configuring the system but it should be > > possible to have the main rootfs built first, adding in the signing, > > then have the initramfs depend on that. > > > > I too thought this should be possible with current implementation and > yet I've spent so many hours on this to no avail it's not funny. :( > I haven't read carefully your thread but ran into what seems to be a similar situation two years ago: https://youtu.be/jtLQ8SzfrDU?t=2336 So, TL;DR, couldn't create a fitimage with kernel-fitimage because of circular dependencies and we had to create a new fitimage bbclass which wasn't inherited in the kernel but by the image recipe IIRC. I didn't think at that time kernel-fitimage made sense because you can technically put whatever you want in a fitimage. I can technically not have a kernel in it. I thought a fitimage bbclass inherited by an image recipe made much more sense. It was two years ago, didn't share anything with the YP folks back then, so my bad. I haven't had this issue since then (no product requiring this) so didn't think much more about it :/ I promised once we had something good enough we would give back to the community. Now that I've left that company and forgot to do it, you can throw rocks at me. Good luck and keep us posted please. Quentin From brgl at bgdev.pl Tue Mar 17 14:05:15 2020 From: brgl at bgdev.pl (Bartosz Golaszewski) Date: Tue, 17 Mar 2020 15:05:15 +0100 Subject: [OE-core] Solving a circular dependency issue between the main image and initramfs In-Reply-To: References: Message-ID: pon., 16 mar 2020 o 15:03 Ernst Sj?strand napisa?(a): > > Hi! > > I have done something very similar, here's what I did. > > My ramdisk is just a vanilla cpio. > My kernel is just vanilla zImage. > > My main image does "inherit magic" and magic.bbclass does something like this, where create_custom_fitimage has a lot of kernel-fitimage.bbclass copied out. > do_magic () { > create_custom_fitimage > install fitImage.bin ${IMAGE_ROOTFS}/boot/fitImage > } > do_magic[depends] += "my-ramdisk:do_image_complete virtual/kernel" > addtask magic before do_image after do_pre_image_task > > It does read a lot of stuff from deploy but so does the main kernel-fitimage.bbclass so I don't think that's a problem. > > Regards > //Ernst > There are probably many workarounds for this, but if we can't do this with upstream OE-core then something is broken/missing upstream and we should fix it. This is what I'm trying to do. I'm just looking for the right way. I don't want to carry some non-upstreamable workaround over to every other project I'm working on - optimally this should be made part of OE-core/meta-security. Best regards, Bartosz Golaszewski From brgl at bgdev.pl Tue Mar 17 14:12:24 2020 From: brgl at bgdev.pl (Bartosz Golaszewski) Date: Tue, 17 Mar 2020 15:12:24 +0100 Subject: [OE-core] Solving a circular dependency issue between the main image and initramfs In-Reply-To: <20200317134535.kle77hptmqsj5yf5@qschulz> References: <20200317134535.kle77hptmqsj5yf5@qschulz> Message-ID: wt., 17 mar 2020 o 14:45 Quentin Schulz napisa?(a): > > Hi Bartosz, > > On Tue, Mar 17, 2020 at 02:26:37PM +0100, Bartosz Golaszewski wrote: > > pon., 16 mar 2020 o 12:01 Richard Purdie > > napisa?(a): > > > > > > On Mon, 2020-03-16 at 11:48 +0100, Bartosz Golaszewski wrote: > > > > There has been no relevant feedback, but I've been experimenting with > > > > various things. I think that the best approach would be to make image > > > > artifacts installable into dependant recipes' sysroots (in > > > > /usr/share/images/). This way the initramfs recipe could calculate > > > > the > > > > dm-verity hashes from the resulting ext4 image before it gets > > > > deployed. We could also modify the kernel recipe to not fetch the > > > > initramfs image from the shared directory but instead have it > > > > installed in its sysroot. > > > > > > > > For this I tried to re-enable the do_install task in image.bbclass. > > > > Unfortunately either I'm doing something wrong or standard tasks are > > > > subject to different rules when it comes to dependencies. I've been > > > > so > > > > far unable to make do_install depend on any image tasks (i.e. make > > > > do_install depend on do_image_ext4/wic etc.) no matter if I use > > > > do_install[depends] or addtask or appropriate helpers from python. > > > > Unfortunately I've been unable to find any information on that in the > > > > manual. > > > > > > > > Is there some trick to changing the dependencies of standard tasks? > > > > > > I don't know how exactly you're configuring the system but it should be > > > possible to have the main rootfs built first, adding in the signing, > > > then have the initramfs depend on that. > > > > > > > I too thought this should be possible with current implementation and > > yet I've spent so many hours on this to no avail it's not funny. :( > > > > I haven't read carefully your thread but ran into what seems to be a > similar situation two years ago: > > https://youtu.be/jtLQ8SzfrDU?t=2336 > > So, TL;DR, couldn't create a fitimage with kernel-fitimage because of > circular dependencies and we had to create a new fitimage bbclass which > wasn't inherited in the kernel but by the image recipe IIRC. > > I didn't think at that time kernel-fitimage made sense because you can > technically put whatever you want in a fitimage. I can technically not > have a kernel in it. I thought a fitimage bbclass inherited by an image > recipe made much more sense. It was two years ago, didn't share anything > with the YP folks back then, so my bad. I haven't had this issue since > then (no product requiring this) so didn't think much more about it :/ > > I promised once we had something good enough we would give back to the > community. Now that I've left that company and forgot to do it, you can > throw rocks at me. > > Good luck and keep us posted please. > Quentin Thanks Quentin, this is pretty much what Ernst suggested earlier in this thread too. I'm not a fan of this solution. Richard et al: do you think making the fitimage class something an image recipe could inherit is a good idea? So far I think there are three solutions to the problem: 1. Make wic image a separate recipe that could run after everything else is done and deployed. 2. Make image.bbclass install its artifacts into whatever recipe DEPENDS on it. 3. Make fitimage a bbclass that could be added to IMAGE_CLASSES. Bartosz From sjolley.yp.pm at gmail.com Tue Mar 17 15:08:26 2020 From: sjolley.yp.pm at gmail.com (sjolley.yp.pm at gmail.com) Date: Tue, 17 Mar 2020 08:08:26 -0700 Subject: [OE-core] Yocto Project Status WW11'20 Message-ID: <05b801d5fc6d$e93495b0$bb9dc110$@gmail.com> Current Dev Position: YP 3.1 M4 - Stabilization Next Deadline: YP 3.1 M4 build date 3/30/2020 Next Team Meetings: * Bug Triage meeting Thursday Mar. 19th at 7:30am PDT ( https://zoom.us/j/454367603) * Monthly Project Meeting Tuesday Apr. 7th at 8am PDT ( https://zoom.us/j/990892712) * Weekly Engineering Sync Tuesday Mar. 17th at 8am PDT ( https://zoom.us/j/990892712) * Twitch - See http://www.twitch.tv/letoatreidesthe2nd Key Status/Updates: * M3 has now been built and is in QA. We are therefore feature frozen. * YP 3.1 has been announced as an LTS release: https://www.yoctoproject.org/yocto-project-long-term-support-announced/ * There were logging changes merged to better handle hashequiv and usability concerns, thanks Joshua * We have seen a welcome rise in green builds recently although several key intermittent failures have not been addressed. It is crucial for an LTS release we do resolve these. * Recipe upgrades are now unlikely to be merged into 3.1 as we focus on stabilizing and bug fixing for the final release YP 3.1 Milestone Dates: * YP 3.1 M3 is in QA * YP 3.1 M3 release date 3/6/2020 * YP 3.1 M4 build date 3/30/2020 * YP 3.1 M4 release date 4/24/2020 Planned upcoming dot releases: * YP 3.0.3 build date 5/4/2020 * YP 3.0.3 release date 5/15/2020 * YP 2.7.4 build date 5/18/2020 * YP 2.7.4 release date 5/29/2020 Tracking Metrics: * WDD 2698 (last week 2703) ( https://wiki.yoctoproject.org/charts/combo.html) * Poky Patch Metrics * Total patches found: 1351 (last week 1354) * Patches in the Pending State: 534 (40%) [last week 541 (40%)] The Yocto Project's technical governance is through its Technical Steering Committee, more information is available at: https://wiki.yoctoproject.org/wiki/TSC 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 * Cell: (208) 244-4460 * Email: sjolley.yp.pm at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.freihofer at gmail.com Tue Mar 17 15:26:49 2020 From: adrian.freihofer at gmail.com (Adrian Freihofer) Date: Tue, 17 Mar 2020 16:26:49 +0100 Subject: [OE-core] [PATCH v4 0/1] runqemu: support multiple NICs Message-ID: <20200317152650.2131885-1-adrian.freihofer@gmail.com> It's a re-write in comparison to v3. Two new QB_ parameters are introduced: QB_CMDLINE_IP_SLIRP and QB_CMDLINE_IP_TAP. These parameters are by default the ip= parameters as they were previously hard-coded in runqemu. However, if, for example, more than one network interface is added to QB_NETWORK_DEVICE, the corresponding kernel parameters need to be configured accordingly. Adrian Freihofer (1): runqemu: support multiple NICs meta/classes/qemuboot.bbclass | 14 ++++++++++++++ scripts/runqemu | 16 ++++++++++++---- 2 files changed, 26 insertions(+), 4 deletions(-) -- 2.25.1 From adrian.freihofer at gmail.com Tue Mar 17 15:26:50 2020 From: adrian.freihofer at gmail.com (Adrian Freihofer) Date: Tue, 17 Mar 2020 16:26:50 +0100 Subject: [OE-core] [PATCH v4 1/1] runqemu: support multiple NICs In-Reply-To: <20200317152650.2131885-1-adrian.freihofer@gmail.com> References: <20200317152650.2131885-1-adrian.freihofer@gmail.com> Message-ID: <20200317152650.2131885-2-adrian.freihofer@gmail.com> From: Adrian Freihofer Emulating more than one network interface with runqemu is a bit tricky, but possible. For example, the following leads to an emulated device with eth0 and eth1: QB_NETWORK_DEVICE_prepend = " \ -device virtio-net-device,mac=52:54:00:12:34:03 \ " or QB_NETWORK_DEVICE_append = " \ -device virtio-net-pci,mac=52:54:00:12:34:03 \ " When booting Qemu with two NICs, the kernel does not know which interface the specified ip=192.168.7.... command line argument should be applied. This delays the boot process for a very long time and a guest wihtout IP configuration. This add two new configuraton parameters to runqemu: QB_CMDLINE_IP_SLIRP and QB_CMDLINE_IP_TAP to explicitely specify the ip= kernel command line arguments for tap and slirp mode. Note: Simply adding "::eth0" broke some builds on the Yocto autobuilder. Signed-off-by: Adrian Freihofer --- meta/classes/qemuboot.bbclass | 14 ++++++++++++++ scripts/runqemu | 16 ++++++++++++---- 2 files changed, 26 insertions(+), 4 deletions(-) diff --git a/meta/classes/qemuboot.bbclass b/meta/classes/qemuboot.bbclass index 15a9e63f2b..54044c38da 100644 --- a/meta/classes/qemuboot.bbclass +++ b/meta/classes/qemuboot.bbclass @@ -36,6 +36,9 @@ # Note, runqemu will replace @MAC@ with a predefined mac, you can set # a custom one, but that may cause conflicts when multiple qemus are # running on the same host. +# Note: If more than one interface of type -device virtio-net-device gets added, +# QB_NETWORK_DEVICE_prepend might be used, since Qemu enumerates the eth* +# devices in reverse order to -device arguments. # # QB_TAP_OPT: netowrk option for 'tap' mode, e.g., # "-netdev tap,id=net0,ifname=@TAP@,script=no,downscript=no" @@ -43,6 +46,15 @@ # # QB_SLIRP_OPT: network option for SLIRP mode, e.g., -netdev user,id=net0" # +# QB_CMDLINE_IP_SLIRP: If QB_NETWORK_DEVICE adds more than one network interface to qemu, usually the +# ip= kernel comand line argument needs to be changed accordingly. Details are documented +# in the kernel docuemntation https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt +# Example to configure only the first interface: "ip=eth0:dhcp" +# QB_CMDLINE_IP_TAP: This parameter is similar to the QB_CMDLINE_IP_SLIRP parameter. Since the tap interface requires +# static IP configuration @CLIENT@ and @GATEWAY@ place holders are replaced by the IP and the gateway +# address of the qemu guest by runqemu. +# Example: "ip=192.168.7. at CLIENT@::192.168.7. at GATEWAY@:255.255.255.0::eth0" +# # QB_ROOTFS_OPT: used as rootfs, e.g., # "-drive id=disk0,file=@ROOTFS@,if=none,format=raw -device virtio-blk-device,drive=disk0" # Note, runqemu will replace "@ROOTFS@" with the one which is used, such as core-image-minimal-qemuarm64.ext4. @@ -63,6 +75,8 @@ QB_DEFAULT_KERNEL ?= "${KERNEL_IMAGETYPE}" QB_DEFAULT_FSTYPE ?= "ext4" QB_OPT_APPEND ?= "-show-cursor" QB_NETWORK_DEVICE ?= "-device virtio-net-pci,netdev=net0,mac=@MAC@" +QB_CMDLINE_IP_SLIRP ?= "ip=dhcp" +QB_CMDLINE_IP_TAP ?= "ip=192.168.7. at CLIENT@::192.168.7. at GATEWAY@:255.255.255.0" # This should be kept align with ROOT_VM QB_DRIVE_TYPE ?= "/dev/sd" diff --git a/scripts/runqemu b/scripts/runqemu index dd0aa4b28f..6f24093d77 100755 --- a/scripts/runqemu +++ b/scripts/runqemu @@ -185,6 +185,8 @@ class BaseConfig(object): self.vmtypes = ('hddimg', 'iso') self.fsinfo = {} self.network_device = "-device e1000,netdev=net0,mac=@MAC@" + self.cmdline_ip_slirp = "ip=dhcp" + self.cmdline_ip_tap = "ip=192.168.7. at CLIENT@::192.168.7. at GATEWAY@:255.255.255.0" # Use different mac section for tap and slirp to avoid # conflicts, e.g., when one is running with tap, the other is # running with slirp. @@ -1032,7 +1034,9 @@ class BaseConfig(object): if self.fstype == 'nfs': self.setup_nfs() - self.kernel_cmdline_script += ' ip=dhcp' + netconf = " " + self.cmdline_ip_slirp + logger.info("Network configuration:%s", netconf) + self.kernel_cmdline_script += netconf # Port mapping hostfwd = ",hostfwd=tcp::2222-:22,hostfwd=tcp::2323-:23" qb_slirp_opt_default = "-netdev user,id=net0%s,tftp=%s" % (hostfwd, self.get('DEPLOY_DIR_IMAGE')) @@ -1147,9 +1151,11 @@ class BaseConfig(object): client = gateway + 1 if self.fstype == 'nfs': self.setup_nfs() - netconf = "192.168.7.%s::192.168.7.%s:255.255.255.0" % (client, gateway) - logger.info("Network configuration: %s", netconf) - self.kernel_cmdline_script += " ip=%s" % netconf + netconf = " " + self.cmdline_ip_tap + netconf = netconf.replace('@CLIENT@', str(client)) + netconf = netconf.replace('@GATEWAY@', str(gateway)) + logger.info("Network configuration:%s", netconf) + self.kernel_cmdline_script += netconf mac = "%s%02x" % (self.mac_tap, client) qb_tap_opt = self.get('QB_TAP_OPT') if qb_tap_opt: @@ -1171,8 +1177,10 @@ class BaseConfig(object): if self.net_bridge: self.setup_net_bridge() elif self.slirp_enabled: + self.cmdline_ip_slirp = self.get('QB_CMDLINE_IP_SLIRP') or self.cmdline_ip_slirp self.setup_slirp() else: + self.cmdline_ip_tap = self.get('QB_CMDLINE_IP_TAP') or self.cmdline_ip_tap self.setup_tap() def setup_rootfs(self): -- 2.25.1 From alex.kiernan at gmail.com Tue Mar 17 15:22:52 2020 From: alex.kiernan at gmail.com (Alex Kiernan) Date: Tue, 17 Mar 2020 15:22:52 +0000 Subject: [OE-core] [OE-Core][RFC PATCH 00/11] Systemd 245 and related updates Message-ID: <20200317152303.4600-1-alex.kiernan@gmail.com> Throwing these out there, so that anyone else who's looking at systemd 245 doesn't have to repeat the work, equally now is clearly not the time to be applying these to master! Not all of these are stricly related to systemd 245. Alex Kiernan (11): systemd: Package udev rules explicitly systemd: Reinstate systemd-hwdb-update.service systemd: Add sch-fq-codel to RRECOMMENDS systemd: Add PACKAGECONFIG for sysvinit systemd: Remove X11 related files when disabled psplash: Set RemainAfterExit on systemd units oeqa/runtime/cases: Disable and stop systemd-timesyncd systemd: upgrade v244.3 -> v245 systemd: Enable smack based on DISTRO_FEATURES systemd: Enable audit based on DISTRO_FEATURES systemd: Enable acl based on DISTRO_FEATURES meta/lib/oeqa/runtime/cases/date.py | 4 +- .../psplash/files/psplash-start.service | 1 + .../psplash/files/psplash-systemd.service | 2 +- ...temd-boot_244.3.bb => systemd-boot_245.bb} | 0 ...temd-conf_244.3.bb => systemd-conf_245.bb} | 0 meta/recipes-core/systemd/systemd.inc | 4 +- .../systemd/0001-Handle-missing-gshadow.patch | 171 ++++++++++++++++++ ...tall-dependency-links-at-install-tim.patch | 14 +- ...-not-disable-buffer-in-writing-files.patch | 46 ++--- ...002-don-t-use-glibc-specific-qsort_r.patch | 12 +- ...k-parse_printf_format-implementation.patch | 10 +- ...set-util.h-add-__cpu_mask-definition.patch | 8 +- ...missing.h-check-for-missing-strndupa.patch | 93 ++++++---- .../0006-Include-netinet-if_ether.h.patch | 41 +++-- ..._register_atfork-for-non-glibc-build.patch | 6 +- ...11-Use-uintmax_t-for-handling-rlim_t.patch | 10 +- ...sable-tests-for-missing-typedefs-in-.patch | 8 +- ...uffering-when-writing-to-oom_score_a.patch | 8 +- .../{systemd_244.3.bb => systemd_245.bb} | 67 +++++-- scripts/postinst-intercepts/update_udev_hwdb | 16 +- 20 files changed, 376 insertions(+), 145 deletions(-) rename meta/recipes-core/systemd/{systemd-boot_244.3.bb => systemd-boot_245.bb} (100%) rename meta/recipes-core/systemd/{systemd-conf_244.3.bb => systemd-conf_245.bb} (100%) create mode 100644 meta/recipes-core/systemd/systemd/0001-Handle-missing-gshadow.patch rename meta/recipes-core/systemd/{systemd_244.3.bb => systemd_245.bb} (91%) -- 2.17.1 From alex.kiernan at gmail.com Tue Mar 17 15:22:53 2020 From: alex.kiernan at gmail.com (Alex Kiernan) Date: Tue, 17 Mar 2020 15:22:53 +0000 Subject: [OE-core] [OE-Core][RFC PATCH 01/11] systemd: Package udev rules explicitly In-Reply-To: <20200317152303.4600-1-alex.kiernan@gmail.com> References: <20200317152303.4600-1-alex.kiernan@gmail.com> Message-ID: <20200317152303.4600-2-alex.kiernan@gmail.com> udev is packaged before systemd so any wildcard inclusions in FILES will override later specifics. List all udev rules explicitly so that the systemd specific rules, packaged alongside systemd, appear in the correct package. Signed-off-by: Alex Kiernan --- meta/recipes-core/systemd/systemd_244.3.bb | 28 +++++++++++++++++++++- 1 file changed, 27 insertions(+), 1 deletion(-) diff --git a/meta/recipes-core/systemd/systemd_244.3.bb b/meta/recipes-core/systemd/systemd_244.3.bb index c5c0ce4bad05..bb799831996c 100644 --- a/meta/recipes-core/systemd/systemd_244.3.bb +++ b/meta/recipes-core/systemd/systemd_244.3.bb @@ -599,7 +599,33 @@ FILES_udev += "${base_sbindir}/udevd \ ${rootlibexecdir}/udev/scsi_id \ ${rootlibexecdir}/udev/v4l_id \ ${rootlibexecdir}/udev/keymaps \ - ${rootlibexecdir}/udev/rules.d/*.rules \ + ${rootlibexecdir}/udev/rules.d/50-udev-default.rules \ + ${rootlibexecdir}/udev/rules.d/60-autosuspend-chromiumos.rules \ + ${rootlibexecdir}/udev/rules.d/60-block.rules \ + ${rootlibexecdir}/udev/rules.d/60-cdrom_id.rules \ + ${rootlibexecdir}/udev/rules.d/60-drm.rules \ + ${rootlibexecdir}/udev/rules.d/60-evdev.rules \ + ${rootlibexecdir}/udev/rules.d/60-fido-id.rules \ + ${rootlibexecdir}/udev/rules.d/60-input-id.rules \ + ${rootlibexecdir}/udev/rules.d/60-persistent-alsa.rules \ + ${rootlibexecdir}/udev/rules.d/60-persistent-input.rules \ + ${rootlibexecdir}/udev/rules.d/60-persistent-storage.rules \ + ${rootlibexecdir}/udev/rules.d/60-persistent-storage-tape.rules \ + ${rootlibexecdir}/udev/rules.d/60-persistent-v4l.rules \ + ${rootlibexecdir}/udev/rules.d/60-sensor.rules \ + ${rootlibexecdir}/udev/rules.d/60-serial.rules \ + ${rootlibexecdir}/udev/rules.d/61-autosuspend-manual.rules \ + ${rootlibexecdir}/udev/rules.d/64-btrfs.rules \ + ${rootlibexecdir}/udev/rules.d/70-joystick.rules \ + ${rootlibexecdir}/udev/rules.d/70-mouse.rules \ + ${rootlibexecdir}/udev/rules.d/70-power-switch.rules \ + ${rootlibexecdir}/udev/rules.d/70-touchpad.rules \ + ${rootlibexecdir}/udev/rules.d/75-net-description.rules \ + ${rootlibexecdir}/udev/rules.d/75-probe_mtd.rules \ + ${rootlibexecdir}/udev/rules.d/78-sound-card.rules \ + ${rootlibexecdir}/udev/rules.d/80-drivers.rules \ + ${rootlibexecdir}/udev/rules.d/80-net-setup-link.rules \ + ${rootlibexecdir}/udev/rules.d/90-vconsole.rules \ ${sysconfdir}/udev \ ${sysconfdir}/init.d/systemd-udevd \ ${systemd_unitdir}/system/*udev* \ -- 2.17.1 From alex.kiernan at gmail.com Tue Mar 17 15:22:54 2020 From: alex.kiernan at gmail.com (Alex Kiernan) Date: Tue, 17 Mar 2020 15:22:54 +0000 Subject: [OE-core] [OE-Core][RFC PATCH 02/11] systemd: Reinstate systemd-hwdb-update.service In-Reply-To: <20200317152303.4600-1-alex.kiernan@gmail.com> References: <20200317152303.4600-1-alex.kiernan@gmail.com> Message-ID: <20200317152303.4600-3-alex.kiernan@gmail.com> systemd supports a distribution hwdb.bin in /usr/lib/udev/hwdb.bin, which is used if /etc/udev/hwdb.bin is not present. When generating the install time hwdb, for systemd, ensure that we put it in /usr/lib/udev, which then ensures that at boot time we do not regenerate it, unless the system is marked for update. This allows fragments dropped into /etc/udev/hwdb.d to be processed correctly, but without requiring a first boot time build: root at qemumips:~# systemctl status systemd-hwdb-update.service * systemd-hwdb-update.service - Rebuild Hardware Database Loaded: loaded (/usr/lib/systemd/system/systemd-hwdb-update.service; static; vendor preset: disabled) Active: inactive (dead) Condition: start condition failed at Wed 2020-03-04 15:18:11 UTC; 44s ago |- ConditionPathExists=|!/usr/lib/udev/hwdb.bin was not met |- ConditionPathExists=|/etc/udev/hwdb.bin was not met `- ConditionDirectoryNotEmpty=|/etc/udev/hwdb.d was not met Docs: man:hwdb(7) man:systemd-hwdb(8) Signed-off-by: Alex Kiernan --- meta/recipes-core/systemd/systemd_244.3.bb | 10 ++++------ scripts/postinst-intercepts/update_udev_hwdb | 16 ++++++++++++++-- 2 files changed, 18 insertions(+), 8 deletions(-) diff --git a/meta/recipes-core/systemd/systemd_244.3.bb b/meta/recipes-core/systemd/systemd_244.3.bb index bb799831996c..048021000448 100644 --- a/meta/recipes-core/systemd/systemd_244.3.bb +++ b/meta/recipes-core/systemd/systemd_244.3.bb @@ -293,10 +293,6 @@ do_install() { # install default policy for presets # https://www.freedesktop.org/wiki/Software/systemd/Preset/#howto install -Dm 0644 ${WORKDIR}/99-default.preset ${D}${systemd_unitdir}/system-preset/99-default.preset - - # We use package postinsts for the hwdb update, as the update service is - # easily triggered for no reason and will slow down boots. - find ${D} -name systemd-hwdb-update.service -delete } python populate_packages_prepend (){ @@ -636,7 +632,9 @@ FILES_udev += "${base_sbindir}/udevd \ ${datadir}/bash-completion/completions/udevadm \ " -FILES_udev-hwdb = "${rootlibexecdir}/udev/hwdb.d" +FILES_udev-hwdb = "${rootlibexecdir}/udev/hwdb.d \ + ${systemd_unitdir}/system/systemd-hwdb-update.service \ + " RCONFLICTS_${PN} = "tiny-init ${@bb.utils.contains('PACKAGECONFIG', 'resolved', 'resolvconf', '', d)}" @@ -696,7 +694,7 @@ pkg_prerm_${PN}_libc-glibc () { PACKAGE_WRITE_DEPS += "qemu-native" pkg_postinst_udev-hwdb () { if test -n "$D"; then - $INTERCEPT_DIR/postinst_intercept update_udev_hwdb ${PKG} mlprefix=${MLPREFIX} binprefix=${MLPREFIX} + $INTERCEPT_DIR/postinst_intercept update_udev_hwdb ${PKG} mlprefix=${MLPREFIX} binprefix=${MLPREFIX} rootlibexecdir="${rootlibexecdir}" PREFERRED_PROVIDER_udev="${PREFERRED_PROVIDER_udev}" else udevadm hwdb --update fi diff --git a/scripts/postinst-intercepts/update_udev_hwdb b/scripts/postinst-intercepts/update_udev_hwdb index c4fb2bffcbf0..102e99b94725 100644 --- a/scripts/postinst-intercepts/update_udev_hwdb +++ b/scripts/postinst-intercepts/update_udev_hwdb @@ -5,5 +5,17 @@ set -e -PSEUDO_UNLOAD=1 ${binprefix}qemuwrapper -L $D $D${libexecdir}/${binprefix}udevadm hwdb --update --root $D -chown root:root $D${sysconfdir}/udev/hwdb.bin +case "${PREFERRED_PROVIDER_udev}" in + systemd) + UDEV_EXTRA_ARGS="--usr" + UDEVLIBDIR="${rootlibexecdir}" + ;; + + *) + UDEV_EXTRA_ARGS="" + UDEVLIBDIR="${sysconfdir}" + ;; +esac + +PSEUDO_UNLOAD=1 ${binprefix}qemuwrapper -L $D $D${libexecdir}/${binprefix}udevadm hwdb --update --root $D ${UDEV_EXTRA_ARGS} +chown root:root $D${UDEVLIBDIR}/udev/hwdb.bin -- 2.17.1 From alex.kiernan at gmail.com Tue Mar 17 15:22:55 2020 From: alex.kiernan at gmail.com (Alex Kiernan) Date: Tue, 17 Mar 2020 15:22:55 +0000 Subject: [OE-core] [OE-Core][RFC PATCH 03/11] systemd: Add sch-fq-codel to RRECOMMENDS In-Reply-To: <20200317152303.4600-1-alex.kiernan@gmail.com> References: <20200317152303.4600-1-alex.kiernan@gmail.com> Message-ID: <20200317152303.4600-4-alex.kiernan@gmail.com> systemd sets net.core.default_qdisc = fq_codel, include kernel-module-sch-fq-codel in RRECOMMENDS to satify this Signed-off-by: Alex Kiernan --- meta/recipes-core/systemd/systemd_244.3.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-core/systemd/systemd_244.3.bb b/meta/recipes-core/systemd/systemd_244.3.bb index 048021000448..b26f3cb72d2b 100644 --- a/meta/recipes-core/systemd/systemd_244.3.bb +++ b/meta/recipes-core/systemd/systemd_244.3.bb @@ -565,7 +565,7 @@ RDEPENDS_${PN} += "volatile-binds update-rc.d" RRECOMMENDS_${PN} += "systemd-extra-utils \ systemd-compat-units udev-hwdb \ e2fsprogs-e2fsck \ - kernel-module-autofs4 kernel-module-unix kernel-module-ipv6 \ + kernel-module-autofs4 kernel-module-unix kernel-module-ipv6 kernel-module-sch-fq-codel \ os-release \ systemd-conf \ " -- 2.17.1 From alex.kiernan at gmail.com Tue Mar 17 15:22:56 2020 From: alex.kiernan at gmail.com (Alex Kiernan) Date: Tue, 17 Mar 2020 15:22:56 +0000 Subject: [OE-core] [OE-Core][RFC PATCH 04/11] systemd: Add PACKAGECONFIG for sysvinit In-Reply-To: <20200317152303.4600-1-alex.kiernan@gmail.com> References: <20200317152303.4600-1-alex.kiernan@gmail.com> Message-ID: <20200317152303.4600-5-alex.kiernan@gmail.com> Add sysvinit PACKAGECONFIG which is bound to DISTRO_FEATURES, this then disables all sysvinit handling in systemd if it isn't present. Consolidate sysvinit handling so that when it's disabled we exclude all sysvinit features. Signed-off-by: Alex Kiernan --- meta/recipes-core/systemd/systemd_244.3.bb | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/meta/recipes-core/systemd/systemd_244.3.bb b/meta/recipes-core/systemd/systemd_244.3.bb index b26f3cb72d2b..7c33bde21a39 100644 --- a/meta/recipes-core/systemd/systemd_244.3.bb +++ b/meta/recipes-core/systemd/systemd_244.3.bb @@ -56,7 +56,7 @@ PAM_PLUGINS = " \ " PACKAGECONFIG ??= " \ - ${@bb.utils.filter('DISTRO_FEATURES', 'efi ldconfig pam selinux usrmerge polkit', d)} \ + ${@bb.utils.filter('DISTRO_FEATURES', 'efi ldconfig pam selinux sysvinit usrmerge polkit', d)} \ ${@bb.utils.contains('DISTRO_FEATURES', 'wifi', 'rfkill', '', d)} \ ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'xkbcommon', '', d)} \ acl \ @@ -165,6 +165,7 @@ PACKAGECONFIG[seccomp] = "-Dseccomp=true,-Dseccomp=false,libseccomp" PACKAGECONFIG[selinux] = "-Dselinux=true,-Dselinux=false,libselinux,initscripts-sushell" PACKAGECONFIG[smack] = "-Dsmack=true,-Dsmack=false" PACKAGECONFIG[sysusers] = "-Dsysusers=true,-Dsysusers=false" +PACKAGECONFIG[sysvinit] = "-Dsysvinit-path=${sysconfdir}/init.d -Dsysvrcnd-path=${sysconfdir},-Dsysvinit-path= -Dsysvrcnd-path=" # When enabled use reproducble build timestamp if set as time epoch, # or build time if not. When disabled, time epoch is unset. def build_epoch(d): @@ -198,7 +199,6 @@ EXTRA_OEMESON += "-Dnobody-user=nobody \ -Dnobody-group=nobody \ -Drootlibdir=${rootlibdir} \ -Drootprefix=${rootprefix} \ - -Dsysvrcnd-path=${sysconfdir} \ -Ddefault-locale=C \ " @@ -234,6 +234,7 @@ do_install() { install -d ${D}${sysconfdir}/init.d install -m 0755 ${WORKDIR}/init ${D}${sysconfdir}/init.d/systemd-udevd sed -i s%@UDEVD@%${rootlibexecdir}/systemd/systemd-udevd% ${D}${sysconfdir}/init.d/systemd-udevd + install -Dm 0755 ${S}/src/systemctl/systemd-sysv-install.SKELETON ${D}${systemd_unitdir}/systemd-sysv-install fi chown root:systemd-journal ${D}/${localstatedir}/log/journal @@ -273,7 +274,6 @@ do_install() { sed -i -e "s%^L! /etc/resolv.conf.*$%L! /etc/resolv.conf - - - - ../run/systemd/resolve/resolv.conf%g" ${D}${exec_prefix}/lib/tmpfiles.d/etc.conf ln -s ../run/systemd/resolve/resolv.conf ${D}${sysconfdir}/resolv-conf.systemd fi - install -Dm 0755 ${S}/src/systemctl/systemd-sysv-install.SKELETON ${D}${systemd_unitdir}/systemd-sysv-install # If polkit is setup fixup permissions and ownership if ${@bb.utils.contains('PACKAGECONFIG', 'polkit', 'true', 'false', d)}; then @@ -560,7 +560,8 @@ FILES_${PN}-dev += "${base_libdir}/security/*.la ${datadir}/dbus-1/interfaces/ $ RDEPENDS_${PN} += "kmod dbus util-linux-mount util-linux-umount udev (= ${EXTENDPKGV}) util-linux-agetty util-linux-fsck" RDEPENDS_${PN} += "${@bb.utils.contains('PACKAGECONFIG', 'serial-getty-generator', '', 'systemd-serialgetty', d)}" -RDEPENDS_${PN} += "volatile-binds update-rc.d" +RDEPENDS_${PN} += "${@bb.utils.contains('DISTRO_FEATURES', 'sysvinit', 'update-rc.d', '', d)}" +RDEPENDS_${PN} += "volatile-binds" RRECOMMENDS_${PN} += "systemd-extra-utils \ systemd-compat-units udev-hwdb \ -- 2.17.1 From alex.kiernan at gmail.com Tue Mar 17 15:22:57 2020 From: alex.kiernan at gmail.com (Alex Kiernan) Date: Tue, 17 Mar 2020 15:22:57 +0000 Subject: [OE-core] [OE-Core][RFC PATCH 05/11] systemd: Remove X11 related files when disabled In-Reply-To: <20200317152303.4600-1-alex.kiernan@gmail.com> References: <20200317152303.4600-1-alex.kiernan@gmail.com> Message-ID: <20200317152303.4600-6-alex.kiernan@gmail.com> When X11 isn't in DISTRO_FEATURES, remove X11 related files. Signed-off-by: Alex Kiernan --- meta/recipes-core/systemd/systemd_244.3.bb | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/meta/recipes-core/systemd/systemd_244.3.bb b/meta/recipes-core/systemd/systemd_244.3.bb index 7c33bde21a39..279e0857244a 100644 --- a/meta/recipes-core/systemd/systemd_244.3.bb +++ b/meta/recipes-core/systemd/systemd_244.3.bb @@ -274,6 +274,10 @@ do_install() { sed -i -e "s%^L! /etc/resolv.conf.*$%L! /etc/resolv.conf - - - - ../run/systemd/resolve/resolv.conf%g" ${D}${exec_prefix}/lib/tmpfiles.d/etc.conf ln -s ../run/systemd/resolve/resolv.conf ${D}${sysconfdir}/resolv-conf.systemd fi + if ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'false', 'true', d)}; then + rm ${D}${exec_prefix}/lib/tmpfiles.d/x11.conf + rm -r ${D}${sysconfdir}/X11 + fi # If polkit is setup fixup permissions and ownership if ${@bb.utils.contains('PACKAGECONFIG', 'polkit', 'true', 'false', d)}; then -- 2.17.1 From alex.kiernan at gmail.com Tue Mar 17 15:22:58 2020 From: alex.kiernan at gmail.com (Alex Kiernan) Date: Tue, 17 Mar 2020 15:22:58 +0000 Subject: [OE-core] [OE-Core][RFC PATCH 06/11] psplash: Set RemainAfterExit on systemd units In-Reply-To: <20200317152303.4600-1-alex.kiernan@gmail.com> References: <20200317152303.4600-1-alex.kiernan@gmail.com> Message-ID: <20200317152303.4600-7-alex.kiernan@gmail.com> psplash is only expected to run during startup, but if any dependency is pulled into a transaction and the unit is inactive, then it can be restarted. Set RemainAfterExit to ensure that the unit remains active and is not gratuitously restarted. Drop the nonexistent systemd-start.service from the unit. Signed-off-by: Alex Kiernan --- meta/recipes-core/psplash/files/psplash-start.service | 1 + meta/recipes-core/psplash/files/psplash-systemd.service | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/meta/recipes-core/psplash/files/psplash-start.service b/meta/recipes-core/psplash/files/psplash-start.service index a8c97c7a7576..36c2bb38e072 100644 --- a/meta/recipes-core/psplash/files/psplash-start.service +++ b/meta/recipes-core/psplash/files/psplash-start.service @@ -6,6 +6,7 @@ RequiresMountsFor=/run [Service] Type=notify ExecStart=/usr/bin/psplash +RemainAfterExit=yes [Install] WantedBy=sysinit.target diff --git a/meta/recipes-core/psplash/files/psplash-systemd.service b/meta/recipes-core/psplash/files/psplash-systemd.service index 4e18980bb271..082207f2324a 100644 --- a/meta/recipes-core/psplash/files/psplash-systemd.service +++ b/meta/recipes-core/psplash/files/psplash-systemd.service @@ -1,13 +1,13 @@ [Unit] Description=Start psplash-systemd progress communication helper DefaultDependencies=no -After=systemd-start.service After=psplash-start.service Requires=psplash-start.service RequiresMountsFor=/run [Service] ExecStart=/usr/bin/psplash-systemd +RemainAfterExit=yes [Install] WantedBy=sysinit.target -- 2.17.1 From alex.kiernan at gmail.com Tue Mar 17 15:22:59 2020 From: alex.kiernan at gmail.com (Alex Kiernan) Date: Tue, 17 Mar 2020 15:22:59 +0000 Subject: [OE-core] [OE-Core][RFC PATCH 07/11] oeqa/runtime/cases: Disable and stop systemd-timesyncd In-Reply-To: <20200317152303.4600-1-alex.kiernan@gmail.com> References: <20200317152303.4600-1-alex.kiernan@gmail.com> Message-ID: <20200317152303.4600-8-alex.kiernan@gmail.com> Stopping systemd-timesyncd doesn't prevent it being restarted by a different transaction within systemd. Disable the service instead during the date test to ensure it can't be restarted. Signed-off-by: Alex Kiernan --- meta/lib/oeqa/runtime/cases/date.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/lib/oeqa/runtime/cases/date.py b/meta/lib/oeqa/runtime/cases/date.py index 7750a7293f8e..fdd2a6ae587e 100644 --- a/meta/lib/oeqa/runtime/cases/date.py +++ b/meta/lib/oeqa/runtime/cases/date.py @@ -13,12 +13,12 @@ class DateTest(OERuntimeTestCase): def setUp(self): if self.tc.td.get('VIRTUAL-RUNTIME_init_manager') == 'systemd': self.logger.debug('Stopping systemd-timesyncd daemon') - self.target.run('systemctl stop systemd-timesyncd') + self.target.run('systemctl disable --now systemd-timesyncd') def tearDown(self): if self.tc.td.get('VIRTUAL-RUNTIME_init_manager') == 'systemd': self.logger.debug('Starting systemd-timesyncd daemon') - self.target.run('systemctl start systemd-timesyncd') + self.target.run('systemctl enable --now systemd-timesyncd') @OETestDepends(['ssh.SSHTest.test_ssh']) @OEHasPackage(['coreutils', 'busybox']) -- 2.17.1 From alex.kiernan at gmail.com Tue Mar 17 15:23:01 2020 From: alex.kiernan at gmail.com (Alex Kiernan) Date: Tue, 17 Mar 2020 15:23:01 +0000 Subject: [OE-core] [OE-Core][RFC PATCH 09/11] systemd: Enable smack based on DISTRO_FEATURES In-Reply-To: <20200317152303.4600-1-alex.kiernan@gmail.com> References: <20200317152303.4600-1-alex.kiernan@gmail.com> Message-ID: <20200317152303.4600-10-alex.kiernan@gmail.com> Signed-off-by: Alex Kiernan --- meta/recipes-core/systemd/systemd_245.bb | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/meta/recipes-core/systemd/systemd_245.bb b/meta/recipes-core/systemd/systemd_245.bb index 19a8f0cb18af..a7fae930f770 100644 --- a/meta/recipes-core/systemd/systemd_245.bb +++ b/meta/recipes-core/systemd/systemd_245.bb @@ -57,7 +57,7 @@ PAM_PLUGINS = " \ " PACKAGECONFIG ??= " \ - ${@bb.utils.filter('DISTRO_FEATURES', 'efi ldconfig pam selinux sysvinit usrmerge polkit', d)} \ + ${@bb.utils.filter('DISTRO_FEATURES', 'efi ldconfig pam selinux smack sysvinit usrmerge polkit', d)} \ ${@bb.utils.contains('DISTRO_FEATURES', 'wifi', 'rfkill', '', d)} \ ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'xkbcommon', '', d)} \ acl \ @@ -81,7 +81,6 @@ PACKAGECONFIG ??= " \ randomseed \ resolved \ set-time-epoch \ - smack \ sysusers \ timedated \ timesyncd \ @@ -99,7 +98,6 @@ PACKAGECONFIG_remove_libc-musl = " \ nss \ nss-mymachines \ nss-resolve \ - smack \ sysusers \ userdb \ utmp \ -- 2.17.1 From alex.kiernan at gmail.com Tue Mar 17 15:23:02 2020 From: alex.kiernan at gmail.com (Alex Kiernan) Date: Tue, 17 Mar 2020 15:23:02 +0000 Subject: [OE-core] [OE-Core][RFC PATCH 10/11] systemd: Enable audit based on DISTRO_FEATURES In-Reply-To: <20200317152303.4600-1-alex.kiernan@gmail.com> References: <20200317152303.4600-1-alex.kiernan@gmail.com> Message-ID: <20200317152303.4600-11-alex.kiernan@gmail.com> Signed-off-by: Alex Kiernan --- meta/recipes-core/systemd/systemd_245.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-core/systemd/systemd_245.bb b/meta/recipes-core/systemd/systemd_245.bb index a7fae930f770..72021a0991ae 100644 --- a/meta/recipes-core/systemd/systemd_245.bb +++ b/meta/recipes-core/systemd/systemd_245.bb @@ -57,7 +57,7 @@ PAM_PLUGINS = " \ " PACKAGECONFIG ??= " \ - ${@bb.utils.filter('DISTRO_FEATURES', 'efi ldconfig pam selinux smack sysvinit usrmerge polkit', d)} \ + ${@bb.utils.filter('DISTRO_FEATURES', 'audit efi ldconfig pam selinux smack sysvinit usrmerge polkit', d)} \ ${@bb.utils.contains('DISTRO_FEATURES', 'wifi', 'rfkill', '', d)} \ ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'xkbcommon', '', d)} \ acl \ -- 2.17.1 From alex.kiernan at gmail.com Tue Mar 17 15:23:00 2020 From: alex.kiernan at gmail.com (Alex Kiernan) Date: Tue, 17 Mar 2020 15:23:00 +0000 Subject: [OE-core] [OE-Core][RFC PATCH 08/11] systemd: upgrade v244.3 -> v245 In-Reply-To: <20200317152303.4600-1-alex.kiernan@gmail.com> References: <20200317152303.4600-1-alex.kiernan@gmail.com> Message-ID: <20200317152303.4600-9-alex.kiernan@gmail.com> Refresh patches for v245, enable userdb by default. Update musl patches for additional missing stdlib headers. Add musl patch to avoid gshadow. Commits: 03985d069b52 NEWS: final contributor update for v245 0d5aef3eb513 hwdb: update for v245 9cbf1e58f962 units: skip modprobe at .service if the unit appears to be already loaded ff12a7954c19 treewide: more portable bash shebangs eda0cbf07186 Use Finished instead of Started for Type=oneshot services (#14851) d48eea583fd8 units: make systemd-network-generator.service stay around 94c3a838da69 systemctl: make list-dependencies take multiple arguments 82c8bdff122d man: mention networkctl in the networkd man page 4a29c185b7fe man: add systemd-network-generator.service(8) 9fd32ff7d363 units: restore RemainAfterExit=yes in systemd-vconsole-setup.service 44e5d00603a8 pid1: remove unnecessary terminator 5403e153372e man: update list of supported controllers a3558e795203 units: do not ignore return value from systemd --user df883de98a88 pid1, nspawn: voidify loopback_setup() fd74a13e85ac timesync, meson: allow statically linked build dbf2801f5ac4 systemctl: do not print items twice in list-dependencies dd0395b5654c make namespace_flags_to_string() not return empty string e31b6bd02050 lgtm: drop the TMPDIR/meson workaround d4de2b2afff6 man: document that .link/.network/.netdev files have the usual ini syntax 870d38dca90b docs: add .link/.network/.netdev files to interface stability chart c7fe06fb0a00 man: document the default value for IPv6AcceptRA= cd517eb7310d man: specify that Domains= is a space-separated list 1699f5378896 hwdb: add corrections for Olimex Teres-I to keyboard hwdb 105a1a36cd6e tree-wide: fix spelling of lookup and setup verbs 33eb1f24978c tree-wide: drop printk.devkmsg=on setting in various places a345d5c1c9b2 man,mkosi: use glibc-minimal-langpack for Fedora 95d311faea78 man: bump fedora versions 1c5b427f5d36 hwdb: 60-sensor.hwdb: Add proximity sensor udev property (#14845) fdb0405edd90 selinux: check return value of string_to_security_class() 81d4a026a61c drop unused translations d015652944b5 update Russian translation 1fb5a5edc7c1 sysusers: do not require /proc to be mounted a100fe3c279b NEWS: Use correct tense in v245 entry 6cb356ca9fe0 basic/fs-util: add a version of chmod_and_chown that doesn not use /proc 08c7c3216bd5 sysusers: many different errnos to express one condition d54bb638750c NEWS: two minor entries 9c4d3d796825 NEWS: update contributors list 8193040362e8 hwdb: update for v245-rc2 a75b21175078 network: Move config_parse_ip_service_type to networkd-dhcp4.c and rename 2b43402c8477 ask-password-api: drop unneeded parentheses 86fca584c38f core/execute: use return value from sockaddr_un_set_path(), remove duplicate check 425d925f24a6 homed,userdb: don't use sockaddr_un_set_path() on fixed addresses f36a9d590901 tree-wide: use the return value from sockaddr_un_set_path() 0f1886872362 test-sizeof: print size socklen_t 64177e9e4e8b journald: fix forwarding to syslog 3b355677b8cc RequireMountsFor in systemd-nspawn should wait for machine mount 27f31daf3e22 shared/logs-show: Remove unused OUTPUT_FOLLOW ef62949a23a2 network: make Type=ether match based on iftype 834ea1a4665f test-network: remove unnecessary dummy interface 2cd651066133 man: fix typo f4665664c4ff units: disable ProtectKernelLogs for machined 123aeae20672 random-seed: add missing header for GRND_NONBLOCK (#14988) 8632e8768903 po: update Polish translation 4347f0abe261 l10n: update Czech Translation 4c2e1833ec1a test-network: add a test case for [DHCPv4] UseRoutes=no ad098b14c5ec network: Allow to configure GW even UseRoutes=false 161bc525bbd7 rules.d: import the keyboard builtin instead of running it df70539f9fe0 resolve: error handling improvements 6f22d5723527 userdb: fix lookup of groups defined by homed 3e93027b5b94 Fix two typos 972e81629d40 Italian: removed spurious lines of old labels f7ae155b14dc italian: language updates 0d066dd1a4cd pid1: add new mode systemd.show-status=error and use it when 'quiet' is passed 5bcf34ebf303 pid1: when showing error status, do not switch to status=temporary 1b4154a8919c pid1: make cylon timeout significantly bigger when not showing any messages ef15d3e1ab67 pid1: touch the /run/systemd/show-status just once 7365a2967031 pid1: when printing status message status, give reason 5ca02bfc3968 core: fix message about show status state b3ce4e2d407a hwdb: Add Medion Akoya E1239T MD60568 to 60-sensor.hwdb 196dedd50300 journalctl: implement --facility=foo c4ad7f83ec60 homed: fix typo aeac9dd6475d Revert "namespace: fix MAC labels of /dev when PrivateDevices=yes" ee00d1e95e84 pid1: do not fail if we get EPERM while setting up network name ecf63c91025b execute: Make '+' exec prefix ignore PrivateTmp=yes 5926ea0a6860 presets: enable systemd-pstore.service by default aa07dc709328 man: add .service suffix to systemd-pstore(8) e3b192626e24 man: tweak markup in systemd-pstore.service(8) ebb7a2fcb979 man: add missing refnames for two binary names b0cda2414802 docs: interlink the docs to make it easier to navigate 04c31af4c5cb docs: say XBOOTLDR instead of just giving the GPT identifier 6ffeca8c8f2e meson: explain GIT_VERSION and PROJECT_VERSION 62641751d529 man: fix links to ssh(1) and sshd(8) 3ea2b1137b6a man: add explanation where environment.d are inherited 8956caf333ff network: fix typo in comment e6e81ec0a568 namespace: fix MAC labels of /dev when PrivateDevices=yes 07336a067216 network: assume Scope=host when Address= is loopback address aa73f181e92c basic/string-table: avoid crash when table is sparse 1a8f0ce64fd2 systemctl: be more specific when emitting warning about rotated journal 68c1ac156891 conf-parser: fix line number in error message 79ac19ae616a hwdb: add cube i7 df5a4889fe85 udevadm: show more error message during exporting database 287f506c32f3 pstore: Don't start systemd-pstore.service in containers 81eb5bc5cc7e network: remove redundant %m in error message 3d7ac1c655ec udev-builtin-input_id: any i2c mouse is a pointing stick 443876d8dcf3 userdb: make groupdb_all() always set iterator when it returns >= 0 0ffbe10b8159 userdb: drop unnecessary goto e9b0b64f77fd fix ACCEL_MOUNT_MATRIX for Thinkpad Yoga 11e 3rd gen 19bb96759a91 userdb: allow dots in username 2a5180945a10 hwdb: Fix rotation for Nuvision Encite Split 11 9c1f969d40f8 swap: finish the secondary swap units' jobs if deactivation of the primary swap unit fails 06654d122515 ata_id: Add support for host managed zone block devices (#14933) aaaf42cb44d4 units: add mount for tracefs 6dea2361dc2f typo: stringy -> string 6ed8c09a40ed po: update Japanese translation of "home area" e60228bf6842 kernel-install: strip BOOT_IMAGE= from kernel options 7c7c44855e2e userdb: fix memleak 662d74daf7c9 userdb: make userdb_all() always set iterator when it returns >= 0 4617d37a375c po: fix confusion about what "it" is in Polish translation 09460a234bed tree-wide: replace "asked to inhibit it" with "is inhibiting this" 15f73764c4fb tree-wide: replace present participle forms 40afe4916a58 test-network: add one more test case for VRF= a856a83f181a po: update Polish translation of "home area" 18143cd76795 tree-wide: s/home/home area/g c0d48bc50ff4 network: use VRF's route table if VRF= is set 1ad448673ed3 man/systemd.unit: Add missing article to `Wants=` description 4a6ab3f79fb3 hwdb.d: actually install the 60-input-id.hwdb 31c33315b3e9 portablectl: block when stopping a unit on detach (--now) d4ffda38716d man: tmpfiles.d: z/Z ignore the argument c667e09ba067 ci: pass max_total_time to libFuzzer 6cec69fc3edd Change all fuzzing links to point to OSS-Fuzz site 129c55c06f49 docs: fix HACKING.md broken links c14faa944015 fixed typo in systemd.netdev Documentation for L2TP ad5555b42e9f systemd: Fix busctl crash on aarch64 when setting output table format bec31cf5f003 systemd: Fix busctl crash on aarch64 when setting output table format c315b79fb43a makefs: strdup arguments to mkfs 7ad1f0439843 lgtm: use the system version of meson 65be7042a876 lgtm: set TMPDIR to /var/tmp 99fdffaa194c Revert "Support Plugable UD-PRO8 dock" d900701eeab4 fix typo in object field c24c83dc67a6 network: Allow multiple IPv6Token 'static' items to generate addresses 38d1255a52f7 test-network: add tests for qdisc Handle= d8b2396d3458 network: add support for qdisc handle bfcdc872604a network: fix indentation 8a98f11ed0cd network: Make address_hash_ops available outside of networkd-address.c 0ddad04eda2a network: Document the lack of actual DAD usage in prefixstable algorithm 8dcce054e396 network: Rewrite IPv6Token documentation for new modes 53f8cced4570 network: Correct typo and naming in error message 87f9d6ea8efa network: Improve variable name for address generation f7ada4b8ec12 test-network: tentatively stops .socket units for udevd b241fa00e92e network: Add test for explicit 'static' IPv6Token b751c3e747a9 network fix parser for IPv6Token= 5f04f4e47037 test: give systemd chance to actually start the unit e2c1ddcc492f portablectl: add --now and --enable to attach/detach 68697cdd1274 hwdb: Fix touchpad toggle on WeiHeng P325J 74deaff1188a journal: fix log message 03b76a197731 repart: do not quit earlier when --empty=force 676047438a12 l10n: update Ukrainian translation 3d55b5a9def5 test-network: add test for teql 9b749c11e20b network: tc: support teql ab9dc1db477e test-network: add more tests for traffic control f0c1ad308d0d network: fix ABRT 59bae425704f network: update log message ab119e633878 network: append period if error message provided by kernel does not contain it 4c2724013ffa network: drop redundant %m 2ed5f6d5de38 network: introduce new [QDisc] section to support Parent=ingress 72545ae05745 core: sync SeccompParseFlags between dbus-execute and load-fragment e2c4070edfb0 network: rename eui64 to static 6e55b9b75839 chromiumos: sync auto suspend rules with chromeos commit e348a229bacc3 cff789b746c6 core/selinux-access: use _cleanup_ and improve logging 0ae5ffe0630a repart: quit earlier if no .conf file exists d7887449e7c9 basic/selinux-util: expose _cleanup_freecon_ 22cd7aabecd8 core/selinux-access: do not use NULL for %s 949fb07e6e3e network: also change fair_queue_traffic_policing?fair_queueing 2b6a90d17f4c selinux: update log message to suppress warning by coverity db99904bc848 sysctl: fix segfault 8aaf18e08a2e shared/ask-password-api: show "(press TAB for no echo)" 72c08a471c9c shared/ask-password-api: return "error" when dialogue is cancelled 1acf344dfa28 core: do not prepare a SELinux context for dummy files for devicenode bind-mounting 39e96f844a46 firstboot: add missing check d5d5b3f4a729 man: fix typo in systemd.unit man page 6b2fd86fd1fd network: remove unnecessary link->ifname from debug log statements 28ca867abdb2 sd-journal: close journal files that were deleted by journald before we've setup inotify watch c7220ca8025e units: drop OnFailure= from .target units e0e2112f6184 cgroup: systemctl: Don't display NULL if protection was set to max 8b51950f4cd2 docs: Correct resource weight range 129466138124 polkit: remove unused variable c450335bf74a github: remove direct paypal link 384db814eea1 meson: bump version numbers for v245 901d1ce8efcd NEWS: add contributors for v245 573e58f62f27 NEWS: mention the operational state changes f05c0615f4c0 NEWS: mention SuppressPrefixLength= 9569e385036c test: adapt to the new capsh format 87bbebeab6e2 test-network: add tests for IPv6Token= 5f506a55606f network: Allow to specify multiple IPv6Token for SLAAC 69f173477bb1 NEWS: mention the TrafficControlQueueingDiscipline rename 823b03527106 NEWS: mention empty .link and .network files 2ad988896c47 NEWS: reword and shorten a bunch of stuff 641aa41200f7 test-network: use udevd in build directory ea9bc14cd0a3 hwdb: update for v245-rc1 427928caa4c0 network: change "Gateway=dhcp" to "Gateway=_dhcp" (#14774) c0f765cac8b0 core: move bus-util include out of selinux-access header bc130b685832 Fix typo in function name 5c1163273569 man: document the new sd_bus_enqueue_for_read() API call 637486261528 polkit: when authorizing via PK let's re-resolve callback/userdata instead of caching it 1068447e6954 sd-bus: introduce API for re-enqueuing incoming messages f4425c72c739 polkit: use structured initialization 7f5698228927 polkit: on async pk requests, re-validate action/details 95f82ae9d774 polkit: reuse some common bus message appending code 773b1a7916bf bus-polkit: rename return error parameter to ret_error f156e60c66fa core: unit_label_path(): take const unit 6bdd90fbcd94 man: add "quick-help" to sysusers.d synopsis 1648233dce34 selinux-access: log warning on context acquisition failure 074b597dd904 selinux-util: increase log severity ca58d00c68bc network: FairQueueTrafficPolicing?FairQueueing 60ed2dcfc7ea network: TokenBufferFilter?TokenBucketFilter 8e92d92fb898 man: tweak description of blockdev at .target eb1322744dea NEWS: correct indenting for two entries ce4121c6ff92 meson: update efi path detection to gnu-efi-3.0.11 18de0969c576 network: split TrafficControlQueueingDiscipline section into small pieces dade73491747 network,udev: refuse .link and .network settings with no matches e519e20ae16e test-network: do not fail if lo has a .network file 90198bcbea92 Fix generator name in hibernate-resume-generator's drop-in 61c3e2c8bfc2 presets: "disable" all passive targets by default 41fd8fe71652 test-network: add a test case for IPv6PrefixDelegation.DNS=linklocal fd3ef936ed5b network,radv: make DNS= in [IPv6PrefixDelegation] section take special value 'linklocal' 5d4fc0e665a3 sysctl: set ipv4 settings in a race-free way e0f424790d3d sysctl: add glob syntax to sysctl.d files 5e9c08f377a6 l10n: update Czech Translation 50152bb1c5c3 core: call dynamic_user_acquire() only when 'group' is non-null 4c1dea42b593 journal: drop unreachable path e362d6eebadc po: update French translation bf2334c054da udev: add {Receive,Transmit}ChecksumOffload= settings 53e1ba280f07 network: add SuppressPrefixLength option to RoutingPolicyRule (#14736) e06d7d0fb0f1 po: update Japanese translation 10f58ad01534 po: update Polish translation 9a4940bf92c9 update NEWS 60d0a5098b2b util: uid_t, gid_t, and pid_t must be 32bit c757517d98ad meson: fix feature list 649916d3561a sysusers: support creating users with a specific primary group 6be8e78e32ec test-network: add test for UID based routing policy ea471a469572 network: support UID based routing policy 03de302a3132 util: add parse_uid_range() helper function af06ddf51a8a meson, man: do not install pam_systemd_home(8) when pam or homed is disabled 2273ecfeda0b test: don't install /etc/securetty 020313b213f0 test: also check the result of merge_gid_lists() 4af8ab2cab69 user-util: fix use after free() on error path b44b735a78be userdbd: fix memleak ad2378524635 update TODO 2b6b8bd3f727 man: document --namespace= switch of journalctl 241c8f67f65a man: document the new sd_journal_open_namespace() API 5b0a76d107eb man: document LogNamespace= unit setting 7d8155b3df13 man: document new _NAMESPACE= journal field 6bc4361997b1 man: document journald at NAMESPACE.conf efcbcd0d043f man: document journald namespaces 23d8c56046f1 journalctl: underline sections in --help 9610210d3235 nspawn: voidify umount_verbose() 02cec1562962 user-record-util: add missing error check 00c7b071acce homework: fix errno in log_error_errno() 852640f8a223 home: add missing variable initialization 340cb115b388 units: define RuntimeDirectory= in systemd-journald.service 5591cd4e2041 units: sort settings in systemd-journald.service again fb38a7beb815 tmpfiles: apply ACLs to top-level journal directory in /run, too 0f5a4f9cd969 tmpfiles: merge lines for the same inodes db23d83bd49b test: add simple test for log namespaces dc5437c78bbf journald: add ability to activate by varlink socket 65c398c031a3 journald: add exit on idle 6d4d6002606e varlink: add ability to register callback for disconnections c4f601f20535 varlink: add API for determining number of current connections d98580e4380e journald: use structured initialization 243526917131 journald: add logging for one error we lacked logging for d93dda3afef4 systemctl: show logs for correct namespace of service 21fa231ece5e journalctl: drop misplaced empty line 6b25db87a180 journalctl: add new --namespace= switch for showing logs for namespace 31e99dd2cc37 journal: make constant argument actually 'const' 456aa8790625 journal: allow opening journal files specific to some namespace 2f5435a14757 journal: use structured initialization 33ff74643e2a journalctl: use an anonymous array when an array is needed 68312977db5e journal: properly mark two definitions that are deprecated with GCC attributes for that e7238caf0cf5 journalctl: use automatic memory cleanup 0491150b5cb4 journalctl: use log_error_errno() wherever we can a6214d9643c1 journalctl: move pcre function code down 91dd5f7cbe6f core: add new LogNamespace= execution setting 839d1b201474 string-util: add brief explanatory comment 1ee51fbd7075 units: add unit files for instantiated journal daemons b1852c48c127 journald: allow running multiple instances of journald d6f46470f562 journald: when create journal directories use calculated paths 4f6031037363 journald: minor coding style updates 4e00337b1621 journald: let's simplify rotating of offline user journals 46e2348a586b journald: simplify find_journal() a bit b42b9479a8e2 journald: hide current storage determination in helper call 74dd8f575932 journald: use structured initialization 8548f4f09ba6 journald: line break overly long function header 7e7ef3bfb283 journald: let's use TAKE_PTR() and TAKE_FD() where appropriate a30e35f85aa9 journald: let's use unlink_and_free() where we can 2066f4fe30f5 journald: specifying _pure_ on static functions is unnecessary, compiler can figure that out on its own a2735a4549e8 journald: don't bother with seqnum file if we don't read form /dev/kmsg anyway dbac26257881 journald: fix indentation 99d0d05a10e4 journald: use free_and_replace() where appropriate 659a77bec6d5 journald: add missing logging for some errors d83f7e4c9218 journald: why bitwise XOR when boolean != is easier to read? 9a1862bfa6cd tests: unset LD_PRELOAD in testsuite.service when it's run under ASan efda8aebcb0e sd-boot: fix -Wpointer-sign warning a614aa1985d6 sd-boot: fix warning about comparison is always true 2d37ea5ca901 man: do not install man pages for systemd-repart if it is disabled 3ae01632f2d0 dhcp6: coding style fixes 9de8a4259eae dhcp6: do not use T1 and T2 longer than one provided by the lease faec9de87f1a docs: Fix example code in ROOT_STORAGE_DAEMONS 58345a2332f3 docs: formatting fix (#14707) 258adeca3c32 po: add src/home/org.freedesktop.home1.policy to POTFILES.in 56b3eddb7043 fix links to GROUP_RECORD and USER_GROUP_API e5e529c30ad5 fix link to JSON User Records f770b7e084d6 man: document man/sd_bus_message_dump.xml 2a4be3c52b98 Various typo fixes and grammar corrections 402058dc3a2c polkit: tweak grammar ec74f47e5617 meson: fix type of homed option 02d89f9a623a man: add syntax quickhelp to sysctl.d(5) def94437934b Revert "sysctl: always write net.ipv4.conf.all.xyz= in addition to net.ipv4.conf.default.xyz=" fa2111bd3ed2 man: document logging downgrade in systemctl f3b136a4847a shared/sysctl-util: normalize repeated slashes or dots to a single value ce306dd872af po: update Polish translation 70e9d9a56c7a update TODO ed2d9661521c update TODO 8d251485fa53 core: fsck images specified as RootImage= too before using them 4fcb96ce253f nspawn: fsck all images when mounting things e475f72977ba dissect: add --fsck= option to systemd-dissect tool cf32c4865761 dissect: optionally, run fsck before mounting dissected images 0f7c9a3d81be dissect: complain if partition flags are set that we don't know a44956c94a93 network: fix implicit type conversion warning by GCC-10 97cd52c1b54b update TODO d200253ba5f6 update TODO e21d90606afc pam_systemd: resolve the tty of display via /sys instead of /dev 72d43d09ccb5 id128: change table header from "uuid" to just "id" 68410195679e NEWS: more v245 preparation 552cafaa86ad po: update French translation 723822f00ae3 NEWS: start preparing v245 bcb1eadc0cf8 test: fix rename_noreplace() test 3c7b4ebf94d1 test: make sure chase_symlink() returns normalized paths 47d7ab727cf5 fs-util: make sure we output normalized paths in chase_symlinks() 6efb1257d10c test: add test for the non-resolving of chase_symlink() root prefix c2595d3b0284 fs-util: when calling chase_symlinks() with root path, leave root part unresolved c809ed783e6c update TODO 0edd431e1549 ci: add new dependencies to CI a9dabd6866d8 docs: document the home directory format f62dd2375e51 docs: document homed UID range 28e208a7d8bb man: document pam_systemd_home 38e7b808eb0f man: add systemd-homed man page ea7a19e95db9 man: add homectl(1) man page ba0fb5acd46e sleep: automatically lock all home directories when suspending 6ead39170aea test: add test case for homed 26cf9fb7f833 home: add pam_systemd_home.so PAM hookup 4aa0a8ac3e54 home: add homectl client tool 70a5db5822c8 home: add new systemd-homed service that can manage LUKS homes e53db1405c5d mkosi: add fdisk-devel, openssl-devel, libpwquality-devel, p11kit-devel and efsck to build 1ffadeaae32d udev: assume that the recv buffer size of the netlink socket is already configured when the socket is passed in a05a6e8bba7e test-network: fix test_qdisc2() 8bc943b47256 fix erroneous "`" in boot loader spec e0db55a643f2 man: document that sd_bus_message_read_array() only supports trivial types 10c238b2cc4a man: clarify that we decode D-Bus bools as "int", not as C99 "bool" e5667705faa8 man: describe types slightly more accurately 979bdc47c9cd man: enclose C type names in 1b3cccfdacc7 unit: add AF_ALG to systemd-networkd.service 11a182aa1e64 test: drop sector-size line from output of sfdisk 37b9966e2525 test: Synchronize journal before reading from it 006c44c1e86f TODO: add various items as result from devconf.cz 2020 discussions 58abbbcc6bce sd-bus: fix introspection bug in signal parameter names 022d334561ab man: doc: Document ProtectClock= 732e3a61043b network: accept NUL character in SendOption= a6a36dea2d40 test: add tests for UNESCAPE_ACCEPT_NUL 0e72e469f88c escape: introduce UNESCAPE_ACCEPT_NUL flag 46dc83440fc6 escape: make cunescape() and cunescape_length() inline 8bdda551dab5 efi: fix build. 9f37272a192e analyze: Add ProtectClock= to analyze-security fc64760dda4d core: shared: Add ProtectClock= to systemd.exec 0de6103dffed man: tmpfiles.d: list missing q 576e50efb694 Update copyright notice fe5a698f7646 bootspec: parse random-seed-mode line in loader.conf a14c18ba7b4e sd-boot: fix typo a3e42c468fc1 test: unpin meson from v0.52.1 da2076a159ba man: remove duplicate in list of variables ignored by Anonymize 2b4a65b66813 sd-bus: export sd_bus_message_dump 27cf4c18c76d sd-bus: make dump flags public dc972b074071 systemd-id128: add new verb to print GPT partitions UUIDs e1d32d6ee86a update TODO 19ce38ce620f shared/gpt: export gpt_partition_type_uuid_{to,from}_string functions 6252bd0e8442 update TODO 4acf0cfd2f92 logind: check PolicyKit before allowing VT switch 269e4d2d6b75 shared: split out polkit stuff from bus-util.c ? bus-polkit.c 2c0d7ed39393 network: do nothing if link is in pending or linger state on reconfiguring 0ce0e3470eb5 network: synchronously save state file when link is being reconfigured 8ae7b8a1e1d6 network: set dirty flag when link is being reconfigured dc084399fad2 loginctl: use /org/freedesktop/login1/session/auto when "lock-session" is called without argument 68bda079fd08 man: document blockdev at .target 44b0d1fd597d core: add implicit ordering dep on blockdev at .target from all mount units e3e6f996894f core: downgrade swap ? device dep to Requires= 61f9cf4e4c48 swap: generate automatic dependencies also for /proc/swaps devices 5de0acf40d32 core: let's be defensive, /dev/nfs is also a special mount source, filter it out 219f3cd94106 core: drop _pure_ from static functions a7e885587949 units: introduce blockdev at .target for properly ordering mounts/swaps against cryptsetup 6bbd539e5e72 cryptsetup-generator: order after cryptsetup-pre.target unconditionally 49685fb31480 cryptsetup-generator: break overly long line 33a4c9834282 fstab-generator: line break a bit more systematically 56a061f508ec update TODO a15e1a5df0c9 man: fix typo in systemd.netdev Xfrm example 502991215726 network,udev: use uint64_t for bit rate ce96c9cb1a8f timesyncd: log louder when we refuse a server due to root distance d3e5639ebb60 Fixed some typos in the documentation f1f20764f9e5 resolved: drop DNSSEC root key that is not valid anymore be02c1cf426d Implemented x-systemd.{required,wanted}-by= options e0567bc8adfe journal: don't use startswith() on something that is not a NUL-terminated string f847b7eca30f hwbd: add Asus TP500LA df062bef2925 hwdb: merge identical entries c9872da4d17c hwdb: fix whitespace issue 680120bb20f0 virt: do not define vm_from_string() for non-x86 architecture b90cf10245bc core: make a number of functions not used externally static 96462ae9984c core: show the UID we cannot parse 898820edb5c9 json: lower maximum allowed recursion to 2K 18e6e8635f06 generator: order growfs for the root fs after systemd-remount-fs d6bd2bb4441e hwdb: fix error numbers passed to log_syntax() 2aecc668878f hwdb: use strv_extend() where we can 2e5180d38b33 strv: get rid of strv_clear() 81248e7f3e83 Documentation update for x-systemd.{before,after} f85df8181727 import: let's disable UNIX signal generation from curl d076f9fd56c9 import: put a time-out on downloads 137c6c6b3659 import: don't complain if FS_NOCOW_FL is not available 492f91d8c6c3 update TODO e65f29b4c6e8 ci: add dependencies for repart + cryptsetup's pkcs#11 support 917cc8082bbd man: document systemd-repart 2f62a8c68809 test: add repart test 29ee6541a414 units: add unit file for systemd-repart to automatically run at boot 64db6f3644c3 mkosi: modernize e594a3b154bd repart: add new systemd-repart tool b57ebc6004bb conf-parser: add parser for 32bit signed integers 7e70f2cb0e43 locale-util: add special glyph ? 1d2a1a0cb808 locale-util: add block drawing special glyphs 137688dff466 format-table: add support for formatting uuids/id128 values 1293a168f16d id128: move make_v4_uuid into id128-util.h to make it generally useful 449d530700ae makefs: simplify SPDX header e56a8790a0bf test: add test for https://github.com/systemd/systemd/issues/14560 3b7f79dc9fc5 core: make sure StandardInput=file: doesn't get dup'ed to stdout/stderr by default cdc6804b6046 units: drop full paths for utilities in $PATH 5608deb847b7 Italian: language update 5cbaf95ee311 wait-online: Support waiting for interfaces to disappear 75cd4a5d9294 wait-online: Add maximum operational state option fc57f105d9e2 pkgconf: add full generator paths 7e284b054ec5 tree-wide: we forgot to destroy some bus errors 287cf2d80226 typo: "May modify to" -> "May modify" 0879fbd6fedc mount: make checks on perpetual mount units more lax 88414eed6f45 core: never allow perpetual units to be masked f535af6bcd51 man: document that WakeSystem= affects clock choice 1e1f4f443dc3 docs: uppercase are headers 3b9796c01c31 docs: let's reduce our spurious whitespace a bit 8eabc083dc83 docs: in PORTABILITY_AND_STABILITY only use one h1 54ed193f8d48 man: clarify that user rlimits cannot go beyond limits set for service mgr 59d83463d18c man: extend on halt documentation 0b306655f1ec man: document that rootflags= does not override /etc/fstab d524094b6b3f man: underline that AccuracySec= is about coalescing timer events, nothing else eec68a1a0807 man: mention that Before= doesn't work for device units 49dd0c161a1e man: suggest SYSTEMD_WANTS usage instead of RUN for long running processes f27a21d48bac man: document the limits of the block device discovery for IO cgroup options 1e8a7eff2207 man: document how error propagation to path units works ba96a8a2778c man: document that program invocation will fail if the User= does not exist 8384ed93b958 docs: clarify that we don't want to own $BOOT exclusively 4ca739e20a09 core: reduce indentation a bit b0a94df9631d logind: use loop instead of repeated code ddee3ada467d shared/user-record-nss: use macro to avoid repeats 192aee3cae72 shared/user-record-nss: shorten code a bit c7d26acce6dc Disable reading SystemdOptions EFI Var when in SecureBoot mode c97ae2b29036 Clarify journald.conf MaxLevelStore documentation c16460cf781c shared/sysctl-util: add missing header 32458cc9687c sysctl: downgrade message when we have no permission b2ae4d9eb85f sysctl: move hashmap allocation out of main function e76c60bf2a2b man: rework section about configuration file precedence 4bb68f2fee91 core: on each iteration processing /proc/self/mountinfo merge all discovery flags for each path 46d7c6afbf92 execute: allow pam_setcred() to fail, ignore errors 5b8d1f6b7757 execute: add const to array parameters, where possible c903ee897681 docs: add documentation for the varlink user/group APIs 32eb3c42299d docs: add documentation for JSON group records, too 812862db7116 docs: add documentation for JSON user records 0ba56d3657b3 man: document the new nss-systemd behaviour 7d9ad0e5e51c man: document systemd-userdbd.service 3b2db6f110f3 man: document userdbctl(1) fc89f88e56cd man: document new pam_systemd features in man page f9c1f4e19308 pam-systemd: apply user record properties to session 7bfbf6cc92bd pam-systemd: normalize return values of append_session_xyz() 9ab0d3ebe5a5 pam-systemd: port over to use a UserRecord structure 355c9966c207 pam-systemd: share bus connection with pam_systemd_home if we can d750dde2a634 pam-systemd: port to pam_bus_log_{create|parse}_error() and pam_log_oom() cef9f2a64766 shared: add pam utility helpers d510589fd0a4 logind: honour per-user stopDelayUSec property 156a363750b3 logind: honour killProcesses field of user record e8e4b7a0b6ef logind: enforce user record resource settings when user logs in 22c902faccb3 logind: port to UserRecord object 1684c56f40f0 nss: hook up nss-systemd with userdb varlink bits 19d22d433d3a core: add user/group resolution varlink interface to PID 1 4bad7eedae3d core: make return parameter of dynamic_user_lookup_name() optional 1604937f83d3 userdbd: add userdbctl tool as client for userdbd d093b62c941e userdbd: add new service that can merge userdb queries from multiple clients 295c1a6e4569 shared: add helpers for displaying new-style user/group records to users ec8e4a0ef12f shared: add internal API for querying JSON user records via varlink 9b2d907877ab shared: add helpers for converting NSS passwd/group structures to new JSON objects 71d0b9d42263 shared: add generic user/group record structures and JSON parsers 64aa2622a3ba libcrypt-util: add superficial validator for UNIX hashed password strings 42f3b2f97510 shared: split out crypt() specific helpers into its own .c/.h in src/shared/ 2ee4b118fa72 nss-util: add macros for generating getpwent()/getgrent() prototypes 65e2766f6458 docs: fix width of console example 5425f8a57c22 Revert "docs: rename HACKING ? Hacking" 8c5cd27dd155 docs: rename HACKING ? Hacking b6bcde2623bf docs: shift console log on index page to the left 6af0a0442808 docs: add the systemd output example 4e96d758f883 docs: update old para with links to the blog stories 48f60ea9ad2e docs: remove markup from title d00386fc0b1c man: add commas and reword a sentence bbaba5748d65 test-format-table: add tests for TABLE_STRV 29e15e98c760 resolvectl: use format-table.[ch] 536cdd07b3f7 networkctl: use TABLE_STRV 4618660d1012 format-table: introduce TABLE_STRV 8b75798d12cc strv: introduce strv_compare() 3fec55246854 docs: rework HTML into GitHub Markdown table c238a2f8899b cgroup: minor comment improvement be2bb14f0044 logind: refuse overriding idle hint on tty sessions de9a8fe18e01 systemctl: use format-table.[ch] for tables 191a3f163451 basic/strv: drop flags argument from strv_fnmatch() 0ef84b80c59b networkctl: return error or warning when interfaces are not matched 1d086a6e5972 mount: mark an existing "mounting" unit from /proc/self/mountinfo as "just_mounted" 48fd01e5f3bf cgroup: drop redundant if check e1e98911a818 cgroup: update only siblings that got realized once 95ae4d142072 cgroup: drop unnecessary {} a0d6590c4e8f cgroup: no need to cast dev_t to dev_t 57f1030b1373 cgroup: use log_warning_errno() where possible b35ec8ded2da docs: uppercase all markdown document titles a0fadf66daba docs: drop "The" in categorization titles of Markdown documentation 744c49e1fef0 docs: update link and more dots 0a5a8f13b421 docs: say that journalctl --flush/--sync also require journald 180f7c26aa18 docs: import initrd interface documentation from fdo wiki f8349d2fa5ce docs: various small fixes to PORTABILITY_AND_STABILITY markdown 0bdd282a4e81 killall: update reference to root storage daemon interface docs 6e47cac0aa86 docs: convert root storage daemon doc to markdown 61c0ac0924d5 hwdb: Entry for Lenovo Ideapad 310S-14ISK Alps Touchpad 23b392166388 journalctl: Correctly handle combination of --reverse and --lines (fixes #1596) 3ac9cac7f7a3 journalctl: Correctly handle --show-cursor in combination with --until or --since and --reverse 03f9228e7cf2 man: suffix parameter with = in our documentation, if it expects an argument fc6eb08e74d6 machinectl: modernize address table handling d91614e717ed format-table: natively support multiline cells f6857fa60118 string-util: add helper for extracting n'th line of a string 8dd6491ef9f6 string-util: let's add helper for truncating string after a specified number of lines f9951b0cf0e5 man: we support bind mounting regular files too 151a7133cd06 man: document that we mkdir() on What= in .mount units too c6cecb744b53 test: Add tests for gid list ops afb11bf1b843 execute: Detect groups added by PAM and merge them with supplementary groups 3bb39ea936a5 execute: Restore call to pam_setcred 0c5d667932f8 user-util: Add helper functions for gid lists operations d89cde099474 docs: say that various cli progs are independent of pid1 ef0bea8cf4f1 docs: say that dbus api is stable (but list various caveats) b2eea3dc325e docs: say that all documented programs in $PATH are stable e4893c6306f4 docs: import "interface stability promise" 117caf376557 networkctl: break long line 8571210a21d7 machinectl: reduce scope of iterator variables 957d9df38822 resolvectl: minor optimizations to allocate less d308bb99d20b Resolve alternative ifnames wherever we would resolve an interface name fc2ea97ad03b util-lib: add function to resolve "alternative" names 6b8fe4c30cbb man: XxxRate= are in bps b8b7309778ca docs/stability: relax the stance on accepting patches a bit 02c789f9f966 docs: import stability chart from wiki 5c3fa98db68f util-lib: move things that parse ifnames to shared/ 955bb7fac3bc basic/socket-util: indent for clarity bad7cecc0aa8 sd-netlink: do not require rtnl pointer to be passed 231d9de1e3e9 networkctl: define a helper for interface name resolution 9030b50a7bfe timedatectl: drop ifindex output parameter too 597da51bae9e tree-wide: make parse_ifindex simply return the index bcc0fe635df5 nspawn: Correct "container" to "host" MAC setting message 2e93770fd865 man: document alias rules and aliases dropin loading 1bf15585521c core,install: allow one more case of "instance propagation" 972f3176fa36 shared/install: drop an unused variable in config_parse_also() 66a19d85a533 shared/install: try harder to find enablement symlinks when disabling a unit 3f57bc2267e0 shared/install: rework alias check and add test 29a743f99346 core: explicit mention of unit ID is redundant with log_unit_*() 9a4f9e69e108 shared/unit-file: expose function to check .wants/.requires symlink validity 2595eb8cd9ba hwdb: make comment more precise 12845a91b5c6 machinectl: do not truncate addresses when --full is specified bd17fa8cd870 tree-wide: use table_log_add_error() 964a7745de89 portablectl: optimize table creation 679c7c7a6741 machinectl: optimize table creation 9c46b437fcb1 analyze: optimize table creation by using table_add_many() d8aedafb57df format-table: add table_log_add_error() 0e05be840513 initctl: (void)ify epoll_ctl() CID 996298 a602a0b44b9e man: Document systemctl --with-dependencies switch e9c387c8293c systemctl: Add --with-dependencies flag e2268fa43742 bash-completion: do not ellipsize machine name a65e34ccb083 machinectl: do not ellipsize table when --full is specified 2a6c483b8cb7 bash-completion: busctrl: support --full command line option b683b82fe770 busctl: introduce --full command line option 6c64cf8859ea bash-completion: networkctl: do not show ellipsized link name a42d94908003 networkctl: set table width 0 when --full is specified a362c069a9d7 systemd-mount: add --full command line option bcf00b6c0a6f format-table: allow forcing arbitrary width tables 0c020321c83e test-network: simplify wait_online() by calling wait_operstate() a4632dc7d131 test-network: convert wait_operstate() to recheck condition for timeout seconds 19cf3143cf9f test-network: rename check_operstate() to wait_operstate() 4c6496525763 network: drop foreign config after addr_gen_mode has been set 0917a2717810 network: if ipv6ll is disabled, enumerate tentative ipv6 addrs before dropping foreign addrs 9524014ee638 network: add link->setting_genmode flag 3a390124b794 network: rename linux_configure_after_setting_mtu() to linux_configure_continue() b63c88b62718 man: describe "symlink" and "systemctl link" explicitly in UNIT FILE LOAD PATH 65f6b6bdcb50 core: fix re-realization of cgroup siblings 6fca66a7f125 core: set error value correctly af4454cb17da core: use unit-based logging instead of generic logging where appropriate eb34a981d671 core: initialize priority_set when parsing swap unit files 6afc31615e63 core: no need to initialize swap structure fields if all zeroes anyway 6d9e0ca40013 core: expose swap priority value via dbus only if it is set 246be82bd419 man: link to specific sections of cgroups-v2 document bb6d563a5049 doc: link to html versions of cgroup docs 0ca1926ec314 bash-completion: networkctl: support --full and --lines 404308486aa2 core: be more restrictive on the dependency types we allow to be created transiently cf57766d792f timedatectl: use format-table.[ch] 7cce68e1e042 core: make sure we use the correct mount flag when re-mounting bind mounts 8403219fc13a mount-util: line break overly long function prototypes 08b1f5c7d119 mount-util: clean up get_mount_flags() 4eaf0d9401ab mount-util: don't mask away MS_RDONLY twice f3dab34d22e6 mount-util: rename cleaned ? simplified, because that's what we actually did here a5279634c025 systemd-mount: add --no-legend command line option 6ae6ea55d81d systemd-mount: use format-table.[ch] f93d876c80a6 format-table: introduce TABLE_PATH 4c2ef3276735 core: propagate service state to socket in more load states 19212f278166 udev: don't import parent ID_FS_ data on partitions b0a94268f876 core: when we cannot open an image file for write, try read-only c8c535d589cc namespace: tweak checks whether we can mount image read-only 9a2ec8f7a6d5 install: use path_strv_contains() where appropriate 3593fa60f2a1 path-util: express PATH_IN_SET() through path_strv_contains() 3841fee82218 path-util: introduce path_strv_contains() helper ab015b13df5e man: small casing fix f2e5e70410ab man: document that scope units can fail, but not due to process exit statusses c80a9a33d04f core: clearly refuse OnFailure= deps on units that can't fail b44d87e200b9 sd-event: use _cleanup_ in one more place 1eac79486ef3 sd-event: use RAII for struct epoll_event 0475919b56c4 network: use automatic stack allocation and structured init 6666c4faeefa network: do not require ethtool_get_permanent_macaddr() to get an fd 6a6078a585f3 test: minor typo fix 514793658c49 test: pin meson to 0.52.1 for fuzzit/fuzzbuzz 64be35ab02c6 network: rename *fd to *ethtool_fd d9b204544b69 man: use xi:include to avoid duplication 95522092925a man: fix option name d2e825b4ab51 doc: tweak grammar in CONTAINER_INTERFACE description caa8538a22b6 networkctl: show permanent mac address if it is not used now 4bb7cc828706 network, udev: introduce PermanentMACAddress= setting in [Match] section 95f2b4dd237f Support Plugable UD-PRO8 dock 79b4428a7d01 ethtool: introduce ethtool_get_permanent_macaddr() 4f0840669e17 gpt-auto: don't assume XBOOTLDR is vfat 5ac8b50d5894 network, meson: allow statically linked build 356873ddec61 zsh: Complete systemctl subcommands in separate tags 8f817cb888cc shared/sleep-config: do not ignore resume_offset when resume not set 8efc2c1608af shared/sleep-config: make swap detection stricter again 411975ce63b2 shared/bus-util: Don't replace exsting strv 4353974d7594 boot: fix osrel parser 3a827125e70a man: stop recommending modprobe -abq in ExecStartPre= d5016c21d7bb units: tweaks to modprobe at .service 867af7282b2e unit: make sure to pull in modprobe at loop.service when RootImage= is used with DeviceAllow= 07141aa00592 bpf-devices: line-break some overly long function signatures 625077264ba0 units: Split modprobing out into a separate service unit 3ce252d0e0cc udev: use dot_or_dot_dot() where appropriate a1686563ded4 man: fix documentation of IBM VIO device naming e232c307c052 man: slightly extend documentation on difference between ID_NET_NAME_ONBOARD and ID_NET_LABEL_ONBOARD e9f0c5d08c65 shared/sleep: use stat() instead of open()+fstat() in one place 7a182f103437 udev: do not use exact match of file permission 6b50cb5ca919 nspawn: set original ifname as alternative if it is truncated 98b0299479a6 network: append INTERFACE= attributes for logs corresponds to a netif fc79e6ff5e1f test-network: suppress logs in status command 10c71c3605d7 networkctl: status command also shows logs of networkd b6cea5496a20 man: drop unnecessary white space 67861acdf3f0 locale-util: extend comments on unicode glyph use, and drop mdash (that actually was an ndash) 214c5bae09fb test-network: add test for Gateway=DHCP 1985c54ff352 network: static routes via DHCP gateway 25454a0c341e virt: drop trailing white spaces 735ea55f5cd8 virt: use string table to detect VM or container 0e97a910a63d pkcs11-util: don't mask return value of the first asprintf() d6246fd498ab network: lower the log-level of harmless message 11b8568f26e5 meson: drop unnecessary linking of libudev_core a26c307320fb sd-netlink: fix copy and paste mistake 53dc5fbc41af man: change links to container interface doc to https://systemd.io/ 635dea2783a6 docs: move container interface docs from wiki to markdown fc67a943d989 core: drop initial ListNames() bus call from PID 1 a5b07847950c core: create/remove unit bus name slots always together 5085ef0d711f core: no need to eat up error 17bda1f19d53 core: shorten code a bit a54654ba700b core: don't check potentially NULL error, it's not gonna work anyway 42837b813484 core: don't check error parameter of get_name_owner_handler() 3425c45e1e95 testsuite: drop "systemctl is-system-running --wait" invocation 13811aa5f6bc test: don't rely on "nobody" user for TEST-43 519b2e521214 test: hardcode shell to use 14b6e6b6f31a sd-netlink: use uint8_t* for non-character data f9aefc91f170 testsuite: drop "systemctl is-system-running --wait" invocation e9786a5c0164 test: don't rely on "nobody" user for TEST-43 6e0ed2865e34 test: hardcode shell to use 52133271a7b3 systemd-sleep: always attempt hibernation if configured ec04aef44225 dbus-execute: avoid extra strdup() ff963ea6ba8e test: use symlinks for Makefiles 097537f07a2f job: Don't mark as redundant if deps are relevant 2436ea761b28 nspawn: Make a custom mount on root imply --read-only. bbd407ea2bc5 nspawn: Don't mount read-only if we have a custom mount on root. 72a86dd5ec25 man: tmpfiles.d: only list "v" once f6bc26ee7fba man: tmpfiles.d: "b", "c" options require major and minor numbers 2ceefe45873d hwdb: Lenovo T490 Synaptics Touchpad hwdb entry 75997c3fa5e7 test: add test case for setpriority_closest() 390902012c51 core: in execute, Never fail setting Nice priority bc5ea049f29c nspawn: Generate unique short veth names b355d0c9affc udev: move naming-scheme.[ch] into src/shared/ b01c1f305c04 systemctl: show 'VENDOR PRESET' column in 'list-unit-files' a25457f5b768 systemctl: skip non-existent units in the 'cat' verb 412a6c646ced systemd.exec: document the file system for EnvironmentFile paths 5b4855ab73c1 nspawn: Move --network-interface interfaces back to the host. 85f04a216147 hwdb: 60-sensor.hwdb Chuwi Hi10 CWI515 accelerometer orientation. 736eadf0284b Update Galician translations be78e0f07b23 systemd-analyze: fixed typo in documentation e514aa1eead3 tree-wide: yet another batch of coccinelle recommendations 48d0248e6df3 network: bump netlink receive buffer size to 128M 14157349db98 travis: wait for the container to fully boot up a3d35654517e test-network: add a test case for CoDel b078e52855d0 network: add more settings for CoDel c695dcf929bc network: Add support to configure DHCPv4 route MTU a9a5d632da72 network: tc introduce codel e6627f2392cd unit drop-in: Fix ordering of special type.d drop-ins f5dd6e50a781 Add failing test to show service.d global drop-in does not get overridden by more specific dropins 98cd752a285c test-condition: fix group check condition 6e3c443b56f1 Fix typo 11fcfc539854 Fix several typos in documentation 40681e5cdc74 network: add one more log message b390f1789262 nspawn-network: Split off udev checking from parse_interface. fa7ea8651084 zsh: Prepare for classifying systemctl commands (#14422) 1d8385b41599 zsh: Complete more systemctl commands 51a3b7263409 zsh: Group systemctl subcommands as in the manual. No functional change. 27cc3c9d764f update TODO 31ca5166b6c7 man: document /var/tmp/ and /var/ handling in systemd-gpt-auto-generator man page 19ac32cdd6c3 docs: import discoverable partitions spec d4dffb8533a0 dissect: introduce new recognizable partition types for /var and /var/tmp 4171837be6b8 bash-completion: move shell-completion for log-level or friends to systemctl b59817b199f3 shared/install: drop creation of alias for DefaultInstance 4ca8072fd619 umount: when we fail to detach a loopback device, set the auto-clear flag b877c3b06f15 umount: check LO_FLAGS_AUTOCLEAR after LOOP_CLR_FD claimed success 63135a2d8db0 umount: detect root loopback device the same way as we detect root DM devices 88287615e631 umount: show correct error message 610f9a42c4a8 umount: remove unneeded variable 49f80dcec83b umount: line break comments again b895fa08e680 Revert "Drop dbus activation stub service" 0fd8b7180959 test-network: add a test case for DHCPv4.SendDecline= c1d3fa29ca9d network: link should not become configured state during ACD probing 0f3ff4eae2f3 network: DHCP4 introduce send decline 7c6d95ea5add network: fix typo 2f8c48b6059b core,journal: export user units' InvocationID and use as _SYSTEMD_INVOCATION_ID f9ef25a483ed basic/unit-name: make sure UnitNameFlags is signed 509b06ffddb0 network: update log message in message_rtnl_process_xyz() aa0f357fd833 shared/install: split out alias verification function 277519db5129 man: add section about user manager units f71502c49fd9 man: add remote-*.targets to the bootup sequence 9e7c8f64cfda time-util: also use 32bit hack on EOVERFLOW 12c7d4d65e4f hwdb: ignore keys added in kernel 5.5 419a8a2dabb4 hwdb: Add LCD menu key mappings for the Logitech MX5000 and MX5500 keyboards 4186441bbd91 Revert "cryptsetup: umount encrypted devices before detaching it during shutdown" a1533ad73f09 [man] note which UID ranges will get user journals d59fc29bb742 [man] fix URL b6657e2c53ee test: add test case for PrivateDevices=y and Group=daemon e5f10cafe0bb core: create inaccessible nodes for users when making runtime dirs a49ad4c482b8 core: add test case for PrivateUsers=true in user manager 5749f855a76b core: PrivateUsers=true for (unprivileged) user managers d909b40fda52 analyze: badness if neither of RootImage and RootDirectory exists de697db05b08 network: introduce AddPrefixRoute= and deprecate PrefixRoute= a0ce990e711f test-network: add test case for multipath routing 6ff5cc6b7a0f network: introduce multipath route 6497a8aa9b48 sd-netlink: introduce rtattr_append_attribute() b012a1f455cb Make openssl dependency optional again 27b4b3cc927e update TODO 3d0205f28b06 Be more strict about what can be an Alias for template and instances 5cddd924aa1f sd-event: don't allocate event queue array on stack ac6431dad950 man: add man page for sd_bus_message_sensitive() 4023637a8ab0 Restore silent handling of BUS_ERROR_SPEED_METER_INACTIVE 1b49e3e3c4f5 shared/loop-util: rename function 7a670b1dd981 shared/dropin: fix assert for invalid drop-in f27bb6abd3b8 initrd: make udev cleanup service confict trigger and settle too 9652d740929f varlink: add varlink_close_unref() helper e10720818ec3 chown-recursive: add fd based API 417a6eece8a1 chown-recursive: move src/core/chown-recursive.[ch] ? src/shared/ 845a7c1fc183 basic: add quota-util.[ch] with some helpers for the Linux quotactl() API 6789dd57f0a0 cryptsetup-pkcs11: just return zero on success, no need to return anything else 3ded1d616a50 cryptsetup-pkcs11: line break some overly long lines 12f69587e973 cryptsetup-pkcs11: refuse keys above 16MiB size 2ccf0ff6e8cd man: tweaks to the crypttab(5) man page 3d864658ea01 hwdb: assume all Medion Akoya E-models have the same matrix 35a05d8d5edc man: whitespace fix 76b73ce21c0a man: we support growing xfs too these days 601f91bec564 time-util: deal with systems where userspace has 64bit time_t but kernel does not e7bdadb5c655 network: support alternative name to get bus path for the link f7581ed6e06b networkctl: support alternative name to specify interface 4d016e965b13 udev: sort alternative names b04c5e51da7a sd-netlink: introduce rtnl_resolve_link_alternative_names() 1209ef94bd09 [import] fix stdin/stdout pipe behavior in import/export tar/raw 05de16766b6b hwdb: Add Bluetooth-attached Logitech MX Master 4afb4a9cc574 systemctl: show what verbs support --dry-run in the help page 6d185cffb196 sd-netlink: add a whitespce between cast operator and variable f501c2515125 sd-netlink: make netlink_container_parse() takes size_t for rt_len 49f5cbe92484 network: set AlternativeNamesPolicy= in 99-default.link ef1d2c07f956 udev: introduce AlternativeNamesPolicy= setting bb181dd4a664 udev: do not fail if kernel does not support alternative names a0f11d1d11a5 random-util: call initialize_srand() after fork() 78f8849f84ca udev: extend the length of ID_NET_NAME_XXX= to ALTIFNAMSIZ 861f1789051d efivars: properly NUL terminate EFI variables when reading e40b4caa1f91 basic/tmpfile: avoid maybe-uninitialized warning in mkostemp_safe() b742942edf60 TODO: drop entry e51712963b81 shared/install: log syntax error for invalid DefaultInstance= cb180b09fab0 Added Trekstor Primetab S11B da7667518b57 docs: CSS files should not be executable 90d81ee96665 github: use systemd.io links in issue template 479ddcdf5ac5 util: constify arguments of strv_xxx() 7a2f6fb6f1bf test-network: pass environment variables to networkctl 6934ace05d04 test-network: add a test case for netdev altname 511070ee9501 networkctl: show alternative names 572b21d96cab network: make Name= in [Match] support alternative names of interfaces a5053a158b43 udev: support AlternativeName= setting in .link file 4252696aec9e util: introduce ifname_valid_full() d08d92d5ee50 test: add a test for sd_netlink_message_{append,read}_strv() 6d725977c4f9 sd-netlink: introduce sd_netlink_message_append_strv() 8f3c18596692 sd-netlink: introduce sd_netlink_message_read_strv() 01813148619c shared/loop-util: spin on open() returning ENOENT too 35b9eb0a72b6 basic/efivars: do not return EIO if an efivar read is shorten than fstat size a97abb30e7eb shared/efi-loader: add some debugging statements f2d9213fee0f shared/loop-util: spin on LOOP_CTL_REMOVE e8af3bfd635c shared/loop-util: fix error handling in loop_device_make_full() ffeb16f5d832 sd-netlink: support IFLA_PROP_LIST and IFLA_ALT_IFNAME attributes d3678e3a0b4b linux: update headers d9ceeb9fe7bb Add Acer Spin 1 SP111-33 to sensor hwdb c8bf87b3399a hwdb: Add accel orientation quirk for Thundersoft TST168 tablet 4ef289250f1c test-network: add a test case for new FQ settings d7ceaf72618a shared/install: provide a nicer error message for invalid WantedBy=/Required= values d9c1c43e678f shared/install: remove duplicated check e83562e51e97 network: tc: add more settings for FQ d0556c55e7b6 nspawn: fix overlay with automatic temporary tree ff2c2d0850c4 docs: make sure there's only one # markdown header in each file db8728a60c73 blockdev-util: rework get_block_device() bd6609eb11ec nspawn-mount: Use FLAGS_SET to check flags. 5530dc87f21c nspawn: Only bind-mount directory when necessary. e091a5dfd162 nspawn-mount: Remove unused parameters 5f0a6347acf0 nspawn: Enable specifying root as the mount target directory. eae1ef076d6b test: increase qemu timeout for TEST-08 and TEST-09 679ecd361634 nspawn: allow combination of private-network and network-namespace-path 9401e488555a test-network: add a test case for the new settings of FQ-CoDel ac810b75c103 network: tc: support more attributes for FQ-CoDel dd1e09971b7d test: add a test case for network-generator 21a925a4ac79 network-generator: allow empty hostname 0baddbd5eef0 test-network: add a test case for FQ 7234b915963c network tc: inroduce FQ - Fair Queue traffic policing eb34f4b3d2a9 sd-netlink: add attributes for FQ ef8863902831 man: document INVOCATION_ID and USER_INVOCATION_ID journal fields 5e13bcdd0391 locale-util: drop weird invisible unicode codepoints accidentally inserted in comment c498df3a7e51 hwdb: trivial indentation fix 8fb82e35dc0d minor: avoid double title b41a3f66c97e docs: make it pretty e8c17dc078ee network: tc: introduce QDiscVTable for future extendability 1f9dd3bfdf0a network: tc: drop unused element 042fc950eafe network: tc: drop unused functions 335498ca57a5 docs: direct to systemd.io version of naming scheme docs 7c4a7c6d13db docs: fix markdown links 471d407eaaea docs: use `` quotes for marking identifiers of some form 955ed5d540fe man: fix typo in net-naming-scheme man page 5d3f5e408196 docs: beef up entrypoint documentation page 4cdca0af1149 docs: place all our markdown docs in rough categories f32d15b0e4f5 man: fix typos (#14304) 92c7593f5e68 network: tc: use typesafe functions to append netlink attributes 42b5f7dd322d sd-netlink: make TCA_OPTIONS take NETLINK_TYPE_UNION e92b60b20f21 ipv4ll: do not reset conflict counter on restart 40821c2ac3a7 test-network: add a test case for fq-codel 4e5ef1491901 network tc: Add support to conkfigure CoDel - Controlled-Delay Active Queue Management algorithm d80810200832 network tc: qdisc parent add support to set ingress 5905d7cf5bc8 tree-wide: use SD_ID128_STRING_MAX where appropriate b5ea030d65e9 id128: introduce ID128_UUID_STRING_MAX for sizing UUID buffers c2d54475c431 man: document pkcs#11 hookup in /etc/crypttab 086697094ec7 cryptsetup: add native pkcs#11 support to cryptsetup f573629c0bba udev: mark all ccid/security devices with a special tag 839fddbe500f shared: add pkcs11-util.[ch] 3f6370198305 shared: add openssl helpers 6047637645ac strv: when growing strv arrays piecemeal actually allocate memory in exponential steps 47ac31f792a8 test-util: add more tests for ALIGN_POWER2 e49e4c33dc96 macro: introduce new GREEDY_ALLOC_ROUND_UP() helper 85c267afa7ce macro: avoid subtraction overflow in ALIGN_POWER2() 886e07a9cf5d test-network: add tests for new TBF settings dcfc23ae7713 network: tc: add more options for TBF 0810e6d787bd test-network: add a test case for SendOption= 83b56c70e6bc network: fix segfault in parsing SendOption= fb4b0465abbd seccomp: real syscall numbers are >= 0 0cab1f197647 Add Cube iWork 11 Stylus 8ee08dc564cc test: do not fail if new device is plugged during enumeration bc942f69aa49 test-network: make test_bind_carrier more stable 6d62ec61b941 network: fix copy and paste mistake 07317d6e343c resolved, networkd: don't resolve the user if not root b076d5d76ddc test-network: add test case for IFB 3295a461b373 network: introduce ifb (Intermediate Functional Block) cec1552ad4e0 sd-netlink: add support for ifb device dc7d3c5fd4cf test-network: add test case for IPv4 DAD 051e77cac119 network: introduce DAD for static address b069c2a3f2b0 shared/seccomp: avoid possibly writing bogus errno code in debug log 2c7b826ddf52 network: do not drop foreign config if interface is in initialized state 6b2a8b80b4bf shared/loop-util: drop inline function with one use ba5450f4119c shared/loop-util: fix leak of fd in error path 1163a2e98a89 shared/loop-util: operate on the right fd 7db054470589 test-network: add tests to verify IPv6MTUBytes 3e8215254359 test-network: disable restart limiting for networkd fd372b1a68a6 test-network: in wait_online() allow a few seconds to reach setup_state befd4b8b60dd test-network: read link attribute at any depth 9dfc1a9339ee test-network: allow specifying only individual drop-in files d236718c167a network: set ipv6 mtu after link-up or device mtu change ab4fae0c8c3f Fix typo (duplicate "or") 14bb274d3fdd networkd: check return value 362c378291e8 cryptsetup: umount encrypted devices before detaching it during shutdown 1dc85eff1d0d crypsetup: introduce x-initrd.attach option 5ebbb45bdee9 TODO: remove obsolete entries bddeb54cbb09 Fix use of unitialized variable in error path d6f1e6607692 growfs: port over to resize_fs() 2b82a99fe0d3 growfs: define main function through macro 49219b5c2a65 seccomp: mmap test results depend on kernel/libseccomp/glibc 5ef3ed97e3c7 seccomp: use per arch shmat_syscall 903659e7b242 seccomp: ensure rules are loaded in seccomp_memory_deny_write_execute bed4668d1dae seccomp: fix multiplexed system calls bf331d87171b network: if /sys is rw, then udev should be around 26208d5b9674 nspawn: do not fail if udev is not running 2e22a54f4e08 Implement SNI when using DNS-over-TLS 6f0245b34276 sd-bus: don't include properties maked as "emit-invalidation" in InterfacesAdded signals 7a77d2a41cb6 sd-bus: add new call sd_bus_message_sensitive() and SD_BUS_VTABLE_SENSITIVE 0ab927913271 test-network: add a test case for SFQ b2340fbb5ab3 network: SFQ cannot be configured with netem or TBF 9942b71089aa network: tc introduce sfq - Stochastic Fairness Queueing 1b628c4f64e9 test-network: add test case for TBF f1dba5556564 network: drop unnecessary headers 6483f04381db network: make network_emulator_fill_message() take NetworkEmulator edc54f2f753b network: rename QDiscs to QDisc 8efb93f02dd6 network: ignore sections which have both NetworkEmulator and TokenBufferFilter settings ba5841b5206d networkd tc: introduce tbf 28937bcc6ca1 shared: add new wrapper for online fs resizing ioctls 24a0b2c0abc0 missing: add XFS magic 6b636c2d2790 main-func: send main exit code to parent via sd_notify() on exit 8987afc4d12c process-util: add new safe_fork() flag for connecting stdout to stderr 7a509acc297a tmpfile-util: modernize mkostemp_safe() a bit e5ea9ed03078 tmpfile-util: if no path is passed to fopen_temporary() make one up a3292ec8d704 user-util: add uid_is_container() for checking whether UID is in container range 6093b2bb05f3 user-util: export is_nologin_shell() so that we can use it elsewhere c0dd3269535b man: document journal rate limit burst multiplier 53caaffdf4a6 string-util: readd string_erase() 282bde106652 memory-util: introduce erase_and_free() helper 9933a4780843 errno-util: add new ERRNO_IS_DISK_SPACE() helper b64cea60275b ordered-set: add ordered_set_first() helper 22810041c220 parse-util: sometimes it is useful to check if a string is a valid integer, but not actually parse it 26601a2a1771 sd-boot: Add a 0.1 second delay before key-probing for showing menu e544601536ac sd-event: refuse running default event loops in any other thread than the one they are default for 8089643328b2 man: document the new sd-event pidfd magic b3508072002c man: mention that SIGCHLD has to be blocked before using sd_event_add_child() 68765d94fec8 man: don't claim we'd unblock the specified signal in sd_event_add_signal() 3ecb3bdc9384 test: add test for pidfd support in sd-event ee880b37c152 sd-event: refuse sd_event_add_child() if SIGCHLD is not blocked d1b75241baa3 sd-event: make use of new signal_is_blocked() helper 90b15e18eef4 signal-util: add new helper signal_is_blocked() f8f3f9263e51 sd-event: add pidfd support 298f466f159e process-util: add helper pidfd_get_pid() 5ead4e85f6b5 missing: add rt_sigqueueinfo() syscall definition 5f152f43d04e missing: define new pidfd syscalls 5a795bff3840 sd-event: (void)ify some epoll_ctl() syscall invocations d1cf20237492 sd-event: drop unnecessary local variable 9f537ae3100f udev: Ensure udev_event_spawn reads stdout a9dfac21ec85 core: reload SELinux label cache on daemon-reload 68d58f38693e pid1: add new kernel cmdline arg systemd.cpu_affinity= 6355715e5b5d Fix DPI for MX Master 2s bluetooth mouse a652f050a786 Create parent directories when creating systemd-private subdirs e813de549b17 network: do not return error but return UINT64_MAX if speed meter is disabled cfd54b6a2e8b Alienware M17xR3 ejectcd button fix 7477451b691d core: swap priority can be negative 09e4b620e7a9 hwdb: Set trackball property for Logitech MX Ergo (#14231) 33ebda2e81aa networkctl: fix to show BSSID ff757c9d2941 hibernate-resume-generator: wait "infinitely" for the resume device 7cecc563163f cryptsetup-generator: unconfuse writing of the device timeout 2fec5854baa6 systemctl: enhance message about kexec missing kernel 6a2dc6a040f7 TODO: remove obsolete entries 23e5e79a51f9 initrd: fix systemd.debug-shell & friends 1e904320aacb Fixup typo in NEWS 10c1b18888b4 valgrind: temporarily handle that valgrind still doesn't know LOOP_GET_STATUS64 50d046993be9 loop-util: if we fail to fully set up a loop device, detach it again b26c39ad2c65 loop-util: fill in the loopback number, even a posteriori f1443709e0c2 loop-util: optionally also resize partitions 441ec80468d1 loop-util: add api for locking the block device with flock() c37878fcedd9 loop-util: allow refreshing offset ed9eeb7b0b50 loop-util: allow creating loopback block devices with offset/length 9dabc4fda574 loop-util: add API to refresh loopback device size and opening existing loopback block devices e08f94acf589 loop-util: accept loopback flags when creating loopback device 2d8143048bc6 json: add new output flag JSON_PRETTY_AUTO 19a209cc710a json: add const string dispatcher e4defdc4b02f json: teach json_build() to build arrays from C arrays of JsonVariant a42ef715a2c6 json: add more dispatch helpers a832b08e6e1b json: add json_variant_set_field_integer() and json_variant_set_field_boolean() helpers faca141c5fb3 json: add json_variant_unbase64() helper 0b1f2e8a0617 json: add new flag for forcing a flush after dumping json data to file 0ac0787e30f0 json: add explicit log call for ENOMEM 3dd1b600b8b7 json: permit 'null' as a way to reset tri-states to default aafa52ab8370 json: add ability to generate empty arrays/objects in json builder 886b0c93a8bc json: allow putting together base64 fields with json_build() 21e215110771 json: add new helper json_variant_append_array() cc164891da29 json: add new helper json_variant_new_base64() b7fc90a2e63f json: add concept of normalization ca409a59c8ee json: add json_variant_merge() helper 15f1fb3e3e3f json: add json_variant_set_field_string() and json_variant_set_field_unsigned() a7f8c9ce60f9 nspawn-oci: use new json_variant_strv() helper 22f14d6b0287 json: add json_variant_strv() helper that converts a json variant to an strv ba23dbf1ebd9 json: optionally, make string checks stricter when dispatching strings d642f640bf39 json: add flags parameter to json_parse_file(), for parsing "sensitive" data f325aaf34175 json: add json_parse_file_at() helper 83bc6cb79233 json: add a new "sensitive" flags for JsonVariant objects 78a41236e40f json: add new json_variant_set_field() helper f2ff34ff2aaa json: add new API json_variant_filter() for dropping fields from objects e787b211a5aa json: add new json_variant_is_blank_{object,array}() helpers 07737617a18d json: beef up strv parser to also accept a single string instead of an array of strings 95244ceb9c82 fileio: add WRITE_STRING_FILE_MODE_0600 flag for writing files 8241f785f414 fileio: add 'dir_fd' parameter to read_full_file_full() 0a38e6b9a37b fileio: add an openat() flavour for fopen() d0d7f11ca27b hwdb: Add accel orientation quirk for Teclast X89 tablet 3b681ace37e2 hwdb: Sort 60-sensor.hwdb Teclast entries alphabetically 6d8f06368bc0 semaphore: switch branch to debian/master 3d92aa4596a7 gpt-auto-generator: rename function for clarity 46c41478c933 tree-wise: standarize on "auto-detection" spelling 607ebf2bd28f bootlctl: show LoaderDevicePartUUID information in status b50a3a156502 gpt-auto-generator: make it easier to notice if boot loader support is missing 1fac34b94121 gpt-auto-generator: use write_drop_in_format() helper and downgrade failure 074cdb953bd2 gpt-auto-generator: improve debug messages a bit 5ecb131d9479 network: include NLMSGERR_ATTR_MSG attribute in error message e4a1e68d7ab3 sd-netlink: support NLMSGERR_ATTR_MSG 0e7e8544712f update TODO 2b1daf24dc82 man: document initrd.target 8755dbad5b2a pid1: use initrd.target in the initramfs by default 9fe6f5cc1668 gpt-auto-generator: move functions around 80e7c8408142 tmpfiles: create with correct MAC label on option C aeec5efab58a copy: add flag COPY_MAC_CREATE to create with correct label 6e86b24db3c5 tree-wide: normalize includes of public headers fe7a6da8c5a9 core: use SPECIAL_DEFAULT_TARGET more 943800f4e772 execute: Call capability_ambient_set_apply even if ambient set is 0 155a6234ea2c test-capability: Modify ambient capability tests to test clearing caps 82d832b435a0 basic: Drop ambient inherited capabilities by default f4331d0db28c shared/install: warn about unkown sections in unit files 130b812f9d68 network: warn about unknown sections when parsing .netdev files ddeb3f5d4b7c shared/conf-parser: allow sections to be silently ignored with new -Section syntax 94a404cb0357 shared/conf-parser: document what the flags do f9761a89a84f shared/conf-parser: turn CONFIG_PARSE_REFUSE_BOM flag into a local variable 15b82eecb646 boot: Deduplicate old-style loader entries. ae474efc3f65 boot: Update bootspec.c to match previous changes. 10d0024a07c8 boot: Improve EFISTUB name and version detection. 6cd12ebcfe45 boot: Retain ".conf" suffix for loader config IDs. 65901c0fd164 boot: Ignore EFISTUB binaries starting with "auto-". 7fa23ab646a0 boot: Make EFISTUB IDs use binaries' filenames. Signed-off-by: Alex Kiernan --- This commit doesn't (currently) include a revert of 097537f07a2f ("job: Don't mark as redundant if deps are relevant"), which both Fedora and Debian have: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953670 https://bugzilla.redhat.com/show_bug.cgi?id=1807771 https://github.com/systemd/systemd/issues/15091 The prior commits to psplash and the testsuite fix the issues which this commit exposes and we probably want to keep both of those changes, but may still want to revert 097537f07a2f. ...temd-boot_244.3.bb => systemd-boot_245.bb} | 0 ...temd-conf_244.3.bb => systemd-conf_245.bb} | 0 meta/recipes-core/systemd/systemd.inc | 4 +- .../systemd/0001-Handle-missing-gshadow.patch | 171 ++++++++++++++++++ ...tall-dependency-links-at-install-tim.patch | 14 +- ...-not-disable-buffer-in-writing-files.patch | 46 ++--- ...002-don-t-use-glibc-specific-qsort_r.patch | 12 +- ...k-parse_printf_format-implementation.patch | 10 +- ...set-util.h-add-__cpu_mask-definition.patch | 8 +- ...missing.h-check-for-missing-strndupa.patch | 93 ++++++---- .../0006-Include-netinet-if_ether.h.patch | 41 +++-- ..._register_atfork-for-non-glibc-build.patch | 6 +- ...11-Use-uintmax_t-for-handling-rlim_t.patch | 10 +- ...sable-tests-for-missing-typedefs-in-.patch | 8 +- ...uffering-when-writing-to-oom_score_a.patch | 8 +- .../{systemd_244.3.bb => systemd_245.bb} | 11 +- 16 files changed, 317 insertions(+), 125 deletions(-) rename meta/recipes-core/systemd/{systemd-boot_244.3.bb => systemd-boot_245.bb} (100%) rename meta/recipes-core/systemd/{systemd-conf_244.3.bb => systemd-conf_245.bb} (100%) create mode 100644 meta/recipes-core/systemd/systemd/0001-Handle-missing-gshadow.patch rename meta/recipes-core/systemd/{systemd_244.3.bb => systemd_245.bb} (99%) diff --git a/meta/recipes-core/systemd/systemd-boot_244.3.bb b/meta/recipes-core/systemd/systemd-boot_245.bb similarity index 100% rename from meta/recipes-core/systemd/systemd-boot_244.3.bb rename to meta/recipes-core/systemd/systemd-boot_245.bb diff --git a/meta/recipes-core/systemd/systemd-conf_244.3.bb b/meta/recipes-core/systemd/systemd-conf_245.bb similarity index 100% rename from meta/recipes-core/systemd/systemd-conf_244.3.bb rename to meta/recipes-core/systemd/systemd-conf_245.bb diff --git a/meta/recipes-core/systemd/systemd.inc b/meta/recipes-core/systemd/systemd.inc index e73b397b5d64..d70884ce6cb2 100644 --- a/meta/recipes-core/systemd/systemd.inc +++ b/meta/recipes-core/systemd/systemd.inc @@ -14,8 +14,8 @@ LICENSE = "GPLv2 & LGPLv2.1" LIC_FILES_CHKSUM = "file://LICENSE.GPL2;md5=751419260aa954499f7abaabaa882bbe \ file://LICENSE.LGPL2.1;md5=4fbd65380cdd255951079008b364516c" -SRCREV = "b7ed902b2394f94e7f1fbe6c3194b5cd9a9429e6" -SRCBRANCH = "v244-stable" +SRCREV = "ea500ac513cf51bcb79a5666f1519499d029428f" +SRCBRANCH = "v245-stable" SRC_URI = "git://github.com/systemd/systemd-stable.git;protocol=git;branch=${SRCBRANCH}" S = "${WORKDIR}/git" diff --git a/meta/recipes-core/systemd/systemd/0001-Handle-missing-gshadow.patch b/meta/recipes-core/systemd/systemd/0001-Handle-missing-gshadow.patch new file mode 100644 index 000000000000..26a597d45b60 --- /dev/null +++ b/meta/recipes-core/systemd/systemd/0001-Handle-missing-gshadow.patch @@ -0,0 +1,171 @@ +From ef9580ea1e2f1e57af3c7dcb0ec392ba8dbb5c8d Mon Sep 17 00:00:00 2001 +From: Alex Kiernan +Date: Tue, 10 Mar 2020 11:05:20 +0000 +Subject: [PATCH] Handle missing gshadow + +gshadow usage is now present in the userdb code. Mask all uses of it to +allow compilation on musl + +Upstream-Status: Inappropriate [musl specific] +Signed-off-by: Alex Kiernan +--- + src/shared/group-record-nss.c | 20 ++++++++++++++++++++ + src/shared/group-record-nss.h | 4 ++++ + src/shared/userdb.c | 6 ++++++ + 3 files changed, 30 insertions(+) + +diff --git a/src/shared/group-record-nss.c b/src/shared/group-record-nss.c +index 77924f1c4067..c64490253ff3 100644 +--- a/src/shared/group-record-nss.c ++++ b/src/shared/group-record-nss.c +@@ -19,8 +19,10 @@ int nss_group_to_group_record( + if (isempty(grp->gr_name)) + return -EINVAL; + ++#if ENABLE_GSHADOW + if (sgrp && !streq_ptr(sgrp->sg_namp, grp->gr_name)) + return -EINVAL; ++#endif + + g = group_record_new(); + if (!g) +@@ -36,6 +38,7 @@ int nss_group_to_group_record( + + g->gid = grp->gr_gid; + ++#if ENABLE_GSHADOW + if (sgrp) { + if (hashed_password_valid(sgrp->sg_passwd)) { + g->hashed_password = strv_new(sgrp->sg_passwd); +@@ -51,6 +54,7 @@ int nss_group_to_group_record( + if (!g->administrators) + return -ENOMEM; + } ++#endif + + r = json_build(&g->json, JSON_BUILD_OBJECT( + JSON_BUILD_PAIR("groupName", JSON_BUILD_STRING(g->group_name)), +@@ -76,6 +80,7 @@ int nss_sgrp_for_group(const struct group *grp, struct sgrp *ret_sgrp, char **re + assert(ret_sgrp); + assert(ret_buffer); + ++#if ENABLE_GSHADOW + for (;;) { + _cleanup_free_ char *buf = NULL; + struct sgrp sgrp, *result; +@@ -104,6 +109,9 @@ int nss_sgrp_for_group(const struct group *grp, struct sgrp *ret_sgrp, char **re + buflen *= 2; + buf = mfree(buf); + } ++#else ++ return -ESRCH; ++#endif + } + + int nss_group_record_by_name(const char *name, GroupRecord **ret) { +@@ -111,7 +119,9 @@ int nss_group_record_by_name(const char *name, GroupRecord **ret) { + struct group grp, *result; + bool incomplete = false; + size_t buflen = 4096; ++#if ENABLE_GSHADOW + struct sgrp sgrp; ++#endif + int r; + + assert(name); +@@ -141,6 +151,7 @@ int nss_group_record_by_name(const char *name, GroupRecord **ret) { + buf = mfree(buf); + } + ++#if ENABLE_GSHADOW + r = nss_sgrp_for_group(result, &sgrp, &sbuf); + if (r < 0) { + log_debug_errno(r, "Failed to do shadow lookup for group %s, ignoring: %m", result->gr_name); +@@ -148,6 +159,9 @@ int nss_group_record_by_name(const char *name, GroupRecord **ret) { + } + + r = nss_group_to_group_record(result, r >= 0 ? &sgrp : NULL, ret); ++#else ++ r = nss_group_to_group_record(result, NULL, ret); ++#endif + if (r < 0) + return r; + +@@ -160,7 +174,9 @@ int nss_group_record_by_gid(gid_t gid, GroupRecord **ret) { + struct group grp, *result; + bool incomplete = false; + size_t buflen = 4096; ++#if ENABLE_GSHADOW + struct sgrp sgrp; ++#endif + int r; + + assert(ret); +@@ -188,6 +204,7 @@ int nss_group_record_by_gid(gid_t gid, GroupRecord **ret) { + buf = mfree(buf); + } + ++#if ENABLE_GSHADOW + r = nss_sgrp_for_group(result, &sgrp, &sbuf); + if (r < 0) { + log_debug_errno(r, "Failed to do shadow lookup for group %s, ignoring: %m", result->gr_name); +@@ -195,6 +212,9 @@ int nss_group_record_by_gid(gid_t gid, GroupRecord **ret) { + } + + r = nss_group_to_group_record(result, r >= 0 ? &sgrp : NULL, ret); ++#else ++ r = nss_group_to_group_record(result, NULL, ret); ++#endif + if (r < 0) + return r; + +diff --git a/src/shared/group-record-nss.h b/src/shared/group-record-nss.h +index 38b2995178ff..d7d95c44cf11 100644 +--- a/src/shared/group-record-nss.h ++++ b/src/shared/group-record-nss.h +@@ -2,7 +2,11 @@ + #pragma once + + #include ++#if ENABLE_GSHADOW + #include ++#else ++struct sgrp; ++#endif + + #include "group-record.h" + +diff --git a/src/shared/userdb.c b/src/shared/userdb.c +index 92f8796768d7..5d912862f85c 100644 +--- a/src/shared/userdb.c ++++ b/src/shared/userdb.c +@@ -924,13 +924,16 @@ int groupdb_iterator_get(UserDBIterator *iterator, GroupRecord **ret) { + if (gr) { + _cleanup_free_ char *buffer = NULL; + bool incomplete = false; ++#if ENABLE_GSHADOW + struct sgrp sgrp; ++#endif + + if (streq_ptr(gr->gr_name, "root")) + iterator->synthesize_root = false; + if (gr->gr_gid == GID_NOBODY) + iterator->synthesize_nobody = false; + ++#if ENABLE_GSHADOW + r = nss_sgrp_for_group(gr, &sgrp, &buffer); + if (r < 0) { + log_debug_errno(r, "Failed to acquire shadow entry for group %s, ignoring: %m", gr->gr_name); +@@ -938,6 +941,9 @@ int groupdb_iterator_get(UserDBIterator *iterator, GroupRecord **ret) { + } + + r = nss_group_to_group_record(gr, r >= 0 ? &sgrp : NULL, ret); ++#else ++ r = nss_group_to_group_record(gr, NULL, ret); ++#endif + if (r < 0) + return r; + +-- +2.17.1 + diff --git a/meta/recipes-core/systemd/systemd/0001-binfmt-Don-t-install-dependency-links-at-install-tim.patch b/meta/recipes-core/systemd/systemd/0001-binfmt-Don-t-install-dependency-links-at-install-tim.patch index 6eaaec71c533..d098084b2ec6 100644 --- a/meta/recipes-core/systemd/systemd/0001-binfmt-Don-t-install-dependency-links-at-install-tim.patch +++ b/meta/recipes-core/systemd/systemd/0001-binfmt-Don-t-install-dependency-links-at-install-tim.patch @@ -1,4 +1,4 @@ -From c73a87871df31b4f8d96c9d443759c6f702935f6 Mon Sep 17 00:00:00 2001 +From e9c993816077c1ae67d25d464f2ece2a090f30b8 Mon Sep 17 00:00:00 2001 From: Chen Qi Date: Thu, 21 Feb 2019 16:23:24 +0800 Subject: [PATCH] binfmt: Don't install dependency links at install time for @@ -26,10 +26,10 @@ Signed-off-by: Scott Murray 3 files changed, 9 insertions(+), 4 deletions(-) diff --git a/units/meson.build b/units/meson.build -index 6a3a0d0dea22..bbb1b78618c3 100644 +index ea91f0cc9ea7..25186f88dfeb 100644 --- a/units/meson.build +++ b/units/meson.build -@@ -46,8 +46,7 @@ units = [ +@@ -52,8 +52,7 @@ units = [ ['poweroff.target', '', 'runlevel0.target'], ['printer.target', ''], @@ -39,16 +39,16 @@ index 6a3a0d0dea22..bbb1b78618c3 100644 ['proc-sys-fs-binfmt_misc.mount', 'ENABLE_BINFMT'], ['reboot.target', '', 'runlevel6.target ctrl-alt-del.target'], -@@ -130,8 +129,7 @@ in_units = [ - ['systemd-ask-password-console.service', ''], - ['systemd-ask-password-wall.service', ''], +@@ -161,8 +160,7 @@ in_units = [ + ['rc-local.service', 'HAVE_SYSV_COMPAT'], + ['rescue.service', ''], ['systemd-backlight at .service', 'ENABLE_BACKLIGHT'], - ['systemd-binfmt.service', 'ENABLE_BINFMT', - 'sysinit.target.wants/'], + ['systemd-binfmt.service', 'ENABLE_BINFMT'], ['systemd-bless-boot.service', 'ENABLE_EFI HAVE_BLKID'], ['systemd-boot-check-no-failures.service', ''], - ['systemd-boot-system-token.service', 'ENABLE_EFI', + ['systemd-coredump at .service', 'ENABLE_COREDUMP'], diff --git a/units/proc-sys-fs-binfmt_misc.automount b/units/proc-sys-fs-binfmt_misc.automount index 30a6bc991844..4231f3b70fe9 100644 --- a/units/proc-sys-fs-binfmt_misc.automount diff --git a/meta/recipes-core/systemd/systemd/0001-do-not-disable-buffer-in-writing-files.patch b/meta/recipes-core/systemd/systemd/0001-do-not-disable-buffer-in-writing-files.patch index f1c7181ef971..4eeec7b7dac1 100644 --- a/meta/recipes-core/systemd/systemd/0001-do-not-disable-buffer-in-writing-files.patch +++ b/meta/recipes-core/systemd/systemd/0001-do-not-disable-buffer-in-writing-files.patch @@ -1,4 +1,4 @@ -From f4a0caaea346b70cf5064f9159a53a1b8020071e Mon Sep 17 00:00:00 2001 +From f92fd7e77ed5aab2dda01a20e6891c37f09415d3 Mon Sep 17 00:00:00 2001 From: Chen Qi Date: Fri, 1 Mar 2019 15:22:15 +0800 Subject: [PATCH] do not disable buffer in writing files @@ -167,10 +167,10 @@ index 7ff844c78c3a..5c5721d7c2f7 100644 STRV_FOREACH(f, files) { k = apply_file(*f, true); diff --git a/src/core/main.c b/src/core/main.c -index c24b696b1663..195be7d2df0d 100644 +index 3c6b66e89c8e..c39ebe56a5b3 100644 --- a/src/core/main.c +++ b/src/core/main.c -@@ -1303,7 +1303,7 @@ static int bump_unix_max_dgram_qlen(void) { +@@ -1312,7 +1312,7 @@ static int bump_unix_max_dgram_qlen(void) { if (v >= DEFAULT_UNIX_MAX_DGRAM_QLEN) return 0; @@ -179,7 +179,7 @@ index c24b696b1663..195be7d2df0d 100644 if (r < 0) return log_full_errno(IN_SET(r, -EROFS, -EPERM, -EACCES) ? LOG_DEBUG : LOG_WARNING, r, "Failed to bump AF_UNIX datagram queue length, ignoring: %m"); -@@ -1527,7 +1527,7 @@ static void initialize_core_pattern(bool skip_setup) { +@@ -1536,7 +1536,7 @@ static void initialize_core_pattern(bool skip_setup) { if (getpid_cached() != 1) return; @@ -228,7 +228,7 @@ index 17e7cd1a009b..87a766771663 100644 log_error_errno(r, "Failed to write '%s' to /sys/power/resume: %m", major_minor); return EXIT_FAILURE; diff --git a/src/libsystemd/sd-device/sd-device.c b/src/libsystemd/sd-device/sd-device.c -index f35612fe12bc..20351bf7fa70 100644 +index 1f2451f8e1b4..3f676ec2841a 100644 --- a/src/libsystemd/sd-device/sd-device.c +++ b/src/libsystemd/sd-device/sd-device.c @@ -1849,7 +1849,7 @@ _public_ int sd_device_set_sysattr_value(sd_device *device, const char *sysattr, @@ -241,10 +241,10 @@ index f35612fe12bc..20351bf7fa70 100644 if (r == -ELOOP) return -EINVAL; diff --git a/src/login/logind-dbus.c b/src/login/logind-dbus.c -index 69b59948786f..b4973c596d48 100644 +index 52a7ea3c77e9..9703de0dabee 100644 --- a/src/login/logind-dbus.c +++ b/src/login/logind-dbus.c -@@ -1322,7 +1322,7 @@ static int trigger_device(Manager *m, sd_device *d) { +@@ -1339,7 +1339,7 @@ static int trigger_device(Manager *m, sd_device *d) { if (!t) return -ENOMEM; @@ -267,10 +267,10 @@ index f5048d9473cb..b6383ab5c97e 100644 log_error_errno(r, "Failed to move process: %m"); goto finish; diff --git a/src/nspawn/nspawn.c b/src/nspawn/nspawn.c -index 873a76596f0b..4e496548bb94 100644 +index 734dee1130e0..71add9a055d2 100644 --- a/src/nspawn/nspawn.c +++ b/src/nspawn/nspawn.c -@@ -2425,7 +2425,7 @@ static int reset_audit_loginuid(void) { +@@ -2440,7 +2440,7 @@ static int reset_audit_loginuid(void) { if (streq(p, "4294967295")) return 0; @@ -279,7 +279,7 @@ index 873a76596f0b..4e496548bb94 100644 if (r < 0) { log_error_errno(r, "Failed to reset audit login UID. This probably means that your kernel is too\n" -@@ -3633,13 +3633,13 @@ static int setup_uid_map(pid_t pid) { +@@ -3665,13 +3665,13 @@ static int setup_uid_map(pid_t pid) { xsprintf(uid_map, "/proc/" PID_FMT "/uid_map", pid); xsprintf(line, UID_FMT " " UID_FMT " " UID_FMT "\n", 0, arg_uid_shift, arg_uid_range); @@ -318,10 +318,10 @@ index e8398cbde5ba..ba682ec0c9e7 100644 log_debug_errno(r, "Failed to %s controller %s for %s (%s): %m", FLAGS_SET(mask, bit) ? "enable" : "disable", n, p, fs); diff --git a/src/shared/sysctl-util.c b/src/shared/sysctl-util.c -index 12fb3ef7ea0e..132ac847c091 100644 +index 8543dbd2d05f..76162599817e 100644 --- a/src/shared/sysctl-util.c +++ b/src/shared/sysctl-util.c -@@ -87,7 +87,7 @@ int sysctl_write_ip_property(int af, const char *ifname, const char *property, c +@@ -93,7 +93,7 @@ int sysctl_write_ip_property(int af, const char *ifname, const char *property, c log_debug("Setting '%s' to '%s'", p, value); @@ -331,28 +331,28 @@ index 12fb3ef7ea0e..132ac847c091 100644 int sysctl_read(const char *property, char **content) { diff --git a/src/sleep/sleep.c b/src/sleep/sleep.c -index 89b80367f8f4..33dbb21364d0 100644 +index fbfddc0262fc..7cc2902154e9 100644 --- a/src/sleep/sleep.c +++ b/src/sleep/sleep.c -@@ -45,7 +45,7 @@ static int write_hibernate_location_info(const HibernateLocation *hibernate_loca +@@ -47,7 +47,7 @@ static int write_hibernate_location_info(const HibernateLocation *hibernate_loca assert(hibernate_location->swap); - assert(hibernate_location->resume); -- r = write_string_file("/sys/power/resume", hibernate_location->resume, WRITE_STRING_FILE_DISABLE_BUFFER); -+ r = write_string_file("/sys/power/resume", hibernate_location->resume, 0); + xsprintf(resume_str, "%u:%u", major(hibernate_location->devno), minor(hibernate_location->devno)); +- r = write_string_file("/sys/power/resume", resume_str, WRITE_STRING_FILE_DISABLE_BUFFER); ++ r = write_string_file("/sys/power/resume", resume_str, 0); if (r < 0) return log_debug_errno(r, "Failed to write partition device to /sys/power/resume for '%s': '%s': %m", - hibernate_location->swap->device, hibernate_location->resume); -@@ -72,7 +72,7 @@ static int write_hibernate_location_info(const HibernateLocation *hibernate_loca + hibernate_location->swap->device, resume_str); +@@ -74,7 +74,7 @@ static int write_hibernate_location_info(const HibernateLocation *hibernate_loca } - xsprintf(offset_str, "%" PRIu64, hibernate_location->resume_offset); + xsprintf(offset_str, "%" PRIu64, hibernate_location->offset); - r = write_string_file("/sys/power/resume_offset", offset_str, WRITE_STRING_FILE_DISABLE_BUFFER); + r = write_string_file("/sys/power/resume_offset", offset_str, 0); if (r < 0) return log_debug_errno(r, "Failed to write swap file offset to /sys/power/resume_offset for '%s': '%s': %m", hibernate_location->swap->device, offset_str); -@@ -89,7 +89,7 @@ static int write_mode(char **modes) { +@@ -91,7 +91,7 @@ static int write_mode(char **modes) { STRV_FOREACH(mode, modes) { int k; @@ -361,7 +361,7 @@ index 89b80367f8f4..33dbb21364d0 100644 if (k >= 0) return 0; -@@ -108,7 +108,7 @@ static int write_state(FILE **f, char **states) { +@@ -110,7 +110,7 @@ static int write_state(FILE **f, char **states) { STRV_FOREACH(state, states) { int k; @@ -384,7 +384,7 @@ index 60c68b5029cf..fdca03d3d42c 100644 bool ignore = IN_SET(r, -ENOENT, -EACCES, -ENODEV, -EROFS); diff --git a/src/udev/udevd.c b/src/udev/udevd.c -index 7678331897f5..6871cde7aa65 100644 +index ca65474f2763..38780681431a 100644 --- a/src/udev/udevd.c +++ b/src/udev/udevd.c @@ -1089,7 +1089,7 @@ static int synthesize_change_one(sd_device *dev, const char *syspath) { diff --git a/meta/recipes-core/systemd/systemd/0002-don-t-use-glibc-specific-qsort_r.patch b/meta/recipes-core/systemd/systemd/0002-don-t-use-glibc-specific-qsort_r.patch index 6b85ff0f8915..a5e41bfabf23 100644 --- a/meta/recipes-core/systemd/systemd/0002-don-t-use-glibc-specific-qsort_r.patch +++ b/meta/recipes-core/systemd/systemd/0002-don-t-use-glibc-specific-qsort_r.patch @@ -1,4 +1,4 @@ -From 49501c80d32c1bc5ecb07f40c324feb82af0b057 Mon Sep 17 00:00:00 2001 +From 3eb12a6ba0bce149717eaabeb1505d379b3d705a Mon Sep 17 00:00:00 2001 From: Chen Qi Date: Mon, 25 Feb 2019 13:41:41 +0800 Subject: [PATCH] don't use glibc-specific qsort_r @@ -40,7 +40,7 @@ index e029f8646eb0..27d68b341cf3 100644 - qsort_r_safe((p), (n), sizeof((p)[0]), (__compar_d_fn_t) _func_, userdata); \ - }) diff --git a/src/libsystemd/sd-hwdb/hwdb-util.c b/src/libsystemd/sd-hwdb/hwdb-util.c -index c83575c7c876..72f8f3a05048 100644 +index d790e8fd0b19..42e0fd7c9b3c 100644 --- a/src/libsystemd/sd-hwdb/hwdb-util.c +++ b/src/libsystemd/sd-hwdb/hwdb-util.c @@ -128,9 +128,13 @@ static void trie_free(struct trie *trie) { @@ -84,10 +84,10 @@ index c83575c7c876..72f8f3a05048 100644 } diff --git a/src/shared/format-table.c b/src/shared/format-table.c -index 4617ae8badc4..17d6b9616256 100644 +index 425013046491..33c1c5a12d43 100644 --- a/src/shared/format-table.c +++ b/src/shared/format-table.c -@@ -1109,31 +1109,33 @@ static int cell_data_compare(TableData *a, size_t index_a, TableData *b, size_t +@@ -1164,31 +1164,33 @@ static int cell_data_compare(TableData *a, size_t index_a, TableData *b, size_t return CMP(index_a, index_b); } @@ -131,7 +131,7 @@ index 4617ae8badc4..17d6b9616256 100644 } /* Order identical lines by the order there were originally added in */ -@@ -1533,7 +1535,12 @@ int table_print(Table *t, FILE *f) { +@@ -1690,7 +1692,12 @@ int table_print(Table *t, FILE *f) { for (i = 0; i < n_rows; i++) sorted[i] = i * t->n_columns; @@ -145,7 +145,7 @@ index 4617ae8badc4..17d6b9616256 100644 } if (t->display_map) -@@ -1997,7 +2004,12 @@ int table_to_json(Table *t, JsonVariant **ret) { +@@ -2236,7 +2243,12 @@ int table_to_json(Table *t, JsonVariant **ret) { for (i = 0; i < n_rows; i++) sorted[i] = i * t->n_columns; diff --git a/meta/recipes-core/systemd/systemd/0004-add-fallback-parse_printf_format-implementation.patch b/meta/recipes-core/systemd/systemd/0004-add-fallback-parse_printf_format-implementation.patch index 71e52c49674e..0dea93327025 100644 --- a/meta/recipes-core/systemd/systemd/0004-add-fallback-parse_printf_format-implementation.patch +++ b/meta/recipes-core/systemd/systemd/0004-add-fallback-parse_printf_format-implementation.patch @@ -1,4 +1,4 @@ -From 142dcaef0d24a78d3c0c94168b66fdf234497e97 Mon Sep 17 00:00:00 2001 +From 8af168cefca01f8f2da336f1c82620c284dc74f2 Mon Sep 17 00:00:00 2001 From: Chen Qi Date: Mon, 25 Feb 2019 14:04:21 +0800 Subject: [PATCH] add fallback parse_printf_format implementation @@ -23,10 +23,10 @@ Signed-off-by: Scott Murray create mode 100644 src/basic/parse-printf-format.h diff --git a/meson.build b/meson.build -index 21d6968abdf4..bab0bf84806c 100644 +index fc216d22da24..a25996803d64 100644 --- a/meson.build +++ b/meson.build -@@ -628,6 +628,7 @@ endif +@@ -640,6 +640,7 @@ endif foreach header : ['crypt.h', 'linux/memfd.h', 'linux/vm_sockets.h', @@ -35,10 +35,10 @@ index 21d6968abdf4..bab0bf84806c 100644 'valgrind/memcheck.h', 'valgrind/valgrind.h', diff --git a/src/basic/meson.build b/src/basic/meson.build -index f70d1b8bf8a0..4cd57373e10d 100644 +index ccb22e159505..25c77ea6bc0e 100644 --- a/src/basic/meson.build +++ b/src/basic/meson.build -@@ -311,6 +311,11 @@ foreach item : [['af', af_list_txt, 'af', ''], +@@ -313,6 +313,11 @@ foreach item : [['af', af_list_txt, 'af', ''], endforeach basic_sources += generated_gperf_headers diff --git a/meta/recipes-core/systemd/systemd/0004-src-shared-cpu-set-util.h-add-__cpu_mask-definition.patch b/meta/recipes-core/systemd/systemd/0004-src-shared-cpu-set-util.h-add-__cpu_mask-definition.patch index 685df01a10ee..d394444c1c6e 100644 --- a/meta/recipes-core/systemd/systemd/0004-src-shared-cpu-set-util.h-add-__cpu_mask-definition.patch +++ b/meta/recipes-core/systemd/systemd/0004-src-shared-cpu-set-util.h-add-__cpu_mask-definition.patch @@ -1,4 +1,4 @@ -From 6883ffc99168056101c667c6421f8353d5ad675a Mon Sep 17 00:00:00 2001 +From dbe8b3ee45580defeefcac929b897c5437ffc50b Mon Sep 17 00:00:00 2001 From: Scott Murray Date: Fri, 13 Sep 2019 19:26:27 -0400 Subject: [PATCH] Handle __cpu_mask usage @@ -38,7 +38,7 @@ index 27812dfd5923..0ab40731ea93 100644 typedef struct CPUSet { cpu_set_t *set; diff --git a/src/test/test-sizeof.c b/src/test/test-sizeof.c -index a710db5370b8..d1601ad9292d 100644 +index c65062d2562c..8b6eefa9cdae 100644 --- a/src/test/test-sizeof.c +++ b/src/test/test-sizeof.c @@ -1,6 +1,5 @@ @@ -47,8 +47,8 @@ index a710db5370b8..d1601ad9292d 100644 -#include #include #include - -@@ -8,6 +7,7 @@ + #include +@@ -10,6 +9,7 @@ #include #include "time-util.h" diff --git a/meta/recipes-core/systemd/systemd/0005-src-basic-missing.h-check-for-missing-strndupa.patch b/meta/recipes-core/systemd/systemd/0005-src-basic-missing.h-check-for-missing-strndupa.patch index aa4bb063c92d..ca4f0d5d623f 100644 --- a/meta/recipes-core/systemd/systemd/0005-src-basic-missing.h-check-for-missing-strndupa.patch +++ b/meta/recipes-core/systemd/systemd/0005-src-basic-missing.h-check-for-missing-strndupa.patch @@ -1,4 +1,4 @@ -From 9597196234a0ccf30d7f65cf185a8c24cb3158b3 Mon Sep 17 00:00:00 2001 +From 85dcaad8f38521ec3dc580794072b601900eed84 Mon Sep 17 00:00:00 2001 From: Chen Qi Date: Mon, 25 Feb 2019 14:18:21 +0800 Subject: [PATCH] src/basic/missing.h: check for missing strndupa @@ -39,6 +39,7 @@ Signed-off-by: Alex Kiernan src/coredump/coredump-vacuum.c | 1 + src/journal-remote/journal-remote-main.c | 1 + src/journal/journalctl.c | 1 + + src/journal/sd-journal.c | 1 + src/libsystemd/sd-bus/bus-message.c | 1 + src/libsystemd/sd-bus/bus-objects.c | 1 + src/libsystemd/sd-bus/bus-socket.c | 1 + @@ -65,16 +66,16 @@ Signed-off-by: Alex Kiernan src/udev/udev-builtin-path_id.c | 1 + src/udev/udev-event.c | 1 + src/udev/udev-rules.c | 1 + - 48 files changed, 59 insertions(+) + 49 files changed, 60 insertions(+) diff --git a/meson.build b/meson.build -index bab0bf84806c..f4e1736cf09e 100644 +index a25996803d64..72b305b5ab58 100644 --- a/meson.build +++ b/meson.build -@@ -517,6 +517,7 @@ foreach ident : [ - #include '''], - ['get_mempolicy', '''#include - #include '''], +@@ -529,6 +529,7 @@ foreach ident : [ + #include + #include + #include '''], + ['strndupa' , '''#include '''], ] @@ -160,7 +161,7 @@ index fa682d4c438e..37902551490a 100644 int mkdir_safe_internal(const char *path, mode_t mode, uid_t uid, gid_t gid, MkdirFlags flags, mkdir_func_t _mkdir) { struct stat st; diff --git a/src/basic/parse-util.c b/src/basic/parse-util.c -index aec6099c9cc1..744b9b134ce4 100644 +index e0094b0f370a..00da6518124b 100644 --- a/src/basic/parse-util.c +++ b/src/basic/parse-util.c @@ -18,6 +18,7 @@ @@ -172,7 +173,7 @@ index aec6099c9cc1..744b9b134ce4 100644 int parse_boolean(const char *v) { if (!v) diff --git a/src/basic/proc-cmdline.c b/src/basic/proc-cmdline.c -index d3d99d9a7f90..e0b9efad03a2 100644 +index 1af58717c686..c1020f4611d4 100644 --- a/src/basic/proc-cmdline.c +++ b/src/basic/proc-cmdline.c @@ -15,6 +15,7 @@ @@ -196,7 +197,7 @@ index 7aaf95bfced2..da7e836f143e 100644 int procfs_tasks_get_limit(uint64_t *ret) { _cleanup_free_ char *value = NULL; diff --git a/src/basic/selinux-util.c b/src/basic/selinux-util.c -index f35e760233be..e4b0a8aa445e 100644 +index 1095cb426cce..806ef4bd97a9 100644 --- a/src/basic/selinux-util.c +++ b/src/basic/selinux-util.c @@ -26,6 +26,7 @@ @@ -206,9 +207,9 @@ index f35e760233be..e4b0a8aa445e 100644 +#include "missing_stdlib.h" #if HAVE_SELINUX - DEFINE_TRIVIAL_CLEANUP_FUNC(char*, freecon); + DEFINE_TRIVIAL_CLEANUP_FUNC(context_t, context_free); diff --git a/src/basic/time-util.c b/src/basic/time-util.c -index bfe2c60da173..d7ef30d2fe52 100644 +index 105584e2e72f..eb0bed47dac3 100644 --- a/src/basic/time-util.c +++ b/src/basic/time-util.c @@ -26,6 +26,7 @@ @@ -244,7 +245,7 @@ index 27dc9e43c3e2..b1a83023600b 100644 BUS_DEFINE_PROPERTY_GET(bus_property_get_tasks_max, "t", TasksMax, tasks_max_resolve); diff --git a/src/core/dbus-execute.c b/src/core/dbus-execute.c -index 1d0bc1ede3cb..313654913345 100644 +index d8ba3e5d9241..729e13fda64c 100644 --- a/src/core/dbus-execute.c +++ b/src/core/dbus-execute.c @@ -41,6 +41,7 @@ @@ -268,7 +269,7 @@ index 7862beaacb6d..3b1ea53a5f0d 100644 int bus_property_get_triggered_unit( sd_bus *bus, diff --git a/src/core/execute.c b/src/core/execute.c -index abc164ff5bef..f04b8ba05002 100644 +index 89dbf6fbd2c1..9762dc57443c 100644 --- a/src/core/execute.c +++ b/src/core/execute.c @@ -88,6 +88,7 @@ @@ -292,7 +293,7 @@ index 09ccd613e32c..f4e64fa283e9 100644 #if HAVE_KMOD #include "module-util.h" diff --git a/src/core/service.c b/src/core/service.c -index 49ad166c2604..c3b14067e201 100644 +index 17f27a4abce3..e5dcc532d0ce 100644 --- a/src/core/service.c +++ b/src/core/service.c @@ -41,6 +41,7 @@ @@ -316,10 +317,10 @@ index 35885dfb47c4..bb9f0660a6a0 100644 #define DEFAULT_MAX_USE_LOWER (uint64_t) (1ULL*1024ULL*1024ULL) /* 1 MiB */ #define DEFAULT_MAX_USE_UPPER (uint64_t) (4ULL*1024ULL*1024ULL*1024ULL) /* 4 GiB */ diff --git a/src/journal-remote/journal-remote-main.c b/src/journal-remote/journal-remote-main.c -index ac2bf648d2af..06c86f0201af 100644 +index 88e42d3a984b..0f08376e5399 100644 --- a/src/journal-remote/journal-remote-main.c +++ b/src/journal-remote/journal-remote-main.c -@@ -21,6 +21,7 @@ +@@ -22,6 +22,7 @@ #include "stat-util.h" #include "string-table.h" #include "strv.h" @@ -328,19 +329,31 @@ index ac2bf648d2af..06c86f0201af 100644 #define PRIV_KEY_FILE CERTIFICATE_ROOT "/private/journal-remote.pem" #define CERT_FILE CERTIFICATE_ROOT "/certs/journal-remote.pem" diff --git a/src/journal/journalctl.c b/src/journal/journalctl.c -index 95b6bfee172a..e0bcfb9d4233 100644 +index e5feec83bce6..c3aec1e219d7 100644 --- a/src/journal/journalctl.c +++ b/src/journal/journalctl.c -@@ -68,6 +68,7 @@ +@@ -69,6 +69,7 @@ #include "unit-name.h" #include "user-util.h" #include "varlink.h" +#include "missing_stdlib.h" #define DEFAULT_FSS_INTERVAL_USEC (15*USEC_PER_MINUTE) + #define PROCESS_INOTIFY_INTERVAL 1024 /* Every 1,024 messages processed */ +diff --git a/src/journal/sd-journal.c b/src/journal/sd-journal.c +index 3fa98dfda237..e655d77e714a 100644 +--- a/src/journal/sd-journal.c ++++ b/src/journal/sd-journal.c +@@ -40,6 +40,7 @@ + #include "string-util.h" + #include "strv.h" + #include "syslog-util.h" ++#include "missing_stdlib.h" + + #define JOURNAL_FILES_MAX 7168 diff --git a/src/libsystemd/sd-bus/bus-message.c b/src/libsystemd/sd-bus/bus-message.c -index eb029e445326..8da2c5d51a75 100644 +index 73127dfe0253..cc8635dea591 100644 --- a/src/libsystemd/sd-bus/bus-message.c +++ b/src/libsystemd/sd-bus/bus-message.c @@ -21,6 +21,7 @@ @@ -352,7 +365,7 @@ index eb029e445326..8da2c5d51a75 100644 static int message_append_basic(sd_bus_message *m, char type, const void *p, const void **stored); diff --git a/src/libsystemd/sd-bus/bus-objects.c b/src/libsystemd/sd-bus/bus-objects.c -index ae643cacc740..f766e235206d 100644 +index 6d140348ec4c..9126b8801bc5 100644 --- a/src/libsystemd/sd-bus/bus-objects.c +++ b/src/libsystemd/sd-bus/bus-objects.c @@ -13,6 +13,7 @@ @@ -376,7 +389,7 @@ index 18d30d010a20..be2ab703f8ed 100644 #define SNDBUF_SIZE (8*1024*1024) diff --git a/src/libsystemd/sd-bus/sd-bus.c b/src/libsystemd/sd-bus/sd-bus.c -index 058492a83eec..54c896f572b9 100644 +index 7ad03680f48d..b9d2181e4910 100644 --- a/src/libsystemd/sd-bus/sd-bus.c +++ b/src/libsystemd/sd-bus/sd-bus.c @@ -41,6 +41,7 @@ @@ -400,7 +413,7 @@ index 8de0a859ee94..58044b6ba908 100644 #define MAX_SIZE (2*1024*1024) diff --git a/src/locale/keymap-util.c b/src/locale/keymap-util.c -index 519dd0d188cf..a8f536915bb2 100644 +index 30669a9359e5..6544b3722099 100644 --- a/src/locale/keymap-util.c +++ b/src/locale/keymap-util.c @@ -21,6 +21,7 @@ @@ -412,19 +425,19 @@ index 519dd0d188cf..a8f536915bb2 100644 static bool startswith_comma(const char *s, const char *prefix) { s = startswith(s, prefix); diff --git a/src/login/pam_systemd.c b/src/login/pam_systemd.c -index aa6e5ea7aca8..c439c21b2872 100644 +index 84bea21ab7be..49720c7f742e 100644 --- a/src/login/pam_systemd.c +++ b/src/login/pam_systemd.c -@@ -28,6 +28,7 @@ - #include "hostname-util.h" +@@ -31,6 +31,7 @@ + #include "locale-util.h" #include "login-util.h" #include "macro.h" +#include "missing_stdlib.h" + #include "pam-util.h" #include "parse-util.h" #include "path-util.h" - #include "process-util.h" diff --git a/src/network/generator/network-generator.c b/src/network/generator/network-generator.c -index 81afa9530762..2c5328f97c63 100644 +index bed1e42697c4..e4847c2beea2 100644 --- a/src/network/generator/network-generator.c +++ b/src/network/generator/network-generator.c @@ -13,6 +13,7 @@ @@ -460,10 +473,10 @@ index 364356da5622..47d4ea44e40f 100644 NSS_GETHOSTBYNAME_PROTOTYPES(mymachines); NSS_GETPW_PROTOTYPES(mymachines); diff --git a/src/portable/portable.c b/src/portable/portable.c -index 34b123e84692..5a48504d00ac 100644 +index e18826ab2685..d9f4b81d8937 100644 --- a/src/portable/portable.c +++ b/src/portable/portable.c -@@ -29,6 +29,7 @@ +@@ -31,6 +31,7 @@ #include "strv.h" #include "tmpfile-util.h" #include "user-util.h" @@ -472,10 +485,10 @@ index 34b123e84692..5a48504d00ac 100644 static const char profile_dirs[] = CONF_PATHS_NULSTR("systemd/portable/profile"); diff --git a/src/resolve/resolvectl.c b/src/resolve/resolvectl.c -index 0a96a18b3836..432d6ebc3730 100644 +index f20e8c44b8bc..9f6c4e8f49a7 100644 --- a/src/resolve/resolvectl.c +++ b/src/resolve/resolvectl.c -@@ -31,6 +31,7 @@ +@@ -33,6 +33,7 @@ #include "strv.h" #include "terminal-util.h" #include "verbs.h" @@ -496,7 +509,7 @@ index b21fe393265f..af2640005c1d 100644 struct CGroupInfo { char *cgroup_path; diff --git a/src/shared/bus-unit-util.c b/src/shared/bus-unit-util.c -index 22a15493d7f3..3f4c51975675 100644 +index 28d85944a8a7..4743a84a417e 100644 --- a/src/shared/bus-unit-util.c +++ b/src/shared/bus-unit-util.c @@ -34,6 +34,7 @@ @@ -508,10 +521,10 @@ index 22a15493d7f3..3f4c51975675 100644 int bus_parse_unit_info(sd_bus_message *message, UnitInfo *u) { assert(message); diff --git a/src/shared/bus-util.c b/src/shared/bus-util.c -index aea46d311996..223426298144 100644 +index 8e6a6e2ce2de..0cbf4b1997df 100644 --- a/src/shared/bus-util.c +++ b/src/shared/bus-util.c -@@ -34,6 +34,7 @@ +@@ -30,6 +30,7 @@ #include "stdio-util.h" #include "strv.h" #include "user-util.h" @@ -544,10 +557,10 @@ index 7c4fc7021dec..3fbaf5a63969 100644 enum { IMPORTER_STATE_LINE = 0, /* waiting to read, or reading line */ diff --git a/src/shared/logs-show.c b/src/shared/logs-show.c -index 95b2e3376e9a..facc23aaecd5 100644 +index 2bfd0b60c26b..6a1bb3a0760f 100644 --- a/src/shared/logs-show.c +++ b/src/shared/logs-show.c -@@ -37,6 +37,7 @@ +@@ -39,6 +39,7 @@ #include "time-util.h" #include "utf8.h" #include "util.h" @@ -592,7 +605,7 @@ index 7cb7d8a477e9..8e7d7f9e7ca6 100644 static bool uid_range_intersect(UidRange *range, uid_t start, uid_t nr) { assert(range); diff --git a/src/socket-proxy/socket-proxyd.c b/src/socket-proxy/socket-proxyd.c -index 2fb9c854fa50..58cef31458f7 100644 +index 2ee6fc2f0a6a..4a9934f9c14d 100644 --- a/src/socket-proxy/socket-proxyd.c +++ b/src/socket-proxy/socket-proxyd.c @@ -26,6 +26,7 @@ @@ -628,7 +641,7 @@ index ca38f5608791..9d8cf4d2807b 100644 _printf_(2,3) static void path_prepend(char **path, const char *fmt, ...) { diff --git a/src/udev/udev-event.c b/src/udev/udev-event.c -index 58d484280aa5..90eab6806b55 100644 +index eb51139e519c..977cc16e9d7c 100644 --- a/src/udev/udev-event.c +++ b/src/udev/udev-event.c @@ -34,6 +34,7 @@ @@ -640,7 +653,7 @@ index 58d484280aa5..90eab6806b55 100644 typedef struct Spawn { sd_device *device; diff --git a/src/udev/udev-rules.c b/src/udev/udev-rules.c -index 6168b332d3b2..245fe0a64d22 100644 +index b9b350d1ef7a..2c114cc77572 100644 --- a/src/udev/udev-rules.c +++ b/src/udev/udev-rules.c @@ -30,6 +30,7 @@ diff --git a/meta/recipes-core/systemd/systemd/0006-Include-netinet-if_ether.h.patch b/meta/recipes-core/systemd/systemd/0006-Include-netinet-if_ether.h.patch index ea003fd7dab7..9142d7b45c8d 100644 --- a/meta/recipes-core/systemd/systemd/0006-Include-netinet-if_ether.h.patch +++ b/meta/recipes-core/systemd/systemd/0006-Include-netinet-if_ether.h.patch @@ -1,4 +1,4 @@ -From 3932ce7f6c8ace5e1210aad20e1a141cb29329b1 Mon Sep 17 00:00:00 2001 +From 47818052121d135632f5e46c369e3e4706a0f9e0 Mon Sep 17 00:00:00 2001 From: Khem Raj Date: Thu, 26 Oct 2017 22:10:42 -0700 Subject: [PATCH] Include netinet/if_ether.h @@ -53,7 +53,7 @@ Signed-off-by: Scott Murray 19 files changed, 18 insertions(+), 4 deletions(-) diff --git a/src/libsystemd-network/sd-dhcp6-client.c b/src/libsystemd-network/sd-dhcp6-client.c -index 5417ba8c5feb..d3aba928dd96 100644 +index eac2e725cce7..1beae7ba91cc 100644 --- a/src/libsystemd-network/sd-dhcp6-client.c +++ b/src/libsystemd-network/sd-dhcp6-client.c @@ -5,7 +5,6 @@ @@ -65,7 +65,7 @@ index 5417ba8c5feb..d3aba928dd96 100644 #include "sd-dhcp6-client.h" diff --git a/src/libsystemd/sd-netlink/netlink-types.c b/src/libsystemd/sd-netlink/netlink-types.c -index a55460f03407..6f9cd527c800 100644 +index e35127a4cd2e..4f6ad9ef5886 100644 --- a/src/libsystemd/sd-netlink/netlink-types.c +++ b/src/libsystemd/sd-netlink/netlink-types.c @@ -3,6 +3,7 @@ @@ -77,7 +77,7 @@ index a55460f03407..6f9cd527c800 100644 #include #include diff --git a/src/machine/machine-dbus.c b/src/machine/machine-dbus.c -index 3b2ac3829859..760ccb445cd0 100644 +index a2990452af17..5af350883c28 100644 --- a/src/machine/machine-dbus.c +++ b/src/machine/machine-dbus.c @@ -3,6 +3,7 @@ @@ -89,7 +89,7 @@ index 3b2ac3829859..760ccb445cd0 100644 /* When we include libgen.h because we need dirname() we immediately * undefine basename() since libgen.h defines it as a macro to the POSIX diff --git a/src/network/netdev/bond.c b/src/network/netdev/bond.c -index 185b155440e7..dc1cd236c814 100644 +index 8df39e35843f..8d697894f970 100644 --- a/src/network/netdev/bond.c +++ b/src/network/netdev/bond.c @@ -1,5 +1,6 @@ @@ -100,7 +100,7 @@ index 185b155440e7..dc1cd236c814 100644 #include "bond.h" #include "conf-parser.h" diff --git a/src/network/netdev/bridge.c b/src/network/netdev/bridge.c -index 59a40faef8fa..8e821a3216b3 100644 +index 6b8f9944612e..7f81ec25c407 100644 --- a/src/network/netdev/bridge.c +++ b/src/network/netdev/bridge.c @@ -1,5 +1,6 @@ @@ -111,7 +111,7 @@ index 59a40faef8fa..8e821a3216b3 100644 #include "bridge.h" diff --git a/src/network/netdev/macsec.c b/src/network/netdev/macsec.c -index 25dc23ff0338..f20d11fbcf53 100644 +index 7d1fec3afe6d..e948a335336d 100644 --- a/src/network/netdev/macsec.c +++ b/src/network/netdev/macsec.c @@ -1,5 +1,6 @@ @@ -134,7 +134,7 @@ index 09a5f4822e03..873299b1f98a 100644 #include "bond.h" #include "bridge.h" diff --git a/src/network/netdev/netdev.c b/src/network/netdev/netdev.c -index 6908c4e811b0..e0d8c459ab63 100644 +index f8121a48ed92..437f411c61e8 100644 --- a/src/network/netdev/netdev.c +++ b/src/network/netdev/netdev.c @@ -1,5 +1,6 @@ @@ -145,7 +145,7 @@ index 6908c4e811b0..e0d8c459ab63 100644 #include diff --git a/src/network/networkd-brvlan.c b/src/network/networkd-brvlan.c -index c3c5d535ac66..ebea408c89a8 100644 +index 41f09287f2b7..b67ce4fc8844 100644 --- a/src/network/networkd-brvlan.c +++ b/src/network/networkd-brvlan.c @@ -4,6 +4,7 @@ @@ -157,7 +157,7 @@ index c3c5d535ac66..ebea408c89a8 100644 #include diff --git a/src/network/networkd-dhcp-common.c b/src/network/networkd-dhcp-common.c -index 6465a8cfe9c7..bd4b2cdfac15 100644 +index 8664d8cdc0d4..e9f91f74c1a1 100644 --- a/src/network/networkd-dhcp-common.c +++ b/src/network/networkd-dhcp-common.c @@ -4,6 +4,7 @@ @@ -169,21 +169,22 @@ index 6465a8cfe9c7..bd4b2cdfac15 100644 #include "parse-util.h" #include "string-table.h" diff --git a/src/network/networkd-dhcp4.c b/src/network/networkd-dhcp4.c -index 8ca87d99d4db..a66284896cf3 100644 +index 13e3e32f40e8..5394399c9150 100644 --- a/src/network/networkd-dhcp4.c +++ b/src/network/networkd-dhcp4.c -@@ -1,8 +1,8 @@ +@@ -1,9 +1,9 @@ /* SPDX-License-Identifier: LGPL-2.1+ */ +#include #include + #include #include -#include #include "alloc-util.h" #include "dhcp-client-internal.h" diff --git a/src/network/networkd-dhcp6.c b/src/network/networkd-dhcp6.c -index 647623ac3778..325c641c6231 100644 +index 7304270c60b1..099064f64715 100644 --- a/src/network/networkd-dhcp6.c +++ b/src/network/networkd-dhcp6.c @@ -3,9 +3,9 @@ @@ -198,7 +199,7 @@ index 647623ac3778..325c641c6231 100644 #include "sd-dhcp6-client.h" diff --git a/src/network/networkd-link.c b/src/network/networkd-link.c -index 2e60adbf7818..05aa8672d585 100644 +index 99d4b29c31ec..e8b467d6ac09 100644 --- a/src/network/networkd-link.c +++ b/src/network/networkd-link.c @@ -1,8 +1,8 @@ @@ -212,7 +213,7 @@ index 2e60adbf7818..05aa8672d585 100644 #include "alloc-util.h" diff --git a/src/network/networkd-network.c b/src/network/networkd-network.c -index 6e443975f171..d1aab0ca5ba2 100644 +index 2e716b291e97..56f18cea57fe 100644 --- a/src/network/networkd-network.c +++ b/src/network/networkd-network.c @@ -1,5 +1,6 @@ @@ -232,7 +233,7 @@ index 25b939639775..530e4928835c 100644 #include "dhcp6-internal.h" #include "dhcp6-protocol.h" diff --git a/src/shared/ethtool-util.c b/src/shared/ethtool-util.c -index 3119b2b92e3b..927ddd067eef 100644 +index 00a71d64a638..4593e89120b8 100644 --- a/src/shared/ethtool-util.c +++ b/src/shared/ethtool-util.c @@ -1,5 +1,6 @@ @@ -243,19 +244,19 @@ index 3119b2b92e3b..927ddd067eef 100644 #include #include diff --git a/src/shared/ethtool-util.h b/src/shared/ethtool-util.h -index d408bcd90a0b..7a1e399af023 100644 +index c1d5d7590ef9..b3e018bf76e9 100644 --- a/src/shared/ethtool-util.h +++ b/src/shared/ethtool-util.h -@@ -2,6 +2,7 @@ - #pragma once +@@ -3,6 +3,7 @@ #include + #include +#include #include #include "conf-parser.h" diff --git a/src/udev/net/link-config.c b/src/udev/net/link-config.c -index 7b07e2f38fa8..18680a8e5484 100644 +index 0332e99269c9..ff3aead4a779 100644 --- a/src/udev/net/link-config.c +++ b/src/udev/net/link-config.c @@ -1,5 +1,6 @@ diff --git a/meta/recipes-core/systemd/systemd/0010-fix-missing-of-__register_atfork-for-non-glibc-build.patch b/meta/recipes-core/systemd/systemd/0010-fix-missing-of-__register_atfork-for-non-glibc-build.patch index 0de1121906d3..5ee501f23596 100644 --- a/meta/recipes-core/systemd/systemd/0010-fix-missing-of-__register_atfork-for-non-glibc-build.patch +++ b/meta/recipes-core/systemd/systemd/0010-fix-missing-of-__register_atfork-for-non-glibc-build.patch @@ -1,4 +1,4 @@ -From 5166a6657570d4072cdce118621791e4a8186e07 Mon Sep 17 00:00:00 2001 +From eed7427db98cc01db7e9b3479655d68b044bc85b Mon Sep 17 00:00:00 2001 From: Chen Qi Date: Mon, 25 Feb 2019 15:03:47 +0800 Subject: [PATCH] fix missing of __register_atfork for non-glibc builds @@ -12,7 +12,7 @@ Signed-off-by: Chen Qi 1 file changed, 7 insertions(+) diff --git a/src/basic/process-util.c b/src/basic/process-util.c -index 9b6c4c31f713..24fec5ecb53a 100644 +index 5de366f830e8..644f53aee005 100644 --- a/src/basic/process-util.c +++ b/src/basic/process-util.c @@ -18,6 +18,9 @@ @@ -25,7 +25,7 @@ index 9b6c4c31f713..24fec5ecb53a 100644 #include "alloc-util.h" #include "architecture.h" -@@ -1114,11 +1117,15 @@ void reset_cached_pid(void) { +@@ -1116,11 +1119,15 @@ void reset_cached_pid(void) { cached_pid = CACHED_PID_UNSET; } diff --git a/meta/recipes-core/systemd/systemd/0011-Use-uintmax_t-for-handling-rlim_t.patch b/meta/recipes-core/systemd/systemd/0011-Use-uintmax_t-for-handling-rlim_t.patch index e00600ab7c32..e5d9515e8639 100644 --- a/meta/recipes-core/systemd/systemd/0011-Use-uintmax_t-for-handling-rlim_t.patch +++ b/meta/recipes-core/systemd/systemd/0011-Use-uintmax_t-for-handling-rlim_t.patch @@ -1,4 +1,4 @@ -From f6df7f25a6bb00d5540915216adfff8afefec2b0 Mon Sep 17 00:00:00 2001 +From 4aa91347ae975051dbe4dd2f98a1f4f459f2604f Mon Sep 17 00:00:00 2001 From: Chen Qi Date: Mon, 25 Feb 2019 15:12:41 +0800 Subject: [PATCH] Use uintmax_t for handling rlim_t @@ -28,10 +28,10 @@ Signed-off-by: Chen Qi 3 files changed, 8 insertions(+), 14 deletions(-) diff --git a/src/basic/format-util.h b/src/basic/format-util.h -index 59622508a333..779b6826d50e 100644 +index c47fa76ea8ff..14a78d9f5fd0 100644 --- a/src/basic/format-util.h +++ b/src/basic/format-util.h -@@ -44,13 +44,7 @@ +@@ -32,13 +32,7 @@ assert_cc(sizeof(gid_t) == sizeof(uint32_t)); # define PRI_TIMEX "li" #endif @@ -78,10 +78,10 @@ index 2dc13eabc30d..0633cc67f417 100644 return 1; } diff --git a/src/core/execute.c b/src/core/execute.c -index f04b8ba05002..084cf1420078 100644 +index 9762dc57443c..4a3421bb3ee6 100644 --- a/src/core/execute.c +++ b/src/core/execute.c -@@ -4455,9 +4455,9 @@ void exec_context_dump(const ExecContext *c, FILE* f, const char *prefix) { +@@ -4567,9 +4567,9 @@ void exec_context_dump(const ExecContext *c, FILE* f, const char *prefix) { for (i = 0; i < RLIM_NLIMITS; i++) if (c->rlimit[i]) { fprintf(f, "%sLimit%s: " RLIM_FMT "\n", diff --git a/meta/recipes-core/systemd/systemd/0014-test-sizeof.c-Disable-tests-for-missing-typedefs-in-.patch b/meta/recipes-core/systemd/systemd/0014-test-sizeof.c-Disable-tests-for-missing-typedefs-in-.patch index aa23c7ab7d08..049096d2a971 100644 --- a/meta/recipes-core/systemd/systemd/0014-test-sizeof.c-Disable-tests-for-missing-typedefs-in-.patch +++ b/meta/recipes-core/systemd/systemd/0014-test-sizeof.c-Disable-tests-for-missing-typedefs-in-.patch @@ -1,4 +1,4 @@ -From 7874912817b5ac7ed7f8557359a12d9d4b2f53eb Mon Sep 17 00:00:00 2001 +From 62fac5e3ff0fccd329cdc49605258b6d0e573a3e Mon Sep 17 00:00:00 2001 From: Chen Qi Date: Wed, 28 Feb 2018 21:25:22 -0800 Subject: [PATCH] test-sizeof.c: Disable tests for missing typedefs in musl @@ -13,10 +13,10 @@ Signed-off-by: Chen Qi 1 file changed, 4 insertions(+) diff --git a/src/test/test-sizeof.c b/src/test/test-sizeof.c -index 7fc16a62b656..a710db5370b8 100644 +index 1020e0cb3153..c65062d2562c 100644 --- a/src/test/test-sizeof.c +++ b/src/test/test-sizeof.c -@@ -42,8 +42,10 @@ int main(void) { +@@ -44,8 +44,10 @@ int main(void) { info(unsigned); info(long unsigned); info(long long unsigned); @@ -27,7 +27,7 @@ index 7fc16a62b656..a710db5370b8 100644 info(float); info(double); -@@ -61,7 +63,9 @@ int main(void) { +@@ -63,7 +65,9 @@ int main(void) { info(ssize_t); info(time_t); info(usec_t); diff --git a/meta/recipes-core/systemd/systemd/0017-Do-not-disable-buffering-when-writing-to-oom_score_a.patch b/meta/recipes-core/systemd/systemd/0017-Do-not-disable-buffering-when-writing-to-oom_score_a.patch index 56f45381de0a..1934b783dc39 100644 --- a/meta/recipes-core/systemd/systemd/0017-Do-not-disable-buffering-when-writing-to-oom_score_a.patch +++ b/meta/recipes-core/systemd/systemd/0017-Do-not-disable-buffering-when-writing-to-oom_score_a.patch @@ -1,4 +1,4 @@ -From a6f3359042219abaa8ae06dfcce41a4721e8c21f Mon Sep 17 00:00:00 2001 +From bb28a9c870bb47dcdb1ccebaa8e3a5a86730a244 Mon Sep 17 00:00:00 2001 From: Chen Qi Date: Wed, 4 Jul 2018 15:00:44 +0800 Subject: [PATCH] Do not disable buffering when writing to oom_score_adj @@ -25,10 +25,10 @@ Signed-off-by: Scott Murray 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/basic/process-util.c b/src/basic/process-util.c -index 24fec5ecb53a..642b02443c85 100644 +index 644f53aee005..acaf13591396 100644 --- a/src/basic/process-util.c +++ b/src/basic/process-util.c -@@ -1492,7 +1492,7 @@ int set_oom_score_adjust(int value) { +@@ -1500,7 +1500,7 @@ int set_oom_score_adjust(int value) { sprintf(t, "%i", value); return write_string_file("/proc/self/oom_score_adj", t, @@ -36,4 +36,4 @@ index 24fec5ecb53a..642b02443c85 100644 + WRITE_STRING_FILE_VERIFY_ON_FAILURE); } - static const char *const ioprio_class_table[] = { + int pidfd_get_pid(int fd, pid_t *ret) { diff --git a/meta/recipes-core/systemd/systemd_244.3.bb b/meta/recipes-core/systemd/systemd_245.bb similarity index 99% rename from meta/recipes-core/systemd/systemd_244.3.bb rename to meta/recipes-core/systemd/systemd_245.bb index 279e0857244a..19a8f0cb18af 100644 --- a/meta/recipes-core/systemd/systemd_244.3.bb +++ b/meta/recipes-core/systemd/systemd_245.bb @@ -47,6 +47,7 @@ SRC_URI_MUSL = "\ file://0002-src-login-brightness.c-include-sys-wait.h.patch \ file://0003-src-basic-copy.c-include-signal.h.patch \ file://0004-src-shared-cpu-set-util.h-add-__cpu_mask-definition.patch \ + file://0001-Handle-missing-gshadow.patch \ " PAM_PLUGINS = " \ @@ -84,6 +85,7 @@ PACKAGECONFIG ??= " \ sysusers \ timedated \ timesyncd \ + userdb \ utmp \ vconsole \ xz \ @@ -99,6 +101,7 @@ PACKAGECONFIG_remove_libc-musl = " \ nss-resolve \ smack \ sysusers \ + userdb \ utmp \ " @@ -176,6 +179,7 @@ PACKAGECONFIG[timedated] = "-Dtimedated=true,-Dtimedated=false" PACKAGECONFIG[timesyncd] = "-Dtimesyncd=true,-Dtimesyncd=false" PACKAGECONFIG[usrmerge] = "-Dsplit-usr=false,-Dsplit-usr=true" PACKAGECONFIG[sbinmerge] = "-Dsplit-bin=false,-Dsplit-bin=true" +PACKAGECONFIG[userdb] = "-Duserdb=true,-Duserdb=false" PACKAGECONFIG[utmp] = "-Dutmp=true,-Dutmp=false" PACKAGECONFIG[valgrind] = "-DVALGRIND=1,,valgrind" PACKAGECONFIG[vconsole] = "-Dvconsole=true,-Dvconsole=false,,${PN}-vconsole-setup" @@ -494,10 +498,13 @@ FILES_${PN}-extra-utils = "\ CONFFILES_${PN} = "${sysconfdir}/systemd/coredump.conf \ ${sysconfdir}/systemd/journald.conf \ ${sysconfdir}/systemd/logind.conf \ - ${sysconfdir}/systemd/system.conf \ - ${sysconfdir}/systemd/user.conf \ + ${sysconfdir}/systemd/networkd.conf \ + ${sysconfdir}/systemd/pstore.conf \ ${sysconfdir}/systemd/resolved.conf \ + ${sysconfdir}/systemd/sleep.conf \ + ${sysconfdir}/systemd/system.conf \ ${sysconfdir}/systemd/timesyncd.conf \ + ${sysconfdir}/systemd/user.conf \ " FILES_${PN} = " ${base_bindir}/* \ -- 2.17.1 From alex.kiernan at gmail.com Tue Mar 17 15:23:03 2020 From: alex.kiernan at gmail.com (Alex Kiernan) Date: Tue, 17 Mar 2020 15:23:03 +0000 Subject: [OE-core] [OE-Core][RFC PATCH 11/11] systemd: Enable acl based on DISTRO_FEATURES In-Reply-To: <20200317152303.4600-1-alex.kiernan@gmail.com> References: <20200317152303.4600-1-alex.kiernan@gmail.com> Message-ID: <20200317152303.4600-12-alex.kiernan@gmail.com> Signed-off-by: Alex Kiernan --- meta/recipes-core/systemd/systemd_245.bb | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/meta/recipes-core/systemd/systemd_245.bb b/meta/recipes-core/systemd/systemd_245.bb index 72021a0991ae..09ea07833d71 100644 --- a/meta/recipes-core/systemd/systemd_245.bb +++ b/meta/recipes-core/systemd/systemd_245.bb @@ -57,10 +57,9 @@ PAM_PLUGINS = " \ " PACKAGECONFIG ??= " \ - ${@bb.utils.filter('DISTRO_FEATURES', 'audit efi ldconfig pam selinux smack sysvinit usrmerge polkit', d)} \ + ${@bb.utils.filter('DISTRO_FEATURES', 'acl audit efi ldconfig pam selinux smack sysvinit usrmerge polkit', d)} \ ${@bb.utils.contains('DISTRO_FEATURES', 'wifi', 'rfkill', '', d)} \ ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'xkbcommon', '', d)} \ - acl \ backlight \ binfmt \ gshadow \ -- 2.17.1 From alhe at linux.microsoft.com Tue Mar 17 22:58:24 2020 From: alhe at linux.microsoft.com (Alejandro Hernandez Samaniego) Date: Tue, 17 Mar 2020 15:58:24 -0700 Subject: [OE-core] [PATCH] Windows: Enable Windows builds under WSLv2 and warn accordingly In-Reply-To: References: <20200315061311.19344-1-alhe@linux.microsoft.com> Message-ID: Hey Richard, On 3/15/2020 4:48 AM, Richard Purdie wrote: > On Sat, 2020-03-14 at 23:13 -0700, Alejandro Hernandez Samaniego wrote: >> Due to the architectural changes between Windows Subsystem for Linux >> v2, and WSL v1 it should now be possible to run bitbake on the >> several distros offered through the Microsoft Store. >> >> WSLv2 is available on Windows 10 build number > 18917 >> >> The current build number may be checked by opening a cmd prompt on >> Windows and running: >> >> C:\Users\myuser>ver >> >> Microsoft Windows [Version 10.0.19041.113] > Thanks, this is useful information. How much of our system works on > WSL2? runqemu? testimage? eSDK? virtgl? Is anything known not to work? > This email implies everything works? > > My big worry here is that we have a set subset of bugs which only occur > on WSL2. We're struggling with the bug reports we have today, adding in > a whole new set with no help to support that is a concern. I have tested enough to be confident that this should not be the case, testimage works, runqemu works (after creating the tap interfaces), unless you have specific tests that you want me to run for virtgl, I did test virtgl on runqemu and ran the image along with some basic graphics testing, esdk works, I just ran bitbake-selftest and oe-selftest and they both work, I understand your concern but I dont believe this would be the case. > > Is this for 3.1 LTS? Are Microsoft going to be able to help us in any > way? How "official" is this change? I can speak for myself and say that if there are any WSL related bugs, they can be assigned to me during TRIAGE and I will take a look at them, also note that these are only the changes on the OE part of things, WSLv2 will be generally available on Windows 10 v2004 https://devblogs.microsoft.com/commandline/wsl2-will-be-generally-available-in-windows-10-version-2004/ So, while my hope is that this can be merged on Dunfell, if possible I'd like to backport this to Zeus at least, note that the previous check simply won't work on WSLv2 and it wont throw any errors about it, I believe people will start using this regardless and its better if we warn them properly about the process (I have tested both current master and Zeus). If that is not possible then at the very least we should throw an error as well for WSLv2 on previous releases. >> if "Microsoft" in l: >> - return "OpenEmbedded doesn't work under WSL at this time, sorry" >> + return "OpenEmbedded doesn't work under WSLv1, please upgrade to WSLv2 if you want to run builds on Windows" >> + elif "microsoft" in l: >> + bb.warn("You are running bitbake under WSLv2, this works properly but you should optimize your VHDX file eventually to avoid running out of storage space") >> return None >> >> # Tar version 1.24 and onwards handle overwriting symlinks correctly > Is Microsoft vs microsoft the best check we can have? Should we be > checking the version specifically? AFAIC this is a good way to test it, it is kept across all Microsoft Store Distros for both WSLv1 and WSLv2. Cheers, Alejandro > > Cheers, > > Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.kjellerstedt at axis.com Tue Mar 17 17:47:10 2020 From: peter.kjellerstedt at axis.com (Peter Kjellerstedt) Date: Tue, 17 Mar 2020 17:47:10 +0000 Subject: [OE-core] [OE-Core][RFC PATCH 04/11] systemd: Add PACKAGECONFIG for sysvinit In-Reply-To: <20200317152303.4600-5-alex.kiernan@gmail.com> References: <20200317152303.4600-1-alex.kiernan@gmail.com> <20200317152303.4600-5-alex.kiernan@gmail.com> Message-ID: <4ba6a14e42f541488dd004804f13be73@XBOX03.axis.com> > -----Original Message----- > From: openembedded-core-bounces at lists.openembedded.org bounces at lists.openembedded.org> On Behalf Of Alex Kiernan > Sent: den 17 mars 2020 16:23 > To: openembedded-core at lists.openembedded.org > Subject: [OE-core] [OE-Core][RFC PATCH 04/11] systemd: Add PACKAGECONFIG > for sysvinit > > Add sysvinit PACKAGECONFIG which is bound to DISTRO_FEATURES, this > then disables all sysvinit handling in systemd if it isn't present. > > Consolidate sysvinit handling so that when it's disabled we exclude all > sysvinit features. > > Signed-off-by: Alex Kiernan > --- > > meta/recipes-core/systemd/systemd_244.3.bb | 9 +++++---- > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/meta/recipes-core/systemd/systemd_244.3.bb b/meta/recipes-core/systemd/systemd_244.3.bb > index b26f3cb72d2b..7c33bde21a39 100644 > --- a/meta/recipes-core/systemd/systemd_244.3.bb > +++ b/meta/recipes-core/systemd/systemd_244.3.bb > @@ -56,7 +56,7 @@ PAM_PLUGINS = " \ > " > > PACKAGECONFIG ??= " \ > - ${@bb.utils.filter('DISTRO_FEATURES', 'efi ldconfig pam selinux usrmerge polkit', d)} \ > + ${@bb.utils.filter('DISTRO_FEATURES', 'efi ldconfig pam selinux sysvinit usrmerge polkit', d)} \ > ${@bb.utils.contains('DISTRO_FEATURES', 'wifi', 'rfkill', '', d)} \ > ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'xkbcommon', '', d)} \ > acl \ > @@ -165,6 +165,7 @@ PACKAGECONFIG[seccomp] = "-Dseccomp=true,-Dseccomp=false,libseccomp" > PACKAGECONFIG[selinux] = "-Dselinux=true,-Dselinux=false,libselinux,initscripts-sushell" > PACKAGECONFIG[smack] = "-Dsmack=true,-Dsmack=false" > PACKAGECONFIG[sysusers] = "-Dsysusers=true,-Dsysusers=false" > +PACKAGECONFIG[sysvinit] = "-Dsysvinit-path=${sysconfdir}/init.d -Dsysvrcnd-path=${sysconfdir},-Dsysvinit-path= -Dsysvrcnd-path=" > # When enabled use reproducble build timestamp if set as time epoch, > # or build time if not. When disabled, time epoch is unset. > def build_epoch(d): > @@ -198,7 +199,6 @@ EXTRA_OEMESON += "-Dnobody-user=nobody \ > -Dnobody-group=nobody \ > -Drootlibdir=${rootlibdir} \ > -Drootprefix=${rootprefix} \ > - -Dsysvrcnd-path=${sysconfdir} \ > -Ddefault-locale=C \ > " > > @@ -234,6 +234,7 @@ do_install() { > install -d ${D}${sysconfdir}/init.d > install -m 0755 ${WORKDIR}/init ${D}${sysconfdir}/init.d/systemd-udevd > sed -i s%@UDEVD@%${rootlibexecdir}/systemd/systemd-udevd% ${D}${sysconfdir}/init.d/systemd-udevd > + install -Dm 0755 ${S}/src/systemctl/systemd-sysv-install.SKELETON ${D}${systemd_unitdir}/systemd-sysv-install > fi > > chown root:systemd-journal ${D}/${localstatedir}/log/journal > @@ -273,7 +274,6 @@ do_install() { > sed -i -e "s%^L! /etc/resolv.conf.*$%L! /etc/resolv.conf - - - - ../run/systemd/resolve/resolv.conf%g" ${D}${exec_prefix}/lib/tmpfiles.d/etc.conf > ln -s ../run/systemd/resolve/resolv.conf ${D}${sysconfdir}/resolv-conf.systemd > fi > - install -Dm 0755 ${S}/src/systemctl/systemd-sysv-install.SKELETON ${D}${systemd_unitdir}/systemd-sysv-install > > # If polkit is setup fixup permissions and ownership > if ${@bb.utils.contains('PACKAGECONFIG', 'polkit', 'true', 'false', d)}; then > @@ -560,7 +560,8 @@ FILES_${PN}-dev += "${base_libdir}/security/*.la ${datadir}/dbus-1/interfaces/ $ > > RDEPENDS_${PN} += "kmod dbus util-linux-mount util-linux-umount udev (= ${EXTENDPKGV}) util-linux-agetty util-linux-fsck" > RDEPENDS_${PN} += "${@bb.utils.contains('PACKAGECONFIG', 'serial-getty-generator', '', 'systemd-serialgetty', d)}" > -RDEPENDS_${PN} += "volatile-binds update-rc.d" > +RDEPENDS_${PN} += "${@bb.utils.contains('DISTRO_FEATURES', 'sysvinit', 'update-rc.d', '', d)}" Move the dependency on update-rc.d up to the sysvinit PACKAGECONFIG. > +RDEPENDS_${PN} += "volatile-binds" > > RRECOMMENDS_${PN} += "systemd-extra-utils \ > systemd-compat-units udev-hwdb \ > -- > 2.17.1 //Peter From raj.khem at gmail.com Tue Mar 17 18:32:20 2020 From: raj.khem at gmail.com (Khem Raj) Date: Tue, 17 Mar 2020 11:32:20 -0700 Subject: [OE-core] [PATCH] libucontext: Fix multilib build Message-ID: <20200317183220.774083-1-raj.khem@gmail.com> libdir is hardcoded to /lib which is not going to work in multilib scene, patch makefile to add a variable to override the libdir from env Signed-off-by: Khem Raj --- .../0001-Makefile-Add-LIBDIR-variable.patch | 46 +++++++++++++++++++ meta/recipes-core/musl/libucontext_git.bb | 3 +- 2 files changed, 48 insertions(+), 1 deletion(-) create mode 100644 meta/recipes-core/musl/libucontext/0001-Makefile-Add-LIBDIR-variable.patch diff --git a/meta/recipes-core/musl/libucontext/0001-Makefile-Add-LIBDIR-variable.patch b/meta/recipes-core/musl/libucontext/0001-Makefile-Add-LIBDIR-variable.patch new file mode 100644 index 0000000000..4f91c8f189 --- /dev/null +++ b/meta/recipes-core/musl/libucontext/0001-Makefile-Add-LIBDIR-variable.patch @@ -0,0 +1,46 @@ +From 9bc3cedba54708c40c4a853b240c46e69f87de3c Mon Sep 17 00:00:00 2001 +From: Khem Raj +Date: Tue, 17 Mar 2020 10:04:40 -0700 +Subject: [PATCH] Makefile: Add LIBDIR variable + +This ensures that it can be installed into custom location and also + +Upstream-Status: Submitted +Signed-off-by: Khem Raj +--- + Makefile | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/Makefile ++++ b/Makefile +@@ -1,5 +1,5 @@ + ARCH := $(shell uname -m) +- ++LIBDIR := /lib + CFLAGS = -ggdb3 -O2 -Wall -Iarch/${ARCH} + + LIBUCONTEXT_C_SRC = $(wildcard arch/${ARCH}/*.c) +@@ -10,8 +10,8 @@ LIBUCONTEXT_SOVERSION = 0 + LIBUCONTEXT_NAME = libucontext.so + LIBUCONTEXT_STATIC_NAME = libucontext.a + LIBUCONTEXT_SONAME = libucontext.so.${LIBUCONTEXT_SOVERSION} +-LIBUCONTEXT_PATH = /lib/${LIBUCONTEXT_SONAME} +-LIBUCONTEXT_STATIC_PATH = /lib/${LIBUCONTEXT_STATIC_NAME} ++LIBUCONTEXT_PATH = ${LIBDIR}/${LIBUCONTEXT_SONAME} ++LIBUCONTEXT_STATIC_PATH = ${LIBDIR}/${LIBUCONTEXT_STATIC_NAME} + + all: ${LIBUCONTEXT_SONAME} ${LIBUCONTEXT_STATIC_NAME} + +@@ -36,9 +36,9 @@ clean: + ${LIBUCONTEXT_OBJ} test_libucontext + + install: all +- install -D -m755 ${LIBUCONTEXT_NAME} ${DESTDIR}/${LIBUCONTEXT_PATH} +- install -D -m664 ${LIBUCONTEXT_STATIC_NAME} ${DESTDIR}/${LIBUCONTEXT_STATIC_PATH} +- ln -sf ${LIBUCONTEXT_SONAME} ${DESTDIR}/lib/${LIBUCONTEXT_NAME} ++ install -D -m755 ${LIBUCONTEXT_NAME} ${DESTDIR}${LIBUCONTEXT_PATH} ++ install -D -m664 ${LIBUCONTEXT_STATIC_NAME} ${DESTDIR}${LIBUCONTEXT_STATIC_PATH} ++ ln -sf ${LIBUCONTEXT_SONAME} ${DESTDIR}${LIBDIR}/${LIBUCONTEXT_NAME} + + check: test_libucontext ${LIBUCONTEXT_SONAME} + env LD_LIBRARY_PATH=$(shell pwd) ./test_libucontext diff --git a/meta/recipes-core/musl/libucontext_git.bb b/meta/recipes-core/musl/libucontext_git.bb index 72e15aa9a4..92cb703b0b 100644 --- a/meta/recipes-core/musl/libucontext_git.bb +++ b/meta/recipes-core/musl/libucontext_git.bb @@ -12,6 +12,7 @@ PV = "0.1.3+${SRCPV}" SRCREV = "e6b4d7516dae9b200e94fcfcb9ebc9331389655f" SRC_URI = "git://code.foxkit.us/adelie/libucontext.git;protocol=https \ file://0001-pass-LDFLAGS-to-link-step.patch \ + file://0001-Makefile-Add-LIBDIR-variable.patch \ " S = "${WORKDIR}/git" @@ -51,7 +52,7 @@ export ARCH = "${@map_kernel_arch(d.getVar('TARGET_ARCH'), d)}" CFLAGS += "-Iarch/${ARCH}" -EXTRA_OEMAKE = "CFLAGS='${CFLAGS}' LDFLAGS='${LDFLAGS}'" +EXTRA_OEMAKE = "CFLAGS='${CFLAGS}' LDFLAGS='${LDFLAGS}' LIBDIR='${base_libdir}'" do_compile() { oe_runmake ARCH=${ARCH} -- 2.25.1 From patchwork at patchwork.openembedded.org Tue Mar 17 19:02:17 2020 From: patchwork at patchwork.openembedded.org (Patchwork) Date: Tue, 17 Mar 2020 19:02:17 -0000 Subject: [OE-core] =?utf-8?q?=E2=9C=97_patchtest=3A_failure_for_libucontex?= =?utf-8?q?t=3A_Fix_multilib_build?= In-Reply-To: <20200317183220.774083-1-raj.khem@gmail.com> References: <20200317183220.774083-1-raj.khem@gmail.com> Message-ID: <20200317190217.2275.40191@do> == Series Details == Series: libucontext: Fix multilib build Revision: 1 URL : https://patchwork.openembedded.org/series/23281/ 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 Upstream-Status is Submitted, but it is not mentioned where [test_upstream_status_presence_format] Suggested fix Include where 0001-Makefile-Add-LIBDIR-variable.patch was submitted Current Upstream-Status: Submitted Standard format Upstream-Status: Submitted [where] If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core at 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 From akuster808 at gmail.com Tue Mar 17 21:12:54 2020 From: akuster808 at gmail.com (akuster808) Date: Tue, 17 Mar 2020 14:12:54 -0700 Subject: [OE-core] [poky] Thud community support In-Reply-To: <15FBEF1FC40D189D.8114@lists.yoctoproject.org> References: <15FBEF1FC40D189D.8114@lists.yoctoproject.org> Message-ID: <81fb73b4-f683-5356-ff07-1ac909afb97d@gmail.com> On 3/13/20 11:03 AM, akuster via Lists.Yoctoproject.Org wrote: > The Poky thud branch is now under 'Community support' and is seeking a > maintainer to continue supporting the following repos for the thud release: > > bitbake, core, meta-yocto and yocto-docs. > > > There will be no more point releases. > > see > https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS#Maintainer_Procedures? > to get an idea on what is expected. > > The one thing we (YP) don't know is if there will be AutoBuilder > resources available.? Please contact me or Richard regarding that statement. > > If no one steps up by April 24th (six weeks -ish from now), Thud will be > moved to EOL status. It was pointed out to me that there is no Maintainer selection process or criteria defined.? This? will have to be sorted out before we move forward on this transition. - armin > - Armin > > > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > > View/Reply Online (#11988): https://lists.yoctoproject.org/g/poky/message/11988 > Mute This Topic: https://lists.yoctoproject.org/mt/71932489/3616698 > Group Owner: poky+owner at lists.yoctoproject.org > Unsubscribe: https://lists.yoctoproject.org/g/poky/unsub [akuster808 at gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- -------------- next part -------------- An HTML attachment was scrubbed... URL: From otavio.salvador at ossystems.com.br Wed Mar 18 03:02:05 2020 From: otavio.salvador at ossystems.com.br (Otavio Salvador) Date: Wed, 18 Mar 2020 00:02:05 -0300 Subject: [OE-core] [OE-Core][RFC PATCH 01/11] systemd: Package udev rules explicitly In-Reply-To: <20200317152303.4600-2-alex.kiernan@gmail.com> References: <20200317152303.4600-1-alex.kiernan@gmail.com> <20200317152303.4600-2-alex.kiernan@gmail.com> Message-ID: On Tue, Mar 17, 2020 at 12:29 PM Alex Kiernan wrote: > udev is packaged before systemd so any wildcard inclusions in FILES will > override later specifics. List all udev rules explicitly so that the > systemd specific rules, packaged alongside systemd, appear in the > correct package. > > Signed-off-by: Alex Kiernan I believe udev ought to be on PACKAGE_BEFORE_PN so it is still handled with the wildcard and allow for easier maintenance in future. -- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 From otavio.salvador at ossystems.com.br Wed Mar 18 03:03:44 2020 From: otavio.salvador at ossystems.com.br (Otavio Salvador) Date: Wed, 18 Mar 2020 00:03:44 -0300 Subject: [OE-core] [OE-Core][RFC PATCH 02/11] systemd: Reinstate systemd-hwdb-update.service In-Reply-To: <20200317152303.4600-3-alex.kiernan@gmail.com> References: <20200317152303.4600-1-alex.kiernan@gmail.com> <20200317152303.4600-3-alex.kiernan@gmail.com> Message-ID: On Tue, Mar 17, 2020 at 12:29 PM Alex Kiernan wrote: > > systemd supports a distribution hwdb.bin in /usr/lib/udev/hwdb.bin, > which is used if /etc/udev/hwdb.bin is not present. When generating the > install time hwdb, for systemd, ensure that we put it in /usr/lib/udev, > which then ensures that at boot time we do not regenerate it, unless the > system is marked for update. > > This allows fragments dropped into /etc/udev/hwdb.d to be processed > correctly, but without requiring a first boot time build: > > root at qemumips:~# systemctl status systemd-hwdb-update.service > * systemd-hwdb-update.service - Rebuild Hardware Database > Loaded: loaded (/usr/lib/systemd/system/systemd-hwdb-update.service; static; vendor preset: disabled) > Active: inactive (dead) > Condition: start condition failed at Wed 2020-03-04 15:18:11 UTC; 44s ago > |- ConditionPathExists=|!/usr/lib/udev/hwdb.bin was not met > |- ConditionPathExists=|/etc/udev/hwdb.bin was not met > `- ConditionDirectoryNotEmpty=|/etc/udev/hwdb.d was not met > Docs: man:hwdb(7) > man:systemd-hwdb(8) > > Signed-off-by: Alex Kiernan Acked-by: Otavio Salvador -- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 From otavio.salvador at ossystems.com.br Wed Mar 18 03:04:15 2020 From: otavio.salvador at ossystems.com.br (Otavio Salvador) Date: Wed, 18 Mar 2020 00:04:15 -0300 Subject: [OE-core] [OE-Core][RFC PATCH 03/11] systemd: Add sch-fq-codel to RRECOMMENDS In-Reply-To: <20200317152303.4600-4-alex.kiernan@gmail.com> References: <20200317152303.4600-1-alex.kiernan@gmail.com> <20200317152303.4600-4-alex.kiernan@gmail.com> Message-ID: On Tue, Mar 17, 2020 at 12:29 PM Alex Kiernan wrote: > > systemd sets net.core.default_qdisc = fq_codel, include > kernel-module-sch-fq-codel in RRECOMMENDS to satify this > > Signed-off-by: Alex Kiernan Acked-by: Otavio Salvador -- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 From otavio.salvador at ossystems.com.br Wed Mar 18 03:05:02 2020 From: otavio.salvador at ossystems.com.br (Otavio Salvador) Date: Wed, 18 Mar 2020 00:05:02 -0300 Subject: [OE-core] [OE-Core][RFC PATCH 05/11] systemd: Remove X11 related files when disabled In-Reply-To: <20200317152303.4600-6-alex.kiernan@gmail.com> References: <20200317152303.4600-1-alex.kiernan@gmail.com> <20200317152303.4600-6-alex.kiernan@gmail.com> Message-ID: On Tue, Mar 17, 2020 at 12:29 PM Alex Kiernan wrote: > > When X11 isn't in DISTRO_FEATURES, remove X11 related files. > > Signed-off-by: Alex Kiernan Acked-by: Otavio Salvador -- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 From otavio.salvador at ossystems.com.br Wed Mar 18 03:06:11 2020 From: otavio.salvador at ossystems.com.br (Otavio Salvador) Date: Wed, 18 Mar 2020 00:06:11 -0300 Subject: [OE-core] [OE-Core][RFC PATCH 06/11] psplash: Set RemainAfterExit on systemd units In-Reply-To: <20200317152303.4600-7-alex.kiernan@gmail.com> References: <20200317152303.4600-1-alex.kiernan@gmail.com> <20200317152303.4600-7-alex.kiernan@gmail.com> Message-ID: On Tue, Mar 17, 2020 at 12:29 PM Alex Kiernan wrote: > > psplash is only expected to run during startup, but if any dependency is > pulled into a transaction and the unit is inactive, then it can be > restarted. > > Set RemainAfterExit to ensure that the unit remains active and is not > gratuitously restarted. > > Drop the nonexistent systemd-start.service from the unit. > > Signed-off-by: Alex Kiernan Acked-by: Otavio Salvador -- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 From otavio.salvador at ossystems.com.br Wed Mar 18 03:06:56 2020 From: otavio.salvador at ossystems.com.br (Otavio Salvador) Date: Wed, 18 Mar 2020 00:06:56 -0300 Subject: [OE-core] [OE-Core][RFC PATCH 07/11] oeqa/runtime/cases: Disable and stop systemd-timesyncd In-Reply-To: <20200317152303.4600-8-alex.kiernan@gmail.com> References: <20200317152303.4600-1-alex.kiernan@gmail.com> <20200317152303.4600-8-alex.kiernan@gmail.com> Message-ID: On Tue, Mar 17, 2020 at 12:29 PM Alex Kiernan wrote: > > Stopping systemd-timesyncd doesn't prevent it being restarted by a > different transaction within systemd. Disable the service instead during > the date test to ensure it can't be restarted. > > Signed-off-by: Alex Kiernan Acked-by: Otavio Salvador -- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 From otavio.salvador at ossystems.com.br Wed Mar 18 03:07:41 2020 From: otavio.salvador at ossystems.com.br (Otavio Salvador) Date: Wed, 18 Mar 2020 00:07:41 -0300 Subject: [OE-core] [OE-Core][RFC PATCH 09/11] systemd: Enable smack based on DISTRO_FEATURES In-Reply-To: <20200317152303.4600-10-alex.kiernan@gmail.com> References: <20200317152303.4600-1-alex.kiernan@gmail.com> <20200317152303.4600-10-alex.kiernan@gmail.com> Message-ID: On Tue, Mar 17, 2020 at 12:30 PM Alex Kiernan wrote: > > Signed-off-by: Alex Kiernan Acked-by: Otavio Salvador -- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 From otavio.salvador at ossystems.com.br Wed Mar 18 03:08:17 2020 From: otavio.salvador at ossystems.com.br (Otavio Salvador) Date: Wed, 18 Mar 2020 00:08:17 -0300 Subject: [OE-core] [OE-Core][RFC PATCH 10/11] systemd: Enable audit based on DISTRO_FEATURES In-Reply-To: <20200317152303.4600-11-alex.kiernan@gmail.com> References: <20200317152303.4600-1-alex.kiernan@gmail.com> <20200317152303.4600-11-alex.kiernan@gmail.com> Message-ID: On Tue, Mar 17, 2020 at 12:30 PM Alex Kiernan wrote: > > Signed-off-by: Alex Kiernan Acked-by: Otavio Salvador -- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 From otavio.salvador at ossystems.com.br Wed Mar 18 03:12:19 2020 From: otavio.salvador at ossystems.com.br (Otavio Salvador) Date: Wed, 18 Mar 2020 00:12:19 -0300 Subject: [OE-core] [OE-Core][RFC PATCH 08/11] systemd: upgrade v244.3 -> v245 In-Reply-To: <20200317152303.4600-9-alex.kiernan@gmail.com> References: <20200317152303.4600-1-alex.kiernan@gmail.com> <20200317152303.4600-9-alex.kiernan@gmail.com> Message-ID: On Tue, Mar 17, 2020 at 12:30 PM Alex Kiernan wrote: > > Refresh patches for v245, enable userdb by default. Update musl patches > for additional missing stdlib headers. Add musl patch to avoid gshadow. Please move this commit as the latest one for multiple reasons: - all previous patches are fixes - most could eventually be backported - they could be merged earlier while the upgrade is under test -- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 From otavio.salvador at ossystems.com.br Wed Mar 18 03:13:27 2020 From: otavio.salvador at ossystems.com.br (Otavio Salvador) Date: Wed, 18 Mar 2020 00:13:27 -0300 Subject: [OE-core] [OE-Core][RFC PATCH 11/11] systemd: Enable acl based on DISTRO_FEATURES In-Reply-To: <20200317152303.4600-12-alex.kiernan@gmail.com> References: <20200317152303.4600-1-alex.kiernan@gmail.com> <20200317152303.4600-12-alex.kiernan@gmail.com> Message-ID: On Tue, Mar 17, 2020 at 12:30 PM Alex Kiernan wrote: > > Signed-off-by: Alex Kiernan Acked-by: Otavio Salvador -- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 From yi.zhao at windriver.com Wed Mar 18 03:38:00 2020 From: yi.zhao at windriver.com (Yi Zhao) Date: Wed, 18 Mar 2020 11:38:00 +0800 Subject: [OE-core] [PATCH] oeqa/manual/bsp-hw.json: fix syntax error Message-ID: <20200318033800.5550-1-yi.zhao@windriver.com> Remove the redundant comma to fix the json decode error: $ resulttool manualexecution ../meta/lib/oeqa/manual/bsp-hw.json Traceback (most recent call last): [snip] File "/usr/lib/python3.6/json/decoder.py", line 357, in raw_decode raise JSONDecodeError("Expecting value", s, err.value) from None json.decoder.JSONDecodeError: Expecting value: line 948 column 1 (char 39810) Signed-off-by: Yi Zhao --- meta/lib/oeqa/manual/bsp-hw.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/lib/oeqa/manual/bsp-hw.json b/meta/lib/oeqa/manual/bsp-hw.json index 73cbaaa7c2..a9bc7d4501 100644 --- a/meta/lib/oeqa/manual/bsp-hw.json +++ b/meta/lib/oeqa/manual/bsp-hw.json @@ -944,5 +944,5 @@ }, "summary": "System_can_boot_up_via_NFS" } - }, + } ] -- 2.17.1 From rahulk at mvista.com Wed Mar 18 09:10:13 2020 From: rahulk at mvista.com (Rahul Kumar) Date: Wed, 18 Mar 2020 14:40:13 +0530 Subject: [OE-core] oe-core (master branch) build failed during enable ptest Message-ID: Hi, I Created OE-Core Standalone Setup. I am building core-image-minimal with openembedded-core (master branch) , bitbake (master branch) and trying to enable ptest for bzip2-ptest. To enable ptest added below lines in local.conf DISTRO_FEATURES_append = " ptest" CORE_IMAGE_EXTRA_INSTALL += "bzip2-ptest" but I am facing below error. ========================= ERROR: busybox-1.31.1-r0 do_package: Error executing a python function in exec_python_func() autogenerated: The stack trace of python calls that resulted in this exception/failure was: File: 'exec_python_func() autogenerated', lineno: 2, function: 0001: *** 0002:ptest_update_alternatives(d) 0003: File: '/opt/opensource/openembedded-core.git/meta/classes/ptest.bbclass', lineno: 98, function: ptest_update_alternatives 0094: for alt_name, alt_link, alt_target, _ in alternatives: 0095: # Some alternatives are for man pages, 0096: # check if the alternative is in PATH 0097: if os.path.dirname(alt_link) in bin_paths: *** 0098: os.symlink(alt_target, os.path.join(ptest_bindir, alt_name)) 0099:} 0100: 0101:do_configure_ptest_base[dirs] = "${B}" 0102:do_compile_ptest_base[dirs] = "${B}" Exception: FileExistsError: [Errno 17] File exists: '/bin/busybox.suid' -> '/opt/opensource/openembedded-core.git/build-master/tmp-glibc/work/core2-64-oe-linux/busybox/1.31.1-r0/package/usr/lib/busybox/ptest/bin/login' ERROR: Logfile of failure stored in: /opt/opensource/openembedded-core.git/build-master/tmp-glibc/work/core2-64-oe-linux/busybox/1.31.1-r0/temp/log.do_package.16217 ERROR: Task (/opt/opensource/openembedded-core.git/meta/recipes-core/busybox/busybox_1.31.1.bb:do_package) failed with exit code '1' ================================ Can group member please provide any pointers on this issue. *Thanks & Regards,* Rahul Kumar Software Engineer,Linux Solutions Engineering Group,Montavista Software LLC Email Id: rahulk at mvista.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From auh at auh.yoctoproject.org Wed Mar 18 11:46:02 2020 From: auh at auh.yoctoproject.org (auh at auh.yoctoproject.org) Date: Wed, 18 Mar 2020 04:46:02 -0700 (PDT) Subject: [OE-core] [AUH] Upgrade status: 2020-03-18 Message-ID: <20200318114602.0DB80440001@auh.yoctoproject.org> Recipe upgrade statistics: * Failed(do_compile): 23 rpcsvc-proto, 1.4.1, Khem Raj gcr, 3.36.0, Alexander Kanavin vulkan-tools, 1.2.131.1, Anuj Mittal xkeyboard-config, 2.29, Armin Kuster alsa-utils, 1.2.2, Tanu Kaskinen libcap, 2.33, Yi Zhao avahi-ui, 0.8, Yi Zhao connman, 1.38, Changhyeok Bae libnotify, 0.7.9, Anuj Mittal vte, 0.60.0, Anuj Mittal epiphany, 3.36.0, Alexander Kanavin wpebackend-fdo, 1.6.0, Alexander Kanavin glib-networking, 2.64.0, Anuj Mittal vulkan-demos, git-new-commits-available, Ross Burton git, 2.25.1, Robert Yang cmake, 3.16.5, Pascal Bach avahi, 0.8, Yi Zhao pulseaudio, 13.99.1, Tanu Kaskinen diffoscope, 137, Joshua Watt libxcrypt, 4.4.15, Khem Raj vulkan-loader, 1.2.131.2, Anuj Mittal clutter-1.0, 1.26.4, Ross Burton gptfdisk, 1.0.5, Alexander Kanavin * Succeeded: 46 bluez5, 5.54, Anuj Mittal gsettings-desktop-schemas, 3.36.0, Anuj Mittal python3-setuptools, 46.0.0, Oleksandr Kravchuk meson, 0.53.2, Alexander Kanavin python3-pycairo, 1.19.1, Oleksandr Kravchuk python3-subunit, 1.4.0, Oleksandr Kravchuk asciidoc, 8.6.10, Yi Zhao lttng-ust, 2.11.1, Richard Purdie python3-pygobject, 3.36.0, Oleksandr Kravchuk python3-testtools, 2.4.0, Oleksandr Kravchuk libsoup-2.4, 2.70.0, Anuj Mittal gtk+3, 3.24.14, Ross Burton ed, 1.16, Alexander Kanavin bison, 3.5.3, Chen Qi libdazzle, 3.36.0, Alexander Kanavin puzzles, 0.0-new-commits-available, Anuj Mittal hwlatdetect, 1.7, Alexander Kanavin libxcrypt-compat, 4.4.15, Khem Raj librepo, 1.11.3, Alexander Kanavin piglit, 1.0-new-commits-available, Ross Burton libwpe, 1.6.0, Alexander Kanavin kmod, 27, Chen Qi vulkan-headers, 1.2.131.1, Anuj Mittal python3-pygments, 2.6.1, Oleksandr Kravchuk dpkg, 1.20.0, An?bal Lim?n alsa-plugins, 1.2.2, Tanu Kaskinen python3-smmap, 3.0.1, Oleksandr Kravchuk python3-git, 3.1.0, Oleksandr Kravchuk at-spi2-core, 2.36.0, Tim Orling libsolv, 0.7.11, Anuj Mittal libical, 3.0.8, Ross Burton cogl-1.0, 1.22.6, Ross Burton sudo, 1.8.31p1, Chen Qi dtc, 1.6.0, Alexander Kanavin createrepo-c, 0.15.9, Alexander Kanavin libsecret, 0.20.2, Alexander Kanavin man-db, 2.9.1, Hongxu Jia alsa-tools, 1.2.2, Tanu Kaskinen python3-mako, 1.1.2, Oleksandr Kravchuk libinput, 1.15.3, Ross Burton at-spi2-atk, 2.34.2, Tim Orling lttng-modules, 2.11.2, Richard Purdie vala, 0.48.1, Alexander Kanavin stress-ng, 0.11.02, Anuj Mittal dnf, 4.2.19, Alexander Kanavin adwaita-icon-theme, 3.36.0, Ross Burton * Failed (devtool error): 28 libdnf, 0.45.0, Alexander Kanavin e2fsprogs, 1.45.5, Robert Yang alsa-topology-conf, 1.2.2, Tanu Kaskinen glib-2.0, 2.64.1, Anuj Mittal rpm, 4.15.1, Mark Hatle bind, 9.16.0, Armin Kuster libxcb, 1.14, Armin Kuster coreutils, 8.32, Chen Qi icu, 66.1, Alexander Kanavin libevdev, 1.9.0, Anuj Mittal apt, 2.0.0, An?bal Lim?n fribidi, 1.0.9, Ross Burton alsa-lib, 1.2.2, Tanu Kaskinen alsa-ucm-conf, 1.2.2, Tanu Kaskinen python3-gitdb, 4.0.2, Oleksandr Kravchuk webkitgtk, 2.28.0, Alexander Kanavin ghostscript, 9.51, Hongxu Jia mc, 4.8.24, Ross Burton xcb-proto, 1.14, Armin Kuster kmscube, git-new-commits-available, Carlos Rafael Giani systemd-boot, 245, Chen Qi rt-tests, 1.7, Alexander Kanavin logrotate, 3.16.0, Yi Zhao python3-numpy, 1.18.1, Oleksandr Kravchuk gobject-introspection, 1.64.0, Alexander Kanavin build-compare, 2019.08.14-new-commits-available, Paul Eggleton ovmf, edk2-stable202002, Ricardo Neri perl, 5.30.2, Alexander Kanavin TOTAL: attempted=97 succeeded=46(47.42%) failed=51(52.58%) Recipe upgrade statistics per Maintainer: Alexander Kanavin Building an SDK on a machine with 8GB RAM resulted in excessive swapping due to the xz compressor using ~20GB of memory. This is because xz is being called with "-T 0 -9". To allow tuning the compression versus memory usage, introduce a variable named SDK_XZ_OPTIONS that defaults to a more sane default: SDK_XZ_OPTIONS ?= "${XZ_DEFAULTS} ${XZ_COMPRESSION_LEVEL}" Thus, inherit any XZ tuning already done, and allow users to specify overrides for this task in their config by supplying SDK_XZ_OPTIONS. Since XZ_COMPRESSION_LEVEL defaults to -9 this does not change the standard behavior. Signed-off-by: Mike Looijmans --- meta/classes/populate_sdk_base.bbclass | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/meta/classes/populate_sdk_base.bbclass b/meta/classes/populate_sdk_base.bbclass index d03465b6fc..13247e42e5 100644 --- a/meta/classes/populate_sdk_base.bbclass +++ b/meta/classes/populate_sdk_base.bbclass @@ -48,6 +48,7 @@ TOOLCHAIN_OUTPUTNAME ?= "${SDK_NAME}-toolchain-${SDK_VERSION}" # Default archived SDK's suffix SDK_ARCHIVE_TYPE ?= "tar.xz" +SDK_XZ_OPTIONS ?= "${XZ_DEFAULTS} ${XZ_COMPRESSION_LEVEL}" # To support different sdk type according to SDK_ARCHIVE_TYPE, now support zip and tar.xz python () { @@ -58,7 +59,7 @@ python () { d.setVar('SDK_ARCHIVE_CMD', 'cd ${SDK_OUTPUT}/${SDKPATH}; zip -r ${SDKDEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.${SDK_ARCHIVE_TYPE} .') else: d.setVar('SDK_ARCHIVE_DEPENDS', 'xz-native') - d.setVar('SDK_ARCHIVE_CMD', 'cd ${SDK_OUTPUT}/${SDKPATH}; tar ${SDKTAROPTS} -cf - . | xz -T 0 -9 > ${SDKDEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.${SDK_ARCHIVE_TYPE}') + d.setVar('SDK_ARCHIVE_CMD', 'cd ${SDK_OUTPUT}/${SDKPATH}; tar ${SDKTAROPTS} -cf - . | xz ${SDK_XZ_OPTIONS} > ${SDKDEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.${SDK_ARCHIVE_TYPE}') } SDK_RDEPENDS = "${TOOLCHAIN_TARGET_TASK} ${TOOLCHAIN_HOST_TASK}" -- 2.17.1 From alex.kanavin at gmail.com Wed Mar 18 13:49:54 2020 From: alex.kanavin at gmail.com (Alexander Kanavin) Date: Wed, 18 Mar 2020 14:49:54 +0100 Subject: [OE-core] [PATCH 1/2] piglit: move to meta-oe In-Reply-To: References: <20200229101433.30787-1-alex.kanavin@gmail.com> <23132fd4872488b259751cdf8bcd8335d703b205.camel@linuxfoundation.org> Message-ID: On Sat, 29 Feb 2020 at 14:42, Alexander Kanavin wrote: > > > I'm not sure about this. The intent was to use piglit as a way of > >> > > improving our graphics testing, particularly allowing it to be >> > > automated. >> > > >> > > Whilst we've had to focus on getting the basics right, I'm not sure >> > > that objective isn't still a worthy goal over time? >> > >> > Piglit is meant for testing and validating OpenGL drivers for real >> > hardware. While we can put it on top of software Mesa driver or >> > virgl, I am not sure there is much value in that? Software rendering >> > might even be too slow to run in practice. >> >> OE-Core is meant to be usable for validating BSPs amongst other things >> though. Testing virgl does prove the graphics stack is working too from >> a software perspective so does have some value. > > > Right, I can put Piglit on top of virgl and see how well that works. It > would be good to enable virgl ?out of the box? at some point, I?ve been > proposing that for a while :) > I found an old ticket where piglit was proposed for the core image testing, and the idea was rejected due to its huge install size, so I won't be pursuing this further. https://bugzilla.yoctoproject.org/show_bug.cgi?id=10047 Would you still say it's worth to keep the recipe in core? Python-numpy (that piglit and only piglit needs) isn't trivial to maintain either (for instance, update to latest version needs cython to be added to core). Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From Daniel.Dragomir at windriver.com Wed Mar 18 16:42:35 2020 From: Daniel.Dragomir at windriver.com (Daniel Dragomir) Date: Wed, 18 Mar 2020 16:42:35 +0000 Subject: [OE-core] [PATCH] lttng-modules: update to 2.11.2 Message-ID: <20200318164235.65997-1-Daniel.Dragomir@windriver.com> Upgrade to version 2.11.2 in order to fix some build errors with latest 5.4 kernel. - conflicting types for 'trace_fast_page_fault' Reproductible on kernel greater than v5.4.19, starting with commit 8a1cd01bee ("KVM: x86: Use gpa_t for cr2/gpa to fix TDP support on 32-bit KVM") Error messages: lttng-modules-2.11.1/probes/../probes/lttng-tracepoint-event-impl.h:130:6: error: 130 | void trace_##_name(_proto); tmp/work-shared/axxiax86-64/kernel-source/include/linux/tracepoint.h:233:21: note: previous definition of 'trace_fast_page_fault' was here 233 | static inline void trace_##name(proto) - conflicting types for 'trace_rcu_dyntick' Reproductible on kernel greater than v5.4.22, starting with commit 6cf539a87a ("rcu: Fix data-race due to atomic_t copy-by-value") Error messages: lttng-modules-2.11.1/probes/../probes/lttng-tracepoint-event-impl.h:130:6: error: conflicting types for 'trace_rcu_dyntick' 130 | void trace_##_name tmp/work-shared/axxiax86-64/kernel-source/include/linux/tracepoint.h:233:21: note: previous definition of 'trace_rcu_dyntick' was here 233 | static inline void trace_##name(proto) Signed-off-by: Daniel Dragomir --- .../{lttng-modules_2.11.1.bb => lttng-modules_2.11.2.bb} | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) rename meta/recipes-kernel/lttng/{lttng-modules_2.11.1.bb => lttng-modules_2.11.2.bb} (86%) diff --git a/meta/recipes-kernel/lttng/lttng-modules_2.11.1.bb b/meta/recipes-kernel/lttng/lttng-modules_2.11.2.bb similarity index 86% rename from meta/recipes-kernel/lttng/lttng-modules_2.11.1.bb rename to meta/recipes-kernel/lttng/lttng-modules_2.11.2.bb index c833ff7009..6fff096a37 100644 --- a/meta/recipes-kernel/lttng/lttng-modules_2.11.1.bb +++ b/meta/recipes-kernel/lttng/lttng-modules_2.11.2.bb @@ -13,8 +13,8 @@ SRC_URI = "https://lttng.org/files/${BPN}/${BPN}-${PV}.tar.bz2 \ file://BUILD_RUNTIME_BUG_ON-vs-gcc7.patch \ " -SRC_URI[md5sum] = "0d964723c8765b39835e5e6efc60a604" -SRC_URI[sha256sum] = "d3e5648937e59dee983ef844f9316c55e9961f9dc8515b9260c473bbb70696c1" +SRC_URI[md5sum] = "2e3bc8cfb264fa13f374618b46f170e7" +SRC_URI[sha256sum] = "8a42240813b8fd1d001835cd6f5ec687f7d7f3b26070d4e21604c35a51a6441d" export INSTALL_MOD_DIR="kernel/lttng-modules" @@ -37,7 +37,7 @@ SRC_URI_class-devupstream = "git://git.lttng.org/lttng-modules;branch=stable-2.1 file://Makefile-Do-not-fail-if-CONFIG_TRACEPOINTS-is-not-en.patch \ file://BUILD_RUNTIME_BUG_ON-vs-gcc7.patch \ " -SRCREV_class-devupstream = "6ad0e68b43c3e52fcb3d47c4d823a7b84aeb443a" -PV_class-devupstream = "2.11.1+git${SRCPV}" +SRCREV_class-devupstream = "17c413953603f063f2a9d6c3788bec914ce6f955" +PV_class-devupstream = "2.11.2+git${SRCPV}" S_class-devupstream = "${WORKDIR}/git" SRCREV_FORMAT ?= "lttng_git" -- 2.17.1 From alex.kiernan at gmail.com Wed Mar 18 17:18:22 2020 From: alex.kiernan at gmail.com (Alex Kiernan) Date: Wed, 18 Mar 2020 17:18:22 +0000 Subject: [OE-core] [OE-Core][RFC PATCH 01/11] systemd: Package udev rules explicitly In-Reply-To: References: <20200317152303.4600-1-alex.kiernan@gmail.com> <20200317152303.4600-2-alex.kiernan@gmail.com> Message-ID: On Wed, Mar 18, 2020 at 3:02 AM Otavio Salvador wrote: > > On Tue, Mar 17, 2020 at 12:29 PM Alex Kiernan wrote: > > udev is packaged before systemd so any wildcard inclusions in FILES will > > override later specifics. List all udev rules explicitly so that the > > systemd specific rules, packaged alongside systemd, appear in the > > correct package. > > > > Signed-off-by: Alex Kiernan > > I believe udev ought to be on PACKAGE_BEFORE_PN so it is still handled > with the wildcard and allow for easier maintenance in future. > It's done with an =+ at the moment, replacing it with PACKAGE_BEFORE_PN would certainly make it clearer (and avoid holes where dev/dbg stuff could leak through). But I don't think that helps with the greedy wildcard problem - we have: FILES_udev += "... ${rootlibexecdir}/udev/rules.d/*.rules \ and FILES_${PN} = " ... ${nonarch_base_libdir}/udev/rules.d/70-uaccess.rules \ ${nonarch_base_libdir}/udev/rules.d/71-seat.rules \ ${nonarch_base_libdir}/udev/rules.d/73-seat-late.rules \ ${nonarch_base_libdir}/udev/rules.d/99-systemd.rules \ Where the FILES_udev consumes all the rules before ${PN} gets a look in, unless there's some magic I'm overlooking? The inconsistent path usage wants fixing too... I'd not noticed that before! -- Alex Kiernan From richard.purdie at linuxfoundation.org Wed Mar 18 21:31:52 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Wed, 18 Mar 2020 21:31:52 +0000 Subject: [OE-core] [PATCH 1/2] piglit: move to meta-oe In-Reply-To: References: <20200229101433.30787-1-alex.kanavin@gmail.com> <23132fd4872488b259751cdf8bcd8335d703b205.camel@linuxfoundation.org> Message-ID: <5839fa696c78f06c668fe8cb8dbd0a80732c7bbd.camel@linuxfoundation.org> On Wed, 2020-03-18 at 14:49 +0100, Alexander Kanavin wrote: > On Sat, 29 Feb 2020 at 14:42, Alexander Kanavin < > alex.kanavin at gmail.com> wrote: > > > > I'm not sure about this. The intent was to use piglit as a way > > of > > > > > improving our graphics testing, particularly allowing it to > > > be > > > > > automated. > > > > > > > > > > Whilst we've had to focus on getting the basics right, I'm > > > not sure > > > > > that objective isn't still a worthy goal over time? > > > > > > > > Piglit is meant for testing and validating OpenGL drivers for > > > real > > > > hardware. While we can put it on top of software Mesa driver or > > > > virgl, I am not sure there is much value in that? Software > > > rendering > > > > might even be too slow to run in practice. > > > > > > OE-Core is meant to be usable for validating BSPs amongst other > > > things > > > though. Testing virgl does prove the graphics stack is working > > > too from > > > a software perspective so does have some value. > > > > Right, I can put Piglit on top of virgl and see how well that > > works. It would be good to enable virgl ?out of the box? at some > > point, I?ve been proposing that for a while :) > > > > I found an old ticket where piglit was proposed for the core image > testing, and the idea was rejected due to its huge install size, so I > won't be pursuing this further. > https://bugzilla.yoctoproject.org/show_bug.cgi?id=10047 > > Would you still say it's worth to keep the recipe in core? Python- > numpy (that piglit and only piglit needs) isn't trivial to maintain > either (for instance, update to latest version needs cython to be > added to core). That bug is for piglit as a default in testapps. We decided that was a bad idea, not that testing with piglit was a bad idea overall. Cheers, Richard From otavio.salvador at ossystems.com.br Wed Mar 18 23:18:03 2020 From: otavio.salvador at ossystems.com.br (Otavio Salvador) Date: Wed, 18 Mar 2020 20:18:03 -0300 Subject: [OE-core] [OE-Core][RFC PATCH 01/11] systemd: Package udev rules explicitly In-Reply-To: References: <20200317152303.4600-1-alex.kiernan@gmail.com> <20200317152303.4600-2-alex.kiernan@gmail.com> Message-ID: On Wed, Mar 18, 2020 at 2:19 PM Alex Kiernan wrote: > > On Wed, Mar 18, 2020 at 3:02 AM Otavio Salvador > wrote: > > > > On Tue, Mar 17, 2020 at 12:29 PM Alex Kiernan wrote: > > > udev is packaged before systemd so any wildcard inclusions in FILES will > > > override later specifics. List all udev rules explicitly so that the > > > systemd specific rules, packaged alongside systemd, appear in the > > > correct package. > > > > > > Signed-off-by: Alex Kiernan > > > > I believe udev ought to be on PACKAGE_BEFORE_PN so it is still handled > > with the wildcard and allow for easier maintenance in future. > > > > It's done with an =+ at the moment, replacing it with > PACKAGE_BEFORE_PN would certainly make it clearer (and avoid holes > where dev/dbg stuff could leak through). But I don't think that helps > with the greedy wildcard problem - we have: > > FILES_udev += "... > ${rootlibexecdir}/udev/rules.d/*.rules \ > > and > > FILES_${PN} = " ... > ${nonarch_base_libdir}/udev/rules.d/70-uaccess.rules \ > ${nonarch_base_libdir}/udev/rules.d/71-seat.rules \ > ${nonarch_base_libdir}/udev/rules.d/73-seat-late.rules \ > ${nonarch_base_libdir}/udev/rules.d/99-systemd.rules \ > > Where the FILES_udev consumes all the rules before ${PN} gets a look > in, unless there's some magic I'm overlooking? > > The inconsistent path usage wants fixing too... I'd not noticed that before! Oh, now I see. This is indeed a real problem. A more long-term friendly approach would be to create a new ${PN}-rules package which is packaged before udev and is added as rdepends on ${PN}. Another alternative is package ${PN} prior udev. Personally I dislike listing all rules as we can easily miss a removal of any in the future and the list become outdated. -- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 From schnitzeltony at gmail.com Thu Mar 19 01:12:05 2020 From: schnitzeltony at gmail.com (=?UTF-8?q?Andreas=20M=C3=BCller?=) Date: Thu, 19 Mar 2020 02:12:05 +0100 Subject: [OE-core] [PATCH 1/2] libnotify: upgrade 0.7.8 -> 0.7.9 / port to meson Message-ID: <20200319011206.14726-1-schnitzeltony@gmail.com> >From [1]: New in 0.7.9 ============ * Fixed linking in darwin [Iain, Marco; !5] * Added man page for notify-send [Jan; !6] * Dropped autotools [Jan; !11] [1] http://ftp.gnome.org/pub/gnome/sources/libnotify/0.7/libnotify-0.7.9.news Signed-off-by: Andreas M?ller --- .../{libnotify_0.7.8.bb => libnotify_0.7.9.bb} | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) rename meta/recipes-gnome/libnotify/{libnotify_0.7.8.bb => libnotify_0.7.9.bb} (59%) diff --git a/meta/recipes-gnome/libnotify/libnotify_0.7.8.bb b/meta/recipes-gnome/libnotify/libnotify_0.7.9.bb similarity index 59% rename from meta/recipes-gnome/libnotify/libnotify_0.7.8.bb rename to meta/recipes-gnome/libnotify/libnotify_0.7.9.bb index 0306b04f4e..38da41639b 100644 --- a/meta/recipes-gnome/libnotify/libnotify_0.7.8.bb +++ b/meta/recipes-gnome/libnotify/libnotify_0.7.9.bb @@ -7,12 +7,20 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=7fbc338309ac38fefcd64b04bb903e34" DEPENDS = "dbus gtk+3 glib-2.0" -inherit gnomebase gtk-doc features_check gobject-introspection +GNOMEBASEBUILDCLASS = "meson" + +inherit gnomebase gtk-doc features_check gobject-introspection manpages # depends on gtk+3 ANY_OF_DISTRO_FEATURES = "${GTK3DISTROFEATURES}" -SRC_URI[archive.md5sum] = "babb4b07b5f21bef42a386d3d7019599" -SRC_URI[archive.sha256sum] = "69209e0b663776a00c7b6c0e560302a8dbf66b2551d55616304f240bba66e18c" +SRC_URI[archive.md5sum] = "ccd9c53364174cc8d13e18a1988faa76" +SRC_URI[archive.sha256sum] = "66c0517ed16df7af258e83208faaf5069727dfd66995c4bbc51c16954d674761" + +GIR_MESON_ENABLE_FLAG = 'enabled' +GIR_MESON_DISABLE_FLAG = 'disabled' +GTKDOC_MESON_OPTION = 'gtk_doc' + +PACKAGECONFIG[manpages] = "-Dman=true,-Dman=false,libxslt-native xmlto-native" # there were times, we had two versions of libnotify (oe-core libnotify:0.6.x / # meta-gnome libnotify3: 0.7.x) -- 2.21.1 From schnitzeltony at gmail.com Thu Mar 19 01:12:06 2020 From: schnitzeltony at gmail.com (=?UTF-8?q?Andreas=20M=C3=BCller?=) Date: Thu, 19 Mar 2020 02:12:06 +0100 Subject: [OE-core] [PATCH 2/2] libsecret: upgrade 0.20.1 -> 0.20.2 / port to meson In-Reply-To: <20200319011206.14726-1-schnitzeltony@gmail.com> References: <20200319011206.14726-1-schnitzeltony@gmail.com> Message-ID: <20200319011206.14726-2-schnitzeltony@gmail.com> >From [1]: 0.20.2 * secret-file-collection: force little-endian in GVariant [!49, #42] * Prefer g_info() over g_message() [!48, #40] * meson: Don't specify shared_library() [!47] * docs: Make sure to set install: true [!46] [1] http://ftp.gnome.org/pub/gnome/sources/libsecret/0.20/libsecret-0.20.2.news Signed-off-by: Andreas M?ller --- ...an-subdir-only-if-manpage-is-enabled.patch | 30 +++++++++++++++++++ ...ibsecret_0.20.1.bb => libsecret_0.20.2.bb} | 20 ++++++++----- 2 files changed, 42 insertions(+), 8 deletions(-) create mode 100644 meta/recipes-gnome/libsecret/libsecret/0001-docs-Add-man-subdir-only-if-manpage-is-enabled.patch rename meta/recipes-gnome/libsecret/{libsecret_0.20.1.bb => libsecret_0.20.2.bb} (59%) diff --git a/meta/recipes-gnome/libsecret/libsecret/0001-docs-Add-man-subdir-only-if-manpage-is-enabled.patch b/meta/recipes-gnome/libsecret/libsecret/0001-docs-Add-man-subdir-only-if-manpage-is-enabled.patch new file mode 100644 index 0000000000..f434e6ae01 --- /dev/null +++ b/meta/recipes-gnome/libsecret/libsecret/0001-docs-Add-man-subdir-only-if-manpage-is-enabled.patch @@ -0,0 +1,30 @@ +From a2037bfcf14a0b5b81f5160b69b5ff94a6096584 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Andreas=20M=C3=BCller?= +Date: Thu, 19 Mar 2020 01:42:22 +0100 +Subject: [PATCH] docs: Add man subdir only if manpage is enabled +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +Upstream-Status: Submitted [https://gitlab.gnome.org/GNOME/libsecret/-/merge_requests/51] + +Signed-off-by: Andreas M?ller +--- + docs/meson.build | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +diff --git a/docs/meson.build b/docs/meson.build +index cc8d964..aa7cfbc 100644 +--- a/docs/meson.build ++++ b/docs/meson.build +@@ -1,4 +1,6 @@ +-subdir('man') ++if with_manpage ++ subdir('man') ++endif + if with_gtkdoc + subdir('reference/libsecret') + endif +-- +2.21.1 + diff --git a/meta/recipes-gnome/libsecret/libsecret_0.20.1.bb b/meta/recipes-gnome/libsecret/libsecret_0.20.2.bb similarity index 59% rename from meta/recipes-gnome/libsecret/libsecret_0.20.1.bb rename to meta/recipes-gnome/libsecret/libsecret_0.20.2.bb index 72511af02d..0effd492fd 100644 --- a/meta/recipes-gnome/libsecret/libsecret_0.20.1.bb +++ b/meta/recipes-gnome/libsecret/libsecret_0.20.2.bb @@ -7,21 +7,25 @@ LICENSE = "LGPLv2.1" BUGTRACKER = "https://gitlab.gnome.org/GNOME/libsecret/issues" LIC_FILES_CHKSUM = "file://COPYING;md5=23c2a5e0106b99d75238986559bb5fc6" +GNOMEBASEBUILDCLASS = "meson" + inherit gnomebase gtk-doc vala gobject-introspection manpages DEPENDS += "glib-2.0 libgcrypt gettext-native" -PACKAGECONFIG[manpages] = "--enable-manpages, --disable-manpages, libxslt-native xmlto-native" +SRC_URI[archive.md5sum] = "f24f82e49d360ff742901d6c387e2bc9" +SRC_URI[archive.sha256sum] = "81e9143833785cdcf96c1da5d0357a8bcf0cd2b0119f15aa0cae775d1f19ffc3" +SRC_URI += "file://0001-docs-Add-man-subdir-only-if-manpage-is-enabled.patch" + +GTKDOC_MESON_OPTION = 'gtk_doc' -SRC_URI[archive.md5sum] = "d2dd660a8d502099317bc8af9f30302e" -SRC_URI[archive.sha256sum] = "57f73e94ec6263a17a077fb809cf8cf424637a897a7f15b4eec42ce4aef52447" +# gobject-introspection is mandatory and cannot be configured +REQUIRED_DISTRO_FEATURES = "gobject-introspection-data" +UNKNOWN_CONFIGURE_WHITELIST_append = " introspection" + +PACKAGECONFIG[manpages] = "-Dmanpage=true,-Dmanpage=false,libxslt-native xmlto-native" # http://errors.yoctoproject.org/Errors/Details/20228/ ARM_INSTRUCTION_SET_armv4 = "arm" ARM_INSTRUCTION_SET_armv5 = "arm" ARM_INSTRUCTION_SET_armv6 = "arm" - -# vapigen.m4 bundled with the tarball does not yet have our cross-compilation fixes -do_configure_prepend() { - rm -f ${S}/build/m4/vapigen.m4 -} -- 2.21.1 From wangmy at cn.fujitsu.com Thu Mar 19 07:41:42 2020 From: wangmy at cn.fujitsu.com (Wang Mingyu) Date: Thu, 19 Mar 2020 00:41:42 -0700 Subject: [OE-core] [PATCH] bluez5: upgrade 5.53 -> 5.54 Message-ID: <1584603707-43423-1-git-send-email-wangmy@cn.fujitsu.com> CVE-2020-0556-1.patch CVE-2020-0556-2.patch removed since they are included in 5.54 Signed-off-by: Wang Mingyu --- meta/recipes-connectivity/bluez5/bluez5.inc | 2 - .../bluez5/bluez5/CVE-2020-0556-1.patch | 35 ----- .../bluez5/bluez5/CVE-2020-0556-2.patch | 143 ------------------ .../bluez5/{bluez5_5.53.bb => bluez5_5.54.bb} | 4 +- 4 files changed, 2 insertions(+), 182 deletions(-) delete mode 100644 meta/recipes-connectivity/bluez5/bluez5/CVE-2020-0556-1.patch delete mode 100644 meta/recipes-connectivity/bluez5/bluez5/CVE-2020-0556-2.patch rename meta/recipes-connectivity/bluez5/{bluez5_5.53.bb => bluez5_5.54.bb} (91%) diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc b/meta/recipes-connectivity/bluez5/bluez5.inc index 708fa1ccec..150d909d73 100644 --- a/meta/recipes-connectivity/bluez5/bluez5.inc +++ b/meta/recipes-connectivity/bluez5/bluez5.inc @@ -52,8 +52,6 @@ SRC_URI = "${KERNELORG_MIRROR}/linux/bluetooth/bluez-${PV}.tar.xz \ ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', '', 'file://0001-Allow-using-obexd-without-systemd-in-the-user-sessio.patch', d)} \ file://0001-tests-add-a-target-for-building-tests-without-runnin.patch \ file://0001-test-gatt-Fix-hung-issue.patch \ - file://CVE-2020-0556-1.patch \ - file://CVE-2020-0556-2.patch \ " S = "${WORKDIR}/bluez-${PV}" diff --git a/meta/recipes-connectivity/bluez5/bluez5/CVE-2020-0556-1.patch b/meta/recipes-connectivity/bluez5/bluez5/CVE-2020-0556-1.patch deleted file mode 100644 index a6bf31e14b..0000000000 --- a/meta/recipes-connectivity/bluez5/bluez5/CVE-2020-0556-1.patch +++ /dev/null @@ -1,35 +0,0 @@ -From 8cdbd3b09f29da29374e2f83369df24228da0ad1 Mon Sep 17 00:00:00 2001 -From: Alain Michaud -Date: Tue, 10 Mar 2020 02:35:16 +0000 -Subject: [PATCH 1/2] HOGP must only accept data from bonded devices. - -HOGP 1.0 Section 6.1 establishes that the HOGP must require bonding. - -Reference: -https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00352.htm - -Upstream-Status: Backport [https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=8cdbd3b09f29da29374e2f83369df24228da0ad1] -Signed-off-by: Anuj Mittal -CVE: CVE-2020-0556 ---- - profiles/input/hog.c | 4 ++++ - 1 file changed, 4 insertions(+) - -diff --git a/profiles/input/hog.c b/profiles/input/hog.c -index 83c017dcb..dfac68921 100644 ---- a/profiles/input/hog.c -+++ b/profiles/input/hog.c -@@ -186,6 +186,10 @@ static int hog_accept(struct btd_service *service) - return -EINVAL; - } - -+ /* HOGP 1.0 Section 6.1 requires bonding */ -+ if (!device_is_bonded(device, btd_device_get_bdaddr_type(device))) -+ return -ECONNREFUSED; -+ - /* TODO: Replace GAttrib with bt_gatt_client */ - bt_hog_attach(dev->hog, attrib); - --- -2.24.1 - diff --git a/meta/recipes-connectivity/bluez5/bluez5/CVE-2020-0556-2.patch b/meta/recipes-connectivity/bluez5/bluez5/CVE-2020-0556-2.patch deleted file mode 100644 index 8acb2f15ec..0000000000 --- a/meta/recipes-connectivity/bluez5/bluez5/CVE-2020-0556-2.patch +++ /dev/null @@ -1,143 +0,0 @@ -From 3cccdbab2324086588df4ccf5f892fb3ce1f1787 Mon Sep 17 00:00:00 2001 -From: Alain Michaud -Date: Tue, 10 Mar 2020 02:35:18 +0000 -Subject: [PATCH 2/2] HID accepts bonded device connections only. - -This change adds a configuration for platforms to choose a more secure -posture for the HID profile. While some older mice are known to not -support pairing or encryption, some platform may choose a more secure -posture by requiring the device to be bonded and require the -connection to be encrypted when bonding is required. - -Reference: -https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00352.html - -Upstream-Status: Backport [https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=3cccdbab2324086588df4ccf5f892fb3ce1f1787] -Signed-off-by: Anuj Mittal -CVE: CVE-2020-0556 - ---- - profiles/input/device.c | 23 ++++++++++++++++++++++- - profiles/input/device.h | 1 + - profiles/input/input.conf | 8 ++++++++ - profiles/input/manager.c | 13 ++++++++++++- - 4 files changed, 43 insertions(+), 2 deletions(-) - -diff --git a/profiles/input/device.c b/profiles/input/device.c -index 2cb3811c8..d89da2d7c 100644 ---- a/profiles/input/device.c -+++ b/profiles/input/device.c -@@ -92,6 +92,7 @@ struct input_device { - - static int idle_timeout = 0; - static bool uhid_enabled = false; -+static bool classic_bonded_only = false; - - void input_set_idle_timeout(int timeout) - { -@@ -103,6 +104,11 @@ void input_enable_userspace_hid(bool state) - uhid_enabled = state; - } - -+void input_set_classic_bonded_only(bool state) -+{ -+ classic_bonded_only = state; -+} -+ - static void input_device_enter_reconnect_mode(struct input_device *idev); - static int connection_disconnect(struct input_device *idev, uint32_t flags); - -@@ -970,8 +976,18 @@ static int hidp_add_connection(struct input_device *idev) - if (device_name_known(idev->device)) - device_get_name(idev->device, req->name, sizeof(req->name)); - -+ /* Make sure the device is bonded if required */ -+ if (classic_bonded_only && !device_is_bonded(idev->device, -+ btd_device_get_bdaddr_type(idev->device))) { -+ error("Rejected connection from !bonded device %s", dst_addr); -+ goto cleanup; -+ } -+ - /* Encryption is mandatory for keyboards */ -- if (req->subclass & 0x40) { -+ /* Some platforms may choose to require encryption for all devices */ -+ /* Note that this only matters for pre 2.1 devices as otherwise the */ -+ /* device is encrypted by default by the lower layers */ -+ if (classic_bonded_only || req->subclass & 0x40) { - if (!bt_io_set(idev->intr_io, &gerr, - BT_IO_OPT_SEC_LEVEL, BT_IO_SEC_MEDIUM, - BT_IO_OPT_INVALID)) { -@@ -1203,6 +1219,11 @@ static void input_device_enter_reconnect_mode(struct input_device *idev) - DBG("path=%s reconnect_mode=%s", idev->path, - reconnect_mode_to_string(idev->reconnect_mode)); - -+ /* Make sure the device is bonded if required */ -+ if (classic_bonded_only && !device_is_bonded(idev->device, -+ btd_device_get_bdaddr_type(idev->device))) -+ return; -+ - /* Only attempt an auto-reconnect when the device is required to - * accept reconnections from the host. - */ -diff --git a/profiles/input/device.h b/profiles/input/device.h -index 51a9aee18..3044db673 100644 ---- a/profiles/input/device.h -+++ b/profiles/input/device.h -@@ -29,6 +29,7 @@ struct input_conn; - - void input_set_idle_timeout(int timeout); - void input_enable_userspace_hid(bool state); -+void input_set_classic_bonded_only(bool state); - - int input_device_register(struct btd_service *service); - void input_device_unregister(struct btd_service *service); -diff --git a/profiles/input/input.conf b/profiles/input/input.conf -index 3e1d65aae..166aff4a4 100644 ---- a/profiles/input/input.conf -+++ b/profiles/input/input.conf -@@ -11,3 +11,11 @@ - # Enable HID protocol handling in userspace input profile - # Defaults to false (HIDP handled in HIDP kernel module) - #UserspaceHID=true -+ -+# Limit HID connections to bonded devices -+# The HID Profile does not specify that devices must be bonded, however some -+# platforms may want to make sure that input connections only come from bonded -+# device connections. Several older mice have been known for not supporting -+# pairing/encryption. -+# Defaults to false to maximize device compatibility. -+#ClassicBondedOnly=true -diff --git a/profiles/input/manager.c b/profiles/input/manager.c -index 1d31b0652..5cd27b839 100644 ---- a/profiles/input/manager.c -+++ b/profiles/input/manager.c -@@ -96,7 +96,7 @@ static int input_init(void) - config = load_config_file(CONFIGDIR "/input.conf"); - if (config) { - int idle_timeout; -- gboolean uhid_enabled; -+ gboolean uhid_enabled, classic_bonded_only; - - idle_timeout = g_key_file_get_integer(config, "General", - "IdleTimeout", &err); -@@ -114,6 +114,17 @@ static int input_init(void) - input_enable_userspace_hid(uhid_enabled); - } else - g_clear_error(&err); -+ -+ classic_bonded_only = g_key_file_get_boolean(config, "General", -+ "ClassicBondedOnly", &err); -+ -+ if (!err) { -+ DBG("input.conf: ClassicBondedOnly=%s", -+ classic_bonded_only ? "true" : "false"); -+ input_set_classic_bonded_only(classic_bonded_only); -+ } else -+ g_clear_error(&err); -+ - } - - btd_profile_register(&input_profile); --- -2.24.1 - diff --git a/meta/recipes-connectivity/bluez5/bluez5_5.53.bb b/meta/recipes-connectivity/bluez5/bluez5_5.54.bb similarity index 91% rename from meta/recipes-connectivity/bluez5/bluez5_5.53.bb rename to meta/recipes-connectivity/bluez5/bluez5_5.54.bb index 055e76bcf1..260eee1402 100644 --- a/meta/recipes-connectivity/bluez5/bluez5_5.53.bb +++ b/meta/recipes-connectivity/bluez5/bluez5_5.54.bb @@ -1,7 +1,7 @@ require bluez5.inc -SRC_URI[md5sum] = "85b14abb138948f50b1650aa866cb019" -SRC_URI[sha256sum] = "38aa2da8302fefad53116bb281a11968732a42eeb19c5fb3668342f39b7938bc" +SRC_URI[md5sum] = "e637feb2dbb7582bbbff1708367a847c" +SRC_URI[sha256sum] = "68cdab9e63e8832b130d5979dc8c96fdb087b31278f342874d992af3e56656dc" # noinst programs in Makefile.tools that are conditional on READLINE # support -- 2.17.1 From wangmy at cn.fujitsu.com Thu Mar 19 07:41:43 2020 From: wangmy at cn.fujitsu.com (Wang Mingyu) Date: Thu, 19 Mar 2020 00:41:43 -0700 Subject: [OE-core] [PATCH] fribidi: upgrade 1.0.8 -> 1.0.9 In-Reply-To: <1584603707-43423-1-git-send-email-wangmy@cn.fujitsu.com> References: <1584603707-43423-1-git-send-email-wangmy@cn.fujitsu.com> Message-ID: <1584603707-43423-2-git-send-email-wangmy@cn.fujitsu.com> Signed-off-by: Wang Mingyu --- .../fribidi/{fribidi_1.0.8.bb => fribidi_1.0.9.bb} | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) rename meta/recipes-support/fribidi/{fribidi_1.0.8.bb => fribidi_1.0.9.bb} (72%) diff --git a/meta/recipes-support/fribidi/fribidi_1.0.8.bb b/meta/recipes-support/fribidi/fribidi_1.0.9.bb similarity index 72% rename from meta/recipes-support/fribidi/fribidi_1.0.8.bb rename to meta/recipes-support/fribidi/fribidi_1.0.9.bb index bab068f3b9..21217aba5e 100644 --- a/meta/recipes-support/fribidi/fribidi_1.0.8.bb +++ b/meta/recipes-support/fribidi/fribidi_1.0.9.bb @@ -3,10 +3,10 @@ SECTION = "libs" LICENSE = "LGPLv2.1+" LIC_FILES_CHKSUM = "file://COPYING;md5=a916467b91076e631dd8edb7424769c7" -SRC_URI = "https://github.com/${BPN}/${BPN}/releases/download/v${PV}/${BP}.tar.bz2 \ +SRC_URI = "https://github.com/${BPN}/${BPN}/releases/download/v${PV}/${BP}.tar.xz \ " -SRC_URI[md5sum] = "962c7d8ebaa711d4e306161dbe14aa55" -SRC_URI[sha256sum] = "94c7b68d86ad2a9613b4dcffe7bbeb03523d63b5b37918bdf2e4ef34195c1e6c" +SRC_URI[md5sum] = "1b767c259c3cd8e0c8496970f63c22dc" +SRC_URI[sha256sum] = "c5e47ea9026fb60da1944da9888b4e0a18854a0e2410bbfe7ad90a054d36e0c7" UPSTREAM_CHECK_URI = "https://github.com/${BPN}/${BPN}/releases" -- 2.17.1 From wangmy at cn.fujitsu.com Thu Mar 19 07:41:44 2020 From: wangmy at cn.fujitsu.com (Wang Mingyu) Date: Thu, 19 Mar 2020 00:41:44 -0700 Subject: [OE-core] [PATCH] glew: upgrade 2.1.0 -> 2.2.0 In-Reply-To: <1584603707-43423-1-git-send-email-wangmy@cn.fujitsu.com> References: <1584603707-43423-1-git-send-email-wangmy@cn.fujitsu.com> Message-ID: <1584603707-43423-3-git-send-email-wangmy@cn.fujitsu.com> 0001-Fixed-compilation-with-current-mesa-versions.patch removed since it is included in 2.2.0 Signed-off-by: Wang Mingyu --- ...mpilation-with-current-mesa-versions.patch | 73 ------------------- .../glew/{glew_2.1.0.bb => glew_2.2.0.bb} | 7 +- 2 files changed, 3 insertions(+), 77 deletions(-) delete mode 100644 meta/recipes-graphics/glew/glew/0001-Fixed-compilation-with-current-mesa-versions.patch rename meta/recipes-graphics/glew/{glew_2.1.0.bb => glew_2.2.0.bb} (87%) diff --git a/meta/recipes-graphics/glew/glew/0001-Fixed-compilation-with-current-mesa-versions.patch b/meta/recipes-graphics/glew/glew/0001-Fixed-compilation-with-current-mesa-versions.patch deleted file mode 100644 index 64f3e2fd9b..0000000000 --- a/meta/recipes-graphics/glew/glew/0001-Fixed-compilation-with-current-mesa-versions.patch +++ /dev/null @@ -1,73 +0,0 @@ -From 7f65a36866f4e24dd1446fe1c9d21424f28bcabd Mon Sep 17 00:00:00 2001 -From: Deve -Date: Wed, 14 Nov 2018 21:07:29 +0100 -Subject: [PATCH] Fixed compilation with current mesa versions. - -As you can see in -https://cgit.freedesktop.org/mesa/mesa/tree/include/GL/glext.h -now the file uses __gl_glext_h_ instead of __glext_h_ -It's precisely caused by commit f7d42ee7d319256608ad60778f6787c140badada - -Backoprt notes: - -* The original patch adjusts auto/src/glew_head.h only -* include/GL/glew.h is not part of git repo and gets created on tarball - creation - -=> patch include/GL/glew.h either to cause the desired fix - -Upstream-Status: Backport [1] - -[1] https://github.com/nigels-com/glew/commit/7f65a36866f4e24dd1446fe1c9d21424f28bcabd - -Signed-off-by: Andreas M??ller ---- - auto/src/glew_head.h | 3 ++- - include/GL/glew.h | 3 ++- - 2 files changed, 4 insertions(+), 2 deletions(-) - -diff --git a/auto/src/glew_head.h b/auto/src/glew_head.h -index c19cefb..8f313d9 100644 ---- a/auto/src/glew_head.h -+++ b/auto/src/glew_head.h -@@ -14,7 +14,7 @@ - #if defined(__REGAL_H__) - #error Regal.h included before glew.h - #endif --#if defined(__glext_h_) || defined(__GLEXT_H_) -+#if defined(__glext_h_) || defined(__GLEXT_H_) || defined(__gl_glext_h_) - #error glext.h included before glew.h - #endif - #if defined(__gl_ATI_h_) -@@ -30,6 +30,7 @@ - #define __X_GL_H - #define __glext_h_ - #define __GLEXT_H_ -+#define __gl_glext_h_ - #define __gl_ATI_h_ - - #if defined(_WIN32) -diff --git a/include/GL/glew.h b/include/GL/glew.h -index b5b6987..a9f9e4b 100644 ---- a/include/GL/glew.h -+++ b/include/GL/glew.h -@@ -93,7 +93,7 @@ - #if defined(__REGAL_H__) - #error Regal.h included before glew.h - #endif --#if defined(__glext_h_) || defined(__GLEXT_H_) -+#if defined(__glext_h_) || defined(__GLEXT_H_) || defined(__gl_glext_h_) - #error glext.h included before glew.h - #endif - #if defined(__gl_ATI_h_) -@@ -109,6 +109,7 @@ - #define __X_GL_H - #define __glext_h_ - #define __GLEXT_H_ -+#define __gl_glext_h_ - #define __gl_ATI_h_ - - #if defined(_WIN32) --- -2.20.1 - diff --git a/meta/recipes-graphics/glew/glew_2.1.0.bb b/meta/recipes-graphics/glew/glew_2.2.0.bb similarity index 87% rename from meta/recipes-graphics/glew/glew_2.1.0.bb rename to meta/recipes-graphics/glew/glew_2.2.0.bb index edcbdc0a7a..8948444e08 100644 --- a/meta/recipes-graphics/glew/glew_2.1.0.bb +++ b/meta/recipes-graphics/glew/glew_2.2.0.bb @@ -6,11 +6,10 @@ LICENSE = "MIT" LIC_FILES_CHKSUM = "file://LICENSE.txt;md5=2ac251558de685c6b9478d89be3149c2" SRC_URI = "${SOURCEFORGE_MIRROR}/project/glew/glew/${PV}/glew-${PV}.tgz \ - file://no-strip.patch \ - file://0001-Fixed-compilation-with-current-mesa-versions.patch" + file://no-strip.patch" -SRC_URI[md5sum] = "b2ab12331033ddfaa50dc39345343980" -SRC_URI[sha256sum] = "04de91e7e6763039bc11940095cd9c7f880baba82196a7765f727ac05a993c95" +SRC_URI[md5sum] = "3579164bccaef09e36c0af7f4fd5c7c7" +SRC_URI[sha256sum] = "d4fc82893cfb00109578d0a1a2337fb8ca335b3ceccf97b97e5cc7f08e4353e1" UPSTREAM_CHECK_URI = "http://sourceforge.net/projects/glew/files/glew" UPSTREAM_CHECK_REGEX = "/glew/(?P(\d+[\.\-_]*)+)/" -- 2.17.1 From wangmy at cn.fujitsu.com Thu Mar 19 07:41:45 2020 From: wangmy at cn.fujitsu.com (Wang Mingyu) Date: Thu, 19 Mar 2020 00:41:45 -0700 Subject: [OE-core] [PATCH] icu: upgrade 65.1 ->66.1 In-Reply-To: <1584603707-43423-1-git-send-email-wangmy@cn.fujitsu.com> References: <1584603707-43423-1-git-send-email-wangmy@cn.fujitsu.com> Message-ID: <1584603707-43423-4-git-send-email-wangmy@cn.fujitsu.com> -License-Update: Copyright year updated to 2020. Signed-off-by: Wang Mingyu --- meta/recipes-support/icu/{icu_65.1.bb => icu_66.1.bb} | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) rename meta/recipes-support/icu/{icu_65.1.bb => icu_66.1.bb} (82%) diff --git a/meta/recipes-support/icu/icu_65.1.bb b/meta/recipes-support/icu/icu_66.1.bb similarity index 82% rename from meta/recipes-support/icu/icu_65.1.bb rename to meta/recipes-support/icu/icu_66.1.bb index bd932d7db4..5018464c14 100644 --- a/meta/recipes-support/icu/icu_65.1.bb +++ b/meta/recipes-support/icu/icu_66.1.bb @@ -1,6 +1,6 @@ require icu.inc -LIC_FILES_CHKSUM = "file://../LICENSE;md5=8bc5d32052a96f214cbdd1e53dfc935d" +LIC_FILES_CHKSUM = "file://../LICENSE;md5=a3808a5b70071b07f87ff2205e4d75a0" def icu_download_version(d): pvsplit = d.getVar('PV').split('.') @@ -28,8 +28,8 @@ SRC_URI = "${BASE_SRC_URI} \ SRC_URI_append_class-target = "\ file://0001-Disable-LDFLAGSICUDT-for-Linux.patch \ " -SRC_URI[md5sum] = "d1ff436e26cabcb28e6cb383d32d1339" -SRC_URI[sha256sum] = "53e37466b3d6d6d01ead029e3567d873a43a5d1c668ed2278e253b683136d948" +SRC_URI[md5sum] = "b33dc6766711517c98d318447e5110f8" +SRC_URI[sha256sum] = "52a3f2209ab95559c1cf0a14f24338001f389615bf00e2585ef3dbc43ecf0a2e" UPSTREAM_CHECK_REGEX = "icu4c-(?P\d+(_\d+)+)-src" UPSTREAM_CHECK_URI = "https://github.com/unicode-org/icu/releases" -- 2.17.1 From wangmy at cn.fujitsu.com Thu Mar 19 07:41:46 2020 From: wangmy at cn.fujitsu.com (Wang Mingyu) Date: Thu, 19 Mar 2020 00:41:46 -0700 Subject: [OE-core] [PATCH] libxcrypt: upgrade 4.4.14 -> 4.4.15 In-Reply-To: <1584603707-43423-1-git-send-email-wangmy@cn.fujitsu.com> References: <1584603707-43423-1-git-send-email-wangmy@cn.fujitsu.com> Message-ID: <1584603707-43423-5-git-send-email-wangmy@cn.fujitsu.com> Signed-off-by: Wang Mingyu --- .../{libxcrypt-compat_4.4.14.bb => libxcrypt-compat_4.4.15.bb} | 0 meta/recipes-core/libxcrypt/libxcrypt.inc | 2 +- .../libxcrypt/{libxcrypt_4.4.14.bb => libxcrypt_4.4.15.bb} | 0 3 files changed, 1 insertion(+), 1 deletion(-) rename meta/recipes-core/libxcrypt/{libxcrypt-compat_4.4.14.bb => libxcrypt-compat_4.4.15.bb} (100%) rename meta/recipes-core/libxcrypt/{libxcrypt_4.4.14.bb => libxcrypt_4.4.15.bb} (100%) diff --git a/meta/recipes-core/libxcrypt/libxcrypt-compat_4.4.14.bb b/meta/recipes-core/libxcrypt/libxcrypt-compat_4.4.15.bb similarity index 100% rename from meta/recipes-core/libxcrypt/libxcrypt-compat_4.4.14.bb rename to meta/recipes-core/libxcrypt/libxcrypt-compat_4.4.15.bb diff --git a/meta/recipes-core/libxcrypt/libxcrypt.inc b/meta/recipes-core/libxcrypt/libxcrypt.inc index e59a096573..bee1367c99 100644 --- a/meta/recipes-core/libxcrypt/libxcrypt.inc +++ b/meta/recipes-core/libxcrypt/libxcrypt.inc @@ -10,7 +10,7 @@ LIC_FILES_CHKSUM ?= "file://LICENSING;md5=3bb6614cf5880cbf1b9dbd9e3d145e2c \ inherit autotools pkgconfig SRC_URI = "git://github.com/besser82/libxcrypt.git;branch=${SRCBRANCH}" -SRCREV = "5c43f7d56a31667bcdaa334bbb4edafb75672872" +SRCREV = "823437d015cd4ab4d100ed205f218681b03ae45c" SRCBRANCH ?= "develop" PROVIDES = "virtual/crypt" diff --git a/meta/recipes-core/libxcrypt/libxcrypt_4.4.14.bb b/meta/recipes-core/libxcrypt/libxcrypt_4.4.15.bb similarity index 100% rename from meta/recipes-core/libxcrypt/libxcrypt_4.4.14.bb rename to meta/recipes-core/libxcrypt/libxcrypt_4.4.15.bb -- 2.17.1 From wangmy at cn.fujitsu.com Thu Mar 19 07:41:47 2020 From: wangmy at cn.fujitsu.com (Wang Mingyu) Date: Thu, 19 Mar 2020 00:41:47 -0700 Subject: [OE-core] [PATCH] mc: upgrade 4.8.23 -> 4.8.24 In-Reply-To: <1584603707-43423-1-git-send-email-wangmy@cn.fujitsu.com> References: <1584603707-43423-1-git-send-email-wangmy@cn.fujitsu.com> Message-ID: <1584603707-43423-6-git-send-email-wangmy@cn.fujitsu.com> 0001-Add-option-to-control-configure-args.patch 0001-Ticket-3629-configure.ac-drop-bundled-gettext.patch removed since they are included in 4.8.24 Signed-off-by: Wang Mingyu --- ...Add-option-to-control-configure-args.patch | 99 ---------------- ...29-configure.ac-drop-bundled-gettext.patch | 110 ------------------ .../mc/{mc_4.8.23.bb => mc_4.8.24.bb} | 6 +- 3 files changed, 2 insertions(+), 213 deletions(-) delete mode 100644 meta/recipes-extended/mc/files/0001-Add-option-to-control-configure-args.patch delete mode 100644 meta/recipes-extended/mc/files/0001-Ticket-3629-configure.ac-drop-bundled-gettext.patch rename meta/recipes-extended/mc/{mc_4.8.23.bb => mc_4.8.24.bb} (88%) diff --git a/meta/recipes-extended/mc/files/0001-Add-option-to-control-configure-args.patch b/meta/recipes-extended/mc/files/0001-Add-option-to-control-configure-args.patch deleted file mode 100644 index e76aac8161..0000000000 --- a/meta/recipes-extended/mc/files/0001-Add-option-to-control-configure-args.patch +++ /dev/null @@ -1,99 +0,0 @@ -From a54501d3c9541bc8600225aa2d42531f93c6def7 Mon Sep 17 00:00:00 2001 -From: Joshua Watt -Date: Sat, 9 Nov 2019 20:01:48 -0600 -Subject: [PATCH] Add option to control configure args - -Embedding the configure time options into the executable can lead to -non-reproducible builds, since configure options often have embedded -paths. Add a configure time option to control if the configure args are -embedded so this can be disabled. - -Upstream-Status: Submitted [https://midnight-commander.org/ticket/4031] -Signed-off-by: Joshua Watt ---- - configure.ac | 6 ++++++ - src/args.c | 6 ++++++ - src/textconf.c | 2 ++ - 3 files changed, 14 insertions(+) - -diff --git a/configure.ac b/configure.ac -index 19d1a76be..a1948f6b9 100644 ---- a/configure.ac -+++ b/configure.ac -@@ -544,6 +544,12 @@ dnl Clarify do we really need GModule - AM_CONDITIONAL([HAVE_GMODULE], [test -n "$g_module_supported" && \ - test x"$textmode_x11_support" = x"yes" -o x"$enable_aspell" = x"yes"]) - -+AC_ARG_ENABLE([configure-args], -+ AS_HELP_STRING([--enable-configure-args], [Handle all compiler warnings as errors])) -+if test "x$enable_configure_args" != xno; then -+ AC_DEFINE([ENABLE_CONFIGURE_ARGS], 1, [Define to enable showing configure arguments in help]) -+fi -+ - AC_DEFINE_UNQUOTED([MC_CONFIGURE_ARGS], ["$ac_configure_args"], [MC configure arguments]) - - AC_CONFIG_FILES( -diff --git a/src/args.c b/src/args.c -index baef1a1c8..f8dc24020 100644 ---- a/src/args.c -+++ b/src/args.c -@@ -95,7 +95,9 @@ static gboolean mc_args__nouse_subshell = FALSE; - #endif /* ENABLE_SUBSHELL */ - static gboolean mc_args__show_datadirs = FALSE; - static gboolean mc_args__show_datadirs_extended = FALSE; -+#ifdef ENABLE_CONFIGURE_ARGS - static gboolean mc_args__show_configure_opts = FALSE; -+#endif - - static GOptionGroup *main_group; - -@@ -125,6 +127,7 @@ static const GOptionEntry argument_main_table[] = { - NULL - }, - -+#ifdef ENABLE_CONFIGURE_ARGS - /* show configure options */ - { - "configure-options", '\0', G_OPTION_FLAG_IN_MAIN, G_OPTION_ARG_NONE, -@@ -132,6 +135,7 @@ static const GOptionEntry argument_main_table[] = { - N_("Print configure options"), - NULL - }, -+#endif - - { - "printwd", 'P', G_OPTION_FLAG_IN_MAIN, G_OPTION_ARG_STRING, -@@ -758,11 +762,13 @@ mc_args_show_info (void) - return FALSE; - } - -+#ifdef ENABLE_CONFIGURE_ARGS - if (mc_args__show_configure_opts) - { - show_configure_options (); - return FALSE; - } -+#endif - - return TRUE; - } -diff --git a/src/textconf.c b/src/textconf.c -index 1e0613e58..f39b9e028 100644 ---- a/src/textconf.c -+++ b/src/textconf.c -@@ -232,10 +232,12 @@ show_datadirs_extended (void) - - /* --------------------------------------------------------------------------------------------- */ - -+#ifdef ENABLE_CONFIGURE_ARGS - void - show_configure_options (void) - { - (void) printf ("%s\n", MC_CONFIGURE_ARGS); - } -+#endif - - /* --------------------------------------------------------------------------------------------- */ --- -2.23.0 - diff --git a/meta/recipes-extended/mc/files/0001-Ticket-3629-configure.ac-drop-bundled-gettext.patch b/meta/recipes-extended/mc/files/0001-Ticket-3629-configure.ac-drop-bundled-gettext.patch deleted file mode 100644 index 8f357378d0..0000000000 --- a/meta/recipes-extended/mc/files/0001-Ticket-3629-configure.ac-drop-bundled-gettext.patch +++ /dev/null @@ -1,110 +0,0 @@ -From 0d677a014a87b968d79eea2353ac4e342b0fd4ca Mon Sep 17 00:00:00 2001 -From: Sergei Trofimovich -Date: Wed, 11 Sep 2019 22:58:18 +0100 -Subject: [PATCH] Ticket #3629: configure.ac: drop bundled gettext - -Bundled libintl did not support linking to internal static -libraries (libmc in our case): directly specified static -libraries are not pulled by libtool and are not usable for -dynamic libraries as PIC-related flags are not passed for -compilation. - -This renders bundled libintl library unusable. - -The change drops libintl bundling support and always relies -on external libintl (or falls back to disabled NLS). - -On a related note gettext-0.20 drops support for bundling -or libintl and this change will ease migration to newer version. - -The change is tested on x86_64-gentoo-linux-musl: mc builds -and links all tests successfully. A few tests fail for lack -of NLS support. - -Upstream-Status: Backport [https://github.com/MidnightCommander/mc/commit/f30e6ff283f4bc86177e4360de94dad794678395] -Signed-off-by: Sergei Trofimovich -Signed-off-by: Andrew Borodin -Signed-off-by: Alexander Kanavin ---- - Makefile.am | 2 +- - configure.ac | 5 +++-- - doc/doxygen.cfg | 2 +- - lib/Makefile.am | 2 +- - m4.include/mc-i18n.m4 | 5 ----- - 5 files changed, 6 insertions(+), 10 deletions(-) - -diff --git a/Makefile.am b/Makefile.am -index ac05a83..f86f6ed 100644 ---- a/Makefile.am -+++ b/Makefile.am -@@ -1,7 +1,7 @@ - ## Process this file with automake to create Makefile.in. - AUTOMAKE_OPTIONS = 1.5 - --SUBDIRS = intl po lib src doc contrib misc -+SUBDIRS = po lib src doc contrib misc - - if HAVE_TESTS - SUBDIRS += tests -diff --git a/configure.ac b/configure.ac -index a1948f6..bbc9e71 100644 ---- a/configure.ac -+++ b/configure.ac -@@ -272,7 +272,9 @@ dnl ############################################################################ - dnl Internationalization - dnl ############################################################################ - --AM_GNU_GETTEXT([no-libtool], [need-ngettext]) -+AC_CHECK_FUNCS([setlocale]) -+ -+AM_GNU_GETTEXT([external], [need-ngettext]) - AM_GNU_GETTEXT_VERSION([0.18.1]) - - mc_I18N -@@ -680,7 +682,6 @@ doc/hlp/pl/Makefile - doc/hlp/ru/Makefile - doc/hlp/sr/Makefile - --intl/Makefile - po/Makefile.in - ]) - -diff --git a/doc/doxygen.cfg b/doc/doxygen.cfg -index 07bc973..1118062 100644 ---- a/doc/doxygen.cfg -+++ b/doc/doxygen.cfg -@@ -91,7 +91,7 @@ FILE_PATTERNS = *.c \ - RECURSIVE = YES - EXCLUDE = - EXCLUDE_SYMLINKS = NO --EXCLUDE_PATTERNS = */intl/* */tests/* */.git/* -+EXCLUDE_PATTERNS = */tests/* */.git/* - EXCLUDE_SYMBOLS = - EXAMPLE_PATH = $(SRCDIR) - EXAMPLE_PATTERNS = -diff --git a/lib/Makefile.am b/lib/Makefile.am -index c448e2d..455f9dd 100644 ---- a/lib/Makefile.am -+++ b/lib/Makefile.am -@@ -74,4 +74,4 @@ else - libmc_la_LIBADD += $(GLIB_LIBS) - endif - --libmc_la_LIBADD += $(PCRE_LIBS) $(LIBICONV) $(LIBINTL) -+libmc_la_LIBADD += $(PCRE_LIBS) -diff --git a/m4.include/mc-i18n.m4 b/m4.include/mc-i18n.m4 -index dd10d00..ec08324 100644 ---- a/m4.include/mc-i18n.m4 -+++ b/m4.include/mc-i18n.m4 -@@ -8,11 +8,6 @@ dnl @license GPL - dnl @copyright Free Software Foundation, Inc. - - AC_DEFUN([mc_I18N],[ -- -- if test "x$USE_INCLUDED_LIBINTL" = xyes; then -- CPPFLAGS="$CPPFLAGS -I\$(top_builddir)/intl -I\$(top_srcdir)/intl" -- fi -- - dnl User visible support for charset conversion. - AC_ARG_ENABLE([charset], - AS_HELP_STRING([--enable-charset], [Support for charset selection and conversion @<:@yes@:>@])) diff --git a/meta/recipes-extended/mc/mc_4.8.23.bb b/meta/recipes-extended/mc/mc_4.8.24.bb similarity index 88% rename from meta/recipes-extended/mc/mc_4.8.23.bb rename to meta/recipes-extended/mc/mc_4.8.24.bb index ead348b92e..7a68270dd2 100644 --- a/meta/recipes-extended/mc/mc_4.8.23.bb +++ b/meta/recipes-extended/mc/mc_4.8.24.bb @@ -9,12 +9,10 @@ RRECOMMENDS_${PN} = "ncurses-terminfo" SRC_URI = "http://www.midnight-commander.org/downloads/${BPN}-${PV}.tar.bz2 \ file://0001-mc-replace-perl-w-with-use-warnings.patch \ - file://0001-Add-option-to-control-configure-args.patch \ - file://0001-Ticket-3629-configure.ac-drop-bundled-gettext.patch \ file://nomandate.patch \ " -SRC_URI[md5sum] = "152927ac29cf0e61d7d019f261bb7d89" -SRC_URI[sha256sum] = "238c4552545dcf3065359bd50753abbb150c1b22ec5a36eaa02c82808293267d" +SRC_URI[md5sum] = "2621de1fa9058a9c41a4248becc969f9" +SRC_URI[sha256sum] = "cfcc4d0546d0c3a88645a8bf71612ed36647ea3264d973b1f28183a0c84bae34" inherit autotools gettext pkgconfig -- 2.17.1 From alex.kanavin at gmail.com Thu Mar 19 07:54:10 2020 From: alex.kanavin at gmail.com (Alexander Kanavin) Date: Thu, 19 Mar 2020 08:54:10 +0100 Subject: [OE-core] [PATCH 1/2] piglit: move to meta-oe In-Reply-To: <5839fa696c78f06c668fe8cb8dbd0a80732c7bbd.camel@linuxfoundation.org> References: <20200229101433.30787-1-alex.kanavin@gmail.com> <23132fd4872488b259751cdf8bcd8335d703b205.camel@linuxfoundation.org> <5839fa696c78f06c668fe8cb8dbd0a80732c7bbd.camel@linuxfoundation.org> Message-ID: On Wed, 18 Mar 2020 at 22:31, Richard Purdie < richard.purdie at linuxfoundation.org> wrote: > > I found an old ticket where piglit was proposed for the core image > > testing, and the idea was rejected due to its huge install size, so I > > won't be pursuing this further. > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=10047 > > > > Would you still say it's worth to keep the recipe in core? Python- > > numpy (that piglit and only piglit needs) isn't trivial to maintain > > either (for instance, update to latest version needs cython to be > > added to core). > > That bug is for piglit as a default in testapps. We decided that was a > bad idea, not that testing with piglit was a bad idea overall. > So adding piglit to perhaps core-image-sato-ptest would be okay? (with the resulting increase in size and do_rootfs times) Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From anuj.mittal at intel.com Thu Mar 19 08:36:21 2020 From: anuj.mittal at intel.com (Anuj Mittal) Date: Thu, 19 Mar 2020 16:36:21 +0800 Subject: [OE-core] [PATCH][zeus 0/7] zeus pull request - cover letter only Message-ID: Please pull these changes for zeus. Clean a-full on autobuilder. Thanks, Anuj The following changes since commit d8cfc309f9dd0dc8904ab18e5898770502ee2540: cve-check: fix ValueError (2020-03-15 13:33:19 -0700) are available in the Git repository at: git://push.openembedded.org/openembedded-core-contrib stable/zeus-next Adrian Bunk (1): python3: Upgrade 3.7.6 -> 3.7.7 Anuj Mittal (1): bluez: fix CVE-2020-0556 Lee Chee Yang (2): qemu: fix CVE-2019-20382 libpcre2: fix CVE-2019-20454 Ross Burton (1): sqlite: fix numerous CVEs Stefan Ghinea (1): aspell: CVE-2019-20433 Wenlin Kang (1): libarchive: Fix CVE-2020-9308 meta/recipes-connectivity/bluez5/bluez5.inc | 2 + .../bluez5/bluez5/CVE-2020-0556-1.patch | 35 + .../bluez5/bluez5/CVE-2020-0556-2.patch | 143 +++ .../{python3_3.7.6.bb => python3_3.7.7.bb} | 6 +- meta/recipes-devtools/qemu/qemu.inc | 1 + .../qemu/qemu/CVE-2019-20382.patch | 1018 +++++++++++++++++ ...ct-files-that-declare-invalid-header.patch | 124 ++ .../libarchive/libarchive_3.4.0.bb | 1 + .../aspell/aspell/CVE-2019-20433-0001.patch | 999 ++++++++++++++++ .../aspell/aspell/CVE-2019-20433-0002.patch | 68 ++ meta/recipes-support/aspell/aspell_0.60.7.bb | 2 + .../libpcre/libpcre2/CVE-2019-20454.patch | 19 + .../recipes-support/libpcre/libpcre2_10.33.bb | 1 + .../sqlite/sqlite3/CVE-2019-19244.patch | 33 + .../sqlite/sqlite3/CVE-2019-19923.patch | 50 + .../sqlite/sqlite3/CVE-2019-19924.patch | 65 ++ .../sqlite/sqlite3/CVE-2019-19925.patch | 33 + .../sqlite/sqlite3/CVE-2019-19926.patch | 31 + .../sqlite/sqlite3/CVE-2019-19959.patch | 46 + .../sqlite/sqlite3/CVE-2019-20218.patch | 31 + meta/recipes-support/sqlite/sqlite3_3.29.0.bb | 10 +- 21 files changed, 2714 insertions(+), 4 deletions(-) create mode 100644 meta/recipes-connectivity/bluez5/bluez5/CVE-2020-0556-1.patch create mode 100644 meta/recipes-connectivity/bluez5/bluez5/CVE-2020-0556-2.patch rename meta/recipes-devtools/python/{python3_3.7.6.bb => python3_3.7.7.bb} (98%) create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2019-20382.patch create mode 100644 meta/recipes-extended/libarchive/libarchive/0001-RAR5-reader-reject-files-that-declare-invalid-header.patch create mode 100644 meta/recipes-support/aspell/aspell/CVE-2019-20433-0001.patch create mode 100644 meta/recipes-support/aspell/aspell/CVE-2019-20433-0002.patch create mode 100644 meta/recipes-support/libpcre/libpcre2/CVE-2019-20454.patch create mode 100644 meta/recipes-support/sqlite/sqlite3/CVE-2019-19244.patch create mode 100644 meta/recipes-support/sqlite/sqlite3/CVE-2019-19923.patch create mode 100644 meta/recipes-support/sqlite/sqlite3/CVE-2019-19924.patch create mode 100644 meta/recipes-support/sqlite/sqlite3/CVE-2019-19925.patch create mode 100644 meta/recipes-support/sqlite/sqlite3/CVE-2019-19926.patch create mode 100644 meta/recipes-support/sqlite/sqlite3/CVE-2019-19959.patch create mode 100644 meta/recipes-support/sqlite/sqlite3/CVE-2019-20218.patch -- 2.25.1 From bunk at stusta.de Thu Mar 19 11:37:36 2020 From: bunk at stusta.de (Adrian Bunk) Date: Thu, 19 Mar 2020 13:37:36 +0200 Subject: [OE-core] [PATCH] classes/populate_sdk_base: Implement xz compression options In-Reply-To: <20200318122156.23599-1-mike.looijmans@topic.nl> References: <20200318122156.23599-1-mike.looijmans@topic.nl> Message-ID: <20200319113736.GA28081@localhost> On Wed, Mar 18, 2020 at 01:21:56PM +0100, Mike Looijmans wrote: > Building an SDK on a machine with 8GB RAM resulted in excessive swapping > due to the xz compressor using ~20GB of memory. This is because xz is > being called with "-T 0 -9". > > To allow tuning the compression versus memory usage, introduce a variable > named SDK_XZ_OPTIONS that defaults to a more sane default: > SDK_XZ_OPTIONS ?= "${XZ_DEFAULTS} ${XZ_COMPRESSION_LEVEL}" > Thus, inherit any XZ tuning already done, and allow users to specify > overrides for this task in their config by supplying SDK_XZ_OPTIONS. > Since XZ_COMPRESSION_LEVEL defaults to -9 this does not change the standard > behavior. >... > +SDK_XZ_OPTIONS ?= "${XZ_DEFAULTS} ${XZ_COMPRESSION_LEVEL}" A problem is that XZ_COMPRESSION_LEVEL compression would now be used for unrelated usecases, and lowering the compression for being able to boot on low-end targets (<= 64 MB RAM) shouldn't impact the SDK. >... > - d.setVar('SDK_ARCHIVE_CMD', 'cd ${SDK_OUTPUT}/${SDKPATH}; tar ${SDKTAROPTS} -cf - . | xz -T 0 -9 > ${SDKDEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.${SDK_ARCHIVE_TYPE}') > + d.setVar('SDK_ARCHIVE_CMD', 'cd ${SDK_OUTPUT}/${SDKPATH}; tar ${SDKTAROPTS} -cf - . | xz ${SDK_XZ_OPTIONS} > ${SDKDEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.${SDK_ARCHIVE_TYPE}') >... Replacing "-T 0" with ${XZ_DEFAULTS} should solve your problem. This already takes both cpus and memory into account. cu Adrian From richard.purdie at linuxfoundation.org Thu Mar 19 14:10:52 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Thu, 19 Mar 2020 14:10:52 +0000 Subject: [OE-core] [PATCH] mc: upgrade 4.8.23 -> 4.8.24 In-Reply-To: <1584603707-43423-6-git-send-email-wangmy@cn.fujitsu.com> References: <1584603707-43423-1-git-send-email-wangmy@cn.fujitsu.com> <1584603707-43423-6-git-send-email-wangmy@cn.fujitsu.com> Message-ID: On Thu, 2020-03-19 at 00:41 -0700, Wang Mingyu wrote: > 0001-Add-option-to-control-configure-args.patch > 0001-Ticket-3629-configure.ac-drop-bundled-gettext.patch > removed since they are included in 4.8.24 > > Signed-off-by: Wang Mingyu > --- > ...Add-option-to-control-configure-args.patch | 99 ---------------- > ...29-configure.ac-drop-bundled-gettext.patch | 110 ---------------- > -- Fails in do_install: https://autobuilder.yoctoproject.org/typhoon/#/builders/23/builds/1945 https://autobuilder.yoctoproject.org/typhoon/#/builders/101/builds/609 How was this tested? Cheers, Richard From brgl at bgdev.pl Thu Mar 19 16:44:01 2020 From: brgl at bgdev.pl (Bartosz Golaszewski) Date: Thu, 19 Mar 2020 17:44:01 +0100 Subject: [OE-core] [RFC PATCH 0/2] image.bbclass: support two-stage deployment of image artifacts Message-ID: <20200319164403.29605-1-brgl@bgdev.pl> From: Bartosz Golaszewski This is a follow-up to the discussion I started on the OE-core mailing list a couple days ago[1]. These patches propose to split the deployment of image artifacts into two stages where the first one includes all "regular" images and takes place before do_image_complete and the second is mostly aimed at wic right now and happens after do_image_complete. These patches work but I'm sending them as RFC mostly to continue the discussion about possible solutions for the circular dependencies between the rootfs and initramfs. [1] http://lists.openembedded.org/pipermail/openembedded-core/2020-March/294094.html Bartosz Golaszewski (2): image.bbclass: add an intermediate deploy task image.bbclass: deploy artifacts in two stages meta/classes/image.bbclass | 54 ++++++++++++++----- meta/classes/image_types.bbclass | 3 ++ meta/classes/image_types_wic.bbclass | 4 +- .../images/build-appliance-image_15.0.0.bb | 2 +- 4 files changed, 47 insertions(+), 16 deletions(-) -- 2.19.1 From brgl at bgdev.pl Thu Mar 19 16:44:02 2020 From: brgl at bgdev.pl (Bartosz Golaszewski) Date: Thu, 19 Mar 2020 17:44:02 +0100 Subject: [OE-core] [RFC PATCH 1/2] image.bbclass: add an intermediate deploy task In-Reply-To: <20200319164403.29605-1-brgl@bgdev.pl> References: <20200319164403.29605-1-brgl@bgdev.pl> Message-ID: <20200319164403.29605-2-brgl@bgdev.pl> From: Bartosz Golaszewski Instead of using do_image_complete for both the deployment of image artifacts into DEPLOY_DIR_IMAGE as well as calling the image post-process commands, split the responsability between two separate tasks: do_image_deploy will take care of the sstate deployment, while do_image_complete will only do the post-processing. This way we can make the dependencies more fine-grained. Signed-off-by: Bartosz Golaszewski --- meta/classes/image.bbclass | 23 +++++++++++++++-------- 1 file changed, 15 insertions(+), 8 deletions(-) diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass index 07aa1f1fa5..6e2b864f73 100644 --- a/meta/classes/image.bbclass +++ b/meta/classes/image.bbclass @@ -144,7 +144,7 @@ python () { deps += " %s:%s" % (dep, task) return deps - d.appendVarFlag('do_image_complete', 'depends', extraimage_getdepends('do_populate_sysroot')) + d.appendVarFlag('do_image_deploy', 'depends', extraimage_getdepends('do_populate_sysroot')) deps = " " + imagetypes_getdepends(d) d.appendVarFlag('do_rootfs', 'depends', deps) @@ -264,6 +264,17 @@ do_image[dirs] = "${TOPDIR}" do_image[umask] = "022" addtask do_image after do_rootfs +do_image_deploy() { + # This is a placeholder really but it still needs to run for sstate + # to correctly deploy the image artifacts. + true +} +SSTATETASKS += "do_image_deploy" +do_image_deploy[sstate-inputdirs] = "${IMGDEPLOYDIR}" +do_image_deploy[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}" +SSTATE_SKIP_CREATION_task-image-deploy = '1' +addtask do_image_deploy after do_image before do_build + fakeroot python do_image_complete () { from oe.utils import execute_pre_post_process @@ -273,12 +284,8 @@ fakeroot python do_image_complete () { } do_image_complete[dirs] = "${TOPDIR}" do_image_complete[umask] = "022" -SSTATETASKS += "do_image_complete" -SSTATE_SKIP_CREATION_task-image-complete = '1' -do_image_complete[sstate-inputdirs] = "${IMGDEPLOYDIR}" -do_image_complete[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}" do_image_complete[stamp-extra-info] = "${MACHINE_ARCH}" -addtask do_image_complete after do_image before do_build +addtask do_image_complete after do_image_deploy before do_build python do_image_complete_setscene () { sstate_setscene(d) } @@ -500,8 +507,8 @@ python () { d.appendVarFlag(task, 'vardeps', ' ' + ' '.join(vardeps)) d.appendVarFlag(task, 'vardepsexclude', ' DATETIME DATE ' + ' '.join(vardepsexclude)) - bb.debug(2, "Adding task %s before %s, after %s" % (task, 'do_image_complete', after)) - bb.build.addtask(task, 'do_image_complete', after, d) + bb.debug(2, "Adding task %s before do_image_deploy, after %s" % (task, after)) + bb.build.addtask(task, 'do_image_deploy', after, d) } # -- 2.19.1 From brgl at bgdev.pl Thu Mar 19 16:44:03 2020 From: brgl at bgdev.pl (Bartosz Golaszewski) Date: Thu, 19 Mar 2020 17:44:03 +0100 Subject: [OE-core] [RFC PATCH 2/2] image.bbclass: deploy artifacts in two stages In-Reply-To: <20200319164403.29605-1-brgl@bgdev.pl> References: <20200319164403.29605-1-brgl@bgdev.pl> Message-ID: <20200319164403.29605-3-brgl@bgdev.pl> From: Bartosz Golaszewski Currently the artifacts for all image types are deployed to the shared space at the same time by the do_image_deploy task. This however creates a problem with circular dependencies if we want to use certain security features[1]. Because wic is designed to fetch artifacts generated by other recipes as well as other images generated by the same recipe it's useful to delay its creation and deployment until after do_image_complete. This patch adds a new variable: IMAGE_TYPES_DEPLOY_LATE which contains a list of image types for which the associated IMAGE_CMD tasks should be called after do_image_complete. The deployment is now done in two stages: before do_image_complete for all regular types and after for types listed in the new variable. This will allow us to fine tune the dependencies in order to implement dm-verity support where initramfs on which the main image depends needs to access the partition image before we create the wic image. [1] http://lists.openembedded.org/pipermail/openembedded-core/2020-March/294094.html Signed-off-by: Bartosz Golaszewski --- meta/classes/image.bbclass | 39 ++++++++++++++----- meta/classes/image_types.bbclass | 3 ++ meta/classes/image_types_wic.bbclass | 4 +- .../images/build-appliance-image_15.0.0.bb | 2 +- 4 files changed, 36 insertions(+), 12 deletions(-) diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass index 6e2b864f73..7d0dd6ee50 100644 --- a/meta/classes/image.bbclass +++ b/meta/classes/image.bbclass @@ -83,6 +83,7 @@ export PACKAGE_INSTALL ?= "${IMAGE_INSTALL} ${ROOTFS_BOOTSTRAP_INSTALL} ${FEATUR PACKAGE_INSTALL_ATTEMPTONLY ?= "${FEATURE_INSTALL_OPTIONAL}" IMGDEPLOYDIR = "${WORKDIR}/deploy-${PN}-image-complete" +LATEIMGDEPLOYDIR = "${WORKDIR}/deploy-${PN}-image-complete-late" # Images are generally built explicitly, do not need to be part of world. EXCLUDE_FROM_WORLD = "1" @@ -127,7 +128,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', 'IMAGE_LINGUAS_COMPLEMENTARY', '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', 'IMAGE_INSTALL_DEBUGFS'] + 'CONVERSIONTYPES', 'IMAGE_GEN_DEBUGFS', 'ROOTFS_RO_UNNEEDED', 'IMGDEPLOYDIR', 'LATEIMGDEPLOYDIR', 'PACKAGE_EXCLUDE_COMPLEMENTARY', 'REPRODUCIBLE_TIMESTAMP_ROOTFS', 'IMAGE_INSTALL_DEBUGFS'] variables.extend(rootfs_command_variables(d)) variables.extend(variable_depends(d)) return " ".join(variables) @@ -247,7 +248,7 @@ fakeroot python do_rootfs () { progress_reporter.finish() } do_rootfs[dirs] = "${TOPDIR}" -do_rootfs[cleandirs] += "${S} ${IMGDEPLOYDIR}" +do_rootfs[cleandirs] += "${S} ${IMGDEPLOYDIR} ${LATEIMGDEPLOYDIR}" do_rootfs[umask] = "022" do_rootfs[file-checksums] += "${POSTINST_INTERCEPT_CHECKSUMS}" addtask rootfs after do_prepare_recipe_sysroot @@ -273,7 +274,21 @@ SSTATETASKS += "do_image_deploy" do_image_deploy[sstate-inputdirs] = "${IMGDEPLOYDIR}" do_image_deploy[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}" SSTATE_SKIP_CREATION_task-image-deploy = '1' -addtask do_image_deploy after do_image before do_build +addtask do_image_deploy after do_image before do_image_complete + +do_image_deploy_late() { + # Avoid using SSTATE_DUPWHITELIST - check which images have already been + # deployed and copy those that haven't into a separate pre-deploy directory + # which will serve as the sstate input directory for this task. + for file in $(ls ${IMGDEPLOYDIR}) ; do + test -e ${DEPLOY_DIR_IMAGE}/$file || cp -a ${IMGDEPLOYDIR}/$file ${LATEIMGDEPLOYDIR}/$file + done +} +SSTATETASKS += "do_image_deploy_late" +do_image_deploy_late[sstate-inputdirs] = "${LATEIMGDEPLOYDIR}" +do_image_deploy_late[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}" +SSTATE_SKIP_CREATION_task-image-deploy-late = '1' +addtask do_image_deploy_late after do_image_complete before do_build fakeroot python do_image_complete () { from oe.utils import execute_pre_post_process @@ -285,7 +300,7 @@ fakeroot python do_image_complete () { do_image_complete[dirs] = "${TOPDIR}" do_image_complete[umask] = "022" do_image_complete[stamp-extra-info] = "${MACHINE_ARCH}" -addtask do_image_complete after do_image_deploy before do_build +addtask do_image_complete after do_image_deploy before do_image_deploy_late python do_image_complete_setscene () { sstate_setscene(d) } @@ -412,6 +427,7 @@ python () { maskedtypes = (d.getVar('IMAGE_TYPES_MASKED') or "").split() maskedtypes = [dbg + t for t in maskedtypes for dbg in ("", "debugfs_")] + latetypes = d.getVar('IMAGE_TYPES_DEPLOY_LATE').split() for t in basetypes: vardeps = set() @@ -491,9 +507,14 @@ python () { for image in sorted(rm_tmp_images): cmds.append("\trm " + image) - after = 'do_image' - for dep in typedeps[t]: - after += ' do_image_%s' % dep.replace("-", "_").replace(".", "_") + if t in latetypes: + before = 'do_image_deploy_late' + after = 'do_image_complete' + else: + before = 'do_image_deploy' + after = 'do_image' + for dep in typedeps[t]: + after += ' do_image_%s' % dep.replace("-", "_").replace(".", "_") task = "do_image_%s" % t.replace("-", "_").replace(".", "_") @@ -507,8 +528,8 @@ python () { d.appendVarFlag(task, 'vardeps', ' ' + ' '.join(vardeps)) d.appendVarFlag(task, 'vardepsexclude', ' DATETIME DATE ' + ' '.join(vardepsexclude)) - bb.debug(2, "Adding task %s before do_image_deploy, after %s" % (task, after)) - bb.build.addtask(task, 'do_image_deploy', after, d) + bb.debug(2, "Adding task %s before %s, after %s" % (task, before, after)) + bb.build.addtask(task, before, after, d) } # diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass index f82f1d8862..665bd7c4b3 100644 --- a/meta/classes/image_types.bbclass +++ b/meta/classes/image_types.bbclass @@ -331,5 +331,8 @@ DEPLOYABLE_IMAGE_TYPES ?= "hddimg iso" # images that will not be built at do_rootfs time: vmdk, vdi, qcow2, hddimg, iso, etc. IMAGE_TYPES_MASKED ?= "" +# Image types that should be generated and deployed after do_image_complete task. +IMAGE_TYPES_DEPLOY_LATE ?= "wic" + # bmap requires python3 to be in the PATH EXTRANATIVEPATH += "${@'python3-native' if d.getVar('IMAGE_FSTYPES').find('.bmap') else ''}" diff --git a/meta/classes/image_types_wic.bbclass b/meta/classes/image_types_wic.bbclass index b83308b45c..80039ed19c 100644 --- a/meta/classes/image_types_wic.bbclass +++ b/meta/classes/image_types_wic.bbclass @@ -113,7 +113,7 @@ python () { # a variable and let the metadata deal with the deps. d.setVar('_WKS_TEMPLATE', body) bb.build.addtask('do_write_wks_template', 'do_image_wic', 'do_image', d) - bb.build.addtask('do_image_wic', 'do_image_complete', None, d) + bb.build.addtask('do_image_wic', None, 'do_image_complete', d) } # @@ -139,6 +139,6 @@ python do_rootfs_wicenv () { depdir = d.getVar('IMGDEPLOYDIR') bb.utils.copyfile(os.path.join(outdir, basename) + '.env', os.path.join(depdir, basename) + '.env') } -addtask do_rootfs_wicenv after do_image before do_image_wic +addtask do_rootfs_wicenv after do_image_complete before do_image_wic do_rootfs_wicenv[vardeps] += "${WICVARS}" do_rootfs_wicenv[prefuncs] = 'set_image_size' diff --git a/meta/recipes-core/images/build-appliance-image_15.0.0.bb b/meta/recipes-core/images/build-appliance-image_15.0.0.bb index 8c9fe92485..5ec66ebd76 100644 --- a/meta/recipes-core/images/build-appliance-image_15.0.0.bb +++ b/meta/recipes-core/images/build-appliance-image_15.0.0.bb @@ -138,4 +138,4 @@ python do_bundle_files() { bb.build.exec_func('create_bundle_files', d) } -addtask bundle_files after do_image_wic before do_image_complete +addtask bundle_files after do_image_wic -- 2.19.1 From mhalstead at linuxfoundation.org Thu Mar 19 16:44:43 2020 From: mhalstead at linuxfoundation.org (Michael Halstead) Date: Thu, 19 Mar 2020 09:44:43 -0700 Subject: [OE-core] Mailing list platform change March 20th In-Reply-To: References: Message-ID: Everything is proceeding smoothly and this work will continue as planned. The migration starts at noon PDT tomorrow. List owners please take care of all outstanding moderation in the next 24 hours to ensure a smooth transition. Thank you, -- Michael Halstead Linux Foundation / Yocto Project Systems Operations Engineer On Fri, Mar 13, 2020 at 4:58 PM Michael Halstead < mhalstead at linuxfoundation.org> wrote: > We are moving our lists from Mailman to Groups.io. E-mail to lists will > be delayed during the move window. We are aiming to complete the migration > during business hours in the Pacific time zone. > > A new account will be created for you on the Groups.io platform if you > don't already have one. > > You can read more about the change on the wiki: > https://www.openembedded.org/wiki/GroupsMigration > > If there are serious issues we will rollback the changes. We will e-mail > all lists when work is complete. > > -- > Michael Halstead > Linux Foundation / Yocto Project > Systems Operations Engineer > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brgl at bgdev.pl Thu Mar 19 16:49:50 2020 From: brgl at bgdev.pl (Bartosz Golaszewski) Date: Thu, 19 Mar 2020 17:49:50 +0100 Subject: [OE-core] [RFC PATCH 0/2] image.bbclass: support two-stage deployment of image artifacts In-Reply-To: <20200319164403.29605-1-brgl@bgdev.pl> References: <20200319164403.29605-1-brgl@bgdev.pl> Message-ID: czw., 19 mar 2020 o 17:44 Bartosz Golaszewski napisa?(a): > > From: Bartosz Golaszewski > > This is a follow-up to the discussion I started on the OE-core mailing > list a couple days ago[1]. These patches propose to split the deployment > of image artifacts into two stages where the first one includes all > "regular" images and takes place before do_image_complete and the second > is mostly aimed at wic right now and happens after do_image_complete. > > These patches work but I'm sending them as RFC mostly to continue the > discussion about possible solutions for the circular dependencies between > the rootfs and initramfs. > > [1] http://lists.openembedded.org/pipermail/openembedded-core/2020-March/294094.html > > Bartosz Golaszewski (2): > image.bbclass: add an intermediate deploy task > image.bbclass: deploy artifacts in two stages > > meta/classes/image.bbclass | 54 ++++++++++++++----- > meta/classes/image_types.bbclass | 3 ++ > meta/classes/image_types_wic.bbclass | 4 +- > .../images/build-appliance-image_15.0.0.bb | 2 +- > 4 files changed, 47 insertions(+), 16 deletions(-) > > -- > 2.19.1 > Just for clarity: this what the task order would look like for a standard beaglebone-yocto image with these patches: do_prepare_recipe_sysroot (32199): log.do_prepare_recipe_sysroot.32199 do_deploy_source_date_epoch (32201): log.do_deploy_source_date_epoch.32201 do_rootfs (32246): log.do_rootfs.32246 do_write_qemuboot_conf (8655): log.do_write_qemuboot_conf.8655 do_image_qa (8657): log.do_image_qa.8657 do_image (8661): log.do_image.8661 do_image_ext4 (35128): log.do_image_ext4.35128 do_image_tar (35133): log.do_image_tar.35133 do_image_jffs2 (35136): log.do_image_jffs2.35136 do_image_deploy (35246): log.do_image_deploy.35246 do_image_complete (35262): log.do_image_complete.35262 do_rootfs_wicenv (35264): log.do_rootfs_wicenv.35264 do_populate_lic_deploy (35267): log.do_populate_lic_deploy.35267 do_image_wic (35283): log.do_image_wic.35283 do_image_deploy_late (35448): log.do_image_deploy_late.35448 Bart From richard.purdie at linuxfoundation.org Thu Mar 19 17:12:57 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Thu, 19 Mar 2020 17:12:57 +0000 Subject: [OE-core] [RFC PATCH 0/2] image.bbclass: support two-stage deployment of image artifacts In-Reply-To: <20200319164403.29605-1-brgl@bgdev.pl> References: <20200319164403.29605-1-brgl@bgdev.pl> Message-ID: <21fcbda1e8b274ba75534159179ca9535c618d68.camel@linuxfoundation.org> On Thu, 2020-03-19 at 17:44 +0100, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > This is a follow-up to the discussion I started on the OE-core > mailing > list a couple days ago[1]. These patches propose to split the > deployment > of image artifacts into two stages where the first one includes all > "regular" images and takes place before do_image_complete and the > second > is mostly aimed at wic right now and happens after do_image_complete. > > These patches work but I'm sending them as RFC mostly to continue the > discussion about possible solutions for the circular dependencies > between > the rootfs and initramfs. > > [1] > http://lists.openembedded.org/pipermail/openembedded-core/2020-March/294094.html This works fine until we have some new image type which then has to depend on happening after wic. We then add a three stage process and so on. Basically this feels like we're hardcoding something for one specific use case which will later break and not scale to other problems/solutions. Sorry, I'm not convinced this is the right way to move forward. I will try and have a think about what the right way is but sadly I don't get much time to spend on specific problems like this :( Cheers, Richard From jpuhlman at mvista.com Thu Mar 19 18:20:48 2020 From: jpuhlman at mvista.com (Jeremy A. Puhlman) Date: Thu, 19 Mar 2020 11:20:48 -0700 Subject: [OE-core] [PATCH] toolchain-shar-extract: check for available python Message-ID: <20200319182048.28380-1-jpuhlman@mvista.com> From: Jeremy Puhlman centos7 doesn't have python3 intalled by default, so running the script errors in novel ways if it is not installed. Signed-off-by: Jeremy A. Puhlman --- meta/files/toolchain-shar-extract.sh | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/meta/files/toolchain-shar-extract.sh b/meta/files/toolchain-shar-extract.sh index 2e0fe94963..04527f891f 100644 --- a/meta/files/toolchain-shar-extract.sh +++ b/meta/files/toolchain-shar-extract.sh @@ -1,8 +1,13 @@ #!/bin/sh export LC_ALL=en_US.UTF-8 +#Make sure at least one python is installed +INIT_PYTHON=$(which python3 2>/dev/null ) +[ -z "$INIT_PYTHON" ] && INIT_PYTHON=$(which python2 2>/dev/null) +[ -z "$INIT_PYTHON" ] && echo "Error: The SDK needs a python installed" && exit 1 + # Remove invalid PATH elements first (maybe from a previously setup toolchain now deleted -PATH=`python3 -c 'import os; print(":".join(e for e in os.environ["PATH"].split(":") if os.path.exists(e)))'` +PATH=`$INIT_PYTHON -c 'import os; print(":".join(e for e in os.environ["PATH"].split(":") if os.path.exists(e)))'` tweakpath () { case ":${PATH}:" in -- 2.13.3 From brgl at bgdev.pl Thu Mar 19 18:20:54 2020 From: brgl at bgdev.pl (Bartosz Golaszewski) Date: Thu, 19 Mar 2020 19:20:54 +0100 Subject: [OE-core] [RFC PATCH 0/2] image.bbclass: support two-stage deployment of image artifacts In-Reply-To: <21fcbda1e8b274ba75534159179ca9535c618d68.camel@linuxfoundation.org> References: <20200319164403.29605-1-brgl@bgdev.pl> <21fcbda1e8b274ba75534159179ca9535c618d68.camel@linuxfoundation.org> Message-ID: czw., 19 mar 2020 o 18:13 Richard Purdie napisa?(a): > > On Thu, 2020-03-19 at 17:44 +0100, Bartosz Golaszewski wrote: > > From: Bartosz Golaszewski > > > > This is a follow-up to the discussion I started on the OE-core > > mailing > > list a couple days ago[1]. These patches propose to split the > > deployment > > of image artifacts into two stages where the first one includes all > > "regular" images and takes place before do_image_complete and the > > second > > is mostly aimed at wic right now and happens after do_image_complete. > > > > These patches work but I'm sending them as RFC mostly to continue the > > discussion about possible solutions for the circular dependencies > > between > > the rootfs and initramfs. > > > > [1] > > http://lists.openembedded.org/pipermail/openembedded-core/2020-March/294094.html > > This works fine until we have some new image type which then has to > depend on happening after wic. We then add a three stage process and so > on. Basically this feels like we're hardcoding something for one > specific use case which will later break and not scale to other > problems/solutions. > I understand you see it as controversial but let me try to convince you: If we'll really get to a point where we need to create a hierarchy of multiple levels of image deployment, then maybe we should switch to deploying each image right after it is created in its dedicated do_image_ task, then we could really fine-tune the inter-task dependencies. But we're not there yet and IMO currently it would be overkill. The rule of thumb for me is not to add new interfaces nobody asks for. The thing with wic is that it's aggregating other deployed images. What we're dealing with are *two* categories of image artifacts: let's call them simple and composed types. Obviously composed types may need to access the simple types and, due to the use-case I described in my previous thread, it's useful if we can depend on the tasks for simple and composed images separately. Maybe if I renamed the tasks: do_image_deploy_simple and do_image_deploy_composed it would look better than an ambiguous do_image_deploy_late. This also makes your argument about adding a third category purely theoretical: I don't see how we would need another category of images anytime soon. Even if we added another aggregating type (one could argue that hddimg qualifies as such) it could, with a 99% chance, run in parallel to wic and thus qualify as a deploy_late/composed image. > Sorry, I'm not convinced this is the right way to move forward. I will > try and have a think about what the right way is but sadly I don't get > much time to spend on specific problems like this :( > Please do - I'm open for other ideas. Just please keep in mind: there's obviously a problem with the current approach. I described it in detail and it turned out Quentin had encountered it too and dealt with it using a nasty workaround (fitImage deployed by the image recipe and not the kernel). I'd like to fix it upstream and proposed a solution that is IMO not horrible. I'd appreciate if we could reach a compromise that wouldn't leave us with downstream hacks. Please also note that sometimes "gets the job done" really is better than not solving problems. Just look at initcall levels in the linux kernel - they are similar to what I proposed here and serve as a surrogate for real dependencies. Best regards, Bartosz Golaszewski From tom.hochstein at nxp.com Thu Mar 19 18:34:24 2020 From: tom.hochstein at nxp.com (Tom Hochstein) Date: Thu, 19 Mar 2020 13:34:24 -0500 Subject: [OE-core] [PATCH 1/2] bitbake.conf: Fix nativesdk-wayland missing from SDK Message-ID: <20200319183425.12294-1-tom.hochstein@nxp.com> nativesdk-wayland was not being added to the SDK because it relies on checking the distro feature. This fixes that by filtering the wayland feature to the SDK build. Signed-off-by: Tom Hochstein --- meta/conf/bitbake.conf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf index 4b544a22cd..e44de34a00 100644 --- a/meta/conf/bitbake.conf +++ b/meta/conf/bitbake.conf @@ -830,7 +830,7 @@ DISTRO_FEATURES_NATIVESDK ?= "x11" # Normally target distro features will not be applied to native builds: # Native distro features on this list will use the target feature value DISTRO_FEATURES_FILTER_NATIVE ?= "api-documentation" -DISTRO_FEATURES_FILTER_NATIVESDK ?= "api-documentation" +DISTRO_FEATURES_FILTER_NATIVESDK ?= "api-documentation wayland" DISTRO_FEATURES_BACKFILL = "pulseaudio sysvinit gobject-introspection-data ldconfig" MACHINE_FEATURES_BACKFILL = "rtc qemu-usermode" -- 2.17.1 From tom.hochstein at nxp.com Thu Mar 19 18:34:25 2020 From: tom.hochstein at nxp.com (Tom Hochstein) Date: Thu, 19 Mar 2020 13:34:25 -0500 Subject: [OE-core] [PATCH 2/2] wayland: Fix wayland-scanner missing from SDK In-Reply-To: <20200319183425.12294-1-tom.hochstein@nxp.com> References: <20200319183425.12294-1-tom.hochstein@nxp.com> Message-ID: <20200319183425.12294-2-tom.hochstein@nxp.com> The FILES variable is customized to package wayland-scanner in the target -dev package. However, this is not correct for the nativesdk packages and causes wayland-scanner to be missing from the SDK. Fix the nativesdk packaging by properly limiting the wayland-scanner target packaging. Signed-off-by: Tom Hochstein --- meta/recipes-graphics/wayland/wayland_1.18.0.bb | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/recipes-graphics/wayland/wayland_1.18.0.bb b/meta/recipes-graphics/wayland/wayland_1.18.0.bb index 00be3aac27..c7098483bc 100644 --- a/meta/recipes-graphics/wayland/wayland_1.18.0.bb +++ b/meta/recipes-graphics/wayland/wayland_1.18.0.bb @@ -54,8 +54,8 @@ sysroot_stage_all_append_class-target () { cp ${STAGING_DATADIR_NATIVE}/aclocal/wayland-scanner.m4 ${SYSROOT_DESTDIR}/${datadir}/aclocal/ } -FILES_${PN} = "${libdir}/*${SOLIBS}" -FILES_${PN}-dev += "${bindir} ${datadir}/wayland" +FILES_${PN}_class-target = "${libdir}/*${SOLIBS}" +FILES_${PN}-dev_append_class-target = " ${bindir} ${datadir}/wayland" BBCLASSEXTEND = "native nativesdk" -- 2.17.1 From martin.jansa at gmail.com Thu Mar 19 19:19:13 2020 From: martin.jansa at gmail.com (Martin Jansa) Date: Thu, 19 Mar 2020 20:19:13 +0100 Subject: [OE-core] [zeus][PATCH] sanity: check for more bits of Python Message-ID: <20200319191913.13388-1-Martin.Jansa@gmail.com> From: Ross Burton MJ: icu in master doesn't need distutils anymore, because icu 65.1 currently in dunfell/master doesn't depend on python3-distutils anymore since: https://github.com/unicode-org/icu/commit/b4d41b0561b6e8de38b99850ce0e4be8ef536bb1 but the icu-64.2 in zeus and openembedded-core/meta/recipes-core/ovmf/ovmf_git.bb still need python3-distutils as described in: http://lists.openembedded.org/pipermail/openembedded-core/2020-March/293984.html Signed-off-by: Ross Burton --- meta/classes/sanity.bbclass | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass index 936fe913b4..5c2f8f9d75 100644 --- a/meta/classes/sanity.bbclass +++ b/meta/classes/sanity.bbclass @@ -625,13 +625,14 @@ def check_sanity_version_change(status, d): # In other words, these tests run once in a given build directory and then # never again until the sanity version or host distrubution id/version changes. - # Check the python install is complete. glib-2.0-natives requries - # xml.parsers.expat + # Check the python install is complete. Examples that are often removed in + # minimal installations: glib-2.0-natives requries # xml.parsers.expat and icu + # requires distutils.sysconfig. try: import xml.parsers.expat - except ImportError: - status.addresult('Your python is not a full install. Please install the module xml.parsers.expat (python-xml on openSUSE and SUSE Linux).\n') - import stat + import distutils.sysconfig + except ImportError as e: + status.addresult('Your Python 3 is not a full install. Please install the module %s (see the Getting Started guide for further information).\n' % e.name) status.addresult(check_make_version(d)) status.addresult(check_patch_version(d)) @@ -667,6 +668,7 @@ def check_sanity_version_change(status, d): status.addresult('Please use ASSUME_PROVIDED +=, not ASSUME_PROVIDED = in your local.conf\n') # Check that TMPDIR isn't on a filesystem with limited filename length (eg. eCryptFS) + import stat tmpdir = d.getVar('TMPDIR') status.addresult(check_create_long_filename(tmpdir, "TMPDIR")) tmpdirmode = os.stat(tmpdir).st_mode -- 2.20.1 From armccurdy at gmail.com Thu Mar 19 19:33:17 2020 From: armccurdy at gmail.com (Andre McCurdy) Date: Thu, 19 Mar 2020 12:33:17 -0700 Subject: [OE-core] [zeus][PATCH] sanity: check for more bits of Python In-Reply-To: <20200319191913.13388-1-Martin.Jansa@gmail.com> References: <20200319191913.13388-1-Martin.Jansa@gmail.com> Message-ID: On Thu, Mar 19, 2020 at 12:19 PM Martin Jansa wrote: > > From: Ross Burton > > MJ: icu in master doesn't need distutils anymore, because icu 65.1 currently in > dunfell/master doesn't depend on python3-distutils anymore since: > https://github.com/unicode-org/icu/commit/b4d41b0561b6e8de38b99850ce0e4be8ef536bb1 > > but the icu-64.2 in zeus and openembedded-core/meta/recipes-core/ovmf/ovmf_git.bb > still need python3-distutils as described in: > http://lists.openembedded.org/pipermail/openembedded-core/2020-March/293984.html > > Signed-off-by: Ross Burton > --- > meta/classes/sanity.bbclass | 12 +++++++----- > 1 file changed, 7 insertions(+), 5 deletions(-) > > diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass > index 936fe913b4..5c2f8f9d75 100644 > --- a/meta/classes/sanity.bbclass > +++ b/meta/classes/sanity.bbclass > @@ -625,13 +625,14 @@ def check_sanity_version_change(status, d): > # In other words, these tests run once in a given build directory and then > # never again until the sanity version or host distrubution id/version changes. s/distrubution/distribution/ (not part of the original patch but maybe worth fixing in a v2). > - # Check the python install is complete. glib-2.0-natives requries > - # xml.parsers.expat > + # Check the python install is complete. Examples that are often removed in > + # minimal installations: glib-2.0-natives requries # xml.parsers.expat and icu Stray # left over from reformatting the comment. > + # requires distutils.sysconfig. > try: > import xml.parsers.expat > - except ImportError: > - status.addresult('Your python is not a full install. Please install the module xml.parsers.expat (python-xml on openSUSE and SUSE Linux).\n') > - import stat > + import distutils.sysconfig > + except ImportError as e: > + status.addresult('Your Python 3 is not a full install. Please install the module %s (see the Getting Started guide for further information).\n' % e.name) Should that be the Yocto Project Quick Start? Googling for "yocto getting started guide" doesn't come up with anything. The version of Yocto Project Quick Start found by google doesn't mention anything about installing python3-distutils though, so maybe it's not the right document... > status.addresult(check_make_version(d)) > status.addresult(check_patch_version(d)) > @@ -667,6 +668,7 @@ def check_sanity_version_change(status, d): > status.addresult('Please use ASSUME_PROVIDED +=, not ASSUME_PROVIDED = in your local.conf\n') > > # Check that TMPDIR isn't on a filesystem with limited filename length (eg. eCryptFS) > + import stat > tmpdir = d.getVar('TMPDIR') > status.addresult(check_create_long_filename(tmpdir, "TMPDIR")) > tmpdirmode = os.stat(tmpdir).st_mode > -- > 2.20.1 > > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core at lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core From martin.jansa at gmail.com Thu Mar 19 19:37:41 2020 From: martin.jansa at gmail.com (Martin Jansa) Date: Thu, 19 Mar 2020 20:37:41 +0100 Subject: [OE-core] [zeus][PATCH] sanity: check for more bits of Python In-Reply-To: References: <20200319191913.13388-1-Martin.Jansa@gmail.com> Message-ID: <20200319193741.7sld24mwcdujjpxb@jama> On Thu, Mar 19, 2020 at 12:33:17PM -0700, Andre McCurdy wrote: > On Thu, Mar 19, 2020 at 12:19 PM Martin Jansa wrote: > > > > From: Ross Burton > > > > MJ: icu in master doesn't need distutils anymore, because icu 65.1 currently in > > dunfell/master doesn't depend on python3-distutils anymore since: > > https://github.com/unicode-org/icu/commit/b4d41b0561b6e8de38b99850ce0e4be8ef536bb1 > > > > but the icu-64.2 in zeus and openembedded-core/meta/recipes-core/ovmf/ovmf_git.bb > > still need python3-distutils as described in: > > http://lists.openembedded.org/pipermail/openembedded-core/2020-March/293984.html > > > > Signed-off-by: Ross Burton > > --- > > meta/classes/sanity.bbclass | 12 +++++++----- > > 1 file changed, 7 insertions(+), 5 deletions(-) > > > > diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass > > index 936fe913b4..5c2f8f9d75 100644 > > --- a/meta/classes/sanity.bbclass > > +++ b/meta/classes/sanity.bbclass > > @@ -625,13 +625,14 @@ def check_sanity_version_change(status, d): > > # In other words, these tests run once in a given build directory and then > > # never again until the sanity version or host distrubution id/version changes. > > s/distrubution/distribution/ (not part of the original patch but maybe > worth fixing in a v2). > > > - # Check the python install is complete. glib-2.0-natives requries > > - # xml.parsers.expat > > + # Check the python install is complete. Examples that are often removed in > > + # minimal installations: glib-2.0-natives requries # xml.parsers.expat and icu > > Stray # left over from reformatting the comment. > > > + # requires distutils.sysconfig. > > try: > > import xml.parsers.expat > > - except ImportError: > > - status.addresult('Your python is not a full install. Please install the module xml.parsers.expat (python-xml on openSUSE and SUSE Linux).\n') > > - import stat > > + import distutils.sysconfig > > + except ImportError as e: > > + status.addresult('Your Python 3 is not a full install. Please install the module %s (see the Getting Started guide for further information).\n' % e.name) > > Should that be the Yocto Project Quick Start? Googling for "yocto > getting started guide" doesn't come up with anything. > > The version of Yocto Project Quick Start found by google doesn't > mention anything about installing python3-distutils though, so maybe > it's not the right document... This is just cherry-pick from master to zeus (I've only updated the commit message). If you want these issues fixed, then it should be fixed first in master and then backported to zeus. > > > status.addresult(check_make_version(d)) > > status.addresult(check_patch_version(d)) > > @@ -667,6 +668,7 @@ def check_sanity_version_change(status, d): > > status.addresult('Please use ASSUME_PROVIDED +=, not ASSUME_PROVIDED = in your local.conf\n') > > > > # Check that TMPDIR isn't on a filesystem with limited filename length (eg. eCryptFS) > > + import stat > > tmpdir = d.getVar('TMPDIR') > > status.addresult(check_create_long_filename(tmpdir, "TMPDIR")) > > tmpdirmode = os.stat(tmpdir).st_mode > > -- > > 2.20.1 > > > > -- > > _______________________________________________ > > Openembedded-core mailing list > > Openembedded-core at lists.openembedded.org > > http://lists.openembedded.org/mailman/listinfo/openembedded-core -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From armccurdy at gmail.com Thu Mar 19 19:55:20 2020 From: armccurdy at gmail.com (Andre McCurdy) Date: Thu, 19 Mar 2020 12:55:20 -0700 Subject: [OE-core] [zeus][PATCH] sanity: check for more bits of Python In-Reply-To: <20200319193741.7sld24mwcdujjpxb@jama> References: <20200319191913.13388-1-Martin.Jansa@gmail.com> <20200319193741.7sld24mwcdujjpxb@jama> Message-ID: On Thu, Mar 19, 2020 at 12:37 PM Martin Jansa wrote: > > On Thu, Mar 19, 2020 at 12:33:17PM -0700, Andre McCurdy wrote: > > On Thu, Mar 19, 2020 at 12:19 PM Martin Jansa wrote: > > > > > > From: Ross Burton > > > > > > MJ: icu in master doesn't need distutils anymore, because icu 65.1 currently in > > > dunfell/master doesn't depend on python3-distutils anymore since: > > > https://github.com/unicode-org/icu/commit/b4d41b0561b6e8de38b99850ce0e4be8ef536bb1 > > > > > > but the icu-64.2 in zeus and openembedded-core/meta/recipes-core/ovmf/ovmf_git.bb > > > still need python3-distutils as described in: > > > http://lists.openembedded.org/pipermail/openembedded-core/2020-March/293984.html > > > > > > Signed-off-by: Ross Burton > > > --- > > > meta/classes/sanity.bbclass | 12 +++++++----- > > > 1 file changed, 7 insertions(+), 5 deletions(-) > > > > > > diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass > > > index 936fe913b4..5c2f8f9d75 100644 > > > --- a/meta/classes/sanity.bbclass > > > +++ b/meta/classes/sanity.bbclass > > > @@ -625,13 +625,14 @@ def check_sanity_version_change(status, d): > > > # In other words, these tests run once in a given build directory and then > > > # never again until the sanity version or host distrubution id/version changes. > > > > s/distrubution/distribution/ (not part of the original patch but maybe > > worth fixing in a v2). > > > > > - # Check the python install is complete. glib-2.0-natives requries > > > - # xml.parsers.expat > > > + # Check the python install is complete. Examples that are often removed in > > > + # minimal installations: glib-2.0-natives requries # xml.parsers.expat and icu > > > > Stray # left over from reformatting the comment. > > > > > + # requires distutils.sysconfig. > > > try: > > > import xml.parsers.expat > > > - except ImportError: > > > - status.addresult('Your python is not a full install. Please install the module xml.parsers.expat (python-xml on openSUSE and SUSE Linux).\n') > > > - import stat > > > + import distutils.sysconfig > > > + except ImportError as e: > > > + status.addresult('Your Python 3 is not a full install. Please install the module %s (see the Getting Started guide for further information).\n' % e.name) > > > > Should that be the Yocto Project Quick Start? Googling for "yocto > > getting started guide" doesn't come up with anything. > > > > The version of Yocto Project Quick Start found by google doesn't > > mention anything about installing python3-distutils though, so maybe > > it's not the right document... > > This is just cherry-pick from master to zeus (I've only updated the > commit message). > > If you want these issues fixed, then it should be fixed first in master > and then backported to zeus. Oh yes, didn't notice it's a backport to zeus. Sorry! > > > > > status.addresult(check_make_version(d)) > > > status.addresult(check_patch_version(d)) > > > @@ -667,6 +668,7 @@ def check_sanity_version_change(status, d): > > > status.addresult('Please use ASSUME_PROVIDED +=, not ASSUME_PROVIDED = in your local.conf\n') > > > > > > # Check that TMPDIR isn't on a filesystem with limited filename length (eg. eCryptFS) > > > + import stat > > > tmpdir = d.getVar('TMPDIR') > > > status.addresult(check_create_long_filename(tmpdir, "TMPDIR")) > > > tmpdirmode = os.stat(tmpdir).st_mode > > > -- > > > 2.20.1 > > > > > > -- > > > _______________________________________________ > > > Openembedded-core mailing list > > > Openembedded-core at lists.openembedded.org > > > http://lists.openembedded.org/mailman/listinfo/openembedded-core From jpuhlman at mvista.com Thu Mar 19 22:44:50 2020 From: jpuhlman at mvista.com (Jeremy A. Puhlman) Date: Thu, 19 Mar 2020 15:44:50 -0700 Subject: [OE-core] [PATCH] qemu-system-native: disable options not included in extended tarball Message-ID: <20200319224450.4798-1-jpuhlman@mvista.com> From: Jeremy Puhlman * Add PACKAGECONFIG option for xkbcommon qemu-keymap.c:16:10: fatal error: xkbcommon/xkbcommon.h: No such file or directory * Add PACKAGECONFIG option and patch for libudev commands-posix.c:53:10: fatal error: libudev.h: No such file or directory * Add PACKAGECONFIG option for libxml2 util/osdep.c:136: undefined reference to `fcntl64' - Without specifying libxml2, configure searches the system and pulls in the system libxml2 if it is present. In the process it adds -L/usr/lib64 which causes the system libc to be linked instead of the one from the extended tarball. * Specifically remove xkbcommon and libudev from qemu-system-native PACKAGECONFIG None of the above libraries appear to be included in the depends for any of the qemu builds, so if they are getting linked in, its probably not intentionally. Signed-off-by: Jeremy Puhlman --- .../qemu/qemu-system-native_4.2.0.bb | 3 +++ meta/recipes-devtools/qemu/qemu.inc | 4 +++ .../qemu/qemu/0001-Add-enable-disable-udev.patch | 29 ++++++++++++++++++++++ 3 files changed, 36 insertions(+) create mode 100644 meta/recipes-devtools/qemu/qemu/0001-Add-enable-disable-udev.patch diff --git a/meta/recipes-devtools/qemu/qemu-system-native_4.2.0.bb b/meta/recipes-devtools/qemu/qemu-system-native_4.2.0.bb index d83ee59375..f3ceaa1003 100644 --- a/meta/recipes-devtools/qemu/qemu-system-native_4.2.0.bb +++ b/meta/recipes-devtools/qemu/qemu-system-native_4.2.0.bb @@ -10,6 +10,9 @@ DEPENDS = "glib-2.0-native zlib-native pixman-native qemu-native bison-native" EXTRA_OECONF_append = " --target-list=${@get_qemu_system_target_list(d)}" PACKAGECONFIG ??= "fdt alsa kvm" +# Do not exist in buildtools-extended-tarball" +PACKAGECONFIG_remove = "xkbcommon" +PACKAGECONFIG_remove = "libudev" # Handle distros such as CentOS 5 32-bit that do not have kvm support PACKAGECONFIG_remove = "${@'kvm' if not os.path.exists('/usr/include/linux/kvm.h') else ''}" diff --git a/meta/recipes-devtools/qemu/qemu.inc b/meta/recipes-devtools/qemu/qemu.inc index 3ce14d9fa0..7cf436783d 100644 --- a/meta/recipes-devtools/qemu/qemu.inc +++ b/meta/recipes-devtools/qemu/qemu.inc @@ -33,6 +33,7 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \ file://CVE-2020-7039-1.patch \ file://CVE-2020-7039-2.patch \ file://CVE-2020-7039-3.patch \ + file://0001-Add-enable-disable-udev.patch \ " UPSTREAM_CHECK_REGEX = "qemu-(?P\d+(\.\d+)+)\.tar" @@ -172,6 +173,9 @@ PACKAGECONFIG[spice] = "--enable-spice,--disable-spice,spice" PACKAGECONFIG[usb-redir] = "--enable-usb-redir,--disable-usb-redir,usbredir" PACKAGECONFIG[snappy] = "--enable-snappy,--disable-snappy,snappy" PACKAGECONFIG[glusterfs] = "--enable-glusterfs,--disable-glusterfs" +PACKAGECONFIG[xkbcommon] = "--enable-xkbcommon,--disable-xkbcommon,libxkbcommon" +PACKAGECONFIG[libudev] = "--enable-libudev,--disable-libudev,eudev" +#PACKAGECONFIG[libxml2] = "--enable-libxml2,--disable-libxml2,libxml2" INSANE_SKIP_${PN} = "arch" diff --git a/meta/recipes-devtools/qemu/qemu/0001-Add-enable-disable-udev.patch b/meta/recipes-devtools/qemu/qemu/0001-Add-enable-disable-udev.patch new file mode 100644 index 0000000000..c2c5849d65 --- /dev/null +++ b/meta/recipes-devtools/qemu/qemu/0001-Add-enable-disable-udev.patch @@ -0,0 +1,29 @@ +From a471cf4e4c73350e090eb2cd87ec959d138012e5 Mon Sep 17 00:00:00 2001 +From: Jeremy Puhlman +Date: Thu, 19 Mar 2020 11:54:26 -0700 +Subject: [PATCH] Add enable/disable libudev + +Upstream-Status: Pending +Signed-off-by: Jeremy Puhlman +--- + configure | 4 ++++ + 1 file changed, 4 insertions(+) + +diff --git a/configure b/configure +index cac271c..bd116eb 100755 +--- a/configure ++++ b/configure +@@ -1539,6 +1539,10 @@ for opt do + ;; + --disable-plugins) plugins="no" + ;; ++ --enable-libudev) libudev="yes" ++ ;; ++ --disable-libudev) libudev="no" ++ ;; + *) + echo "ERROR: unknown option $opt" + echo "Try '$0 --help' for more information" +-- +1.8.3.1 + -- 2.13.3 From richard.purdie at linuxfoundation.org Thu Mar 19 23:38:15 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Thu, 19 Mar 2020 23:38:15 +0000 Subject: [OE-core] [RFC PATCH 0/2] image.bbclass: support two-stage deployment of image artifacts In-Reply-To: References: <20200319164403.29605-1-brgl@bgdev.pl> <21fcbda1e8b274ba75534159179ca9535c618d68.camel@linuxfoundation.org> Message-ID: On Thu, 2020-03-19 at 19:20 +0100, Bartosz Golaszewski wrote: > If we'll really get to a point where we need to create a hierarchy of > multiple levels of image deployment, then maybe we should switch to > deploying each image right after it is created in its dedicated > do_image_ task, then we could really fine-tune the inter-task > dependencies. But we're not there yet and IMO currently it would be > overkill. The rule of thumb for me is not to add new interfaces > nobody asks for. Going back in time I'm the person who split the image pieces off from do_rootfs and split the different image commands into different tasks. I did this for several reasons but one was we were developing new task dependency code inside the image construction which was just crazy. I was wondering about the option of having the image task deploy the image earlier. I think that could be made to work. I think conceptually it makes more sense architecturally than adding in arbitrary new task levels to the existing structure. > This also makes your argument about adding a third category purely > theoretical: I don't see how we would need another category of images > anytime soon. I often think things like that but then new use cases come along... > Please do - I'm open for other ideas. Just please keep in mind: > there's obviously a problem with the current approach. I described it > in detail and it turned out Quentin had encountered it too and dealt > with it using a nasty workaround (fitImage deployed by the image > recipe and not the kernel). I'd like to fix it upstream and proposed > a solution that is IMO not horrible. I'd appreciate if we could reach > a compromise that wouldn't leave us with downstream hacks. I do understand there is a problem. We also have problems with people not understanding the code as it works today. Your proposal adds something else with is hard to explain to users ("Is my image simple or composed?") and whilst we can and do add complexity where we need to, I'm not yet convinced this change makes enough sense to have it. Changing the way image deployment works would in many ways be much easier for people to understand and makes the system more flexible without adding problematic terminology. > Please also note that sometimes "gets the job done" really is better > than not solving problems. Just look at initcall levels in the linux > kernel - they are similar to what I proposed here and serve as a > surrogate for real dependencies. We have piles of "get the job done" and also need to sometimes take a step back and see if we can do something better. Right now I think your proposal makes things worse and will be hard to explain to people. My instinct is we can do better here. Cheers, Richard From jpitti at cisco.com Thu Mar 19 23:33:30 2020 From: jpitti at cisco.com (Julius Hemanth Pitti) Date: Thu, 19 Mar 2020 16:33:30 -0700 Subject: [OE-core] [zeus][PATCH] nfs-utils: Disable statx if using glibc emulation Message-ID: <20200319233330.65306-1-jpitti@cisco.com> nfs-utils 2.4.1, moves from "stat" to "statx with AT_STATX_DONT_SYNC" in parts of the code. statx is supported in Linux kernel v4.11 and above. For all older kernels glibc emulates statx, and it doesn't support AT_STATX_DONT_SYNC and will return EINVAL. When server uses nfs-utils 2.4.1 on kernel v4.10 and older, mount.nfs4 would fail with error "reason given by server: No such file or directory". Since Linux v4.4 and v4.9 are LTS, its more likely that people would use above combination. This issue has been fixed in nfs-utils 2.4.3 and above. Backporting fix to 2.4.1. Signed-off-by: Julius Hemanth Pitti --- ...sable-statx-if-using-glibc-emulation.patch | 34 +++++++++++++++++++ .../nfs-utils/nfs-utils_2.4.1.bb | 1 + 2 files changed, 35 insertions(+) create mode 100644 meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Disable-statx-if-using-glibc-emulation.patch diff --git a/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Disable-statx-if-using-glibc-emulation.patch b/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Disable-statx-if-using-glibc-emulation.patch new file mode 100644 index 0000000000..b8f96f3fba --- /dev/null +++ b/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Disable-statx-if-using-glibc-emulation.patch @@ -0,0 +1,34 @@ +From ff3ad88c233ecd87f7983ad13836323f944540ec Mon Sep 17 00:00:00 2001 +From: Doug Nazar +Date: Mon, 9 Dec 2019 10:53:37 -0500 +Subject: [PATCH] Disable statx if using glibc emulation + +On older kernels without statx, glibc with statx support will attempt +to emulate the call. However it doesn't support AT_STATX_DONT_SYNC and +will return EINVAL. This causes all xstat/xlstat calls to fail. + +Upstream Status: Backport + +Signed-off-by: Doug Nazar +Signed-off-by: Steve Dickson +--- + support/misc/xstat.c | 3 +++ + 1 file changed, 3 insertions(+) + +diff --git a/support/misc/xstat.c b/support/misc/xstat.c +index 661e29e4..a438fbcc 100644 +--- a/support/misc/xstat.c ++++ b/support/misc/xstat.c +@@ -51,6 +51,9 @@ statx_do_stat(int fd, const char *pathname, struct stat *statbuf, int flags) + statx_copy(statbuf, &stxbuf); + return 0; + } ++ /* glibc emulation doesn't support AT_STATX_DONT_SYNC */ ++ if (errno == EINVAL) ++ errno = ENOSYS; + if (errno == ENOSYS) + statx_supported = 0; + } else +-- +2.19.1 + diff --git a/meta/recipes-connectivity/nfs-utils/nfs-utils_2.4.1.bb b/meta/recipes-connectivity/nfs-utils/nfs-utils_2.4.1.bb index 7e80354e4e..3ae8f965c8 100644 --- a/meta/recipes-connectivity/nfs-utils/nfs-utils_2.4.1.bb +++ b/meta/recipes-connectivity/nfs-utils/nfs-utils_2.4.1.bb @@ -33,6 +33,7 @@ SRC_URI = "${KERNELORG_MIRROR}/linux/utils/nfs-utils/${PV}/nfs-utils-${PV}.tar.x file://0001-Makefile.am-fix-undefined-function-for-libnsm.a.patch \ file://0001-Don-t-build-tools-with-CC_FOR_BUILD.patch \ file://0001-Fix-include-order-between-config.h-and-stat.h.patch \ + file://0001-Disable-statx-if-using-glibc-emulation.patch \ " SRC_URI_append_libc-glibc = " file://0001-configure.ac-Do-not-fatalize-Wmissing-prototypes.patch" SRC_URI_append_libc-musl = " file://nfs-utils-musl-res_querydomain.patch" -- 2.18.1 From richard.purdie at linuxfoundation.org Thu Mar 19 23:42:37 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Thu, 19 Mar 2020 23:42:37 +0000 Subject: [OE-core] [PATCH 2/2] wayland: Fix wayland-scanner missing from SDK In-Reply-To: <20200319183425.12294-2-tom.hochstein@nxp.com> References: <20200319183425.12294-1-tom.hochstein@nxp.com> <20200319183425.12294-2-tom.hochstein@nxp.com> Message-ID: <80d37c49027b32c2bebe939dbcd439240b0139c6.camel@linuxfoundation.org> On Thu, 2020-03-19 at 13:34 -0500, Tom Hochstein wrote: > The FILES variable is customized to package wayland-scanner > in the target -dev package. However, this is not correct for > the nativesdk packages and causes wayland-scanner to be > missing from the SDK. > > Fix the nativesdk packaging by properly limiting the > wayland-scanner target packaging. > > Signed-off-by: Tom Hochstein > --- > meta/recipes-graphics/wayland/wayland_1.18.0.bb | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/meta/recipes-graphics/wayland/wayland_1.18.0.bb b/meta/recipes-graphics/wayland/wayland_1.18.0.bb > index 00be3aac27..c7098483bc 100644 > --- a/meta/recipes-graphics/wayland/wayland_1.18.0.bb > +++ b/meta/recipes-graphics/wayland/wayland_1.18.0.bb > @@ -54,8 +54,8 @@ sysroot_stage_all_append_class-target () { > cp ${STAGING_DATADIR_NATIVE}/aclocal/wayland-scanner.m4 ${SYSROOT_DESTDIR}/${datadir}/aclocal/ > } > > -FILES_${PN} = "${libdir}/*${SOLIBS}" > -FILES_${PN}-dev += "${bindir} ${datadir}/wayland" > +FILES_${PN}_class-target = "${libdir}/*${SOLIBS}" > +FILES_${PN}-dev_append_class-target = " ${bindir} ${datadir}/wayland" Nobody can look at that and tell that its an fix for nativesdk packaging. At the very least it needs a comment about what its doing but I can't help feeling there must be some neater way we can do this that overrides for nativesdk instead of misleading with target references? Cheers, Richard From patchwork at patchwork.openembedded.org Fri Mar 20 00:02:11 2020 From: patchwork at patchwork.openembedded.org (Patchwork) Date: Fri, 20 Mar 2020 00:02:11 -0000 Subject: [OE-core] =?utf-8?q?=E2=9C=97_patchtest=3A_failure_for_nfs-utils?= =?utf-8?q?=3A_Disable_statx_if_using_glibc_emulation?= In-Reply-To: <20200319233330.65306-1-jpitti@cisco.com> References: <20200319233330.65306-1-jpitti@cisco.com> Message-ID: <20200320000211.2274.16233@do> == Series Details == Series: nfs-utils: Disable statx if using glibc emulation Revision: 1 URL : https://patchwork.openembedded.org/series/23317/ 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 Upstream-Status is in incorrect format [test_upstream_status_presence_format] Suggested fix Fix Upstream-Status format in 0001-Disable-statx-if-using-glibc-emulation.patch Current Upstream Status: Backport Standard format Upstream-Status: Valid status Pending, Accepted, Backport, Denied, Inappropriate [reason], Submitted [where] If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core at 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 From richard.purdie at linuxfoundation.org Fri Mar 20 00:02:22 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Fri, 20 Mar 2020 00:02:22 +0000 Subject: [OE-core] [PATCH] qemu-system-native: disable options not included in extended tarball In-Reply-To: <20200319224450.4798-1-jpuhlman@mvista.com> References: <20200319224450.4798-1-jpuhlman@mvista.com> Message-ID: <4cf821be03065accd90e14237708eaf7f343b572.camel@linuxfoundation.org> On Thu, 2020-03-19 at 15:44 -0700, Jeremy A. Puhlman wrote: > From: Jeremy Puhlman > > * Add PACKAGECONFIG option for xkbcommon > qemu-keymap.c:16:10: fatal error: xkbcommon/xkbcommon.h: No such file or directory > > * Add PACKAGECONFIG option and patch for libudev > commands-posix.c:53:10: fatal error: libudev.h: No such file or directory > > * Add PACKAGECONFIG option for libxml2 > util/osdep.c:136: undefined reference to `fcntl64' > > - Without specifying libxml2, configure searches the system and pulls in the system > libxml2 if it is present. In the process it adds -L/usr/lib64 which causes the > system libc to be linked instead of the one from the extended tarball. > > * Specifically remove xkbcommon and libudev from qemu-system-native PACKAGECONFIG > > None of the above libraries appear to be included in the depends for any of the qemu > builds, so if they are getting linked in, its probably not intentionally. > > Signed-off-by: Jeremy Puhlman > --- > .../qemu/qemu-system-native_4.2.0.bb | 3 +++ > meta/recipes-devtools/qemu/qemu.inc | 4 +++ > .../qemu/qemu/0001-Add-enable-disable-udev.patch | 29 ++++++++++++++++++++++ > 3 files changed, 36 insertions(+) > create mode 100644 meta/recipes-devtools/qemu/qemu/0001-Add-enable-disable-udev.patch > > diff --git a/meta/recipes-devtools/qemu/qemu-system-native_4.2.0.bb b/meta/recipes-devtools/qemu/qemu-system-native_4.2.0.bb > index d83ee59375..f3ceaa1003 100644 > --- a/meta/recipes-devtools/qemu/qemu-system-native_4.2.0.bb > +++ b/meta/recipes-devtools/qemu/qemu-system-native_4.2.0.bb > @@ -10,6 +10,9 @@ DEPENDS = "glib-2.0-native zlib-native pixman-native qemu-native bison-native" > EXTRA_OECONF_append = " --target-list=${@get_qemu_system_target_list(d)}" > > PACKAGECONFIG ??= "fdt alsa kvm" > +# Do not exist in buildtools-extended-tarball" > +PACKAGECONFIG_remove = "xkbcommon" > +PACKAGECONFIG_remove = "libudev" I don't like this piece of the patch. Remove is generally a bad idea as its very hard to counteract. If you did add this to PACKAGECONFIG, it would add the appropriate -native pieces to DEPENDS so I'm not sure what we're trying to achieve here anyway, it should work without this remove code either way? At the very least the comment is very misleading and will be hard to understand in a few months time without looking back at this commit. Cheers, Richard From jpuhlman at mvista.com Fri Mar 20 00:06:26 2020 From: jpuhlman at mvista.com (Jeremy Puhlman) Date: Thu, 19 Mar 2020 17:06:26 -0700 Subject: [OE-core] [PATCH] qemu-system-native: disable options not included in extended tarball In-Reply-To: <4cf821be03065accd90e14237708eaf7f343b572.camel@linuxfoundation.org> References: <20200319224450.4798-1-jpuhlman@mvista.com> <4cf821be03065accd90e14237708eaf7f343b572.camel@linuxfoundation.org> Message-ID: On 3/19/2020 5:02 PM, Richard Purdie wrote: > On Thu, 2020-03-19 at 15:44 -0700, Jeremy A. Puhlman wrote: >> From: Jeremy Puhlman >> >> * Add PACKAGECONFIG option for xkbcommon >> qemu-keymap.c:16:10: fatal error: xkbcommon/xkbcommon.h: No such file or directory >> >> * Add PACKAGECONFIG option and patch for libudev >> commands-posix.c:53:10: fatal error: libudev.h: No such file or directory >> >> * Add PACKAGECONFIG option for libxml2 >> util/osdep.c:136: undefined reference to `fcntl64' >> >> - Without specifying libxml2, configure searches the system and pulls in the system >> libxml2 if it is present. In the process it adds -L/usr/lib64 which causes the >> system libc to be linked instead of the one from the extended tarball. >> >> * Specifically remove xkbcommon and libudev from qemu-system-native PACKAGECONFIG >> >> None of the above libraries appear to be included in the depends for any of the qemu >> builds, so if they are getting linked in, its probably not intentionally. >> >> Signed-off-by: Jeremy Puhlman >> --- >> .../qemu/qemu-system-native_4.2.0.bb | 3 +++ >> meta/recipes-devtools/qemu/qemu.inc | 4 +++ >> .../qemu/qemu/0001-Add-enable-disable-udev.patch | 29 ++++++++++++++++++++++ >> 3 files changed, 36 insertions(+) >> create mode 100644 meta/recipes-devtools/qemu/qemu/0001-Add-enable-disable-udev.patch >> >> diff --git a/meta/recipes-devtools/qemu/qemu-system-native_4.2.0.bb b/meta/recipes-devtools/qemu/qemu-system-native_4.2.0.bb >> index d83ee59375..f3ceaa1003 100644 >> --- a/meta/recipes-devtools/qemu/qemu-system-native_4.2.0.bb >> +++ b/meta/recipes-devtools/qemu/qemu-system-native_4.2.0.bb >> @@ -10,6 +10,9 @@ DEPENDS = "glib-2.0-native zlib-native pixman-native qemu-native bison-native" >> EXTRA_OECONF_append = " --target-list=${@get_qemu_system_target_list(d)}" >> >> PACKAGECONFIG ??= "fdt alsa kvm" >> +# Do not exist in buildtools-extended-tarball" >> +PACKAGECONFIG_remove = "xkbcommon" >> +PACKAGECONFIG_remove = "libudev" > I don't like this piece of the patch. Remove is generally a bad idea as > its very hard to counteract. If you did add this to PACKAGECONFIG, it > would add the appropriate -native pieces to DEPENDS so I'm not sure > what we're trying to achieve here anyway, it should work without this > remove code either way? Fair enough, I was just trying to ensure it would build if the options got set elsewhere. We don't have a eudev-native or xkbcommon-native so if it got enabled it should die from lack of dependencies. I was trying to be cautious. > > At the very least the comment is very misleading and will be hard to > understand in a few months time without looking back at this commit. Okay I can remove it, -- Jeremy A. Puhlman jpuhlman at mvista.com From jpuhlman at mvista.com Fri Mar 20 00:21:56 2020 From: jpuhlman at mvista.com (Jeremy A. Puhlman) Date: Thu, 19 Mar 2020 17:21:56 -0700 Subject: [OE-core] [PATCH v2] qemu-system-native: disable options not included in extended tarball Message-ID: <20200320002156.8456-1-jpuhlman@mvista.com> From: Jeremy Puhlman * Add PACKAGECONFIG option for xkbcommon qemu-keymap.c:16:10: fatal error: xkbcommon/xkbcommon.h: No such file or directory * Add PACKAGECONFIG option and patch for libudev commands-posix.c:53:10: fatal error: libudev.h: No such file or directory * Add PACKAGECONFIG option for libxml2 util/osdep.c:136: undefined reference to `fcntl64' - Without specifying libxml2, configure searches the system and pulls in the system libxml2 if it is present. In the process it adds -L/usr/lib64 which causes the system libc to be linked instead of the one from the extended tarball. None of the above libraries appear to be included in the depends for any of the qemu builds, so if they are getting linked in, its probably not intentionally. Signed-off-by: Jeremy Puhlman --- meta/recipes-devtools/qemu/qemu.inc | 4 +++ .../qemu/qemu/0001-Add-enable-disable-udev.patch | 29 ++++++++++++++++++++++ 2 files changed, 33 insertions(+) create mode 100644 meta/recipes-devtools/qemu/qemu/0001-Add-enable-disable-udev.patch diff --git a/meta/recipes-devtools/qemu/qemu.inc b/meta/recipes-devtools/qemu/qemu.inc index 3ce14d9fa0..7cf436783d 100644 --- a/meta/recipes-devtools/qemu/qemu.inc +++ b/meta/recipes-devtools/qemu/qemu.inc @@ -33,6 +33,7 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \ file://CVE-2020-7039-1.patch \ file://CVE-2020-7039-2.patch \ file://CVE-2020-7039-3.patch \ + file://0001-Add-enable-disable-udev.patch \ " UPSTREAM_CHECK_REGEX = "qemu-(?P\d+(\.\d+)+)\.tar" @@ -172,6 +173,9 @@ PACKAGECONFIG[spice] = "--enable-spice,--disable-spice,spice" PACKAGECONFIG[usb-redir] = "--enable-usb-redir,--disable-usb-redir,usbredir" PACKAGECONFIG[snappy] = "--enable-snappy,--disable-snappy,snappy" PACKAGECONFIG[glusterfs] = "--enable-glusterfs,--disable-glusterfs" +PACKAGECONFIG[xkbcommon] = "--enable-xkbcommon,--disable-xkbcommon,libxkbcommon" +PACKAGECONFIG[libudev] = "--enable-libudev,--disable-libudev,eudev" +#PACKAGECONFIG[libxml2] = "--enable-libxml2,--disable-libxml2,libxml2" INSANE_SKIP_${PN} = "arch" diff --git a/meta/recipes-devtools/qemu/qemu/0001-Add-enable-disable-udev.patch b/meta/recipes-devtools/qemu/qemu/0001-Add-enable-disable-udev.patch new file mode 100644 index 0000000000..c2c5849d65 --- /dev/null +++ b/meta/recipes-devtools/qemu/qemu/0001-Add-enable-disable-udev.patch @@ -0,0 +1,29 @@ +From a471cf4e4c73350e090eb2cd87ec959d138012e5 Mon Sep 17 00:00:00 2001 +From: Jeremy Puhlman +Date: Thu, 19 Mar 2020 11:54:26 -0700 +Subject: [PATCH] Add enable/disable libudev + +Upstream-Status: Pending +Signed-off-by: Jeremy Puhlman +--- + configure | 4 ++++ + 1 file changed, 4 insertions(+) + +diff --git a/configure b/configure +index cac271c..bd116eb 100755 +--- a/configure ++++ b/configure +@@ -1539,6 +1539,10 @@ for opt do + ;; + --disable-plugins) plugins="no" + ;; ++ --enable-libudev) libudev="yes" ++ ;; ++ --disable-libudev) libudev="no" ++ ;; + *) + echo "ERROR: unknown option $opt" + echo "Try '$0 --help' for more information" +-- +1.8.3.1 + -- 2.13.3 From jpitti at cisco.com Fri Mar 20 00:26:43 2020 From: jpitti at cisco.com (Julius Hemanth Pitti) Date: Thu, 19 Mar 2020 17:26:43 -0700 Subject: [OE-core] [zeus][PATCH v2] nfs-utils: Disable statx if using glibc emulation Message-ID: <20200320002643.14888-1-jpitti@cisco.com> nfs-utils 2.4.1, moves from "stat" to "statx with AT_STATX_DONT_SYNC" in parts of the code. statx is supported in Linux kernel v4.11 and above. For all older kernels glibc emulates statx, and it doesn't support AT_STATX_DONT_SYNC and will return EINVAL. When server uses nfs-utils 2.4.1 on kernel v4.10 and older, mount.nfs4 would fail with error "reason given by server: No such file or directory". Since Linux v4.4 and v4.9 are LTS, its more likely that people would use above combination. This issue has been fixed in nfs-utils 2.4.3 and above. Backporting fix to 2.4.1. Signed-off-by: Julius Hemanth Pitti --- ...sable-statx-if-using-glibc-emulation.patch | 34 +++++++++++++++++++ .../nfs-utils/nfs-utils_2.4.1.bb | 1 + 2 files changed, 35 insertions(+) create mode 100644 meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Disable-statx-if-using-glibc-emulation.patch diff --git a/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Disable-statx-if-using-glibc-emulation.patch b/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Disable-statx-if-using-glibc-emulation.patch new file mode 100644 index 0000000000..98b1391923 --- /dev/null +++ b/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Disable-statx-if-using-glibc-emulation.patch @@ -0,0 +1,34 @@ +From ff3ad88c233ecd87f7983ad13836323f944540ec Mon Sep 17 00:00:00 2001 +From: Doug Nazar +Date: Mon, 9 Dec 2019 10:53:37 -0500 +Subject: [PATCH] Disable statx if using glibc emulation + +On older kernels without statx, glibc with statx support will attempt +to emulate the call. However it doesn't support AT_STATX_DONT_SYNC and +will return EINVAL. This causes all xstat/xlstat calls to fail. + +Upstream-Status: Backport + +Signed-off-by: Doug Nazar +Signed-off-by: Steve Dickson +--- + support/misc/xstat.c | 3 +++ + 1 file changed, 3 insertions(+) + +diff --git a/support/misc/xstat.c b/support/misc/xstat.c +index 661e29e4..a438fbcc 100644 +--- a/support/misc/xstat.c ++++ b/support/misc/xstat.c +@@ -51,6 +51,9 @@ statx_do_stat(int fd, const char *pathname, struct stat *statbuf, int flags) + statx_copy(statbuf, &stxbuf); + return 0; + } ++ /* glibc emulation doesn't support AT_STATX_DONT_SYNC */ ++ if (errno == EINVAL) ++ errno = ENOSYS; + if (errno == ENOSYS) + statx_supported = 0; + } else +-- +2.19.1 + diff --git a/meta/recipes-connectivity/nfs-utils/nfs-utils_2.4.1.bb b/meta/recipes-connectivity/nfs-utils/nfs-utils_2.4.1.bb index 7e80354e4e..3ae8f965c8 100644 --- a/meta/recipes-connectivity/nfs-utils/nfs-utils_2.4.1.bb +++ b/meta/recipes-connectivity/nfs-utils/nfs-utils_2.4.1.bb @@ -33,6 +33,7 @@ SRC_URI = "${KERNELORG_MIRROR}/linux/utils/nfs-utils/${PV}/nfs-utils-${PV}.tar.x file://0001-Makefile.am-fix-undefined-function-for-libnsm.a.patch \ file://0001-Don-t-build-tools-with-CC_FOR_BUILD.patch \ file://0001-Fix-include-order-between-config.h-and-stat.h.patch \ + file://0001-Disable-statx-if-using-glibc-emulation.patch \ " SRC_URI_append_libc-glibc = " file://0001-configure.ac-Do-not-fatalize-Wmissing-prototypes.patch" SRC_URI_append_libc-musl = " file://nfs-utils-musl-res_querydomain.patch" -- 2.17.1 From anuj.mittal at intel.com Fri Mar 20 01:01:56 2020 From: anuj.mittal at intel.com (Anuj Mittal) Date: Fri, 20 Mar 2020 09:01:56 +0800 Subject: [OE-core] [PATCH] icu: fix CVE-2020-10531 Message-ID: <20200320010156.120590-1-anuj.mittal@intel.com> Signed-off-by: Anuj Mittal --- .../icu/icu/CVE-2020-10531.patch | 122 ++++++++++++++++++ meta/recipes-support/icu/icu_65.1.bb | 1 + 2 files changed, 123 insertions(+) create mode 100644 meta/recipes-support/icu/icu/CVE-2020-10531.patch diff --git a/meta/recipes-support/icu/icu/CVE-2020-10531.patch b/meta/recipes-support/icu/icu/CVE-2020-10531.patch new file mode 100644 index 0000000000..56303fc0f2 --- /dev/null +++ b/meta/recipes-support/icu/icu/CVE-2020-10531.patch @@ -0,0 +1,122 @@ +From b7d08bc04a4296982fcef8b6b8a354a9e4e7afca Mon Sep 17 00:00:00 2001 +From: Frank Tang +Date: Sat, 1 Feb 2020 02:39:04 +0000 +Subject: [PATCH] ICU-20958 Prevent SEGV_MAPERR in append + +See #971 + +Upstream-Status: Backport [https://github.com/unicode-org/icu/commit/b7d08bc04a4296982fcef8b6b8a354a9e4e7afca] +CVE: CVE-2020-10531 +Signed-off-by: Anuj Mittal +--- + icu4c/source/common/unistr.cpp | 6 ++- + icu4c/source/test/intltest/ustrtest.cpp | 62 +++++++++++++++++++++++++ + icu4c/source/test/intltest/ustrtest.h | 1 + + 3 files changed, 68 insertions(+), 1 deletion(-) + +diff --git a/icu4c/source/common/unistr.cpp b/icu4c/source/common/unistr.cpp +index 901bb3358ba..077b4d6ef20 100644 +--- a/icu4c/source/common/unistr.cpp ++++ b/icu4c/source/common/unistr.cpp +@@ -1563,7 +1563,11 @@ UnicodeString::doAppend(const UChar *srcChars, int32_t srcStart, int32_t srcLeng + } + + int32_t oldLength = length(); +- int32_t newLength = oldLength + srcLength; ++ int32_t newLength; ++ if (uprv_add32_overflow(oldLength, srcLength, &newLength)) { ++ setToBogus(); ++ return *this; ++ } + + // Check for append onto ourself + const UChar* oldArray = getArrayStart(); +diff --git a/icu4c/source/test/intltest/ustrtest.cpp b/icu4c/source/test/intltest/ustrtest.cpp +index b6515ea813c..ad38bdf53a3 100644 +--- a/icu4c/source/test/intltest/ustrtest.cpp ++++ b/icu4c/source/test/intltest/ustrtest.cpp +@@ -67,6 +67,7 @@ void UnicodeStringTest::runIndexedTest( int32_t index, UBool exec, const char* & + TESTCASE_AUTO(TestWCharPointers); + TESTCASE_AUTO(TestNullPointers); + TESTCASE_AUTO(TestUnicodeStringInsertAppendToSelf); ++ TESTCASE_AUTO(TestLargeAppend); + TESTCASE_AUTO_END; + } + +@@ -2310,3 +2311,64 @@ void UnicodeStringTest::TestUnicodeStringInsertAppendToSelf() { + str.insert(2, sub); + assertEquals("", u"abbcdcde", str); + } ++ ++void UnicodeStringTest::TestLargeAppend() { ++ if(quick) return; ++ ++ IcuTestErrorCode status(*this, "TestLargeAppend"); ++ // Make a large UnicodeString ++ int32_t len = 0xAFFFFFF; ++ UnicodeString str; ++ char16_t *buf = str.getBuffer(len); ++ // A fast way to set buffer to valid Unicode. ++ // 4E4E is a valid unicode character ++ uprv_memset(buf, 0x4e, len * 2); ++ str.releaseBuffer(len); ++ UnicodeString dest; ++ // Append it 16 times ++ // 0xAFFFFFF times 16 is 0xA4FFFFF1, ++ // which is greater than INT32_MAX, which is 0x7FFFFFFF. ++ int64_t total = 0; ++ for (int32_t i = 0; i < 16; i++) { ++ dest.append(str); ++ total += len; ++ if (total <= INT32_MAX) { ++ assertFalse("dest is not bogus", dest.isBogus()); ++ } else { ++ assertTrue("dest should be bogus", dest.isBogus()); ++ } ++ } ++ dest.remove(); ++ total = 0; ++ for (int32_t i = 0; i < 16; i++) { ++ dest.append(str); ++ total += len; ++ if (total + len <= INT32_MAX) { ++ assertFalse("dest is not bogus", dest.isBogus()); ++ } else if (total <= INT32_MAX) { ++ // Check that a string of exactly the maximum size works ++ UnicodeString str2; ++ int32_t remain = INT32_MAX - total; ++ char16_t *buf2 = str2.getBuffer(remain); ++ if (buf2 == nullptr) { ++ // if somehow memory allocation fail, return the test ++ return; ++ } ++ uprv_memset(buf2, 0x4e, remain * 2); ++ str2.releaseBuffer(remain); ++ dest.append(str2); ++ total += remain; ++ assertEquals("When a string of exactly the maximum size works", (int64_t)INT32_MAX, total); ++ assertEquals("When a string of exactly the maximum size works", INT32_MAX, dest.length()); ++ assertFalse("dest is not bogus", dest.isBogus()); ++ ++ // Check that a string size+1 goes bogus ++ str2.truncate(1); ++ dest.append(str2); ++ total++; ++ assertTrue("dest should be bogus", dest.isBogus()); ++ } else { ++ assertTrue("dest should be bogus", dest.isBogus()); ++ } ++ } ++} +diff --git a/icu4c/source/test/intltest/ustrtest.h b/icu4c/source/test/intltest/ustrtest.h +index 218befdcc68..4a356a92c7a 100644 +--- a/icu4c/source/test/intltest/ustrtest.h ++++ b/icu4c/source/test/intltest/ustrtest.h +@@ -97,6 +97,7 @@ class UnicodeStringTest: public IntlTest { + void TestWCharPointers(); + void TestNullPointers(); + void TestUnicodeStringInsertAppendToSelf(); ++ void TestLargeAppend(); + }; + + #endif diff --git a/meta/recipes-support/icu/icu_65.1.bb b/meta/recipes-support/icu/icu_65.1.bb index bd932d7db4..2512916780 100644 --- a/meta/recipes-support/icu/icu_65.1.bb +++ b/meta/recipes-support/icu/icu_65.1.bb @@ -23,6 +23,7 @@ SRC_URI = "${BASE_SRC_URI} \ file://fix-install-manx.patch \ file://0001-Fix-big-endian-build.patch \ file://0001-icu-Added-armeb-support.patch \ + file://CVE-2020-10531.patch;striplevel=3 \ " SRC_URI_append_class-target = "\ -- 2.25.1 From anuj.mittal at intel.com Fri Mar 20 01:56:19 2020 From: anuj.mittal at intel.com (Anuj Mittal) Date: Fri, 20 Mar 2020 09:56:19 +0800 Subject: [OE-core] [zeus][PATCH 1/2] icu: fix CVE-2020-10531 Message-ID: <20200320015620.125128-1-anuj.mittal@intel.com> Signed-off-by: Anuj Mittal --- .../icu/icu/CVE-2020-10531.patch | 122 ++++++++++++++++++ meta/recipes-support/icu/icu_64.2.bb | 1 + 2 files changed, 123 insertions(+) create mode 100644 meta/recipes-support/icu/icu/CVE-2020-10531.patch diff --git a/meta/recipes-support/icu/icu/CVE-2020-10531.patch b/meta/recipes-support/icu/icu/CVE-2020-10531.patch new file mode 100644 index 0000000000..56303fc0f2 --- /dev/null +++ b/meta/recipes-support/icu/icu/CVE-2020-10531.patch @@ -0,0 +1,122 @@ +From b7d08bc04a4296982fcef8b6b8a354a9e4e7afca Mon Sep 17 00:00:00 2001 +From: Frank Tang +Date: Sat, 1 Feb 2020 02:39:04 +0000 +Subject: [PATCH] ICU-20958 Prevent SEGV_MAPERR in append + +See #971 + +Upstream-Status: Backport [https://github.com/unicode-org/icu/commit/b7d08bc04a4296982fcef8b6b8a354a9e4e7afca] +CVE: CVE-2020-10531 +Signed-off-by: Anuj Mittal +--- + icu4c/source/common/unistr.cpp | 6 ++- + icu4c/source/test/intltest/ustrtest.cpp | 62 +++++++++++++++++++++++++ + icu4c/source/test/intltest/ustrtest.h | 1 + + 3 files changed, 68 insertions(+), 1 deletion(-) + +diff --git a/icu4c/source/common/unistr.cpp b/icu4c/source/common/unistr.cpp +index 901bb3358ba..077b4d6ef20 100644 +--- a/icu4c/source/common/unistr.cpp ++++ b/icu4c/source/common/unistr.cpp +@@ -1563,7 +1563,11 @@ UnicodeString::doAppend(const UChar *srcChars, int32_t srcStart, int32_t srcLeng + } + + int32_t oldLength = length(); +- int32_t newLength = oldLength + srcLength; ++ int32_t newLength; ++ if (uprv_add32_overflow(oldLength, srcLength, &newLength)) { ++ setToBogus(); ++ return *this; ++ } + + // Check for append onto ourself + const UChar* oldArray = getArrayStart(); +diff --git a/icu4c/source/test/intltest/ustrtest.cpp b/icu4c/source/test/intltest/ustrtest.cpp +index b6515ea813c..ad38bdf53a3 100644 +--- a/icu4c/source/test/intltest/ustrtest.cpp ++++ b/icu4c/source/test/intltest/ustrtest.cpp +@@ -67,6 +67,7 @@ void UnicodeStringTest::runIndexedTest( int32_t index, UBool exec, const char* & + TESTCASE_AUTO(TestWCharPointers); + TESTCASE_AUTO(TestNullPointers); + TESTCASE_AUTO(TestUnicodeStringInsertAppendToSelf); ++ TESTCASE_AUTO(TestLargeAppend); + TESTCASE_AUTO_END; + } + +@@ -2310,3 +2311,64 @@ void UnicodeStringTest::TestUnicodeStringInsertAppendToSelf() { + str.insert(2, sub); + assertEquals("", u"abbcdcde", str); + } ++ ++void UnicodeStringTest::TestLargeAppend() { ++ if(quick) return; ++ ++ IcuTestErrorCode status(*this, "TestLargeAppend"); ++ // Make a large UnicodeString ++ int32_t len = 0xAFFFFFF; ++ UnicodeString str; ++ char16_t *buf = str.getBuffer(len); ++ // A fast way to set buffer to valid Unicode. ++ // 4E4E is a valid unicode character ++ uprv_memset(buf, 0x4e, len * 2); ++ str.releaseBuffer(len); ++ UnicodeString dest; ++ // Append it 16 times ++ // 0xAFFFFFF times 16 is 0xA4FFFFF1, ++ // which is greater than INT32_MAX, which is 0x7FFFFFFF. ++ int64_t total = 0; ++ for (int32_t i = 0; i < 16; i++) { ++ dest.append(str); ++ total += len; ++ if (total <= INT32_MAX) { ++ assertFalse("dest is not bogus", dest.isBogus()); ++ } else { ++ assertTrue("dest should be bogus", dest.isBogus()); ++ } ++ } ++ dest.remove(); ++ total = 0; ++ for (int32_t i = 0; i < 16; i++) { ++ dest.append(str); ++ total += len; ++ if (total + len <= INT32_MAX) { ++ assertFalse("dest is not bogus", dest.isBogus()); ++ } else if (total <= INT32_MAX) { ++ // Check that a string of exactly the maximum size works ++ UnicodeString str2; ++ int32_t remain = INT32_MAX - total; ++ char16_t *buf2 = str2.getBuffer(remain); ++ if (buf2 == nullptr) { ++ // if somehow memory allocation fail, return the test ++ return; ++ } ++ uprv_memset(buf2, 0x4e, remain * 2); ++ str2.releaseBuffer(remain); ++ dest.append(str2); ++ total += remain; ++ assertEquals("When a string of exactly the maximum size works", (int64_t)INT32_MAX, total); ++ assertEquals("When a string of exactly the maximum size works", INT32_MAX, dest.length()); ++ assertFalse("dest is not bogus", dest.isBogus()); ++ ++ // Check that a string size+1 goes bogus ++ str2.truncate(1); ++ dest.append(str2); ++ total++; ++ assertTrue("dest should be bogus", dest.isBogus()); ++ } else { ++ assertTrue("dest should be bogus", dest.isBogus()); ++ } ++ } ++} +diff --git a/icu4c/source/test/intltest/ustrtest.h b/icu4c/source/test/intltest/ustrtest.h +index 218befdcc68..4a356a92c7a 100644 +--- a/icu4c/source/test/intltest/ustrtest.h ++++ b/icu4c/source/test/intltest/ustrtest.h +@@ -97,6 +97,7 @@ class UnicodeStringTest: public IntlTest { + void TestWCharPointers(); + void TestNullPointers(); + void TestUnicodeStringInsertAppendToSelf(); ++ void TestLargeAppend(); + }; + + #endif diff --git a/meta/recipes-support/icu/icu_64.2.bb b/meta/recipes-support/icu/icu_64.2.bb index 10bac7aac0..2ed807787d 100644 --- a/meta/recipes-support/icu/icu_64.2.bb +++ b/meta/recipes-support/icu/icu_64.2.bb @@ -18,6 +18,7 @@ SRC_URI = "${BASE_SRC_URI} \ file://fix-install-manx.patch \ file://0001-Fix-big-endian-build.patch \ file://0001-icu-Added-armeb-support.patch \ + file://CVE-2020-10531.patch;striplevel=3 \ " SRC_URI_append_class-target = "\ -- 2.25.1 From anuj.mittal at intel.com Fri Mar 20 01:56:20 2020 From: anuj.mittal at intel.com (Anuj Mittal) Date: Fri, 20 Mar 2020 09:56:20 +0800 Subject: [OE-core] [zeus][PATCH 2/2] screen: fix CVE-2020-9366 In-Reply-To: <20200320015620.125128-1-anuj.mittal@intel.com> References: <20200320015620.125128-1-anuj.mittal@intel.com> Message-ID: <20200320015620.125128-2-anuj.mittal@intel.com> Signed-off-by: Anuj Mittal --- .../screen/screen/CVE-2020-9366.patch | 48 +++++++++++++++++++ meta/recipes-extended/screen/screen_4.6.2.bb | 1 + 2 files changed, 49 insertions(+) create mode 100644 meta/recipes-extended/screen/screen/CVE-2020-9366.patch diff --git a/meta/recipes-extended/screen/screen/CVE-2020-9366.patch b/meta/recipes-extended/screen/screen/CVE-2020-9366.patch new file mode 100644 index 0000000000..a52b9e6e68 --- /dev/null +++ b/meta/recipes-extended/screen/screen/CVE-2020-9366.patch @@ -0,0 +1,48 @@ +From 8ce90c1d3d5bece150479d8bc9303fd9d9f45e03 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Amadeusz=20S=C5=82awi=C5=84ski?= +Date: Thu, 30 Jan 2020 17:56:27 +0100 +Subject: [PATCH] Fix out of bounds access when setting w_xtermosc after OSC 49 +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: =?UTF-8?q?Amadeusz=20S=C5=82awi=C5=84ski?= +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +echo -e "\e]49\e; \n\ec" +crashes screen. + +This happens because 49 is divided by 10 and used as table index +resulting in access to w_xtermosc[4], which is out of bounds with table +itself being size 4. Increase size of table by 1 to 5, which is enough +for all current uses. + +As this overwrites memory based on user input it is potential security +issue. + +Reported-by: pippin at gimp.org +Signed-off-by: Amadeusz S?awi?ski + +Upstream-Status: Backport [https://git.savannah.gnu.org/cgit/screen.git/commit/?h=v.4.8.0&id=68386dfb1fa33471372a8cd2e74686758a2f527b] +CVE: CVE-2020-9366 +Signed-off-by: Anuj Mittal + +--- + window.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/window.h b/window.h +index bd10dcd..a8afa19 100644 +--- a/window.h ++++ b/window.h +@@ -237,7 +237,7 @@ struct win + char w_vbwait; + char w_norefresh; /* dont redisplay when switching to that win */ + #ifdef RXVT_OSC +- char w_xtermosc[4][MAXSTR]; /* special xterm/rxvt escapes */ ++ char w_xtermosc[5][MAXSTR]; /* special xterm/rxvt escapes */ + #endif + int w_mouse; /* mouse mode 0,9,1000 */ + #ifdef HAVE_BRAILLE diff --git a/meta/recipes-extended/screen/screen_4.6.2.bb b/meta/recipes-extended/screen/screen_4.6.2.bb index 21b476ddb0..d00b849021 100644 --- a/meta/recipes-extended/screen/screen_4.6.2.bb +++ b/meta/recipes-extended/screen/screen_4.6.2.bb @@ -25,6 +25,7 @@ SRC_URI = "${GNU_MIRROR}/screen/screen-${PV}.tar.gz \ file://0001-fix-for-multijob-build.patch \ file://0001-configure.ac-fix-configure-failed-while-build-dir-ha.patch \ file://0001-Remove-more-compatibility-stuff.patch \ + file://CVE-2020-9366.patch \ " SRC_URI[md5sum] = "a0f529d3333b128dfaa324d978ba73a8" -- 2.25.1 From chee.yang.lee at intel.com Fri Mar 20 08:06:42 2020 From: chee.yang.lee at intel.com (chee.yang.lee at intel.com) Date: Fri, 20 Mar 2020 16:06:42 +0800 Subject: [OE-core] [PATCH][zeus] virglrenderer : fix CVE-2019-18388 Message-ID: <1584691602-12741-1-git-send-email-chee.yang.lee@intel.com> From: Chee Yang Lee Signed-off-by: Chee Yang Lee --- .../virglrenderer/CVE-2019-18388.patch | 141 +++++++++++++++++++++ .../virglrenderer/virglrenderer_0.8.0.bb | 3 +- 2 files changed, 143 insertions(+), 1 deletion(-) create mode 100644 meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2019-18388.patch diff --git a/meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2019-18388.patch b/meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2019-18388.patch new file mode 100644 index 0000000..43563e4 --- /dev/null +++ b/meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2019-18388.patch @@ -0,0 +1,141 @@ +From 0d9a2c88dc3a70023541b3260b9f00c982abda16 Mon Sep 17 00:00:00 2001 +From: Gert Wollny +Date: Thu, 10 Oct 2019 09:42:25 +0200 +Subject: [PATCH] vrend: Check resource creation more thoroughly + +While we are at it: + - free memory if texture allocation fails + +Closes #144 +Closes #145 +Closes #146 + +v2: Move the error string creation to extra patch (Emil) +v3: Fix whitespace errors (Emil) and one logic error + +Signed-off-by: Gert Wollny +Reviewed-by: Emil Velikov + +Upstream-Status: Backport [https://gitlab.freedesktop.org/virgl/virglrenderer/commit/0d9a2c88dc3a70023541b3260b9f00c982abda16] +CVE: CVE-2019-18388 +Signed-off-by: Lee Chee Yang + + +--- + src/vrend_renderer.c | 58 ++++++++++++++++++++++++++++++++++++++++++-- + 1 file changed, 56 insertions(+), 2 deletions(-) + +diff --git a/src/vrend_renderer.c b/src/vrend_renderer.c +index 0c6b5efd..1fb657b7 100644 +--- a/src/vrend_renderer.c ++++ b/src/vrend_renderer.c +@@ -6044,6 +6044,8 @@ static int check_resource_valid(struct vrend_renderer_resource_create_args *args + + if (args->format >= VIRGL_FORMAT_MAX) + return -1; ++ bool format_can_texture_storage = has_feature(feat_texture_storage) && ++ (tex_conv_table[args->format].flags & VIRGL_TEXTURE_CAN_TEXTURE_STORAGE); + + /* only texture 2d and 2d array can have multiple samples */ + if (args->nr_samples > 0) { +@@ -6061,15 +6063,18 @@ static int check_resource_valid(struct vrend_renderer_resource_create_args *args + /* buffer and rect textures can't have mipmaps */ + if (args->target == PIPE_BUFFER || args->target == PIPE_TEXTURE_RECT) + return -1; ++ + if (args->last_level > (floor(log2(MAX2(args->width, args->height))) + 1)) + return -1; + } ++ + if (args->flags != 0 && args->flags != VIRGL_RESOURCE_Y_0_TOP) + return -1; + +- if (args->flags & VIRGL_RESOURCE_Y_0_TOP) ++ if (args->flags & VIRGL_RESOURCE_Y_0_TOP) { + if (args->target != PIPE_TEXTURE_2D && args->target != PIPE_TEXTURE_RECT) + return -1; ++ } + + /* array size for array textures only */ + if (args->target == PIPE_TEXTURE_CUBE) { +@@ -6088,6 +6093,9 @@ static int check_resource_valid(struct vrend_renderer_resource_create_args *args + if (!has_feature(feat_texture_array)) + return -1; + } ++ if (format_can_texture_storage && !args->width) { ++ return -1; ++ } + + if (args->bind == 0 || + args->bind == VIRGL_BIND_CUSTOM || +@@ -6124,11 +6132,55 @@ static int check_resource_valid(struct vrend_renderer_resource_create_args *args + args->target == PIPE_TEXTURE_CUBE_ARRAY) { + if (args->depth != 1) + return -1; ++ if (format_can_texture_storage && !args->height) { ++ return -1; ++ } + } + if (args->target == PIPE_TEXTURE_1D || + args->target == PIPE_TEXTURE_1D_ARRAY) { + if (args->height != 1 || args->depth != 1) + return -1; ++ if (args->width > vrend_state.max_texture_2d_size) { ++ return -1; ++ } ++ } ++ ++ if (args->target == PIPE_TEXTURE_2D || ++ args->target == PIPE_TEXTURE_RECT || ++ args->target == PIPE_TEXTURE_2D_ARRAY) { ++ if (args->width > vrend_state.max_texture_2d_size || ++ args->height > vrend_state.max_texture_2d_size) { ++ return -1; ++ } ++ } ++ ++ if (args->target == PIPE_TEXTURE_3D) { ++ if (format_can_texture_storage && ++ (!args->height || !args->depth)) { ++ return -1; ++ } ++ if (args->width > vrend_state.max_texture_3d_size || ++ args->height > vrend_state.max_texture_3d_size || ++ args->depth > vrend_state.max_texture_3d_size) { ++ return -1; ++ } ++ } ++ if (args->target == PIPE_TEXTURE_2D_ARRAY || ++ args->target == PIPE_TEXTURE_CUBE_ARRAY || ++ args->target == PIPE_TEXTURE_1D_ARRAY) { ++ if (format_can_texture_storage && ++ !args->array_size) { ++ return -1; ++ } ++ } ++ if (args->target == PIPE_TEXTURE_CUBE || ++ args->target == PIPE_TEXTURE_CUBE_ARRAY) { ++ if (args->width != args->height) { ++ return -1; ++ } ++ if (args->width > vrend_state.max_texture_cube_size) { ++ return -1; ++ } + } + } + return 0; +@@ -6458,8 +6510,10 @@ int vrend_renderer_resource_create(struct vrend_renderer_resource_create_args *a + vrend_create_buffer(gr, args->width); + } else { + int r = vrend_renderer_resource_allocate_texture(gr, image_oes); +- if (r) ++ if (r) { ++ FREE(gr); + return r; ++ } + } + + ret = vrend_resource_insert(gr, args->handle); +-- +2.24.1 + diff --git a/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.0.bb b/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.0.bb index e91ccc6..0480d90 100644 --- a/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.0.bb +++ b/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.0.bb @@ -11,7 +11,8 @@ SRC_URI = "git://anongit.freedesktop.org/virglrenderer \ file://CVE-2019-18390.patch \ file://CVE-2019-18391.patch \ file://CVE-2020-8002.patch \ - " + file://CVE-2019-18388.patch \ +" S = "${WORKDIR}/git" -- 2.7.4 From rpjday at crashcourse.ca Fri Mar 20 11:04:05 2020 From: rpjday at crashcourse.ca (Robert P. J. Day) Date: Fri, 20 Mar 2020 07:04:05 -0400 (EDT) Subject: [OE-core] recipe design curiosity: how to best install a package configuration file? Message-ID: got into a discussion yesterday about the "cleanest" way to design a .bbappend file to install a package's configuration file, so i'm curious about best practices, and here's an example. (and i'm asking as it looks like this will be an issue for a number of recipes i'm looking at.) current recipe for conntrack-tools: http://cgit.openembedded.org/meta-openembedded/tree/meta-networking/recipes-filter/conntrack-tools/conntrack-tools_1.4.5.bb note how the recipe install step installs a conntrack.conf.sample file: do_install_append() { install -d ${D}/${sysconfdir}/conntrackd install -d ${D}/${sysconfdir}/init.d install -m 0644 ${S}/doc/sync/ftfw/conntrackd.conf ${D}/${sysconfdir}/conntrackd/conntrackd.conf.sample ... so far, so good. now, in cases where a sample conf file is provided, there is, of course, no guarantee that it will be applicable out of the box -- one *expects* that it might be necessary to tweak such a file and install it as part of a .bbappend file. and here's the point of contention. in this current situation, it turns out that that sample conf file just happens to be appropriate, so the entire .bbappend file for this recipe consists of: do_install_append () { install -m 0644 \ ${D}/${sysconfdir}/conntrackd/conntrackd.conf.sample \ ${D}/${sysconfdir}/conntrackd/conntrackd.conf } yes, that will work, but i suggested that, even though it's convenient, the problem with that approach is that looking at the .bbappend file doesn't show you the contents of the file that will be installed. to see the actual conf file, you'd have to peruse the source, or check the final result ... you get the idea. i suggested that, even though the sample file in *this* case was perfectly appropriate, i would choose to make a copy of it under files/, and install the conf file from *there*, the advantage being that the actual file being installed is immediately readable. does anyone have any strong opinions on this? it seems mundane, but i think the latter approach is still superior, especially since i suspect most sample configuration files would have to be adjusted, anyway. thoughts? just trying to collect some best practices to apply to this project. rday From ankur.tyagi85 at gmail.com Fri Mar 20 11:15:40 2020 From: ankur.tyagi85 at gmail.com (Ankur Tyagi) Date: Sat, 21 Mar 2020 00:15:40 +1300 Subject: [OE-core] recipe design curiosity: how to best install a package configuration file? In-Reply-To: References: Message-ID: what if sample file is updated in new version? Now you have to maintain the copy in your "file/" as well. If you are using sample file as it is, then keeping a copy is probably not a good idea Cheers Ankur On Sat, Mar 21, 2020, 12:04 AM Robert P. J. Day wrote: > > got into a discussion yesterday about the "cleanest" way to design a > .bbappend file to install a package's configuration file, so i'm > curious about best practices, and here's an example. (and i'm asking > as it looks like this will be an issue for a number of recipes i'm > looking at.) > > current recipe for conntrack-tools: > > > http://cgit.openembedded.org/meta-openembedded/tree/meta-networking/recipes-filter/conntrack-tools/conntrack-tools_1.4.5.bb > > note how the recipe install step installs a conntrack.conf.sample > file: > > do_install_append() { > install -d ${D}/${sysconfdir}/conntrackd > install -d ${D}/${sysconfdir}/init.d > install -m 0644 ${S}/doc/sync/ftfw/conntrackd.conf > ${D}/${sysconfdir}/conntrackd/conntrackd.conf.sample > ... > > so far, so good. now, in cases where a sample conf file is provided, > there is, of course, no guarantee that it will be applicable out of > the box -- one *expects* that it might be necessary to tweak such a > file and install it as part of a .bbappend file. and here's the point > of contention. > > in this current situation, it turns out that that sample conf file > just happens to be appropriate, so the entire .bbappend file for this > recipe consists of: > > do_install_append () { > install -m 0644 \ > ${D}/${sysconfdir}/conntrackd/conntrackd.conf.sample \ > ${D}/${sysconfdir}/conntrackd/conntrackd.conf > } > > yes, that will work, but i suggested that, even though it's > convenient, the problem with that approach is that looking at the > .bbappend file doesn't show you the contents of the file that will be > installed. to see the actual conf file, you'd have to peruse the > source, or check the final result ... you get the idea. > > i suggested that, even though the sample file in *this* case was > perfectly appropriate, i would choose to make a copy of it under > files/, and install the conf file from *there*, the advantage being > that the actual file being installed is immediately readable. > > does anyone have any strong opinions on this? it seems mundane, but > i think the latter approach is still superior, especially since i > suspect most sample configuration files would have to be adjusted, > anyway. > > thoughts? just trying to collect some best practices to apply to > this project. > > rday > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core at lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chee.yang.lee at intel.com Fri Mar 20 11:21:27 2020 From: chee.yang.lee at intel.com (Lee, Chee Yang) Date: Fri, 20 Mar 2020 11:21:27 +0000 Subject: [OE-core] [PATCH][zeus] virglrenderer : fix CVE-2019-18388 In-Reply-To: <1584691602-12741-1-git-send-email-chee.yang.lee@intel.com> References: <1584691602-12741-1-git-send-email-chee.yang.lee@intel.com> Message-ID: Please ignore this patch, it is causing compilation error. -----Original Message----- From: openembedded-core-bounces at lists.openembedded.org On Behalf Of chee.yang.lee at intel.com Sent: Friday, March 20, 2020 4:07 PM To: openembedded-core at lists.openembedded.org Subject: [OE-core] [PATCH][zeus] virglrenderer : fix CVE-2019-18388 From: Chee Yang Lee Signed-off-by: Chee Yang Lee --- .../virglrenderer/CVE-2019-18388.patch | 141 +++++++++++++++++++++ .../virglrenderer/virglrenderer_0.8.0.bb | 3 +- 2 files changed, 143 insertions(+), 1 deletion(-) create mode 100644 meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2019-18388.patch diff --git a/meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2019-18388.patch b/meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2019-18388.patch new file mode 100644 index 0000000..43563e4 --- /dev/null +++ b/meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2019-18388.p +++ atch @@ -0,0 +1,141 @@ +From 0d9a2c88dc3a70023541b3260b9f00c982abda16 Mon Sep 17 00:00:00 2001 +From: Gert Wollny +Date: Thu, 10 Oct 2019 09:42:25 +0200 +Subject: [PATCH] vrend: Check resource creation more thoroughly + +While we are at it: + - free memory if texture allocation fails + +Closes #144 +Closes #145 +Closes #146 + +v2: Move the error string creation to extra patch (Emil) +v3: Fix whitespace errors (Emil) and one logic error + +Signed-off-by: Gert Wollny +Reviewed-by: Emil Velikov + +Upstream-Status: Backport +[https://gitlab.freedesktop.org/virgl/virglrenderer/commit/0d9a2c88dc3a +70023541b3260b9f00c982abda16] +CVE: CVE-2019-18388 +Signed-off-by: Lee Chee Yang + + +--- + src/vrend_renderer.c | 58 ++++++++++++++++++++++++++++++++++++++++++-- + 1 file changed, 56 insertions(+), 2 deletions(-) + +diff --git a/src/vrend_renderer.c b/src/vrend_renderer.c index +0c6b5efd..1fb657b7 100644 +--- a/src/vrend_renderer.c ++++ b/src/vrend_renderer.c +@@ -6044,6 +6044,8 @@ static int check_resource_valid(struct +vrend_renderer_resource_create_args *args + + if (args->format >= VIRGL_FORMAT_MAX) + return -1; ++ bool format_can_texture_storage = has_feature(feat_texture_storage) && ++ (tex_conv_table[args->format].flags & ++ VIRGL_TEXTURE_CAN_TEXTURE_STORAGE); + + /* only texture 2d and 2d array can have multiple samples */ + if (args->nr_samples > 0) { +@@ -6061,15 +6063,18 @@ static int check_resource_valid(struct vrend_renderer_resource_create_args *args + /* buffer and rect textures can't have mipmaps */ + if (args->target == PIPE_BUFFER || args->target == PIPE_TEXTURE_RECT) + return -1; ++ + if (args->last_level > (floor(log2(MAX2(args->width, args->height))) + 1)) + return -1; + } ++ + if (args->flags != 0 && args->flags != VIRGL_RESOURCE_Y_0_TOP) + return -1; + +- if (args->flags & VIRGL_RESOURCE_Y_0_TOP) ++ if (args->flags & VIRGL_RESOURCE_Y_0_TOP) { + if (args->target != PIPE_TEXTURE_2D && args->target != PIPE_TEXTURE_RECT) + return -1; ++ } + + /* array size for array textures only */ + if (args->target == PIPE_TEXTURE_CUBE) { @@ -6088,6 +6093,9 @@ +static int check_resource_valid(struct vrend_renderer_resource_create_args *args + if (!has_feature(feat_texture_array)) + return -1; + } ++ if (format_can_texture_storage && !args->width) { ++ return -1; ++ } + + if (args->bind == 0 || + args->bind == VIRGL_BIND_CUSTOM || @@ -6124,11 +6132,55 @@ +static int check_resource_valid(struct vrend_renderer_resource_create_args *args + args->target == PIPE_TEXTURE_CUBE_ARRAY) { + if (args->depth != 1) + return -1; ++ if (format_can_texture_storage && !args->height) { ++ return -1; ++ } + } + if (args->target == PIPE_TEXTURE_1D || + args->target == PIPE_TEXTURE_1D_ARRAY) { + if (args->height != 1 || args->depth != 1) + return -1; ++ if (args->width > vrend_state.max_texture_2d_size) { ++ return -1; ++ } ++ } ++ ++ if (args->target == PIPE_TEXTURE_2D || ++ args->target == PIPE_TEXTURE_RECT || ++ args->target == PIPE_TEXTURE_2D_ARRAY) { ++ if (args->width > vrend_state.max_texture_2d_size || ++ args->height > vrend_state.max_texture_2d_size) { ++ return -1; ++ } ++ } ++ ++ if (args->target == PIPE_TEXTURE_3D) { ++ if (format_can_texture_storage && ++ (!args->height || !args->depth)) { ++ return -1; ++ } ++ if (args->width > vrend_state.max_texture_3d_size || ++ args->height > vrend_state.max_texture_3d_size || ++ args->depth > vrend_state.max_texture_3d_size) { ++ return -1; ++ } ++ } ++ if (args->target == PIPE_TEXTURE_2D_ARRAY || ++ args->target == PIPE_TEXTURE_CUBE_ARRAY || ++ args->target == PIPE_TEXTURE_1D_ARRAY) { ++ if (format_can_texture_storage && ++ !args->array_size) { ++ return -1; ++ } ++ } ++ if (args->target == PIPE_TEXTURE_CUBE || ++ args->target == PIPE_TEXTURE_CUBE_ARRAY) { ++ if (args->width != args->height) { ++ return -1; ++ } ++ if (args->width > vrend_state.max_texture_cube_size) { ++ return -1; ++ } + } + } + return 0; +@@ -6458,8 +6510,10 @@ int vrend_renderer_resource_create(struct vrend_renderer_resource_create_args *a + vrend_create_buffer(gr, args->width); + } else { + int r = vrend_renderer_resource_allocate_texture(gr, image_oes); +- if (r) ++ if (r) { ++ FREE(gr); + return r; ++ } + } + + ret = vrend_resource_insert(gr, args->handle); +-- +2.24.1 + diff --git a/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.0.bb b/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.0.bb index e91ccc6..0480d90 100644 --- a/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.0.bb +++ b/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.0.bb @@ -11,7 +11,8 @@ SRC_URI = "git://anongit.freedesktop.org/virglrenderer \ file://CVE-2019-18390.patch \ file://CVE-2019-18391.patch \ file://CVE-2020-8002.patch \ - " + file://CVE-2019-18388.patch \ " S = "${WORKDIR}/git" -- 2.7.4 -- _______________________________________________ Openembedded-core mailing list Openembedded-core at lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core From bunk at stusta.de Fri Mar 20 11:28:07 2020 From: bunk at stusta.de (Adrian Bunk) Date: Fri, 20 Mar 2020 13:28:07 +0200 Subject: [OE-core] recipe design curiosity: how to best install a package configuration file? In-Reply-To: References: Message-ID: <20200320112807.GB31090@localhost> On Fri, Mar 20, 2020 at 07:04:05AM -0400, Robert P. J. Day wrote: >... > in this current situation, it turns out that that sample conf file > just happens to be appropriate, >... I'd guess you are wrong on that. IPv4_interface 192.168.100.100 Interface eth2 > rday cu Adrian From rpjday at crashcourse.ca Fri Mar 20 11:32:24 2020 From: rpjday at crashcourse.ca (Robert P. J. Day) Date: Fri, 20 Mar 2020 07:32:24 -0400 (EDT) Subject: [OE-core] recipe design curiosity: how to best install a package configuration file? In-Reply-To: References: Message-ID: On Sat, 21 Mar 2020, Ankur Tyagi wrote: > what if sample file is updated in new version? Now you have to > maintain the copy in your "file/" as well. > > If you are using sample file as it is, then keeping a copy is > probably not a good idea > > Cheers > Ankur i actually think that's an argument in my favour ... i would be very nervous about how upgrading a recipe version would quietly upgrade my configuration file. i would far prefer to have to manually upgrade my configuration to keep in step. rday > ? got into a discussion yesterday about the "cleanest" way to design a > .bbappend file to install a package's configuration file, so i'm > curious about best practices, and here's an example. (and i'm asking > as it looks like this will be an issue for a number of recipes i'm > looking at.) > > ? current recipe for conntrack-tools: > > http://cgit.openembedded.org/meta-openembedded/tree/meta-networking/recipes-filter/conntrack-tools/conntrack-tools_1.4.5.bb > > note how the recipe install step installs a conntrack.conf.sample > file: > > do_install_append() { > ? install -d ${D}/${sysconfdir}/conntrackd > ? install -d ${D}/${sysconfdir}/init.d > ? install -m 0644 ${S}/doc/sync/ftfw/conntrackd.conf ${D}/${sysconfdir}/conntrackd/conntrackd.conf.sample > ? ... > > so far, so good. now, in cases where a sample conf file is provided, > there is, of course, no guarantee that it will be applicable out of > the box -- one *expects* that it might be necessary to tweak such a > file and install it as part of a .bbappend file. and here's the point > of contention. > > ? in this current situation, it turns out that that sample conf file > just happens to be appropriate, so the entire .bbappend file for this > recipe consists of: > > do_install_append () { > ? ? install -m 0644? \ > ? ? ${D}/${sysconfdir}/conntrackd/conntrackd.conf.sample \ > ? ? ${D}/${sysconfdir}/conntrackd/conntrackd.conf > } > > ? yes, that will work, but i suggested that, even though it's > convenient, the problem with that approach is that looking at the > .bbappend file doesn't show you the contents of the file that will be > installed. to see the actual conf file, you'd have to peruse the > source, or check the final result ... you get the idea. > > ? i suggested that, even though the sample file in *this* case was > perfectly appropriate, i would choose to make a copy of it under > files/, and install the conf file from *there*, the advantage being > that the actual file being installed is immediately readable. > > ? does anyone have any strong opinions on this? it seems mundane, but > i think the latter approach is still superior, especially since i > suspect most sample configuration files would have to be adjusted, > anyway. > > ? thoughts? just trying to collect some best practices to apply to > this project. > > rday > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core at lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core > > > -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ======================================================================== From ankur.tyagi85 at gmail.com Fri Mar 20 11:47:26 2020 From: ankur.tyagi85 at gmail.com (Ankur Tyagi) Date: Sat, 21 Mar 2020 00:47:26 +1300 Subject: [OE-core] recipe design curiosity: how to best install a package configuration file? In-Reply-To: References: Message-ID: new recipe version (most likely) will have new release and expect any change If you are concerned about recipe version in your layer then manage that rather than copying original recipe file *as it is* in your layer When upgrading recipe, anyway have to test it to make sure your image doesn't break. So no way you will miss any breaking change introduced. And at that point you could have (if needed) your custom version in "file/" rather than always copying the working sample which is already maintained by someone else I wouldn't recommend to have copy of unchanged upstream files in a custom layer Cheers Ankur On Sat, Mar 21, 2020, 12:32 AM Robert P. J. Day wrote: > On Sat, 21 Mar 2020, Ankur Tyagi wrote: > > > what if sample file is updated in new version? Now you have to > > maintain the copy in your "file/" as well. > > > > If you are using sample file as it is, then keeping a copy is > > probably not a good idea > > > > Cheers > > Ankur > > i actually think that's an argument in my favour ... i would be very > nervous about how upgrading a recipe version would quietly upgrade my > configuration file. i would far prefer to have to manually upgrade my > configuration to keep in step. > > rday > > > got into a discussion yesterday about the "cleanest" way to > design a > > .bbappend file to install a package's configuration file, so i'm > > curious about best practices, and here's an example. (and i'm > asking > > as it looks like this will be an issue for a number of recipes i'm > > looking at.) > > > > current recipe for conntrack-tools: > > > > > http://cgit.openembedded.org/meta-openembedded/tree/meta-networking/recipes-filter/conntrack-tools/conntrack-tools_1.4.5.bb > > > > note how the recipe install step installs a conntrack.conf.sample > > file: > > > > do_install_append() { > > install -d ${D}/${sysconfdir}/conntrackd > > install -d ${D}/${sysconfdir}/init.d > > install -m 0644 ${S}/doc/sync/ftfw/conntrackd.conf > ${D}/${sysconfdir}/conntrackd/conntrackd.conf.sample > > ... > > > > so far, so good. now, in cases where a sample conf file is > provided, > > there is, of course, no guarantee that it will be applicable out of > > the box -- one *expects* that it might be necessary to tweak such a > > file and install it as part of a .bbappend file. and here's the > point > > of contention. > > > > in this current situation, it turns out that that sample conf > file > > just happens to be appropriate, so the entire .bbappend file for > this > > recipe consists of: > > > > do_install_append () { > > install -m 0644 \ > > ${D}/${sysconfdir}/conntrackd/conntrackd.conf.sample \ > > ${D}/${sysconfdir}/conntrackd/conntrackd.conf > > } > > > > yes, that will work, but i suggested that, even though it's > > convenient, the problem with that approach is that looking at the > > .bbappend file doesn't show you the contents of the file that will > be > > installed. to see the actual conf file, you'd have to peruse the > > source, or check the final result ... you get the idea. > > > > i suggested that, even though the sample file in *this* case was > > perfectly appropriate, i would choose to make a copy of it under > > files/, and install the conf file from *there*, the advantage being > > that the actual file being installed is immediately readable. > > > > does anyone have any strong opinions on this? it seems mundane, > but > > i think the latter approach is still superior, especially since i > > suspect most sample configuration files would have to be adjusted, > > anyway. > > > > thoughts? just trying to collect some best practices to apply to > > this project. > > > > rday > > -- > > _______________________________________________ > > Openembedded-core mailing list > > Openembedded-core at lists.openembedded.org > > http://lists.openembedded.org/mailman/listinfo/openembedded-core > > > > > > > > -- > > ======================================================================== > Robert P. J. Day Ottawa, Ontario, CANADA > http://crashcourse.ca > > Twitter: http://twitter.com/rpjday > LinkedIn: http://ca.linkedin.com/in/rpjday > ======================================================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From rpjday at crashcourse.ca Fri Mar 20 11:57:32 2020 From: rpjday at crashcourse.ca (Robert P. J. Day) Date: Fri, 20 Mar 2020 07:57:32 -0400 (EDT) Subject: [OE-core] recipe design curiosity: how to best install a package configuration file? In-Reply-To: <20200320112807.GB31090@localhost> References: <20200320112807.GB31090@localhost> Message-ID: On Fri, 20 Mar 2020, Adrian Bunk wrote: > On Fri, Mar 20, 2020 at 07:04:05AM -0400, Robert P. J. Day wrote: > >... > > in this current situation, it turns out that that sample conf file > > just happens to be appropriate, > >... > > I'd guess you are wrong on that. > > IPv4_interface 192.168.100.100 > Interface eth2 ah, i was just going on the recipe append file as it was, which simply copied that sample file. now i'm even more curious as to what's going on in the background, as i did not create that append file. rday From quentin.schulz at streamunlimited.com Fri Mar 20 12:12:16 2020 From: quentin.schulz at streamunlimited.com (Quentin Schulz) Date: Fri, 20 Mar 2020 13:12:16 +0100 Subject: [OE-core] recipe design curiosity: how to best install a package configuration file? In-Reply-To: References: Message-ID: <20200320121216.23l62svwmpxquur5@qschulz> Hi Robert, On Fri, Mar 20, 2020 at 07:04:05AM -0400, Robert P. J. Day wrote: > > got into a discussion yesterday about the "cleanest" way to design a > .bbappend file to install a package's configuration file, so i'm > curious about best practices, and here's an example. (and i'm asking > as it looks like this will be an issue for a number of recipes i'm > looking at.) > > current recipe for conntrack-tools: > > http://cgit.openembedded.org/meta-openembedded/tree/meta-networking/recipes-filter/conntrack-tools/conntrack-tools_1.4.5.bb > > note how the recipe install step installs a conntrack.conf.sample > file: > > do_install_append() { > install -d ${D}/${sysconfdir}/conntrackd > install -d ${D}/${sysconfdir}/init.d > install -m 0644 ${S}/doc/sync/ftfw/conntrackd.conf ${D}/${sysconfdir}/conntrackd/conntrackd.conf.sample > ... > > so far, so good. now, in cases where a sample conf file is provided, > there is, of course, no guarantee that it will be applicable out of > the box -- one *expects* that it might be necessary to tweak such a > file and install it as part of a .bbappend file. and here's the point > of contention. > > in this current situation, it turns out that that sample conf file > just happens to be appropriate, so the entire .bbappend file for this > recipe consists of: > > do_install_append () { > install -m 0644 \ > ${D}/${sysconfdir}/conntrackd/conntrackd.conf.sample \ > ${D}/${sysconfdir}/conntrackd/conntrackd.conf > } > > yes, that will work, but i suggested that, even though it's > convenient, the problem with that approach is that looking at the > .bbappend file doesn't show you the contents of the file that will be > installed. to see the actual conf file, you'd have to peruse the > source, or check the final result ... you get the idea. > > i suggested that, even though the sample file in *this* case was > perfectly appropriate, i would choose to make a copy of it under > files/, and install the conf file from *there*, the advantage being > that the actual file being installed is immediately readable. > Have a look at how wpa-supplicant is doing it. It has two config files. wpa-supplicant.conf which is going straight to the docs directory on the rootfs and wpa-supplicant.conf-sane which is the one used by wpa-supplicant at runtime. So when you want to override the default wpa-supplicant.conf, you override wpa-supplicant.conf-sane in a bbappend. I don't know if it's the proper way, but that's one and particularly in poky which is usually done with best practices in mind. Quentin From brgl at bgdev.pl Fri Mar 20 13:11:53 2020 From: brgl at bgdev.pl (Bartosz Golaszewski) Date: Fri, 20 Mar 2020 14:11:53 +0100 Subject: [OE-core] [RFC PATCH 0/2] image.bbclass: support two-stage deployment of image artifacts In-Reply-To: References: <20200319164403.29605-1-brgl@bgdev.pl> <21fcbda1e8b274ba75534159179ca9535c618d68.camel@linuxfoundation.org> Message-ID: pt., 20 mar 2020 o 00:38 Richard Purdie napisa?(a): > > On Thu, 2020-03-19 at 19:20 +0100, Bartosz Golaszewski wrote: > > If we'll really get to a point where we need to create a hierarchy of > > multiple levels of image deployment, then maybe we should switch to > > deploying each image right after it is created in its dedicated > > do_image_ task, then we could really fine-tune the inter-task > > dependencies. But we're not there yet and IMO currently it would be > > overkill. The rule of thumb for me is not to add new interfaces > > nobody asks for. > > Going back in time I'm the person who split the image pieces off from > do_rootfs and split the different image commands into different tasks. > I did this for several reasons but one was we were developing new task > dependency code inside the image construction which was just crazy. > > I was wondering about the option of having the image task deploy the > image earlier. I think that could be made to work. I think conceptually > it makes more sense architecturally than adding in arbitrary new task > levels to the existing structure. > > > This also makes your argument about adding a third category purely > > theoretical: I don't see how we would need another category of images > > anytime soon. > > I often think things like that but then new use cases come along... > > > Please do - I'm open for other ideas. Just please keep in mind: > > there's obviously a problem with the current approach. I described it > > in detail and it turned out Quentin had encountered it too and dealt > > with it using a nasty workaround (fitImage deployed by the image > > recipe and not the kernel). I'd like to fix it upstream and proposed > > a solution that is IMO not horrible. I'd appreciate if we could reach > > a compromise that wouldn't leave us with downstream hacks. > > I do understand there is a problem. We also have problems with people > not understanding the code as it works today. Your proposal adds > something else with is hard to explain to users ("Is my image simple or > composed?") and whilst we can and do add complexity where we need to, > I'm not yet convinced this change makes enough sense to have it. > > Changing the way image deployment works would in many ways be much > easier for people to understand and makes the system more flexible > without adding problematic terminology. > > > Please also note that sometimes "gets the job done" really is better > > than not solving problems. Just look at initcall levels in the linux > > kernel - they are similar to what I proposed here and serve as a > > surrogate for real dependencies. > > We have piles of "get the job done" and also need to sometimes take a > step back and see if we can do something better. Right now I think your > proposal makes things worse and will be hard to explain to people. My > instinct is we can do better here. > Fair enough. I don't quite agree and I'd like to hear other voices too but I also don't want to waste time arguing either. As I'm afraid that if I don't follow up on this myself, it will simply be forgotten, I'm offering to spend some time figuring out per-task deployment. I started looking into it and figured that ideally we could have each image task use a separate local-deploy directory and make them all part of SSTATETASKS. Unfortunately a lot of places reference the IMGDEPLOYDIR variable so it probably has to stay in some form. I couldn't find any info on that - does bitbake offer anything like "per-task variables"? Variables that expand to different values depending on the task that calls them? Otherwise we could replace IMGDEPLOYDIR calls with some helper function that would return a different value depending on BB_CURRENTTASK? Any advice on technicalities is welcome. Bart From mike.looijmans at topic.nl Fri Mar 20 14:45:20 2020 From: mike.looijmans at topic.nl (Mike Looijmans) Date: Fri, 20 Mar 2020 15:45:20 +0100 Subject: [OE-core] [PATCH v2] classes/populate_sdk_base: Implement xz compression options Message-ID: <20200320144520.16732-1-mike.looijmans@topic.nl> Building an SDK on a machine with 8GB RAM resulted in excessive swapping due to the xz compressor using ~20GB of memory. This is because xz is being called with "-T 0 -9". To allow tuning the compression versus memory usage, introduce a variable named SDK_XZ_OPTIONS that defaults to a more sane default: SDK_XZ_OPTIONS ?= "${XZ_DEFAULTS} ${SDK_XZ_COMPRESSION_LEVEL}" The use of XZ_DEFAULTS fixes the excessive memory usage. The SDK_XZ_COMPRESSION_LEVEL variable allows overriding the speed vs compression. In an office or development environment the extra time spent on compressing a few percent more is just not worth it. Signed-off-by: Mike Looijmans --- meta/classes/populate_sdk_base.bbclass | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/meta/classes/populate_sdk_base.bbclass b/meta/classes/populate_sdk_base.bbclass index d03465b6fc..179ed93979 100644 --- a/meta/classes/populate_sdk_base.bbclass +++ b/meta/classes/populate_sdk_base.bbclass @@ -48,6 +48,8 @@ TOOLCHAIN_OUTPUTNAME ?= "${SDK_NAME}-toolchain-${SDK_VERSION}" # Default archived SDK's suffix SDK_ARCHIVE_TYPE ?= "tar.xz" +SDK_XZ_COMPRESSION_LEVEL ?= "-9" +SDK_XZ_OPTIONS ?= "${XZ_DEFAULTS} ${SDK_XZ_COMPRESSION_LEVEL}" # To support different sdk type according to SDK_ARCHIVE_TYPE, now support zip and tar.xz python () { @@ -58,7 +60,7 @@ python () { d.setVar('SDK_ARCHIVE_CMD', 'cd ${SDK_OUTPUT}/${SDKPATH}; zip -r ${SDKDEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.${SDK_ARCHIVE_TYPE} .') else: d.setVar('SDK_ARCHIVE_DEPENDS', 'xz-native') - d.setVar('SDK_ARCHIVE_CMD', 'cd ${SDK_OUTPUT}/${SDKPATH}; tar ${SDKTAROPTS} -cf - . | xz -T 0 -9 > ${SDKDEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.${SDK_ARCHIVE_TYPE}') + d.setVar('SDK_ARCHIVE_CMD', 'cd ${SDK_OUTPUT}/${SDKPATH}; tar ${SDKTAROPTS} -cf - . | xz ${SDK_XZ_OPTIONS} > ${SDKDEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.${SDK_ARCHIVE_TYPE}') } SDK_RDEPENDS = "${TOOLCHAIN_TARGET_TASK} ${TOOLCHAIN_HOST_TASK}" -- 2.17.1 From mike.looijmans at topic.nl Fri Mar 20 14:48:00 2020 From: mike.looijmans at topic.nl (Mike Looijmans) Date: Fri, 20 Mar 2020 15:48:00 +0100 Subject: [OE-core] [PATCH] classes/populate_sdk_base: Implement xz compression options In-Reply-To: <20200319113736.GA28081@localhost> References: <20200318122156.23599-1-mike.looijmans@topic.nl> <20200319113736.GA28081@localhost> Message-ID: On 19-03-2020 12:37, Adrian Bunk wrote: > On Wed, Mar 18, 2020 at 01:21:56PM +0100, Mike Looijmans wrote: >> Building an SDK on a machine with 8GB RAM resulted in excessive swapping >> due to the xz compressor using ~20GB of memory. This is because xz is >> being called with "-T 0 -9". >> >> To allow tuning the compression versus memory usage, introduce a variable >> named SDK_XZ_OPTIONS that defaults to a more sane default: >> SDK_XZ_OPTIONS ?= "${XZ_DEFAULTS} ${XZ_COMPRESSION_LEVEL}" >> Thus, inherit any XZ tuning already done, and allow users to specify >> overrides for this task in their config by supplying SDK_XZ_OPTIONS. >> Since XZ_COMPRESSION_LEVEL defaults to -9 this does not change the standard >> behavior. >> ... >> +SDK_XZ_OPTIONS ?= "${XZ_DEFAULTS} ${XZ_COMPRESSION_LEVEL}" > > A problem is that XZ_COMPRESSION_LEVEL compression would now be used for > unrelated usecases, and lowering the compression for being able to boot > on low-end targets (<= 64 MB RAM) shouldn't impact the SDK. Clear. I wasn't aware that this was for the targets... > >> ... >> - d.setVar('SDK_ARCHIVE_CMD', 'cd ${SDK_OUTPUT}/${SDKPATH}; tar ${SDKTAROPTS} -cf - . | xz -T 0 -9 > ${SDKDEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.${SDK_ARCHIVE_TYPE}') >> + d.setVar('SDK_ARCHIVE_CMD', 'cd ${SDK_OUTPUT}/${SDKPATH}; tar ${SDKTAROPTS} -cf - . | xz ${SDK_XZ_OPTIONS} > ${SDKDEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.${SDK_ARCHIVE_TYPE}') >> ... > > Replacing "-T 0" with ${XZ_DEFAULTS} should solve your problem. > This already takes both cpus and memory into account. I'd still want to have control over that -9 though. It's not worth it to spend 15 minutes compressing just a few megabytes better in a development environment. -- Mike Looijmans From bunk at stusta.de Fri Mar 20 17:23:53 2020 From: bunk at stusta.de (Adrian Bunk) Date: Fri, 20 Mar 2020 19:23:53 +0200 Subject: [OE-core] [zeus][PATCH 1/2] e2fsprogs: fix CVE-2019-5188 Message-ID: <20200320172354.9777-1-bunk@stusta.de> From: Anuj Mittal Also see: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948508 (From OE-Core rev: 09bdcef183d885025da6aa87a7c2bf7e8268774e) Signed-off-by: Anuj Mittal Signed-off-by: Richard Purdie Signed-off-by: Adrian Bunk --- ...-t-try-to-rehash-a-deleted-directory.patch | 49 ++++++++++++++++ .../e2fsprogs/e2fsprogs/CVE-2019-5188.patch | 57 +++++++++++++++++++ .../e2fsprogs/e2fsprogs_1.45.3.bb | 2 + 3 files changed, 108 insertions(+) create mode 100644 meta/recipes-devtools/e2fsprogs/e2fsprogs/0001-e2fsck-don-t-try-to-rehash-a-deleted-directory.patch create mode 100644 meta/recipes-devtools/e2fsprogs/e2fsprogs/CVE-2019-5188.patch diff --git a/meta/recipes-devtools/e2fsprogs/e2fsprogs/0001-e2fsck-don-t-try-to-rehash-a-deleted-directory.patch b/meta/recipes-devtools/e2fsprogs/e2fsprogs/0001-e2fsck-don-t-try-to-rehash-a-deleted-directory.patch new file mode 100644 index 0000000000..ba4e3a3c97 --- /dev/null +++ b/meta/recipes-devtools/e2fsprogs/e2fsprogs/0001-e2fsck-don-t-try-to-rehash-a-deleted-directory.patch @@ -0,0 +1,49 @@ +From 71ba13755337e19c9a826dfc874562a36e1b24d3 Mon Sep 17 00:00:00 2001 +From: Theodore Ts'o +Date: Thu, 19 Dec 2019 19:45:06 -0500 +Subject: [PATCH] e2fsck: don't try to rehash a deleted directory + +If directory has been deleted in pass1[bcd] processing, then we +shouldn't try to rehash the directory in pass 3a when we try to +rehash/reoptimize directories. + +Signed-off-by: Theodore Ts'o + +Upstream-Status: Backport [https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/?id=71ba13755337e19c9a826dfc874562a36e1b24d3] +Signed-off-by: Anuj Mittal +--- + e2fsck/pass1b.c | 4 ++++ + e2fsck/rehash.c | 2 ++ + 2 files changed, 6 insertions(+) + +diff --git a/e2fsck/pass1b.c b/e2fsck/pass1b.c +index 5693b9cf..bca701ca 100644 +--- a/e2fsck/pass1b.c ++++ b/e2fsck/pass1b.c +@@ -705,6 +705,10 @@ static void delete_file(e2fsck_t ctx, ext2_ino_t ino, + fix_problem(ctx, PR_1B_BLOCK_ITERATE, &pctx); + if (ctx->inode_bad_map) + ext2fs_unmark_inode_bitmap2(ctx->inode_bad_map, ino); ++ if (ctx->inode_reg_map) ++ ext2fs_unmark_inode_bitmap2(ctx->inode_reg_map, ino); ++ ext2fs_unmark_inode_bitmap2(ctx->inode_dir_map, ino); ++ ext2fs_unmark_inode_bitmap2(ctx->inode_used_map, ino); + ext2fs_inode_alloc_stats2(fs, ino, -1, LINUX_S_ISDIR(dp->inode.i_mode)); + quota_data_sub(ctx->qctx, &dp->inode, ino, + pb.dup_blocks * fs->blocksize); +diff --git a/e2fsck/rehash.c b/e2fsck/rehash.c +index 3dd1e941..2c908be0 100644 +--- a/e2fsck/rehash.c ++++ b/e2fsck/rehash.c +@@ -1028,6 +1028,8 @@ void e2fsck_rehash_directories(e2fsck_t ctx) + if (!ext2fs_u32_list_iterate(iter, &ino)) + break; + } ++ if (!ext2fs_test_inode_bitmap2(ctx->inode_dir_map, ino)) ++ continue; + + pctx.dir = ino; + if (first) { +-- +2.24.1 + diff --git a/meta/recipes-devtools/e2fsprogs/e2fsprogs/CVE-2019-5188.patch b/meta/recipes-devtools/e2fsprogs/e2fsprogs/CVE-2019-5188.patch new file mode 100644 index 0000000000..de4bce0037 --- /dev/null +++ b/meta/recipes-devtools/e2fsprogs/e2fsprogs/CVE-2019-5188.patch @@ -0,0 +1,57 @@ +From 8dd73c149f418238f19791f9d666089ef9734dff Mon Sep 17 00:00:00 2001 +From: Theodore Ts'o +Date: Thu, 19 Dec 2019 19:37:34 -0500 +Subject: [PATCH] e2fsck: abort if there is a corrupted directory block when + rehashing + +In e2fsck pass 3a, when we are rehashing directories, at least in +theory, all of the directories should have had corruptions with +respect to directory entry structure fixed. However, it's possible +(for example, if the user declined a fix) that we can reach this stage +of processing with a corrupted directory entries. + +So check for that case and don't try to process a corrupted directory +block so we don't run into trouble in mutate_name() if there is a +zero-length file name. + +Addresses: TALOS-2019-0973 +Addresses: CVE-2019-5188 +Signed-off-by: Theodore Ts'o + +CVE: CVE-2019-5188 +Signed-off-by: Anuj Mittal +Upstream-Status: Backport [https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/?id=8dd73c149f418238f19791f9d666089ef9734dff] +--- + e2fsck/rehash.c | 9 +++++++++ + 1 file changed, 9 insertions(+) + +diff --git a/e2fsck/rehash.c b/e2fsck/rehash.c +index a5fc1be1..3dd1e941 100644 +--- a/e2fsck/rehash.c ++++ b/e2fsck/rehash.c +@@ -160,6 +160,10 @@ static int fill_dir_block(ext2_filsys fs, + dir_offset += rec_len; + if (dirent->inode == 0) + continue; ++ if ((name_len) == 0) { ++ fd->err = EXT2_ET_DIR_CORRUPTED; ++ return BLOCK_ABORT; ++ } + if (!fd->compress && (name_len == 1) && + (dirent->name[0] == '.')) + continue; +@@ -401,6 +405,11 @@ static int duplicate_search_and_fix(e2fsck_t ctx, ext2_filsys fs, + continue; + } + new_len = ext2fs_dirent_name_len(ent->dir); ++ if (new_len == 0) { ++ /* should never happen */ ++ ext2fs_unmark_valid(fs); ++ continue; ++ } + memcpy(new_name, ent->dir->name, new_len); + mutate_name(new_name, &new_len); + for (j=0; j < fd->num_array; j++) { +-- +2.24.1 + diff --git a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.45.3.bb b/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.45.3.bb index 14c05a446c..2014e68579 100644 --- a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.45.3.bb +++ b/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.45.3.bb @@ -6,6 +6,8 @@ SRC_URI += "file://remove.ldconfig.call.patch \ file://mkdir_p.patch \ file://0001-misc-create_inode.c-set-dir-s-mode-correctly.patch \ file://CVE-2019-5094.patch \ + file://CVE-2019-5188.patch \ + file://0001-e2fsck-don-t-try-to-rehash-a-deleted-directory.patch \ " SRC_URI_append_class-native = " file://e2fsprogs-fix-missing-check-for-permission-denied.patch \ -- 2.17.1 From bunk at stusta.de Fri Mar 20 17:23:54 2020 From: bunk at stusta.de (Adrian Bunk) Date: Fri, 20 Mar 2020 19:23:54 +0200 Subject: [OE-core] [zeus][PATCH 2/2] e2fsprogs: backport upstream patch In-Reply-To: <20200320172354.9777-1-bunk@stusta.de> References: <20200320172354.9777-1-bunk@stusta.de> Message-ID: <20200320172354.9777-2-bunk@stusta.de> From: Anuj Mittal Fixes a bug wherein a use after free could potentially be used to run malicious code if a user can be tricked into running e2fsck on a maliciously crafted file system. Also see: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948517 (From OE-Core rev: 23c1b157362609bd8d85c7d35e6c7f0f60c32c88) Signed-off-by: Anuj Mittal Signed-off-by: Richard Purdie Signed-off-by: Adrian Bunk --- ...fix-use-after-free-in-calculate_tree.patch | 76 +++++++++++++++++++ .../e2fsprogs/e2fsprogs_1.45.3.bb | 1 + 2 files changed, 77 insertions(+) create mode 100644 meta/recipes-devtools/e2fsprogs/e2fsprogs/e2fsck-fix-use-after-free-in-calculate_tree.patch diff --git a/meta/recipes-devtools/e2fsprogs/e2fsprogs/e2fsck-fix-use-after-free-in-calculate_tree.patch b/meta/recipes-devtools/e2fsprogs/e2fsprogs/e2fsck-fix-use-after-free-in-calculate_tree.patch new file mode 100644 index 0000000000..342a2b855b --- /dev/null +++ b/meta/recipes-devtools/e2fsprogs/e2fsprogs/e2fsck-fix-use-after-free-in-calculate_tree.patch @@ -0,0 +1,76 @@ +From: Wang Shilong +Date: Mon, 30 Dec 2019 19:52:39 -0500 +Subject: e2fsck: fix use after free in calculate_tree() + +The problem is alloc_blocks() will call get_next_block() which might +reallocate outdir->buf, and memory address could be changed after +this. To fix this, pointers that point into outdir->buf, such as +int_limit and root need to be recaulated based on the new starting +address of outdir->buf. + +[ Changed to correctly recalculate int_limit, and to optimize how we + reallocate outdir->buf. -TYT ] + +Addresses-Debian-Bug: 948517 +Signed-off-by: Wang Shilong +Signed-off-by: Theodore Ts'o +(cherry picked from commit 101e73e99ccafa0403fcb27dd7413033b587ca01) + +Signed-off-by: Anuj Mittal +Upstream-Status: Backport [https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/?id=101e73e99ccafa0403fcb27dd7413033b587ca01] +--- + e2fsck/rehash.c | 17 ++++++++++++++++- + 1 file changed, 16 insertions(+), 1 deletion(-) + +diff --git a/e2fsck/rehash.c b/e2fsck/rehash.c +index 0a5888a9..2574e151 100644 +--- a/e2fsck/rehash.c ++++ b/e2fsck/rehash.c +@@ -295,7 +295,11 @@ static errcode_t get_next_block(ext2_filsys fs, struct out_dir *outdir, + errcode_t retval; + + if (outdir->num >= outdir->max) { +- retval = alloc_size_dir(fs, outdir, outdir->max + 50); ++ int increment = outdir->max / 10; ++ ++ if (increment < 50) ++ increment = 50; ++ retval = alloc_size_dir(fs, outdir, outdir->max + increment); + if (retval) + return retval; + } +@@ -637,6 +641,9 @@ static int alloc_blocks(ext2_filsys fs, + if (retval) + return retval; + ++ /* outdir->buf might be reallocated */ ++ *prev_ent = (struct ext2_dx_entry *) (outdir->buf + *prev_offset); ++ + *next_ent = set_int_node(fs, block_start); + *limit = (struct ext2_dx_countlimit *)(*next_ent); + if (next_offset) +@@ -726,6 +733,9 @@ static errcode_t calculate_tree(ext2_filsys fs, + return retval; + } + if (c3 == 0) { ++ int delta1 = (char *)int_limit - outdir->buf; ++ int delta2 = (char *)root - outdir->buf; ++ + retval = alloc_blocks(fs, &limit, &int_ent, + &dx_ent, &int_offset, + NULL, outdir, i, &c2, +@@ -733,6 +743,11 @@ static errcode_t calculate_tree(ext2_filsys fs, + if (retval) + return retval; + ++ /* outdir->buf might be reallocated */ ++ int_limit = (struct ext2_dx_countlimit *) ++ (outdir->buf + delta1); ++ root = (struct ext2_dx_entry *) ++ (outdir->buf + delta2); + } + dx_ent->block = ext2fs_cpu_to_le32(i); + if (c3 != limit->limit) +-- +2.24.1 + diff --git a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.45.3.bb b/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.45.3.bb index 2014e68579..f81defb837 100644 --- a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.45.3.bb +++ b/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.45.3.bb @@ -8,6 +8,7 @@ SRC_URI += "file://remove.ldconfig.call.patch \ file://CVE-2019-5094.patch \ file://CVE-2019-5188.patch \ file://0001-e2fsck-don-t-try-to-rehash-a-deleted-directory.patch \ + file://e2fsck-fix-use-after-free-in-calculate_tree.patch \ " SRC_URI_append_class-native = " file://e2fsprogs-fix-missing-check-for-permission-denied.patch \ -- 2.17.1 From pkj at axis.com Fri Mar 20 18:03:12 2020 From: pkj at axis.com (Peter Kjellerstedt) Date: Fri, 20 Mar 2020 19:03:12 +0100 Subject: [OE-core] [PATCH] archiver.bbclass: Correct a typo Message-ID: <20200320180312.31459-1-pkj@axis.com> Also add a missing space in a warning message. Signed-off-by: Peter Kjellerstedt --- meta/classes/archiver.bbclass | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/classes/archiver.bbclass b/meta/classes/archiver.bbclass index 013195df7d..48b4913a9f 100644 --- a/meta/classes/archiver.bbclass +++ b/meta/classes/archiver.bbclass @@ -32,7 +32,7 @@ # directory suitable for direct use as a mirror. Duplicate sources are # ignored. # 12) Source mirror exclusions: -# ARCHIVE_MIRROR_EXCLUDE is a list of prefixes to exclude from the mirror. +# ARCHIVER_MIRROR_EXCLUDE is a list of prefixes to exclude from the mirror. # This may be used for sources which you are already publishing yourself # (e.g. if the URI starts with 'https://mysite.com/' and your mirror is # going to be published to the same site). It may also be used to exclude @@ -359,7 +359,7 @@ python do_ar_mirror() { break if len(ud.mirrortarballs) and not localpath: - bb.warn('Mirror tarballs are listed for a source but none are present.' \ + bb.warn('Mirror tarballs are listed for a source but none are present. ' \ 'Falling back to original download.\n' \ 'SRC_URI = %s' % (url)) -- 2.21.1 From pkj at axis.com Fri Mar 20 18:04:20 2020 From: pkj at axis.com (Peter Kjellerstedt) Date: Fri, 20 Mar 2020 19:04:20 +0100 Subject: [OE-core] [master][zeus][PATCH] relocatable.bbclass: Avoid an exception if an empty pkgconfig dir exist Message-ID: <20200320180420.32303-1-pkj@axis.com> Rewrite relocatable_native_pcfiles() so that it can handle that any of the checked pkgconfig directories are empty without causing an exception. Signed-off-by: Peter Kjellerstedt --- meta/classes/relocatable.bbclass | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git a/meta/classes/relocatable.bbclass b/meta/classes/relocatable.bbclass index 582812c1cf..af04be5cca 100644 --- a/meta/classes/relocatable.bbclass +++ b/meta/classes/relocatable.bbclass @@ -6,13 +6,15 @@ python relocatable_binaries_preprocess() { rpath_replace(d.expand('${SYSROOT_DESTDIR}'), d) } -relocatable_native_pcfiles () { - if [ -d ${SYSROOT_DESTDIR}${libdir}/pkgconfig ]; then - rel=${@os.path.relpath(d.getVar('base_prefix'), d.getVar('libdir') + "/pkgconfig")} - sed -i -e "s:${base_prefix}:\${pcfiledir}/$rel:g" ${SYSROOT_DESTDIR}${libdir}/pkgconfig/*.pc - fi - if [ -d ${SYSROOT_DESTDIR}${datadir}/pkgconfig ]; then - rel=${@os.path.relpath(d.getVar('base_prefix'), d.getVar('datadir') + "/pkgconfig")} - sed -i -e "s:${base_prefix}:\${pcfiledir}/$rel:g" ${SYSROOT_DESTDIR}${datadir}/pkgconfig/*.pc - fi +relocatable_native_pcfiles() { + for dir in ${libdir}/pkgconfig ${datadir}/pkgconfig; do + files_template=${SYSROOT_DESTDIR}$dir/*.pc + # Expand to any files matching $files_template + files=$(echo $files_template) + # $files_template and $files will differ if any files were found + if [ "$files_template" != "$files" ]; then + rel=$(realpath -m --relative-to=$dir ${base_prefix}) + sed -i -e "s:${base_prefix}:\${pcfiledir}/$rel:g" $files + fi + done } -- 2.21.1 From mhalstead at linuxfoundation.org Fri Mar 20 18:59:42 2020 From: mhalstead at linuxfoundation.org (Michael Halstead) Date: Fri, 20 Mar 2020 11:59:42 -0700 Subject: [OE-core] Mailing list platform change March 20th In-Reply-To: References: Message-ID: The migration will begin shortly. List mail will be delayed until the process is complete. E-mail sent during downtime should eventually be delivered. However waiting to send until after the switch is recommended. Thank you, -- Michael Halstead Linux Foundation / Yocto Project Systems Operations Engineer On Thu, Mar 19, 2020 at 9:44 AM Michael Halstead < mhalstead at linuxfoundation.org> wrote: > Everything is proceeding smoothly and this work will continue as planned. > The migration starts at noon PDT tomorrow. > > List owners please take care of all outstanding moderation in the next 24 > hours to ensure a smooth transition. > > Thank you, > -- > Michael Halstead > Linux Foundation / Yocto Project > Systems Operations Engineer > > On Fri, Mar 13, 2020 at 4:58 PM Michael Halstead < > mhalstead at linuxfoundation.org> wrote: > >> We are moving our lists from Mailman to Groups.io. E-mail to lists will >> be delayed during the move window. We are aiming to complete the migration >> during business hours in the Pacific time zone. >> >> A new account will be created for you on the Groups.io platform if you >> don't already have one. >> >> You can read more about the change on the wiki: >> https://www.openembedded.org/wiki/GroupsMigration >> >> If there are serious issues we will rollback the changes. We will e-mail >> all lists when work is complete. >> >> -- >> Michael Halstead >> Linux Foundation / Yocto Project >> Systems Operations Engineer >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: