Re: [OE-core] Pseudo Abort due to path mismatch #pseudo #kirkstone
Don't use:
S = "${WORKDIR}"
move it to separate directory and it will work fine.
On Wed, Apr 24, 2024 at 6:41 PM lukas.palme via lists.openembedded.org
wrote:
>
> Hello openembedded community!
>
> I hope this is the right place to ask this question,
> https://wiki.yoctoproject.org/wiki/Pseudo_Abort brought me here.
>
> I have a custom recipe which builds fine on the first build, but fails on
> subsequent builds in the do_install step:
>
> ERROR: Task
> (/home/swarco/WindriverLinux22/build/../layers/meta-swarco/meta-vega/recipes-kernel/mymodule/mymodule.bb:do_install)
> failed with exit code '1'
> Pseudo log:
> path mismatch [3 links]: ino 78038 db
> '/home/swarco/WindriverLinux22/build/tmp-glibc/work/vegamx8-wrs-linux/mymodule/1.0-r0/package/usr/src/debug/mymodule/1.0-r0/mymodule_public.h'
> req
> '/home/swarco/WindriverLinux22/build/tmp-glibc/work/vegamx8-wrs-linux/mymodule/1.0-r0/mymodule_public.h'.
> Setup complete, sending SIGUSR1 to pid 12937.
>
> Yocto is the only one touching the files in between builds. Also the files
> questioned do exist with the noted inode:
>
> swarco@SWFPERWKS065:~/WindriverLinux22$ stat
> /home/swarco/WindriverLinux22/build/tmp-glibc/work/vegamx8-wrs-linux/mymodule/1.0-r0/package/usr/src/debug/mymodule/1.0-r0/mymodule_public.h
> File:
> /home/swarco/WindriverLinux22/build/tmp-glibc/work/vegamx8-wrs-linux/mymodule/1.0-r0/package/usr/src/debug/mymodule/1.0-r0/mymodule_public.h
> Size: 3146Blocks: 8 IO Block: 4096 regular file
> Device: 820h/2080d Inode: 78038 Links: 3
> Access: (0644/-rw-r--r--) Uid: ( 1000/ swarco) Gid: ( 1000/ swarco)
> Access: 2024-04-24 18:17:21.182513722 +0200
> Modify: 2024-04-24 18:16:50.402199580 +0200
> Change: 2024-04-24 18:17:19.432495797 +0200
> Birth: 2024-04-24 18:11:59.419201062 +0200
>
> swarco@SWFPERWKS065:~/WindriverLinux22$ stat
> /home/swarco/WindriverLinux22/build/tmp-glibc/work/vegamx8-wrs-linux/mymodule/1.0-r0/mymodule_public.h
> File:
> /home/swarco/WindriverLinux22/build/tmp-glibc/work/vegamx8-wrs-linux/mymodule/1.0-r0/mymodule_public.h
> Size: 3146Blocks: 8 IO Block: 4096 regular file
> Device: 820h/2080d Inode: 78038 Links: 3
> Access: (0644/-rw-r--r--) Uid: ( 1000/ swarco) Gid: ( 1000/ swarco)
> Access: 2024-04-24 18:17:21.182513722 +0200
> Modify: 2024-04-24 18:16:50.402199580 +0200
> Change: 2024-04-24 18:17:19.432495797 +0200
> Birth: 2024-04-24 18:11:59.419201062 +0200
>
> This is the recipe mymodule.bb:
>
> SUMMARY = "mymodule"
> DESCRIPTION = "Recipe for building a mymodule Linux kernel module"
> LICENSE = "GPL-2.0-only"
> LIC_FILES_CHKSUM =
> "file://${COMMON_LICENSE_DIR}/GPL-2.0-only;md5=801f80980d171dd6425610833a22dbe6"
>
> inherit module
>
> SRC_URI = "file://Makefile \
>file://mymodule_core.c \
>file://mymodule.h \
>file://mymodule_public.h \
>file://mymodule_remote_public.h \
> "
>
> S = "${WORKDIR}"
>
> do_install:append() {
> install -d ${D}${includedir}
> install -m 0755 ${S}/mymodule_public.h ${D}${includedir}/
> }
> # The inherit of module.bbclass will automatically name module packages with
> # "kernel-module-" prefix as required by the oe-core build environment.
>
> RPROVIDES:${PN} += "kernel-module-mymodule"
> FILES:${PN}-dev += "${includedir}/*"
>
> I am doing nothing unusual here.
>
> Additional notes to my setup:
>
> Host machine: Ubuntu 22.04 on WSL
> Linux kernel: linux-imx (NXP)
>
> Does someone have an idea what is happening here? Any help is appreciated!
>
> Kind regards,
>
> Lukas Palme
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#198690):
https://lists.openembedded.org/g/openembedded-core/message/198690
Mute This Topic: https://lists.openembedded.org/mt/105713810/21656
Mute
#pseudo:https://lists.openembedded.org/g/openembedded-core/mutehashtag/pseudo
Mute
#kirkstone:https://lists.openembedded.org/g/openembedded-core/mutehashtag/kirkstone
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/2] liba52: update SRC_URI
Have you tried: https://sources.yoctoproject.org/mirror/sources/a52dec-0.7.4.tar.gz that has the old caa9f5bc44232dc8aeea773fea56be80 ? https://sourceforge.net/projects/liba52/files/a52dec-0.7.4.tar.gz returns just HTML to me with md5sum c9fe0eb75b290358b3948b58e9f10baa: $ head a52dec-0.7.4.tar.gz
Re: [OE-core] [PATCH 1/2] liba52: update SRC_URI
What is the difference between the tarballs that it requires checksum update?
On Thu, Apr 18, 2024 at 12:28 AM Jon Mason via lists.openembedded.org
wrote:
>
> The former SRC_URI was no longer working. Update to one that is. This
> required updating the md5sum and sha256sum. NOTE: SOURCEFORGE_MIRROR
> (https://downloads.sourceforge.net) does not appear to be working for
> liba52.
>
> Signed-off-by: Jon Mason
> ---
> meta/recipes-multimedia/liba52/liba52_0.7.4.bb | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/meta/recipes-multimedia/liba52/liba52_0.7.4.bb
> b/meta/recipes-multimedia/liba52/liba52_0.7.4.bb
> index 7a3b4a43c8d4..684dd590ca15 100644
> --- a/meta/recipes-multimedia/liba52/liba52_0.7.4.bb
> +++ b/meta/recipes-multimedia/liba52/liba52_0.7.4.bb
> @@ -10,11 +10,11 @@ SECTION = "libs"
>
> inherit autotools
>
> -SRC_URI = "http://liba52.sourceforge.net/files/a52dec-${PV}.tar.gz \
> +SRC_URI = "https://sourceforge.net/projects/liba52/files/a52dec-${PV}.tar.gz
> \
> file://buildcleanup.patch"
>
> -SRC_URI[md5sum] = "caa9f5bc44232dc8aeea773fea56be80"
> -SRC_URI[sha256sum] =
> "a21d724ab3b390194353687df82c475b5dfb997513eef4c25de6c865ec33"
> +SRC_URI[md5sum] = "1a2e77b4f7aacd858961a6b727710551"
> +SRC_URI[sha256sum] =
> "c1931bc511dc48987fdba6888be577f3035e3f0b6b81d3ea3e766fca8d18e128"
>
> UPSTREAM_CHECK_URI = "http://liba52.sourceforge.net/downloads.html;
>
> --
> 2.30.2
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#198499):
https://lists.openembedded.org/g/openembedded-core/message/198499
Mute This Topic: https://lists.openembedded.org/mt/105587757/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] base.bbclass: make do_fetch depends on PREMIRRORS MIRRORS
How does this work when sharing sstate between builders with different
PREMIRRORS/MIRRORS? Doesn't this cause all signatures to be different
as do_unpack does depend on do_fetch?
On Mon, Apr 15, 2024 at 10:30 AM Changqing Li via
lists.openembedded.org
wrote:
>
> From: Changqing Li
>
> When there are tarballs in local mirror file://, do_fetch will
> create symlink under DL_DIR, eg:
> pseudo-prebuilt-2.33.tar.xz ->
> /project/path/to/localmirrorA/pseudo-prebuilt-2.33.tar.xz
> after user update path from localmirrorA to localmirrorB, because
> do_fetch don't depends on PREMIRRORS/MIRRORS, do_fetch will not
> be rerun, so the symlink will not update to:
> pseudo-prebuilt-2.33.tar.xz ->
> /project/path/to/localmirrorB/pseudo-prebuilt-2.33.tar.xz
> then, do_upack will failed since the tarball cannot be found.
>
> Signed-off-by: Changqing Li
> ---
> meta/classes-global/base.bbclass | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/meta/classes-global/base.bbclass
> b/meta/classes-global/base.bbclass
> index 0999b42daa..5094a1540e 100644
> --- a/meta/classes-global/base.bbclass
> +++ b/meta/classes-global/base.bbclass
> @@ -139,6 +139,7 @@ do_fetch[file-checksums] =
> "${@bb.fetch.get_checksum_file_list(d)}"
> do_fetch[file-checksums] += " ${@get_lic_checksum_file_list(d)}"
> do_fetch[prefuncs] += "fetcher_hashes_dummyfunc"
> do_fetch[network] = "1"
> +do_fetch[vardeps] += "PREMIRRORS MIRRORS"
> python base_do_fetch() {
>
> src_uri = (d.getVar('SRC_URI') or "").split()
> --
> 2.25.1
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#198223):
https://lists.openembedded.org/g/openembedded-core/message/198223
Mute This Topic: https://lists.openembedded.org/mt/105532159/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] [kirkstone][PATCH 2/3] tiff: fix CVE-2023-52356 CVE-2023-6277
Please fix your Upstream-Status formatting
CVE-2023-52356.patch and all 4 CVE-2023-6277-[1-4].patch trigger:
Please correct according to
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines#Patch_Header_Recommendations:_Upstream-Status
:
Upstream-Status: Backport
ERROR: tiff-4.3.0-r0 do_patch: Malformed Upstream-Status in patch
as it is in kirkstone-nut
On Thu, Mar 28, 2024 at 8:50 AM Lee Chee Yang wrote:
>
> From: Lee Chee Yang
>
> import patch from ubuntu to fix CVE-2023-52356 CVE-2023-6277
> import from
> http://archive.ubuntu.com/ubuntu/pool/main/t/tiff/tiff_4.3.0-6ubuntu0.8.debian.tar.xz
>
> Signed-off-by: Lee Chee Yang
> ---
> .../libtiff/tiff/CVE-2023-52356.patch | 55 ++
> .../libtiff/tiff/CVE-2023-6277-1.patch| 179 ++
> .../libtiff/tiff/CVE-2023-6277-2.patch| 152 +++
> .../libtiff/tiff/CVE-2023-6277-3.patch| 47 +
> .../libtiff/tiff/CVE-2023-6277-4.patch| 94 +
> meta/recipes-multimedia/libtiff/tiff_4.3.0.bb | 5 +
> 6 files changed, 532 insertions(+)
> create mode 100644 meta/recipes-multimedia/libtiff/tiff/CVE-2023-52356.patch
> create mode 100644 meta/recipes-multimedia/libtiff/tiff/CVE-2023-6277-1.patch
> create mode 100644 meta/recipes-multimedia/libtiff/tiff/CVE-2023-6277-2.patch
> create mode 100644 meta/recipes-multimedia/libtiff/tiff/CVE-2023-6277-3.patch
> create mode 100644 meta/recipes-multimedia/libtiff/tiff/CVE-2023-6277-4.patch
>
> diff --git a/meta/recipes-multimedia/libtiff/tiff/CVE-2023-52356.patch
> b/meta/recipes-multimedia/libtiff/tiff/CVE-2023-52356.patch
> new file mode 100644
> index 00..6c3c5adc52
> --- /dev/null
> +++ b/meta/recipes-multimedia/libtiff/tiff/CVE-2023-52356.patch
> @@ -0,0 +1,55 @@
> +CVE: CVE-2023-52356
> +Upstream-Status: Backport
> +[ upstream :
> https://gitlab.com/libtiff/libtiff/-/commit/51558511bdbbcffdce534db21dbaf5d54b31638a
> +ubuntu :
> http://archive.ubuntu.com/ubuntu/pool/main/t/tiff/tiff_4.3.0-6ubuntu0.8.debian.tar.xz
> ]
> +Signed-off-by: Lee Chee Yang
> +
> +[Ubuntu note: Backport of the following patch from upstream, with a few
> changes
> +to match the current version of the file in the present Ubuntu release:
> + . using TIFFErrorExt instead of TIFFErrorExtR (the latter did not exist
> yet);
> +-- Rodrigo Figueiredo Zaiden]
> +
> +Backport of:
> +
> +From 51558511bdbbcffdce534db21dbaf5d54b31638a Mon Sep 17 00:00:00 2001
> +From: Even Rouault
> +Date: Tue, 31 Oct 2023 15:58:41 +0100
> +Subject: [PATCH] TIFFReadRGBAStrip/TIFFReadRGBATile: add more validation of
> + col/row (fixes #622)
> +
> +---
> + libtiff/tif_getimage.c | 15 +++
> + 1 file changed, 15 insertions(+)
> +
> +
> +--- tiff-4.3.0.orig/libtiff/tif_getimage.c
> tiff-4.3.0/libtiff/tif_getimage.c
> +@@ -2942,6 +2942,13 @@ TIFFReadRGBAStripExt(TIFF* tif, uint32_t
> + }
> +
> + if (TIFFRGBAImageOK(tif, emsg) && TIFFRGBAImageBegin(, tif,
> stop_on_error, emsg)) {
> ++if (row >= img.height)
> ++{
> ++TIFFErrorExt(tif->tif_clientdata, TIFFFileName(tif),
> ++ "Invalid row passed to TIFFReadRGBAStrip().");
> ++TIFFRGBAImageEnd();
> ++return (0);
> ++}
> +
> + img.row_offset = row;
> + img.col_offset = 0;
> +@@ -3018,6 +3025,14 @@ TIFFReadRGBATileExt(TIFF* tif, uint32_t
> + return( 0 );
> + }
> +
> ++if (col >= img.width || row >= img.height)
> ++{
> ++TIFFErrorExt(tif->tif_clientdata, TIFFFileName(tif),
> ++ "Invalid row/col passed to TIFFReadRGBATile().");
> ++TIFFRGBAImageEnd();
> ++return (0);
> ++}
> ++
> + /*
> + * The TIFFRGBAImageGet() function doesn't allow us to get off the
> + * edge of the image, even to fill an otherwise valid tile. So we
> diff --git a/meta/recipes-multimedia/libtiff/tiff/CVE-2023-6277-1.patch
> b/meta/recipes-multimedia/libtiff/tiff/CVE-2023-6277-1.patch
> new file mode 100644
> index 00..6882529cfb
> --- /dev/null
> +++ b/meta/recipes-multimedia/libtiff/tiff/CVE-2023-6277-1.patch
> @@ -0,0 +1,179 @@
> +CVE: CVE-2023-6277
> +Upstream-Status: Backport
> +[ upstream :
> https://gitlab.com/libtiff/libtiff/-/commit/5320c9d89c054fa805d037d84c57da874470b01a
> +ubuntu :
> http://archive.ubuntu.com/ubuntu/pool/main/t/tiff/tiff_4.3.0-6ubuntu0.8.debian.tar.xz
> ]
> +Signed-off-by: Lee Chee Yang
> +
> +[Ubuntu note: Backport of the following patch from upstream, with a few
> changes
> +to match the current version of the file in the present Ubuntu release:
> + . using TIFFWarningExt instead of TIFFWarningExtR (the latter did not exist
> yet);
> + . calling _TIFFfree(data) instead of _TIFFfreeExt(tif, data) (the latter
> did not exist yet);
> +-- Rodrigo Figueiredo Zaiden]
> +
> +Backport of:
> +
> +From 5320c9d89c054fa805d037d84c57da874470b01a Mon Sep 17 00:00:00 2001
> +From: Su Laus
> +Date: Tue, 31 Oct 2023
Re: [OE-core] [PATCH 36/36] xz: upgrade 5.4.6 -> 5.6.1 _WARNING_
>From what is publicly known it injected malicious code (through m4 macro using payload hidden in obfuscated compressed test file) into built liblzma.so.5 which then hijacks RSA_public_decrypt call e.g. in sshd (when sshd is built with patch adding systemd notifications which brings liblzma dependency to sshd e.g. on debian and ubuntu based systems). The build systems which just built this xz version shouldn't be affected (as it won't be using the liblzma.so from the OE build on the host). This publicly known part should be OK for OE, but it's right to be worried about the other things which aren't known (not only from these guys or from xz project). Regards, On Sat, Mar 30, 2024 at 1:52 PM Alexander Kanavin wrote: > > I’m slightly worried. Does this compromise build systems (given that back > door was injected into autoconf scripts) or only systems where xz binaries > are installed? > > Ale > > On Sat 30. Mar 2024 at 13.26, Richard Purdie > wrote: >> >> On Sat, 2024-03-30 at 13:08 +0100, Marta Rybczynska wrote: >> > Absolutely confirm. DO NOT UPDATE >> > >> > Marta >> > >> > On Sat, 30 Mar 2024, 02:04 Mark Hatle, >> > wrote: >> > > I know this request is a week or so old.. >> > > >> > > But do NOT upgrade to 'xz' 5.6.0 or 5.6.1. It has been >> > > compromised: >> > > >> > > https://www.openwall.com/lists/oss-security/2024/03/29/4 >> > > >> > > --Mark >> >> We're not going to. The upgrade was already dropped after it failed >> build testing. I do wonder why it failed. >> >> https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/8737 >> >> I've ensured the sources were removed from our mirrors too. >> >> Cheers, >> >> Richard >> >> >> > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#197651): https://lists.openembedded.org/g/openembedded-core/message/197651 Mute This Topic: https://lists.openembedded.org/mt/105226831/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] pulseaudio: replace "pulseaudio-" with "${PN}-"
On Tue, Mar 19, 2024 at 6:11 PM Daniel Ottiger via
lists.openembedded.org
wrote:
>
> Sure I try as good as I can:
>
> pulseaudio is part of my DISTRO_FEATURES, therefore "libao" depends on
> pulseaudio.
>
> As far as I understand that is because in
> meta-openembedded/meta-multimedia/recipes-multimedia/libao/libao_1.2.0.bb
> I find this lines:
>
> PACKAGECONFIG ?= "${@bb.utils.filter('DISTRO_FEATURES', 'alsa pulseaudio',
> d)}"
> PACKAGECONFIG[alsa] = "--enable-alsa,--disable-alsa,alsa-lib"
> PACKAGECONFIG[pulseaudio] = "--enable-pulse,--disable-pulse,pulseaudio"
>
> In addition vorbis-tools depends on libao, because in
> meta-openembedded/meta-multimedia/recipes-multimedia/vorbis-tools/vorbis-tools_1.4.2.bb
> I find this lines:
>
> PACKAGECONFIG ??= "flac ogg123"
> PACKAGECONFIG[flac] = ",--without-flac,flac,libflac"
> PACKAGECONFIG[speex] = ",--without-speex,speex,speex"
> PACKAGECONFIG[ogg123] = "--enable-ogg123,--disable-ogg123,libao curl"
>
> Therefore if I would like to build
> vorbis-tools-native it requires libao-native which then requires
> pulseaudio-native, at least in my case.
>
> Since I do not know those projects (vorbis-tools, libao) well enough, I
> cannot tell if this dependencies are really required or not.
See:
https://github.com/xiph/libao/blob/master/configure.ac#L448
it's possible to build libao without the output plugin for pulseaudio.
> Of course I would be happy if I can work without pulseaudio for this.
> One solution might be to remove it from my DISTRO_FEATURES, but I cannot see
> how I can do this when I need it on my target.
>
> This is based on this commit of meta-openembedded repository:
>
> commit a8310f7f31acdf273a3f51a75c74cc957375426e (HEAD -> scarthgap,
> yoctoproject/scarthgap, yoctoproject/master)
> Author: Khem Raj
> Date: Sat Mar 16 19:52:58 2024 -0700
>
> layer.conf: Prepare for release, drop nanbield LAYERSERIES
>
> Signed-off-by: Khem Raj
>
> Thanks a lot for looking into this.
> Daniel
>
>
>
> From: Alexander Kanavin
> Sent: 19 March 2024 17:38
> To: Daniel Ottiger
> Cc: openembedded-core@lists.openembedded.org
>
> Subject: Re: [EXTERNAL] Re: [OE-core] [PATCH] pulseaudio: replace
> "pulseaudio-" with "${PN}-"
>
> Please dig a little deeper, and inspect the recipes for vorbis tools and
> libao and their respective source trees. I’m just saying that converting
> compressed audio files shouldn’t be requiring a sound server and it would be
> good to understand why it does.
>
> Alex
>
> On Tue 19. Mar 2024 at 17.30, Daniel Ottiger
> wrote:
>
> If I remove my bbappend file for enabling native compilation, and I try to
> build "vorbis-tools-native" I get the following error:
>
> bitbake vorbis-tools-native
> Parsing recipes: 100%
> |#|
> Time: 0:00:05
> Parsing of 3691 .bb files complete (0 cached, 3691 parsed). 5918 targets,
> 1137 skipped, 0 masked, 0 errors.
> Removing 1 recipes from the x86_64 sysroot: 100%
> |##|
> Time: 0:00:00
> NOTE: Resolving any missing task queue dependencies
> ERROR: Nothing PROVIDES 'pulseaudio-native' (but
> virtual:native:/home/ottigeda/workspace/yocto-builder-scarthgap/meta-openembedded/meta-multimedia/recipes-multimedia/libao/libao_1.2.0.bb
> DEPENDS on or otherwise requires it). Close matches:
> pseudo-native
> pulseaudio
> usbredir-native
>
> In case this is important, I also have meta-openembedded layer
> (https://github.com/openembedded/meta-openembedded) added.
> Maybe the dependency is from there ?
>
> Daniel
>
> From: Alexander Kanavin
> Sent: 19 March 2024 17:14
> To: Daniel Ottiger
> Cc: openembedded-core@lists.openembedded.org
>
> Subject: [EXTERNAL] Re: [OE-core] [PATCH] pulseaudio: replace "pulseaudio-"
> with "${PN}-"
>
> Wait, what do vorbis tools need pulseaudio for? It’s an odd dependency, can
> you check?
>
> Alex
>
> On Tue 19. Mar 2024 at 17.10, Daniel Ottiger via lists.openembedded.org
> wrote:
>
> avoid preferred provider warnings when compiling pulseaudio natively.
>
> Enabling native compilation was done in a separate bbappend file for
> pulseadio:
>
> BBCLASSEXTEND += "native"
>
>
> pulseaudio is a dependency of vorbis-tools,
> from which we like to use the native version of oggenc
> in order to convert wav to ogg files as part of the yocto build.
>
> Signed-off-by: Daniel Ottiger
> ---
> .../pulseaudio/pulseaudio.inc | 78 +--
> 1 file changed, 39 insertions(+), 39 deletions(-)
>
> diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
> b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
> index ae16056d243..85515b3581f 100644
>
Re: [OE-core] [kirkstone][PATCH] stress-ng: avoid calling sync during do_compile
No, I've noticed this when stress-ng and lib32-stress-ng were running
do_compile at the same time and for some reason both sync calls got
stuck, I've killed it when it was running both do_compile tasks for 13
hours (and there was chromium and lib32-chromium do_compile running
for 15+ hours as well (not sure if it was related to this sync or
something else).
On Sun, Mar 17, 2024 at 3:37 PM Randy MacLeod wrote:
>
>
>
> On Sun, Mar 17, 2024, 08:01 Martin Jansa wrote:
>>
>> calling 'sync' from do_compile in the middle of big OE world
>> build harms the build time.
>
>
> No objection from me but do you have a any data on how much an innocuous call
> to sync slows down a build?
>
> Randy
>
>>
>> Signed-off-by: Martin Jansa
>> ---
>> .../0001-Makefile-avoid-calling-sync.patch| 35 +++
>> .../stress-ng/stress-ng_0.13.12.bb| 1 +
>> 2 files changed, 36 insertions(+)
>> create mode 100644
>> meta/recipes-extended/stress-ng/stress-ng-0.13.12/0001-Makefile-avoid-calling-sync.patch
>>
>> diff --git
>> a/meta/recipes-extended/stress-ng/stress-ng-0.13.12/0001-Makefile-avoid-calling-sync.patch
>>
>> b/meta/recipes-extended/stress-ng/stress-ng-0.13.12/0001-Makefile-avoid-calling-sync.patch
>> new file mode 100644
>> index 00..fec8c524eb
>> --- /dev/null
>> +++
>> b/meta/recipes-extended/stress-ng/stress-ng-0.13.12/0001-Makefile-avoid-calling-sync.patch
>> @@ -0,0 +1,35 @@
>> +From 1d1801902a4944c6f5fa521c19b32fbac7342a0c Mon Sep 17 00:00:00 2001
>> +From: Colin Ian King
>> +Date: Sat, 6 Aug 2022 13:05:59 +
>> +Subject: [PATCH] Makefile: avoid calling sync
>> +
>> +Original commit message:
>> +Makefile: use ld-gold if it is available
>> +
>> +Speed up linking by using ld-gold if is available. Add build
>> +time detection to see if compiler allows it
>> +
>> +MJ: backported only the "sync" removal from Makefile as calling
>> +it from do_compile in the middle of big OE world build harms
>> +the build time.
>> +
>> +Upstream-Status: Backport [V0.14.04
>> c10e5c3f9f5560a085279f4c4b399c2f34cb897d]
>> +
>> +Signed-off-by: Colin Ian King
>> +Signed-off-by: Martin Jansa
>> +---
>> + Makefile | 1 -
>> + 1 file changed, 1 deletion(-)
>> +
>> +diff --git a/Makefile b/Makefile
>> +index f8f71c54b..23db4c612 100644
>> +--- a/Makefile
>> b/Makefile
>> +@@ -425,7 +425,6 @@ OBJS += $(CONFIG_OBJS)
>> + stress-ng: $(OBJS)
>> + $(Q)echo "LD $@"
>> + $(V)$(CC) $(CPPFLAGS) $(CFLAGS) $(OBJS) -lm $(LDFLAGS) -o $@
>> +- $(V)sync
>> +
>> + config.h:
>> + +$(MAKE) -f Makefile.config STATIC=$(STATIC) -j
>> diff --git a/meta/recipes-extended/stress-ng/stress-ng_0.13.12.bb
>> b/meta/recipes-extended/stress-ng/stress-ng_0.13.12.bb
>> index 807ecd3466..72dafddaf8 100644
>> --- a/meta/recipes-extended/stress-ng/stress-ng_0.13.12.bb
>> +++ b/meta/recipes-extended/stress-ng/stress-ng_0.13.12.bb
>> @@ -7,6 +7,7 @@ LIC_FILES_CHKSUM =
>> "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
>>
>> SRC_URI =
>> "git://github.com/ColinIanKing/stress-ng.git;protocol=https;branch=master \
>>
>> file://0001-stress-cpu-disable-float128-math-on-powerpc64-to-avo.patch \
>> + file://0001-Makefile-avoid-calling-sync.patch \
>>"
>> SRCREV = "f59bcb2fe1e25042e77d5e4942f72bfa026fa305"
>> S = "${WORKDIR}/git"
>> --
>> 2.44.0
>>
>>
>>
>>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197265):
https://lists.openembedded.org/g/openembedded-core/message/197265
Mute This Topic: https://lists.openembedded.org/mt/104982006/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [kirkstone][PATCH] stress-ng: avoid calling sync during do_compile
calling 'sync' from do_compile in the middle of big OE world
build harms the build time.
Signed-off-by: Martin Jansa
---
.../0001-Makefile-avoid-calling-sync.patch| 35 +++
.../stress-ng/stress-ng_0.13.12.bb| 1 +
2 files changed, 36 insertions(+)
create mode 100644
meta/recipes-extended/stress-ng/stress-ng-0.13.12/0001-Makefile-avoid-calling-sync.patch
diff --git
a/meta/recipes-extended/stress-ng/stress-ng-0.13.12/0001-Makefile-avoid-calling-sync.patch
b/meta/recipes-extended/stress-ng/stress-ng-0.13.12/0001-Makefile-avoid-calling-sync.patch
new file mode 100644
index 00..fec8c524eb
--- /dev/null
+++
b/meta/recipes-extended/stress-ng/stress-ng-0.13.12/0001-Makefile-avoid-calling-sync.patch
@@ -0,0 +1,35 @@
+From 1d1801902a4944c6f5fa521c19b32fbac7342a0c Mon Sep 17 00:00:00 2001
+From: Colin Ian King
+Date: Sat, 6 Aug 2022 13:05:59 +
+Subject: [PATCH] Makefile: avoid calling sync
+
+Original commit message:
+Makefile: use ld-gold if it is available
+
+Speed up linking by using ld-gold if is available. Add build
+time detection to see if compiler allows it
+
+MJ: backported only the "sync" removal from Makefile as calling
+it from do_compile in the middle of big OE world build harms
+the build time.
+
+Upstream-Status: Backport [V0.14.04 c10e5c3f9f5560a085279f4c4b399c2f34cb897d]
+
+Signed-off-by: Colin Ian King
+Signed-off-by: Martin Jansa
+---
+ Makefile | 1 -
+ 1 file changed, 1 deletion(-)
+
+diff --git a/Makefile b/Makefile
+index f8f71c54b..23db4c612 100644
+--- a/Makefile
b/Makefile
+@@ -425,7 +425,6 @@ OBJS += $(CONFIG_OBJS)
+ stress-ng: $(OBJS)
+ $(Q)echo "LD $@"
+ $(V)$(CC) $(CPPFLAGS) $(CFLAGS) $(OBJS) -lm $(LDFLAGS) -o $@
+- $(V)sync
+
+ config.h:
+ +$(MAKE) -f Makefile.config STATIC=$(STATIC) -j
diff --git a/meta/recipes-extended/stress-ng/stress-ng_0.13.12.bb
b/meta/recipes-extended/stress-ng/stress-ng_0.13.12.bb
index 807ecd3466..72dafddaf8 100644
--- a/meta/recipes-extended/stress-ng/stress-ng_0.13.12.bb
+++ b/meta/recipes-extended/stress-ng/stress-ng_0.13.12.bb
@@ -7,6 +7,7 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
SRC_URI =
"git://github.com/ColinIanKing/stress-ng.git;protocol=https;branch=master \
file://0001-stress-cpu-disable-float128-math-on-powerpc64-to-avo.patch \
+ file://0001-Makefile-avoid-calling-sync.patch \
"
SRCREV = "f59bcb2fe1e25042e77d5e4942f72bfa026fa305"
S = "${WORKDIR}/git"
--
2.44.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197260):
https://lists.openembedded.org/g/openembedded-core/message/197260
Mute This Topic: https://lists.openembedded.org/mt/104982006/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] insane: add patch-status to default ERROR_QA for all layers
FWIW: meta-virtualization/master is fine since 2023-06-22:
https://git.yoctoproject.org/meta-virtualization/log/?qt=grep=Upstream-Status
There are only 4 new issues currently in master-next:
Missing Upstream-Status tag
(/OE/layers/meta-virtualization/recipes-containers/criu/files/0003-crit-pycriu-build-and-install-wheels.patch)
Missing Upstream-Status tag
(/OE/layers/meta-virtualization/recipes-containers/criu/files/0004-pycriu-attr-pycriu.version.__version__.patch)
Missing Upstream-Status tag
(/OE/layers/meta-virtualization/recipes-containers/criu/files/0005-pycriu-skip-dependency-check-during-build.patch)
Missing Upstream-Status tag
(/OE/layers/meta-virtualization/recipes-extended/virt-manager/virt-manager/0001-setup.py-move-global-args-to-install-args.patch)
Patches missing Upstream-Status: 4 (3%)
Patches with malformed Upstream-Status: 0 (0%)
meta-oe layers were updated a day before that:
https://git.openembedded.org/meta-openembedded/commit/?id=be8c765c7c4ed48404da8fd8e813c9f3ab5ad415
and few times since then:
https://git.openembedded.org/meta-openembedded/log/?qt=grep=Upstream-Status
Some examples in other layers:
https://git.yoctoproject.org/meta-security/log/?qt=grep=Upstream-Status
https://git.yoctoproject.org/meta-raspberrypi/log/?qt=grep=Upstream-Status
https://code.qt.io/cgit/yocto/meta-qt6.git/commit/?id=d65dc4592bc7e836dbe13d37e8e0ba0a4396f4e3
https://github.com/meta-qt5/meta-qt5/commit/2c7ddcefe58099578094c91ed9a2f48f755e2dfa
https://github.com/webosose/meta-webosose/commit/eb4838a019fdbe24a50868f8ab43dd2e6d2ae52f
https://github.com/webosose/meta-webosose/commit/2c78e37ad9ceb9e236c03b44cca5b38e9d9eb2fc
https://github.com/webOS-ports/meta-webos-ports/commit/617a7ee19e9f47d993f308264ff9392ddd9a0678
https://github.com/shift-left-test/meta-shift/commit/45c96ca2adff5015c5e29c854cafeab4d1b43153
https://github.com/kraj/meta-clang/commit/ea117ca52f51224b5a1b9223ac4c3164fc3dcfb6
https://github.com/kraj/meta-clang/commit/26534d0a406caa5652dddcd4c3694d9e925b66aa
https://github.com/OSSystems/meta-browser/commit/760f47527f1cfa757aff7427fdee9e5365a94f1b
https://github.com/OSSystems/meta-browser/commit/a9e3d2b8f29ba4a2a852f30f11943cdc6afb9e60
...
Usually by me (because I had this in ERROR_QA for long time) and I'm
willing to be Upstream-Status monkey for few more days if it helps
getting this approved and resolved in even more layers :).
Cheers,
On Thu, Mar 14, 2024 at 5:17 PM Bruce Ashfield wrote:
>
> On Thu, Mar 14, 2024 at 3:09 AM Martin Jansa wrote:
> >
> > * it's enabled for patches in oe-core for very long time and I was using
> > it for many other layers as well, so most layers should be in good
> > shape
> >
> > * it's also possible to disable it for individual layer as shown
> > by oe-core in:
> >
> > https://git.openembedded.org/openembedded-core/commit/meta/classes-global/insane.bbclass?h=scarthgap=61a881fdbe8b5a21c6276b8a5d06cc30486b1eb3
>
> Most people have heard my opinions on tracking status
> within files themselves (versus the revision control
> system), but that's not the point of my reply (for once!)
>
> Even with the QA error only enabled in oe-core at the
> moment, it is effectively enabled / enforced in all layers
> ... since if someone is building a product and enables
> the QA error .. all layers are going to have to comply
> even if they don't agree (since removing it from
> someone's QA checklist in a layer would probably
> fail yocto compat standards).
>
> The summary of my rambling is: that I lost the debate
> when the check was created and became an error
> in OEcore. So surprisingly, it doesn't really matter to
> me, but I lean towards doing it post release as well.
>
> Bruce
>
>
> >
> > Signed-off-by: Martin Jansa
> > ---
> > meta/classes-global/insane.bbclass | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/meta/classes-global/insane.bbclass
> > b/meta/classes-global/insane.bbclass
> > index e963001d09..9350bfa106 100644
> > --- a/meta/classes-global/insane.bbclass
> > +++ b/meta/classes-global/insane.bbclass
> > @@ -45,11 +45,10 @@ ERROR_QA ?= "dev-so debug-deps dev-deps debug-files
> > arch pkgconfig la \
> > already-stripped installed-vs-shipped ldflags
> > compile-host-path \
> > install-host-path pn-overrides unknown-configure-option \
> > useless-rpaths rpaths staticdev empty-dirs \
> > -patch-fuzz \
> > +patch-fuzz patch-status \
> > "
> > # Add usrmerge QA check based on distro feature
> > ERROR_QA:append = "${@bb.utils.contains('DISTRO_FEATURES', 'usrmerge', '
> > usrmerge', '', d)}"
> > -ERROR_QA:append:layer-core = " patch-status"
> &
Re: [OE-core] [PATCH] insane: add patch-status to default ERROR_QA for all layers
On Thu, Mar 14, 2024 at 4:32 PM Ross Burton wrote: > > On 14 Mar 2024, at 07:09, Martin Jansa via lists.openembedded.org > wrote: > > > > * it's enabled for patches in oe-core for very long time and I was using > > it for many other layers as well, so most layers should be in good > > shape > > > > * it's also possible to disable it for individual layer as shown > > by oe-core in: > > > > https://git.openembedded.org/openembedded-core/commit/meta/classes-global/insane.bbclass?h=scarthgap=61a881fdbe8b5a21c6276b8a5d06cc30486b1eb3 > > This is quite a “strong” change in policy, especially for so late in the > release cycle (post-M3). I’m on the fence but lean towards letting layers > opt-in, instead of forcing it on them and having to opt out. I was expecting some response like that :/. Other layers don't have to release at the same time as oe-core, right? And oe-core itself won't be affected much as it was already applied there. It's easy to resolve (even if it is by adding Pending to .patches without any Upstream-Status) or to opt-out if they really don't care to run one-liner to at least add Pending. Easier than resolving build failures caused by boost upgrade this late in cycle :). Also if we don't add it now, then we might not add it early in next cycle as well, because the layers opposing to fix it, won't probably add it in master branch shortly after branching for scarthgap as well. I'm using this for over a year and regularly sending patches to layers I sometimes build (and when I do I use scripts/contrib/patchreview.py to catch it in all the .patch files, not just the recipes I've built). I don't have strong opinion, I was thinking about sending this only as RFC, but IMHO it's worth considering. Cheers, -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#197113): https://lists.openembedded.org/g/openembedded-core/message/197113 Mute This Topic: https://lists.openembedded.org/mt/104922136/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: add patch-status to default ERROR_QA for all layers
* it's enabled for patches in oe-core for very long time and I was using
it for many other layers as well, so most layers should be in good
shape
* it's also possible to disable it for individual layer as shown
by oe-core in:
https://git.openembedded.org/openembedded-core/commit/meta/classes-global/insane.bbclass?h=scarthgap=61a881fdbe8b5a21c6276b8a5d06cc30486b1eb3
Signed-off-by: Martin Jansa
---
meta/classes-global/insane.bbclass | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/meta/classes-global/insane.bbclass
b/meta/classes-global/insane.bbclass
index e963001d09..9350bfa106 100644
--- a/meta/classes-global/insane.bbclass
+++ b/meta/classes-global/insane.bbclass
@@ -45,11 +45,10 @@ ERROR_QA ?= "dev-so debug-deps dev-deps debug-files arch
pkgconfig la \
already-stripped installed-vs-shipped ldflags compile-host-path \
install-host-path pn-overrides unknown-configure-option \
useless-rpaths rpaths staticdev empty-dirs \
-patch-fuzz \
+patch-fuzz patch-status \
"
# Add usrmerge QA check based on distro feature
ERROR_QA:append = "${@bb.utils.contains('DISTRO_FEATURES', 'usrmerge', '
usrmerge', '', d)}"
-ERROR_QA:append:layer-core = " patch-status"
WARN_QA:append:layer-core = " missing-metadata missing-maintainer"
FAKEROOT_QA = "host-user-contaminated"
--
2.44.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197098):
https://lists.openembedded.org/g/openembedded-core/message/197098
Mute This Topic: https://lists.openembedded.org/mt/104922136/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] Final nanbield release build on March 25, 2024
Hi Steve, I'm not using nanbield, but does https://wiki.yoctoproject.org/wiki/Releases need to be updated? It says "Support for 7 months (until May 2024)" so I was expecting final call for dunfell (which says "Long Term Support (until Apr. 2024¹)) before nanbield. Regards, On Sun, Mar 10, 2024 at 5:11 PM Steve Sakoman wrote: > > If you have any patches you would like to submit for nanbield before > it goes EOL, please do so now! > > I'll be taking patches until around March 18 in preparation for a > March 25 build. > > Steve > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#196901): https://lists.openembedded.org/g/openembedded-core/message/196901 Mute This Topic: https://lists.openembedded.org/mt/104846319/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] ptest: test for PTEST_ENABLED instead of DISTRO_FEATURES
On Sun, Mar 10, 2024 at 3:11 PM Robert P. J. Day wrote:
>
> On Sun, 10 Mar 2024, Alexander Kanavin wrote:
>
> > On Sat, 9 Mar 2024 at 11:29, Robert P. J. Day wrote:
> > > As ptest.bbclass defines the more intuitive ptest-related variable:
> > >
> > > PTEST_ENABLED =
> > > "${@bb.utils.contains('DISTRO_FEATURES', 'ptest', '1', '0', d)}"
> > >
> > > modify a number of obvious recipe ptest checks to use that simpler
> > > form.
> >
> > I disagree. When someone reads a recipe, and sees a variable, the
> > questions that typically come up are:
> >
> > - where is it set
> > - how is it set
> > - what needs to be done to change it.
> >
> > DISTRO_FEATURES wins all three, as it's commonly known and understood
> > facility.
>
> then what is the point of defining PTEST_ENABLED in the first place?
> and using a mixture of both throughout the code base?
I've used PTEST_ENABLED few times to disable ptest support in specific
recipe while it's "by default" enabled through DISTRO_FEATURES.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196887):
https://lists.openembedded.org/g/openembedded-core/message/196887
Mute This Topic: https://lists.openembedded.org/mt/104825491/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] glib-2.0: backport a switch from distutils to packaging in codegen
On Thu, Mar 7, 2024 at 4:48 PM Peter Kjellerstedt
wrote:
>
> We have a lot of recipes that use gdbus-codegen and are now facing this
> problem. To solve it, I have added a gdbus-codegen.bbclass that does:
>
> DEPENDS:append = " glib-2.0-native python3-packaging-native"
>
> inherit python3native
>
> This adds the dependencies needed to use gdbus-codegen, and is similar
> in spirit to pkgconfig.bbclass, which adds the dependencies needed to use
> pkg-config.
>
> I can send a patch to add it to either meta or meta-oe if it sounds
> like this is something that would be useful to others.
I was wondering about the same while changing this, there is already
CODEGEN_PYTHON_RDEPENDS = "python3 python3-packaging python3-xml"
CODEGEN_PYTHON_RDEPENDS:mingw32 = ""
RDEPENDS:${PN}-codegen += "${CODEGEN_PYTHON_RDEPENDS}"
but that won't apply the python3native inherit, unless moving this to
some gdbus-codegen.bbclass as you suggested.
I've already fixed all recipes in meta-oe and our internal layers so I
don't need this anymore, but agree it would be useful.
Regards,
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196808):
https://lists.openembedded.org/g/openembedded-core/message/196808
Mute This Topic: https://lists.openembedded.org/mt/104560766/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] image_types.bbclass: fix vfat image names
LGTM, I'm sorry I've missed it when updating other types.
Signed-off-by: Martin Jansa
On Tue, Mar 5, 2024 at 9:46 AM Taedcke, Christian
wrote:
>
> From: Christian Taedcke
>
> Remove the appended ${IMAGE_NAME_SUFFIX}, since it is already included
> in ${IMAGE_NAME}.
>
> In commit 26d97acc7137 ("image-artifact-names: include
> ${IMAGE_NAME_SUFFIX} directly in both ${IMAGE_NAME} and
> ${IMAGE_LINK_NAME}") ${IMAGE_NAME_SUFFIX} was included into
> ${IMAGE_NAME}. In this commit all other filesystems in
> image_types.bbclass were adapted.
>
> Signed-off-by: Christian Taedcke
> ---
> meta/classes-recipe/image_types.bbclass | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/meta/classes-recipe/image_types.bbclass
> b/meta/classes-recipe/image_types.bbclass
> index 3733bdfc20..1c3a88bd0f 100644
> --- a/meta/classes-recipe/image_types.bbclass
> +++ b/meta/classes-recipe/image_types.bbclass
> @@ -133,8 +133,8 @@ IMAGE_CMD:erofs-lz4hc = "mkfs.erofs -zlz4hc
> ${EXTRA_IMAGECMD} ${IMGDEPLOYDIR}/${
> # can (e.g. device files, symlinks, etc.) and therefore it not suitable for
> all
> # use cases
> oe_mkvfatfs () {
> -mkfs.vfat $@ -C ${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.vfat
> ${ROOTFS_SIZE}
> -mcopy -i "${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.vfat" -vsmpQ
> ${IMAGE_ROOTFS}/* ::/
> +mkfs.vfat $@ -C ${IMGDEPLOYDIR}/${IMAGE_NAME}.vfat ${ROOTFS_SIZE}
> +mcopy -i "${IMGDEPLOYDIR}/${IMAGE_NAME}.vfat" -vsmpQ ${IMAGE_ROOTFS}/*
> ::/
> }
>
> IMAGE_CMD:vfat = "oe_mkvfatfs ${EXTRA_IMAGECMD}"
> --
> 2.34.1
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196629):
https://lists.openembedded.org/g/openembedded-core/message/196629
Mute This Topic: https://lists.openembedded.org/mt/104740857/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] glib-2.0: backport a switch from distutils to packaging in codegen
Yes, it was reproducible on my host gentoo after removing distutils with dev-python/setuptools (and for updated glib-2.0-native after removing dev-python/packaging) Fixes sent: https://patchwork.yoctoproject.org/project/oe/patch/20240227113711.834767-1-martin.ja...@gmail.com/ https://patchwork.yoctoproject.org/project/oe/patch/20240227113711.834767-2-martin.ja...@gmail.com/ Cheers, On Tue, Feb 27, 2024 at 12:58 AM Martin Jansa via lists.openembedded.org wrote: > > Thanks Khem, will try to reproduce tomorrow. Maybe these don't use > CODEGEN_PYTHON_RDEPENDS. > > With this patch backported to kirkstone I've seen glib-2.0-native > failing with the same issue as python3native there doesn't include > python3-packaging. > > Maybe these recipes aren't using python3native and were depending on > packaging from host, will debug tomorrow. > > On Tue, Feb 27, 2024 at 12:16 AM Khem Raj wrote: > > > > I am seeing some build failures which seems to be related to this patch > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/88/builds/3657/steps/15/logs/stdio > > > > | File > > "/home/pokybuild/yocto-worker/meta-oe/build/build/tmp/work/core2-64-poky-linux/gattlib/0.2+git/recipe-sysroot-native/usr/share/glib-2.0/codegen/utils.py", > > line 22, in > > | import packaging.version > > | ModuleNotFoundError: No module named 'packaging' > > > > > > > > | File > > "/home/pokybuild/yocto-worker/meta-oe/build/build/tmp/work/core2-64-poky-linux/networkmanager-fortisslvpn/1.4.0/recipe-sysroot-native/usr/share/glib-2.0/codegen/utils.py", > > line 22, in > > | import packaging.version > > | ModuleNotFoundError: No module named 'packaging' > > | make: *** [Makefile:2081: src/nm-fortisslvpn-pppd-service-dbus.h] > > Error 1 > > > > > > On Sun, Feb 25, 2024 at 1:37 AM Martin Jansa wrote: > > > > > > * to fix build on hosts with python-3.12, now it fails with: > > > > > > Traceback (most recent call last): > > > File "recipe-sysroot-native/usr/bin/gdbus-codegen", line 53, in > > > from codegen import codegen_main > > > File > > > "recipe-sysroot-native/usr/share/glib-2.0/codegen/codegen_main.py", line > > > 29, in > > > from . import dbustypes > > > File "recipe-sysroot-native/usr/share/glib-2.0/codegen/dbustypes.py", > > > line 22, in > > > from . import utils > > > File "recipe-sysroot-native/usr/share/glib-2.0/codegen/utils.py", line > > > 22, in > > > import distutils.version > > > ModuleNotFoundError: No module named 'distutils' > > > CMake Error at CMakeLists.txt:90 (message): > > > Error in generating code for connman interface using gdbus-codegen > > > > > > Signed-off-by: Martin Jansa > > > --- > > > ...deprecated-distutils-module-to-the-p.patch | 34 +++ > > > meta/recipes-core/glib-2.0/glib-2.0_2.78.3.bb | 1 + > > > meta/recipes-core/glib-2.0/glib.inc | 4 +-- > > > 3 files changed, 36 insertions(+), 3 deletions(-) > > > create mode 100644 > > > meta/recipes-core/glib-2.0/glib-2.0/0001-Switch-from-the-deprecated-distutils-module-to-the-p.patch > > > > > > diff --git > > > a/meta/recipes-core/glib-2.0/glib-2.0/0001-Switch-from-the-deprecated-distutils-module-to-the-p.patch > > > > > > b/meta/recipes-core/glib-2.0/glib-2.0/0001-Switch-from-the-deprecated-distutils-module-to-the-p.patch > > > new file mode 100644 > > > index 00..50368ed22c > > > --- /dev/null > > > +++ > > > b/meta/recipes-core/glib-2.0/glib-2.0/0001-Switch-from-the-deprecated-distutils-module-to-the-p.patch > > > @@ -0,0 +1,34 @@ > > > +From 05f0674c93d94fe6b29c1b707980aac469ddcd72 Mon Sep 17 00:00:00 2001 > > > +From: Jordan Williams > > > +Date: Fri, 1 Dec 2023 09:53:50 -0600 > > > +Subject: [PATCH] Switch from the deprecated distutils module to the > > > packaging > > > + module > > > + > > > +The distutils module was removed in Python 3.12. > > > + > > > +Upstream-Status: Backport > > > [https://gitlab.gnome.org/GNOME/glib/-/commit/6ef967a0f930ce37a8c9b5aff969693b34714291] > > > + > > > +Signed-off-by: Martin Jansa > > > +--- > > > + gio/gdbus-2.0/codegen/utils.py | 4 ++-- > > > + 1 file changed, 2 insertions(+), 2 deletions(-) > > > + > > > +diff --git a/gio/gdbus-2.0/codegen/util
Re: [OE-core] [PATCH] glib-2.0: backport a switch from distutils to packaging in codegen
Thanks Khem, will try to reproduce tomorrow. Maybe these don't use CODEGEN_PYTHON_RDEPENDS. With this patch backported to kirkstone I've seen glib-2.0-native failing with the same issue as python3native there doesn't include python3-packaging. Maybe these recipes aren't using python3native and were depending on packaging from host, will debug tomorrow. On Tue, Feb 27, 2024 at 12:16 AM Khem Raj wrote: > > I am seeing some build failures which seems to be related to this patch > > https://autobuilder.yoctoproject.org/typhoon/#/builders/88/builds/3657/steps/15/logs/stdio > > | File > "/home/pokybuild/yocto-worker/meta-oe/build/build/tmp/work/core2-64-poky-linux/gattlib/0.2+git/recipe-sysroot-native/usr/share/glib-2.0/codegen/utils.py", > line 22, in > | import packaging.version > | ModuleNotFoundError: No module named 'packaging' > > > > | File > "/home/pokybuild/yocto-worker/meta-oe/build/build/tmp/work/core2-64-poky-linux/networkmanager-fortisslvpn/1.4.0/recipe-sysroot-native/usr/share/glib-2.0/codegen/utils.py", > line 22, in > | import packaging.version > | ModuleNotFoundError: No module named 'packaging' > | make: *** [Makefile:2081: src/nm-fortisslvpn-pppd-service-dbus.h] Error > 1 > > > On Sun, Feb 25, 2024 at 1:37 AM Martin Jansa wrote: > > > > * to fix build on hosts with python-3.12, now it fails with: > > > > Traceback (most recent call last): > > File "recipe-sysroot-native/usr/bin/gdbus-codegen", line 53, in > > from codegen import codegen_main > > File "recipe-sysroot-native/usr/share/glib-2.0/codegen/codegen_main.py", > > line 29, in > > from . import dbustypes > > File "recipe-sysroot-native/usr/share/glib-2.0/codegen/dbustypes.py", > > line 22, in > > from . import utils > > File "recipe-sysroot-native/usr/share/glib-2.0/codegen/utils.py", line > > 22, in > > import distutils.version > > ModuleNotFoundError: No module named 'distutils' > > CMake Error at CMakeLists.txt:90 (message): > > Error in generating code for connman interface using gdbus-codegen > > > > Signed-off-by: Martin Jansa > > --- > > ...deprecated-distutils-module-to-the-p.patch | 34 +++ > > meta/recipes-core/glib-2.0/glib-2.0_2.78.3.bb | 1 + > > meta/recipes-core/glib-2.0/glib.inc | 4 +-- > > 3 files changed, 36 insertions(+), 3 deletions(-) > > create mode 100644 > > meta/recipes-core/glib-2.0/glib-2.0/0001-Switch-from-the-deprecated-distutils-module-to-the-p.patch > > > > diff --git > > a/meta/recipes-core/glib-2.0/glib-2.0/0001-Switch-from-the-deprecated-distutils-module-to-the-p.patch > > > > b/meta/recipes-core/glib-2.0/glib-2.0/0001-Switch-from-the-deprecated-distutils-module-to-the-p.patch > > new file mode 100644 > > index 00..50368ed22c > > --- /dev/null > > +++ > > b/meta/recipes-core/glib-2.0/glib-2.0/0001-Switch-from-the-deprecated-distutils-module-to-the-p.patch > > @@ -0,0 +1,34 @@ > > +From 05f0674c93d94fe6b29c1b707980aac469ddcd72 Mon Sep 17 00:00:00 2001 > > +From: Jordan Williams > > +Date: Fri, 1 Dec 2023 09:53:50 -0600 > > +Subject: [PATCH] Switch from the deprecated distutils module to the > > packaging > > + module > > + > > +The distutils module was removed in Python 3.12. > > + > > +Upstream-Status: Backport > > [https://gitlab.gnome.org/GNOME/glib/-/commit/6ef967a0f930ce37a8c9b5aff969693b34714291] > > + > > +Signed-off-by: Martin Jansa > > +--- > > + gio/gdbus-2.0/codegen/utils.py | 4 ++-- > > + 1 file changed, 2 insertions(+), 2 deletions(-) > > + > > +diff --git a/gio/gdbus-2.0/codegen/utils.py > > b/gio/gdbus-2.0/codegen/utils.py > > +index 0204610..08f1ba9 100644 > > +--- a/gio/gdbus-2.0/codegen/utils.py > > b/gio/gdbus-2.0/codegen/utils.py > > +@@ -19,7 +19,7 @@ > > + # > > + # Author: David Zeuthen > > + > > +-import distutils.version > > ++import packaging.version > > + import os > > + import sys > > + > > +@@ -166,4 +166,4 @@ def version_cmp_key(key): > > + v = str(key[0]) > > + else: > > + v = "0" > > +-return (distutils.version.LooseVersion(v), key[1]) > > ++return (packaging.version.Version(v), key[1]) > > diff --git a/meta/recipes-core/glib-2.0/glib-2.0_2.78.3.bb > > b/meta/recipes-core/glib-2.0/glib-2.0_2.78.3.bb > > index 42814ba544..6c3e99c641 100644 > > --- a/meta/recipes-core/glib-2.0/glib-2.0_2.78.3.bb > > +++
Re: [OE-core] [PATCH v2 5/5] sanity.bbclass: do not check for presence of distutils
On Wed, Nov 9, 2022 at 9:21 PM Alexander Kanavin wrote:
>
> This will be removed in 3.12 and has been deprecated for a while.
>
> If anything breaks because of its absence on the host, this would
> expose the breakage so it can be fixed.
I've sent a fix for glib-2.0-native yesterday:
https://lists.openembedded.org/g/openembedded-core/message/196136
which is now queued in master-next
> icu source specifically does not refer to distutils anywhere.
yes, that was removed in 65-1 release with
https://github.com/unicode-org/icu/commit/b4d41b0561b6e8de38b99850ce0e4be8ef536bb1
FWIW: in gentoo with python-3.12.1 I can still use distutils (provided
by setuptools):
$ python3.12
Python 3.12.2 (main, Feb 17 2024, 22:28:14) [GCC 13.2.1 20240210] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import distutils
>>>
so I've noticed this issue only after ubuntu-24.04 switched the
default python3 from 3.11 to 3.12 and my Dockerfile was installing
only python3-distutils, not python3-setuptools:
# python3-distutils is needed by few components:
# icu-native, ovmf-native:
#
x86_64-linux/icu-native/64.2-r0/temp/log.do_configure.28031:ModuleNotFoundError:
No module named 'distutils.sysconfig'
# x86_64-linux/ovmf-native/edk2-stable201905-r0/temp/log.do_compile.67451:Python
reported: "No module named 'distutils.util"
# in Ubuntu the python3 package doesn't pull python3-distutils:
# python3 -m distutils.sysconfig
# /usr/bin/python3: No module named distutils.sysconfig
# This issue with icu-native with Yocto 3.0 Zeus was discussed here:
# https://www.yoctoproject.org/pipermail/yocto/2019-October/047169.html
# https://www.mail-archive.com/yocto@yoctoproject.org/msg46284.html
# icu-native/65.1 and newer (in Yocto 3.1 Dunfell) doesn't need
python3-distutils
# anymore, it was removed here:
#
https://github.com/unicode-org/icu/commit/b4d41b0561b6e8de38b99850ce0e4be8ef536bb1
# Re-reported upstream in:
#
http://lists.openembedded.org/pipermail/openembedded-core/2020-March/293984.html
RUN apt-get install -y python3-distutils
Not sure what to do with python-3.12 in kirkstone, icu is fine there
(70.1), ovmf-native should be fine as well (distutils removed in
edk2-stable202108-rc0:
https://github.com/tianocore/edk2/commit/fc50df0d8eb5331b6641daeedd7f05ae75014ece
https://github.com/tianocore/edk2/commit/0b1b0a9674e27c858f05436ed92250f4498245cf
kirkstone has edk2-stable202202)
So we might be able to drop it as well with only that glib-2.0 fix
backported to kirkstone.
+Steve if he agrees with this plan for kirkstone or would prefer not
to support python 3.12 there.
Cheers,
>
> Signed-off-by: Alexander Kanavin
> ---
> meta/classes-global/sanity.bbclass | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/meta/classes-global/sanity.bbclass
> b/meta/classes-global/sanity.bbclass
> index 606444cae1..38f4a4b22f 100644
> --- a/meta/classes-global/sanity.bbclass
> +++ b/meta/classes-global/sanity.bbclass
> @@ -625,11 +625,9 @@ def check_sanity_version_change(status, d):
> # never again until the sanity version or host distrubution id/version
> changes.
>
> # Check the python install is complete. Examples that are often removed
> in
> -# minimal installations: glib-2.0-natives requries # xml.parsers.expat
> and icu
> -# requires distutils.sysconfig.
> +# minimal installations: glib-2.0-natives requries # xml.parsers.expat
> try:
> import xml.parsers.expat
> -import distutils.sysconfig
> except ImportError as e:
> status.addresult('Your Python 3 is not a full install. Please
> install the module %s (see the Getting Started guide for further
> information).\n' % e.name)
>
> --
> 2.30.2
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196218):
https://lists.openembedded.org/g/openembedded-core/message/196218
Mute This Topic: https://lists.openembedded.org/mt/94921928/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] rpm: add PACKAGECONFIG for openmp and disable it by default for native builds
On Mon, Feb 26, 2024 at 3:39 PM Alexander Kanavin wrote: > > This needs to be handled with care. We rely heavily on openmp support in rpm > to speed up rpm operations; adding an option to turn it off is okay, but > actually turning it off is not. That's why it was sent only as RFC, do you want me to re-send v2 RFC with keeping it enabled for native builds or should I wait for more (unlikely) feedback from others? When explicitly enabled for native it might start failing on hosts without openmp (where it was autodetected as disabled until now). I use package_ipk, so from rpm-native I'm using only the rpmdeps. This can surely wait for styhead release (as I'm probably the only one seeing this issue and only with experimental profile). -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#196213): https://lists.openembedded.org/g/openembedded-core/message/196213 Mute This Topic: https://lists.openembedded.org/mt/104582694/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [RFC PATCH] rpm: add PACKAGECONFIG for openmp and disable it by default for native builds
* and keep it enabled in target builds unless libc-musl where it was
disabled since upgrade to 4.15.1 in:
https://git.openembedded.org/openembedded-core/commit/?id=67257ca87c6fa8e6050a20ecea50daf834c7e869
and disable it for native builds to be able to reuse rpm-native
between hosts with libomp and without to avoid do_package failures like:
recipe-sysroot-native/usr/lib/rpm/rpmdeps: error while loading shared
libraries: libgomp.so.1: cannot open shared object file: No such file or
directory
* and on hosts without libomp it fails in do_configure:
| CMake Error at
/OE/build/tmp-glibc/work/x86_64-linux/rpm-native/4.19.1/recipe-sysroot-native/usr/share/cmake-3.28/Modules/FindPackageHandleStandardArgs.cmake:230
(message):
| Could NOT find OpenMP_C (missing: OpenMP_C_FLAGS OpenMP_C_LIB_NAMES)
| (Required is at least version "4.5")
* I've noticed this in new experimental gentoo profiles which don't
enable openmp by default for gcc-13 and newer, see:
https://bugs.gentoo.org/890999
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8189b4b48c25dbd7b330b51b53f9023cdbbb29ec
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=94d882482714698d6d9b765920cd26bbe849336d
I'm not sure what other distributions plan with openmp support in future
(and this profile is just experimental and the decision not to enable
openmp by default might still change), but having the PACKAGECONFIG
at least gives easy way to explicitly enable/disable this in bbappend
openmp is also explicitly disabled in gettext since 2011:
https://git.openembedded.org/openembedded-core/commit/?id=e897103a58ad672cc87d2bab3ec45501ef09f8f1
Signed-off-by: Martin Jansa
---
meta/recipes-devtools/rpm/rpm_4.19.1.bb | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-devtools/rpm/rpm_4.19.1.bb
b/meta/recipes-devtools/rpm/rpm_4.19.1.bb
index 1f8611a29c..477e1c2d62 100644
--- a/meta/recipes-devtools/rpm/rpm_4.19.1.bb
+++ b/meta/recipes-devtools/rpm/rpm_4.19.1.bb
@@ -52,7 +52,7 @@ DEPENDS = "lua libgcrypt file popt xz bzip2 elfutils python3
sqlite3 zstd"
DEPENDS:append:class-native = " file-replacement-native
bzip2-replacement-native"
EXTRA_OECMAKE:append = " -D__CURL:FILEPATH=curl"
-EXTRA_OECMAKE:append:libc-musl = " -DENABLE_NLS=OFF -DENABLE_OPENMP=OFF"
+EXTRA_OECMAKE:append:libc-musl = " -DENABLE_NLS=OFF"
# --sysconfdir prevents rpm from attempting to access machine-specific
configuration in sysroot/etc; we need to have it in rootfs
# --localstatedir prevents rpm from writing its database to native sysroot
when building images
@@ -64,10 +64,15 @@ OECMAKE_GENERATOR = "Unix Makefiles"
BBCLASSEXTEND = "native nativesdk"
-PACKAGECONFIG ??= "internal-openpgp"
+PACKAGECONFIG_OPENMP = "openmp"
+PACKAGECONFIG_OPENMP:libc-musl = ""
+PACKAGECONFIG_OPENMP:class-native = ""
+
+PACKAGECONFIG ??= "internal-openpgp ${PACKAGECONFIG_OPENMP}"
PACKAGECONFIG[plugins] = "-DENABLE_PLUGINS=ON,-DENABLE_PLUGINS=OFF"
PACKAGECONFIG[testsuite] = "-DENABLE_TESTSUITE=ON,-DENABLE_TESTSUITE=OFF"
+PACKAGECONFIG[openmp] = "-DENABLE_OPENMP=ON,-DENABLE_OPENMP=OFF"
# Deprecated! https://fedoraproject.org/wiki/Changes/RpmSequoia
PACKAGECONFIG[internal-openpgp] =
"-DWITH_INTERNAL_OPENPGP=ON,-DWITH_INTERNAL_OPENPGP=OFF"
--
2.44.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196205):
https://lists.openembedded.org/g/openembedded-core/message/196205
Mute This Topic: https://lists.openembedded.org/mt/104582694/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] pixman: explicitly disable openmp in native builds
On Mon, Feb 26, 2024 at 2:32 PM Martin Jansa via
lists.openembedded.org
wrote:
>
> * on some hosts (e.g. on my gentoo after recent update) it detects OpenMP in
> do_configure:
> Run-time dependency OpenMP found: YES 4.5
> but then fails in do_compile as shown in:
> http://errors.yoctoproject.org/Errors/Details/754632/
>
> gcc -o test/fetch-test test/fetch-test.p/fetch-test.c.o
> -LTOPDIR/tmp-glibc/work/x86_64-linux/pixman-native/0.42.2/recipe-sysroot-native/usr/lib
>
> -LTOPDIR/tmp-glibc/work/x86_64-linux/pixman-native/0.42.2/recipe-sysroot-native/lib
> -Wl,--as-needed -Wl,--no-undefined -Wl,--enable-new-dtags
> -Wl,-rpath-link,TOPDIR/tmp-glibc/work/x86_64-linux/pixman-native/0.42.2/recipe-sysroot-native/usr/lib
>
> -Wl,-rpath-link,TOPDIR/tmp-glibc/work/x86_64-linux/pixman-native/0.42.2/recipe-sysroot-native/lib
>
> -Wl,-rpath,TOPDIR/tmp-glibc/work/x86_64-linux/pixman-native/0.42.2/recipe-sysroot-native/usr/lib
>
> -Wl,-rpath,TOPDIR/tmp-glibc/work/x86_64-linux/pixman-native/0.42.2/recipe-sysroot-native/lib
> -Wl,-O1 '-Wl,-rpath,$ORIGIN/../pixman'
> -Wl,-rpath-link,TOPDIR/tmp-glibc/work/x86_64-linux/pixman-native/0.42.2/build/pixman
> -Wl,--start-group test/libtestutils.a pixman/libpixman-1.so.0.42.2 -pthread
> -fopenmp -fopenmp -lm -Wl,--end-group
> gcc: fatal error: cannot read spec file ‘libgomp.spec’: No such file or
> directory
> compilation terminated.
>
> it's only used in tests, so should be safe to disable for native builds
>
> * the check in meson uses /usr/include/omp.h which is provided by libomp
> even when openmp support is disabled in native gcc in gentoo this happned
> after switching from 17.1 profile to 23.0 which doesn't include openmp
> USE flag by default, if you later run depclean it will uninstall libomp
> as well which will fix this conflict in meson's OpenMP autodetection
Just FYI, even after uninstalling libomp you will get do_package failures like:
recipe-sysroot-native/usr/lib/rpm/rpmdeps: error while loading shared
libraries: libgomp.so.1: cannot open shared object file: No such file
or directory
until you manually cleansstate rpm-native to rebuild it without openmp
support (and you need to make sure not to re-use rpm-native from
sstate built on some other host with openmp enabled).
And rebuilding rpm-native without openmp support on host will
currently fail with:
| CMake Error at
/OE/build/tmp-glibc/work/x86_64-linux/rpm-native/4.19.1/recipe-sysroot-native/usr/share/cmake-3.28/Modules/FindPackageHandleStandardArgs.cmake:230
(message):
| Could NOT find OpenMP_C (missing: OpenMP_C_FLAGS OpenMP_C_LIB_NAMES)
| (Required is at least version "4.5")
I'm not sure why openmp ended disabled in 23.0 gentoo profile, looks
like it should still be enabled through make.defaults even for 23.0:
/usr/portage/profiles/releases/17.0/make.defaults:USE="${USE} fortran openmp"
/usr/portage/profiles/use.desc:openmp - Build support for the OpenMP
(support parallel computing), requires >=sys-devel/gcc-4.2 built with
USE="openmp"
/usr/portage/profiles/prefix/linux/make.defaults:USE="${USE} openmp"
might be temporary issue as 23.0 profile is experimental and not for production:
https://wiki.gentoo.org/wiki/Project:Toolchain/23.0_profile_transition
Regards,
> Signed-off-by: Martin Jansa
> ---
> meta/recipes-graphics/xorg-lib/pixman_0.42.2.bb | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/meta/recipes-graphics/xorg-lib/pixman_0.42.2.bb
> b/meta/recipes-graphics/xorg-lib/pixman_0.42.2.bb
> index 8a93f8c0fe..23ae0cbb27 100644
> --- a/meta/recipes-graphics/xorg-lib/pixman_0.42.2.bb
> +++ b/meta/recipes-graphics/xorg-lib/pixman_0.42.2.bb
> @@ -40,6 +40,8 @@ EXTRA_OEMESON:append:class-target:powerpc64le = "
> ${@bb.utils.contains("TUNE_FEA
> EXTRA_OEMESON:append:armv7a =
> "${@bb.utils.contains("TUNE_FEATURES","neon",""," -Dneon=disabled",d)}"
> EXTRA_OEMESON:append:armv7ve =
> "${@bb.utils.contains("TUNE_FEATURES","neon",""," -Dneon=disabled",d)}"
>
> +EXTRA_OEMESON:append:class-native = " -Dopenmp=disabled"
> +
> BBCLASSEXTEND = "native nativesdk"
>
> CVE_STATUS[CVE-2023-37769] = "not-applicable-config: stress-test is an
> uninstalled test"
> --
> 2.44.0
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196203):
https://lists.openembedded.org/g/openembedded-core/message/196203
Mute This Topic: https://lists.openembedded.org/mt/104581651/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] pixman: explicitly disable openmp in native builds
* on some hosts (e.g. on my gentoo after recent update) it detects OpenMP in
do_configure:
Run-time dependency OpenMP found: YES 4.5
but then fails in do_compile as shown in:
http://errors.yoctoproject.org/Errors/Details/754632/
gcc -o test/fetch-test test/fetch-test.p/fetch-test.c.o
-LTOPDIR/tmp-glibc/work/x86_64-linux/pixman-native/0.42.2/recipe-sysroot-native/usr/lib
-LTOPDIR/tmp-glibc/work/x86_64-linux/pixman-native/0.42.2/recipe-sysroot-native/lib
-Wl,--as-needed -Wl,--no-undefined -Wl,--enable-new-dtags
-Wl,-rpath-link,TOPDIR/tmp-glibc/work/x86_64-linux/pixman-native/0.42.2/recipe-sysroot-native/usr/lib
-Wl,-rpath-link,TOPDIR/tmp-glibc/work/x86_64-linux/pixman-native/0.42.2/recipe-sysroot-native/lib
-Wl,-rpath,TOPDIR/tmp-glibc/work/x86_64-linux/pixman-native/0.42.2/recipe-sysroot-native/usr/lib
-Wl,-rpath,TOPDIR/tmp-glibc/work/x86_64-linux/pixman-native/0.42.2/recipe-sysroot-native/lib
-Wl,-O1 '-Wl,-rpath,$ORIGIN/../pixman'
-Wl,-rpath-link,TOPDIR/tmp-glibc/work/x86_64-linux/pixman-native/0.42.2/build/pixman
-Wl,--start-group test/libtestutils.a pixman/libpixman-1.so.0.42.2 -pthread
-fopenmp -fopenmp -lm -Wl,--end-group
gcc: fatal error: cannot read spec file ‘libgomp.spec’: No such file or
directory
compilation terminated.
it's only used in tests, so should be safe to disable for native builds
* the check in meson uses /usr/include/omp.h which is provided by libomp
even when openmp support is disabled in native gcc in gentoo this happned
after switching from 17.1 profile to 23.0 which doesn't include openmp
USE flag by default, if you later run depclean it will uninstall libomp
as well which will fix this conflict in meson's OpenMP autodetection
Signed-off-by: Martin Jansa
---
meta/recipes-graphics/xorg-lib/pixman_0.42.2.bb | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/recipes-graphics/xorg-lib/pixman_0.42.2.bb
b/meta/recipes-graphics/xorg-lib/pixman_0.42.2.bb
index 8a93f8c0fe..23ae0cbb27 100644
--- a/meta/recipes-graphics/xorg-lib/pixman_0.42.2.bb
+++ b/meta/recipes-graphics/xorg-lib/pixman_0.42.2.bb
@@ -40,6 +40,8 @@ EXTRA_OEMESON:append:class-target:powerpc64le = "
${@bb.utils.contains("TUNE_FEA
EXTRA_OEMESON:append:armv7a =
"${@bb.utils.contains("TUNE_FEATURES","neon",""," -Dneon=disabled",d)}"
EXTRA_OEMESON:append:armv7ve =
"${@bb.utils.contains("TUNE_FEATURES","neon",""," -Dneon=disabled",d)}"
+EXTRA_OEMESON:append:class-native = " -Dopenmp=disabled"
+
BBCLASSEXTEND = "native nativesdk"
CVE_STATUS[CVE-2023-37769] = "not-applicable-config: stress-test is an
uninstalled test"
--
2.44.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196201):
https://lists.openembedded.org/g/openembedded-core/message/196201
Mute This Topic: https://lists.openembedded.org/mt/104581651/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] glib-2.0: backport a switch from distutils to packaging in codegen
* to fix build on hosts with python-3.12, now it fails with:
Traceback (most recent call last):
File "recipe-sysroot-native/usr/bin/gdbus-codegen", line 53, in
from codegen import codegen_main
File "recipe-sysroot-native/usr/share/glib-2.0/codegen/codegen_main.py", line
29, in
from . import dbustypes
File "recipe-sysroot-native/usr/share/glib-2.0/codegen/dbustypes.py", line
22, in
from . import utils
File "recipe-sysroot-native/usr/share/glib-2.0/codegen/utils.py", line 22, in
import distutils.version
ModuleNotFoundError: No module named 'distutils'
CMake Error at CMakeLists.txt:90 (message):
Error in generating code for connman interface using gdbus-codegen
Signed-off-by: Martin Jansa
---
...deprecated-distutils-module-to-the-p.patch | 34 +++
meta/recipes-core/glib-2.0/glib-2.0_2.78.3.bb | 1 +
meta/recipes-core/glib-2.0/glib.inc | 4 +--
3 files changed, 36 insertions(+), 3 deletions(-)
create mode 100644
meta/recipes-core/glib-2.0/glib-2.0/0001-Switch-from-the-deprecated-distutils-module-to-the-p.patch
diff --git
a/meta/recipes-core/glib-2.0/glib-2.0/0001-Switch-from-the-deprecated-distutils-module-to-the-p.patch
b/meta/recipes-core/glib-2.0/glib-2.0/0001-Switch-from-the-deprecated-distutils-module-to-the-p.patch
new file mode 100644
index 00..50368ed22c
--- /dev/null
+++
b/meta/recipes-core/glib-2.0/glib-2.0/0001-Switch-from-the-deprecated-distutils-module-to-the-p.patch
@@ -0,0 +1,34 @@
+From 05f0674c93d94fe6b29c1b707980aac469ddcd72 Mon Sep 17 00:00:00 2001
+From: Jordan Williams
+Date: Fri, 1 Dec 2023 09:53:50 -0600
+Subject: [PATCH] Switch from the deprecated distutils module to the packaging
+ module
+
+The distutils module was removed in Python 3.12.
+
+Upstream-Status: Backport
[https://gitlab.gnome.org/GNOME/glib/-/commit/6ef967a0f930ce37a8c9b5aff969693b34714291]
+
+Signed-off-by: Martin Jansa
+---
+ gio/gdbus-2.0/codegen/utils.py | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/gio/gdbus-2.0/codegen/utils.py b/gio/gdbus-2.0/codegen/utils.py
+index 0204610..08f1ba9 100644
+--- a/gio/gdbus-2.0/codegen/utils.py
b/gio/gdbus-2.0/codegen/utils.py
+@@ -19,7 +19,7 @@
+ #
+ # Author: David Zeuthen
+
+-import distutils.version
++import packaging.version
+ import os
+ import sys
+
+@@ -166,4 +166,4 @@ def version_cmp_key(key):
+ v = str(key[0])
+ else:
+ v = "0"
+-return (distutils.version.LooseVersion(v), key[1])
++return (packaging.version.Version(v), key[1])
diff --git a/meta/recipes-core/glib-2.0/glib-2.0_2.78.3.bb
b/meta/recipes-core/glib-2.0/glib-2.0_2.78.3.bb
index 42814ba544..6c3e99c641 100644
--- a/meta/recipes-core/glib-2.0/glib-2.0_2.78.3.bb
+++ b/meta/recipes-core/glib-2.0/glib-2.0_2.78.3.bb
@@ -14,6 +14,7 @@ SRC_URI = "${GNOME_MIRROR}/glib/${SHRT_VER}/glib-${PV}.tar.xz
\
file://0001-Do-not-write-bindir-into-pkg-config-files.patch \
file://0001-meson-Run-atomics-test-on-clang-as-well.patch \
file://0001-gio-tests-resources.c-comment-out-a-build-host-only-.patch \
+
file://0001-Switch-from-the-deprecated-distutils-module-to-the-p.patch \
file://memory-monitor.patch \
file://native-gtkdoc.patch \
"
diff --git a/meta/recipes-core/glib-2.0/glib.inc
b/meta/recipes-core/glib-2.0/glib.inc
index 5a57549d85..fac8875d84 100644
--- a/meta/recipes-core/glib-2.0/glib.inc
+++ b/meta/recipes-core/glib-2.0/glib.inc
@@ -144,9 +144,7 @@ do_install:append:mingw32() {
rm -f ${D}${bindir}/gtester-report
}
-# remove setuptools dependency when usage of distutils is dropped in
-#
https://gitlab.gnome.org/GNOME/glib/-/blob/main/gio/gdbus-2.0/codegen/utils.py
-CODEGEN_PYTHON_RDEPENDS = "python3 python3-setuptools python3-xml"
+CODEGEN_PYTHON_RDEPENDS = "python3 python3-packaging python3-xml"
CODEGEN_PYTHON_RDEPENDS:mingw32 = ""
RDEPENDS:${PN}-codegen += "${CODEGEN_PYTHON_RDEPENDS}"
--
2.43.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196136):
https://lists.openembedded.org/g/openembedded-core/message/196136
Mute This Topic: https://lists.openembedded.org/mt/104560766/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 5/7] lib/oe/buildcfg.py: Add additional git functions
Was there a reason why this wasn't merged in the end (other than being sent
as RFC)?
We're using git describe in webOS for long time (through our bbclass:
https://github.com/webosose/meta-webosose/blob/master/meta-webos/classes/webos_base.bbclass#L114
)
I would be happy to drop it from our bbclass to use this shared function.
Regards,
On Tue, Nov 7, 2023 at 4:27 PM Jermain Horsman
wrote:
> From: Jermain Horsman
>
> Includes a function to determine the default remote.
>
> Signed-off-by: Jermain Horsman
> ---
> meta/lib/oe/buildcfg.py | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/meta/lib/oe/buildcfg.py b/meta/lib/oe/buildcfg.py
> index f9cb0cc74c..2ca654e56e 100644
> --- a/meta/lib/oe/buildcfg.py
> +++ b/meta/lib/oe/buildcfg.py
> @@ -50,6 +50,22 @@ def get_metadata_git_remote_url(path, remote):
> uri = ''
> return uri.strip()
>
> +def get_metadata_git_default_remote(path):
> +remotes = get_metadata_git_remotes(path)
> +if len(remotes) == 1:
> +default_remote = remotes[0]
> +else:
> +try:
> +default_remote, _ = bb.process.run('git config --local
> checkout.defaultRemote', cwd=path)
> +except bb.process.ExecutionError:
> +default_remote = ""
> +if not default_remote:
> +try:
> +default_remote, _ = bb.process.run('git config
> checkout.defaultRemote', cwd=path)
> +except bb.process.ExecutionError:
> +default_remote = ""
> +return default_remote.strip()
> +
> def get_metadata_git_describe(path):
> try:
> describe, _ = bb.process.run('git describe --tags', cwd=path)
> --
> 2.42.0.windows.2
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#195832):
https://lists.openembedded.org/g/openembedded-core/message/195832
Mute This Topic: https://lists.openembedded.org/mt/102444609/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] bb.utils.vercmp_string_op() vs Python 3.12
On Fri, Jan 26, 2024 at 12:14 PM Böszörményi Zoltán
wrote:
> 2024. 01. 26. 11:53 keltezéssel, Martin Jansa írta:
> > > I copied vercmp_string_op() and all others called by it from
> bitbake/lib/bb/utils.py
> > into a new python script.
> >
> > It's not an issue in vercmp_string_op itself,
>
> I already know this.
> Apparently you haven't read my mail fully for the conclusion.
>
I did and you said that you were testing vercmp_string_op in jack, instead
of looking at waf --version.
> but the version value it gets from waf --version isn't just the version
> itself but also
> > SyntaxWarning from waf.
>
> That is not a problem in itself as the preceding call only collects the
> stdout:
>
> result = subprocess.check_output([python, wafbin, '--version'],
> cwd=subsrcdir,
> stderr=subprocess.STDOUT)
>
> SyntaxWarning goes (or should go) to stderr.
>
Which goes to stdout as configured in this call.
After applying
https://gitlab.com/ita1024/waf/-/commit/d2060dfd8af4edb5824153ff24e207b39ecd67a2.patch
to fix:
| DEBUG: Executing shell function do_configure
| Traceback (most recent call last):
| File
"/OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/jack/1.9.22/git/./waf",
line 166, in
| from waflib import Scripting
| File
"/OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/jack/1.9.22/git/waflib/Scripting.py",
line 10, in
| from waflib import Utils, Configure, Logs, Options, ConfigSet,
Context, Errors, Build, Node
| File
"/OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/jack/1.9.22/git/waflib/Configure.py",
line 16, in
| from waflib import ConfigSet, Utils, Options, Logs, Context, Build,
Errors
| File
"/OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/jack/1.9.22/git/waflib/Options.py",
line 14, in
| from waflib import Logs, Utils, Context, Errors
| File
"/OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/jack/1.9.22/git/waflib/Context.py",
line 9, in
| import os, re, imp, sys
| ModuleNotFoundError: No module named 'imp'
martin@jama
/OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/jack/1.9.22/git $ git
diff
diff --git a/waflib/Context.py b/waflib/Context.py
index 761b521f..38ab03f1 100644
--- a/waflib/Context.py
+++ b/waflib/Context.py
@@ -6,10 +6,17 @@
Classes and functions enabling the command system
"""
-import os, re, imp, sys
+import os, re, sys
from waflib import Utils, Errors, Logs
import waflib.Node
+if sys.hexversion > 0x304:
+ import types
+ class imp(object):
+ new_module = lambda x: types.ModuleType(x)
+else:
+ import imp
+
# the following 3 constants are updated on each new release (do not touch)
HEXVERSION=0x2000c00
"""Constant updated on new releases"""
The SyntaxWarning is easily reproducible:
martin@jama
/OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/jack/1.9.22/git $
python3 waf --version
/OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/jack/1.9.22/git/waflib/Context.py:617:
SyntaxWarning: invalid escape sequence '\_'
"""
/OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/jack/1.9.22/git/waflib/Build.py:107:
SyntaxWarning: invalid escape sequence '\*'
"""List of targets to build (default: \*)"""
/OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/jack/1.9.22/git/waflib/Task.py:1047:
SyntaxWarning: invalid escape sequence '\w'
re_cond = re.compile('(?P\w+)|(?P\|)|(?P&)')
/OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/jack/1.9.22/git/waflib/TaskGen.py:730:
SyntaxWarning: invalid escape sequence '\w'
re_m4 = re.compile('@(\w+)@', re.M)
waf 2.0.12 (54841218840ffa34fddf834680a5a17db69caa12)
martin@jama
/OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/jack/1.9.22/git $
python3 --version
Python 3.12.1
When this part is moved into a minimal test case, there is no error at all.
>
> The error only happens inside bitbake and there was no such problem
> with Python 3.11.x or earlier.
>
> Ergo, the problem must be a Python 3.12 issue.
> The actual version here is python3-3.12.1-2.fc39.x86_64 for me.
>
> > So you need to update waf in jack not to trigger SyntaxWarning when waf
> --version is called.
> >
> > On Fri, Jan 26, 2024 at 10:17 AM Zoltan Boszormenyi
> wrote:
> >
> > Hi,
> >
> > Just a FYI.
> >
> > After the bitbake-server getting stuck after bitbake exited
> > with Python 3.12 issue was fixed, here's another one.
> >
> > This time it's semi-reliably triggered by the jack recipe
> > in meta-openembedded:
> >
> > ERROR: jack-1.19.22-r0 do_configure: Error executing a python
> function in
> > exec_func_python() autogenerated:
> >
> > The stack trace of python calls that resulted in this
> exception/failure
Re: [OE-core] bb.utils.vercmp_string_op() vs Python 3.12
See
https://git.openembedded.org/meta-openembedded/commit/?h=kirkstone=8a042b540db5421785edcf21d5114be6358246fd
On Fri, Jan 26, 2024 at 11:53 AM Martin Jansa
wrote:
> > I copied vercmp_string_op() and all others called by it from
> bitbake/lib/bb/utils.py into a new python script.
>
> It's not an issue in vercmp_string_op itself, but the version value it
> gets from waf --version isn't just the version itself but also
> SyntaxWarning from waf.
>
> So you need to update waf in jack not to trigger SyntaxWarning when waf
> --version is called.
>
> On Fri, Jan 26, 2024 at 10:17 AM Zoltan Boszormenyi
> wrote:
>
>> Hi,
>>
>> Just a FYI.
>>
>> After the bitbake-server getting stuck after bitbake exited
>> with Python 3.12 issue was fixed, here's another one.
>>
>> This time it's semi-reliably triggered by the jack recipe
>> in meta-openembedded:
>>
>> ERROR: jack-1.19.22-r0 do_configure: Error executing a python function in
>> exec_func_python() autogenerated:
>>
>> The stack trace of python calls that resulted in this exception/failure
>> was:
>> File: 'exec_func_python() autogenerated', lineno: 2, function:
>> 0001:
>> *** 0002:waf_preconfigure(d)
>> 0003:
>> File:
>> '/home/zozo/test-yocto-4.3-gh/conf/../layers/openembedded-core/meta/classes-recipe/waf.bbclass',
>>
>> lineno: 58, function: waf_preconfigure
>> 0054:wafbin = os.path.join(subsrcdir, 'waf')
>> 0055:try:
>> 0056:result = subprocess.check_output([python, wafbin,
>> '--version'],
>> cwd=subsrcdir, stderr=subprocess.STDOUT)
>> 0057:version = result.decode('utf-8').split()[1]
>> *** 0058:if bb.utils.vercmp_string_op(version, "1.8.7", ">="):
>> 0059:d.setVar("WAF_EXTRA_CONF", "--bindir=${bindir}
>> --libdir=${libdir}")
>> 0060:except subprocess.CalledProcessError as e:
>> 0061:bb.warn("Unable to execute waf --version, exit code
>> %d. Assuming waf
>> version without bindir/libdir support." % e.returncode)
>> 0062:except FileNotFoundError:
>> File: '/home/zozo/test-yocto-4.3-gh/bitbake/lib/bb/utils.py', lineno:
>> 150, function:
>> vercmp_string_op
>> 0146:Compare two versions and check if the specified comparison
>> operator matches
>> the result of the comparison.
>> 0147:This function is fairly liberal about what operators it
>> will accept since
>> there are a variety of styles
>> 0148:depending on the context.
>> 0149:"""
>> *** 0150:res = vercmp_string(a, b)
>> 0151:if op in ('=', '=='):
>> 0152:return res == 0
>> 0153:elif op == '<=':
>> 0154:return res <= 0
>> File: '/home/zozo/test-yocto-4.3-gh/bitbake/lib/bb/utils.py', lineno:
>> 140, function:
>> vercmp_string
>> 0136:return r
>> 0137:
>> 0138:def vercmp_string(a, b):
>> 0139:""" Split version strings and compare them """
>> *** 0140:ta = split_version(a)
>> 0141:tb = split_version(b)
>> 0142:return vercmp(ta, tb)
>> 0143:
>> 0144:def vercmp_string_op(a, b, op):
>> File: '/home/zozo/test-yocto-4.3-gh/bitbake/lib/bb/utils.py', lineno: 91,
>> function:
>> split_version
>> 0087:"""Split a version string into its constituent parts (PE,
>> PV, PR)"""
>> 0088:s = s.strip(" <>=")
>> 0089:e = 0
>> 0090:if s.count(':'):
>> *** 0091:e = int(s.split(":")[0])
>> 0092:s = s.split(":")[1]
>> 0093:r = ""
>> 0094:if s.count('-'):
>> 0095:r = s.rsplit("-", 1)[1]
>> Exception: ValueError: invalid literal for int() with base 10:
>> 'SyntaxWarning'
>>
>> ERROR: Logfile of failure stored in:
>>
>> /home/zozo/test-yocto-4.3-gh/tmp-sicom-glibc/work/corei7-64-oe-linux/jack/1.19.22/temp/log.do_configure.1709417
>>
>> "Semi-reliably", i.e. about 50-50 or 60-40 percent failure vs success
>> rate.
>> Usually the second run succeeds after a failure.
>>
>> I copied vercmp_string_op() and all others called by it
>> from bitbake/lib/bb/utils.py into a new python script as a
>> minimum test case. Running this script inside a locally
>> cloned jack git repository has 100% success rate.
>>
>> It looks like an internal Python "flake" issue.
>>
>> Best regards,
>> Zoltán Böszörményi
>>
>>
>>
>>
>>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#194350):
https://lists.openembedded.org/g/openembedded-core/message/194350
Mute This Topic: https://lists.openembedded.org/mt/103973063/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] bb.utils.vercmp_string_op() vs Python 3.12
> I copied vercmp_string_op() and all others called by it from
bitbake/lib/bb/utils.py into a new python script.
It's not an issue in vercmp_string_op itself, but the version value it gets
from waf --version isn't just the version itself but also SyntaxWarning
from waf.
So you need to update waf in jack not to trigger SyntaxWarning when waf
--version is called.
On Fri, Jan 26, 2024 at 10:17 AM Zoltan Boszormenyi
wrote:
> Hi,
>
> Just a FYI.
>
> After the bitbake-server getting stuck after bitbake exited
> with Python 3.12 issue was fixed, here's another one.
>
> This time it's semi-reliably triggered by the jack recipe
> in meta-openembedded:
>
> ERROR: jack-1.19.22-r0 do_configure: Error executing a python function in
> exec_func_python() autogenerated:
>
> The stack trace of python calls that resulted in this exception/failure
> was:
> File: 'exec_func_python() autogenerated', lineno: 2, function:
> 0001:
> *** 0002:waf_preconfigure(d)
> 0003:
> File:
> '/home/zozo/test-yocto-4.3-gh/conf/../layers/openembedded-core/meta/classes-recipe/waf.bbclass',
>
> lineno: 58, function: waf_preconfigure
> 0054:wafbin = os.path.join(subsrcdir, 'waf')
> 0055:try:
> 0056:result = subprocess.check_output([python, wafbin,
> '--version'],
> cwd=subsrcdir, stderr=subprocess.STDOUT)
> 0057:version = result.decode('utf-8').split()[1]
> *** 0058:if bb.utils.vercmp_string_op(version, "1.8.7", ">="):
> 0059:d.setVar("WAF_EXTRA_CONF", "--bindir=${bindir}
> --libdir=${libdir}")
> 0060:except subprocess.CalledProcessError as e:
> 0061:bb.warn("Unable to execute waf --version, exit code %d.
> Assuming waf
> version without bindir/libdir support." % e.returncode)
> 0062:except FileNotFoundError:
> File: '/home/zozo/test-yocto-4.3-gh/bitbake/lib/bb/utils.py', lineno: 150,
> function:
> vercmp_string_op
> 0146:Compare two versions and check if the specified comparison
> operator matches
> the result of the comparison.
> 0147:This function is fairly liberal about what operators it
> will accept since
> there are a variety of styles
> 0148:depending on the context.
> 0149:"""
> *** 0150:res = vercmp_string(a, b)
> 0151:if op in ('=', '=='):
> 0152:return res == 0
> 0153:elif op == '<=':
> 0154:return res <= 0
> File: '/home/zozo/test-yocto-4.3-gh/bitbake/lib/bb/utils.py', lineno: 140,
> function:
> vercmp_string
> 0136:return r
> 0137:
> 0138:def vercmp_string(a, b):
> 0139:""" Split version strings and compare them """
> *** 0140:ta = split_version(a)
> 0141:tb = split_version(b)
> 0142:return vercmp(ta, tb)
> 0143:
> 0144:def vercmp_string_op(a, b, op):
> File: '/home/zozo/test-yocto-4.3-gh/bitbake/lib/bb/utils.py', lineno: 91,
> function:
> split_version
> 0087:"""Split a version string into its constituent parts (PE,
> PV, PR)"""
> 0088:s = s.strip(" <>=")
> 0089:e = 0
> 0090:if s.count(':'):
> *** 0091:e = int(s.split(":")[0])
> 0092:s = s.split(":")[1]
> 0093:r = ""
> 0094:if s.count('-'):
> 0095:r = s.rsplit("-", 1)[1]
> Exception: ValueError: invalid literal for int() with base 10:
> 'SyntaxWarning'
>
> ERROR: Logfile of failure stored in:
>
> /home/zozo/test-yocto-4.3-gh/tmp-sicom-glibc/work/corei7-64-oe-linux/jack/1.19.22/temp/log.do_configure.1709417
>
> "Semi-reliably", i.e. about 50-50 or 60-40 percent failure vs success rate.
> Usually the second run succeeds after a failure.
>
> I copied vercmp_string_op() and all others called by it
> from bitbake/lib/bb/utils.py into a new python script as a
> minimum test case. Running this script inside a locally
> cloned jack git repository has 100% success rate.
>
> It looks like an internal Python "flake" issue.
>
> Best regards,
> Zoltán Böszörményi
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#194349):
https://lists.openembedded.org/g/openembedded-core/message/194349
Mute This Topic: https://lists.openembedded.org/mt/103973063/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/1] qemu: Allow native and nativesdk versions on Linux older then 4.17
I did something similar for LGE when we were using 18.04 ubuntu, but IIRC
it's not about the kernel version, but glibc being older than 2.27.
18.04 is already unsupported for a while, I don't think oe-core should
support unsupported host OS versions (that's why I've never send my
version).
To make this change smaller you can just
revert c42e77a90d9244c8caf76fe0e54f84200430a4e1 from qemu.
If oe-core really needs to support this I can share my version as in:
https://github.com/shr-project/meta-webosose/commit/7528c20bf3ba7576d4611f71f987a408ac8845c2
Regards,
On Thu, Jan 25, 2024 at 10:04 PM Mark Hatle
wrote:
> From: Mark Hatle
>
> Linux kernel 4.17 introduced two new mmap flags, MAP_FIXED_NOREPLACE and
> MAP_SHARED_VALIDATE. Starting with QEMU 8.1, these flags are now used
> and required for proper system operation. In order to build and run on a
> system older then 4.17, we need to emulate this new behavior.
>
> Not having a newer kernel could result in the mmap memory being allocated
> in a way that will cause failures without QEMU checking for these
> conditions. Note, memory allocation issues are rare in my experience so
> this is more of a 'just-in-case' behavior.
>
> SDK_OLDEST_KERNEL is currently set to 3.2.0, the only way this can claim
> that qemu works in an SDK is by checking the return values to emulate
> the expected behavior.
>
> Signed-off-by: Mark Hatle
> Signed-off-by: Mark Hatle
> ---
> meta/recipes-devtools/qemu/qemu.inc | 12 +
> ...round-for-missing-MAP_FIXED_NOREPLAC.patch | 286 ++
> ...round-for-missing-MAP_SHARED_VALIDAT.patch | 51
> 3 files changed, 349 insertions(+)
> create mode 100644
> meta/recipes-devtools/qemu/qemu/0011-linux-user-workaround-for-missing-MAP_FIXED_NOREPLAC.patch
> create mode 100644
> meta/recipes-devtools/qemu/qemu/0012-linux-user-workaround-for-missing-MAP_SHARED_VALIDAT.patch
>
> diff --git a/meta/recipes-devtools/qemu/qemu.inc
> b/meta/recipes-devtools/qemu/qemu.inc
> index ccb2880402..7c31a5aa83 100644
> --- a/meta/recipes-devtools/qemu/qemu.inc
> +++ b/meta/recipes-devtools/qemu/qemu.inc
> @@ -39,6 +39,18 @@ SRC_URI = "
> https://download.qemu.org/${BPN}-${PV}.tar.xz \
> "
> UPSTREAM_CHECK_REGEX = "qemu-(?P\d+(\.\d+)+)\.tar"
>
> +# SDK_OLDEST_KERNEL is set below 4.17, which is the minimum version
> required by QEMU >= 8.1
> +# This is due to two MMAP flags being used at certain points
> +SRC_URI:append:class-nativesdk = " \
> +
> file://0011-linux-user-workaround-for-missing-MAP_FIXED_NOREPLAC.patch \
> +
> file://0012-linux-user-workaround-for-missing-MAP_SHARED_VALIDAT.patch \
> +"
> +
> +# Support building and using native version on pre 4.17 kernels
> +SRC_URI:append:class-native = " \
> +
> file://0011-linux-user-workaround-for-missing-MAP_FIXED_NOREPLAC.patch \
> +
> file://0012-linux-user-workaround-for-missing-MAP_SHARED_VALIDAT.patch \
> +"
>
> SRC_URI[sha256sum] =
> "bf00d2fa12010df8b0ade93371def58e632cb32a6bfdc5f5a0ff8e6a1fb1bf32"
>
> diff --git
> a/meta/recipes-devtools/qemu/qemu/0011-linux-user-workaround-for-missing-MAP_FIXED_NOREPLAC.patch
> b/meta/recipes-devtools/qemu/qemu/0011-linux-user-workaround-for-missing-MAP_FIXED_NOREPLAC.patch
> new file mode 100644
> index 00..8941911fb3
> --- /dev/null
> +++
> b/meta/recipes-devtools/qemu/qemu/0011-linux-user-workaround-for-missing-MAP_FIXED_NOREPLAC.patch
> @@ -0,0 +1,286 @@
> +From fa9bcabe2387bb230ef82d62827ad6f93b8a1e61 Mon Sep 17 00:00:00 2001
> +From: Frederic Konrad
> +Date: Wed, 17 Jan 2024 18:15:06 +
> +Subject: [PATCH 1/2] linux-user/*: workaround for missing
> MAP_FIXED_NOREPLACE
> +
> +QEMU v8.1.0 recently requires MAP_FIXED_NOREPLACE flags implementation
> for mmap.
> +
> +This is missing from ubuntu 18.04, thus this patch catches the mmap calls
> which
> +could use that new flag and forwards them to mmap when MAP_FIXED_NOREPLACE
> +flag isn't set or emulates them by checking the returned address w.r.t the
> +requested address.
> +
> +Signed-off-by: Frederic Konrad
> +Signed-off-by: Francisco Iglesias
> +
> +Upstream-Status: Inappropriate [OE specific]
> +
> +The upstream only supports the last two major releases of an OS. The ones
> +they have declared all have kernel 4.17 or newer.
> +
> +See:
> +https://xilinx.slack.com/archives/D04G2647CTV/p1705074697942019
> +
> +https://www.qemu.org/docs/master/about/build-platforms.html
> +
> + The project aims to support the most recent major version at all times
> for up
> + to five years after its initial release. Support for the previous major
> + version will be dropped 2 years after the new major version is released
> or
> + when the vendor itself drops support, whichever comes first.
> +
> +Signed-off-by: Mark Hatle
> +---
> + linux-user/elfload.c| 7 +++--
> + linux-user/meson.build | 1 +
> + linux-user/mmap-fixed.c | 63 +
> + linux-user/mmap-fixed.h | 39 +
> +
Re: [OE-core] [PATCH V2] tcmode-default.inc: use ?= to set PREFERRED_VERSION_llvm/llvm-native/nativesdk-llvm
-1
This doesn't fix the issue, just makes the work around in other layers a
bit easier to implement. But those other layers will still need to update
whenever llvm recipe version is updated in oe-core which is annoying and
unnecessary.
I have to do the same with LLVM_PREFERRED_VERSION as it was proposed for
oe-core, because I had to apply it in our layer as in:
https://github.com/webosose/meta-webosose/commit/ba43dfb2d9d5256f0fda0127097d794da7fb3af8#diff-47795833863a904c85557a8d6a3cc4528bccac3e02f224bf392197d2f6656c98
but if the same is applied in oe-core then LLVM_PREFERRED_VERSION would be
updated together with llvm recipe upgrades in oe-core and meta-clang users
would get the right LLVMVERSION automatically from meta-clang's layer.conf:
https://github.com/kraj/meta-clang/blob/master/conf/layer.conf#L36
without doing any of these work arounds (other than setting
PREFERRED_PROVIDERS _once_ as described in
https://github.com/kraj/meta-clang/blob/master/README.md#providing-llvm)
NAK
On Tue, Jan 23, 2024 at 3:37 AM Changqing Li
wrote:
> From: Changqing Li
>
> If meta-clang is included, LLVMVERSION might set to version different
> from llvm version in oe-core, and PREFERRED_PROVIDER_llvm set to clang,
> In this condition, following warning is reported:
> WARNING: preferred version 16.0.1 of llvm-native not available (for item
> llvm-native)
> WARNING: versions of llvm-native available: 15.0.7
>
> use ?= to set following configs in order to allow user
> to override the default settings:
> PREFERRED_VERSION_llvm
> PREFERRED_VERSION_llvm-native
> PREFERRED_VERSION_nativesdk-llvm
>
> Signed-off-by: Changqing Li
> ---
> meta/conf/distro/include/tcmode-default.inc | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/meta/conf/distro/include/tcmode-default.inc
> b/meta/conf/distro/include/tcmode-default.inc
> index 3720a4c5b8..0de858d3af 100644
> --- a/meta/conf/distro/include/tcmode-default.inc
> +++ b/meta/conf/distro/include/tcmode-default.inc
> @@ -77,9 +77,9 @@ PREFERRED_VERSION_go-runtime ?= "${GOVERSION}"
> PREFERRED_VERSION_nativesdk-go ?= "${GOVERSION}"
> PREFERRED_VERSION_nativesdk-go-runtime ?= "${GOVERSION}"
>
> -PREFERRED_VERSION_llvm = "${LLVMVERSION}"
> -PREFERRED_VERSION_llvm-native = "${LLVMVERSION}"
> -PREFERRED_VERSION_nativesdk-llvm = "${LLVMVERSION}"
> +PREFERRED_VERSION_llvm ?= "${LLVMVERSION}"
> +PREFERRED_VERSION_llvm-native ?= "${LLVMVERSION}"
> +PREFERRED_VERSION_nativesdk-llvm ?= "${LLVMVERSION}"
>
> # Rust toolchain preferred versions:
>
> --
> 2.25.1
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#194225):
https://lists.openembedded.org/g/openembedded-core/message/194225
Mute This Topic: https://lists.openembedded.org/mt/103902328/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] insane.bbclass: Allow the warning about virtual/ to be disabled
On Mon, Jan 22, 2024 at 3:02 PM Richard Purdie < richard.pur...@linuxfoundation.org> wrote: > On Mon, 2024-01-22 at 06:52 +0100, Peter Kjellerstedt wrote: > > Commit f673d3d239799fb1ab50f4aa5d44187666aa0cd7 introduced a warning for > > virtual/ being used in RPROVIDES and RDEPENDS. Make it possible to > > disable the warning by removing "virtual-slash from WARN_QA. > > > > Signed-off-by: Peter Kjellerstedt > > --- > > meta/classes-global/insane.bbclass | 13 +++-- > > 1 file changed, 7 insertions(+), 6 deletions(-) > > Whilst I can understand why you might want to make this configurable, > I'm not sure if is a great idea since people are just going to turn it > off and continue to ignore it :/. > It also allows to add it to ERROR_QA :). -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#194166): https://lists.openembedded.org/g/openembedded-core/message/194166 Mute This Topic: https://lists.openembedded.org/mt/103881481/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] tcmode-default.inc: use ?= to set PREFERRED_VERSION_llvm/llvm-native/nativesdk-llvm
So please suggest a variable name which Richard will accept as I think it's
easier to use separate variable than overriding all 3
PREFERRED_VERSION_llvm* to version currently in oe-core whenever someone
wants to use meta-clang.
On Mon, Jan 22, 2024 at 1:58 AM Changqing Li
wrote:
> Yes
> On 1/19/24 19:57, Martin Jansa 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.
> Do you need to override the PREFERRED_VERSION_? instead of overriding
> LLVMVERSION?
>
> Aren't you trying to fix what was fixed in proposed change a while ago:
>
> https://patchwork.yoctoproject.org/project/oe-core/patch/20230401163241.354257-1-martin.ja...@gmail.com/
> <https://urldefense.com/v3/__https://patchwork.yoctoproject.org/project/oe-core/patch/20230401163241.354257-1-martin.ja...@gmail.com/__;!!AjveYdw8EvQ!fHtiSeYD8TPEVNtjfDtPZrodZY3GykPPupY5y-fmJHKZ6GInFWbYKkRN5UpNDB4pdgdmAzzT-aah4fEExz_0nBedyN8m3FE$>
>
> On Fri, Jan 19, 2024 at 8:35 AM Changqing Li <
> changqing...@eng.windriver.com> wrote:
>
>> From: Changqing Li
>>
>> use ?= to set following configs in order to allow user
>> to override the default settings:
>> PREFERRED_VERSION_llvm
>> PREFERRED_VERSION_llvm-native
>> PREFERRED_VERSION_nativesdk-llvm
>>
>> Signed-off-by: Changqing Li
>> ---
>> meta/conf/distro/include/tcmode-default.inc
>> <https://urldefense.com/v3/__http://tcmode-default.inc__;!!AjveYdw8EvQ!fHtiSeYD8TPEVNtjfDtPZrodZY3GykPPupY5y-fmJHKZ6GInFWbYKkRN5UpNDB4pdgdmAzzT-aah4fEExz_0nBedwNSyZRE$>
>> | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/meta/conf/distro/include/tcmode-default.inc
>> <https://urldefense.com/v3/__http://tcmode-default.inc__;!!AjveYdw8EvQ!fHtiSeYD8TPEVNtjfDtPZrodZY3GykPPupY5y-fmJHKZ6GInFWbYKkRN5UpNDB4pdgdmAzzT-aah4fEExz_0nBedwNSyZRE$>
>> b/meta/conf/distro/include/tcmode-default.inc
>> <https://urldefense.com/v3/__http://tcmode-default.inc__;!!AjveYdw8EvQ!fHtiSeYD8TPEVNtjfDtPZrodZY3GykPPupY5y-fmJHKZ6GInFWbYKkRN5UpNDB4pdgdmAzzT-aah4fEExz_0nBedwNSyZRE$>
>> index 3720a4c5b8..0de858d3af 100644
>> --- a/meta/conf/distro/include/tcmode-default.inc
>> <https://urldefense.com/v3/__http://tcmode-default.inc__;!!AjveYdw8EvQ!fHtiSeYD8TPEVNtjfDtPZrodZY3GykPPupY5y-fmJHKZ6GInFWbYKkRN5UpNDB4pdgdmAzzT-aah4fEExz_0nBedwNSyZRE$>
>> +++ b/meta/conf/distro/include/tcmode-default.inc
>> <https://urldefense.com/v3/__http://tcmode-default.inc__;!!AjveYdw8EvQ!fHtiSeYD8TPEVNtjfDtPZrodZY3GykPPupY5y-fmJHKZ6GInFWbYKkRN5UpNDB4pdgdmAzzT-aah4fEExz_0nBedwNSyZRE$>
>> @@ -77,9 +77,9 @@ PREFERRED_VERSION_go-runtime ?= "${GOVERSION}"
>> PREFERRED_VERSION_nativesdk-go ?= "${GOVERSION}"
>> PREFERRED_VERSION_nativesdk-go-runtime ?= "${GOVERSION}"
>>
>> -PREFERRED_VERSION_llvm = "${LLVMVERSION}"
>> -PREFERRED_VERSION_llvm-native = "${LLVMVERSION}"
>> -PREFERRED_VERSION_nativesdk-llvm = "${LLVMVERSION}"
>> +PREFERRED_VERSION_llvm ?= "${LLVMVERSION}"
>> +PREFERRED_VERSION_llvm-native ?= "${LLVMVERSION}"
>> +PREFERRED_VERSION_nativesdk-llvm ?= "${LLVMVERSION}"
>>
>> # Rust toolchain preferred versions:
>>
>> --
>> 2.25.1
>>
>>
>>
>>
>>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#194139):
https://lists.openembedded.org/g/openembedded-core/message/194139
Mute This Topic: https://lists.openembedded.org/mt/103826050/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] tcmode-default.inc: use ?= to set PREFERRED_VERSION_llvm/llvm-native/nativesdk-llvm
Do you need to override the PREFERRED_VERSION_? instead of overriding
LLVMVERSION?
Aren't you trying to fix what was fixed in proposed change a while ago:
https://patchwork.yoctoproject.org/project/oe-core/patch/20230401163241.354257-1-martin.ja...@gmail.com/
On Fri, Jan 19, 2024 at 8:35 AM Changqing Li
wrote:
> From: Changqing Li
>
> use ?= to set following configs in order to allow user
> to override the default settings:
> PREFERRED_VERSION_llvm
> PREFERRED_VERSION_llvm-native
> PREFERRED_VERSION_nativesdk-llvm
>
> Signed-off-by: Changqing Li
> ---
> meta/conf/distro/include/tcmode-default.inc | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/meta/conf/distro/include/tcmode-default.inc
> b/meta/conf/distro/include/tcmode-default.inc
> index 3720a4c5b8..0de858d3af 100644
> --- a/meta/conf/distro/include/tcmode-default.inc
> +++ b/meta/conf/distro/include/tcmode-default.inc
> @@ -77,9 +77,9 @@ PREFERRED_VERSION_go-runtime ?= "${GOVERSION}"
> PREFERRED_VERSION_nativesdk-go ?= "${GOVERSION}"
> PREFERRED_VERSION_nativesdk-go-runtime ?= "${GOVERSION}"
>
> -PREFERRED_VERSION_llvm = "${LLVMVERSION}"
> -PREFERRED_VERSION_llvm-native = "${LLVMVERSION}"
> -PREFERRED_VERSION_nativesdk-llvm = "${LLVMVERSION}"
> +PREFERRED_VERSION_llvm ?= "${LLVMVERSION}"
> +PREFERRED_VERSION_llvm-native ?= "${LLVMVERSION}"
> +PREFERRED_VERSION_nativesdk-llvm ?= "${LLVMVERSION}"
>
> # Rust toolchain preferred versions:
>
> --
> 2.25.1
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#194035):
https://lists.openembedded.org/g/openembedded-core/message/194035
Mute This Topic: https://lists.openembedded.org/mt/103826050/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] kmscube: Upgrade to latest revision
On Mon, Jan 8, 2024 at 6:02 PM Fabio Estevam wrote: > Hi Martin, > > On Mon, Jan 8, 2024 at 1:21 PM Martin Jansa > wrote: > > > > Hi, > > > > can you please set PV to something else than "git"? meson.build says > version : '0.0.1' > > Yes, I can do that. > > > The last commit from the new 3 is causing build failure on some setups > without GL/gl.h: > > > > kmscube/git/git $ git log --oneline > ea6c5d1eeefbfb0a1c27ab74a6e4621f1d9adf4c..96d63eb59e34c647cda1cbb489265f8c536ae055 > > 96d63eb kmscube: Add gears mode > > d93842d es: Update to prepare for gears mode > > b076d85 ci: enable MR pipelines > > > > Until "96d63eb kmscube: Add gears mode" it was using only EGL: > > > > kmscube/git/git $ git grep "gl\.h" > > common.h:#include > > cube-gears.c:#include > > esUtil.h:#include > > Does the change below fix (add virtual/libgl to DEPENDS) the problem? > > --- a/meta/recipes-graphics/kmscube/kmscube_git.bb > +++ b/meta/recipes-graphics/kmscube/kmscube_git.bb > @@ -6,7 +6,7 @@ OpenGL or OpenGL ES." > HOMEPAGE = "https://cgit.freedesktop.org/mesa/kmscube/; > LICENSE = "MIT" > SECTION = "graphics" > -DEPENDS = "virtual/libgles3 virtual/libgles2 virtual/egl libdrm > virtual/libgbm" > +DEPENDS = "virtual/libgles3 virtual/libgles2 virtual/egl libdrm > virtual/libgbm virtual/libgl" > > LIC_FILES_CHKSUM = > > "file://kmscube.c;beginline=1;endline=23;md5=8b309d4ee67b7315ff7381270dd631fb" > On this platform it doesn't as GL/gl.h is not available, but it builds fine after replacing GL/gl.h with GLES3/gl3.h (for GL_DEPTH24_STENCIL8). -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#193428): https://lists.openembedded.org/g/openembedded-core/message/193428 Mute This Topic: https://lists.openembedded.org/mt/103368830/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] kmscube: Upgrade to latest revision
Hi, can you please set PV to something else than "git"? meson.build says version : '0.0.1' The last commit from the new 3 is causing build failure on some setups without GL/gl.h: kmscube/git/git $ git log --oneline ea6c5d1eeefbfb0a1c27ab74a6e4621f1d9adf4c..96d63eb59e34c647cda1cbb489265f8c536ae055 96d63eb kmscube: Add gears mode d93842d es: Update to prepare for gears mode b076d85 ci: enable MR pipelines Until "96d63eb kmscube: Add gears mode" it was using only EGL: kmscube/git/git $ git grep "gl\.h" common.h:#include cube-gears.c:#include esUtil.h:#include Regards, On Tue, Dec 26, 2023 at 1:38 PM Fabio Estevam wrote: > From: Fabio Estevam > > Upgrade to the latest kmscube revision. > > Signed-off-by: Fabio Estevam > --- > meta/recipes-graphics/kmscube/kmscube_git.bb | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/meta/recipes-graphics/kmscube/kmscube_git.bb > b/meta/recipes-graphics/kmscube/kmscube_git.bb > index 4cdc0f06bb8b..aab582281ac3 100644 > --- a/meta/recipes-graphics/kmscube/kmscube_git.bb > +++ b/meta/recipes-graphics/kmscube/kmscube_git.bb > @@ -10,7 +10,7 @@ DEPENDS = "virtual/libgles3 virtual/libgles2 virtual/egl > libdrm virtual/libgbm" > > LIC_FILES_CHKSUM = > "file://kmscube.c;beginline=1;endline=23;md5=8b309d4ee67b7315ff7381270dd631fb" > > -SRCREV = "ea6c5d1eeefbfb0a1c27ab74a6e4621f1d9adf4c" > +SRCREV = "96d63eb59e34c647cda1cbb489265f8c536ae055" > SRC_URI = "git:// > gitlab.freedesktop.org/mesa/kmscube;branch=master;protocol=https" > > UPSTREAM_CHECK_COMMITS = "1" > -- > 2.34.1 > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#193422): https://lists.openembedded.org/g/openembedded-core/message/193422 Mute This Topic: https://lists.openembedded.org/mt/103368830/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] sstate-cache-management: Rewrite in python
FWIW: I've compared openembedded-core/scripts/sstate-cache-management.sh -d --cache-dir=sstate-cache with openembedded-core/scripts/sstate-cache-management.py -d --cache-dir=sstate-cache on some older kirkstone and nanbield build dirs and the python version removes _much_ more than the shell version did and it was indeed significantly faster. For kirkstone shell version removed from 145G to 125G and triggering python version after that left only 19G. For nanbield shell version removed from 88G to 77G and triggering python version after that left only 11G. I didn't check if all those sstate archives should have been removed or whether the new python script is supposed to be compatible with older releases, I just needed to free some disk space quickly before triggering new build, so I gave it a try and found the huge difference interesting to share. Details from the 4 runs bellow: kirkstone $ du -hs sstate-cache/; openembedded-core/scripts/sstate-cache-management.sh -d --cache-dir=sstate-cache; du -hs sstate-cache/ 145Gsstate-cache/ Figuring out the archs in the layers ... Done Figuring out the suffixes in the sstate cache dir ... Done The following suffixes have been found in the cache dir: addto_recipe_sysroot bundle_initramfs clean cleansstate compile compile_kernelmodules configure configure_manifest configure_security create_v8_qemu_wrapper deploy deploy_source_date_epoch extra_symlinks fetch flush_pseudodb gcc_stash_builddir generate_qt_config_file generate_toolchain_file generate_webos_localization image image_debugfs_tar image_ext4 image_tar image_wic install kernel_checkout kernel_configcheck kernel_configme kernel_link_images kernel_metadata kernel_version_sanity_check locate_enactjs_appinfo make_icudata mkimage multilib_install package packagedata package_qa package_write_ipk patch populate_lic populate_sysroot preconfigure prepare_recipe_sysroot recipe_qa rootfs rootfs_wicenv shared_workdir sizecheck stash_locale strip symlink_kernsrc transform_kernel unpack validate_branches warn_musl write_config write_qemuboot_conf Figuring out the archs in the sstate cache dir ... Done The following archs have been found in the cache dir: allarch hammerhead_halium qemux86_64 tissot x86_64 ... 14012 out of 67493 files will be removed! ... 14012 files have been removed! 125Gsstate-cache/ kirkstone $ du -hs sstate-cache/; ../scarthgap/openembedded-core/scripts/sstate-cache-management.py -d --cache-dir=sstate-cache; du -hs sstate-cache/ 125Gsstate-cache/ 39927 out of 55994 files will be removed! Do you want to continue (y/n)? y 19G sstate-cache/ nanbield $ du -hs sstate-cache/; openembedded-core/scripts/sstate-cache-management.sh -d --cache-dir=sstate-cache; du -hs sstate-cache/ 88G sstate-cache/ Figuring out the archs in the layers ... Done Figuring out the suffixes in the sstate cache dir ... Done The following suffixes have been found in the cache dir: addto_recipe_sysroot bundle_initramfs clean cleansstate compile compile_kernelmodules configure configure_manifest configure_security create_v8_qemu_wrapper deploy deploy_source_date_epoch extra_symlinks fetch flush_pseudodb gcc_stash_builddir generate_native_toolchain_file generate_qt_config_file generate_toolchain_file generate_webos_localization hack_recipe_sysroot image image_ext4 image_tar image_wic install kernel_checkout kernel_configcheck kernel_configme kernel_link_images kernel_metadata kernel_version_sanity_check locate_enactjs_appinfo make_icudata mkimage multilib_install package package_qa package_write_ipk packagedata patch populate_lic populate_sysroot preconfigure prepare_recipe_sysroot recipe_qa rootfs rootfs_wicenv shared_workdir sizecheck stash_locale strip symlink_kernsrc transform_kernel unpack validate_branches warn_musl write_config write_qemuboot_conf Figuring out the archs in the sstate cache dir ... Done The following archs have been found in the cache dir: allarch qemux86_64 x86_64 ... 14339 out of 73198 files will be removed! ... 14339 files have been removed! 77G sstate-cache/ nanbield $ du -hs sstate-cache/; ../scarthgap/openembedded-core/scripts/sstate-cache-management.py -d --cache-dir=sstate-cache; du -hs sstate-cache/ 77G sstate-cache/ 43490 out of 60639 files will be removed! Do you want to continue (y/n)? y 11G sstate-cache/ On Sat, Dec 23, 2023 at 3:25 PM Alex Kiernan wrote: > This (should be) a drop in replacement for sstate-cache-management.sh. > Signed-off-by: Alex Kiernan > --- > This is hopefully an option compatible drop in for the existing shell > sstate-cache-management script. It's orders of magnitude faster, for > example removing duplicates, with a warmed cache across a more or less > vanilla poky build: > > shell: 24.55s > python: 0.63s > > Running on an NFS mount with 1000s of objects the improvement is even > more marked. > > There are differences in the lists of things which are removed, but all > examples I've found are things where the shell failed to remove things >
Re: [OE-core] bitbake-server does not exit after build ends
On Fri, Jan 5, 2024 at 5:06 PM Martin Jansa via lists.openembedded.org
wrote:
> FWIW: I see the processes running after bitbake exit only in kirkstone and
> only with
> PRSERV_HOST = "localhost:0"
> if I drop PRSERV_HOST then all 3 bitbake-server processes exist together
> with bitbake itself.
>
> luneos-kirkstone $ rm -f bitbake-cookerdaemon.log
> luneos-kirkstone $ ps aux | grep luneos-kirkstone
> martin 4184043 0.0 0.0 9124 2048 pts/4S+ 16:47 0:00 grep
> --colour=auto luneos-kirkstone
> luneos-kirkstone $ bitbake -k zlib-native
> NOTE: Started PRServer with DBfile:
> /OE/build/luneos-kirkstone/cache/prserv.sqlite3, Address: 127.0.0.1:35811,
> PID: 4184924
> Loading cache: 100%
> |##|
> Time: 0:00:04
> Loaded 4570 entries from dependency cache.
> ...
> Sstate summary: Wanted 10 Local 10 Mirrors 0 Missed 0 Current 11 (100%
> match, 100% complete)
> NOTE: Executing Tasks
> NOTE: Tasks Summary: Attempted 92 tasks of which 92 didn't need to be
> rerun and all succeeded.
> NOTE: Writing buildhistory
> NOTE: Writing buildhistory took: 15 seconds
> luneos-kirkstone $ ps aux | grep luneos-kirkstone
> martin 51324 0.0 0.0 9124 2048 pts/4S+ 16:54 0:00 grep
> --colour=auto luneos-kirkstone
> martin 4184584 8.9 0.4 668196 536892 ? Sl 16:47 0:37
> bitbake-server /OE/build/luneos-kirkstone/bitbake/bin/bitbake-server
> decafbad 3 5 /OE/build/luneos-kirkstone/bitbake-cookerdaemon.log
> /OE/build/luneos-kirkstone/bitbake.lock
> /OE/build/luneos-kirkstone/bitbake.sock 0 None 0
> martin 4184924 0.0 0.1 340280 196428 ? S16:47 0:00
> bitbake-server /OE/build/luneos-kirkstone/bitbake/bin/bitbake-server
> decafbad 3 5 /OE/build/luneos-kirkstone/bitbake-cookerdaemon.log
> /OE/build/luneos-kirkstone/bitbake.lock
> /OE/build/luneos-kirkstone/bitbake.sock 0 None 0
> martin 4184927 0.0 0.1 340328 194440 ? S16:47 0:00
> bitbake-server /OE/build/luneos-kirkstone/bitbake/bin/bitbake-server
> decafbad 3 5 /OE/build/luneos-kirkstone/bitbake-cookerdaemon.log
> /OE/build/luneos-kirkstone/bitbake.lock
> /OE/build/luneos-kirkstone/bitbake.sock 0 None 0
>
> luneos-kirkstone $ cat bitbake-cookerdaemon.log
> 4184584 16:47:38.367593 --- Starting bitbake server pid 4184584 at
> 2024-01-05 16:47:38.367526 ---
> 4184584 16:47:38.370315 Started bitbake server pid 4184584
> 4184584 16:47:38.370831 Entering server connection loop
> 4184584 16:47:38.372043 Accepting [ proto=0, laddr=bitbake.sock>] ([])
> 4184584 16:47:38.376431 Processing Client
> 4184584 16:47:38.376633 Connecting Client
> 4184584 16:47:38.377632 Running command ['setFeatures', [2, 1]]
> 4184584 16:47:38.379355 Command Completed
> 4184584 16:47:38.379868 Running command ['updateConfig', {'halt': False,
> 'force': False, 'invalidate_stamp': None, 'dry_run': False,
> 'dump_signatures': [], 'extra_assume_provided': [], 'profile': False,
> 'prefile': [], 'postfile': [], 'server_timeout': None, 'nosetscene': False,
> 'setsceneonly': False, 'skipsetscene': False, 'runall': None, 'runonly':
> None, 'writeeventlog': None, 'build_verbose_shell': False,
> 'build_verbose_stdout': False, 'default_loglevel': 20, 'debug_domains':
> {}}, {'SHELL': '/bin/bash', 'BB_ENV_PASSTHROUGH_ADDITIONS': 'MACHINE DISTRO
> TCMODE TCLIBC http_proxy ftp_proxy https_proxy all_proxy ALL_PROXY no_proxy
> SSH_AGENT_PID SSH_AUTH_SOCK BB_SRCREV_POLICY SDKMACHINE BB_NUMBER_THREADS
> PARALLEL_MAKE GIT_PROXY_COMMAND GIT_PROXY_IGNORE SOCKS5_PASSWD SOCKS5_USER
> WEBOS_DISTRO_BUILD_ID PSEUDO_DISABLED PSEUDO_BUILD', 'DISTRO': 'luneos',
> 'SSH_AUTH_SOCK': '/tmp/ssh-XX2ZxYBo/agent.1893', 'SSH_AGENT_PID':
> '1894', 'PWD': '/OE/build/luneos-kirkstone', 'LOGNAME': 'martin', 'HOME':
> '/home/martin-gentoo', 'MACHINE': 'qemux86-64', 'USER': 'martin', 'PATH':
> '/OE/build/luneos-kirkstone/openembedded-core/scripts:/OE/build/luneos-kirkstone/bitbake/bin:/home/martin-gentoo/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/opt/bin:/usr/lib/llvm/17/bin:/opt/android-sdk-update-manager/tools:/opt/android-sdk-update-manager/platform-tools:/etc/eselect/wine/bin:/usr/lib64/opencascade/bin:/var/lib/snapd/snap/bin',
> 'LC_ALL': 'en_US.UTF-8', 'SESSION_MANAGER':
> 'local/jama:@/tmp/.ICE-unix/1838,unix/jama:/tmp/.ICE-unix/1838',
> 'WINDOWID': '35651587', 'COLORTERM': 'truecolor',
> 'CSF_MDTVTexturesDirectory': '/usr/share/opencascade/resources/Textures',
> 'MACHINES': 'qemux86-64', 'XDG_CONFIG_DIRS': '/etc/xdg', 'LESS': '-R -M
> --shift 5', 'XDG_SESSION_PATH': '/org/freedesktop/DisplayManager/Session1',
> 'XDG_MENU_PREFIX': '
Re: [OE-core] bitbake-server does not exit after build ends
contains[varname].add(node.args[1].s)
/usr/lib/python3.12/asyncio/streams.py:413: ResourceWarning: unclosed
> reader=>>>
warnings.warn(f"unclosed {self!r}", ResourceWarning)
/OE/build/luneos-kirkstone/bitbake/lib/bb/codeparser.py:228:
DeprecationWarning: ast.Str is deprecated and will be removed in Python
3.14; use ast.Constant instead
if isinstance(node.args[0], ast.Str):
/OE/build/luneos-kirkstone/bitbake/lib/bb/codeparser.py:229:
DeprecationWarning: Attribute s is deprecated and will be removed in Python
3.14; use value instead
varname = node.args[0].s
4184584 16:48:37.909973 Processing Client
4184584 16:48:37.910125 Disconnecting Client
4184584 16:48:37.910729 No timeout, exiting.
4184584 16:48:38.011341 Exiting
It is reproducible with nanbield as well and fixed in scarthgap, will
bisect it when time allows.
Regards,
On Sun, Dec 31, 2023 at 11:03 AM Alexander Kanavin
wrote:
> For what it's worth, I am not seeing any of these issues (hanging
> processes after bitbake exit, timeouts on world builds with all
> meta-oe-layers) with python 3.12 provided by buildtools-tarball. The
> issues are probably real, but it's also possible python 3.12 per se is
> not to blame.
>
> It would probably help if you check if what you're seeing occurs with
> python 3.12 from the tarball, which you can build from this branch:
> https://git.yoctoproject.org/poky-contrib/log/?h=akanavin/py3.12
> (the log in the web ui isn't updated yet, I just pushed)
>
> Alex
>
> On Fri, 22 Dec 2023 at 00:06, Randy MacLeod via lists.openembedded.org
> wrote:
> >
> > On 2023-12-21 1:56 p.m., Martin Jansa wrote:
> >
> > On Thu, Dec 21, 2023 at 7:47 PM Randy MacLeod <
> randy.macl...@windriver.com> wrote:
> >>
> >> On 2023-11-28 4:26 a.m., Zoltan Boszormenyi via lists.openembedded.org
> wrote:
> >>
> >> So it's not just Fedora, but Python 3.12 in general.
> >>
> >> Googling for problem with threads + fork reveals that
> >> it is indeed an issue even in C / POSIX: only the thread
> >> executing fork() will become part of the new process,
> >> but not the main process starting the thread or any
> >> other threads from the original process.
> >>
> >> The warning is justified, and apparently the issue
> >> not occurring in bitbake with previous Python versions
> >> is pure luck.
> >>
> >> FYI: Fixed in Fedora 39 if you update to get python-3.12.1-1 or later.
> >
> >
> > But this fixes it only for bitbake master, right?
> >
> > Even master might still have some problems.
> > I can do a simple build of a package but in doing:
> >
> > $ bitbake -k world
> >
> > I see:
> > NOTE: No reply from server in 30s (for command ping at 17:50:35.510798)
> >
> > After some time.
> >
> > I'm not going to try to debug it at this point in the day/year!
> >
> >
> > With bitbake 2.0 used in kirkstone I still see bitbake processes still
> running after the build is finished.
> >
> > I didn't try kirkstone. Maybe Steve has that on his list of things to do
> in his spare time! ;-)
> >
> > ../Randy
> >
> >
> > --
> > # Randy MacLeod
> > # Wind River Linux
> >
> >
> >
> >
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#193369):
https://lists.openembedded.org/g/openembedded-core/message/193369
Mute This Topic: https://lists.openembedded.org/mt/102826186/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: match .rootfs. in image names instead of -image-
On Wed, Jan 3, 2024 at 11:16 AM Mikko Rapeli wrote: > Don't expect image file names to include "-image-" but > expect them to have the ".rootfs." postfix which is the > default. > It's the current default, but whole runqemu won't work when someone changes: meta/classes-recipe/image-artifact-names.bbclass:IMAGE_NAME_SUFFIX ??= ".rootfs" So you should probably read IMAGE_NAME_SUFFIX variable first, but the most likely change someone will have in local.conf would be to drop this suffix and set this to empty and then the check for empty string in basename won't be very useful as well. Regards, -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#193287): https://lists.openembedded.org/g/openembedded-core/message/193287 Mute This Topic: https://lists.openembedded.org/mt/103499438/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [kirkstone][PATCH] elfutils: Disable stringop-overflow warning for build host
From: Khem Raj Some distributions shipping gcc12 end up with stringop-overflow warnings e.g. /usr/include/bits/unistd.h:74:10: error: ‘__pread_alias’ specified size between 9223372036854775813 and 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Werror=stringop-overflow=] 74 | return __glibc_fortify (pread, __nbytes, sizeof (char), | ^~~ Until fixed, lets not treat this warning as hard error MJ: this is needed e.g. on ubuntu 24.04 after gcc was upgraded from 13.2.0-8ubuntu1 to 13.2.0-9ubuntu1 which includes switch _FORTIFY_SOURCE to 3: https://changelogs.ubuntu.com/changelogs/pool/main/g/gcc-13/gcc-13_13.2.0-9ubuntu1/changelog elfutils config.log then shows: configure:6762: checking whether to add -D_FORTIFY_SOURCE=2 to CFLAGS configure:6779: gcc -c -D_FORTIFY_SOURCE=2 -isystem/work/x86_64-linux/elfutils-native/0.186-r0/recipe-sysroot-native/usr/include -O2 -pipe -Werror -isystem/work/x86_64-linux/elfutils-native/0.186-r0/recipe-sysroot-native/usr/include conftest.c >&5 : error: "_FORTIFY_SOURCE" redefined [-Werror] : note: this is the location of the previous definition cc1: all warnings being treated as errors configure:6786: result: no and -D_FORTIFY_SOURCE=2 missing in CFLAGS later causes the above error in do_compile Signed-off-by: Khem Raj Signed-off-by: Richard Purdie Signed-off-by: Martin Jansa --- meta/recipes-devtools/elfutils/elfutils_0.186.bb | 2 ++ 1 file changed, 2 insertions(+) diff --git a/meta/recipes-devtools/elfutils/elfutils_0.186.bb b/meta/recipes-devtools/elfutils/elfutils_0.186.bb index 46ee40cce6..d742a2e14e 100644 --- a/meta/recipes-devtools/elfutils/elfutils_0.186.bb +++ b/meta/recipes-devtools/elfutils/elfutils_0.186.bb @@ -35,6 +35,8 @@ PTEST_ENABLED:libc-musl = "0" EXTRA_OECONF = "--program-prefix=eu-" +BUILD_CFLAGS += "-Wno-error=stringop-overflow" + DEPENDS_BZIP2 = "bzip2-replacement-native" DEPENDS_BZIP2:class-target = "bzip2" -- 2.43.0 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#192887): https://lists.openembedded.org/g/openembedded-core/message/192887 Mute This Topic: https://lists.openembedded.org/mt/103339009/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] bitbake-server does not exit after build ends
On Thu, Dec 21, 2023 at 7:47 PM Randy MacLeod wrote: > On 2023-11-28 4:26 a.m., Zoltan Boszormenyi via lists.openembedded.org > wrote: > > So it's not just Fedora, but Python 3.12 in general. > > Googling for problem with threads + fork reveals that > it is indeed an issue even in C / POSIX: only the thread > executing fork() will become part of the new process, > but not the main process starting the thread or any > other threads from the original process. > > The warning is justified, and apparently the issue > not occurring in bitbake with previous Python versions > is pure luck. > > FYI: Fixed in Fedora 39 if you update to get python-3.12.1-1 or later. > But this fixes it only for bitbake master, right? With bitbake 2.0 used in kirkstone I still see bitbake processes still running after the build is finished. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#192845): https://lists.openembedded.org/g/openembedded-core/message/192845 Mute This Topic: https://lists.openembedded.org/mt/102826186/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] systemtap: upgrade 4.9 -> 5.0
On Mon, Dec 18, 2023 at 7:16 AM Victor Kamensky wrote: > On Thu, Dec 14, 2023 at 6:27 AM Martin Jansa > wrote: > > > > PACKAGECONFIG:remove:pn-elfutils = "debuginfod" > > PACKAGECONFIG:remove:pn-elfutils = "libdebuginfod" > > PACKAGECONFIG:remove:pn-binutils = "debuginfod" > > > > in local.conf is the easiest way to reproduce it. > > > > The one for binutils isn't strictly needed (but target binutils will > fail as well when debuginfod is disabled in elfutils and enabled in > binutils). > > Thanks, Martin. I was able to reproduce it with removing debuginfod > from DISTRO_FEATURES_DEFAULT > > Submitted patches to systemtap mailing list: > https://sourceware.org/pipermail/systemtap/2023q4/027914.html > https://sourceware.org/pipermail/systemtap/2023q4/027915.html > > And to oe-core: > > https://lists.openembedded.org/g/openembedded-core/message/192600?p=%2C%2C%2C20%2C0%2C0%2C0%3A%3Acreated%2C0%2CVictor+Kamensky%2C20%2C2%2C0%2C103238308 > > https://lists.openembedded.org/g/openembedded-core/message/192601?p=%2C%2C%2C20%2C0%2C0%2C0%3A%3Acreated%2C0%2CVictor+Kamensky%2C20%2C2%2C0%2C103238309 > > Appreciate reporting the issue! > Thanks for the fixes! They LGTM. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#192607): https://lists.openembedded.org/g/openembedded-core/message/192607 Mute This Topic: https://lists.openembedded.org/mt/102987514/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] systemtap: upgrade 4.9 -> 5.0
PACKAGECONFIG:remove:pn-elfutils = "debuginfod"
PACKAGECONFIG:remove:pn-elfutils = "libdebuginfod"
PACKAGECONFIG:remove:pn-binutils = "debuginfod"
in local.conf is the easiest way to reproduce it.
The one for binutils isn't strictly needed (but target binutils will fail
as well when debuginfod is disabled in elfutils and enabled in binutils).
On Wed, Dec 13, 2023 at 11:45 PM Martin Jansa via lists.openembedded.org
wrote:
> Hi Victor,
>
> no problem, at least it forced me to enable debuginfod in our builds as
> well (where it wasn't intentionally disabled). Just didn't get enabled when
> it was added to default DISTRO_FEATUREs as we define our own and it wasn't
> using BACKFILL mechanism to enable it in such setups.
>
> Removing debuginfod from DISTRO_FEATURES should be enough to reproduce the
> issue (as it will disable both *debuginfod PACKAGECONFIG options from
> elfutils as well).
>
> I haven't tried, but removing the PACKAGECONFIG just from elfutils will
> probably reproduce it as well (with possibly fewer recipes needing to
> rebuilt). There are 2 PACKAGECONFIGs for this, not sure which one is
> needed, but you can just disable both.
>
> Cheers,
>
> On Wed, Dec 13, 2023 at 10:27 PM Victor Kamensky <
> victor.kamens...@gmail.com> wrote:
>
>> Hi Martin,
>>
>> Sorry about that. I am looking at it now.
>>
>> Do I understand it correctly to reproduce the issue: I need to remove
>> debuginfod (as it is currently on
>> by default) from DISTO_FEATURES and remove debuginfod from elfutils
>> PACKAGECONFIG defaults?
>>
>> Thanks,
>> Victor
>>
>> On Sun, Dec 10, 2023 at 3:16 AM Martin Jansa
>> wrote:
>> >
>> > This seems to be causing:
>> > ../git/util.cxx:51:10: fatal error: elfutils/debuginfod.h: No such file
>> or directory
>> >51 | #include
>> > | ^~~
>> > compilation terminated.
>> > make[2]: *** [Makefile:1389: stap-util.o] Error 1
>> >
>> > on some systems.
>> >
>> > Looks like with
>> https://sourceware.org/git/?p=systemtap.git;a=commit;h=2e67b053e3796ee7cf29a39f9698729b52078406
>> it now enables debuginfod ("AC_MSG_RESULT([yes])" _after_ the
>> PKG_CHECK_MODULES now seems wrong).
>> >
>> > log.do_configure:
>> > checking whether to use debuginfod... checking for debuginfod... no
>> > yes
>> > checking for debuginfod_find_metadata in -ldebuginfod... no
>> >
>> > build $ grep DEBUGINFO config.h
>> > #define HAVE_LIBDEBUGINFOD 1
>> >
>> > config.log (see the strange result yes):
>> > configure:12213: checking whether to use debuginfod
>> > configure:12228: checking for debuginfod
>> > configure:12235: $PKG_CONFIG --exists --print-errors "libdebuginfod >=
>> 0.179"
>> > Package libdebuginfod was not found in the pkg-config search path.
>> > Perhaps you should add the directory containing `libdebuginfod.pc'
>> > to the PKG_CONFIG_PATH environment variable
>> > No package 'libdebuginfod' found
>> > configure:12238: $? = 1
>> > configure:12252: $PKG_CONFIG --exists --print-errors "libdebuginfod >=
>> 0.179"
>> > Package libdebuginfod was not found in the pkg-config search path.
>> > Perhaps you should add the directory containing `libdebuginfod.pc'
>> > to the PKG_CONFIG_PATH environment variable
>> > No package 'libdebuginfod' found
>> > configure:12255: $? = 1
>> > configure:12269: result: no
>> > No package 'libdebuginfod' found
>> > configure:12304: result: yes
>> > configure:12315: checking for debuginfod_find_metadata in -ldebuginfod
>> > configure:12344: ccache aarch64-webos-linux-gcc -mcpu=cortex-a72
>> -march=armv8-a+crc -mbranch-protection=standard -fstack-protector-strong
>> -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security
>> -Werror=return-type
>> --sysroot=/OE/lge/build/webos/scarthgap/BUILD/work/raspberrypi4_64-webos-linux/systemtap/5.0/recipe-sysroot
>> -o conftest -O2 -pipe -g -feliminate-unused-debug-types
>> -fcanon-prefix-map
>> -fmacro-prefix-map=/OE/lge/build/webos/scarthgap/BUILD/work/raspberrypi4_64-webos-linux/systemtap/5.0/git=/usr/src/debug/systemtap/5.0
>> -fdebug-prefix-map=/OE/lge/build/webos/scarthgap/BUILD/work/raspberrypi4_64-webos-linux/systemtap/5.0/git=/usr/src/debug/systemtap/5.0
>> -fmacro-prefix-map=/OE/lge/build/webos/scarthgap/BUILD/work/raspberrypi4_64-webos-linux/systemtap/5.0/build=/usr/src/debug/systemtap/5.0
>> -fdebug-prefix-map
Re: [OE-core] [PATCH 1/3] systemtap: upgrade 4.9 -> 5.0
Hi Victor,
no problem, at least it forced me to enable debuginfod in our builds as
well (where it wasn't intentionally disabled). Just didn't get enabled when
it was added to default DISTRO_FEATUREs as we define our own and it wasn't
using BACKFILL mechanism to enable it in such setups.
Removing debuginfod from DISTRO_FEATURES should be enough to reproduce the
issue (as it will disable both *debuginfod PACKAGECONFIG options from
elfutils as well).
I haven't tried, but removing the PACKAGECONFIG just from elfutils will
probably reproduce it as well (with possibly fewer recipes needing to
rebuilt). There are 2 PACKAGECONFIGs for this, not sure which one is
needed, but you can just disable both.
Cheers,
On Wed, Dec 13, 2023 at 10:27 PM Victor Kamensky
wrote:
> Hi Martin,
>
> Sorry about that. I am looking at it now.
>
> Do I understand it correctly to reproduce the issue: I need to remove
> debuginfod (as it is currently on
> by default) from DISTO_FEATURES and remove debuginfod from elfutils
> PACKAGECONFIG defaults?
>
> Thanks,
> Victor
>
> On Sun, Dec 10, 2023 at 3:16 AM Martin Jansa
> wrote:
> >
> > This seems to be causing:
> > ../git/util.cxx:51:10: fatal error: elfutils/debuginfod.h: No such file
> or directory
> >51 | #include
> > | ^~~
> > compilation terminated.
> > make[2]: *** [Makefile:1389: stap-util.o] Error 1
> >
> > on some systems.
> >
> > Looks like with
> https://sourceware.org/git/?p=systemtap.git;a=commit;h=2e67b053e3796ee7cf29a39f9698729b52078406
> it now enables debuginfod ("AC_MSG_RESULT([yes])" _after_ the
> PKG_CHECK_MODULES now seems wrong).
> >
> > log.do_configure:
> > checking whether to use debuginfod... checking for debuginfod... no
> > yes
> > checking for debuginfod_find_metadata in -ldebuginfod... no
> >
> > build $ grep DEBUGINFO config.h
> > #define HAVE_LIBDEBUGINFOD 1
> >
> > config.log (see the strange result yes):
> > configure:12213: checking whether to use debuginfod
> > configure:12228: checking for debuginfod
> > configure:12235: $PKG_CONFIG --exists --print-errors "libdebuginfod >=
> 0.179"
> > Package libdebuginfod was not found in the pkg-config search path.
> > Perhaps you should add the directory containing `libdebuginfod.pc'
> > to the PKG_CONFIG_PATH environment variable
> > No package 'libdebuginfod' found
> > configure:12238: $? = 1
> > configure:12252: $PKG_CONFIG --exists --print-errors "libdebuginfod >=
> 0.179"
> > Package libdebuginfod was not found in the pkg-config search path.
> > Perhaps you should add the directory containing `libdebuginfod.pc'
> > to the PKG_CONFIG_PATH environment variable
> > No package 'libdebuginfod' found
> > configure:12255: $? = 1
> > configure:12269: result: no
> > No package 'libdebuginfod' found
> > configure:12304: result: yes
> > configure:12315: checking for debuginfod_find_metadata in -ldebuginfod
> > configure:12344: ccache aarch64-webos-linux-gcc -mcpu=cortex-a72
> -march=armv8-a+crc -mbranch-protection=standard -fstack-protector-strong
> -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security
> -Werror=return-type
> --sysroot=/OE/lge/build/webos/scarthgap/BUILD/work/raspberrypi4_64-webos-linux/systemtap/5.0/recipe-sysroot
> -o conftest -O2 -pipe -g -feliminate-unused-debug-types
> -fcanon-prefix-map
> -fmacro-prefix-map=/OE/lge/build/webos/scarthgap/BUILD/work/raspberrypi4_64-webos-linux/systemtap/5.0/git=/usr/src/debug/systemtap/5.0
> -fdebug-prefix-map=/OE/lge/build/webos/scarthgap/BUILD/work/raspberrypi4_64-webos-linux/systemtap/5.0/git=/usr/src/debug/systemtap/5.0
> -fmacro-prefix-map=/OE/lge/build/webos/scarthgap/BUILD/work/raspberrypi4_64-webos-linux/systemtap/5.0/build=/usr/src/debug/systemtap/5.0
> -fdebug-prefix-map=/OE/lge/build/webos/scarthgap/BUILD/work/raspberrypi4_64-webos-linux/systemtap/5.0/build=/usr/src/debug/systemtap/5.0
> -fdebug-prefix-map=/OE/lge/build/webos/scarthgap/BUILD/work/raspberrypi4_64-webos-linux/systemtap/5.0/recipe-sysroot=
> -fmacro-prefix-map=/OE/lge/build/webos/scarthgap/BUILD/work/raspberrypi4_64-webos-linux/systemtap/5.0/recipe-sysroot=
> -fdebug-prefix-map=/OE/lge/build/webos/scarthgap/BUILD/work/raspberrypi4_64-webos-linux/systemtap/5.0/recipe-sysroot-native=
> -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -fcanon-prefix-map
> -fmacro-prefix-map=/OE/lge/build/webos/scarthgap/BUILD/work/raspberrypi4_64-webos-linux/systemtap/5.0/git=/usr/src/debug/systemtap/5.0
> -fdebug-prefix-map=/OE/lge/build/webos/scarthgap/BUILD/work/raspberrypi4_64-webos-linux/systemtap/5.0/git=/usr/src/debug/systemtap/5.0
> -fmacro-prefix-map=/OE/lg
Re: [OE-core] why does using ${AUTOREV} with kernel recipe rebuild every time?
You didn't say which Yocto release that WRL build was using, maybe your
deploy artifacts are changing due to package_get_auto_pr calls or not
excluded DATETIME in your filenames as described in:
https://patchwork.yoctoproject.org/project/oe-core/patch/932d980fb4fcfd3b78183d5bd51adb4f038eee47.1700600804.git.martin.ja...@gmail.com/
unfortunately this whole series
https://patchwork.yoctoproject.org/project/oe-core/list/?series=19541 was
rejected:
https://lists.openembedded.org/g/openembedded-core/message/191101
On Wed, Dec 13, 2023 at 4:54 PM Robert P. J. Day
wrote:
>
> i *know* i should know the answer to this, but someone just showed
> me a build (WRLinux-based, but still relevant) where the linux kernel
> recipe uses:
>
> SRCREV_machine = ${AUTOREV}
>
> which is what one reads in the WRL version of linux-yocto-custom.bb,
> but also makes it clear in that recipe file that that is discouraged.
>
> in any event, this appears to be forcing an entire rebuild of the
> kernel every time, even in the presence of sstate-cache, so the
> obvious question is, what is it about using ${AUTOREV} that defeats
> the use of sstate-cache? apologies if this should be obvious.
>
> rday
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#192308):
https://lists.openembedded.org/g/openembedded-core/message/192308
Mute This Topic: https://lists.openembedded.org/mt/103151800/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] strace: Disable bluetooth support by default
There is missing leading space in suggested:
PACKAGECONFIG:append:pn-strace = "bluez"
On Wed, Dec 13, 2023 at 8:43 AM Yoann Congal wrote:
> The bluetooth support adds a bluez5 dependency (and,recursively, a lot
> of other stuff). Disable it by default to avoid having to build all of
> this when it is not needed.
>
> This decrease the number of tasks run for a core-image-minimal build by
> ~1000 (-21%).
>
> To re-enable bluetooth support in strace, add "bluez" to strace
> PACKAGECONFIG. For example, in local.conf:
> PACKAGECONFIG:append:pn-strace = "bluez"
>
> Fixes [YOCTO #15323]
>
> Signed-off-by: Yoann Congal
> Suggested-by: Ross Burton
> ---
> v1->v2:
> * Fixed local.conf example (thanks Tim)
> * Added Suggested-by: Ross (thanks Ross)
> * Removed an extra empty line
> ---
> meta/recipes-devtools/strace/strace_6.6.bb | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/meta/recipes-devtools/strace/strace_6.6.bb
> b/meta/recipes-devtools/strace/strace_6.6.bb
> index a3de7941cf..eeffe477b3 100644
> --- a/meta/recipes-devtools/strace/strace_6.6.bb
> +++ b/meta/recipes-devtools/strace/strace_6.6.bb
> @@ -22,10 +22,6 @@ inherit autotools ptest
> # Not yet ported to rv32
> COMPATIBLE_HOST:riscv32 = "null"
>
> -PACKAGECONFIG:class-target ??= "\
> -${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', 'bluez', '', d)}
> \
> -"
> -
> PACKAGECONFIG[bluez] =
> "ac_cv_header_bluetooth_bluetooth_h=yes,ac_cv_header_bluetooth_bluetooth_h=no,bluez5"
> PACKAGECONFIG[libunwind] =
> "--with-libunwind,--without-libunwind,libunwind"
>
> --
> 2.30.2
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#192271):
https://lists.openembedded.org/g/openembedded-core/message/192271
Mute This Topic: https://lists.openembedded.org/mt/103145986/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] systemtap: upgrade 4.9 -> 5.0
This seems to be causing:
../git/util.cxx:51:10: fatal error: elfutils/debuginfod.h: No such file or
directory
51 | #include
| ^~~
compilation terminated.
make[2]: *** [Makefile:1389: stap-util.o] Error 1
on some systems.
Looks like with
https://sourceware.org/git/?p=systemtap.git;a=commit;h=2e67b053e3796ee7cf29a39f9698729b52078406
it now enables debuginfod ("AC_MSG_RESULT([yes])" _after_
the PKG_CHECK_MODULES now seems wrong).
log.do_configure:
checking whether to use debuginfod... checking for debuginfod... no
yes
checking for debuginfod_find_metadata in -ldebuginfod... no
build $ grep DEBUGINFO config.h
#define HAVE_LIBDEBUGINFOD 1
config.log (see the strange result yes):
configure:12213: checking whether to use debuginfod
configure:12228: checking for debuginfod
configure:12235: $PKG_CONFIG --exists --print-errors "libdebuginfod >=
0.179"
Package libdebuginfod was not found in the pkg-config search path.
Perhaps you should add the directory containing `libdebuginfod.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libdebuginfod' found
configure:12238: $? = 1
configure:12252: $PKG_CONFIG --exists --print-errors "libdebuginfod >=
0.179"
Package libdebuginfod was not found in the pkg-config search path.
Perhaps you should add the directory containing `libdebuginfod.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libdebuginfod' found
configure:12255: $? = 1
configure:12269: result: no
No package 'libdebuginfod' found
configure:12304: result: yes
configure:12315: checking for debuginfod_find_metadata in -ldebuginfod
configure:12344: ccache aarch64-webos-linux-gcc -mcpu=cortex-a72
-march=armv8-a+crc -mbranch-protection=standard -fstack-protector-strong
-O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security
-Werror=return-type
--sysroot=/OE/lge/build/webos/scarthgap/BUILD/work/raspberrypi4_64-webos-linux/systemtap/5.0/recipe-sysroot
-o conftest -O2 -pipe -g -feliminate-unused-debug-types -fcanon-prefix-map
-fmacro-prefix-map=/OE/lge/build/webos/scarthgap/BUILD/work/raspberrypi4_64-webos-linux/systemtap/5.0/git=/usr/src/debug/systemtap/5.0
-fdebug-prefix-map=/OE/lge/build/webos/scarthgap/BUILD/work/raspberrypi4_64-webos-linux/systemtap/5.0/git=/usr/src/debug/systemtap/5.0
-fmacro-prefix-map=/OE/lge/build/webos/scarthgap/BUILD/work/raspberrypi4_64-webos-linux/systemtap/5.0/build=/usr/src/debug/systemtap/5.0
-fdebug-prefix-map=/OE/lge/build/webos/scarthgap/BUILD/work/raspberrypi4_64-webos-linux/systemtap/5.0/build=/usr/src/debug/systemtap/5.0
-fdebug-prefix-map=/OE/lge/build/webos/scarthgap/BUILD/work/raspberrypi4_64-webos-linux/systemtap/5.0/recipe-sysroot=
-fmacro-prefix-map=/OE/lge/build/webos/scarthgap/BUILD/work/raspberrypi4_64-webos-linux/systemtap/5.0/recipe-sysroot=
-fdebug-prefix-map=/OE/lge/build/webos/scarthgap/BUILD/work/raspberrypi4_64-webos-linux/systemtap/5.0/recipe-sysroot-native=
-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -fcanon-prefix-map
-fmacro-prefix-map=/OE/lge/build/webos/scarthgap/BUILD/work/raspberrypi4_64-webos-linux/systemtap/5.0/git=/usr/src/debug/systemtap/5.0
-fdebug-prefix-map=/OE/lge/build/webos/scarthgap/BUILD/work/raspberrypi4_64-webos-linux/systemtap/5.0/git=/usr/src/debug/systemtap/5.0
-fmacro-prefix-map=/OE/lge/build/webos/scarthgap/BUILD/work/raspberrypi4_64-webos-linux/systemtap/5.0/build=/usr/src/debug/systemtap/5.0
-fdebug-prefix-map=/OE/lge/build/webos/scarthgap/BUILD/work/raspberrypi4_64-webos-linux/systemtap/5.0/build=/usr/src/debug/systemtap/5.0
-fdebug-prefix-map=/OE/lge/build/webos/scarthgap/BUILD/work/raspberrypi4_64-webos-linux/systemtap/5.0/recipe-sysroot=
-fmacro-prefix-map=/OE/lge/build/webos/scarthgap/BUILD/work/raspberrypi4_64-webos-linux/systemtap/5.0/recipe-sysroot=
-fdebug-prefix-map=/OE/lge/build/webos/scarthgap/BUILD/work/raspberrypi4_64-webos-linux/systemtap/5.0/recipe-sysroot-native=
-Wl,-z,relro,-z,now conftest.c -ldebuginfod >&5
/OE/lge/build/webos/scarthgap/BUILD/work/raspberrypi4_64-webos-linux/systemtap/5.0/recipe-sysroot-native/usr/bin/aarch64-webos-linux/../../libexec/aarch64-webos-linux/gcc/aarch64-webos-linux/13.2.0/ld:
cannot find -ldebuginfod: No such file or directory
collect2: error: ld returned 1 exit status
With debuginfod in DISTRO_FEATURES (which is included by default) and
*debuginfod PACKAGECONFIG enabled in elfutils (also by default based on
DISTRO_FEAUTRES) this builds OK.
Regards,
On Tue, Dec 5, 2023 at 7:33 AM Victor Kamensky
wrote:
> Similar to 4.9 release, in 5.0 release release-5.0 tag is off any branch,
> release-5.0a tag e72dc118e563c645d93a1a2d771e8d90e8fec1ae is on the master
> branch. Use this value for SRCREV and add catch up patch,
> 0001-prerelease-datestamp-fixes.patch, to bring source up to release-5.0
> tag
> level. Remove 0001-prerelease-datestamp-fixes.patch in next upgrade.
>
> Signed-off-by: Victor Kamensky
> ---
> .../0001-prerelease-datestamp-fixes.patch | 23
Re: [OE-core] packagegroup-base.bb override syntax
Because this line is wrong and should be removed completely. Please send a
patch removing it.
On Sun, Dec 3, 2023 at 12:24 PM Vincent Prince
wrote:
> Hello,
>
> I just came back to Yocto after several years of pause, I see that
> there is a new override syntax, and I'm wondering why the following
> line is not changed ?
>
>
> https://git.openembedded.org/openembedded-core/tree/meta/recipes-core/packagegroups/packagegroup-base.bb?h=master-next#n125
>
> DEPENDS_packagegroup-distro-base = "${DISTRO_EXTRA_DEPENDS}"
>
> (and not DEPENDS:packagegroup-distro-base)
>
> Sorry by advance if this question has trivial response
>
> Best regards,
> Vincent
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#191711):
https://lists.openembedded.org/g/openembedded-core/message/191711
Mute This Topic: https://lists.openembedded.org/mt/102949698/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 09/14] image-artifact-names: add IMAGE_MACHINE_SUFFIX variable
Hi Paul,
this was fixed in:
https://patchwork.yoctoproject.org/project/oe-core/list/?series=19541
please check it and share your opinion about these changes, otherwise it
won't get merged and https://bugzilla.yoctoproject.org/show_bug.cgi?id=12937
will be closed as "won't fix".
Cheers,
On Thu, May 11, 2023 at 9:41 AM Martin Jansa wrote:
> Hi Paul,
>
> I'm sorry about that, will make sure this is supported again in final
> state with all [YOCTO #12937] changes where the *_NAME and *_LINK_NAME
> variables are reversed:
>
> -IMAGE_NAME ?= "${IMAGE_LINK_NAME}${IMAGE_VERSION_SUFFIX}"
> -IMAGE_LINK_NAME ?=
> "${IMAGE_BASENAME}${IMAGE_MACHINE_SUFFIX}${IMAGE_NAME_SUFFIX}"
> +IMAGE_NAME ?=
> "${IMAGE_BASENAME}${IMAGE_MACHINE_SUFFIX}${IMAGE_NAME_SUFFIX}"
> +IMAGE_LINK_NAME ?= "${IMAGE_NAME}${IMAGE_VERSION_SUFFIX}"
>
> and versioned hardlinks (instead of symlinks) *_LINK_NAME are created by
> separate task. Which will respect *_LINK_NAME variables being set to empty
> to disable creating them.
>
> I've just added another commit to my [YOCTO #12937] staging branch
> https://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/artifacts
> to respect empty *_LINK_NAME variables also for kernel artifacts.
>
> Cheers,
>
> On Wed, Apr 19, 2023 at 12:43 AM Paul Eggleton <
> bluelightn...@bluelightning.org> wrote:
>
>> Hi Martin
>>
>> On Tuesday, 14 March 2023 01:15:36 NZST Martin Jansa wrote:
>> > * to make it easier for projects to avoid default -${MACHINE} suffix if
>> > the ${MACHINE} named DEPLOY_DIR_IMAGE works better for them
>> >
>> > * also use IMAGE_LINK_NAME in IMAGE_NAME to make it more clear
>> > that IMAGE_NAME is the same as IMAGE_LINK_NAME but with version
>> > suffix
>> >
>> > * adding it as separate variable helps us to catch the cases
>> > where we didn't respect ${IMAGE_LINK_NAME} variable and just used
>> > the common default ${IMAGE_BASENAME}-${MACHINE}.
>> >
>> > [YOCTO #12937]
>> >
>> > Signed-off-by: Martin Jansa
>> > ---
>> > meta/classes-recipe/image-artifact-names.bbclass | 15 ---
>> > meta/classes-recipe/kernel-artifact-names.bbclass | 2 +-
>> > 2 files changed, 13 insertions(+), 4 deletions(-)
>> >
>> > diff --git a/meta/classes-recipe/image-artifact-names.bbclass
>> > b/meta/classes-recipe/image-artifact-names.bbclass index
>> > 9dc25b6dde..ac2376d59a 100644
>> > --- a/meta/classes-recipe/image-artifact-names.bbclass
>> > +++ b/meta/classes-recipe/image-artifact-names.bbclass
>> > @@ -11,11 +11,20 @@
>> > IMAGE_BASENAME ?= "${PN}"
>> > IMAGE_VERSION_SUFFIX ?= "-${DATETIME}"
>> > IMAGE_VERSION_SUFFIX[vardepsexclude] += "DATETIME SOURCE_DATE_EPOCH"
>> > -IMAGE_NAME ?= "${IMAGE_BASENAME}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
>> > -IMAGE_LINK_NAME ?= "${IMAGE_BASENAME}-${MACHINE}"
>> > +IMAGE_NAME ?= "${IMAGE_LINK_NAME}${IMAGE_VERSION_SUFFIX}"
>> > +IMAGE_LINK_NAME ?= "${IMAGE_BASENAME}${IMAGE_MACHINE_SUFFIX}"
>>
>> So there's a minor unfortunate side-effect of this in that you can no
>> longer
>> just set IMAGE_LINK_NAME = "" to drop the symlinks - a minority use case,
>> but
>> something I have used. Of course you can just re-set the value of
>> IMAGE_NAME.
>> I am making a note in the manual and migration guide.
>>
>> Cheers
>> Paul
>>
>>
>>
>>
>>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#191355):
https://lists.openembedded.org/g/openembedded-core/message/191355
Mute This Topic: https://lists.openembedded.org/mt/97578959/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] bitbake-server does not exit after build ends
I can confirm the same on gentoo with python-3.12.
On Mon, Nov 27, 2023 at 12:29 PM Zoltan Boszormenyi
wrote:
> 2023. 11. 27. 11:52 keltezéssel, Richard Purdie írta:
> > Is there anything interesting in the bitbake-cookerdaemon.log file?
>
> Actually, yes.
>
> This is obviously the most suspicious:
>
> /usr/lib64/python3.12/multiprocessing/popen_fork.py:66:
> DeprecationWarning: This process
> (pid=1605202) is multi-threaded, use of fork() may lead to deadlocks in
> the child.
>self.pid = os.fork()
> /home/zozo/test-yocto-4.3/bitbake/bin/bitbake-worker:210:
> DeprecationWarning: This process
> (pid=1605590) is multi-threaded, use of fork() may lead to deadlocks in
> the child.
>pid = os.fork()
> /home/zozo/test-yocto-4.3/bitbake/bin/bitbake-worker:210:
> DeprecationWarning: This process
> (pid=1607833) is multi-threaded, use of fork() may lead to deadlocks in
> the child.
>pid = os.fork()
>
> There are a few other deprecation warnings, too,
> which are not relevant to this particular problem
> but may be interesting for the future, nevertheless:
>
> /home/zozo/test-yocto-4.3/bitbake/lib/bb/codeparser.py:260:
> DeprecationWarning: ast.Str is
> deprecated and will be removed in Python 3.14; use ast.Constant instead
>if name in self.containsfuncs and isinstance(node.args[1], ast.Str):
> /home/zozo/test-yocto-4.3/bitbake/lib/bb/codeparser.py:263:
> DeprecationWarning: Attribute
> s is deprecated and will be removed in Python 3.14; use value instead
>self.contains[varname].add(node.args[1].s)
>
> ruby.bbclass has a lot of these at different line numbers:
>
> /home/zozo/test-yocto-4.3/conf/../layers/meta-cloud-services/classes/ruby.bbclass:28:
>
> SyntaxWarning: invalid escape sequence '\.'
>r = re.compile("ruby ([0-9]+\.[0-9]+\.[0-9]+)*")
>
> These lines occur at the end (probably normal):
>
> 1605202 10:39:58.854287 Parse cache valid
> 1605202 10:40:13.098694 Registering idle function BBCooker.buildTargets..buildTargetsIdle at 0x7fa3e22e79c0>
> 1605202 10:40:13.098736 Removing idle function Command.runAsyncCommand of
> >
> 1605202 12:17:02.357378 Running command ['stateShutdown']
> 1605202 12:17:02.357622 Sending reply (None, None)
> 1605202 12:17:02.357819 Command Completed (socket: True)
>
> And the remaining child processes:
>
> $ ps auxw | grep bitb | grep -v grep
> zozo 1605202 2.3 3.5 184 1151808 ? Sl 10:39 2:29
> /usr/bin/python3
> /home/zozo/test-yocto-4.3/bitbake/bin/bitbake-server decafbad 3 5
> /home/zozo/test-yocto-4.3/bitbake-cookerdaemon.log
> /home/zozo/test-yocto-4.3/bitbake.lock
> /home/zozo/test-yocto-4.3/bitbake.sock 0 0 None 0
> zozo 1605208 0.0 1.4 559372 466260 ? S10:39 0:00
> /usr/bin/python3
> /home/zozo/test-yocto-4.3/bitbake/bin/bitbake-server decafbad 3 5
> /home/zozo/test-yocto-4.3/bitbake-cookerdaemon.log
> /home/zozo/test-yocto-4.3/bitbake.lock
> /home/zozo/test-yocto-4.3/bitbake.sock 0 0 None 0
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#191298):
https://lists.openembedded.org/g/openembedded-core/message/191298
Mute This Topic: https://lists.openembedded.org/mt/102826186/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] Revert "lzop: remove recipe from oe-core"
On Fri, Nov 24, 2023 at 8:52 AM Alexander Kanavin wrote: > On Thu, 23 Nov 2023 at 22:07, Marek Vasut wrote: > > > The lzop is called in oe-core and I was under the impression that > > oe-core shouldn't depend on anything except bitbake . So either this > > stuff should be moved to meta-oe too (which would be unfortunate growth > > of dependencies) or the lzop should be reinstated . I would obviously be > > in favor of the later. > > There are plenty of recipes in oe-core that have optional features > (enabled via PACKAGECONFIG) that depend on recipes that are not in > core. If you enable them, bitbake will say that the needed recipe is > missing and then you need to figure out which layer to add (typically > something in meta-openembedded tree). This is not that different: > optional feature, disabled by default, and the error will be the same: > missing lzop recipe. > I think this case is slightly different as this optional dependency might be "enabled" by MACHINE config in some BSP layer and BSP layer depending on meta-oe just to build the kernel (with BSP preferred compression) isn't great - compared with some DISTRO config enabling some additional PACKAGECONFIG in some other recipe the DISTRO uses. At least if Marek agrees to maintain it instead of restoring Denys as maintainer :). Cheers, -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#191178): https://lists.openembedded.org/g/openembedded-core/message/191178 Mute This Topic: https://lists.openembedded.org/mt/102759947/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 00/21] Consistent naming scheme for deployed artifacts
On Wed, Nov 22, 2023 at 2:19 PM Richard Purdie < richard.pur...@linuxfoundation.org> wrote: > On Wed, 2023-11-22 at 13:44 +0100, Martin Jansa wrote: > > This is the final part of changes for [YOCTO #12937]. > > > > I've run complete selftest with this and didn't see any failures. > > > > Only these 4 fail once, but pass when re-executed (and the same is > > reproducible here with master): > > pkgdata.OePkgdataUtilTests.test_lookup_recipe > > spdx.SPDXCheck.test_spdx_base_files > > esdk.oeSDKExtSelfTest.test_image_generation_binary_feeds > > esdk.oeSDKExtSelfTest.test_install_libraries_headers > > > > runtime_test.TestImage.test_testimage_virgl_gtk_sdl and this one > > needs extra "xhost +local" otherwise fails with: > > runqemu - ERROR - Failed to run qemu: Invalid MIT-MAGIC-COOKIE-1 key > > qemu-system-x86_64: OpenGL is not supported by the display > > > > The short description of these changes is that instead of symlinks > > it creates hardlinks in deploy dir and the kernel do_deploy creates > > the artifacts without version suffix and the do_deploy_links task > > adds those versioned hardlinks (this way do_deploy can be reused from > > sstate and only quick do_deploy_links is re-executed when the > > IMAGE_VERSION_SUFFIX changes - before that if you cannot re-use do_deploy > > from sstate due to different artifact filenames you had to re-run e.g. > > do_compile as well if you haven't built the same in the same TMPDIR > > before). > > I am a bit worried about this change since there were uses for having > the symlinks present and this unconditionally moves everything over to > hardlinks. > > With the symlink, you can see the pointer quite clearly, with > hardlinks, it is unclear which files are duplicates of each other > withouth diving into comparing inodes. > Yes, it's definitely disadvantage of hardlinks (especially if someone forgets to preserve hardlinks when cp or rsync the deploy directory). But having the version in symlink would be even worse (as it could point to different artifact already). And having the version in the artifact itself requires do_deploy to re-run and without prior build it would re-run do_compile for kernel, bootloader and other artifacts as well. This is also why I've made sure you can set IMAGE_VERSION_SUFFIX to empty to prevent all of these hardlinks to be created, if all you care is just whatever is latest to be in the deploy directory. It might be interesting to have the versioned and version-less artifacts in different directories, so that you always cp/rsync only one set of them, but I fear that it would require even more oeqa changes and this area is already a bit too complicated I think. FWIW: we're using this for webOS builds since 2015 with webos_deploy task mentioned in the first patch, but to do this from "outside" is a bit difficult to maintain as webos_deploy needs to know about all possible artifacts other layers might create and also to inject dependency on webos_deploy task from all the right places. Thanks for review Richard, lets hope that someone else will also share an opinion about this. Cheers, Part of the reasoning was due to the way OE used to work where it would > stack images, each build would add a new one and it would update the > end symlink to point at the latest. Once sstate started removing old > entries, that became less needed but the pointers still help runqemu > and other tooling find the latest. > > This change is trying make the code do something different and it to > change versioning and do that in a way which allows maximal reuse from > sstate. > > Both are valid usages so we gain some things with the change but lose > others. I'm not sure how users in general are going to find things > overall :/. > > Cheers, > > Richard > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#191102): https://lists.openembedded.org/g/openembedded-core/message/191102 Mute This Topic: https://lists.openembedded.org/mt/102747718/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 21/21] u-boot.inc: don't replace the binary with symlink
* when UBOOT_ARTIFACT_NAME and UBOOT_ARTIFACT_LINK_NAME are empty
the UBOOT_BINARYNAME and UBOOT_IMAGE might be indentical and the
binary gets overwritten by the symlink to itself (similarly for SPL_*)
$ ls -lah
/OE/build/poky/build/tmp/work/qemuarm-poky-linux-gnueabi/u-boot/2023.10/package/boot
total 8.0K
drwxr-xr-x 2 martin martin 4.0K Nov 21 21:23 .
drwxr-xr-x 4 martin martin 4.0K Nov 21 21:23 ..
lrwxrwxrwx 1 martin martin3 Nov 21 21:23 MLO -> MLO
lrwxrwxrwx 1 martin martin 10 Nov 21 21:23 u-boot.bin -> u-boot.bin
* which causes:
ERROR: u-boot-1_2023.10-r0 do_package: Error executing a python function in
exec_func_python() autogenerated:
The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_func_python() autogenerated', lineno: 2, function:
0001:
*** 0002:do_package(d)
0003:
File: '/OE/build/poky/meta/classes-global/package.bbclass', lineno: 536,
function: do_package
0532:bb.build.exec_func("package_prepare_pkgdata", d)
0533:bb.build.exec_func("perform_packagecopy", d)
0534:for f in (d.getVar('PACKAGE_PREPROCESS_FUNCS') or '').split():
0535:bb.build.exec_func(f, d)
*** 0536:oe.package.process_split_and_strip_files(d)
0537:oe.package.fixup_perms(d)
0538:
0539:
###
0540:# Split up PKGD into PKGDEST
File: '/OE/build/poky/meta/lib/oe/package.py', lineno: 1073, function:
process_split_and_strip_files
1069:staticlibs.append(file)
1070:continue
1071:
1072:try:
*** 1073:ltarget = cpath.realpath(file, dvar, False)
1074:s = cpath.lstat(ltarget)
1075:except OSError as e:
1076:(err, strerror) = e.args
1077:if err != errno.ENOENT:
File: '/OE/build/poky/meta/lib/oe/cachedpath.py', lineno: 231, function:
realpath
0227:if e.errno == errno.ELOOP:
0228:# make ELOOP more readable; without catching it,
there will
0229:# be printed a backtrace with 100s of OSError
exceptions
0230:# else
*** 0231:raise OSError(errno.ELOOP,
0232: "too much recursions while resolving
'%s'; loop in '%s'" %
0233: (file, e.strerror))
0234:
0235:raise
Exception: OSError: [Errno 40] too much recursions while resolving
'/OE/build/poky/build/tmp/work/qemuarm-poky-linux-gnueabi/u-boot/2023.10/package/boot/MLO';
loop in
'/OE/build/poky/build/tmp/work/qemuarm-poky-linux-gnueabi/u-boot/2023.10/package/boot/MLO'
ERROR: Logfile of failure stored in:
/OE/build/poky/build/tmp/work/qemuarm-poky-linux-gnueabi/u-boot/2023.10/temp/log.do_package.3990391
[YOCTO #12937]
Signed-off-by: Martin Jansa
---
meta/classes-recipe/uboot-sign.bbclass | 24 ++---
meta/recipes-bsp/u-boot/u-boot.inc | 29 +++---
2 files changed, 34 insertions(+), 19 deletions(-)
diff --git a/meta/classes-recipe/uboot-sign.bbclass
b/meta/classes-recipe/uboot-sign.bbclass
index e89c8214d3..d7de2c3bde 100644
--- a/meta/classes-recipe/uboot-sign.bbclass
+++ b/meta/classes-recipe/uboot-sign.bbclass
@@ -420,24 +420,24 @@ do_deploy:prepend() {
fi
if [ "${UBOOT_SIGN_ENABLE}" = "1" -a -n "${UBOOT_DTB_BINARY}" ] ; then
- ln -vf ${DEPLOYDIR}/${UBOOT_DTB_IMAGE}
${DEPLOYDIR}/${UBOOT_DTB_BINARY}
- ln -vf ${DEPLOYDIR}/${UBOOT_DTB_IMAGE}
${DEPLOYDIR}/${UBOOT_DTB_LINK}
- ln -vf ${DEPLOYDIR}/${UBOOT_NODTB_IMAGE}
${DEPLOYDIR}/${UBOOT_NODTB_LINK}
- ln -vf ${DEPLOYDIR}/${UBOOT_NODTB_IMAGE}
${DEPLOYDIR}/${UBOOT_NODTB_BINARY}
+ [ "${UBOOT_DTB_IMAGE}" != "${UBOOT_DTB_BINARY}" ] && ln -vf
${DEPLOYDIR}/${UBOOT_DTB_IMAGE} ${DEPLOYDIR}/${UBOOT_DTB_BINARY}
+ [ "${UBOOT_DTB_IMAGE}" != "${UBOOT_DTB_LINK}" ] && ln -vf
${DEPLOYDIR}/${UBOOT_DTB_IMAGE} ${DEPLOYDIR}/${UBOOT_DTB_LINK}
+ [ "${UBOOT_NODTB_IMAGE}" != "${UBOOT_NODTB_LINK}" ] && ln -vf
${DEPLOYDIR}/${UBOOT_NODTB_IMAGE} ${DEPLOYDIR}/${UBOOT_NODTB_LINK}
+ [ "${UBOOT_NODTB_IMAGE}" != "${UBOOT_NODTB_BINARY}" ] && ln -vf
${DEPLOYDIR}/${UBOOT_NODTB_IMAGE} ${DEPLOYDIR}/${UBOOT_NODTB_BINARY}
fi
if [ "${UBOOT_FITIMAGE_ENABLE}" = "1" ] ; then
- ln -vf ${DEPLOYDIR}/${UBOOT_ITS_IMAGE} ${DEPLOYDIR}/${UBOOT_ITS}
- ln -vf ${DEPLOYDIR}/${UBOOT_ITS_IMAGE}
${DEPLOYDIR}/${UBOOT_ITS_LINK}
- ln -vf ${DEPLOYDIR}/${UBOOT_FITIMAGE
[OE-core] [PATCH 20/21] populate_sdk_ext.bbclass: add *:do_shared_workdir to BB_SETSCENE_ENFORCE_IGNORE_TASKS
* otherwise populate_sdk_ext task will fail as shown e.g. with:
bitbake core-image-minimal -c populate_sdk_ext
esdk.oeSDKExtSelfTest.test_image_generation_binary_feeds
esdk.oeSDKExtSelfTest.test_install_libraries_headers:
ERROR: Task linux-yocto.do_deploy_links attempted to execute unexpectedly
Task
tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta/recipes-core/images/core-image-minimal.bb:do_image_qa,
unihash 9d177d4c6ca34e68e19b1bc23deec58c3eabe5f9d5808f90402161163a73f22f,
taskhash 9d177d4c6ca34e68e19b1bc23deec58c3eabe5f9d5808f90402161163a73f22f
Task
tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta/recipes-core/images/core-image-minimal.bb:do_image_complete,
unihash 0aff4dcbdb3c5ca68e0ebb39457fbe86beb3482986ddfe0b0b6fc0386807edbf,
taskhash 0aff4dcbdb3c5ca68e0ebb39457fbe86beb3482986ddfe0b0b6fc0386807edbf
This is usually due to missing setscene tasks. Those missing in this build
were:
{'tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta/recipes-core/images/core-image-minimal.bb:do_image_complete',
'tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta/recipes-core/images/core-image-minimal.bb:do_image_qa'}
ERROR: Task
(tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta/recipes-kernel/linux/linux-yocto_6.5.bb:do_deploy_links)
failed with exit code 'setscene ignore_tasks'
NOTE: Tasks Summary: Attempted 4975 tasks of which 4971 didn't need to be rerun
and 1 failed.
Summary: 1 task failed:
tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta/recipes-kernel/linux/linux-yocto_6.5.bb:do_deploy_links
Summary: There was 1 WARNING message.
Summary: There was 1 ERROR message, returning a non-zero exit code.
ERROR: Logfile of failure stored in:
tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0/temp/log.do_populate_sdk_ext.2280835
NOTE: recipe core-image-minimal-1.0-r0: task do_populate_sdk_ext: Failed
ERROR: Task
(/OE/build/poky/meta/recipes-core/images/core-image-minimal.bb:do_populate_sdk_ext)
failed with exit code '1'
NOTE: Tasks Summary: Attempted 6211 tasks of which 6147 didn't need to be rerun
and 1 failed.
Summary: 1 task failed:
/OE/build/poky/meta/recipes-core/images/core-image-minimal.bb:do_populate_sdk_ext
Summary: There was 1 ERROR message, returning a non-zero exit code.
[YOCTO #12937]
Signed-off-by: Martin Jansa
---
meta/classes-recipe/populate_sdk_ext.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes-recipe/populate_sdk_ext.bbclass
b/meta/classes-recipe/populate_sdk_ext.bbclass
index f209becae1..5705140359 100644
--- a/meta/classes-recipe/populate_sdk_ext.bbclass
+++ b/meta/classes-recipe/populate_sdk_ext.bbclass
@@ -366,7 +366,7 @@ def write_local_conf(d, baseoutpath, derivative,
core_meta_subdir, uninative_che
f.write('BB_HASHCONFIG_IGNORE_VARS:append = "
SIGGEN_UNLOCKED_RECIPES"\n\n')
# Set up which tasks are ignored for run on install
-f.write('BB_SETSCENE_ENFORCE_IGNORE_TASKS = "%:*
*:do_shared_workdir *:do_rm_work wic-tools:* *:do_addto_recipe_sysroot"\n\n')
+f.write('BB_SETSCENE_ENFORCE_IGNORE_TASKS = "%:*
*:do_shared_workdir *:do_rm_work *:do_deploy_links wic-tools:*
*:do_addto_recipe_sysroot"\n\n')
# Hide the config information from bitbake output (since it's
fixed within the SDK)
f.write('BUILDCFG_HEADER = ""\n\n')
--
2.43.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#191097):
https://lists.openembedded.org/g/openembedded-core/message/191097
Mute This Topic: https://lists.openembedded.org/mt/102747738/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 18/21] selftest: multiconfig-image-packager: use IMAGE_NAME instead of IMAGE_LINK_NAME
* the IMAGE_LINK_NAME now contains PKGV, PKGR in the filename, but the
multiconfig-image-packager and MC_DEPLOY_IMAGE_BASENAME
(e.g. core-image-minimal) has different PKGV value causing:
| DEBUG: Executing shell function do_install
| install: cannot stat
'tmp-mc-musl/deploy/images/qemux86-64/core-image-minimal-qemux86-64.rootfs--0.1-r0-2011040523.ext4':
No such file or directory
...
| install: cannot stat
'tmp-mc-tiny/deploy/images/qemux86/core-image-minimal-qemux86.rootfs--0.1-r0-2011040523.cpio.gz':
No such file or directory
because the actual filenames are:
tmp-mc-musl/deploy/images/qemux86-64/core-image-minimal-qemux86-64.rootfs--1.0-r0-2011040523.ext4
tmp-mc-tiny/deploy/images/qemux86/core-image-minimal-qemux86.rootfs--1.0-r0-2011040523.ext4
[YOCTO #12937]
Signed-off-by: Martin Jansa
---
.../multiconfig/multiconfig-image-packager_0.1.bb| 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git
a/meta-selftest/recipes-test/multiconfig/multiconfig-image-packager_0.1.bb
b/meta-selftest/recipes-test/multiconfig/multiconfig-image-packager_0.1.bb
index d7785cee2e..b53b6a4b26 100644
--- a/meta-selftest/recipes-test/multiconfig/multiconfig-image-packager_0.1.bb
+++ b/meta-selftest/recipes-test/multiconfig/multiconfig-image-packager_0.1.bb
@@ -13,11 +13,11 @@ do_install[mcdepends] +=
"mc::${MCNAME}:core-image-minimal:do_image_complete mc:
do_install () {
install -d ${D}/var/lib/machines/${MCNAME}
-install
${MC_DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME_CORE_IMAGE_MINIMAL}.${MCIMGTYPE}
${D}/var/lib/machines/${MCNAME}/${MC_DEPLOY_IMAGE_BASENAME}.${MCIMGTYPE}
+install
${MC_DEPLOY_DIR_IMAGE}/${IMAGE_NAME_CORE_IMAGE_MINIMAL}.${MCIMGTYPE}
${D}/var/lib/machines/${MCNAME}/${MC_DEPLOY_IMAGE_BASENAME}.${MCIMGTYPE}
install ${MC_DEPLOY_DIR_IMAGE}/bzImage ${D}/var/lib/machines/${MCNAME}
}
-# for IMAGE_LINK_NAME, IMAGE_BASENAME
+# for IMAGE_NAME, IMAGE_BASENAME
inherit image-artifact-names
python () {
@@ -31,14 +31,14 @@ python () {
# these will most likely start with my BPN multiconfig-image-packager, but
I want them from core-image-minimal
# as there is no good way to query core-image-minimal's context lets
assume that there are no overrides
# and that we can just replace IMAGE_BASENAME
-image_link_name = d.getVar('IMAGE_LINK_NAME')
+image_name = d.getVar('IMAGE_NAME')
image_basename = d.getVar('IMAGE_BASENAME')
machine = d.getVar('MACHINE')
mcmachine = d.getVar('MCMACHINE')
image_to_deploy = d.getVar('MC_DEPLOY_IMAGE_BASENAME')
-image_link_name_to_deploy = image_link_name.replace(image_basename,
image_to_deploy).replace(machine, mcmachine)
-bb.warn('%s: assuming that "%s" built for "%s" has IMAGE_LINK_NAME "%s"' %
(d.getVar('PN'), mcmachine, image_to_deploy, image_link_name_to_deploy))
-d.setVar('IMAGE_LINK_NAME_CORE_IMAGE_MINIMAL', image_link_name_to_deploy)
+image_name_to_deploy = image_name.replace(image_basename,
image_to_deploy).replace(machine, mcmachine)
+bb.warn('%s: assuming that "%s" built for "%s" has IMAGE_NAME "%s"' %
(d.getVar('PN'), mcmachine, image_to_deploy, image_name_to_deploy))
+d.setVar('IMAGE_NAME_CORE_IMAGE_MINIMAL', image_name_to_deploy)
}
BBCLASSEXTEND = "mcextend:tiny mcextend:musl"
--
2.43.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#191095):
https://lists.openembedded.org/g/openembedded-core/message/191095
Mute This Topic: https://lists.openembedded.org/mt/102747736/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 19/21] image.bbclass: remove hardlinks as well
* it was removing only destination symlinks, but sometimes hardlink might be
regenerated
as well, e.g. in oeqa test wic.Wic.test_permissions which was failing with:
NOTE: recipe core-image-minimal-1.0-r0: task do_image_wic: Started
ERROR: core-image-minimal-1.0-r0 do_image_wic: Error executing a python
function in exec_func_python() autogenerated:
The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_func_python() autogenerated', lineno: 2, function:
0001:
*** 0002:create_hardlinks(d)
0003:
File: '/OE/build/poky/meta/classes-recipe/image.bbclass', lineno: 606,
function: create_hardlinks
0602:if os.path.exists(src):
0603:bb.note("Creating hardlink: %s -> %s" % (dst, src))
0604:if os.path.islink(dst):
0605:os.remove(dst)
*** 0606:os.link(src, dst)
0607:else:
0608:bb.note("Skipping hardlink, source does not exist: %s ->
%s" % (dst, src))
0609:}
0610:
Exception: FileExistsError: [Errno 17] File exists:
'tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0/deploy-core-image-minimal-image-complete/core-image-minimal-qemux86-64.rootfs.wic'
->
'tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0/deploy-core-image-minimal-image-complete/core-image-minimal-qemux86-64.rootfs--1.0-r0-2011040523.wic'
[YOCTO #12937]
Signed-off-by: Martin Jansa
---
meta/classes-recipe/image.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes-recipe/image.bbclass
b/meta/classes-recipe/image.bbclass
index e68b8034ea..081f1927fb 100644
--- a/meta/classes-recipe/image.bbclass
+++ b/meta/classes-recipe/image.bbclass
@@ -601,7 +601,7 @@ python create_hardlinks() {
src = os.path.join(deploy_dir, img_name + "." + type)
if os.path.exists(src):
bb.note("Creating hardlink: %s -> %s" % (dst, src))
-if os.path.islink(dst):
+if os.path.isfile(dst):
os.remove(dst)
os.link(src, dst)
else:
--
2.43.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#191096):
https://lists.openembedded.org/g/openembedded-core/message/191096
Mute This Topic: https://lists.openembedded.org/mt/102747737/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 17/21] oeqa: fitimage: respect KERNEL_FIT_NAME
* avoid couple of get_bb_var calls and use get_bb_vars instead
* use KERNEL_FIT_LINK_NAME instead of assuming it's MACHINE as e.g.:
machine = get_bb_var('MACHINE')
fitimage_its_path = os.path.join(deploy_dir_image,
"fitImage-its-%s-%s-%s" % (image_type, machine, machine))
* be aware that KERNEL_FIT_LINK_NAME can still be set to empty
and then this oeqa check would fail again, because this hardlink:
ln -vf $deployDir/fitImage-its-${INITRAMFS_IMAGE_NAME}${KERNEL_FIT_NAME}.its
"$deployDir/fitImage-its-${INITRAMFS_IMAGE_NAME}${KERNEL_FIT_LINK_NAME}"
wouldn't be created and also with KERNEL_FIT_LINK_NAME the
PKGV in kernel recipe looks differently in the final kernel
artifact and KERNEL_FIT_LINK_NAME e.g.:
AssertionError: False is not true:
tmp/deploy/images/beaglebone-yocto/fitImage-its-core-image-minimal-initramfs-beaglebone-yocto-beaglebone-yocto--6.1.20+git-r0-20230318024804
image tree source doesn't exist
because it's actually named with SRCPV expanded:
tmp/deploy/images/beaglebone-yocto/fitImage-its-core-image-minimal-initramfs-beaglebone-yocto-beaglebone-yocto--6.1.20+git0+29ec3dc6f4_423e199669-r0-20230318024804
Use KERNEL_FIT_NAME instead of KERNEL_FIT_LINK_NAME but then we would
need to add .its extension to expected filenames as well, but in previous
commit I've added KERNEL_FIT_ITS_EXT variable and used it for links as well.
But this doesn't apply for u-boot-its* files which don't use any extension.
[YOCTO #12937]
Signed-off-by: Martin Jansa
---
meta/lib/oeqa/selftest/cases/fitimage.py | 98
1 file changed, 48 insertions(+), 50 deletions(-)
diff --git a/meta/lib/oeqa/selftest/cases/fitimage.py
b/meta/lib/oeqa/selftest/cases/fitimage.py
index 9383d0c4db..170df1bea2 100644
--- a/meta/lib/oeqa/selftest/cases/fitimage.py
+++ b/meta/lib/oeqa/selftest/cases/fitimage.py
@@ -5,7 +5,7 @@
#
from oeqa.selftest.case import OESelftestTestCase
-from oeqa.utils.commands import runCmd, bitbake, get_bb_var, get_bb_vars
+from oeqa.utils.commands import runCmd, bitbake, get_bb_vars
import os
import re
@@ -46,12 +46,12 @@ FIT_DESC = "A model description"
# fitImage is created as part of linux recipe
image = "virtual/kernel"
bitbake(image)
-bb_vars = get_bb_vars(['DEPLOY_DIR_IMAGE', 'INITRAMFS_IMAGE_NAME',
'KERNEL_FIT_LINK_NAME'], image)
+bb_vars = get_bb_vars(['DEPLOY_DIR_IMAGE', 'INITRAMFS_IMAGE_NAME',
'KERNEL_FIT_NAME', 'KERNEL_FIT_ITS_EXT', 'KERNEL_FIT_BIN_EXT'], image)
fitimage_its_path = os.path.join(bb_vars['DEPLOY_DIR_IMAGE'],
-"fitImage-its-%s-%s" % (bb_vars['INITRAMFS_IMAGE_NAME'],
bb_vars['KERNEL_FIT_LINK_NAME']))
+"fitImage-its-%s%s%s" % (bb_vars['INITRAMFS_IMAGE_NAME'],
bb_vars['KERNEL_FIT_NAME'], bb_vars['KERNEL_FIT_ITS_EXT']))
fitimage_path = os.path.join(bb_vars['DEPLOY_DIR_IMAGE'],
-"fitImage-%s-%s" % (bb_vars['INITRAMFS_IMAGE_NAME'],
bb_vars['KERNEL_FIT_LINK_NAME']))
+"fitImage-%s%s%s" % (bb_vars['INITRAMFS_IMAGE_NAME'],
bb_vars['KERNEL_FIT_NAME'], bb_vars['KERNEL_FIT_BIN_EXT']))
self.assertTrue(os.path.exists(fitimage_its_path),
"%s image tree source doesn't exist" % (fitimage_its_path))
@@ -126,12 +126,12 @@ UBOOT_MKIMAGE_SIGN_ARGS = "-c 'a smart comment'"
# fitImage is created as part of linux recipe
image = "virtual/kernel"
bitbake(image)
-bb_vars = get_bb_vars(['DEPLOY_DIR_IMAGE', 'KERNEL_FIT_LINK_NAME'],
image)
+bb_vars = get_bb_vars(['DEPLOY_DIR_IMAGE', 'KERNEL_FIT_NAME',
'KERNEL_FIT_ITS_EXT', 'KERNEL_FIT_BIN_EXT'], image)
fitimage_its_path = os.path.join(bb_vars['DEPLOY_DIR_IMAGE'],
-"fitImage-its-%s" % (bb_vars['KERNEL_FIT_LINK_NAME']))
+"fitImage-its%s%s" % (bb_vars['KERNEL_FIT_NAME'],
bb_vars['KERNEL_FIT_ITS_EXT']))
fitimage_path = os.path.join(bb_vars['DEPLOY_DIR_IMAGE'],
-"fitImage-%s.bin" % (bb_vars['KERNEL_FIT_LINK_NAME']))
+"fitImage%s%s" % (bb_vars['KERNEL_FIT_NAME'],
bb_vars['KERNEL_FIT_BIN_EXT']))
self.assertTrue(os.path.exists(fitimage_its_path),
"%s image tree source doesn't exist" % (fitimage_its_path))
@@ -278,14 +278,14 @@ FIT_SIGN_INDIVIDUAL = "1"
self.write_config(config)
# The U-Boot fitImage is created as part of the U-Boot recipe
-bitbake("virtual/bootloader")
+image = "virtual/bootloader"
+bitbake(image)
+bb_vars = get_bb_vars(['DEPLOY_DIR_IMAGE', 'KERNEL_FIT_NAME'], image)
-deploy_dir_image = get_bb_var('DEPLOY_DIR_IMAGE')
-machine = get_bb_var('MACHINE')
-fitimage_its_path = os.path.join(deploy_dir_image,
-"u-boot-its-%s" % (m
[OE-core] [PATCH 15/21] oeqa: imagefeatures: append -dbg suffix at the end of IMAGE_NAME not IMAGE_LINK_NAME
* the filename is constructed as:
meta/classes-recipe/image.bbclass:d.appendVar('IMAGE_NAME','-dbg')
and IMAGE_LINK_NAME adds ${IMAGE_VERSION_SUFFIX} _after_ this
[YOCTO #12937]
Signed-off-by: Martin Jansa
---
meta/lib/oeqa/selftest/cases/imagefeatures.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/lib/oeqa/selftest/cases/imagefeatures.py
b/meta/lib/oeqa/selftest/cases/imagefeatures.py
index dc88c222bd..da510f0e8e 100644
--- a/meta/lib/oeqa/selftest/cases/imagefeatures.py
+++ b/meta/lib/oeqa/selftest/cases/imagefeatures.py
@@ -288,9 +288,9 @@ SKIP_RECIPE[busybox] = "Don't build this"
self.write_config(features)
bitbake(image)
-bb_vars = get_bb_vars(['DEPLOY_DIR_IMAGE', 'IMAGE_LINK_NAME'], image)
+bb_vars = get_bb_vars(['DEPLOY_DIR_IMAGE', 'IMAGE_NAME'], image)
-dbg_tar_file = os.path.join(bb_vars['DEPLOY_DIR_IMAGE'], "%s-dbg.%s" %
(bb_vars['IMAGE_LINK_NAME'], image_fstypes_debugfs))
+dbg_tar_file = os.path.join(bb_vars['DEPLOY_DIR_IMAGE'], "%s-dbg.%s" %
(bb_vars['IMAGE_NAME'], image_fstypes_debugfs))
self.assertTrue(os.path.exists(dbg_tar_file), 'debug filesystem not
generated at %s' % dbg_tar_file)
result = runCmd('cd %s; tar xvf %s' % (bb_vars['DEPLOY_DIR_IMAGE'],
dbg_tar_file))
self.assertEqual(result.status, 0, msg='Failed to extract %s: %s' %
(dbg_tar_file, result.output))
--
2.43.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#191092):
https://lists.openembedded.org/g/openembedded-core/message/191092
Mute This Topic: https://lists.openembedded.org/mt/102747733/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 16/21] oeqa: gdbserver: append -dbg suffix at the end of IMAGE_NAME not IMAGE_LINK_NAME
* the filename is constructed as:
meta/classes-recipe/image.bbclass:d.appendVar('IMAGE_NAME','-dbg')
and IMAGE_LINK_NAME adds ${IMAGE_VERSION_SUFFIX} _after_ this
[YOCTO #12937]
Signed-off-by: Martin Jansa
---
meta/lib/oeqa/selftest/cases/gdbserver.py | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta/lib/oeqa/selftest/cases/gdbserver.py
b/meta/lib/oeqa/selftest/cases/gdbserver.py
index 9da97ae780..f441468861 100644
--- a/meta/lib/oeqa/selftest/cases/gdbserver.py
+++ b/meta/lib/oeqa/selftest/cases/gdbserver.py
@@ -34,12 +34,12 @@ CORE_IMAGE_EXTRA_INSTALL = "gdbserver"
self.assertEqual(r.status, 0)
self.assertIn("GNU gdb", r.output)
image = 'core-image-minimal'
-bb_vars = get_bb_vars(['DEPLOY_DIR_IMAGE', 'IMAGE_LINK_NAME'], image)
+bb_vars = get_bb_vars(['DEPLOY_DIR_IMAGE', 'IMAGE_NAME'], image)
with tempfile.TemporaryDirectory(prefix="debugfs-") as debugfs:
-filename = os.path.join(bb_vars['DEPLOY_DIR_IMAGE'],
"%s-dbg.tar.bz2" % bb_vars['IMAGE_LINK_NAME'])
+filename = os.path.join(bb_vars['DEPLOY_DIR_IMAGE'],
"%s-dbg.tar.bz2" % bb_vars['IMAGE_NAME'])
shutil.unpack_archive(filename, debugfs)
-filename = os.path.join(bb_vars['DEPLOY_DIR_IMAGE'], "%s.tar.bz2"
% bb_vars['IMAGE_LINK_NAME'])
+filename = os.path.join(bb_vars['DEPLOY_DIR_IMAGE'], "%s.tar.bz2"
% bb_vars['IMAGE_NAME'])
shutil.unpack_archive(filename, debugfs)
with runqemu("core-image-minimal", runqemuparams="nographic") as
qemu:
--
2.43.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#191093):
https://lists.openembedded.org/g/openembedded-core/message/191093
Mute This Topic: https://lists.openembedded.org/mt/102747734/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 14/21] image.bbclass: don't append -dbg suffix twice
* now with IMAGE_LINK_NAME defined based on IMAGE_NAME we don't want to
append -dbg to IMAGE_NAME and then again to IMAGE_LINK_NAME
* this resulted in filename like:
core-image-minimal-qemux86-64.rootfs-dbg--1.0-r0-2011040523-dbg.tar.bz2
[YOCTO #12937]
Signed-off-by: Martin Jansa
---
meta/classes-recipe/image.bbclass | 2 --
1 file changed, 2 deletions(-)
diff --git a/meta/classes-recipe/image.bbclass
b/meta/classes-recipe/image.bbclass
index aa24a92245..e68b8034ea 100644
--- a/meta/classes-recipe/image.bbclass
+++ b/meta/classes-recipe/image.bbclass
@@ -338,8 +338,6 @@ addtask do_image_qa_setscene
def setup_debugfs_variables(d):
d.appendVar('IMAGE_ROOTFS', '-dbg')
-if d.getVar('IMAGE_LINK_NAME'):
-d.appendVar('IMAGE_LINK_NAME', '-dbg')
d.appendVar('IMAGE_NAME','-dbg')
d.setVar('IMAGE_BUILDING_DEBUGFS', 'true')
debugfs_image_fstypes = d.getVar('IMAGE_FSTYPES_DEBUGFS')
--
2.43.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#191091):
https://lists.openembedded.org/g/openembedded-core/message/191091
Mute This Topic: https://lists.openembedded.org/mt/102747732/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 13/21] kernel.bbclass: inherit KERNEL_CLASSES at the end
* after defining deploy-links task, so that e.g. kernel-fitimage can append to
it
like kernel-devicetree.bbclass
[YOCTO #12937]
Signed-off-by: Martin Jansa
---
meta/classes-recipe/kernel.bbclass | 34 +++---
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/meta/classes-recipe/kernel.bbclass
b/meta/classes-recipe/kernel.bbclass
index e38784a320..c5ff7453ff 100644
--- a/meta/classes-recipe/kernel.bbclass
+++ b/meta/classes-recipe/kernel.bbclass
@@ -156,23 +156,6 @@ set -e
d.appendVarFlag('do_configure', 'depends', ' ${INITRAMFS_TASK}')
}
-# Here we pull in all various kernel image types which we support.
-#
-# In case you're wondering why kernel.bbclass inherits the other image
-# types instead of the other way around, the reason for that is to
-# maintain compatibility with various currently existing meta-layers.
-# By pulling in the various kernel image types here, we retain the
-# original behavior of kernel.bbclass, so no meta-layers should get
-# broken.
-#
-# KERNEL_CLASSES by default pulls in kernel-uimage.bbclass, since this
-# used to be the default behavior when only uImage was supported. This
-# variable can be appended by users who implement support for new kernel
-# image types.
-
-KERNEL_CLASSES ?= " kernel-uimage "
-inherit ${KERNEL_CLASSES}
-
# Old style kernels may set ${S} = ${WORKDIR}/git for example
# We need to move these over to STAGING_KERNEL_DIR. We can't just
# create the symlink in advance as the git fetcher can't cope with
@@ -892,3 +875,20 @@ EXPORT_FUNCTIONS do_deploy do_deploy_links
# Add using Device Tree support
inherit kernel-devicetree
+
+# Here we pull in all various kernel image types which we support.
+#
+# In case you're wondering why kernel.bbclass inherits the other image
+# types instead of the other way around, the reason for that is to
+# maintain compatibility with various currently existing meta-layers.
+# By pulling in the various kernel image types here, we retain the
+# original behavior of kernel.bbclass, so no meta-layers should get
+# broken.
+#
+# KERNEL_CLASSES by default pulls in kernel-uimage.bbclass, since this
+# used to be the default behavior when only uImage was supported. This
+# variable can be appended by users who implement support for new kernel
+# image types.
+
+KERNEL_CLASSES ?= " kernel-uimage "
+inherit ${KERNEL_CLASSES}
--
2.43.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#191090):
https://lists.openembedded.org/g/openembedded-core/message/191090
Mute This Topic: https://lists.openembedded.org/mt/102747731/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 12/21] linux-dummy: add do_deploy_links task
* fixes containerimage.ContainerImageTests.test_expected_files oeqa test
failing with:
Initialising tasks...ERROR: Task do_build in
/OE/build/poky/build-st/meta-selftest/recipes-test/container-image/container-test-image.bb
depends upon non-existent task do_deploy_links in
/OE/build/poky/meta/recipes-kernel/linux/linux-dummy.bb
[YOCTO #12937]
Signed-off-by: Martin Jansa
---
meta/recipes-kernel/linux/linux-dummy.bb | 5 +
1 file changed, 5 insertions(+)
diff --git a/meta/recipes-kernel/linux/linux-dummy.bb
b/meta/recipes-kernel/linux/linux-dummy.bb
index 2396f46202..47a0d5e9da 100644
--- a/meta/recipes-kernel/linux/linux-dummy.bb
+++ b/meta/recipes-kernel/linux/linux-dummy.bb
@@ -60,7 +60,12 @@ do_deploy() {
:
}
+do_deploy_links() {
+ :
+}
+
addtask bundle_initramfs after do_install before do_deploy
addtask deploy after do_install
+addtask deploy_links after do_deploy
addtask shared_workdir after do_compile before do_install
addtask compile_kernelmodules
--
2.43.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#191089):
https://lists.openembedded.org/g/openembedded-core/message/191089
Mute This Topic: https://lists.openembedded.org/mt/102747730/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 10/21] oeqa: bbtests.BitbakeTests.test_image_manifest: use just isfile() instead of islink()
* with [YOCTO #12937] changes the manifest is hardlink not symlink * fixes: 2023-11-16 00:16:33,967 - oe-selftest - INFO - test_image_manifest (bbtests.BitbakeTests.test_image_manifest) 2023-11-16 00:19:05,060 - oe-selftest - INFO - ... FAIL 2023-11-16 00:19:05,060 - oe-selftest - INFO - Traceback (most recent call last): File "/OE/build/poky/meta/lib/oeqa/selftest/cases/bbtests.py", line 139, in test_image_manifest self.assertTrue(os.path.islink(manifest), msg="No manifest file created for image. It should have been created in %s" % manifest) AssertionError: False is not true : No manifest file created for image. It should have been created in /OE/build/poky/tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.rootfs--1.0-r0-2011040523.manifest [YOCTO #12937] Signed-off-by: Martin Jansa --- meta/lib/oeqa/selftest/cases/bbtests.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/lib/oeqa/selftest/cases/bbtests.py b/meta/lib/oeqa/selftest/cases/bbtests.py index d242352ea2..4276a9ba91 100644 --- a/meta/lib/oeqa/selftest/cases/bbtests.py +++ b/meta/lib/oeqa/selftest/cases/bbtests.py @@ -136,7 +136,7 @@ class BitbakeTests(OESelftestTestCase): deploydir = bb_vars["DEPLOY_DIR_IMAGE"] imagename = bb_vars["IMAGE_LINK_NAME"] manifest = os.path.join(deploydir, imagename + ".manifest") -self.assertTrue(os.path.islink(manifest), msg="No manifest file created for image. It should have been created in %s" % manifest) +self.assertTrue(os.path.isfile(manifest), msg="No manifest file created for image. It should have been created in %s" % manifest) def test_invalid_recipe_src_uri(self): data = 'SRC_URI = "file://invalid"' -- 2.43.0 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#191087): https://lists.openembedded.org/g/openembedded-core/message/191087 Mute This Topic: https://lists.openembedded.org/mt/102747728/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 11/21] oeqa: wic: use just isfile() instead of islink()
* with [YOCTO #12937] changes the manifest is hardlink not symlink
* fixes:
2023-11-18 23:48:55,695 - oe-selftest - INFO - ... FAIL
2023-11-18 23:48:55,696 - oe-selftest - INFO - Traceback (most recent call
last):
File "/OE/build/poky/meta/lib/oeqa/core/decorator/__init__.py", line 35, in
wrapped_f
return func(*args, **kwargs)
^
File "/OE/build/poky/meta/lib/oeqa/selftest/cases/wic.py", line 836, in
test_wic_image_type
self.assertTrue(os.path.islink(path), msg="Link %s wasn't generated as
expected" % path)
AssertionError: False is not true : Link
tmp/deploy/images/qemux86-64/wic-image-minimal-qemux86-64.rootfs--1.0-r0-2011040523.wic
wasn't generated as expected
---
meta/lib/oeqa/selftest/cases/wic.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/lib/oeqa/selftest/cases/wic.py
b/meta/lib/oeqa/selftest/cases/wic.py
index b4866bcb32..fdff3e846e 100644
--- a/meta/lib/oeqa/selftest/cases/wic.py
+++ b/meta/lib/oeqa/selftest/cases/wic.py
@@ -833,7 +833,7 @@ class Wic2(WicTestCase):
# pointing to existing files
for suffix in ('wic', 'manifest'):
path = prefix + suffix
-self.assertTrue(os.path.islink(path), msg="Link %s wasn't
generated as expected" % path)
+self.assertTrue(os.path.isfile(path), msg="Link %s wasn't
generated as expected" % path)
self.assertTrue(os.path.isfile(os.path.realpath(path)), msg="File
linked to by %s wasn't generated as expected" % path)
# TODO this should work on aarch64
--
2.43.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#191088):
https://lists.openembedded.org/g/openembedded-core/message/191088
Mute This Topic: https://lists.openembedded.org/mt/102747729/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 09/21] image-artifact-names.bbclass: add IMAGE_VERSION_SUFFIX_DATETIME which uses SOURCE_DATE_EPOCH
* since
https://git.openembedded.org/openembedded-core/diff/meta/classes/image-artifact-names.bbclass?id=abb0671d2cebfd7e8df94796404bbe9c7f961058
which removed the
bb.data.inherits_class('reproducible_build', d)
condition this was already applied in all the builds which used DATETIME, so
we
can move it to the default value directly and DISTRO configs than can choose
to use IMAGE_VERSION_SUFFIX_DATETIME as they want
[YOCTO #12937]
Signed-off-by: Martin Jansa
---
meta/classes-global/base.bbclass | 3 +++
meta/classes-recipe/image-artifact-names.bbclass | 12 +++-
2 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/meta/classes-global/base.bbclass b/meta/classes-global/base.bbclass
index ac84312a87..755d10106a 100644
--- a/meta/classes-global/base.bbclass
+++ b/meta/classes-global/base.bbclass
@@ -207,6 +207,9 @@ do_unpack[postfuncs] += "create_source_date_epoch_stamp"
def get_source_date_epoch_value(d):
return oe.reproducible.epochfile_read(d.getVar('SDE_FILE'), d)
+def get_source_date_epoch_value_datetime(d):
+import datetime
+return
datetime.datetime.fromtimestamp(int(get_source_date_epoch_value(d)),
datetime.timezone.utc).strftime('%Y%m%d%H%M%S')
def get_layers_branch_rev(d):
revisions = oe.buildcfg.get_layer_revisions(d)
diff --git a/meta/classes-recipe/image-artifact-names.bbclass
b/meta/classes-recipe/image-artifact-names.bbclass
index d0f1b0dc55..2d18f34c9c 100644
--- a/meta/classes-recipe/image-artifact-names.bbclass
+++ b/meta/classes-recipe/image-artifact-names.bbclass
@@ -9,8 +9,9 @@
##
IMAGE_BASENAME ?= "${PN}"
-IMAGE_VERSION_SUFFIX ?= "-${PKGE}-${PKGV}-${PKGR}-${DATETIME}"
-IMAGE_VERSION_SUFFIX[vardepsexclude] += "DATETIME SOURCE_DATE_EPOCH"
+IMAGE_VERSION_SUFFIX_DATETIME = "${@get_source_date_epoch_value_datetime(d)}"
+IMAGE_VERSION_SUFFIX_DATETIME[vardepvalue] = ""
+IMAGE_VERSION_SUFFIX ?=
"-${PKGE}-${PKGV}-${PKGR}-${IMAGE_VERSION_SUFFIX_DATETIME}"
IMAGE_NAME ?= "${IMAGE_BASENAME}${IMAGE_MACHINE_SUFFIX}${IMAGE_NAME_SUFFIX}"
IMAGE_LINK_NAME ?= "${IMAGE_NAME}${IMAGE_VERSION_SUFFIX}"
@@ -32,10 +33,3 @@ IMAGE_MACHINE_SUFFIX ??= "-${MACHINE}"
# by default) followed by additional suffices which describe the format (.ext4,
# .ext4.xz, etc.).
IMAGE_NAME_SUFFIX ??= ".rootfs"
-
-python () {
-if bb.data.inherits_class('deploy', d) and
d.getVar("IMAGE_VERSION_SUFFIX") == "-${DATETIME}":
-import datetime
-d.setVar("IMAGE_VERSION_SUFFIX", "-" +
datetime.datetime.fromtimestamp(int(d.getVar("SOURCE_DATE_EPOCH")),
datetime.timezone.utc).strftime('%Y%m%d%H%M%S'))
-d.setVarFlag("IMAGE_VERSION_SUFFIX", "vardepvalue", "")
-}
--
2.43.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#191086):
https://lists.openembedded.org/g/openembedded-core/message/191086
Mute This Topic: https://lists.openembedded.org/mt/102747727/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 07/21] uboot: use ${IMAGE_MACHINE_SUFFIX} instead of -${MACHINE} and use hardlinks
* rename variables to match the conventions used in kernel and image recipes
* use versioned hardlinks as kernel and image recipes, but don't split
the do_deploy_links task (can be split later).
[YOCTO #12937]
Signed-off-by: Martin Jansa
---
meta/classes-recipe/uboot-config.bbclass | 22 ++-
meta/classes-recipe/uboot-sign.bbclass | 68 -
meta/recipes-bsp/u-boot/u-boot.inc | 177 +++
3 files changed, 129 insertions(+), 138 deletions(-)
diff --git a/meta/classes-recipe/uboot-config.bbclass
b/meta/classes-recipe/uboot-config.bbclass
index 9be1d64d3e..a3c875e762 100644
--- a/meta/classes-recipe/uboot-config.bbclass
+++ b/meta/classes-recipe/uboot-config.bbclass
@@ -19,6 +19,12 @@ def removesuffix(s, suffix):
return s[:-len(suffix)]
return s
+inherit kernel-artifact-names
+
+UBOOT_VERSION_SUFFIX ?= "${IMAGE_VERSION_SUFFIX}"
+UBOOT_ARTIFACT_NAME ?= "${IMAGE_MACHINE_SUFFIX}"
+UBOOT_ARTIFACT_LINK_NAME ?= "${UBOOT_ARTIFACT_NAME}${UBOOT_VERSION_SUFFIX}"
+
UBOOT_ENTRYPOINT ?= "20008000"
UBOOT_LOADADDRESS ?= "${UBOOT_ENTRYPOINT}"
@@ -27,8 +33,8 @@ UBOOT_LOADADDRESS ?= "${UBOOT_ENTRYPOINT}"
UBOOT_SUFFIX ??= "bin"
UBOOT_BINARY ?= "u-boot.${UBOOT_SUFFIX}"
UBOOT_BINARYNAME ?= "${@os.path.splitext(d.getVar("UBOOT_BINARY"))[0]}"
-UBOOT_IMAGE ?= "${UBOOT_BINARYNAME}-${MACHINE}-${PV}-${PR}.${UBOOT_SUFFIX}"
-UBOOT_SYMLINK ?= "${UBOOT_BINARYNAME}-${MACHINE}.${UBOOT_SUFFIX}"
+UBOOT_IMAGE ?= "${UBOOT_BINARYNAME}${UBOOT_ARTIFACT_NAME}.${UBOOT_SUFFIX}"
+UBOOT_LINK ?= "${UBOOT_BINARYNAME}${UBOOT_ARTIFACT_LINK_NAME}.${UBOOT_SUFFIX}"
UBOOT_MAKE_TARGET ?= "all"
# Output the ELF generated. Some platforms can use the ELF file and directly
@@ -38,7 +44,7 @@ UBOOT_ELF ?= ""
UBOOT_ELF_SUFFIX ?= "elf"
UBOOT_ELF_IMAGE ?= "u-boot-${MACHINE}-${PV}-${PR}.${UBOOT_ELF_SUFFIX}"
UBOOT_ELF_BINARY ?= "u-boot.${UBOOT_ELF_SUFFIX}"
-UBOOT_ELF_SYMLINK ?= "u-boot-${MACHINE}.${UBOOT_ELF_SUFFIX}"
+UBOOT_ELF_LINK ?= "u-boot${UBOOT_ARTIFACT_LINK_NAME}.${UBOOT_ELF_SUFFIX}"
# Some versions of u-boot build an SPL (Second Program Loader) image that
# should be packaged along with the u-boot binary as well as placed in the
@@ -49,8 +55,8 @@ SPL_BINARY ?= ""
SPL_DELIMITER ?= "${@'.' if d.getVar("SPL_SUFFIX") else ''}"
SPL_BINARYFILE ?= "${@os.path.basename(d.getVar("SPL_BINARY"))}"
SPL_BINARYNAME ?= "${@removesuffix(d.getVar("SPL_BINARYFILE"), "." +
d.getVar("SPL_SUFFIX"))}"
-SPL_IMAGE ?=
"${SPL_BINARYNAME}-${MACHINE}-${PV}-${PR}${SPL_DELIMITER}${SPL_SUFFIX}"
-SPL_SYMLINK ?= "${SPL_BINARYNAME}-${MACHINE}${SPL_DELIMITER}${SPL_SUFFIX}"
+SPL_IMAGE ?=
"${SPL_BINARYNAME}${UBOOT_ARTIFACT_NAME}${SPL_DELIMITER}${SPL_SUFFIX}"
+SPL_LINK ?=
"${SPL_BINARYNAME}${UBOOT_ARTIFACT_LINK_NAME}${SPL_DELIMITER}${SPL_SUFFIX}"
# Additional environment variables or a script can be installed alongside
# u-boot to be used automatically on boot. This file, typically 'uEnv.txt'
@@ -62,8 +68,8 @@ UBOOT_ENV ?= ""
UBOOT_ENV_SRC_SUFFIX ?= "cmd"
UBOOT_ENV_SRC ?= "${UBOOT_ENV}.${UBOOT_ENV_SRC_SUFFIX}"
UBOOT_ENV_BINARY ?= "${UBOOT_ENV}.${UBOOT_ENV_SUFFIX}"
-UBOOT_ENV_IMAGE ?= "${UBOOT_ENV}-${MACHINE}-${PV}-${PR}.${UBOOT_ENV_SUFFIX}"
-UBOOT_ENV_SYMLINK ?= "${UBOOT_ENV}-${MACHINE}.${UBOOT_ENV_SUFFIX}"
+UBOOT_ENV_IMAGE ?= "${UBOOT_ENV}${UBOOT_ARTIFACT_NAME}.${UBOOT_ENV_SUFFIX}"
+UBOOT_ENV_LINK ?= "${UBOOT_ENV}${UBOOT_ARTIFACT_LINK_NAME}.${UBOOT_ENV_SUFFIX}"
# Default name of u-boot initial env, but enable individual recipes to change
# this value.
@@ -73,7 +79,7 @@ UBOOT_INITIAL_ENV ?= "${PN}-initial-env"
# to find EXTLINUX conf file.
UBOOT_EXTLINUX_INSTALL_DIR ?= "/boot/extlinux"
UBOOT_EXTLINUX_CONF_NAME ?= "extlinux.conf"
-UBOOT_EXTLINUX_SYMLINK ?= "${UBOOT_EXTLINUX_CONF_NAME}-${MACHINE}-${PR}"
+UBOOT_EXTLINUX_CONF_LINK ?=
"${UBOOT_EXTLINUX_CONF_NAME}${UBOOT_ARTIFACT_LINK_NAME}"
# Options for the device tree compiler passed to mkimage '-D' feature:
UBOOT_MKIMAGE_DTCOPTS ??= ""
diff --git a/meta/classes-recipe/uboot-sign.bbclass
b/meta/classes-recipe/uboot-sign.bbclass
index ad04c82378..e89c8214d3 100644
--- a/meta/classes-recipe/uboot-sign.bbclass
+++ b/meta/classes-recipe/uboot-sign.bbclass
@@ -34,27 +34,27 @@ UBOOT_FITIMAGE_ENABLE ?= "0"
SPL_SIGN_ENABLE ?= "0"
# Default value for deployment filenames.
-UBOOT_DTB_IMAGE ?= "u-boot-${MACHINE}-${PV}-${PR}.dtb"
+UBOOT_DTB_IMAGE ?= "u-boot${UBOOT_ARTIFACT_NAME}.dtb"
UBOOT_DTB_BINARY ?= "u-boot.dtb"
UBOOT_DTB_SIGNED ?= &q
[OE-core] [PATCH 08/21] image.bbclass: rename create_symlinks to create_hardlinks
* to make it more clear what this postfunc does now
[YOCTO #12937]
Signed-off-by: Martin Jansa
---
meta/classes-recipe/image-live.bbclass | 2 +-
meta/classes-recipe/image.bbclass | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/meta/classes-recipe/image-live.bbclass
b/meta/classes-recipe/image-live.bbclass
index 95dd44a8c0..4d926cb7a7 100644
--- a/meta/classes-recipe/image-live.bbclass
+++ b/meta/classes-recipe/image-live.bbclass
@@ -257,7 +257,7 @@ python do_bootimg() {
bb.build.exec_func('build_efi_cfg', d)
bb.build.exec_func('build_hddimg', d)
bb.build.exec_func('build_iso', d)
-bb.build.exec_func('create_symlinks', d)
+bb.build.exec_func('create_hardlinks', d)
}
do_bootimg[subimages] = "hddimg iso"
diff --git a/meta/classes-recipe/image.bbclass
b/meta/classes-recipe/image.bbclass
index 48dc70b8fc..aa24a92245 100644
--- a/meta/classes-recipe/image.bbclass
+++ b/meta/classes-recipe/image.bbclass
@@ -508,7 +508,7 @@ python () {
d.setVarFlag(task, 'fakeroot', '1')
d.appendVarFlag(task, 'prefuncs', ' ' + debug + ' set_image_size')
-d.prependVarFlag(task, 'postfuncs', 'create_symlinks ')
+d.prependVarFlag(task, 'postfuncs', 'create_hardlinks ')
d.appendVarFlag(task, 'subimages', ' ' + ' '.join(subimages))
d.appendVarFlag(task, 'vardeps', ' ' + ' '.join(vardeps))
d.appendVarFlag(task, 'vardepsexclude', ' DATETIME DATE ' + '
'.join(vardepsexclude))
@@ -584,9 +584,9 @@ python set_image_size () {
}
#
-# Create symlinks to the newly created image
+# Create hardlinks to the newly created image
#
-python create_symlinks() {
+python create_hardlinks() {
deploy_dir = d.getVar('IMGDEPLOYDIR')
img_name = d.getVar('IMAGE_NAME')
--
2.43.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#191085):
https://lists.openembedded.org/g/openembedded-core/message/191085
Mute This Topic: https://lists.openembedded.org/mt/102747726/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 02/21] create-spdx-2.2.bbclass: use hardlink as well
[YOCTO #12937]
Signed-off-by: Martin Jansa
---
meta/classes/create-spdx-2.2.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/create-spdx-2.2.bbclass
b/meta/classes/create-spdx-2.2.bbclass
index b0aef80db1..8c77f6b886 100644
--- a/meta/classes/create-spdx-2.2.bbclass
+++ b/meta/classes/create-spdx-2.2.bbclass
@@ -967,7 +967,7 @@ python image_combine_spdx() {
if image_link_name:
link = imgdeploydir / (image_link_name + suffix)
if link != target_path:
-link.symlink_to(os.path.relpath(target_path, link.parent))
+os.link(target_path, link)
spdx_tar_path = imgdeploydir / (image_name + ".spdx.tar.zst")
make_image_link(spdx_tar_path, ".spdx.tar.zst")
--
2.43.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#191079):
https://lists.openembedded.org/g/openembedded-core/message/191079
Mute This Topic: https://lists.openembedded.org/mt/102747720/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 06/21] kernel-fitimage.bbclass: add .its extension also to links
* for consistency with the names
[YOCTO #12937]
---
meta/classes-recipe/kernel-artifact-names.bbclass | 2 ++
meta/classes-recipe/kernel-fitimage.bbclass | 8
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/meta/classes-recipe/kernel-artifact-names.bbclass
b/meta/classes-recipe/kernel-artifact-names.bbclass
index 023ce61de5..1117a5b61f 100644
--- a/meta/classes-recipe/kernel-artifact-names.bbclass
+++ b/meta/classes-recipe/kernel-artifact-names.bbclass
@@ -31,6 +31,8 @@ KERNEL_FIT_NAME ?= "${KERNEL_ARTIFACT_NAME}"
KERNEL_FIT_LINK_NAME ?= "${KERNEL_ARTIFACT_LINK_NAME}"
KERNEL_FIT_BIN_EXT ?= "${KERNEL_ARTIFACT_BIN_EXT}"
+KERNEL_FIT_ITS_EXT ?= ".its"
+
MODULE_TARBALL_NAME ?= "${KERNEL_ARTIFACT_NAME}"
MODULE_TARBALL_LINK_NAME ?= "${KERNEL_ARTIFACT_LINK_NAME}"
MODULE_TARBALL_DEPLOY ?= "1"
diff --git a/meta/classes-recipe/kernel-fitimage.bbclass
b/meta/classes-recipe/kernel-fitimage.bbclass
index 25a33123a6..ee2496fedc 100644
--- a/meta/classes-recipe/kernel-fitimage.bbclass
+++ b/meta/classes-recipe/kernel-fitimage.bbclass
@@ -843,14 +843,14 @@ kernel_do_deploy:append() {
if [ "${INITRAMFS_IMAGE_BUNDLE}" != "1" ]; then
bbnote "Copying fit-image.its source file..."
- install -m 0644 ${B}/fit-image.its
"$deployDir/fitImage-its${KERNEL_FIT_NAME}.its"
+ install -m 0644 ${B}/fit-image.its
"$deployDir/fitImage-its${KERNEL_FIT_NAME}${KERNEL_FIT_ITS_EXT}"
bbnote "Copying linux.bin file..."
install -m 0644 ${B}/linux.bin
$deployDir/fitImage-linux${KERNEL_FIT_NAME}${KERNEL_FIT_BIN_EXT}
fi
if [ -n "${INITRAMFS_IMAGE}" ]; then
bbnote "Copying fit-image-${INITRAMFS_IMAGE}.its source
file..."
- install -m 0644 ${B}/fit-image-${INITRAMFS_IMAGE}.its
"$deployDir/fitImage-its-${INITRAMFS_IMAGE_NAME}${KERNEL_FIT_NAME}.its"
+ install -m 0644 ${B}/fit-image-${INITRAMFS_IMAGE}.its
"$deployDir/fitImage-its-${INITRAMFS_IMAGE_NAME}${KERNEL_FIT_NAME}${KERNEL_FIT_ITS_EXT}"
if [ "${INITRAMFS_IMAGE_BUNDLE}" != "1" ]; then
bbnote "Copying fitImage-${INITRAMFS_IMAGE}
file..."
install -m 0644
${B}/${KERNEL_OUTPUT_DIR}/fitImage-${INITRAMFS_IMAGE}
"$deployDir/fitImage-${INITRAMFS_IMAGE_NAME}${KERNEL_FIT_NAME}${KERNEL_FIT_BIN_EXT}"
@@ -864,12 +864,12 @@ kernel_do_deploy_links:append() {
bbnote "Not creating versioned hardlinks, because
KERNEL_FIT_LINK_NAME is empty or identical to KERNEL_FIT_NAME"
else
if [ "${INITRAMFS_IMAGE_BUNDLE}" != "1" ]; then
- ln -vf
$deployDir/fitImage-its${KERNEL_FIT_NAME}.its
"$deployDir/fitImage-its${KERNEL_FIT_LINK_NAME}"
+ ln -vf
$deployDir/fitImage-its${KERNEL_FIT_NAME}${KERNEL_FIT_ITS_EXT}
"$deployDir/fitImage-its${KERNEL_FIT_LINK_NAME}${KERNEL_FIT_ITS_EXT}"
ln -vf
$deployDir/fitImage-linux${KERNEL_FIT_NAME}${KERNEL_FIT_BIN_EXT}
"$deployDir/fitImage-linux${KERNEL_FIT_LINK_NAME}${KERNEL_FIT_BIN_EXT}"
fi
if [ -n "${INITRAMFS_IMAGE}" ]; then
- ln -vf
$deployDir/fitImage-its-${INITRAMFS_IMAGE_NAME}${KERNEL_FIT_NAME}.its
"$deployDir/fitImage-its-${INITRAMFS_IMAGE_NAME}${KERNEL_FIT_LINK_NAME}"
+ ln -vf
$deployDir/fitImage-its-${INITRAMFS_IMAGE_NAME}${KERNEL_FIT_NAME}${KERNEL_FIT_ITS_EXT}
"$deployDir/fitImage-its-${INITRAMFS_IMAGE_NAME}${KERNEL_FIT_LINK_NAME}${KERNEL_FIT_ITS_EXT}"
if [ "${INITRAMFS_IMAGE_BUNDLE}" != "1" ]; then
ln -vf
$deployDir/fitImage-${INITRAMFS_IMAGE_NAME}${KERNEL_FIT_NAME}${KERNEL_FIT_BIN_EXT}
"$deployDir/fitImage-${INITRAMFS_IMAGE_NAME}${KERNEL_FIT_LINK_NAME}${KERNEL_FIT_BIN_EXT}"
fi
--
2.43.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#191083):
https://lists.openembedded.org/g/openembedded-core/message/191083
Mute This Topic: https://lists.openembedded.org/mt/102747724/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 04/21] kernel: move the leading dash into KERNEL_ARTIFACT_NAME
* this matches how IMAGE_MACHINE_SUFFIX works and we can use
that for the default value
* allows to set IMAGE_MACHINE_SUFFIX to empty for people
who prefer to keep MACHINE name only in the directory name
otherwise there would be a stray dash in:
lrwxrwxrwx 2 martin martin 12 Nov 18 13:25 bzImage -> bzImage-.bin
-rw-r--r-- 2 martin martin 12M Nov 18 13:25 bzImage-.bin
-rw-r--r-- 2 martin martin 182M Nov 18 13:25 modules-.tgz
if you set
KERNEL_ARTIFACT_NAME = ""
[YOCTO #12937]
Signed-off-by: Martin Jansa
---
.../classes-recipe/kernel-artifact-names.bbclass | 6 +++---
meta/classes-recipe/kernel-devicetree.bbclass| 12 ++--
meta/classes-recipe/kernel-fitimage.bbclass | 16
meta/classes-recipe/kernel.bbclass | 10 +-
4 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/meta/classes-recipe/kernel-artifact-names.bbclass
b/meta/classes-recipe/kernel-artifact-names.bbclass
index 186c6bc5b9..023ce61de5 100644
--- a/meta/classes-recipe/kernel-artifact-names.bbclass
+++ b/meta/classes-recipe/kernel-artifact-names.bbclass
@@ -14,7 +14,7 @@ inherit image-artifact-names
KERNEL_VERSION_SUFFIX ?= "${IMAGE_VERSION_SUFFIX}"
-KERNEL_ARTIFACT_NAME ?= "${MACHINE}"
+KERNEL_ARTIFACT_NAME ?= "${IMAGE_MACHINE_SUFFIX}"
KERNEL_ARTIFACT_LINK_NAME ?= "${KERNEL_ARTIFACT_NAME}${KERNEL_VERSION_SUFFIX}"
KERNEL_ARTIFACT_BIN_EXT ?= ".bin"
@@ -35,5 +35,5 @@ MODULE_TARBALL_NAME ?= "${KERNEL_ARTIFACT_NAME}"
MODULE_TARBALL_LINK_NAME ?= "${KERNEL_ARTIFACT_LINK_NAME}"
MODULE_TARBALL_DEPLOY ?= "1"
-INITRAMFS_NAME ?= "initramfs-${KERNEL_ARTIFACT_NAME}"
-INITRAMFS_LINK_NAME ?= "initramfs-${KERNEL_ARTIFACT_LINK_NAME}"
+INITRAMFS_NAME ?= "initramfs${KERNEL_ARTIFACT_NAME}"
+INITRAMFS_LINK_NAME ?= "initramfs${KERNEL_ARTIFACT_LINK_NAME}"
diff --git a/meta/classes-recipe/kernel-devicetree.bbclass
b/meta/classes-recipe/kernel-devicetree.bbclass
index 1fde90f023..2cd8588304 100644
--- a/meta/classes-recipe/kernel-devicetree.bbclass
+++ b/meta/classes-recipe/kernel-devicetree.bbclass
@@ -102,7 +102,7 @@ kernel_do_deploy:append() {
fi
install -m 0644 ${D}/${KERNEL_DTBDEST}/$dtb
$deployDir/$dtb_base_name.$dtb_ext
if [ -n "${KERNEL_DTB_NAME}" ] ; then
- ln -vf $deployDir/$dtb_base_name.$dtb_ext
$deployDir/$dtb_base_name-${KERNEL_DTB_NAME}.$dtb_ext
+ ln -vf $deployDir/$dtb_base_name.$dtb_ext
$deployDir/$dtb_base_name${KERNEL_DTB_NAME}.$dtb_ext
fi
for type in ${KERNEL_IMAGETYPE_FOR_MAKE}; do
if [ "$type" = "zImage" ] && [
"${KERNEL_DEVICETREE_BUNDLE}" = "1" ]; then
@@ -111,7 +111,7 @@ kernel_do_deploy:append() {
>
$deployDir/$type-$dtb_base_name.$dtb_ext${KERNEL_DTB_BIN_EXT}
if [ -n "${KERNEL_DTB_NAME}" ]; then
ln -sf
$type-$dtb_base_name.$dtb_ext${KERNEL_DTB_BIN_EXT} \
-
$deployDir/$type-$dtb_base_name-${KERNEL_DTB_NAME}.$dtb_ext${KERNEL_DTB_BIN_EXT}
+
$deployDir/$type-$dtb_base_name${KERNEL_DTB_NAME}.$dtb_ext${KERNEL_DTB_BIN_EXT}
fi
if [ -e
"${KERNEL_OUTPUT_DIR}/${type}.initramfs" ]; then
cat
${KERNEL_OUTPUT_DIR}/${type}.initramfs \
@@ -119,7 +119,7 @@ kernel_do_deploy:append() {
>
$deployDir/${type}-${INITRAMFS_NAME}-$dtb_base_name.$dtb_ext${KERNEL_DTB_BIN_EXT}
if [ -n "${KERNEL_DTB_NAME}" ]; then
ln -sf
${type}-${INITRAMFS_NAME}-$dtb_base_name.$dtb_ext${KERNEL_DTB_BIN_EXT} \
-
$deployDir/${type}-${INITRAMFS_NAME}-$dtb_base_name-${KERNEL_DTB_NAME}.$dtb_ext${KERNEL_DTB_BIN_EXT}
+
$deployDir/${type}-${INITRAMFS_NAME}-$dtb_base_name${KERNEL_DTB_NAME}.$dtb_ext${KERNEL_DTB_BIN_EXT}
fi
fi
fi
@@ -134,14 +134,14 @@ kernel_do_deploy_links:append() {
dtb=`normalize_dtb "$dtbf"`
dtb_ext=${dtb##*.}
dtb_base_name=`basename $dtb .$dtb_ext`
- ln -vf $deployDir/$dtb_base_name.$dtb_ext
$deployDir/$dtb_base_name-${KERNEL_DTB_LINK_NAME}.$dtb_ext
+ ln -vf $deployDir/$dtb_base_nam
[OE-core] [PATCH 05/21] kernel-fitimage.bbclass: avoid duplicate .bin extension
* the linux.bin was deployed as:
fitImage-linux.bin${KERNEL_FIT_NAME}${KERNEL_FIT_BIN_EXT}
where KERNEL_FIT_BIN_EXT is the 2nd ".bin"
* add the${KERNEL_FIT_BIN_EXT} also to corresponding links:
fitImage-linux${KERNEL_FIT_LINK_NAME}${KERNEL_FIT_BIN_EXT}
[YOCTO #12937]
Signed-off-by: Martin Jansa
---
meta/classes-recipe/kernel-fitimage.bbclass | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta/classes-recipe/kernel-fitimage.bbclass
b/meta/classes-recipe/kernel-fitimage.bbclass
index 266680ffa8..25a33123a6 100644
--- a/meta/classes-recipe/kernel-fitimage.bbclass
+++ b/meta/classes-recipe/kernel-fitimage.bbclass
@@ -845,7 +845,7 @@ kernel_do_deploy:append() {
bbnote "Copying fit-image.its source file..."
install -m 0644 ${B}/fit-image.its
"$deployDir/fitImage-its${KERNEL_FIT_NAME}.its"
bbnote "Copying linux.bin file..."
- install -m 0644 ${B}/linux.bin
$deployDir/fitImage-linux.bin${KERNEL_FIT_NAME}${KERNEL_FIT_BIN_EXT}
+ install -m 0644 ${B}/linux.bin
$deployDir/fitImage-linux${KERNEL_FIT_NAME}${KERNEL_FIT_BIN_EXT}
fi
if [ -n "${INITRAMFS_IMAGE}" ]; then
@@ -865,13 +865,13 @@ kernel_do_deploy_links:append() {
else
if [ "${INITRAMFS_IMAGE_BUNDLE}" != "1" ]; then
ln -vf
$deployDir/fitImage-its${KERNEL_FIT_NAME}.its
"$deployDir/fitImage-its${KERNEL_FIT_LINK_NAME}"
- ln -vf
$deployDir/fitImage-linux.bin${KERNEL_FIT_NAME}${KERNEL_FIT_BIN_EXT}
"$deployDir/fitImage-linux.bin${KERNEL_FIT_LINK_NAME}"
+ ln -vf
$deployDir/fitImage-linux${KERNEL_FIT_NAME}${KERNEL_FIT_BIN_EXT}
"$deployDir/fitImage-linux${KERNEL_FIT_LINK_NAME}${KERNEL_FIT_BIN_EXT}"
fi
if [ -n "${INITRAMFS_IMAGE}" ]; then
ln -vf
$deployDir/fitImage-its-${INITRAMFS_IMAGE_NAME}${KERNEL_FIT_NAME}.its
"$deployDir/fitImage-its-${INITRAMFS_IMAGE_NAME}${KERNEL_FIT_LINK_NAME}"
if [ "${INITRAMFS_IMAGE_BUNDLE}" != "1" ]; then
- ln -vf
$deployDir/fitImage-${INITRAMFS_IMAGE_NAME}${KERNEL_FIT_NAME}${KERNEL_FIT_BIN_EXT}
"$deployDir/fitImage-${INITRAMFS_IMAGE_NAME}${KERNEL_FIT_LINK_NAME}"
+ ln -vf
$deployDir/fitImage-${INITRAMFS_IMAGE_NAME}${KERNEL_FIT_NAME}${KERNEL_FIT_BIN_EXT}
"$deployDir/fitImage-${INITRAMFS_IMAGE_NAME}${KERNEL_FIT_LINK_NAME}${KERNEL_FIT_BIN_EXT}"
fi
fi
fi
--
2.43.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#191082):
https://lists.openembedded.org/g/openembedded-core/message/191082
Mute This Topic: https://lists.openembedded.org/mt/102747723/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 03/21] image, kernel: allow to disable creating the hardlinks by setting *LINK_NAME variables to empty
From: Martin Jansa
* they can be disabled individually by setting *_LINK_NAME
to empty or disable them all by setting IMAGE_VERSION_SUFFIX
to empty (making them equal to *_NAME variables)
There are couple *_LINK_NAME variables:
IMAGE_LINK_NAME = ""
KERNEL_IMAGE_LINK_NAME = ""
KERNEL_DTB_LINK_NAME = ""
KERNEL_FIT_LINK_NAME = ""
MODULE_TARBALL_LINK_NAME = ""
INITRAMFS_LINK_NAME = ""
or
IMAGE_MACHINE_SUFFIX = ""
IMAGE_NAME_SUFFIX = ""
IMAGE_VERSION_SUFFIX = ""
to have really the minimal filenames:
$ ls tmp/deploy/images/qemux86-64/
bzImage core-image-minimal.manifest
core-image-minimal.tar.bz2
bzImage-qemux86-64.bin core-image-minimal.qemuboot.conf
core-image-minimal.testdata.json
core-image-minimal.ext4 core-image-minimal.spdx.tar.zst
modules-qemux86-64.tgz
and to remove MACHINE name from kernel artifacts as well
(if you prefer the MACHINE name in directory only), you can set:
KERNEL_ARTIFACT_NAME = ""
[YOCTO #12937]
Signed-off-by: Martin Jansa
---
meta/classes-recipe/image.bbclass | 3 +-
meta/classes-recipe/kernel-devicetree.bbclass | 32 +
meta/classes-recipe/kernel-fitimage.bbclass | 17 -
meta/classes-recipe/kernel.bbclass| 36 ---
4 files changed, 49 insertions(+), 39 deletions(-)
diff --git a/meta/classes-recipe/image.bbclass
b/meta/classes-recipe/image.bbclass
index 2dd004d312..48dc70b8fc 100644
--- a/meta/classes-recipe/image.bbclass
+++ b/meta/classes-recipe/image.bbclass
@@ -595,7 +595,8 @@ python create_symlinks() {
taskname = d.getVar("BB_CURRENTTASK")
subimages = (d.getVarFlag("do_" + taskname, 'subimages', False) or
"").split()
-if not link_name:
+if not link_name or link_name == img_name:
+bb.note("Not creating versioned hardlinks, because IMAGE_LINK_NAME is
empty or identical to IMAGE_NAME")
return
for type in subimages:
dst = os.path.join(deploy_dir, link_name + "." + type)
diff --git a/meta/classes-recipe/kernel-devicetree.bbclass
b/meta/classes-recipe/kernel-devicetree.bbclass
index cbfaa5c183..1fde90f023 100644
--- a/meta/classes-recipe/kernel-devicetree.bbclass
+++ b/meta/classes-recipe/kernel-devicetree.bbclass
@@ -127,22 +127,24 @@ kernel_do_deploy:append() {
done
}
kernel_do_deploy_links:append() {
- for dtbf in ${KERNEL_DEVICETREE}; do
- dtb=`normalize_dtb "$dtbf"`
- dtb_ext=${dtb##*.}
- dtb_base_name=`basename $dtb .$dtb_ext`
- if [ -n "${KERNEL_DTB_LINK_NAME}" ] ; then
+ if [ -z "${KERNEL_DTB_LINK_NAME}" -o "${KERNEL_DTB_LINK_NAME}" =
"${KERNEL_DTB_NAME}" ] ; then
+ bbnote "Not creating versioned hardlinks, because
KERNEL_DTB_LINK_NAME is empty or identical to KERNEL_DTB_NAME"
+ else
+ for dtbf in ${KERNEL_DEVICETREE}; do
+ dtb=`normalize_dtb "$dtbf"`
+ dtb_ext=${dtb##*.}
+ dtb_base_name=`basename $dtb .$dtb_ext`
ln -vf $deployDir/$dtb_base_name.$dtb_ext
$deployDir/$dtb_base_name-${KERNEL_DTB_LINK_NAME}.$dtb_ext
- fi
- for type in ${KERNEL_IMAGETYPE_FOR_MAKE}; do
- if [ "$type" = "zImage" ] && [
"${KERNEL_DEVICETREE_BUNDLE}" = "1" ] && [ -n "${KERNEL_DTB_LINK_NAME}" ]; then
- ln -vf
$deployDir/$type-$dtb_base_name.$dtb_ext${KERNEL_DTB_BIN_EXT} \
-
$deployDir/$type-$dtb_base_name-${KERNEL_DTB_LINK_NAME}.$dtb_ext${KERNEL_DTB_BIN_EXT}
- if [ -e
"${KERNEL_OUTPUT_DIR}/${type}.initramfs" ]; then
- ln -vf
$deployDir/${type}-${INITRAMFS_NAME}-$dtb_base_name.$dtb_ext${KERNEL_DTB_BIN_EXT}
\
-
$deployDir/${type}-${INITRAMFS_NAME}-$dtb_base_name-${KERNEL_DTB_LINK_NAME}.$dtb_ext${KERNEL_DTB_BIN_EXT}
+ for type in ${KERNEL_IMAGETYPE_FOR_MAKE}; do
+ if [ "$type" = "zImage" ] && [
"${KERNEL_DEVICETREE_BUNDLE}" = "1" ] ; then
+ ln -vf
$deployDir/$type-$dtb_base_name.$dtb_ext${KERNEL_DTB_BIN_EXT} \
+
$deployDir/$type-$dtb_base_name-${KERNEL_DTB_LINK_NAME}.$dtb_ext${KERNEL_DTB_BIN_EXT}
+ if [ -e
"${KERNEL_OUTPUT_DIR}/${type}.initramfs" ]; then
+ ln -vf
$deployDir/${type}-${INITRAMFS_NAME}-$dtb_base_name.$dtb_ext${KERNEL_DTB
[OE-core] [PATCH 00/21] Consistent naming scheme for deployed artifacts
nimal.tar.bz2
55389029 -rw-r--r-- 2 martin martin263255 Nov 21 21:59
core-image-minimal.testdata.json
55387973 lrwxrwxrwx 2 martin martin12 Nov 21 21:59 fitImage ->
fitImage.bin
55387964 -rw-r--r-- 2 martin martin 11398621 Nov 21 21:59
fitImage-core-image-minimal.bin
55387965 -rw-r--r-- 2 martin martin 2417 Nov 21 21:59
fitImage-its-core-image-minimal.its
55387968 -rw-r--r-- 2 martin martin 1638 Nov 21 21:59 fitImage-its.its
55387966 -rw-r--r-- 2 martin martin 7149168 Nov 21 21:59 fitImage-linux.bin
55386185 -rw-r--r-- 2 martin martin 7151161 Nov 21 21:59 fitImage.bin
55387972 -rw-r--r-- 2 martin martin 45290074 Nov 21 21:59 modules.tgz
55394322 -rw-r--r-- 4 martin martin786682 Nov 21 21:59 u-boot-fitImage
55394327 -rw-r--r-- 2 martin martin 12284 Nov 21 21:59 u-boot-initial-env
55394325 -rw-r--r-- 4 martin martin 805 Nov 21 21:59 u-boot-its
55394319 -rw-r--r-- 2 martin martin645864 Nov 21 21:59 u-boot-nodtb.bin
55394322 -rw-r--r-- 4 martin martin786682 Nov 21 21:59 u-boot.bin
55386290 -rw-r--r-- 2 martin martin139160 Nov 21 21:59 u-boot.dtb
55394325 -rw-r--r-- 4 martin martin 805 Nov 21 21:59 u-boot.its
36783106 -rw-r--r-- 2 martin martin 231 Nov 21 21:59
ubinize-core-image-base.cfg
55342465 lrwxrwxrwx 2 martin martin10 Nov 21 21:59 zImage -> zImage.bin
55342449 -rw-r--r-- 2 martin martin 7149168 Nov 21 21:59 zImage.bin
The following changes since commit faa32bbb35e92a14b8064715c12e1007fd106b34:
ffmpeg: Upgrade 6.0 -> 6.1 (2023-11-20 15:30:46 +)
are available in the Git repository at:
https://git.openembedded.org/openembedded-core-contrib jansa/artifacts
https://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/artifacts
Martin Jansa (21):
image*.bbclass, kernel*.bbclass: create version-less artifacts and
versioned hard links
create-spdx-2.2.bbclass: use hardlink as well
image, kernel: allow to disable creating the hardlinks by setting
*LINK_NAME variables to empty
kernel: move the leading dash into KERNEL_ARTIFACT_NAME
kernel-fitimage.bbclass: avoid duplicate .bin extension
kernel-fitimage.bbclass: add .its extension also to links
uboot: use ${IMAGE_MACHINE_SUFFIX} instead of -${MACHINE} and use
hardlinks
image.bbclass: rename create_symlinks to create_hardlinks
image-artifact-names.bbclass: add IMAGE_VERSION_SUFFIX_DATETIME which
uses SOURCE_DATE_EPOCH
oeqa: bbtests.BitbakeTests.test_image_manifest: use just isfile()
instead of islink()
oeqa: wic: use just isfile() instead of islink()
linux-dummy: add do_deploy_links task
kernel.bbclass: inherit KERNEL_CLASSES at the end
image.bbclass: don't append -dbg suffix twice
oeqa: imagefeatures: append -dbg suffix at the end of IMAGE_NAME not
IMAGE_LINK_NAME
oeqa: gdbserver: append -dbg suffix at the end of IMAGE_NAME not
IMAGE_LINK_NAME
oeqa: fitimage: respect KERNEL_FIT_NAME
selftest: multiconfig-image-packager: use IMAGE_NAME instead of
IMAGE_LINK_NAME
image.bbclass: remove hardlinks as well
populate_sdk_ext.bbclass: add *:do_shared_workdir to
BB_SETSCENE_ENFORCE_IGNORE_TASKS
u-boot.inc: don't replace the binary with symlink
.../multiconfig-image-packager_0.1.bb | 12 +-
meta/classes-global/base.bbclass | 3 +
.../image-artifact-names.bbclass | 18 +-
meta/classes-recipe/image-live.bbclass| 2 +-
meta/classes-recipe/image.bbclass | 25 ++-
.../kernel-artifact-names.bbclass | 12 +-
meta/classes-recipe/kernel-devicetree.bbclass | 41 ++--
meta/classes-recipe/kernel-fitimage.bbclass | 40 ++--
meta/classes-recipe/kernel.bbclass| 97 +
meta/classes-recipe/populate_sdk_ext.bbclass | 2 +-
meta/classes-recipe/qemuboot.bbclass | 2 +-
.../rootfs-postcommands.bbclass | 4 +-
meta/classes-recipe/uboot-config.bbclass | 22 +-
meta/classes-recipe/uboot-sign.bbclass| 68 +++---
meta/classes/create-spdx-2.2.bbclass | 2 +-
meta/classes/cve-check.bbclass| 14 +-
meta/lib/oe/cve_check.py | 6 +-
meta/lib/oeqa/selftest/cases/bbtests.py | 2 +-
meta/lib/oeqa/selftest/cases/fitimage.py | 98 +
meta/lib/oeqa/selftest/cases/gdbserver.py | 6 +-
meta/lib/oeqa/selftest/cases/imagefeatures.py | 4 +-
meta/lib/oeqa/selftest/cases/wic.py | 2 +-
meta/recipes-bsp/u-boot/u-boot.inc| 200 +-
meta/recipes-kernel/linux/linux-dummy.bb | 5 +
24 files changed, 368 insertions(+), 319 deletions(-)
--
2.43.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#191077):
https://lists.openembedded.org/g/openembedded-core/message/191077
Mute This Topic: https://lists.openembedded.org/mt/102747718/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 01/21] image*.bbclass, kernel*.bbclass: create version-less artifacts and versioned hard links
From: Martin Jansa
* instead of versioned artifacts and version-less symlinks
* We used to create the actual artifact files with some version
in the filename and then created symlink without any version
which was updated to point to the latest one created.
In some scenarios it's useful to create all artifacts - typically
rootfs and kernel images with the same version - like release
build even when the kernel itself wasn't modified since the
previous release.
If we include the release version in the regular _NAME variables
then we'll need to re-run do_deploy and do_image which will cause
kernel to be rebuilt and image to be re-created even when the
only change since last build was the version number.
With this change we can re-use kernel and image from sstate when
nothing was changed and run only very fast do_deploy_links task
which just adds another hard link to existing artifact from
sstate.
* This is already used by various LGE builds as do_webos_deploy_fixup()
https://github.com/webosose/meta-webosose/blob/master/meta-webos/classes/webos_deploy.bbclass
but injecting this task in all the right places is difficult
and sometimes requires whole bbclass to be duplicated. Having
simpler way of versioning artifacts directly in oe-core might
be useful for others.
* move IMAGE_VERSION_SUFFIX from _NAME variables to _LINK_NAME
that way e.g. kernel.do_deploy can be reused from sstate to
provide "version-less" artifacts and then very fast
do_deploy_links task just adds links with consistent suffixes
(by default the version from the recipe but could be easily set
to e.g. some release name when building some products).
* create hard links instead of symlinks, so that whatever version
the filename says is really there
* some IMAGE_FSTYPES might need the "version-less" IMAGE_NAME file
to be removed first or they might either append or update the
content of the image instead of creating new image file from
scratch - I have seen this only with one proprietary format we
generate with our own tool, so hopefully this isn't very common
* this is basically the mechanism are using in webOS with
WEBOS_IMAGE_NAME_SUFFIX which is for official builds set from
jenkins job and then all artifacts (images as well as corresponding
kernel files) have the same version string)
* without this, you can still easily set the variables to contain
the version from jenkins job (excluded from sstate signature like
DATETIME currently is to prevent rebuilding it everytime even when
the content didn't change) but then when kernel is reused from sstate
you can have version 1.0 used on kernel artifacts and 2.0 on image
artifacts.
* if you don't exclude the version string with vardepsexclude, then
you get the right version in the filenames but for cost of
re-executing do_deploy every single time, which with rm_work will
cause all kernel tasks to be re-executed (together with everything
which depends on it like external modules etc).
* the implementation "from outside" is a bit tricky as shown in webOS
OSE, because first you need to reverse the meaning of IMAGE_NAME
and IMAGE_LINK_NAME like here, but also replace all symlinks with
hardlinks and then adjust all recipes/bbclasses to depend on our
do_deploy_fixup task instead of the original do_deploy
see the variable modifications:
https://github.com/webosose/meta-webosose/blob/a35e81622aae1066591e44a132d01297ff478248/meta-webos/conf/distro/include/webos.inc#L65
and then various bbclasses to hook do_webos_deploy_fixup task creating
the hardlinks for possible artifacts:
https://github.com/webosose/meta-webosose/blob/a35e81622aae1066591e44a132d01297ff478248/meta-webos/classes/webos_deploy.bbclass
https://github.com/webosose/meta-webosose/blob/a35e81622aae1066591e44a132d01297ff478248/meta-webos/classes/kernel.bbclass
https://github.com/webosose/meta-webosose/blob/a35e81622aae1066591e44a132d01297ff478248/meta-webos/classes/image.bbclass
so hopefully with all these changes in oe-core other project can
achieve the same just by setting one variable IMAGE_VERSION_SUFFIX
* drop ${PKGE}-${PKGV}-${PR} from kernel artifacts names (this is the
latest build) and add it only in hardlinks created in do_deploy_links
so that we can use PKGR there again (because these links are generally
used only by human operators and they don't have their own TASKHASH or
the IMAGE_VERSION_SUFFIX might be set to some release name which they
do understand
* this allows to drop package_get_auto_pr from kernel do_deploy as well,
leaving only 2 EXTENDPRAUTO bumps for each kernel build (do_package
and do_deploy_links, unfortunatelly these will still have different
value, so if you're looking for the exact kernel image in deploy
directory based on kernel image package version seen on the device the
EXTENDPRAUTO part of PR will be different).
[YOCTO #12937]
Signed-off-by
Re: [OE-core][nanbield 11/33] kernel.bbclass: Use strip utility used for kernel build in do_package
This requires additional fix from:
https://git.openembedded.org/openembedded-core/commit/?id=41f019afc41f800b622c46a6d7cf1beffc97716a
Cheers,
On Mon, Nov 20, 2023 at 5:39 PM Steve Sakoman wrote:
> From: Khem Raj
>
> os.environ does not pass this down to runstrip() function and in
> strip_execs() its using STRIP bitbake variable to find the strip utility
> to use. Since there might be a trailing whitespace in KERNEL_STRIP
> remove that otherwise python is not able to launch it.
> e.g.
>
> FileNotFoundError: [Errno 2] No such file or directory:
> 'riscv64-yoe-linux-strip '
>
> This is more evident when STRIP and KERNEL_STRIP are different utilities
> e.g. when using clang as default toolchain but using gcc+binutils only for
> kernel build.
>
> Signed-off-by: Khem Raj
> Cc: Bruce Ashfield
> Signed-off-by: Luca Ceresoli
> Signed-off-by: Richard Purdie
> (cherry picked from commit 77497dbdca92ab4d6386a071bc281c42a7e8a14b)
> Signed-off-by: Steve Sakoman
> ---
> meta/classes-recipe/kernel.bbclass | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/classes-recipe/kernel.bbclass
> b/meta/classes-recipe/kernel.bbclass
> index 2ec9ea2091..16b85dbca4 100644
> --- a/meta/classes-recipe/kernel.bbclass
> +++ b/meta/classes-recipe/kernel.bbclass
> @@ -336,7 +336,7 @@ kernel_do_transform_bundled_initramfs() {
> do_transform_bundled_initramfs[dirs] = "${B}"
>
> python do_package:prepend () {
> -os.environ['STRIP'] = d.getVar('KERNEL_STRIP')
> +d.setVar('STRIP', d.getVar('KERNEL_STRIP').strip())
> }
>
> python do_devshell:prepend () {
> --
> 2.34.1
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#190923):
https://lists.openembedded.org/g/openembedded-core/message/190923
Mute This Topic: https://lists.openembedded.org/mt/102710661/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] package: split strip cmd when ccache is used
It was already removed from KERNEL_STRIP in: https://git.openembedded.org/openembedded-core/commit/?id=41f019afc41f800b622c46a6d7cf1beffc97716a On Mon, Nov 20, 2023 at 4:28 PM Javier Tia wrote: > On 10/31/23 06:26, Richard Purdie wrote: > > > > That looks very like a hack/workaround rather than a real fix. The > > packaging code shouldn't know/care about ccache. > Took another look at the problem to find a proper solution. Removing > CCACHE from KERNEL_STRIP along with the rest of the KERNEL_* variables, > except for the compiler. > > As of right now, ccache is limited to compilers. Attempting to use it > with other tools is not beneficial. I received the confirmation from > ccache's maintainer. [1] > > I will be submitting another patch. > > [1] > https://github.com/ccache/ccache/discussions/1346#discussioncomment-7616180 > > Regards, > » Javier Tia > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#190883): https://lists.openembedded.org/g/openembedded-core/message/190883 Mute This Topic: https://lists.openembedded.org/mt/102291706/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCHv2 12/12] igt-gpu-tools: drop PR from /usr/src/debug paths
Signed-off-by: Martin Jansa
---
meta/recipes-graphics/igt-gpu-tools/igt-gpu-tools_git.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-graphics/igt-gpu-tools/igt-gpu-tools_git.bb
b/meta/recipes-graphics/igt-gpu-tools/igt-gpu-tools_git.bb
index 529b374c7d..90cd09ea70 100644
--- a/meta/recipes-graphics/igt-gpu-tools/igt-gpu-tools_git.bb
+++ b/meta/recipes-graphics/igt-gpu-tools/igt-gpu-tools_git.bb
@@ -24,7 +24,7 @@ PACKAGE_BEFORE_PN = "${PN}-benchmarks ${PN}-tests"
PACKAGECONFIG[chamelium] = "-Dchamelium=enabled,-Dchamelium=disabled,gsl
xmlrpc-c"
-EXTRA_OEMESON = "-Ddocs=disabled -Drunner=enabled
-Dsrcdir=/usr/src/debug/${PN}/${PV}-${PR}/git/ -Dversion_hash=${PV}"
+EXTRA_OEMESON = "-Ddocs=disabled -Drunner=enabled
-Dsrcdir=${TARGET_DBGSRC_DIR}/git/ -Dversion_hash=${PV}"
COMPATIBLE_HOST = "(x86_64.*|i.86.*|arm.*|aarch64).*-linux"
COMPATIBLE_HOST:libc-musl:class-target = "null"
SECURITY_LDFLAGS = "${SECURITY_X_LDFLAGS}"
--
2.42.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#190826):
https://lists.openembedded.org/g/openembedded-core/message/190826
Mute This Topic: https://lists.openembedded.org/mt/102637413/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCHv2 11/12] python3-cython: drop PE, PR from /usr/src/debug paths
Signed-off-by: Martin Jansa
---
.../python/python3-cython_0.29.36.bb | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/meta/recipes-devtools/python/python3-cython_0.29.36.bb
b/meta/recipes-devtools/python/python3-cython_0.29.36.bb
index 78be2b94ed..07638d7ad7 100644
--- a/meta/recipes-devtools/python/python3-cython_0.29.36.bb
+++ b/meta/recipes-devtools/python/python3-cython_0.29.36.bb
@@ -20,17 +20,17 @@ do_install:append() {
PACKAGESPLITFUNCS =+ "cython_fix_sources"
cython_fix_sources () {
- for f in
${PKGD}/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR}/Cython/Compiler/FlowControl.c
\
-
${PKGD}/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR}/Cython/Compiler/FusedNode.c \
-
${PKGD}/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR}/Cython/Compiler/Scanning.c \
-
${PKGD}/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR}/Cython/Compiler/Visitor.c \
-
${PKGD}/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR}/Cython/Plex/Actions.c \
-
${PKGD}/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR}/Cython/Plex/Scanners.c \
-
${PKGD}/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR}/Cython/Runtime/refnanny.c \
-
${PKGD}/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR}/Cython/Tempita/_tempita.c \
+ for f in ${PKGD}${TARGET_DBGSRC_DIR}/Cython/Compiler/FlowControl.c \
+ ${PKGD}${TARGET_DBGSRC_DIR}/Cython/Compiler/FusedNode.c \
+ ${PKGD}${TARGET_DBGSRC_DIR}/Cython/Compiler/Scanning.c \
+ ${PKGD}${TARGET_DBGSRC_DIR}/Cython/Compiler/Visitor.c \
+ ${PKGD}${TARGET_DBGSRC_DIR}/Cython/Plex/Actions.c \
+ ${PKGD}${TARGET_DBGSRC_DIR}/Cython/Plex/Scanners.c \
+ ${PKGD}${TARGET_DBGSRC_DIR}/Cython/Runtime/refnanny.c \
+ ${PKGD}${TARGET_DBGSRC_DIR}/Cython/Tempita/_tempita.c \
${PKGD}${libdir}/${PYTHON_DIR}/site-packages/Cython*/SOURCES.txt; do
if [ -e $f ]; then
- sed -i -e
's#${WORKDIR}/Cython-${PV}#/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR}#g' $f
+ sed -i -e
's#${WORKDIR}/Cython-${PV}#${TARGET_DBGSRC_DIR}#g' $f
fi
done
}
--
2.42.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#190825):
https://lists.openembedded.org/g/openembedded-core/message/190825
Mute This Topic: https://lists.openembedded.org/mt/102637411/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCHv2 09/12] vulkan-samples: drop PE, PR from /usr/src/debug paths
Signed-off-by: Martin Jansa
---
.../0001-vulkan-samples-Fix-reproducibility-issue.patch | 2 +-
meta/recipes-graphics/vulkan/vulkan-samples_git.bb | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git
a/meta/recipes-graphics/vulkan/vulkan-samples/0001-vulkan-samples-Fix-reproducibility-issue.patch
b/meta/recipes-graphics/vulkan/vulkan-samples/0001-vulkan-samples-Fix-reproducibility-issue.patch
index 7609011421..c16e05112f 100644
---
a/meta/recipes-graphics/vulkan/vulkan-samples/0001-vulkan-samples-Fix-reproducibility-issue.patch
+++
b/meta/recipes-graphics/vulkan/vulkan-samples/0001-vulkan-samples-Fix-reproducibility-issue.patch
@@ -9,7 +9,7 @@ in the debug source remapping from CFLAGS
We export the right path to use in the recipe with:
-EXTRA_OECMAKE =
"-DCMAKE_DEBUG_SRCDIR=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR}/"
+EXTRA_OECMAKE = "-DCMAKE_DEBUG_SRCDIR=${TARGET_DBGSRC_DIR}/"
and we then patch this into the code instead of the broken use
of CMAKE_SOURCE_DIR since __FILENAME__ will match our path prefix
diff --git a/meta/recipes-graphics/vulkan/vulkan-samples_git.bb
b/meta/recipes-graphics/vulkan/vulkan-samples_git.bb
index 66f1ef5e9d..d60c0f3190 100644
--- a/meta/recipes-graphics/vulkan/vulkan-samples_git.bb
+++ b/meta/recipes-graphics/vulkan/vulkan-samples_git.bb
@@ -29,7 +29,7 @@ FILES:${PN} += "${datadir}"
# used for logging with LOGE in the code. We need to make this match the value
we use
# in the debug source remapping from CFLAGS
#
-EXTRA_OECMAKE +=
"-DCMAKE_DEBUG_SRCDIR=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR}/"
+EXTRA_OECMAKE += "-DCMAKE_DEBUG_SRCDIR=${TARGET_DBGSRC_DIR}/"
# Binaries built with PCH enabled don't appear reproducible, differing results
were seen
# from some builds depending on the point the PCH was compiled. Disable it to
be
# deterministic
--
2.42.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#190823):
https://lists.openembedded.org/g/openembedded-core/message/190823
Mute This Topic: https://lists.openembedded.org/mt/102637409/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCHv2 10/12] valgrind: drop PE, PR from /usr/src/debug paths
Signed-off-by: Martin Jansa
---
meta/recipes-devtools/valgrind/valgrind_3.21.0.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-devtools/valgrind/valgrind_3.21.0.bb
b/meta/recipes-devtools/valgrind/valgrind_3.21.0.bb
index 68ab319a1b..67a197c509 100644
--- a/meta/recipes-devtools/valgrind/valgrind_3.21.0.bb
+++ b/meta/recipes-devtools/valgrind/valgrind_3.21.0.bb
@@ -239,8 +239,8 @@ do_install_ptest() {
# As the binary isn't stripped or debug-splitted, the source file isn't
fetched
# via dwarfsrcfiles either, so it needs to be installed manually.
-mkdir -p ${D}/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR}/none/tests/
-install ${S}/none/tests/tls.c
${D}/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR}/none/tests/
+mkdir -p ${D}${TARGET_DBGSRC_DIR}/none/tests/
+install ${S}/none/tests/tls.c ${D}${TARGET_DBGSRC_DIR}/none/tests/
}
do_install_ptest:append:x86-64 () {
--
2.42.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#190824):
https://lists.openembedded.org/g/openembedded-core/message/190824
Mute This Topic: https://lists.openembedded.org/mt/102637410/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCHv2 08/12] rust: drop PE, PR from /usr/src/debug paths
Signed-off-by: Martin Jansa
---
meta/classes-recipe/rust-common.bbclass| 2 +-
meta/recipes-devtools/rust/cargo_1.70.0.bb | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/classes-recipe/rust-common.bbclass
b/meta/classes-recipe/rust-common.bbclass
index 878272721c..3d73a370ec 100644
--- a/meta/classes-recipe/rust-common.bbclass
+++ b/meta/classes-recipe/rust-common.bbclass
@@ -14,7 +14,7 @@ FILES:${PN}-dev += "${rustlibdir}/*.rlib
${rustlibdir}/*.rmeta"
FILES:${PN}-dbg += "${rustlibdir}/.debug"
RUSTLIB = "-L ${STAGING_DIR_HOST}${rustlibdir}"
-RUST_DEBUG_REMAP =
"--remap-path-prefix=${WORKDIR}=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR}"
+RUST_DEBUG_REMAP = "--remap-path-prefix=${WORKDIR}=${TARGET_DBGSRC_DIR}"
RUSTFLAGS += "${RUSTLIB} ${RUST_DEBUG_REMAP}"
RUSTLIB_DEP ?= "libstd-rs"
RUST_PANIC_STRATEGY ?= "unwind"
diff --git a/meta/recipes-devtools/rust/cargo_1.70.0.bb
b/meta/recipes-devtools/rust/cargo_1.70.0.bb
index a5c1064106..50b7e7c7b4 100644
--- a/meta/recipes-devtools/rust/cargo_1.70.0.bb
+++ b/meta/recipes-devtools/rust/cargo_1.70.0.bb
@@ -19,7 +19,7 @@ CARGO_VENDORING_DIRECTORY = "${RUSTSRC}/vendor"
inherit cargo pkgconfig
-DEBUG_PREFIX_MAP +=
"-fdebug-prefix-map=${RUSTSRC}/vendor=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR}"
+DEBUG_PREFIX_MAP += "-fdebug-prefix-map=${RUSTSRC}/vendor=${TARGET_DBGSRC_DIR}"
do_cargo_setup_snapshot () {
${WORKDIR}/rust-snapshot-components/${CARGO_SNAPSHOT}/install.sh
--prefix="${WORKDIR}/${CARGO_SNAPSHOT}" --disable-ldconfig
--
2.42.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#190822):
https://lists.openembedded.org/g/openembedded-core/message/190822
Mute This Topic: https://lists.openembedded.org/mt/102637408/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCHv2 07/12] perf: drop PE, PR from /usr/src/debug paths
Signed-off-by: Martin Jansa
---
meta/recipes-kernel/perf/perf.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/perf.bb
index a90acd55ef..32882afdf4 100644
--- a/meta/recipes-kernel/perf/perf.bb
+++ b/meta/recipes-kernel/perf/perf.bb
@@ -98,7 +98,7 @@ EXTRA_OEMAKE = '\
AR="${AR}" \
LD="${LD}" \
EXTRA_CFLAGS="-ldw -I${S}" \
-YFLAGS='-y
--file-prefix-map=${WORKDIR}=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR}' \
+YFLAGS='-y --file-prefix-map=${WORKDIR}=${TARGET_DBGSRC_DIR}' \
EXTRA_LDFLAGS="${PERF_EXTRA_LDFLAGS}" \
perfexecdir=${libexecdir} \
NO_GTK2=1 \
@@ -405,7 +405,7 @@ PACKAGESPLITFUNCS =+ "perf_fix_sources"
perf_fix_sources () {
for f in util/parse-events-flex.h util/parse-events-flex.c
util/pmu-flex.c \
util/pmu-flex.h util/expr-flex.h util/expr-flex.c; do
- f=${PKGD}/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR}/$f
+ f=${PKGD}${TARGET_DBGSRC_DIR}/$f
if [ -e $f ]; then
sed -i -e 's#${S}/##g' $f
fi
--
2.42.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#190821):
https://lists.openembedded.org/g/openembedded-core/message/190821
Mute This Topic: https://lists.openembedded.org/mt/102637407/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCHv2 06/12] ffmpeg: drop PE, PR from /usr/src/debug paths
Signed-off-by: Martin Jansa
---
meta/recipes-multimedia/ffmpeg/ffmpeg_6.0.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-multimedia/ffmpeg/ffmpeg_6.0.bb
b/meta/recipes-multimedia/ffmpeg/ffmpeg_6.0.bb
index e65f80d64b..1c9edaf176 100644
--- a/meta/recipes-multimedia/ffmpeg/ffmpeg_6.0.bb
+++ b/meta/recipes-multimedia/ffmpeg/ffmpeg_6.0.bb
@@ -151,7 +151,7 @@ do_configure() {
export TMPDIR="${B}/tmp"
mkdir -p ${B}/tmp
${S}/configure ${EXTRA_OECONF}
-sed -i -e "s,^X86ASMFLAGS=.*,&
--debug-prefix-map=${S}=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR}
--debug-prefix-map=${B}=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR},g"
${B}/ffbuild/config.mak
+sed -i -e "s,^X86ASMFLAGS=.*,&
--debug-prefix-map=${S}=${TARGET_DBGSRC_DIR}
--debug-prefix-map=${B}=${TARGET_DBGSRC_DIR},g" ${B}/ffbuild/config.mak
}
# patch out build host paths for reproducibility
--
2.42.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#190820):
https://lists.openembedded.org/g/openembedded-core/message/190820
Mute This Topic: https://lists.openembedded.org/mt/102637406/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCHv2 05/12] libjpeg-turbo: drop PE, PR from /usr/src/debug paths
Signed-off-by: Martin Jansa
---
meta/recipes-graphics/jpeg/libjpeg-turbo_3.0.1.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-graphics/jpeg/libjpeg-turbo_3.0.1.bb
b/meta/recipes-graphics/jpeg/libjpeg-turbo_3.0.1.bb
index 99ed82dac4..132d4b375a 100644
--- a/meta/recipes-graphics/jpeg/libjpeg-turbo_3.0.1.bb
+++ b/meta/recipes-graphics/jpeg/libjpeg-turbo_3.0.1.bb
@@ -24,7 +24,7 @@ RCONFLICTS:${PN} += "jpeg"
inherit cmake pkgconfig
-export NASMENV = "--reproducible
--debug-prefix-map=${WORKDIR}=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR}"
+export NASMENV = "--reproducible
--debug-prefix-map=${WORKDIR}=${TARGET_DBGSRC_DIR}"
# Add nasm-native dependency consistently for all build arches is hard
EXTRA_OECMAKE:append:class-native = " -DWITH_SIMD=False"
--
2.42.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#190819):
https://lists.openembedded.org/g/openembedded-core/message/190819
Mute This Topic: https://lists.openembedded.org/mt/102637405/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCHv2 03/12] go-cross-canadian.inc: drop PE, PR from /usr/src/debug paths
Signed-off-by: Martin Jansa
---
meta/recipes-devtools/go/go-cross-canadian.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/go/go-cross-canadian.inc
b/meta/recipes-devtools/go/go-cross-canadian.inc
index 45758f3361..8298fe31be 100644
--- a/meta/recipes-devtools/go/go-cross-canadian.inc
+++ b/meta/recipes-devtools/go/go-cross-canadian.inc
@@ -8,7 +8,7 @@ PN = "go-cross-canadian-${TRANSLATED_TARGET_ARCH}"
# it uses gcc on build machine during go-cross-canadian bootstrap, but
# the gcc version may be old and not support option '-fmacro-prefix-map'
# which is one of default values of DEBUG_PREFIX_MAP
-DEBUG_PREFIX_MAP =
"-fdebug-prefix-map=${WORKDIR}=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR} \
+DEBUG_PREFIX_MAP = "-fdebug-prefix-map=${WORKDIR}=${TARGET_DBGSRC_DIR} \
-fdebug-prefix-map=${STAGING_DIR_HOST}= \
-fdebug-prefix-map=${STAGING_DIR_NATIVE}= \
"
--
2.42.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#190817):
https://lists.openembedded.org/g/openembedded-core/message/190817
Mute This Topic: https://lists.openembedded.org/mt/102637403/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCHv2 04/12] acpica: drop PE, PR from /usr/src/debug paths
Signed-off-by: Martin Jansa
---
meta/recipes-extended/acpica/acpica_20230628.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-extended/acpica/acpica_20230628.bb
b/meta/recipes-extended/acpica/acpica_20230628.bb
index b7921516a2..8974bdc1f1 100644
--- a/meta/recipes-extended/acpica/acpica_20230628.bb
+++ b/meta/recipes-extended/acpica/acpica_20230628.bb
@@ -36,7 +36,7 @@ EXTRA_OEMAKE = "CC='${CC}' \
INSTALLDIR=${bindir} \
INSTALLFLAGS= \
YACC=bison \
-YFLAGS='-y
--file-prefix-map=${WORKDIR}=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR}' \
+YFLAGS='-y --file-prefix-map=${WORKDIR}=${TARGET_DBGSRC_DIR}' \
"
do_install() {
--
2.42.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#190818):
https://lists.openembedded.org/g/openembedded-core/message/190818
Mute This Topic: https://lists.openembedded.org/mt/102637404/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCHv4 01/12] bitbake.conf: drop ${PE} and ${PR} from -f{file,macro,debug}-prefix-map
* ${EXTENDPE} and ${PR} was already dropped from ${WORKDIR} in:
https://lists.openembedded.org/g/openembedded-core/message/185818
adjust -fmacro-prefix-map and -fdebug-prefix-map similarly.
As we don't depend on PR in WORKDIR maybe we don't need it in
/usr/src/debug paths as well anymore.
* add TARGET_DBGSRC_DIR variable with "/usr/src/debug/${PN}/${PV}"
because there is quite a few places where this location is being
used in various recipes
* The interesting side-effect of this is that for DISTROs which still
use PR (e.g. webOS OSE), the difference in -fdebug-prefix-map causes
all binaries to be slightly different when rebuilt with different PR
(due to this path, even when otherwise they are binary reproducible)
and when the number of digits in PR changes (e.g. from r9 to r10) it
also results in slightly bigger binaries (and more unnecessary changes
in buildhistory diffs).
For example this foo binary, the difference between "new" and "old" is
extra patch applied in SRC_URI (which doesn't affect the foo binary,
but was the reason for PR bump).
And the binary is bigger with r10, identical with r6 and slightly
different due to debug-prefix-map between r6 and r7:
$ ls -la 1.0.0-175-*/image/usr/sbin/foo
-rwxr-xr-x 1 bitbake bitbake 30182460 Nov 8 08:29
1.0.0-175-new-r10/image/usr/sbin/foo
-rwxr-xr-x 1 bitbake bitbake 30182224 Nov 8 08:02
1.0.0-175-new-r6/image/usr/sbin/foo
-rwxr-xr-x 1 bitbake bitbake 30182224 Nov 8 07:49
1.0.0-175-new-r7/image/usr/sbin/foo
-rwxr-xr-x 1 bitbake bitbake 30182224 Nov 8 07:39
1.0.0-175-old-r6/image/usr/sbin/foo
$ md5sum 1.0.0-175-*/image/usr/sbin/foo
8e3ab67d596f8cc2f9c6320dab10af01 1.0.0-175-new-r10/image/usr/sbin/foo
f6ff1e64fe6affb9ba0d8f278cf7ed79 1.0.0-175-new-r6/image/usr/sbin/foo
6469a0b10aac233911e63c5ea97b03c0 1.0.0-175-new-r7/image/usr/sbin/foo
f6ff1e64fe6affb9ba0d8f278cf7ed79 1.0.0-175-old-r6/image/usr/sbin/foo
Signed-off-by: Martin Jansa
---
v4: add TARGET_DBGSRC_DIR variable
meta/conf/bitbake.conf | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 67ff769046..59f142f6bc 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -646,12 +646,13 @@ EXTRA_OEMAKE:prepend:task-install = "${PARALLEL_MAKEINST}
"
##
# Optimization flags.
##
+TARGET_DBGSRC_DIR ?= "/usr/src/debug/${PN}/${PV}"
# Beware: applied last to first
DEBUG_PREFIX_MAP ?= "-fcanon-prefix-map \
- -fmacro-prefix-map=${S}=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR} \
- -fdebug-prefix-map=${S}=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR} \
- -fmacro-prefix-map=${B}=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR} \
- -fdebug-prefix-map=${B}=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR} \
+ -fmacro-prefix-map=${S}=${TARGET_DBGSRC_DIR} \
+ -fdebug-prefix-map=${S}=${TARGET_DBGSRC_DIR} \
+ -fmacro-prefix-map=${B}=${TARGET_DBGSRC_DIR} \
+ -fdebug-prefix-map=${B}=${TARGET_DBGSRC_DIR} \
-fdebug-prefix-map=${STAGING_DIR_HOST}= \
-fmacro-prefix-map=${STAGING_DIR_HOST}= \
-fdebug-prefix-map=${STAGING_DIR_NATIVE}= \
--
2.42.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#190815):
https://lists.openembedded.org/g/openembedded-core/message/190815
Mute This Topic: https://lists.openembedded.org/mt/102637400/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCHv2 02/12] ovmf: drop PE, PR from /usr/src/debug paths
Signed-off-by: Martin Jansa
---
meta/recipes-core/ovmf/ovmf_git.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-core/ovmf/ovmf_git.bb
b/meta/recipes-core/ovmf/ovmf_git.bb
index 6bbe21ac5c..3dc031d3b6 100644
--- a/meta/recipes-core/ovmf/ovmf_git.bb
+++ b/meta/recipes-core/ovmf/ovmf_git.bb
@@ -122,7 +122,7 @@ fix_toolchain:append:class-native() {
# --debug-prefix-map to nasm (we carry a patch to nasm for this). The
# tools definitions are built by ovmf-native so we need to pass this in
# at target build time when we know the right values.
-export NASM_PREFIX_MAP =
"--debug-prefix-map=${WORKDIR}=/usr/src/debug/ovmf/${EXTENDPE}${PV}-${PR}"
+export NASM_PREFIX_MAP = "--debug-prefix-map=${WORKDIR}=${TARGET_DBGSRC_DIR}"
export GCC_PREFIX_MAP = "${DEBUG_PREFIX_MAP} -Wno-stringop-overflow
-Wno-maybe-uninitialized"
GCC_VER="$(${CC} -v 2>&1 | tail -n1 | awk '{print $3}')"
--
2.42.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#190816):
https://lists.openembedded.org/g/openembedded-core/message/190816
Mute This Topic: https://lists.openembedded.org/mt/102637401/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] [PATCHv3 01/11] bitbake.conf: drop ${PE} and ${PR} from -f{file,macro,debug}-prefix-map
On Thu, Nov 16, 2023 at 8:44 PM Khem Raj wrote:
> On Wed, Nov 15, 2023 at 11:36 PM Martin Jansa
> wrote:
> >
> > * ${EXTENDPE} and ${PR} was already dropped from ${WORKDIR} in:
> > https://lists.openembedded.org/g/openembedded-core/message/185818
> > adjust -fmacro-prefix-map and -fdebug-prefix-map similarly.
> > As we don't depend on PR in WORKDIR maybe we don't need it in
> > /usr/src/debug paths as well anymore.
> >
> > * The interesting side-effect of this is that for DISTROs which still
> > use PR (e.g. webOS OSE), the difference in -fdebug-prefix-map causes
> > all binaries to be slightly different when rebuilt with different PR
> > (due to this path, even when otherwise they are binary reproducible)
> > and when the number of digits in PR changes (e.g. from r9 to r10) it
> > also results in slightly bigger binaries (and more unnecessary changes
> > in buildhistory diffs).
> >
>
> these paths are for binary outputs unlike workdir, this change would means
> we
> have same path to install debug info on targets which might not match
> to installed
> binaries Can you check if these paths are matching while debugging on
> target ?
>
I did run the selftest with this included and it doesn't show any new
issues.
In a image built with IMAGE_FEATURES:append = " dev-pkgs dbg-pkgs src-pkgs"
and checked that there are no dirs with ${PR} anymore:
ls usr/src/debug/*/*-r*
and the paths in rootfs-dbg from IMAGE_GEN_DEBUGFS uses the same paths.
I also have 8 commits for meta-oe recipes to adjust for this.
Cheers,
> > For example this foo binary, the difference between "new" and "old" is
> > extra patch applied in SRC_URI (which doesn't affect the foo binary,
> > but was the reason for PR bump).
> >
> > And the binary is bigger with r10, identical with r6 and slightly
> > different due to debug-prefix-map between r6 and r7:
> >
> > $ ls -la 1.0.0-175-*/image/usr/sbin/foo
> > -rwxr-xr-x 1 bitbake bitbake 30182460 Nov 8 08:29
> 1.0.0-175-new-r10/image/usr/sbin/foo
> > -rwxr-xr-x 1 bitbake bitbake 30182224 Nov 8 08:02
> 1.0.0-175-new-r6/image/usr/sbin/foo
> > -rwxr-xr-x 1 bitbake bitbake 30182224 Nov 8 07:49
> 1.0.0-175-new-r7/image/usr/sbin/foo
> > -rwxr-xr-x 1 bitbake bitbake 30182224 Nov 8 07:39
> 1.0.0-175-old-r6/image/usr/sbin/foo
> >
> > $ md5sum 1.0.0-175-*/image/usr/sbin/foo
> > 8e3ab67d596f8cc2f9c6320dab10af01 1.0.0-175-new-r10/image/usr/sbin/foo
> > f6ff1e64fe6affb9ba0d8f278cf7ed79 1.0.0-175-new-r6/image/usr/sbin/foo
> > 6469a0b10aac233911e63c5ea97b03c0 1.0.0-175-new-r7/image/usr/sbin/foo
> > f6ff1e64fe6affb9ba0d8f278cf7ed79 1.0.0-175-old-r6/image/usr/sbin/foo
> >
> > Signed-off-by: Martin Jansa
> > ---
> > v3: added additional fix for perf (and changes in other recipes were
> moved to separate commits)
> >
> > meta/conf/bitbake.conf | 8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> > index 67ff769046..3836a389b8 100644
> > --- a/meta/conf/bitbake.conf
> > +++ b/meta/conf/bitbake.conf
> > @@ -648,10 +648,10 @@ EXTRA_OEMAKE:prepend:task-install =
> "${PARALLEL_MAKEINST} "
> > ##
> > # Beware: applied last to first
> > DEBUG_PREFIX_MAP ?= "-fcanon-prefix-map \
> > - -fmacro-prefix-map=${S}=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR} \
> > - -fdebug-prefix-map=${S}=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR} \
> > - -fmacro-prefix-map=${B}=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR} \
> > - -fdebug-prefix-map=${B}=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR} \
> > + -fmacro-prefix-map=${S}=/usr/src/debug/${PN}/${PV} \
> > + -fdebug-prefix-map=${S}=/usr/src/debug/${PN}/${PV} \
> > + -fmacro-prefix-map=${B}=/usr/src/debug/${PN}/${PV} \
> > + -fdebug-prefix-map=${B}=/usr/src/debug/${PN}/${PV} \
> > -fdebug-prefix-map=${STAGING_DIR_HOST}= \
> > -fmacro-prefix-map=${STAGING_DIR_HOST}= \
> > -fdebug-prefix-map=${STAGING_DIR_NATIVE}= \
> > --
> > 2.42.1
> >
> >
> >
> >
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#190814):
https://lists.openembedded.org/g/openembedded-core/message/190814
Mute This Topic: https://lists.openembedded.org/mt/102623139/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] [PATCHv3 01/11] bitbake.conf: drop ${PE} and ${PR} from -f{file,macro,debug}-prefix-map
RP asked on #yocto to add TARGET_DBGSRC_DIR variable for
/usr/src/debug/${PN}/${PV} so that all recipes fixed in follow up changes
(and 10+ more for meta-oe layers) can use this instead of hardcoding the
/usr/src/debug/${PN}/${PV} value.
Will send v4 later today.
On Thu, Nov 16, 2023 at 8:36 AM Martin Jansa via lists.openembedded.org
wrote:
> * ${EXTENDPE} and ${PR} was already dropped from ${WORKDIR} in:
> https://lists.openembedded.org/g/openembedded-core/message/185818
> adjust -fmacro-prefix-map and -fdebug-prefix-map similarly.
> As we don't depend on PR in WORKDIR maybe we don't need it in
> /usr/src/debug paths as well anymore.
>
> * The interesting side-effect of this is that for DISTROs which still
> use PR (e.g. webOS OSE), the difference in -fdebug-prefix-map causes
> all binaries to be slightly different when rebuilt with different PR
> (due to this path, even when otherwise they are binary reproducible)
> and when the number of digits in PR changes (e.g. from r9 to r10) it
> also results in slightly bigger binaries (and more unnecessary changes
> in buildhistory diffs).
>
> For example this foo binary, the difference between "new" and "old" is
> extra patch applied in SRC_URI (which doesn't affect the foo binary,
> but was the reason for PR bump).
>
> And the binary is bigger with r10, identical with r6 and slightly
> different due to debug-prefix-map between r6 and r7:
>
> $ ls -la 1.0.0-175-*/image/usr/sbin/foo
> -rwxr-xr-x 1 bitbake bitbake 30182460 Nov 8 08:29
> 1.0.0-175-new-r10/image/usr/sbin/foo
> -rwxr-xr-x 1 bitbake bitbake 30182224 Nov 8 08:02
> 1.0.0-175-new-r6/image/usr/sbin/foo
> -rwxr-xr-x 1 bitbake bitbake 30182224 Nov 8 07:49
> 1.0.0-175-new-r7/image/usr/sbin/foo
> -rwxr-xr-x 1 bitbake bitbake 30182224 Nov 8 07:39
> 1.0.0-175-old-r6/image/usr/sbin/foo
>
> $ md5sum 1.0.0-175-*/image/usr/sbin/foo
> 8e3ab67d596f8cc2f9c6320dab10af01 1.0.0-175-new-r10/image/usr/sbin/foo
> f6ff1e64fe6affb9ba0d8f278cf7ed79 1.0.0-175-new-r6/image/usr/sbin/foo
> 6469a0b10aac233911e63c5ea97b03c0 1.0.0-175-new-r7/image/usr/sbin/foo
> f6ff1e64fe6affb9ba0d8f278cf7ed79 1.0.0-175-old-r6/image/usr/sbin/foo
>
> Signed-off-by: Martin Jansa
> ---
> v3: added additional fix for perf (and changes in other recipes were moved
> to separate commits)
>
> meta/conf/bitbake.conf | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> index 67ff769046..3836a389b8 100644
> --- a/meta/conf/bitbake.conf
> +++ b/meta/conf/bitbake.conf
> @@ -648,10 +648,10 @@ EXTRA_OEMAKE:prepend:task-install =
> "${PARALLEL_MAKEINST} "
> ##
> # Beware: applied last to first
> DEBUG_PREFIX_MAP ?= "-fcanon-prefix-map \
> - -fmacro-prefix-map=${S}=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR} \
> - -fdebug-prefix-map=${S}=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR} \
> - -fmacro-prefix-map=${B}=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR} \
> - -fdebug-prefix-map=${B}=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR} \
> + -fmacro-prefix-map=${S}=/usr/src/debug/${PN}/${PV} \
> + -fdebug-prefix-map=${S}=/usr/src/debug/${PN}/${PV} \
> + -fmacro-prefix-map=${B}=/usr/src/debug/${PN}/${PV} \
> + -fdebug-prefix-map=${B}=/usr/src/debug/${PN}/${PV} \
> -fdebug-prefix-map=${STAGING_DIR_HOST}= \
> -fmacro-prefix-map=${STAGING_DIR_HOST}= \
> -fdebug-prefix-map=${STAGING_DIR_NATIVE}= \
> --
> 2.42.1
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#190769):
https://lists.openembedded.org/g/openembedded-core/message/190769
Mute This Topic: https://lists.openembedded.org/mt/102623139/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 11/11] python3-cython: drop PE, PR from /usr/src/debug paths
Signed-off-by: Martin Jansa
---
.../python/python3-cython_0.29.36.bb | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/meta/recipes-devtools/python/python3-cython_0.29.36.bb
b/meta/recipes-devtools/python/python3-cython_0.29.36.bb
index 78be2b94ed..8f971b2179 100644
--- a/meta/recipes-devtools/python/python3-cython_0.29.36.bb
+++ b/meta/recipes-devtools/python/python3-cython_0.29.36.bb
@@ -20,17 +20,17 @@ do_install:append() {
PACKAGESPLITFUNCS =+ "cython_fix_sources"
cython_fix_sources () {
- for f in
${PKGD}/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR}/Cython/Compiler/FlowControl.c
\
-
${PKGD}/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR}/Cython/Compiler/FusedNode.c \
-
${PKGD}/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR}/Cython/Compiler/Scanning.c \
-
${PKGD}/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR}/Cython/Compiler/Visitor.c \
-
${PKGD}/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR}/Cython/Plex/Actions.c \
-
${PKGD}/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR}/Cython/Plex/Scanners.c \
-
${PKGD}/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR}/Cython/Runtime/refnanny.c \
-
${PKGD}/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR}/Cython/Tempita/_tempita.c \
+ for f in
${PKGD}/usr/src/debug/${PN}/${PV}/Cython/Compiler/FlowControl.c \
+ ${PKGD}/usr/src/debug/${PN}/${PV}/Cython/Compiler/FusedNode.c \
+ ${PKGD}/usr/src/debug/${PN}/${PV}/Cython/Compiler/Scanning.c \
+ ${PKGD}/usr/src/debug/${PN}/${PV}/Cython/Compiler/Visitor.c \
+ ${PKGD}/usr/src/debug/${PN}/${PV}/Cython/Plex/Actions.c \
+ ${PKGD}/usr/src/debug/${PN}/${PV}/Cython/Plex/Scanners.c \
+ ${PKGD}/usr/src/debug/${PN}/${PV}/Cython/Runtime/refnanny.c \
+ ${PKGD}/usr/src/debug/${PN}/${PV}/Cython/Tempita/_tempita.c \
${PKGD}${libdir}/${PYTHON_DIR}/site-packages/Cython*/SOURCES.txt; do
if [ -e $f ]; then
- sed -i -e
's#${WORKDIR}/Cython-${PV}#/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR}#g' $f
+ sed -i -e
's#${WORKDIR}/Cython-${PV}#/usr/src/debug/${PN}/${PV}#g' $f
fi
done
}
--
2.42.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#190763):
https://lists.openembedded.org/g/openembedded-core/message/190763
Mute This Topic: https://lists.openembedded.org/mt/102623150/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 10/11] valgrind: drop PE, PR from /usr/src/debug paths
Signed-off-by: Martin Jansa
---
meta/recipes-devtools/valgrind/valgrind_3.21.0.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-devtools/valgrind/valgrind_3.21.0.bb
b/meta/recipes-devtools/valgrind/valgrind_3.21.0.bb
index 68ab319a1b..d098ae08fc 100644
--- a/meta/recipes-devtools/valgrind/valgrind_3.21.0.bb
+++ b/meta/recipes-devtools/valgrind/valgrind_3.21.0.bb
@@ -239,8 +239,8 @@ do_install_ptest() {
# As the binary isn't stripped or debug-splitted, the source file isn't
fetched
# via dwarfsrcfiles either, so it needs to be installed manually.
-mkdir -p ${D}/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR}/none/tests/
-install ${S}/none/tests/tls.c
${D}/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR}/none/tests/
+mkdir -p ${D}/usr/src/debug/${PN}/${PV}/none/tests/
+install ${S}/none/tests/tls.c ${D}/usr/src/debug/${PN}/${PV}/none/tests/
}
do_install_ptest:append:x86-64 () {
--
2.42.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#190762):
https://lists.openembedded.org/g/openembedded-core/message/190762
Mute This Topic: https://lists.openembedded.org/mt/102623148/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 09/11] vulkan-samples: drop PE, PR from /usr/src/debug paths
Signed-off-by: Martin Jansa
---
.../0001-vulkan-samples-Fix-reproducibility-issue.patch | 2 +-
meta/recipes-graphics/vulkan/vulkan-samples_git.bb | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git
a/meta/recipes-graphics/vulkan/vulkan-samples/0001-vulkan-samples-Fix-reproducibility-issue.patch
b/meta/recipes-graphics/vulkan/vulkan-samples/0001-vulkan-samples-Fix-reproducibility-issue.patch
index 7609011421..fbe5cf0c8e 100644
---
a/meta/recipes-graphics/vulkan/vulkan-samples/0001-vulkan-samples-Fix-reproducibility-issue.patch
+++
b/meta/recipes-graphics/vulkan/vulkan-samples/0001-vulkan-samples-Fix-reproducibility-issue.patch
@@ -9,7 +9,7 @@ in the debug source remapping from CFLAGS
We export the right path to use in the recipe with:
-EXTRA_OECMAKE =
"-DCMAKE_DEBUG_SRCDIR=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR}/"
+EXTRA_OECMAKE = "-DCMAKE_DEBUG_SRCDIR=/usr/src/debug/${PN}/${PV}/"
and we then patch this into the code instead of the broken use
of CMAKE_SOURCE_DIR since __FILENAME__ will match our path prefix
diff --git a/meta/recipes-graphics/vulkan/vulkan-samples_git.bb
b/meta/recipes-graphics/vulkan/vulkan-samples_git.bb
index 66f1ef5e9d..973ceeb573 100644
--- a/meta/recipes-graphics/vulkan/vulkan-samples_git.bb
+++ b/meta/recipes-graphics/vulkan/vulkan-samples_git.bb
@@ -29,7 +29,7 @@ FILES:${PN} += "${datadir}"
# used for logging with LOGE in the code. We need to make this match the value
we use
# in the debug source remapping from CFLAGS
#
-EXTRA_OECMAKE +=
"-DCMAKE_DEBUG_SRCDIR=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR}/"
+EXTRA_OECMAKE += "-DCMAKE_DEBUG_SRCDIR=/usr/src/debug/${PN}/${PV}/"
# Binaries built with PCH enabled don't appear reproducible, differing results
were seen
# from some builds depending on the point the PCH was compiled. Disable it to
be
# deterministic
--
2.42.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#190761):
https://lists.openembedded.org/g/openembedded-core/message/190761
Mute This Topic: https://lists.openembedded.org/mt/102623147/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 07/11] perf: drop PE, PR from /usr/src/debug paths
Signed-off-by: Martin Jansa
---
meta/recipes-kernel/perf/perf.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/perf.bb
index a90acd55ef..85ae338a67 100644
--- a/meta/recipes-kernel/perf/perf.bb
+++ b/meta/recipes-kernel/perf/perf.bb
@@ -98,7 +98,7 @@ EXTRA_OEMAKE = '\
AR="${AR}" \
LD="${LD}" \
EXTRA_CFLAGS="-ldw -I${S}" \
-YFLAGS='-y
--file-prefix-map=${WORKDIR}=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR}' \
+YFLAGS='-y --file-prefix-map=${WORKDIR}=/usr/src/debug/${PN}/${PV}' \
EXTRA_LDFLAGS="${PERF_EXTRA_LDFLAGS}" \
perfexecdir=${libexecdir} \
NO_GTK2=1 \
@@ -405,7 +405,7 @@ PACKAGESPLITFUNCS =+ "perf_fix_sources"
perf_fix_sources () {
for f in util/parse-events-flex.h util/parse-events-flex.c
util/pmu-flex.c \
util/pmu-flex.h util/expr-flex.h util/expr-flex.c; do
- f=${PKGD}/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR}/$f
+ f=${PKGD}/usr/src/debug/${PN}/${PV}/$f
if [ -e $f ]; then
sed -i -e 's#${S}/##g' $f
fi
--
2.42.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#190759):
https://lists.openembedded.org/g/openembedded-core/message/190759
Mute This Topic: https://lists.openembedded.org/mt/102623145/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 08/11] rust: drop PE, PR from /usr/src/debug paths
Signed-off-by: Martin Jansa
---
meta/classes-recipe/rust-common.bbclass| 2 +-
meta/recipes-devtools/rust/cargo_1.70.0.bb | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/classes-recipe/rust-common.bbclass
b/meta/classes-recipe/rust-common.bbclass
index 878272721c..cadbc7abb0 100644
--- a/meta/classes-recipe/rust-common.bbclass
+++ b/meta/classes-recipe/rust-common.bbclass
@@ -14,7 +14,7 @@ FILES:${PN}-dev += "${rustlibdir}/*.rlib
${rustlibdir}/*.rmeta"
FILES:${PN}-dbg += "${rustlibdir}/.debug"
RUSTLIB = "-L ${STAGING_DIR_HOST}${rustlibdir}"
-RUST_DEBUG_REMAP =
"--remap-path-prefix=${WORKDIR}=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR}"
+RUST_DEBUG_REMAP = "--remap-path-prefix=${WORKDIR}=/usr/src/debug/${PN}/${PV}"
RUSTFLAGS += "${RUSTLIB} ${RUST_DEBUG_REMAP}"
RUSTLIB_DEP ?= "libstd-rs"
RUST_PANIC_STRATEGY ?= "unwind"
diff --git a/meta/recipes-devtools/rust/cargo_1.70.0.bb
b/meta/recipes-devtools/rust/cargo_1.70.0.bb
index a5c1064106..9a23ba9d5f 100644
--- a/meta/recipes-devtools/rust/cargo_1.70.0.bb
+++ b/meta/recipes-devtools/rust/cargo_1.70.0.bb
@@ -19,7 +19,7 @@ CARGO_VENDORING_DIRECTORY = "${RUSTSRC}/vendor"
inherit cargo pkgconfig
-DEBUG_PREFIX_MAP +=
"-fdebug-prefix-map=${RUSTSRC}/vendor=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR}"
+DEBUG_PREFIX_MAP +=
"-fdebug-prefix-map=${RUSTSRC}/vendor=/usr/src/debug/${PN}/${PV}"
do_cargo_setup_snapshot () {
${WORKDIR}/rust-snapshot-components/${CARGO_SNAPSHOT}/install.sh
--prefix="${WORKDIR}/${CARGO_SNAPSHOT}" --disable-ldconfig
--
2.42.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#190760):
https://lists.openembedded.org/g/openembedded-core/message/190760
Mute This Topic: https://lists.openembedded.org/mt/102623146/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 06/11] ffmpeg: drop PE, PR from /usr/src/debug paths
Signed-off-by: Martin Jansa
---
meta/recipes-multimedia/ffmpeg/ffmpeg_6.0.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-multimedia/ffmpeg/ffmpeg_6.0.bb
b/meta/recipes-multimedia/ffmpeg/ffmpeg_6.0.bb
index e65f80d64b..0ad2f80217 100644
--- a/meta/recipes-multimedia/ffmpeg/ffmpeg_6.0.bb
+++ b/meta/recipes-multimedia/ffmpeg/ffmpeg_6.0.bb
@@ -151,7 +151,7 @@ do_configure() {
export TMPDIR="${B}/tmp"
mkdir -p ${B}/tmp
${S}/configure ${EXTRA_OECONF}
-sed -i -e "s,^X86ASMFLAGS=.*,&
--debug-prefix-map=${S}=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR}
--debug-prefix-map=${B}=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR},g"
${B}/ffbuild/config.mak
+sed -i -e "s,^X86ASMFLAGS=.*,&
--debug-prefix-map=${S}=/usr/src/debug/${PN}/${PV}
--debug-prefix-map=${B}=/usr/src/debug/${PN}/${PV},g" ${B}/ffbuild/config.mak
}
# patch out build host paths for reproducibility
--
2.42.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#190758):
https://lists.openembedded.org/g/openembedded-core/message/190758
Mute This Topic: https://lists.openembedded.org/mt/102623144/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 05/11] libjpeg-turbo: drop PE, PR from /usr/src/debug paths
Signed-off-by: Martin Jansa
---
meta/recipes-graphics/jpeg/libjpeg-turbo_3.0.1.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-graphics/jpeg/libjpeg-turbo_3.0.1.bb
b/meta/recipes-graphics/jpeg/libjpeg-turbo_3.0.1.bb
index 99ed82dac4..ca1910966e 100644
--- a/meta/recipes-graphics/jpeg/libjpeg-turbo_3.0.1.bb
+++ b/meta/recipes-graphics/jpeg/libjpeg-turbo_3.0.1.bb
@@ -24,7 +24,7 @@ RCONFLICTS:${PN} += "jpeg"
inherit cmake pkgconfig
-export NASMENV = "--reproducible
--debug-prefix-map=${WORKDIR}=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR}"
+export NASMENV = "--reproducible
--debug-prefix-map=${WORKDIR}=/usr/src/debug/${PN}/${PV}"
# Add nasm-native dependency consistently for all build arches is hard
EXTRA_OECMAKE:append:class-native = " -DWITH_SIMD=False"
--
2.42.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#190757):
https://lists.openembedded.org/g/openembedded-core/message/190757
Mute This Topic: https://lists.openembedded.org/mt/102623143/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 03/11] go-cross-canadian.inc: drop PE, PR from /usr/src/debug paths
Signed-off-by: Martin Jansa
---
meta/recipes-devtools/go/go-cross-canadian.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/go/go-cross-canadian.inc
b/meta/recipes-devtools/go/go-cross-canadian.inc
index 45758f3361..0a72e89bbd 100644
--- a/meta/recipes-devtools/go/go-cross-canadian.inc
+++ b/meta/recipes-devtools/go/go-cross-canadian.inc
@@ -8,7 +8,7 @@ PN = "go-cross-canadian-${TRANSLATED_TARGET_ARCH}"
# it uses gcc on build machine during go-cross-canadian bootstrap, but
# the gcc version may be old and not support option '-fmacro-prefix-map'
# which is one of default values of DEBUG_PREFIX_MAP
-DEBUG_PREFIX_MAP =
"-fdebug-prefix-map=${WORKDIR}=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR} \
+DEBUG_PREFIX_MAP = "-fdebug-prefix-map=${WORKDIR}=/usr/src/debug/${PN}/${PV} \
-fdebug-prefix-map=${STAGING_DIR_HOST}= \
-fdebug-prefix-map=${STAGING_DIR_NATIVE}= \
"
--
2.42.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#190755):
https://lists.openembedded.org/g/openembedded-core/message/190755
Mute This Topic: https://lists.openembedded.org/mt/102623141/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 04/11] acpica: drop PE, PR from /usr/src/debug paths
Signed-off-by: Martin Jansa
---
meta/recipes-extended/acpica/acpica_20230628.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-extended/acpica/acpica_20230628.bb
b/meta/recipes-extended/acpica/acpica_20230628.bb
index b7921516a2..8ca1f0892f 100644
--- a/meta/recipes-extended/acpica/acpica_20230628.bb
+++ b/meta/recipes-extended/acpica/acpica_20230628.bb
@@ -36,7 +36,7 @@ EXTRA_OEMAKE = "CC='${CC}' \
INSTALLDIR=${bindir} \
INSTALLFLAGS= \
YACC=bison \
-YFLAGS='-y
--file-prefix-map=${WORKDIR}=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR}' \
+YFLAGS='-y
--file-prefix-map=${WORKDIR}=/usr/src/debug/${PN}/${PV}' \
"
do_install() {
--
2.42.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#190756):
https://lists.openembedded.org/g/openembedded-core/message/190756
Mute This Topic: https://lists.openembedded.org/mt/102623142/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 02/11] ovmf: drop PE, PR from /usr/src/debug paths
Signed-off-by: Martin Jansa
---
meta/recipes-core/ovmf/ovmf_git.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-core/ovmf/ovmf_git.bb
b/meta/recipes-core/ovmf/ovmf_git.bb
index 6bbe21ac5c..bf67a2a4a8 100644
--- a/meta/recipes-core/ovmf/ovmf_git.bb
+++ b/meta/recipes-core/ovmf/ovmf_git.bb
@@ -122,7 +122,7 @@ fix_toolchain:append:class-native() {
# --debug-prefix-map to nasm (we carry a patch to nasm for this). The
# tools definitions are built by ovmf-native so we need to pass this in
# at target build time when we know the right values.
-export NASM_PREFIX_MAP =
"--debug-prefix-map=${WORKDIR}=/usr/src/debug/ovmf/${EXTENDPE}${PV}-${PR}"
+export NASM_PREFIX_MAP =
"--debug-prefix-map=${WORKDIR}=/usr/src/debug/ovmf/${PV}"
export GCC_PREFIX_MAP = "${DEBUG_PREFIX_MAP} -Wno-stringop-overflow
-Wno-maybe-uninitialized"
GCC_VER="$(${CC} -v 2>&1 | tail -n1 | awk '{print $3}')"
--
2.42.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#190754):
https://lists.openembedded.org/g/openembedded-core/message/190754
Mute This Topic: https://lists.openembedded.org/mt/102623140/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
