[PATCH 1/9] classes/cargo_common: move PKG_CONFIG_ALLOW_CROSS export to oe_cargo_fix_env

[PATCH 1/9] classes/cargo_common: move PKG_CONFIG_ALLOW_CROSS export to oe_cargo_fix_env

[Ross Burton]

This export is used to tell the pkg-config-rs crate how to behave, so is
only needed at build time.  Move the export to oe_cargo_fix_env() along
with the other variables so that the exports are localised and not
global.

Signed-off-by: Ross Burton <ross.burton@arm.com>
---
 meta/classes-recipe/cargo_common.bbclass | 15 +++++++--------
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/meta/classes-recipe/cargo_common.bbclass b/meta/classes-recipe/cargo_common.bbclass
index a21c5423642..95739122a59 100644
--- a/meta/classes-recipe/cargo_common.bbclass
+++ b/meta/classes-recipe/cargo_common.bbclass
@@ -20,11 +20,6 @@ inherit rust-common
 # Where we download our registry and dependencies to
 export CARGO_HOME = "${UNPACKDIR}/cargo_home"
 
-# The pkg-config-rs library used by cargo build scripts disables itself when
-# cross compiling unless this is defined. We set up pkg-config appropriately
-# for cross compilation, so tell it we know better than it.
-export PKG_CONFIG_ALLOW_CROSS = "1"
-
 # Don't instruct cargo to use crates downloaded by bitbake. Some rust packages,
 # for example the rust compiler itself, come with their own vendored sources.
 # Specifying two [source.crates-io] will not work.
