Re: [OE-core] [PATCH 2/9] multilib_header.bbclass: need multilib headers for nativesdk builds

2025-02-05 Thread Richard Purdie via lists.openembedded.org
On Wed, 2025-01-29 at 16:58 +, Ross Burton via lists.openembedded.org wrote: > On 21 Jan 2025, at 08:55, hongxu via lists.openembedded.org > wrote: > > The nativesdk multilib support required it to fix multilib headers > > conflict > > So the context here is that luajit apparently needs to be

[OE-core] [PATCH v4 2/3] uki.bbclass: capture ukify command stdout and stderr

2025-02-05 Thread Mikko Rapeli via lists.openembedded.org
ukify tool can show important warnings and even errors if it fails so capture the logs. Signed-off-by: Mikko Rapeli --- meta/classes-recipe/uki.bbclass | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/meta/classes-recipe/uki.bbclass b/meta/classes-recipe/uki.bbclass index 92

[OE-core] [PATCH v4 3/3] systemd-boot-native: fix kernel signature for secureboot

2025-02-05 Thread Mikko Rapeli via lists.openembedded.org
systemd update from 256 to 257 broke kernel secureboot signatures inside signed UKI files with u-boot based UEFI firmware, e.g. meta-arm and qemuarm64-secureboot machine config and secureboot: $ cd meta-arm $ kas build ci/poky.yml:ci/qemuarm64-secureboot.yml:ci/uefi-secureboot.yml:ci/testimage.ym

[OE-core] [PATCH v4 1/3] systemd-boot-native: move do_install() to after do_patch()

2025-02-05 Thread Mikko Rapeli via lists.openembedded.org
The tasks were deleted and do_patch() was run after do_install() which means that patches applied in SRC_URI were not in the ukify.py binary installed. Moving do_install() to after do_patch() fixes this. Signed-off-by: Mikko Rapeli --- meta/recipes-core/systemd/systemd-boot-native_257.1.bb | 2 +

Re: [OE-core] [PATCH v3 1/3] systemd-boot-native: undelete but disable configure and compile tasks

2025-02-05 Thread Mikko Rapeli via lists.openembedded.org
Hi, On Wed, Feb 05, 2025 at 12:58:17PM +, Richard Purdie wrote: > On Tue, 2025-02-04 at 16:17 +0200, Mikko Rapeli via > lists.openembedded.org wrote: > > The tasks were deleted and do_patch() was run after do_install() > > which means that patches applied in SRC_URI were not in the > > ukify.p

[OE-core][PATCH v8 3/5] rpm: Set SEQUOIA_CRYPTO_POLICY in wrapped tools

2025-02-05 Thread Zoltan Boszormenyi via lists.openembedded.org
Point to the crypto policy file so RPM signing may work. Signed-off-by: Zoltán Böszörményi --- meta/recipes-devtools/rpm/rpm_4.20.0.bb | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/recipes-devtools/rpm/rpm_4.20.0.bb b/meta/recipes-devtools/rpm/rpm_4.20.0.bb index 6c995ff50c..d296c20d

[OE-core][PATCH v8 2/5] rpm-sequoia: New recipe for version 1.7.0

2025-02-05 Thread Zoltan Boszormenyi via lists.openembedded.org
rpm 4.20 removed the built-in code to handle signed packages and uses rpm-sequoia as a more feature complete library. Runtime-depend on rpm-sequoia-crypto-policy. Signed-off-by: Zoltán Böszörményi --- meta/conf/distro/include/maintainers.inc | 1 + .../rpm-sequoia/rpm-sequoia-crates.inc

[OE-core][PATCH v8 5/5] oeqa/selftest/cases/signing.py: Re-enable self-test

2025-02-05 Thread Zoltan Boszormenyi via lists.openembedded.org
With all the pieces in place, the self test can be re-enabled. Signed-off-by: Zoltán Böszörményi --- meta/lib/oeqa/selftest/cases/signing.py | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/meta/lib/oeqa/selftest/cases/signing.py b/meta/lib/oeqa/selftest/cases/signing.py in

[OE-core][PATCH v8 4/5] dnf: Set SEQUOIA_CRYPTO_POLICY in wrapped tools

2025-02-05 Thread Zoltan Boszormenyi via lists.openembedded.org
Point to the crypto policy file so dnf can work with signed packages. Signed-off-by: Zoltán Böszörményi --- meta/recipes-devtools/dnf/dnf_4.22.0.bb | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/recipes-devtools/dnf/dnf_4.22.0.bb b/meta/recipes-devtools/dnf/dnf_4.22.0.bb index f9d6ea1

