[OE-core] [dunfell][PATCH] git: fix CVE-2021-21300

[Minjae Kim]

checkout: fix bug that makes checkout follow symlinks in leading path

Upstream-Status: Acepted 
[https://github.com/git/git/commit/684dd4c2b414bcf648505e74498a608f28de4592]
CVE: CVE-2021-21300
Signed-off-by: Minjae Kim 
---
 .../git/files/CVE-2021-21300.patch| 305 ++
 meta/recipes-devtools/git/git.inc |   4 +-
 2 files changed, 308 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-devtools/git/files/CVE-2021-21300.patch

diff --git a/meta/recipes-devtools/git/files/CVE-2021-21300.patch 
b/meta/recipes-devtools/git/files/CVE-2021-21300.patch
new file mode 100644
index 00..9206f711cf
--- /dev/null
+++ b/meta/recipes-devtools/git/files/CVE-2021-21300.patch
@@ -0,0 +1,305 @@
+From 0e9cef2414f0df3fa5b9b56ff9072aa122bef29c Mon Sep 17 00:00:00 2001
+From: Minjae Kim 
+Date: Sat, 27 Mar 2021 15:18:46 +0900
+Subject: [PATCH] checkout: fix bug that makes checkout follow symlinks in
+ leading path
+
+Before checking out a file, we have to confirm that all of its leading
+components are real existing directories. And to reduce the number of
+lstat() calls in this process, we cache the last leading path known to
+contain only directories. However, when a path collision occurs (e.g.
+when checking out case-sensitive files in case-insensitive file
+systems), a cached path might have its file type changed on disk,
+leaving the cache on an invalid state. Normally, this doesn't bring
+any bad consequences as we usually check out files in index order, and
+therefore, by the time the cached path becomes outdated, we no longer
+need it anyway (because all files in that directory would have already
+been written).
+
+But, there are some users of the checkout machinery that do not always
+follow the index order. In particular: checkout-index writes the paths
+in the same order that they appear on the CLI (or stdin); and the
+delayed checkout feature -- used when a long-running filter process
+replies with "status=delayed" -- postpones the checkout of some entries,
+thus modifying the checkout order.
+
+When we have to check out an out-of-order entry and the lstat() cache is
+invalid (due to a previous path collision), checkout_entry() may end up
+using the invalid data and thrusting that the leading components are
+real directories when, in reality, they are not. In the best case
+scenario, where the directory was replaced by a regular file, the user
+will get an error: "fatal: unable to create file 'foo/bar': Not a
+directory". But if the directory was replaced by a symlink, checkout
+could actually end up following the symlink and writing the file at a
+wrong place, even outside the repository. Since delayed checkout is
+affected by this bug, it could be used by an attacker to write
+arbitrary files during the clone of a maliciously crafted repository.
+
+Some candidate solutions considered were to disable the lstat() cache
+during unordered checkouts or sort the entries before passing them to
+the checkout machinery. But both ideas include some performance penalty
+and they don't future-proof the code against new unordered use cases.
+
+Instead, we now manually reset the lstat cache whenever we successfully
+remove a directory. Note: We are not even checking whether the directory
+was the same as the lstat cache points to because we might face a
+scenario where the paths refer to the same location but differ due to
+case folding, precomposed UTF-8 issues, or the presence of `..`
+components in the path. Two regression tests, with case-collisions and
+utf8-collisions, are also added for both checkout-index and delayed
+checkout.
+
+Note: to make the previously mentioned clone attack unfeasible, it would
+be sufficient to reset the lstat cache only after the remove_subtree()
+call inside checkout_entry(). This is the place where we would remove a
+directory whose path collides with the path of another entry that we are
+currently trying to check out (possibly a symlink). However, in the
+interest of a thorough fix that does not leave Git open to
+similar-but-not-identical attack vectors, we decided to intercept
+all `rmdir()` calls in one fell swoop.
+
+This addresses CVE-2021-21300.
+
+Co-authored-by: Johannes Schindelin 
+Signed-off-by: Matheus Tavares 
+
+Upstream-Status: Acepted 
[https://github.com/git/git/commit/684dd4c2b414bcf648505e74498a608f28de4592]
+CVE: CVE-2021-21300
+Signed-off-by: Minjae Kim 
+---
+ cache.h |  1 +
+ compat/mingw.c  |  2 ++
+ git-compat-util.h   |  5 +
+ symlinks.c  | 25 +
+ t/t0021-conversion.sh   | 39 
+ t/t0021/rot13-filter.pl | 21 ++---
+ t/t2006-checkout-index-basic.sh | 40 +
+ 7 files changed, 130 insertions(+), 3 deletions(-)
+
+diff --git a/cache.h b/cache.h
+index 04cabaa..dda373f 100644
+--- a/cache.h
 b/cache.h
+@@ -1675,6 +1675,7 @@ int 

[OE-core] [gatesgarth][PATCH] git: fix CVE-2021-21300

[Minjae Kim]

checkout: fix bug that makes checkout follow symlinks in leading path

Upstream-Status: Acepted 
[https://github.com/git/git/commit/684dd4c2b414bcf648505e74498a608f28de4592]
CVE: CVE-2021-21300
Signed-off-by: Minjae Kim 
---
 meta/recipes-devtools/git/git.inc |   4 +-
 .../git/git/CVE-2021-21300.patch  | 304 ++
 2 files changed, 307 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-devtools/git/git/CVE-2021-21300.patch

diff --git a/meta/recipes-devtools/git/git.inc 
b/meta/recipes-devtools/git/git.inc
index 586a305b27..3e78254eec 100644
--- a/meta/recipes-devtools/git/git.inc
+++ b/meta/recipes-devtools/git/git.inc
@@ -8,7 +8,9 @@ PROVIDES_append_class-native = " git-replacement-native"
 
 SRC_URI = "${KERNELORG_MIRROR}/software/scm/git/git-${PV}.tar.gz;name=tarball \

${KERNELORG_MIRROR}/software/scm/git/git-manpages-${PV}.tar.gz;name=manpages \
-   file://fixsort.patch"
+   file://fixsort.patch \
+  file://CVE-2021-21300.patch \
+"
 
 S = "${WORKDIR}/git-${PV}"
 
diff --git a/meta/recipes-devtools/git/git/CVE-2021-21300.patch 
b/meta/recipes-devtools/git/git/CVE-2021-21300.patch
new file mode 100644
index 00..390570fe78
--- /dev/null
+++ b/meta/recipes-devtools/git/git/CVE-2021-21300.patch
@@ -0,0 +1,304 @@
+From ba07d31bd2140190c4d8c197c9b8a503544b4c29 Mon Sep 17 00:00:00 2001
+From: Minjae Kim 
+Date: Sat, 27 Mar 2021 14:05:56 +0900
+Subject: [PATCH] checkout: fix bug that makes checkout follow symlinks in
+ leading path
+
+Before checking out a file, we have to confirm that all of its leading
+components are real existing directories. And to reduce the number of
+lstat() calls in this process, we cache the last leading path known to
+contain only directories. However, when a path collision occurs (e.g.
+when checking out case-sensitive files in case-insensitive file
+systems), a cached path might have its file type changed on disk,
+leaving the cache on an invalid state. Normally, this doesn't bring
+any bad consequences as we usually check out files in index order, and
+therefore, by the time the cached path becomes outdated, we no longer
+need it anyway (because all files in that directory would have already
+been written).
+
+But, there are some users of the checkout machinery that do not always
+follow the index order. In particular: checkout-index writes the paths
+in the same order that they appear on the CLI (or stdin); and the
+delayed checkout feature -- used when a long-running filter process
+replies with "status=delayed" -- postpones the checkout of some entries,
+thus modifying the checkout order.
+
+When we have to check out an out-of-order entry and the lstat() cache is
+invalid (due to a previous path collision), checkout_entry() may end up
+using the invalid data and thrusting that the leading components are
+real directories when, in reality, they are not. In the best case
+scenario, where the directory was replaced by a regular file, the user
+will get an error: "fatal: unable to create file 'foo/bar': Not a
+directory". But if the directory was replaced by a symlink, checkout
+could actually end up following the symlink and writing the file at a
+wrong place, even outside the repository. Since delayed checkout is
+affected by this bug, it could be used by an attacker to write
+arbitrary files during the clone of a maliciously crafted repository.
+
+Some candidate solutions considered were to disable the lstat() cache
+during unordered checkouts or sort the entries before passing them to
+the checkout machinery. But both ideas include some performance penalty
+and they don't future-proof the code against new unordered use cases.
+
+Instead, we now manually reset the lstat cache whenever we successfully
+remove a directory. Note: We are not even checking whether the directory
+was the same as the lstat cache points to because we might face a
+scenario where the paths refer to the same location but differ due to
+case folding, precomposed UTF-8 issues, or the presence of `..`
+components in the path. Two regression tests, with case-collisions and
+utf8-collisions, are also added for both checkout-index and delayed
+checkout.
+
+Note: to make the previously mentioned clone attack unfeasible, it would
+be sufficient to reset the lstat cache only after the remove_subtree()
+call inside checkout_entry(). This is the place where we would remove a
+directory whose path collides with the path of another entry that we are
+currently trying to check out (possibly a symlink). However, in the
+interest of a thorough fix that does not leave Git open to
+similar-but-not-identical attack vectors, we decided to intercept
+all `rmdir()` calls in one fell swoop.
+
+This addresses CVE-2021-21300.
+
+Co-authored-by: Johannes Schindelin 
+Signed-off-by: Matheus Tavares 
+
+Upstream-Status: Acepted 
[https://github.com/git/git/commit/684dd4c2b414bcf648505e74498a608f28de4592]
+CVE: CVE-2021-21300
+Signed-off-by

[OE-core] [PATCH] git: upgrade 2.30.1 -> 2.31.1

[Minjae Kim]

Includes a fix for CVE-2021-21300

Signed-off-by: Minjae Kim 
---
 meta/recipes-devtools/git/{git_2.30.1.bb => git_2.31.1.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-devtools/git/{git_2.30.1.bb => git_2.31.1.bb} (51%)

diff --git a/meta/recipes-devtools/git/git_2.30.1.bb 
b/meta/recipes-devtools/git/git_2.31.1.bb
similarity index 51%
rename from meta/recipes-devtools/git/git_2.30.1.bb
rename to meta/recipes-devtools/git/git_2.31.1.bb
index bc1635ada9..6bfa1f7a1e 100644
--- a/meta/recipes-devtools/git/git_2.30.1.bb
+++ b/meta/recipes-devtools/git/git_2.31.1.bb
@@ -5,5 +5,5 @@ EXTRA_OECONF += "ac_cv_snprintf_returns_bogus=no \
  "
 EXTRA_OEMAKE += "NO_GETTEXT=1"
 
-SRC_URI[tarball.sha256sum] = 
"23a3e53f0d2dd3e62a8147b24a1a91d6ffe95b92123ef4dbae04e9a6205e71c0"
-SRC_URI[manpages.sha256sum] = 
"db323e1b242e9d0337363b1e538c8b879e4c46eedbf94d3bee9e65dab6d49138"
+SRC_URI[tarball.sha256sum] = 
"46d37c229e9d786510e0c53b60065704ce92d5aedc16f2c5111e3ed35093bfa7"
+SRC_URI[manpages.sha256sum] = 
"d330498aaaea6928b0ab896f6f605efd8d35f23cbbb2de38c87a737d4543"
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150007): 
https://lists.openembedded.org/g/openembedded-core/message/150007
Mute This Topic: https://lists.openembedded.org/mt/81646287/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] make-mod-scripts: Provide the correct objcopy to kernel make

[Denys Dmytriyenko]

Hi, Bruce,

Would you mind taking a look at this? Have you seen any issues building latest 
kernel 5.12-rc for aarch64 and seeing host objcopy being used instead of cross 
compile one? Please let us know. Thanks!

-- 
Denys


On Thu, Mar 25, 2021 at 08:13:04PM -0500, Nishanth Menon wrote:
> When cross-compiling with v5.12-rc3, prepare fails[1] build of vdso at
> the objcopy stage since it seems to be using the local host's objcopy
> rather than the cross-compile version we want it to use.
> 
> This can be trivially reproduced in a localbuild of the kernel
> following the build parameters provided in the process[2]
> 
> Lets fix this by passing OBJCOPY over to the kernel.
> 
> [1] https://pastebin.ubuntu.com/p/pNcQtb93wr/
> [2] https://pastebin.ubuntu.com/p/vZGqgh9Sq5/
> Signed-off-by: Nishanth Menon 
> ---
> 
> NOTE:
> 1. This is a different problem and is not resolved with
> https://lists.openembedded.org/g/openembedded-core/message/149943
> 
> 2. Though reproduced during a dunfell build, this should probably
> apply else where as well.
> 
> 3. I have'nt been able to cleanly bisect things, but my best guess was
> that this might be a consequence of kernel fixup exposing this.
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a5b8ca97fbf8300a5e21c393df25ce6f521e7939
> 
>  meta/classes/kernel-arch.bbclass | 3 +++
>  meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb | 2 +-
>  2 files changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/classes/kernel-arch.bbclass 
> b/meta/classes/kernel-arch.bbclass
> index 07ec242e63bb..3d25fc7ac531 100644
> --- a/meta/classes/kernel-arch.bbclass
> +++ b/meta/classes/kernel-arch.bbclass
> @@ -60,9 +60,12 @@ TARGET_LD_KERNEL_ARCH ?= ""
>  HOST_LD_KERNEL_ARCH ?= "${TARGET_LD_KERNEL_ARCH}"
>  TARGET_AR_KERNEL_ARCH ?= ""
>  HOST_AR_KERNEL_ARCH ?= "${TARGET_AR_KERNEL_ARCH}"
> +TARGET_OBJCOPY_KERNEL_ARCH ?= ""
> +HOST_OBJCOPY_KERNEL_ARCH ?= "${TARGET_OBJCOPY_KERNEL_ARCH}"
>  
>  KERNEL_CC = "${CCACHE}${HOST_PREFIX}gcc ${HOST_CC_KERNEL_ARCH} -fuse-ld=bfd 
> ${DEBUG_PREFIX_MAP} 
> -fdebug-prefix-map=${STAGING_KERNEL_DIR}=${KERNEL_SRC_PATH}"
>  KERNEL_LD = "${CCACHE}${HOST_PREFIX}ld.bfd ${HOST_LD_KERNEL_ARCH}"
>  KERNEL_AR = "${CCACHE}${HOST_PREFIX}ar ${HOST_AR_KERNEL_ARCH}"
> +KERNEL_OBJCOPY = "${CCACHE}${HOST_PREFIX}objcopy ${HOST_OBJCOPY_KERNEL_ARCH}"
>  TOOLCHAIN = "gcc"
>  
> diff --git a/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb 
> b/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
> index 87b7d240f51a..2d73e8093c2e 100644
> --- a/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
> +++ b/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
> @@ -25,7 +25,7 @@ EXTRA_OEMAKE = " HOSTCC="${BUILD_CC} ${BUILD_CFLAGS} 
> ${BUILD_LDFLAGS}" HOSTCPP="
>  do_configure() {
>   unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
>   for t in prepare scripts_basic scripts; do
> - oe_runmake CC="${KERNEL_CC}" LD="${KERNEL_LD}" 
> AR="${KERNEL_AR}" \
> + oe_runmake CC="${KERNEL_CC}" LD="${KERNEL_LD}" 
> AR="${KERNEL_AR}" OBJCOPY="${KERNEL_OBJCOPY}"\
>   -C ${STAGING_KERNEL_DIR} O=${STAGING_KERNEL_BUILDDIR} $t
>   done
>  }
> -- 
> 2.31.0
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150006): 
https://lists.openembedded.org/g/openembedded-core/message/150006
Mute This Topic: https://lists.openembedded.org/mt/81618199/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] git: fix CVE-2021-21300

[Khem Raj]

Can we also upgrade git to 2.31.1 as a follow up ?

On Fri, Mar 26, 2021 at 8:13 PM Minjae Kim  wrote:
>
> checkout: fix bug that makes checkout follow symlinks in leading path
>
> Upstream-Status: Acepted 
> [https://github.com/git/git/commit/684dd4c2b414bcf648505e74498a608f28de4592]
> CVE: CVE-2021-21300
> Signed-off-by: Minjae Kim 
> ---
>  meta/recipes-devtools/git/git.inc |   4 +-
>  .../git/git/CVE-2021-21300.patch  | 304 ++
>  2 files changed, 307 insertions(+), 1 deletion(-)
>  create mode 100644 meta/recipes-devtools/git/git/CVE-2021-21300.patch
>
> diff --git a/meta/recipes-devtools/git/git.inc 
> b/meta/recipes-devtools/git/git.inc
> index 0cc40b9378..fb1dddc011 100644
> --- a/meta/recipes-devtools/git/git.inc
> +++ b/meta/recipes-devtools/git/git.inc
> @@ -9,7 +9,9 @@ PROVIDES_append_class-native = " git-replacement-native"
>
>  SRC_URI = 
> "${KERNELORG_MIRROR}/software/scm/git/git-${PV}.tar.gz;name=tarball \
> 
> ${KERNELORG_MIRROR}/software/scm/git/git-manpages-${PV}.tar.gz;name=manpages \
> -   file://fixsort.patch"
> +   file://fixsort.patch \
> +  file://CVE-2021-21300.patch \
> +"
>
>  S = "${WORKDIR}/git-${PV}"
>
> diff --git a/meta/recipes-devtools/git/git/CVE-2021-21300.patch 
> b/meta/recipes-devtools/git/git/CVE-2021-21300.patch
> new file mode 100644
> index 00..ec5d98395d
> --- /dev/null
> +++ b/meta/recipes-devtools/git/git/CVE-2021-21300.patch
> @@ -0,0 +1,304 @@
> +From 464431b4155e3ff918709de663aa0195d73c99fd Mon Sep 17 00:00:00 2001
> +From: Matheus Tavares 
> +Date: Sat, 27 Mar 2021 11:50:05 +0900
> +Subject: [PATCH] checkout: fix bug that makes checkout follow symlinks in
> + leading path
> +
> +Before checking out a file, we have to confirm that all of its leading
> +components are real existing directories. And to reduce the number of
> +lstat() calls in this process, we cache the last leading path known to
> +contain only directories. However, when a path collision occurs (e.g.
> +when checking out case-sensitive files in case-insensitive file
> +systems), a cached path might have its file type changed on disk,
> +leaving the cache on an invalid state. Normally, this doesn't bring
> +any bad consequences as we usually check out files in index order, and
> +therefore, by the time the cached path becomes outdated, we no longer
> +need it anyway (because all files in that directory would have already
> +been written).
> +
> +But, there are some users of the checkout machinery that do not always
> +follow the index order. In particular: checkout-index writes the paths
> +in the same order that they appear on the CLI (or stdin); and the
> +delayed checkout feature -- used when a long-running filter process
> +replies with "status=delayed" -- postpones the checkout of some entries,
> +thus modifying the checkout order.
> +
> +When we have to check out an out-of-order entry and the lstat() cache is
> +invalid (due to a previous path collision), checkout_entry() may end up
> +using the invalid data and thrusting that the leading components are
> +real directories when, in reality, they are not. In the best case
> +scenario, where the directory was replaced by a regular file, the user
> +will get an error: "fatal: unable to create file 'foo/bar': Not a
> +directory". But if the directory was replaced by a symlink, checkout
> +could actually end up following the symlink and writing the file at a
> +wrong place, even outside the repository. Since delayed checkout is
> +affected by this bug, it could be used by an attacker to write
> +arbitrary files during the clone of a maliciously crafted repository.
> +
> +Some candidate solutions considered were to disable the lstat() cache
> +during unordered checkouts or sort the entries before passing them to
> +the checkout machinery. But both ideas include some performance penalty
> +and they don't future-proof the code against new unordered use cases.
> +
> +Instead, we now manually reset the lstat cache whenever we successfully
> +remove a directory. Note: We are not even checking whether the directory
> +was the same as the lstat cache points to because we might face a
> +scenario where the paths refer to the same location but differ due to
> +case folding, precomposed UTF-8 issues, or the presence of `..`
> +components in the path. Two regression tests, with case-collisions and
> +utf8-collisions, are also added for both checkout-index and delayed
> +checkout.
> +
> +Note: to make the previously mentioned clone attack unfeasible, it would
> +be sufficient to reset the lstat cache only after the remove_subtree()
> +call inside checkout_entry(). This is the place where we would remove a
> +directory whose path collides with the path of another entry that we are
> +currently trying to check out (possibly a symlink). However, in the
> +interest of a thorough fix that does not leave Git open to
> +similar-but-not-identical attack vectors, we decided to inter

[OE-core] [PATCH] git: fix CVE-2021-21300

[Minjae Kim]

checkout: fix bug that makes checkout follow symlinks in leading path

Upstream-Status: Acepted 
[https://github.com/git/git/commit/684dd4c2b414bcf648505e74498a608f28de4592]
CVE: CVE-2021-21300
Signed-off-by: Minjae Kim 
---
 meta/recipes-devtools/git/git.inc |   4 +-
 .../git/git/CVE-2021-21300.patch  | 304 ++
 2 files changed, 307 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-devtools/git/git/CVE-2021-21300.patch

diff --git a/meta/recipes-devtools/git/git.inc 
b/meta/recipes-devtools/git/git.inc
index 0cc40b9378..fb1dddc011 100644
--- a/meta/recipes-devtools/git/git.inc
+++ b/meta/recipes-devtools/git/git.inc
@@ -9,7 +9,9 @@ PROVIDES_append_class-native = " git-replacement-native"
 
 SRC_URI = "${KERNELORG_MIRROR}/software/scm/git/git-${PV}.tar.gz;name=tarball \

${KERNELORG_MIRROR}/software/scm/git/git-manpages-${PV}.tar.gz;name=manpages \
-   file://fixsort.patch"
+   file://fixsort.patch \
+  file://CVE-2021-21300.patch \
+"
 
 S = "${WORKDIR}/git-${PV}"
 
diff --git a/meta/recipes-devtools/git/git/CVE-2021-21300.patch 
b/meta/recipes-devtools/git/git/CVE-2021-21300.patch
new file mode 100644
index 00..ec5d98395d
--- /dev/null
+++ b/meta/recipes-devtools/git/git/CVE-2021-21300.patch
@@ -0,0 +1,304 @@
+From 464431b4155e3ff918709de663aa0195d73c99fd Mon Sep 17 00:00:00 2001
+From: Matheus Tavares 
+Date: Sat, 27 Mar 2021 11:50:05 +0900
+Subject: [PATCH] checkout: fix bug that makes checkout follow symlinks in
+ leading path
+
+Before checking out a file, we have to confirm that all of its leading
+components are real existing directories. And to reduce the number of
+lstat() calls in this process, we cache the last leading path known to
+contain only directories. However, when a path collision occurs (e.g.
+when checking out case-sensitive files in case-insensitive file
+systems), a cached path might have its file type changed on disk,
+leaving the cache on an invalid state. Normally, this doesn't bring
+any bad consequences as we usually check out files in index order, and
+therefore, by the time the cached path becomes outdated, we no longer
+need it anyway (because all files in that directory would have already
+been written).
+
+But, there are some users of the checkout machinery that do not always
+follow the index order. In particular: checkout-index writes the paths
+in the same order that they appear on the CLI (or stdin); and the
+delayed checkout feature -- used when a long-running filter process
+replies with "status=delayed" -- postpones the checkout of some entries,
+thus modifying the checkout order.
+
+When we have to check out an out-of-order entry and the lstat() cache is
+invalid (due to a previous path collision), checkout_entry() may end up
+using the invalid data and thrusting that the leading components are
+real directories when, in reality, they are not. In the best case
+scenario, where the directory was replaced by a regular file, the user
+will get an error: "fatal: unable to create file 'foo/bar': Not a
+directory". But if the directory was replaced by a symlink, checkout
+could actually end up following the symlink and writing the file at a
+wrong place, even outside the repository. Since delayed checkout is
+affected by this bug, it could be used by an attacker to write
+arbitrary files during the clone of a maliciously crafted repository.
+
+Some candidate solutions considered were to disable the lstat() cache
+during unordered checkouts or sort the entries before passing them to
+the checkout machinery. But both ideas include some performance penalty
+and they don't future-proof the code against new unordered use cases.
+
+Instead, we now manually reset the lstat cache whenever we successfully
+remove a directory. Note: We are not even checking whether the directory
+was the same as the lstat cache points to because we might face a
+scenario where the paths refer to the same location but differ due to
+case folding, precomposed UTF-8 issues, or the presence of `..`
+components in the path. Two regression tests, with case-collisions and
+utf8-collisions, are also added for both checkout-index and delayed
+checkout.
+
+Note: to make the previously mentioned clone attack unfeasible, it would
+be sufficient to reset the lstat cache only after the remove_subtree()
+call inside checkout_entry(). This is the place where we would remove a
+directory whose path collides with the path of another entry that we are
+currently trying to check out (possibly a symlink). However, in the
+interest of a thorough fix that does not leave Git open to
+similar-but-not-identical attack vectors, we decided to intercept
+all `rmdir()` calls in one fell swoop.
+
+This addresses CVE-2021-21300.
+
+Co-authored-by: Johannes Schindelin 
+Signed-off-by: Matheus Tavares 
+
+Upstream-Status: Acepted 
[https://github.com/git/git/commit/684dd4c2b414bcf648505e74498a608f28de4592]
+CVE: CVE-2021-21300
+Signed-o

[OE-core] [PATCH] lib/oe/utils: ignore stderr while checking compiler version

[Lars Poeschel]

From: Lars Poeschel 

The functions for checking the C compiler version call the compiler with
the --version argument and capture stdout and stderr to extract the
version information from that. This does not work if something goes
wrong for the compiler and it then prints some warning to stderr. The
following regex will certainly fail in that case.
It is better to just concentrate on stdout where the real version is
printed to and ignore stderr. So we have a chance to get a version info
even if a waring or error happened.

Signed-off-by: Lars Poeschel 
---
 meta/lib/oe/utils.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/lib/oe/utils.py b/meta/lib/oe/utils.py
index 9a2187e36f..4c7f54c777 100644
--- a/meta/lib/oe/utils.py
+++ b/meta/lib/oe/utils.py
@@ -391,7 +391,7 @@ def get_host_compiler_version(d, taskcontextonly=False):
 # this breaks the install-buildtools use-case
 # env["PATH"] = d.getVar("PATH")
 output = subprocess.check_output("%s --version" % compiler, \
-shell=True, env=env, 
stderr=subprocess.STDOUT).decode("utf-8")
+shell=True, env=env).decode("utf-8")
 except subprocess.CalledProcessError as e:
 bb.fatal("Error running %s --version: %s" % (compiler, 
e.output.decode("utf-8")))
 
@@ -417,7 +417,7 @@ def host_gcc_version(d, taskcontextonly=False):
 env = os.environ.copy()
 env["PATH"] = d.getVar("PATH")
 output = subprocess.check_output("%s --version" % compiler, \
-shell=True, env=env, 
stderr=subprocess.STDOUT).decode("utf-8")
+shell=True, env=env).decode("utf-8")
 except subprocess.CalledProcessError as e:
 bb.fatal("Error running %s --version: %s" % (compiler, 
e.output.decode("utf-8")))
 
-- 
2.30.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150003): 
https://lists.openembedded.org/g/openembedded-core/message/150003
Mute This Topic: https://lists.openembedded.org/mt/81644274/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH][gatesgarth][dunfell] openssl: update to 1.1.1k to fix CVE-2021-3450 and CVE-2021-3449

[Mikko Rapeli]

On Fri, Mar 26, 2021 at 09:22:51AM -1000, Steve Sakoman wrote:
> On Fri, Mar 26, 2021 at 8:54 AM Khem Raj  wrote:
> >
> > do we need this on dunfell too?
> 
> I plan to take it when it hits master.

Thanks! As subject says, the patch applies to both gatesgarth and dunfell.

-Mikko
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150002): 
https://lists.openembedded.org/g/openembedded-core/message/150002
Mute This Topic: https://lists.openembedded.org/mt/81611322/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH v2 4/4] oe-selftest: Add U-Boot fitImage signing testcases

[Klaus Heinrich Kiwi]

Derived from the similar kernel fitImage sign testcase, the U-Boot
fitImage testcases exercises the following fitimage.FitImageTest
scenarios:

 * test_uboot_fit_image - create unsigned U-Boot fitImage
 * test_uboot_sign_fit_image - create unsigned U-Boot fitImage in
   addition to signed Kernel fitImage
 * test_sign_standalone_uboot_fit_image - Create signed U-Boot fitImage
   without a Kernel fitImage
 * test_sign_cascaded_uboot_fit_image - Create and sign U-Boot and
   Kernel fitImages

Signed-off-by: Klaus Heinrich Kiwi 
---
 meta/lib/oeqa/selftest/cases/fitimage.py | 468 +++
 1 file changed, 468 insertions(+)

diff --git a/meta/lib/oeqa/selftest/cases/fitimage.py 
b/meta/lib/oeqa/selftest/cases/fitimage.py
index 02692de822..b911fded74 100644
--- a/meta/lib/oeqa/selftest/cases/fitimage.py
+++ b/meta/lib/oeqa/selftest/cases/fitimage.py
@@ -231,6 +231,474 @@ UBOOT_MKIMAGE_SIGN_ARGS = "-c 'a smart comment'"
 result = runCmd('grep "### uboot-mkimage signing wrapper message" 
%s/log.do_assemble_fitimage' % tempdir, ignore_status=True)
 self.assertEqual(result.status, 0, 'UBOOT_MKIMAGE_SIGN did not work')
 
+def test_uboot_fit_image(self):
+"""
+Summary: Check if Uboot FIT image and Image Tree Source
+ (its) are built and the Image Tree Source has the
+ correct fields.
+Expected:1. u-boot-fitImage and u-boot-its can be built
+ 2. The type, load address, entrypoint address and
+ default values of U-boot image are correct in the
+ Image Tree Source. Not all the fields are tested,
+ only the key fields that wont vary between
+ different architectures.
+Product: oe-core
+Author:  Klaus Heinrich Kiwi 
+ based on work by Usama Arif 
+"""
+config = """
+# We need at least CONFIG_SPL_LOAD_FIT and CONFIG_SPL_OF_CONTROL set
+MACHINE = "qemuarm"
+UBOOT_MACHINE = "am57xx_evm_defconfig"
+SPL_BINARY = "MLO"
+
+# Enable creation of the U-Boot fitImage
+UBOOT_FITIMAGE_ENABLE = "1"
+
+# (U-boot) fitImage properties
+UBOOT_LOADADDRESS = "0x8008"
+UBOOT_ENTRYPOINT = "0x8008"
+UBOOT_FIT_DESC = "A model description"
+
+# Enable creation of Kernel fitImage
+KERNEL_IMAGETYPES += " fitImage "
+KERNEL_CLASSES = " kernel-fitimage"
+UBOOT_SIGN_ENABLE = "1"
+FIT_GENERATE_KEYS = "1"
+UBOOT_SIGN_KEYDIR = "${TOPDIR}/signing-keys"
+UBOOT_SIGN_KEYNAME = "oe-selftest"
+FIT_SIGN_INDIVIDUAL = "1"
+"""
+self.write_config(config)
+
+# The U-Boot fitImage is created as part of linux recipe
+bitbake("virtual/kernel")
+
+deploy_dir_image = get_bb_var('DEPLOY_DIR_IMAGE')
+machine = get_bb_var('MACHINE')
+fitimage_its_path = os.path.join(deploy_dir_image,
+"u-boot-its-%s" % (machine,))
+fitimage_path = os.path.join(deploy_dir_image,
+"u-boot-fitImage-%s" % (machine,))
+
+self.assertTrue(os.path.exists(fitimage_its_path),
+"%s image tree source doesn't exist" % (fitimage_its_path))
+self.assertTrue(os.path.exists(fitimage_path),
+"%s FIT image doesn't exist" % (fitimage_path))
+
+# Check that the type, load address, entrypoint address and default
+# values for kernel and ramdisk in Image Tree Source are as expected.
+# The order of fields in the below array is important. Not all the
+# fields are tested, only the key fields that wont vary between
+# different architectures.
+its_field_check = [
+'description = "A model description";',
+'type = "uboot";',
+'load = <0x8008>;',
+'entry = <0x8008>;',
+'default = "conf";',
+'loadables = "uboot";',
+'fdt = "fdt";'
+]
+
+with open(fitimage_its_path) as its_file:
+field_index = 0
+for line in its_file:
+if field_index == len(its_field_check):
+break
+if its_field_check[field_index] in line:
+field_index +=1
+
+if field_index != len(its_field_check): # if its equal, the test passed
+self.assertTrue(field_index == len(its_field_check),
+"Fields in Image Tree Source File %s did not match, error in 
finding %s"
+% (fitimage_its_path, its_field_check[field_index]))
+
+def test_uboot_sign_fit_image(self):
+"""
+Summary: Check if Uboot FIT image and Image Tree Source
+ (its) are built and the Image Tree Source has the
+ correct fields, in the scenario where the Kernel
+ is also creating/signing it's fitImage.
+Expected:1. u-boot-fitImage and u-boot-its can be built
+ 2. The type, load address, entrypoint add

[OE-core] [PATCH v2 0/4] u-boot: Support for SPL verified boot

[Klaus Heinrich Kiwi]

This patch series aims at extending U-Boot's verified boot support to
also include SPL.

Presently, setting UBOOT_SIGN_ENABLE instructs the classes uboot-sign
and kernel-fitimage to create and sign a Linux Kernel fitImage. This
proposal introduces the variables UBOOT_FITIMAGE_ENABLE and
SPL_SIGN_ENABLE that will, respectively, create and sign a U-Boot
(proper) fitImage that the SPL can load (and verify if enabled)

In order to accomplish this, the first patch moves some of necessary
infrastructure (variables, functions) used to sign the Kernel
fitImage to more common locations, and then essentially duplicates the
method currently used to sign the Kernel fitImage to also sign the
U-Boot fitImage.

If the variable UBOOT_FITIMAGE_ENABLE = "1", the uboot-sign class will
copy the SPL files (nodtb image and dtb file) from the u-boot recipe to
the staging area, so that the Kernel recipe can then create the U-Boot
fitImage.

In case SPL_SIGN_ENABLE = "1", the U-Boot fitImage will be signed using
the key provided by SPL_SIGN_KEYNAME / SPL_SIGN_KEYDIR, or will
auto-generate keys based on UBOOT_FIT_HASH_ALG, UBOOT_FIT_SIGN_ALG and
UBOOT_FIT_SIGN_NUMBITS if UBOOT_FIT_GENERATE_KEYS is "1".

After the operations above, the Kernel recipe will deploy the (signed)
U-Boot fitImage, the ITS script used to create it, as well as the SPL
concatenated with the DTB containing the pubkey to the images directory.

The reason why the U-Boot fitImage is created by the Kernel is in order
to make sure that, when UBOOT_SIGN_ENABLE is set (and the Kernel
fitImage is signed), the U-Boot fitImage being created/signed contains
the pubkey used by the Kernel recipe to sign the Kernel fitImage.

I added oe-selftest testcases and also tested this on upstream OpenBMC
with AST2600 BMC devices.

Signed-off-by: Klaus Heinrich Kiwi 

---
Changes since V1:

 * Separated SPL_SIGN_ENABLE from UBOOT_FITIMAGE_ENABLE so that an
   U-Boot fitImage can be created without a signature

 * Completely moved the task of creating/signing the U-Boot fitImage to
   the Kernel recipe, so that we don't get collisions when reusing the
   build tree while changing the configuration. This is apparently also
   necessary for testcases to be sane.

 * Testcases changes and additions, covering the above scenarios

 meta/classes/kernel-fitimage.bbclass |  82 ++---
 meta/classes/uboot-config.bbclass|  58 
 meta/classes/uboot-sign.bbclass  | 407 +++--
 meta/lib/oeqa/selftest/cases/fitimage.py | 468 +
 meta/recipes-bsp/u-boot/u-boot.inc   |  46 ---
 5 files changed, 928 insertions(+), 133 deletions(-)


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149997): 
https://lists.openembedded.org/g/openembedded-core/message/149997
Mute This Topic: https://lists.openembedded.org/mt/81638249/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH v2 3/4] u-boot: Use a different Key for SPL signing

[Klaus Heinrich Kiwi]

Duplicate the variables governing u-boot signing so that we can have a
different set of keys/parameters signing the SPL.

Signed-off-by: Klaus Heinrich Kiwi 
---
 meta/classes/uboot-config.bbclass |  2 ++
 meta/classes/uboot-sign.bbclass   | 53 +--
 2 files changed, 45 insertions(+), 10 deletions(-)

diff --git a/meta/classes/uboot-config.bbclass 
b/meta/classes/uboot-config.bbclass
index 31487c1418..3bba02828b 100644
--- a/meta/classes/uboot-config.bbclass
+++ b/meta/classes/uboot-config.bbclass
@@ -61,6 +61,7 @@ UBOOT_EXTLINUX_SYMLINK ?= 
"${UBOOT_EXTLINUX_CONF_NAME}-${MACHINE}-${PR}"
 
 # Options for the device tree compiler passed to mkimage '-D' feature:
 UBOOT_MKIMAGE_DTCOPTS ??= ""
+SPL_MKIMAGE_DTCOPTS ??= ""
 
 # mkimage command
 UBOOT_MKIMAGE ?= "uboot-mkimage"
@@ -68,6 +69,7 @@ UBOOT_MKIMAGE_SIGN ?= "${UBOOT_MKIMAGE}"
 
 # Arguments passed to mkimage for signing
 UBOOT_MKIMAGE_SIGN_ARGS ?= ""
+SPL_MKIMAGE_SIGN_ARGS ?= ""
 
 python () {
 ubootmachine = d.getVar("UBOOT_MACHINE")
diff --git a/meta/classes/uboot-sign.bbclass b/meta/classes/uboot-sign.bbclass
index 30ccebe94a..5f1750fdcc 100644
--- a/meta/classes/uboot-sign.bbclass
+++ b/meta/classes/uboot-sign.bbclass
@@ -65,27 +65,34 @@ SPL_NODTB_SYMLINK ?= "u-boot-spl-nodtb-${MACHINE}.bin"
 # U-Boot fitImage description
 UBOOT_FIT_DESC ?= "U-Boot fitImage for ${DISTRO_NAME}/${PV}/${MACHINE}"
 
-# fitImage Hash Algo
+# Kernel / U-Boot fitImage Hash Algo
 FIT_HASH_ALG ?= "sha256"
+UBOOT_FIT_HASH_ALG ?= "sha256"
 
-# fitImage Signature Algo
+# Kernel / U-Boot fitImage Signature Algo
 FIT_SIGN_ALG ?= "rsa2048"
+UBOOT_FIT_SIGN_ALG ?= "rsa2048"
 
-# Generate keys for signing fitImage
+# Generate keys for signing Kernel / U-Boot fitImage
 FIT_GENERATE_KEYS ?= "0"
+UBOOT_FIT_GENERATE_KEYS ?= "0"
 
-# Size of private key in number of bits
+# Size of private keys in number of bits
 FIT_SIGN_NUMBITS ?= "2048"
+UBOOT_FIT_SIGN_NUMBITS ?= "2048"
 
 # args to openssl genrsa (Default is just the public exponent)
 FIT_KEY_GENRSA_ARGS ?= "-F4"
+UBOOT_FIT_KEY_GENRSA_ARGS ?= "-F4"
 
 # args to openssl req (Default is -batch for non interactive mode and
 # -new for new certificate)
 FIT_KEY_REQ_ARGS ?= "-batch -new"
+UBOOT_FIT_KEY_REQ_ARGS ?= "-batch -new"
 
 # Standard format for public key certificate
 FIT_KEY_SIGN_PKCS ?= "-x509"
+UBOOT_FIT_KEY_SIGN_PKCS ?= "-x509"
 
 # Functions on this bbclass can apply to either U-boot or Kernel,
 # depending on the scenario
@@ -280,6 +287,32 @@ do_generate_rsa_keys() {
-out 
"${UBOOT_SIGN_KEYDIR}/${UBOOT_SIGN_KEYNAME}".crt
fi
fi
+
+   if [ "${SPL_SIGN_ENABLE}" = "0" ] && [ "${UBOOT_FIT_GENERATE_KEYS}" = 
"1" ]; then
+   bbwarn "UBOOT_FIT_GENERATE_KEYS is set to 1 eventhough 
SPL_SIGN_ENABLE is set to 0. The keys will not be generated as they won't be 
used."
+   fi
+
+   if [ "${SPL_SIGN_ENABLE}" = "1" ] && [ "${UBOOT_FIT_GENERATE_KEYS}" = 
"1" ]; then
+
+   # Generate keys only if they don't already exist
+   if [ ! -f "${SPL_SIGN_KEYDIR}/${SPL_SIGN_KEYNAME}".key ] || \
+   [ ! -f "${SPL_SIGN_KEYDIR}/${SPL_SIGN_KEYNAME}".crt ]; 
then
+
+   # make directory if it does not already exist
+   mkdir -p "${SPL_SIGN_KEYDIR}"
+
+   echo "Generating RSA private key for signing U-Boot 
fitImage"
+   openssl genrsa ${UBOOT_FIT_KEY_GENRSA_ARGS} -out \
+   "${SPL_SIGN_KEYDIR}/${SPL_SIGN_KEYNAME}".key \
+   "${UBOOT_FIT_SIGN_NUMBITS}"
+
+   echo "Generating certificate for signing U-Boot 
fitImage"
+   openssl req ${FIT_KEY_REQ_ARGS} 
"${UBOOT_FIT_KEY_SIGN_PKCS}" \
+   -key 
"${SPL_SIGN_KEYDIR}/${SPL_SIGN_KEYNAME}".key \
+   -out 
"${SPL_SIGN_KEYDIR}/${SPL_SIGN_KEYNAME}".crt
+   fi
+   fi
+
 }
 
 addtask generate_rsa_keys before do_uboot_assemble_fitimage after do_compile
@@ -292,9 +325,9 @@ uboot_fitimage_assemble() {
uboot_dtb="${3}"
uboot_bin="${4}"
spl_dtb="${5}"
-   uboot_csum="${FIT_HASH_ALG}"
-   uboot_sign_algo="${FIT_SIGN_ALG}"
-   uboot_sign_keyname="${UBOOT_SIGN_KEYNAME}"
+   uboot_csum="${UBOOT_FIT_HASH_ALG}"
+   uboot_sign_algo="${UBOOT_FIT_SIGN_ALG}"
+   uboot_sign_keyname="${SPL_SIGN_KEYNAME}"
 
rm -f ${uboot_its} ${uboot_bin}
 
@@ -365,7 +398,7 @@ EOF
# Assemble the U-boot FIT image
#
${UBOOT_MKIMAGE} \
-   ${@'-D "${UBOOT_MKIMAGE_DTCOPTS}"' if 
len('${UBOOT_MKIMAGE_DTCOPTS}') else ''} \
+   ${@'-D "${SPL_MKIMAGE_DTCOPTS}"' if 
len('${SPL_MKIMAGE_DTCOPTS}') else ''} \
-f ${uboot_its} \
${uboot_bin}
 
@@ -374,11 +407,11 @@ EOF
# Sign the U-boot FIT image and add public key to SPL d

[OE-core] [PATCH v2 2/4] u-boot: Add infrastructure to SPL verified boot

[Klaus Heinrich Kiwi]

Add the necessary infrastructure to create a U-boot proper fitimage,
sign it (using the same keys as the kernel-fitimage), and put the public
key in the SPL binary so that verified SPL boot can be accomplished.

Signed-off-by: Klaus Heinrich Kiwi 
---
 meta/classes/kernel-fitimage.bbclass |  24 +-
 meta/classes/uboot-sign.bbclass  | 351 ---
 2 files changed, 340 insertions(+), 35 deletions(-)

diff --git a/meta/classes/kernel-fitimage.bbclass 
b/meta/classes/kernel-fitimage.bbclass
index 6b7c1c3a7d..5cfd8af99d 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -55,7 +55,7 @@ python __anonymous () {
 
 
 # Description string
-FIT_DESC ?= "U-Boot fitImage for ${DISTRO_NAME}/${PV}/${MACHINE}"
+FIT_DESC ?= "Kernel fitImage for ${DISTRO_NAME}/${PV}/${MACHINE}"
 
 # Sign individual images as well
 FIT_SIGN_INDIVIDUAL ?= "0"
@@ -695,12 +695,22 @@ kernel_do_deploy_append() {
ln -snf 
fitImage-${INITRAMFS_IMAGE_NAME}-${KERNEL_FIT_NAME}.bin 
"$deployDir/fitImage-${INITRAMFS_IMAGE_NAME}-${KERNEL_FIT_LINK_NAME}"
fi
fi
-   if [ "${UBOOT_SIGN_ENABLE}" = "1" -a -n "${UBOOT_DTB_BINARY}" ] 
; then
-   # UBOOT_DTB_IMAGE is a realfile, but we can't use
-   # ${UBOOT_DTB_IMAGE} since it contains ${PV} which is 
aimed
-   # for u-boot, but we are in kernel env now.
-   install -m 0644 ${B}/u-boot-${MACHINE}*.dtb 
"$deployDir/"
-   fi
+   fi
+   if [ "${UBOOT_SIGN_ENABLE}" = "1" -o "${UBOOT_FITIMAGE_ENABLE}" = "1" ] 
&& \
+  [ -n "${UBOOT_DTB_BINARY}" ] ; then
+   # UBOOT_DTB_IMAGE is a realfile, but we can't use
+   # ${UBOOT_DTB_IMAGE} since it contains ${PV} which is aimed
+   # for u-boot, but we are in kernel env now.
+   install -m 0644 ${B}/u-boot-${MACHINE}*.dtb "$deployDir/"
+   fi
+   if [ "${UBOOT_FITIMAGE_ENABLE}" = "1" -a -n "${UBOOT_BINARY}" -a -n 
"${SPL_DTB_BINARY}" ] ; then
+   # If we're also creating and/or signing the uboot fit, now we 
need to
+   # deploy it, it's its file, as well as u-boot-spl.dtb
+   install -m 0644 ${B}/u-boot-spl-${MACHINE}*.dtb "$deployDir/"
+   echo "Copying u-boot-fitImage file..."
+   install -m 0644 ${B}/u-boot-fitImage-* "$deployDir/"
+   echo "Copying u-boot-its file..."
+   install -m 0644 ${B}/u-boot-its-* "$deployDir/"
fi
 }
 
diff --git a/meta/classes/uboot-sign.bbclass b/meta/classes/uboot-sign.bbclass
index d57bef6669..30ccebe94a 100644
--- a/meta/classes/uboot-sign.bbclass
+++ b/meta/classes/uboot-sign.bbclass
@@ -34,26 +34,36 @@
 # We need some variables from u-boot-config
 inherit uboot-config
 
-# Signature activation.
+# Enable use of a U-Boot fitImage
+UBOOT_FITIMAGE_ENABLE ?= "0"
+
+# Signature activation - these require their respective fitImages
 UBOOT_SIGN_ENABLE ?= "0"
+SPL_SIGN_ENABLE ?= "0"
 
 # Default value for deployment filenames.
 UBOOT_DTB_IMAGE ?= "u-boot-${MACHINE}-${PV}-${PR}.dtb"
 UBOOT_DTB_BINARY ?= "u-boot.dtb"
 UBOOT_DTB_SYMLINK ?= "u-boot-${MACHINE}.dtb"
-UBOOT_NODTB_IMAGE ?= "u-boot-nodtb-${MACHINE}-${PV}-${PR}.${UBOOT_SUFFIX}"
-UBOOT_NODTB_BINARY ?= "u-boot-nodtb.${UBOOT_SUFFIX}"
-UBOOT_NODTB_SYMLINK ?= "u-boot-nodtb-${MACHINE}.${UBOOT_SUFFIX}"
-UBOOT_ITS_IMAGE ?= "u-boot-${MACHINE}-${PV}-${PR}.its"
+UBOOT_NODTB_IMAGE ?= "u-boot-nodtb-${MACHINE}-${PV}-${PR}.bin"
+UBOOT_NODTB_BINARY ?= "u-boot-nodtb.bin"
+UBOOT_NODTB_SYMLINK ?= "u-boot-nodtb-${MACHINE}.bin"
+UBOOT_ITS_IMAGE ?= "u-boot-its-${MACHINE}-${PV}-${PR}"
 UBOOT_ITS ?= "u-boot.its"
-UBOOT_ITS_SYMLINK ?= "u-boot-${MACHINE}.its"
-SPL_DIR ?= "${@os.path.dirname(d.getVar("SPL_BINARY")) or '.'}"
+UBOOT_ITS_SYMLINK ?= "u-boot-its-${MACHINE}"
+UBOOT_FITIMAGE_IMAGE ?= "u-boot-fitImage-${MACHINE}-${PV}-${PR}"
+UBOOT_FITIMAGE_BINARY ?= "u-boot-fitImage"
+UBOOT_FITIMAGE_SYMLINK ?= "u-boot-fitImage-${MACHINE}"
+SPL_DIR ?= "spl"
 SPL_DTB_IMAGE ?= "u-boot-spl-${MACHINE}-${PV}-${PR}.dtb"
 SPL_DTB_BINARY ?= "u-boot-spl.dtb"
 SPL_DTB_SYMLINK ?= "u-boot-spl-${MACHINE}.dtb"
-SPL_NODTB_IMAGE ?= 
"${@os.path.splitext(d.getVar("SPL_BINARYNAME"))[0]}-nodtb-${MACHINE}-${PV}-${PR}${@os.path.splitext(d.getVar("SPL_BINARYNAME"))[1]}"
-SPL_NODTB_BINARY ?= 
"${@os.path.splitext(d.getVar("SPL_BINARYNAME"))[0]}-nodtb${@os.path.splitext(d.getVar("SPL_BINARYNAME"))[1]}"
-SPL_NODTB_SYMLINK ?= 
"${@os.path.splitext(d.getVar("SPL_BINARYNAME"))[0]}-nodtb-${MACHINE}${@os.path.splitext(d.getVar("SPL_BINARYNAME"))[1]}"
+SPL_NODTB_IMAGE ?= "u-boot-spl-nodtb-${MACHINE}-${PV}-${PR}.bin"
+SPL_NODTB_BINARY ?= "u-boot-spl-nodtb.bin"
+SPL_NODTB_SYMLINK ?= "u-boot-spl-nodtb-${MACHINE}.bin"
+
+# U-Boot fitImage description
+UBOOT_FIT_DESC ?= "U-Boot fitImage for ${DISTRO_NAME}/${PV}/${MACHINE}"
 
 # fitImage Hash Algo
 FIT_HASH_AL

[OE-core] [PATCH v2 1/4] u-boot: Move definitions to common locations

[Klaus Heinrich Kiwi]

Move some definitions from u-boot.inc into uboot-config.bbclass and
similarly from kernel-fitimage.bbclass into uboot-sign.bbclass, so that
they can be useful when signing the U-boot proper fitimage, for a
verified-boot SPL.

Signed-off-by: Klaus Heinrich Kiwi 
---
 meta/classes/kernel-fitimage.bbclass | 58 
 meta/classes/uboot-config.bbclass| 56 +++
 meta/classes/uboot-sign.bbclass  | 35 +
 meta/recipes-bsp/u-boot/u-boot.inc   | 46 --
 4 files changed, 91 insertions(+), 104 deletions(-)

diff --git a/meta/classes/kernel-fitimage.bbclass 
b/meta/classes/kernel-fitimage.bbclass
index b9d8270027..6b7c1c3a7d 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -53,30 +53,6 @@ python __anonymous () {
 d.appendVarFlag('do_assemble_fitimage_initramfs', 'depends', ' 
%s:do_populate_sysroot' % uboot_pn)
 }
 
-# Options for the device tree compiler passed to mkimage '-D' feature:
-UBOOT_MKIMAGE_DTCOPTS ??= ""
-
-# fitImage Hash Algo
-FIT_HASH_ALG ?= "sha256"
-
-# fitImage Signature Algo
-FIT_SIGN_ALG ?= "rsa2048"
-
-# Generate keys for signing fitImage
-FIT_GENERATE_KEYS ?= "0"
-
-# Size of private key in number of bits
-FIT_SIGN_NUMBITS ?= "2048"
-
-# args to openssl genrsa (Default is just the public exponent)
-FIT_KEY_GENRSA_ARGS ?= "-F4"
-
-# args to openssl req (Default is -batch for non interactive mode and
-# -new for new certificate)
-FIT_KEY_REQ_ARGS ?= "-batch -new"
-
-# Standard format for public key certificate
-FIT_KEY_SIGN_PKCS ?= "-x509"
 
 # Description string
 FIT_DESC ?= "U-Boot fitImage for ${DISTRO_NAME}/${PV}/${MACHINE}"
@@ -84,13 +60,6 @@ FIT_DESC ?= "U-Boot fitImage for 
${DISTRO_NAME}/${PV}/${MACHINE}"
 # Sign individual images as well
 FIT_SIGN_INDIVIDUAL ?= "0"
 
-# mkimage command
-UBOOT_MKIMAGE ?= "uboot-mkimage"
-UBOOT_MKIMAGE_SIGN ?= "${UBOOT_MKIMAGE}"
-
-# Arguments passed to mkimage for signing
-UBOOT_MKIMAGE_SIGN_ARGS ?= ""
-
 #
 # Emit the fitImage ITS header
 #
@@ -698,33 +667,6 @@ do_assemble_fitimage_initramfs() {
 
 addtask assemble_fitimage_initramfs before do_deploy after do_bundle_initramfs
 
-do_generate_rsa_keys() {
-   if [ "${UBOOT_SIGN_ENABLE}" = "0" ] && [ "${FIT_GENERATE_KEYS}" = "1" 
]; then
-   bbwarn "FIT_GENERATE_KEYS is set to 1 eventhough 
UBOOT_SIGN_ENABLE is set to 0. The keys will not be generated as they won't be 
used."
-   fi
-
-   if [ "${UBOOT_SIGN_ENABLE}" = "1" ] && [ "${FIT_GENERATE_KEYS}" = "1" 
]; then
-
-   # Generate keys only if they don't already exist
-   if [ ! -f "${UBOOT_SIGN_KEYDIR}/${UBOOT_SIGN_KEYNAME}".key ] || 
\
-   [ ! -f 
"${UBOOT_SIGN_KEYDIR}/${UBOOT_SIGN_KEYNAME}".crt]; then
-
-   # make directory if it does not already exist
-   mkdir -p "${UBOOT_SIGN_KEYDIR}"
-
-   echo "Generating RSA private key for signing fitImage"
-   openssl genrsa ${FIT_KEY_GENRSA_ARGS} -out \
-   
"${UBOOT_SIGN_KEYDIR}/${UBOOT_SIGN_KEYNAME}".key \
-   "${FIT_SIGN_NUMBITS}"
-
-   echo "Generating certificate for signing fitImage"
-   openssl req ${FIT_KEY_REQ_ARGS} "${FIT_KEY_SIGN_PKCS}" \
-   -key 
"${UBOOT_SIGN_KEYDIR}/${UBOOT_SIGN_KEYNAME}".key \
-   -out 
"${UBOOT_SIGN_KEYDIR}/${UBOOT_SIGN_KEYNAME}".crt
-   fi
-   fi
-}
-
 addtask generate_rsa_keys before do_assemble_fitimage after do_compile
 
 kernel_do_deploy[vardepsexclude] = "DATETIME"
diff --git a/meta/classes/uboot-config.bbclass 
b/meta/classes/uboot-config.bbclass
index 89ff970fcc..31487c1418 100644
--- a/meta/classes/uboot-config.bbclass
+++ b/meta/classes/uboot-config.bbclass
@@ -11,7 +11,63 @@
 #
 # Copyright 2013, 2014 (C) O.S. Systems Software LTDA.
 
+# Some versions of u-boot use .bin and others use .img.  By default use .bin
+# but enable individual recipes to change this value.
+UBOOT_SUFFIX ??= "bin"
 UBOOT_BINARY ?= "u-boot.${UBOOT_SUFFIX}"
+UBOOT_BINARYNAME ?= "${@os.path.splitext(d.getVar("UBOOT_BINARY"))[0]}"
+UBOOT_IMAGE ?= "u-boot-${MACHINE}-${PV}-${PR}.${UBOOT_SUFFIX}"
+UBOOT_SYMLINK ?= "u-boot-${MACHINE}.${UBOOT_SUFFIX}"
+UBOOT_MAKE_TARGET ?= "all"
+
+# Output the ELF generated. Some platforms can use the ELF file and directly
+# load it (JTAG booting, QEMU) additionally the ELF can be used for debugging
+# purposes.
+UBOOT_ELF ?= ""
+UBOOT_ELF_SUFFIX ?= "elf"
+UBOOT_ELF_IMAGE ?= "u-boot-${MACHINE}-${PV}-${PR}.${UBOOT_ELF_SUFFIX}"
+UBOOT_ELF_BINARY ?= "u-boot.${UBOOT_ELF_SUFFIX}"
+UBOOT_ELF_SYMLINK ?= "u-boot-${MACHINE}.${UBOOT_ELF_SUFFIX}"
+
+# Some versions of u-boot build an SPL (Second Program Loader) image that
+# should be packaged along with the u-boot binary as well as placed in the
+# deploy directory.  F

Re: [OE-core] [PATCH][gatesgarth][dunfell] openssl: update to 1.1.1k to fix CVE-2021-3450 and CVE-2021-3449

[Steve Sakoman]

On Fri, Mar 26, 2021 at 8:54 AM Khem Raj  wrote:
>
> do we need this on dunfell too?

I plan to take it when it hits master.

Steve

>
> On Thu, Mar 25, 2021 at 12:20 PM Mikko Rapeli  wrote:
> >
> > Only security issues fixed in this release according to
> > https://www.openssl.org/news/cl111.txt
> >
> > Signed-off-by: Mikko Rapeli 
> > ---
> >  .../openssl/{openssl_1.1.1j.bb => openssl_1.1.1k.bb}| 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >  rename meta/recipes-connectivity/openssl/{openssl_1.1.1j.bb => 
> > openssl_1.1.1k.bb} (98%)
> >
> > diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1j.bb 
> > b/meta/recipes-connectivity/openssl/openssl_1.1.1k.bb
> > similarity index 98%
> > rename from meta/recipes-connectivity/openssl/openssl_1.1.1j.bb
> > rename to meta/recipes-connectivity/openssl/openssl_1.1.1k.bb
> > index f054d2fdba..5f281197c9 100644
> > --- a/meta/recipes-connectivity/openssl/openssl_1.1.1j.bb
> > +++ b/meta/recipes-connectivity/openssl/openssl_1.1.1k.bb
> > @@ -23,7 +23,7 @@ SRC_URI_append_class-nativesdk = " \
> > file://environment.d-openssl.sh \
> > "
> >
> > -SRC_URI[sha256sum] = 
> > "aaf2fcb575cdf6491b98ab4829abf78a3dec8402b8b81efc8f23c00d443981bf"
> > +SRC_URI[sha256sum] = 
> > "892a0875b9872acd04a9fde79b1f943075d5ea162415de3047c327df33fbaee5"
> >
> >  inherit lib_package multilib_header multilib_script ptest
> >  MULTILIB_SCRIPTS = "${PN}-bin:${bindir}/c_rehash"
> > --
> > 2.20.1
> >
> >
> >
> >
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149996): 
https://lists.openembedded.org/g/openembedded-core/message/149996
Mute This Topic: https://lists.openembedded.org/mt/81611322/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] some trivial(?) questions about packagegroups

[Andre McCurdy]

On Fri, Mar 26, 2021 at 8:45 AM Robert P. J. Day  wrote:
>
>   what should be easy questions about packagegroups, inspired by my
> running across some puzzling packagegroup recipes in my travels
> recently. (i'll start with examples out of oe-core).
>
>   first, as with any other recipe, given a "trivial" packagegroup
> like, say, packagegroup-core-eclipse-debug.bb:
>
>   SUMMARY = "Remote debugging tools for Eclipse integration"
>
>   inherit packagegroup
>
>   RDEPENDS_${PN} = "\
> gdbserver \
> tcf-agent \
> openssh-sftp-server \
> "
>
> there is no need to add a "PROVIDES" line since every recipe file
> automatically provides its own name. so far, so good.
>
>   if we move up to packagegroup-core-nfs.bb, note how this recipe file
> defines two additional packagegroups, and has to add a PROVIDES line
> in order to make those new names accessible:
>
>   PROVIDES = "${PACKAGES}"
>   PACKAGES = "${PN}-server ${PN}-client"
>
>   SUMMARY_${PN}-client = "NFS client"
>   RDEPENDS_${PN}-client = "nfs-utils-client"
>
>   SUMMARY_${PN}-server = "NFS server"
>   RDEPENDS_${PN}-server = "\
> nfs-utils \
> nfs-utils-client \
> "
>
> so the question is, must one supply a PROVIDES line for any
> packagegroup names above and beyond the one that comes with the recipe
> file itself? i ask what seems like a dumb question as i've run across
> packagegroup recipe files that define multiple additional
> packagegroups, but do not add them to the PROVIDES line. what is that
> supposed to represent?

PROVIDES sets up a name which can be used as DEPENDS (ie a build time
dependency) in other recipes. If PROVIDES contains more than one name,
they all just become aliases for each other.

Since packagegroup recipes only define run time dependencies, nothing
should have a build time dependency on a packagegroup recipe... and so
there's no obvious reason to set PROVIDES to anything. Leaving the
default will be fine (although it won't be used for anything).

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149995): 
https://lists.openembedded.org/g/openembedded-core/message/149995
Mute This Topic: https://lists.openembedded.org/mt/81631340/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH v3] grub-efi: Re-introduce lost cast to long

[Khem Raj]

This cast was accidentally dropped in
https://git.savannah.gnu.org/cgit/grub.git/commit/?id=2bf40e9e5be9808b17852e688eead87acff14420

Signed-off-by: Khem Raj 
Cc: Alistair Francis 
---
v1: Avoid apply addent to rv32
v2: Drop building grub-efi for rv32
v3: Fix the real regression due to dropped typecast

 ...1-RISC-V-Restore-the-typcast-to-long.patch | 29 +++
 meta/recipes-bsp/grub/grub2.inc   |  1 +
 2 files changed, 30 insertions(+)
 create mode 100644 
meta/recipes-bsp/grub/files/0001-RISC-V-Restore-the-typcast-to-long.patch

diff --git 
a/meta/recipes-bsp/grub/files/0001-RISC-V-Restore-the-typcast-to-long.patch 
b/meta/recipes-bsp/grub/files/0001-RISC-V-Restore-the-typcast-to-long.patch
new file mode 100644
index 00..f0ffb3d954
--- /dev/null
+++ b/meta/recipes-bsp/grub/files/0001-RISC-V-Restore-the-typcast-to-long.patch
@@ -0,0 +1,29 @@
+From bf248231cb4f9f966f0d57821dd0491af54d4a0b Mon Sep 17 00:00:00 2001
+From: Khem Raj 
+Date: Fri, 26 Mar 2021 11:59:43 -0700
+Subject: [PATCH] RISC-V: Restore the typcast to long
+
+this makes the type promotions clear and explicit
+
+Upstream-Status: Pending
+Signed-off-by: Khem Raj 
+---
+ util/grub-mkimagexx.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/util/grub-mkimagexx.c b/util/grub-mkimagexx.c
+index 00f49cc..ab5523d 100644
+--- a/util/grub-mkimagexx.c
 b/util/grub-mkimagexx.c
+@@ -1242,7 +1242,7 @@ SUFFIX (relocate_addrs) (Elf_Ehdr *e, struct 
section_metadata *smd,
+ */
+ 
+sym_addr += addend;
+-   off = sym_addr - target_section_addr - offset - 
image_target->vaddr_offset;
++   off = (long)sym_addr - target_section_addr - offset - 
image_target->vaddr_offset;
+ 
+switch (ELF_R_TYPE (info))
+  {
+-- 
+2.31.0
+
diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index bcff676c26..590deb8d92 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -19,6 +19,7 @@ SRC_URI = 
"https://alpha.gnu.org/gnu/grub/grub-${REALPV}.tar.xz \
file://grub-module-explicitly-keeps-symbole-.module_license.patch \
file://0001-grub.d-10_linux.in-add-oe-s-kernel-name.patch \
file://determinism.patch \
+   file://0001-RISC-V-Restore-the-typcast-to-long.patch \
 "
 
 SRC_URI[sha256sum] = 
"2c87f1f21e2ab50043e6cd9163c08f1b6c3a6171556bf23ff9ed65b074145484"
-- 
2.31.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149994): 
https://lists.openembedded.org/g/openembedded-core/message/149994
Mute This Topic: https://lists.openembedded.org/mt/81636660/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH][gatesgarth][dunfell] openssl: update to 1.1.1k to fix CVE-2021-3450 and CVE-2021-3449

[Khem Raj]

do we need this on dunfell too?

On Thu, Mar 25, 2021 at 12:20 PM Mikko Rapeli  wrote:
>
> Only security issues fixed in this release according to
> https://www.openssl.org/news/cl111.txt
>
> Signed-off-by: Mikko Rapeli 
> ---
>  .../openssl/{openssl_1.1.1j.bb => openssl_1.1.1k.bb}| 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>  rename meta/recipes-connectivity/openssl/{openssl_1.1.1j.bb => 
> openssl_1.1.1k.bb} (98%)
>
> diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1j.bb 
> b/meta/recipes-connectivity/openssl/openssl_1.1.1k.bb
> similarity index 98%
> rename from meta/recipes-connectivity/openssl/openssl_1.1.1j.bb
> rename to meta/recipes-connectivity/openssl/openssl_1.1.1k.bb
> index f054d2fdba..5f281197c9 100644
> --- a/meta/recipes-connectivity/openssl/openssl_1.1.1j.bb
> +++ b/meta/recipes-connectivity/openssl/openssl_1.1.1k.bb
> @@ -23,7 +23,7 @@ SRC_URI_append_class-nativesdk = " \
> file://environment.d-openssl.sh \
> "
>
> -SRC_URI[sha256sum] = 
> "aaf2fcb575cdf6491b98ab4829abf78a3dec8402b8b81efc8f23c00d443981bf"
> +SRC_URI[sha256sum] = 
> "892a0875b9872acd04a9fde79b1f943075d5ea162415de3047c327df33fbaee5"
>
>  inherit lib_package multilib_header multilib_script ptest
>  MULTILIB_SCRIPTS = "${PN}-bin:${bindir}/c_rehash"
> --
> 2.20.1
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149993): 
https://lists.openembedded.org/g/openembedded-core/message/149993
Mute This Topic: https://lists.openembedded.org/mt/81611322/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH v2 1/3] meson: fix native/host confusion in gobject-introspection

[Khem Raj]

I am seeing some failures

https://errors.yoctoproject.org/Errors/Details/574541/

On Thu, Mar 25, 2021 at 12:08 PM Ross Burton  wrote:
>
> On Thu, 25 Mar 2021 at 18:15, Alexander Kanavin  
> wrote:
> > I don't think I fully understand this. Is g-i in meson projects already 
> > broken for a while (there was a bit of refactor in the latest meson 
> > version, which I tested, but perhaps not well enough), or is this necessary 
> > for the other patches in your set?
>
> I just sent a mail which sort-of answers this question without seeing it.
>
> Basically, the change is that Meson now knows that it should call
> pkg-config-native for native pkgconfig lookups.  Before, it was using
> pkg-config.
>
> As far as I can tell there is very little code which hits that
> codepath, so we didn't notice.  When setting pkgconfig-native
> correctly, this broke.
>
> Ross
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149992): 
https://lists.openembedded.org/g/openembedded-core/message/149992
Mute This Topic: https://lists.openembedded.org/mt/81608826/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH v11] util-linux: split uuid in separate recipe to allow bootstrapping

[Andre McCurdy]

On Fri, Mar 26, 2021 at 11:12 AM Richard Purdie
 wrote:
>
> On Fri, 2021-03-26 at 18:06 +, Peter Kjellerstedt wrote:
> > > -Original Message-
> > > From: Richard Purdie 
> > > Sent: den 25 mars 2021 17:52
> > > To: Peter Kjellerstedt ; Oleksiy Obitotskyi -
> > > X (oobitots - GLOBALLOGIC INC at Cisco) ; Luca Bocassi
> > > ; openembedded-core@lists.openembedded.org
> > > Cc: bluelightn...@bluelightning.org; Khem Raj 
> > > Subject: Re: [OE-core] [PATCH v11] util-linux: split uuid in separate
> > > recipe to allow bootstrapping
> > >
> > > On Thu, 2021-03-25 at 16:19 +, Peter Kjellerstedt wrote:
> > > > > -Original Message-
> > > > > From: Richard Purdie 
> > > > > Sent: den 25 mars 2021 15:27
> > > > > To: Peter Kjellerstedt ; Oleksiy
> > > Obitotskyi -
> > > > > X (oobitots - GLOBALLOGIC INC at Cisco) ; Luca
> > > Bocassi
> > > > > ; openembedded-core@lists.openembedded.org
> > > > > Cc: bluelightn...@bluelightning.org; Khem Raj 
> > > > > Subject: Re: [OE-core] [PATCH v11] util-linux: split uuid in separate
> > > > > recipe to allow bootstrapping
> > > > >
> > > > > On Thu, 2021-03-25 at 14:22 +, Peter Kjellerstedt wrote:
> > > > > > > -Original Message-
> > > > > > > From: Richard Purdie 
> > > > > > > Sent: den 25 mars 2021 10:34
> > > > > > > To: Oleksiy Obitotskyi -X (oobitots - GLOBALLOGIC INC at Cisco)
> > > > > > > ; Luca Bocassi ;
> > > > > > > openembedded-core@lists.openembedded.org
> > > > > > > Cc: bluelightn...@bluelightning.org; Peter Kjellerstedt
> > > > > > > ; Khem Raj 
> > > > > > > Subject: Re: [OE-core] [PATCH v11] util-linux: split uuid in
> > > separate
> > > > > > > recipe to allow bootstrapping
> > > > > > >
> > > > > > > On Thu, 2021-03-25 at 09:17 +, Oleksiy Obitotskyi -X (oobitots
> > > -
> > > > > > > GLOBALLOGIC INC at Cisco) wrote:
> > > > > > > > Could you look into this warning.
> > > > > > > >
> > > > > > > > WARNING: util-linux-2.36.2-r0 do_package_qa: QA Issue: util-
> > > linux-
> > > > > dev
> > > > > > > rdepends on util-linux-libuuid-dev, but it isn't a build
> > > dependency?
> > > > > > > [build-deps]
> > > > > > > >
> > > > > > > >
> > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/61/builds/3226
> > > > > > >
> > > > > > > That failure was my fault when testing some fixes.
> > > > > > >
> > > > > > > I've sent out a patch which renames util-linux-uuid to util-linux-
> > > > > libuuid
> > > > > > > and sorts out the license issue Peter reported.
> > > > > >
> > > > > > I don't mind the recipe being renamed and cleaned up, but I would
> > > prefer
> > > > > > to see my entire patch for the license parts being either integrated
> > > > > before
> > > > > > this or squashed into it, whichever you prefer. It does not make
> > > sense
> > > > > to
> > > > > > use the same LIC_FILES_CHKSUM for util-linux-libuuid as for util-
> > > linux,
> > > > > > and setting the other LICENSE variables in util-linux.inc no longer
> > > > > makes
> > > > > > sense as they are only relevant for util-linux.
> > > > >
> > > > > I'm torn on that. Code with the other licenses is present, just not
> > > used
> > > > > in the final output and I personally suspect that having one
> > > LIC_FILES_CHKSUM
> > > > > is going to be easier to maintain in the future rather than two
> > > separate
> > > > > ones.
> > > >
> > > > I actually checked all the files that go into -dev and -src before
> > > suggesting
> > > > this change, and all files are either marked as public domain or use a
> > > > BSD-3-Clause license.
> > >
> > > There is a difference between what ends up in ${S} and what ends up in the
> > > binary packages. LICENSE clearly governs the latter. Its the scope of
> > > LIC_FILES_CHECKSUM which there are differences of opinion on.
> >
> > Well, the latter governs what ends up in ${PN}-lic, so having a lot of
> > unrelated (to the installed packages) license files in LIC_FILES_CHECKSUM
> > does not make sense (to me). If everything that is built and (possibly)
> > installed and thus distributed is covered by BSD-3-Clause licenses, why
> > should ${PN}-lic include a lot of license files for unrelated code?
>
> I hadn't considered ${PN}-lic :(.
>
> We can't win. If we change LIC_FILES_CHKSUM we'll see complaints from
> people scanning the code that there are licenses present in WORKDIR that
> are not in LIC_FILES_CHKSUM.

If there's code in the upstream tar file etc which is not involved at
all in the build of the one particular sub component you're interested
in then this type of complaint can be solved by removing the unused
code from ${S} as part of do_patch.

> If we don't change it, ${PN}-lic does give
> more information than necessary. I still think the latter is probably
> safer and makes recipe upgrades easier.
>
> Licensing in general needs a step back and an overhaul. Sadly people are
> generally only prepared to do this piecemeal solving their specific
> issue rather than the general case and big picture.
>
> Cheers,
>
> Ric

Re: [OE-core] [PATCH v11] util-linux: split uuid in separate recipe to allow bootstrapping

[Richard Purdie]

On Fri, 2021-03-26 at 18:06 +, Peter Kjellerstedt wrote:
> > -Original Message-
> > From: Richard Purdie 
> > Sent: den 25 mars 2021 17:52
> > To: Peter Kjellerstedt ; Oleksiy Obitotskyi -
> > X (oobitots - GLOBALLOGIC INC at Cisco) ; Luca Bocassi
> > ; openembedded-core@lists.openembedded.org
> > Cc: bluelightn...@bluelightning.org; Khem Raj 
> > Subject: Re: [OE-core] [PATCH v11] util-linux: split uuid in separate
> > recipe to allow bootstrapping
> > 
> > On Thu, 2021-03-25 at 16:19 +, Peter Kjellerstedt wrote:
> > > > -Original Message-
> > > > From: Richard Purdie 
> > > > Sent: den 25 mars 2021 15:27
> > > > To: Peter Kjellerstedt ; Oleksiy
> > Obitotskyi -
> > > > X (oobitots - GLOBALLOGIC INC at Cisco) ; Luca
> > Bocassi
> > > > ; openembedded-core@lists.openembedded.org
> > > > Cc: bluelightn...@bluelightning.org; Khem Raj 
> > > > Subject: Re: [OE-core] [PATCH v11] util-linux: split uuid in separate
> > > > recipe to allow bootstrapping
> > > > 
> > > > On Thu, 2021-03-25 at 14:22 +, Peter Kjellerstedt wrote:
> > > > > > -Original Message-
> > > > > > From: Richard Purdie 
> > > > > > Sent: den 25 mars 2021 10:34
> > > > > > To: Oleksiy Obitotskyi -X (oobitots - GLOBALLOGIC INC at Cisco)
> > > > > > ; Luca Bocassi ;
> > > > > > openembedded-core@lists.openembedded.org
> > > > > > Cc: bluelightn...@bluelightning.org; Peter Kjellerstedt
> > > > > > ; Khem Raj 
> > > > > > Subject: Re: [OE-core] [PATCH v11] util-linux: split uuid in
> > separate
> > > > > > recipe to allow bootstrapping
> > > > > > 
> > > > > > On Thu, 2021-03-25 at 09:17 +, Oleksiy Obitotskyi -X (oobitots
> > -
> > > > > > GLOBALLOGIC INC at Cisco) wrote:
> > > > > > > Could you look into this warning.
> > > > > > > 
> > > > > > > WARNING: util-linux-2.36.2-r0 do_package_qa: QA Issue: util-
> > linux-
> > > > dev
> > > > > > rdepends on util-linux-libuuid-dev, but it isn't a build
> > dependency?
> > > > > > [build-deps]
> > > > > > > 
> > > > > > > 
> > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/61/builds/3226
> > > > > > 
> > > > > > That failure was my fault when testing some fixes.
> > > > > > 
> > > > > > I've sent out a patch which renames util-linux-uuid to util-linux-
> > > > libuuid
> > > > > > and sorts out the license issue Peter reported.
> > > > > 
> > > > > I don't mind the recipe being renamed and cleaned up, but I would
> > prefer
> > > > > to see my entire patch for the license parts being either integrated
> > > > before
> > > > > this or squashed into it, whichever you prefer. It does not make
> > sense
> > > > to
> > > > > use the same LIC_FILES_CHKSUM for util-linux-libuuid as for util-
> > linux,
> > > > > and setting the other LICENSE variables in util-linux.inc no longer
> > > > makes
> > > > > sense as they are only relevant for util-linux.
> > > > 
> > > > I'm torn on that. Code with the other licenses is present, just not
> > used
> > > > in the final output and I personally suspect that having one
> > LIC_FILES_CHKSUM
> > > > is going to be easier to maintain in the future rather than two
> > separate
> > > > ones.
> > > 
> > > I actually checked all the files that go into -dev and -src before
> > suggesting
> > > this change, and all files are either marked as public domain or use a
> > > BSD-3-Clause license.
> > 
> > There is a difference between what ends up in ${S} and what ends up in the
> > binary packages. LICENSE clearly governs the latter. Its the scope of
> > LIC_FILES_CHECKSUM which there are differences of opinion on.
> 
> Well, the latter governs what ends up in ${PN}-lic, so having a lot of 
> unrelated (to the installed packages) license files in LIC_FILES_CHECKSUM 
> does not make sense (to me). If everything that is built and (possibly) 
> installed and thus distributed is covered by BSD-3-Clause licenses, why 
> should ${PN}-lic include a lot of license files for unrelated code?

I hadn't considered ${PN}-lic :(.

We can't win. If we change LIC_FILES_CHKSUM we'll see complaints from
people scanning the code that there are licenses present in WORKDIR that
are not in LIC_FILES_CHKSUM. If we don't change it, ${PN}-lic does give
more information than necessary. I still think the latter is probably
safer and makes recipe upgrades easier.

Licensing in general needs a step back and an overhaul. Sadly people are 
generally only prepared to do this piecemeal solving their specific
issue rather than the general case and big picture.

Cheers,

Richard




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149990): 
https://lists.openembedded.org/g/openembedded-core/message/149990
Mute This Topic: https://lists.openembedded.org/mt/81254724/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH v11] util-linux: split uuid in separate recipe to allow bootstrapping

[Peter Kjellerstedt]

> -Original Message-
> From: Richard Purdie 
> Sent: den 25 mars 2021 17:52
> To: Peter Kjellerstedt ; Oleksiy Obitotskyi -
> X (oobitots - GLOBALLOGIC INC at Cisco) ; Luca Bocassi
> ; openembedded-core@lists.openembedded.org
> Cc: bluelightn...@bluelightning.org; Khem Raj 
> Subject: Re: [OE-core] [PATCH v11] util-linux: split uuid in separate
> recipe to allow bootstrapping
> 
> On Thu, 2021-03-25 at 16:19 +, Peter Kjellerstedt wrote:
> > > -Original Message-
> > > From: Richard Purdie 
> > > Sent: den 25 mars 2021 15:27
> > > To: Peter Kjellerstedt ; Oleksiy
> Obitotskyi -
> > > X (oobitots - GLOBALLOGIC INC at Cisco) ; Luca
> Bocassi
> > > ; openembedded-core@lists.openembedded.org
> > > Cc: bluelightn...@bluelightning.org; Khem Raj 
> > > Subject: Re: [OE-core] [PATCH v11] util-linux: split uuid in separate
> > > recipe to allow bootstrapping
> > >
> > > On Thu, 2021-03-25 at 14:22 +, Peter Kjellerstedt wrote:
> > > > > -Original Message-
> > > > > From: Richard Purdie 
> > > > > Sent: den 25 mars 2021 10:34
> > > > > To: Oleksiy Obitotskyi -X (oobitots - GLOBALLOGIC INC at Cisco)
> > > > > ; Luca Bocassi ;
> > > > > openembedded-core@lists.openembedded.org
> > > > > Cc: bluelightn...@bluelightning.org; Peter Kjellerstedt
> > > > > ; Khem Raj 
> > > > > Subject: Re: [OE-core] [PATCH v11] util-linux: split uuid in
> separate
> > > > > recipe to allow bootstrapping
> > > > >
> > > > > On Thu, 2021-03-25 at 09:17 +, Oleksiy Obitotskyi -X (oobitots
> -
> > > > > GLOBALLOGIC INC at Cisco) wrote:
> > > > > > Could you look into this warning.
> > > > > >
> > > > > > WARNING: util-linux-2.36.2-r0 do_package_qa: QA Issue: util-
> linux-
> > > dev
> > > > > rdepends on util-linux-libuuid-dev, but it isn't a build
> dependency?
> > > > > [build-deps]
> > > > > >
> > > > > >
> > > https://autobuilder.yoctoproject.org/typhoon/#/builders/61/builds/3226
> > > > >
> > > > > That failure was my fault when testing some fixes.
> > > > >
> > > > > I've sent out a patch which renames util-linux-uuid to util-linux-
> > > libuuid
> > > > > and sorts out the license issue Peter reported.
> > > >
> > > > I don't mind the recipe being renamed and cleaned up, but I would
> prefer
> > > > to see my entire patch for the license parts being either integrated
> > > before
> > > > this or squashed into it, whichever you prefer. It does not make
> sense
> > > to
> > > > use the same LIC_FILES_CHKSUM for util-linux-libuuid as for util-
> linux,
> > > > and setting the other LICENSE variables in util-linux.inc no longer
> > > makes
> > > > sense as they are only relevant for util-linux.
> > >
> > > I'm torn on that. Code with the other licenses is present, just not
> used
> > > in the final output and I personally suspect that having one
> LIC_FILES_CHKSUM
> > > is going to be easier to maintain in the future rather than two
> separate
> > > ones.
> >
> > I actually checked all the files that go into -dev and -src before
> suggesting
> > this change, and all files are either marked as public domain or use a
> > BSD-3-Clause license.
> 
> There is a difference between what ends up in ${S} and what ends up in the
> binary packages. LICENSE clearly governs the latter. Its the scope of
> LIC_FILES_CHECKSUM which there are differences of opinion on.

Well, the latter governs what ends up in ${PN}-lic, so having a lot of 
unrelated (to the installed packages) license files in LIC_FILES_CHECKSUM 
does not make sense (to me). If everything that is built and (possibly) 
installed and thus distributed is covered by BSD-3-Clause licenses, why 
should ${PN}-lic include a lot of license files for unrelated code?

> Cheers,
> 
> Richard

//Peter


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149989): 
https://lists.openembedded.org/g/openembedded-core/message/149989
Mute This Topic: https://lists.openembedded.org/mt/81254724/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] Autobuilder data collection for intermittent bugs

[Richard Purdie]

On Thu, 2021-03-25 at 20:00 -0400, Randy MacLeod wrote:
> Thanks for the update Sakib.
> 
> We're planning to follow Steve's example of getting commit access to
> contrib branches of y-a-h and poky and using the YP AB to start custom 
> workers/job initially.  We'll also keep working to duplicate the
> AB behaviour locally. Trevor has asked Konrad for an additional system
> or two since when jobs are running, the web UI is
> painfully slow since it's runnig on the same node right now.
> 
> The one part that Sakib didn't ask about is how to get all the workers
> to do the data collection but that's not urgent since we'll be doing
> some smaller scale experiments tomorrow. If you can point out a helpful
> example, that'd be good.

The easiest is the fact that the workers all share an NFS mount which
is at BASE_SHAREDDIR in config.json. See also WEBPUBLISH_DIR and 
WEBPUBLISH_URL.

We use this to share the reproducible build failures and to share the 
reproducible build failures/diffoscope and test results, e.g.:
OEQA_DEBUGGING_SAVED_OUTPUT=${BASE_SHAREDDIR}/pub/repro-fail/

or perhaps more useful is scripts/collect-results:

"""
#!/bin/bash
WORKDIR=$1
DEST=$2
target=$3

RESFILE=$WORKDIR/tmp/log/oeqa/testresults.json 

if [ -e $RESFILE ]; then
mkdir -p $DEST/$target
cp $WORKDIR/tmp/log/oeqa/testresults.json  $DEST/$target/
fi
"""

would let you do something similar and DEST here is specific to a given 
build (date stamp + number). An example would be:

https://autobuilder.yocto.io/pub/non-release/20210129-3/

and then you could create a folder per target. You may need to 
include the worker name in the log.

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149988): 
https://lists.openembedded.org/g/openembedded-core/message/149988
Mute This Topic: https://lists.openembedded.org/mt/81615102/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] some trivial(?) questions about packagegroups

[Robert P. J. Day]

  what should be easy questions about packagegroups, inspired by my
running across some puzzling packagegroup recipes in my travels
recently. (i'll start with examples out of oe-core).

  first, as with any other recipe, given a "trivial" packagegroup
like, say, packagegroup-core-eclipse-debug.bb:

  SUMMARY = "Remote debugging tools for Eclipse integration"

  inherit packagegroup

  RDEPENDS_${PN} = "\
gdbserver \
tcf-agent \
openssh-sftp-server \
"

there is no need to add a "PROVIDES" line since every recipe file
automatically provides its own name. so far, so good.

  if we move up to packagegroup-core-nfs.bb, note how this recipe file
defines two additional packagegroups, and has to add a PROVIDES line
in order to make those new names accessible:

  PROVIDES = "${PACKAGES}"
  PACKAGES = "${PN}-server ${PN}-client"

  SUMMARY_${PN}-client = "NFS client"
  RDEPENDS_${PN}-client = "nfs-utils-client"

  SUMMARY_${PN}-server = "NFS server"
  RDEPENDS_${PN}-server = "\
nfs-utils \
nfs-utils-client \
"

so the question is, must one supply a PROVIDES line for any
packagegroup names above and beyond the one that comes with the recipe
file itself? i ask what seems like a dumb question as i've run across
packagegroup recipe files that define multiple additional
packagegroups, but do not add them to the PROVIDES line. what is that
supposed to represent?

rday

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149987): 
https://lists.openembedded.org/g/openembedded-core/message/149987
Mute This Topic: https://lists.openembedded.org/mt/81631340/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[oe-core][PATCH v3 2/2] valgrind: Disable ptest swapcontext.vgtest

[Yi Fan Yu]

New test introduced in valgrind 3.17.0.
Test fails on both qemuarm64 and qemux64.

[YOCTO #14324]

Signed-off-by: Yi Fan Yu 
---
Changes in V3:

Added Reference to Yocto bug in the patch itself

 ...orarily-drd-tests-swapcontext.vgtest.patch | 29 +++
 .../valgrind/valgrind_3.17.0.bb   |  1 +
 2 files changed, 30 insertions(+)
 create mode 100644 
meta/recipes-devtools/valgrind/valgrind/0001-Disable-temporarily-drd-tests-swapcontext.vgtest.patch

diff --git 
a/meta/recipes-devtools/valgrind/valgrind/0001-Disable-temporarily-drd-tests-swapcontext.vgtest.patch
 
b/meta/recipes-devtools/valgrind/valgrind/0001-Disable-temporarily-drd-tests-swapcontext.vgtest.patch
new file mode 100644
index 00..10ec06ccaf
--- /dev/null
+++ 
b/meta/recipes-devtools/valgrind/valgrind/0001-Disable-temporarily-drd-tests-swapcontext.vgtest.patch
@@ -0,0 +1,29 @@
+From 0f1814a618eff4233e9e8379a8cb2dededdc5a8b Mon Sep 17 00:00:00 2001
+From: Yi Fan Yu 
+Date: Tue, 23 Mar 2021 11:09:20 -0700
+Subject: [PATCH] Disable temporarily drd/tests/swapcontext.vgtest
+
+New test introduced in valgrind 3.17.0.
+Test fails on both qemuarm64 and qemux64.
+
+Upstream-Status: Pending [Needs more Investigation]
+[YOCTO #14324]
+
+Signed-off-by: Yi Fan Yu 
+---
+ drd/tests/swapcontext.vgtest | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drd/tests/swapcontext.vgtest b/drd/tests/swapcontext.vgtest
+index 98e3712c4..5492da31d 100644
+--- a/drd/tests/swapcontext.vgtest
 b/drd/tests/swapcontext.vgtest
+@@ -1,4 +1,4 @@
+-prereq: test -e swapcontext && ./supported_libpthread
++prereq: false
+ vgopts: --read-var-info=yes --check-stack-var=yes --show-confl-seg=no 
--num-callers=2
+ prog: swapcontext
+ stderr_filter: filter_stderr
+-- 
+2.17.1
+
diff --git a/meta/recipes-devtools/valgrind/valgrind_3.17.0.bb 
b/meta/recipes-devtools/valgrind/valgrind_3.17.0.bb
index 1e29896596..7a6b766121 100644
--- a/meta/recipes-devtools/valgrind/valgrind_3.17.0.bb
+++ b/meta/recipes-devtools/valgrind/valgrind_3.17.0.bb
@@ -43,6 +43,7 @@ SRC_URI = 
"https://sourceware.org/pub/valgrind/valgrind-${PV}.tar.bz2 \

file://0001-none-tests-fdleak_cmsg.stderr.exp-adjust-tmp-paths.patch \
file://0001-memcheck-tests-Fix-timerfd-syscall-test.patch \
file://0001-Add-missing-musl.supp.patch \
+   file://0001-Disable-temporarily-drd-tests-swapcontext.vgtest.patch \
"
 SRC_URI[md5sum] = "afe11b5572c3121a781433b7c0ab741b"
 SRC_URI[sha256sum] = 
"ad3aec668e813e40f238995f60796d9590eee64a16dff88421430630e69285a2"
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149986): 
https://lists.openembedded.org/g/openembedded-core/message/149986
Mute This Topic: https://lists.openembedded.org/mt/81629458/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[oe-core][PATCH v3 1/2] valgrind: update 3.16.1 -> 3.17.0

[Yi Fan Yu]

Notable changes:
* library is now in libexecdir instead of libdir

Added patches:
* Add musl.supp: missing musl.supp in 3.17.0

Dropped backport patches:
* nlcontrolc: found in c79180a3afcf65902e578646c3b716cc749db406
* drd Fedora33: found in 15330adf7c2471fbaa6a0818db07078d81dbff97
* lmw lswi ppc64le: found in 74b74174d572fee4015b8f4e326db3cd949bcdc3

Other dropped patches
* helgrind intercept: found in d2d54dbcc74244adfc0c80b40862edf2b82f53b9
* drd musl fix: found in d2d54dbcc74244adfc0c80b40862edf2b82f53b9

TESTING RESULTS:
qemux86-64:
FAIL: drd/tests/swapcontext

  3.17.0  3.16.1
===
TOTAL:  736726
PASSED: 694688
FAILED:   1  0
SKIPPED: 41 38

Signed-off-by: Yi Fan Yu 
---
Changes for V2:

minor edit to commit msg

fix reproducibility

+# point the expanded @abs_top_builddir@ of the host to PTEST_PATH
+sed -i s:${S}:${PTEST_PATH}:g \
+${D}${PTEST_PATH}/memcheck/tests/linux/debuginfod-check.vgtest

 .../valgrind/0001-Add-missing-musl.supp.patch |  72 +++
 ...gtest-hanging-on-newer-glibc-and-or-.patch | 200 --
 .../valgrind/0001-drd-Port-to-Fedora-33.patch |  48 -
 .../valgrind/valgrind/0001-drd-musl-fix.patch |  31 ---
 ...01-helgrind-Intercept-libc-functions.patch |  54 -
 ...ated-PowerPC-insns-aren-t-allowed-on.patch |  62 --
 ...eak_cmsg.stderr.exp-adjust-tmp-paths.patch |   2 +-
 ...ntext-APIs-are-not-available-on-musl.patch |  50 -
 .../valgrind/valgrind/fixed-perl-path.patch   |  20 +-
 .../valgrind/valgrind/run-ptest   |   3 +-
 .../valgrind/valgrind/s390x_vec_op_t.patch|  24 ++-
 ...{valgrind_3.16.1.bb => valgrind_3.17.0.bb} |  25 ++-
 12 files changed, 165 insertions(+), 426 deletions(-)
 create mode 100644 
meta/recipes-devtools/valgrind/valgrind/0001-Add-missing-musl.supp.patch
 delete mode 100644 
meta/recipes-devtools/valgrind/valgrind/0001-Fix-nlcontrolc.vgtest-hanging-on-newer-glibc-and-or-.patch
 delete mode 100644 
meta/recipes-devtools/valgrind/valgrind/0001-drd-Port-to-Fedora-33.patch
 delete mode 100644 
meta/recipes-devtools/valgrind/valgrind/0001-drd-musl-fix.patch
 delete mode 100644 
meta/recipes-devtools/valgrind/valgrind/0001-helgrind-Intercept-libc-functions.patch
 delete mode 100644 
meta/recipes-devtools/valgrind/valgrind/0001-lmw-lswi-and-related-PowerPC-insns-aren-t-allowed-on.patch
 rename meta/recipes-devtools/valgrind/{valgrind_3.16.1.bb => 
valgrind_3.17.0.bb} (92%)

diff --git 
a/meta/recipes-devtools/valgrind/valgrind/0001-Add-missing-musl.supp.patch 
b/meta/recipes-devtools/valgrind/valgrind/0001-Add-missing-musl.supp.patch
new file mode 100644
index 00..2a73f7e81f
--- /dev/null
+++ b/meta/recipes-devtools/valgrind/valgrind/0001-Add-missing-musl.supp.patch
@@ -0,0 +1,72 @@
+From 61bc8664f93cd980831c9da4a3e8a385b089a0ab Mon Sep 17 00:00:00 2001
+From: Yi Fan Yu 
+Date: Tue, 23 Mar 2021 09:32:22 -0700
+Subject: [PATCH] Add missing musl.supp
+
+3.17 did not ship musl.supp in the tarball.
+
+This is a workaround until next release.
+
+Upstream-Status: Backport [dde556d51f8226a6de564a00bf82536bb7042c54]
+
+Signed-off-by: Yi Fan Yu 
+---
+ musl.supp | 46 ++
+ 1 file changed, 46 insertions(+)
+ create mode 100644 musl.supp
+
+diff --git a/musl.supp b/musl.supp
+new file mode 100644
+index 0..864172a24
+--- /dev/null
 b/musl.supp
+@@ -0,0 +1,46 @@
++# Suppressions for musl libc
++# See: https://www.openwall.com/lists/musl/2017/06/15/4
++
++{
++   musl-dynlink-false-positive1
++   Memcheck:Leak
++   fun:calloc
++   fun:load_direct_deps
++   fun:load_deps
++   fun:load_deps
++   fun:__dls3
++   fun:__dls2b
++   fun:__dls2
++}
++
++{
++   musl-dynlink-false-positive2
++   Memcheck:Leak
++   fun:calloc
++   fun:load_direct_deps
++   fun:load_deps
++   fun:load_deps
++   fun:__dls3
++   fun:__dls2
++}
++
++{
++   musl-dynlink-false-positive3
++   Memcheck:Leak
++   fun:calloc
++   fun:load_library
++   fun:load_preload
++   fun:__dls3
++   fun:__dls2b
++   fun:__dls2
++}
++
++{
++   musl-dynlink-false-positive4
++   Memcheck:Leak
++   fun:calloc
++   fun:load_library
++   fun:load_preload
++   fun:__dls3
++   fun:__dls2
++}
+-- 
+2.17.1
+
diff --git 
a/meta/recipes-devtools/valgrind/valgrind/0001-Fix-nlcontrolc.vgtest-hanging-on-newer-glibc-and-or-.patch
 
b/meta/recipes-devtools/valgrind/valgrind/0001-Fix-nlcontrolc.vgtest-hanging-on-newer-glibc-and-or-.patch
deleted file mode 100644
index 98cbcd132c..00
--- 
a/meta/recipes-devtools/valgrind/valgrind/0001-Fix-nlcontrolc.vgtest-hanging-on-newer-glibc-and-or-.patch
+++ /dev/null
@@ -1,200 +0,0 @@
-From 83c24e31df6932a6d4fced179050c6d8d8c6f3b5 Mon Sep 17 00:00:00 2001
-From: Philippe Waroquiers 
-Date: Sun, 7 Mar 2021 22:29:27 +0100
-Subject: [PATCH] Fix nlcontrolc.vgtest hanging on newer glibc and/or arm64
-
-This test verifies that GDB can interrupt a process with all threads
-blocked in a long select syscall.
-The test used to terminate by having GDB modi

Re: [OE-core] [PATCH] populate_sdk_ext: Avoid copying and producing .pyc files

[Mark Hatle]

On 3/26/21 12:54 AM, Alexander Kanavin wrote:
> Wait, I have to say neither reason is convincing. Pyc files are not
> system-specific, they are the same on all systems. And pseudo issues should be
> dealt with by fixing the issue, not working around the symptoms, no?

These are pyc files that are generated by the host system python.  As such, they
contain versioning information of the particular host they were constructed on.

The next user (of the eSDK) would regenerate the pyc files, assuming their
python was a different version/configuration anyway.

The pseudo issue is simply caused by the generation of these files outside of
the pseudo context.  The three places modified need to run without pseudo
control in order to setup the bitbake (host) environment properly, as well as
verify that the previous files copied/setup are infact correct.

So we're not working around symptoms.. we are indeed fixing the underlying
issues in the implementation.  It just happened to be that I was able to
reproduce the build failure reliably for a time vs it just going away on it's 
own.

--Mark

> Alex
> 
> On Thu, 25 Mar 2021 at 23:44, Mark Hatle  > wrote:
> 
> Since pyc cache files are really system specific, no real reason to copy 
> or
> generate them during the eSDK build process.  Also generating them has the
> possibility of re-using inodes that pseudo may have been tracking, leading
> a build failure.
> 
> Signed-off-by: Mark Hatle  >
> ---
>  meta/classes/populate_sdk_ext.bbclass | 4 +++-
>  meta/lib/oe/copy_buildsystem.py       | 6 +++---
>  2 files changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/meta/classes/populate_sdk_ext.bbclass
> b/meta/classes/populate_sdk_ext.bbclass
> index 9112ab6c5e..14689ec6ac 100644
> --- a/meta/classes/populate_sdk_ext.bbclass
> +++ b/meta/classes/populate_sdk_ext.bbclass
> @@ -251,7 +251,9 @@ python copy_buildsystem () {
> 
>      # Create a layer for new recipes / appends
>      bbpath = d.getVar('BBPATH')
> -    bb.process.run(['devtool', '--bbpath', bbpath, '--basepath',
> baseoutpath, 'create-workspace', '--create-only', 
> os.path.join(baseoutpath,
> 'workspace')])
> +    env = os.environ.copy()
> +    env['PYTHONDONTWRITEBYTECODE'] = '1'
> +    bb.process.run(['devtool', '--bbpath', bbpath, '--basepath',
> baseoutpath, 'create-workspace', '--create-only', 
> os.path.join(baseoutpath,
> 'workspace')], env=env)
> 
>      # Create bblayers.conf
>      bb.utils.mkdirhier(baseoutpath + '/conf')
> diff --git a/meta/lib/oe/copy_buildsystem.py 
> b/meta/lib/oe/copy_buildsystem.py
> index 31a84f5b06..d97bf9d1b9 100644
> --- a/meta/lib/oe/copy_buildsystem.py
> +++ b/meta/lib/oe/copy_buildsystem.py
> @@ -20,7 +20,7 @@ def _smart_copy(src, dest):
>      mode = os.stat(src).st_mode
>      if stat.S_ISDIR(mode):
>          bb.utils.mkdirhier(dest)
> -        cmd = "tar --exclude='.git' --xattrs --xattrs-include='*' -chf - 
> -C
> %s -p . \
> +        cmd = "tar --exclude='.git' --exclude='__pycache__' --xattrs
> --xattrs-include='*' -chf - -C %s -p . \
>          | tar --xattrs --xattrs-include='*' -xf - -C %s" % (src, dest)
>          subprocess.check_output(cmd, shell=True, 
> stderr=subprocess.STDOUT)
>      else:
> @@ -259,7 +259,7 @@ def create_locked_sstate_cache(lockedsigs,
> input_sstate_cache, output_sstate_cac
>      bb.note('Generating sstate-cache...')
> 
>      nativelsbstring = d.getVar('NATIVELSBSTRING')
> -    bb.process.run("gen-lockedsig-cache %s %s %s %s %s" % (lockedsigs,
> input_sstate_cache, output_sstate_cache, nativelsbstring, filterfile or 
> ''))
> +    bb.process.run("PYTHONDONTWRITEBYTECODE=1 gen-lockedsig-cache %s %s 
> %s
> %s %s" % (lockedsigs, input_sstate_cache, output_sstate_cache,
> nativelsbstring, filterfile or ''))
>      if fixedlsbstring and nativelsbstring != fixedlsbstring:
>          nativedir = output_sstate_cache + '/' + nativelsbstring
>          if os.path.isdir(nativedir):
> @@ -286,7 +286,7 @@ def check_sstate_task_list(d, targets, filteroutfile,
> cmdprefix='', cwd=None, lo
>          logparam = '-l %s' % logfile
>      else:
>          logparam = ''
> -    cmd = "%sBB_SETSCENE_ENFORCE=1 PSEUDO_DISABLED=1 oe-check-sstate %s 
> -s
> -o %s %s" % (cmdprefix, targets, filteroutfile, logparam)
> +    cmd = "%sPYTHONDONTWRITEBYTECODE=1 BB_SETSCENE_ENFORCE=1
> PSEUDO_DISABLED=1 oe-check-sstate %s -s -o %s %s" % (cmdprefix, targets,
> filteroutfile, logparam)
>      env = dict(d.getVar('BB_ORIGENV', False))
>      env.pop('BUILDDIR', '')
>      env.pop('BBPATH', '')
> -- 
> 2.17.1
> 
> 
> 
> 
> 
> 
> 
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View

Re: [OE-core] [poky][dunfell][PATCH] buildhistory.bbclass: store MAINTAINER variable

[Martin Jansa]

This change isn't in master nor gatesgarth.

On Fri, Mar 26, 2021 at 2:46 PM Purushottam choudhary <
purushottam.choudh...@kpit.com> wrote:

> The maintainer declaration in the buildhistory
> is useful for tracking the maintainer of recipes.
> This change adds the MAINTAINER variable for
> recipes and packages to its buildhistory data.
>
> Signed-off-by: Purushottam Choudhary 
> ---
>  meta/classes/buildhistory.bbclass | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/meta/classes/buildhistory.bbclass
> b/meta/classes/buildhistory.bbclass
> index 8a1359a..04fac82 100644
> --- a/meta/classes/buildhistory.bbclass
> +++ b/meta/classes/buildhistory.bbclass
> @@ -109,6 +109,7 @@ python buildhistory_emit_pkghistory() {
>  self.pe = "0"
>  self.pv = "0"
>  self.pr = "r0"
> +self.maintainer = ""
>  self.depends = ""
>  self.packages = ""
>  self.srcrev = ""
> @@ -126,6 +127,7 @@ python buildhistory_emit_pkghistory() {
>  self.pkge = ""
>  self.pkgv = ""
>  self.pkgr = ""
> +self.maintainer = ""
>  self.size = 0
>  self.depends = ""
>  self.rprovides = ""
> @@ -162,6 +164,8 @@ python buildhistory_emit_pkghistory() {
>  pkginfo.pkgv = value
>  elif name == "PKGR":
>  pkginfo.pkgr = value
> +elif name == "MAINTAINER":
> +pkginfo.maintainer = value
>  elif name == "RPROVIDES":
>  pkginfo.rprovides = value
>  elif name == "RDEPENDS":
> @@ -215,6 +219,7 @@ python buildhistory_emit_pkghistory() {
>  pr = d.getVar('PR')
>  layer = bb.utils.get_file_layer(d.getVar('FILE'), d)
>
> +maintainer = d.getVar('MAINTAINER') or ''
>  pkgdata_dir = d.getVar('PKGDATA_DIR')
>  packages = ""
>  try:
> @@ -251,6 +256,7 @@ python buildhistory_emit_pkghistory() {
>  rcpinfo.pe = pe
>  rcpinfo.pv = pv
>  rcpinfo.pr = pr
> +rcpinfo.maintainer = maintainer
>  rcpinfo.depends = sortlist(oe.utils.squashspaces(d.getVar('DEPENDS')
> or ""))
>  rcpinfo.packages = packages
>  rcpinfo.layer = layer
> @@ -270,6 +276,7 @@ python buildhistory_emit_pkghistory() {
>  pkge = pkgdata.get('PKGE', '0')
>  pkgv = pkgdata['PKGV']
>  pkgr = pkgdata['PKGR']
> +pkg_maintainer = d.getVar('MAINTAINER_%s' % (pkg,), True) or
> maintainer
>  #
>  # Find out what the last version was
>  # Make sure the version did not decrease
> @@ -293,6 +300,7 @@ python buildhistory_emit_pkghistory() {
>  pkginfo.pkge = pkge
>  pkginfo.pkgv = pkgv
>  pkginfo.pkgr = pkgr
> +pkginfo.maintainer = pkg_maintainer
>  pkginfo.rprovides =
> sortpkglist(oe.utils.squashspaces(pkgdata.get('RPROVIDES', "")))
>  pkginfo.rdepends =
> sortpkglist(oe.utils.squashspaces(pkgdata.get('RDEPENDS', "")))
>  pkginfo.rrecommends =
> sortpkglist(oe.utils.squashspaces(pkgdata.get('RRECOMMENDS', "")))
> @@ -368,6 +376,7 @@ def write_recipehistory(rcpinfo, d):
>  f.write(u"DEPENDS = %s\n" %  rcpinfo.depends)
>  f.write(u"PACKAGES = %s\n" %  rcpinfo.packages)
>  f.write(u"LAYER = %s\n" %  rcpinfo.layer)
> +f.write(u"MAINTAINER = %s\n" % rcpinfo.maintainer)
>
>  write_latest_srcrev(d, pkghistdir)
>
> @@ -386,6 +395,7 @@ def write_pkghistory(pkginfo, d):
>  f.write(u"PE = %s\n" %  pkginfo.pe)
>  f.write(u"PV = %s\n" %  pkginfo.pv)
>  f.write(u"PR = %s\n" %  pkginfo.pr)
> +f.write(u"MAINTAINER = %s\n" % pkginfo.maintainer)
>
>  if pkginfo.pkg != pkginfo.name:
>  f.write(u"PKG = %s\n" % pkginfo.pkg)
> --
> 2.7.4
>
> This message contains information that may be privileged or confidential
> and is the property of the KPIT Technologies Ltd. It is intended only for
> the person to whom it is addressed. If you are not the intended recipient,
> you are not authorized to read, print, retain copy, disseminate,
> distribute, or use this message or any part thereof. If you receive this
> message in error, please notify the sender immediately and delete all
> copies of this message. KPIT Technologies Ltd. does not accept any
> liability for virus infected mails.
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149983): 
https://lists.openembedded.org/g/openembedded-core/message/149983
Mute This Topic: https://lists.openembedded.org/mt/81628110/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [poky][dunfell][PATCH] buildhistory.bbclass: store MAINTAINER variable

[Purushottam choudhary]

The maintainer declaration in the buildhistory
is useful for tracking the maintainer of recipes.
This change adds the MAINTAINER variable for
recipes and packages to its buildhistory data.

Signed-off-by: Purushottam Choudhary 
---
 meta/classes/buildhistory.bbclass | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/meta/classes/buildhistory.bbclass 
b/meta/classes/buildhistory.bbclass
index 8a1359a..04fac82 100644
--- a/meta/classes/buildhistory.bbclass
+++ b/meta/classes/buildhistory.bbclass
@@ -109,6 +109,7 @@ python buildhistory_emit_pkghistory() {
 self.pe = "0"
 self.pv = "0"
 self.pr = "r0"
+self.maintainer = ""
 self.depends = ""
 self.packages = ""
 self.srcrev = ""
@@ -126,6 +127,7 @@ python buildhistory_emit_pkghistory() {
 self.pkge = ""
 self.pkgv = ""
 self.pkgr = ""
+self.maintainer = ""
 self.size = 0
 self.depends = ""
 self.rprovides = ""
@@ -162,6 +164,8 @@ python buildhistory_emit_pkghistory() {
 pkginfo.pkgv = value
 elif name == "PKGR":
 pkginfo.pkgr = value
+elif name == "MAINTAINER":
+pkginfo.maintainer = value
 elif name == "RPROVIDES":
 pkginfo.rprovides = value
 elif name == "RDEPENDS":
@@ -215,6 +219,7 @@ python buildhistory_emit_pkghistory() {
 pr = d.getVar('PR')
 layer = bb.utils.get_file_layer(d.getVar('FILE'), d)

+maintainer = d.getVar('MAINTAINER') or ''
 pkgdata_dir = d.getVar('PKGDATA_DIR')
 packages = ""
 try:
@@ -251,6 +256,7 @@ python buildhistory_emit_pkghistory() {
 rcpinfo.pe = pe
 rcpinfo.pv = pv
 rcpinfo.pr = pr
+rcpinfo.maintainer = maintainer
 rcpinfo.depends = sortlist(oe.utils.squashspaces(d.getVar('DEPENDS') or 
""))
 rcpinfo.packages = packages
 rcpinfo.layer = layer
@@ -270,6 +276,7 @@ python buildhistory_emit_pkghistory() {
 pkge = pkgdata.get('PKGE', '0')
 pkgv = pkgdata['PKGV']
 pkgr = pkgdata['PKGR']
+pkg_maintainer = d.getVar('MAINTAINER_%s' % (pkg,), True) or maintainer
 #
 # Find out what the last version was
 # Make sure the version did not decrease
@@ -293,6 +300,7 @@ python buildhistory_emit_pkghistory() {
 pkginfo.pkge = pkge
 pkginfo.pkgv = pkgv
 pkginfo.pkgr = pkgr
+pkginfo.maintainer = pkg_maintainer
 pkginfo.rprovides = 
sortpkglist(oe.utils.squashspaces(pkgdata.get('RPROVIDES', "")))
 pkginfo.rdepends = 
sortpkglist(oe.utils.squashspaces(pkgdata.get('RDEPENDS', "")))
 pkginfo.rrecommends = 
sortpkglist(oe.utils.squashspaces(pkgdata.get('RRECOMMENDS', "")))
@@ -368,6 +376,7 @@ def write_recipehistory(rcpinfo, d):
 f.write(u"DEPENDS = %s\n" %  rcpinfo.depends)
 f.write(u"PACKAGES = %s\n" %  rcpinfo.packages)
 f.write(u"LAYER = %s\n" %  rcpinfo.layer)
+f.write(u"MAINTAINER = %s\n" % rcpinfo.maintainer)

 write_latest_srcrev(d, pkghistdir)

@@ -386,6 +395,7 @@ def write_pkghistory(pkginfo, d):
 f.write(u"PE = %s\n" %  pkginfo.pe)
 f.write(u"PV = %s\n" %  pkginfo.pv)
 f.write(u"PR = %s\n" %  pkginfo.pr)
+f.write(u"MAINTAINER = %s\n" % pkginfo.maintainer)

 if pkginfo.pkg != pkginfo.name:
 f.write(u"PKG = %s\n" % pkginfo.pkg)
--
2.7.4

This message contains information that may be privileged or confidential and is 
the property of the KPIT Technologies Ltd. It is intended only for the person 
to whom it is addressed. If you are not the intended recipient, you are not 
authorized to read, print, retain copy, disseminate, distribute, or use this 
message or any part thereof. If you receive this message in error, please 
notify the sender immediately and delete all copies of this message. KPIT 
Technologies Ltd. does not accept any liability for virus infected mails.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149982): 
https://lists.openembedded.org/g/openembedded-core/message/149982
Mute This Topic: https://lists.openembedded.org/mt/81628110/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] [RFC] ffmpeg: make LICENSE_FLAGS fine-grained

[Yann Dirson]

Le jeu. 25 mars 2021 à 14:44, Yann Dirson via lists.openembedded.org
 a écrit :
>
> Hi Alex,
>
> Le mar. 23 mars 2021 à 17:42, Alexander Kanavin
>  a écrit :
> >
> > Is it possible to further split the NONCOMMERCIAL_PACKAGECONFIGS into ones 
> > that are enabled and disabled, and use the former in PACKAGECONFIG itself?
>
> You mean something like this ?
>
> # PACKAGECONFIG features that do not pull codecs
> NONCOMMERCIAL_DEFAULT_PACKAGECONFIGS = " \
>  avdevice avfilter avformat swresample swscale postproc avresample \
>  alsa bzlib drm gpl lzma pic pthreads shared zlib \
>  ${@bb.utils.contains('AVAILTUNES', 'mips32r2', 'mips32r2', '', d)} \
>  ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'xv xcb', '', d)} \
> "
> NONCOMMERCIAL_NONDEFAULT_PACKAGECONFIGS = " \
>  altivec bzlib gsm jack openssl sdl2 \
> "
>
> PACKAGECONFIG ??= "avcodec theora \
>${NONCOMMERCIAL_DEFAULT_PACKAGECONFIGS}"
>
> I admit I'm not completely sure about every feature's status.
>
> I tend to think that if ffmpeg relies on a lib providing an
> implementation, and there
> are patent-related risks, it should that lib setting a LICENSE_FLAG.
> Eg. x264 and others
> already sets the "commercial" flag, so I'm tempted to not add a
> duplicate flag in
> ffmpeg (in the same spirit as my patches against gst-libav and mpv).
> Would it be
> good enough ?

On second thought, it appears the only PACKAGECONFIG feature bringing
codecs and not backed by a lib is just "avcodec".

Thus we could probably just use:

LICENSE_FLAGS = "${@bb.utils.contains('PACKAGECONFIG', 'avcodec',
'commercial', '', d)}"

We would possibly not even need to set EXCLUDE_FROM_WORLD on this one, since the
default PACKAGECONFIG would still set the "commercial" flag, right ?

>
> >
> >
> > Alex
> >
> > On Tue, 23 Mar 2021 at 17:38, Yann Dirson  
> > wrote:
> >>
> >> From: Yann Dirson 
> >>
> >> The rationale here is that if the user can only whitelist "commercial"
> >> to use any part of ffmpeg, even it the list of features is carefully
> >> reviewed when switching the whitelisting on, there was nothing to
> >> guard from inadvertently activating a new feature that would not have
> >> been reviewed.
> >>
> >> This patch adds one LICENSE_FLAGS value for each feature, except for
> >> those that bring no codec, trying to be on the same level of legal
> >> safety - but then I may miss something.
> >>
> >> I tried to leave out of the safe NONCOMMERCIAL_PACKAGECONFIGS list
> >> anything that brings a codec, notably libavcodec.  I also did not look
> >> at non-default features yet.
> >>
> >> There may still be a problem if any feature in ffmpeg gets activated
> >> by default upstream and not registed as a PACKAGECONFIG feature.  At
> >> least any of those that depend on another lib would not be enabled,
> >> that could be seen as a sufficient safeguard.
> >> ---
> >>  meta/recipes-multimedia/ffmpeg/ffmpeg_4.3.2.bb | 12 +++-
> >>  1 file changed, 11 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/meta/recipes-multimedia/ffmpeg/ffmpeg_4.3.2.bb 
> >> b/meta/recipes-multimedia/ffmpeg/ffmpeg_4.3.2.bb
> >> index 08be38ca50..3a36c95151 100644
> >> --- a/meta/recipes-multimedia/ffmpeg/ffmpeg_4.3.2.bb
> >> +++ b/meta/recipes-multimedia/ffmpeg/ffmpeg_4.3.2.bb
> >> @@ -16,7 +16,17 @@ LICENSE_libavutil = 
> >> "${@bb.utils.contains('PACKAGECONFIG', 'gpl', 'GPLv2+', 'LGP
> >>  LICENSE_libpostproc = "GPLv2+"
> >>  LICENSE_libswresample = "${@bb.utils.contains('PACKAGECONFIG', 'gpl', 
> >> 'GPLv2+', 'LGPLv2.1+', d)}"
> >>  LICENSE_libswscale = "${@bb.utils.contains('PACKAGECONFIG', 'gpl', 
> >> 'GPLv2+', 'LGPLv2.1+', d)}"
> >> -LICENSE_FLAGS = "commercial"
> >> +
> >> +# PACKAGECONFIG features that do not pull codecs
> >> +NONCOMMERCIAL_PACKAGECONFIGS = " \
> >> + alsa bzlib drm gpl lzma zlib xcb xv \
> >> + avdevice avfilter avformat swresample swscale postproc avresample \
> >> +"
> >> +# An ffmpeg feature not in NONCOMMERCIAL_PACKAGECONFIGS should be 
> >> explicitly whitelisted.
> >> +# See https://ffmpeg.org/legal.html
> >> +LICENSE_FLAGS = "${@' '.join('commercial_' + cfg \
> >> + for cfg in '${PACKAGECONFIG}'.split() \
> >> + if cfg not in 
> >> '${NONCOMMERCIAL_PACKAGECONFIGS}'.split())}"
> >>
> >>  LIC_FILES_CHKSUM = 
> >> "file://COPYING.GPLv2;md5=b234ee4d69f5fce4486a80fdaf4a4263 \
> >>  
> >> file://COPYING.GPLv3;md5=d32239bcb673463ab874e80d47fae504 \
> >> --
> >> 2.30.2
> >>
> >>
> >>
> >>
>
>
> --
> Yann Dirson 
> Blade / Shadow -- http://shadow.tech
>
> 
>


-- 
Yann Dirson 
Blade / Shadow -- http://shadow.tech

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149981): 
https://lists.openembedded.org/g/openembedded-core/message/149981
Mute This Topic: https://lists.openembedded.org/mt/81555357/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arc

Re: [OE-core] [PATCH] gst-examples,gstreamer1.0-libav: Add option to exclude from world build

[Yann Dirson]

Hi Khem,

Le ven. 26 mars 2021 à 02:07, Khem Raj  a écrit :
>
> When LICENSE_FLAGS_WHITELIST does not have commercial in it then the
> the dependencies like ffmpeg will become invisible and render these
> packages unbuildable, therefore world build will report parse issues
>
> its better to exclude them from world build in such cases
>
> Signed-off-by: Khem Raj 
> Cc: Yann Dirson 
> ---
>  meta/recipes-multimedia/gstreamer/gst-examples_1.18.4.bb   | 2 ++
>  meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.18.4.bb | 3 +++
>  2 files changed, 5 insertions(+)
>
> diff --git a/meta/recipes-multimedia/gstreamer/gst-examples_1.18.4.bb 
> b/meta/recipes-multimedia/gstreamer/gst-examples_1.18.4.bb
> index 4670ab34db..196258e00f 100644
> --- a/meta/recipes-multimedia/gstreamer/gst-examples_1.18.4.bb
> +++ b/meta/recipes-multimedia/gstreamer/gst-examples_1.18.4.bb
> @@ -33,3 +33,5 @@ RRECOMMENDS_${PN} = "gstreamer1.0-plugins-base-meta \
>${@bb.utils.contains("LICENSE_FLAGS_WHITELIST", 
> "commercial", "gstreamer1.0-libav", "", d)} \
>   ${@bb.utils.contains("LICENSE_FLAGS_WHITELIST", 
> "commercial", "gstreamer1.0-plugins-ugly-meta", "", d)}"
>  RPROVIDES_${PN} += "gst-player gst-player-bin"
> +
> +EXCLUDE_FROM_WORLD = "${@bb.utils.contains("LICENSE_FLAGS_WHITELIST", 
> "commercial", "0", "1", d)}"
> diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.18.4.bb 
> b/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.18.4.bb
> index 6a84f92f31..7c39e7da37 100644
> --- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.18.4.bb
> +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.18.4.bb
> @@ -6,6 +6,7 @@ SECTION = "multimedia"
>
>  # ffmpeg has comercial license flags so add it as we need ffmpeg as a 
> dependency
>  LICENSE_FLAGS = "commercial"
> +

The LICENSE_FLAGS can then be dropped here, right ?

>  LICENSE = "LGPLv2+"
>  LIC_FILES_CHKSUM = "file://COPYING;md5=6762ed442b3822387a51c92d928ead0d \
>  
> file://ext/libav/gstav.h;beginline=1;endline=18;md5=a752c35267d8276fd9ca3db6994fca9c
>  \
> @@ -22,3 +23,5 @@ inherit meson pkgconfig upstream-version-is-even
>
>  FILES_${PN} += "${libdir}/gstreamer-1.0/*.so"
>  FILES_${PN}-staticdev += "${libdir}/gstreamer-1.0/*.a"
> +
> +EXCLUDE_FROM_WORLD = "${@bb.utils.contains("LICENSE_FLAGS_WHITELIST", 
> "commercial", "0", "1", d)}"
> --
> 2.31.0
>


-- 
Yann Dirson 
Blade / Shadow -- http://shadow.tech

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149980): 
https://lists.openembedded.org/g/openembedded-core/message/149980
Mute This Topic: https://lists.openembedded.org/mt/81618084/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [qa-build-notification] QA notification for completed autobuilder build (yocto-3.3_M3.rc2)

[Sangeeta Jain]

Hi All,

This is the full report for yocto-3.3_M3.rc2:
https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults

=== Summary 
No high milestone defects.

No new issue found:


Bugs verified:

BUG id:14306 - [3.3 M3 rc1] beaglebone poky-alt wic image can not bootup 
   Verified Fixed.

=== Bugs 
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14306

Thanks,
Sangeeta

> -Original Message-
> From: qa-build-notificat...@lists.yoctoproject.org  notificat...@lists.yoctoproject.org> On Behalf Of Pokybuild User
> Sent: Wednesday, 24 March, 2021 12:01 PM
> To: yo...@lists.yoctoproject.org
> Cc: qa-build-notificat...@lists.yoctoproject.org
> Subject: [qa-build-notification] QA notification for completed autobuilder 
> build
> (yocto-3.3_M3.rc2)
> 
> 
> A build flagged for QA (yocto-3.3_M3.rc2) was completed on the autobuilder
> and is available at:
> 
> 
> https://autobuilder.yocto.io/pub/releases/yocto-3.3_M3.rc2
> 
> 
> Build hash information:
> 
> bitbake: ed8e1fd4cf9d5ac8a8203638add99d686b4b3521
> meta-arm: ac1dc0b894642101a80235a920bdc3bbe6d74558
> meta-gplv2: 9e119f333cc8f53bd3cf64326f826dbc6ce3db0f
> meta-intel: 6fea44c695730129df8bd744b0e22ccd62a725c2
> meta-kernel: 29329d7cacc71595cecfdd05a455a0cfb164564d
> meta-mingw: 422b96cb2b6116442be1f40dfb5bd77447d1219e
> oecore: 7ae12e4278e98c5b916a1067ae0b48c2da6e82cd
> poky: ea455ca8671d3bc2a1097989bfaabe92f3ca37ab
> 
> 
> 
> This is an automated message from the Yocto Project Autobuilder
> Git: git://git.yoctoproject.org/yocto-autobuilder2
> Email: richard.pur...@linuxfoundation.org
> 
> 
> 
> 
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149979): 
https://lists.openembedded.org/g/openembedded-core/message/149979
Mute This Topic: https://lists.openembedded.org/mt/81571069/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-