[OE-core] [PATCH] python3-numpy: upgrade 1.20.3 -> 1.21.0

refresh 0001-Don-t-search-usr-and-so-on-for-libraries-by-default-.patch License-Updage: Copyright year updated to 2021 Signed-off-by: Wang Mingyu --- ...-and-so-on-for-libraries-by-default-.patch | 19 +-- ...umpy_1.20.3.bb => python3-numpy_1.21.0.bb} | 4 ++-- 2 files changed,

[OE-core] [PATCH] libva: upgrade 2.11.0 -> 2.12.0

Signed-off-by: Wang Mingyu --- .../libva/{libva-initial_2.11.0.bb => libva-initial_2.12.0.bb} | 0 .../libva/{libva-utils_2.11.1.bb => libva-utils_2.12.0.bb} | 0 meta/recipes-graphics/libva/libva.inc | 2 +- .../recipes-graphics/libva/{libva_2.11.0.bb => libva_2.1

[OE-core] [PATCH] libxcrypt: upgrade 4.4.22 -> 4.4.23

Signed-off-by: Wang Mingyu --- .../{libxcrypt-compat_4.4.22.bb => libxcrypt-compat_4.4.23.bb} | 0 meta/recipes-core/libxcrypt/libxcrypt.inc | 2 +- .../libxcrypt/{libxcrypt_4.4.22.bb => libxcrypt_4.4.23.bb} | 0 3 files changed, 1 insertion(+), 1 deletion(-) rename m

[OE-core] [PATCH] libhandy: upgrade 1.2.2 -> 1.2.3

Signed-off-by: Wang Mingyu --- .../libhandy/{libhandy_1.2.2.bb => libhandy_1.2.3.bb} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename meta/recipes-gnome/libhandy/{libhandy_1.2.2.bb => libhandy_1.2.3.bb} (92%) diff --git a/meta/recipes-gnome/libhandy/libhandy_1.2.2.bb b

[OE-core] [PATCH] libcap: upgrade 2.50 -> 2.51

refresh 0001-tests-do-not-statically-link-a-test.patch Signed-off-by: Wang Mingyu --- .../0001-tests-do-not-statically-link-a-test.patch | 10 ++ .../libcap/{libcap_2.50.bb => libcap_2.51.bb} | 2 +- 2 files changed, 7 insertions(+), 5 deletions(-) rename meta/recipes-supp

Re: [OE-core][PATCH 1/2] kernel.bbclass: run read_package_metadata only if packaging is enabled

On Wed, Jun 23, 2021 at 12:52 AM Richard Purdie wrote: > > On Wed, 2021-06-23 at 00:18 +0200, Andrea Adami wrote: > > As exposed in the ML > > https://lists.openembedded.org/g/openembedded-core/message/153000 > > > > up to commit 86142da in Gatesgarth it was possible to build a second > > mini-ke

Re: [OE-core][PATCH 1/2] kernel.bbclass: run read_package_metadata only if packaging is enabled

On Wed, 2021-06-23 at 00:18 +0200, Andrea Adami wrote: > As exposed in the ML > https://lists.openembedded.org/g/openembedded-core/message/153000 > > up to commit 86142da in Gatesgarth it was possible to build a second > mini-kernel w/out > modules to be just deployed and collected by other recip

[OE-core][PATCH 2/2] kernel.bbclass: inherit kernel_devicetree only if KERNEL_DEVICETREE is set

Now it unconditionally tries to create package kernel-devicetre even for legacy devices w/out DT. Signed-off-by: Andrea Adami --- meta/classes/kernel.bbclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass index 06e644

[OE-core][PATCH 1/2] kernel.bbclass: run read_package_metadata only if packaging is enabled

As exposed in the ML https://lists.openembedded.org/g/openembedded-core/message/153000 up to commit 86142da in Gatesgarth it was possible to build a second mini-kernel w/out modules to be just deployed and collected by other recipes. These kernels use special care to avoid packaging: inherit no

Re: [OE-core][PATCH] README.skeleton: add readme to meta-skeleton layer

I didn't see that this patch was picked up (but maybe I'm looking in the wrong place) and I received the email from Stephen that the issue should be moved to 3.4 M2. Did I send this to the wrong mailing list or is it not the solution you're looking for? I elaborated in bugzilla on why I think just