[OE-core][PATCH v8 1/5] rpm-sequoia-crypto-policy: New recipe

2025-02-05 Thread Zoltan Boszormenyi via lists.openembedded.org
This ships a crypto policy file for rpm-sequoia. Signed-off-by: Zoltán Böszörményi --- meta/conf/distro/include/maintainers.inc | 1 + .../rpm-sequoia-crypto-policy_git.bb | 27 +++ 2 files changed, 28 insertions(+) create mode 100644 meta/recipes-devtools/rpm-se

Patchtest results for [OE-core][PATCH v7 5/5] oeqa/selftest/cases/signing.py: Re-enable self-test

2025-02-05 Thread Patchtest via lists.openembedded.org
Thank you for your submission. Patchtest identified one or more issues with the patch. Please see the log below for more information: --- Testing patch /home/patchtest/share/mboxes/v7-5-5-oeqa-selftest-cases-signing.py-Re-enable-self-test.patch FAIL: test commit message presence: Please include

Patchtest results for [OE-core][PATCH v7 3/5] rpm: Set SEQUOIA_CRYPTO_POLICY in wrapped tools

2025-02-05 Thread Patchtest via lists.openembedded.org
Thank you for your submission. Patchtest identified one or more issues with the patch. Please see the log below for more information: --- Testing patch /home/patchtest/share/mboxes/v7-3-5-rpm-Set-SEQUOIA_CRYPTO_POLICY-in-wrapped-tools.patch FAIL: test commit message presence: Please include a co

Patchtest results for [OE-core][PATCH v7 4/5] dnf: Set SEQUOIA_CRYPTO_POLICY in wrapped tools

2025-02-05 Thread Patchtest via lists.openembedded.org
Thank you for your submission. Patchtest identified one or more issues with the patch. Please see the log below for more information: --- Testing patch /home/patchtest/share/mboxes/v7-4-5-dnf-Set-SEQUOIA_CRYPTO_POLICY-in-wrapped-tools.patch FAIL: test commit message presence: Please include a co

Re: [OE-core][PATCH v7 3/5] rpm: Set SEQUOIA_CRYPTO_POLICY in wrapped tools

2025-02-05 Thread Zoltan Boszormenyi via lists.openembedded.org
2025. 02. 06. 5:42 keltezéssel, Zoltán Böszörményi írta: Signed-off-by: Zoltán Böszörményi --- meta/recipes-devtools/rpm/rpm_4.20.0.bb | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/recipes-devtools/rpm/rpm_4.20.0.bb b/meta/recipes-devtools/rpm/rpm_4.20.0.bb index 6c995ff50c..d296c

[OE-core][PATCH v7 4/5] dnf: Set SEQUOIA_CRYPTO_POLICY in wrapped tools

2025-02-05 Thread Zoltan Boszormenyi via lists.openembedded.org
Signed-off-by: Zoltán Böszörményi --- meta/recipes-devtools/dnf/dnf_4.22.0.bb | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/recipes-devtools/dnf/dnf_4.22.0.bb b/meta/recipes-devtools/dnf/dnf_4.22.0.bb index f9d6ea1fa6..e5ac3c9824 100644 --- a/meta/recipes-devtools/dnf/dnf_4.22.0.bb ++

[OE-core][PATCH v7 5/5] oeqa/selftest/cases/signing.py: Re-enable self-test

2025-02-05 Thread Zoltan Boszormenyi via lists.openembedded.org
Signed-off-by: Zoltán Böszörményi --- meta/lib/oeqa/selftest/cases/signing.py | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/meta/lib/oeqa/selftest/cases/signing.py b/meta/lib/oeqa/selftest/cases/signing.py index 51d1c3fa64..4df45ba032 100644 --- a/meta/lib/oeqa/selftest/c

[OE-core][PATCH v7 2/5] rpm-sequoia: New recipe for version 1.7.0

2025-02-05 Thread Zoltan Boszormenyi via lists.openembedded.org
rpm 4.20 removed the built-in code to handle signed packages and uses rpm-sequoia as a more feature complete library. Runtime-depend on rpm-sequoia-crypto-policy. Signed-off-by: Zoltán Böszörményi --- meta/conf/distro/include/maintainers.inc | 1 + .../rpm-sequoia/rpm-sequoia-crates.inc

[OE-core][PATCH v7 3/5] rpm: Set SEQUOIA_CRYPTO_POLICY in wrapped tools

