Re: [OE-core][kirkstone][PATCH] libpcap: upgrade 1.10.1 -> 1.10.5
This update seems to break nmap build from meta-oe:
nse_nsock.cc:36:3: error: expected identifier before 'int'
36 | PCAP_SOCKET = lua_upvalueindex(3), /* pcap socket metatable */
| ^~~
nse_nsock.cc:36:3: error: expected '}' before 'int'
nse_nsock.cc:33:6: note: to match this '{'
33 | enum {
| ^
nse_nsock.cc:36:15: error: expected unqualified-id before '=' token
36 | PCAP_SOCKET = lua_upvalueindex(3), /* pcap socket metatable */
| ^
nse_nsock.cc:40:1: error: expected declaration before '}' token
40 | };
| ^
nse_nsock.cc: In function 'int socket_lock(lua_State*, int)':
nse_nsock.cc:181:17: error: 'THREAD_SOCKETS' was not declared in this
scope; did you mean 'MAX_SOCKETS'?
181 | lua_rawget(L, THREAD_SOCKETS);
| ^~
| MAX_SOCKETS
nse_nsock.cc:203:19: error: 'CONNECT_WAITING' was not declared in this scope
203 | lua_rawset(L, CONNECT_WAITING);
| ^~~
I don't think this upgrade from
470 Wednesday, June 9, 2021:
471 Summary for 1.10.1 libpcap release:
to
70 Friday, August 30, 2024 / The Tcpdump Group
71 Summary for 1.10.5 libpcap release
is suitable for stable branch, please cherry-pick just the security fixes.
On Thu, Sep 12, 2024 at 3:17 PM Vijay Anusuri via
lists.openembedded.org
wrote:
>
> From: Vijay Anusuri
>
> Changelog:
> https://git.tcpdump.org/libpcap/blob/HEAD:/CHANGES
>
> Includes Security fixes
> CVE-2023-7256, CVE-2024-8006
>
> Signed-off-by: Vijay Anusuri
> ---
> .../libpcap/{libpcap_1.10.1.bb => libpcap_1.10.5.bb} | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> rename meta/recipes-connectivity/libpcap/{libpcap_1.10.1.bb =>
> libpcap_1.10.5.bb} (92%)
>
> diff --git a/meta/recipes-connectivity/libpcap/libpcap_1.10.1.bb
> b/meta/recipes-connectivity/libpcap/libpcap_1.10.5.bb
> similarity index 92%
> rename from meta/recipes-connectivity/libpcap/libpcap_1.10.1.bb
> rename to meta/recipes-connectivity/libpcap/libpcap_1.10.5.bb
> index dbe2fd8157..94b6466722 100644
> --- a/meta/recipes-connectivity/libpcap/libpcap_1.10.1.bb
> +++ b/meta/recipes-connectivity/libpcap/libpcap_1.10.5.bb
> @@ -10,8 +10,8 @@ LIC_FILES_CHKSUM =
> "file://LICENSE;md5=5eb289217c160e2920d2e35bddc36453 \
>
> file://pcap.h;beginline=1;endline=32;md5=39af3510e011f34b8872f120b1dc31d2"
> DEPENDS = "flex-native bison-native"
>
> -SRC_URI = "https://www.tcpdump.org/release/${BP}.tar.gz";
> -SRC_URI[sha256sum] =
> "ed285f4accaf05344f90975757b3dbfe772ba41d1c401c2648b7fa45b711bdd4"
> +SRC_URI = "https://www.tcpdump.org/release/${BP}.tar.xz";
> +SRC_URI[sha256sum] =
> "84fa89ac6d303028c1c5b754abff77224f45eca0a94eb1a34ff0aa9ceece3925"
>
> inherit autotools binconfig-disabled pkgconfig
>
> --
> 2.25.1
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#204489):
https://lists.openembedded.org/g/openembedded-core/message/204489
Mute This Topic: https://lists.openembedded.org/mt/108412577/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] sanity: check for working user namespaces
On Thu, Sep 12, 2024 at 7:28 PM Ross Burton wrote:
>
> By which do you mean the build failed gracefully, whereas previously it would
> have exploded?
Without existing TMPDIR it failed with just the error from sanity
check (as expected).
With existing TMPDIR (where sanity check was already executed before
your change) or without your change applied it fails with many
PermissionError exceptions.
I forgot to mention that I did another zlib-native build after
echo 0 > /proc/sys/kernel/apparmor_restrict_unprivileged_userns
and that didn't fail sanity check nor in build (as expected).
> > On 12 Sep 2024, at 18:22, Martin Jansa wrote:
> >
> > Works as expected, the build failed :).
> >
> > openembedded-core/build$ bitbake -k zlib-native
> > ERROR: User namespaces are not usable by BitBake, possibly due to AppArmor.
> > See
> > https://discourse.ubuntu.com/t/ubuntu-24-04-lts-noble-numbat-release-notes/39890#unprivileged-user-namespace-restrictions
> > for more information.
> >
> > The only issue might be that these checks are executed only once, so
> > if you have existing TMPDIR (where it was failing) then it will
> > continue failing with:
> >
> > ERROR: PermissionError: [Errno 1] Operation not permitted
> >
> > During handling of the above exception, another exception occurred:
> >
> > Traceback (most recent call last):
> > File "/home/martin/work/bitbake/bin/bitbake-worker", line 278, in child
> >bb.utils.disable_network(uid, gid)
> > File "/home/martin/work/bitbake/lib/bb/utils.py", line 1696, in
> > disable_network
> >with open("/proc/self/uid_map", "w") as f:
> > PermissionError: [Errno 1] Operation not permitted
> >
> > until TMPDIR is removed and sanity re-executed.
> >
> > On Thu, Sep 12, 2024 at 6:59 PM Ross Burton via lists.openembedded.org
> > wrote:
> >>
> >> Note that in its final form this isn’t had any testing on an Ubuntu
> >> machine, so testing would be appreciated if anyone has an Ubuntu 24.x
> >> machine (not a container, need their kernel) with apparmor enabled.
> >>
> >> Thanks,
> >> Ross
> >>
> >>> On 12 Sep 2024, at 17:57, Ross Burton via lists.openembedded.org
> >>> wrote:
> >>>
> >>> If user namespaces are not available (typically because AppArmor is
> >>> blocking them), alert the user.
> >>>
> >>> We consider network isolation sufficiently important that this is a fatal
> >>> error, and the user will need to configure AppArmor to allow bitbake to
> >>> create a user namespace.
> >>>
> >>> [ YOCTO #15592 ]
> >>>
> >>> Signed-off-by: Ross Burton
> >>> ---
> >>> meta/classes-global/sanity.bbclass | 24
> >>> 1 file changed, 24 insertions(+)
> >>>
> >>> diff --git a/meta/classes-global/sanity.bbclass
> >>> b/meta/classes-global/sanity.bbclass
> >>> index 1d242f0f0a0..72dab0fea2b 100644
> >>> --- a/meta/classes-global/sanity.bbclass
> >>> +++ b/meta/classes-global/sanity.bbclass
> >>> @@ -475,6 +475,29 @@ def check_wsl(d):
> >>>bb.warn("You are running bitbake under WSLv2, this works
> >>> properly but you should optimize your VHDX file eventually to avoid
> >>> running out of storage space")
> >>>return None
> >>>
> >>> +def check_userns():
> >>> +"""
> >>> +Check that user namespaces are functional, as they're used for
> >>> network isolation.
> >>> +"""
> >>> +
> >>> +# There is a known failure case with AppAmrmor where the unshare()
> >>> call
> >>> +# succeeds (at which point the uid is nobody) but writing to the
> >>> uid_map
> >>> +# fails (so the uid isn't reset back to the user's uid). We can
> >>> detect this.
> >>> +parentuid = os.getuid()
> >>> +pid = os.fork()
> >>> +if not pid:
> >>> +try:
> >>> +bb.utils.disable_network()
> >>> +except:
> >>> +pass
> >>> +os._exit(parentuid != os.getuid())
> >>> +
> >>> +ret = os.waitpid(pid, 0)[1]
> >>> +if ret:
> >>> +bb.fatal("User namespaces are not usable by BitBake, possibly
> >>
Re: [OE-core] [PATCH] sanity: check for working user namespaces
Works as expected, the build failed :).
openembedded-core/build$ bitbake -k zlib-native
ERROR: User namespaces are not usable by BitBake, possibly due to AppArmor.
See
https://discourse.ubuntu.com/t/ubuntu-24-04-lts-noble-numbat-release-notes/39890#unprivileged-user-namespace-restrictions
for more information.
The only issue might be that these checks are executed only once, so
if you have existing TMPDIR (where it was failing) then it will
continue failing with:
ERROR: PermissionError: [Errno 1] Operation not permitted
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/martin/work/bitbake/bin/bitbake-worker", line 278, in child
bb.utils.disable_network(uid, gid)
File "/home/martin/work/bitbake/lib/bb/utils.py", line 1696, in
disable_network
with open("/proc/self/uid_map", "w") as f:
PermissionError: [Errno 1] Operation not permitted
until TMPDIR is removed and sanity re-executed.
On Thu, Sep 12, 2024 at 6:59 PM Ross Burton via lists.openembedded.org
wrote:
>
> Note that in its final form this isn’t had any testing on an Ubuntu machine,
> so testing would be appreciated if anyone has an Ubuntu 24.x machine (not a
> container, need their kernel) with apparmor enabled.
>
> Thanks,
> Ross
>
> > On 12 Sep 2024, at 17:57, Ross Burton via lists.openembedded.org
> > wrote:
> >
> > If user namespaces are not available (typically because AppArmor is
> > blocking them), alert the user.
> >
> > We consider network isolation sufficiently important that this is a fatal
> > error, and the user will need to configure AppArmor to allow bitbake to
> > create a user namespace.
> >
> > [ YOCTO #15592 ]
> >
> > Signed-off-by: Ross Burton
> > ---
> > meta/classes-global/sanity.bbclass | 24
> > 1 file changed, 24 insertions(+)
> >
> > diff --git a/meta/classes-global/sanity.bbclass
> > b/meta/classes-global/sanity.bbclass
> > index 1d242f0f0a0..72dab0fea2b 100644
> > --- a/meta/classes-global/sanity.bbclass
> > +++ b/meta/classes-global/sanity.bbclass
> > @@ -475,6 +475,29 @@ def check_wsl(d):
> > bb.warn("You are running bitbake under WSLv2, this works
> > properly but you should optimize your VHDX file eventually to avoid running
> > out of storage space")
> > return None
> >
> > +def check_userns():
> > +"""
> > +Check that user namespaces are functional, as they're used for network
> > isolation.
> > +"""
> > +
> > +# There is a known failure case with AppAmrmor where the unshare() call
> > +# succeeds (at which point the uid is nobody) but writing to the
> > uid_map
> > +# fails (so the uid isn't reset back to the user's uid). We can detect
> > this.
> > +parentuid = os.getuid()
> > +pid = os.fork()
> > +if not pid:
> > +try:
> > +bb.utils.disable_network()
> > +except:
> > +pass
> > +os._exit(parentuid != os.getuid())
> > +
> > +ret = os.waitpid(pid, 0)[1]
> > +if ret:
> > +bb.fatal("User namespaces are not usable by BitBake, possibly due
> > to AppArmor.\n"
> > + "See
> > https://discourse.ubuntu.com/t/ubuntu-24-04-lts-noble-numbat-release-notes/39890#unprivileged-user-namespace-restrictions
> > for more information.")
> > +
> > +
> > # Require at least gcc version 8.0
> > #
> > # This can be fixed on CentOS-7 with devtoolset-6+
> > @@ -641,6 +664,7 @@ def check_sanity_version_change(status, d):
> > status.addresult(check_git_version(d))
> > status.addresult(check_perl_modules(d))
> > status.addresult(check_wsl(d))
> > +status.addresult(check_userns())
> >
> > missing = ""
> >
> > --
> > 2.34.1
> >
> >
> >
> >
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#204452):
https://lists.openembedded.org/g/openembedded-core/message/204452
Mute This Topic: https://lists.openembedded.org/mt/108416977/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] Revert "python3-setuptools: upgrade 72.1.0 -> 72.2.0"
On Mon, Sep 9, 2024 at 10:40 AM Alexander Kanavin wrote: > > It would help to include specific steps to reproduce the problem in > the commit message here, otherwise there's going to be unneeded > friction when someone submits an update again without being aware of > the issue. Inherit ccache, build anything which uses python3-setuptools (e.g. python3-icu). -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#204320): https://lists.openembedded.org/g/openembedded-core/message/204320 Mute This Topic: https://lists.openembedded.org/mt/108308394/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [scarthgap][PATCH] yocto-uninative: Update to 4.6 for glibc 2.40
From: Michael Halstead
Signed-off-by: Michael Halstead
Signed-off-by: Richard Purdie
---
meta/conf/distro/include/yocto-uninative.inc | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/meta/conf/distro/include/yocto-uninative.inc
b/meta/conf/distro/include/yocto-uninative.inc
index 657c1032f9..a6f7107dfe 100644
--- a/meta/conf/distro/include/yocto-uninative.inc
+++ b/meta/conf/distro/include/yocto-uninative.inc
@@ -6,10 +6,10 @@
# to the distro running on the build machine.
#
-UNINATIVE_MAXGLIBCVERSION = "2.39"
-UNINATIVE_VERSION = "4.5"
+UNINATIVE_MAXGLIBCVERSION = "2.40"
+UNINATIVE_VERSION = "4.6"
UNINATIVE_URL ?=
"http://downloads.yoctoproject.org/releases/uninative/${UNINATIVE_VERSION}/";
-UNINATIVE_CHECKSUM[aarch64] ?=
"df2e29e2e6feb187a3499abf3b1322a3b251da819c77a7b19d4fe952351365ab"
-UNINATIVE_CHECKSUM[i686] ?=
"8ef3eda53428b484c20157f6ec3c130b03080b3d4b3889067e0e184e05102d35"
-UNINATIVE_CHECKSUM[x86_64] ?=
"43ee6a25bcf5fce16ea87076d6a96e79ead6ced90690a058d07432f902773473"
+UNINATIVE_CHECKSUM[aarch64] ?=
"c2d36338272eba101580f648dd8dff5352cdb4c1809db7dedf8fc4d7e7df716c"
+UNINATIVE_CHECKSUM[i686] ?=
"0041584678109c18deca48fb59eaf14cf725cf024a170ab537b354b63240c504"
+UNINATIVE_CHECKSUM[x86_64] ?=
"6bf00154c5a7bc48adbf63fd17684bb87eb07f4814fbb482a3fbd817c1ccf4c5"
--
2.46.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#204301):
https://lists.openembedded.org/g/openembedded-core/message/204301
Mute This Topic: https://lists.openembedded.org/mt/108337131/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 19/24] python3-setuptools: upgrade 72.1.0 -> 72.2.0
Hi Khem, it's surely related, but not a simple revert (as distutils commits are merged into setuptools into different prefix and there were couple commits on top), but with most of it reverted as in: https://git.openembedded.org/openembedded-core-contrib/commit/?h=jansa/master-setuptools&id=cf310822e986802b0b97a7dcac2b9022d640efab it no longer fails (tested with python3-icu with ccache enabled). Regards, On Tue, Sep 3, 2024 at 7:01 PM Khem Raj wrote: > > Hi Martin > > Can you try reverting this patch > > https://github.com/pypa/setuptools/commit/2c937116cc0dcd9b26b6070e89a3dc5dcbedc2ae > > and see if it helps ? > > On Tue, Sep 3, 2024 at 1:36 AM Martin Jansa via lists.openembedded.org > wrote: > > > > Hello Wang, > > > > did you have a look at this regression (with ccache) from the > > setuptools upgrade? > > > > Regards, > > > > On Thu, Aug 22, 2024 at 6:30 PM Martin Jansa wrote: > > > > > > This seems to break python3-numpy build. > > > > > > I guess it can be resolved by upgrading numpy as in: > > > https://lists.openembedded.org/g/openembedded-core/message/203231 > > > which switches from setuptools3 to python_mesonpy > > > > > > Comparing the failing command line it looks like CXX and some other > > > flags are included twice: > > > > > > with: setuptools-72.2.0: > > > > > > ccache \ > > > aarch64-oe-linux-g++ \ > > > -fstack-protector-all \ > > > -O2 \ > > > -D_FORTIFY_SOURCE=2 \ > > > -Wformat \ > > > -Wformat-security \ > > > -Werror=format-security \ > > > -Werror=return-type \ > > > -funwind-tables \ > > > --sysroot=WORKDIR/recipe-sysroot \ > > > -O2 \ > > > -g \ > > > -fcanon-prefix-map \ > > > -fmacro-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 > > > \ > > > -fdebug-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 > > > \ > > > -fmacro-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 > > > \ > > > -fdebug-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 > > > \ > > > -fdebug-prefix-map=WORKDIR/recipe-sysroot= \ > > > -fmacro-prefix-map=WORKDIR/recipe-sysroot= \ > > > -fdebug-prefix-map=WORKDIR/recipe-sysroot-native= \ > > > -pipe \ > > > -fvisibility-inlines-hidden \ > > > aarch64-oe-linux-g++ \ > > > -fstack-protector-all \ > > > -O2 \ > > > -D_FORTIFY_SOURCE=2 \ > > > -Wformat \ > > > -Wformat-security \ > > > -Werror=format-security \ > > > -Werror=return-type \ > > > -funwind-tables \ > > > --sysroot=WORKDIR/recipe-sysroot \ > > > -shared \ > > > -Wl,-O1 \ > > > -Wl,--hash-style=gnu \ > > > -Wl,--as-needed \ > > > -fcanon-prefix-map \ > > > -fmacro-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 > > > \ > > > -fdebug-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 > > > \ > > > -fmacro-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 > > > \ > > > -fdebug-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 > > > \ > > > -fdebug-prefix-map=WORKDIR/recipe-sysroot= \ > > > -fmacro-prefix-map=WORKDIR/recipe-sysroot= \ > > > -fdebug-prefix-map=WORKDIR/recipe-sysroot-native= \ > > > -Wl,-z,relro,-z,now \ > > > -O2 \ > > > -g \ > > > -fcanon-prefix-map \ > > > -fmacro-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 > > > \ > > > -fdebug-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 > > > \ > > > -fmacro-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 > > > \ > > > -fdebug-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 > > > \ > > > -fdebug-prefix-map=WORKDIR/recipe-sysroot= \ > > > -fmacro-prefix-map=WORKDIR/recipe-sysroot= \ > > > -fdebug-prefix-map=WORKDIR/recipe-sysroot-native= \ > > > -pipe \ > > > -fvisibility-inlines-hidden \ > > > build/temp.linux-x86_64-cpython-312/build/src.linux-x86_64-3.12/numpy/core/src/multiarray/_multiarray_tests.o > > > \ > > > build/temp.linux-x86_64-cpython-312/numpy/core/src/common/mem_overlap.o \ > > > build/temp.linux-x86_64-cpython-312/numpy/core/src/common/npy_argparse.o \ > > > build/temp.linux-x86_64-cpython-312/numpy/core/src/common/npy_ha
[OE-core] [RFC PATCH v2] bitbake.conf: DEBUG_PREFIX_MAP: add -fmacro-prefix-map for STAGING_DIR_NATIVE
* the default STAGING_DIR_NATIVE starts with STAGING_DIR_HOST and the
only difference is '-native' suffix at the end
* this can lead into replacing STAGING_DIR_NATIVE path with just "-native"
in FILE macros
* I've noticed this by accident in python3-matplotlib where buildpaths
QA warning was triggered only for lib32-python3-matplotlib and it was
because pybind11 path to STAGING_DIR_NATIVE was mapped to only
'-native/' in python3-matplotlib build (which doesn't trigger
buildpaths QA and lib32-python3-matplotlib the macro path wasn't
replaced at all, because of 'lib32-' prefix in:
-fdebug-prefix-map=/OE/build/oe-core/tmp-glibc/work/i586-oemllib32-linux/lib32-python3-matplotlib/3.7.2/lib32-recipe-sysroot=
\
-fmacro-prefix-map=/OE/build/oe-core/tmp-glibc/work/i586-oemllib32-linux/lib32-python3-matplotlib/3.7.2/lib32-recipe-sysroot=
\
-fdebug-prefix-map=/OE/build/oe-core/tmp-glibc/work/i586-oemllib32-linux/lib32-python3-matplotlib/3.7.2/recipe-sysroot-native=
\
* more details in meta-python fix for lib32-python3-matplotlib:
https://lists.openembedded.org/g/openembedded-devel/message/112074
* the order of *-prefix-map options still seems to be that the last
one matching wins and this works with gcc and clang, see:
https://reviews.llvm.org/D148975?id=516863
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109591
* some components might sometimes be built with -coverage and could use
-fcoverage-prefix-map:
https://reviews.llvm.org/D148757
or -fprofile-prefix-map:
https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html#index-fprofile-prefix-map
but will leave that to recipes which actually use -coverage for now
Signed-off-by: Martin Jansa
---
v2: the order doesn't need to be changed
tested with gcc and clang by building both
lib32-python3-matplotlib and python3-matplotlib
and checking for buildpaths in
tmp-glibc*/work/*/*python3-matplotlib/*/package/usr/lib*/python3.12/site-packages/matplotlib/_tri.cpython-312-*-linux-gnu.so
and there were no TMPDIR or '^-native' paths inside (nor buildpaths QA
issues triggered with this change)
meta/conf/bitbake.conf | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index d8252c5b82..04b288abc1 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -656,6 +656,7 @@ DEBUG_PREFIX_MAP ?= "-fcanon-prefix-map \
-fdebug-prefix-map=${STAGING_DIR_HOST}= \
-fmacro-prefix-map=${STAGING_DIR_HOST}= \
-fdebug-prefix-map=${STAGING_DIR_NATIVE}= \
+ -fmacro-prefix-map=${STAGING_DIR_NATIVE}= \
"
DEBUG_LEVELFLAG ?= "-g"
--
2.46.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#204228):
https://lists.openembedded.org/g/openembedded-core/message/204228
Mute This Topic: https://lists.openembedded.org/mt/108281685/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [RFC PATCH] bitbake.conf: DEBUG_PREFIX_MAP: move STAGING_DIR_NATIVE before STAGING_DIR_HOST
On Wed, Sep 4, 2024 at 1:57 PM Richard Purdie
wrote:
>
> On Wed, 2024-09-04 at 08:53 +0200, Martin Jansa via
> lists.openembedded.org wrote:
> > Some related info I've found now:
> > https://reviews.llvm.org/D148975?id=516863
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109591
> >
> > maybe affected by -fcanon-prefix-map used since gcc-13:
> > https://git.openembedded.org/openembedded-core/commit/?id=abe97fa74b10c2c71d79bc3573d4edb509b111f5
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108464#c8
> >
> > and I was also using ccache which used to have some issues in this
> > area (but the python3-matplotlib issue is IIRC reproducible without
> > ccache as well):
> > https://github.com/ccache/ccache/issues/163
> >
> > We might need more experiments before this is applied (I'm glad I've
> > sent it only as RFC). I'll try to find some time next week.
>
> I'm a bit worried that gcc might apply the ordering one way in some
> locations and the other way around in others so there may be a bug
> lurking somewhere. I agree we should look further into this.
I had only a bit of time in the morning to quickly scan through them,
but if it's correct that gcc as well as llvm are applying the longest
substitution now, then the ordering might not be important anymore and
it might actually explain the case with python3-matplotlib I was
seeing, because for -fmacro-prefix-map there wasn't the native path at
all, so it "correctly" replaced the longest matching one which was
-fmacro-prefix-map=${STAGING_DIR_HOST}= for python3-matplotlib and no
replacement for lib32-python3-matplotlib as it didn't match at all in
any of them.
Will redo both builds with just
-fmacro-prefix-map=${STAGING_DIR_NATIVE}= added at the end to see if
it fixes paths in both python3-matplotlib and lib32-python3-matplotlib
and should probably test the same with clang to be sure it works the
same.
Regards,
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#204205):
https://lists.openembedded.org/g/openembedded-core/message/204205
Mute This Topic: https://lists.openembedded.org/mt/108229773/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [RFC PATCH] bitbake.conf: DEBUG_PREFIX_MAP: move STAGING_DIR_NATIVE before STAGING_DIR_HOST
Some related info I've found now:
https://reviews.llvm.org/D148975?id=516863
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109591
maybe affected by -fcanon-prefix-map used since gcc-13:
https://git.openembedded.org/openembedded-core/commit/?id=abe97fa74b10c2c71d79bc3573d4edb509b111f5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108464#c8
and I was also using ccache which used to have some issues in this
area (but the python3-matplotlib issue is IIRC reproducible without
ccache as well):
https://github.com/ccache/ccache/issues/163
We might need more experiments before this is applied (I'm glad I've
sent it only as RFC). I'll try to find some time next week.
On Wed, Sep 4, 2024 at 8:42 AM Martin Jansa via lists.openembedded.org
wrote:
>
> Please be aware that:
> https://git.openembedded.org/openembedded-core/commit/?id=593c3baf064b982891d61dacebd08aed3e96
> claims that these options are evaluated right to left (last one first)
> and even shows the same issue as what I was seeing as a reason to do
> the opposite (move STAGING_DIR_NATIVE after STAGING_DIR_HOST) and I'm
> basically reverting that change (which I didn't noticed until today).
>
> So either the processing order changed since 2018 with gcc-7.3 or
> something is wrong (at least the comment above DEBUG_PREFIX_MAP would
> be wrong if the processing order was changed).
>
> Regards,
>
> On Mon, Sep 2, 2024 at 6:29 PM Martin Jansa via lists.openembedded.org
> wrote:
> >
> > * and add -fmacro-prefix-map as well
> >
> > * the default STAGING_DIR_NATIVE starts with STAGING_DIR_HOST and the
> > only difference is '-native' suffix at the end
> >
> > * this can lead into replacing STAGING_DIR_NATIVE path with just -native
> > if STAGING_DIR_HOST is listed in DEBUG_PREFIX_MAP before
> > STAGING_DIR_NATIVE
> >
> > * I've noticed this by accident in python3-matplotlib where buildpaths
> > QA warning was triggered only for lib32-python3-matplotlib and it was
> > because pybind11 path to STAGING_DIR_NATIVE was mapped to only
> > '-native/' in python3-matplotlib build (which doesn't trigger
> > buildpaths QA and lib32-python3-matplotlib the macro path wasn't
> > replaced at all, because of 'lib32-' prefix in:
> >
> > -fdebug-prefix-map=/OE/build/oe-core/tmp-glibc/work/i586-oemllib32-linux/lib32-python3-matplotlib/3.7.2/lib32-recipe-sysroot=
> > \
> >
> > -fmacro-prefix-map=/OE/build/oe-core/tmp-glibc/work/i586-oemllib32-linux/lib32-python3-matplotlib/3.7.2/lib32-recipe-sysroot=
> > \
> >
> > -fdebug-prefix-map=/OE/build/oe-core/tmp-glibc/work/i586-oemllib32-linux/lib32-python3-matplotlib/3.7.2/recipe-sysroot-native=
> > \
> >
> > * more details in meta-python fix for lib32-python3-matplotlib:
> > https://lists.openembedded.org/g/openembedded-devel/message/112074
> >
> > Signed-off-by: Martin Jansa
> > ---
> > Sending as RFC, because I haven't build whole world with this
> > and there might be better way to do this or more buildpaths
> > issues triggered by this than fixed
> >
> > meta/conf/bitbake.conf | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> > index d8252c5b82..ad152ffb6a 100644
> > --- a/meta/conf/bitbake.conf
> > +++ b/meta/conf/bitbake.conf
> > @@ -653,9 +653,10 @@ DEBUG_PREFIX_MAP ?= "-fcanon-prefix-map \
> > -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_NATIVE}= \
> > + -fmacro-prefix-map=${STAGING_DIR_NATIVE}= \
> > -fdebug-prefix-map=${STAGING_DIR_HOST}= \
> > -fmacro-prefix-map=${STAGING_DIR_HOST}= \
> > - -fdebug-prefix-map=${STAGING_DIR_NATIVE}= \
> > "
> > DEBUG_LEVELFLAG ?= "-g"
> >
> > --
> > 2.46.0
> >
> >
> >
> >
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#204192):
https://lists.openembedded.org/g/openembedded-core/message/204192
Mute This Topic: https://lists.openembedded.org/mt/108229773/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [RFC PATCH] bitbake.conf: DEBUG_PREFIX_MAP: move STAGING_DIR_NATIVE before STAGING_DIR_HOST
Please be aware that:
https://git.openembedded.org/openembedded-core/commit/?id=593c3baf064b982891d61dacebd08aed3e96
claims that these options are evaluated right to left (last one first)
and even shows the same issue as what I was seeing as a reason to do
the opposite (move STAGING_DIR_NATIVE after STAGING_DIR_HOST) and I'm
basically reverting that change (which I didn't noticed until today).
So either the processing order changed since 2018 with gcc-7.3 or
something is wrong (at least the comment above DEBUG_PREFIX_MAP would
be wrong if the processing order was changed).
Regards,
On Mon, Sep 2, 2024 at 6:29 PM Martin Jansa via lists.openembedded.org
wrote:
>
> * and add -fmacro-prefix-map as well
>
> * the default STAGING_DIR_NATIVE starts with STAGING_DIR_HOST and the
> only difference is '-native' suffix at the end
>
> * this can lead into replacing STAGING_DIR_NATIVE path with just -native
> if STAGING_DIR_HOST is listed in DEBUG_PREFIX_MAP before STAGING_DIR_NATIVE
>
> * I've noticed this by accident in python3-matplotlib where buildpaths
> QA warning was triggered only for lib32-python3-matplotlib and it was
> because pybind11 path to STAGING_DIR_NATIVE was mapped to only
> '-native/' in python3-matplotlib build (which doesn't trigger
> buildpaths QA and lib32-python3-matplotlib the macro path wasn't
> replaced at all, because of 'lib32-' prefix in:
>
> -fdebug-prefix-map=/OE/build/oe-core/tmp-glibc/work/i586-oemllib32-linux/lib32-python3-matplotlib/3.7.2/lib32-recipe-sysroot=
> \
>
> -fmacro-prefix-map=/OE/build/oe-core/tmp-glibc/work/i586-oemllib32-linux/lib32-python3-matplotlib/3.7.2/lib32-recipe-sysroot=
> \
>
> -fdebug-prefix-map=/OE/build/oe-core/tmp-glibc/work/i586-oemllib32-linux/lib32-python3-matplotlib/3.7.2/recipe-sysroot-native=
> \
>
> * more details in meta-python fix for lib32-python3-matplotlib:
> https://lists.openembedded.org/g/openembedded-devel/message/112074
>
> Signed-off-by: Martin Jansa
> ---
> Sending as RFC, because I haven't build whole world with this
> and there might be better way to do this or more buildpaths
> issues triggered by this than fixed
>
> meta/conf/bitbake.conf | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> index d8252c5b82..ad152ffb6a 100644
> --- a/meta/conf/bitbake.conf
> +++ b/meta/conf/bitbake.conf
> @@ -653,9 +653,10 @@ DEBUG_PREFIX_MAP ?= "-fcanon-prefix-map \
> -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_NATIVE}= \
> + -fmacro-prefix-map=${STAGING_DIR_NATIVE}= \
> -fdebug-prefix-map=${STAGING_DIR_HOST}= \
> -fmacro-prefix-map=${STAGING_DIR_HOST}= \
> - -fdebug-prefix-map=${STAGING_DIR_NATIVE}= \
> "
> DEBUG_LEVELFLAG ?= "-g"
>
> --
> 2.46.0
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#204190):
https://lists.openembedded.org/g/openembedded-core/message/204190
Mute This Topic: https://lists.openembedded.org/mt/108229773/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 19/24] python3-setuptools: upgrade 72.1.0 -> 72.2.0
Hello Wang, did you have a look at this regression (with ccache) from the setuptools upgrade? Regards, On Thu, Aug 22, 2024 at 6:30 PM Martin Jansa wrote: > > This seems to break python3-numpy build. > > I guess it can be resolved by upgrading numpy as in: > https://lists.openembedded.org/g/openembedded-core/message/203231 > which switches from setuptools3 to python_mesonpy > > Comparing the failing command line it looks like CXX and some other > flags are included twice: > > with: setuptools-72.2.0: > > ccache \ > aarch64-oe-linux-g++ \ > -fstack-protector-all \ > -O2 \ > -D_FORTIFY_SOURCE=2 \ > -Wformat \ > -Wformat-security \ > -Werror=format-security \ > -Werror=return-type \ > -funwind-tables \ > --sysroot=WORKDIR/recipe-sysroot \ > -O2 \ > -g \ > -fcanon-prefix-map \ > -fmacro-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 \ > -fdebug-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 \ > -fmacro-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 \ > -fdebug-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 \ > -fdebug-prefix-map=WORKDIR/recipe-sysroot= \ > -fmacro-prefix-map=WORKDIR/recipe-sysroot= \ > -fdebug-prefix-map=WORKDIR/recipe-sysroot-native= \ > -pipe \ > -fvisibility-inlines-hidden \ > aarch64-oe-linux-g++ \ > -fstack-protector-all \ > -O2 \ > -D_FORTIFY_SOURCE=2 \ > -Wformat \ > -Wformat-security \ > -Werror=format-security \ > -Werror=return-type \ > -funwind-tables \ > --sysroot=WORKDIR/recipe-sysroot \ > -shared \ > -Wl,-O1 \ > -Wl,--hash-style=gnu \ > -Wl,--as-needed \ > -fcanon-prefix-map \ > -fmacro-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 \ > -fdebug-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 \ > -fmacro-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 \ > -fdebug-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 \ > -fdebug-prefix-map=WORKDIR/recipe-sysroot= \ > -fmacro-prefix-map=WORKDIR/recipe-sysroot= \ > -fdebug-prefix-map=WORKDIR/recipe-sysroot-native= \ > -Wl,-z,relro,-z,now \ > -O2 \ > -g \ > -fcanon-prefix-map \ > -fmacro-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 \ > -fdebug-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 \ > -fmacro-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 \ > -fdebug-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 \ > -fdebug-prefix-map=WORKDIR/recipe-sysroot= \ > -fmacro-prefix-map=WORKDIR/recipe-sysroot= \ > -fdebug-prefix-map=WORKDIR/recipe-sysroot-native= \ > -pipe \ > -fvisibility-inlines-hidden \ > build/temp.linux-x86_64-cpython-312/build/src.linux-x86_64-3.12/numpy/core/src/multiarray/_multiarray_tests.o > \ > build/temp.linux-x86_64-cpython-312/numpy/core/src/common/mem_overlap.o \ > build/temp.linux-x86_64-cpython-312/numpy/core/src/common/npy_argparse.o \ > build/temp.linux-x86_64-cpython-312/numpy/core/src/common/npy_hashtable.o \ > -LWORKDIR/recipe-sysroot/usr/lib \ > -Lbuild/temp.linux-x86_64-cpython-312 \ > -lnpymath \ > -o \ > build/lib.linux-x86_64-cpython-312/numpy/core/_multiarray_tests.cpython-312-aarch64-linux-gnu.so > > --- setuptools-72.1.0 2024-08-22 18:17:36.941146726 +0200 > +++ setuptools-72.2.0 2024-08-22 18:17:27.208147768 +0200 > @@ -9,6 +9,28 @@ > -Werror=return-type \ > -funwind-tables \ > --sysroot=WORKDIR/recipe-sysroot \ > +-O2 \ > +-g \ > +-fcanon-prefix-map \ > +-fmacro-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 \ > +-fdebug-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 \ > +-fmacro-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 \ > +-fdebug-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 \ > +-fdebug-prefix-map=WORKDIR/recipe-sysroot= \ > +-fmacro-prefix-map=WORKDIR/recipe-sysroot= \ > +-fdebug-prefix-map=WORKDIR/recipe-sysroot-native= \ > +-pipe \ > +-fvisibility-inlines-hidden \ > +aarch64-oe-linux-g++ \ > +-fstack-protector-all \ > +-O2 \ > +-D_FORTIFY_SOURCE=2 \ > +-Wformat \ > +-Wformat-security \ > +-Werror=format-security \ > +-Werror=return-type \ > +-funwind-tables \ > +--sysroot=WORKDIR/recipe-sysroot \ > -shared \ > -Wl,-O1 \ > -Wl,--hash-style=gnu \ > @@ -33,6 +55,7 @@ > -fmacro-prefix-map=WORKDIR/recipe-sysroot= \ > -fdebug-prefix-map=WORKDIR/recipe-sysroot-native= \ > -pipe \ > +-fvisibility-inlines-hidden \ > > build/temp.linux-x86_64-cpython-312/build/src.linux-x86_64-3.12/numpy/core/src/multiarray/_multiarray_tests.o > \ > build/temp.linux-x86_64-cpython-312/numpy/core/src/common/mem_o
[OE-core] [RFC PATCH] bitbake.conf: DEBUG_PREFIX_MAP: move STAGING_DIR_NATIVE before STAGING_DIR_HOST
* and add -fmacro-prefix-map as well
* the default STAGING_DIR_NATIVE starts with STAGING_DIR_HOST and the
only difference is '-native' suffix at the end
* this can lead into replacing STAGING_DIR_NATIVE path with just -native
if STAGING_DIR_HOST is listed in DEBUG_PREFIX_MAP before STAGING_DIR_NATIVE
* I've noticed this by accident in python3-matplotlib where buildpaths
QA warning was triggered only for lib32-python3-matplotlib and it was
because pybind11 path to STAGING_DIR_NATIVE was mapped to only
'-native/' in python3-matplotlib build (which doesn't trigger
buildpaths QA and lib32-python3-matplotlib the macro path wasn't
replaced at all, because of 'lib32-' prefix in:
-fdebug-prefix-map=/OE/build/oe-core/tmp-glibc/work/i586-oemllib32-linux/lib32-python3-matplotlib/3.7.2/lib32-recipe-sysroot=
\
-fmacro-prefix-map=/OE/build/oe-core/tmp-glibc/work/i586-oemllib32-linux/lib32-python3-matplotlib/3.7.2/lib32-recipe-sysroot=
\
-fdebug-prefix-map=/OE/build/oe-core/tmp-glibc/work/i586-oemllib32-linux/lib32-python3-matplotlib/3.7.2/recipe-sysroot-native=
\
* more details in meta-python fix for lib32-python3-matplotlib:
https://lists.openembedded.org/g/openembedded-devel/message/112074
Signed-off-by: Martin Jansa
---
Sending as RFC, because I haven't build whole world with this
and there might be better way to do this or more buildpaths
issues triggered by this than fixed
meta/conf/bitbake.conf | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index d8252c5b82..ad152ffb6a 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -653,9 +653,10 @@ DEBUG_PREFIX_MAP ?= "-fcanon-prefix-map \
-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_NATIVE}= \
+ -fmacro-prefix-map=${STAGING_DIR_NATIVE}= \
-fdebug-prefix-map=${STAGING_DIR_HOST}= \
-fmacro-prefix-map=${STAGING_DIR_HOST}= \
- -fdebug-prefix-map=${STAGING_DIR_NATIVE}= \
"
DEBUG_LEVELFLAG ?= "-g"
--
2.46.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#204110):
https://lists.openembedded.org/g/openembedded-core/message/204110
Mute This Topic: https://lists.openembedded.org/mt/108229773/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] mc: set ac_cv_path_ZIP to avoid buildpaths QA issues
* in builds with zip in HOSTTOOLS mc fails with:
ERROR: mc-4.8.31-r0 do_package_qa: QA Issue: File
/usr/libexec/mc/extfs.d/uzip in package mc-helpers-perl contains reference to
TMPDIR [buildpaths]
and it's because of the path to zip:
mc/4.8.31/package $ grep -R styhead .
./usr/libexec/mc/extfs.d/uzip:my $app_zip = "TMPDIR/hosttools/zip";
* don't use /usr/bin/env as in other cases, because app_zip is then used e.g.
with:
my $cmd_addlink = "$app_zip -g -y";
Signed-off-by: Martin Jansa
---
meta/recipes-extended/mc/mc_4.8.31.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-extended/mc/mc_4.8.31.bb
b/meta/recipes-extended/mc/mc_4.8.31.bb
index 5f8257f71f..69d089d267 100644
--- a/meta/recipes-extended/mc/mc_4.8.31.bb
+++ b/meta/recipes-extended/mc/mc_4.8.31.bb
@@ -31,6 +31,7 @@ CACHED_CONFIGUREVARS += "ac_cv_path_PERL='/usr/bin/env perl'"
CACHED_CONFIGUREVARS += "ac_cv_path_PERL_FOR_BUILD='/usr/bin/env perl'"
CACHED_CONFIGUREVARS += "ac_cv_path_PYTHON='/usr/bin/env python'"
CACHED_CONFIGUREVARS += "ac_cv_path_GREP='/usr/bin/env grep'"
+CACHED_CONFIGUREVARS += "ac_cv_path_ZIP='/usr/bin/zip'"
CACHED_CONFIGUREVARS += "mc_cv_have_zipinfo=yes"
do_install:append () {
--
2.46.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#204062):
https://lists.openembedded.org/g/openembedded-core/message/204062
Mute This Topic: https://lists.openembedded.org/mt/108223402/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] python3-numpy: disable ccache
It seems to be bigger issue in multiple python recipes (numpy was the
only one shown in my image builds), in world build with ccache enabled
I see:
meta-oe/meta-python/recipes-devtools/python/python3-msgpack_1.0.8.bb:do_compile)
failed with exit code '1'
meta-oe/meta-python/recipes-devtools/python/python3-ujson_5.10.0.bb:do_compile)
failed with exit code '1'
meta-oe/meta-python/recipes-devtools/python/python3-rapidjson_1.19.bb:do_compile)
failed with exit code '1'
meta-oe/meta-python/recipes-devtools/python/python3-greenlet_3.0.3.bb:do_compile)
failed with exit code '1'
meta-oe/meta-python/recipes-devtools/python/python3-matplotlib_3.7.2.bb:do_compile)
failed with exit code '1'
meta-oe/meta-python/recipes-devtools/python/python3-fastnumbers_5.1.0.bb:do_compile)
failed with exit code '1'
meta-oe/meta-python/recipes-devtools/python/python3-kiwisolver_1.4.5.bb:do_compile)
failed with exit code '1'
meta-oe/meta-python/recipes-devtools/python/python3-fann2_1.1.2.bb:do_compile)
failed with exit code '1'
meta-oe/meta-python/recipes-devtools/python/python3-snappy_0.6.1.bb:do_compile)
failed with exit code '1'
meta-oe/meta-python/recipes-devtools/python/python3-icu_2.13.1.bb:do_compile)
failed with exit code '1'
meta-oe/meta-python/recipes-devtools/python/python3-grpcio-tools_1.62.2.bb:do_compile)
failed with exit code '1'
meta-oe/meta-python/recipes-devtools/python/python3-cchardet_2.1.7.bb:do_compile)
failed with exit code '1'
meta-oe/meta-python/recipes-devtools/python/python3-pandas_2.0.3.bb:do_compile)
failed with exit code '1'
probably because of the same issue, so setuptools should probably be
fixed instead.
On Thu, Aug 22, 2024 at 8:27 PM Martin Jansa via
lists.openembedded.org
wrote:
>
> * fails to parse CXX correctly since the setuptools upgrade from 72.1.0 to
> 72.2.0
> * it can be resolved by upgrading numpy as in:
> https://lists.openembedded.org/g/openembedded-core/message/203231
> which switches from setuptools3 to python_mesonpy, but before that
> is merged, we can just disable ccache here
> * more details in:
> https://lists.openembedded.org/g/openembedded-core/message/203658
>
> Signed-off-by: Martin Jansa
> ---
> meta/recipes-devtools/python/python3-numpy_1.26.4.bb | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/meta/recipes-devtools/python/python3-numpy_1.26.4.bb
> b/meta/recipes-devtools/python/python3-numpy_1.26.4.bb
> index 914245507c..7cd9d30d2d 100644
> --- a/meta/recipes-devtools/python/python3-numpy_1.26.4.bb
> +++ b/meta/recipes-devtools/python/python3-numpy_1.26.4.bb
> @@ -24,6 +24,9 @@ inherit ptest setuptools3 github-releases
>
> S = "${WORKDIR}/numpy-${PV}"
>
> +# fails to parse CXX correctly since the setuptools upgrade from 72.1.0 to
> 72.2.0
> +# https://lists.openembedded.org/g/openembedded-core/message/203658
> +CCACHE_DISABLE = "1"
> CLEANBROKEN = "1"
>
> do_compile:prepend() {
> --
> 2.46.0
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#203687):
https://lists.openembedded.org/g/openembedded-core/message/203687
Mute This Topic: https://lists.openembedded.org/mt/108043577/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] python3-numpy: disable ccache
* fails to parse CXX correctly since the setuptools upgrade from 72.1.0 to
72.2.0
* it can be resolved by upgrading numpy as in:
https://lists.openembedded.org/g/openembedded-core/message/203231
which switches from setuptools3 to python_mesonpy, but before that
is merged, we can just disable ccache here
* more details in:
https://lists.openembedded.org/g/openembedded-core/message/203658
Signed-off-by: Martin Jansa
---
meta/recipes-devtools/python/python3-numpy_1.26.4.bb | 3 +++
1 file changed, 3 insertions(+)
diff --git a/meta/recipes-devtools/python/python3-numpy_1.26.4.bb
b/meta/recipes-devtools/python/python3-numpy_1.26.4.bb
index 914245507c..7cd9d30d2d 100644
--- a/meta/recipes-devtools/python/python3-numpy_1.26.4.bb
+++ b/meta/recipes-devtools/python/python3-numpy_1.26.4.bb
@@ -24,6 +24,9 @@ inherit ptest setuptools3 github-releases
S = "${WORKDIR}/numpy-${PV}"
+# fails to parse CXX correctly since the setuptools upgrade from 72.1.0 to
72.2.0
+# https://lists.openembedded.org/g/openembedded-core/message/203658
+CCACHE_DISABLE = "1"
CLEANBROKEN = "1"
do_compile:prepend() {
--
2.46.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#203660):
https://lists.openembedded.org/g/openembedded-core/message/203660
Mute This Topic: https://lists.openembedded.org/mt/108043577/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 19/24] python3-setuptools: upgrade 72.1.0 -> 72.2.0
It seems to fail only when ccache is enabled, I'll send patch to add CCACHE_DISABLE to numpy recipe to work around this issue for now. On Thu, Aug 22, 2024 at 6:30 PM Martin Jansa via lists.openembedded.org wrote: > > This seems to break python3-numpy build. > > I guess it can be resolved by upgrading numpy as in: > https://lists.openembedded.org/g/openembedded-core/message/203231 > which switches from setuptools3 to python_mesonpy > > Comparing the failing command line it looks like CXX and some other > flags are included twice: > > with: setuptools-72.2.0: > > ccache \ > aarch64-oe-linux-g++ \ > -fstack-protector-all \ > -O2 \ > -D_FORTIFY_SOURCE=2 \ > -Wformat \ > -Wformat-security \ > -Werror=format-security \ > -Werror=return-type \ > -funwind-tables \ > --sysroot=WORKDIR/recipe-sysroot \ > -O2 \ > -g \ > -fcanon-prefix-map \ > -fmacro-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 \ > -fdebug-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 \ > -fmacro-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 \ > -fdebug-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 \ > -fdebug-prefix-map=WORKDIR/recipe-sysroot= \ > -fmacro-prefix-map=WORKDIR/recipe-sysroot= \ > -fdebug-prefix-map=WORKDIR/recipe-sysroot-native= \ > -pipe \ > -fvisibility-inlines-hidden \ > aarch64-oe-linux-g++ \ > -fstack-protector-all \ > -O2 \ > -D_FORTIFY_SOURCE=2 \ > -Wformat \ > -Wformat-security \ > -Werror=format-security \ > -Werror=return-type \ > -funwind-tables \ > --sysroot=WORKDIR/recipe-sysroot \ > -shared \ > -Wl,-O1 \ > -Wl,--hash-style=gnu \ > -Wl,--as-needed \ > -fcanon-prefix-map \ > -fmacro-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 \ > -fdebug-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 \ > -fmacro-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 \ > -fdebug-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 \ > -fdebug-prefix-map=WORKDIR/recipe-sysroot= \ > -fmacro-prefix-map=WORKDIR/recipe-sysroot= \ > -fdebug-prefix-map=WORKDIR/recipe-sysroot-native= \ > -Wl,-z,relro,-z,now \ > -O2 \ > -g \ > -fcanon-prefix-map \ > -fmacro-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 \ > -fdebug-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 \ > -fmacro-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 \ > -fdebug-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 \ > -fdebug-prefix-map=WORKDIR/recipe-sysroot= \ > -fmacro-prefix-map=WORKDIR/recipe-sysroot= \ > -fdebug-prefix-map=WORKDIR/recipe-sysroot-native= \ > -pipe \ > -fvisibility-inlines-hidden \ > build/temp.linux-x86_64-cpython-312/build/src.linux-x86_64-3.12/numpy/core/src/multiarray/_multiarray_tests.o > \ > build/temp.linux-x86_64-cpython-312/numpy/core/src/common/mem_overlap.o \ > build/temp.linux-x86_64-cpython-312/numpy/core/src/common/npy_argparse.o \ > build/temp.linux-x86_64-cpython-312/numpy/core/src/common/npy_hashtable.o \ > -LWORKDIR/recipe-sysroot/usr/lib \ > -Lbuild/temp.linux-x86_64-cpython-312 \ > -lnpymath \ > -o \ > build/lib.linux-x86_64-cpython-312/numpy/core/_multiarray_tests.cpython-312-aarch64-linux-gnu.so > > --- setuptools-72.1.0 2024-08-22 18:17:36.941146726 +0200 > +++ setuptools-72.2.0 2024-08-22 18:17:27.208147768 +0200 > @@ -9,6 +9,28 @@ > -Werror=return-type \ > -funwind-tables \ > --sysroot=WORKDIR/recipe-sysroot \ > +-O2 \ > +-g \ > +-fcanon-prefix-map \ > +-fmacro-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 \ > +-fdebug-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 \ > +-fmacro-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 \ > +-fdebug-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 \ > +-fdebug-prefix-map=WORKDIR/recipe-sysroot= \ > +-fmacro-prefix-map=WORKDIR/recipe-sysroot= \ > +-fdebug-prefix-map=WORKDIR/recipe-sysroot-native= \ > +-pipe \ > +-fvisibility-inlines-hidden \ > +aarch64-oe-linux-g++ \ > +-fstack-protector-all \ > +-O2 \ > +-D_FORTIFY_SOURCE=2 \ > +-Wformat \ > +-Wformat-security \ > +-Werror=format-security \ > +-Werror=return-type \ > +-funwind-tables \ > +--sysroot=WORKDIR/recipe-sysroot \ > -shared \ > -Wl,-O1 \ > -Wl,--hash-style=gnu \ > @@ -33,6 +55,7 @@ > -fmacro-prefix-map=WORKDIR/recipe-sysroot= \ > -fdebug-prefix-map=WORKDIR/recipe-sysroot-native= \ > -pipe \ > +-fvisibility-inlines-hidden \ > > build/temp.linux-x86_64-cpython-312/build/src.linux-x86_64-3.12/numpy/core/src/multiarray/_multiarray_tests.o > \ > b
Re: [OE-core] [PATCH 19/24] python3-setuptools: upgrade 72.1.0 -> 72.2.0
This seems to break python3-numpy build. I guess it can be resolved by upgrading numpy as in: https://lists.openembedded.org/g/openembedded-core/message/203231 which switches from setuptools3 to python_mesonpy Comparing the failing command line it looks like CXX and some other flags are included twice: with: setuptools-72.2.0: ccache \ aarch64-oe-linux-g++ \ -fstack-protector-all \ -O2 \ -D_FORTIFY_SOURCE=2 \ -Wformat \ -Wformat-security \ -Werror=format-security \ -Werror=return-type \ -funwind-tables \ --sysroot=WORKDIR/recipe-sysroot \ -O2 \ -g \ -fcanon-prefix-map \ -fmacro-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 \ -fdebug-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 \ -fmacro-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 \ -fdebug-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 \ -fdebug-prefix-map=WORKDIR/recipe-sysroot= \ -fmacro-prefix-map=WORKDIR/recipe-sysroot= \ -fdebug-prefix-map=WORKDIR/recipe-sysroot-native= \ -pipe \ -fvisibility-inlines-hidden \ aarch64-oe-linux-g++ \ -fstack-protector-all \ -O2 \ -D_FORTIFY_SOURCE=2 \ -Wformat \ -Wformat-security \ -Werror=format-security \ -Werror=return-type \ -funwind-tables \ --sysroot=WORKDIR/recipe-sysroot \ -shared \ -Wl,-O1 \ -Wl,--hash-style=gnu \ -Wl,--as-needed \ -fcanon-prefix-map \ -fmacro-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 \ -fdebug-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 \ -fmacro-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 \ -fdebug-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 \ -fdebug-prefix-map=WORKDIR/recipe-sysroot= \ -fmacro-prefix-map=WORKDIR/recipe-sysroot= \ -fdebug-prefix-map=WORKDIR/recipe-sysroot-native= \ -Wl,-z,relro,-z,now \ -O2 \ -g \ -fcanon-prefix-map \ -fmacro-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 \ -fdebug-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 \ -fmacro-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 \ -fdebug-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 \ -fdebug-prefix-map=WORKDIR/recipe-sysroot= \ -fmacro-prefix-map=WORKDIR/recipe-sysroot= \ -fdebug-prefix-map=WORKDIR/recipe-sysroot-native= \ -pipe \ -fvisibility-inlines-hidden \ build/temp.linux-x86_64-cpython-312/build/src.linux-x86_64-3.12/numpy/core/src/multiarray/_multiarray_tests.o \ build/temp.linux-x86_64-cpython-312/numpy/core/src/common/mem_overlap.o \ build/temp.linux-x86_64-cpython-312/numpy/core/src/common/npy_argparse.o \ build/temp.linux-x86_64-cpython-312/numpy/core/src/common/npy_hashtable.o \ -LWORKDIR/recipe-sysroot/usr/lib \ -Lbuild/temp.linux-x86_64-cpython-312 \ -lnpymath \ -o \ build/lib.linux-x86_64-cpython-312/numpy/core/_multiarray_tests.cpython-312-aarch64-linux-gnu.so --- setuptools-72.1.0 2024-08-22 18:17:36.941146726 +0200 +++ setuptools-72.2.0 2024-08-22 18:17:27.208147768 +0200 @@ -9,6 +9,28 @@ -Werror=return-type \ -funwind-tables \ --sysroot=WORKDIR/recipe-sysroot \ +-O2 \ +-g \ +-fcanon-prefix-map \ +-fmacro-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 \ +-fdebug-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 \ +-fmacro-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 \ +-fdebug-prefix-map=WORKDIR/numpy-1.26.4=/usr/src/debug/python3-numpy/1.26.4 \ +-fdebug-prefix-map=WORKDIR/recipe-sysroot= \ +-fmacro-prefix-map=WORKDIR/recipe-sysroot= \ +-fdebug-prefix-map=WORKDIR/recipe-sysroot-native= \ +-pipe \ +-fvisibility-inlines-hidden \ +aarch64-oe-linux-g++ \ +-fstack-protector-all \ +-O2 \ +-D_FORTIFY_SOURCE=2 \ +-Wformat \ +-Wformat-security \ +-Werror=format-security \ +-Werror=return-type \ +-funwind-tables \ +--sysroot=WORKDIR/recipe-sysroot \ -shared \ -Wl,-O1 \ -Wl,--hash-style=gnu \ @@ -33,6 +55,7 @@ -fmacro-prefix-map=WORKDIR/recipe-sysroot= \ -fdebug-prefix-map=WORKDIR/recipe-sysroot-native= \ -pipe \ +-fvisibility-inlines-hidden \ build/temp.linux-x86_64-cpython-312/build/src.linux-x86_64-3.12/numpy/core/src/multiarray/_multiarray_tests.o \ build/temp.linux-x86_64-cpython-312/numpy/core/src/common/mem_overlap.o \ build/temp.linux-x86_64-cpython-312/numpy/core/src/common/npy_argparse.o \ failing with: WORKDIR/recipe-sysroot-native/usr/bin/aarch64-oe-linux/../../libexec/aarch64-oe-linux/gcc/aarch64-oe-linux/14.2.0/ld: cannot find aarch64-oe-linux-g++: No such file or directory collect2: error: ld returned 1 exit status On Tue, Aug 20, 2024 at 8:52 AM wangmy via lists.openembedded.org wrote: > > From: Wang Mingyu > > Changelog: > - Support for Pathlike objects in data files and extensions > - native support for C++ compilers > - removed unused get_msvcr() > > Signed-off-by: Wang Mingyu > --- > ...ython3-setuptools_72.1.0.bb => python3-setuptools_72.2.0.bb} | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > rename meta/recipes-devtools/py
[OE-core] [PATCH] populate_sdk_base: inherit nopackages
Since this bbclass sets PACKAGES = "", inherit the nopackages
class to skip the various packaging functions which wouldn't
do anything anyway.
This fixes errors from buildhistory changes where packages-split would be empty.
e.g. meta-toolchain build now fails with:
| DEBUG: Executing shell function buildhistory_list_pkg_files
| find: ".../meta-toolchain/1.0/packages-split/*": No such file or directory
| WARNING: exit code 1 from a shell command.
| DEBUG: Python function buildhistory_emit_pkghistory finished
Signed-off-by: Martin Jansa
---
meta/classes-recipe/populate_sdk_base.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes-recipe/populate_sdk_base.bbclass
b/meta/classes-recipe/populate_sdk_base.bbclass
index 2f6e7b4076..16013d5872 100644
--- a/meta/classes-recipe/populate_sdk_base.bbclass
+++ b/meta/classes-recipe/populate_sdk_base.bbclass
@@ -13,7 +13,7 @@ PACKAGES = ""
# SDK processing context. This class happens to be common to these usages.
SPDX_MULTILIB_SSTATE_ARCHS = "${@all_multilib_tune_values(d, 'SSTATE_ARCHS')}"
-inherit image-postinst-intercepts image-artifact-names
+inherit image-postinst-intercepts image-artifact-names nopackages
# Wildcards specifying complementary packages to install for every package
that has been explicitly
# installed into the rootfs
--
2.46.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#203474):
https://lists.openembedded.org/g/openembedded-core/message/203474
Mute This Topic: https://lists.openembedded.org/mt/107938615/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] meta-world-pkgdata: Inherit nopackages
Since this is a recipe with PACKAGES = "", inherit the nopackages
class to skip the various packaging functions which wouldn't do anything anyway.
This fixes errors from buildhistory changes where packages-split would be empty.
Signed-off-by: Martin Jansa
---
meta/recipes-core/meta/meta-world-pkgdata.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-core/meta/meta-world-pkgdata.bb
b/meta/recipes-core/meta/meta-world-pkgdata.bb
index 244175ddd4..1bfaf2c1e3 100644
--- a/meta/recipes-core/meta/meta-world-pkgdata.bb
+++ b/meta/recipes-core/meta/meta-world-pkgdata.bb
@@ -27,7 +27,7 @@ python do_collect_packagedata() {
oe.copy_buildsystem.generate_locked_sigs(sigfile, d)
}
-inherit nospdx
+inherit nospdx nopackages
deltask do_fetch
deltask do_unpack
deltask do_patch
--
2.46.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#203338):
https://lists.openembedded.org/g/openembedded-core/message/203338
Mute This Topic: https://lists.openembedded.org/mt/107913551/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [scarthgap][master][PATCH] python3: provide /usr/bin/python as a symlink to python3
Doesn't https://peps.python.org/pep-0394/ recommend the current status quo anyway? Distributors may choose to set the behavior of the python command as follows: python2, python3, not provide python command, allow python to be configurable by an end user or a system administrator. When packaging third party Python scripts, distributors are encouraged to change less specific shebangs to more specific ones. This ensures software is used with the latest version of Python available, and it can remove a dependency on Python 2. The details on what specifics to set are left to the distributors; though. Example specifics could include: Changing python shebangs to python3 when Python 3.x is supported. Changing python shebangs to python2 when Python 3.x is not yet supported. Changing python3 shebangs to python3.8 if the software is built with Python 3.8. My preference would be to keep it as is and not merge this change as RP said. If we drop the patches then we go against the recommendation to use more specific shebangs and if we don't drop them then python-is-python3 recipes or package shouldn't be needed. Cheers, On Wed, Jul 24, 2024 at 6:18 PM Alexander Kanavin via lists.openembedded.org wrote: > > On Wed, 24 Jul 2024 at 18:01, Richard Purdie > wrote: > > > Having listened to the discussions and given this is pretty much a > > solved problem for the majority of our current metadata, I'm in favour > > of maintaining the status quo and not taking this change, even if we > > have to carry a few patches. It does at least make the situation quite > > clear and explicit. > > I'm fine with this. We have significantly bigger issues in oe-core > (e.g. the rust situation where the slide behind upstream is constantly > growing). > > I think the really correct solution is a coordinated effort by common > distributions to convince python upstream to add the symlink directly > in cpython installation. Or make an official statement that it is not > going to happen, which would explicitly mean that scripts *have* to be > written with python3 shebang. > > Alex > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#202468): https://lists.openembedded.org/g/openembedded-core/message/202468 Mute This Topic: https://lists.openembedded.org/mt/107264938/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] kernel.bbclass: add original package name to RPROVIDES for -image and -base
* -image and -base change PKG to:
PKG:${KERNEL_PACKAGE_NAME}-image =
"${KERNEL_PACKAGE_NAME}-image-${@legitimize_package_name(d.getVar(KERNEL_VERSION))}"
PKG:${KERNEL_PACKAGE_NAME}-base =
"${KERNEL_PACKAGE_NAME}-${@legitimize_package_name(d.getVar(KERNEL_VERSION))}"
* but only when debian.bbclass is inheritted they add the original package name
into RPROVIDES by:
https://git.openembedded.org/openembedded-core/commit/?id=3409c4379559afbb1d1d29045582995147a33bbc
* fixes the build if some packagegroup or something RDEPENDS on kernel-image or
kernel-base
and the DISTRO doesn't inherit debian.bbclass
* as shown in pkgdata:
linux-raspberrypi $ egrep "^(PKG:)|(RPRO)"
6.6.36+git-*/pkgdata/runtime/kernel-image
6.6.36+git-debian/pkgdata/runtime/kernel-image:RPROVIDES:kernel-image:
kernel-image (=6.6.36+git@PRSERV_PV_AUTOINC@+733366844f_769634f344)
6.6.36+git-debian/pkgdata/runtime/kernel-image:PKG:kernel-image:
kernel-image-6.6.36-v8
6.6.36+git-without-debian/pkgdata/runtime/kernel-image:PKG:kernel-image:
kernel-image-6.6.36-v8
linux-raspberrypi $ egrep "^(PKG:)|(RPRO)"
6.6.36+git-*/pkgdata/runtime/kernel-image-image
6.6.36+git-debian/pkgdata/runtime/kernel-image-image:RPROVIDES:kernel-image-image:
kernel-image-image (=6.6.36+git@PRSERV_PV_AUTOINC@+733366844f_769634f344)
6.6.36+git-debian/pkgdata/runtime/kernel-image-image:PKG:kernel-image-image:
kernel-image-image-6.6.36-v8
6.6.36+git-without-debian/pkgdata/runtime/kernel-image-image:PKG:kernel-image-image:
kernel-image-image-6.6.36-v8
Signed-off-by: Martin Jansa
---
meta/classes-recipe/kernel.bbclass | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/classes-recipe/kernel.bbclass
b/meta/classes-recipe/kernel.bbclass
index 2a4f3defda..4464155b73 100644
--- a/meta/classes-recipe/kernel.bbclass
+++ b/meta/classes-recipe/kernel.bbclass
@@ -720,9 +720,10 @@ RDEPENDS:${KERNEL_PACKAGE_NAME} =
"${KERNEL_PACKAGE_NAME}-base (= ${EXTENDPKGV})
# not wanted in images as standard
RRECOMMENDS:${KERNEL_PACKAGE_NAME}-base ?= "${KERNEL_PACKAGE_NAME}-image (=
${EXTENDPKGV})"
PKG:${KERNEL_PACKAGE_NAME}-image =
"${KERNEL_PACKAGE_NAME}-image-${@legitimize_package_name(d.getVar('KERNEL_VERSION'))}"
+RPROVIDES:${KERNEL_PACKAGE_NAME}-image += "${KERNEL_PACKAGE_NAME}-image"
RDEPENDS:${KERNEL_PACKAGE_NAME}-image +=
"${@oe.utils.conditional('KERNEL_IMAGETYPE', 'vmlinux',
'${KERNEL_PACKAGE_NAME}-vmlinux (= ${EXTENDPKGV})', '', d)}"
PKG:${KERNEL_PACKAGE_NAME}-base =
"${KERNEL_PACKAGE_NAME}-${@legitimize_package_name(d.getVar('KERNEL_VERSION'))}"
-RPROVIDES:${KERNEL_PACKAGE_NAME}-base +=
"${KERNEL_PACKAGE_NAME}-${KERNEL_VERSION}"
+RPROVIDES:${KERNEL_PACKAGE_NAME}-base +=
"${KERNEL_PACKAGE_NAME}-${KERNEL_VERSION} ${KERNEL_PACKAGE_NAME}-base"
ALLOW_EMPTY:${KERNEL_PACKAGE_NAME} = "1"
ALLOW_EMPTY:${KERNEL_PACKAGE_NAME}-base = "1"
ALLOW_EMPTY:${KERNEL_PACKAGE_NAME}-image = "1"
--
2.45.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#202309):
https://lists.openembedded.org/g/openembedded-core/message/202309
Mute This Topic: https://lists.openembedded.org/mt/107481555/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] gstreamer1.0-plugins-bad: add PACKAGECONFIG for gtk3
* gtkwaylandsink was added in 1.21.1 version: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1515 * gtk3+ could be autodetected (e.g. as transitive dependency from opencv) Signed-off-by: Martin Jansa --- .../gstreamer/gstreamer1.0-plugins-bad_1.24.5.bb | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.24.5.bb b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.24.5.bb index e549728c20..6766a8c19a 100644 --- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.24.5.bb +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.24.5.bb @@ -46,6 +46,7 @@ PACKAGECONFIG[dtls]= "-Ddtls=enabled,-Ddtls=disabled,openssl" PACKAGECONFIG[faac]= "-Dfaac=enabled,-Dfaac=disabled,faac" PACKAGECONFIG[faad]= "-Dfaad=enabled,-Dfaad=disabled,faad2" PACKAGECONFIG[fluidsynth] = "-Dfluidsynth=enabled,-Dfluidsynth=disabled,fluidsynth" +PACKAGECONFIG[gtk3]= "-Dgtk3=enabled,-Dgtk3=disabled,gtk3+" PACKAGECONFIG[hls] = "-Dhls=enabled,-Dhls=disabled," # Pick atleast one crypto backend below when enabling hls PACKAGECONFIG[nettle] = "-Dhls-crypto=nettle,,nettle" -- 2.45.2 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#202235): https://lists.openembedded.org/g/openembedded-core/message/202235 Mute This Topic: https://lists.openembedded.org/mt/107421959/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 0/6] Use the kernel from sstate when building fitImages
On Thu, Jul 18, 2024 at 2:37 PM Adrian Freihofer wrote: > > On Thu, 2024-07-18 at 10:39 +0200, Martin Jansa wrote: > > On Thu, Jul 18, 2024 at 10:00 AM Adrian Freihofer > > wrote: > > > > > > Hi Martin > > > > > > Thank you for looking at my patches. > > > > > > On Mon, 2024-07-15 at 16:32 +0200, Martin Jansa wrote: > > > > Doesn't it still rebuild from scratch when IMAGE_VERSION_SUFFIX > > > > changes? > > > > > > I wonder why this happens in WebOS. I think that this line > > > kernel_do_deploy[vardepsexclude] = "DATETIME" > > > prevents such unnecessary rebuilds. > > > > Hi Adrian, > > > > yes DATETIME is excluded by default, but it's useful to use different > > suffix in IMAGE_VERSION_SUFFIX (e.g. BUILD_NUMBER from CI on jenkins > > or release version when building release) and in such cases you don't > > want to vardepexclude it, because it's useful to produce matching > > version in images as well as kernel (and other artifacts you might > > have), so your 1.2.1 release images doesn't end with 1.2.0 kernel > > artifacts just because kernel sstate signature didn't change in 1.2.1 > > bugfix release. > > > > Does this make sense? I bet it would happen in your builds as well. > > I try to optimize everything towards binary-reproducible builds. This > means that we remove all kinds of variables that change because the > time changes or because the CI build ID changes or something like that. > I see no benefit in compiling such information into the firmware. > But the problem I see is that such ideas clash with efficient and > binary-reproducible builds. > > That means that I don't see a reason for changing the > IMAGE_VERSION_SUFFIX variable in such a way. > > > > > Whole point of: > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=12937 > > is to allow "renaming" (adding more hardlinks) artifacts with > > matching > > IMAGE_VERSION_SUFFIX without the need of rebuilding anything (e.g. > > version-less kernel artifacts are re-used from sstate and then only > > quick deploy-links task is executed to add right versioned hardlinks > > in deploy directory.) > > > > Well, yes, it would. But, I am confident that it is a better strategy > to simply not do this than to support it. > > If such non-reproducible information is needed anyway, it can be > archived independently of Bitbake. Well the changes from: https://bugzilla.yoctoproject.org/show_bug.cgi?id=12937 make the builds _more_ reproducible, because they move the DATETIME or whatever IMAGE_VERSION_SUFFIX out of the artifacts in sstate and move creating versioned names to separate task which can be disabled (by setting IMAGE_VERSION_SUFFIX to empty if you prefer not to create them). -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#202212): https://lists.openembedded.org/g/openembedded-core/message/202212 Mute This Topic: https://lists.openembedded.org/mt/107231736/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 0/6] Use the kernel from sstate when building fitImages
On Thu, Jul 18, 2024 at 10:00 AM Adrian Freihofer wrote: > > Hi Martin > > Thank you for looking at my patches. > > On Mon, 2024-07-15 at 16:32 +0200, Martin Jansa wrote: > > Doesn't it still rebuild from scratch when IMAGE_VERSION_SUFFIX > > changes? > > I wonder why this happens in WebOS. I think that this line > kernel_do_deploy[vardepsexclude] = "DATETIME" > prevents such unnecessary rebuilds. Hi Adrian, yes DATETIME is excluded by default, but it's useful to use different suffix in IMAGE_VERSION_SUFFIX (e.g. BUILD_NUMBER from CI on jenkins or release version when building release) and in such cases you don't want to vardepexclude it, because it's useful to produce matching version in images as well as kernel (and other artifacts you might have), so your 1.2.1 release images doesn't end with 1.2.0 kernel artifacts just because kernel sstate signature didn't change in 1.2.1 bugfix release. Does this make sense? I bet it would happen in your builds as well. Whole point of: https://bugzilla.yoctoproject.org/show_bug.cgi?id=12937 is to allow "renaming" (adding more hardlinks) artifacts with matching IMAGE_VERSION_SUFFIX without the need of rebuilding anything (e.g. version-less kernel artifacts are re-used from sstate and then only quick deploy-links task is executed to add right versioned hardlinks in deploy directory.) Cheers, > So far we haven't had any problems with rebuilding kernels. The trouble > started when we started using fitImages with initramfs for some > devices. It is also worth noting that we build from sstate, but with an > empty TMPDIR. > > In such a scenario bitbake does: > > * The initramfs gets assembled. This is expected because images are >not sstate cached. This runs quickly because all the packages which >are required to build the initramfs come from sstate-cache. > * Since the initramfs changes, the fitImage which includes it must be >re-assembled as well. > * Now the hassle starts: The do_assemble_fitimage_initramfs needs the >kernel binaries (linux.bin, DTBs...) which are not available from >sttate. Bitbake has to start with kernel do_fetch in case of an >empty TMPDIR just to get the fitImage assembled. > > With my patches the kernel binaries used for the fitImage come from > sstate (if the initramfs is not bundled). > > I tested this like that: > > cat build/conf/local.conf > > KERNEL_IMAGETYPE = "Image" > KERNEL_IMAGETYPES += " fitImage " > KERNEL_CLASSES = " kernel-fitimage "and RAM disk > IMAGE_FSTYPES += "cpio.gz" > INITRAMFS_IMAGE = "core-image-minimal" > IMAGE_NAME_SUFFIX:pn-core-image-minimal = "" > UBOOT_RD_LOADADDRESS = "0x8800" > UBOOT_RD_ENTRYPOINT = "0x8800" > UBOOT_LOADADDRESS = "0x8008" > UBOOT_ENTRYPOINT = "0x8008" > FIT_DESC = "A model description" > > # Allow to change the initramfs > FOO_VAR = "1" > INHERIT += "image-buildinfo" > IMAGE_BUILDINFO_VARS:append = " FOO_VAR" > > > bitbake virtual/kernel > > mv build/tmp build/tmp-old-1 > > bitbake virtual/kernel > -> bitbake does: > - setscene tasks > - core-image-minimal do_rootfs ... > - kernel do_deploy (from sstate) > - kernel do_deploy_fitimage_unbundled > > > bitbake virtual/kernel > -> bitbake does: nothing > > > # Enforce a re-build of the initramfs > mv build/tmp build/tmp-old-2 > echo 'FOO_VAR = "1"' >> build/conf/local.conf > > bitbake virtual/kernel > -> bitbake does: > - setscene tasks > - core-image-minimal do_rootfs ... > - kernel do_deploy (from sstate) > - kernel do_deploy_fitimage_unbundled > > > bitbake virtual/kernel > -> bitbake does: nothing > > > diff \ > <(ls build/tmp-old-2/deploy/images/qemux86-64 -1) \ > <(ls build/tmp/deploy/images/qemux86-64/ -1) > 4,10c4,10 > < core-image-minimal-qemux86-64-20240718065105.cpio.gz > < core-image-minimal-qemux86-64-20240718065105.ext4 > < core-image-minimal-qemux86-64-20240718065105.manifest > < core-image-minimal-qemux86-64-20240718065105.qemuboot.conf > < core-image-minimal-qemux86-64-20240718065105.spdx.tar.zst > < core-image-minimal-qemux86-64-20240718065105.tar.bz2 > < core-image-minimal-qemux86-64-20240718065105.testdata.json > --- > > core-image-minimal-qemux86-64-20240718073341.cpio.gz > > core-image-minimal-qemux86-64-20240718073341.ext4 > > core-image-minimal-qemux86-64-20240718073341.manifest > > core-image-minimal-qemux86-64-20240718073341.qemuboot.conf > > core-image-minimal-qemux86-64-20240718073341.spdx.tar.zs
Re: [OE-core] [PATCH v2 0/6] Use the kernel from sstate when building fitImages
Doesn't it still rebuild from scratch when IMAGE_VERSION_SUFFIX changes? To be able to re-use the kernel from sstate even when IMAGE_VERSION_SUFFIX changes I've implemented: https://bugzilla.yoctoproject.org/show_bug.cgi?id=12937 which was unfortunately rejected due to lack of interest from other people outside LGE, but maybe you could take advantage of that as well. On Mon, Jul 15, 2024 at 4:22 PM Adrian Freihofer via lists.openembedded.org wrote: > > Task dependeny changes > > Configuration: image, fitimage, initramfs, unbundled > > KERNEL_IMAGETYPE = "Image" > KERNEL_IMAGETYPES += " fitImage " > KERNEL_CLASSES = " kernel-fitimage " > IMAGE_FSTYPES += "cpio.gz" > INITRAMFS_IMAGE = "core-image-minimal-initramfs" > > branch: master > > core-image-minimal.do_build do_deploy do_assemble_fitimage_initramfs > do_bundle_initramfs do_populate_sysroot do_assemble_fitimage do_compile > do_kernel_generate_rsa_keys core-image-minimal.do_image_complete do_install > > branch: adrianf/kernel-fitimage-sstate > > core-image-minimal.do_build do_deploy do_deploy_fitimage_unbundled > core-image-minimal.do_image_complete do_install do_populate_sysroot > do_assemble_fitimage do_compile do_kernel_generate_rsa_keys > > Diff > > 2a3 > > "core-image-minimal.do_build" -> "do_deploy_fitimage_unbundled" > 6,11d6 > < "do_assemble_fitimage_initramfs" [label="do_assemble_fitimage_initramfs"] > < "do_assemble_fitimage_initramfs" -> "core-image-minimal.do_image_complete" > < "do_assemble_fitimage_initramfs" -> "do_bundle_initramfs" > < "do_bundle_initramfs" [label="do_bundle_initramfs"] > < "do_bundle_initramfs" -> "core-image-minimal.do_image_complete" > < "do_bundle_initramfs" -> "do_install" > 14,15c9,10 > < "do_deploy" -> "do_assemble_fitimage_initramfs" > < "do_deploy" -> "do_bundle_initramfs" > --- > > "do_deploy" -> "core-image-minimal.do_image_complete" > > "do_deploy" -> "do_install" > 16a12,14 > > "do_deploy_fitimage_unbundled" [label="do_deploy_fitimage_unbundled"] > > "do_deploy_fitimage_unbundled" -> "core-image-minimal.do_image_complete" > > "do_deploy_fitimage_unbundled" -> "do_deploy" > > Configuration: fitimage, initramfs, unbundled > > KERNEL_IMAGETYPE:forcevariable = "fitImage" > KERNEL_CLASSES = " kernel-fitimage " > IMAGE_FSTYPES += "cpio.gz" > INITRAMFS_IMAGE = "core-image-minimal-initramfs" > > branch: master > > core-image-minimal.do_build do_deploy do_assemble_fitimage_initramfs > do_bundle_initramfs do_populate_sysroot do_assemble_fitimage do_compile > do_kernel_generate_rsa_keys core-image-minimal.do_image_complete do_install > > branch: adrianf/kernel-fitimage-sstate > > core-image-minimal.do_build do_deploy do_deploy_fitimage_unbundled > core-image-minimal.do_image_complete do_install do_populate_sysroot > do_assemble_fitimage do_compile do_kernel_generate_rsa_keys > > Diff > > 2a3 > > "core-image-minimal.do_build" -> "do_deploy_fitimage_unbundled" > 6,11d6 > < "do_assemble_fitimage_initramfs" [label="do_assemble_fitimage_initramfs"] > < "do_assemble_fitimage_initramfs" -> "core-image-minimal.do_image_complete" > < "do_assemble_fitimage_initramfs" -> "do_bundle_initramfs" > < "do_bundle_initramfs" [label="do_bundle_initramfs"] > < "do_bundle_initramfs" -> "core-image-minimal.do_image_complete" > < "do_bundle_initramfs" -> "do_install" > 14,15c9,10 > < "do_deploy" -> "do_assemble_fitimage_initramfs" > < "do_deploy" -> "do_bundle_initramfs" > --- > > "do_deploy" -> "core-image-minimal.do_image_complete" > > "do_deploy" -> "do_install" > 16a12,14 > > "do_deploy_fitimage_unbundled" [label="do_deploy_fitimage_unbundled"] > > "do_deploy_fitimage_unbundled" -> "core-image-minimal.do_image_complete" > > "do_deploy_fitimage_unbundled" -> "do_deploy" > > Configuration: image, fitimage, initramfs, bundled > > KERNEL_IMAGETYPE = "Image" > KERNEL_IMAGETYPES += " fitImage " > KERNEL_CLASSES = " kernel-fitimage " > IMAGE_FSTYPES += "cpio.gz" > INITRAMFS_IMAGE = "core-image-minimal-initramfs" > INITRAMFS_IMAGE_BUNDLE = "1" > > branch: master > > core-image-minimal.do_build do_deploy do_assemble_fitimage_initramfs > do_bundle_initramfs do_populate_sysroot do_transform_bundled_initramfs > do_assemble_fitimage do_compile do_kernel_generate_rsa_keys > core-image-minimal.do_image_complete do_install > > branch: adrianf/kernel-fitimage-sstate > > core-image-minimal.do_build do_deploy do_assemble_fitimage_initramfs > do_bundle_initramfs do_populate_sysroot do_transform_bundled_initramfs > do_assemble_fitimage do_compile do_kernel_generate_rsa_keys > core-image-minimal.do_image_complete do_install > > Diff > > Configuration: image, fitimage > > KERNEL_IMAGETYPE = "Image" > KERNEL_IMAGETYPES += " fitImage " > KERNEL_CLASSES = " kernel-fitimage " > > branch: master > > core-image-minimal.do_build do_deploy do_assemble_fitimage_initramfs > do_bundle_initramfs do_populate_sysroot do_assemble_fitimage do_compile > do_kernel_generate_rsa_keys core-image-minimal.do_image_complete do_install > > branch: adrianf/kernel-fit
Re: [OE-core] [PATCH v3 1/1] gfortran: update runtime dependencies
Hi Kai,
are you also seeing these buildpaths warnings from libgfortran? These
will be fatal since ERROR_QA update from yesterday:
https://git.openembedded.org/openembedded-core/commit/?id=b79b191cc43a45dde2adb61ea349b426cb2461d1
and it probably wasn't detected in AB builds which might not enable fortran.
Regards,
On Mon, Jun 24, 2024 at 12:12 PM Kai wrote:
>
> On 6/19/24 23:00, Martin Jansa wrote:
> > See https://lists.openembedded.org/g/openembedded-core/message/200915
> > which allows to me to build nativesdk-gcc again.
>
> Thanks for your fix.
>
> Regards,
> Kai
>
> >
> > I've built nativesdk-libgfortran and libgfortran with the patch, but
> > haven't used fortran in runtime at all, that's why it's an RFC, there
> > were also 2 warnings:
> > WARNING: nativesdk-libgfortran-14.1.0-r0 do_package_qa: QA Issue: File
> > /opt/.../usr/lib/.debug/libgfortran.so.5.0.0 in package
> > nativesdk-libgfortran-dbg contains reference to TMPDIR [buildpaths]
> > WARNING: libgfortran-14.1.0-r0 do_package_qa: QA Issue: File
> > /usr/lib/.debug/libgfortran.so.5.0.0 in package libgfortran-dbg
> > contains reference to TMPDIR [buildpaths]
> > which I guess were already there.
> >
> > On Wed, Jun 19, 2024 at 3:24 PM Martin Jansa via
> > lists.openembedded.org
> > wrote:
> >> Something seems wrong with this change which was merged today, now with:
> >> MACHINE=qemuarm64
> >> FORTRAN:forcevariable = ",fortran"
> >>
> >> I'm seeing:
> >> build/oe-core $ bitbake -g nativesdk-libgfortran
> >> NOTE: Resolving any missing task queue dependencies
> >> ERROR: Nothing PROVIDES 'gcc-cross-x86_64' (but
> >> virtual:nativesdk:/OE/build/oe-core/openembedded-core/meta/recipes-devtools/gcc/libgfortran_14.1.bb
> >> DEPENDS on or otherwise requires it). Close matches:
> >>gcc-cross-aarch64
> >> ...
> >>
> >> This might have been broken even before this change, but now it got
> >> included in dependency tree of nativesdk-gcc (as shown in bitbake -g
> >> nativesdk-gcc now failing when host and target arch don't match):
> >>
> >> "nativesdk-gcc.do_package_qa" -> "nativesdk-libgfortran.do_packagedata"
> >> nativesdk-gcc.do_package_write_ipk" ->
> >> "nativesdk-libgfortran.do_packagedata"
> >>
> >> Missing or unbuildable dependency chain was: ['image',
> >> 'nativesdk-packagegroup-sdk-host', 'nativesdk-lcov',
> >> 'nativesdk-gcov-symlinks', 'nativesdk-libgfortran-dev',
> >> 'gcc-cross-x86_64']
> >>
> >> I guess the easiest fix would be in:
> >> meta/recipes-devtools/gcc/libgfortran.inc:DEPENDS = "gcc-runtime
> >> gcc-cross-${TARGET_ARCH}"
> >> but I'm not very familiar with fortran (we've enabled it long time ago
> >> to build lapack(blas) for snowboy, but wasn't actively used for couple
> >> years).
> >>
> >> Regards,
> >>
> >>
> >>
> >> On Sun, Jun 16, 2024 at 5:32 PM Kai Kang via lists.openembedded.org
> >> wrote:
> >>> From: Kai Kang
> >>>
> >>> It fails to run both `gcc` and `gfortran` with errors:
> >>>
> >>> | root@qemux86-64:~# x86_64-poky-linux-gcc a.c
> >>> | x86_64-poky-linux-gcc: fatal error: cannot execute 'as': posix_spawnp:
> >>> No such file or directory
> >>>
> >>> then add binutils which provides `as` to RDEPENDS of gcc.
> >>>
> >>> libgfortran-dev provides libgfortran.spec which required by gfortran:
> >>>
> >>> | root@qemux86-64:~# gfortran hello.f95
> >>> | gfortran: fatal error: cannot read spec file 'libgfortran.spec': No
> >>> such file or directory
> >>>
> >>> And gcc provides liblto_plugin.so:
> >>>
> >>> | root@qemux86-64:~# gfortran hello.f95
> >>> | gfortran: fatal error: '-fuse-linker-plugin', but liblto_plugin.so not
> >>> found
> >>>
> >>> Signed-off-by: Kai Kang
> >>> ---
> >>> meta/recipes-devtools/gcc/gcc-target.inc | 9 +++--
> >>> 1 file changed, 7 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/meta/recipes-devtools/gcc/gcc-target.inc
> >>> b/meta/recipes-devtools/gcc/gcc-target.inc
> >>> index 8e9693b4cb..e9187fc444 100644
Re: [OE-core] [PATCH] hdparm: drop NO_GENERIC_LICENSE
see:
https://lists.openembedded.org/g/openembedded-core/message/201631
which is already in master-next:
https://git.openembedded.org/openembedded-core/commit/?h=master-next&id=129d2df6bb963bf33da3656ceb6ca5b03cd80383
On Wed, Jul 10, 2024 at 2:02 AM Denys Dmytriyenko via
lists.openembedded.org wrote:
>
> Latest SPDX update[1] brought in a generic hdparm license, no need
> to set NO_GENERIC_LICENSE any more.
>
> [1]
> https://git.openembedded.org/openembedded-core/commit/?id=e9c1f48af10ccb58251ecc7e041babb99b94d6df
>
> Signed-off-by: Denys Dmytriyenko
> ---
> meta/recipes-extended/hdparm/hdparm_9.65.bb | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/meta/recipes-extended/hdparm/hdparm_9.65.bb
> b/meta/recipes-extended/hdparm/hdparm_9.65.bb
> index d5e6ab6065a..1b6af566a29 100644
> --- a/meta/recipes-extended/hdparm/hdparm_9.65.bb
> +++ b/meta/recipes-extended/hdparm/hdparm_9.65.bb
> @@ -8,7 +8,6 @@ LICENSE = "BSD-2-Clause & GPL-2.0-only & hdparm"
> LICENSE:${PN} = "BSD-2-Clause & hdparm"
> LICENSE:${PN}-dbg = "BSD-2-Clause & hdparm"
> LICENSE:wiper = "GPL-2.0-only"
> -NO_GENERIC_LICENSE[hdparm] = "LICENSE.TXT"
>
> LIC_FILES_CHKSUM = "file://LICENSE.TXT;md5=495d03e50dc6c89d6a30107ab0df5b03 \
>
> file://debian/copyright;md5=a82d7ba3ade9e8ec902749db98c592f3 \
> --
> 2.35.3
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#201687):
https://lists.openembedded.org/g/openembedded-core/message/201687
Mute This Topic: https://lists.openembedded.org/mt/107133678/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] hdparm: drop NO_GENERIC_LICENSE[hdparm]
* the hdparm license text was added in:
https://git.openembedded.org/openembedded-core/commit/?id=e9c1f48af10ccb58251ecc7e041babb99b94d6df
and now the NO_GENERIC_LICENSE was causing:
ERROR: hdparm-9.65-r0 do_populate_lic: QA Issue: hdparm: hdparm is a generic
license, please don't use NO_GENERIC_LICENSE for it. [license-no-generic]
Signed-off-by: Martin Jansa
---
meta/recipes-extended/hdparm/hdparm_9.65.bb | 1 -
1 file changed, 1 deletion(-)
diff --git a/meta/recipes-extended/hdparm/hdparm_9.65.bb
b/meta/recipes-extended/hdparm/hdparm_9.65.bb
index d5e6ab6065..1b6af566a2 100644
--- a/meta/recipes-extended/hdparm/hdparm_9.65.bb
+++ b/meta/recipes-extended/hdparm/hdparm_9.65.bb
@@ -8,7 +8,6 @@ LICENSE = "BSD-2-Clause & GPL-2.0-only & hdparm"
LICENSE:${PN} = "BSD-2-Clause & hdparm"
LICENSE:${PN}-dbg = "BSD-2-Clause & hdparm"
LICENSE:wiper = "GPL-2.0-only"
-NO_GENERIC_LICENSE[hdparm] = "LICENSE.TXT"
LIC_FILES_CHKSUM = "file://LICENSE.TXT;md5=495d03e50dc6c89d6a30107ab0df5b03 \
file://debian/copyright;md5=a82d7ba3ade9e8ec902749db98c592f3 \
--
2.45.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#201631):
https://lists.openembedded.org/g/openembedded-core/message/201631
Mute This Topic: https://lists.openembedded.org/mt/107099199/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 0/2] Update to latest version of SPDX licenses
Doesn't this cause:
ERROR: hdparm-9.65-r0 do_populate_lic: QA Issue: hdparm: hdparm is a
generic license, please don't use NO_GENERIC_LICENSE for it.
[license-no-generic]
?
On Mon, Jul 1, 2024 at 4:33 PM Joshua Watt via lists.openembedded.org
wrote:
>
> Ah, right, I should have known that would happen. I'll send the fix
>
> On Mon, Jul 1, 2024 at 12:56 AM Richard Purdie
> wrote:
> >
> > On Thu, 2024-06-27 at 16:16 -0600, Joshua Watt via lists.openembedded.org
> > wrote:
> > > Adds a script to read the released SPDX license JSON data, and uses it
> > > to update the common license files
> > >
> > > Joshua Watt (2):
> > > scripts/pull-spdx-licenses.py: Add script
> > > licenses: Update to SPDX license version 3.24.0
> >
> > Thanks for doing this. It does seem to upset one of the selftests:
> >
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/80/builds/6871
> >
> > 2024-06-30 21:07:48,909 - oe-selftest - INFO -
> > ==
> > 2024-06-30 21:07:48,966 - oe-selftest - INFO - FAIL:
> > spdx.SPDXCheck.test_spdx_base_files (subunit.RemotedTestCase)
> > 2024-06-30 21:07:48,966 - oe-selftest - INFO -
> > --
> > 2024-06-30 21:07:48,980 - oe-selftest - INFO -
> > testtools.testresult.real._StringException: Traceback (most recent call
> > last):
> > File
> > "/home/pokybuild/yocto-worker/oe-selftest-debian/build/meta/lib/oeqa/selftest/cases/spdx.py",
> > line 55, in test_spdx_base_files
> > self.check_recipe_spdx("packages", "base-files.spdx.json", "base-files")
> > File
> > "/home/pokybuild/yocto-worker/oe-selftest-debian/build/meta/lib/oeqa/selftest/cases/spdx.py",
> > line 52, in check_recipe_spdx
> > result = check_spdx_json(full_file_path)
> > ^^^
> > File
> > "/home/pokybuild/yocto-worker/oe-selftest-debian/build/meta/lib/oeqa/selftest/cases/spdx.py",
> > line 49, in check_spdx_json
> > result = runCmd("{} {} -i {}".format(python, validator, filename))
> > ^
> > File
> > "/home/pokybuild/yocto-worker/oe-selftest-debian/build/meta/lib/oeqa/utils/commands.py",
> > line 212, in runCmd
> > raise AssertionError("Command '%s' returned non-zero exit status
> > %d:\n%s" % (command, result.status, exc_output))
> > AssertionError: Command
> > '/home/pokybuild/yocto-worker/oe-selftest-debian/build/build-st-296488/tmp/work/x86_64-linux/python3-spdx-tools-native/0.8.2/recipe-sysroot-native/usr/bin/nativepython3
> >
> > /home/pokybuild/yocto-worker/oe-selftest-debian/build/build-st-296488/tmp/work/x86_64-linux/python3-spdx-tools-native/0.8.2/recipe-sysroot-native/usr/bin/pyspdxtools
> > -i
> > /home/pokybuild/yocto-worker/oe-selftest-debian/build/build-st-296488/tmp/deploy/spdx/2.2/qemux86_64/packages/base-files.spdx.json'
> > returned non-zero exit status 1:
> > ERROR:root:There have been issues while parsing the provided document:
> > Error while parsing Document: ['Error while parsing version 3.24.0: 3.24.0
> > is not a valid version string']
> >
> > It is coming from here:
> >
> > https://github.com/spdx/tools-python/blob/main/src/spdx_tools/spdx/model/version.py
> >
> > in spdx-tools :/.
> >
> > Cheers,
> >
> > Richard
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#201630):
https://lists.openembedded.org/g/openembedded-core/message/201630
Mute This Topic: https://lists.openembedded.org/mt/106918424/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] os-release: Fix VERSION_CODENAME in case it is empty
If you want to set VERSION_CODENAME to empty you can just add:
DISTRO_CODENAME ??= ""
to make sure it's always expanded to at least empty string.
On Thu, Jun 20, 2024 at 3:04 PM Daniel Semkowicz via
lists.openembedded.org
wrote:
>
> If DISTRO_CODENAME was not set, VERSION_CODENAME field was populated
> with unparsed string. This resulted in the following line in os-release
> file:
>
> VERSION_CODENAME="${DISTRO_CODENAME}"
>
> According to systemd documentation, this field is optional.
> Fix the problem by setting VERSION_CODENAME conditionally, only if
> DISTRO_CODENAME was set.
>
> Signed-off-by: Daniel Semkowicz
> ---
> meta/recipes-core/os-release/os-release.bb | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-core/os-release/os-release.bb
> b/meta/recipes-core/os-release/os-release.bb
> index 8906906bc3..93af08c182 100644
> --- a/meta/recipes-core/os-release/os-release.bb
> +++ b/meta/recipes-core/os-release/os-release.bb
> @@ -24,7 +24,7 @@ ID = "${DISTRO}"
> NAME = "${DISTRO_NAME}"
> VERSION = "${DISTRO_VERSION}${@' (%s)' % DISTRO_CODENAME if
> 'DISTRO_CODENAME' in d else ''}"
> VERSION_ID = "${DISTRO_VERSION}"
> -VERSION_CODENAME = "${DISTRO_CODENAME}"
> +VERSION_CODENAME = "${@d.getVar('DISTRO_CODENAME') or ''}"
> PRETTY_NAME = "${DISTRO_NAME} ${VERSION}"
>
> # The vendor field is hardcoded to "openembedded" deliberately. We'd
> --
> 2.45.2
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#200953):
https://lists.openembedded.org/g/openembedded-core/message/200953
Mute This Topic: https://lists.openembedded.org/mt/106779331/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v3 1/1] gfortran: update runtime dependencies
See https://lists.openembedded.org/g/openembedded-core/message/200915
which allows to me to build nativesdk-gcc again.
I've built nativesdk-libgfortran and libgfortran with the patch, but
haven't used fortran in runtime at all, that's why it's an RFC, there
were also 2 warnings:
WARNING: nativesdk-libgfortran-14.1.0-r0 do_package_qa: QA Issue: File
/opt/.../usr/lib/.debug/libgfortran.so.5.0.0 in package
nativesdk-libgfortran-dbg contains reference to TMPDIR [buildpaths]
WARNING: libgfortran-14.1.0-r0 do_package_qa: QA Issue: File
/usr/lib/.debug/libgfortran.so.5.0.0 in package libgfortran-dbg
contains reference to TMPDIR [buildpaths]
which I guess were already there.
On Wed, Jun 19, 2024 at 3:24 PM Martin Jansa via
lists.openembedded.org
wrote:
>
> Something seems wrong with this change which was merged today, now with:
> MACHINE=qemuarm64
> FORTRAN:forcevariable = ",fortran"
>
> I'm seeing:
> build/oe-core $ bitbake -g nativesdk-libgfortran
> NOTE: Resolving any missing task queue dependencies
> ERROR: Nothing PROVIDES 'gcc-cross-x86_64' (but
> virtual:nativesdk:/OE/build/oe-core/openembedded-core/meta/recipes-devtools/gcc/libgfortran_14.1.bb
> DEPENDS on or otherwise requires it). Close matches:
> gcc-cross-aarch64
> ...
>
> This might have been broken even before this change, but now it got
> included in dependency tree of nativesdk-gcc (as shown in bitbake -g
> nativesdk-gcc now failing when host and target arch don't match):
>
> "nativesdk-gcc.do_package_qa" -> "nativesdk-libgfortran.do_packagedata"
> nativesdk-gcc.do_package_write_ipk" -> "nativesdk-libgfortran.do_packagedata"
>
> Missing or unbuildable dependency chain was: ['image',
> 'nativesdk-packagegroup-sdk-host', 'nativesdk-lcov',
> 'nativesdk-gcov-symlinks', 'nativesdk-libgfortran-dev',
> 'gcc-cross-x86_64']
>
> I guess the easiest fix would be in:
> meta/recipes-devtools/gcc/libgfortran.inc:DEPENDS = "gcc-runtime
> gcc-cross-${TARGET_ARCH}"
> but I'm not very familiar with fortran (we've enabled it long time ago
> to build lapack(blas) for snowboy, but wasn't actively used for couple
> years).
>
> Regards,
>
>
>
> On Sun, Jun 16, 2024 at 5:32 PM Kai Kang via lists.openembedded.org
> wrote:
> >
> > From: Kai Kang
> >
> > It fails to run both `gcc` and `gfortran` with errors:
> >
> > | root@qemux86-64:~# x86_64-poky-linux-gcc a.c
> > | x86_64-poky-linux-gcc: fatal error: cannot execute 'as': posix_spawnp: No
> > such file or directory
> >
> > then add binutils which provides `as` to RDEPENDS of gcc.
> >
> > libgfortran-dev provides libgfortran.spec which required by gfortran:
> >
> > | root@qemux86-64:~# gfortran hello.f95
> > | gfortran: fatal error: cannot read spec file 'libgfortran.spec': No such
> > file or directory
> >
> > And gcc provides liblto_plugin.so:
> >
> > | root@qemux86-64:~# gfortran hello.f95
> > | gfortran: fatal error: '-fuse-linker-plugin', but liblto_plugin.so not
> > found
> >
> > Signed-off-by: Kai Kang
> > ---
> > meta/recipes-devtools/gcc/gcc-target.inc | 9 +++--
> > 1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/meta/recipes-devtools/gcc/gcc-target.inc
> > b/meta/recipes-devtools/gcc/gcc-target.inc
> > index 8e9693b4cb..e9187fc444 100644
> > --- a/meta/recipes-devtools/gcc/gcc-target.inc
> > +++ b/meta/recipes-devtools/gcc/gcc-target.inc
> > @@ -33,7 +33,7 @@ PACKAGES = "\
> > ${PN} ${PN}-plugins ${PN}-symlinks \
> > g++ g++-symlinks \
> > cpp cpp-symlinks \
> > -gfortran gfortran-symlinks \
> > +${@bb.utils.contains('FORTRAN', ',fortran', 'gfortran
> > gfortran-symlinks', '', d)} \
> > gcov gcov-symlinks \
> > ${PN}-doc \
> > ${PN}-dev \
> > @@ -60,7 +60,7 @@ RRECOMMENDS:${PN} += "\
> > libssp \
> > libssp-dev \
> > "
> > -RDEPENDS:${PN} += "cpp"
> > +RDEPENDS:${PN} += "binutils cpp"
> >
> > FILES:${PN}-dev = "\
> > ${gcclibdir}/${TARGET_SYS}/${BINV}/lib*${SOLIBSDEV} \
> > @@ -80,10 +80,15 @@ FILES:${PN}-plugins = "\
> > "
> > ALLOW_EMPTY:${PN}-plugins = "1"
> >
> > +INSANE_SKIP:${MLPREFIX}gfortran += "dev-deps"
> > FILES:gfortran = "\
> > ${bindir}/${TARGET_PREFIX}gfortran \
> > ${libexecdir}/gcc/${TARGET_SYS}/${BINV}/f951 \
> > "
> > +RDEPENDS:gfortran = "\
> > +gcc \
> > +libgfortran-dev \
> > +"
> > RRECOMMENDS:gfortran = "\
> > libquadmath \
> > libquadmath-dev \
> > --
> > 2.34.1
> >
> >
> >
> >
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#200916):
https://lists.openembedded.org/g/openembedded-core/message/200916
Mute This Topic: https://lists.openembedded.org/mt/106704990/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] libgfortran.inc: fix nativesdk-libgfortran dependencies
* use virtual/* variables as INHIBIT_DEFAULT_DEPS does to avoid dependency on
gcc-cross-
from nativesdk-libgfortran
* the dependency was added in:
https://git.openembedded.org/openembedded-core/commit/?id=00fba52c8a6f6383137cf89fc7aa34cc3e2ff45f
causing:
build/oe-core $ bitbake -g nativesdk-libgfortran
NOTE: Resolving any missing task queue dependencies
ERROR: Nothing PROVIDES 'gcc-cross-x86_64' (but
virtual:nativesdk:/OE/build/oe-core/openembedded-core/meta/recipes-devtools/gcc/libgfortran_14.1.bb
DEPENDS on or otherwise requires it). Close matches:
gcc-cross-aarch64
...
with:
MACHINE=qemuarm64
FORTRAN:forcevariable = ",fortran"
* after:
https://git.openembedded.org/openembedded-core/commit/?id=44fc7aa1468ff042739cc5a91c84ef5c2a09e0a3
nativesdk-libgfortran is pulled as dependency of nativesdk-gcc so this affects
more people who didn't explicitly use nativesdk-libgfortran before
* the INHIBIT_DEFAULT_DEPS and gcc-runtime was there since gcc-4.8:
https://git.openembedded.org/openembedded-core/commit/?id=a5e7ee5770b9e0cf719c573efffd874440f74289
Signed-off-by: Martin Jansa
---
meta/recipes-devtools/gcc/libgfortran.inc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/gcc/libgfortran.inc
b/meta/recipes-devtools/gcc/libgfortran.inc
index e810146d4d..c68645e392 100644
--- a/meta/recipes-devtools/gcc/libgfortran.inc
+++ b/meta/recipes-devtools/gcc/libgfortran.inc
@@ -47,8 +47,9 @@ do_install () {
chown -R root:root ${D}
}
+# avoid virtual/libc
INHIBIT_DEFAULT_DEPS = "1"
-DEPENDS = "gcc-runtime gcc-cross-${TARGET_ARCH}"
+DEPENDS = "virtual/${HOST_PREFIX}gcc virtual/${HOST_PREFIX}compilerlibs"
BBCLASSEXTEND = "nativesdk"
--
2.45.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#200915):
https://lists.openembedded.org/g/openembedded-core/message/200915
Mute This Topic: https://lists.openembedded.org/mt/106761834/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v3 1/1] gfortran: update runtime dependencies
Something seems wrong with this change which was merged today, now with:
MACHINE=qemuarm64
FORTRAN:forcevariable = ",fortran"
I'm seeing:
build/oe-core $ bitbake -g nativesdk-libgfortran
NOTE: Resolving any missing task queue dependencies
ERROR: Nothing PROVIDES 'gcc-cross-x86_64' (but
virtual:nativesdk:/OE/build/oe-core/openembedded-core/meta/recipes-devtools/gcc/libgfortran_14.1.bb
DEPENDS on or otherwise requires it). Close matches:
gcc-cross-aarch64
...
This might have been broken even before this change, but now it got
included in dependency tree of nativesdk-gcc (as shown in bitbake -g
nativesdk-gcc now failing when host and target arch don't match):
"nativesdk-gcc.do_package_qa" -> "nativesdk-libgfortran.do_packagedata"
nativesdk-gcc.do_package_write_ipk" -> "nativesdk-libgfortran.do_packagedata"
Missing or unbuildable dependency chain was: ['image',
'nativesdk-packagegroup-sdk-host', 'nativesdk-lcov',
'nativesdk-gcov-symlinks', 'nativesdk-libgfortran-dev',
'gcc-cross-x86_64']
I guess the easiest fix would be in:
meta/recipes-devtools/gcc/libgfortran.inc:DEPENDS = "gcc-runtime
gcc-cross-${TARGET_ARCH}"
but I'm not very familiar with fortran (we've enabled it long time ago
to build lapack(blas) for snowboy, but wasn't actively used for couple
years).
Regards,
On Sun, Jun 16, 2024 at 5:32 PM Kai Kang via lists.openembedded.org
wrote:
>
> From: Kai Kang
>
> It fails to run both `gcc` and `gfortran` with errors:
>
> | root@qemux86-64:~# x86_64-poky-linux-gcc a.c
> | x86_64-poky-linux-gcc: fatal error: cannot execute 'as': posix_spawnp: No
> such file or directory
>
> then add binutils which provides `as` to RDEPENDS of gcc.
>
> libgfortran-dev provides libgfortran.spec which required by gfortran:
>
> | root@qemux86-64:~# gfortran hello.f95
> | gfortran: fatal error: cannot read spec file 'libgfortran.spec': No such
> file or directory
>
> And gcc provides liblto_plugin.so:
>
> | root@qemux86-64:~# gfortran hello.f95
> | gfortran: fatal error: '-fuse-linker-plugin', but liblto_plugin.so not found
>
> Signed-off-by: Kai Kang
> ---
> meta/recipes-devtools/gcc/gcc-target.inc | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/meta/recipes-devtools/gcc/gcc-target.inc
> b/meta/recipes-devtools/gcc/gcc-target.inc
> index 8e9693b4cb..e9187fc444 100644
> --- a/meta/recipes-devtools/gcc/gcc-target.inc
> +++ b/meta/recipes-devtools/gcc/gcc-target.inc
> @@ -33,7 +33,7 @@ PACKAGES = "\
> ${PN} ${PN}-plugins ${PN}-symlinks \
> g++ g++-symlinks \
> cpp cpp-symlinks \
> -gfortran gfortran-symlinks \
> +${@bb.utils.contains('FORTRAN', ',fortran', 'gfortran
> gfortran-symlinks', '', d)} \
> gcov gcov-symlinks \
> ${PN}-doc \
> ${PN}-dev \
> @@ -60,7 +60,7 @@ RRECOMMENDS:${PN} += "\
> libssp \
> libssp-dev \
> "
> -RDEPENDS:${PN} += "cpp"
> +RDEPENDS:${PN} += "binutils cpp"
>
> FILES:${PN}-dev = "\
> ${gcclibdir}/${TARGET_SYS}/${BINV}/lib*${SOLIBSDEV} \
> @@ -80,10 +80,15 @@ FILES:${PN}-plugins = "\
> "
> ALLOW_EMPTY:${PN}-plugins = "1"
>
> +INSANE_SKIP:${MLPREFIX}gfortran += "dev-deps"
> FILES:gfortran = "\
> ${bindir}/${TARGET_PREFIX}gfortran \
> ${libexecdir}/gcc/${TARGET_SYS}/${BINV}/f951 \
> "
> +RDEPENDS:gfortran = "\
> +gcc \
> +libgfortran-dev \
> +"
> RRECOMMENDS:gfortran = "\
> libquadmath \
> libquadmath-dev \
> --
> 2.34.1
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#200913):
https://lists.openembedded.org/g/openembedded-core/message/200913
Mute This Topic: https://lists.openembedded.org/mt/106704990/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] libgcrypt: Fix building error with '-O2' in sysroot path
On Sat, Jun 8, 2024 at 12:46 AM Martin Jansa via lists.openembedded.org wrote: > > > > +-o_flag_munging = sed -e 's/-O\([1-9sgz][1-9sgz]*\)/-O0/g' -e > > > 's/-Ofast/-O0/g' > > > ++o_flag_munging = sed -e 's/[[:blank:]]-O\([2-9sgz][2-9sgz]*\)/ -O0 /' > > > -e 's/[[:blank:]]-Ofast/ -O0 /g' > > I guess the 1-9 should have stayed in this one (now it no longer > replaces -O1 with -O0) and also the "/g" got missing, so it replaced > the first -O* on command line, but not the 2nd one which stayed -O2. > > To be safe you should add /g to the first sed call as well. > > It should be fixed upstream as well as the issue is already in the > merged version: > https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=blobdiff;f=random/Makefile.am;h=340df38a798997b975d81a445cbc84cb23f5ea7a;hp=0c935a05952b5f1d91ef5992ec090912a77b03d2;hb=7d9817ca935a35fe6c8e2c2c7615825fa08a3a19;hpb=75e9bcccb69a9dea67d90840bd295bbd1749cea3 > The 1-9 part was already fixed upstream: https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=blobdiff;f=random/Makefile.am;h=c7100ef8b896f321c9f85249184a8e4a2ca38a1e;hp=340df38a798997b975d81a445cbc84cb23f5ea7a;hb=5afadba008918d651afefb842ae123cc18454c74;hpb=3f5989014a1b7c01aced88897d878ce5105d15df > Regards, > > On Sat, Jun 8, 2024 at 12:35 AM Alexandre Belloni via > lists.openembedded.org > wrote: > > > > This seems to fail: > > > > | libtool: compile: arm-poky-linux-gnueabi-gcc -mfpu=neon -mfloat-abi=hard > > -mcpu=cortex-a8 -fstack-protector-strong -O0 -D_FORTIFY_SOURCE=2 -Wformat > > -Wformat-security -Werror=format-security -D_TIME_BITS=64 > > -D_FILE_OFFSET_BITS=64 > > --sysroot=/home/pokybuild/yocto-worker/beaglebone-alt/build/build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/libgcrypt/1.10.3/recipe-sysroot > > -DHAVE_CONFIG_H -I. -I../../libgcrypt-1.10.3/random -I.. -I../src > > -I../../libgcrypt-1.10.3/src -O2 -pipe -g -feliminate-unused-debug-types > > -fcanon-prefix-map > > -fmacro-prefix-map=/home/pokybuild/yocto-worker/beaglebone-alt/build/build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/libgcrypt/1.10.3/libgcrypt-1.10.3=/usr/src/debug/libgcrypt/1.10.3 > > > > -fdebug-prefix-map=/home/pokybuild/yocto-worker/beaglebone-alt/build/build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/libgcrypt/1.10.3/libgcrypt-1.10.3=/usr/src/debug/libgcrypt/1.10.3 > > > > -fmacro-prefix-map=/home/pokybuild/yocto-worker/beaglebone-alt/build/build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/libgcrypt/1.10.3/build=/usr/src/debug/libgcrypt/1.10.3 > > > > -fdebug-prefix-map=/home/pokybuild/yocto-worker/beaglebone-alt/build/build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/libgcrypt/1.10.3/build=/usr/src/debug/libgcrypt/1.10.3 > > > > -fdebug-prefix-map=/home/pokybuild/yocto-worker/beaglebone-alt/build/build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/libgcrypt/1.10.3/recipe-sysroot= > > > > -fmacro-prefix-map=/home/pokybuild/yocto-worker/beaglebone-alt/build/build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/libgcrypt/1.10.3/recipe-sysroot= > > > > -fdebug-prefix-map=/home/pokybuild/yocto-worker/beaglebone-alt/build/build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/libgcrypt/1.10.3/recipe-sysroot-native= > > -fvisibility=hidden -fno-delete-null-pointer-checks -Wall -c > > ../../libgcrypt-1.10.3/random/rndjent.c -fPIC -DPIC -o .libs/rndjent.o > > | In file included from ../../libgcrypt-1.10.3/random/rndjent.c:99: > > | ../../libgcrypt-1.10.3/random/jitterentropy-base.c:58:3: error: #error > > "The CPU Jitter random number generator must not be compiled with > > optimizations. See documentation. Use the compiler switch -O0 for compiling > > jitterentropy.c." > > |58 | #error "The CPU Jitter random number generator must not be > > compiled with optimizations. See documentation. Use the compiler switch -O0 > > for compiling jitterentropy.c." > > | | ^ > > | make[2]: *** [Makefile:775: rndjent.lo] Error 1 > > | make[2]: Leaving directory > > '/home/pokybuild/yocto-worker/beaglebone-alt/build/build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/libgcrypt/1.10.3/build/random' > > | make[1]: *** [Makefile:500: all-recursive] Error 1 > > | make[1]: Leaving directory > > '/home/pokybuild/yocto-worker/beaglebone-alt/build/build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/libgcrypt/1.10.3/build' > > | make: *** [Makefile:432: all] Error 2 > > | ERROR: oe_runmake failed > > | WARNING: exit code 1 from a shell command. > > NOTE: recipe libgcrypt-1.10.3-r0: task do_compile: Failed > > > > https://autobuilder.yoctoprojec
Re: [OE-core] [PATCHv3] libgcrypt: Fix building error with '-O2' in sysroot path
> > +-o_flag_munging = sed -e 's/-O\([1-9sgz][1-9sgz]*\)/-O0/g' -e > > 's/-Ofast/-O0/g' > > ++o_flag_munging = sed -e 's/[[:blank:]]-O\([2-9sgz][2-9sgz]*\)/ -O0 /' -e > > 's/[[:blank:]]-Ofast/ -O0 /g' I guess the 1-9 should have stayed in this one (now it no longer replaces -O1 with -O0) and also the "/g" got missing, so it replaced the first -O* on command line, but not the 2nd one which stayed -O2. To be safe you should add /g to the first sed call as well. It should be fixed upstream as well as the issue is already in the merged version: https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=blobdiff;f=random/Makefile.am;h=340df38a798997b975d81a445cbc84cb23f5ea7a;hp=0c935a05952b5f1d91ef5992ec090912a77b03d2;hb=7d9817ca935a35fe6c8e2c2c7615825fa08a3a19;hpb=75e9bcccb69a9dea67d90840bd295bbd1749cea3 Regards, On Sat, Jun 8, 2024 at 12:35 AM Alexandre Belloni via lists.openembedded.org wrote: > > This seems to fail: > > | libtool: compile: arm-poky-linux-gnueabi-gcc -mfpu=neon -mfloat-abi=hard > -mcpu=cortex-a8 -fstack-protector-strong -O0 -D_FORTIFY_SOURCE=2 -Wformat > -Wformat-security -Werror=format-security -D_TIME_BITS=64 > -D_FILE_OFFSET_BITS=64 > --sysroot=/home/pokybuild/yocto-worker/beaglebone-alt/build/build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/libgcrypt/1.10.3/recipe-sysroot > -DHAVE_CONFIG_H -I. -I../../libgcrypt-1.10.3/random -I.. -I../src > -I../../libgcrypt-1.10.3/src -O2 -pipe -g -feliminate-unused-debug-types > -fcanon-prefix-map > -fmacro-prefix-map=/home/pokybuild/yocto-worker/beaglebone-alt/build/build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/libgcrypt/1.10.3/libgcrypt-1.10.3=/usr/src/debug/libgcrypt/1.10.3 > > -fdebug-prefix-map=/home/pokybuild/yocto-worker/beaglebone-alt/build/build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/libgcrypt/1.10.3/libgcrypt-1.10.3=/usr/src/debug/libgcrypt/1.10.3 > > -fmacro-prefix-map=/home/pokybuild/yocto-worker/beaglebone-alt/build/build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/libgcrypt/1.10.3/build=/usr/src/debug/libgcrypt/1.10.3 > > -fdebug-prefix-map=/home/pokybuild/yocto-worker/beaglebone-alt/build/build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/libgcrypt/1.10.3/build=/usr/src/debug/libgcrypt/1.10.3 > > -fdebug-prefix-map=/home/pokybuild/yocto-worker/beaglebone-alt/build/build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/libgcrypt/1.10.3/recipe-sysroot= > > -fmacro-prefix-map=/home/pokybuild/yocto-worker/beaglebone-alt/build/build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/libgcrypt/1.10.3/recipe-sysroot= > > -fdebug-prefix-map=/home/pokybuild/yocto-worker/beaglebone-alt/build/build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/libgcrypt/1.10.3/recipe-sysroot-native= > -fvisibility=hidden -fno-delete-null-pointer-checks -Wall -c > ../../libgcrypt-1.10.3/random/rndjent.c -fPIC -DPIC -o .libs/rndjent.o > | In file included from ../../libgcrypt-1.10.3/random/rndjent.c:99: > | ../../libgcrypt-1.10.3/random/jitterentropy-base.c:58:3: error: #error "The > CPU Jitter random number generator must not be compiled with optimizations. > See documentation. Use the compiler switch -O0 for compiling jitterentropy.c." > |58 | #error "The CPU Jitter random number generator must not be > compiled with optimizations. See documentation. Use the compiler switch -O0 > for compiling jitterentropy.c." > | | ^ > | make[2]: *** [Makefile:775: rndjent.lo] Error 1 > | make[2]: Leaving directory > '/home/pokybuild/yocto-worker/beaglebone-alt/build/build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/libgcrypt/1.10.3/build/random' > | make[1]: *** [Makefile:500: all-recursive] Error 1 > | make[1]: Leaving directory > '/home/pokybuild/yocto-worker/beaglebone-alt/build/build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/libgcrypt/1.10.3/build' > | make: *** [Makefile:432: all] Error 2 > | ERROR: oe_runmake failed > | WARNING: exit code 1 from a shell command. > NOTE: recipe libgcrypt-1.10.3-r0: task do_compile: Failed > > https://autobuilder.yoctoproject.org/typhoon/#/builders/106/builds/8078/steps/11/logs/stdio > > > > On 06/06/2024 16:26:41+0530, simit.ghane wrote: > > Characters like '-O2' or '-Ofast' will be replaced by '-O1' and '-O0' > > respectively when compiling cipher and random in the filesystem > > paths as well if they happen to contain '-O2' or '-Ofast > > > > If we are cross compiling libgcrypt and sysroot contains such > > characters, we would > > get compile errors because the sysroot path has been modified. > > > > Fix this by adding blank spaces and tabs before the original matching > > pattern in the sed command. > > > > It is difficult to control -O1 for cipher and -O0 for random > > at the same time in OE environment along with patch file. > > So, keeping same change as it is. > > > > Signed-off-by: simit.ghane > > --- > > v3: No change > > > > ...ilding-error-with-O2-in-sysroot-path.patch | 52 +-- > > 1 file changed, 36 insertions(+), 16 deletions(-) > > > > diff --git > > a/m
[OE-core] [PATCH v4 1/2] selftest: add Upstream-Status to .patch files
Signed-off-by: Martin Jansa --- v4: use Inappropriate [Test artefact] everywhere as requested add Upstream-Status to *.patch.expected as well to fix devtool.DevtoolUpdateTests.test_devtool_update_recipe_with_gitignore devtool.DevtoolUpdateTests.test_devtool_update_recipe_long_filename .../recipes-extended/hello-rs/hello-rs/0001-Greet-OE-Core.patch | 2 +- .../devtool/devtool-patch-overrides/qemuarm/arm.patch | 2 ++ .../devtool/devtool-patch-overrides/qemux86/x86.patch | 2 ++ .../devtool/devtool-test-ignored/devtool-test-ignored.patch | 2 ++ .../devtool-test-ignored/devtool-test-ignored.patch.expected| 1 + ...1-I-ll-patch-you-only-if-devtool-lets-me-to-do-it-corr.patch | 2 ++ ...tch-you-only-if-devtool-lets-me-to-do-it-corr.patch.expected | 1 + .../0001-Add-a-note-line-to-the-quick-reference.patch | 2 ++ .../devtool/devtool-upgrade-test1-1.5.3/backported.patch| 2 ++ .../recipes-test/gitrepotest/gitrepotest/0001-testpatch.patch | 2 ++ .../recipes-test/man-db/files/0001-Test-patch-here.patch| 2 ++ meta-selftest/recipes-test/recipetool/files/add-file.patch | 2 ++ 12 files changed, 21 insertions(+), 1 deletion(-) diff --git a/meta-selftest/recipes-extended/hello-rs/hello-rs/0001-Greet-OE-Core.patch b/meta-selftest/recipes-extended/hello-rs/hello-rs/0001-Greet-OE-Core.patch index 7569ccef7bb..96be6f4a614 100644 --- a/meta-selftest/recipes-extended/hello-rs/hello-rs/0001-Greet-OE-Core.patch +++ b/meta-selftest/recipes-extended/hello-rs/hello-rs/0001-Greet-OE-Core.patch @@ -4,7 +4,7 @@ Date: Wed, 27 Dec 2023 09:55:48 + Subject: [PATCH] Greet "OE-Core" Signed-off-by: Alex Kiernan -Upstream-Status: Inappropriate +Upstream-Status: Inappropriate [Test artefact] --- src/main.rs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta-selftest/recipes-test/devtool/devtool-patch-overrides/qemuarm/arm.patch b/meta-selftest/recipes-test/devtool/devtool-patch-overrides/qemuarm/arm.patch index e33a2753f9e..17ed5a54f16 100644 --- a/meta-selftest/recipes-test/devtool/devtool-patch-overrides/qemuarm/arm.patch +++ b/meta-selftest/recipes-test/devtool/devtool-patch-overrides/qemuarm/arm.patch @@ -1,3 +1,5 @@ +Upstream-Status: Inappropriate [Test artefact] + --- source.orig2020-10-06 13:26:10.792688630 +0100 +++ source 2020-10-06 13:26:18.853424694 +0100 @@ -1 +1 @@ diff --git a/meta-selftest/recipes-test/devtool/devtool-patch-overrides/qemux86/x86.patch b/meta-selftest/recipes-test/devtool/devtool-patch-overrides/qemux86/x86.patch index 1a0a175fa84..0af5ebbfaf9 100644 --- a/meta-selftest/recipes-test/devtool/devtool-patch-overrides/qemux86/x86.patch +++ b/meta-selftest/recipes-test/devtool/devtool-patch-overrides/qemux86/x86.patch @@ -1,3 +1,5 @@ +Upstream-Status: Inappropriate [Test artefact] + --- source.orig2020-10-06 13:26:10.792688630 +0100 +++ source 2020-10-06 13:26:18.853424694 +0100 @@ -1 +1 @@ diff --git a/meta-selftest/recipes-test/devtool/devtool-test-ignored/devtool-test-ignored.patch b/meta-selftest/recipes-test/devtool/devtool-test-ignored/devtool-test-ignored.patch index 96ea0eb4e3b..bc1ca4bc4a8 100644 --- a/meta-selftest/recipes-test/devtool/devtool-test-ignored/devtool-test-ignored.patch +++ b/meta-selftest/recipes-test/devtool/devtool-test-ignored/devtool-test-ignored.patch @@ -1,3 +1,5 @@ +Upstream-Status: Inappropriate [Test artefact] + diff --git a/ignored b/ignored index a579759..e3d7b43 100644 --- a/ignored diff --git a/meta-selftest/recipes-test/devtool/devtool-test-ignored/devtool-test-ignored.patch.expected b/meta-selftest/recipes-test/devtool/devtool-test-ignored/devtool-test-ignored.patch.expected index 68ec6d9875f..8ead9ee1ce6 100644 --- a/meta-selftest/recipes-test/devtool/devtool-test-ignored/devtool-test-ignored.patch.expected +++ b/meta-selftest/recipes-test/devtool/devtool-test-ignored/devtool-test-ignored.patch.expected @@ -3,6 +3,7 @@ From: Martin Jansa Date: Thu, 28 May 2020 01:32:31 +0200 Subject: [PATCH] meta-selftest: add test of .gitignore in tarball +Upstream-Status: Inappropriate [Test artefact] --- ignored | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta-selftest/recipes-test/devtool/devtool-test-long-filename/0001-I-ll-patch-you-only-if-devtool-lets-me-to-do-it-corr.patch b/meta-selftest/recipes-test/devtool/devtool-test-long-filename/0001-I-ll-patch-you-only-if-devtool-lets-me-to-do-it-corr.patch index 6aaf409ebc5..2b7088e3676 100644 --- a/meta-selftest/recipes-test/devtool/devtool-test-long-filename/0001-I-ll-patch-you-only-if-devtool-lets-me-to-do-it-corr.patch +++ b/meta-selftest/recipes-test/devtool/devtool-test-long-filename/0001-I-ll-patch-you-only-if-devtool-lets-me-to-do-it-corr.patch @@ -1,3 +1,5 @@ +Upstream-Status: Inappropriate [Test artefact] + diff --git a/patch-me b/patch-me index a20b29a..5e35d1b 100644 --- a/patch-me diff --git a/meta-selftest/re
[OE-core] [PATCH v4 2/2] insane: add patch-status to default ERROR_QA
* 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&id=61a881fdbe8b5a21c6276b8a5d06cc30486b1eb3
Signed-off-by: Martin Jansa
---
v4: no change
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 bd05da0378e..06181d9059e 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.45.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#200379):
https://lists.openembedded.org/g/openembedded-core/message/200379
Mute This Topic: https://lists.openembedded.org/mt/106509023/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] [RESENDv2][PATCH 2/2] insane: add patch-status to default ERROR_QA
On Tue, Jun 4, 2024 at 8:46 PM Khem Raj wrote: > > On Fri, May 31, 2024 at 4:01 PM 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 > > Do other layers have the patches taken care of is what you mean here ? > otherwise I would suggest sending those fixes ahead of merging this. The layers I sometimes use were already fixed, the list of fixes was included in: https://lists.openembedded.org/g/openembedded-core/message/197115 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#200345): https://lists.openembedded.org/g/openembedded-core/message/200345 Mute This Topic: https://lists.openembedded.org/mt/106418259/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [RESENDv4][PATCH 3/4] selftest: add few missing Upstream-Status found by patchreview
* now patchreview complains only about missing SOBs $ scripts/contrib/patchreview.py -v meta-selftest/ Found layers meta-selftest Missing Signed-off-by tag (/OE/layers/openembedded-core/meta-selftest/recipes-test/devtool/devtool-patch-overrides/qemuarm/arm.patch) Missing Signed-off-by tag (/OE/layers/openembedded-core/meta-selftest/recipes-test/devtool/devtool-patch-overrides/qemux86/x86.patch) Missing Signed-off-by tag (/OE/layers/openembedded-core/meta-selftest/recipes-test/devtool/devtool-test-ignored/devtool-test-ignored.patch) Missing Signed-off-by tag (/OE/layers/openembedded-core/meta-selftest/recipes-test/devtool/devtool-test-long-filename/0001-I-ll-patch-you-only-if-devtool-lets-me-to-do-it-corr.patch) Missing Signed-off-by tag (/OE/layers/openembedded-core/meta-selftest/recipes-test/devtool/devtool-upgrade-test1-1.5.3/0001-Add-a-note-line-to-the-quick-reference.patch) Missing Signed-off-by tag (/OE/layers/openembedded-core/meta-selftest/recipes-test/devtool/devtool-upgrade-test1-1.5.3/backported.patch) Missing Signed-off-by tag (/OE/layers/openembedded-core/meta-selftest/recipes-test/gitrepotest/gitrepotest/0001-testpatch.patch) Missing Signed-off-by tag (/OE/layers/openembedded-core/meta-selftest/recipes-test/man-db/files/0001-Test-patch-here.patch) Missing Signed-off-by tag (/OE/layers/openembedded-core/meta-selftest/recipes-test/recipetool/files/add-file.patch) Total patches found: 13 Patches missing Signed-off-by: 9 (69%) Patches with malformed Signed-off-by: 0 (0%) Patches missing CVE: 0 (0%) Patches missing Upstream-Status: 0 (0%) Patches with malformed Upstream-Status: 0 (0%) Patches in Pending state: 1 (8%) Signed-off-by: Martin Jansa --- .../devtool/devtool-patch-overrides/qemuarm/arm.patch | 2 ++ .../devtool/devtool-patch-overrides/qemux86/x86.patch | 2 ++ .../recipes-test/man-db/files/0001-Test-patch-here.patch| 2 ++ 3 files changed, 6 insertions(+) diff --git a/meta-selftest/recipes-test/devtool/devtool-patch-overrides/qemuarm/arm.patch b/meta-selftest/recipes-test/devtool/devtool-patch-overrides/qemuarm/arm.patch index e33a2753f9..26702c4bc9 100644 --- a/meta-selftest/recipes-test/devtool/devtool-patch-overrides/qemuarm/arm.patch +++ b/meta-selftest/recipes-test/devtool/devtool-patch-overrides/qemuarm/arm.patch @@ -1,3 +1,5 @@ +Upstream-Status: Inappropriate [test file] + --- source.orig2020-10-06 13:26:10.792688630 +0100 +++ source 2020-10-06 13:26:18.853424694 +0100 @@ -1 +1 @@ diff --git a/meta-selftest/recipes-test/devtool/devtool-patch-overrides/qemux86/x86.patch b/meta-selftest/recipes-test/devtool/devtool-patch-overrides/qemux86/x86.patch index 1a0a175fa8..64af8f4dd8 100644 --- a/meta-selftest/recipes-test/devtool/devtool-patch-overrides/qemux86/x86.patch +++ b/meta-selftest/recipes-test/devtool/devtool-patch-overrides/qemux86/x86.patch @@ -1,3 +1,5 @@ +Upstream-Status: Inappropriate [test file] + --- source.orig2020-10-06 13:26:10.792688630 +0100 +++ source 2020-10-06 13:26:18.853424694 +0100 @@ -1 +1 @@ diff --git a/meta-selftest/recipes-test/man-db/files/0001-Test-patch-here.patch b/meta-selftest/recipes-test/man-db/files/0001-Test-patch-here.patch index b1d5eab2b8..859073cedf 100644 --- a/meta-selftest/recipes-test/man-db/files/0001-Test-patch-here.patch +++ b/meta-selftest/recipes-test/man-db/files/0001-Test-patch-here.patch @@ -4,6 +4,8 @@ Date: Fri, 9 Feb 2018 17:37:48 +0200 Subject: [PATCH] Test patch here! This is an invalid patch used by oe-selftest + +Upstream-Status: Inappropriate [test file] --- README | 1 + 1 file changed, 1 insertion(+) -- 2.45.2 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#200318): https://lists.openembedded.org/g/openembedded-core/message/200318 Mute This Topic: https://lists.openembedded.org/mt/106479178/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [RESENDv4][PATCH 2/4] selftest: add few missing Upstream-Status
* these were reported in: https://lists.openembedded.org/g/openembedded-core/message/200282 Signed-off-by: Martin Jansa --- .../devtool/devtool-test-ignored/devtool-test-ignored.patch | 2 ++ ...1-I-ll-patch-you-only-if-devtool-lets-me-to-do-it-corr.patch | 2 ++ .../0001-Add-a-note-line-to-the-quick-reference.patch | 2 ++ .../devtool/devtool-upgrade-test1-1.5.3/backported.patch| 2 ++ meta-selftest/recipes-test/recipetool/files/add-file.patch | 2 ++ 5 files changed, 10 insertions(+) diff --git a/meta-selftest/recipes-test/devtool/devtool-test-ignored/devtool-test-ignored.patch b/meta-selftest/recipes-test/devtool/devtool-test-ignored/devtool-test-ignored.patch index 96ea0eb4e3..389e00b2fa 100644 --- a/meta-selftest/recipes-test/devtool/devtool-test-ignored/devtool-test-ignored.patch +++ b/meta-selftest/recipes-test/devtool/devtool-test-ignored/devtool-test-ignored.patch @@ -1,3 +1,5 @@ +Upstream-Status: Inappropriate [this is ignored] + diff --git a/ignored b/ignored index a579759..e3d7b43 100644 --- a/ignored diff --git a/meta-selftest/recipes-test/devtool/devtool-test-long-filename/0001-I-ll-patch-you-only-if-devtool-lets-me-to-do-it-corr.patch b/meta-selftest/recipes-test/devtool/devtool-test-long-filename/0001-I-ll-patch-you-only-if-devtool-lets-me-to-do-it-corr.patch index 6aaf409ebc..74d0836c77 100644 --- a/meta-selftest/recipes-test/devtool/devtool-test-long-filename/0001-I-ll-patch-you-only-if-devtool-lets-me-to-do-it-corr.patch +++ b/meta-selftest/recipes-test/devtool/devtool-test-long-filename/0001-I-ll-patch-you-only-if-devtool-lets-me-to-do-it-corr.patch @@ -1,3 +1,5 @@ +Upstream-Status: Inappropriate [please don't submit me] + diff --git a/patch-me b/patch-me index a20b29a..5e35d1b 100644 --- a/patch-me diff --git a/meta-selftest/recipes-test/devtool/devtool-upgrade-test1-1.5.3/0001-Add-a-note-line-to-the-quick-reference.patch b/meta-selftest/recipes-test/devtool/devtool-upgrade-test1-1.5.3/0001-Add-a-note-line-to-the-quick-reference.patch index 4ea3d74f0f..457fce3a13 100644 --- a/meta-selftest/recipes-test/devtool/devtool-upgrade-test1-1.5.3/0001-Add-a-note-line-to-the-quick-reference.patch +++ b/meta-selftest/recipes-test/devtool/devtool-upgrade-test1-1.5.3/0001-Add-a-note-line-to-the-quick-reference.patch @@ -4,6 +4,8 @@ Date: Wed, 24 Feb 2016 17:43:03 +1300 Subject: [PATCH] Add a note line to the quick reference A test patch so we have a file to move around. + +Upstream-Status: Inappropriate [too important] --- doc/quickref.1.in | 1 + 1 file changed, 1 insertion(+) diff --git a/meta-selftest/recipes-test/devtool/devtool-upgrade-test1-1.5.3/backported.patch b/meta-selftest/recipes-test/devtool/devtool-upgrade-test1-1.5.3/backported.patch index c4f3f12666..c39c65eed4 100644 --- a/meta-selftest/recipes-test/devtool/devtool-upgrade-test1-1.5.3/backported.patch +++ b/meta-selftest/recipes-test/devtool/devtool-upgrade-test1-1.5.3/backported.patch @@ -4,6 +4,8 @@ Date: Mon Nov 18 18:43:15 2019 +0100 Backport of the NEWS file from version 1.6.0 +Upstream-Status: Backport [v1.6.0] + diff --git a/doc/NEWS b/doc/NEWS index 69793fc..fd49b1c 100644 --- a/doc/NEWS diff --git a/meta-selftest/recipes-test/recipetool/files/add-file.patch b/meta-selftest/recipes-test/recipetool/files/add-file.patch index bdc99c94f0..bbaa365ec6 100644 --- a/meta-selftest/recipes-test/recipetool/files/add-file.patch +++ b/meta-selftest/recipes-test/recipetool/files/add-file.patch @@ -1,3 +1,5 @@ +Upstream-Status: Inappropriate [test file] + diff --git a/file2 b/file2 new file mode 100644 index 000..049b42e -- 2.45.2 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#200317): https://lists.openembedded.org/g/openembedded-core/message/200317 Mute This Topic: https://lists.openembedded.org/mt/106479177/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [RESENDv4][PATCH 1/4] selftest: gitrepotest: add Upstream-Status to 0001-testpatch.patch
Signed-off-by: Martin Jansa --- .../recipes-test/gitrepotest/gitrepotest/0001-testpatch.patch | 2 ++ 1 file changed, 2 insertions(+) diff --git a/meta-selftest/recipes-test/gitrepotest/gitrepotest/0001-testpatch.patch b/meta-selftest/recipes-test/gitrepotest/gitrepotest/0001-testpatch.patch index bccda17ee9..c3f99455ca 100644 --- a/meta-selftest/recipes-test/gitrepotest/gitrepotest/0001-testpatch.patch +++ b/meta-selftest/recipes-test/gitrepotest/gitrepotest/0001-testpatch.patch @@ -1,3 +1,5 @@ +Upstream-Status: Inappropriate [this is useless patch only for selftest] + diff --git a/Makefile.am b/Makefile.am index 432a9b4..bbf7c74 100644 --- a/Makefile.am -- 2.45.2 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#200316): https://lists.openembedded.org/g/openembedded-core/message/200316 Mute This Topic: https://lists.openembedded.org/mt/106479176/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [RESENDv4][PATCH 4/4] insane: add patch-status to default ERROR_QA
* 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&id=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 151cf0c4ea..e3d592fa5d 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.45.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#200319):
https://lists.openembedded.org/g/openembedded-core/message/200319
Mute This Topic: https://lists.openembedded.org/mt/106479179/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [RESENDv3][PATCH 3/4] selftest: add few missing Upstream-Status found by patchreview
* now patchreview complains only about missing SOBs $ scripts/contrib/patchreview.py -v meta-selftest/ Found layers meta-selftest Missing Signed-off-by tag (/OE/layers/openembedded-core/meta-selftest/recipes-test/devtool/devtool-patch-overrides/qemuarm/arm.patch) Missing Signed-off-by tag (/OE/layers/openembedded-core/meta-selftest/recipes-test/devtool/devtool-patch-overrides/qemux86/x86.patch) Missing Signed-off-by tag (/OE/layers/openembedded-core/meta-selftest/recipes-test/devtool/devtool-test-ignored/devtool-test-ignored.patch) Missing Signed-off-by tag (/OE/layers/openembedded-core/meta-selftest/recipes-test/devtool/devtool-test-long-filename/0001-I-ll-patch-you-only-if-devtool-lets-me-to-do-it-corr.patch) Missing Signed-off-by tag (/OE/layers/openembedded-core/meta-selftest/recipes-test/devtool/devtool-upgrade-test1-1.5.3/0001-Add-a-note-line-to-the-quick-reference.patch) Missing Signed-off-by tag (/OE/layers/openembedded-core/meta-selftest/recipes-test/devtool/devtool-upgrade-test1-1.5.3/backported.patch) Missing Signed-off-by tag (/OE/layers/openembedded-core/meta-selftest/recipes-test/gitrepotest/gitrepotest/0001-testpatch.patch) Missing Signed-off-by tag (/OE/layers/openembedded-core/meta-selftest/recipes-test/man-db/files/0001-Test-patch-here.patch) Missing Signed-off-by tag (/OE/layers/openembedded-core/meta-selftest/recipes-test/recipetool/files/add-file.patch) Total patches found: 13 Patches missing Signed-off-by: 9 (69%) Patches with malformed Signed-off-by: 0 (0%) Patches missing CVE: 0 (0%) Patches missing Upstream-Status: 0 (0%) Patches with malformed Upstream-Status: 0 (0%) Patches in Pending state: 4 (31%) Signed-off-by: Martin Jansa --- .../devtool/devtool-patch-overrides/qemuarm/arm.patch | 2 ++ .../devtool/devtool-patch-overrides/qemux86/x86.patch | 2 ++ .../recipes-test/man-db/files/0001-Test-patch-here.patch| 2 ++ 3 files changed, 6 insertions(+) diff --git a/meta-selftest/recipes-test/devtool/devtool-patch-overrides/qemuarm/arm.patch b/meta-selftest/recipes-test/devtool/devtool-patch-overrides/qemuarm/arm.patch index e33a2753f9..f7f729a86c 100644 --- a/meta-selftest/recipes-test/devtool/devtool-patch-overrides/qemuarm/arm.patch +++ b/meta-selftest/recipes-test/devtool/devtool-patch-overrides/qemuarm/arm.patch @@ -1,3 +1,5 @@ +Upstream-Status: Pending + --- source.orig2020-10-06 13:26:10.792688630 +0100 +++ source 2020-10-06 13:26:18.853424694 +0100 @@ -1 +1 @@ diff --git a/meta-selftest/recipes-test/devtool/devtool-patch-overrides/qemux86/x86.patch b/meta-selftest/recipes-test/devtool/devtool-patch-overrides/qemux86/x86.patch index 1a0a175fa8..0aa1affedd 100644 --- a/meta-selftest/recipes-test/devtool/devtool-patch-overrides/qemux86/x86.patch +++ b/meta-selftest/recipes-test/devtool/devtool-patch-overrides/qemux86/x86.patch @@ -1,3 +1,5 @@ +Upstream-Status: Pending + --- source.orig2020-10-06 13:26:10.792688630 +0100 +++ source 2020-10-06 13:26:18.853424694 +0100 @@ -1 +1 @@ diff --git a/meta-selftest/recipes-test/man-db/files/0001-Test-patch-here.patch b/meta-selftest/recipes-test/man-db/files/0001-Test-patch-here.patch index b1d5eab2b8..d4d43904df 100644 --- a/meta-selftest/recipes-test/man-db/files/0001-Test-patch-here.patch +++ b/meta-selftest/recipes-test/man-db/files/0001-Test-patch-here.patch @@ -4,6 +4,8 @@ Date: Fri, 9 Feb 2018 17:37:48 +0200 Subject: [PATCH] Test patch here! This is an invalid patch used by oe-selftest + +Upstream-Status: Pending --- README | 1 + 1 file changed, 1 insertion(+) -- 2.45.2 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#200306): https://lists.openembedded.org/g/openembedded-core/message/200306 Mute This Topic: https://lists.openembedded.org/mt/106478759/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [RESENDv3][PATCH 2/4] selftest: add few missing Upstream-Status
* these were reported in: https://lists.openembedded.org/g/openembedded-core/message/200282 Signed-off-by: Martin Jansa --- .../devtool/devtool-test-ignored/devtool-test-ignored.patch | 2 ++ ...1-I-ll-patch-you-only-if-devtool-lets-me-to-do-it-corr.patch | 2 ++ .../0001-Add-a-note-line-to-the-quick-reference.patch | 2 ++ .../devtool/devtool-upgrade-test1-1.5.3/backported.patch| 2 ++ meta-selftest/recipes-test/recipetool/files/add-file.patch | 2 ++ 5 files changed, 10 insertions(+) diff --git a/meta-selftest/recipes-test/devtool/devtool-test-ignored/devtool-test-ignored.patch b/meta-selftest/recipes-test/devtool/devtool-test-ignored/devtool-test-ignored.patch index 96ea0eb4e3..389e00b2fa 100644 --- a/meta-selftest/recipes-test/devtool/devtool-test-ignored/devtool-test-ignored.patch +++ b/meta-selftest/recipes-test/devtool/devtool-test-ignored/devtool-test-ignored.patch @@ -1,3 +1,5 @@ +Upstream-Status: Inappropriate [this is ignored] + diff --git a/ignored b/ignored index a579759..e3d7b43 100644 --- a/ignored diff --git a/meta-selftest/recipes-test/devtool/devtool-test-long-filename/0001-I-ll-patch-you-only-if-devtool-lets-me-to-do-it-corr.patch b/meta-selftest/recipes-test/devtool/devtool-test-long-filename/0001-I-ll-patch-you-only-if-devtool-lets-me-to-do-it-corr.patch index 6aaf409ebc..74d0836c77 100644 --- a/meta-selftest/recipes-test/devtool/devtool-test-long-filename/0001-I-ll-patch-you-only-if-devtool-lets-me-to-do-it-corr.patch +++ b/meta-selftest/recipes-test/devtool/devtool-test-long-filename/0001-I-ll-patch-you-only-if-devtool-lets-me-to-do-it-corr.patch @@ -1,3 +1,5 @@ +Upstream-Status: Inappropriate [please don't submit me] + diff --git a/patch-me b/patch-me index a20b29a..5e35d1b 100644 --- a/patch-me diff --git a/meta-selftest/recipes-test/devtool/devtool-upgrade-test1-1.5.3/0001-Add-a-note-line-to-the-quick-reference.patch b/meta-selftest/recipes-test/devtool/devtool-upgrade-test1-1.5.3/0001-Add-a-note-line-to-the-quick-reference.patch index 4ea3d74f0f..457fce3a13 100644 --- a/meta-selftest/recipes-test/devtool/devtool-upgrade-test1-1.5.3/0001-Add-a-note-line-to-the-quick-reference.patch +++ b/meta-selftest/recipes-test/devtool/devtool-upgrade-test1-1.5.3/0001-Add-a-note-line-to-the-quick-reference.patch @@ -4,6 +4,8 @@ Date: Wed, 24 Feb 2016 17:43:03 +1300 Subject: [PATCH] Add a note line to the quick reference A test patch so we have a file to move around. + +Upstream-Status: Inappropriate [too important] --- doc/quickref.1.in | 1 + 1 file changed, 1 insertion(+) diff --git a/meta-selftest/recipes-test/devtool/devtool-upgrade-test1-1.5.3/backported.patch b/meta-selftest/recipes-test/devtool/devtool-upgrade-test1-1.5.3/backported.patch index c4f3f12666..c39c65eed4 100644 --- a/meta-selftest/recipes-test/devtool/devtool-upgrade-test1-1.5.3/backported.patch +++ b/meta-selftest/recipes-test/devtool/devtool-upgrade-test1-1.5.3/backported.patch @@ -4,6 +4,8 @@ Date: Mon Nov 18 18:43:15 2019 +0100 Backport of the NEWS file from version 1.6.0 +Upstream-Status: Backport [v1.6.0] + diff --git a/doc/NEWS b/doc/NEWS index 69793fc..fd49b1c 100644 --- a/doc/NEWS diff --git a/meta-selftest/recipes-test/recipetool/files/add-file.patch b/meta-selftest/recipes-test/recipetool/files/add-file.patch index bdc99c94f0..bbaa365ec6 100644 --- a/meta-selftest/recipes-test/recipetool/files/add-file.patch +++ b/meta-selftest/recipes-test/recipetool/files/add-file.patch @@ -1,3 +1,5 @@ +Upstream-Status: Inappropriate [test file] + diff --git a/file2 b/file2 new file mode 100644 index 000..049b42e -- 2.45.2 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#200305): https://lists.openembedded.org/g/openembedded-core/message/200305 Mute This Topic: https://lists.openembedded.org/mt/106478758/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [RESENDv3][PATCH 4/4] insane: add patch-status to default ERROR_QA
* 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&id=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 99736830b9..6d2f83c6f7 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.45.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#200307):
https://lists.openembedded.org/g/openembedded-core/message/200307
Mute This Topic: https://lists.openembedded.org/mt/106478760/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [RESENDv3][PATCH 1/4] selftest: gitrepotest: add Upstream-Status to 0001-testpatch.patch
Signed-off-by: Martin Jansa --- .../recipes-test/gitrepotest/gitrepotest/0001-testpatch.patch | 2 ++ 1 file changed, 2 insertions(+) diff --git a/meta-selftest/recipes-test/gitrepotest/gitrepotest/0001-testpatch.patch b/meta-selftest/recipes-test/gitrepotest/gitrepotest/0001-testpatch.patch index bccda17ee9..c3f99455ca 100644 --- a/meta-selftest/recipes-test/gitrepotest/gitrepotest/0001-testpatch.patch +++ b/meta-selftest/recipes-test/gitrepotest/gitrepotest/0001-testpatch.patch @@ -1,3 +1,5 @@ +Upstream-Status: Inappropriate [this is useless patch only for selftest] + diff --git a/Makefile.am b/Makefile.am index 432a9b4..bbf7c74 100644 --- a/Makefile.am -- 2.45.2 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#200304): https://lists.openembedded.org/g/openembedded-core/message/200304 Mute This Topic: https://lists.openembedded.org/mt/106478757/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] [RESENDv2][PATCH 2/2] insane: add patch-status to default ERROR_QA
Thanks and sorry for not catching it earlier. The errors refer to these 5 files: /home/pokybuild/yocto-worker/oe-selftest-debian/build/build-st-795212/meta-selftest/recipes-test/recipetool/files/add-file.patch /home/pokybuild/yocto-worker/oe-selftest-debian/build/build-st-795262/meta-selftest/recipes-test/devtool/devtool-test-ignored/devtool-test-ignored.patch /home/pokybuild/yocto-worker/oe-selftest-debian/build/build-st-795262/meta-selftest/recipes-test/devtool/devtool-test-long-filename/0001-I-ll-patch-you-only-if-devtool-lets-me-to-do-it-corr.patch /home/pokybuild/yocto-worker/oe-selftest-debian/build/build-st-795274/meta-selftest/recipes-test/devtool/devtool-upgrade-test1-1.5.3/0001-Add-a-note-line-to-the-quick-reference.patch /home/pokybuild/yocto-worker/oe-selftest-debian/build/build-st-795274/meta-selftest/recipes-test/devtool/devtool-upgrade-test1-1.5.3/backported.patch will check where they are used and send v3 with fixes. Regards, On Mon, Jun 3, 2024 at 11:26 PM Richard Purdie wrote: > > On Sat, 2024-06-01 at 01:01 +0200, 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&id=61a881fdbe8b5a21c6276b8a5d06cc30486b1eb3 > > > > Signed-off-by: Martin Jansa > > --- > > meta/classes-global/insane.bbclass | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > I'm pretty sure this is causing at least some of the failures in oe- > selftest: > > https://valkyrie.yoctoproject.org/#/builders/35/builds/36/steps/14/logs/stdio > > Cheers, > > Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#200301): https://lists.openembedded.org/g/openembedded-core/message/200301 Mute This Topic: https://lists.openembedded.org/mt/106418259/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [RESENDv2][PATCH 1/2] gitrepotest: add Upstream-Status to 0001-testpatch.patch
Signed-off-by: Martin Jansa --- .../recipes-test/gitrepotest/gitrepotest/0001-testpatch.patch | 2 ++ 1 file changed, 2 insertions(+) diff --git a/meta-selftest/recipes-test/gitrepotest/gitrepotest/0001-testpatch.patch b/meta-selftest/recipes-test/gitrepotest/gitrepotest/0001-testpatch.patch index bccda17ee9..c3f99455ca 100644 --- a/meta-selftest/recipes-test/gitrepotest/gitrepotest/0001-testpatch.patch +++ b/meta-selftest/recipes-test/gitrepotest/gitrepotest/0001-testpatch.patch @@ -1,3 +1,5 @@ +Upstream-Status: Inappropriate [this is useless patch only for selftest] + diff --git a/Makefile.am b/Makefile.am index 432a9b4..bbf7c74 100644 --- a/Makefile.am -- 2.45.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#200090): https://lists.openembedded.org/g/openembedded-core/message/200090 Mute This Topic: https://lists.openembedded.org/mt/106418257/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [RESENDv2][PATCH 2/2] insane: add patch-status to default ERROR_QA
* 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&id=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 99736830b9..6d2f83c6f7 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.45.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#200091):
https://lists.openembedded.org/g/openembedded-core/message/200091
Mute This Topic: https://lists.openembedded.org/mt/106418259/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] [RESEND][PATCH] insane: add patch-status to default ERROR_QA
On Fri, May 31, 2024 at 11:29 PM Alexandre Belloni
wrote:
>
> ERROR: gitrepotest-1.0-r0 do_patch: QA Issue: Missing Upstream-Status in patch
> /home/pokybuild/yocto-worker/reproducible/build/build-st/meta-selftest/recipes-test/gitrepotest/gitrepotest/0001-testpatch.patch
> Please add according to
> https://docs.yoctoproject.org/contributor-guide/recipe-style-guide.html#patch-upstream-status
> . [patch-status]
> ERROR: gitrepotest-1.0-r0 do_patch: Fatal QA errors were found, failing task.
https://lists.openembedded.org/g/openembedded-core/message/200086
should fix that.
Thanks,
>
> On 24/05/2024 18:00:25+0200, 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&id=61a881fdbe8b5a21c6276b8a5d06cc30486b1eb3
> >
> > Signed-off-by: Martin Jansa
> > ---
> > Resend
> > https://patchwork.yoctoproject.org/project/oe-core/patch/20240314070903.83765-1-martin.ja...@gmail.com/
> > now when scarthgap is released and master is open for development
> >
> > 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 99736830b9..6d2f83c6f7 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.45.1
> >
>
> >
> >
> >
>
>
> --
> Alexandre Belloni, co-owner and COO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#200087):
https://lists.openembedded.org/g/openembedded-core/message/200087
Mute This Topic: https://lists.openembedded.org/mt/106284256/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] gitrepotest: add Upstream-Status to 0001-testpatch.patch
Signed-off-by: Martin Jansa --- .../recipes-test/gitrepotest/gitrepotest/0001-testpatch.patch | 2 ++ 1 file changed, 2 insertions(+) diff --git a/meta-selftest/recipes-test/gitrepotest/gitrepotest/0001-testpatch.patch b/meta-selftest/recipes-test/gitrepotest/gitrepotest/0001-testpatch.patch index bccda17ee9..c3f99455ca 100644 --- a/meta-selftest/recipes-test/gitrepotest/gitrepotest/0001-testpatch.patch +++ b/meta-selftest/recipes-test/gitrepotest/gitrepotest/0001-testpatch.patch @@ -1,3 +1,5 @@ +Upstream-Status: Inappropriate [this is useless patch only for selftest] + diff --git a/Makefile.am b/Makefile.am index 432a9b4..bbf7c74 100644 --- a/Makefile.am -- 2.45.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#200086): https://lists.openembedded.org/g/openembedded-core/message/200086 Mute This Topic: https://lists.openembedded.org/mt/106417971/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][scarthgap][PATCH] opencl: fix virtual PROVIDES warnings
And you're changing the build time dependencies, the warning is about runtime dependencies, so I don't think this is correct. On Fri, May 31, 2024 at 8:59 AM Peter Marko via lists.openembedded.org wrote: > > -Original Message- > From: openembedded-core@lists.openembedded.org > On Behalf Of Bin Lan via > lists.openembedded.org > Sent: Friday, May 31, 2024 8:30 > To: openembedded-core@lists.openembedded.org > Cc: Bin Lan > Subject: [OE-core][scarthgap][PATCH] opencl: fix virtual PROVIDES warnings > > > From: Bin Lan > > > > oe-core has started to warn when virtual/ is used outside of > > the RPROVIDES (build) context. > > > > We tweak provides/depends to use virtual- instead to > > avoid the warning: > > > > RPROVIDES is set to virtual/opencl-icd, the substring 'virtual/' > > holds no meaning in this context. It is suggested to use the 'virtual-' > > You have old version of master/scarthgap, current warning is: > %s is set to %s but the substring 'virtual/' holds no meaning in this > context. It only works for build time dependencies, not runtime ones. It is > suggested to use 'VIRTUAL-RUNTIME_' variables instead. > > Also you should send this to master first as it applies to that branch, too. > > > > > Signed-off-by: Bin Lan > > --- > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#200058): https://lists.openembedded.org/g/openembedded-core/message/200058 Mute This Topic: https://lists.openembedded.org/mt/106403372/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] db: ignore implicit-int and implicit-function-declaration issues fatal with gcc-14
* many configure tests (which might not fail before) are failing with gcc-14:
# grep implicit build/config.log
conftest.c:47:1: error: return type defaults to 'int' [-Wimplicit-int]
conftest.c:47:1: error: return type defaults to 'int' [-Wimplicit-int]
conftest.c:47:1: error: return type defaults to 'int' [-Wimplicit-int]
conftest.c:47:1: error: return type defaults to 'int' [-Wimplicit-int]
conftest.c:47:1: error: return type defaults to 'int' [-Wimplicit-int]
conftest.c:47:1: error: return type defaults to 'int' [-Wimplicit-int]
conftest.c:50:17: error: implicit declaration of function 'exit'
[-Wimplicit-function-declaration]
conftest.c:50:17: warning: incompatible implicit declaration of built-in
function 'exit' [-Wbuiltin-declaration-mismatch]
conftest.c:53:9: error: implicit declaration of function 'msem_init'
[-Wimplicit-function-declaration]
conftest.c:54:9: error: implicit declaration of function 'msem_lock'
[-Wimplicit-function-declaration]
conftest.c:55:9: error: implicit declaration of function 'msem_unlock'
[-Wimplicit-function-declaration]
conftest.c:56:9: error: implicit declaration of function 'exit'
[-Wimplicit-function-declaration]
conftest.c:56:9: warning: incompatible implicit declaration of built-in
function 'exit' [-Wbuiltin-declaration-mismatch]
conftest.c:50:9: error: implicit declaration of function '_spin_lock_try'
[-Wimplicit-function-declaration]
conftest.c:51:9: error: implicit declaration of function '_spin_unlock'
[-Wimplicit-function-declaration]
* I have noticed this on db-native build on host with gcc-14
where it caused fatal do_configure error:
http://errors.yoctoproject.org/Errors/Details/784164/
checking for mutexes... UNIX/fcntl
configure: error: Support for FCNTL mutexes was removed in BDB 4.8.
the config.log confirms it's because implicit-int:
configure:22798: checking for mutexes
configure:22925: gcc -o conftest
-isystem/OE/build/oe-core/tmp-glibc/work/x86_64-linux/db-native/5.3.28/recipe-sysroot-native/usr/include
-O2 -pipe
-isystem/OE/build/oe-core/tmp-glibc/work/x86_64-linux/db-native/5.3.28/recipe-sysroot-native/usr/include
-D_GNU_SOURCE -D_REENTRANT
-L/OE/build/oe-core/tmp-glibc/work/x86_64-linux/db-native/5.3.28/recipe-sysroot-native/usr/lib
-L/OE/build/oe-core/tmp-glibc/work/x86_64-linux/db-native/5.3.28/recipe-sysroot-native/lib
-Wl,--enable-new-dtags
-Wl,-rpath-link,/OE/build/oe-core/tmp-glibc/work/x86_64-linux/db-native/5.3.28/recipe-sysroot-native/usr/lib
-Wl,-rpath-link,/OE/build/oe-core/tmp-glibc/work/x86_64-linux/db-native/5.3.28/recipe-sysroot-native/lib
-Wl,-rpath,/OE/build/oe-core/tmp-glibc/work/x86_64-linux/db-native/5.3.28/recipe-sysroot-native/usr/lib
-Wl,-rpath,/OE/build/oe-core/tmp-glibc/work/x86_64-linux/db-native/5.3.28/recipe-sysroot-native/lib
-Wl,-O1 conftest.c -lpthread >&5
conftest.c:47:1: error: return type defaults to 'int' [-Wimplicit-int]
47 | main() {
| ^~~~
configure:22925: $? = 1
configure: program exited with status 1
* comparing target db with and without this change shows following diff
in log.do_configure:
db $ diff 5.3.28*/temp/log.do_configure
268c268
< checking for mutexes... POSIX/pthreads/library
---
> checking for mutexes... POSIX/pthreads/library/x86_64/gcc-assembly
271c271
< checking for atomic operations... no
---
> checking for atomic operations... x86/gcc-assembly
Signed-off-by: Martin Jansa
---
meta/recipes-support/db/db_5.3.28.bb | 4
1 file changed, 4 insertions(+)
diff --git a/meta/recipes-support/db/db_5.3.28.bb
b/meta/recipes-support/db/db_5.3.28.bb
index a99d5cea62..a7d061e0da 100644
--- a/meta/recipes-support/db/db_5.3.28.bb
+++ b/meta/recipes-support/db/db_5.3.28.bb
@@ -116,3 +116,7 @@ INSANE_SKIP:${PN} = "dev-so"
INSANE_SKIP:${PN}-cxx = "dev-so"
BBCLASSEXTEND = "native nativesdk"
+
+# many configure tests are failing with gcc-14
+CFLAGS += "-Wno-error=implicit-int -Wno-error=implicit-function-declaration"
+BUILD_CFLAGS += "-Wno-error=implicit-int
-Wno-error=implicit-function-declaration"
--
2.45.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13):
https://lists.openembedded.org/g/openembedded-core/message/13
Mute This Topic: https://lists.openembedded.org/mt/106364949/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] layer.conf: Add os-release to SIGGEN_EXCLUDERECIPES_ABISAFE
SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS is weaker version of SIGGEN_EXCLUDERECIPES_ABISAFE to mark it ABI safe only for some recipes. As you mark it ABI safe globally then the os-release entries in SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS shouldn't be needed, they don't harm except few more cpu cycles, I've just noticed it's strange. On Fri, May 24, 2024 at 6:31 PM Jose Quaresma wrote: > > > > Martin Jansa escreveu (sexta, 24/05/2024 à(s) 17:22): >> >> >> diff --git a/meta/conf/layer.conf b/meta/conf/layer.conf >> >> index f2bca0aa5ba..65eb657fd93 100644 >> >> --- a/meta/conf/layer.conf >> >> +++ b/meta/conf/layer.conf >> >> @@ -45,6 +45,7 @@ SIGGEN_EXCLUDERECIPES_ABISAFE += " \ >> >>ca-certificates \ >> >>shared-mime-info \ >> >>desktop-file-utils \ >> >> + os-release \ >> > >> > >> > Acked-by: Jose Quaresma >> > >> > I've had this on the Linux microPlatform distro for a while now but I >> > forgot to submit >> > https://github.com/foundriesio/meta-lmp/blob/efe9acade717181a5b9d3c520d90aa53049abb27/meta-lmp-base/conf/layer.conf#L37 >> >> You can drop few lines from SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS there as well :). > > > I can try to see if I still need to have it, this one was to store and re-use > the initramfs on the sstate-cache. > Without that I sometimes need to rebuild the kernel when this would not be > necessary. > All of that was validated on the kirkstone branch. > > Anyway, I will take a look. > > Thanks for the tip. > > -- > Best regards, > > José Quaresma -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#199859): https://lists.openembedded.org/g/openembedded-core/message/199859 Mute This Topic: https://lists.openembedded.org/mt/106283450/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] layer.conf: Add os-release to SIGGEN_EXCLUDERECIPES_ABISAFE
>> diff --git a/meta/conf/layer.conf b/meta/conf/layer.conf >> index f2bca0aa5ba..65eb657fd93 100644 >> --- a/meta/conf/layer.conf >> +++ b/meta/conf/layer.conf >> @@ -45,6 +45,7 @@ SIGGEN_EXCLUDERECIPES_ABISAFE += " \ >>ca-certificates \ >>shared-mime-info \ >>desktop-file-utils \ >> + os-release \ > > > Acked-by: Jose Quaresma > > I've had this on the Linux microPlatform distro for a while now but I forgot > to submit > https://github.com/foundriesio/meta-lmp/blob/efe9acade717181a5b9d3c520d90aa53049abb27/meta-lmp-base/conf/layer.conf#L37 You can drop few lines from SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS there as well :). -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#199857): https://lists.openembedded.org/g/openembedded-core/message/199857 Mute This Topic: https://lists.openembedded.org/mt/106283450/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [RESEND][PATCH] insane: add patch-status to default ERROR_QA
* 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&id=61a881fdbe8b5a21c6276b8a5d06cc30486b1eb3
Signed-off-by: Martin Jansa
---
Resend
https://patchwork.yoctoproject.org/project/oe-core/patch/20240314070903.83765-1-martin.ja...@gmail.com/
now when scarthgap is released and master is open for development
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 99736830b9..6d2f83c6f7 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.45.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199853):
https://lists.openembedded.org/g/openembedded-core/message/199853
Mute This Topic: https://lists.openembedded.org/mt/106284256/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] base: Switch UNPACKDIR to a subdir of WORKDIR
On Wed, May 22, 2024 at 3:09 PM Richard Purdie via
lists.openembedded.org
wrote:
>
> On Wed, 2024-05-22 at 13:00 +, Peter Kjellerstedt wrote:
> > > -Original Message-
> > > From: openembedded-core@lists.openembedded.org
> > > On Behalf Of Richard Purdie
> > > Sent: den 22 maj 2024 11:28
> > > To: openembedded-core@lists.openembedded.org
> > > Subject: [OE-core] [PATCH 1/3] base: Switch UNPACKDIR to a subdir of
> > > WORKDIR
> > >
> > > Change do_unpack to unpack files to a subdirectory of WORKDIR instead of
> > > WORKDIR
> > > itself. There are several good reasons for this but it is mainly about
> > > being able
> > > to isolate the output of the unpack task and tell the files apart from
> > > other things
> > > which are created in workdir (logs, sysroots, temp dirs and more).
> > >
> > > This means that when the do_unpack task reruns, we can clean UNPACKDIR
> > > and know
> > > we have a standard point to start builds from.
> > >
> > > It also makes code in tools like devtool and recipetool easier.
> > >
> > > To reduce the impact to users, if a subdirectory under UNPACKDIR matches
> > > the first subdirectory under WORKDIR of S, that directory is moved into
> > > position
> > > inside WORKDIR. This preserves the behaviour of S = "${WORKDIR}/git",
> > > S = "${WORKDIR}/${BPN}" and other commonly used source directory setups.
> > >
> > > The directory is moved since sadly many autotools based projects can't
> > > cope with
> > > symlinks in their paths.
> > >
> > > The patch also updates reproducible and SOURCE_DATE_EPOCH handling to
> > > match the new potential source locations. We can get rid of the horrible
> > > list of hardcoded directories in WORKDIR to ignore from that code.
> > >
> > > Signed-off-by: Richard Purdie
> > > ---
> > > meta/classes-global/base.bbclass | 28 +++-
> > > meta/conf/bitbake.conf | 2 +-
> > > meta/lib/oe/reproducible.py | 19 ++-
> > > 3 files changed, 34 insertions(+), 15 deletions(-)
> > >
> > > diff --git a/meta/classes-global/base.bbclass
> > > b/meta/classes-global/base.bbclass
> > > index 066f3848f7c..13e91b24a3b 100644
> > > --- a/meta/classes-global/base.bbclass
> > > +++ b/meta/classes-global/base.bbclass
> > > @@ -153,20 +153,38 @@ python base_do_fetch() {
> > > }
> > >
> > > addtask unpack after do_fetch
> > > -do_unpack[dirs] = "${UNPACKDIR}"
> > > -
> > > -do_unpack[cleandirs] = "${@d.getVar('S') if
> > > os.path.normpath(d.getVar('S')) != os.path.normpath(d.getVar('WORKDIR'))
> > > else os.path.join('${S}', 'patches')}"
> > > +do_unpack[cleandirs] = "${UNPACKDIR}"
> > >
> > > python base_do_unpack() {
> > > +import shutil
> > > +
> > > +sourcedir = d.getVar('S')
> > > +# Intentionally keep SOURCE_BASEDIR internal to the task just for SDE
> > > +d.setVar("SOURCE_BASEDIR", sourcedir)
> > > +
> > > src_uri = (d.getVar('SRC_URI') or "").split()
> > > if not src_uri:
> > > return
> > >
> > > +basedir = None
> > > +unpackdir = d.getVar('UNPACKDIR')
> > > +workdir = d.getVar('WORKDIR')
> > > +if sourcedir.startswith(workdir) and not
> > > sourcedir.startswith(unpackdir):
> > > +basedir = sourcedir.replace(workdir, '').strip("/").split('/')[0]
> > > +if basedir:
> > > +bb.utils.remove(workdir + '/' + basedir, True)
> > > +d.setVar("SOURCE_BASEDIR", workdir + '/' + basedir)
> > > +
> > > try:
> > > fetcher = bb.fetch2.Fetch(src_uri, d)
> > > fetcher.unpack(d.getVar('UNPACKDIR'))
> > > except bb.fetch2.BBFetchException as e:
> > > bb.fatal("Bitbake Fetcher Error: " + repr(e))
> > > +
> > > +if basedir and os.path.exists(unpackdir + '/' + basedir):
> > > +# Compatibility magic to ensure ${WORKDIR}/git and
> > > ${WORKDIR}/${BP}
> > > +# as often used in S work as expected.
> > > +shutil.move(unpackdir + '/' + basedir, workdir + '/' + basedir)
> > > }
> > >
> > > SSTATETASKS += "do_deploy_source_date_epoch"
> > > @@ -199,8 +217,8 @@ addtask do_deploy_source_date_epoch_setscene
> > > addtask do_deploy_source_date_epoch before do_configure after do_patch
> > >
> > > python create_source_date_epoch_stamp() {
> > > -# Version: 1
> > > -source_date_epoch = oe.reproducible.get_source_date_epoch(d,
> > > d.getVar('S'))
> > > +# Version: 2
> > > +source_date_epoch = oe.reproducible.get_source_date_epoch(d,
> > > d.getVar('SOURCE_BASEDIR') or d.getVar('S'))
> > > oe.reproducible.epochfile_write(source_date_epoch,
> > > d.getVar('SDE_FILE'), d)
> > > }
> > > do_unpack[postfuncs] += "create_source_date_epoch_stamp"
> >
> > The following code is part of the anonymous python() function in
> > base.bbclass:
> >
> > if os.path.normpath(d.getVar("WORKDIR")) !=
> > os.path.normpath(d.getVar("S")):
> > d.appendVar("PSEUDO_IGNORE_PATHS", ",${S}")
> > if os.path.normpath(d.getVar("WORKDIR")) !=
> > os.
[OE-core] [PATCH v2] cdrtools-native: fix build with gcc-14
Fixes:
http://errors.yoctoproject.org/Errors/Details/770525/
| checking whether the C compiler (gcc
-isystem/OE/build/oe-core/tmp-glibc/work/x86_64-linux/cdrtools-native/3.01/recipe-sysroot-native/usr/include
-O2 -pipe ) works... no
| configure: error: installation or configuration problem: C compiler cannot
create executables.
| RULES/rules.cnf:70:
incs/amd-ryzen-threadripper-3970x-32-core-processor-linux-cc/rules.cnf: No such
file or directory
| make: *** [RULES/rules.cnf:59:
incs/amd-ryzen-threadripper-3970x-32-core-processor-linux-cc/rules.cnf] Error 1
| make: *** Waiting for unfinished jobs
where config.log show it's caused by gcc-14:
configure:1189: checking whether the C compiler (gcc
-isystem/OE/build/oe-core/tmp-glibc/work/x86_64-linux/cdrtools-native/3.01/recipe-sysroot-native/usr/include
-O2 -pipe ) works
configure:1211: gcc -o conftest
-isystem/OE/build/oe-core/tmp-glibc/work/x86_64-linux/cdrtools-native/3.01/recipe-sysroot-native/usr/include
-O2 -pipe -D_GNU_SOURCE conftest.c 1>&5
configure:1208:1: error: return type defaults to 'int' [-Wimplicit-int]
configure: failed program was:
main(){return(0);}
Signed-off-by: Martin Jansa
---
v2: drop last minute change from make to oe_runmake in do_install which caused
INS_BASE=${prefix} not to be respected
meta/recipes-devtools/cdrtools/cdrtools-native_3.01.bb | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/cdrtools/cdrtools-native_3.01.bb
b/meta/recipes-devtools/cdrtools/cdrtools-native_3.01.bb
index bf8be1ad0c..0fe661ae6a 100644
--- a/meta/recipes-devtools/cdrtools/cdrtools-native_3.01.bb
+++ b/meta/recipes-devtools/cdrtools/cdrtools-native_3.01.bb
@@ -19,13 +19,17 @@ SRC_URI = " \
SRC_URI[md5sum] = "7d45c5b7e1f78d85d1583b361aee6e8b"
SRC_URI[sha256sum] =
"ed282eb6276c4154ce6a0b5dee0bdb81940d0cbbfc7d03f769c4735ef5f5860f"
-EXTRA_OEMAKE = "-e MAKEFLAGS="
+EXTRA_OEMAKE = "-e MAKEFLAGS= CPPOPTX='${CPPFLAGS}' COPTX='${CFLAGS}'
C++OPTX='${CXXFLAGS}' LDOPTX='${LDFLAGS}' GMAKE_NOWARN='true'"
# Stop failures when 'cc' can't be found
export ac_cv_prog_CC = "${CC}"
inherit native
+# Use -std=gnu89 to build with gcc-14 (https://bugs.gentoo.org/903876)
+# this needs to be after native inherit (which sets CFLAGS to BUILD_CFLAGS)
+CFLAGS += "-std=gnu89"
+
do_configure() {
install -m 0755 ${STAGING_DATADIR_NATIVE}/gnu-config/config.sub
${S}/autoconf
install -m 0755 ${STAGING_DATADIR_NATIVE}/gnu-config/config.guess
${S}/autoconf
--
2.45.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199603):
https://lists.openembedded.org/g/openembedded-core/message/199603
Mute This Topic: https://lists.openembedded.org/mt/106219053/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] cdrtools-native: fix build with gcc-14
That doesn't fix that, I did the upgrade first and Ross was already
looking for cdrtools alternatives, so I went with minimal fix for
gcc-14 on host.
On Mon, May 20, 2024 at 8:45 PM Khem Raj wrote:
>
> perhaps we should try to upgrade to
> https://sourceforge.net/projects/cdrtools/files/alpha/cdrtools-3.02a09.tar.bz2
> this is last release of cdrtools and other distros are packaging it
> too, I am not sure if it will fix this issue but we might be
> able to share fixes. We should also explore options to replace this
> dependency for live/iso image generation.
>
> On Mon, May 20, 2024 at 7:34 AM Martin Jansa via
> lists.openembedded.org
> wrote:
> >
> > Fixes:
> > http://errors.yoctoproject.org/Errors/Details/770525/
> > | checking whether the C compiler (gcc
> > -isystem/OE/build/oe-core/tmp-glibc/work/x86_64-linux/cdrtools-native/3.01/recipe-sysroot-native/usr/include
> > -O2 -pipe ) works... no
> > | configure: error: installation or configuration problem: C compiler
> > cannot create executables.
> > | RULES/rules.cnf:70:
> > incs/amd-ryzen-threadripper-3970x-32-core-processor-linux-cc/rules.cnf: No
> > such file or directory
> > | make: *** [RULES/rules.cnf:59:
> > incs/amd-ryzen-threadripper-3970x-32-core-processor-linux-cc/rules.cnf]
> > Error 1
> > | make: *** Waiting for unfinished jobs
> >
> > where config.log show it's caused by gcc-14:
> >
> > configure:1189: checking whether the C compiler (gcc
> > -isystem/OE/build/oe-core/tmp-glibc/work/x86_64-linux/cdrtools-native/3.01/recipe-sysroot-native/usr/include
> > -O2 -pipe ) works
> > configure:1211: gcc -o conftest
> > -isystem/OE/build/oe-core/tmp-glibc/work/x86_64-linux/cdrtools-native/3.01/recipe-sysroot-native/usr/include
> > -O2 -pipe -D_GNU_SOURCE conftest.c 1>&5
> > configure:1208:1: error: return type defaults to 'int' [-Wimplicit-int]
> > configure: failed program was:
> >
> > main(){return(0);}
> >
> > Signed-off-by: Martin Jansa
> > ---
> > meta/recipes-devtools/cdrtools/cdrtools-native_3.01.bb | 8 ++--
> > 1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/meta/recipes-devtools/cdrtools/cdrtools-native_3.01.bb
> > b/meta/recipes-devtools/cdrtools/cdrtools-native_3.01.bb
> > index bf8be1ad0c..239b351933 100644
> > --- a/meta/recipes-devtools/cdrtools/cdrtools-native_3.01.bb
> > +++ b/meta/recipes-devtools/cdrtools/cdrtools-native_3.01.bb
> > @@ -19,13 +19,17 @@ SRC_URI = " \
> > SRC_URI[md5sum] = "7d45c5b7e1f78d85d1583b361aee6e8b"
> > SRC_URI[sha256sum] =
> > "ed282eb6276c4154ce6a0b5dee0bdb81940d0cbbfc7d03f769c4735ef5f5860f"
> >
> > -EXTRA_OEMAKE = "-e MAKEFLAGS="
> > +EXTRA_OEMAKE = "-e MAKEFLAGS= CPPOPTX='${CPPFLAGS}' COPTX='${CFLAGS}'
> > C++OPTX='${CXXFLAGS}' LDOPTX='${LDFLAGS}' GMAKE_NOWARN='true'"
> >
> > # Stop failures when 'cc' can't be found
> > export ac_cv_prog_CC = "${CC}"
> >
> > inherit native
> >
> > +# Use -std=gnu89 to build with gcc-14 (https://bugs.gentoo.org/903876)
> > +# this needs to be after native inherit (which sets CFLAGS to BUILD_CFLAGS)
> > +CFLAGS += "-std=gnu89"
> > +
> > do_configure() {
> > install -m 0755 ${STAGING_DATADIR_NATIVE}/gnu-config/config.sub
> > ${S}/autoconf
> > install -m 0755 ${STAGING_DATADIR_NATIVE}/gnu-config/config.guess
> > ${S}/autoconf
> > @@ -33,5 +37,5 @@ do_configure() {
> > }
> >
> > do_install() {
> > - make install GMAKE_NOWARN=true INS_BASE=${prefix} DESTDIR=${D}
> > + oe_runmake install INS_BASE=${prefix} DESTDIR=${D}
> > }
> > --
> > 2.45.1
> >
> >
> >
> >
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199602):
https://lists.openembedded.org/g/openembedded-core/message/199602
Mute This Topic: https://lists.openembedded.org/mt/106204338/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] cdrtools-native: fix build with gcc-14
Fixes:
http://errors.yoctoproject.org/Errors/Details/770525/
| checking whether the C compiler (gcc
-isystem/OE/build/oe-core/tmp-glibc/work/x86_64-linux/cdrtools-native/3.01/recipe-sysroot-native/usr/include
-O2 -pipe ) works... no
| configure: error: installation or configuration problem: C compiler cannot
create executables.
| RULES/rules.cnf:70:
incs/amd-ryzen-threadripper-3970x-32-core-processor-linux-cc/rules.cnf: No such
file or directory
| make: *** [RULES/rules.cnf:59:
incs/amd-ryzen-threadripper-3970x-32-core-processor-linux-cc/rules.cnf] Error 1
| make: *** Waiting for unfinished jobs
where config.log show it's caused by gcc-14:
configure:1189: checking whether the C compiler (gcc
-isystem/OE/build/oe-core/tmp-glibc/work/x86_64-linux/cdrtools-native/3.01/recipe-sysroot-native/usr/include
-O2 -pipe ) works
configure:1211: gcc -o conftest
-isystem/OE/build/oe-core/tmp-glibc/work/x86_64-linux/cdrtools-native/3.01/recipe-sysroot-native/usr/include
-O2 -pipe -D_GNU_SOURCE conftest.c 1>&5
configure:1208:1: error: return type defaults to 'int' [-Wimplicit-int]
configure: failed program was:
main(){return(0);}
Signed-off-by: Martin Jansa
---
meta/recipes-devtools/cdrtools/cdrtools-native_3.01.bb | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-devtools/cdrtools/cdrtools-native_3.01.bb
b/meta/recipes-devtools/cdrtools/cdrtools-native_3.01.bb
index bf8be1ad0c..239b351933 100644
--- a/meta/recipes-devtools/cdrtools/cdrtools-native_3.01.bb
+++ b/meta/recipes-devtools/cdrtools/cdrtools-native_3.01.bb
@@ -19,13 +19,17 @@ SRC_URI = " \
SRC_URI[md5sum] = "7d45c5b7e1f78d85d1583b361aee6e8b"
SRC_URI[sha256sum] =
"ed282eb6276c4154ce6a0b5dee0bdb81940d0cbbfc7d03f769c4735ef5f5860f"
-EXTRA_OEMAKE = "-e MAKEFLAGS="
+EXTRA_OEMAKE = "-e MAKEFLAGS= CPPOPTX='${CPPFLAGS}' COPTX='${CFLAGS}'
C++OPTX='${CXXFLAGS}' LDOPTX='${LDFLAGS}' GMAKE_NOWARN='true'"
# Stop failures when 'cc' can't be found
export ac_cv_prog_CC = "${CC}"
inherit native
+# Use -std=gnu89 to build with gcc-14 (https://bugs.gentoo.org/903876)
+# this needs to be after native inherit (which sets CFLAGS to BUILD_CFLAGS)
+CFLAGS += "-std=gnu89"
+
do_configure() {
install -m 0755 ${STAGING_DATADIR_NATIVE}/gnu-config/config.sub
${S}/autoconf
install -m 0755 ${STAGING_DATADIR_NATIVE}/gnu-config/config.guess
${S}/autoconf
@@ -33,5 +37,5 @@ do_configure() {
}
do_install() {
- make install GMAKE_NOWARN=true INS_BASE=${prefix} DESTDIR=${D}
+ oe_runmake install INS_BASE=${prefix} DESTDIR=${D}
}
--
2.45.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199594):
https://lists.openembedded.org/g/openembedded-core/message/199594
Mute This Topic: https://lists.openembedded.org/mt/106204338/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] glibc: correct license
On Thu, May 16, 2024 at 10:05 PM Khem Raj wrote: > > On Wed, May 15, 2024 at 10:29 PM Martin Jansa via > lists.openembedded.org > wrote: > > > > Hi Peter, > > > > what about BSD-4-Clause-UC, BSD-3-Clause, ISC licenses included in glibc. > > > > I've suggested to add them long time ago in: > > https://lists.openembedded.org/g/openembedded-core/topic/91285771#msg166005 > > which resulted in: > > https://sourceware.org/bugzilla/show_bug.cgi?id=28007 > > https://sourceware.org/pipermail/libc-alpha/2022-May/139167.html > > but the discussion upstream stopped shortly after and the oe-core > > change was never merged because of that. Maybe it's time to re-check > > and ping upstream again after 2 years. > > Perhaps yes. > > On a tangent here, but I also think we should use > https://github.com/nexB/scancode-toolkit > to extract the license information from source code itself to update > the LICENSE field > in the recipes. Yeah, we've added it 10+ years ago, because Blackduck or something was complaining about missing license identifiers in: https://github.com/openwebos/meta-webos/commit/8eb313e4303defbe495cf7f91974799046975fca then I've dropped this 2 years ago in: https://github.com/webosose/meta-webosose/commit/95d7c2798d6f0a7a227db9631775eff7a2928596 after failed attempt to upstream this to oe-core and upstream glibc reaction. The LICENSE information in the recipe isn't complete and as Peter wanted to fix "or later" part I though he might be interested in other licenses as well. There weren't many changes in: https://sourceware.org/git/?p=glibc.git;a=history;f=LICENSES;h=530893b1dc9ea00755603c68fb36bd4fc38a7be8;hb=HEAD but the last commit looks interesting. Cheers, -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#199498): https://lists.openembedded.org/g/openembedded-core/message/199498 Mute This Topic: https://lists.openembedded.org/mt/105935723/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] glibc: correct license
Hi Peter, what about BSD-4-Clause-UC, BSD-3-Clause, ISC licenses included in glibc. I've suggested to add them long time ago in: https://lists.openembedded.org/g/openembedded-core/topic/91285771#msg166005 which resulted in: https://sourceware.org/bugzilla/show_bug.cgi?id=28007 https://sourceware.org/pipermail/libc-alpha/2022-May/139167.html but the discussion upstream stopped shortly after and the oe-core change was never merged because of that. Maybe it's time to re-check and ping upstream again after 2 years. Cheers, On Mon, May 6, 2024 at 9:46 AM Peter Marko via lists.openembedded.org wrote: > > From: Peter Marko > > The license per [1] is LGPL-2.1-or-later and > [2] converted last LGPL-2.1-only references. > > License-Update: corrected from LGPL-2.1-only to LGPL-2.1-or-later based on > [1] and [2] > > [1] https://www.gnu.org/software/libc/ > [2] > https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=273a835fe7c685cc54266bb8b502787bad5e9bae > > Signed-off-by: Peter Marko > --- > meta/recipes-core/glibc/glibc-common.inc | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/meta/recipes-core/glibc/glibc-common.inc > b/meta/recipes-core/glibc/glibc-common.inc > index b9516e77f0..91a3f5bcd5 100644 > --- a/meta/recipes-core/glibc/glibc-common.inc > +++ b/meta/recipes-core/glibc/glibc-common.inc > @@ -2,7 +2,7 @@ SUMMARY = "GLIBC (GNU C Library)" > DESCRIPTION = "The GNU C Library is used as the system C library in most > systems with the Linux kernel." > HOMEPAGE = "http://www.gnu.org/software/libc/libc.html"; > SECTION = "libs" > -LICENSE = "GPL-2.0-only & LGPL-2.1-only" > +LICENSE = "GPL-2.0-only & LGPL-2.1-or-later" > > LIC_FILES_CHKSUM ?= "file://LICENSES;md5=f77e878d320e99e94ae9a4aea7f491d1 \ >file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263 \ > -- > 2.30.2 > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#199437): https://lists.openembedded.org/g/openembedded-core/message/199437 Mute This Topic: https://lists.openembedded.org/mt/105935723/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 04/11] zip lrzsz connman-gnome libfm: ignore various issues fatal with gcc-14
On Tue, May 7, 2024 at 7:33 AM Khem Raj wrote: > > From: Martin Jansa > > work arounds for: > oe-core/meta/recipes-bsp/lrzsz/lrzsz_0.12.20.bb:do_compile > oe-core/meta/recipes-connectivity/connman/connman-gnome_0.7.bb:do_compile > oe-core/meta/recipes-support/libfm/libfm_1.3.2.bb:do_compile > oe-core/meta/recipes-extended/zip/zip_3.0.bb:do_compile > > http://errors.yoctoproject.org/Errors/Build/183127/ > > More fixes on ML (especially for -native with gcc-14 on host) > zip: https://lists.openembedded.org/g/openembedded-core/message/198783 > cdrtools: https://lists.openembedded.org/g/openembedded-core/message/198899 > syslinux: https://lists.openembedded.org/g/openembedded-core/message/198901 > > Signed-off-by: Martin Jansa > Signed-off-by: Khem Raj > --- ... > diff --git a/meta/recipes-extended/zip/zip_3.0.bb > b/meta/recipes-extended/zip/zip_3.0.bb > index 70df5ab8728..e7705b8faf4 100644 > --- a/meta/recipes-extended/zip/zip_3.0.bb > +++ b/meta/recipes-extended/zip/zip_3.0.bb > @@ -53,3 +53,8 @@ BBCLASSEXTEND = "native" > > # exclude version 2.3.2 which triggers a false positive > UPSTREAM_CHECK_REGEX = "^zip(?P(?!232).+)\.tgz" > + > +# http://errors.yoctoproject.org/Errors/Details/766953/ > +# unix/unix.c:84:51: error: passing argument 4 of 'fread' from incompatible > pointer type [-Wincompatible-pointer-types] > +CFLAGS += "-Wno-error=incompatible-pointer-types" > +# proper fix on ML: > https://lists.openembedded.org/g/openembedded-core/message/198783 I think we should take the proper fix from ML instead of this work around (I just haven't tested it yet). -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#199079): https://lists.openembedded.org/g/openembedded-core/message/199079 Mute This Topic: https://lists.openembedded.org/mt/105955494/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 3/4] recipes: Update S = WORKDIR recipes to use ${S} correctly
On Wed, May 1, 2024 at 11:56 PM Richard Purdie via
lists.openembedded.org
wrote:
>
> Where recipes use S = ${WORKDIR}, ensure they are referencing ${S} correctly
> to access files as soon we want to stop doing this in WORKDIR at which point
> they would break unless corrected.
-LIC_FILES_CHKSUM =
"file://${WORKDIR}/LICENSE-OASIS;md5=c608985dd5f7f215e669e7639a0b1d2e"
+LIC_FILES_CHKSUM =
"file://${S}/LICENSE-OASIS;md5=c608985dd5f7f215e669e7639a0b1d2e"
Isn't LIC_FILES_CHKSUM usually relative path from ${S} so all of these
changes could just drop the ${S} now?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199069):
https://lists.openembedded.org/g/openembedded-core/message/199069
Mute This Topic: https://lists.openembedded.org/mt/105852187/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 04/10] zip lrzsz connman-gnome kea libfm: ignore various issues fatal with gcc-14
kea should be dropped from this (commit message as well as the bbfile)
I had a fix in my jansa/master-gcc14 branch and now you have a
different one in this series, so the TODO here doesn't make sense
anymore, you can pick it from:
https://git.openembedded.org/openembedded-core-contrib/commit/?h=jansa/master-gcc14&id=4c89509e37f86f4d8e0bfce6135e6eaefd9e216f
as mentioned yesterday
On Tue, May 7, 2024 at 3:15 AM Khem Raj wrote:
>
> From: Martin Jansa
>
> TODO: kea
>
> work arounds for:
> oe-core/meta/recipes-bsp/lrzsz/lrzsz_0.12.20.bb:do_compile
> oe-core/meta/recipes-connectivity/connman/connman-gnome_0.7.bb:do_compile
> oe-core/meta/recipes-connectivity/kea/kea_2.4.1.bb:do_compile
> oe-core/meta/recipes-support/libfm/libfm_1.3.2.bb:do_compile
> oe-core/meta/recipes-extended/zip/zip_3.0.bb:do_compile
>
> http://errors.yoctoproject.org/Errors/Build/183127/
>
> More fixes on ML (especially for -native with gcc-14 on host)
> zip: https://lists.openembedded.org/g/openembedded-core/message/198783
> cdrtools: https://lists.openembedded.org/g/openembedded-core/message/198899
> syslinux: https://lists.openembedded.org/g/openembedded-core/message/198901
>
> Signed-off-by: Martin Jansa
> Signed-off-by: Khem Raj
> ---
> meta/recipes-bsp/lrzsz/lrzsz_0.12.20.bb| 6 ++
> meta/recipes-connectivity/connman/connman-gnome_0.7.bb | 4
> meta/recipes-connectivity/kea/kea_2.4.1.bb | 6 ++
> meta/recipes-extended/zip/zip_3.0.bb | 5 +
> meta/recipes-support/libfm/libfm_1.3.2.bb | 4
> 5 files changed, 25 insertions(+)
>
> diff --git a/meta/recipes-bsp/lrzsz/lrzsz_0.12.20.bb
> b/meta/recipes-bsp/lrzsz/lrzsz_0.12.20.bb
> index 63edcbd8643..3024ddcaf07 100644
> --- a/meta/recipes-bsp/lrzsz/lrzsz_0.12.20.bb
> +++ b/meta/recipes-bsp/lrzsz/lrzsz_0.12.20.bb
> @@ -46,3 +46,9 @@ ALTERNATIVE_TARGET[rb] = "${bindir}/lrz"
> ALTERNATIVE_TARGET[sz] = "${bindir}/lsz"
> ALTERNATIVE_TARGET[sx] = "${bindir}/lsz"
> ALTERNATIVE_TARGET[sb] = "${bindir}/lsz"
> +
> +# http://errors.yoctoproject.org/Errors/Details/766929/
> +# lrzsz-0.12.20/src/tcp.c:75:56: error: passing argument 3 of 'getsockname'
> from incompatible pointer type [-Wincompatible-pointer-types]
> +# lrzsz-0.12.20/src/tcp.c:83:52: error: passing argument 3 of 'getsockname'
> from incompatible pointer type [-Wincompatible-pointer-types]
> +# lrzsz-0.12.20/src/tcp.c:103:51: error: passing argument 3 of 'accept' from
> incompatible pointer type [-Wincompatible-pointer-types]
> +CFLAGS += "-Wno-error=incompatible-pointer-types"
> diff --git a/meta/recipes-connectivity/connman/connman-gnome_0.7.bb
> b/meta/recipes-connectivity/connman/connman-gnome_0.7.bb
> index f6150d98ec9..46b3f854c52 100644
> --- a/meta/recipes-connectivity/connman/connman-gnome_0.7.bb
> +++ b/meta/recipes-connectivity/connman/connman-gnome_0.7.bb
> @@ -28,3 +28,7 @@ RDEPENDS:${PN} = "connman"
> do_install:append() {
> install -m 0644 ${UNPACKDIR}/images/*
> ${D}/usr/share/icons/hicolor/22x22/apps/
> }
> +
> +# http://errors.yoctoproject.org/Errors/Details/766926/
> +# connman-client.c:200:15: error: assignment to 'GtkTreeModel *' {aka
> 'struct _GtkTreeModel *'} from incompatible pointer type 'GtkTreeStore *'
> {aka 'struct _GtkTreeStore *'} [-Wincompatible-pointer-types]
> +CFLAGS += "-Wno-error=incompatible-pointer-types"
> diff --git a/meta/recipes-connectivity/kea/kea_2.4.1.bb
> b/meta/recipes-connectivity/kea/kea_2.4.1.bb
> index 6c1e457938a..fc963e545ad 100644
> --- a/meta/recipes-connectivity/kea/kea_2.4.1.bb
> +++ b/meta/recipes-connectivity/kea/kea_2.4.1.bb
> @@ -75,3 +75,9 @@ FILES:${PN}-staticdev += "${libdir}/kea/hooks/*.a
> ${libdir}/hooks/*.a"
> FILES:${PN} += "${libdir}/hooks/*.so"
>
> PARALLEL_MAKEINST = ""
> +
> +# http://errors.yoctoproject.org/Errors/Details/766928/
> +#
> TOPDIR/BUILD/work/qemux86_64-webos-linux/kea/2.4.1/recipe-sysroot-native/usr/bin/x86_64-webos-linux/../../libexec/x86_64-webos-linux/gcc/x86_64-webos-linux/14.0.1/ld:
> ./.libs/libdhcp4.a(dhcp4_srv.o): in function `isc::dhcp::OptionDescriptor
> isc::dhcp::CfgOption::get(char const (&) [6], unsigned short)
> const':
> +#
> /usr/src/debug/kea/2.4.1/src/lib/dhcpsrv/cfg_option.h:608:(.text._ZNK3isc4dhcp9CfgOption3getIA6_cEENS0_16OptionDescriptorERKT_t[_ZNK3isc4dhcp9CfgOption3getIA6_cEENS0_16OptionDescriptorERKT_t]+0x85):
> undefined reference to
> `isc::dhcp::CfgOption::getAll(std::__cxx11::basic_string std::char_traits, std::allocator > const&) const'
> +# collect2
Re: [OE-core] [PATCH] openssl: fix pkg-config file libdir from /usr back to /usr/lib
On Fri, May 3, 2024 at 12:46 PM Mikko Rapeli wrote:
>
> Hi,
>
> On Fri, May 03, 2024 at 12:43:29PM +0200, Martin Jansa wrote:
> > On Fri, May 3, 2024 at 12:37 PM Mikko Rapeli via
> > lists.openembedded.org
> > wrote:
> > >
> > > Hi,
> > >
> > > On Fri, May 03, 2024 at 12:32:42PM +0200, Alexander Kanavin wrote:
> > > > I’m sorry, this doesn’t look right. Shouldn’t we rather ensure
> > > > $(LIBDIR) is
> > > > correctly set? Besides, hardcoding to lib is certainly incorrect as it
> > > > will
> > > > break multilib. We constantly have to fix upstreams in the opposite
> > > > direction.
> > >
> > > Yes, you and Ross on #yocto are right. This is not right. I tried also
> > > setting
> > > LIBDIR=${BASELIB} in do_install() and do_configure but those did not work
> > > either. openssl builds scripts are quite hard to work with...
> >
> > Isn't it easier to fix tpm2-openssl then?
> >
> > I had similar issue in chip which was using "pkg-config
> > --variable=prefix openssl" and didn't expect it to be empty in "if
> > prefix[-4] == '/usr'" and rather patched chip than changing openssl.
>
> To me this is a bug/regression in openssl pkg-config since libdir changed
> from /usr/lib to /usr which doesn't work for same use cases anymore.
OK, then it would be appropriate to report and resolve with openssl
upstream, right? Not with Inappropriate .patch :).
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#198975):
https://lists.openembedded.org/g/openembedded-core/message/198975
Mute This Topic: https://lists.openembedded.org/mt/105885236/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] openssl: fix pkg-config file libdir from /usr back to /usr/lib
On Fri, May 3, 2024 at 12:37 PM Mikko Rapeli via
lists.openembedded.org
wrote:
>
> Hi,
>
> On Fri, May 03, 2024 at 12:32:42PM +0200, Alexander Kanavin wrote:
> > I’m sorry, this doesn’t look right. Shouldn’t we rather ensure $(LIBDIR) is
> > correctly set? Besides, hardcoding to lib is certainly incorrect as it will
> > break multilib. We constantly have to fix upstreams in the opposite
> > direction.
>
> Yes, you and Ross on #yocto are right. This is not right. I tried also setting
> LIBDIR=${BASELIB} in do_install() and do_configure but those did not work
> either. openssl builds scripts are quite hard to work with...
Isn't it easier to fix tpm2-openssl then?
I had similar issue in chip which was using "pkg-config
--variable=prefix openssl" and didn't expect it to be empty in "if
prefix[-4] == '/usr'" and rather patched chip than changing openssl.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#198972):
https://lists.openembedded.org/g/openembedded-core/message/198972
Mute This Topic: https://lists.openembedded.org/mt/105885236/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] 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(&img, tif,
> stop_on_error, emsg)) {
> ++if (row >= img.height)
> ++{
> ++TIFFErrorExt(tif->tif_clientdata, TIFFFileName(tif),
> ++ "Invalid row passed to TIFFReadRGBAStrip().");
> ++TIFFRGBAImageEnd(&img);
> ++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(&img);
> ++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
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&q=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&q=Upstream-Status
Some examples in other layers:
https://git.yoctoproject.org/meta-security/log/?qt=grep&q=Upstream-Status
https://git.yoctoproject.org/meta-raspberrypi/log/?qt=grep&q=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&id=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', '
> > usr
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&id=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&id=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(-) > > > + >
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/recip
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() autogenera
Re: [OE-core] bb.utils.vercmp_string_op() vs Python 3.12
See
https://git.openembedded.org/meta-openembedded/commit/?h=kirkstone&id=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 +
> + linu
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]
-=-=-=-=-=-=-=-=-=-=-=-