Re: [OE-core][PATCH 1/2] python3-pip: upgrade 20.0.2 -> 21.1.2

On 2021-06-22 2:47 p.m., Alexander Kanavin wrote: **[Please note: This e-mail is from an EXTERNAL e-mail address] Ah, because pypi.bbclass sets SRC_URI += instead of =. I'll queue a patch to fix the class. Right, Tim noticed this too and I re-submitted a v2 of this patch to fix the orderin

[OE-core] [PATCH] pypi: set SRC_URI with =, not with +=

This did not cause problems in builds, but broke some devtool workflows such as version upgrades or checking the latest version from upstream. Tarballs should come first, not the patches. Signed-off-by: Alexander Kanavin --- meta/classes/pypi.bbclass | 2 +- 1 file changed, 1 insertion(+), 1 del

Re: [OE-core][PATCH 1/2] python3-pip: upgrade 20.0.2 -> 21.1.2

Ah, because pypi.bbclass sets SRC_URI += instead of =. I'll queue a patch to fix the class. Alex On Tue, 22 Jun 2021 at 20:44, Alexander Kanavin via lists.openembedded.org wrote: > Can you please check why 'devtool check-upgrade-status' wasn't able to > report that all these new versions have b

Re: [OE-core][PATCH 1/2] python3-pip: upgrade 20.0.2 -> 21.1.2

Can you please check why 'devtool check-upgrade-status' wasn't able to report that all these new versions have been available? Alex On Tue, 22 Jun 2021 at 19:37, Trevor Gamblin wrote: > 21.1.2 contains a fix for CVE-2021-3572 > ( > https://github.com/pypa/pip/commit/e46bdda9711392fec0c45c1175ba

[OE-core][PATCH v2] python3-pip: upgrade 20.0.2 -> 21.1.2