@@ -241,11 +236,15 @@ oe_cargo_fix_env () {
 	# openssl-sys
 	export OPENSSL_NO_VENDOR="1"
 
-	# pkg-config-rs. Crates can still override the dynamic linking
-	# but try to dynamically link to system libraries.
+	# pkg-config-rs.
 	# https://docs.rs/pkg-config/latest/pkg_config/
-	export SYSTEM_DEPS_BUILD_INTERNAL="never"
+	# In cross pkg-config-rs disables itself unless this is defined to tell it
+	# we have set up sysroots appropriately.
+	export PKG_CONFIG_ALLOW_CROSS="1"
+	# Crates can still override the dynamic linking but try to dynamically link
+	# to system libraries.
 	export PKG_CONFIG_ALL_DYNAMIC="1"
+	export SYSTEM_DEPS_BUILD_INTERNAL="never"
 
 	# zstd-sys
 	export ZSTD_SYS_USE_PKG_CONFIG="1"
-- 
2.43.0

[PATCH 2/9] classes/rust: remove unused variables

[Ross Burton]

RUSTC_ARCHFLAGS is never passed anywhere, remove it.

RUSTC_BUILD_LDFLAGS is commented out, remove it.

HOST_CFLAGS et al are assigned to the CFLAGS for convenience, but are
not used anywhere and the same values are exported in cargo_common's
oe_cargo_fix_env().

Signed-off-by: Ross Burton <ross.burton@arm.com>
---
 meta/classes-recipe/rust.bbclass | 22 ----------------------
 1 file changed, 22 deletions(-)

diff --git a/meta/classes-recipe/rust.bbclass b/meta/classes-recipe/rust.bbclass
index e727601679a..6407c103941 100644
--- a/meta/classes-recipe/rust.bbclass
+++ b/meta/classes-recipe/rust.bbclass
@@ -8,8 +8,6 @@ inherit rust-common
 
 RUSTC = "rustc"
 
-RUSTC_ARCHFLAGS += "--target=${RUST_HOST_SYS} ${RUSTFLAGS}"
-
 def rust_base_dep(d):
     # Taken from meta/classes/base.bbclass `base_dep_prepend` and modified to
     # use rust instead of gcc
@@ -23,26 +21,6 @@ def rust_base_dep(d):
 
 DEPENDS:append = " ${@rust_base_dep(d)}"
 
-# BUILD_LDFLAGS
-# 	${STAGING_LIBDIR_NATIVE}
-# 	${STAGING_BASE_LIBDIR_NATIVE}
-# BUILDSDK_LDFLAGS
-# 	${STAGING_LIBDIR}
-# 	#{STAGING_DIR_HOST}
-# TARGET_LDFLAGS ?????
-#RUSTC_BUILD_LDFLAGS = "\
-#	--sysroot ${STAGING_DIR_NATIVE} \
-#	-L${STAGING_LIBDIR_NATIVE}	\
-#	-L${STAGING_BASE_LIBDIR_NATIVE}	\
-#"
-
-# XXX: for some reason bitbake sets BUILD_* & TARGET_* but uses the bare
-# variables for HOST. Alias things to make it easier for us.
-HOST_LDFLAGS  ?= "${LDFLAGS}"
-HOST_CFLAGS   ?= "${CFLAGS}"
-HOST_CXXFLAGS ?= "${CXXFLAGS}"
-HOST_CPPFLAGS ?= "${CPPFLAGS}"
-
 rustlib_suffix = "${TUNE_ARCH}${TARGET_VENDOR}-${TARGET_OS}/rustlib/${RUST_HOST_SYS}/lib"
 # Native sysroot standard library path
 rustlib_src = "${prefix}/lib/${rustlib_suffix}"
-- 
2.43.0

[PATCH 3/9] classes/cargo: move general assignments to cargo_common.bbclass

[Ross Burton]

The cargo integration is split into two classes so that recipes can
inherit cargo_common if they can't use cargo directly to build, for
example when using meson+cargo or building rust itself.

However, a number of variables where in cargo.bbclass when they should
really be in cargo_common.bbclass: move the assignments so that the
cargo.bbclass simply inherits cargo_common, sets B, and implements the
compile/install tasks.

Signed-off-by: Ross Burton <ross.burton@arm.com>
---
 meta/classes-recipe/cargo.bbclass        | 27 ----------------------
 meta/classes-recipe/cargo_common.bbclass | 29 ++++++++++++++++++++++++
 2 files changed, 29 insertions(+), 27 deletions(-)

diff --git a/meta/classes-recipe/cargo.bbclass b/meta/classes-recipe/cargo.bbclass
index b34f3ce0cd7..31e655650cc 100644
--- a/meta/classes-recipe/cargo.bbclass
+++ b/meta/classes-recipe/cargo.bbclass
@@ -26,33 +26,6 @@ DEPENDS:append:class-native = " rust-native"
 # Enable build separation
 B = "${WORKDIR}/build"
 
-# In case something fails in the build process, give a bit more feedback on
-# where the issue occured
-export RUST_BACKTRACE = "1"
-
-RUSTFLAGS ??= ""
-
-# The cargo profile to use. Defaults to release or dev based on DEBUG_BUILD, but
-# can be set to any valid profile.
-# https://doc.rust-lang.org/cargo/reference/profiles.html
-CARGO_PROFILE ?= "${@oe.utils.vartrue('DEBUG_BUILD', 'dev', 'release', d)}"
-
-# --frozen flag will prevent network access (which is required since only
-# the do_fetch step is authorized to access network)
-# and will require an up to date Cargo.lock file.
-# This force the package being built to already ship a Cargo.lock, in the end
-# this is what we want, at least, for reproducibility of the build.
-CARGO_BUILD_FLAGS = "-v --frozen --target ${RUST_HOST_SYS} --profile=${CARGO_PROFILE} --manifest-path=${CARGO_MANIFEST_PATH}"
-
-# The build directory is named after the profile, apart from the dev profile
-# which uses 'debug'.
-def cargo_build_directory(d):
-    profile = d.getVar("CARGO_PROFILE")
-    return "debug" if profile == "dev" else profile
-BUILD_DIR = "${@cargo_build_directory(d)}"
-
-CARGO_TARGET_SUBDIR = "${RUST_HOST_SYS}/${BUILD_DIR}"
-
 oe_cargo_build () {
 	export RUSTFLAGS="${RUSTFLAGS}"
 	bbnote "Using rust targets from ${RUST_TARGET_PATH}"
diff --git a/meta/classes-recipe/cargo_common.bbclass b/meta/classes-recipe/cargo_common.bbclass
index 95739122a59..0fb6844d932 100644
--- a/meta/classes-recipe/cargo_common.bbclass
+++ b/meta/classes-recipe/cargo_common.bbclass
@@ -17,6 +17,35 @@
 # add crate fetch support
 inherit rust-common
 
+# In case something fails in the build process, give a bit more feedback on
+# where the issue occured
+export RUST_BACKTRACE = "1"
+
+# Flags passed to all invocations of rustc
+# https://doc.rust-lang.org/cargo/reference/config.html#buildrustflags
+RUSTFLAGS ??= ""
+
+# The cargo profile to use. Defaults to release or dev based on DEBUG_BUILD, but
+# can be set to any valid profile.
+# https://doc.rust-lang.org/cargo/reference/profiles.html
+CARGO_PROFILE ?= "${@oe.utils.vartrue('DEBUG_BUILD', 'dev', 'release', d)}"
+
+# --frozen flag will prevent network access (which is required since only
+# the do_fetch step is authorized to access network)
+# and will require an up to date Cargo.lock file.
+# This force the package being built to already ship a Cargo.lock, in the end
+# this is what we want, at least, for reproducibility of the build.
+CARGO_BUILD_FLAGS = "-v --frozen --target ${RUST_HOST_SYS} --profile=${CARGO_PROFILE} --manifest-path=${CARGO_MANIFEST_PATH}"
+
+# The build directory is named after the profile, apart from the dev profile
+# which uses 'debug'.
+def cargo_build_directory(d):
+    profile = d.getVar("CARGO_PROFILE")
+    return "debug" if profile == "dev" else profile
+BUILD_DIR = "${@cargo_build_directory(d)}"
+
+CARGO_TARGET_SUBDIR = "${RUST_HOST_SYS}/${BUILD_DIR}"
+
 # Where we download our registry and dependencies to
 export CARGO_HOME = "${UNPACKDIR}/cargo_home"
 
-- 
2.43.0

[PATCH 4/9] classes/cargo: consolidate dependencies

[Ross Burton]

Move the dependencies from cargo to cargo_common: if cargo is being used
in any way then you need to depend on cargo-native.

Inherit rust instead of rust-common or rust-target-config: rust inherits
rust-common that inherits rust-target-config, and rust.bbclass simply
adds the dependency on rust-native. This means we can drop the explicit
rust dependencies to avoid duplication.

Signed-off-by: Ross Burton <ross.burton@arm.com>
---
 meta/classes-recipe/cargo.bbclass        | 9 ---------
 meta/classes-recipe/cargo_common.bbclass | 4 +++-
 2 files changed, 3 insertions(+), 10 deletions(-)

diff --git a/meta/classes-recipe/cargo.bbclass b/meta/classes-recipe/cargo.bbclass
index 31e655650cc..628dbc98f18 100644
--- a/meta/classes-recipe/cargo.bbclass
+++ b/meta/classes-recipe/cargo.bbclass
@@ -10,19 +10,10 @@
 ## Cargo.
 
 inherit cargo_common
-inherit rust-target-config
 
 # the binary we will use
 CARGO = "cargo"
 
-# We need cargo to compile for the target
-BASEDEPENDS:append = " cargo-native"
-
-# Ensure we get the right rust variant
-DEPENDS:append:class-target = " rust-native ${RUSTLIB_DEP}"
-DEPENDS:append:class-nativesdk = " rust-native ${RUSTLIB_DEP}"
-DEPENDS:append:class-native = " rust-native"
-
 # Enable build separation
 B = "${WORKDIR}/build"
 
diff --git a/meta/classes-recipe/cargo_common.bbclass b/meta/classes-recipe/cargo_common.bbclass
index 0fb6844d932..f58bd80728c 100644
--- a/meta/classes-recipe/cargo_common.bbclass
+++ b/meta/classes-recipe/cargo_common.bbclass
@@ -15,7 +15,9 @@
 ##
 
 # add crate fetch support
-inherit rust-common
+inherit rust
+
+BASEDEPENDS:append = " cargo-native"
 
 # In case something fails in the build process, give a bit more feedback on
 # where the issue occured
-- 
2.43.0

[PATCH 5/9] rust: clean up dependencies

[Ross Burton]

The rust recipe inherits cargo_common which now depends on rust-native
and cargo-native, so we can just remove those dependencies in the native
case instead of having to handle target/nativesdk.

Signed-off-by: Ross Burton <ross.burton@arm.com>
---
 meta/recipes-devtools/rust/rust_1.96.1.bb | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/meta/recipes-devtools/rust/rust_1.96.1.bb b/meta/recipes-devtools/rust/rust_1.96.1.bb
index f8f47b04142..7d1761c562c 100644
--- a/meta/recipes-devtools/rust/rust_1.96.1.bb
+++ b/meta/recipes-devtools/rust/rust_1.96.1.bb
@@ -12,21 +12,19 @@ inherit rust
 inherit cargo_common
 
 DEPENDS += "llvm"
+
 # native rust uses cargo/rustc from binary snapshots to bootstrap
 # but everything else should use our native builds
-DEPENDS:append:class-target = " cargo-native rust-native"
-DEPENDS:append:class-nativesdk = " cargo-native rust-native"
+DEPENDS:remove:class-native = "cargo-native"
+INHIBIT_DEFAULT_RUST_DEPS:class-native = "1"
+
+PROVIDES:class-native = "virtual/${TARGET_PREFIX}rust"
 
 RDEPENDS:${PN}:append:class-target = " gcc g++ binutils"
 
 PACKAGECONFIG ??= "llvm-shared"
 PACKAGECONFIG[llvm-shared] = ",,,"
 
-# Otherwise we'll depend on what we provide
-INHIBIT_DEFAULT_RUST_DEPS:class-native = "1"
-# We don't need to depend on gcc-native because yocto assumes it exists
-PROVIDES:class-native = "virtual/${TARGET_PREFIX}rust"
-
 S = "${RUSTSRC}"
 # Separate build directory from the shared source tree so that multiple
 # variants (target, native, nativesdk) don't conflict in the source dir.
-- 
2.43.0

[PATCH 6/9] classes/cargo_c: inherit cargo_common

[Ross Burton]

This class is an alternative to cargo.bbclass, and now the dependencies
have moved to cargo_common.bbclass it can inherit that class directly.

As cargo.bbclass sets B, we can set it in cargo_c.bbclass.

Signed-off-by: Ross Burton <ross.burton@arm.com>
---
 meta/classes-recipe/cargo_c.bbclass | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/classes-recipe/cargo_c.bbclass b/meta/classes-recipe/cargo_c.bbclass
index e91ee1d9fc0..18574b73cb2 100644
--- a/meta/classes-recipe/cargo_c.bbclass
+++ b/meta/classes-recipe/cargo_c.bbclass
@@ -9,7 +9,7 @@
 ## This class is used by any recipes that want to compile a C ABI compatible
 ## library with header and pkg config file
 
-inherit cargo pkgconfig
+inherit cargo_common pkgconfig
 
 # the binaries we will use
 CARGO_C_BUILD = "cargo-cbuild"
@@ -18,6 +18,8 @@ CARGO_C_INSTALL = "cargo-cinstall"
 # We need cargo-c to compile for the target
 BASEDEPENDS:append = " cargo-c-native"
 
+B = "${WORKDIR}/build"
+
 do_compile[progress] = "outof:\s+(\d+)/(\d+)"
 cargo_c_do_compile() {
     oe_cargo_fix_env
-- 
2.43.0

[PATCH 7/9] classes/cargo-c: remove CARGO_C_BUILD/CARGO_C_INSTALL variables

[Ross Burton]

There's no point in having variables to control what cargo-c binaries
are executed as there are no alternatives.

The cargo class does this because it is used when bootstrapping cargo.
This isn't needed to build cargo-c, but the pattern was copied into this
class.

Signed-off-by: Ross Burton <ross.burton@arm.com>
---
 meta/classes-recipe/cargo_c.bbclass | 11 ++---------
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/meta/classes-recipe/cargo_c.bbclass b/meta/classes-recipe/cargo_c.bbclass
index 18574b73cb2..e68ac93a610 100644
--- a/meta/classes-recipe/cargo_c.bbclass
+++ b/meta/classes-recipe/cargo_c.bbclass
@@ -11,10 +11,6 @@
 
 inherit cargo_common pkgconfig
 
-# the binaries we will use
-CARGO_C_BUILD = "cargo-cbuild"
-CARGO_C_INSTALL = "cargo-cinstall"
-
 # We need cargo-c to compile for the target
 BASEDEPENDS:append = " cargo-c-native"
 
@@ -25,16 +21,13 @@ cargo_c_do_compile() {
     oe_cargo_fix_env
     export RUSTFLAGS="${RUSTFLAGS}"
     bbnote "Using rust targets from ${RUST_TARGET_PATH}"
-    bbnote "cargo-cbuild = $(which ${CARGO_C_BUILD})"
-    bbnote "${CARGO_C_BUILD} cbuild ${CARGO_BUILD_FLAGS}"
-    "${CARGO_C_BUILD}" cbuild ${CARGO_BUILD_FLAGS}
+    cargo-cbuild cbuild ${CARGO_BUILD_FLAGS}
 }
 
 cargo_c_do_install() {
     oe_cargo_fix_env
     export RUSTFLAGS="${RUSTFLAGS}"
-    bbnote "cargo-cinstall = $(which ${CARGO_C_INSTALL})"
-    "${CARGO_C_INSTALL}" cinstall ${CARGO_BUILD_FLAGS} \
+    cargo-cinstall cinstall ${CARGO_BUILD_FLAGS} \
         --destdir ${D} \
         --prefix ${prefix} \
         --libdir ${libdir} \
-- 
2.43.0

[PATCH 8/9] classes/cargo-c: pass flags via CARGO_BUILD_FLAGS

[Ross Burton]

We need to pass the same flags to cbuild and cinstall, as otherwise it
will build in do_compile and then rebuild with the right paths in
do_install.

Add the flags to CARGO_BUILD_FLAGS so that they get used in all calls
and do_install no longer does any building. Example from buildstats:

PKG                        TASK        ABSDIFF  RELDIFF  WALLTIME1 -> WALLTIME2
gstreamer1.0-plugins-rs    do_install  -263.6s   -99.0%     266.2s -> 2.7s

Signed-off-by: Ross Burton <ross.burton@arm.com>
---
 meta/classes-recipe/cargo_c.bbclass | 13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/meta/classes-recipe/cargo_c.bbclass b/meta/classes-recipe/cargo_c.bbclass
index e68ac93a610..cd486b20067 100644
--- a/meta/classes-recipe/cargo_c.bbclass
+++ b/meta/classes-recipe/cargo_c.bbclass
@@ -16,6 +16,13 @@ BASEDEPENDS:append = " cargo-c-native"
 
 B = "${WORKDIR}/build"
 
+CARGO_BUILD_FLAGS += "\
+    --destdir ${D} \
+    --prefix ${prefix} \
+    --libdir ${libdir} \
+    --library-type cdylib \
+    "
+
 do_compile[progress] = "outof:\s+(\d+)/(\d+)"
 cargo_c_do_compile() {
     oe_cargo_fix_env
@@ -27,11 +34,7 @@ cargo_c_do_compile() {
 cargo_c_do_install() {
     oe_cargo_fix_env
     export RUSTFLAGS="${RUSTFLAGS}"
-    cargo-cinstall cinstall ${CARGO_BUILD_FLAGS} \
-        --destdir ${D} \
-        --prefix ${prefix} \
-        --libdir ${libdir} \
-        --library-type cdylib
+    cargo-cinstall cinstall ${CARGO_BUILD_FLAGS}
 }
 
 EXPORT_FUNCTIONS do_compile do_install
-- 
2.43.0

[PATCH 9/9] classes/cargo: merge oe_cargo_build into cargo_do_compile

[Ross Burton]

A layer of indirection between cargo_do_compile() and actually calling
cargo isn't needed, so merge oe_cargo_build into cargo_do_compile.

Signed-off-by: Ross Burton <ross.burton@arm.com>
---
 meta/classes-recipe/cargo.bbclass | 8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/meta/classes-recipe/cargo.bbclass b/meta/classes-recipe/cargo.bbclass
index 628dbc98f18..586071988a9 100644
--- a/meta/classes-recipe/cargo.bbclass
+++ b/meta/classes-recipe/cargo.bbclass
@@ -17,7 +17,8 @@ CARGO = "cargo"
 # Enable build separation
 B = "${WORKDIR}/build"
 
-oe_cargo_build () {
+do_compile[progress] = "outof:\s+(\d+)/(\d+)"
+cargo_do_compile () {
 	export RUSTFLAGS="${RUSTFLAGS}"
 	bbnote "Using rust targets from ${RUST_TARGET_PATH}"
 	bbnote "cargo = $(which ${CARGO})"
@@ -25,11 +26,6 @@ oe_cargo_build () {
 	"${CARGO}" build ${CARGO_BUILD_FLAGS} ${PACKAGECONFIG_CONFARGS} "$@"
 }
 
-do_compile[progress] = "outof:\s+(\d+)/(\d+)"
-cargo_do_compile () {
-	oe_cargo_build
-}
-
 cargo_do_install () {
 	local have_installed=false
 	for tgt in "${B}/target/${CARGO_TARGET_SUBDIR}/"*; do
-- 
2.43.0

Re: [OE-core] [PATCH 4/9] classes/cargo: consolidate dependencies

[Mathieu Dubois-Briand]

On Tue Aug 4, 2026 at 6:57 PM CEST, Ross Burton via lists.openembedded.org wrote:
> Move the dependencies from cargo to cargo_common: if cargo is being used
> in any way then you need to depend on cargo-native.
>
> Inherit rust instead of rust-common or rust-target-config: rust inherits
> rust-common that inherits rust-target-config, and rust.bbclass simply
> adds the dependency on rust-native. This means we can drop the explicit
> rust dependencies to avoid duplication.
>
> Signed-off-by: Ross Burton <ross.burton@arm.com>
> ---

Hi Ross,

It looks like this is breaking some selftests on the autobuilder:

2026-08-05 04:42:45,835 - oe-selftest - INFO - sstatetests.SStateHashSameSigs.test_sstate_sdk_arch_same_hash (subunit.RemotedTestCase)
2026-08-05 04:42:45,835 - oe-selftest - INFO -  ... FAIL
...
2026-08-05 04:42:45,835 - oe-selftest - INFO - 6: 27/69 387/763 (108.57s) (2 failed) (sstatetests.SStateHashSameSigs.test_sstate_sdk_arch_same_hash)
2026-08-05 04:42:45,836 - oe-selftest - INFO - testtools.testresult.real._StringException: Traceback (most recent call last):
  File "/srv/pokybuild/yocto-worker/oe-selftest-debian/build/layers/openembedded-core/meta/lib/oeqa/selftest/cases/sstatetests.py", line 416, in test_sstate_sdk_arch_same_hash
    self.sstate_hashtest("aarch64")
  File "/srv/pokybuild/yocto-worker/oe-selftest-debian/build/layers/openembedded-core/meta/lib/oeqa/core/decorator/__init__.py", line 35, in wrapped_f
    return func(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^
  File "/srv/pokybuild/yocto-worker/oe-selftest-debian/build/layers/openembedded-core/meta/lib/oeqa/selftest/cases/sstatetests.py", line 401, in sstate_hashtest
    self.assertCountEqual(files1, files2)
  File "/usr/lib/python3.12/unittest/case.py", line 1216, in assertCountEqual
    self.fail(msg)
  File "/usr/lib/python3.12/unittest/case.py", line 715, in fail
    raise self.failureException(msg)
AssertionError: Element counts were not equal:
First has 1, Second has 0:  '/srv/pokybuild/yocto-worker/oe-selftest-debian/build/build-st-3947568/tmp-sstatesamehash/stamps/all-poky-linux/adwaita-icon-theme/50.0.do_install.sigdata.cf83a7b1dadddfa2d6b44fc9390f46b27793c74918dbab4fe0048d924780eaf5'
First has 1, Second has 0:  '/srv/pokybuild/yocto-worker/oe-selftest-debian/build/build-st-3947568/tmp-sstatesamehash/stamps/all-poky-linux/adwaita-icon-theme/50.0.do_create_package_spdx.sigdata.f15f70b42ba9db4c88b4cd7b650dddf4f7b1dbbd911ff71f2c803f3b16d985ca'
First has 1, Second has 0:  '/srv/pokybuild/yocto-worker/oe-selftest-debian/build/build-st-3947568/tmp-sstatesamehash/stamps/all-poky-linux/adwaita-icon-theme/50.0.do_package.sigdata.81c59c71a0ee5154503141307ed14df0ac325fce8e0351ec308317e951ea66f1'
First has 1, Second has 0:  '/srv/pokybuild/yocto-worker/oe-selftest-debian/build/build-st-3947568/tmp
...

And I suspect it's also responsible of these two failures:

2026-08-05 04:39:10,815 - oe-selftest - INFO - sstatetests.SStateHashSameSigs.test_sstate_32_64_same_hash (subunit.RemotedTestCase)
2026-08-05 04:39:10,816 - oe-selftest - INFO -  ... FAIL
...
2026-08-05 05:32:43,041 - oe-selftest - INFO - devtool.DevtoolIdeSdkTests.test_devtool_ide_sdk_code_meson_clang (subunit.RemotedTestCase)
2026-08-05 05:32:43,041 - oe-selftest - INFO -  ... FAIL

https://autobuilder.yoctoproject.org/valkyrie/#/builders/35/builds/4471
https://autobuilder.yoctoproject.org/valkyrie/#/builders/48/builds/4289

Can you have a look at the issue?

Thanks,
Mathieu

-- 
Mathieu Dubois-Briand, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com