Re: [OE-core] [PATCH v3 00/12] systemd uki support
On Thu, 2024-09-19 at 17:36 +0300, Mikko Rapeli via lists.openembedded.org wrote: > These changes enable building systemd uki images which combine > kernel, kernel command line, initrd and possibly signatures to > a single UEFI binary. This binary can be booted with UEFI firmware > and systemd-boot. No grub is needed and UEFI firmware and/or > systemd-boot provide possibilities for boot menus. > The uki binary can also be signed for UEFI secure boot > so the secure boot extends from firmware to kernel and initrd. > Binding secure boot to full userspace is then easier since for example > kernel command line and initrd contain the support needed to mount > encrypted dm-verity etc partitions, and/or create partitions on demand > with systemd-repart using device specific TPM devices for encryption. > > Tested on qemuarm64-secureboot machine from meta-arm with changes to > support secure boot. Slightly different configuration tested on > multiple arm64 System Ready boards with UEFI firmware, real and firmware > based TPM devices. Tested with ovmf firmware on x86_64 with selftests but > without secure boot which seems to be harder to setup in ovmf. > > Sadly I see two wic selftests, wic.Wic2.test_rawcopy_plugin_qemu and > wic.Wic2.test_expand_mbr_image, failing when executing all wic selftests > on a build machine with zfs filesystem. Will investigate this further. > The issue seems to be in mkfs.ext4 producing broken filesystem, and partially > in the tests which don't run the correct rootfs file (.ext4 vs .wic). > Will debug this further and it is IMO unrelated to these changes since > they reproduce on pure master branch without this series. > > v3: rebased, fixed and added more sefltests, removed wic plugin side uki > support > > v2: https://lists.openembedded.org/g/openembedded-core/message/204090 > > Michelle Lin (1): > uki.bbclass: add class for building Unified Kernel Images (UKI) > > Mikko Rapeli (11): > python3-pefile: add recipe from meta-openembedded > maintainers.inc: add python3-pefile > systemd-boot-native: add runtime dependency to python3-pefile-native > image_types_wic.bbclass: set systemd-boot and os-release dependency > for all archs > wic bootimg-efi.py: keep timestamps and add debug prints > wic bootimg-efi.py: change UKI support from wic plugin to uki.bbclass > oeqa selftest uki.py: add tests for uki.bbclass > oeqa selftest efibootpartition.py: add TEST_RUNQEMUPARAMS to runqemu > oeqa selftest efibootpartition.py: remove systemd-boot from grub-efi > test > oeqa selftest wic.py: add TEST_RUNQEMUPARAMS to runqemu > oeqa selftest wic.py: support UKIs via uki.bbclass > > meta-selftest/wic/test_efi_plugin.wks | 5 +- > meta/classes-recipe/image_types_wic.bbclass | 5 +- > meta/classes-recipe/uki.bbclass | 197 ++ > meta/conf/distro/include/maintainers.inc | 1 + > .../oeqa/selftest/cases/efibootpartition.py | 11 +- > meta/lib/oeqa/selftest/cases/uki.py | 138 > meta/lib/oeqa/selftest/cases/wic.py | 58 -- > .../systemd/systemd-boot-native_256.5.bb | 2 + > .../python/python3-pefile/run-ptest | 3 + > .../python/python3-pefile_2023.2.7.bb | 28 +++ > .../wic/canned-wks/efi-uki-bootdisk.wks.in | 3 + > scripts/lib/wic/plugins/source/bootimg-efi.py | 187 + > 12 files changed, 481 insertions(+), 157 deletions(-) > create mode 100644 meta/classes-recipe/uki.bbclass > create mode 100644 meta/lib/oeqa/selftest/cases/uki.py > create mode 100644 meta/recipes-devtools/python/python3-pefile/run-ptest > create mode 100644 meta/recipes-devtools/python/python3-pefile_2023.2.7.bb > create mode 100644 scripts/lib/wic/canned-wks/efi-uki-bootdisk.wks.in In addition to the other recipe issue, I also noticed selftest failing: https://valkyrie.yoctoproject.org/#/builders/35/builds/142/steps/14/logs/stdio "runqemu - ERROR - Can't handle two unknown args: None qemux86-64" (all the selftest targets failed, this is one example) Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#204725): https://lists.openembedded.org/g/openembedded-core/message/204725 Mute This Topic: https://lists.openembedded.org/mt/108540775/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 v3 01/12] python3-pefile: add recipe from meta-openembedded
On Thu, 2024-09-19 at 17:36 +0300, Mikko Rapeli via lists.openembedded.org
wrote:
> It is needed by systemd ukify tool and uki.bbclass to generate
> UEFI boot binaries.
>
> Signed-off-by: Mikko Rapeli
> ---
> .../python/python3-pefile/run-ptest | 3 ++
> .../python/python3-pefile_2023.2.7.bb | 28 +++
> 2 files changed, 31 insertions(+)
> create mode 100644 meta/recipes-devtools/python/python3-pefile/run-ptest
> create mode 100644 meta/recipes-devtools/python/python3-pefile_2023.2.7.bb
>
> diff --git a/meta/recipes-devtools/python/python3-pefile/run-ptest
> b/meta/recipes-devtools/python/python3-pefile/run-ptest
> new file mode 100644
> index 00..95ae72306f
> --- /dev/null
> +++ b/meta/recipes-devtools/python/python3-pefile/run-ptest
> @@ -0,0 +1,3 @@
> +#!/bin/sh
> +
> +pytest --automake --ignore=./tests/pefile_test.py
> diff --git a/meta/recipes-devtools/python/python3-pefile_2023.2.7.bb
> b/meta/recipes-devtools/python/python3-pefile_2023.2.7.bb
> new file mode 100644
> index 00..e30b362323
> --- /dev/null
> +++ b/meta/recipes-devtools/python/python3-pefile_2023.2.7.bb
> @@ -0,0 +1,28 @@
> +SUMMARY = "Python PE parsing module"
> +DESCRIPTION = "A multi-platform Python module to parse and work with
> Portable Executable (PE) files."
> +HOMEPAGE = "https://github.com/erocarrera/pefile";
> +LICENSE = "MIT"
> +LIC_FILES_CHKSUM = "file://LICENSE;md5=3807888b01d8118ff9cc23da1873"
> +
> +inherit setuptools3 ptest
> +SRCREV = "1ab2807c4eec16041e791d7a6acc68cc23fd5266"
> +SRC_URI = "git://github.com/erocarrera/pefile;branch=master;protocol=https \
> + file://run-ptest"
> +S = "${WORKDIR}/git"
> +
> +BBCLASSEXTEND = "native nativesdk"
> +
> +do_install_ptest() {
> + install -d ${D}${PTEST_PATH}/tests
> + cp -rf ${S}/tests/* ${D}${PTEST_PATH}/tests/
> +}
> +
> +RDEPENDS:${PN} += " \
> + python3-mmap \
> + python3-netclient \
> + python3-stringold \
> +"
> +RDEPENDS:${PN}-ptest += "\
> + python3-pytest \
> + python3-unittest-automake-output \
> +"
I've not gone into the series in detail but there was testing capacity
so I did run it through that. This recipe caused:
https://valkyrie.yoctoproject.org/#/builders/59/builds/140/steps/11/logs/stdio
https://valkyrie.yoctoproject.org/#/builders/17/builds/144/steps/12/logs/stdio
https://valkyrie.yoctoproject.org/#/builders/37/builds/169/steps/12/logs/stdio
https://valkyrie.yoctoproject.org/#/builders/6/builds/153/steps/11/logs/stdio
https://valkyrie.yoctoproject.org/#/builders/3/builds/162/steps/11/logs/stdio
https://valkyrie.yoctoproject.org/#/builders/25/builds/154/steps/11/logs/stdio
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#204724):
https://lists.openembedded.org/g/openembedded-core/message/204724
Mute This Topic: https://lists.openembedded.org/mt/108540778/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 v7 0/7] Add barebox bootloader support (and testing)
On Thu, 2024-09-19 at 14:06 +0200, Enrico Jörns wrote: > This adds support for the barebox bootloader (and tools) to oe-core. > > In order to have proper testing, this extends oe-selftest to allow > basic testing of bootloaders. While at it, cover both u-boot and > barebox. > > v7: > * add missing HOMEPAGE to barebox recipe > * ignore barebox for maintainers check since the recipe is skipped > during parsing (because of PREFERRED_PROVIDER mechanism). > > Enrico Jorns (5): > barebox: set default BAREBOX_CONFIG for qemu machines > oeqa/utils/qemurunner: support ignoring vt100 escape sequences > oeqa: support passing custom boot patterns to runqemu > oeqa/selftest/cases: add basic u-boot test > oeqa/selftest/cases: add basic barebox tests > > Marco Felsch (2): > barebox: add initial support > barebox-tools: add initial barebox tools support This looked better in testing, thanks. There was: https://valkyrie.yoctoproject.org/#/builders/23/builds/168/steps/14/logs/stdio which is from oe-selftest on an ARM server though :/ Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#204717): https://lists.openembedded.org/g/openembedded-core/message/204717 Mute This Topic: https://lists.openembedded.org/mt/108538165/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 v5 1/2] binutils: Fix packaging of bfd-plugins
On Thu, 2024-09-19 at 14:41 +0100, Richard Purdie via lists.openembedded.org
wrote:
> On Thu, 2024-09-19 at 05:48 -0700, Sadineni, Harish via
> lists.openembedded.org wrote:
> > From: Harish Sadineni
> >
> > Fixes the follwing error while building nativesdk-binutils with
> > i686-mingw32 as SDKMACHINE:
> > ERROR: nativesdk-binutils-2.43.1-r0 do_package: QA Issue:
> > nativesdk-binutils: Files/directories
> > were installed but not shipped in any package:
> >
> > /usr/local/oe-sdk-hardcoded-buildpath/sysroots/i686-w64-mingw32/usr/lib/bfd-plugins
> >
> > /usr/local/oe-sdk-hardcoded-buildpath/sysroots/i686-w64-mingw32/usr/lib/bfd-plugins/libdep.dll
> >
> > Signed-off-by: Harish Sadineni
> > ---
> > meta/recipes-devtools/binutils/binutils_2.43.1.bb | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/meta/recipes-devtools/binutils/binutils_2.43.1.bb
> > b/meta/recipes-devtools/binutils/binutils_2.43.1.bb
> > index 2cce40f1ef..eb7c16cbc4 100644
> > --- a/meta/recipes-devtools/binutils/binutils_2.43.1.bb
> > +++ b/meta/recipes-devtools/binutils/binutils_2.43.1.bb
> > @@ -72,5 +72,6 @@ SRC_URI:append:class-nativesdk = "
> > file://0003-binutils-nativesdk-Search-for-al
> >
> > USE_ALTERNATIVES_FOR:class-nativesdk = ""
> > FILES:${PN}:append:class-nativesdk = " ${bindir}"
> > +FILES:${PN}:append:class-nativesdk = " ${libdir}/bfd-plugins"
> >
> > BBCLASSEXTEND = "native nativesdk"
>
> I ended up digging into this a lot more. I was able to reproduce the
> failure locally but that implies the autobuilder isn't testing this
> combination. According to the configuration, it should be so I'm a bit
> puzzled why the autobuilder doesn't see it.
>
> The autobuilder config for this is here:
>
> https://git.yoctoproject.org/yocto-autobuilder-helper/tree/config.json#n1362
>
> Resulting in a build such as this:
>
> https://valkyrie.yoctoproject.org/#/builders/7/builds/162
>
> I would like to understand why automated testing isn't catching this.
Just to complete things on this topic, I realised the issue. We build
binutils-cross-canadian-* for mingw but nativesdk-bintuils isn't that
useful in general on mingw and isn't built. I'd be curious if you are
actually using it.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#204716):
https://lists.openembedded.org/g/openembedded-core/message/204716
Mute This Topic: https://lists.openembedded.org/mt/108538762/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 2/2] binutils: Fix binutils mingw packaging
Use SOLIBSDEV in FILES to fix nativesdk-binutils packaging on mingw
builds.
Signed-off-by: Richard Purdie
---
meta/recipes-devtools/binutils/binutils.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/binutils/binutils.inc
b/meta/recipes-devtools/binutils/binutils.inc
index e176b5cff1a..e1b903f1ebf 100644
--- a/meta/recipes-devtools/binutils/binutils.inc
+++ b/meta/recipes-devtools/binutils/binutils.inc
@@ -18,7 +18,7 @@ inherit autotools gettext multilib_header pkgconfig texinfo
FILES:${PN} = " \
${bindir}/${TARGET_PREFIX}* \
${libdir}/lib*.so.* \
- ${libdir}/bfd-plugins/lib*.so \
+ ${libdir}/bfd-plugins/lib*${SOLIBSDEV} \
${libdir}/lib*-${PV}*.so \
${prefix}/${TARGET_SYS}/bin/* \
${bindir}/embedspu"
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#204715):
https://lists.openembedded.org/g/openembedded-core/message/204715
Mute This Topic: https://lists.openembedded.org/mt/108547798/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 1/2] bitbake.conf: Add mingw32 SOLIBS and SOLIBSDEV definitions
We may as well define the dll output for mingw alongside the darwin dylib definitions. There are some recipes which output .so files even on mingw but those can be handled specifically in mingw. Signed-off-by: Richard Purdie --- meta/conf/bitbake.conf | 2 ++ 1 file changed, 2 insertions(+) diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf index ab4c6a2d9c9..3f583668f66 100644 --- a/meta/conf/bitbake.conf +++ b/meta/conf/bitbake.conf @@ -307,12 +307,14 @@ BB_MULTI_PROVIDER_ALLOWED = "virtual/libintl virtual/libintl-native virtual/nati SOLIBS = ".so.*" SOLIBS:darwin = ".dylib" +SOLIBS:mingw32 = ".dll" SOLIBSDEV = ".so" # Due to the ordering of PACKAGES and the naming of the dev symlinks on darwin, # we can't make the symlinks end up in the -dev packages easily at this point. This hack # at least means builds aren't completely broken and symlinks don't take up much space. SOLIBSDEV:darwin = ".dylibbroken" +SOLIBSDEV:mingw32 = ".dll" PACKAGE_DEBUG_SPLIT_STYLE ?= "debug-with-srcpkg" -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#204714): https://lists.openembedded.org/g/openembedded-core/message/204714 Mute This Topic: https://lists.openembedded.org/mt/108547797/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 v5 2/2] nativesdk-packagegroup-sdk-host: Add missing perl modules to RDEPENDS
On Thu, 2024-09-19 at 05:48 -0700, Sadineni, Harish via lists.openembedded.org wrote: > From: Harish Sadineni > > In SDK, missing perl modules causes 'x86_64-pokysdk-linux-gp-display-html > --help' to abort with below errors.. > - Can't locate bignum.pm in @INC (you may need to install the feature > module). > - Can't locate Math/BigInt.pm in @INC (you may need to install the > Math::BigInt module) > > By adding the following perl modules to RDEPENDS fixes the above errors: > nativesdk-perl-module-bignum > nativesdk-perl-module-bigint > nativesdk-perl-module-math-bigint > > Signed-off-by: Harish Sadineni > --- > meta/recipes-devtools/binutils/binutils_2.43.1.bb | 4 > 1 file changed, 4 insertions(+) You've updated the commit to do what is needed whic is great, thanks. Unfortunately the shortlog is now incorrect though. It should now read: "binutils: Add missing perl modules to RDEPENDS for nativsdk variant" The patch also fails to apply as I can't take 1/2 for other reasons as discussed. I'm going to tweak the patch locally for testing though on this occasion. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#204713): https://lists.openembedded.org/g/openembedded-core/message/204713 Mute This Topic: https://lists.openembedded.org/mt/108538761/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] cve-check: add field "modified" to JSON report
On Thu, 2024-09-19 at 15:40 +0200, Katawann via lists.openembedded.org
wrote:
> cve-check: add field "modified" to JSON report
>
> Signed-off-by: Katawann
> ---
> meta/classes/cve-check.bbclass | 1 +
> 1 file changed, 1 insertion(+)
Duplicating the shortlog isn't a great way to avoid the patchtest
email. You had some good text in your 0/1 cover letter. I'd suggest
putting that ("Added the "modified" field to the JSON export in the
cve-check.class. This field captures the last modification date of each
CVE, providing more detailed information on changes and updates within
the exported data.") into the main commit message instead.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#204710):
https://lists.openembedded.org/g/openembedded-core/message/204710
Mute This Topic: https://lists.openembedded.org/mt/108539655/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 v5 1/2] binutils: Fix packaging of bfd-plugins
On Thu, 2024-09-19 at 05:48 -0700, Sadineni, Harish via lists.openembedded.org
wrote:
> From: Harish Sadineni
>
> Fixes the follwing error while building nativesdk-binutils with i686-mingw32
> as SDKMACHINE:
> ERROR: nativesdk-binutils-2.43.1-r0 do_package: QA Issue: nativesdk-binutils:
> Files/directories
> were installed but not shipped in any package:
>
> /usr/local/oe-sdk-hardcoded-buildpath/sysroots/i686-w64-mingw32/usr/lib/bfd-plugins
>
> /usr/local/oe-sdk-hardcoded-buildpath/sysroots/i686-w64-mingw32/usr/lib/bfd-plugins/libdep.dll
>
> Signed-off-by: Harish Sadineni
> ---
> meta/recipes-devtools/binutils/binutils_2.43.1.bb | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/meta/recipes-devtools/binutils/binutils_2.43.1.bb
> b/meta/recipes-devtools/binutils/binutils_2.43.1.bb
> index 2cce40f1ef..eb7c16cbc4 100644
> --- a/meta/recipes-devtools/binutils/binutils_2.43.1.bb
> +++ b/meta/recipes-devtools/binutils/binutils_2.43.1.bb
> @@ -72,5 +72,6 @@ SRC_URI:append:class-nativesdk = "
> file://0003-binutils-nativesdk-Search-for-al
>
> USE_ALTERNATIVES_FOR:class-nativesdk = ""
> FILES:${PN}:append:class-nativesdk = " ${bindir}"
> +FILES:${PN}:append:class-nativesdk = " ${libdir}/bfd-plugins"
>
> BBCLASSEXTEND = "native nativesdk"
I ended up digging into this a lot more. I was able to reproduce the
failure locally but that implies the autobuilder isn't testing this
combination. According to the configuration, it should be so I'm a bit
puzzled why the autobuilder doesn't see it.
The autobuilder config for this is here:
https://git.yoctoproject.org/yocto-autobuilder-helper/tree/config.json#n1362
Resulting in a build such as this:
https://valkyrie.yoctoproject.org/#/builders/7/builds/162
I would like to understand why automated testing isn't catching this.
Getting back to the patch, I noticed that bintutils.inc already does:
FILES:${PN} = " \
${bindir}/${TARGET_PREFIX}* \
${libdir}/lib*.so.* \
${libdir}/bfd-plugins/lib*.so \
...
and the issue is that it uses .so and the recipe is generating a .dll
file.
I'd note that bitbake.conf has:
SOLIBS = ".so.*"
SOLIBS:darwin = ".dylib"
SOLIBSDEV = ".so"
# Due to the ordering of PACKAGES and the naming of the dev symlinks on darwin,
# we can't make the symlinks end up in the -dev packages easily at this point.
This hack
# at least means builds aren't completely broken and symlinks don't take up
much space.
SOLIBSDEV:darwin = ".dylibbroken"
with the intent of being able to abstract out dylib/so/dll references.
I'm wondering if we should add:
SOLIBS:mingw32 = ".dll"
SOLIBSDEV:mingw32 = ".dll"
which would then let us change the binutils.inc entry to:
${libdir}/bfd-plugins/lib*${SOLIBSDEV}
In testing this I found it breaks zstd and zlib since those always
generate .so files even on mingw. I've hardcoded SOLIBS and SOLIBSDEV
in the bbappends in mingw to counteract that:
https://git.yoctoproject.org/meta-mingw/commit/?id=db1f53f73e95499a5f0b0edc45dd9cc9718d3c8a
I think these changes should combine to fix the underlying problem and
also make it easier to fix things like this in future.
They probably need wider testing though.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#204690):
https://lists.openembedded.org/g/openembedded-core/message/204690
Mute This Topic: https://lists.openembedded.org/mt/108538762/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 2/2] oeqa/postactions: do not uncompress retrieved archive on host
On Thu, 2024-09-19 at 08:42 +0100, Richard Purdie via
lists.openembedded.org wrote:
> On Mon, 2024-08-12 at 17:14 +0200, Alexis Lothoré via
> lists.openembedded.org wrote:
> > From: Alexis Lothoré
> >
> > Current postaction module executes a remote tar command, pipe it in
> > a SSH
> > connection, and uncompress the raw stream with another tar command.
> > With
> > this command, the whole artifacts tree is directly available on the
> > host
> > executing the test, but it is not very convenient if we want to
> > download
> > the whole retrieved ptests directory.
> >
> > Stop uncompressing the retrieved ptests archive onto host, just
> > save the
> > archive as it is. The new output then looks like the following:
> >
> > tmp/log/oeqa-artefacts
> > └── oeqa-target-artefacts-20240812-juzqdb80
> > ├── host_disk_usage.txt
> > ├── target_disk_usage.txt
> > └── tests_artifacts.tar.gz
> >
> > Suggested-By: Alexandre Belloni
> > Signed-off-by: Alexis Lothoré
> > ---
> > meta/lib/oeqa/utils/postactions.py | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/meta/lib/oeqa/utils/postactions.py
> > b/meta/lib/oeqa/utils/postactions.py
> > index 3b537146c50a..d5080523aa83 100644
> > --- a/meta/lib/oeqa/utils/postactions.py
> > +++ b/meta/lib/oeqa/utils/postactions.py
> > @@ -68,7 +68,8 @@ def list_and_fetch_failed_tests_artifacts(d, tc,
> > artifacts_list, outputdir):
> > (status, output) = tc.target.run(cmd, raw = True)
> > if status != 0 or not output:
> > raise Exception("Error while fetching compressed
> > artifacts")
> > - p = subprocess.run(["tar", "zxf", "-", "-C", outputdir],
> > input=output)
> > + with open(archive_name, "wb") as f:
> > + f.write(output)
> > except Exception as e:
> > bb.warn(f"Can not retrieve artifacts from test target:
> > {e}")
>
>
> This change is causing failures since archive_name isn't defined
> anywhere :/
I'd also note that scarthgap actually throws errors:
https://valkyrie.yoctoproject.org/#/builders/73/builds/135/steps/12/logs/stdio
Exception: NameError: name 'artifact_path' is not defined
which is related to some of these patches :/.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#204684):
https://lists.openembedded.org/g/openembedded-core/message/204684
Mute This Topic: https://lists.openembedded.org/mt/107858382/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] [scarthgap][PATCH] gcc-target.inc: Add RPROVIDES to resolve gcc-symlinks & lib32-gcc-symlinks file conflicts
On Thu, 2024-09-19 at 03:22 -0700, Hemraj, Deepthi via lists.openembedded.org
wrote:
> From: Deepthi Hemraj
>
> Enabling multilib support and adding both lib32-gcc-symlinks and gcc-symlinks
> to the image installation results in a conflict between
> gcc-symlinks-13.3.0-r0.corei7_64 and lib32-gcc-symlinks-13.3.0-r0.corei7_32.
> Following error occurs because of the conflict:
> "file /usr/bin/gcc conflicts between attempted installs of
> gcc-symlinks-13.3.0-r0.corei7_64 and lib32-gcc-symlinks-13.3.0-r0.corei7_32"
>
> The conflict occurs because both packages try to install files in the same
> location,
> causing installation errors during the build process.
>
> By using the RPROVIDES, gcc package can satisfy the dependencies for both
> `gcc-symlinks` and `lib32-gcc-symlinks`.
> This prevents the conflict, while ensuring that both 32-bit and 64-bit
> symlink packages can co-exist.
>
> Signed-off-by: Deepthi Hemraj
> ---
> meta/recipes-devtools/gcc/gcc-target.inc | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/meta/recipes-devtools/gcc/gcc-target.inc
> b/meta/recipes-devtools/gcc/gcc-target.inc
> index 7dac3ef422..f31ea15740 100644
> --- a/meta/recipes-devtools/gcc/gcc-target.inc
> +++ b/meta/recipes-devtools/gcc/gcc-target.inc
> @@ -27,6 +27,7 @@ EXTRA_OECONF:append:x86-64:class-target = "
> ${@get_gcc_x86_64_arch_setting(bb, d
> export gcc_cv_objdump = "${TARGET_PREFIX}objdump"
>
> EXTRA_OECONF_GCC_FLOAT = "${@get_gcc_float_setting(bb, d)}"
> +RPROVIDES:${PN} += "gcc-symlinks lib32-gcc-symlinks"
>
> PACKAGES = "\
> ${PN} ${PN}-plugins ${PN}-symlinks \
>
This isn't correct. What if my multilib was "lib64" or something else?
This definitely can't be hardcoded like that.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#204671):
https://lists.openembedded.org/g/openembedded-core/message/204671
Mute This Topic: https://lists.openembedded.org/mt/108536953/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 v4 2/2] nativesdk-packagegroup-sdk-host: Add missing perl modules to RDEPENDS
On Thu, 2024-09-19 at 02:42 -0700, Sadineni, Harish via lists.openembedded.org
wrote:
> From: Harish Sadineni
>
> In SDK, missing perl modules causes 'x86_64-pokysdk-linux-gp-display-html
> --help' to abort with below errors..
> - Can't locate bignum.pm in @INC (you may need to install the feature
> module).
> - Can't locate Math/BigInt.pm in @INC (you may need to install the
> Math::BigInt module)
>
> By adding the following perl modules to RDEPENDS fixes the above errors:
> nativesdk-perl-module-bignum
> nativesdk-perl-module-bigint
> nativesdk-perl-module-math-bigint
>
> Signed-off-by: Harish Sadineni
> ---
> .../packagegroups/nativesdk-packagegroup-sdk-host.bb | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git
> a/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
> b/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
> index c1d3c25060..70a7d3e494 100644
> --- a/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
> +++ b/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
> @@ -30,6 +30,9 @@ RDEPENDS:${PN} = "\
> nativesdk-bison \
> nativesdk-flex \
> nativesdk-perl-module-integer \
> + nativesdk-perl-module-bignum \
> + nativesdk-perl-module-bigint \
> + nativesdk-perl-module-math-bigint \
> "
>
> RDEPENDS:${PN}:darwin = "\
This doesn't address my feedback/concerns in the original patch.
SHouldn't these dependencies be added to the nativesdk-binutils-gprofng
RDEPENDS?
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#204666):
https://lists.openembedded.org/g/openembedded-core/message/204666
Mute This Topic: https://lists.openembedded.org/mt/108536644/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 v6 0/7] Add barebox bootloader support (and testing)
On Thu, 2024-09-19 at 11:47 +0200, Enrico Jörns wrote: > Am Mittwoch, dem 18.09.2024 um 22:37 +0100 schrieb Richard Purdie: > > On Wed, 2024-09-18 at 13:45 +0200, Enrico Jörns wrote: > > > Am Mittwoch, dem 18.09.2024 um 12:21 +0100 schrieb Richard Purdie: > > > > On Wed, 2024-09-18 at 12:39 +0200, Enrico Jörns wrote: > > > > > Hi Richard, > > > > > > > > > > Am Mittwoch, dem 18.09.2024 um 11:11 +0100 schrieb Richard > > > > > Purdie: > > > > > > On Thu, 2024-09-12 at 11:18 +0200, Enrico Jörns via > > > > > > lists.openembedded.org wrote: > > > > > > > This adds support for the barebox bootloader (and tools) to > > > > > > > oe- > > > > > > > core. > > > > > > > > > > > > > > In order to have proper testing, this extends oe-selftest to > > > > > > > allow > > > > > > > basic testing of bootloaders. While at it, cover both u-boot > > > > > > > and > > > > > > > barebox. > > > > > > > > > > > > > > v6: > > > > > > > * replace barebox.inc by barebox.bbclass (move content of > > > > > > > barebox-common.inc into .bbclass and .bb files) > > > > > > > * support for UNPACKDIR > > > > > > > > > > > > > > Enrico Jorns (5): > > > > > > > barebox: set default BAREBOX_CONFIG for qemu machines > > > > > > > oeqa/utils/qemurunner: support ignoring vt100 escape > > > > > > > sequences > > > > > > > oeqa: support passing custom boot patterns to runqemu > > > > > > > oeqa/selftest/cases: add basic u-boot test > > > > > > > oeqa/selftest/cases: add basic barebox tests > > > > > > > > > > > > > > Marco Felsch (2): > > > > > > > barebox: add initial support > > > > > > > barebox-tools: add initial barebox tools support > > > > > > > > > > > > We had some testing capacity so I ran this through automated > > > > > > testing. > > > > > > The one issue that showed up so far was: > > > > > > > > > > > > https://valkyrie.yoctoproject.org/#/builders/29/builds/174/steps/13/logs/warnings > > > > > > > > > > > > which is at least easily fixed! The rest of the build is still > > > > > > going. > > > > > > > > > > thanks for the test run and the first result. > > > > > > > > > > Indeed, looks easily fixable 😉 > > > > > Is it worth a v7 or should I wait for other results to show up? > > > > > > > > Most of the tests have run and there were other issues in the build > > > > but > > > > there was one other issue I noticed: > > > > > > > > https://valkyrie.yoctoproject.org/#/builders/54/builds/149/steps/14/logs/stdio > > > > > > > > which is a missing maintainers entry. Probably worth a v7 with > > > > those > > > > two things fixed. > > > > > > The test output says > > > > > > > Unable to find recipes for the following entries in > > > > maintainers.inc: > > > > barebox > > > > > > Could you give me a hint what that means? The barebox_2024.08.0.bb > > > and the change in maintainers.inc > > > are in the same commit. So I am unsure why it does not find the > > > recipe. > > > > It means the recipe is being skipped in the context of the QA test. > > This means there is a maintainers entry but the test can't see any > > recipe to match against it due to the skip. > > Thanks. I was not sure if the recipes are just evaluated and skipped based on > normal bitbake parsing > or if there is a special mechanism that just looks for .bb files. > > > The test is there to ensure when we delete recipes, we don't have stale > > entries in the file. > > > > Can we provide a config that makes sense for qemux86-64? > > The reason it is skipped from default parsing is > > PREFERRED_PROVIDER_virtual/bootloader = "u-boot" > > I put in meta/conf/machine/qemux86-64.conf since we have two competing > providers of > virtaul/bootloader now (and that's what the mechanism is actually made for I > guess 😉). > > Not sure if there is a way to remove the provider for just that check? > > Or should I add it to the exception list in distrodata.py like its done for > similar other recipes > that have competing providers (e.g. musl, newlib for virtual/libc; > linux-yocto, linux-dummy for > virtual/kernel)?. I think it will just have to go into the exception list. We really need to find a better way to do this but you're right, that is how we're doing it for the other cases. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#204665): https://lists.openembedded.org/g/openembedded-core/message/204665 Mute This Topic: https://lists.openembedded.org/mt/108410144/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 2/2] oeqa/postactions: do not uncompress retrieved archive on host
On Mon, 2024-08-12 at 17:14 +0200, Alexis Lothoré via lists.openembedded.org
wrote:
> From: Alexis Lothoré
>
> Current postaction module executes a remote tar command, pipe it in a SSH
> connection, and uncompress the raw stream with another tar command. With
> this command, the whole artifacts tree is directly available on the host
> executing the test, but it is not very convenient if we want to download
> the whole retrieved ptests directory.
>
> Stop uncompressing the retrieved ptests archive onto host, just save the
> archive as it is. The new output then looks like the following:
>
> tmp/log/oeqa-artefacts
> └── oeqa-target-artefacts-20240812-juzqdb80
> ├── host_disk_usage.txt
> ├── target_disk_usage.txt
> └── tests_artifacts.tar.gz
>
> Suggested-By: Alexandre Belloni
> Signed-off-by: Alexis Lothoré
> ---
> meta/lib/oeqa/utils/postactions.py | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/meta/lib/oeqa/utils/postactions.py
> b/meta/lib/oeqa/utils/postactions.py
> index 3b537146c50a..d5080523aa83 100644
> --- a/meta/lib/oeqa/utils/postactions.py
> +++ b/meta/lib/oeqa/utils/postactions.py
> @@ -68,7 +68,8 @@ def list_and_fetch_failed_tests_artifacts(d, tc,
> artifacts_list, outputdir):
> (status, output) = tc.target.run(cmd, raw = True)
> if status != 0 or not output:
> raise Exception("Error while fetching compressed artifacts")
> - p = subprocess.run(["tar", "zxf", "-", "-C", outputdir],
> input=output)
> + with open(archive_name, "wb") as f:
> + f.write(output)
> except Exception as e:
> bb.warn(f"Can not retrieve artifacts from test target: {e}")
This change is causing failures since archive_name isn't defined anywhere :/
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#204657):
https://lists.openembedded.org/g/openembedded-core/message/204657
Mute This Topic: https://lists.openembedded.org/mt/107858382/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 v6 0/7] Add barebox bootloader support (and testing)
On Wed, 2024-09-18 at 13:45 +0200, Enrico Jörns wrote: > Am Mittwoch, dem 18.09.2024 um 12:21 +0100 schrieb Richard Purdie: > > On Wed, 2024-09-18 at 12:39 +0200, Enrico Jörns wrote: > > > Hi Richard, > > > > > > Am Mittwoch, dem 18.09.2024 um 11:11 +0100 schrieb Richard > > > Purdie: > > > > On Thu, 2024-09-12 at 11:18 +0200, Enrico Jörns via > > > > lists.openembedded.org wrote: > > > > > This adds support for the barebox bootloader (and tools) to > > > > > oe- > > > > > core. > > > > > > > > > > In order to have proper testing, this extends oe-selftest to > > > > > allow > > > > > basic testing of bootloaders. While at it, cover both u-boot > > > > > and > > > > > barebox. > > > > > > > > > > v6: > > > > > * replace barebox.inc by barebox.bbclass (move content of > > > > > barebox-common.inc into .bbclass and .bb files) > > > > > * support for UNPACKDIR > > > > > > > > > > Enrico Jorns (5): > > > > > barebox: set default BAREBOX_CONFIG for qemu machines > > > > > oeqa/utils/qemurunner: support ignoring vt100 escape > > > > > sequences > > > > > oeqa: support passing custom boot patterns to runqemu > > > > > oeqa/selftest/cases: add basic u-boot test > > > > > oeqa/selftest/cases: add basic barebox tests > > > > > > > > > > Marco Felsch (2): > > > > > barebox: add initial support > > > > > barebox-tools: add initial barebox tools support > > > > > > > > We had some testing capacity so I ran this through automated > > > > testing. > > > > The one issue that showed up so far was: > > > > > > > > https://valkyrie.yoctoproject.org/#/builders/29/builds/174/steps/13/logs/warnings > > > > > > > > which is at least easily fixed! The rest of the build is still > > > > going. > > > > > > thanks for the test run and the first result. > > > > > > Indeed, looks easily fixable 😉 > > > Is it worth a v7 or should I wait for other results to show up? > > > > Most of the tests have run and there were other issues in the build > > but > > there was one other issue I noticed: > > > > https://valkyrie.yoctoproject.org/#/builders/54/builds/149/steps/14/logs/stdio > > > > which is a missing maintainers entry. Probably worth a v7 with > > those > > two things fixed. > > The test output says > > > Unable to find recipes for the following entries in > > maintainers.inc: > > barebox > > Could you give me a hint what that means? The barebox_2024.08.0.bb > and the change in maintainers.inc > are in the same commit. So I am unsure why it does not find the > recipe. It means the recipe is being skipped in the context of the QA test. This means there is a maintainers entry but the test can't see any recipe to match against it due to the skip. The test is there to ensure when we delete recipes, we don't have stale entries in the file. Can we provide a config that makes sense for qemux86-64? Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#204655): https://lists.openembedded.org/g/openembedded-core/message/204655 Mute This Topic: https://lists.openembedded.org/mt/108410144/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 v6 0/7] Add barebox bootloader support (and testing)
On Wed, 2024-09-18 at 12:39 +0200, Enrico Jörns wrote: > Hi Richard, > > Am Mittwoch, dem 18.09.2024 um 11:11 +0100 schrieb Richard Purdie: > > On Thu, 2024-09-12 at 11:18 +0200, Enrico Jörns via > > lists.openembedded.org wrote: > > > This adds support for the barebox bootloader (and tools) to oe- > > > core. > > > > > > In order to have proper testing, this extends oe-selftest to > > > allow > > > basic testing of bootloaders. While at it, cover both u-boot and > > > barebox. > > > > > > v6: > > > * replace barebox.inc by barebox.bbclass (move content of > > > barebox-common.inc into .bbclass and .bb files) > > > * support for UNPACKDIR > > > > > > Enrico Jorns (5): > > > barebox: set default BAREBOX_CONFIG for qemu machines > > > oeqa/utils/qemurunner: support ignoring vt100 escape sequences > > > oeqa: support passing custom boot patterns to runqemu > > > oeqa/selftest/cases: add basic u-boot test > > > oeqa/selftest/cases: add basic barebox tests > > > > > > Marco Felsch (2): > > > barebox: add initial support > > > barebox-tools: add initial barebox tools support > > > > We had some testing capacity so I ran this through automated > > testing. > > The one issue that showed up so far was: > > > > https://valkyrie.yoctoproject.org/#/builders/29/builds/174/steps/13/logs/warnings > > > > which is at least easily fixed! The rest of the build is still > > going. > > thanks for the test run and the first result. > > Indeed, looks easily fixable 😉 > Is it worth a v7 or should I wait for other results to show up? Most of the tests have run and there were other issues in the build but there was one other issue I noticed: https://valkyrie.yoctoproject.org/#/builders/54/builds/149/steps/14/logs/stdio which is a missing maintainers entry. Probably worth a v7 with those two things fixed. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#204642): https://lists.openembedded.org/g/openembedded-core/message/204642 Mute This Topic: https://lists.openembedded.org/mt/108410144/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] userns issues on Ubunu 24.04/24.10
I wanted to give people some real world data on the userns issues on
Ubuntu 24.04 and 24.10.
The advice has been to create /etc/apparmor.d/bitbake:
abi ,
include
profile bitbake /**/bitbake/bin/bitbake flags=(unconfined) {
userns,
}
EOF
and then reparse the config:
sudo apparmor_parser -r /etc/apparmor.d/bitbake
This "works" to a point however we started seeing weird failures on
some of the new autobuilder workers even with this applied.
The problem is BB_SERVER_TIMEOUT=60 the autobuilder uses which means
task execution commands may not be started with a "bitbake" command but
could be started by devtool or something else. Those don't match the
glob above.
So far the only reliable solution I've found was to effectively disable
the userns restrictions with a /** glob.
I wanted to try and stop someone else scratching their head over why
this fails.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#204641):
https://lists.openembedded.org/g/openembedded-core/message/204641
Mute This Topic: https://lists.openembedded.org/mt/108517994/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 v6 0/7] Add barebox bootloader support (and testing)
On Thu, 2024-09-12 at 11:18 +0200, Enrico Jörns via lists.openembedded.org wrote: > This adds support for the barebox bootloader (and tools) to oe-core. > > In order to have proper testing, this extends oe-selftest to allow > basic testing of bootloaders. While at it, cover both u-boot and barebox. > > v6: > * replace barebox.inc by barebox.bbclass (move content of > barebox-common.inc into .bbclass and .bb files) > * support for UNPACKDIR > > Enrico Jorns (5): > barebox: set default BAREBOX_CONFIG for qemu machines > oeqa/utils/qemurunner: support ignoring vt100 escape sequences > oeqa: support passing custom boot patterns to runqemu > oeqa/selftest/cases: add basic u-boot test > oeqa/selftest/cases: add basic barebox tests > > Marco Felsch (2): > barebox: add initial support > barebox-tools: add initial barebox tools support We had some testing capacity so I ran this through automated testing. The one issue that showed up so far was: https://valkyrie.yoctoproject.org/#/builders/29/builds/174/steps/13/logs/warnings which is at least easily fixed! The rest of the build is still going. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#204638): https://lists.openembedded.org/g/openembedded-core/message/204638 Mute This Topic: https://lists.openembedded.org/mt/108410144/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] scripts/install-buildtools: Update to 5.0.3
Update to the 5.0.3 release of the 5.0 series for buildtools. Signed-off-by: Richard Purdie --- scripts/install-buildtools | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts/install-buildtools b/scripts/install-buildtools index 5b86c130776..92a4c9dfb1a 100755 --- a/scripts/install-buildtools +++ b/scripts/install-buildtools @@ -57,8 +57,8 @@ logger = scriptutils.logger_create(PROGNAME, stream=sys.stdout) DEFAULT_INSTALL_DIR = os.path.join(os.path.split(scripts_path)[0],'buildtools') DEFAULT_BASE_URL = 'https://downloads.yoctoproject.org/releases/yocto' -DEFAULT_RELEASE = 'yocto-5.0.1' -DEFAULT_INSTALLER_VERSION = '5.0.1' +DEFAULT_RELEASE = 'yocto-5.0.3' +DEFAULT_INSTALLER_VERSION = '5.0.3' DEFAULT_BUILDDATE = '202110XX' # Python version sanity check -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#204622): https://lists.openembedded.org/g/openembedded-core/message/204622 Mute This Topic: https://lists.openembedded.org/mt/108499127/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 v3 1/2] classes: Print bitbake branch and revision
On Wed, 2024-09-11 at 07:35 -0700, Robert Yang via lists.openembedded.org wrote: > From: Robert Yang > > There is no bitbake revision when it is in a separate repo, then we have no > way > to know which version of bitbake is used from the log, this patch always > prints > it. > > * console-latest.log > bitbake = "master:165368bad152a14b32b5216b938aa4b915d72a70" > meta > meta-poky > meta-yocto-bsp = "master:165368bad152a14b32b5216b938aa4b915d72a70" I think this is confusing as it implies that revision is in the bitbake repository which it isn't, that is a poky revision. The current output tries to make that clear, this patch starts to confuse that. We're really close to release and I'm not going to rush into changing this so close to a release build. I don't mind printing a bitbake revision but it should probably only be when it is a separate repo. The change is too late for 5.1 IMO. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#204621): https://lists.openembedded.org/g/openembedded-core/message/204621 Mute This Topic: https://lists.openembedded.org/mt/108394689/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] libsdl2: Fix non-deterministic configure option for libsamplerate
The libsamplerate option was floating and being enabled on some systems and not others. Fix this to be deterministic. Signed-off-by: Richard Purdie --- meta/recipes-graphics/libsdl2/libsdl2_2.30.7.bb | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/recipes-graphics/libsdl2/libsdl2_2.30.7.bb b/meta/recipes-graphics/libsdl2/libsdl2_2.30.7.bb index f3c78a31e20..25bbe2067a3 100644 --- a/meta/recipes-graphics/libsdl2/libsdl2_2.30.7.bb +++ b/meta/recipes-graphics/libsdl2/libsdl2_2.30.7.bb @@ -67,6 +67,7 @@ PACKAGECONFIG[directfb] = "-DSDL_DIRECTFB=ON,-DSDL_DIRECTFB=OFF,directfb,direc PACKAGECONFIG[gles2] = "-DSDL_OPENGLES=ON,-DSDL_OPENGLES=OFF,virtual/libgles2" PACKAGECONFIG[jack] = "-DSDL_JACK=ON,-DSDL_JACK=OFF,jack" PACKAGECONFIG[kmsdrm] = "-DSDL_KMSDRM=ON,-DSDL_KMSDRM=OFF,libdrm virtual/libgbm" +PACKAGECONFIG[libsamplerate] = "-DSDL_LIBSAMPLERATE=ON,-DSDL_LIBSAMPLERATE=OFF,libsamplerate0" # The hidraw support doesn't catch Xbox, PS4 and Nintendo controllers, # so we'll just use libusb when it's available. PACKAGECONFIG[libusb] = ",,libusb1" -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#204620): https://lists.openembedded.org/g/openembedded-core/message/204620 Mute This Topic: https://lists.openembedded.org/mt/108498686/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][master][PATCH] tzdata : Upgrade to 2024b
On Tue, 2024-09-17 at 08:32 +0100, Richard Purdie via
lists.openembedded.org wrote:
> On Fri, 2024-09-13 at 15:47 +0530, Priyal Doshi via
> lists.openembedded.org wrote:
> > From: Priyal Doshi
> >
> > Signed-off-by: Priyal Doshi
> > ---
> > meta/recipes-extended/timezone/timezone.inc | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/meta/recipes-extended/timezone/timezone.inc
> > b/meta/recipes-extended/timezone/timezone.inc
> > index 4734adc..adf0952 100644
> > --- a/meta/recipes-extended/timezone/timezone.inc
> > +++ b/meta/recipes-extended/timezone/timezone.inc
> > @@ -6,7 +6,7 @@ SECTION = "base"
> > LICENSE = "PD & BSD-3-Clause"
> > LIC_FILES_CHKSUM =
> > "file://LICENSE;md5=c679c9d6b02bc2757b3eaf8f53c43fba"
> >
> > -PV = "2024a"
> > +PV = "2024b"
> >
> > SRC_URI ="
> > http://www.iana.org/time-zones/repository/releases/tzcode${PV}.tar.gz;name=tzcode;subdir=tz
> > \
> >
> > http://www.iana.org/time-zones/repository/releases/tzdata${PV}.tar.gz;name=tzdata;subdir=tz
> > \
> > @@ -16,5 +16,5 @@ S = "${WORKDIR}/tz"
> >
> > UPSTREAM_CHECK_URI = "http://www.iana.org/time-zones";
> >
> > -SRC_URI[tzcode.sha256sum] =
> > "80072894adff5a458f1d143e16e4ca1d8b2a122c9c5399da482cb68cba6a1ff8"
> > -SRC_URI[tzdata.sha256sum] =
> > "0d0434459acbd2059a7a8da1f3304a84a86591f6ed69c6248fffa502b6edffe3"
> > +SRC_URI[tzcode.sha256sum] =
> > "5e438fc449624906af16a18ff4573739f0cda9862e5ec28d3bcb19cbaed0f672"
> > +SRC_URI[tzdata.sha256sum] =
> > "70e754db126a8d0db3d16d6b4cb5f7ec1e04d5f261255e4558a67fe92d39e550"
>
> I think this breaks a test in the glib-2.0 test suite:
>
> https://valkyrie.yoctoproject.org/#/builders/73/builds/126/steps/12/logs/stdio
>
> WARNING: core-image-ptest-glib-2.0-1.0-r0 do_testimage: There were
> failing ptests.
> Failed ptests:
> {'glib-2.0': ['glib/gdatetime.test']}
>
I managed to find ptest logs for this:
ok 62 /GTimeZone/no-header-identifier
**
GLib:ERROR:/usr/src/debug/glib-2.0/2.80.4/glib/tests/gdatetime.c:2960:test_posix_parse:
assertion failed (g_time_zone_get_abbreviation (tz, 0) == "PST"): ("LMT" ==
"PST")
not ok /GTimeZone/posix-parse -
GLib:ERROR:/usr/src/debug/glib-2.0/2.80.4/glib/tests/gdatetime.c:2960:test_posix_parse:
assertion failed (g_time_zone_get_abbreviation (tz, 0) == "PST"): ("LMT" ==
"PST")
Bail out!
FAIL: glib/gdatetime.test (Child process killed by signal 6)
Running test: glib/bitlock.test
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#204618):
https://lists.openembedded.org/g/openembedded-core/message/204618
Mute This Topic: https://lists.openembedded.org/mt/108429297/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][master][PATCH] tzdata : Upgrade to 2024b
On Fri, 2024-09-13 at 15:47 +0530, Priyal Doshi via lists.openembedded.org
wrote:
> From: Priyal Doshi
>
> Signed-off-by: Priyal Doshi
> ---
> meta/recipes-extended/timezone/timezone.inc | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/meta/recipes-extended/timezone/timezone.inc
> b/meta/recipes-extended/timezone/timezone.inc
> index 4734adc..adf0952 100644
> --- a/meta/recipes-extended/timezone/timezone.inc
> +++ b/meta/recipes-extended/timezone/timezone.inc
> @@ -6,7 +6,7 @@ SECTION = "base"
> LICENSE = "PD & BSD-3-Clause"
> LIC_FILES_CHKSUM = "file://LICENSE;md5=c679c9d6b02bc2757b3eaf8f53c43fba"
>
> -PV = "2024a"
> +PV = "2024b"
>
> SRC_URI ="
> http://www.iana.org/time-zones/repository/releases/tzcode${PV}.tar.gz;name=tzcode;subdir=tz
> \
>
> http://www.iana.org/time-zones/repository/releases/tzdata${PV}.tar.gz;name=tzdata;subdir=tz
> \
> @@ -16,5 +16,5 @@ S = "${WORKDIR}/tz"
>
> UPSTREAM_CHECK_URI = "http://www.iana.org/time-zones";
>
> -SRC_URI[tzcode.sha256sum] =
> "80072894adff5a458f1d143e16e4ca1d8b2a122c9c5399da482cb68cba6a1ff8"
> -SRC_URI[tzdata.sha256sum] =
> "0d0434459acbd2059a7a8da1f3304a84a86591f6ed69c6248fffa502b6edffe3"
> +SRC_URI[tzcode.sha256sum] =
> "5e438fc449624906af16a18ff4573739f0cda9862e5ec28d3bcb19cbaed0f672"
> +SRC_URI[tzdata.sha256sum] =
> "70e754db126a8d0db3d16d6b4cb5f7ec1e04d5f261255e4558a67fe92d39e550"
I think this breaks a test in the glib-2.0 test suite:
https://valkyrie.yoctoproject.org/#/builders/73/builds/126/steps/12/logs/stdio
WARNING: core-image-ptest-glib-2.0-1.0-r0 do_testimage: There were failing
ptests.
Failed ptests:
{'glib-2.0': ['glib/gdatetime.test']}
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#204617):
https://lists.openembedded.org/g/openembedded-core/message/204617
Mute This Topic: https://lists.openembedded.org/mt/108429297/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] Backport fix for inter-recipe useradd dependencies bug #13419
On Mon, 2024-09-16 at 19:38 +, Jonas Mark (BT-FS/ENG1-Mue) wrote: > I am wondering whether it would be reasonable to ask for backporting > of the fix for inter-recipe useradd dependencies to Kirkstone? > > I am referring to the fix for bug #13419 which was fixed on > Scarthgap. > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=13419 > > I understand that the backporting would involve the addition of > USERADD_DEPENDS to useradd.bbclass as well a fix to bitbake. > > My colleague Ricardo and I are visiting the OSSEU this week in case > somebody would like to discuss this in person. The changes to bitbake were complex and relied on previous work. Whether that work was even present in the kirkstone version of bitbake, I'm not sure. I've be very nervous about trying to backport that kind of change to a release as far through the LTS cycle as kirkstone is, particularly as it changes behaviour. You didn't mention whether you had tested those fixes against kirkstone? Even if so, I'd still probably be nervous about making changes like this as people might be relying on the existing behaviour or have their own workarounds. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#204611): https://lists.openembedded.org/g/openembedded-core/message/204611 Mute This Topic: https://lists.openembedded.org/mt/108488497/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] host libs in the SDK link to the host libs
On Thu, 2024-09-12 at 11:05 -0700, Aleksandar Nikolic via lists.openembedded.org wrote: > Hi all, > > one thing regarding the libs in the SDK is bugging me and I would like to > understand it. In short, I cloned the poky repository, checked out the > scarthgap branch and built the SDK with "bitbake -c populate_sdk > core-image-weston-sdk". After installing the SDK, I checked what the ldd > command is returning: > > ```bash > # executed from the installed SDK > ldd sysroots/x86_64-pokysdk-linux/lib/libanl.so.1 > sysroots/x86_64-pokysdk-linux/lib/libanl.so.1: > /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.36' not found (required by > sysroots/x86_64-pokysdk-linux/lib/libanl.so.1) > sysroots/x86_64-pokysdk-linux/lib/libanl.so.1: > /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_ABI_DT_RELR' not found > (required by sysroots/x86_64-pokysdk-linux/lib/libanl.so.1) > linux-vdso.so.1 (0x7ffdc31a2000) > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fade7545000) > /lib64/ld-linux-x86-64.so.2 (0x7fade7753000) > ``` > > Could someone tell me why is libanl.so.1 linking against the libc.so.6 host > library and not the one from the SDK - > sysroots/x86_64-pokysdk-linux/lib/libc.so.6? Is it because I used the host > ldd? > > I am also getting the same error (that the versions do not match), when > trying to execute binaries built with the above SDK by using qemu-x86_64. The binaries in the SDK are executed using its own dynamic loader which tweaks the search paths. The output from the host's ldd won't be correct. qemu probably isn't aware of or accounting for the change to the loader. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#204465): https://lists.openembedded.org/g/openembedded-core/message/204465 Mute This Topic: https://lists.openembedded.org/mt/108418277/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] python3: Upgrade 3.12.5 -> 3.12.6
On Thu, 2024-09-12 at 17:43 +, Ross Burton via lists.openembedded.org wrote: > Hi Divya, > > > On 12 Sep 2024, at 16:22, Richard Purdie via lists.openembedded.org > > wrote: > > Unfortunately "0001-test_readline-skip-limited-history-test.patch" > > is still needed as it failed in testing: > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/6985/steps/12/logs/stdio > > > > Could you rebase that patch and resend with it included please? > > We’d really like this to be part of the next release which is > scheduled to be built asap (like, Monday), so sending this revised > patch promptly would be _much_ appreciated. As I'm worried about time pressures, I've tried refreshing that patch in master-next and am retesting... Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#204464): https://lists.openembedded.org/g/openembedded-core/message/204464 Mute This Topic: https://lists.openembedded.org/mt/108408677/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] sanity: check for working user namespaces
On Thu, 2024-09-12 at 18:29 +0100, Jose Quaresma via
lists.openembedded.org wrote:
>
>
> Ross Burton via lists.openembedded.org
> escreveu (quinta,
> 12/09/2024 à(s) 17:57):
> > If user namespaces are not available (typically because AppArmor is
> > blocking them), alert the user.
> >
> > We consider network isolation sufficiently important that this is a
> > fatal
> > error, and the user will need to configure AppArmor to allow
> > bitbake to
> > create a user namespace.
> >
> > [ YOCTO #15592 ]
> >
> > Signed-off-by: Ross Burton
> > ---
> > meta/classes-global/sanity.bbclass | 24
> > 1 file changed, 24 insertions(+)
> >
> > diff --git a/meta/classes-global/sanity.bbclass b/meta/classes-
> > global/sanity.bbclass
> > index 1d242f0f0a0..72dab0fea2b 100644
> > --- a/meta/classes-global/sanity.bbclass
> > +++ b/meta/classes-global/sanity.bbclass
> > @@ -475,6 +475,29 @@ def check_wsl(d):
> > bb.warn("You are running bitbake under WSLv2, this
> > works properly but you should optimize your VHDX file eventually to
> > avoid running out of storage space")
> > return None
> >
> > +def check_userns():
> > + """
> > + Check that user namespaces are functional, as they're used for
> > network isolation.
> > + """
> > +
> > + # There is a known failure case with AppAmrmor where the
> > unshare() call
> > + # succeeds (at which point the uid is nobody) but writing to
> > the uid_map
> > + # fails (so the uid isn't reset back to the user's uid). We
> > can detect this.
> > + parentuid = os.getuid()
> > + pid = os.fork()
> > + if not pid:
> > + try:
> > + bb.utils.disable_network()
> > + except:
> > + pass
> > + os._exit(parentuid != os.getuid())
> > +
> > + ret = os.waitpid(pid, 0)[1]
> > + if ret:
> > + bb.fatal("User namespaces are not usable by BitBake,
> > possibly due to AppArmor.\n"
> > + "See
> > https://discourse.ubuntu.com/t/ubuntu-24-04-lts-noble-numbat-release-notes/39890#unprivileged-user-namespace-restrictions
> > for more information.")
> >
>
>
> The error message could be better imo.
> It will also happen inside a docker container that runs without the
> NET_ADMIN capability, which is the default.
> https://docs.docker.com/engine/containers/run/#runtime-privilege-and-linux-capabilities
Did you actually observe that?
If the unshare() fails, the uids will still match and I don't think the
error message will trigger but I could be wrong.
What we want to detect is where the unshare() works but the uid mapping
then fails which is the annoying apparmor corner case.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#204463):
https://lists.openembedded.org/g/openembedded-core/message/204463
Mute This Topic: https://lists.openembedded.org/mt/108416977/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] python3: Upgrade 3.12.5 -> 3.12.6
On Thu, 2024-09-12 at 06:44 +, dchellam via lists.openembedded.org wrote: > From: Divya Chellam > > Includes security fixes for CVE-2024-7592, CVE-2024-8088, CVE-2024-6232 > and other bug fixes. > > Removed below patches, as the fix is included in 3.12.6 upgrade: > 1. CVE-2024-7592.patch > 2. 0001-test_readline-skip-limited-history-test.patch > > Release Notes: > https://www.python.org/downloads/release/python-3126/ > > Signed-off-by: Divya Chellam > --- Unfortunately "0001-test_readline-skip-limited-history-test.patch" is still needed as it failed in testing: https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/6985/steps/12/logs/stdio Could you rebase that patch and resend with it included please? Thanks, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#204446): https://lists.openembedded.org/g/openembedded-core/message/204446 Mute This Topic: https://lists.openembedded.org/mt/108408677/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 v3 3/3] nativesdk-packagegroup-sdk-host: Add missing perl modules to RDEPENDS
On Wed, 2024-09-11 at 22:46 -0700, Sadineni, Harish via lists.openembedded.org
wrote:
> From: Harish Sadineni
>
> In SDK, missing perl modules causes 'x86_64-wrlinuxsdk-linux-gp-display-html
> --help' to abort with below errors..
> - Can't locate bignum.pm in @INC (you may need to install the feature
> module).
> - Can't locate Math/BigInt.pm in @INC (you may need to install the
> Math::BigInt module)
>
> Signed-off-by: Harish Sadineni
> ---
> .../packagegroups/nativesdk-packagegroup-sdk-host.bb | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git
> a/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
> b/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
> index c1d3c25060..70a7d3e494 100644
> --- a/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
> +++ b/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
> @@ -30,6 +30,9 @@ RDEPENDS:${PN} = "\
> nativesdk-bison \
> nativesdk-flex \
> nativesdk-perl-module-integer \
> + nativesdk-perl-module-bignum \
> + nativesdk-perl-module-bigint \
> + nativesdk-perl-module-math-bigint \
> "
>
> RDEPENDS:${PN}:darwin = "\
>
Those dependencies should really be added to binutils-gprofng?
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#204426):
https://lists.openembedded.org/g/openembedded-core/message/204426
Mute This Topic: https://lists.openembedded.org/mt/108408163/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 v3 2/3] binutils-cross-canadian: add gprofng package as runtime dependency
On Wed, 2024-09-11 at 22:46 -0700, Sadineni, Harish via lists.openembedded.org
wrote:
> From: Harish Sadineni
>
> In SDK, while running "x86_64-poky-linux-gp-collect-app ./exe" fails
> to create 'test.1.er' due to missing gprofng configure file in sysconfdir
> and aborting with below error while generating the profiling data.
> - configuration error: can not find libgp-collector.so. run aborted
>
> Signed-off-by: Harish Sadineni
> ---
> meta/recipes-devtools/binutils/binutils-cross-canadian.inc | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/meta/recipes-devtools/binutils/binutils-cross-canadian.inc
> b/meta/recipes-devtools/binutils/binutils-cross-canadian.inc
> index 62ebb3f5bc..7f2699089e 100644
> --- a/meta/recipes-devtools/binutils/binutils-cross-canadian.inc
> +++ b/meta/recipes-devtools/binutils/binutils-cross-canadian.inc
> @@ -30,3 +30,4 @@ do_install () {
> }
>
> BBCLASSEXTEND = ""
> +RDEPENDS:${PN} = "nativesdk-gprofng"
Shouldn't gp-collect-app be put into the gprofng package instead?
Adding that dependency effectively join the gprof package into the main
PN and makes the separation pointless.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#204424):
https://lists.openembedded.org/g/openembedded-core/message/204424
Mute This Topic: https://lists.openembedded.org/mt/108408162/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 2/2] libedit: Make docs generation deterministic
The presence or lack of nroff on the host was changing the doc type. Stop
the code from looking at host paths outside HOSTTOOLS and hence cause the
doc type to be deterministic and reproducible.
Signed-off-by: Richard Purdie
---
meta/recipes-devtools/libedit/libedit_20240808-3.1.bb | 7 +++
1 file changed, 7 insertions(+)
diff --git a/meta/recipes-devtools/libedit/libedit_20240808-3.1.bb
b/meta/recipes-devtools/libedit/libedit_20240808-3.1.bb
index 932e5a1485a..bf6ec8ebd3c 100644
--- a/meta/recipes-devtools/libedit/libedit_20240808-3.1.bb
+++ b/meta/recipes-devtools/libedit/libedit_20240808-3.1.bb
@@ -15,4 +15,11 @@ SRC_URI = "http://www.thrysoee.dk/editline/${BP}.tar.gz \
"
SRC_URI[sha256sum] =
"5f0573349d77c4a48967191cdd6634dd7aa5f6398c6a57fe037cc02696d6099f"
+# configure hardcodes /usr/bin search path bypassing HOSTTOOLS
+CACHED_CONFIGUREVARS += "ac_cv_path_NROFF=/bin/false"
+
+# remove at next version upgrade or when output changes
+PR = "r1"
+HASHEQUIV_HASH_VERSION .= ".1"
+
BBCLASSEXTEND = "native nativesdk"
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#204355):
https://lists.openembedded.org/g/openembedded-core/message/204355
Mute This Topic: https://lists.openembedded.org/mt/108376414/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 1/2] ruby: Make docs generation deterministic
The presence or lack of nroff on the host was changing the doc type. Set it explicitly to be deterministic and reproducible. Signed-off-by: Richard Purdie --- meta/recipes-devtools/ruby/ruby_3.3.4.bb | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/recipes-devtools/ruby/ruby_3.3.4.bb b/meta/recipes-devtools/ruby/ruby_3.3.4.bb index ebff4136c9c..d39b7ae5206 100644 --- a/meta/recipes-devtools/ruby/ruby_3.3.4.bb +++ b/meta/recipes-devtools/ruby/ruby_3.3.4.bb @@ -67,6 +67,7 @@ EXTRA_OECONF = "\ --enable-load-relative \ --with-pkg-config=pkg-config \ --with-static-linked-ext \ +--with-mantype=man \ " EXTRA_OECONF:append:libc-musl = "\ -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#204356): https://lists.openembedded.org/g/openembedded-core/message/204356 Mute This Topic: https://lists.openembedded.org/mt/108376416/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] Revert "python3-setuptools: upgrade 72.1.0 -> 72.2.0"
This reverts commit 8fccef7a731f44e5d27653e06becb54cf770e5e5.
The patch causes problems for systems using ccache. Revert until this is fixed.
Signed-off-by: Richard Purdie
---
...ython3-setuptools_72.2.0.bb => python3-setuptools_72.1.0.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-devtools/python/{python3-setuptools_72.2.0.bb =>
python3-setuptools_72.1.0.bb} (94%)
diff --git a/meta/recipes-devtools/python/python3-setuptools_72.2.0.bb
b/meta/recipes-devtools/python/python3-setuptools_72.1.0.bb
similarity index 94%
rename from meta/recipes-devtools/python/python3-setuptools_72.2.0.bb
rename to meta/recipes-devtools/python/python3-setuptools_72.1.0.bb
index 63ea60b..945d443affc 100644
--- a/meta/recipes-devtools/python/python3-setuptools_72.2.0.bb
+++ b/meta/recipes-devtools/python/python3-setuptools_72.1.0.bb
@@ -11,7 +11,7 @@ SRC_URI:append:class-native = "
file://0001-conditionally-do-not-fetch-code-by-e
SRC_URI += " \
file://0001-_distutils-sysconfig.py-make-it-possible-to-substite.patch"
-SRC_URI[sha256sum] =
"80aacbf633704e9c8bfa1d99fa5dd4dc59573efcf9e4042c13d3bcef91ac2ef9"
+SRC_URI[sha256sum] =
"8d243eff56d095e5817f796ede6ae32941278f542e0f941867cc05ae52b162ec"
DEPENDS += "python3"
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#204279):
https://lists.openembedded.org/g/openembedded-core/message/204279
Mute This Topic: https://lists.openembedded.org/mt/108308394/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] layer.conf: Drop scarthgap namespace from LAYERSERIES
As we move to release, drop the scarthgap namespace and prepare for
styhead.
Signed-off-by: Richard Purdie
---
meta/conf/layer.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/conf/layer.conf b/meta/conf/layer.conf
index 65eb657fd93..0e54ad7eccd 100644
--- a/meta/conf/layer.conf
+++ b/meta/conf/layer.conf
@@ -7,7 +7,7 @@ BBFILE_COLLECTIONS += "core"
BBFILE_PATTERN_core = "^${LAYERDIR}/"
BBFILE_PRIORITY_core = "5"
-LAYERSERIES_CORENAMES = "scarthgap styhead"
+LAYERSERIES_CORENAMES = "styhead"
# This should only be incremented on significant changes that will
# cause compatibility issues with other layers
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#204275):
https://lists.openembedded.org/g/openembedded-core/message/204275
Mute This Topic: https://lists.openembedded.org/mt/108306337/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] [master/scarthgap PATCH] meta-ide-support: Mark recipe as MACHINE-specific
On Thu, 2024-09-05 at 23:40 +0100, Richard Purdie via lists.openembedded.org
wrote:
> On Thu, 2024-09-05 at 21:21 +0100, Paul Barker via lists.openembedded.org
> wrote:
> > meta-ide-support:do_write_test_data dumps the bitbake data dictionary to
> > a file using export2json(). As this obviously includes the value of
> > MACHINE, and other MACHINE-specific variables, the recipe needs to be
> > marked as MACHINE-specific.
> >
> > Signed-off-by: Paul Barker
> > ---
> > meta/recipes-core/meta/meta-ide-support.bb | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/meta/recipes-core/meta/meta-ide-support.bb
> > b/meta/recipes-core/meta/meta-ide-support.bb
> > index d85aa120c08b..7ed422ce4ddb 100644
> > --- a/meta/recipes-core/meta/meta-ide-support.bb
> > +++ b/meta/recipes-core/meta/meta-ide-support.bb
> > @@ -1,6 +1,7 @@
> > SUMMARY = "Integrated Development Environment support"
> > DESCRIPTION = "Meta package for ensuring the build directory contains all
> > appropriate toolchain packages for using an IDE"
> > LICENSE = "MIT"
> > +PACKAGE_ARCH = "${MACHINE_ARCH}"
> >
> > DEPENDS = "virtual/libc gdb-cross-${TARGET_ARCH} qemu-native
> > qemu-helper-native unfs3-native cmake-native autoconf-native
> > automake-native meson-native intltool-native pkgconfig-native"
> > RM_WORK_EXCLUDE += "${PN}"
>
> Something about this is making our toolchain tests unhappy, e.g.:
>
> https://valkyrie.yoctoproject.org/#/builders/42/builds/86/steps/12/logs/stdio
>
> I've not looked into it at all, just reporting what we've need to fix
> in order to be able to consider merging this.
It can be fixed with:
diff --git a/meta/lib/oeqa/selftest/cases/meta_ide.py
b/meta/lib/oeqa/selftest/cases/meta_ide.py
index ffe0d2604d1..5a17ca52ea1 100644
--- a/meta/lib/oeqa/selftest/cases/meta_ide.py
+++ b/meta/lib/oeqa/selftest/cases/meta_ide.py
@@ -20,8 +20,8 @@ class MetaIDE(OESelftestTestCase):
bitbake('meta-ide-support')
bitbake('build-sysroots -c build_native_sysroot')
bitbake('build-sysroots -c build_target_sysroot')
-bb_vars = get_bb_vars(['MULTIMACH_TARGET_SYS', 'DEPLOY_DIR_IMAGE',
'COREBASE'])
-cls.environment_script = 'environment-setup-%s' %
bb_vars['MULTIMACH_TARGET_SYS']
+bb_vars = get_bb_vars(['MACHINE_ARCH', 'TARGET_VENDOR', 'TARGET_OS',
'DEPLOY_DIR_IMAGE', 'COREBASE'])
+cls.environment_script = 'environment-setup-%s%s-%s' %
(bb_vars['MACHINE_ARCH'], bb_vars['TARGET_VENDOR'], bb_vars['TARGET_OS'])
cls.deploydir = bb_vars['DEPLOY_DIR_IMAGE']
cls.environment_script_path = '%s/%s' % (cls.deploydir,
cls.environment_script)
cls.corebasedir = bb_vars['COREBASE']
Whether that is a good/right fix, I'm not sure...
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#204268):
https://lists.openembedded.org/g/openembedded-core/message/204268
Mute This Topic: https://lists.openembedded.org/mt/108292901/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] runqemu: lock tap creation process
On Fri, 2024-09-06 at 10:18 +0200, Konrad Weihmann wrote:
> On 05.09.24 11:56, Richard Purdie wrote:
> > On Wed, 2024-09-04 at 12:21 +, Konrad Weihmann via
> > lists.openembedded.org wrote:
> > > in case of running two or more runqemu instances in parallel
> > > with no previously setup tap devices, the following happens:
> > >
> > > instance A probes for tap devices, but doesn't find
> > > any, proceeds to generating tap devices with the sudo call,
> > > resulting in tap0.
> > > instance B starts to probes, finds tap0.
> > > Both will lock tap0.
> > >
> > > tap0 will be then forwarded to qemu.
> > > Instance A reporting
> > >
> > > "Using preconfigured tap device tap0"
> > >
> > > but then failing with
> > >
> > > qemu-system... could not configure /dev/net/tun (tap0): Device or
> > > resource busy
> > >
> > > To fix that, lock the entire tap creation process with
> > > an exclusive file (blocking) lock, so only a single instance can
> > > perform the non-atomic changes.
> > >
> > > Signed-off-by: Konrad Weihmann
> > > ---
> > > scripts/runqemu | 10 ++
> > > 1 file changed, 10 insertions(+)
> > >
> > > diff --git a/scripts/runqemu b/scripts/runqemu
> > > index 2817acb19f..e5db06be37 100755
> > > --- a/scripts/runqemu
> > > +++ b/scripts/runqemu
> > > @@ -1163,6 +1163,9 @@ to your build configuration.
> > >
> > > self.make_lock_dir(lockdir)
> > >
> > > + tap_setup_lock = open(os.path.join(lockdir,
> > > '_tap_creation_lock'), 'w')
> > > + fcntl.flock(tap_setup_lock, fcntl.LOCK_EX)
> > > +
> > > cmd = (ip, 'link')
> > > logger.debug('Running %s...' % str(cmd))
> > > ip_link = subprocess.check_output(cmd).decode('utf-8')
> > > @@ -1187,6 +1190,8 @@ to your build configuration.
> > >
> > > if not tap:
> > > if os.path.exists(nosudo_flag):
> > > + fcntl.flock(tap_setup_lock, fcntl.LOCK_UN)
> > > + tap_setup_lock.close()
> > > logger.error("Error: There are no available tap devices
> > > to use for networking,")
> > > logger.error("and I see %s exists, so I am not going to
> > > try creating" % nosudo_flag)
> > > raise RunQemuError("a new one with sudo.")
> >
> > This doesn't make sense to me. Surely you should be taking this lock
> > *within* the "if not tap" code block since that is where the ifup is
> > called out to with sudo? You appear to be dropping the lock there
> > instead?
>
> Right before the raise of an exception the lock should be released,
> shouldn't it?
Ok, I see why you've done it this way. I'd much prefer to move the lock
to just be in that conditional though. I don't believe it is needed in
the earlier search code - that code works fine today and is only used
if the devices are pre-setup.
> Otherwise we would rely on the fact that none of the calling functions
> does any exception handling and
> the entire process fails to release the lock.
>
> >
> > It appears you're putting the locking around the search for pre-
> > configured tap devices which is already atomic and working well from a
> > race perspective?
>
> That is the actual race condition here.
> On the on hand you have the search function, which in itself is atomic
> and save yes but then you have the setup function below
>
> 1198 try:
> 1199 tap =
> subprocess.check_output(cmd).decode('utf-8').strip()
> 1200 except subprocess.CalledProcessError as e:
> 1201 logger.error('Setting up tap device failed:\n%s\nRun
> runqemu-gen-tapdevs to manually create one.' % str(e))
> 1202 sys.exit(1)
> 1203 lockfile = os.path.join(lockdir, tap)
> 1204 self.taplock = lockfile + '.lock'
> 1205 self.acquire_taplock()
>
> the section from line 1199 till 1205 is completely unguarded from a lock
> perspective.
> Meaning (and I think that is what is actually happening) that the new
> tap device is created as the result of line 1199 by process A but locked
> by process B, as the search function finds it and acquires the lock.
> So in my opinion the en
Re: [OE-core] [master/scarthgap PATCH] meta-ide-support: Mark recipe as MACHINE-specific
On Thu, 2024-09-05 at 21:21 +0100, Paul Barker via lists.openembedded.org wrote:
> meta-ide-support:do_write_test_data dumps the bitbake data dictionary to
> a file using export2json(). As this obviously includes the value of
> MACHINE, and other MACHINE-specific variables, the recipe needs to be
> marked as MACHINE-specific.
>
> Signed-off-by: Paul Barker
> ---
> meta/recipes-core/meta/meta-ide-support.bb | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/meta/recipes-core/meta/meta-ide-support.bb
> b/meta/recipes-core/meta/meta-ide-support.bb
> index d85aa120c08b..7ed422ce4ddb 100644
> --- a/meta/recipes-core/meta/meta-ide-support.bb
> +++ b/meta/recipes-core/meta/meta-ide-support.bb
> @@ -1,6 +1,7 @@
> SUMMARY = "Integrated Development Environment support"
> DESCRIPTION = "Meta package for ensuring the build directory contains all
> appropriate toolchain packages for using an IDE"
> LICENSE = "MIT"
> +PACKAGE_ARCH = "${MACHINE_ARCH}"
>
> DEPENDS = "virtual/libc gdb-cross-${TARGET_ARCH} qemu-native
> qemu-helper-native unfs3-native cmake-native autoconf-native automake-native
> meson-native intltool-native pkgconfig-native"
> RM_WORK_EXCLUDE += "${PN}"
Something about this is making our toolchain tests unhappy, e.g.:
https://valkyrie.yoctoproject.org/#/builders/42/builds/86/steps/12/logs/stdio
I've not looked into it at all, just reporting what we've need to fix
in order to be able to consider merging this.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#204245):
https://lists.openembedded.org/g/openembedded-core/message/204245
Mute This Topic: https://lists.openembedded.org/mt/108292901/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 1/2] license: Fix directory layout issues
There are several issues:
a) pointless empty directories were being created as a path wasn't
fixed in a previous commit
b) SSTATE_PKGARCH wasn't being captured into the task signature
since it is in the ignore list by default. We want to capture
the absolute value, not the dependencies
c) with those issues fixed, cross/native issues became apparent so
those need to be fixed too.
Signed-off-by: Richard Purdie
---
meta/classes-global/license.bbclass | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/meta/classes-global/license.bbclass
b/meta/classes-global/license.bbclass
index 4e39ec1d44e..043715fcc36 100644
--- a/meta/classes-global/license.bbclass
+++ b/meta/classes-global/license.bbclass
@@ -18,8 +18,14 @@ LICENSE_CREATE_PACKAGE ??= "0"
LICENSE_PACKAGE_SUFFIX ??= "-lic"
LICENSE_FILES_DIRECTORY ??= "${datadir}/licenses/"
+LICENSE_DEPLOY_PATHCOMPONENT = "${SSTATE_PKGARCH}"
+LICENSE_DEPLOY_PATHCOMPONENT:class-cross = "native"
+LICENSE_DEPLOY_PATHCOMPONENT:class-native = "native"
+# Ensure the *value* of SSTATE_PKGARCH is captured as it is used in the output
paths
+LICENSE_DEPLOY_PATHCOMPONENT[vardepvalue] += "${LICENSE_DEPLOY_PATHCOMPONENT}"
+
addtask populate_lic after do_patch before do_build
-do_populate_lic[dirs] = "${LICSSTATEDIR}/${PN}"
+do_populate_lic[dirs] = "${LICSSTATEDIR}/${LICENSE_DEPLOY_PATHCOMPONENT}/${PN}"
do_populate_lic[cleandirs] = "${LICSSTATEDIR}"
python do_populate_lic() {
@@ -29,7 +35,7 @@ python do_populate_lic() {
lic_files_paths = find_license_files(d)
# The base directory we wrangle licenses to
-destdir = os.path.join(d.getVar('LICSSTATEDIR'),
d.getVar('SSTATE_PKGARCH'), d.getVar('PN'))
+destdir = os.path.join(d.getVar('LICSSTATEDIR'),
d.getVar('LICENSE_DEPLOY_PATHCOMPONENT'), d.getVar('PN'))
copy_license_files(lic_files_paths, destdir)
info = get_recipe_info(d)
with open(os.path.join(destdir, "recipeinfo"), "w") as f:
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#204240):
https://lists.openembedded.org/g/openembedded-core/message/204240
Mute This Topic: https://lists.openembedded.org/mt/108288015/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 2/2] sstate: Make do_recipe_qa and do_populate_lic non-arch specific
The sstate functions currently pull in STAMP and SSTATE_PKG which end up pulling in DEFAULTTUNE and other variables. The location on disk encodes all the "architecture" information we need so clean up the dependencies of these tasks and make them non-architecture specific. Signed-off-by: Richard Purdie --- meta/classes-global/sstate.bbclass | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/classes-global/sstate.bbclass b/meta/classes-global/sstate.bbclass index f38041b735a..11bb892a42a 100644 --- a/meta/classes-global/sstate.bbclass +++ b/meta/classes-global/sstate.bbclass @@ -354,7 +354,7 @@ def sstate_install(ss, d): for lock in locks: bb.utils.unlockfile(lock) -sstate_install[vardepsexclude] += "SSTATE_ALLOW_OVERLAP_FILES SSTATE_MANMACH SSTATE_MANFILEPREFIX" +sstate_install[vardepsexclude] += "SSTATE_ALLOW_OVERLAP_FILES SSTATE_MANMACH SSTATE_MANFILEPREFIX STAMP" def sstate_installpkg(ss, d): from oe.gpg_sign import get_signer @@ -724,7 +724,7 @@ def sstate_package(ss, d): return -sstate_package[vardepsexclude] += "SSTATE_SIG_KEY" +sstate_package[vardepsexclude] += "SSTATE_SIG_KEY SSTATE_PKG" def pstaging_fetch(sstatefetch, d): import bb.fetch2 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#204239): https://lists.openembedded.org/g/openembedded-core/message/204239 Mute This Topic: https://lists.openembedded.org/mt/108288014/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] runqemu: lock tap creation process
On Wed, 2024-09-04 at 12:21 +, Konrad Weihmann via lists.openembedded.org
wrote:
> in case of running two or more runqemu instances in parallel
> with no previously setup tap devices, the following happens:
>
> instance A probes for tap devices, but doesn't find
> any, proceeds to generating tap devices with the sudo call,
> resulting in tap0.
> instance B starts to probes, finds tap0.
> Both will lock tap0.
>
> tap0 will be then forwarded to qemu.
> Instance A reporting
>
> "Using preconfigured tap device tap0"
>
> but then failing with
>
> qemu-system... could not configure /dev/net/tun (tap0): Device or resource
> busy
>
> To fix that, lock the entire tap creation process with
> an exclusive file (blocking) lock, so only a single instance can
> perform the non-atomic changes.
>
> Signed-off-by: Konrad Weihmann
> ---
> scripts/runqemu | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/scripts/runqemu b/scripts/runqemu
> index 2817acb19f..e5db06be37 100755
> --- a/scripts/runqemu
> +++ b/scripts/runqemu
> @@ -1163,6 +1163,9 @@ to your build configuration.
>
> self.make_lock_dir(lockdir)
>
> + tap_setup_lock = open(os.path.join(lockdir, '_tap_creation_lock'),
> 'w')
> + fcntl.flock(tap_setup_lock, fcntl.LOCK_EX)
> +
> cmd = (ip, 'link')
> logger.debug('Running %s...' % str(cmd))
> ip_link = subprocess.check_output(cmd).decode('utf-8')
> @@ -1187,6 +1190,8 @@ to your build configuration.
>
> if not tap:
> if os.path.exists(nosudo_flag):
> + fcntl.flock(tap_setup_lock, fcntl.LOCK_UN)
> + tap_setup_lock.close()
> logger.error("Error: There are no available tap devices to
> use for networking,")
> logger.error("and I see %s exists, so I am not going to try
> creating" % nosudo_flag)
> raise RunQemuError("a new one with sudo.")
This doesn't make sense to me. Surely you should be taking this lock
*within* the "if not tap" code block since that is where the ifup is
called out to with sudo? You appear to be dropping the lock there
instead?
It appears you're putting the locking around the search for pre-
configured tap devices which is already atomic and working well from a
race perspective?
> @@ -1198,6 +1203,8 @@ to your build configuration.
> try:
> tap = subprocess.check_output(cmd).decode('utf-8').strip()
> except subprocess.CalledProcessError as e:
> + fcntl.flock(tap_setup_lock, fcntl.LOCK_UN)
> + tap_setup_lock.close()
> logger.error('Setting up tap device failed:\n%s\nRun
> runqemu-gen-tapdevs to manually create one.' % str(e))
> sys.exit(1)
> lockfile = os.path.join(lockdir, tap)
> @@ -1206,6 +1213,9 @@ to your build configuration.
> self.cleantap = True
> logger.debug('Created tap: %s' % tap)
>
> + fcntl.flock(tap_setup_lock, fcntl.LOCK_UN)
> + tap_setup_lock.close()
For locks like this, they should really be in a try/finally or with clause...
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#204229):
https://lists.openembedded.org/g/openembedded-core/message/204229
Mute This Topic: https://lists.openembedded.org/mt/108263503/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] expat: 2.6.2 -> 2.6.3
Includes fixes for CVE-2024-45490, CVE-2024-45491 and CVE-2024-45492.
https://blog.hartwork.org/posts/expat-2-6-3-released/
Signed-off-by: Richard Purdie
---
meta/recipes-core/expat/{expat_2.6.2.bb => expat_2.6.3.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-core/expat/{expat_2.6.2.bb => expat_2.6.3.bb} (92%)
diff --git a/meta/recipes-core/expat/expat_2.6.2.bb
b/meta/recipes-core/expat/expat_2.6.3.bb
similarity index 92%
rename from meta/recipes-core/expat/expat_2.6.2.bb
rename to meta/recipes-core/expat/expat_2.6.3.bb
index 6c9db91bef5..5ae694a0041 100644
--- a/meta/recipes-core/expat/expat_2.6.2.bb
+++ b/meta/recipes-core/expat/expat_2.6.3.bb
@@ -15,7 +15,7 @@ SRC_URI =
"${GITHUB_BASE_URI}/download/R_${VERSION_TAG}/expat-${PV}.tar.bz2 \
GITHUB_BASE_URI = "https://github.com/libexpat/libexpat/releases/";
UPSTREAM_CHECK_REGEX = "releases/tag/R_(?P.+)"
-SRC_URI[sha256sum] =
"9c7c1b5dcbc3c237c500a8fb1493e14d9582146dd9b42aa8d3ffb856a3b927e0"
+SRC_URI[sha256sum] =
"b8baef92f328eebcf731f4d18103951c61fa8c8ec21d5ff4202fb6f2198aeb2d"
EXTRA_OECMAKE:class-native += "-DEXPAT_BUILD_DOCS=OFF"
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#204211):
https://lists.openembedded.org/g/openembedded-core/message/204211
Mute This Topic: https://lists.openembedded.org/mt/108272788/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] [RFC PATCH] bitbake.conf: DEBUG_PREFIX_MAP: move STAGING_DIR_NATIVE before STAGING_DIR_HOST
On Wed, 2024-09-04 at 08:53 +0200, Martin Jansa via lists.openembedded.org wrote: > Some related info I've found now: > https://reviews.llvm.org/D148975?id=516863 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109591 > > maybe affected by -fcanon-prefix-map used since gcc-13: > https://git.openembedded.org/openembedded-core/commit/?id=abe97fa74b10c2c71d79bc3573d4edb509b111f5 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108464#c8 > > and I was also using ccache which used to have some issues in this > area (but the python3-matplotlib issue is IIRC reproducible without > ccache as well): > https://github.com/ccache/ccache/issues/163 > > We might need more experiments before this is applied (I'm glad I've > sent it only as RFC). I'll try to find some time next week. I'm a bit worried that gcc might apply the ordering one way in some locations and the other way around in others so there may be a bug lurking somewhere. I agree we should look further into this. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#204201): https://lists.openembedded.org/g/openembedded-core/message/204201 Mute This Topic: https://lists.openembedded.org/mt/108229773/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] conf/defaultsetup.conf: Drop TCLIBCAPPEND
We've been able to run musl and glibc builds in the same TMPDIR for
many years and a separate directory is not required. Most distros disable
this value for that reason.
Drop support for the variable to make it clear and easy for distros
to be able to set multiconfigs which behave consistently for distros
which do and don't clear it by dropping it entirely.
Signed-off-by: Richard Purdie
---
meta/classes-recipe/populate_sdk_ext.bbclass | 2 --
meta/conf/distro/defaultsetup.conf | 4
meta/lib/oeqa/selftest/cases/sstatetests.py | 15 ---
3 files changed, 21 deletions(-)
diff --git a/meta/classes-recipe/populate_sdk_ext.bbclass
b/meta/classes-recipe/populate_sdk_ext.bbclass
index b02295384bb..8cb27ad9958 100644
--- a/meta/classes-recipe/populate_sdk_ext.bbclass
+++ b/meta/classes-recipe/populate_sdk_ext.bbclass
@@ -153,7 +153,6 @@ def create_filtered_tasklist(d, sdkbasepath, tasklistfile,
conf_initpath):
f.write('SSTATE_MIRRORS:forcevariable = "file://universal/(.*)
file://universal-4.9/\\1 file://universal-4.9/(.*) file://universal-4.8/\\1"\n')
# Ensure TMPDIR is the default so that clean_esdk_builddir() can
delete it
f.write('TMPDIR:forcevariable = "${TOPDIR}/tmp"\n')
-f.write('TCLIBCAPPEND:forcevariable = ""\n')
# Drop uninative if the build isn't using it (or else
NATIVELSBSTRING will
# be different and we won't be able to find our native sstate)
if not bb.data.inherits_class('uninative', d):
@@ -340,7 +339,6 @@ def write_local_conf(d, baseoutpath, derivative,
core_meta_subdir, uninative_che
f.write('\n')
f.write('TMPDIR = "${TOPDIR}/tmp"\n')
-f.write('TCLIBCAPPEND = ""\n')
f.write('DL_DIR = "${TOPDIR}/downloads"\n')
if bb.data.inherits_class('uninative', d):
diff --git a/meta/conf/distro/defaultsetup.conf
b/meta/conf/distro/defaultsetup.conf
index 90b68057ad4..e6369dcec4b 100644
--- a/meta/conf/distro/defaultsetup.conf
+++ b/meta/conf/distro/defaultsetup.conf
@@ -8,10 +8,6 @@ require conf/distro/include/tclibc-${TCLIBC}.inc
require conf/distro/include/uninative-flags.inc
-# Allow single libc distros to disable this code
-TCLIBCAPPEND ?= "-${TCLIBC}"
-TMPDIR .= "${TCLIBCAPPEND}"
-
USER_CLASSES ?= ""
PACKAGE_CLASSES ?= "package_ipk"
INHERIT_DISTRO ?= "debian devshell sstate license remove-libtool create-spdx"
diff --git a/meta/lib/oeqa/selftest/cases/sstatetests.py
b/meta/lib/oeqa/selftest/cases/sstatetests.py
index 49d650bac7a..ae295bef5f7 100644
--- a/meta/lib/oeqa/selftest/cases/sstatetests.py
+++ b/meta/lib/oeqa/selftest/cases/sstatetests.py
@@ -378,7 +378,6 @@ class SStateHashSameSigs(SStateBase):
self.write_config("""
MACHINE = "qemux86"
TMPDIR = "${TOPDIR}/tmp-sstatesamehash"
-TCLIBCAPPEND = ""
BUILD_ARCH = "x86_64"
BUILD_OS = "linux"
SDKMACHINE = "x86_64"
@@ -390,7 +389,6 @@ BB_SIGNATURE_HANDLER = "OEBasicHash"
self.write_config("""
MACHINE = "qemux86"
TMPDIR = "${TOPDIR}/tmp-sstatesamehash2"
-TCLIBCAPPEND = ""
BUILD_ARCH = "i686"
BUILD_OS = "linux"
SDKMACHINE = "i686"
@@ -426,7 +424,6 @@ BB_SIGNATURE_HANDLER = "OEBasicHash"
self.write_config("""
TMPDIR = \"${TOPDIR}/tmp-sstatesamehash\"
-TCLIBCAPPEND = \"\"
NATIVELSBSTRING = \"DistroA\"
BB_SIGNATURE_HANDLER = "OEBasicHash"
""")
@@ -434,7 +431,6 @@ BB_SIGNATURE_HANDLER = "OEBasicHash"
bitbake("core-image-weston -S none")
self.write_config("""
TMPDIR = \"${TOPDIR}/tmp-sstatesamehash2\"
-TCLIBCAPPEND = \"\"
NATIVELSBSTRING = \"DistroB\"
BB_SIGNATURE_HANDLER = "OEBasicHash"
""")
@@ -463,14 +459,12 @@ class SStateHashSameSigs2(SStateBase):
configA = """
TMPDIR = \"${TOPDIR}/tmp-sstatesamehash\"
-TCLIBCAPPEND = \"\"
MACHINE = \"qemux86-64\"
BB_SIGNATURE_HANDLER = "OEBasicHash"
"""
#OLDEST_KERNEL is arch specific so set to a different value here for
testing
configB = """
TMPDIR = \"${TOPDIR}/tmp-sstatesamehash2\"
-TCLIBCAPPEND = \"\"
MACHINE = \"qemuarm\"
OLDEST_KERNEL = \"3.3.0\"
BB_SIGNATURE_HANDLER = "OEBasicHash"
@@ -486,7 +480,6 @@ WARN_QA:append = " someotheroption"
configA = """
TMPDIR = \"${TOPDIR}/tmp-sstatesamehash\"
[OE-core] [PATCH] insane: Remove dependency on TCLIBC from QA test
The TCLIBC value is already encoded into build paths through the triplet
so no need to encode it here where it can cause problems for allarch output
that span multiple libcs.
Signed-off-by: Richard Purdie
---
meta/classes-global/insane.bbclass | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/classes-global/insane.bbclass
b/meta/classes-global/insane.bbclass
index d7aba89b494..1691d96b64a 100644
--- a/meta/classes-global/insane.bbclass
+++ b/meta/classes-global/insane.bbclass
@@ -430,6 +430,7 @@ def package_qa_hash_style(path, name, d, elf):
if has_syms and not sane:
path = package_qa_clean_path(path, d, name)
oe.qa.handle_error("ldflags", "File %s in package %s doesn't have
GNU_HASH (didn't pass LDFLAGS?)" % (path, name), d)
+package_qa_hash_style[vardepsexclude] = "TCLIBC"
QAPATHTEST[buildpaths] = "package_qa_check_buildpaths"
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#204198):
https://lists.openembedded.org/g/openembedded-core/message/204198
Mute This Topic: https://lists.openembedded.org/mt/108262305/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 06/22] json-glib: upgrade 1.8.0 -> 1.10.0
On Wed, 2024-09-04 at 01:25 +, Mingyu Wang (Fujitsu) wrote: > I set machine=qemux86_64, DISTRO="poky-altcfg", but I did not > reproduce this issue. > Is there any other setting necessary? That build also adds: DISTRO_FEATURES:append = ' api-documentation' Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#204193): https://lists.openembedded.org/g/openembedded-core/message/204193 Mute This Topic: https://lists.openembedded.org/mt/108241638/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 06/22] json-glib: upgrade 1.8.0 -> 1.10.0
On Tue, 2024-09-03 at 16:32 +0800, wangmy via lists.openembedded.org wrote: > From: Wang Mingyu > > License-Update: Add copyright and licensing metadata to all files > > Changelog: > == > - Improve conformance of the JSON parser > - Add conformance test suite from > https://github.com/nst/JSONTestSuite > - Add JsonParser:strict to enable strict parsing > - Add '--strict' to json-glib-validate to enable strict parsing > - Deprecate the signals on JsonParser > - Port tools man pages from DocBook to reStructureText > - Add "documentation" configuration option, and deprecate "gtk_doc" > - Add JsonGenerator.take_root() > - Documentation improvements for JsonReader > - Raise parser error for malformed Unicode > - Build fixes and performance improvements > - Allow disabling installed tests > - Support parsing multiple root statements in non-strict mode > - Allow loading files >4GB with json-glib-validate > > Signed-off-by: Wang Mingyu https://autobuilder.yoctoproject.org/typhoon/#/builders/108/builds/6344/steps/11/logs/stdio The recipe probably needs to adapt to the change listed above: 'Add "documentation" configuration option, and deprecate "gtk_doc"' but I didn't look in detail, I'm just noting it was a docs build that failed. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#204179): https://lists.openembedded.org/g/openembedded-core/message/204179 Mute This Topic: https://lists.openembedded.org/mt/108241638/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 2/2] elfutils: Drop obsolete ptest conditional in do_install
The PTEST_ENABLED conditional is no longer needed since the task is deleted
if ptest isn't enabled.
Signed-off-by: Richard Purdie
---
.../elfutils/elfutils_0.191.bb| 70 +--
1 file changed, 34 insertions(+), 36 deletions(-)
diff --git a/meta/recipes-devtools/elfutils/elfutils_0.191.bb
b/meta/recipes-devtools/elfutils/elfutils_0.191.bb
index 76bd2b3a99c..95364cef975 100644
--- a/meta/recipes-devtools/elfutils/elfutils_0.191.bb
+++ b/meta/recipes-devtools/elfutils/elfutils_0.191.bb
@@ -66,42 +66,40 @@ do_compile_ptest() {
PTEST_PARALLEL_MAKE = ""
do_install_ptest() {
- if [ ${PTEST_ENABLED} = "1" ]; then
- # copy the files which needed by the cases
- TEST_FILES="strip strip.o addr2line elfcmp objdump readelf
size.o nm.o nm elflint elfcompress elfclassify stack unstrip srcfiles"
- install -d -m 755 ${D}${PTEST_PATH}/src
- install -d -m 755 ${D}${PTEST_PATH}/lib
- install -d -m 755 ${D}${PTEST_PATH}/libelf
- install -d -m 755 ${D}${PTEST_PATH}/libdw
- install -d -m 755
${D}${PTEST_PATH}/libdwfl
- install -d -m 755
${D}${PTEST_PATH}/libdwelf
- install -d -m 755 ${D}${PTEST_PATH}/libasm
- install -d -m 755 ${D}${PTEST_PATH}/libcpu
- install -d -m 755 ${D}${PTEST_PATH}/libebl
- for test_file in ${TEST_FILES}; do
- if [ -f ${B}/src/${test_file} ]; then
- cp -r ${B}/src/${test_file}
${D}${PTEST_PATH}/src
- fi
- done
- cp ${D}${libdir}/libelf-${PV}.so
${D}${PTEST_PATH}/libelf/libelf.so
- cp ${D}${libdir}/libdw-${PV}.so ${D}${PTEST_PATH}/libdw/libdw.so
- cp ${D}${libdir}/libasm-${PV}.so
${D}${PTEST_PATH}/libasm/libasm.so
- cp ${B}/libcpu/libcpu.a ${D}${PTEST_PATH}/libcpu/
- cp ${B}/libebl/libebl.a ${D}${PTEST_PATH}/libebl/
- cp ${B}/lib/libeu.a ${D}${PTEST_PATH}/lib/
- cp ${S}/libelf/*.h ${D}${PTEST_PATH}/libelf/
- cp ${S}/libdw/*.h ${D}${PTEST_PATH}/libdw/
- cp ${S}/libdwfl/*.h${D}${PTEST_PATH}/libdwfl/
- cp ${S}/libdwelf/*.h ${D}${PTEST_PATH}/libdwelf/
- cp ${S}/libasm/*.h ${D}${PTEST_PATH}/libasm/
- cp -r ${S}/tests/ ${D}${PTEST_PATH}
- cp -r ${B}/tests/* ${D}${PTEST_PATH}/tests
- cp -r ${B}/config.h ${D}${PTEST_PATH}
- cp -r ${B}/backends ${D}${PTEST_PATH}
- cp -r ${B}/debuginfod ${D}${PTEST_PATH}
- sed -i '/^Makefile:/c Makefile:'
${D}${PTEST_PATH}/tests/Makefile
- find ${D}${PTEST_PATH} -type f -name *.[hoc] | xargs -i rm {}
- fi
+ # copy the files which needed by the cases
+ TEST_FILES="strip strip.o addr2line elfcmp objdump readelf size.o nm.o
nm elflint elfcompress elfclassify stack unstrip srcfiles"
+ install -d -m 755 ${D}${PTEST_PATH}/src
+ install -d -m 755 ${D}${PTEST_PATH}/lib
+ install -d -m 755 ${D}${PTEST_PATH}/libelf
+ install -d -m 755 ${D}${PTEST_PATH}/libdw
+ install -d -m 755 ${D}${PTEST_PATH}/libdwfl
+ install -d -m 755 ${D}${PTEST_PATH}/libdwelf
+ install -d -m 755 ${D}${PTEST_PATH}/libasm
+ install -d -m 755 ${D}${PTEST_PATH}/libcpu
+ install -d -m 755 ${D}${PTEST_PATH}/libebl
+ for test_file in ${TEST_FILES}; do
+ if [ -f ${B}/src/${test_file} ]; then
+ cp -r ${B}/src/${test_file} ${D}${PTEST_PATH}/src
+ fi
+ done
+ cp ${D}${libdir}/libelf-${PV}.so ${D}${PTEST_PATH}/libelf/libelf.so
+ cp ${D}${libdir}/libdw-${PV}.so ${D}${PTEST_PATH}/libdw/libdw.so
+ cp ${D}${libdir}/libasm-${PV}.so ${D}${PTEST_PATH}/libasm/libasm.so
+ cp ${B}/libcpu/libcpu.a ${D}${PTEST_PATH}/libcpu/
+ cp ${B}/libebl/libebl.a ${D}${PTEST_PATH}/libebl/
+ cp ${B}/lib/libeu.a ${D}${PTEST_PATH}/lib/
+ cp ${S}/libelf/*.h ${D}${PTEST_PATH}/libelf/
+ cp ${S}/libdw/*.h ${D}${PTEST_PATH}/libdw/
+ cp ${S}/libdwfl/*.h${D}${PTEST_PATH}/libdwfl/
+ cp ${S}/libdwelf/*.h ${D}${PTEST_PATH}/libdwelf/
+ cp ${S}/libasm/*.h
[OE-core] [PATCH 1/2] gettext: Drop obsolete ptest conditional in do_install
The PTEST_ENABLED conditional is no longer needed since the task is deleted
if ptest isn't enabled.
Signed-off-by: Richard Purdie
---
meta/recipes-core/gettext/gettext_0.22.5.bb | 2 --
1 file changed, 2 deletions(-)
diff --git a/meta/recipes-core/gettext/gettext_0.22.5.bb
b/meta/recipes-core/gettext/gettext_0.22.5.bb
index ef5272a2065..0bf2a56e5fc 100644
--- a/meta/recipes-core/gettext/gettext_0.22.5.bb
+++ b/meta/recipes-core/gettext/gettext_0.22.5.bb
@@ -145,7 +145,6 @@ do_compile_ptest() {
}
do_install_ptest() {
-if [ ${PTEST_ENABLED} = "1" ]; then
mkdir -p${D}${PTEST_PATH}/tests
mkdir -p${D}${PTEST_PATH}/src
mkdir -p${D}${PTEST_PATH}/po
@@ -178,7 +177,6 @@ do_install_ptest() {
chmod 0755 ${D}${PTEST_PATH}/tests/lang-vala
${D}${PTEST_PATH}/tests/plural-1 ${D}${PTEST_PATH}/tests/xgettext-tcl-4 \
${D}${PTEST_PATH}/tests/xgettext-vala-1
${D}${PTEST_PATH}/tests/xgettext-po-2 ${D}${PTEST_PATH}/tests/xgettext-vala-6
sed -i -e 's|${DEBUG_PREFIX_MAP}||g' ${D}${PTEST_PATH}/tests/init-env
-fi
}
RDEPENDS:${PN}-ptest += "make xz bash gawk autoconf locale-base-de-de
locale-base-fr-fr"
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#204165):
https://lists.openembedded.org/g/openembedded-core/message/204165
Mute This Topic: https://lists.openembedded.org/mt/108245465/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] does do_install_ptest() need to check "PTEST_ENABLED"?
On Tue, 2024-09-03 at 06:56 -0400, Robert P. J. Day via lists.openembedded.org wrote: > > another quirk in my travels through the ptest feature so i can > write > a tutorial, i ran across precisely two OE recipes that check > PTEST_ENABLED in their definition of do_install_ptest(): > > https://git.openembedded.org/openembedded-core/tree/meta/recipes-core/gettext/gettext_0.22.5.bb#n147 > https://git.openembedded.org/openembedded-core/tree/meta/recipes-devtools/elfutils/elfutils_0.191.bb#n68 > > that test *seems* unnecessary, or is there something particularly > subtle that might require that? i don't see any compelling reason to > have to check that variable. It is unnecessary with how the class is written now. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#204156): https://lists.openembedded.org/g/openembedded-core/message/204156 Mute This Topic: https://lists.openembedded.org/mt/108242664/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 1/3] uboot-config: fix devtool modify with kernel-fitimage
On Mon, 2024-09-02 at 22:31 +0200, Adrian Freihofer via lists.openembedded.org
wrote:
> From: Adrian Freihofer
>
> How to reproduce:
> - UBOOT_CONFIG must be used. With UBOOT_MACHINE it works fine.
> A simple example based on oe-core is to modify the
> beaglebone-yocto.conf file like this:
> -UBOOT_MACHINE = "am335x_evm_defconfig"
> +UBOOT_CONFIG = "foo"
> +UBOOT_CONFIG[foo] = "am335x_evm_defconfig"
> - A build configuration which inherits the kernel-fitimage.bbclass is
> needed. For example:
> MACHINE = "beaglebone-yocto"
> KERNEL_IMAGETYPE = "Image"
> KERNEL_IMAGETYPES += " fitImage "
> KERNEL_CLASSES = " kernel-fitimage "
>
> devtool modify linux-yocto
> devtool build linux-yocto
> ...
> > cp: cannot stat '.../linux-yocto-6.6.21+git/am335x_evm_defconfig/.config':
> No such file or directory
> > WARNING: .../linux-yocto/6.6.21+git/temp/run.do_configure.2081673:172 exit 1
> from 'cp .../linux-yocto-6.6.21+git/am335x_evm_defconfig/.config
> .../build/workspace/sources/linux-yocto/.config.baseline'
>
> The reason for this problem is that the uboot-config.bbclass sets the
> variable KCONFIG_CONFIG_ROOTDIR to a path that makes sense for u-boot,
> but not for other recipes. However, the kernel-fitimage.bbclasse, for
> example, inherits the uboot-config.bbclass, which brings the
> u-boot-specific path into the kernel build context.
>
> This change removes the uboot-specific KCONFIG_CONFIG_ROOTDIR path from
> recipes other than u-boot itself.
>
> Signed-off-by: Adrian Freihofer
> ---
> meta/classes-recipe/uboot-config.bbclass | 15 +--
> 1 file changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/meta/classes-recipe/uboot-config.bbclass
> b/meta/classes-recipe/uboot-config.bbclass
> index e55fc38b7c7..09001997d3d 100644
> --- a/meta/classes-recipe/uboot-config.bbclass
> +++ b/meta/classes-recipe/uboot-config.bbclass
> @@ -101,9 +101,9 @@ python () {
> # The "doc" varflag is special, we don't want to see it here
> ubootconfigflags.pop('doc', None)
> ubootconfig = (d.getVar('UBOOT_CONFIG') or "").split()
> + PN = d.getVar("PN")
Convention says uppercase strings are constants in python. I'd prefer
this to be something like recipename, particularly as the access isn't
immediately around the variable definition. This is mainly to try and
retain code consistency.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#204127):
https://lists.openembedded.org/g/openembedded-core/message/204127
Mute This Topic: https://lists.openembedded.org/mt/108234037/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 3/3] devtool: remove obsolete SRCTREECOVEREDTASKS handling
On Mon, 2024-09-02 at 22:31 +0200, Adrian Freihofer via lists.openembedded.org
wrote:
> From: Adrian Freihofer
>
> The kernel-yocto.bbclass defines some tasks tasks and it also adds these
> tasks to the SRCTREECOVEREDTASKS list. There is no need for devtool to
> duplicate this code and override what the kernel-yocto.bbclass already
> does.
>
> devtool modify generates a linux-yocto.6.6.bbappend containing:
> SRCTREECOVEREDTASKS="\
> do_fetch \
> do_kernel_checkout \
> do_kernel_configcheck \
> do_unpack \
> do_validate_branches \
> "
> do_patch[noexec] = "1"
>
> linux-yocto set SRCTREECOVEREDTASKS to
> SRCTREECOVEREDTASKS="\
> do_fetch \
> do_kernel_checkout \
> do_kernel_configcheck \
> do_patch \
> do_unpack \
> do_validate_branches \
> "
>
> The code in devtool modify is therefore considered as redundant and
> removed.
>
> Signed-off-by: Adrian Freihofer
> ---
> scripts/lib/devtool/standard.py | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/scripts/lib/devtool/standard.py b/scripts/lib/devtool/standard.py
> index 312eb8ab506..b2e1a6ca3a5 100644
> --- a/scripts/lib/devtool/standard.py
> +++ b/scripts/lib/devtool/standard.py
> @@ -952,9 +952,6 @@ def modify(args, config, basepath, workspace):
> f.write('EXTERNALSRC_BUILD:pn-%s = "%s"\n' % (pn, srctree))
>
> if bb.data.inherits_class('kernel', rd):
> - f.write('SRCTREECOVEREDTASKS = "do_validate_branches
> do_kernel_checkout '
> - 'do_fetch do_unpack do_kernel_configcheck"\n')
> - f.write('\ndo_patch[noexec] = "1"\n')
> f.write('\ndo_kernel_configme:prepend() {\n'
> ' if [ -e ${S}/.config ]; then\n'
> ' mv ${S}/.config ${S}/.config.old\n'
Note that "kernel" != "linux-yocto". Does a standard kernel still need
fetch/unpack?
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#204121):
https://lists.openembedded.org/g/openembedded-core/message/204121
Mute This Topic: https://lists.openembedded.org/mt/108234041/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] [yocto-security] OE-core CVE metrics for master on Sun 01 Sep 2024 01:00:01 AM HST
On Sun, 2024-09-01 at 01:18 -1000, Steve Sakoman via lists.yoctoproject.org wrote: > Full list: Found 0 unpatched CVEs Much as I wish that were true... :/ Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#204103): https://lists.openembedded.org/g/openembedded-core/message/204103 Mute This Topic: https://lists.openembedded.org/mt/108226399/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] [scarthgap][PATCH 4/4] sstate: Drop SSTATEPOSTINSTFUNC support
On Mon, 2024-09-02 at 11:31 +0100, Pedro Ferreira wrote: > From: Richard Purdie > > This was deprecated with the introduction of postfunc support for > tasks > in general and only used by buildhistory. Now that usage has been > removed, > drop the code from sstate.bbclass. Any other users should be able to > use > postfuncs too. > > Signed-off-by: Richard Purdie > --- > meta/classes-global/sstate.bbclass | 6 -- > 1 file changed, 6 deletions(-) I suspect this patch can be dropped from the series as we wouldn't remove this on a stable branch. I'd also highlight that this has not merged to master yet. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#204099): https://lists.openembedded.org/g/openembedded-core/message/204099 Mute This Topic: https://lists.openembedded.org/mt/108224350/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] why does EXTRA_IMAGE_FEATURES += "ptest-pkgs" not install *all* ptest pkgs?
On Mon, 2024-09-02 at 06:39 -0400, Robert P. J. Day via lists.openembedded.org wrote: > > i'm sure i've overlooked something silly, but in building a > qemuarm64 image to demo ptest to some colleagues, poky by default sets > the "ptest" DISTRO_FEATURES setting so all of the corresponding ptest > packages are *built*, but when adding: > > EXTRA_IMAGE_FEATURES += "ptest-pkgs" > > only *some* of the ptest packages are added to the image. eg: while > bzip2-ptest is built, it is not added to the image, as are a number of > other ptest packages. if i *explicitly* add that package, then it gets > included. > > is there some obvious reason that a number of ptest packages are not > included in the resulting image, despite them being built? In your example, was bzip2 actually in your image or was it only built? I suspect it only installs ptests for things actually in the image. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#204089): https://lists.openembedded.org/g/openembedded-core/message/204089 Mute This Topic: https://lists.openembedded.org/mt/108224395/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 1/3] systemd-tools: add recipe
On Mon, 2024-09-02 at 12:41 +0300, Mikko Rapeli via
lists.openembedded.org wrote:
> From: Erik Schilling
>
> Provides systemd-tools-native recipe for ukify.py tooling.
> Avoids full systemd native build which is not needed.
>
> Signed-off-by: Mikko Rapeli
> ---
> .../systemd/systemd-tools_256.5.bb | 41
> +++
> 1 file changed, 41 insertions(+)
> create mode 100644 meta/recipes-core/systemd/systemd-tools_256.5.bb
>
> diff --git a/meta/recipes-core/systemd/systemd-tools_256.5.bb
> b/meta/recipes-core/systemd/systemd-tools_256.5.bb
> new file mode 100644
> index 00..f2e419ffe0
> --- /dev/null
> +++ b/meta/recipes-core/systemd/systemd-tools_256.5.bb
> @@ -0,0 +1,41 @@
> +require systemd.inc
> +FILESEXTRAPATHS =. "${FILE_DIRNAME}/systemd:"
> +
> +DEPENDS = " \
> + intltool-native \
> + libcap \
> + util-linux \
> + gperf-native \
> + python3-jinja2-native \
> + python3-pyelftools-native \
> + python3-pefile \
> +"
> +
> +inherit meson pkgconfig gettext
> +
> +MESON_TARGET = "ukify"
> +
> +# Helper variables to clarify locations. This mirrors the logic in
> systemd's
> +# build system.
> +rootprefix ?= "${root_prefix}"
> +rootlibdir ?= "${base_libdir}"
> +rootlibexecdir = "${rootprefix}/lib"
> +
> +EXTRA_OEMESON += "-Dnobody-user=nobody \
> + -Dnobody-group=nogroup \
> + -Drootlibdir=${rootlibdir} \
> + -Drootprefix=${rootprefix} \
> + -Ddefault-locale=C \
> + -Dmode=release \
> + -Dsystem-alloc-uid-min=101 \
> + -Dsystem-uid-max=999 \
> + -Dsystem-alloc-gid-min=101 \
> + -Dsystem-gid-max=999 \
> +"
> +
> +do_install() {
> + install -d ${D}${bindir}/
> + install -m 0755 ${S}/src/ukify/ukify.py ${D}${bindir}/ukify
> +}
> +
> +BBCLASSEXTEND = "native"
This will fail in CI as there is now maintainers file entry...
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#204068):
https://lists.openembedded.org/g/openembedded-core/message/204068
Mute This Topic: https://lists.openembedded.org/mt/108223984/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] gcc-sanitizers: Add ptest support for AddressSanitizer tests
On Mon, 2024-09-02 at 00:39 -0700, Hemraj, Deepthi via lists.openembedded.org
wrote:
> From: Deepthi Hemraj
>
> [YOCTO #15338]
> Enabled ptest integration in gcc-sanitizers.inc to facilitate the proper
> testing and execution of address sanitizer (ASan)
>
> Defined the do_check task to execute ASan tests with proper environment setup
> and updated do_install_ptest_base to copy ASan test executables to the ptest
> directory. Included the run-ptest script to automate test execution.
>
> The run-ptest script iterates through executable files copied from the host,
> runs each on the target, and logs the outcomes as either 'PASS' or 'XFAIL'.
> XFAIL is because these tests are expected to fail on the host system as per
> dejagnu as { dg-shouldfail "asan" }
>
> Signed-off-by: Deepthi Hemraj
> ---
> .../distro/include/ptest-packagelists.inc | 1 +
> meta/recipes-devtools/gcc/gcc-14.2.inc | 2 +
> meta/recipes-devtools/gcc/gcc-sanitizers.inc | 43
> meta/recipes-devtools/gcc/gcc/asan-exp.patch | 51 +++
> meta/recipes-devtools/gcc/gcc/run-ptest | 28 ++
> 5 files changed, 125 insertions(+)
> create mode 100644 meta/recipes-devtools/gcc/gcc/asan-exp.patch
> create mode 100755 meta/recipes-devtools/gcc/gcc/run-ptest
Would it make more sense to run this as part of the other gcc testsuites?
It looks like there is a lot of duplication in these changes including
a lot of ptest code.
I'm also quite concerned at the buildpaths exceptions, build paths
would be pointless in target packages so I'm not sure why those are
present.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#204063):
https://lists.openembedded.org/g/openembedded-core/message/204063
Mute This Topic: https://lists.openembedded.org/mt/108223362/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] [AUH] Upgrade status: 2024-09-01
On Sun, 2024-09-01 at 21:21 +0200, Alexander Kanavin wrote: > This AUH run was thwarted by a botched libtool update - it's one of > those notorious corner cases that AUH hits occasionally. First, > libtool update failed thusly: > https://lists.openembedded.org/g/openembedded-core/topic/auh/108206634 > > (if I'm reading this right, libtool-native got upgraded first, but > the > outcome was a non-functional libtool-native for the purpose of tasks > that 'devtool upgrade' needs to run) > > Then, this somehow damaged the build dir so that no further builds in > it could happen, but AUH cannot tell when that happens and carries on > with the list of things to update: > https://lists.openembedded.org/g/openembedded-core/topic/auh/108206638 > > libtool releases have historically been rare, and RP has issued an > update for this one already. If new libtool releases continue to > subvert AUH, we can probably mark it as needing manual updates. There is a patch specific to libtool-cross and maybe some others but not libtool-native and that needed to be rebased (fixinstall.patch). I suspect that is what caused AUH the issues :/. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#204058): https://lists.openembedded.org/g/openembedded-core/message/204058 Mute This Topic: https://lists.openembedded.org/mt/108206687/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 2/2] libtool: 2.5.1 -> 2.5.2
Signed-off-by: Richard Purdie
---
.../{libtool-2.5.1.inc => libtool-2.5.2.inc} | 2 +-
...-cross_2.5.1.bb => libtool-cross_2.5.2.bb} | 0
...ative_2.5.1.bb => libtool-native_2.5.2.bb} | 0
.../libtool/libtool/fixinstall.patch | 35 ---
.../{libtool_2.5.1.bb => libtool_2.5.2.bb}| 0
...ol_2.5.1.bb => nativesdk-libtool_2.5.2.bb} | 0
6 files changed, 23 insertions(+), 14 deletions(-)
rename meta/recipes-devtools/libtool/{libtool-2.5.1.inc => libtool-2.5.2.inc}
(94%)
rename meta/recipes-devtools/libtool/{libtool-cross_2.5.1.bb =>
libtool-cross_2.5.2.bb} (100%)
rename meta/recipes-devtools/libtool/{libtool-native_2.5.1.bb =>
libtool-native_2.5.2.bb} (100%)
rename meta/recipes-devtools/libtool/{libtool_2.5.1.bb => libtool_2.5.2.bb}
(100%)
rename meta/recipes-devtools/libtool/{nativesdk-libtool_2.5.1.bb =>
nativesdk-libtool_2.5.2.bb} (100%)
diff --git a/meta/recipes-devtools/libtool/libtool-2.5.1.inc
b/meta/recipes-devtools/libtool/libtool-2.5.2.inc
similarity index 94%
rename from meta/recipes-devtools/libtool/libtool-2.5.1.inc
rename to meta/recipes-devtools/libtool/libtool-2.5.2.inc
index 94344d4d416..bde80e12ce7 100644
--- a/meta/recipes-devtools/libtool/libtool-2.5.1.inc
+++ b/meta/recipes-devtools/libtool/libtool-2.5.2.inc
@@ -18,7 +18,7 @@ SRC_URI =
"https://alpha.gnu.org/gnu/libtool/libtool-${PV}.tar.gz \
file://nohardcodepaths.patch \
"
-SRC_URI[sha256sum] =
"6a83edafd42d4e2ebdc09579f99ce828d5f932f1738de02495cc8c2884e430ce"
+SRC_URI[sha256sum] =
"29275fb45b236d6ff720a433f9cd5f61ea2f52cc3aa2e5f89ba57726bda54793"
inherit autotools texinfo
EXTRA_AUTORECONF = "--exclude=libtoolize"
diff --git a/meta/recipes-devtools/libtool/libtool-cross_2.5.1.bb
b/meta/recipes-devtools/libtool/libtool-cross_2.5.2.bb
similarity index 100%
rename from meta/recipes-devtools/libtool/libtool-cross_2.5.1.bb
rename to meta/recipes-devtools/libtool/libtool-cross_2.5.2.bb
diff --git a/meta/recipes-devtools/libtool/libtool-native_2.5.1.bb
b/meta/recipes-devtools/libtool/libtool-native_2.5.2.bb
similarity index 100%
rename from meta/recipes-devtools/libtool/libtool-native_2.5.1.bb
rename to meta/recipes-devtools/libtool/libtool-native_2.5.2.bb
diff --git a/meta/recipes-devtools/libtool/libtool/fixinstall.patch
b/meta/recipes-devtools/libtool/libtool/fixinstall.patch
index 48330d82fbf..94601b1beb8 100644
--- a/meta/recipes-devtools/libtool/libtool/fixinstall.patch
+++ b/meta/recipes-devtools/libtool/libtool/fixinstall.patch
@@ -18,10 +18,11 @@ RP 2011/11/16
Updated by: Robert Yang
-diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
a/build-aux/ltmain.in
-+++ b/build-aux/ltmain.in
-@@ -2355,7 +2355,7 @@ func_mode_install ()
+Index: libtool-2.5.2/build-aux/ltmain.in
+===
+--- libtool-2.5.2.orig/build-aux/ltmain.in
libtool-2.5.2/build-aux/ltmain.in
+@@ -2381,7 +2381,7 @@ func_mode_install ()
dir=$func_dirname_result
func_append dir "$objdir"
@@ -29,8 +30,8 @@ diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
+ if test "$fast_install" = no && test -n "$relink_command"; then
# Strip any trailing slash from the destination.
func_stripname '' '/' "$libdir"
- destlibdir=$func_stripname_result
-@@ -2394,7 +2394,7 @@ func_mode_install ()
+ destlibdir=$func_stripname_result
+@@ -2419,7 +2419,7 @@ func_mode_install ()
shift
srcname=$realname
@@ -39,7 +40,7 @@ diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
# Install the shared library and build the symlinks.
func_show_eval "$install_shared_prog $dir/$srcname
$destdir/$realname" \
-@@ -6162,15 +6162,15 @@ func_mode_link ()
+@@ -6276,17 +6276,17 @@ func_mode_link ()
# Hardcode the library path.
# Skip directories that are in the system default run-time
# search path.
@@ -48,7 +49,9 @@ diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
- *)
-case "$compile_rpath " in
-*" $absdir "*) ;;
--*) func_append compile_rpath " $absdir" ;;
+-*) case $absdir in
+- "$progdir/"*) func_append compile_rpath " $absdir" ;;
+- esac
-esac
-;;
- esac
@@ -57,14 +60,16 @@ diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
+ #*)
+ # case "$compile_rpath " in
+ # *" $absdir "*) ;;
-+ # *) func_append compile_rpath " $absdir" ;;
++ # *) case $absdir in
++# "$progdir/"*) func_append compile_rpath " $absdir" ;;
++ #esac
+ # esac
+
[OE-core] [PATCH 1/2] lttng-tools: 2.13.13 -> 2.13.14
Signed-off-by: Richard Purdie
---
.../lttng/{lttng-tools_2.13.13.bb => lttng-tools_2.13.14.bb}| 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-kernel/lttng/{lttng-tools_2.13.13.bb =>
lttng-tools_2.13.14.bb} (99%)
diff --git a/meta/recipes-kernel/lttng/lttng-tools_2.13.13.bb
b/meta/recipes-kernel/lttng/lttng-tools_2.13.14.bb
similarity index 99%
rename from meta/recipes-kernel/lttng/lttng-tools_2.13.13.bb
rename to meta/recipes-kernel/lttng/lttng-tools_2.13.14.bb
index e73dd4801a6..65d19b6e5fd 100644
--- a/meta/recipes-kernel/lttng/lttng-tools_2.13.13.bb
+++ b/meta/recipes-kernel/lttng/lttng-tools_2.13.14.bb
@@ -41,7 +41,7 @@ SRC_URI =
"https://lttng.org/files/lttng-tools/lttng-tools-${PV}.tar.bz2 \
file://0001-Fix-rotation-destroy-flush-fix-session-daemon-abort-.patch \
"
-SRC_URI[sha256sum] =
"ff5f4f00b081dac66092afe8e72b7c790670931cf1c1ee0deaa7f80fbc53883e"
+SRC_URI[sha256sum] =
"53bdf7c4ad07dbfe660ee4d9affc63fe44ae59e9a73c6f7a96e0fca140e5adcb"
inherit autotools ptest pkgconfig useradd python3-dir manpages systemd
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#204053):
https://lists.openembedded.org/g/openembedded-core/message/204053
Mute This Topic: https://lists.openembedded.org/mt/108215563/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 2/2] sstate: Drop SSTATEPOSTINSTFUNC support
This was deprecated with the introduction of postfunc support for tasks
in general and only used by buildhistory. Now that usage has been removed,
drop the code from sstate.bbclass. Any other users should be able to use
postfuncs too.
Signed-off-by: Richard Purdie
---
meta/classes-global/sstate.bbclass | 6 --
1 file changed, 6 deletions(-)
diff --git a/meta/classes-global/sstate.bbclass
b/meta/classes-global/sstate.bbclass
index 586757afbd5..f38041b735a 100644
--- a/meta/classes-global/sstate.bbclass
+++ b/meta/classes-global/sstate.bbclass
@@ -103,7 +103,6 @@ SSTATECREATEFUNCS[vardeps] = "SSTATE_SCAN_FILES"
SSTATEPOSTCREATEFUNCS = ""
SSTATEPREINSTFUNCS = ""
SSTATEPOSTUNPACKFUNCS = "sstate_hardcode_path_unpack"
-SSTATEPOSTINSTFUNCS = ""
EXTRA_STAGING_FIXMES ?= "HOSTTOOLS_DIR"
# Check whether sstate exists for tasks that support sstate and are in the
@@ -352,15 +351,10 @@ def sstate_install(ss, d):
prepdir(dest)
bb.utils.rename(src, dest)
-for postinst in (d.getVar('SSTATEPOSTINSTFUNCS') or '').split():
-# All hooks should run in the SSTATE_INSTDIR
-bb.build.exec_func(postinst, d, (sstateinst,))
-
for lock in locks:
bb.utils.unlockfile(lock)
sstate_install[vardepsexclude] += "SSTATE_ALLOW_OVERLAP_FILES SSTATE_MANMACH
SSTATE_MANFILEPREFIX"
-sstate_install[vardeps] += "${SSTATEPOSTINSTFUNCS}"
def sstate_installpkg(ss, d):
from oe.gpg_sign import get_signer
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#204049):
https://lists.openembedded.org/g/openembedded-core/message/204049
Mute This Topic: https://lists.openembedded.org/mt/108211450/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 1/2] buildhistory: Simplify intercept call sites and drop SSTATEPOSTINSTFUNC usage
We planned to drop SSTATEPOSTINSTFUNC some time ago with the introduction of
postfuncs. Finally get around to doing that which should make the buildhistory
code a little more readable.
Unfortunately ordering the buildhistory function calls after the sstate ones is
difficult without coding that into the sstate class. This patch does that to
ensure everything functions as expected until we can find a better way. This is
still likely preferable than the generic sstate postfuncs support since the
function
flow is much more readable.
Signed-off-by: Richard Purdie
---
meta/classes-global/sstate.bbclass | 5 +++-
meta/classes/buildhistory.bbclass | 39 +++---
2 files changed, 23 insertions(+), 21 deletions(-)
diff --git a/meta/classes-global/sstate.bbclass
b/meta/classes-global/sstate.bbclass
index fdd529ee4e8..586757afbd5 100644
--- a/meta/classes-global/sstate.bbclass
+++ b/meta/classes-global/sstate.bbclass
@@ -161,7 +161,10 @@ python () {
d.setVar('SSTATETASKS', " ".join(unique_tasks))
for task in unique_tasks:
d.prependVarFlag(task, 'prefuncs', "sstate_task_prefunc ")
-d.appendVarFlag(task, 'postfuncs', " sstate_task_postfunc")
+# Generally sstate should be last, execpt for buildhistory functions
+postfuncs = (d.getVarFlag(task, 'postfuncs') or "").split()
+newpostfuncs = [p for p in postfuncs if "buildhistory" not in p] +
["sstate_task_postfunc"] + [p for p in postfuncs if "buildhistory" in p]
+d.setVarFlag(task, 'postfuncs', " ".join(newpostfuncs))
d.setVarFlag(task, 'network', '1')
d.setVarFlag(task + "_setscene", 'network', '1')
}
diff --git a/meta/classes/buildhistory.bbclass
b/meta/classes/buildhistory.bbclass
index bac2abdab0f..ce3abaa69d4 100644
--- a/meta/classes/buildhistory.bbclass
+++ b/meta/classes/buildhistory.bbclass
@@ -47,11 +47,18 @@ BUILDHISTORY_PUSH_REPO ?= ""
BUILDHISTORY_TAG ?= "build"
BUILDHISTORY_PATH_PREFIX_STRIP ?= ""
-SSTATEPOSTINSTFUNCS:append = " buildhistory_emit_pkghistory"
-# We want to avoid influencing the signatures of sstate tasks - first the
function itself:
-sstate_install[vardepsexclude] += "buildhistory_emit_pkghistory"
-# then the value added to SSTATEPOSTINSTFUNCS:
-SSTATEPOSTINSTFUNCS[vardepvalueexclude] .= "| buildhistory_emit_pkghistory"
+# We want to avoid influencing the signatures of the task so use vardepsexclude
+do_populate_sysroot[postfuncs] += "buildhistory_emit_sysroot"
+do_populate_sysroot_setscene[postfuncs] += "buildhistory_emit_sysroot"
+do_populate_sysroot[vardepsexclude] += "buildhistory_emit_sysroot"
+
+do_package[postfuncs] += "buildhistory_list_pkg_files"
+do_package_setscene[postfuncs] += "buildhistory_list_pkg_files"
+do_package[vardepsexclude] += "buildhistory_list_pkg_files"
+
+do_packagedata[postfuncs] += "buildhistory_emit_pkghistory"
+do_packagedata_setscene[postfuncs] += "buildhistory_emit_pkghistory"
+do_packagedata[vardepsexclude] += "buildhistory_emit_pkghistory"
# Similarly for our function that gets the output signatures
SSTATEPOSTUNPACKFUNCS:append = " buildhistory_emit_outputsigs"
@@ -91,27 +98,15 @@ buildhistory_emit_sysroot() {
# Write out metadata about this package for comparison when writing future
packages
#
python buildhistory_emit_pkghistory() {
-if d.getVar('BB_CURRENTTASK') in ['populate_sysroot',
'populate_sysroot_setscene']:
-bb.build.exec_func("buildhistory_emit_sysroot", d)
-return 0
-
-if not "package" in (d.getVar('BUILDHISTORY_FEATURES') or "").split():
-return 0
-
-if d.getVar('BB_CURRENTTASK') in ['package', 'package_setscene']:
-# Create files-in-.txt files containing a list of files
of each recipe's package
-bb.build.exec_func("buildhistory_list_pkg_files", d)
-return 0
-
-if not d.getVar('BB_CURRENTTASK') in ['packagedata',
'packagedata_setscene']:
-return 0
-
import re
import json
import shlex
import errno
import shutil
+if not "package" in (d.getVar('BUILDHISTORY_FEATURES') or "").split():
+return 0
+
pkghistdir = d.getVar('BUILDHISTORY_DIR_PACKAGE')
oldpkghistdir = d.getVar('BUILDHISTORY_OLD_DIR_PACKAGE')
@@ -621,6 +616,10 @@ buildhistory_list_files_no_owners() {
}
buildhistory_list_pkg_files() {
+ if [ "${@bb.utils.contains('BUILDHISTORY_FEATURES', 'package', '1',
'0', d)}"
Re: [OE-core] [PATCH] insane: Drop oe.qa.add_message usage
On Sun, 2024-09-01 at 11:21 +, Peter Kjellerstedt wrote: > > -Original Message- > > From: openembedded-core@lists.openembedded.org > > On Behalf Of Richard Purdie > > Sent: den 28 augusti 2024 18:15 > > To: openembedded-core@lists.openembedded.org > > Subject: [OE-core] [PATCH] insane: Drop oe.qa.add_message usage > > > > Drop the oe.qa.add_message() usage in favour of oe.qa.handle_error() which > > has > > code allowing it to be optimised with contains usage. > > > > The patch also drops unused return values which we stopped using a while ago > > and drops the now unneeded function parameters, generally leading to cleaner > > code. > > > > The code should be functionally equivalent. > > There is at least one difference. We have the following in our distro: > > WARN_QA:remove = "virtual-slash" > ERROR_QA:remove = "virtual-slash" > > since we do not build any package feeds and thus this QA error is not a > problem > for us. > > After the change from add_message() to handle_error(), I now get a lot of: > > NOTE: /path/to/recipe_1.2.3.bb: QA Issue: RDEPENDS is set to virtual/foobar > but the substring 'virtual/' holds no meaning in this context. It only works > for build time dependencies, not runtime ones. It is suggested to use > 'VIRTUAL-RUNTIME_' variables instead. [virtual-slash] > > during recipe parsing, which defeats the purpose of turning of the QA error. > > Now, we can of course fix our recipes to avoid the use of runtime > dependencies > on virtual/. I just wanted to point out that there is a difference in > functionality, and one that is hard to do anything about in layers on top of > OE-Core. You're right, that is an unintended side effect. That said, I think the note log level is very noisy anyway? Is the issue that notes at parse time get handled differently to those during task execution? Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#204046): https://lists.openembedded.org/g/openembedded-core/message/204046 Mute This Topic: https://lists.openembedded.org/mt/108145107/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] icu: Fix 'buildpaths' QA error
On Sat, 2024-08-31 at 16:01 +0300, Niko Mauno via lists.openembedded.org wrote: > Add stripping of STAGING_DIR_NATIVE during target/nativesdk specific > do_install, which mitigates following BitBake failure: > > ERROR: icu-75-1-r0 do_package_qa: QA Issue: File > /usr/lib/icu/75.1/pkgdata.inc in package icu-dev contains reference > to TMPDIR [buildpaths] > ERROR: icu-75-1-r0 do_package_qa: Fatal QA errors were found, > failing task. > > While doing so, we also drop HOSTTOOLS_DIR stripping, as it's value > does not appear in the content of either file that are manipulated > here. > > Signed-off-by: Niko Mauno > --- > meta/recipes-support/icu/icu_75-1.bb | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Why aren't we seeing this issue in automated test? Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#204043): https://lists.openembedded.org/g/openembedded-core/message/204043 Mute This Topic: https://lists.openembedded.org/mt/108194777/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] abi-version/ssate: Bump to avoid systemd hash corruption issue
On Sun, 2024-09-01 at 10:36 +, Peter Kjellerstedt wrote: > > -Original Message- > > From: > > openembedded-core@lists.openembedded.org > > > > On Behalf Of Richard Purdie > > Sent: den 1 september 2024 09:19 > > To: openembedded-core@lists.openembedded.org > > Subject: [OE-core] [PATCH] abi-version/ssate: Bump to avoid systemd > > hash corruption issue > > > > Unfortunately some recent patches caused non-deterministic output. > > One input hash lead to both good and bad output and whilst that > > patch > > has been fixed, the problematic hash 'cross' linkage remains. Bump > > to > > a new sstate and hash equivalence version to avoid this and work > > from > > a clean slate. > > > > Signed-off-by: Richard Purdie > > --- > > meta/classes-global/sstate.bbclass | 2 +- > > meta/conf/abi_version.conf | 2 +- > > 2 files changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/meta/classes-global/sstate.bbclass b/meta/classes- > > global/sstate.bbclass > > index beb22f424e8..fdd529ee4e8 100644 > > --- a/meta/classes-global/sstate.bbclass > > +++ b/meta/classes-global/sstate.bbclass > > @@ -4,7 +4,7 @@ > > # SPDX-License-Identifier: MIT > > # > > > > -SSTATE_VERSION = "12" > > +SSTATE_VERSION = "14" > > > > SSTATE_ZSTD_CLEVEL ??= "8" > > > > diff --git a/meta/conf/abi_version.conf > > b/meta/conf/abi_version.conf > > index 0fe91b5ddf3..ac97752c976 100644 > > --- a/meta/conf/abi_version.conf > > +++ b/meta/conf/abi_version.conf > > @@ -12,4 +12,4 @@ OELAYOUT_ABI = "15" > > # a reset of the equivalence, for example when reproducibility > > issues break the > > # existing match data. Distros can also append to this value for > > the same effect. > > # > > -HASHEQUIV_HASH_VERSION = "17" > > +HASHEQUIV_HASH_VERSION = "18" > > Is this actually needed now after the changes to insane.bbclass? > Won't those changes effectively invalidate the whole sstate anyway? Firstly, those changes don't change the output of the tasks so no, the mismatched output hashes would have remained a problem. Secondly, those had already merged and been tested alongside the systemd changes so it was already too late anyway. So sadly I just can't see an alternative to this due to where the corruption is. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#204042): https://lists.openembedded.org/g/openembedded-core/message/204042 Mute This Topic: https://lists.openembedded.org/mt/108207031/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] abi-version/ssate: Bump to avoid systemd hash corruption issue
Unfortunately some recent patches caused non-deterministic output. One input hash lead to both good and bad output and whilst that patch has been fixed, the problematic hash 'cross' linkage remains. Bump to a new sstate and hash equivalence version to avoid this and work from a clean slate. Signed-off-by: Richard Purdie --- meta/classes-global/sstate.bbclass | 2 +- meta/conf/abi_version.conf | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/classes-global/sstate.bbclass b/meta/classes-global/sstate.bbclass index beb22f424e8..fdd529ee4e8 100644 --- a/meta/classes-global/sstate.bbclass +++ b/meta/classes-global/sstate.bbclass @@ -4,7 +4,7 @@ # SPDX-License-Identifier: MIT # -SSTATE_VERSION = "12" +SSTATE_VERSION = "14" SSTATE_ZSTD_CLEVEL ??= "8" diff --git a/meta/conf/abi_version.conf b/meta/conf/abi_version.conf index 0fe91b5ddf3..ac97752c976 100644 --- a/meta/conf/abi_version.conf +++ b/meta/conf/abi_version.conf @@ -12,4 +12,4 @@ OELAYOUT_ABI = "15" # a reset of the equivalence, for example when reproducibility issues break the # existing match data. Distros can also append to this value for the same effect. # -HASHEQUIV_HASH_VERSION = "17" +HASHEQUIV_HASH_VERSION = "18" -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#204040): https://lists.openembedded.org/g/openembedded-core/message/204040 Mute This Topic: https://lists.openembedded.org/mt/108207031/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] sysvinit: upgrade 3.04 -> 3.10
On Thu, 2024-08-29 at 13:36 -0700, Sven Reschke via lists.openembedded.org wrote: > > On Thu, Aug 29, 2024 at 1:52 AM Richard Purdie via > > lists.openembedded.org > > wrote: > > > On Mon, 2024-08-26 at 12:01 -0700, Sven Reschke via > > > lists.openembedded.org wrote: > > > > Hi Alex and Alexandre, > > > > > > > > sorry for the delay. > > > > I've created a PR on Github on top of your latest changes: > > > > https://github.com/Nanowires/oe-core-clone/pull/1 > > > I did try this on our automated testing and there were some > > > issues: > > > > > > musl build failures: > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/9440/steps/11/logs/stdio > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/45/builds/9456/steps/11/logs/stdio > > This can be fixed by using realpath(path, NULL) API instead of > > canonicalize_file_name(path), we have done such changes > > in few packages e.g. elfutils > > > > https://sourceware.org/git/?p=elfutils.git;a=commitdiff;h=06263dda990be6778a4beb33481cfd39ce60c623;hp=fd0cee63fb02455a5021ca298da8dadb4df63a9a > > > > there is a meta-oe patch for ssiapi > > https://git.openembedded.org/meta-openembedded/tree/meta-oe/recipes-support/ssiapi/ssiapi/0003-replace-canonicalize_file_name-with-realpath.patch > > > first of all: Thanks for the automated testing :-) > Yes, I broke the realpath.patch with my update. I've pushed a fix, > which should solve this issue. > > > > systemd+sysvinit build failure: > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/72/builds/9431/steps/25/logs/stdio > > > > Cheers, > > > > Richard > For this I fixed the install.patch (which I removed in the first > place). Could you re-run the tests with my latest commits? ;-) I can't just test one persons changes so there are multiple patches causing multiple issues in this build but there still seem to be sysvinit issues: https://autobuilder.yoctoproject.org/typhoon/#/builders/113/builds/5903/steps/12/logs/stdio There are probably other issues in there too. As Alex says, pulling patches from github subverts our review process so whilst I did it as a one off, I can't do this on a regular basis. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#203952): https://lists.openembedded.org/g/openembedded-core/message/203952 Mute This Topic: https://lists.openembedded.org/mt/107960881/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] selftest/sstatetests: Extend to cover ERROR_QA/WARN_QA common issues
Now that adding new values to ERROR_QA doesn't invalidate tasks, add this check to the selftests so that this functionality doens't regress in future. Signed-off-by: Richard Purdie --- meta/lib/oeqa/selftest/cases/sstatetests.py | 2 ++ 1 file changed, 2 insertions(+) diff --git a/meta/lib/oeqa/selftest/cases/sstatetests.py b/meta/lib/oeqa/selftest/cases/sstatetests.py index 0153ef37cb6..49d650bac7a 100644 --- a/meta/lib/oeqa/selftest/cases/sstatetests.py +++ b/meta/lib/oeqa/selftest/cases/sstatetests.py @@ -474,6 +474,8 @@ TCLIBCAPPEND = \"\" MACHINE = \"qemuarm\" OLDEST_KERNEL = \"3.3.0\" BB_SIGNATURE_HANDLER = "OEBasicHash" +ERROR_QA:append = " somenewoption" +WARN_QA:append = " someotheroption" """ self.sstate_common_samesigs(configA, configB, allarch=True) -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#203918): https://lists.openembedded.org/g/openembedded-core/message/203918 Mute This Topic: https://lists.openembedded.org/mt/108159594/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] sstate: Drop SSTATEPOSTINSTFUNC support
This was deprecated with the introduction of postfunc support for tasks
in general and only used by buildhistory. Now that usage has been removed,
drop the code from sstate.bbclass. Any other users should be able to use
postfuncs too.
Signed-off-by: Richard Purdie
---
meta/classes-global/sstate.bbclass | 6 --
1 file changed, 6 deletions(-)
diff --git a/meta/classes-global/sstate.bbclass
b/meta/classes-global/sstate.bbclass
index beb22f424e8..2a8a40ef570 100644
--- a/meta/classes-global/sstate.bbclass
+++ b/meta/classes-global/sstate.bbclass
@@ -103,7 +103,6 @@ SSTATECREATEFUNCS[vardeps] = "SSTATE_SCAN_FILES"
SSTATEPOSTCREATEFUNCS = ""
SSTATEPREINSTFUNCS = ""
SSTATEPOSTUNPACKFUNCS = "sstate_hardcode_path_unpack"
-SSTATEPOSTINSTFUNCS = ""
EXTRA_STAGING_FIXMES ?= "HOSTTOOLS_DIR"
# Check whether sstate exists for tasks that support sstate and are in the
@@ -349,15 +348,10 @@ def sstate_install(ss, d):
prepdir(dest)
bb.utils.rename(src, dest)
-for postinst in (d.getVar('SSTATEPOSTINSTFUNCS') or '').split():
-# All hooks should run in the SSTATE_INSTDIR
-bb.build.exec_func(postinst, d, (sstateinst,))
-
for lock in locks:
bb.utils.unlockfile(lock)
sstate_install[vardepsexclude] += "SSTATE_ALLOW_OVERLAP_FILES SSTATE_MANMACH
SSTATE_MANFILEPREFIX"
-sstate_install[vardeps] += "${SSTATEPOSTINSTFUNCS}"
def sstate_installpkg(ss, d):
from oe.gpg_sign import get_signer
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#203917):
https://lists.openembedded.org/g/openembedded-core/message/203917
Mute This Topic: https://lists.openembedded.org/mt/108159581/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/2] buildhistory: fix package output folder creation
You'd have to test it but I've a patch I've been working on which drops the use of SSTATEPOSTINSTFUNCS from buildhistory entirely. I've just sent that out for review. That might be enough to fix this on the release branches for buildhistory even if it doesn't fix the sstate bug. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#203916): https://lists.openembedded.org/g/openembedded-core/message/203916 Mute This Topic: https://lists.openembedded.org/mt/107750091/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 2/2] buildhistory: Simplify intercept call sites and drop SSTATEPOSTINSTFUNC usage
We planned to drop SSTATEPOSTINSTFUNC some time ago with the introduction of
postfuncs. Finally get around to doing that which should make the buildhistory
code a little more readable.
Signed-off-by: Richard Purdie
---
meta/classes/buildhistory.bbclass | 39 +++
1 file changed, 19 insertions(+), 20 deletions(-)
diff --git a/meta/classes/buildhistory.bbclass
b/meta/classes/buildhistory.bbclass
index bac2abdab0f..ce3abaa69d4 100644
--- a/meta/classes/buildhistory.bbclass
+++ b/meta/classes/buildhistory.bbclass
@@ -47,11 +47,18 @@ BUILDHISTORY_PUSH_REPO ?= ""
BUILDHISTORY_TAG ?= "build"
BUILDHISTORY_PATH_PREFIX_STRIP ?= ""
-SSTATEPOSTINSTFUNCS:append = " buildhistory_emit_pkghistory"
-# We want to avoid influencing the signatures of sstate tasks - first the
function itself:
-sstate_install[vardepsexclude] += "buildhistory_emit_pkghistory"
-# then the value added to SSTATEPOSTINSTFUNCS:
-SSTATEPOSTINSTFUNCS[vardepvalueexclude] .= "| buildhistory_emit_pkghistory"
+# We want to avoid influencing the signatures of the task so use vardepsexclude
+do_populate_sysroot[postfuncs] += "buildhistory_emit_sysroot"
+do_populate_sysroot_setscene[postfuncs] += "buildhistory_emit_sysroot"
+do_populate_sysroot[vardepsexclude] += "buildhistory_emit_sysroot"
+
+do_package[postfuncs] += "buildhistory_list_pkg_files"
+do_package_setscene[postfuncs] += "buildhistory_list_pkg_files"
+do_package[vardepsexclude] += "buildhistory_list_pkg_files"
+
+do_packagedata[postfuncs] += "buildhistory_emit_pkghistory"
+do_packagedata_setscene[postfuncs] += "buildhistory_emit_pkghistory"
+do_packagedata[vardepsexclude] += "buildhistory_emit_pkghistory"
# Similarly for our function that gets the output signatures
SSTATEPOSTUNPACKFUNCS:append = " buildhistory_emit_outputsigs"
@@ -91,27 +98,15 @@ buildhistory_emit_sysroot() {
# Write out metadata about this package for comparison when writing future
packages
#
python buildhistory_emit_pkghistory() {
-if d.getVar('BB_CURRENTTASK') in ['populate_sysroot',
'populate_sysroot_setscene']:
-bb.build.exec_func("buildhistory_emit_sysroot", d)
-return 0
-
-if not "package" in (d.getVar('BUILDHISTORY_FEATURES') or "").split():
-return 0
-
-if d.getVar('BB_CURRENTTASK') in ['package', 'package_setscene']:
-# Create files-in-.txt files containing a list of files
of each recipe's package
-bb.build.exec_func("buildhistory_list_pkg_files", d)
-return 0
-
-if not d.getVar('BB_CURRENTTASK') in ['packagedata',
'packagedata_setscene']:
-return 0
-
import re
import json
import shlex
import errno
import shutil
+if not "package" in (d.getVar('BUILDHISTORY_FEATURES') or "").split():
+return 0
+
pkghistdir = d.getVar('BUILDHISTORY_DIR_PACKAGE')
oldpkghistdir = d.getVar('BUILDHISTORY_OLD_DIR_PACKAGE')
@@ -621,6 +616,10 @@ buildhistory_list_files_no_owners() {
}
buildhistory_list_pkg_files() {
+ if [ "${@bb.utils.contains('BUILDHISTORY_FEATURES', 'package', '1',
'0', d)}" = "0" ] ; then
+ return
+ fi
+
# Create individual files-in-package for each recipe's package
pkgdirlist=$(find ${PKGDEST}/* -maxdepth 0 -type d)
for pkgdir in $pkgdirlist; do
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#203915):
https://lists.openembedded.org/g/openembedded-core/message/203915
Mute This Topic: https://lists.openembedded.org/mt/108159528/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 1/2] insane: Add missing vardepsexclude
If we improve the function dependency visibility in insane.bbclass, it
exposes some dependencies which were previously not seen causing variances
in the do_package_qa task checksums. Update vardepsexclude in a couple of
test cases to ensure the sstate hash selftests pass and the taskhashes
don't vary when we don't expect them too.
Signed-off-by: Richard Purdie
---
meta/classes-global/insane.bbclass | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/classes-global/insane.bbclass
b/meta/classes-global/insane.bbclass
index 4d9543f1e66..32adcc722b3 100644
--- a/meta/classes-global/insane.bbclass
+++ b/meta/classes-global/insane.bbclass
@@ -361,6 +361,7 @@ def package_qa_check_arch(path,name,d, elf):
elif not ((littleendian == elf.isLittleEndian()) or is_bpf):
oe.qa.handle_error("arch", "Endiannes did not match (%d, expected %d)
in %s" % \
(elf.isLittleEndian(), littleendian,
package_qa_clean_path(path, d, name)), d)
+package_qa_check_arch[vardepsexclude] = "DEFAULTTUNE"
QAPATHTEST[desktop] = "package_qa_check_desktop"
def package_qa_check_desktop(path, name, d, elf):
@@ -616,6 +617,7 @@ def check_32bit_symbols(path, packagename, d, elf):
for sym in usedapis:
oe.qa.handle_error('32bit-time', msgformat % sym, d)
oe.qa.handle_error('32bit-time', 'Suppress with INSANE_SKIP =
"32bit-time"', d)
+check_32bit_symbols[vardepsexclude] = "OVERRIDES"
# Check license variables
do_populate_lic[postfuncs] += "populate_lic_qa_checksum"
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#203914):
https://lists.openembedded.org/g/openembedded-core/message/203914
Mute This Topic: https://lists.openembedded.org/mt/108159527/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/2] buildhistory: fix package output folder creation
On Thu, 2024-08-29 at 10:55 +, Pedro Silva Ferreira wrote: > I tried to pickup your patch and make it fit but unsuccessful. Would > this be an alternative only for LTS branches? No, since there are multiple call sites into sstate_install and this therefore only partially fixes the problem. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#203913): https://lists.openembedded.org/g/openembedded-core/message/203913 Mute This Topic: https://lists.openembedded.org/mt/107750091/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 1/2] lz4: Fix static library reproducibility issue
The autobuilder was seeing an intermittent reproducbility issue in lz4 with
regard to symbol ordering in the static library. Add a patch to fix this which
has been submitted upstream.
Fix the SRC_URI whitespace and cleanup the patch directory naming whilst here.
Signed-off-by: Richard Purdie
---
.../lz4/lz4/reproducibility.patch | 33 +++
.../lz4/{files => lz4}/run-ptest | 0
meta/recipes-support/lz4/lz4_1.10.0.bb| 4 +--
3 files changed, 35 insertions(+), 2 deletions(-)
create mode 100644 meta/recipes-support/lz4/lz4/reproducibility.patch
rename meta/recipes-support/lz4/{files => lz4}/run-ptest (100%)
diff --git a/meta/recipes-support/lz4/lz4/reproducibility.patch
b/meta/recipes-support/lz4/lz4/reproducibility.patch
new file mode 100644
index 000..c138986da89
--- /dev/null
+++ b/meta/recipes-support/lz4/lz4/reproducibility.patch
@@ -0,0 +1,33 @@
+lib/Makefile: Fix static library reproducibility
+
+The static library contents varies depending of the order of the object files
on disk meaning
+it isn't reproducible.
+
+To avoid this, use the SRCFILES values which are already sorted, mapped to the
object names
+instead.
+
+
+Upstream-Status: Submitted [https://github.com/lz4/lz4/pull/1497]
+Signed-off-by: Richard Purdie
+
+Index: git/lib/Makefile
+===
+--- git.orig/lib/Makefile
git/lib/Makefile
+@@ -55,6 +55,7 @@ CFLAGS = $(DEBUGFLAGS) $(USERCFLAGS)
+ ALLFLAGS = $(CFLAGS) $(CPPFLAGS) $(LDFLAGS)
+
+ SRCFILES := $(sort $(wildcard *.c))
++OBJFILES = $(SRCFILES:.c=.o)
+
+ include ../Makefile.inc
+
+@@ -102,7 +103,7 @@ liblz4.a: $(SRCFILES)
+ ifeq ($(BUILD_STATIC),yes) # can be disabled on command line
+ @echo compiling static library
+ $(COMPILE.c) $^
+- $(AR) rcs $@ *.o
++ $(AR) rcs $@ $(OBJFILES)
+ endif
+
+ ifeq ($(WINBASED),yes)
diff --git a/meta/recipes-support/lz4/files/run-ptest
b/meta/recipes-support/lz4/lz4/run-ptest
similarity index 100%
rename from meta/recipes-support/lz4/files/run-ptest
rename to meta/recipes-support/lz4/lz4/run-ptest
diff --git a/meta/recipes-support/lz4/lz4_1.10.0.bb
b/meta/recipes-support/lz4/lz4_1.10.0.bb
index 40768fb2925..3b98adf42e5 100644
--- a/meta/recipes-support/lz4/lz4_1.10.0.bb
+++ b/meta/recipes-support/lz4/lz4_1.10.0.bb
@@ -13,8 +13,8 @@ PE = "1"
SRCREV = "ebb370ca83af193212df4dcbadcc5d87bc0de2f0"
SRC_URI = "git://github.com/lz4/lz4.git;branch=release;protocol=https \
- file://run-ptest \
- "
+ file://reproducibility.patch \
+ file://run-ptest"
UPSTREAM_CHECK_GITTAGREGEX = "v(?P.*)"
S = "${WORKDIR}/git"
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#203908):
https://lists.openembedded.org/g/openembedded-core/message/203908
Mute This Topic: https://lists.openembedded.org/mt/108158430/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 2/2] lz4: Disable static libraries again
This option was incorrectly removed in the recent upgrade. We don't use/need
the static library so disable the build of it to save time/disk usage.
Signed-off-by: Richard Purdie
---
meta/recipes-support/lz4/lz4_1.10.0.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-support/lz4/lz4_1.10.0.bb
b/meta/recipes-support/lz4/lz4_1.10.0.bb
index 3b98adf42e5..f77a2e7bb95 100644
--- a/meta/recipes-support/lz4/lz4_1.10.0.bb
+++ b/meta/recipes-support/lz4/lz4_1.10.0.bb
@@ -23,7 +23,7 @@ inherit ptest
CVE_STATUS[CVE-2014-4715] = "fixed-version: Fixed in r118, which is larger
than the current version."
-EXTRA_OEMAKE = "DESTDIR=${D}"
+EXTRA_OEMAKE = "DESTDIR=${D} BUILD_STATIC=no"
do_install() {
oe_runmake install
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#203909):
https://lists.openembedded.org/g/openembedded-core/message/203909
Mute This Topic: https://lists.openembedded.org/mt/108158431/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] sysvinit: upgrade 3.04 -> 3.10
On Mon, 2024-08-26 at 12:01 -0700, Sven Reschke via lists.openembedded.org wrote: > Hi Alex and Alexandre, > > sorry for the delay. > I've created a PR on Github on top of your latest changes: > https://github.com/Nanowires/oe-core-clone/pull/1 I did try this on our automated testing and there were some issues: musl build failures: https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/9440/steps/11/logs/stdio https://autobuilder.yoctoproject.org/typhoon/#/builders/45/builds/9456/steps/11/logs/stdio systemd+sysvinit build failure: https://autobuilder.yoctoproject.org/typhoon/#/builders/72/builds/9431/steps/25/logs/stdio Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#203905): https://lists.openembedded.org/g/openembedded-core/message/203905 Mute This Topic: https://lists.openembedded.org/mt/107960881/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 2/2] insane: Allow ERROR_QA to use 'contains' hash optimisations for do_package_qa
We want ERROR_QA to operate using the "contains" optimizations which means
accessing the variable only using the contains function.
To do this, remove usage of ALL_QA, open coding the few references to check
both WARN_QA and ERROR_QA.
Move the function table generation to a separate function where we can exclude
the ERROR_QA and WARN_QA variables since they are handled by the handle_error()
function calls.
Ensure all the chain of functions to the handle_error calls is correctly
recognised in the variable dependencies.
Signed-off-by: Richard Purdie
---
meta/classes-global/insane.bbclass | 64 +++---
1 file changed, 33 insertions(+), 31 deletions(-)
diff --git a/meta/classes-global/insane.bbclass
b/meta/classes-global/insane.bbclass
index 7ef2ffcc8b3..7f84cd2cd5b 100644
--- a/meta/classes-global/insane.bbclass
+++ b/meta/classes-global/insane.bbclass
@@ -54,8 +54,6 @@ FAKEROOT_QA = "host-user-contaminated"
FAKEROOT_QA[doc] = "QA tests which need to run under fakeroot. If any \
enabled tests are listed here, the do_package_qa task will run under fakeroot."
-ALL_QA = "${WARN_QA} ${ERROR_QA}"
-
UNKNOWN_CONFIGURE_OPT_IGNORE ?= "--enable-nls --disable-nls
--disable-silent-rules --disable-dependency-tracking --disable-static"
# This is a list of directories that are expected to be empty.
@@ -1081,6 +1079,25 @@ def package_qa_check_missing_update_alternatives(pn, d):
if d.getVar('ALTERNATIVE:%s' % pkg) and not
bb.data.inherits_class('update-alternatives', d):
oe.qa.handle_error("missing-update-alternatives", "%s: recipe
defines ALTERNATIVE:%s but doesn't inherit update-alternatives. This might fail
during do_rootfs later!" % (pn, pkg), d)
+def parse_test_matrix(matrix_name):
+testmatrix = d.getVarFlags(matrix_name) or {}
+g = globals()
+checks = []
+for w in (d.getVar("WARN_QA") or "").split():
+if w in skip:
+ continue
+if w in testmatrix and testmatrix[w] in g:
+checks.append(g[testmatrix[w]])
+
+for e in (d.getVar("ERROR_QA") or "").split():
+if e in skip:
+ continue
+if e in testmatrix and testmatrix[e] in g:
+checks.append(g[testmatrix[e]])
+return checks
+parse_test_matrix[vardepsexclude] = "ERROR_QA WARN_QA"
+
+
# The PACKAGE FUNC to scan each package
python do_package_qa () {
import subprocess
@@ -1136,23 +1153,6 @@ python do_package_qa () {
for dep in taskdepdata:
taskdeps.add(taskdepdata[dep][0])
-def parse_test_matrix(matrix_name):
-testmatrix = d.getVarFlags(matrix_name) or {}
-g = globals()
-checks = []
-for w in (d.getVar("WARN_QA") or "").split():
-if w in skip:
- continue
-if w in testmatrix and testmatrix[w] in g:
-checks.append(g[testmatrix[w]])
-
-for e in (d.getVar("ERROR_QA") or "").split():
-if e in skip:
- continue
-if e in testmatrix and testmatrix[e] in g:
-checks.append(g[testmatrix[e]])
-return checks
-
for package in packages:
skip = set((d.getVar('INSANE_SKIP') or "").split() +
(d.getVar('INSANE_SKIP:' + package) or "").split())
@@ -1179,8 +1179,7 @@ python do_package_qa () {
for func in checks:
func(pn, d)
-if 'libdir' in d.getVar("ALL_QA").split():
-package_qa_check_libdir(d)
+package_qa_check_libdir(d)
oe.qa.exit_if_errors(d)
}
@@ -1198,6 +1197,10 @@ python() {
pkgs = (d.getVar('PACKAGES') or '').split()
for pkg in pkgs:
d.appendVarFlag("do_package_qa", "vardeps", "
INSANE_SKIP:{}".format(pkg))
+funcs = d.getVarFlags("QAPATHTEST")
+funcs.update(d.getVarFlags("QAPKGTEST"))
+funcs.update(d.getVarFlags("QARECIPETEST"))
+d.appendVarFlag("do_package_qa", "vardeps", " ".join(funcs.values()))
}
SSTATETASKS += "do_package_qa"
@@ -1295,7 +1298,9 @@ python do_qa_patch() {
return False
srcdir = d.getVar('S')
-if not bb.utils.contains('DISTRO_FEATURES', 'ptest', True, False, d) or
not bb.utils.contains('ALL_QA', 'unimplemented-ptest', True, False, d):
+if not bb.utils.contains('DISTRO_FEATURES', 'ptest', True, False, d):
+pass
+elif not (bb.utils.contains('ERROR_QA', 'unimplemented-ptest', True,
False, d) or bb.utils.contains('WARN_QA', 'unimplemented-ptest',
[OE-core] [PATCH 1/2] insane: Further simplify code
Now handle_error is used, we can further simplify the QA test execution
as we don't need seperate function lists for warnings and errors.
Signed-off-by: Richard Purdie
---
meta/classes-global/insane.bbclass | 41 ++
1 file changed, 14 insertions(+), 27 deletions(-)
diff --git a/meta/classes-global/insane.bbclass
b/meta/classes-global/insane.bbclass
index c664a86b41c..7ef2ffcc8b3 100644
--- a/meta/classes-global/insane.bbclass
+++ b/meta/classes-global/insane.bbclass
@@ -780,21 +780,12 @@ def qa_check_staged(path,d):
if not skip_shebang_size:
package_qa_check_shebang_size(path, "", d, None, errors)
-
-
-# Run all recipe-wide warnfuncs and errorfuncs
-def package_qa_recipe(warnfuncs, errorfuncs, pn, d):
-for func in warnfuncs:
-func(pn, d)
-for func in errorfuncs:
-func(pn, d)
-
def prepopulate_objdump_p(elf, d):
output = elf.run_objdump("-p", d)
return (elf.name, output)
# Walk over all files in a directory and call func
-def package_qa_walk(warnfuncs, errorfuncs, package, d):
+def package_qa_walk(checkfuncs, package, d):
elves = {}
for path in pkgfiles[package]:
elf = None
@@ -815,9 +806,7 @@ def package_qa_walk(warnfuncs, errorfuncs, package, d):
for path in pkgfiles[package]:
if path in elves:
elves[path].open()
-for func in warnfuncs:
-func(path, package, d, elves.get(path))
-for func in errorfuncs:
+for func in checkfuncs:
func(path, package, d, elves.get(path))
if path in elves:
elves[path].close()
@@ -1005,7 +994,7 @@ def package_qa_check_unlisted_pkg_lics(package, d):
"listed in LICENSE" % (package, '
'.join(unlisted)), d)
obsolete = set(oe.license.obsolete_license_list()) & package_lics -
recipe_lics_set
if obsolete:
-oe.qa.handle_error(messages, "obsolete-license",
+oe.qa.handle_error("obsolete-license",
"LICENSE:%s includes obsolete licenses %s" %
(package, ' '.join(obsolete)), d)
QAPKGTEST[empty-dirs] = "package_qa_check_empty_dirs"
@@ -1150,20 +1139,19 @@ python do_package_qa () {
def parse_test_matrix(matrix_name):
testmatrix = d.getVarFlags(matrix_name) or {}
g = globals()
-warnchecks = []
+checks = []
for w in (d.getVar("WARN_QA") or "").split():
if w in skip:
continue
if w in testmatrix and testmatrix[w] in g:
-warnchecks.append(g[testmatrix[w]])
+checks.append(g[testmatrix[w]])
-errorchecks = []
for e in (d.getVar("ERROR_QA") or "").split():
if e in skip:
continue
if e in testmatrix and testmatrix[e] in g:
-errorchecks.append(g[testmatrix[e]])
-return warnchecks, errorchecks
+checks.append(g[testmatrix[e]])
+return checks
for package in packages:
skip = set((d.getVar('INSANE_SKIP') or "").split() +
@@ -1177,20 +1165,19 @@ python do_package_qa () {
oe.qa.handle_error("pkgname",
"%s doesn't match the [a-z0-9.+-]+ regex" % package, d)
-warn_checks, error_checks = parse_test_matrix("QAPATHTEST")
-package_qa_walk(warn_checks, error_checks, package, d)
+checks = parse_test_matrix("QAPATHTEST")
+package_qa_walk(checks, package, d)
-warn_checks, error_checks = parse_test_matrix("QAPKGTEST")
-for func in warn_checks:
-func(package, d)
-for func in error_checks:
+checks = parse_test_matrix("QAPKGTEST")
+for func in checks:
func(package, d)
package_qa_check_rdepends(package, pkgdest, skip, taskdeps, packages,
d)
package_qa_check_deps(package, pkgdest, d)
-warn_checks, error_checks = parse_test_matrix("QARECIPETEST")
-package_qa_recipe(warn_checks, error_checks, pn, d)
+checks = parse_test_matrix("QARECIPETEST")
+for func in checks:
+func(pn, d)
if 'libdir' in d.getVar("ALL_QA").split():
package_qa_check_libdir(d)
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#203895):
https://lists.openembedded.org/g/openembedded-core/message/203895
Mute This Topic: https://lists.openembedded.org/mt/108150251/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 1/2] lib/oe: Use new visitorcode functionality for qa.handle_error()
Early functions like do_recipe_qa (which do_fetch depends upon) reference
oe.qa.handle_error() which in turn adds dependencies on ERROR_QA and
WARN_QA. This means that ERROR_QA:append = " nothing" will cause
literally everything to rebuild and break sstate reuse.
Take advantage of new bitbake functionality to add a custom visitorcode
function to handle_error which optimises the references into contains
expressions which means the ERROR_QA and WARN_QA references are optmised
to containing specific strings. This dramatically improves sstate reuse.
The qa module has to be imported first since other code in later modules
references it and bitbake can't handle the dependency ordering internally
without a lot of unwanted complexity.
Signed-off-by: Richard Purdie
---
meta/lib/oe/__init__.py | 6 --
meta/lib/oe/qa.py | 16
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/meta/lib/oe/__init__.py b/meta/lib/oe/__init__.py
index 6eb536ad284..d7604812834 100644
--- a/meta/lib/oe/__init__.py
+++ b/meta/lib/oe/__init__.py
@@ -7,6 +7,8 @@
from pkgutil import extend_path
__path__ = extend_path(__path__, __name__)
-BBIMPORTS = ["data", "path", "utils", "types", "package", "packagedata", \
+# Modules with vistorcode need to go first else anything depending on them
won't be
+# processed correctly (e.g. qa)
+BBIMPORTS = ["qa", "data", "path", "utils", "types", "package", "packagedata",
\
"packagegroup", "sstatesig", "lsb", "cachedpath", "license", \
- "qa", "reproducible", "rust", "buildcfg", "go"]
+ "reproducible", "rust", "buildcfg", "go"]
diff --git a/meta/lib/oe/qa.py b/meta/lib/oe/qa.py
index f8ae3c743ff..2f928804447 100644
--- a/meta/lib/oe/qa.py
+++ b/meta/lib/oe/qa.py
@@ -4,6 +4,7 @@
# SPDX-License-Identifier: GPL-2.0-only
#
+import ast
import os, struct, mmap
class NotELFFileError(Exception):
@@ -186,6 +187,20 @@ def write_error(type, error, d):
with open(logfile, "a+") as f:
f.write("%s: %s [%s]\n" % (p, error, type))
+def handle_error_visitorcode(name, args):
+execs = set()
+contains = {}
+warn = None
+if isinstance(args[0], ast.Constant) and isinstance(args[0].value, str):
+for i in ["ERROR_QA", "WARN_QA"]:
+if i not in contains:
+contains[i] = set()
+contains[i].add(args[0].value)
+else:
+warn = args[0]
+execs.add(name)
+return contains, execs, warn
+
def handle_error(error_class, error_msg, d):
if error_class in (d.getVar("ERROR_QA") or "").split():
write_error(error_class, error_msg, d)
@@ -198,6 +213,7 @@ def handle_error(error_class, error_msg, d):
else:
bb.note("QA Issue: %s [%s]" % (error_msg, error_class))
return True
+handle_error.visitorcode = handle_error_visitorcode
def add_message(messages, section, new_msg):
if section not in messages:
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#203886):
https://lists.openembedded.org/g/openembedded-core/message/203886
Mute This Topic: https://lists.openembedded.org/mt/108146168/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 2/2] insane: Optimise ERROR_QA/WARN_QA references in do_populate_sysroot
The new contains code can't inspect variable references in handle_error()
calls. Expand what is effectively a hardcoded reference anyway so the code
can optimise it.
Signed-off-by: Richard Purdie
---
meta/classes-global/insane.bbclass | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/meta/classes-global/insane.bbclass
b/meta/classes-global/insane.bbclass
index 6a84c4aa74d..a008f21c6ee 100644
--- a/meta/classes-global/insane.bbclass
+++ b/meta/classes-global/insane.bbclass
@@ -789,9 +789,8 @@ def qa_check_staged(path,d):
if not skip_shebang_size:
errors = {}
package_qa_check_shebang_size(path, "", d, None, errors)
-for e in errors:
-oe.qa.handle_error(e, errors[e], d)
-
+if "shebang-size" in errors:
+oe.qa.handle_error("shebang-size", errors["shebang-size"],
d)
# Run all package-wide warnfuncs and errorfuncs
def package_qa_package(warnfuncs, errorfuncs, package, d):
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#203887):
https://lists.openembedded.org/g/openembedded-core/message/203887
Mute This Topic: https://lists.openembedded.org/mt/108146169/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] insane: Drop oe.qa.add_message usage
Drop the oe.qa.add_message() usage in favour of oe.qa.handle_error() which has
code allowing it to be optimised with contains usage.
The patch also drops unused return values which we stopped using a while ago
and drops the now unneeded function parameters, generally leading to cleaner
code.
The code should be functionally equivalent.
Signed-off-by: Richard Purdie
---
meta/classes-global/insane.bbclass | 219 +++--
meta/lib/oe/qa.py | 6 -
2 files changed, 84 insertions(+), 141 deletions(-)
diff --git a/meta/classes-global/insane.bbclass
b/meta/classes-global/insane.bbclass
index a008f21c6ee..3094197804e 100644
--- a/meta/classes-global/insane.bbclass
+++ b/meta/classes-global/insane.bbclass
@@ -83,7 +83,7 @@ def package_qa_clean_path(path, d, pkg=None):
return path.replace(d.getVar("TMPDIR"), "/").replace("//", "/")
QAPATHTEST[shebang-size] = "package_qa_check_shebang_size"
-def package_qa_check_shebang_size(path, name, d, elf, messages):
+def package_qa_check_shebang_size(path, name, d, elf):
import stat
if os.path.islink(path) or stat.S_ISFIFO(os.stat(path).st_mode) or elf:
return
@@ -102,25 +102,23 @@ def package_qa_check_shebang_size(path, name, d, elf,
messages):
return
if len(stanza) > 129:
-oe.qa.add_message(messages, "shebang-size", "%s: %s maximum
shebang size exceeded, the maximum size is 128." % (name,
package_qa_clean_path(path, d, name)))
+oe.qa.handle_error("shebang-size", "%s: %s maximum shebang size
exceeded, the maximum size is 128." % (name, package_qa_clean_path(path, d,
name)), d)
return
QAPATHTEST[libexec] = "package_qa_check_libexec"
-def package_qa_check_libexec(path,name, d, elf, messages):
+def package_qa_check_libexec(path,name, d, elf):
# Skip the case where the default is explicitly /usr/libexec
libexec = d.getVar('libexecdir')
if libexec == "/usr/libexec":
-return True
+return
if 'libexec' in path.split(os.path.sep):
-oe.qa.add_message(messages, "libexec", "%s: %s is using libexec please
relocate to %s" % (name, package_qa_clean_path(path, d, name), libexec))
-return False
-
-return True
+oe.qa.handle_error("libexec", "%s: %s is using libexec please relocate
to %s" % (name, package_qa_clean_path(path, d, name), libexec), d)
+return
QAPATHTEST[rpaths] = "package_qa_check_rpath"
-def package_qa_check_rpath(file,name, d, elf, messages):
+def package_qa_check_rpath(file,name, d, elf):
"""
Check for dangerous RPATHs
"""
@@ -142,10 +140,10 @@ def package_qa_check_rpath(file,name, d, elf, messages):
rpath = m.group(1)
for dir in bad_dirs:
if dir in rpath:
-oe.qa.add_message(messages, "rpaths", "package %s contains
bad RPATH %s in file %s" % (name, rpath, file))
+oe.qa.handle_error("rpaths", "package %s contains bad
RPATH %s in file %s" % (name, rpath, file), d)
QAPATHTEST[useless-rpaths] = "package_qa_check_useless_rpaths"
-def package_qa_check_useless_rpaths(file, name, d, elf, messages):
+def package_qa_check_useless_rpaths(file, name, d, elf):
"""
Check for RPATHs that are useless but not dangerous
"""
@@ -172,31 +170,31 @@ def package_qa_check_useless_rpaths(file, name, d, elf,
messages):
if rpath_eq(rpath, libdir) or rpath_eq(rpath, base_libdir):
# The dynamic linker searches both these places anyway. There
is no point in
# looking there again.
-oe.qa.add_message(messages, "useless-rpaths", "%s: %s contains
probably-redundant RPATH %s" % (name, package_qa_clean_path(file, d, name),
rpath))
+oe.qa.handle_error("useless-rpaths", "%s: %s contains
probably-redundant RPATH %s" % (name, package_qa_clean_path(file, d, name),
rpath), d)
QAPATHTEST[dev-so] = "package_qa_check_dev"
-def package_qa_check_dev(path, name, d, elf, messages):
+def package_qa_check_dev(path, name, d, elf):
"""
Check for ".so" library symlinks in non-dev packages
"""
if not name.endswith("-dev") and not name.endswith("-dbg") and not
name.endswith("-ptest") and not name.startswith("nativesdk-") and
path.endswith(".so") and os.path.islink(path):
-oe.qa.add_message(messages, "dev-so", "non -dev/-dbg/nativesdk-
package %s contains symlink .so '%s'" % \
- (name, package_qa_clean_path(pa
[OE-core] [PATCH 2/2] insane: Optimise ERROR_QA/WARN_QA references in do_populate_sysroot
The new contains code can't inspect variable references in handle_error()
calls. Expand what is effectively a hardcoded reference anyway so the code
can optimise it.
Signed-off-by: Richard Purdie
---
meta/classes-global/insane.bbclass | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/meta/classes-global/insane.bbclass
b/meta/classes-global/insane.bbclass
index 6a84c4aa74d..a008f21c6ee 100644
--- a/meta/classes-global/insane.bbclass
+++ b/meta/classes-global/insane.bbclass
@@ -789,9 +789,8 @@ def qa_check_staged(path,d):
if not skip_shebang_size:
errors = {}
package_qa_check_shebang_size(path, "", d, None, errors)
-for e in errors:
-oe.qa.handle_error(e, errors[e], d)
-
+if "shebang-size" in errors:
+oe.qa.handle_error("shebang-size", errors["shebang-size"],
d)
# Run all package-wide warnfuncs and errorfuncs
def package_qa_package(warnfuncs, errorfuncs, package, d):
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#203881):
https://lists.openembedded.org/g/openembedded-core/message/203881
Mute This Topic: https://lists.openembedded.org/mt/108140368/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 1/2] lib/oe: Use new visitorcode functionality for qa.handle_error()
Early functions like do_recipe_qa (which do_fetch depends upon) reference
oe.qa.handle_error() which in turn adds dependencies on ERROR_QA and
WARN_QA. This means that ERROR_QA:append = " nothing" will cause
literally everything to rebuild and break sstate reuse.
Take advantage of new bitbake functionality to add a custom visitorcode
function to handle_error which optimises the references into contains
expressions which means the ERROR_QA and WARN_QA references are optmised
to containing specific strings. This dramatically improves sstate reuse.
The qa module has to be imported first since other code in later modules
references it and bitbake can't handle the dependency ordering internally
without a lot of unwanted complexity.
Signed-off-by: Richard Purdie
---
meta/lib/oe/__init__.py | 6 --
meta/lib/oe/qa.py | 11 +++
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/meta/lib/oe/__init__.py b/meta/lib/oe/__init__.py
index 6eb536ad284..d7604812834 100644
--- a/meta/lib/oe/__init__.py
+++ b/meta/lib/oe/__init__.py
@@ -7,6 +7,8 @@
from pkgutil import extend_path
__path__ = extend_path(__path__, __name__)
-BBIMPORTS = ["data", "path", "utils", "types", "package", "packagedata", \
+# Modules with vistorcode need to go first else anything depending on them
won't be
+# processed correctly (e.g. qa)
+BBIMPORTS = ["qa", "data", "path", "utils", "types", "package", "packagedata",
\
"packagegroup", "sstatesig", "lsb", "cachedpath", "license", \
- "qa", "reproducible", "rust", "buildcfg", "go"]
+ "reproducible", "rust", "buildcfg", "go"]
diff --git a/meta/lib/oe/qa.py b/meta/lib/oe/qa.py
index f8ae3c743ff..2c558673701 100644
--- a/meta/lib/oe/qa.py
+++ b/meta/lib/oe/qa.py
@@ -199,6 +199,17 @@ def handle_error(error_class, error_msg, d):
bb.note("QA Issue: %s [%s]" % (error_msg, error_class))
return True
+handle_error.visitorcode = """
+if isinstance(args[0], ast.Constant) and isinstance(args[0].value, str):
+for i in ["ERROR_QA", "WARN_QA"]:
+if i not in self.contains:
+self.contains[i] = set()
+self.contains[i].add(args[0].value)
+else:
+self.warn(node.func, args[0])
+self.execs.add(name)
+"""
+
def add_message(messages, section, new_msg):
if section not in messages:
messages[section] = new_msg
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#203880):
https://lists.openembedded.org/g/openembedded-core/message/203880
Mute This Topic: https://lists.openembedded.org/mt/108140367/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] Unexpected behavior with class-native and class-target in combination with inherit(_defer)
On Wed, 2024-08-28 at 09:40 +, Jasper Orschulko via lists.openembedded.org
wrote:
> we are on the latest scarthgap and trying to use class-target to do
> target specific overrides, as described in
> https://docs.yoctoproject.org/4.0.20/singleindex.html#native.
>
> We tried removing python from PACKAGECONFIG:class-target. However, this
> breaks the native build of libxml2.
>
> This is due to the following inherit_defer statement not being called
> on native:
> https://github.com/yoctoproject/poky/blob/cf9d8807f80c5715daed11b5bcbb4378dcbcbd54/meta/recipes-core/libxml/libxml2_2.12.8.bb#L39
>
> We were able to reproduce this with a minimal example consisting of a
> .bb file and a .bbclass file:
>
>
> test.bb:
> ```
> SUMMARY = "Test"
> LICENSE = "CLOSED"
> LIC_FILES_CHKSUM = ""
>
> SOMEVAR = "foo bar"
> SOMEVAR:remove:class-target = "bar"
>
> inherit_defer ${@bb.utils.contains('SOMEVAR', 'bar', 'testclass', '',
> d)}
>
> do_install() {
> install -d ${D}/test/
> echo "Value SOMEVAR: ${SOMEVAR}" >> ${D}/test/output
> echo "Value TESTCLASSVAR: ${TESTCLASSVAR}" >> ${D}/test/output
> echo "SOMEVAR contains 'foo'? ${@bb.utils.contains('SOMEVAR',
> 'foo', 'true', 'false', d)}" >> ${D}/test/output
> echo "SOMEVAR contains 'bar'? ${@bb.utils.contains('SOMEVAR',
> 'bar', 'true', 'false', d)}" >> ${D}/test/output
> }
>
> FILES:${PN} += "/test/output"
>
> BBCLASSEXTEND = "native"
> ```
>
> and testclass.bbclass:
> ```
> TESTCLASSVAR = "foobar"
> ```
>
> We would expect that the inherit is executed for native, but not for
> target, thus the variable TESTCLASSVAR to be set in native. However,
> inherit is not called for either of them, as seen in the test output:
>
> Target:
> ```
> Value SOMEVAR: foo
> Value TESTCLASSVAR:
> SOMEVAR contains 'foo'? true
> SOMEVAR contains 'bar'? false
> ```
>
> Native:
> ```
> Value SOMEVAR: foo bar
> Value TESTCLASSVAR:
> SOMEVAR contains 'foo'? true
> SOMEVAR contains 'bar'? true
> ```
>
> Vice versa, when removing from class-native the inherit statement is
> always called, not only on the target as we would expect.
>
> Is this a known limitation or a bug?
It is a known rather annoying limitation of inherit_defer :(
The trouble is that BBCLASSEXTEND = "native" is also something which
happens at the end of parsing. The expansion of inherit_defer happens
before BBCLASSEXTEND. You can't really swap them since native and other
extensions are meant to happen last. This means overrides that come
from the BBCLASSEXTEND don't function when used with inherit_defer.
Something always has to come last and I'm not sure what we can do to
improve this.
I did wonder about adding logic to set the class override earlier
somehow but it is hard to make work reliably for all cases.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#203879):
https://lists.openembedded.org/g/openembedded-core/message/203879
Mute This Topic: https://lists.openembedded.org/mt/108139065/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 2/2] rust: Upgrade 1.78.0->1.79.0
On Tue, 2024-08-27 at 22:38 +0200, Alexander Kanavin wrote: > On Tue, 27 Aug 2024 at 21:51, Richard Purdie > wrote: > > > Shouldn't rust complain if it doesn't work with old compilers? Are > > the > > compiler requirements for rust documented anywhere? I'm reluctant > > to > > throw buildtools at anything that breaks. In theory we also would > > need > > to change the sanity.bbclass compiler versions tests and so on too > > :/ > > The specific error seems to be about libz-sys, which carries a copy > of > zlib and that is built using host gcc - I suspect that somehow alma9 > gcc is used incorrectly there. This could be a problem on our side, > I'd need to first try building cargo 1.79.0 directly on alma9 and see > if that breaks too in the same way, or not. Don't have any more time > to look into it today. The failure is building cargo-native iirc so using the host gcc would be expected there? Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#203862): https://lists.openembedded.org/g/openembedded-core/message/203862 Mute This Topic: https://lists.openembedded.org/mt/108090372/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 2/2] rust: Upgrade 1.78.0->1.79.0
On Tue, 2024-08-27 at 19:16 +0200, Alexander Kanavin wrote: > On Tue, 27 Aug 2024 at 18:25, Alexander Kanavin via > lists.openembedded.org > > wrote: > > > > On Tue, 27 Aug 2024 at 18:23, Alexander Kanavin via > > lists.openembedded.org > > > > wrote: > > > I just reproduced this on autobuilder's alma9 in a private build > > > without sstate. I don't have any immediate ideas on where to > > > start > > > looking into it, but I left the build in place, so if any of you > > > can > > > suggest experiments or things to look at, I'd be glad to help. > > > > Oh, and I immediately got an idea after hitting 'send' :) > > > > [akanavin@alma9-ty-2 build]$ gcc --version > > gcc (GCC) 11.4.1 20231218 (Red Hat 11.4.1-3) > > > > I'm going to try again, with buildtools-tarball. It may be that red > > hat compiler is 'too old' anymore for rust. > > ... and this worked. So the easiest way out is to update alma9 config > to use buildtools. Shouldn't rust complain if it doesn't work with old compilers? Are the compiler requirements for rust documented anywhere? I'm reluctant to throw buildtools at anything that breaks. In theory we also would need to change the sanity.bbclass compiler versions tests and so on too :/ Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#203859): https://lists.openembedded.org/g/openembedded-core/message/203859 Mute This Topic: https://lists.openembedded.org/mt/108090372/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/2] buildhistory: fix package output folder creation
On Tue, 2024-08-27 at 12:50 +, Pedro Silva Ferreira wrote: > Hi Steve and Richard, > > I tried to backport locally patches [4] and [5] to kirkstone and > scarthgap but i ran into some issues related to sstate.bbclass. After > some investigation i saw that i was missing a patch done by Richard > [3] in the context of this buildhistory change but after applying the > patch [3], due to the `interceptfuncs` logic i ran into an undefined > variable (SSTATE_INSTDIR) while executing `bb.utils.rename` helper > function. Applying patch [1] and [2] in combination with [3] , [4] > and [5] seems to do the job but im not really sure if patch [1] and > [2] can be backported to lts branches since they remove some > features/class that might be used by other components that I am not > aware of. I tested this with ncurses recipe and with core-image- > minimal. > > 1: siteconfig: Drop siteconfig class/code/support > f3766dc038f7ba9780ddaf5eb8d27385ea31d7d0 > 2: sstate: Drop intercept functions support > cfbfd0b2e89eb71783c55a1be4a7e63e6cd82c2f We definitely can't backport those. > 3: sstate/buildhistory: Fix plaindirs handling to occur before > SSTATEPOSTINSTFUNCS > 62ee349cf18532dac8736488752c00e89de78fcd We'd probably need to find a way to make that change and continue to work with the intercept functions :/. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#203844): https://lists.openembedded.org/g/openembedded-core/message/203844 Mute This Topic: https://lists.openembedded.org/mt/107750091/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 2/2] rust: Upgrade 1.78.0->1.79.0
On Tue, 2024-08-27 at 18:17 +0530, Yash Shinde via lists.openembedded.org wrote: > > On 27-08-2024 18:10, Richard Purdie wrote: > > CAUTION: This email comes from a non Wind River email account! > > Do not click links or open attachments unless you recognize the > > sender and know the content is safe. > > > > On Tue, 2024-08-27 at 14:24 +0200, Alexander Kanavin wrote: > > > > The error log says: > > > > > > > > stdio: ERROR: cargo-native-1.79.0-r0 do_compile: Execution of > > > > '/home/pokybuild/yocto- > > > > worker/qemuarm64/build/build/tmp/work/x86_64-linux/cargo- > > > > native/1.79.0/temp/run.do_compile.1874995' failed with exit > > > > code 101 > > > > stdio: ERROR: Logfile of failure stored in: > > > > /home/pokybuild/yocto- > > > > worker/qemuarm64/build/build/tmp/work/x86_64-linux/cargo- > > > > native/1.79.0/temp/log.do_compile.1874995 > > > > stdio: ERROR: Task (virtual:native:/home/pokybuild/yocto- > > > > worker/qemuarm64/build/meta/recipes- > > > > devtools/rust/cargo_1.79.0.bb:do_compile) failed with exit code > > > > '1' > > > > > > > > stdio: ERROR: Command . ./oe-init-build-env; bitbake core- > > > > image-sato core-image-sato-sdk core-image-minimal core-image- > > > > minimal-dev core-image-full-cmdline core-image- > > > > sato:do_populate_sdk core-image-minimal:do_populate_sdk_ext > > > > core-image-sato:do_populate_sdk_ext -k failed with exit code 1, > > > > see errors above. (1724719291.3: 11079.3) > > > > > > > > I checked "bitbake cargo -c do_compile", "core-image- > > > > minimal:do_populate_sdk" and core-image-sato:do_populate_sdk > > > > and all passed successfully. > > > > > > > > The build cmd has many core-image minimal and sato build cmds. > > > > Could you please help me to point out which of these exactly > > > > cause the issue? > > > The key error is at line 22936: > > > > > > error: linking with > > > `/home/pokybuild/yocto- > > > worker/qemuarm64/build/build/tmp/work/x86_64-linux/cargo- > > > native/1.79.0/wrapper/target-rust-ccld` > > > failed: exit status: 1 > > > > = note: LC_ALL="C" > > > PATH="/home/pokybuild/yocto- > > > worker/qemuarm64/build/build/tmp/work/x86_64-linux/cargo- > > > native/1.79.0/recipe-sysroot-native/usr/lib/rustlib/x86_64- > > > unknown-linux-gnu/bin:/home/pokybuild/yocto- > > > worker/qemuarm64/build/scripts/native- > > > intercept:/home/pokybuild/yocto- > > > worker/qemuarm64/build/build/tmp/sysroots-uninative/x86_64- > > > linux/usr/bin:/home/pokybuild/yocto- > > > worker/qemuarm64/build/build/tmp/work/x86_64-linux/cargo- > > > native/1.79.0/recipe-sysroot-native/usr/bin/python3- > > > native:/home/pokybuild/yocto- > > > worker/qemuarm64/build/scripts:/home/pokybuild/yocto- > > > worker/qemuarm64/build/build/tmp/work/x86_64-linux/cargo- > > > native/1.79.0/recipe-sysroot-native/usr/bin/x86_64- > > > linux:/home/pokybuild/yocto- > > > worker/qemuarm64/build/build/tmp/work/x86_64-linux/cargo- > > > native/1.79.0/recipe-sysroot- > > > native/usr/bin:/home/pokybuild/yocto- > > > worker/qemuarm64/build/build/tmp/work/x86_64-linux/cargo- > > > native/1.79.0/recipe-sysroot- > > > native/usr/sbin:/home/pokybuild/yocto- > > > worker/qemuarm64/build/build/tmp/work/x86_64-linux/cargo- > > > native/1.79.0/recipe-sysroot- > > > native/usr/bin:/home/pokybuild/yocto- > > > worker/qemuarm64/build/build/tmp/work/x86_64-linux/cargo- > > > native/1.79.0/recipe-sysroot-native/sbin:/home/pokybuild/yocto- > > > worker/qemuarm64/build/build/tmp/work/x86_64-linux/cargo- > > > native/1.79.0/recipe-sysroot-native/bin:/home/pokybuild/yocto- > > > worker/qemuarm64/build/bitbake/bin:/home/pokybuild/yocto- > > > worker/qemuarm64/build/build/tmp/hosttools" > > > VSLANG="1033" "/home/pokybuild/yocto- > > > worker/qemuarm64/build/build/tmp/work/x86_64-linux/cargo- > > > native/1.79.0/wrapper/target-rust-ccld" > > > "-m64" "/tmp/rustcgeGK7l/symbols.o" > > > "/home/pokybuild/yocto- > > > worker/qemuarm64/build/build/tmp/work/x86_64-linux/cargo- > > > native/1.79.0/build/target/release/build/cargo- > > > 559f5ce7ae478850/build_script_build- > > > 55
Re: [OE-core] [PATCH 2/2] rust: Upgrade 1.78.0->1.79.0
On Tue, 2024-08-27 at 14:24 +0200, Alexander Kanavin wrote: > > The error log says: > > > > stdio: ERROR: cargo-native-1.79.0-r0 do_compile: Execution of > > '/home/pokybuild/yocto-worker/qemuarm64/build/build/tmp/work/x86_64-linux/cargo-native/1.79.0/temp/run.do_compile.1874995' > > failed with exit code 101 > > stdio: ERROR: Logfile of failure stored in: > > /home/pokybuild/yocto-worker/qemuarm64/build/build/tmp/work/x86_64-linux/cargo-native/1.79.0/temp/log.do_compile.1874995 > > stdio: ERROR: Task > > (virtual:native:/home/pokybuild/yocto-worker/qemuarm64/build/meta/recipes-devtools/rust/cargo_1.79.0.bb:do_compile) > > failed with exit code '1' > > > > stdio: ERROR: Command . ./oe-init-build-env; bitbake core-image-sato > > core-image-sato-sdk core-image-minimal core-image-minimal-dev > > core-image-full-cmdline core-image-sato:do_populate_sdk > > core-image-minimal:do_populate_sdk_ext > > core-image-sato:do_populate_sdk_ext -k failed with exit code 1, see errors > > above. (1724719291.3: 11079.3) > > > > I checked "bitbake cargo -c do_compile", > > "core-image-minimal:do_populate_sdk" and core-image-sato:do_populate_sdk > > and all passed successfully. > > > > The build cmd has many core-image minimal and sato build cmds. > > Could you please help me to point out which of these exactly cause the > > issue? > > The key error is at line 22936: > > error: linking with > `/home/pokybuild/yocto-worker/qemuarm64/build/build/tmp/work/x86_64-linux/cargo-native/1.79.0/wrapper/target-rust-ccld` > failed: exit status: 1 > > > > > = note: LC_ALL="C" > PATH="/home/pokybuild/yocto-worker/qemuarm64/build/build/tmp/work/x86_64-linux/cargo-native/1.79.0/recipe-sysroot-native/usr/lib/rustlib/x86_64-unknown-linux-gnu/bin:/home/pokybuild/yocto-worker/qemuarm64/build/scripts/native-intercept:/home/pokybuild/yocto-worker/qemuarm64/build/build/tmp/sysroots-uninative/x86_64-linux/usr/bin:/home/pokybuild/yocto-worker/qemuarm64/build/build/tmp/work/x86_64-linux/cargo-native/1.79.0/recipe-sysroot-native/usr/bin/python3-native:/home/pokybuild/yocto-worker/qemuarm64/build/scripts:/home/pokybuild/yocto-worker/qemuarm64/build/build/tmp/work/x86_64-linux/cargo-native/1.79.0/recipe-sysroot-native/usr/bin/x86_64-linux:/home/pokybuild/yocto-worker/qemuarm64/build/build/tmp/work/x86_64-linux/cargo-native/1.79.0/recipe-sysroot-native/usr/bin:/home/pokybuild/yocto-worker/qemuarm64/build/build/tmp/work/x86_64-linux/cargo-native/1.79.0/recipe-sysroot-native/usr/sbin:/home/pokybuild/yocto-worker/qemuarm64/build/build/tmp/work/x86_64-linux/cargo-native/1.79.0/recipe-sysroot-native/usr/bin:/home/pokybuild/yocto-worker/qemuarm64/build/build/tmp/work/x86_64-linux/cargo-native/1.79.0/recipe-sysroot-native/sbin:/home/pokybuild/yocto-worker/qemuarm64/build/build/tmp/work/x86_64-linux/cargo-native/1.79.0/recipe-sysroot-native/bin:/home/pokybuild/yocto-worker/qemuarm64/build/bitbake/bin:/home/pokybuild/yocto-worker/qemuarm64/build/build/tmp/hosttools" > VSLANG="1033" > "/home/pokybuild/yocto-worker/qemuarm64/build/build/tmp/work/x86_64-linux/cargo-native/1.79.0/wrapper/target-rust-ccld" > "-m64" "/tmp/rustcgeGK7l/symbols.o" > "/home/pokybuild/yocto-worker/qemuarm64/build/build/tmp/work/x86_64-linux/cargo-native/1.79.0/build/target/release/build/cargo-559f5ce7ae478850/build_script_build-559f5ce7ae478850.build_script_build.a4202d660cdaa2b7-cgu.0.rcgu.o" > "/home/pokybuild/yocto-worker/qemuarm64/build/build/tmp/work/x86_64-linux/cargo-native/1.79.0/build/target/release/build/cargo-559f5ce7ae478850/build_script_build-559f5ce7ae478850.build_script_build.a4202d660cdaa2b7-cgu.1.rcgu.o" > "/home/pokybuild/yocto-worker/qemuarm64/build/build/tmp/work/x86_64-linux/cargo-native/1.79.0/build/target/release/build/cargo-559f5ce7ae478850/build_script_build-559f5ce7ae478850.build_script_build.a4202d660cdaa2b7-cgu.2.rcgu.o" > "/home/pokybuild/yocto-worker/qemuarm64/build/build/tmp/work/x86_64-linux/cargo-native/1.79.0/build/target/release/build/cargo-559f5ce7ae478850/build_script_build-559f5ce7ae478850.build_script_build.a4202d660cdaa2b7-cgu.3.rcgu.o" > "/home/pokybuild/yocto-worker/qemuarm64/build/build/tmp/work/x86_64-linux/cargo-native/1.79.0/build/target/release/build/cargo-559f5ce7ae478850/build_script_build-559f5ce7ae478850.23ia22jv7py8po1d.rcgu.o" > "-Wl,--as-needed" "-L" > "/home/pokybuild/yocto-worker/qemuarm64/build/build/tmp/work/x86_64-linux/cargo-native/1.79.0/build/target/release/deps" > "-L" > "/home/pokybuild/yocto-worker/qemuarm64/build/build/tmp/work/x86_64-linux/cargo-native/1.79.0/recipe-sysroot-native/usr/lib/pkgconfig/../../../usr/lib" > "-L" > "/home/pokybuild/yocto-worker/qemuarm64/build/build/tmp/work/x86_64-linux/cargo-native/1.79.0/build/target/release/build/libz-sys-4aaad36e8fa0c1c8/out/lib" > "-L" > "/home/pokybuild/yocto-worker/qemuarm64/build/build/tmp/work/x86_64-linux/cargo-native/1.79.0/build/target/release/build/libz-sys-4aaad36e8fa0c1c8/out/lib" > "-L" > "/home/pokybuild/yocto-worker/qemuarm64/build/build/tmp
Re: [OE-core] [PATCH 2/2] rust: Upgrade 1.78.0->1.79.0
On Sun, 2024-08-25 at 10:05 -0700, Yash Shinde via lists.openembedded.org wrote: > From: Yash Shinde > > Update the patch files with rust v1.79.0. > > Drop the following backported patch which is merged > with rust v1.79 upgrade. > > - cross-targets-backport.patch > > https://blog.rust-lang.org/2024/06/13/Rust-1.79.0.html > > Signed-off-by: Yash Shinde It seems mostly ok but we did see: https://autobuilder.yoctoproject.org/typhoon/#/builders/42/builds/9385/steps/13/logs/stdio in Alexandre's build :( Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#203827): https://lists.openembedded.org/g/openembedded-core/message/203827 Mute This Topic: https://lists.openembedded.org/mt/108090372/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/4] bluez5: Fix build with musl
On Mon, 2024-08-26 at 10:43 -0700, Khem Raj via lists.openembedded.org wrote:
> Signed-off-by: Khem Raj
> ---
> v2: Fix the upstream submission and latest patch submitted upstream
>
> meta/recipes-connectivity/bluez5/bluez5.inc | 1 +
> ...U-basename-compatible-implementation.patch | 136 ++
> 2 files changed, 137 insertions(+)
> create mode 100644
> meta/recipes-connectivity/bluez5/bluez5/0001-Provide-GNU-basename-compatible-implementation.patch
>
> diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc
> b/meta/recipes-connectivity/bluez5/bluez5.inc
> index d8b9f817715..e0d3e651871 100644
> --- a/meta/recipes-connectivity/bluez5/bluez5.inc
> +++ b/meta/recipes-connectivity/bluez5/bluez5.inc
> @@ -70,6 +70,7 @@ SRC_URI =
> "${KERNELORG_MIRROR}/linux/bluetooth/bluez-${PV}.tar.xz \
>
> file://0001-tests-add-a-target-for-building-tests-without-runnin.patch \
> file://0001-test-gatt-Fix-hung-issue.patch \
> file://0004-src-shared-util.c-include-linux-limits.h.patch \
> + file://0001-Provide-GNU-basename-compatible-implementation.patch \
> "
> S = "${WORKDIR}/bluez-${PV}"
>
> diff --git
> a/meta/recipes-connectivity/bluez5/bluez5/0001-Provide-GNU-basename-compatible-implementation.patch
>
> b/meta/recipes-connectivity/bluez5/bluez5/0001-Provide-GNU-basename-compatible-implementation.patch
> new file mode 100644
> index 000..293675ee0a2
> --- /dev/null
> +++
> b/meta/recipes-connectivity/bluez5/bluez5/0001-Provide-GNU-basename-compatible-implementation.patch
> @@ -0,0 +1,136 @@
> +From 4ea6d5f344574b876bbf029501301131e623e992 Mon Sep 17 00:00:00 2001
> +From: Khem Raj
> +Date: Mon, 26 Aug 2024 09:55:03 -0700
> +Subject: [PATCH BlueZ] Provide GNU basename compatible implementation
> +
> +Call to basename() relies on a GNU extension
> +to take a const char * vs a char *. Let's define
> +a trivial helper function to ensure compatibility
> +with musl.
> +
> +Fixes Issue: https://github.com/bluez/bluez/issues/843
> +
> +Upstream-Status: Submitted
> [https://lore.kernel.org/linux-bluetooth/20240826173844.2918630-1-raj.k...@gmail.com/T/#u]
> +Signed-off-by: Khem Raj
> +---
> + Makefile.mesh | 2 ++
> + Makefile.tools | 3 ++-
> + mesh/mesh-config-json.c | 5 +++--
> + mesh/rpl.c | 3 ++-
> + src/shared/util.h | 6 ++
> + tools/hex2hcd.c | 3 ++-
> + 6 files changed, 17 insertions(+), 5 deletions(-)
> +
> +diff --git a/Makefile.mesh b/Makefile.mesh
> +index e4c9fa6a3..bebedaf05 100644
> +--- a/Makefile.mesh
> b/Makefile.mesh
> +@@ -47,6 +47,8 @@ mesh/main.$(OBJEXT): src/builtin.h
> lib/bluetooth/bluetooth.h
> + mesh_bluetooth_meshd_SOURCES = $(mesh_sources) mesh/main.c
> + mesh_bluetooth_meshd_LDADD = src/libshared-ell.la $(ell_ldadd) -ljson-c
> +
> ++mesh_bluetooth_meshd_CFLAGS = -I${top_srcdir}/src
> ++
> + if MANPAGES
> + man_MANS += mesh/bluetooth-meshd.8
> + endif
> +diff --git a/Makefile.tools b/Makefile.tools
> +index 5b9034078..6fc73b8a2 100644
> +--- a/Makefile.tools
> b/Makefile.tools
> +@@ -328,7 +328,8 @@ tools_l2ping_LDADD = lib/libbluetooth-internal.la
> + tools_bluemoon_SOURCES = tools/bluemoon.c monitor/bt.h
> + tools_bluemoon_LDADD = src/libshared-mainloop.la
> +
> +-tools_hex2hcd_SOURCES = tools/hex2hcd.c
> ++tools_hex2hcd_SOURCES = tools/hex2hcd.c src/shared/util.h
> ++tools_hex2hcd_CFLAGS = -I${top_srcdir}/src
> +
> + tools_mpris_proxy_SOURCES = tools/mpris-proxy.c
> + tools_mpris_proxy_LDADD = gdbus/libgdbus-internal.la $(GLIB_LIBS)
> $(DBUS_LIBS)
> +diff --git a/mesh/mesh-config-json.c b/mesh/mesh-config-json.c
> +index c198627c6..8f89a1498 100644
> +--- a/mesh/mesh-config-json.c
> b/mesh/mesh-config-json.c
> +@@ -28,6 +28,7 @@
> + #include
> + #include
> +
> ++#include "shared/util.h"
> + #include "mesh/mesh-defs.h"
> + #include "mesh/util.h"
> + #include "mesh/mesh-config.h"
> +@@ -2694,7 +2695,7 @@ bool mesh_config_load_nodes(const char *cfgdir_name,
> mesh_config_node_func_t cb,
> +
> + void mesh_config_destroy_nvm(struct mesh_config *cfg)
> + {
> +-char *node_dir, *node_name;
> ++const char *node_dir, *node_name;
> + char uuid[33];
> +
> + if (!cfg)
> +@@ -2706,7 +2707,7 @@ void mesh_config_destroy_nvm(struct mesh_config *cfg)
> + if (!hex2str(cfg->uuid, 16, uuid, sizeof(uuid)))
> + return;
> +
> +-node_name = basename(node_dir);
> ++node_name = bluez_basename(node_dir);
> +
> + /* Make sure path name of node follows expected guidelines */
> + if (strcmp(node_name, uuid))
> +diff --git a/mesh/rpl.c b/mesh/rpl.c
> +index fb225..fb89f0afd 100644
> +--- a/mesh/rpl.c
> b/mesh/rpl.c
> +@@ -24,6 +24,7 @@
> +
> + #include
> +
> ++#include "shared/util.h"
> + #include "mesh/mesh-defs.h"
> +
> + #include "mesh/node.h"
> +@@ -146,7 +147,7 @@ static void get_entries(const char *iv_path, struct
> l_queue *rpl_list)
> + if (!dir)
> + return;
> +
> +-
Re: [OE-core] [PATCH] makedevs: Fix matching uid/gid
On Mon, 2024-08-26 at 22:41 +0900, Jung Jaeyoon(Jay) wrote:
> As an actual example, suppose there is an entry as below in a device
> table that makedevs receives:
>
> /dev/system c 0660 root system 1000
> 0 - - -
>
> then you will get "system" group for id_buf in convert2guid().
> and suppose there are two entries in /etc/group where both start with
> "system" like:
>
> systemd-journal:x:900:
> system:x:2020:
>
> Obviously convert2guid() should return 2020 in this case, but with
> the existing code it will return 900 because the entry of "systemd-
> journal" comes first in the loop and strncmp("systemd-journal",
> "system", strlen("system")) returns 0.
That makes sense and does indeed look like a bug. I think we should
change the strlen to MAX_ID_LEN instead?
I'm still a little worried there is an off by one error somewhere in
there too.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#203754):
https://lists.openembedded.org/g/openembedded-core/message/203754
Mute This Topic: https://lists.openembedded.org/mt/10759/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] makedevs: Fix matching uid/gid
On Mon, 2024-08-26 at 19:07 +0900, Jung Jaeyoon(Jay) wrote: > On Sat, Aug 17, 2024 at 06:47 AM, Richard Purdie wrote: > > I'm afraid I don't understand the problem here. If partial matching > > is occurring, doesn't that mean MAX_ID_LEN is wrong? > > > > If we drop the strncmp() here, that appears to put us at risk of > > buffer overflow problems, particularly if MAX_ID_LEN is too short? > > > > Can you give an example of how this is failing and where the above > > change helps? > > > (Sorry for being late responding on this. It has been missing in my > INBOX somehow.) > > A typical case where it is failing is when id_buf is shorter than > node->name and they match partially, e.g, id_buf is "foo" and node- > >name is "foobar". > Note that it's using strlen(id_buf), not strlen(MAX_ID_LEN). convert2guid, where the strlen is located, is called from two places both in interpret_table_entry() and there the buffer is defined as: char usr_buf[MAX_ID_LEN]; char grp_buf[MAX_ID_LEN]; The name field of node is defined as: char name[MAX_NAME_LEN+1] which could be a problem if they differ but: #define MAX_ID_LEN 40 #define MAX_NAME_LEN40 so the only issue I can see is there is perhaps an off by one on the length definition? > I believe using strcmp() here is safe because it is guaranteed that > both strings cannot be longer than MAX_ID_LEN(=MAX_NAME_LEN) and are > always NULL-terminated. Perhaps, but I think the existing code should work and if there is a bug, I'd like to understand what it is. Is the issue an off by one on the length? I'd ask again if you have an actual example of the failure? Is it only with strings of 39/40 length? Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#203750): https://lists.openembedded.org/g/openembedded-core/message/203750 Mute This Topic: https://lists.openembedded.org/mt/10759/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] [master][PATCH] webkitgtk: fix do_configure error on beaglebone-yocto
On Mon, 2024-08-26 at 16:51 +0800, Changqing Li via lists.openembedded.org wrote: > From: Changqing Li > > * According to latest comment [1] and the mentioned pull request > [2], build an ENABLE(WEBASSEMBLY) && !ENABLE(JIT) configuration is > supported, so original issue already fixed in current version, the > EXTRA_OECMAKE setting is not needed anymore. > > * This EXTRA_OECMAKE setting causes following configure error on > beaglebone-yocto, remove the setting to let the configure process > decide > the configuration: > CMake Error at Source/cmake/WebKitFeatures.cmake:312 (message): > ENABLE_JIT conflicts with ENABLE_C_LOOP. You must disable one or > the > other. > > [YOCTO #15254] > > [1] https://github.com/WebKit/WebKit/pull/17447 > [2] https://github.com/WebKit/WebKit/pull/17688 > > Signed-off-by: Changqing Li > --- > meta/recipes-sato/webkit/webkitgtk_2.44.3.bb | 12 > 1 file changed, 12 deletions(-) Why aren't we seeing that error on the autobuilder? Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#203748): https://lists.openembedded.org/g/openembedded-core/message/203748 Mute This Topic: https://lists.openembedded.org/mt/108100749/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] testimage: Add support to create test report in JUnit XML format
On Mon, 2024-08-26 at 10:13 +0200, Clara Kowalsky via lists.openembedded.org wrote: > This introduces the possibility to report the test results of testimage > in JUnit XML format by setting TESTIMAGE_JUNIT_REPORT = "1". > The generated unit test report is located in the TEST_LOG_DIR and can be > used in the CI/CD pipeline to display the test results. > > Signed-off-by: Clara Kowalsky > --- > meta/classes-recipe/testimage.bbclass | 15 +++ > meta/lib/oeqa/core/runner.py | 39 ++- > 2 files changed, 53 insertions(+), 1 deletion(-) I'm not sure that we want to add new output formats every time we have a need for a different way of displaying the results as this won't scale each time a new output format is needed and we can easily end up with missing data with one of the formats. Could we use a conversion tool instead (it could be part of resulttool)? If there is data missing in the json format, we should be able to add it. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#203746): https://lists.openembedded.org/g/openembedded-core/message/203746 Mute This Topic: https://lists.openembedded.org/mt/108100544/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] [RFC PATCH] piglit: add a patch to address host contamination for wayland-scanner
On Fri, 2024-08-23 at 15:50 +0200, Alexander Kanavin via lists.openembedded.org
wrote:
> From: Alexander Kanavin
>
> Signed-off-by: Alexander Kanavin
> ---
> ...o-not-obtain-wayland-scanner-path-fr.patch | 38 +++
> meta/recipes-graphics/piglit/piglit_git.bb | 1 +
> 2 files changed, 39 insertions(+)
> create mode 100644
> meta/recipes-graphics/piglit/piglit/0001-CMakeLists.txt-do-not-obtain-wayland-scanner-path-fr.patch
>
> diff --git
> a/meta/recipes-graphics/piglit/piglit/0001-CMakeLists.txt-do-not-obtain-wayland-scanner-path-fr.patch
>
> b/meta/recipes-graphics/piglit/piglit/0001-CMakeLists.txt-do-not-obtain-wayland-scanner-path-fr.patch
> new file mode 100644
> index 000..b47e16af6b3
> --- /dev/null
> +++
> b/meta/recipes-graphics/piglit/piglit/0001-CMakeLists.txt-do-not-obtain-wayland-scanner-path-fr.patch
> @@ -0,0 +1,38 @@
> +From 8f25cdf54e35ab1a174cabf5078784b8e48bda01 Mon Sep 17 00:00:00 2001
> +From: Alexander Kanavin
> +Date: Fri, 23 Aug 2024 15:29:45 +0200
> +Subject: [PATCH] CMakeLists.txt: do not obtain wayland-scanner path from
> + pkg-config
> +
> +cmake can only use target wayland-scanner.pc which (correctly) points to
> /usr/bin/wayland-scanner
> +
> +However in cross builds it should be using wayland-scanner from native
> sysroot,
> +otherwise builds will break if wayland-scanner is not installed on the host
> +distro.
> +
> +Upstream-Status: Inappropriate [yocto specific]
> +Signed-off-by: Alexander Kanavin
> +---
> + CMakeLists.txt | 6 +-
> + 1 file changed, 1 insertion(+), 5 deletions(-)
> +
> +diff --git a/CMakeLists.txt b/CMakeLists.txt
> +index d169fb481..8394f5236 100644
> +--- a/CMakeLists.txt
> b/CMakeLists.txt
> +@@ -211,11 +211,7 @@ if(PIGLIT_USE_WAYLAND)
> + message(FATAL_ERROR "Failed to find wayland-protocols XML path")
> + endif()
> +
> +-pkg_check_modules(WaylandScanner REQUIRED wayland-scanner)
> +-pkg_get_variable(WaylandScannerPath wayland-scanner wayland_scanner)
> +-if (NOT WaylandScannerPath)
> +-message(FATAL_ERROR "Failed to find wayland-scanner path from
> pkg-config")
> +-endif()
> ++set(WaylandScannerPath wayland-scanner)
> + add_executable(WaylandScannerExe IMPORTED)
> + set_property(TARGET WaylandScannerExe PROPERTY IMPORTED_LOCATION
> ${WaylandScannerPath})
> + endif()
Is there any notion of cross compiling in cmake? This might be
upstreamable if you could make "wayland-scanner" conditional upon cross
compiling?
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#203699):
https://lists.openembedded.org/g/openembedded-core/message/203699
Mute This Topic: https://lists.openembedded.org/mt/108056130/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] VOLATILE_TMP_DIR: Extend to specify the persistence of /var/tmp
On Thu, 2024-05-30 at 17:02 +0800, Changqing Li via lists.openembedded.org
wrote:
> From: Changqing Li
>
> Currently, set VOLATILE_TMP_DIR to "no", only make /tmp as persistent.
> This patch extends VOLATILE_TMP_DIR to also specify the persistence of
> /var/tmp by following changes:
>
> * change FILESYSTEM_PERMS_TABLES to remove symlink /var/tmp ->
> /var/volatile/tmp
> for the packaging process
> * update base-files to create /var/tmp as a dir not symlink to
> /var/volatile/tmp
>
> Here is an use case:
> Steps:
> 1. docker import core-image-minimal-qemux86-64.tar.bz2 poky:latest
> 2. docker run -it --rm poky:latest /bin/sh
> 3. /var/log /var/tmp are deadlinks, and cause "No such file or directory"
> errors
>
> Root cause:
> By default, /var/tmp links to /var/volatile/tmp, and /var/volatile/tmp
> usually created by initscript(sysV) or systemd-tmpfile.d(systemd) during
> boot up, but for container, initscript/systemd-tmpfile.d will not be
> executed, so /var/volatile/tmp is not created.
>
> This patch provides an option for user want to use container, set
> VOLATILE_TMP_DIR to "no" can resolve above case.
>
> Signed-off-by: Changqing Li
Sorry it has taken me so long to get to this. I agree we should try and
fix the issues you raise here but I don't think the patch is quite the
best way to do it. What I'd propose is that we keen the new fs-perms
files you're creating but change the tables variable to simply be:
FILESYSTEM_PERMS_TABLES ?= " files/fs-perms.txt \
files/fs-perms-volatile-log.txt \
files/fs-perms-volatile-tmp.txt \
"
The other references can then simply work along the lines of:
${@bb.utils.contains("FILESYSTEM_PERMS_TABLES",
"files/fs-perms-volatile-log.txt", "log", "", d)}
and we drop the VOLATILE_*_DIR variables.
I'd suggest two patches, one separating out fs-perms-volatile-log.txt
and the other adding fs-perms-volatile-tmp.txt.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#203697):
https://lists.openembedded.org/g/openembedded-core/message/203697
Mute This Topic: https://lists.openembedded.org/mt/106385197/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][REQUEST FOR ASSISTANCE][PATCH] piglit: upgrade 22eaf6a91c -> c11c9374c1
On Fri, 2024-08-23 at 10:18 -0400, Trevor Gamblin via lists.openembedded.org wrote: > > On 2024-08-23 9:51 a.m., Alexander Kanavin wrote: > > I just sent a patch that addresses the wayland-scanner problem > > (marked > > RFC as it depends on your patch applied first). Does the problem > > and > > the fix make sense to you? > Thanks for sending that out. It's actually not clear to me why there > isn't a need to tweak a variable or something to tell it to look at > the > native sysroot version of wayland-scanner. I'm guessing that > `set(WaylandScannerPath wayland-scanner)` is picking up a path in the > build environment? > bitbake.conf puts the native sysroot in PATH so we can rely on that to be picked up from there as it will be set like that in the build environment. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#203694): https://lists.openembedded.org/g/openembedded-core/message/203694 Mute This Topic: https://lists.openembedded.org/mt/108039675/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 4/4] kernel-fitimage: run unbundled fitimage after deploy
I have been struggling to find time to sit and think through the implications of this. I have finally done that, at least a little and I have some questions below. Sorry about the delay in getting to this, I keep hoping someone else will help with this kind of review but it is very time consuming and I suspect nobody has quite the right set of knowledge to make it easier. On Mon, 2024-08-19 at 17:17 +0200, Adrian Freihofer via lists.openembedded.org wrote: > From: Adrian Freihofer > > Without this change, the kernel is always rebuilt if something changes > in the initramfs. If the kernel is rebuilt with an empty TMPDIR, the > process starts by fetching the large kernel git repository and > recompiling it from scratch. This is very inefficient. > > This cannot be improved if INITRAMFS_IMAGE_BUNDLE = "1". If the kernel > Makefile is needed to generate the initramfs bundle the kernel build > folder is required. For this cases nothing changes. When you say "kernel Makefile", I'm assuming to rebuild the kernel image, you need much more than just the Makefile but a complete kernel build tree? The Makefile is a solvable problem, the tree isn't! > But for a build configuration with INITRAMFS_IMAGE_BUNDLE = "" the > build folder is not needed. Creating the initramfs bundle requires: > linux.bin, DTBs and the initramfs. These artifacts are all available in > the deploy folder which is also sstate cached. > > Therefore do_assemble_fitimage_initramfs gets split into two tasks: > - do_assemble_fitimage_initramfs creates the bundled fitImage which runs > before do_deploy. This is without sstate and therefore the do_deploy > task still deploys the artifacts generated by this task. > - do_deploy_fitimage_unbundled creates the fitImage in unbundled mode. > This task runs after do_deploy. It uses the linux.bin artifact from > do_deploy to create the fitImage with initramfs. I'm a bit worried about having a second do_deploy_xxx task after do_deploy. This creates a recipe with two deploy tasks and whilst I can understand why you're doing it, I worry this is going to create confusion down the road. The reason I say this is that there are rules for "deploy" tasks, e.g. in meta-classes/sstate.bbclass:setscene_depvalid() has: # do_package/packagedata/package_qa/deploy don't need do_populate_sysroot if taskdependees[task][1] == "do_populate_sysroot" and taskdependees[dep][1] in ['do_package', 'do_packagedata', 'do_package_qa', 'do_deploy']: continue do_deploy_fitimage_unbundled isn't listed in SSTATETASKS. Whilst that is simple to fix, I'm not sure what side effects that is then going to cause. Also, there is this to consider: meta/classes-global/base.bbclass:do_build[recrdeptask] += "do_deploy" which is basically making sure "build" targets (the default) trigger all artefacts to be deployed. I think this new task will be missed by global code as it isn't covered there. The intent was to have one name which covered all cases, not having recipe specific entries in there. I'm starting to wonder if that unbundled case should be handled by a separate recipe, which can then have its own do_deploy task and depend on all the correct pieces. > This task is done with SSTATE_SKIP_CREATION, because this also works > with the eSDK installer (oe-selftest -r esdk is successful). It is > also more effective to quickly create the fit image instead of > handling it via sstate. Skipping sstate creation is a huge red warning sign in my mind. So far we've only had images and eSDKs using this option and I never wanted to add the option generically in the first place since it was going to lead to more exceptions like this. The implications of not creating the sstate can be problematic, for example the sstate tests then need to learn that some new subset of sstate artefacts will never be created. This also complicated the testing of eSDKs which do a similar verification which will also need exceptions. I can understand why you've done it but I am worried the side effects will be left for others (such as myself) to resolve as fit images get used in new codepaths :/. > Unfortunately, this change is not 100% backward compatible. Previously, > a dependency on do_deploy deployed all types of fit images. With this > change, deploying the unbundled fit image requires a dependency on > do_deploy_fitimage_unbundled. To address this the image.bbclass gets > improved to handle both cases with the KERNEL_DEPLOY_DEPEND variable. I think this proves my point about why adding a new deploy task is potentially problematic. Have you considered using an intermediate recipe for the unbundled case instead? I wish we could determine how much use the bundled and unbundled cases have. I'm also starting to wonder if the two cases should be separated apart into two clear workflows rather than the current entwined situation which is very hard to visualise and understand. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][PATCH v3] piglit: upgrade 22eaf6a91c -> c11c9374c1
On Thu, 2024-08-22 at 11:04 +0100, Richard Purdie via lists.openembedded.org wrote: > On Wed, 2024-08-21 at 15:46 -0400, Trevor Gamblin via > lists.openembedded.org wrote: > > > > On 2024-08-21 3:45 p.m., Trevor Gamblin via lists.openembedded.org > > wrote: > > > Commit 79895d fixes builds with numpy 2.x. > > > > > > Patch '0001-utils-Include-libgen.h-on-musl-linux-systems.patch' > > > dropped > > > because it is now upstream in commit 9c941dfc36. > > > > > > Add wayland and wayland-protocols to DEPENDS to avoid errors during > > > build. > > > > > > Adjust the x11 PACKAGECONFIG flags so that piglit builds without > > > x11 > > > available. > > > > FYI, I've tried the reproducible tests on piglit with and without > > TCLIBC=musl, and also with and without the numpy 2.0.1 upgrade, and I > > can't reproduce them. Hopefully this works on the AB now. > > Unfortunately it didn't :(. > > reproducible: > https://autobuilder.yoctoproject.org/typhoon/#/builders/117/builds/5220 > world docs build: > https://autobuilder.yoctoproject.org/typhoon/#/builders/108/builds/6306 > world build: > https://autobuilder.yoctoproject.org/typhoon/#/builders/108/builds/6306 > musl: > https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/9404/steps/11/logs/stdio > https://autobuilder.yoctoproject.org/typhoon/#/builders/45/builds/9416/steps/11/logs/stdio > no-x11: > https://autobuilder.yoctoproject.org/typhoon/#/builders/40/builds/9390/steps/12/logs/stdio > https://autobuilder.yoctoproject.org/typhoon/#/builders/40/builds/9390/steps/15/logs/stdio > > It is hard to see which are warnings and which are errors in the logs. > I did wonder if the issue was python version specific. Are there any > related commits upstream looking to fix anything like this? I have a lead, I think it is using a hardcoded path into the host system for wayland-scanner: /bin/sh: 1: /usr/bin/wayland-scanner: not found We're trying builds on systems with wayland installed, the autobuilders don't have that! So have a look for a hardcoded path to that... Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#203651): https://lists.openembedded.org/g/openembedded-core/message/203651 Mute This Topic: https://lists.openembedded.org/mt/108025942/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] [PATCHv2 2/2] oeqa/selftest/bbclasses: Add tests for systemd and update-rc.d interaction
On Thu, 2024-08-22 at 11:07 +0100, Richard Purdie via lists.openembedded.org wrote: > I'm really happy to see tests so thanks for that! Unfortunately > something isn't quite right, some builds passed and some failed. The > failures: > > https://autobuilder.yoctoproject.org/typhoon/#/builders/127/builds/3754/steps/15/logs/stdio > https://autobuilder.yoctoproject.org/typhoon/#/builders/127/builds/3754/steps/15/logs/stdio > https://autobuilder.yoctoproject.org/typhoon/#/builders/87/builds/7088/steps/14/logs/stdio > > and the passes: > > https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/7074 > https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/7096 > > At this point I've not looked into what happened, I'm just reporting > the results. I meant to add that I'm a bit worried this series is also causing these runtime test failures: https://autobuilder.yoctoproject.org/typhoon/#/builders/101/builds/8100/steps/14/logs/stdio https://autobuilder.yoctoproject.org/typhoon/#/builders/102/builds/6427/steps/15/logs/stdio https://autobuilder.yoctoproject.org/typhoon/#/builders/107/builds/6478/steps/14/logs/stdio https://autobuilder.yoctoproject.org/typhoon/#/builders/109/builds/8213/steps/14/logs/stdio https://autobuilder.yoctoproject.org/typhoon/#/builders/110/builds/8253/steps/14/logs/stdio Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#203650): https://lists.openembedded.org/g/openembedded-core/message/203650 Mute This Topic: https://lists.openembedded.org/mt/108010122/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