21.1.2 contains a fix for CVE-2021-3572 (https://github.com/pypa/pip/commit/e46bdda9711392fec0c45c1175bae6db847cb30b) The LICENSE.txt signature changed due to an update to the copyright dates, but the terms are the same. Also update 0001-change-shebang-to-python3.patch to cover all files in pip's

Re: [OE-core][PATCH 1/2] python3-pip: upgrade 20.0.2 -> 21.1.2

On 2021-06-22 1:37 p.m., Trevor Gamblin wrote: 21.1.2 contains a fix for CVE-2021-3572 (https://github.com/pypa/pip/commit/e46bdda9711392fec0c45c1175bae6db847cb30b) The LICENSE.txt signature changed due to an update to the copyright dates, but the terms are the same. Also update 0001-change-sh

Re: [OE-core] [RFC PATCH 1/2] glibc: backport MTE improvements from master

On Tue, 22 Jun 2021 at 17:53, Khem Raj wrote: > This looks fine, I have been using master/2.34 so did not see this > issue, at this time I do have 2.34 ready for testing here [1] Yes, I can verify that your staging branch with 2.34 is also good. Ross -=-=-=-=-=-=-=-=-=-=-=- Links: You receive a

[OE-core][PATCH 1/2] python3-pip: upgrade 20.0.2 -> 21.1.2

21.1.2 contains a fix for CVE-2021-3572 (https://github.com/pypa/pip/commit/e46bdda9711392fec0c45c1175bae6db847cb30b) The LICENSE.txt signature changed due to an update to the copyright dates, but the terms are the same. Also update 0001-change-shebang-to-python3.patch to cover all files in pip's

[OE-core][PATCH 2/2] python3-pip: add multiprocessing to RDEPENDS

Without it, simple invocations like "pip3 list" will fail with a ModuleNotFoundError for multiprocessing. Signed-off-by: Trevor Gamblin --- meta/recipes-devtools/python/python3-pip_21.1.2.bb | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/recipes-devtools/python/python3-pip_21.1.2.bb b

Re: [OE-core] [RFC PATCH 1/2] glibc: backport MTE improvements from master

Hi Ross This looks fine, I have been using master/2.34 so did not see this issue, at this time I do have 2.34 ready for testing here [1] [1] https://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/glibc-2.34 On 6/22/21 9:24 AM, Ross Burton wrote: After realising that the MTE s

[OE-core] [RFC PATCH 1/2] glibc: backport MTE improvements from master

After realising that the MTE support in 2.33 was suboptimal, discussion with upstream revealed that these issues are known and already fixed. They will be in glibc 2.34 which is scheduled for August, so backport the fixes for now. Signed-off-by: Ross Burton --- .../glibc/glibc/mte-backports.pat

[OE-core] [RFC PATCH 2/2] glibc: re-enable memory tagging

Now that the performance regressions caused by MTE have been resolved, we can enable memory tagging again. It is safe to globally enable the config as glibc does nothing if it isn't supported on that target. Signed-off-by: Ross Burton --- meta/recipes-core/glibc/glibc_2.33.bb | 2 +- 1 file cha

[OE-core] [RFC PATCH 2/2] glibc: re-enable memory tagging

Now that the performance regressions caused by MTE have been resolved, we can enable memory tagging again. It is safe to globally enable the config as glibc does nothing if it isn't supported on that target. Signed-off-by: Ross Burton --- meta/recipes-core/glibc/glibc_2.33.bb | 2 +- 1 file cha

[oe-core][dunfell][PATCH v3] libx11: Fix CVE-2021-31535

https://lists.x.org/archives/xorg-announce/2021-May/003088.html XLookupColor() and other X libraries function lack proper validation of the length of their string parameters. If those parameters can be controlled by an external application (for instance a color name that can be emitted via a termi

[OE-core] Yocto Project Status WW25`21

Current Dev Position: YP 3.4 M2 Next Deadline: 12th July 2021 YP 3.4 M2 build Next Team Meetings: * Bug Triage meeting Thursday June 24th at 7:30am PDT ( https://zoom.us/j/454367603?pwd=ZGxoa2ZXL3FkM3Y0bFd5aVpHVVZ6dz09)

Re: [oe-core][dunfell][PATCH v2] libx11: Fix CVE-2021-31535

Obviously, patch files in patch files still confuse me... :D v3 on it's way! On 22 June 2021 16:30:40 CEST, Steve Sakoman wrote: >On Tue, Jun 22, 2021 at 2:09 AM Jasper Orschulko via >lists.openembedded.org >wrote: >> >> https://lists.x.org/archives/xorg-announce/2021-May/003088.html >> >> XLook

Re: [oe-core][dunfell][PATCH v2] libxml2: Fix CVE-2021-3518

On Mon, Jun 21, 2021 at 5:34 AM Jasper Orschulko via lists.openembedded.org wrote: > > There's a flaw in libxml2 in versions before 2.9.11. An attacker who is able > to submit a crafted file to be processed by an application linked with > libxml2 could trigger a use-after-free. The greatest impa

Re: [oe-core][dunfell][PATCH v2] libx11: Fix CVE-2021-31535

On Tue, Jun 22, 2021 at 2:09 AM Jasper Orschulko via lists.openembedded.org wrote: > > https://lists.x.org/archives/xorg-announce/2021-May/003088.html > > XLookupColor() and other X libraries function lack proper validation > of the length of their string parameters. If those parameters can be > c

Re: [OE-core][PATCH] ca-certificates: revert mktemp patch in update-ca-certificates script

On Tue, 2021-06-22 at 14:15 +0200, Andrej Valek wrote: > - revert f3eabbb5c15fb55ae3d46b2377c09bb58226d965 > - mktemp from busybox does not support '--tmpdir' option > - coreutils is usually not possible to use because of 'GPLv3+' LICENSE I suspect the better long term solution here is to submit a

Re: [OE-core][PATCH] ca-certificates: revert mktemp patch in update-ca-certificates script

On Tue, Jun 22, 2021 at 8:16 AM Andrej Valek wrote: > > - revert f3eabbb5c15fb55ae3d46b2377c09bb58226d965 > - mktemp from busybox does not support '--tmpdir' option > - coreutils is usually not possible to use because of 'GPLv3+' LICENSE This should say "coreutils may not be possible" .. many fol

Re: [OE-core][PATCH] ca-certificates: revert mktemp patch in update-ca-certificates script

This submission is modifying two different patch files (one of which I think should not be touched), and reverting something that was already accepted upstream. I would suggest that you first take latest upstream code, then do any needed modifications there, then submit them upstream and backport t

[OE-core][PATCH] ca-certificates: revert mktemp patch in update-ca-certificates script

- revert f3eabbb5c15fb55ae3d46b2377c09bb58226d965 - mktemp from busybox does not support '--tmpdir' option - coreutils is usually not possible to use because of 'GPLv3+' LICENSE Signed-off-by: Andrej Valek --- .../ca-certificates/ca-certificates/sbindir.patch | 10 ++ .../update-ca-cer

[oe-core][dunfell][PATCH v2] libx11: Fix CVE-2021-31535

https://lists.x.org/archives/xorg-announce/2021-May/003088.html XLookupColor() and other X libraries function lack proper validation of the length of their string parameters. If those parameters can be controlled by an external application (for instance a color name that can be emitted via a termi

[oe-core][dunfell][PATCH] libx11: Fix CVE-2021-31535

https://lists.x.org/archives/xorg-announce/2021-May/003088.html XLookupColor() and other X libraries function lack proper validation of the length of their string parameters. If those parameters can be controlled by an external application (for instance a color name that can be emitted via a termi

[OE-core] [PATCH 18/19] x264: upgrade to latest revision

Signed-off-by: Alexander Kanavin --- meta/recipes-multimedia/x264/x264_git.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-multimedia/x264/x264_git.bb b/meta/recipes-multimedia/x264/x264_git.bb index 81354a8fd3..902396e4bf 100644 --- a/meta/recipes-multimedia/

[OE-core] [PATCH 19/19] python3: apply test skipping patch unconditionally

Testing IMAGE_FEATURES from component recipes cannot possibly work; adjusting the test to soft-fail if needed items are not available is not trivial, so let's just skip unconditionally for now. Signed-off-by: Alexander Kanavin --- meta/recipes-devtools/python/python3_3.9.5.bb | 2 +- 1 file chan

[OE-core] [PATCH 11/19] libdnf: upgrade 0.63.0 -> 0.63.1

Signed-off-by: Alexander Kanavin --- .../libdnf/{libdnf_0.63.0.bb => libdnf_0.63.1.bb} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename meta/recipes-devtools/libdnf/{libdnf_0.63.0.bb => libdnf_0.63.1.bb} (97%) diff --git a/meta/recipes-devtools/libdnf/libdnf_0.63.0.bb

[OE-core] [PATCH 17/19] vte: upgrade 0.64.1 -> 0.64.2

Signed-off-by: Alexander Kanavin --- meta/recipes-support/vte/{vte_0.64.1.bb => vte_0.64.2.bb} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename meta/recipes-support/vte/{vte_0.64.1.bb => vte_0.64.2.bb} (95%) diff --git a/meta/recipes-support/vte/vte_0.64.1.bb b/meta/recipes-support

[OE-core] [PATCH 10/19] gdbm: upgrade 1.19 -> 1.20

Signed-off-by: Alexander Kanavin --- meta/recipes-support/gdbm/{gdbm_1.19.bb => gdbm_1.20.bb} | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) rename meta/recipes-support/gdbm/{gdbm_1.19.bb => gdbm_1.20.bb} (90%) diff --git a/meta/recipes-support/gdbm/gdbm_1.19.bb b/meta/recipes-support

[OE-core] [PATCH 01/19] devtool upgrade: rebase override-only patches as well

There's a number of recipes (such as nettle or glib) which were upgraded incorrectly due to rebasing only the default set of patches in main SRC_URI. Native-only or musl-only patches were not handled, causing do_patch fails and overall misery. Unfortunately, this also necessitates aborting any inc

[OE-core] [PATCH 16/19] sqlite3: upgrade 3.35.5 -> 3.36.0

Signed-off-by: Alexander Kanavin --- .../sqlite/{sqlite3_3.35.5.bb => sqlite3_3.36.0.bb} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename meta/recipes-support/sqlite/{sqlite3_3.35.5.bb => sqlite3_3.36.0.bb} (83%) diff --git a/meta/recipes-support/sqlite/sqlite3_3.35.5.b

[OE-core] [PATCH 15/19] python3-git: upgrade 3.1.17 -> 3.1.18

Signed-off-by: Alexander Kanavin --- .../python/{python3-git_3.1.17.bb => python3-git_3.1.18.bb} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename meta/recipes-devtools/python/{python3-git_3.1.17.bb => python3-git_3.1.18.bb} (92%) diff --git a/meta/recipes-devtools/python/python

[OE-core] [PATCH 14/19] mtools: upgrade 4.0.29 -> 4.0.31

Signed-off-by: Alexander Kanavin --- .../mtools/mtools/disable-hardcoded-configs.patch | 6 +++--- .../mtools/{mtools_4.0.29.bb => mtools_4.0.31.bb} | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) rename meta/recipes-devtools/mtools/{mtools_4.0.29.bb => mtools_4.0.31

[OE-core] [PATCH 13/19] libxi: upgrade 1.7.10 -> 1.7.99.2

Signed-off-by: Alexander Kanavin --- .../xorg-lib/{libxi_1.7.10.bb => libxi_1.7.99.2.bb}| 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) rename meta/recipes-graphics/xorg-lib/{libxi_1.7.10.bb => libxi_1.7.99.2.bb} (82%) diff --git a/meta/recipes-graphics/xorg-lib/libxi_1.7.1

[OE-core] [PATCH 12/19] libpcre: upgrade 8.44 -> 8.45

License-Update: copyright years Signed-off-by: Alexander Kanavin --- .../libpcre/{libpcre_8.44.bb => libpcre_8.45.bb} | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) rename meta/recipes-support/libpcre/{libpcre_8.44.bb => libpcre_8.45.bb} (92%) diff --git a/meta/recipes-

[OE-core] [PATCH 03/19] gnu-config: update to latest revision

Signed-off-by: Alexander Kanavin --- meta/recipes-devtools/gnu-config/gnu-config_git.bb | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/recipes-devtools/gnu-config/gnu-config_git.bb b/meta/recipes-devtools/gnu-config/gnu-config_git.bb index 8d7d6ac3ee..420363415c 100

[OE-core] [PATCH 09/19] dejagnu: upgrade 1.6.2 -> 1.6.3

Signed-off-by: Alexander Kanavin --- .../dejagnu/{dejagnu_1.6.2.bb => dejagnu_1.6.3.bb} | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) rename meta/recipes-devtools/dejagnu/{dejagnu_1.6.2.bb => dejagnu_1.6.3.bb} (78%) diff --git a/meta/recipes-devtools/dejagnu/dejagnu_1.6.2

[OE-core] [PATCH 08/19] bluez5: upgrade 5.58 -> 5.59

Signed-off-by: Alexander Kanavin --- meta/recipes-connectivity/bluez5/bluez5.inc | 2 +- am-add-missing-mkdir-for-ell-shared.patch | 25 --- .../bluez5/{bluez5_5.58.bb => bluez5_5.59.bb} | 2 +- 3 files changed, 2 insertions(+), 27 deletions(-) delete mode 100644 meta/re

[OE-core] [PATCH 07/19] bind: upgrade 9.16.16 -> 9.16.18

Signed-off-by: Alexander Kanavin --- .../0001-avoid-start-failure-with-bind-user.patch | 0 ...0001-named-lwresd-V-and-start-log-hide-build-options.patch | 0 ...bind-ensure-searching-for-json-headers-searches-sysr.patch | 0 .../bind/{bind-9.16.16 => bind-9.16.18}/bind9

[OE-core] [PATCH 06/19] vulkan-samples: update to latest revision

Signed-off-by: Alexander Kanavin --- meta/recipes-graphics/vulkan/vulkan-samples_git.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-graphics/vulkan/vulkan-samples_git.bb b/meta/recipes-graphics/vulkan/vulkan-samples_git.bb index a177d9a391..972173ef50 100644

[OE-core] [PATCH 05/19] dnf: updatee 4.7.0 -> 4.8.0

Remove patches merged upstream. Signed-off-by: Alexander Kanavin --- ...-dnf-rpm-miscutils.py-fix-usage-of-_.patch | 39 --- ...s.py-do-not-hardcode-usr-bin-rpmkeys.patch | 37 -- ...PYTHON_INSTALL_DIR-by-running-python.patch | 8 ++-- .../dnf/{dnf_4.7.0.bb => dn

[OE-core] [PATCH 04/19] bash: update 5.1 -> 5.1.8

Signed-off-by: Alexander Kanavin --- meta/recipes-extended/bash/bash_5.1.8.bb | 24 ++ meta/recipes-extended/bash/bash_5.1.bb | 32 2 files changed, 24 insertions(+), 32 deletions(-) create mode 100644 meta/recipes-extended/bash/bash_5.1.8.bb delete mo

[OE-core] [PATCH 02/19] cmake: update 3.20.3 -> 3.20.4

Signed-off-by: Alexander Kanavin --- .../cmake/{cmake-native_3.20.3.bb => cmake-native_3.20.4.bb}| 0 meta/recipes-devtools/cmake/cmake.inc | 2 +- .../recipes-devtools/cmake/{cmake_3.20.3.bb => cmake_3.20.4.bb} | 0 3 files changed, 1 insertion(+), 1 deletion(-) re

[OE-core] [hardknott][PATCH 13/13] kernel.bbclass: fix do_sizecheck() comparison

From: Andrea Adami The routine do_sizecheck() was historically needed by legacy devices with limited flash memory. The lowest extreme is probably with Zaurus collie having exactly 1024*1024 = 1048576 bytes for the kernel partition. In the years the KERNEL_IMAGE_MAXSIZE has been converted to kilo

[OE-core] [hardknott][PATCH 12/13] avahi: apply fix for CVE-2021-3468

From: Ross Burton This patch isn't yet upstream but it has been submitted and other distros are shipping it. Signed-off-by: Ross Burton Signed-off-by: Richard Purdie (cherry picked from commit ea33a4a2df4600a55b268e9d57e7396c30f3d123) Signed-off-by: Anuj Mittal --- meta/recipes-connectivity/

[OE-core] [hardknott][PATCH 10/13] valgrind: Actually install list of non-deterministic ptests

From: Tony Tascioglu Install list of non-deterministic threaded ptests to be run using taskset to force them to a single core. This commit works with b318944d7, which updated the testing script to run the non-deterministic tests separately but didn't install the list of tests, so these tests were

[OE-core] [hardknott][PATCH 11/13] perf: Use python3targetconfig to ensure we use target libraries

From: Richard Purdie We've seen some reproducibility issues on the autobuilder in perf where the size of the python module varies slightly between systems. After some head scratching and removing the --quiet option to the python module build, you can see it using -Lrecipe-sysroot-native in the li

[OE-core] [hardknott][PATCH 09/13] valgrind: remove buggy ptest from arm64

From: Tony Tascioglu This commit removes the stack_changes ptest from aarch64 devices. This test is buggy and fails almost 100% of the time in qemuarm64. In general, many of the valgrind tests are more likely to fail on qemuarm64 vs native x86_64. This test previously worked on gatesgarth and du

[OE-core] [hardknott][PATCH 08/13] linuxloader: Be aware of riscv32 ldso

From: Khem Raj Signed-off-by: Khem Raj Signed-off-by: Richard Purdie (cherry picked from commit 0d7aa00663e1e41980afb24d0ada2d76e8723e2b) Signed-off-by: Anuj Mittal --- meta/classes/linuxloader.bbclass | 2 ++ 1 file changed, 2 insertions(+) diff --git a/meta/classes/linuxloader.bbclass b/me

[OE-core] [hardknott][PATCH 00/13] review request

Please review these changes for hardknott. I have not included 5.10 kernel update since that breaks build for -rt kernel. Two ptests, for valgrind and lttng-tools, failed while testing on autobuilder. We already have bugs for these. Thanks, Anuj The following changes since commit bfe25c99e91406

[OE-core] [hardknott][PATCH 07/13] linux-yocto/5.4: update to v5.4.125

From: Bruce Ashfield Updating linux-yocto/5.4 to the latest korg -stable release that comprises the following commits: 3909e2374335 Linux 5.4.125 d99029e6aab6 neighbour: allow NUD_NOARP entries to be forced GCed 8e0bb29446d1 i2c: qcom-geni: Suspend and resume the bus during SYSTEM_S

[OE-core] [hardknott][PATCH 01/13] curl: cleanup CVE patches for hardknott

From: Trevor Gamblin The patch backported to address CVE-2021-22890 was missing a bracket to properly close out the logic in lib/vtls/wolfssl.c. Fix this so to avoid any surprise failures when using curl with hardknott. Also fix the CVE designation in the patch descriptions for CVEs CVE-2021-228

[OE-core] [hardknott][PATCH 05/13] linux-yocto/5.4: update to v5.4.124

From: Bruce Ashfield Updating linux-yocto/5.4 to the latest korg -stable release that comprises the following commits: 70154d2f82a9 Linux 5.4.124 23c7e3235a3a usb: core: reduce power-on-good delay time of root hub 241abccc8a33 neighbour: Prevent Race condition in neighbour subsytem

[OE-core] [hardknott][PATCH 03/13] util-linux.inc: Do not modify BPN

From: Peter Kjellerstedt Changing BPN to be "util-linux" regardless if it is the util-linux recipe or the util-linux-libuuid recipe that is being built was an easy way to allow ${BPN} and ${BP} to be used in the SRC_URI for both recipes. However, it causes problems for native.bbclass where there

[OE-core] [hardknott][PATCH 02/13] libx11: fix CVE-2021-31535

From: Kai Kang Backport patch to fix CVE-2021-31535 of libx11. Adjust indentation as well. Signed-off-by: Kai Kang Signed-off-by: Anuj Mittal --- .../xorg-lib/libx11/fix-CVE-2021-31535.patch | 320 ++ .../recipes-graphics/xorg-lib/libx11_1.7.0.bb | 5 +- 2 files changed, 32

[OE-core] [hardknott][PATCH 06/13] lttng-tools: upgrade 2.12.3 -> 2.12.4

From: Richard Purdie Add a new lttng file to one of the tests to avoid test failures. Also add a dependency on grep since standalone testing revealed test failures without this. Normally this was added by other dependencies in the ptest images so we didn't see this. Signed-off-by: Richard Purdi

[OE-core] [hardknott][PATCH 04/13] native.bbclass: Do not remove "-native" in the middle of recipe names

From: Peter Kjellerstedt For dependencies such as "${PN}-foo", when modifying them for native recipes, it is expected that they become "${BPN}-foo-native" rather than "${BPN}-native-foo-native". This was previously done by removing all occurences of "-native" from the dependency before adding "-n