Re: [OE-Core][PATCH v4 03/10] meta-selftest: hello-rs: Simple rust test recipe
On Sat, Dec 30, 2023 at 12:41 AM Richard Purdie wrote: > > On Fri, 2023-12-29 at 14:04 +0200, Alexander Kanavin wrote: > > Reproducibility exclusions should be listed in the test itself, so > > this continues to be built in regular world builds (otherwise it may > > silently regress). > > FWIW this is what the zvariant recipe was doing and the recipe is in > meta-selftest... > > I'm torn on it to be honest. > I'm fine with changing it (and I did basically copy from zvariant without really thinking about it), but I do feel that leaking what's a pretty poor recipe name (`hello-rs`) outside of meta-selftest into the wider ecosystem wouldn't be ideal as the recipe itself is basically useless other than for this specific test purpose. Mostly I just want to get the series merged before anything else changes and we find yet another thing which needs fixing; also I think I've got 1.75.0 building now, which obviously sits on top of this series! -- Alex Kiernan -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#193067): https://lists.openembedded.org/g/openembedded-core/message/193067 Mute This Topic: https://lists.openembedded.org/mt/103415636/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-Core][PATCH v4 00/10] Stepwise rust upgrade 1.71.1 -> 1.74.1
On Fri, 2023-12-29 at 11:44 +, Alex Kiernan wrote: > This is the 1.74.1 rust series rebased to include a revert of > https://github.com/rust-lang/cc-rs/commit/c4f414f449bb7cffba3bc923f277704d1d08a8ec > which I'm pretty sure is what's causing our filename churn. I've checked > 1.72.0 and 1.74.1 for the absvdi2.o intrinsic (one of many intrinsics > which had the issue) and in both cases we're not generating the dirname > based prefix - hopefully that means that the interim commits are fine > too, if not we can do the step back through the commits to find the next > issue. > > Changes in v4: > - Mark hello-rs as EXCLUDE_FROM_WORLD as it's not reproducible > > Changes in v3: > - Add hello-rs as a replacement for the tests which used zvariant > > Changes in v2: > - Skip zvariant based test rather than deleting it. > > Alex Kiernan (10): > devtool: selftest: Fix test_devtool_modify_git_crates_subpath > inequality > devtool: selftest: Fix test_devtool_modify_git_crates_subpath bbappend > check > meta-selftest: hello-rs: Simple rust test recipe > devtool: selftest: Swap to hello-rs for crates testing > zvariant: Drop recipe > rust: Upgrade 1.71.1 -> 1.72.0 > rust: Upgrade 1.72.0 -> 1.72.1 > rust: Upgrade 1.72.1 -> 1.73.0 > rust: Upgrade 1.73.0 -> 1.74.0 > rust: Upgrade 1.74.0 -> 1.74.1 Thanks for working through this, I've gone ahead and merged it :) I am a little worried that: * the test recipe isn't reproducible * we still have the tests disabled * the next version looks problematic but I think we're at the point it makes sense to move to the newer version. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#193068): https://lists.openembedded.org/g/openembedded-core/message/193068 Mute This Topic: https://lists.openembedded.org/mt/103415633/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-Core][PATCH v4 03/10] meta-selftest: hello-rs: Simple rust test recipe
On Sat, 2023-12-30 at 10:40 +, Alex Kiernan wrote: > On Sat, Dec 30, 2023 at 12:41 AM Richard Purdie > wrote: > > > > On Fri, 2023-12-29 at 14:04 +0200, Alexander Kanavin wrote: > > > Reproducibility exclusions should be listed in the test itself, so > > > this continues to be built in regular world builds (otherwise it may > > > silently regress). > > > > FWIW this is what the zvariant recipe was doing and the recipe is in > > meta-selftest... > > > > I'm torn on it to be honest. > > > > I'm fine with changing it (and I did basically copy from zvariant > without really thinking about it), but I do feel that leaking what's a > pretty poor recipe name (`hello-rs`) outside of meta-selftest into the > wider ecosystem wouldn't be ideal as the recipe itself is basically > useless other than for this specific test purpose. > > Mostly I just want to get the series merged before anything else > changes and we find yet another thing which needs fixing; also I think > I've got 1.75.0 building now, which obviously sits on top of this > series! I agree, it doesn't really change what we're doing and moves things forward so I'm considering it as a base to build on if/as/when we can. As such the series merged, thanks! :). Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#193069): https://lists.openembedded.org/g/openembedded-core/message/193069 Mute This Topic: https://lists.openembedded.org/mt/103415636/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [bitbake-devel] pthread_cancel bug on ubuntu2004/debian11
On Wed, 2023-12-27 at 11:30 -0700, Joshua Watt wrote:
> On Wed, Dec 27, 2023 at 4:28 AM Richard Purdie
> wrote:
> >
> > I wanted to write down some thoughts on this which I have all the
> > pieces handy.
> >
> > We saw a nightly layer check fail for meta-openembedded:
> >
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/121/builds/1798/steps/21/logs/stdio
> >
> > INFO: ==
> > INFO: ERROR: test_show_environment (common.CommonCheckLayer)
> > INFO: --
> > INFO: Traceback (most recent call last):
> > File
> > "/home/pokybuild/yocto-worker/check-layer-nightly/build/scripts/lib/checklayer/cases/common.py",
> > line 48, in test_show_environment
> > check_command('Layer %s failed to show environment.' %
> > self.tc.layer['name'],
> > File
> > "/home/pokybuild/yocto-worker/check-layer-nightly/build/scripts/lib/checklayer/__init__.py",
> > line 287, in check_command
> > raise RuntimeError(msg)
> > RuntimeError: Layer meta-gnome failed to show environment.
> > Command: bitbake -e
> > Output:
> > libgcc_s.so.1 must be installed for pthread_cancel to work
> > Aborted (core dumped)
> >
> > which unsurprisingly is on ubuntn 20.04. We've also seen issues like
> > this on Debian 11.
> >
> > I noticed:
> >
> > https://stackoverflow.com/questions/64797838/libgcc-s-so-1-must-be-installed-for-pthread-cancel-to-work
> >
> > and:
> >
> > https://bugs.ams1.psf.io/issue42888
> >
> > which led me to try:
> > ubuntu2004-ty-1:~$ wget
> > https://bugs.ams1.psf.io/file50112/pthread_cancel_bug.py
> > ubuntu2004-ty-1:~$ python3 pthread_cancel_bug.py
> > ubuntu2004-ty-1:~$ echo $?
> > 0
> > rpurdie@ubuntu2004-ty-1:~$ python3 pthread_cancel_bug.py
> > libgcc_s.so.1 must be installed for pthread_cancel to work
> > Aborted (core dumped)
> > ubuntu2004-ty-1:~$ python3 pthread_cancel_bug.py
> > libgcc_s.so.1 must be installed for pthread_cancel to work
> > Aborted (core dumped)
> > ubuntu2004-ty-1:~$ python3 pthread_cancel_bug.py
> > libgcc_s.so.1 must be installed for pthread_cancel to work
> > Aborted (core dumped)
> >
> > (1 in 4 success)
> >
> > Then adding to the script:
> > import ctypes
> > libgcc_s = ctypes.CDLL('libgcc_s.so.1')
> >
> > ubuntu2004-ty-1:~$ python3 pthread_cancel_bug.py
> > ubuntu2004-ty-1:~$ python3 pthread_cancel_bug.py
> > ubuntu2004-ty-1:~$ python3 pthread_cancel_bug.py
> > ubuntu2004-ty-1:~$ python3 pthread_cancel_bug.py
> > ubuntu2004-ty-1:~$ python3 pthread_cancel_bug.py
> > ubuntu2004-ty-1:~$ python3 pthread_cancel_bug.py
> > ubuntu2004-ty-1:~$ python3 pthread_cancel_bug.py
> > ubuntu2004-ty-1:~$ python3 pthread_cancel_bug.py
> > ubuntu2004-ty-1:~$ python3 pthread_cancel_bug.py
> > ubuntu2004-ty-1:~$ python3 pthread_cancel_bug.py
> > ubuntu2004-ty-1:~$ python3 pthread_cancel_bug.py
> > ubuntu2004-ty-1:~$ python3 pthread_cancel_bug.py
> > ubuntu2004-ty-1:~$ python3 pthread_cancel_bug.py
> > ubuntu2004-ty-1:~$ python3 --version
> > Python 3.8.10
> >
> > I also tried this on debian 11:
> >
> > debian11-ty-1:~$ python3 pthread_cancel_bug.py
> > libgcc_s.so.1 must be installed for pthread_cancel to work
> > Aborted
> >
> > debian11-ty-1:~$ python3 --version
> > Python 3.9.2
> >
> > where the above workaround using ctypes also seems to work.
> >
> > I'm therefore tempted for python 3.8/3.9 to preload libgcc_s as a
> > workaround for this...
>
> Seems reasonable to me, as long as we can restrict it to a specific
> version range of python and have a nice comment explaining why
Patch tested, sent and I've applied it to older bitbake branches too in
the hope that it helps some of Steve's autobuilder failures too.
Once we get to 3.10 as a minimum version we can drop it.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#193070):
https://lists.openembedded.org/g/openembedded-core/message/193070
Mute This Topic: https://lists.openembedded.org/mt/103388962/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][dunfell][PATCH] tzdata: Upgrade to 2023d
Hi Steve,
I have sent this patch to upgrade tzdata to the latest version "2023d" for
dunfell branch.
The mailing list link for the same:
https://lists.openembedded.org/g/openembedded-core/message/192913
Can you please check if this patch can be accepted in the dunfell-nut
branch of oe-core-contrib.
Thanks,
Shubham Kulkarni
On Tue, Dec 26, 2023 at 10:44 PM Shubham Kulkarni via lists.openembedded.org
wrote:
> From: Shubham Kulkarni
>
> Signed-off-by: Shubham Kulkarni
> ---
> meta/recipes-extended/timezone/timezone.inc | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/meta/recipes-extended/timezone/timezone.inc
> b/meta/recipes-extended/timezone/timezone.inc
> index 2960bfefe3..75f13cfc94 100644
> --- a/meta/recipes-extended/timezone/timezone.inc
> +++ b/meta/recipes-extended/timezone/timezone.inc
> @@ -6,7 +6,7 @@ SECTION = "base"
> LICENSE = "PD & BSD-3-Clause"
> LIC_FILES_CHKSUM = "file://LICENSE;md5=c679c9d6b02bc2757b3eaf8f53c43fba"
>
> -PV = "2023c"
> +PV = "2023d"
>
> SRC_URI ="
> http://www.iana.org/time-zones/repository/releases/tzcode${PV}.tar.gz;name=tzcode
> \
>
> http://www.iana.org/time-zones/repository/releases/tzdata${PV}.tar.gz;name=tzdata
> \
> @@ -14,5 +14,5 @@ SRC_URI ="
> http://www.iana.org/time-zones/repository/releases/tzcode${PV}.tar.gz
>
> UPSTREAM_CHECK_URI = "http://www.iana.org/time-zones";
>
> -SRC_URI[tzcode.sha256sum] =
> "46d17f2bb19ad73290f03a203006152e0fa0d7b11e5b71467c4a823811b214e7"
> -SRC_URI[tzdata.sha256sum] =
> "3f510b5d1b4ae9bb38e485aa302a776b317fb3637bdb6404c4adf7b6cadd965c"
> +SRC_URI[tzcode.sha256sum] =
> "e9a5f9e118886d2de92b62bb05510a28cc6c058d791c93bd6b84d3292c3c161e"
> +SRC_URI[tzdata.sha256sum] =
> "dbca21970b0a8b8c0ceceec1d7b91fa903be0f6eca5ae732b5329672232a08f3"
> --
> 2.42.0
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#193071):
https://lists.openembedded.org/g/openembedded-core/message/193071
Mute This Topic: https://lists.openembedded.org/mt/103372051/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-Core][PATCH v4 00/10] Stepwise rust upgrade 1.71.1 -> 1.74.1
On Sat, Dec 30, 2023 at 11:08 AM Richard Purdie wrote: > > On Fri, 2023-12-29 at 11:44 +, Alex Kiernan wrote: > > This is the 1.74.1 rust series rebased to include a revert of > > https://github.com/rust-lang/cc-rs/commit/c4f414f449bb7cffba3bc923f277704d1d08a8ec > > which I'm pretty sure is what's causing our filename churn. I've checked > > 1.72.0 and 1.74.1 for the absvdi2.o intrinsic (one of many intrinsics > > which had the issue) and in both cases we're not generating the dirname > > based prefix - hopefully that means that the interim commits are fine > > too, if not we can do the step back through the commits to find the next > > issue. > > > > Changes in v4: > > - Mark hello-rs as EXCLUDE_FROM_WORLD as it's not reproducible > > > > Changes in v3: > > - Add hello-rs as a replacement for the tests which used zvariant > > > > Changes in v2: > > - Skip zvariant based test rather than deleting it. > > > > Alex Kiernan (10): > > devtool: selftest: Fix test_devtool_modify_git_crates_subpath > > inequality > > devtool: selftest: Fix test_devtool_modify_git_crates_subpath bbappend > > check > > meta-selftest: hello-rs: Simple rust test recipe > > devtool: selftest: Swap to hello-rs for crates testing > > zvariant: Drop recipe > > rust: Upgrade 1.71.1 -> 1.72.0 > > rust: Upgrade 1.72.0 -> 1.72.1 > > rust: Upgrade 1.72.1 -> 1.73.0 > > rust: Upgrade 1.73.0 -> 1.74.0 > > rust: Upgrade 1.74.0 -> 1.74.1 > > Thanks for working through this, I've gone ahead and merged it :) > > I am a little worried that: > > * the test recipe isn't reproducible This one concerns me... upstream is clearly trying to get reproducibility yet we're seeing issues. I worry that we're doing something which means they're not seeing it. > * we still have the tests disabled I think we need to find a way to engage with upstream on this - as far as I can tell they simply don't run the tests on release code, only on nightlies, so we're really going off-piste here. > * the next version looks problematic Hopefully I've found/fixed the issues - it looks like it's bugs from poor assumptions which don't hold true in our world and at least one FIXME in the upstream code :| Just tidying the patches and will send it shortly. > > but I think we're at the point it makes sense to move to the newer > version. > Thanks! -- Alex Kiernan -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#193072): https://lists.openembedded.org/g/openembedded-core/message/193072 Mute This Topic: https://lists.openembedded.org/mt/103415633/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][dunfell][PATCH] tzdata: Upgrade to 2023d
On Sat, Dec 30, 2023 at 4:37 AM Shubham Kulkarni wrote:
>
> Hi Steve,
>
> I have sent this patch to upgrade tzdata to the latest version "2023d" for
> dunfell branch.
> The mailing list link for the same:
> https://lists.openembedded.org/g/openembedded-core/message/192913
>
> Can you please check if this patch can be accepted in the dunfell-nut branch
> of oe-core-contrib.
I can take it now that it has been merged to the master branch.
Steve
> On Tue, Dec 26, 2023 at 10:44 PM Shubham Kulkarni via lists.openembedded.org
> wrote:
>>
>> From: Shubham Kulkarni
>>
>> Signed-off-by: Shubham Kulkarni
>> ---
>> meta/recipes-extended/timezone/timezone.inc | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/meta/recipes-extended/timezone/timezone.inc
>> b/meta/recipes-extended/timezone/timezone.inc
>> index 2960bfefe3..75f13cfc94 100644
>> --- a/meta/recipes-extended/timezone/timezone.inc
>> +++ b/meta/recipes-extended/timezone/timezone.inc
>> @@ -6,7 +6,7 @@ SECTION = "base"
>> LICENSE = "PD & BSD-3-Clause"
>> LIC_FILES_CHKSUM = "file://LICENSE;md5=c679c9d6b02bc2757b3eaf8f53c43fba"
>>
>> -PV = "2023c"
>> +PV = "2023d"
>>
>> SRC_URI ="
>> http://www.iana.org/time-zones/repository/releases/tzcode${PV}.tar.gz;name=tzcode
>> \
>>
>> http://www.iana.org/time-zones/repository/releases/tzdata${PV}.tar.gz;name=tzdata
>> \
>> @@ -14,5 +14,5 @@ SRC_URI ="
>> http://www.iana.org/time-zones/repository/releases/tzcode${PV}.tar.gz
>>
>> UPSTREAM_CHECK_URI = "http://www.iana.org/time-zones";
>>
>> -SRC_URI[tzcode.sha256sum] =
>> "46d17f2bb19ad73290f03a203006152e0fa0d7b11e5b71467c4a823811b214e7"
>> -SRC_URI[tzdata.sha256sum] =
>> "3f510b5d1b4ae9bb38e485aa302a776b317fb3637bdb6404c4adf7b6cadd965c"
>> +SRC_URI[tzcode.sha256sum] =
>> "e9a5f9e118886d2de92b62bb05510a28cc6c058d791c93bd6b84d3292c3c161e"
>> +SRC_URI[tzdata.sha256sum] =
>> "dbca21970b0a8b8c0ceceec1d7b91fa903be0f6eca5ae732b5329672232a08f3"
>> --
>> 2.42.0
>>
>>
>>
>>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#193073):
https://lists.openembedded.org/g/openembedded-core/message/193073
Mute This Topic: https://lists.openembedded.org/mt/103372051/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-Core][PATCH 1/4] rust: Move RUST_DIST_SERVER to rust-config.inc
Overriding the location of RUST_DIST_SERVER is useful for testing rust
pre-releases, but we need it in rust-source and rust-snapshot; move
RUST_DIST_SERVER to rust-config.inc so we can set it to
`dev-static.rust-lang.org` and use it from both locations.
Signed-off-by: Alex Kiernan
---
meta/recipes-devtools/rust/rust-config.inc | 1 +
meta/recipes-devtools/rust/rust-snapshot.inc | 2 --
meta/recipes-devtools/rust/rust-source.inc | 4 +++-
meta/recipes-devtools/rust/rust_1.74.1.bb| 11 ---
4 files changed, 12 insertions(+), 6 deletions(-)
create mode 100644 meta/recipes-devtools/rust/rust-config.inc
diff --git a/meta/recipes-devtools/rust/rust-config.inc
b/meta/recipes-devtools/rust/rust-config.inc
new file mode 100644
index ..9fd360616bc4
--- /dev/null
+++ b/meta/recipes-devtools/rust/rust-config.inc
@@ -0,0 +1 @@
+RUST_DIST_SERVER ??= "https://static.rust-lang.org";
diff --git a/meta/recipes-devtools/rust/rust-snapshot.inc
b/meta/recipes-devtools/rust/rust-snapshot.inc
index ffc1aed2957c..b67e42d27063 100644
--- a/meta/recipes-devtools/rust/rust-snapshot.inc
+++ b/meta/recipes-devtools/rust/rust-snapshot.inc
@@ -52,8 +52,6 @@ SRC_URI += " \
${RUST_DIST_SERVER}/dist/${CARGO_SNAPSHOT}.tar.xz;name=cargo-snapshot-${RUST_BUILD_ARCH};subdir=rust-snapshot-components
\
"
-RUST_DIST_SERVER = "https://static.rust-lang.org";
-
RUST_STD_SNAPSHOT =
"rust-std-${SNAPSHOT_VERSION}-${RUST_BUILD_ARCH}-unknown-linux-gnu"
RUSTC_SNAPSHOT =
"rustc-${SNAPSHOT_VERSION}-${RUST_BUILD_ARCH}-unknown-linux-gnu"
CARGO_SNAPSHOT =
"cargo-${SNAPSHOT_VERSION}-${RUST_BUILD_ARCH}-unknown-linux-gnu"
diff --git a/meta/recipes-devtools/rust/rust-source.inc
b/meta/recipes-devtools/rust/rust-source.inc
index 83a0dbc15fae..fdac009c6d20 100644
--- a/meta/recipes-devtools/rust/rust-source.inc
+++ b/meta/recipes-devtools/rust/rust-source.inc
@@ -1,6 +1,8 @@
+require rust-config.inc
+
RUST_VERSION ?= "${@d.getVar('PV').split('-')[0]}"
-SRC_URI +=
"https://static.rust-lang.org/dist/rustc-${RUST_VERSION}-src.tar.xz;name=rust \
+SRC_URI +=
"${RUST_DIST_SERVER}/dist/rustc-${RUST_VERSION}-src.tar.xz;name=rust \
file://hardcodepaths.patch;patchdir=${RUSTSRC} \
file://0001-Don-t-use-LFS64-symbols-on-musl.patch;patchdir=${RUSTSRC} \
file://zlib-off64_t.patch;patchdir=${RUSTSRC} \
diff --git a/meta/recipes-devtools/rust/rust_1.74.1.bb
b/meta/recipes-devtools/rust/rust_1.74.1.bb
index 30543ada7dbc..dd931a42717c 100644
--- a/meta/recipes-devtools/rust/rust_1.74.1.bb
+++ b/meta/recipes-devtools/rust/rust_1.74.1.bb
@@ -316,6 +316,10 @@ python do_update_snapshot() {
arch = m.group('arch')
src_uri[arch].append(f"SRC_URI[{component}-snapshot-{arch}.sha256sum] =
\"{v}\"")
+config = """\
+RUST_DIST_SERVER ??= "%s"
+""" % config_dist_server
+
snapshot = """\
## This is information on the rust-snapshot (binary) used to build our current
release.
## snapshot info is taken from rust/src/stage0.json
@@ -337,12 +341,13 @@ SRC_URI += " \\
${RUST_DIST_SERVER}/dist/${CARGO_SNAPSHOT}.tar.xz;name=cargo-snapshot-${RUST_BUILD_ARCH};subdir=rust-snapshot-components
\\
"
-RUST_DIST_SERVER = "%s"
-
RUST_STD_SNAPSHOT =
"rust-std-${SNAPSHOT_VERSION}-${RUST_BUILD_ARCH}-unknown-linux-gnu"
RUSTC_SNAPSHOT =
"rustc-${SNAPSHOT_VERSION}-${RUST_BUILD_ARCH}-unknown-linux-gnu"
CARGO_SNAPSHOT =
"cargo-${SNAPSHOT_VERSION}-${RUST_BUILD_ARCH}-unknown-linux-gnu"
-""" % config_dist_server
+"""
+
+with open(os.path.join(d.getVar("THISDIR"), "rust-config.inc"), "w") as f:
+f.write(config)
with open(os.path.join(d.getVar("THISDIR"), "rust-snapshot.inc"), "w") as
f:
f.write(snapshot)
--
2.39.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#193074):
https://lists.openembedded.org/g/openembedded-core/message/193074
Mute This Topic: https://lists.openembedded.org/mt/103433088/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-Core][PATCH 2/4] cargo: Create CARGO_HOME and CARGO_VENDORING_DIRECTORY
Remove assumption that CARGO_VENDORING_DIRECTORY is ${CARGO_HOME}/bitbake
and create both directories as part of cargo configure.
Signed-off-by: Alex Kiernan
---
meta/classes-recipe/cargo_common.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes-recipe/cargo_common.bbclass
b/meta/classes-recipe/cargo_common.bbclass
index 0fb443edbdde..e932ada862bd 100644
--- a/meta/classes-recipe/cargo_common.bbclass
+++ b/meta/classes-recipe/cargo_common.bbclass
@@ -45,7 +45,7 @@ CARGO_LOCK_PATH ??= "${@
os.path.join(os.path.dirname(d.getVar('CARGO_MANIFEST_P
CARGO_RUST_TARGET_CCLD ??= "${RUST_TARGET_CCLD}"
cargo_common_do_configure () {
- mkdir -p ${CARGO_HOME}/bitbake
+ mkdir -p "${CARGO_VENDORING_DIRECTORY}" "${CARGO_HOME}"
cat <<- EOF > ${CARGO_HOME}/config
# EXTRA_OECARGO_PATHS
--
2.39.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#193075):
https://lists.openembedded.org/g/openembedded-core/message/193075
Mute This Topic: https://lists.openembedded.org/mt/103433090/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 3/4] cargo: Move vendor directory to registry/src
rust 1.75 has an assumption from 85c0ce24cc74 ("remap cargo dependencies
to /rust/deps") that unpacked crates (vendored or otherwise)
are found in .../registry/src (usually in ~/.cargo). Moving our vendor
directory to match is the easiest workaround to avoid the upstream
assumption causing issues.
Signed-off-by: Alex Kiernan
---
This requires the concomitant change in bitbake to use
CARGO_VENDORING_DIRECTORY for unpacking crates into.
meta/classes-recipe/cargo_common.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes-recipe/cargo_common.bbclass
b/meta/classes-recipe/cargo_common.bbclass
index e932ada862bd..3cb21cfddcb6 100644
--- a/meta/classes-recipe/cargo_common.bbclass
+++ b/meta/classes-recipe/cargo_common.bbclass
@@ -31,7 +31,7 @@ export PKG_CONFIG_ALLOW_CROSS = "1"
CARGO_DISABLE_BITBAKE_VENDORING ??= "0"
# Used by libstd-rs to point to the vendor dir included in rustc src
-CARGO_VENDORING_DIRECTORY ??= "${CARGO_HOME}/bitbake"
+CARGO_VENDORING_DIRECTORY ??= "${CARGO_HOME}/registry/src"
# The directory of the Cargo.toml relative to the root directory, per default
# assume there's a Cargo.toml directly in the root directory
--
2.39.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#193076):
https://lists.openembedded.org/g/openembedded-core/message/193076
Mute This Topic: https://lists.openembedded.org/mt/103433091/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [bitbake-devel] pthread_cancel bug on ubuntu2004/debian11
It’s preloading the library so I think it
Won’t have unintended side effects therefore can be applied regardless I
would imagine
On Wed, Dec 27, 2023 at 10:30 AM Joshua Watt wrote:
> On Wed, Dec 27, 2023 at 4:28 AM Richard Purdie
> wrote:
> >
> > I wanted to write down some thoughts on this which I have all the
> > pieces handy.
> >
> > We saw a nightly layer check fail for meta-openembedded:
> >
> >
> https://autobuilder.yoctoproject.org/typhoon/#/builders/121/builds/1798/steps/21/logs/stdio
> >
> > INFO:
> ==
> > INFO: ERROR: test_show_environment (common.CommonCheckLayer)
> > INFO:
> --
> > INFO: Traceback (most recent call last):
> > File
> "/home/pokybuild/yocto-worker/check-layer-nightly/build/scripts/lib/checklayer/cases/common.py",
> line 48, in test_show_environment
> > check_command('Layer %s failed to show environment.' %
> self.tc.layer['name'],
> > File
> "/home/pokybuild/yocto-worker/check-layer-nightly/build/scripts/lib/checklayer/__init__.py",
> line 287, in check_command
> > raise RuntimeError(msg)
> > RuntimeError: Layer meta-gnome failed to show environment.
> > Command: bitbake -e
> > Output:
> > libgcc_s.so.1 must be installed for pthread_cancel to work
> > Aborted (core dumped)
> >
> > which unsurprisingly is on ubuntn 20.04. We've also seen issues like
> > this on Debian 11.
> >
> > I noticed:
> >
> >
> https://stackoverflow.com/questions/64797838/libgcc-s-so-1-must-be-installed-for-pthread-cancel-to-work
> >
> > and:
> >
> > https://bugs.ams1.psf.io/issue42888
> >
> > which led me to try:
> > ubuntu2004-ty-1:~$ wget
> https://bugs.ams1.psf.io/file50112/pthread_cancel_bug.py
> > ubuntu2004-ty-1:~$ python3 pthread_cancel_bug.py
> > ubuntu2004-ty-1:~$ echo $?
> > 0
> > rpurdie@ubuntu2004-ty-1:~$ python3 pthread_cancel_bug.py
> > libgcc_s.so.1 must be installed for pthread_cancel to work
> > Aborted (core dumped)
> > ubuntu2004-ty-1:~$ python3 pthread_cancel_bug.py
> > libgcc_s.so.1 must be installed for pthread_cancel to work
> > Aborted (core dumped)
> > ubuntu2004-ty-1:~$ python3 pthread_cancel_bug.py
> > libgcc_s.so.1 must be installed for pthread_cancel to work
> > Aborted (core dumped)
> >
> > (1 in 4 success)
> >
> > Then adding to the script:
> > import ctypes
> > libgcc_s = ctypes.CDLL('libgcc_s.so.1')
> >
> > ubuntu2004-ty-1:~$ python3 pthread_cancel_bug.py
> > ubuntu2004-ty-1:~$ python3 pthread_cancel_bug.py
> > ubuntu2004-ty-1:~$ python3 pthread_cancel_bug.py
> > ubuntu2004-ty-1:~$ python3 pthread_cancel_bug.py
> > ubuntu2004-ty-1:~$ python3 pthread_cancel_bug.py
> > ubuntu2004-ty-1:~$ python3 pthread_cancel_bug.py
> > ubuntu2004-ty-1:~$ python3 pthread_cancel_bug.py
> > ubuntu2004-ty-1:~$ python3 pthread_cancel_bug.py
> > ubuntu2004-ty-1:~$ python3 pthread_cancel_bug.py
> > ubuntu2004-ty-1:~$ python3 pthread_cancel_bug.py
> > ubuntu2004-ty-1:~$ python3 pthread_cancel_bug.py
> > ubuntu2004-ty-1:~$ python3 pthread_cancel_bug.py
> > ubuntu2004-ty-1:~$ python3 pthread_cancel_bug.py
> > ubuntu2004-ty-1:~$ python3 --version
> > Python 3.8.10
> >
> > I also tried this on debian 11:
> >
> > debian11-ty-1:~$ python3 pthread_cancel_bug.py
> > libgcc_s.so.1 must be installed for pthread_cancel to work
> > Aborted
> >
> > debian11-ty-1:~$ python3 --version
> > Python 3.9.2
> >
> > where the above workaround using ctypes also seems to work.
> >
> > I'm therefore tempted for python 3.8/3.9 to preload libgcc_s as a
> > workaround for this...
>
> Seems reasonable to me, as long as we can restrict it to a specific
> version range of python and have a nice comment explaining why
>
> >
> > Cheers,
> >
> > Richard
> >
> >
> >
> >
> >
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#193078):
https://lists.openembedded.org/g/openembedded-core/message/193078
Mute This Topic: https://lists.openembedded.org/mt/103388962/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 v5 1/3] mesa: drop -Dopencl-native=true
The flag -Dopencl-native=true was dropped in Mesa 22.3, remove it from
mesa.inc.
Signed-off-by: Dmitry Baryshkov
---
meta/recipes-graphics/mesa/mesa.inc | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/meta/recipes-graphics/mesa/mesa.inc
b/meta/recipes-graphics/mesa/mesa.inc
index 5f5c8ceb4c84..efbce5caade5 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -140,8 +140,7 @@ PACKAGECONFIG[gles] = "-Dgles1=enabled -Dgles2=enabled,
-Dgles1=disabled -Dgles2
PACKAGECONFIG[egl] = "-Degl=enabled, -Degl=disabled"
# "opencl" requires libclc from meta-clang and spirv-tools from OE-Core
-OPENCL_NATIVE = "${@bb.utils.contains('PACKAGECONFIG', 'freedreno',
'-Dopencl-native=true', '', d)}"
-PACKAGECONFIG[opencl] = "-Dgallium-opencl=icd -Dopencl-spirv=true
${OPENCL_NATIVE},-Dgallium-opencl=disabled -Dopencl-spirv=false,libclc
spirv-tools python3-ply-native"
+PACKAGECONFIG[opencl] = "-Dgallium-opencl=icd
-Dopencl-spirv=true,-Dgallium-opencl=disabled -Dopencl-spirv=false,libclc
spirv-tools python3-ply-native"
PACKAGECONFIG[broadcom] = ""
PACKAGECONFIG[etnaviv] = ""
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#193079):
https://lists.openembedded.org/g/openembedded-core/message/193079
Mute This Topic: https://lists.openembedded.org/mt/103436168/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 v5 2/3] mesa: add support for RustiCL under PACKAGECONFIG "opencl"
From: Zoltán Böszörményi
Mesa now has two OpenCL implementations: Clover (older one) and RustiCL
(newer one). Extend the "opencl" package config to include both
implementations into the libopencl-mesa (-dev) packages. As the Clover
implementation is in maintenance mode and is expected to be removed at
some point, it doesn't make sense to split the packages or to provide
two config options.
Signed-off-by: Zoltán Böszörményi
[DB: reworked rust class inheritance]
[DB: merged "rusticl" and "clover" back to "opencl"]
Signed-off-by: Dmitry Baryshkov
---
meta/recipes-graphics/mesa/mesa.inc | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/meta/recipes-graphics/mesa/mesa.inc
b/meta/recipes-graphics/mesa/mesa.inc
index efbce5caade5..a192562a7935 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -48,6 +48,12 @@ PROVIDES = " \
inherit meson pkgconfig python3native gettext features_check
+# We can not include rust conditionally, otherwise it can not be overriden by
+# the bbappends. Instead always include it, but remove the dependencies by
+# default.
+inherit rust
+INHIBIT_DEFAULT_RUST_DEPS = "${@bb.utils.contains('PACKAGECONFIG', 'opencl',
'', '1', d)}"
+
BBCLASSEXTEND = "native nativesdk"
ANY_OF_DISTRO_FEATURES = "opengl vulkan"
@@ -139,8 +145,13 @@ PACKAGECONFIG[gles] = "-Dgles1=enabled -Dgles2=enabled,
-Dgles1=disabled -Dgles2
# "egl" requires "opengl"
PACKAGECONFIG[egl] = "-Degl=enabled, -Degl=disabled"
-# "opencl" requires libclc from meta-clang and spirv-tools from OE-Core
-PACKAGECONFIG[opencl] = "-Dgallium-opencl=icd
-Dopencl-spirv=true,-Dgallium-opencl=disabled -Dopencl-spirv=false,libclc
spirv-tools python3-ply-native"
+# "clover" requires libclc from meta-clang and python3-ply-native and
spirv-tools from OE-Core
+# "rusticl" requires libclc, spirv-llvm-translator and bindgen-cli-native from
meta-clang and spirv-tools from OE-Core
+PACKAGECONFIG[opencl] = "\
+-Dgallium-opencl=icd -Dopencl-spirv=true -Dgallium-rusticl=true
-Drust_std=2021, \
+-Dgallium-opencl=disabled -Dopencl-spirv=false -Dgallium-rusticl=false, \
+libclc spirv-tools bindgen-cli-native python3-ply-native"
+#PACKAGECONFIG[opencl] = ",,spirv-llvm-translator"
PACKAGECONFIG[broadcom] = ""
PACKAGECONFIG[etnaviv] = ""
@@ -221,7 +232,7 @@ DEV_PKG_DEPENDENCY = ""
# development package of libgles3.
RDEPENDS:libgles3-mesa-dev += "libgles2-mesa-dev"
-RDEPENDS:libopencl-mesa += "${@bb.utils.contains('PACKAGECONFIG', 'opencl',
'libclc spirv-tools', '', d)}"
+RDEPENDS:libopencl-mesa += "${@bb.utils.contains('PACKAGECONFIG', 'opencl',
'libclc spirv-tools spirv-llvm-translator', '', d)}"
PACKAGES =+ "libegl-mesa libegl-mesa-dev \
libosmesa libosmesa-dev \
@@ -332,7 +343,7 @@ FILES:libgles1-mesa = "${libdir}/libGLESv1*.so.*"
FILES:libgles2-mesa = "${libdir}/libGLESv2.so.*"
FILES:libgl-mesa = "${libdir}/libGL.so.*"
FILES:libglx-mesa = "${libdir}/libGLX*.so.*"
-FILES:libopencl-mesa = "${libdir}/libMesaOpenCL.so.*
${libdir}/gallium-pipe/*.so ${sysconfdir}/OpenCL/vendors/mesa.icd"
+FILES:libopencl-mesa = "${libdir}/lib*OpenCL.so.* ${libdir}/gallium-pipe/*.so
${sysconfdir}/OpenCL/vendors/*.icd"
FILES:libglapi = "${libdir}/libglapi.so.*"
FILES:libosmesa = "${libdir}/libOSMesa.so.*"
FILES:libxatracker = "${libdir}/libxatracker.so.*"
@@ -346,7 +357,7 @@ FILES:libglapi-dev = "${libdir}/libglapi.*"
FILES:libgles1-mesa-dev = "${libdir}/libGLESv1*.* ${includedir}/GLES
${libdir}/pkgconfig/glesv1*.pc"
FILES:libgles2-mesa-dev = "${libdir}/libGLESv2.* ${includedir}/GLES2
${libdir}/pkgconfig/glesv2.pc"
FILES:libgles3-mesa-dev = "${includedir}/GLES3"
-FILES:libopencl-mesa-dev = "${libdir}/libMesaOpenCL.so"
+FILES:libopencl-mesa-dev = "${libdir}/lib*OpenCL.so"
FILES:libosmesa-dev = "${libdir}/libOSMesa.* ${includedir}/GL/osmesa.h
${libdir}/pkgconfig/osmesa.pc"
FILES:libxatracker-dev = "${libdir}/libxatracker.so ${libdir}/libxatracker.la \
${includedir}/xa_tracker.h
${includedir}/xa_composite.h ${includedir}/xa_context.h \
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#193081):
https://lists.openembedded.org/g/openembedded-core/message/193081
Mute This Topic: https://lists.openembedded.org/mt/103436170/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 v5 3/3] mesa: fix building of RustiCL + nouveau
Incorporate a patch by Karol Herbst, fixing nouveau / libgalliumvl
dependency.
Signed-off-by: Dmitry Baryshkov
---
meta/recipes-graphics/mesa/files/26680.patch | 236 +++
meta/recipes-graphics/mesa/mesa.inc | 1 +
2 files changed, 237 insertions(+)
create mode 100644 meta/recipes-graphics/mesa/files/26680.patch
diff --git a/meta/recipes-graphics/mesa/files/26680.patch
b/meta/recipes-graphics/mesa/files/26680.patch
new file mode 100644
index ..a42b7667edee
--- /dev/null
+++ b/meta/recipes-graphics/mesa/files/26680.patch
@@ -0,0 +1,236 @@
+From daf4935359cb3c88606536924e346ead5e4b2137 Mon Sep 17 00:00:00 2001
+From: Karol Herbst
+Date: Thu, 14 Dec 2023 03:19:34 +0100
+Subject: [PATCH 1/7] gallium/vl: stub vl_video_buffer_create_as_resource
+
+It's used by radeonsi
+
+Signed-off-by: Karol Herbst
+Upstream-Status: Pending
[https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26680]
+---
+ src/gallium/auxiliary/vl/vl_stubs.c | 10 ++
+ 1 file changed, 10 insertions(+)
+
+diff --git a/src/gallium/auxiliary/vl/vl_stubs.c
b/src/gallium/auxiliary/vl/vl_stubs.c
+index 194e7a8700b6b..89e5f28128909 100644
+--- a/src/gallium/auxiliary/vl/vl_stubs.c
b/src/gallium/auxiliary/vl/vl_stubs.c
+@@ -146,6 +146,16 @@ vl_create_mpeg12_decoder(struct pipe_context *pipe,
+return NULL;
+ }
+
++struct pipe_video_buffer *
++vl_video_buffer_create_as_resource(struct pipe_context *pipe,
++ const struct pipe_video_buffer *tmpl,
++ const uint64_t *modifiers,
++ int modifiers_count)
++{
++ assert(0);
++ return NULL;
++}
++
+ /*
+ * vl_zscan
+ */
+--
+GitLab
+
+
+From 5dd1598b5ac988d3ef53adc9dcb1f2bc1788513c Mon Sep 17 00:00:00 2001
+From: Karol Herbst
+Date: Sat, 30 Dec 2023 20:00:33 +0100
+Subject: [PATCH 2/7] gallium/vl: remove stubs which are already defined in
+ mesa_util
+
+---
+ src/gallium/auxiliary/vl/vl_stubs.c | 6 --
+ 1 file changed, 6 deletions(-)
+
+diff --git a/src/gallium/auxiliary/vl/vl_stubs.c
b/src/gallium/auxiliary/vl/vl_stubs.c
+index 89e5f28128909..fcdbd9850428b 100644
+--- a/src/gallium/auxiliary/vl/vl_stubs.c
b/src/gallium/auxiliary/vl/vl_stubs.c
+@@ -155,9 +155,3 @@ vl_video_buffer_create_as_resource(struct pipe_context
*pipe,
+assert(0);
+return NULL;
+ }
+-
+-/*
+- * vl_zscan
+- */
+-const int vl_zscan_normal[] = {0};
+-const int vl_zscan_alternate[] = {0};
+--
+GitLab
+
+
+From 6df28bce29d34da949f84739f52a5eff7fb01b80 Mon Sep 17 00:00:00 2001
+From: Karol Herbst
+Date: Thu, 14 Dec 2023 03:20:08 +0100
+Subject: [PATCH 3/7] rusticl: link against libgalliumvl_stub
+
+---
+ src/gallium/targets/rusticl/meson.build | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/src/gallium/targets/rusticl/meson.build
b/src/gallium/targets/rusticl/meson.build
+index b2963fe6dfa76..e1acaca7e68e3 100644
+--- a/src/gallium/targets/rusticl/meson.build
b/src/gallium/targets/rusticl/meson.build
+@@ -42,6 +42,7 @@ librusticl = shared_library(
+ ],
+ link_whole : librusticl,
+ link_with : [
++libgalliumvl_stub,
+ libpipe_loader_static,
+ libswdri,
+ libswkmsdri,
+--
+GitLab
+
+
+From b158c041e2b89c73fd16be945286efa7dcf9b75f Mon Sep 17 00:00:00 2001
+From: Karol Herbst
+Date: Thu, 14 Dec 2023 03:28:48 +0100
+Subject: [PATCH 4/7] frontend/nine: link against libgalliumvl_stub
+
+---
+ src/gallium/targets/d3dadapter9/meson.build | 9 +
+ 1 file changed, 1 insertion(+), 8 deletions(-)
+
+diff --git a/src/gallium/targets/d3dadapter9/meson.build
b/src/gallium/targets/d3dadapter9/meson.build
+index 282859fd93266..c6f1a0dc2a287 100644
+--- a/src/gallium/targets/d3dadapter9/meson.build
b/src/gallium/targets/d3dadapter9/meson.build
+@@ -27,7 +27,7 @@ gallium_nine_c_args = []
+ gallium_nine_ld_args = []
+ gallium_nine_link_depends = []
+ gallium_nine_link_with = [
+-libgallium, libnine_st,
++libgallium, libgalliumvl_stub, libnine_st,
+ libpipe_loader_static, libws_null, libwsw, libswdri,
+ libswkmsdri,
+ ]
+@@ -37,13 +37,6 @@ if with_ld_version_script
+ gallium_nine_link_depends += files('d3dadapter9.sym')
+ endif
+
+-if (with_gallium_va or with_gallium_vdpau or with_gallium_omx != 'disabled' or
+-with_dri)
+- gallium_nine_link_with += libgalliumvl
+-else
+- gallium_nine_link_with += libgalliumvl_stub
+-endif
+-
+ libgallium_nine = shared_library(
+ 'd3dadapter9',
+ files('description.c', 'getproc.c', 'drm.c'),
+--
+GitLab
+
+
+From 9d3192871d5038f73317fd2770118dc0ba08e6d4 Mon Sep 17 00:00:00 2001
+From: Karol Herbst
+Date: Thu, 14 Dec 2023 03:29:14 +0100
+Subject: [PATCH 5/7] dri: link against libgalliumvl_stub
+
+---
+ src/gallium/targets/dri/meson.build | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/gallium/targets/dri/meson.build
b/src/gallium/targets/dri/meson.build
+index 83925248b17e6..e50581dc121e6 100644
+--- a/src/gallium/targets/dri/meson
[OE-core] [PATCH v5 0/3] mesa: RustiCL support
RustiCL is a new OpenCL implementation developed within the mesa library. It supports more drivers and more features compared to the existing Clover implementation. The Clover is supposed to fade away and to be removed in the foreseeble feature ([1]), thus it doesn't make sense to add separate clover / rusticl options, they are going to be removed anyway. This series is based on previous work by Zoltán ([2]), so it starts its versions from v4. [1] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19385 [2] https://lore.kernel.org/openembedded-core/20230306091108.3347363-1-zbos...@gmail.com/ Changes since v4: - Switched to patchset from the merge request rather than using the interim patch from Karol Herbst. Changes since v3: - Dropped clover / rusticl separation in PACKAGECONFIG - Reworked rust inheritance to allow changing of PACKAGECONFIG from bbappend files - Added an upstream fix - Dropped removed config option Dmitry Baryshkov (2): mesa: drop -Dopencl-native=true mesa: fix building of RustiCL + nouveau Zoltán Böszörményi (1): mesa: add support for RustiCL under PACKAGECONFIG "opencl" meta/recipes-graphics/mesa/files/26680.patch | 236 +++ meta/recipes-graphics/mesa/mesa.inc | 23 +- 2 files changed, 253 insertions(+), 6 deletions(-) create mode 100644 meta/recipes-graphics/mesa/files/26680.patch -- 2.39.2 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#193080): https://lists.openembedded.org/g/openembedded-core/message/193080 Mute This Topic: https://lists.openembedded.org/mt/103436169/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [bitbake-devel] pthread_cancel bug on ubuntu2004/debian11
On Sat, Dec 30, 2023 at 1:31 AM Richard Purdie
wrote:
>
> On Wed, 2023-12-27 at 11:30 -0700, Joshua Watt wrote:
> > On Wed, Dec 27, 2023 at 4:28 AM Richard Purdie
> > wrote:
> > >
> > > I wanted to write down some thoughts on this which I have all the
> > > pieces handy.
> > >
> > > We saw a nightly layer check fail for meta-openembedded:
> > >
> > > https://autobuilder.yoctoproject.org/typhoon/#/builders/121/builds/1798/steps/21/logs/stdio
> > >
> > > INFO:
> > > ==
> > > INFO: ERROR: test_show_environment (common.CommonCheckLayer)
> > > INFO:
> > > --
> > > INFO: Traceback (most recent call last):
> > > File
> > > "/home/pokybuild/yocto-worker/check-layer-nightly/build/scripts/lib/checklayer/cases/common.py",
> > > line 48, in test_show_environment
> > > check_command('Layer %s failed to show environment.' %
> > > self.tc.layer['name'],
> > > File
> > > "/home/pokybuild/yocto-worker/check-layer-nightly/build/scripts/lib/checklayer/__init__.py",
> > > line 287, in check_command
> > > raise RuntimeError(msg)
> > > RuntimeError: Layer meta-gnome failed to show environment.
> > > Command: bitbake -e
> > > Output:
> > > libgcc_s.so.1 must be installed for pthread_cancel to work
> > > Aborted (core dumped)
> > >
> > > which unsurprisingly is on ubuntn 20.04. We've also seen issues like
> > > this on Debian 11.
> > >
> > > I noticed:
> > >
> > > https://stackoverflow.com/questions/64797838/libgcc-s-so-1-must-be-installed-for-pthread-cancel-to-work
> > >
> > > and:
> > >
> > > https://bugs.ams1.psf.io/issue42888
> > >
> > > which led me to try:
> > > ubuntu2004-ty-1:~$ wget
> > > https://bugs.ams1.psf.io/file50112/pthread_cancel_bug.py
> > > ubuntu2004-ty-1:~$ python3 pthread_cancel_bug.py
> > > ubuntu2004-ty-1:~$ echo $?
> > > 0
> > > rpurdie@ubuntu2004-ty-1:~$ python3 pthread_cancel_bug.py
> > > libgcc_s.so.1 must be installed for pthread_cancel to work
> > > Aborted (core dumped)
> > > ubuntu2004-ty-1:~$ python3 pthread_cancel_bug.py
> > > libgcc_s.so.1 must be installed for pthread_cancel to work
> > > Aborted (core dumped)
> > > ubuntu2004-ty-1:~$ python3 pthread_cancel_bug.py
> > > libgcc_s.so.1 must be installed for pthread_cancel to work
> > > Aborted (core dumped)
> > >
> > > (1 in 4 success)
> > >
> > > Then adding to the script:
> > > import ctypes
> > > libgcc_s = ctypes.CDLL('libgcc_s.so.1')
> > >
> > > ubuntu2004-ty-1:~$ python3 pthread_cancel_bug.py
> > > ubuntu2004-ty-1:~$ python3 pthread_cancel_bug.py
> > > ubuntu2004-ty-1:~$ python3 pthread_cancel_bug.py
> > > ubuntu2004-ty-1:~$ python3 pthread_cancel_bug.py
> > > ubuntu2004-ty-1:~$ python3 pthread_cancel_bug.py
> > > ubuntu2004-ty-1:~$ python3 pthread_cancel_bug.py
> > > ubuntu2004-ty-1:~$ python3 pthread_cancel_bug.py
> > > ubuntu2004-ty-1:~$ python3 pthread_cancel_bug.py
> > > ubuntu2004-ty-1:~$ python3 pthread_cancel_bug.py
> > > ubuntu2004-ty-1:~$ python3 pthread_cancel_bug.py
> > > ubuntu2004-ty-1:~$ python3 pthread_cancel_bug.py
> > > ubuntu2004-ty-1:~$ python3 pthread_cancel_bug.py
> > > ubuntu2004-ty-1:~$ python3 pthread_cancel_bug.py
> > > ubuntu2004-ty-1:~$ python3 --version
> > > Python 3.8.10
> > >
> > > I also tried this on debian 11:
> > >
> > > debian11-ty-1:~$ python3 pthread_cancel_bug.py
> > > libgcc_s.so.1 must be installed for pthread_cancel to work
> > > Aborted
> > >
> > > debian11-ty-1:~$ python3 --version
> > > Python 3.9.2
> > >
> > > where the above workaround using ctypes also seems to work.
> > >
> > > I'm therefore tempted for python 3.8/3.9 to preload libgcc_s as a
> > > workaround for this...
> >
> > Seems reasonable to me, as long as we can restrict it to a specific
> > version range of python and have a nice comment explaining why
>
> Patch tested, sent and I've applied it to older bitbake branches too in
> the hope that it helps some of Steve's autobuilder failures too.
I pulled the patch into my -nut branches when you posted it and have
been testing too -- all looks fine from my perspective.
Thanks for merging!
Steve
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#193083):
https://lists.openembedded.org/g/openembedded-core/message/193083
Mute This Topic: https://lists.openembedded.org/mt/103388962/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v5 2/3] mesa: add support for RustiCL under PACKAGECONFIG "opencl"
On Sat, 2023-12-30 at 21:14 +0200, Dmitry Baryshkov wrote:
> From: Zoltán Böszörményi
>
> Mesa now has two OpenCL implementations: Clover (older one) and RustiCL
> (newer one). Extend the "opencl" package config to include both
> implementations into the libopencl-mesa (-dev) packages. As the Clover
> implementation is in maintenance mode and is expected to be removed at
> some point, it doesn't make sense to split the packages or to provide
> two config options.
>
> Signed-off-by: Zoltán Böszörményi
> [DB: reworked rust class inheritance]
> [DB: merged "rusticl" and "clover" back to "opencl"]
> Signed-off-by: Dmitry Baryshkov
> ---
> meta/recipes-graphics/mesa/mesa.inc | 21 -
> 1 file changed, 16 insertions(+), 5 deletions(-)
>
> diff --git a/meta/recipes-graphics/mesa/mesa.inc
> b/meta/recipes-graphics/mesa/mesa.inc
> index efbce5caade5..a192562a7935 100644
> --- a/meta/recipes-graphics/mesa/mesa.inc
> +++ b/meta/recipes-graphics/mesa/mesa.inc
> @@ -48,6 +48,12 @@ PROVIDES = " \
>
> inherit meson pkgconfig python3native gettext features_check
>
> +# We can not include rust conditionally, otherwise it can not be overriden by
> +# the bbappends. Instead always include it, but remove the dependencies by
> +# default.
> +inherit rust
> +INHIBIT_DEFAULT_RUST_DEPS = "${@bb.utils.contains('PACKAGECONFIG', 'opencl',
> '', '1', d)}"
> +
I'd really prefer not to have the rust inherit unconditionally. I have
some ideas about how we could fix this in bitbake so we may need to
wait for that if we can't avoid the PACKAGECONFIG issue from appends...
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#193084):
https://lists.openembedded.org/g/openembedded-core/message/193084
Mute This Topic: https://lists.openembedded.org/mt/103436170/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] cargo: Move vendor directory to registry/src
On Sat, 2023-12-30 at 15:49 +, Alex Kiernan wrote:
> rust 1.75 has an assumption from 85c0ce24cc74 ("remap cargo dependencies
> to /rust/deps") that unpacked crates (vendored or otherwise)
> are found in .../registry/src (usually in ~/.cargo). Moving our vendor
> directory to match is the easiest workaround to avoid the upstream
> assumption causing issues.
> Signed-off-by: Alex Kiernan
> ---
> This requires the concomitant change in bitbake to use
> CARGO_VENDORING_DIRECTORY for unpacking crates into.
>
> meta/classes-recipe/cargo_common.bbclass | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/classes-recipe/cargo_common.bbclass
> b/meta/classes-recipe/cargo_common.bbclass
> index e932ada862bd..3cb21cfddcb6 100644
> --- a/meta/classes-recipe/cargo_common.bbclass
> +++ b/meta/classes-recipe/cargo_common.bbclass
> @@ -31,7 +31,7 @@ export PKG_CONFIG_ALLOW_CROSS = "1"
> CARGO_DISABLE_BITBAKE_VENDORING ??= "0"
>
> # Used by libstd-rs to point to the vendor dir included in rustc src
> -CARGO_VENDORING_DIRECTORY ??= "${CARGO_HOME}/bitbake"
> +CARGO_VENDORING_DIRECTORY ??= "${CARGO_HOME}/registry/src"
>
> # The directory of the Cargo.toml relative to the root directory, per default
> # assume there's a Cargo.toml directly in the root directory
I think the patchdir in SRC_URI of the librsvg recipe needs updating to
match that else you see:
https://autobuilder.yoctoproject.org/typhoon/#/builders/57/builds/8232/steps/11/logs/stdio
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#193085):
https://lists.openembedded.org/g/openembedded-core/message/193085
Mute This Topic: https://lists.openembedded.org/mt/103433091/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