2025-02-05 Thread Zoltan Boszormenyi via lists.openembedded.org
Signed-off-by: Zoltán Böszörményi --- meta/recipes-devtools/rpm/rpm_4.20.0.bb | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/recipes-devtools/rpm/rpm_4.20.0.bb b/meta/recipes-devtools/rpm/rpm_4.20.0.bb index 6c995ff50c..d296c20d78 100644 --- a/meta/recipes-devtools/rpm/rpm_4.20.0.bb ++

[OE-core][PATCH v7 1/5] rpm-sequoia-crypto-policy: New recipe

2025-02-05 Thread Zoltan Boszormenyi via lists.openembedded.org
This ships a crypto policy file for rpm-sequoia. Signed-off-by: Zoltán Böszörményi --- meta/conf/distro/include/maintainers.inc | 1 + .../rpm-sequoia-crypto-policy_git.bb | 26 +++ 2 files changed, 27 insertions(+) create mode 100644 meta/recipes-devtools/rpm-se

Re: [OE-core][PATCH] debugedit: fix build failure when enabling DEBUG_BUILD

2025-02-05 Thread Chen Qi via lists.openembedded.org
Hi Randy, Thanks a lot for the information. I’ve created a bug for upstream: 32648 – debugedit fails to build with '-Og' option and gcc 14 I’ve put the information you provided there and also added a comment to link to my patch. Hope upstre

Re: [OE-core] [PATCH 35/46] python3-pyopenssl: upgrade 24.3.0 -> 25.0.0

