Re: [OE-core] [PATCH] armv8/tunes: Set TUNE_PKGARCH_64 based on ARMPKGARCH

On Thu, May 21, 2020 at 06:30:50PM -0700, Khem Raj wrote: >... > This lets higher up tune files for arm64 SOCs override them if needed, > this can help building multiple armv8 machines with different tunes in > same workspace. >... I am getting code for cortexa53-crypto built in a directory

[OE-core] Yocto Project Status WW20'21

Current Dev Position: YP 3.2 M1 Next Deadline: YP 3.2 M1 build date 2020/6/16 Next Team Meetings: * Bug Triage meeting Thursday May 28th at 7:30am PDT ( https://zoom.us/j/454367603) * Monthly Project Meeting Tuesday June 2nd at 8am PDT (

Re: [OE-core][dunfell 14/17] newlib: Upgrade to latest yearly release 3.3.0

On Mon, May 25, 2020 at 10:31 PM Paul Barker wrote: > > On Mon, 25 May 2020 at 23:37, Steve Sakoman wrote: > > > > From: Alejandro Hernandez > > > > Upgrade to the latest snapshot, also drop md5sum while were at it. > > > > (From OE-Core rev: d73aa359e42e707dbc7cfa29c55a2fc8e6bb938a) > > > >

Re: [OE-core] [PATCH 6/6] perf: drop 'include' copy

On Tue, May 26, 2020 at 1:44 AM Andrey Zhizhikin wrote: > > On Mon, Oct 21, 2019 at 10:58 PM Bruce Ashfield > wrote: > > > > On Mon, Oct 21, 2019 at 4:24 PM Martin Jansa wrote: > > > > > > On Mon, Oct 21, 2019 at 04:16:18PM -0400, bruce.ashfi...@gmail.com wrote: > > > > From: Bruce Ashfield >

Re: [OE-core] [PATCH] multilib/recipes: Use new RecipePostKeyExpansion event

For master I this looks great. We have been bitten in various edge cases by this in the past. You mentioned pushing it on to dunfell. I a little leary at this point, but if we are going to its kind of now or never. My feeling is there will be some fallout(which is perfectly fine on master, a

[OE-core] [PATCH] features_check: Factorize code for checking features

The DISTRO/MACHINE/COMBINED features should be treated identically, so convert the expanded code to a loop. This fixes some of the COMBINED error messages which were previously referring to MACHINE features. There should be no functional changes. Signed-off-by: Jacob Kroon ---

[OE-core] [meta-oe][PATCH 4/4] libksba: made libksba-lic "GPLv2+ | LGPLv3+"

From: Matthias Schoepfer If not set manually to "GPLv2+ | LGPLv3+", install of non GPLv3 parts (the library in this case) will be prevented in a setup that has INCOMPATIBLE_LICENSE = "GPLv3 LGPLv3 GPLv3+ LGPLv3+ GPL-3.0 LGPL-3.0 AGPL-3.0" COPY_LIC_MANIFEST = "1" COPY_LIC_DIRS = "1"

[OE-core] [meta-oe][PATCH 3/4] libgcrypt: made libgcrypt-lic license "GPLv2+ & LGPLv2.1+"

From: Matthias Schoepfer With the exception of dumpsexp.c, which is GPLv3, all other parts of libgcrypt are GPLv2+ & LGPLv2.1+, BSD or MIT or other "permissive" licenses. If libgcrypt-lic is not set to "GPLv2+ & LGPLv2.1+", image creation will fail with settings like INCOMPATIBLE_LICENSE =

Re: [OE-core] [meta-oe][PATCH 3/4] libgcrypt: made libgcrypt-lic license "GPLv2+ & LGPLv2.1+"

On Tue, 2020-05-26 at 10:12 +0200, Matthias Schoepfer via lists.openembedded.org wrote: > From: Matthias Schoepfer > > With the exception of dumpsexp.c, which is GPLv3, all other parts > of libgcrypt are GPLv2+ & LGPLv2.1+, BSD or MIT or other "permissive" > licenses. > > If libgcrypt-lic is

Re: [OE-core][dunfell 09/17] libubootenv: Depend on zlib

On Mon, 25 May 2020 at 23:37, Steve Sakoman wrote: > > From: Marek Vasut > > The libubootenv depends on zlib as it calls at least crc32() from > there and links against it. Add the DEPENDS entry. > > Signed-off-by: Marek Vasut > Cc: Stefano Babic > Signed-off-by: Richard Purdie >

[OE-core] [meta-oe][PATCH 2/4] elfutils: made elfutils-lic "GPLv2 | LGPLv3+"

From: Matthias Schoepfer If not set manually to "GPLv2 | LGPLv3+", install of non GPLv3 parts of elfutils will be prevented in a setup that has INCOMPATIBLE_LICENSE = "GPLv3 LGPLv3 GPLv3+ LGPLv3+ GPL-3.0 LGPL-3.0 AGPL-3.0" COPY_LIC_MANIFEST = "1" COPY_LIC_DIRS = "1" LICENSE_CREATE_PACKAGE = "1"

[OE-core] [meta-oe][PATCH 1/4] libgcc: made libgcc-lic "GPL-3.0-with-GCC-exception"

From: Matthias Schoepfer libgcc LICENSE_${PN} is "GPL-3.0-with-GCC-exception". If libgcc-lic is not also set to the same license, creating of image with INCOMPATIBLE_LICENSE = "GPLv3 LGPLv3 GPLv3+ LGPLv3+ GPL-3.0 LGPL-3.0 AGPL-3.0" COPY_LIC_MANIFEST = "1" COPY_LIC_DIRS = "1"

Re: [OE-core][dunfell 14/17] newlib: Upgrade to latest yearly release 3.3.0

On Mon, 25 May 2020 at 23:37, Steve Sakoman wrote: > > From: Alejandro Hernandez > > Upgrade to the latest snapshot, also drop md5sum while were at it. > > (From OE-Core rev: d73aa359e42e707dbc7cfa29c55a2fc8e6bb938a) > > Signed-off-by: Alejandro Hernandez Samaniego > Signed-off-by: Alejandro

Re: [OE-core][dunfell 09/17] libubootenv: Depend on zlib

On Tue, May 26, 2020 at 09:24:59AM +0100, Paul Barker wrote: > On Mon, 25 May 2020 at 23:37, Steve Sakoman wrote: > > > > From: Marek Vasut > > > > The libubootenv depends on zlib as it calls at least crc32() from > > there and links against it. Add the DEPENDS entry. > > > > Signed-off-by:

Re: [OE-core][dunfell 09/17] libubootenv: Depend on zlib

On Tue, 26 May 2020 at 09:56, Adrian Bunk wrote: > > On Tue, May 26, 2020 at 09:24:59AM +0100, Paul Barker wrote: > > On Mon, 25 May 2020 at 23:37, Steve Sakoman wrote: > > > > > > From: Marek Vasut > > > > > > The libubootenv depends on zlib as it calls at least crc32() from > > > there and

Re: [OE-core][dunfell 09/17] libubootenv: Depend on zlib

On 26.05.20 10:57, Paul Barker wrote: > On Tue, 26 May 2020 at 09:56, Adrian Bunk wrote: >> >> On Tue, May 26, 2020 at 09:24:59AM +0100, Paul Barker wrote: >>> On Mon, 25 May 2020 at 23:37, Steve Sakoman wrote: From: Marek Vasut The libubootenv depends on zlib as it calls at

Re: [OE-core] Meta Qt5 Qt 5.6.3 compatibility with Yocto 2.4(poky)

Hi, Thanks for your mail. Do we have Meta Qt5.6.3 recipes for Yocto 2.4 Rocko branch? Best Regards, Ramakanth On Mon, 25 May, 2020, 18:17 Quentin Schulz, < quentin.sch...@streamunlimited.com> wrote: > Hi Ramakanth, > > On Mon, May 25, 2020 at 06:06:34PM +0530, Ramakanth Kesireddy wrote: > >

Re: [OE-core] [PATCH] multilib/recipes: Use new RecipePostKeyExpansion event

On Tue, 2020-05-26 at 08:45 -0700, Jeremy Puhlman wrote: > For master I this looks great. We have been bitten in various edge > cases by this in the past. You mentioned > pushing it on to dunfell. I a little leary at this point, but if we > are going to its kind of now or never. My feeling > is

Re: [OE-core] [PATCH 1/5 v2] multilib/recipes: Use new RecipePostKeyExpansion event

On Tue, 2020-05-26 at 15:12 -0700, Jeremy Puhlman wrote: > The one question I did have is there are a couple of places where you > add the ML prefix for > nativesdk classes. If we don't have them, it shouldn't hurt anything, > but do we actually support > multilib nativesdk packages? nativesdk

Re: [OE-core] [PATCH 1/5 v2] multilib/recipes: Use new RecipePostKeyExpansion event

The one question I did have is there are a couple of places where you add the ML prefix for nativesdk classes. If we don't have them, it shouldn't hurt anything, but do we actually support multilib nativesdk packages? On 5/26/2020 2:57 PM, Richard Purdie wrote: There are issues with multilib

[OE-core] [PATCH V2] armv8/tunes: Set TUNE_PKGARCH_64 based on ARMPKGARCH

The setting is to modify TUNE_PKGARCH which is filled with TUNE_PKGARCH_64 or TUNE_PKGARCH_32 in arm-arch64.inc This lets higher up tune files for arm64 SOCs override them if needed, this can help building multiple armv8 machines with different tunes in same workspace. No need to set TUNE_PKGARCH

[OE-core] [PATCH] python3-pycairo:upgrade 1.19.0 -> 1.19.1

Signed-off-by: Zang Ruochen --- .../{python3-pycairo_1.19.0.bb => python3-pycairo_1.19.1.bb} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename meta/recipes-devtools/python/{python3-pycairo_1.19.0.bb => python3-pycairo_1.19.1.bb} (84%) diff --git

Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2

I'm looking at this after our chat on the call today, picked on this email in particular just because I needed one to reply to On Wed, 20 May 2020 at 21:59, Randy MacLeod wrote: > > On 2020-05-19 8:06 p.m., Peter Kjellerstedt wrote: > >> -Original Message- > >> From: Randy MacLeod >

[OE-core][PATCH v6 2/3] classes: Add a new bbclass that abstracts the generation of FIT blobs

FIT format is very versatile allowing various combination of booting sequences. In the same time different U-Boot boot stages can use FIT blobs to pack various binaries (e.g. SPL supports reading U-Boot from a FIT blob). Because of the allowed level of customization, the generation of a FIT blob

[OE-core][PATCH v6 0/3] Add a new bbclass that abstracts the generation of FIT blobs

Description -- Add a new class and unittest for generating FIT blobs. Testing --- 1. linux-yocto_5.4.bbappend was modified to have the following configuration: ``` inherit fit-image KERNEL_IMAGE_NODE[name] = "kernel" KERNEL_IMAGE_NODE[description] = "${PF}"

[OE-core][PATCH v6 3/3] selftest: add a unit-test for fit-image bbclass

The unit-test will test the basic functionality of `fit-image.bbclass`. Signed-off-by: Nandor Han --- .../fit-image-test/files/dt-fake.dtb | 3 + .../fit-image-test/files/zImage-fake | 3 + .../fit-image-test/fit-image-test.bb | 17 ++

[OE-core][PATCH v6 1/3] Add a recipe for `python3-fdt` package

The package `python3-fdt` is used for parsing and generating DTBs. Signed-off-by: Nandor Han --- meta/recipes-devtools/python/python3-fdt_0.2.0.bb | 14 ++ 1 file changed, 14 insertions(+) create mode 100644 meta/recipes-devtools/python/python3-fdt_0.2.0.bb diff --git

Re: [OE-core] [PATCH 6/6] perf: drop 'include' copy

On Tue, May 26, 2020 at 10:22:07PM +0200, Andrey Zhizhikin wrote: > Kernel 4.4 is also LTS and has (had) a very long time span, so I > believe there are some people out there who might still have it in > their Products (industrial applications are pretty conservative guys). > I have to admit that

Re: [OE-core] [PATCH 6/6] perf: drop 'include' copy

On Tue, May 26, 2020 at 2:31 PM Bruce Ashfield wrote: > > On Tue, May 26, 2020 at 1:44 AM Andrey Zhizhikin wrote: > > > > On Mon, Oct 21, 2019 at 10:58 PM Bruce Ashfield > > wrote: > > > > > > On Mon, Oct 21, 2019 at 4:24 PM Martin Jansa > > > wrote: > > > > > > > > On Mon, Oct 21, 2019 at

Re: [OE-core] [PATCH] bind: Apply CVE-2020-8616.patch for bind 9.11.13

Steve this is Dunfell worthy too. So please track it. On Tue, May 26, 2020 at 1:51 PM Khem Raj wrote: > > From: Rense Jacob > > backport for nvd.nist.gov/vuln/detail/CVE-2020-8616 > > Signed-off-by: Rense > Signed-off-by: Khem Raj > --- > .../bind/bind/CVE-2020-8616.patch | 221

[OE-core] [PATCH] bind: Apply CVE-2020-8616.patch for bind 9.11.13

From: Rense Jacob backport for nvd.nist.gov/vuln/detail/CVE-2020-8616 Signed-off-by: Rense Signed-off-by: Khem Raj --- .../bind/bind/CVE-2020-8616.patch | 221 ++ .../recipes-connectivity/bind/bind_9.11.13.bb | 1 + 2 files changed, 222 insertions(+) create

[OE-core] ✗ patchtest: failure for bind: Apply CVE-2020-8616.patch for bind 9.11.13

== Series Details == Series: bind: Apply CVE-2020-8616.patch for bind 9.11.13 Revision: 1 URL : https://patchwork.openembedded.org/series/24328/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have

[oe-core][PATCH] libexif: upgrade to 0.6.22, change source to GitHub

Updated libexif to 0.6.22, but needed to change to GitHub as a source, since SourceForge does not yet have 0.6.22 version. The new version includes the fixes for the three patch files that have been removed, as well as other severe CVEs. CVE: CVE-2018-20030 CVE: CVE-2020-13114 CVE: CVE-2020-13113

Re: [OE-core] [PATCH 6/6] perf: drop 'include' copy

On Tue, May 26, 2020 at 10:44 PM Martin Jansa wrote: > > On Tue, May 26, 2020 at 10:22:07PM +0200, Andrey Zhizhikin wrote: > > Kernel 4.4 is also LTS and has (had) a very long time span, so I > > believe there are some people out there who might still have it in > > their Products (industrial

[OE-core] [PATCH 3/5] resulttool/report: Remove leftover debugging

I've long since wondered why there was some odd output in result reports, remove the leftover debug which was causing it. Signed-off-by: Richard Purdie --- scripts/lib/resulttool/report.py | 1 - 1 file changed, 1 deletion(-) diff --git a/scripts/lib/resulttool/report.py

[OE-core] [PATCH 1/5 v2] multilib/recipes: Use new RecipePostKeyExpansion event

There are issues with multilib due to the ordering of events where some functions see the remapped multilib dependencies and some do not. A significant problem is that the multilib class needs to make some changes before key expansion and some afterwards but by using existing event handlers, some

[OE-core] [PATCH 2/5] ltp: Add missing dependencies on coreutils, bc, e2fsprogs and gdb

When the tests are run we see messages like: /opt/ltp/testcases/bin/run_cpuctl_stress_test.sh: line 242: nice: command not found /opt/ltp/testcases/bin/run_cpuctl_test_fj.sh: line 66: tac: command not found vma05 1 TCONF: 'gdb' not found memcg_failcnt 1 TCONF: 'bc' not found Owner=nobody;

[OE-core] [PATCH 4/5] resulttool/log: Add ability to dump ltp logs as well as ptest

Currently only ptest logs are accessible with the log command, this adds support so the ltp logs can be extracted too. Signed-off-by: Richard Purdie --- scripts/lib/resulttool/log.py | 21 ++--- scripts/lib/resulttool/resultutils.py | 22 ++ 2 files

[OE-core] [PATCH 5/5] ltp: Exclude the memcg_stress tests due to timeout problems

This test runs for 900s, we often see tests killed after 300s without output which makes the test results unreliable and inconsistent. The easiest solution for now is to skip this long running test, patching it out wth sed. Signed-off-by: Richard Purdie ---

[OE-core] ✗ patchtest: failure for Add a new bbclass that abstracts the generation of FIT blobs (rev7)

== Series Details == Series: Add a new bbclass that abstracts the generation of FIT blobs (rev7) Revision: 7 URL : https://patchwork.openembedded.org/series/23431/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response.

[OE-core] ✗ patchtest: failure for Add a new bbclass that abstracts the generation of FIT blobs (rev6)

== Series Details == Series: Add a new bbclass that abstracts the generation of FIT blobs (rev6) Revision: 6 URL : https://patchwork.openembedded.org/series/23431/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response.

Re: [OE-core] [PATCH] package_rpm.bbclass: respect package overrides for the main package

Does this patch (and the follow-on series) make sense for inclusion in dunfell? Steve On Sun, May 24, 2020 at 9:46 PM Michael Ho wrote: > > From: Michael Ho > > Apply ${PN} to OVERRIDES when determining the base package spec variables. > Without this, there is a mismatch in behaviour where

[OE-core][PATCH v4 0/3] Add a new bbclass that abstracts the generation of FIT blobs

Description -- Add a new class and unittest for generating FIT blobs. Testing --- 1. linux-yocto_5.4.bbappend was modified to have the following configuration: ``` inherit fit-image KERNEL_IMAGE_NODE[name] = "kernel" KERNEL_IMAGE_NODE[description] = "${PF}"

[OE-core] [PATCH v3] classes: Add a new bbclass that abstracts the generation of FIT blobs

FIT format is very versatile allowing various combination of booting sequences. In the same time different U-Boot boot stages can use FIT blobs to pack various binaries (e.g. SPL supports reading U-Boot from a FIT blob). Because of the allowed level of customization, the generation of a FIT blob

[OE-core][PATCH v4 2/3] classes: Add a new bbclass that abstracts the generation of FIT blobs

FIT format is very versatile allowing various combination of booting sequences. In the same time different U-Boot boot stages can use FIT blobs to pack various binaries (e.g. SPL supports reading U-Boot from a FIT blob). Because of the allowed level of customization, the generation of a FIT blob

[OE-core][PATCH v4 3/3] selftest: add a unit-test for fit-image bbclass

The unit-test will test the basic functionality of `fit-image.bbclass`. Signed-off-by: Nandor Han --- .../fit-image-test/files/dt-fake.dtb | 3 + .../fit-image-test/files/zImage-fake | 3 + .../fit-image-test/fit-image-test.bb | 17 ++

[OE-core][PATCH v4 1/3] Add a recipe for `python3-fdt` package

The package `python3-fdt` is used for parsing and generating DTBs. Signed-off-by: Nandor Han --- meta/recipes-devtools/python/python3-fdt_0.2.0.bb | 14 ++ 1 file changed, 14 insertions(+) create mode 100644 meta/recipes-devtools/python/python3-fdt_0.2.0.bb diff --git

Re: [OE-core] [meta-oe][PATCH 3/4] libgcrypt: made libgcrypt-lic license "GPLv2+ & LGPLv2.1+"

Hi Richard, On 5/26/20 10:19 AM, Richard Purdie wrote: On Tue, 2020-05-26 at 10:12 +0200, Matthias Schoepfer via lists.openembedded.org wrote: From: Matthias Schoepfer With the exception of dumpsexp.c, which is GPLv3, all other parts of libgcrypt are GPLv2+ & LGPLv2.1+, BSD or MIT or other

Re: [OE-core] [meta-oe][PATCH 3/4] libgcrypt: made libgcrypt-lic license "GPLv2+ & LGPLv2.1+"

On Tue, May 26, 2020 at 01:20:50PM +0200, Matthias Schoepfer via lists.openembedded.org wrote: >... > The question here seems to be, is the GPLv3 License itself GPLv3 licensed. >... Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not

Re: [OE-core] [meta-oe][PATCH 3/4] libgcrypt: made libgcrypt-lic license "GPLv2+ & LGPLv2.1+"

On Tue, 2020-05-26 at 13:20 +0200, Matthias Schoepfer wrote: > Hi Richard, > > On 5/26/20 10:19 AM, Richard Purdie wrote: > > On Tue, 2020-05-26 at 10:12 +0200, Matthias Schoepfer via > > lists.openembedded.org wrote: > > > From: Matthias Schoepfer > > > > > > With the exception of dumpsexp.c,

Re: [OE-core] Meta Qt5 Qt 5.6.3 compatibility with Yocto 2.4(poky)

Hi Ramakanth, On Tue, May 26, 2020 at 04:39:26PM +0530, Ramakanth Kesireddy wrote: > Hi, > > Thanks for your mail. > Do we have > Meta Qt5.6.3 recipes for Yocto 2.4 Rocko branch? > As I said, I'm using qt5.6.3 on thud with the krogoth branch of meta-qt5. So a meta-qt5 meant for krogoth, but