2025-02-05 Thread Khem Raj via lists.openembedded.org
On Mon, Feb 3, 2025 at 8:42 AM Richard Purdie via lists.openembedded.org wrote: > > Signed-off-by: Richard Purdie > --- > ...{python3-pyopenssl_24.3.0.bb => python3-pyopenssl_25.0.0.bb} | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > rename meta/recipes-devtools/python/{python3-pyopen

Re: [OE-core][PATCH] bitbake.conf: Include fragments before local.conf

2025-02-05 Thread Richard Purdie via lists.openembedded.org
On Wed, 2025-02-05 at 14:55 -0700, Joshua Watt via lists.openembedded.org wrote: > On Wed, Feb 5, 2025 at 2:36 PM Alexander Kanavin > wrote: > > > > We have discussed this before. With this change, users will no > > longer be able to set fragments from local.conf, as addfragments > > would be pro

Re: [OE-core][PATCH] bitbake.conf: Include fragments before local.conf

2025-02-05 Thread Joshua Watt via lists.openembedded.org
On Wed, Feb 5, 2025 at 3:37 PM Alexander Kanavin wrote: > > Btw the other option for overriding fragments would be to use direct require > statement with a path to them in local.conf, followed by tweaks. It’s not too > horrible. And using a fragment variable can then be seen as ‘immutable’ > fr

Re: [OE-core][PATCH] bitbake.conf: Include fragments before local.conf

2025-02-05 Thread Joshua Watt via lists.openembedded.org
On Wed, Feb 5, 2025 at 3:26 PM Alexander Kanavin wrote: > > One could conceivably want to ship a local.conf.sample template with > fragments already enabled in it, or hand edit local.conf to enable something > via fragment. We can’t force users to use fragment tooling. > > It would be equally su

Re: [OE-core][PATCH] bitbake.conf: Include fragments before local.conf

2025-02-05 Thread Alexander Kanavin via lists.openembedded.org
Btw the other option for overriding fragments would be to use direct require statement with a path to them in local.conf, followed by tweaks. It’s not too horrible. And using a fragment variable can then be seen as ‘immutable’ fragment enabling which could be beneficial precisely because users can’

[OE-core] Patchtest results for [PATCH v2] uboot-config: Fix devtool modify

2025-02-05 Thread Patchtest via lists.openembedded.org
Thank you for your submission. Patchtest identified one or more issues with the patch. Please see the log below for more information: --- Testing patch /home/patchtest/share/mboxes/v2-uboot-config-Fix-devtool-modify.patch FAIL: test commit message user tags: Mbox includes one or more GitHub-styl

Re: [OE-core][PATCH] bitbake.conf: Include fragments before local.conf

2025-02-05 Thread Alexander Kanavin via lists.openembedded.org
One could conceivably want to ship a local.conf.sample template with fragments already enabled in it, or hand edit local.conf to enable something via fragment. We can’t force users to use fragment tooling. It would be equally surprising to find out that setting fragments this way doesn’t actually

[OE-core] [PATCH v2] uboot-config: Fix devtool modify

2025-02-05 Thread Tom Hochstein via lists.openembedded.org
Fix a problem with `devtool modify` as suggested by Marcus Flyckt on the mailing list: ``` I encountered an issue with `do_config` when using `devtool modify` on `u-boot-imx`. ``` [...] | cp: cannot stat '[...]/u-boot-imx/2024.04/build/imx8mp_wl400s_defconfig/.config': No such

Re: [OE-core][PATCH] bitbake.conf: Include fragments before local.conf

2025-02-05 Thread Joshua Watt via lists.openembedded.org
On Wed, Feb 5, 2025 at 2:36 PM Alexander Kanavin wrote: > > We have discussed this before. With this change, users will no longer be able > to set fragments from local.conf, as addfragments would be processed before > that file. You need to use ?= in fragments instead for things that are meant

Re: [OE-core] [PATCH] uboot-config: Fix devtool modify

2025-02-05 Thread Yoann Congal via lists.openembedded.org
Le mer. 5 févr. 2025 à 19:10, Tom Hochstein via lists.openembedded.org a écrit : > Fix a problem with `devtool modify` as suggested by Marcus Flyckt on > the mailing list: > ``` > I encountered an issue with `do_config` when using `devtool modify` > on `u-boot-imx`. > > ``` > [...

Re: [OE-core][PATCH] bitbake.conf: Include fragments before local.conf

2025-02-05 Thread Alexander Kanavin via lists.openembedded.org
We have discussed this before. With this change, users will no longer be able to set fragments from local.conf, as addfragments would be processed before that file. You need to use ?= in fragments instead for things that are meant to be overridden. Alex On Wed 5. Feb 2025 at 22.24, Joshua Watt w

Re: [OE-core] Patchtest results for [PATCH] uboot-config: Fix devtool modify

2025-02-05 Thread Tom Hochstein via lists.openembedded.org
On 2/5/2025 12:16 PM, patcht...@automation.yoctoproject.org wrote: [You don't often get email from patcht...@automation.yoctoproject.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] Thank you for your submission. Patchtest identified one or more issues with th

[OE-core][PATCH] bitbake.conf: Include fragments before local.conf

2025-02-05 Thread Joshua Watt via lists.openembedded.org
Per some usability assessment and offline discussion, one of the useful use cases of config fragments is that they allow the "default" configuration for some device to be committed to source control and easily selected and used by the end users. However, when doing this, there is still the desire t

[OE-core] Patchtest results for [PATCH] uboot-config: Fix devtool modify

2025-02-05 Thread Patchtest via lists.openembedded.org
Thank you for your submission. Patchtest identified one or more issues with the patch. Please see the log below for more information: --- Testing patch /home/patchtest/share/mboxes/uboot-config-Fix-devtool-modify.patch FAIL: test commit message user tags: Mbox includes one or more GitHub-style u

Re: [OE-core] multiple toolchains in SDK?

2025-02-05 Thread Joakim Tjernlund via lists.openembedded.org
On Fri, 2024-12-06 at 17:08 +0100, Christian Eggers wrote: On Friday, 6 December 2024, 15:12:03 CET, Joakim Tjernlund via lists.openembedded.org wrote: > Trying to figure out how to build in SDK: > gcc-arm32-musl > and > gcc-arm64-musl(or possibly gcc-arm64-newlib) +1 We currently use ARMv7 (32

[OE-core] [PATCH] uboot-config: Fix devtool modify

2025-02-05 Thread Tom Hochstein via lists.openembedded.org
Fix a problem with `devtool modify` as suggested by Marcus Flyckt on the mailing list: ``` I encountered an issue with `do_config` when using `devtool modify` on `u-boot-imx`. ``` [...] | cp: cannot stat '[...]/u-boot-imx/2024.04/build/imx8mp_wl400s_defconfig/.config': No such

[OE-core][PATCH] classes: switch p7zip to 7zip

2025-02-05 Thread Peter Marko via lists.openembedded.org
From: Peter Marko meta-oe has switched from p7zip to 7zip. p7zip recipe does not exist anymore and p7zip is provided and rprovided by 7zip recipe. Use real provider instead of replaced one. Signed-off-by: Peter Marko --- meta/classes-global/base.bbclass | 4 ++-- meta/classes-reci

[OE-core] [PATCH] rpm: add PACKAGECONFIG dependencies

2025-02-05 Thread Dan McGregor via lists.openembedded.org
From: Daniel McGregor The cap and acl configs were missing dependency specifications. They could get satisfied transitively if archive was also used, but alone get missed. Signed-off-by: Daniel McGregor --- meta/recipes-devtools/rpm/rpm_4.20.0.bb | 4 ++-- 1 file changed, 2 insertions(+), 2 de

[OE-core] Patchtest results for [PATCH v4 1/2] add basic b4 config file

2025-02-05 Thread Patchtest via lists.openembedded.org
Thank you for your submission. Patchtest identified one or more issues with the patch. Please see the log below for more information: --- Testing patch /home/patchtest/share/mboxes/v4-1-2-add-basic-b4-config-file.patch FAIL: test shortlog format: Commit shortlog (first line of commit message) sh

[OE-core] [PATCH v4 0/2] add basic b4 config file

2025-02-05 Thread Quentin Schulz
.call calling "which lsdiff" with shutil.which("lsdiff") so it is supported by more systems, - Link to v3: https://lore.kernel.org/r/20250205-b4-support-v3-0-f8b1456ae...@cherry.de Changes in v3: - populate To recipient list instead of Cc to follow what's asked in our READ

[OE-core] [PATCH v4 2/2] scripts: add b4-wrapper for poky

2025-02-05 Thread Quentin Schulz
From: Quentin Schulz poky is a combo-layer containing BitBake, OpenEmbedded-Core and Yocto Documentation source code into one big repo. It is not uncommon to have people develop patches for either of those projects from a poky git repo. However, it is unlikely those patches are to be sent to the

[OE-core] [PATCH v4 1/2] add basic b4 config file

2025-02-05 Thread Quentin Schulz
From: Quentin Schulz b4[1] is a very nice tool for mail-based contribution. A config[2] file exists to set up a few defaults. We can use it to set the Cc recipients to always add, in our case the mailing list. Because we do not have anything to check for now, disable needs-checking so patches ca

[OE-core] [PATCH] libslirp: set the PV in the filename

2025-02-05 Thread Ross Burton via lists.openembedded.org
As this recipe builds the tagged releases we can put the PV in the filename. Signed-off-by: Ross Burton --- .../slirp/{libslirp_git.bb => libslirp_4.9.0.bb}| 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) rename meta/recipes-connectivity/slirp/{libslirp_git.bb => libslirp

Re: [OE-core] [PATCH v3 2/2] scripts: add b4-wrapper for poky

2025-02-05 Thread Ross Burton via lists.openembedded.org
> On 5 Feb 2025, at 15:05, Quentin Schulz via lists.openembedded.org > wrote: > +if subprocess.call(["which", "lsdiff"], stdout=subprocess.DEVNULL) != 0: “which” isn’t actually a standard tool, so I’d use shutil.which() instead: guaranteed to work and no need to spawn. Ross -=-=-=-=-=-=-=-

[OE-core] [PATCH v3][OE-core 4/4] cve-check: allow feed choice

2025-02-05 Thread Marta Rybczynska via lists.openembedded.org
Allow choice of one of three feeds and update task dependencies accordingly. All feeds contain data from NVD and are stored in different files. Set the NVD_DB_VERSION variable to choose feed: NVD2 (default) - the NVD feed with API version 2 NVD1 - the NVD JSON feed (deprecated) FKIE - the FKIE-CAD

Re: [OE-core][PATCH v6 1/3] rpm-sequoia: New recipe for version 1.7.0

2025-02-05 Thread Alexander Kanavin via lists.openembedded.org
On Wed, 5 Feb 2025 at 16:45, Böszörményi Zoltán wrote: > > I'd be ok with a separate recipe for it. > > For all of the fedora-crypto-policies contents, or just for the one for > rpm-sequoia? We can just pick the one file we need out of it in do_install. Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You

Re: [OE-core][PATCH v6 1/3] rpm-sequoia: New recipe for version 1.7.0

2025-02-05 Thread Zoltan Boszormenyi via lists.openembedded.org
2025. 02. 05. 16:34 keltezéssel, Alexander Kanavin írta: On Wed, 5 Feb 2025 at 16:21, Böszörményi Zoltán wrote: Okay, how about using a git:// SRC_URI entry for fedora-crypto-policies? That should be self explanatory and no "magic file". However, I had to do this abomination of a workaround to

Re: [OE-core][PATCH v6 1/3] rpm-sequoia: New recipe for version 1.7.0

2025-02-05 Thread Alexander Kanavin via lists.openembedded.org
On Wed, 5 Feb 2025 at 16:21, Böszörményi Zoltán wrote: > Okay, how about using a git:// SRC_URI entry for fedora-crypto-policies? > That should be self explanatory and no "magic file". > > However, I had to do this abomination of a workaround to > exclude the directory from being manhandled by "ca

Re: [OE-core][PATCH v6 1/3] rpm-sequoia: New recipe for version 1.7.0

2025-02-05 Thread Zoltan Boszormenyi via lists.openembedded.org
2025. 02. 05. 11:56 keltezéssel, Alexander Kanavin írta: On Wed, 5 Feb 2025 at 05:36, Zoltán Böszörményi wrote: Also ship a crypto policy file which is used to validate signing keys. .../rpm-sequoia/rpm-sequoia.config| 51 ++ +++ b/meta/recipes-devtools/rpm-sequoia/rpm-sequoia/rpm

Re: [OE-core][PATCH v6 3/3] oeqa/selftest/cases/signing.py: Re-enable self-test

2025-02-05 Thread Zoltan Boszormenyi via lists.openembedded.org
2025. 02. 05. 12:04 keltezéssel, Alexander Kanavin írta: On Wed, 5 Feb 2025 at 05:36, Zoltán Böszörményi wrote: Add a crypto policy file (identical to the one shipped by rpm-sequoia) and use its path in SEQUOIA_CRYPTO_POLICY envvar for runCmd('rpmkeys') commands. This complicated maintaining t

[OE-core] Patchtest results for [PATCH v3 1/2] add basic b4 config file

2025-02-05 Thread Patchtest via lists.openembedded.org
Thank you for your submission. Patchtest identified one or more issues with the patch. Please see the log below for more information: --- Testing patch /home/patchtest/share/mboxes/v3-1-2-add-basic-b4-config-file.patch FAIL: test shortlog format: Commit shortlog (first line of commit message) sh

[OE-core] [PATCH v3 1/2] add basic b4 config file

2025-02-05 Thread Quentin Schulz
From: Quentin Schulz b4[1] is a very nice tool for mail-based contribution. A config[2] file exists to set up a few defaults. We can use it to set the Cc recipients to always add, in our case the mailing list. Because we do not have anything to check for now, disable needs-checking so patches ca

[OE-core] [PATCH v3 0/2] add basic b4 config file

2025-02-05 Thread Quentin Schulz
This adds very basic support for using b4 in OE-Core. This essentially just automatically adds the proper mailing list when running b4 prep --auto-to-cc. This also adds the b4 wrapper script that poky will need to use in order to identify which mailing list a patch needs to be sent to and do some

[OE-core] [PATCH v3 2/2] scripts: add b4-wrapper for poky

2025-02-05 Thread Quentin Schulz
From: Quentin Schulz poky is a combo-layer containing BitBake, OpenEmbedded-Core and Yocto Documentation source code into one big repo. It is not uncommon to have people develop patches for either of those projects from a poky git repo. However, it is unlikely those patches are to be sent to the

[OE-core] [PATCH v3][OE-core 2/4] cve-update-db-native: update structure

2025-02-05 Thread Marta Rybczynska via lists.openembedded.org
Update the database structure and tasks to fit the current YP master. This means: - add the unpack task - update the database structure (CVSS, vector string) However, the old feed does not include CVSS4 Signed-off-by: Marta Rybczynska --- .../recipes-core/meta/cve-update-db-native.bb | 26 +

[OE-core] [PATCH v3][OE-core 1/4] cve-update-db-native: restore

2025-02-05 Thread Marta Rybczynska via lists.openembedded.org
Restore cve-update-db from kirkstone Use cve-update-db-native.bb from OE 8c10f4a4dc12f65212576e6e568fa4369014aaa0 Signed-off-by: Marta Rybczynska --- .../recipes-core/meta/cve-update-db-native.bb | 291 ++ 1 file changed, 291 insertions(+) create mode 100644 meta/recipes-core/m

Re: [OE-core] [PATCH v2][OE-core 4/4] cve-check: allow feed choice

2025-02-05 Thread Marta Rybczynska via lists.openembedded.org
I've submitted the v3. It fixes the typo, upgrades the warning to erroronce, but still defaults to NVD2. One other change is the move to different database file names for each feed. There might be slight transitional differences between them depending on the synchronization time. A merge between s

[OE-core] [PATCH v3][OE-core 3/4] cve-update-db-native: add the fkie source

2025-02-05 Thread Marta Rybczynska via lists.openembedded.org
Add support for FKIE-CAD reconstruction of NVD feed from https://github.com/fkie-cad/nvd-json-data-feeds We download this feed directly from github releases. Signed-off-by: Marta Rybczynska --- .../recipes-core/meta/cve-update-db-native.bb | 126 -- 1 file changed, 113 insertion

[OE-core] [PATCH v3][OE-core 0/4] cve-check: allow feed selection

2025-02-05 Thread Marta Rybczynska via lists.openembedded.org
This series is allowing choice of the NVD feed to use, you can configure them using the NVD_DB_VERSION variable in local.conf Available feeds: - NVD2 (default) - the current NVD API v2 feed - NVD1 - the old NVD feed (deprecated, but still working) - FKIE - the NVD feed restoration from FKIE-CAD M

Re: [OE-core] [PATCH v2 1/2] add basic b4 config file

2025-02-05 Thread Richard Purdie via lists.openembedded.org
On Wed, 2025-02-05 at 14:09 +0100, Quentin Schulz via lists.openembedded.org wrote: > Hi all, > > On 2/3/25 4:17 PM, Quentin Schulz wrote: > > From: Quentin Schulz > > > > b4[1] is a very nice tool for mail-based contribution. A config[2] file > > exists to set up a few defaults. We can use it

Re: [OE-core] [PATCH v2 1/2] add basic b4 config file

2025-02-05 Thread Quentin Schulz via lists.openembedded.org
Hi all, On 2/3/25 4:17 PM, Quentin Schulz wrote: From: Quentin Schulz b4[1] is a very nice tool for mail-based contribution. A config[2] file exists to set up a few defaults. We can use it to set the Cc recipients to always add, in our case the mailing list. Because we do not have anything to

Re: [OE-core] [PATCH v3 1/3] systemd-boot-native: undelete but disable configure and compile tasks

2025-02-05 Thread Richard Purdie via lists.openembedded.org
On Tue, 2025-02-04 at 16:17 +0200, Mikko Rapeli via lists.openembedded.org wrote: > The tasks were deleted and do_patch() was run after do_install() > which means that patches applied in SRC_URI were not in the > ukify.py binary installed. Mark the tasks as noexec since > they don't need to do anyt

Re: [OE-core] [PATCH v2][OE-core 4/4] cve-check: allow feed choice

2025-02-05 Thread Marta Rybczynska via lists.openembedded.org
Hello, This one is simple. cve-update-db-native is starting from 2002, while cve-update-nvd2-native from the beginning of the database, so 1999. We might unify this, but I do not consider it priority. Kind regards, Marta On Wed, Jan 15, 2025 at 1:23 PM Ross Burton wrote: > Hi, > > Also I ran t

Re: [OE-core] [PATCH] image/populate_sdk: Support usrmerge for nativesdk in SDK builds

2025-02-05 Thread Sean Nyekjaer via lists.openembedded.org
On Wed, Feb 05, 2025 at 11:10:37AM +0100, Richard Purdie wrote: [...] > > There are other ways to solve this problem.  > > Sean said you need libudev in nativesdk and I'd imagine there are other > ways to manage to build that without changing the whole SDK layout. > Sure, that is probably a path

Re: [OE-core] [PATCH] image/populate_sdk: Support usrmerge for nativesdk in SDK builds

2025-02-05 Thread Richard Purdie via lists.openembedded.org
On Wed, 2025-02-05 at 11:29 +0100, Esben Haabendal via lists.openembedded.org wrote: > "Richard Purdie via lists.openembedded.org" > writes: > > > > We'd at least need to make sure there were clear errors about why the > > > > configuration wouldn't work. > > > > > > Do you mean > > > > > > 1.

Re: [OE-core][PATCH v6 3/3] oeqa/selftest/cases/signing.py: Re-enable self-test

2025-02-05 Thread Alexander Kanavin via lists.openembedded.org
On Wed, 5 Feb 2025 at 05:36, Zoltán Böszörményi wrote: > Add a crypto policy file (identical to the one shipped by > rpm-sequoia) and use its path in SEQUOIA_CRYPTO_POLICY envvar > for runCmd('rpmkeys') commands. This complicated maintaining the policy file even further. Rather, you should set th

Re: [OE-core][PATCH v6 1/3] rpm-sequoia: New recipe for version 1.7.0

2025-02-05 Thread Alexander Kanavin via lists.openembedded.org
On Wed, 5 Feb 2025 at 05:36, Zoltán Böszörményi wrote: > Also ship a crypto policy file which is used to validate > signing keys. > .../rpm-sequoia/rpm-sequoia.config| 51 ++ > +++ b/meta/recipes-devtools/rpm-sequoia/rpm-sequoia/rpm-sequoia.config > @@ -0,0 +1,51 @@ > +[hash_algorithm

Re: [OE-core] [PATCH] image/populate_sdk: Support usrmerge for nativesdk in SDK builds

2025-02-05 Thread Esben Haabendal via lists.openembedded.org
"Richard Purdie via lists.openembedded.org" writes: > On Wed, 2025-02-05 at 10:53 +0100, Esben Haabendal wrote: >> Richard Purdie writes: >> >> > On Wed, 2025-02-05 at 09:28 +0100, Esben Haabendal wrote: >> > > "Richard Purdie via lists.openembedded.org" >> > > writes: >> > > > > Is anything h

Re: [OE-core] [PATCH] image/populate_sdk: Support usrmerge for nativesdk in SDK builds

2025-02-05 Thread Richard Purdie via lists.openembedded.org
On Wed, 2025-02-05 at 10:53 +0100, Esben Haabendal wrote: > Richard Purdie writes: > > > On Wed, 2025-02-05 at 09:28 +0100, Esben Haabendal wrote: > > > "Richard Purdie via lists.openembedded.org" > > > writes: > > > > > Is anything holding this back? > > > > > > > > Yes, there is. > > > > > >

Re: [OE-core] [PATCH] image/populate_sdk: Support usrmerge for nativesdk in SDK builds

2025-02-05 Thread Esben Haabendal via lists.openembedded.org
Richard Purdie writes: > On Wed, 2025-02-05 at 09:28 +0100, Esben Haabendal wrote: >> "Richard Purdie via lists.openembedded.org" >> writes: >> > > Is anything holding this back? >> > >> > Yes, there is. >> > >> > You're using the SDK in a way which it wasn't really intended for and >> > we're

[OE-core] Patchtest results for [PATCH v3 2/2] systemd: Build the systemctl executable

2025-02-05 Thread Patchtest via lists.openembedded.org
Thank you for your submission. Patchtest identified one or more issues with the patch. Please see the log below for more information: --- Testing patch /home/patchtest/share/mboxes/v3-2-2-systemd-Build-the-systemctl-executable.patch FAIL: test lic files chksum modified not mentioned: LIC_FILES_C

[OE-core] [PATCH v3 2/2] systemd: Build the systemctl executable

2025-02-05 Thread Vyacheslav Yurkov via lists.openembedded.org
From: Vyacheslav Yurkov Instead of the python re-implementation build the actual systemctl from the systemd source tree. The python script was used when systemd didn't provide an option to build individual executables. It is possible in the meantime, so instead of always adapting the script when

[OE-core] [PATCH v3 1/2] meson.bbclass: Add an option to specify install tags

2025-02-05 Thread Vyacheslav Yurkov via lists.openembedded.org
From: Vyacheslav Yurkov The feature is available since meson 0.60.0. You can specify comma-separated list of install tags (not targets). Signed-off-by: Vyacheslav Yurkov --- meta/classes-recipe/meson.bbclass | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/meta/classe

Re: [OE-core] [PATCH] image/populate_sdk: Support usrmerge for nativesdk in SDK builds

2025-02-05 Thread Richard Purdie via lists.openembedded.org
On Wed, 2025-02-05 at 09:28 +0100, Esben Haabendal wrote: > "Richard Purdie via lists.openembedded.org" > writes: > > > Is anything holding this back? > > > > Yes, there is. > > > > You're using the SDK in a way which it wasn't really intended for and > > we're seeing "feature creep" where syste

Re: [OE-core] [PATCH v2 3/3] systemd: Build the systemctl executable

2025-02-05 Thread Zoltan Boszormenyi via lists.openembedded.org
2025. 02. 04. 11:53 keltezéssel, Vyacheslav Yurkov via lists.openembedded.org írta: From: Vyacheslav Yurkov Instead of the python re-implementation build the actual systemctl from the systemd source tree. The python script was used when systemd didn't provide an option to build individual exec

Re: [OE-core] [PATCH] image/populate_sdk: Support usrmerge for nativesdk in SDK builds

2025-02-05 Thread Esben Haabendal via lists.openembedded.org
"Richard Purdie via lists.openembedded.org" writes: > On Tue, 2025-02-04 at 14:59 +0100, Sean Nyekjaer via > lists.openembedded.org wrote: >> Hi Ross, >> >> On Wed, Jan 22, 2025 at 03:04:35PM +0100, Sean Nyekjaer wrote: >> > On Wed, Jan 22, 2025 at 01:41:11PM +0100, Ross Burton wrote: >> > > Hi

[OE-core] [scarthgap][PATCH] binutils: File name too long causing failure to open temporary head file in dlltool

2025-02-05 Thread Song, Jiaying (CN) via lists.openembedded.org
From: Jiaying Song During the execution of the command: i686-w64-mingw32-dlltool --input-def $def_filepath --output-delaylib $filepath --dllname qemu.exe An error occurred: i686-w64-mingw32-dlltool: failed to open temporary head file: ..._w64_mingw32_nativesdk_qemu_8_2_2_build_plugins_libqemu_pl