[PATCH 1/4] libtool: strip build system triplet from installed libtool script

[PATCH 1/4] libtool: strip build system triplet from installed libtool script

[Alejandro Hernandez]

The installed /usr/bin/libtool script sourced by any recipe that
inherits libtool contains build_alias=, build= and build_os= lines
populated by config.status with the *build machine's* triplet
(e.g. build=x86_64-pc-linux-gnu, build_alias=x86_64-linux). Those
values vary between autobuilder workers whose config.guess reports
different vendors or OS strings, which makes libtool.rpm non-
reproducible across the autobuilder pool and shows up as a diff in
the reproducibility selftest.

Extend the sanitising sed in remove-buildpaths.inc to blank those
three lines the same way the existing rules blank sysroot and
build-path references.

Verified locally: before this change the installed libtool contained
`build_alias=x86_64-linux`, `build=x86_64-pc-linux-gnu` and
`build_os=linux-gnu`; after this change all three lines are empty.

Assisted-by: AI - OpenAI
Signed-off-by: Alejandro Hernandez <alhe@linux.microsoft.com>
---
 meta/recipes-devtools/libtool/remove-buildpaths.inc | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-devtools/libtool/remove-buildpaths.inc b/meta/recipes-devtools/libtool/remove-buildpaths.inc
index 1ca95aeace..31bae6fb62 100644
--- a/meta/recipes-devtools/libtool/remove-buildpaths.inc
+++ b/meta/recipes-devtools/libtool/remove-buildpaths.inc
@@ -9,5 +9,8 @@ do_install:append () {
             -e 's@^\(predep_objects="\).*@\1"@' \
             -e 's@^\(postdep_objects="\).*@\1"@' \
             -e "s@${HOSTTOOLS_DIR}/@@g" \
+            -e 's@^build_alias=.*@build_alias=@' \
+            -e 's@^build=.*@build=@' \
+            -e 's@^build_os=.*@build_os=@' \
             -i ${D}${bindir}/libtool
 }
-- 
2.43.0

[PATCH 2/4] ptest.bbclass: strip build machine triplet from installed ptest Makefiles

[Alejandro Hernandez]

do_install_ptest_base already rewrites HOSTTOOLS_DIR and WORKDIR
references out of installed ptest Makefiles, but automake-generated
Makefiles (as shipped by strace-ptest, gnutls-ptest and others) also
carry six autoconf-generated variables that encode the *build
machine*, not the target:

  build_triplet, build_alias, build, build_cpu, build_vendor, build_os

Those values differ across autobuilder workers (typical values are
build=x86_64-pc-linux-gnu, build_alias=x86_64-linux, build_vendor=pc),
causing corresponding -ptest packages to fail the reproducibility
selftest.

Add sed rules to blank the RHS of each of those assignments, plus the
matching automake helper lines `set build_triplet` and
`set build_alias`, and extend PTEST_BUILD_HOST_FILES to include
site.exp (also autoconf-generated with the same variables).

Verified locally: before this change strace-ptest carried
`build_triplet = x86_64-pc-linux-gnu`, `build = x86_64-pc-linux-gnu`,
`build_alias = x86_64-linux`, `build_cpu = x86_64`,
`build_vendor = pc`, `build_os = linux-gnu`; after this change all six
lines have an empty RHS.

Assisted-by: AI - OpenAI
Signed-off-by: Alejandro Hernandez <alhe@linux.microsoft.com>
---
 meta/classes-recipe/ptest.bbclass | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/meta/classes-recipe/ptest.bbclass b/meta/classes-recipe/ptest.bbclass
index 64c4bb9788..0f80fbc1d8 100644
--- a/meta/classes-recipe/ptest.bbclass
+++ b/meta/classes-recipe/ptest.bbclass
@@ -9,7 +9,7 @@ DESCRIPTION:${PN}-ptest ?= "${DESCRIPTION}  \
 This package contains a test directory ${PTEST_PATH} for package test purposes."
 
 PTEST_PATH ?= "${libdir}/${BPN}/ptest"
-PTEST_BUILD_HOST_FILES ?= "Makefile"
+PTEST_BUILD_HOST_FILES ?= "Makefile site.exp"
 PTEST_BUILD_HOST_PATTERN ?= ""
 PTEST_PARALLEL_MAKE ?= "${PARALLEL_MAKE}"
 PTEST_PARALLEL_MAKEINST ?= "${PARALLEL_MAKEINST}"
@@ -69,6 +69,14 @@ do_install_ptest_base() {
             sed -e 's#${HOSTTOOLS_DIR}/*##g' \
                 -e 's#${WORKDIR}/*=#.=#g' \
                 -e 's#${WORKDIR}/*##g' \
+                -e 's#^\(build_triplet[[:space:]]*=\).*#\1#' \
+                -e 's#^\(build_alias[[:space:]]*=\).*#\1#' \
+                -e 's#^\(build[[:space:]]*=\).*#\1#' \
+                -e 's#^\(build_cpu[[:space:]]*=\).*#\1#' \
+                -e 's#^\(build_vendor[[:space:]]*=\).*#\1#' \
+                -e 's#^\(build_os[[:space:]]*=\).*#\1#' \
+                -e 's#^\(set build_triplet\).*#\1#' \
+                -e 's#^\(set build_alias\).*#\1#' \
                 -i $installed_ptest_file
             if [ -n "${PTEST_BUILD_HOST_PATTERN}" ]; then
                sed -E '/${PTEST_BUILD_HOST_PATTERN}/d' \
-- 
2.43.0

[PATCH 3/4] python_pep517.bbclass: always export _PYTHON_HOST_PLATFORM for wheel tag

[Alejandro Hernandez]

python distutils/sysconfig.get_platform() falls back to
distutils.util.get_platform() when the _PYTHON_HOST_PLATFORM
environment variable is unset, and returns the *build host* arch.
The result is baked into the produced wheel's filename
(pkg-<ver>-cp3XX-cp3XX-<PLAT>.whl) and its <pkg>.dist-info/WHEEL
metadata.

Without this export, extension-module wheels tag themselves with
whichever arch the autobuilder worker happens to have, which makes
the resulting rpm non-reproducible across mixed-arch autobuilder
pools.

Since python 3.14 + wheel >=0.44 also rejects wheels with an empty
platform tag ("Bad wheel filename"), the value has to be non-empty
in every class scope. HOST_ARCH is class-scoped by bitbake
(target/native/cross/nativesdk), so `linux-${HOST_ARCH}` covers
every case with a single unconditional assignment. Setting per-class
overrides to "" (as an earlier draft did) trips the wheel filename
check and must be avoided.

Pure-python wheels ignore _PYTHON_HOST_PLATFORM and remain tagged
"any", so this change only affects wheels that ship compiled
extensions (cffi, cryptography, numpy, bcrypt, markupsafe, psutil,
rpds-py, websockets, ...).

Assisted-by: AI - OpenAI
Signed-off-by: Alejandro Hernandez <alhe@linux.microsoft.com>
---
 meta/classes-recipe/python_pep517.bbclass | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/meta/classes-recipe/python_pep517.bbclass b/meta/classes-recipe/python_pep517.bbclass
index d6246af5c2..06b23d3cba 100644
--- a/meta/classes-recipe/python_pep517.bbclass
+++ b/meta/classes-recipe/python_pep517.bbclass
@@ -30,6 +30,22 @@ PEP517_INSTALL_PYTHON:class-native = "nativepython3"
 # pypa/installer option to control the bytecode compilation
 INSTALL_WHEEL_COMPILE_BYTECODE ?= "--compile-bytecode=0"
 
+# Force the wheel's platform tag to reflect the target machine rather than the
+# build host. Without this, extension-module wheels bake the build host's arch
+# (e.g. linux_x86_64) into <pkg>.dist-info/WHEEL via distutils/sysconfig's
+# get_platform(), which breaks reproducibility across autobuilder workers of
+# different architectures. Pure-python wheels ignore this variable and remain
+# tagged "any".
+#
+# HOST_ARCH is class-scoped by bitbake:
+#   - target:     HOST_ARCH == TARGET_ARCH (reproducible across workers)
+#   - native:     HOST_ARCH == BUILD_ARCH  (matches worker arch, unpackaged)
+#   - cross:      HOST_ARCH == BUILD_ARCH
+#   - nativesdk:  HOST_ARCH == SDK_ARCH
+# so a single expression covers every class without producing an empty tag
+# (which python 3.14 + wheel >=0.44 rejects with "Bad wheel filename").
+export _PYTHON_HOST_PLATFORM = "linux-${HOST_ARCH}"
+
 # PEP517 doesn't have a specific configure step, so set an empty do_configure to avoid
 # running base_do_configure.
 python_pep517_do_configure () {
-- 
2.43.0

Re: [OE-core] [PATCH 3/4] python_pep517.bbclass: always export _PYTHON_HOST_PLATFORM for wheel tag

[Richard Purdie]

On Tue, 2026-08-04 at 22:04 +0000, Alejandro Hernandez Samaniego via lists.openembedded.org wrote:
> python distutils/sysconfig.get_platform() falls back to
> distutils.util.get_platform() when the _PYTHON_HOST_PLATFORM
> environment variable is unset, and returns the *build host* arch.
> The result is baked into the produced wheel's filename
> (pkg-<ver>-cp3XX-cp3XX-<PLAT>.whl) and its <pkg>.dist-info/WHEEL
> metadata.
> 
> Without this export, extension-module wheels tag themselves with
> whichever arch the autobuilder worker happens to have, which makes
> the resulting rpm non-reproducible across mixed-arch autobuilder
> pools.
> 
> Since python 3.14 + wheel >=0.44 also rejects wheels with an empty
> platform tag ("Bad wheel filename"), the value has to be non-empty
> in every class scope. HOST_ARCH is class-scoped by bitbake
> (target/native/cross/nativesdk), so `linux-${HOST_ARCH}` covers
> every case with a single unconditional assignment. Setting per-class
> overrides to "" (as an earlier draft did) trips the wheel filename
> check and must be avoided.
> 
> Pure-python wheels ignore _PYTHON_HOST_PLATFORM and remain tagged
> "any", so this change only affects wheels that ship compiled
> extensions (cffi, cryptography, numpy, bcrypt, markupsafe, psutil,
> rpds-py, websockets, ...).
> 
> Assisted-by: AI - OpenAI
> Signed-off-by: Alejandro Hernandez <alhe@linux.microsoft.com>
> ---
>  meta/classes-recipe/python_pep517.bbclass | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
> 
> diff --git a/meta/classes-recipe/python_pep517.bbclass b/meta/classes-recipe/python_pep517.bbclass
> index d6246af5c2..06b23d3cba 100644
> --- a/meta/classes-recipe/python_pep517.bbclass
> +++ b/meta/classes-recipe/python_pep517.bbclass
> @@ -30,6 +30,22 @@ PEP517_INSTALL_PYTHON:class-native = "nativepython3"
>  # pypa/installer option to control the bytecode compilation
>  INSTALL_WHEEL_COMPILE_BYTECODE ?= "--compile-bytecode=0"
>  
> +# Force the wheel's platform tag to reflect the target machine rather than the
> +# build host. Without this, extension-module wheels bake the build host's arch
> +# (e.g. linux_x86_64) into <pkg>.dist-info/WHEEL via distutils/sysconfig's
> +# get_platform(), which breaks reproducibility across autobuilder workers of
> +# different architectures. Pure-python wheels ignore this variable and remain
> +# tagged "any".
> +#
> +# HOST_ARCH is class-scoped by bitbake:
> +#   - target:     HOST_ARCH == TARGET_ARCH (reproducible across workers)
> +#   - native:     HOST_ARCH == BUILD_ARCH  (matches worker arch, unpackaged)
> +#   - cross:      HOST_ARCH == BUILD_ARCH
> +#   - nativesdk:  HOST_ARCH == SDK_ARCH
> +# so a single expression covers every class without producing an empty tag
> +# (which python 3.14 + wheel >=0.44 rejects with "Bad wheel filename").
> +export _PYTHON_HOST_PLATFORM = "linux-${HOST_ARCH}"

The fix looks right, thanks!

I'm not sure we need the 10+ lines of explanation from AI ;-) The
commit message could be more concise too. We're seening way too much
text being added by AI in general and it will make the codebase harder
to understand in the long run :(.

Cheers,

Richard

Re: [OE-core] [PATCH 3/4] python_pep517.bbclass: always export _PYTHON_HOST_PLATFORM for wheel tag

[Alejandro Hernandez]

[-- Attachment #1: Type: text/plain, Size: 3953 bytes --]


On 8/6/2026 6:26 AM, Richard Purdie via lists.openembedded.org wrote:
> On Tue, 2026-08-04 at 22:04 +0000, Alejandro Hernandez Samaniego via lists.openembedded.org wrote:
>> python distutils/sysconfig.get_platform() falls back to
>> distutils.util.get_platform() when the _PYTHON_HOST_PLATFORM
>> environment variable is unset, and returns the *build host* arch.
>> The result is baked into the produced wheel's filename
>> (pkg-<ver>-cp3XX-cp3XX-<PLAT>.whl) and its <pkg>.dist-info/WHEEL
>> metadata.
>>
>> Without this export, extension-module wheels tag themselves with
>> whichever arch the autobuilder worker happens to have, which makes
>> the resulting rpm non-reproducible across mixed-arch autobuilder
>> pools.
>>
>> Since python 3.14 + wheel >=0.44 also rejects wheels with an empty
>> platform tag ("Bad wheel filename"), the value has to be non-empty
>> in every class scope. HOST_ARCH is class-scoped by bitbake
>> (target/native/cross/nativesdk), so `linux-${HOST_ARCH}` covers
>> every case with a single unconditional assignment. Setting per-class
>> overrides to "" (as an earlier draft did) trips the wheel filename
>> check and must be avoided.
>>
>> Pure-python wheels ignore _PYTHON_HOST_PLATFORM and remain tagged
>> "any", so this change only affects wheels that ship compiled
>> extensions (cffi, cryptography, numpy, bcrypt, markupsafe, psutil,
>> rpds-py, websockets, ...).
>>
>> Assisted-by: AI - OpenAI
>> Signed-off-by: Alejandro Hernandez<alhe@linux.microsoft.com>
>> ---
>>   meta/classes-recipe/python_pep517.bbclass | 16 ++++++++++++++++
>>   1 file changed, 16 insertions(+)
>>
>> diff --git a/meta/classes-recipe/python_pep517.bbclass b/meta/classes-recipe/python_pep517.bbclass
>> index d6246af5c2..06b23d3cba 100644
>> --- a/meta/classes-recipe/python_pep517.bbclass
>> +++ b/meta/classes-recipe/python_pep517.bbclass
>> @@ -30,6 +30,22 @@ PEP517_INSTALL_PYTHON:class-native = "nativepython3"
>>   # pypa/installer option to control the bytecode compilation
>>   INSTALL_WHEEL_COMPILE_BYTECODE ?= "--compile-bytecode=0"
>>   
>> +# Force the wheel's platform tag to reflect the target machine rather than the
>> +# build host. Without this, extension-module wheels bake the build host's arch
>> +# (e.g. linux_x86_64) into <pkg>.dist-info/WHEEL via distutils/sysconfig's
>> +# get_platform(), which breaks reproducibility across autobuilder workers of
>> +# different architectures. Pure-python wheels ignore this variable and remain
>> +# tagged "any".
>> +#
>> +# HOST_ARCH is class-scoped by bitbake:
>> +#   - target:     HOST_ARCH == TARGET_ARCH (reproducible across workers)
>> +#   - native:     HOST_ARCH == BUILD_ARCH  (matches worker arch, unpackaged)
>> +#   - cross:      HOST_ARCH == BUILD_ARCH
>> +#   - nativesdk:  HOST_ARCH == SDK_ARCH
>> +# so a single expression covers every class without producing an empty tag
>> +# (which python 3.14 + wheel >=0.44 rejects with "Bad wheel filename").
>> +export _PYTHON_HOST_PLATFORM = "linux-${HOST_ARCH}"
> The fix looks right, thanks!
>
> I'm not sure we need the 10+ lines of explanation from AI ;-) The
> commit message could be more concise too. We're seening way too much
> text being added by AI in general and it will make the codebase harder
> to understand in the long run :(.
>
> Cheers,
>
> Richard

I agree, I can send a v2 or just keep it in mind for next time, let me know.

Cheers,
Alejandro

>
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#242937):https://lists.openembedded.org/g/openembedded-core/message/242937
> Mute This Topic:https://lists.openembedded.org/mt/120602086/4354175
> Group Owner:openembedded-core+owner@lists.openembedded.org
> Unsubscribe:https://lists.openembedded.org/g/openembedded-core/unsub [alhe@linux.microsoft.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

[-- Attachment #2: Type: text/html, Size: 5251 bytes --]

Re: [OE-core] [PATCH 3/4] python_pep517.bbclass: always export _PYTHON_HOST_PLATFORM for wheel tag

[Richard Purdie]

On Thu, 2026-08-06 at 09:51 -0600, Alejandro Hernandez wrote:
>  
> 
> 
>  
> 
>  
> 
> On 8/6/2026 6:26 AM, Richard Purdie via lists.openembedded.org wrote:
>  
> 
>  
> 
> >  
> > 
> > On Tue, 2026-08-04 at 22:04 +0000, Alejandro Hernandez Samaniego via lists.openembedded.org wrote:
> >  
> > 
> > >  
> > > 
> > > python distutils/sysconfig.get_platform() falls back to
> > > distutils.util.get_platform() when the _PYTHON_HOST_PLATFORM
> > > environment variable is unset, and returns the *build host* arch.
> > > The result is baked into the produced wheel's filename
> > > (pkg-<ver>-cp3XX-cp3XX-<PLAT>.whl) and its <pkg>.dist-info/WHEEL
> > > metadata.
> > > 
> > > Without this export, extension-module wheels tag themselves with
> > > whichever arch the autobuilder worker happens to have, which makes
> > > the resulting rpm non-reproducible across mixed-arch autobuilder
> > > pools.
> > > 
> > > Since python 3.14 + wheel >=0.44 also rejects wheels with an empty
> > > platform tag ("Bad wheel filename"), the value has to be non-empty
> > > in every class scope. HOST_ARCH is class-scoped by bitbake
> > > (target/native/cross/nativesdk), so `linux-${HOST_ARCH}` covers
> > > every case with a single unconditional assignment. Setting per-class
> > > overrides to "" (as an earlier draft did) trips the wheel filename
> > > check and must be avoided.
> > > 
> > > Pure-python wheels ignore _PYTHON_HOST_PLATFORM and remain tagged
> > > "any", so this change only affects wheels that ship compiled
> > > extensions (cffi, cryptography, numpy, bcrypt, markupsafe, psutil,
> > > rpds-py, websockets, ...).
> > > 
> > > Assisted-by: AI - OpenAI
> > > Signed-off-by: Alejandro Hernandez <alhe@linux.microsoft.com>
> > > ---
> > >  meta/classes-recipe/python_pep517.bbclass | 16 ++++++++++++++++
> > >  1 file changed, 16 insertions(+)
> > > 
> > > diff --git a/meta/classes-recipe/python_pep517.bbclass b/meta/classes-recipe/python_pep517.bbclass
> > > index d6246af5c2..06b23d3cba 100644
> > > --- a/meta/classes-recipe/python_pep517.bbclass
> > > +++ b/meta/classes-recipe/python_pep517.bbclass
> > > @@ -30,6 +30,22 @@ PEP517_INSTALL_PYTHON:class-native = "nativepython3"
> > >  # pypa/installer option to control the bytecode compilation
> > >  INSTALL_WHEEL_COMPILE_BYTECODE ?= "--compile-bytecode=0"
> > >  
> > > +# Force the wheel's platform tag to reflect the target machine rather than the
> > > +# build host. Without this, extension-module wheels bake the build host's arch
> > > +# (e.g. linux_x86_64) into <pkg>.dist-info/WHEEL via distutils/sysconfig's
> > > +# get_platform(), which breaks reproducibility across autobuilder workers of
> > > +# different architectures. Pure-python wheels ignore this variable and remain
> > > +# tagged "any".
> > > +#
> > > +# HOST_ARCH is class-scoped by bitbake:
> > > +#   - target:     HOST_ARCH == TARGET_ARCH (reproducible across workers)
> > > +#   - native:     HOST_ARCH == BUILD_ARCH  (matches worker arch, unpackaged)
> > > +#   - cross:      HOST_ARCH == BUILD_ARCH
> > > +#   - nativesdk:  HOST_ARCH == SDK_ARCH
> > > +# so a single expression covers every class without producing an empty tag
> > > +# (which python 3.14 + wheel >=0.44 rejects with "Bad wheel filename").
> > > +export _PYTHON_HOST_PLATFORM = "linux-${HOST_ARCH}"
> > >  
> > > 
> >  
> > 
> > The fix looks right, thanks!
> > 
> > I'm not sure we need the 10+ lines of explanation from AI ;-) The
> > commit message could be more concise too. We're seening way too much
> > text being added by AI in general and it will make the codebase harder
> > to understand in the long run :(.
> > 
> > Cheers,
> > 
> > Richard
> >  
> > 
>  
> 
> I agree, I can send a v2 or just keep it in mind for next time, let me know.

v2 please, it is too verbose and I would have to manually trim it...

Cheers,

Richard

Re: [OE-core] [PATCH 3/4] python_pep517.bbclass: always export _PYTHON_HOST_PLATFORM for wheel tag

[Alejandro Hernandez]

[-- Attachment #1: Type: text/plain, Size: 4470 bytes --]


On 8/6/2026 10:09 AM, Richard Purdie via lists.openembedded.org wrote:
> On Thu, 2026-08-06 at 09:51 -0600, Alejandro Hernandez wrote:
>>   
>>
>>
>>   
>>
>>   
>>
>> On 8/6/2026 6:26 AM, Richard Purdie via lists.openembedded.org wrote:
>>   
>>
>>   
>>
>>>   
>>>
>>> On Tue, 2026-08-04 at 22:04 +0000, Alejandro Hernandez Samaniego via lists.openembedded.org wrote:
>>>   
>>>
>>>>   
>>>>
>>>> python distutils/sysconfig.get_platform() falls back to
>>>> distutils.util.get_platform() when the _PYTHON_HOST_PLATFORM
>>>> environment variable is unset, and returns the *build host* arch.
>>>> The result is baked into the produced wheel's filename
>>>> (pkg-<ver>-cp3XX-cp3XX-<PLAT>.whl) and its <pkg>.dist-info/WHEEL
>>>> metadata.
>>>>
>>>> Without this export, extension-module wheels tag themselves with
>>>> whichever arch the autobuilder worker happens to have, which makes
>>>> the resulting rpm non-reproducible across mixed-arch autobuilder
>>>> pools.
>>>>
>>>> Since python 3.14 + wheel >=0.44 also rejects wheels with an empty
>>>> platform tag ("Bad wheel filename"), the value has to be non-empty
>>>> in every class scope. HOST_ARCH is class-scoped by bitbake
>>>> (target/native/cross/nativesdk), so `linux-${HOST_ARCH}` covers
>>>> every case with a single unconditional assignment. Setting per-class
>>>> overrides to "" (as an earlier draft did) trips the wheel filename
>>>> check and must be avoided.
>>>>
>>>> Pure-python wheels ignore _PYTHON_HOST_PLATFORM and remain tagged
>>>> "any", so this change only affects wheels that ship compiled
>>>> extensions (cffi, cryptography, numpy, bcrypt, markupsafe, psutil,
>>>> rpds-py, websockets, ...).
>>>>
>>>> Assisted-by: AI - OpenAI
>>>> Signed-off-by: Alejandro Hernandez<alhe@linux.microsoft.com>
>>>> ---
>>>>   meta/classes-recipe/python_pep517.bbclass | 16 ++++++++++++++++
>>>>   1 file changed, 16 insertions(+)
>>>>
>>>> diff --git a/meta/classes-recipe/python_pep517.bbclass b/meta/classes-recipe/python_pep517.bbclass
>>>> index d6246af5c2..06b23d3cba 100644
>>>> --- a/meta/classes-recipe/python_pep517.bbclass
>>>> +++ b/meta/classes-recipe/python_pep517.bbclass
>>>> @@ -30,6 +30,22 @@ PEP517_INSTALL_PYTHON:class-native = "nativepython3"
>>>>   # pypa/installer option to control the bytecode compilation
>>>>   INSTALL_WHEEL_COMPILE_BYTECODE ?= "--compile-bytecode=0"
>>>>   
>>>> +# Force the wheel's platform tag to reflect the target machine rather than the
>>>> +# build host. Without this, extension-module wheels bake the build host's arch
>>>> +# (e.g. linux_x86_64) into <pkg>.dist-info/WHEEL via distutils/sysconfig's
>>>> +# get_platform(), which breaks reproducibility across autobuilder workers of
>>>> +# different architectures. Pure-python wheels ignore this variable and remain
>>>> +# tagged "any".
>>>> +#
>>>> +# HOST_ARCH is class-scoped by bitbake:
>>>> +#   - target:     HOST_ARCH == TARGET_ARCH (reproducible across workers)
>>>> +#   - native:     HOST_ARCH == BUILD_ARCH  (matches worker arch, unpackaged)
>>>> +#   - cross:      HOST_ARCH == BUILD_ARCH
>>>> +#   - nativesdk:  HOST_ARCH == SDK_ARCH
>>>> +# so a single expression covers every class without producing an empty tag
>>>> +# (which python 3.14 + wheel >=0.44 rejects with "Bad wheel filename").
>>>> +export _PYTHON_HOST_PLATFORM = "linux-${HOST_ARCH}"
>>>>   
>>>>
>>>   
>>>
>>> The fix looks right, thanks!
>>>
>>> I'm not sure we need the 10+ lines of explanation from AI ;-) The
>>> commit message could be more concise too. We're seening way too much
>>> text being added by AI in general and it will make the codebase harder
>>> to understand in the long run :(.
>>>
>>> Cheers,
>>>
>>> Richard
>>>   
>>>
>>   
>>
>> I agree, I can send a v2 or just keep it in mind for next time, let me know.
> v2 please, it is too verbose and I would have to manually trim it...
>
> Cheers,
>
> Richard

Sent v2

Cheers!

>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#242955):https://lists.openembedded.org/g/openembedded-core/message/242955
> Mute This Topic:https://lists.openembedded.org/mt/120602086/4354175
> Group Owner:openembedded-core+owner@lists.openembedded.org
> Unsubscribe:https://lists.openembedded.org/g/openembedded-core/unsub [alhe@linux.microsoft.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

[-- Attachment #2: Type: text/html, Size: 5857 bytes --]

[PATCH 4/4] bitbake.conf, rust-common.bbclass: include RUST_BUILD_SYS in the task hash

[Alejandro Hernandez]

RUST_BUILD_SYS is currently listed in BB_BASEHASH_IGNORE_VARS, which
tells bitbake that rust recipes should hash-match regardless of the
build machine's triplet. In practice that is not true:

rustc computes each crate's Strict Version Hash (SVH) using inputs
that include the *stage0/stage1 bootstrap compiler* fingerprint, which
in turn depends on the build host arch. That seed cascades through
every dependent crate's mangled symbols and the packing order of
rodata sections, so an sstate blob populated on one worker arch and
reused on a differently-arched worker produces byte-different (but
semantically identical) artifacts and fails the reproducibility
selftest causing autobuilder intermittent issues when the sstate
matches for the incorrect architecture.

Remove RUST_BUILD_SYS from BB_BASEHASH_IGNORE_VARS so the task hash
tracks the build triplet and mixed-arch autobuilder pools get an
sstate miss instead of a silently-wrong hit. RUST_HOST_SYS and
RUST_TARGET_SYS stay excluded because they're already covered by the
target/host arch hash inputs.

While this is not ideal, it should unblock the reproducible test case,
another solution would be to patch rust sources manually and attempt
to upstream that change.

This also has the side-effect that multiple variants of the conflicting
rust recipes sstate artifacts are created, but they'll be correctly used
now in each architecture.

Also add an explanatory comment next to the RUST_*_SYS[vardepvalue]
declarations in rust-common.bbclass so future readers don't re-add
the exclusion.

Verified locally: Tier 1 sighash test toggling BUILD_ARCH now produces
different task hashes for rust/libstd-rs/rpm-sequoia/python3-crypto-
graphy/cargo/librsvg, where previously the hashes matched despite the
build machine change.

[YOCTO #15554]

Assisted-by: AI - OpenAI
Signed-off-by: Alejandro Hernandez <alhe@linux.microsoft.com>
---
 meta/classes-recipe/rust-common.bbclass | 10 ++++++++++
 meta/conf/bitbake.conf                  |  2 +-
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/meta/classes-recipe/rust-common.bbclass b/meta/classes-recipe/rust-common.bbclass
index 6bc42016d1..98b46c4e3c 100644
--- a/meta/classes-recipe/rust-common.bbclass
+++ b/meta/classes-recipe/rust-common.bbclass
@@ -114,6 +114,16 @@ RUST_HOST_SYS[vardepvalue] = "${RUST_HOST_SYS}"
 RUST_TARGET_SYS = "${@rust_base_triple(d, 'TARGET')}"
 RUST_TARGET_SYS[vardepvalue] = "${RUST_TARGET_SYS}"
 
+# Note: RUST_BUILD_SYS is intentionally NOT on BB_BASEHASH_IGNORE_VARS
+# (see meta/conf/bitbake.conf). rustc's crate SVH (Strict Version Hash)
+# is seeded by the stage0/stage1 bootstrap compiler whose fingerprint
+# depends on the BUILD host arch; that seed cascades through every
+# dependent crate's mangled symbols and rodata packing order. Excluding
+# RUST_BUILD_SYS from task hashes let a mixed-arch autobuilder pool
+# populate sstate on one worker arch and get a cache hit on a differently-
+# arched worker, producing byte-different (but semantically identical)
+# artifacts and failing reproducibility tests. See Yocto bug #15554.
+
 # wrappers to get around the fact that Rust needs a single
 # binary but Yocto's compiler and linker commands have
 # arguments. Technically the archiver is always one command but
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index bdf37d0da2..ee23459506 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -969,7 +969,7 @@ BB_HASHEXCLUDE_COMMON ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH BBSERVER DL_DI
     SSTATE_HASHEQUIV_OWNER CCACHE_TOP_DIR BB_HASHSERVE GIT_CEILING_DIRECTORIES \
     OMP_NUM_THREADS BB_CURRENTTASK"
 BB_BASEHASH_IGNORE_VARS ?= "${BB_HASHEXCLUDE_COMMON} PSEUDO_INCLUDE_PATHS BUILDHISTORY_DIR \
-    SSTATE_DIR SOURCE_DATE_EPOCH RUST_BUILD_SYS RUST_HOST_SYS RUST_TARGET_SYS"
+    SSTATE_DIR SOURCE_DATE_EPOCH RUST_HOST_SYS RUST_TARGET_SYS"
 BB_HASHCONFIG_IGNORE_VARS ?= "${BB_HASHEXCLUDE_COMMON} DATE TIME SSH_AGENT_PID \
     SSH_AUTH_SOCK PSEUDO_BUILD BB_ENV_PASSTHROUGH_ADDITIONS DISABLE_SANITY_CHECKS \
     PARALLEL_MAKE BB_NUMBER_THREADS BB_ORIGENV BB_INVALIDCONF BBINCLUDED \
-- 
2.43.0

Re: [OE-core] [PATCH 4/4] bitbake.conf, rust-common.bbclass: include RUST_BUILD_SYS in the task hash

[Mathieu Dubois-Briand]

On Wed Aug 5, 2026 at 12:04 AM CEST, Alejandro Hernandez Samaniego via lists.openembedded.org wrote:
> RUST_BUILD_SYS is currently listed in BB_BASEHASH_IGNORE_VARS, which
> tells bitbake that rust recipes should hash-match regardless of the
> build machine's triplet. In practice that is not true:
>
> rustc computes each crate's Strict Version Hash (SVH) using inputs
> that include the *stage0/stage1 bootstrap compiler* fingerprint, which
> in turn depends on the build host arch. That seed cascades through
> every dependent crate's mangled symbols and the packing order of
> rodata sections, so an sstate blob populated on one worker arch and
> reused on a differently-arched worker produces byte-different (but
> semantically identical) artifacts and fails the reproducibility
> selftest causing autobuilder intermittent issues when the sstate
> matches for the incorrect architecture.
>
> Remove RUST_BUILD_SYS from BB_BASEHASH_IGNORE_VARS so the task hash
> tracks the build triplet and mixed-arch autobuilder pools get an
> sstate miss instead of a silently-wrong hit. RUST_HOST_SYS and
> RUST_TARGET_SYS stay excluded because they're already covered by the
> target/host arch hash inputs.
>
> While this is not ideal, it should unblock the reproducible test case,
> another solution would be to patch rust sources manually and attempt
> to upstream that change.
>
> This also has the side-effect that multiple variants of the conflicting
> rust recipes sstate artifacts are created, but they'll be correctly used
> now in each architecture.
>
> Also add an explanatory comment next to the RUST_*_SYS[vardepvalue]
> declarations in rust-common.bbclass so future readers don't re-add
> the exclusion.
>
> Verified locally: Tier 1 sighash test toggling BUILD_ARCH now produces
> different task hashes for rust/libstd-rs/rpm-sequoia/python3-crypto-
> graphy/cargo/librsvg, where previously the hashes matched despite the
> build machine change.
>
> [YOCTO #15554]
>
> Assisted-by: AI - OpenAI
> Signed-off-by: Alejandro Hernandez <alhe@linux.microsoft.com>
> ---

Hi Alejandro,

It looks like this is breaking some selftests:

2026-08-05 10:11:05,494 - oe-selftest - INFO - sstatetests.SStateHashSameSigs.test_sstate_sdk_arch_same_hash (subunit.RemotedTestCase)
2026-08-05 10:11:05,494 - oe-selftest - INFO -  ... FAIL
...

2026-08-05 10:11:05,495 - oe-selftest - INFO - 6: 27/69 496/763 (108.24s) (2 failed) (sstatetests.SStateHashSameSigs.test_sstate_sdk_arch_same_hash)
2026-08-05 10:11:05,495 - 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.13/unittest/case.py", line 1238, in assertCountEqual
    self.fail(msg)
    ~~~~~~~~~^^^^^
  File "/usr/lib/python3.13/unittest/case.py", line 732, 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-3278758/tmp-sstatesamehash/stamps/x86_64-linux/gtk+3-native/3.24.52.do_create_spdx.sigdata.469683d7e676bd4feadb3e363efaa9a55c47eb06559fcda0d3f5cf26473919c5'
First has 1, Second has 0:  '/srv/pokybuild/yocto-worker/oe-selftest-debian/build/build-st-3278758/tmp-sstatesamehash/stamps/x86_64-linux/gtk+3-native/3.24.52.do_populate_sysroot.sigdata.c29ff418823da4b52189a4cf7395c310a3c14fed57eb24562cd0e387fe2235a3'
First has 1, Second has 0:  '/srv/pokybuild/yocto-worker/oe-selftest-debian/build/build-st-3278758/tmp-sstatesamehash/stamps/x86_64-linux/gtk+3-native/3.24.52.do_create_package_spdx.sigdata.ede62d86abb84a871e239607d0a7173c6a9c45027aafffc624b37e2e1bb5111f'
First has 1, Second has 0:  '/srv/pokybuild/yocto-worker/oe-selftest-debian/build/build-st-3278758/tmp-sstatesamehash/stamps/x86_64-linux/rust-native/1.96.1.do_create_spdx.sigdata.76ed6652ba8e8eba4e8750240fa7a048fcc90e94b45e753068a44560ef2e29f0'
First has 1, Second has 0:  '/srv/pokybuild/yocto-worker/oe-selftest-debian/build/build-st-3278758/tmp-sstatesamehash/stamps/x86_64-linux/rust-native/1.96.1.do_create_package_spdx.sigdata.4234a33aff5f4b52703a74c1caec1893206476f908c70b32c78e46dcc3e4fb38'
First has 1, Second has 0:  '/srv/pokybuild/yocto-worker/oe-selftest-debian/build/build-st-3278758/tmp-sstatesamehash/stamps/x86_64-linux/rust-native/1.96.1.do_compile.sigdata.67ed98cf74ac06f829d6432f4fd904779b2f6e540f588baeab3dcf0ac35a9c75'
First has 1, Second has 0:  '/srv/pokybuild/yocto-worker/oe-selftest-debian/build/build-st-3278758/tmp-sstatesamehash/stamps/x86_64-linux/rust-native/1.96.1.do_populate_sysroot.sigdata.3203f6ea1fd6bb92ed523ba0e1ef0464166f1e5392207ea002c35e0007d435f9'
First has 1, Second has 0:  '/srv/pokybuild/yocto-worker/oe-selftest-debian/build/build-st-3278758/tmp-sstatesamehash/stamps/x86_64-linux/rust-native/1.96.1.do_configure.sigdata.df7cc5717b4cbc2ccb19bdb823fb55193cc2f95049ac7e07d440bc2da5590c96'
...

And same for sstatetests.SStateHashSameSigs.test_sstate_32_64_same_hash:
2026-08-05 10:07:29,974 - oe-selftest - INFO - sstatetests.SStateHashSameSigs.test_sstate_32_64_same_hash (subunit.RemotedTestCase)
2026-08-05 10:07:29,975 - oe-selftest - INFO -  ... FAIL
...

https://autobuilder.yoctoproject.org/valkyrie/#/builders/35/builds/4472
https://autobuilder.yoctoproject.org/valkyrie/#/builders/48/builds/4290

Can you have a look at the issue?

Thanks,
Mathieu

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

Re: [OE-core] [PATCH 4/4] bitbake.conf, rust-common.bbclass: include RUST_BUILD_SYS in the task hash

[Alejandro Hernandez]

[-- Attachment #1: Type: text/plain, Size: 6851 bytes --]


On 8/5/2026 11:58 PM, Mathieu Dubois-Briand via lists.openembedded.org 
wrote:
> On Wed Aug 5, 2026 at 12:04 AM CEST, Alejandro Hernandez Samaniego via lists.openembedded.org wrote:
>> RUST_BUILD_SYS is currently listed in BB_BASEHASH_IGNORE_VARS, which
>> tells bitbake that rust recipes should hash-match regardless of the
>> build machine's triplet. In practice that is not true:
>>
>> rustc computes each crate's Strict Version Hash (SVH) using inputs
>> that include the *stage0/stage1 bootstrap compiler* fingerprint, which
>> in turn depends on the build host arch. That seed cascades through
>> every dependent crate's mangled symbols and the packing order of
>> rodata sections, so an sstate blob populated on one worker arch and
>> reused on a differently-arched worker produces byte-different (but
>> semantically identical) artifacts and fails the reproducibility
>> selftest causing autobuilder intermittent issues when the sstate
>> matches for the incorrect architecture.
>>
>> Remove RUST_BUILD_SYS from BB_BASEHASH_IGNORE_VARS so the task hash
>> tracks the build triplet and mixed-arch autobuilder pools get an
>> sstate miss instead of a silently-wrong hit. RUST_HOST_SYS and
>> RUST_TARGET_SYS stay excluded because they're already covered by the
>> target/host arch hash inputs.
>>
>> While this is not ideal, it should unblock the reproducible test case,
>> another solution would be to patch rust sources manually and attempt
>> to upstream that change.
>>
>> This also has the side-effect that multiple variants of the conflicting
>> rust recipes sstate artifacts are created, but they'll be correctly used
>> now in each architecture.
>>
>> Also add an explanatory comment next to the RUST_*_SYS[vardepvalue]
>> declarations in rust-common.bbclass so future readers don't re-add
>> the exclusion.
>>
>> Verified locally: Tier 1 sighash test toggling BUILD_ARCH now produces
>> different task hashes for rust/libstd-rs/rpm-sequoia/python3-crypto-
>> graphy/cargo/librsvg, where previously the hashes matched despite the
>> build machine change.
>>
>> [YOCTO #15554]
>>
>> Assisted-by: AI - OpenAI
>> Signed-off-by: Alejandro Hernandez<alhe@linux.microsoft.com>
>> ---
> Hi Alejandro,
>
> It looks like this is breaking some selftests:
>
> 2026-08-05 10:11:05,494 - oe-selftest - INFO - sstatetests.SStateHashSameSigs.test_sstate_sdk_arch_same_hash (subunit.RemotedTestCase)
> 2026-08-05 10:11:05,494 - oe-selftest - INFO -  ... FAIL
> ...
>
> 2026-08-05 10:11:05,495 - oe-selftest - INFO - 6: 27/69 496/763 (108.24s) (2 failed) (sstatetests.SStateHashSameSigs.test_sstate_sdk_arch_same_hash)
> 2026-08-05 10:11:05,495 - 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.13/unittest/case.py", line 1238, in assertCountEqual
>      self.fail(msg)
>      ~~~~~~~~~^^^^^
>    File "/usr/lib/python3.13/unittest/case.py", line 732, 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-3278758/tmp-sstatesamehash/stamps/x86_64-linux/gtk+3-native/3.24.52.do_create_spdx.sigdata.469683d7e676bd4feadb3e363efaa9a55c47eb06559fcda0d3f5cf26473919c5'
> First has 1, Second has 0:  '/srv/pokybuild/yocto-worker/oe-selftest-debian/build/build-st-3278758/tmp-sstatesamehash/stamps/x86_64-linux/gtk+3-native/3.24.52.do_populate_sysroot.sigdata.c29ff418823da4b52189a4cf7395c310a3c14fed57eb24562cd0e387fe2235a3'
> First has 1, Second has 0:  '/srv/pokybuild/yocto-worker/oe-selftest-debian/build/build-st-3278758/tmp-sstatesamehash/stamps/x86_64-linux/gtk+3-native/3.24.52.do_create_package_spdx.sigdata.ede62d86abb84a871e239607d0a7173c6a9c45027aafffc624b37e2e1bb5111f'
> First has 1, Second has 0:  '/srv/pokybuild/yocto-worker/oe-selftest-debian/build/build-st-3278758/tmp-sstatesamehash/stamps/x86_64-linux/rust-native/1.96.1.do_create_spdx.sigdata.76ed6652ba8e8eba4e8750240fa7a048fcc90e94b45e753068a44560ef2e29f0'
> First has 1, Second has 0:  '/srv/pokybuild/yocto-worker/oe-selftest-debian/build/build-st-3278758/tmp-sstatesamehash/stamps/x86_64-linux/rust-native/1.96.1.do_create_package_spdx.sigdata.4234a33aff5f4b52703a74c1caec1893206476f908c70b32c78e46dcc3e4fb38'
> First has 1, Second has 0:  '/srv/pokybuild/yocto-worker/oe-selftest-debian/build/build-st-3278758/tmp-sstatesamehash/stamps/x86_64-linux/rust-native/1.96.1.do_compile.sigdata.67ed98cf74ac06f829d6432f4fd904779b2f6e540f588baeab3dcf0ac35a9c75'
> First has 1, Second has 0:  '/srv/pokybuild/yocto-worker/oe-selftest-debian/build/build-st-3278758/tmp-sstatesamehash/stamps/x86_64-linux/rust-native/1.96.1.do_populate_sysroot.sigdata.3203f6ea1fd6bb92ed523ba0e1ef0464166f1e5392207ea002c35e0007d435f9'
> First has 1, Second has 0:  '/srv/pokybuild/yocto-worker/oe-selftest-debian/build/build-st-3278758/tmp-sstatesamehash/stamps/x86_64-linux/rust-native/1.96.1.do_configure.sigdata.df7cc5717b4cbc2ccb19bdb823fb55193cc2f95049ac7e07d440bc2da5590c96'
> ...
>
> And same for sstatetests.SStateHashSameSigs.test_sstate_32_64_same_hash:
> 2026-08-05 10:07:29,974 - oe-selftest - INFO - sstatetests.SStateHashSameSigs.test_sstate_32_64_same_hash (subunit.RemotedTestCase)
> 2026-08-05 10:07:29,975 - oe-selftest - INFO -  ... FAIL
> ...
>
> https://autobuilder.yoctoproject.org/valkyrie/#/builders/35/builds/4472
> https://autobuilder.yoctoproject.org/valkyrie/#/builders/48/builds/4290
>
> Can you have a look at the issue?
>
> Thanks,
> Mathieu

Thanks Mathieu, yes this actually make sense, this is why I wasn't too convinced since the beginning and wanted to send an RFC, I'll attempt to fix this in some other way.

Alejandro

>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#242899):https://lists.openembedded.org/g/openembedded-core/message/242899
> Mute This Topic:https://lists.openembedded.org/mt/120602088/4354175
> Group Owner:openembedded-core+owner@lists.openembedded.org
> Unsubscribe:https://lists.openembedded.org/g/openembedded-core/unsub [alhe@linux.microsoft.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

[-- Attachment #2: Type: text/html, Size: 8224 bytes --]

Re: [OE-core] [PATCH 4/4] bitbake.conf, rust-common.bbclass: include RUST_BUILD_SYS in the task hash

[Richard Purdie]

On Tue, 2026-08-04 at 22:04 +0000, Alejandro Hernandez Samaniego via lists.openembedded.org wrote:
> RUST_BUILD_SYS is currently listed in BB_BASEHASH_IGNORE_VARS, which
> tells bitbake that rust recipes should hash-match regardless of the
> build machine's triplet. In practice that is not true:
> 
> rustc computes each crate's Strict Version Hash (SVH) using inputs
> that include the *stage0/stage1 bootstrap compiler* fingerprint, which
> in turn depends on the build host arch. That seed cascades through
> every dependent crate's mangled symbols and the packing order of
> rodata sections, so an sstate blob populated on one worker arch and
> reused on a differently-arched worker produces byte-different (but
> semantically identical) artifacts and fails the reproducibility
> selftest causing autobuilder intermittent issues when the sstate
> matches for the incorrect architecture.
> 
> Remove RUST_BUILD_SYS from BB_BASEHASH_IGNORE_VARS so the task hash
> tracks the build triplet and mixed-arch autobuilder pools get an
> sstate miss instead of a silently-wrong hit. RUST_HOST_SYS and
> RUST_TARGET_SYS stay excluded because they're already covered by the
> target/host arch hash inputs.
> 
> While this is not ideal, it should unblock the reproducible test case,
> another solution would be to patch rust sources manually and attempt
> to upstream that change.
> 
> This also has the side-effect that multiple variants of the conflicting
> rust recipes sstate artifacts are created, but they'll be correctly used
> now in each architecture.
> 
> Also add an explanatory comment next to the RUST_*_SYS[vardepvalue]
> declarations in rust-common.bbclass so future readers don't re-add
> the exclusion.
> 
> Verified locally: Tier 1 sighash test toggling BUILD_ARCH now produces
> different task hashes for rust/libstd-rs/rpm-sequoia/python3-crypto-
> graphy/cargo/librsvg, where previously the hashes matched despite the
> build machine change.
> 
> [YOCTO #15554]
> 
> Assisted-by: AI - OpenAI
> Signed-off-by: Alejandro Hernandez <alhe@linux.microsoft.com>
> ---
>  meta/classes-recipe/rust-common.bbclass | 10 ++++++++++
>  meta/conf/bitbake.conf                  |  2 +-
>  2 files changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/classes-recipe/rust-common.bbclass b/meta/classes-recipe/rust-common.bbclass
> index 6bc42016d1..98b46c4e3c 100644
> --- a/meta/classes-recipe/rust-common.bbclass
> +++ b/meta/classes-recipe/rust-common.bbclass
> @@ -114,6 +114,16 @@ RUST_HOST_SYS[vardepvalue] = "${RUST_HOST_SYS}"
>  RUST_TARGET_SYS = "${@rust_base_triple(d, 'TARGET')}"
>  RUST_TARGET_SYS[vardepvalue] = "${RUST_TARGET_SYS}"
>  
> +# Note: RUST_BUILD_SYS is intentionally NOT on BB_BASEHASH_IGNORE_VARS
> +# (see meta/conf/bitbake.conf). rustc's crate SVH (Strict Version Hash)
> +# is seeded by the stage0/stage1 bootstrap compiler whose fingerprint
> +# depends on the BUILD host arch; that seed cascades through every
> +# dependent crate's mangled symbols and rodata packing order. Excluding
> +# RUST_BUILD_SYS from task hashes let a mixed-arch autobuilder pool
> +# populate sstate on one worker arch and get a cache hit on a differently-
> +# arched worker, producing byte-different (but semantically identical)
> +# artifacts and failing reproducibility tests. See Yocto bug #15554.
> +
>  # wrappers to get around the fact that Rust needs a single
>  # binary but Yocto's compiler and linker commands have
>  # arguments. Technically the archiver is always one command but
> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> index bdf37d0da2..ee23459506 100644
> --- a/meta/conf/bitbake.conf
> +++ b/meta/conf/bitbake.conf
> @@ -969,7 +969,7 @@ BB_HASHEXCLUDE_COMMON ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH BBSERVER DL_DI
>      SSTATE_HASHEQUIV_OWNER CCACHE_TOP_DIR BB_HASHSERVE GIT_CEILING_DIRECTORIES \
>      OMP_NUM_THREADS BB_CURRENTTASK"
>  BB_BASEHASH_IGNORE_VARS ?= "${BB_HASHEXCLUDE_COMMON} PSEUDO_INCLUDE_PATHS BUILDHISTORY_DIR \
> -    SSTATE_DIR SOURCE_DATE_EPOCH RUST_BUILD_SYS RUST_HOST_SYS RUST_TARGET_SYS"
> +    SSTATE_DIR SOURCE_DATE_EPOCH RUST_HOST_SYS RUST_TARGET_SYS"
>  BB_HASHCONFIG_IGNORE_VARS ?= "${BB_HASHEXCLUDE_COMMON} DATE TIME SSH_AGENT_PID \
>      SSH_AUTH_SOCK PSEUDO_BUILD BB_ENV_PASSTHROUGH_ADDITIONS DISABLE_SANITY_CHECKS \
>      PARALLEL_MAKE BB_NUMBER_THREADS BB_ORIGENV BB_INVALIDCONF BBINCLUDED \

Just to be clear, the sstatetests fail for this change for good reason,
it breaks the way "native" works in our system. We work on the
principle that "native" things work the same way regardless of
architecture and that the sstate hashes remain the same.

If you change this as above all of the rust targets will rebuild
depending on the build architecture, despite the fact they're meant to
be build architecture independent. It might manage to fool the test but
the output would still not be build architecture independent and hence
doesn't fix the real issue, just hides it from the tests.

Cheers,

Richard

Re: [OE-core] [PATCH 4/4] bitbake.conf, rust-common.bbclass: include RUST_BUILD_SYS in the task hash

[Alejandro Hernandez]

[-- Attachment #1: Type: text/plain, Size: 6081 bytes --]


On 8/6/2026 6:53 AM, Richard Purdie via lists.openembedded.org wrote:
> On Tue, 2026-08-04 at 22:04 +0000, Alejandro Hernandez Samaniego via lists.openembedded.org wrote:
>> RUST_BUILD_SYS is currently listed in BB_BASEHASH_IGNORE_VARS, which
>> tells bitbake that rust recipes should hash-match regardless of the
>> build machine's triplet. In practice that is not true:
>>
>> rustc computes each crate's Strict Version Hash (SVH) using inputs
>> that include the *stage0/stage1 bootstrap compiler* fingerprint, which
>> in turn depends on the build host arch. That seed cascades through
>> every dependent crate's mangled symbols and the packing order of
>> rodata sections, so an sstate blob populated on one worker arch and
>> reused on a differently-arched worker produces byte-different (but
>> semantically identical) artifacts and fails the reproducibility
>> selftest causing autobuilder intermittent issues when the sstate
>> matches for the incorrect architecture.
>>
>> Remove RUST_BUILD_SYS from BB_BASEHASH_IGNORE_VARS so the task hash
>> tracks the build triplet and mixed-arch autobuilder pools get an
>> sstate miss instead of a silently-wrong hit. RUST_HOST_SYS and
>> RUST_TARGET_SYS stay excluded because they're already covered by the
>> target/host arch hash inputs.
>>
>> While this is not ideal, it should unblock the reproducible test case,
>> another solution would be to patch rust sources manually and attempt
>> to upstream that change.
>>
>> This also has the side-effect that multiple variants of the conflicting
>> rust recipes sstate artifacts are created, but they'll be correctly used
>> now in each architecture.
>>
>> Also add an explanatory comment next to the RUST_*_SYS[vardepvalue]
>> declarations in rust-common.bbclass so future readers don't re-add
>> the exclusion.
>>
>> Verified locally: Tier 1 sighash test toggling BUILD_ARCH now produces
>> different task hashes for rust/libstd-rs/rpm-sequoia/python3-crypto-
>> graphy/cargo/librsvg, where previously the hashes matched despite the
>> build machine change.
>>
>> [YOCTO #15554]
>>
>> Assisted-by: AI - OpenAI
>> Signed-off-by: Alejandro Hernandez<alhe@linux.microsoft.com>
>> ---
>>   meta/classes-recipe/rust-common.bbclass | 10 ++++++++++
>>   meta/conf/bitbake.conf                  |  2 +-
>>   2 files changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/meta/classes-recipe/rust-common.bbclass b/meta/classes-recipe/rust-common.bbclass
>> index 6bc42016d1..98b46c4e3c 100644
>> --- a/meta/classes-recipe/rust-common.bbclass
>> +++ b/meta/classes-recipe/rust-common.bbclass
>> @@ -114,6 +114,16 @@ RUST_HOST_SYS[vardepvalue] = "${RUST_HOST_SYS}"
>>   RUST_TARGET_SYS = "${@rust_base_triple(d, 'TARGET')}"
>>   RUST_TARGET_SYS[vardepvalue] = "${RUST_TARGET_SYS}"
>>   
>> +# Note: RUST_BUILD_SYS is intentionally NOT on BB_BASEHASH_IGNORE_VARS
>> +# (see meta/conf/bitbake.conf). rustc's crate SVH (Strict Version Hash)
>> +# is seeded by the stage0/stage1 bootstrap compiler whose fingerprint
>> +# depends on the BUILD host arch; that seed cascades through every
>> +# dependent crate's mangled symbols and rodata packing order. Excluding
>> +# RUST_BUILD_SYS from task hashes let a mixed-arch autobuilder pool
>> +# populate sstate on one worker arch and get a cache hit on a differently-
>> +# arched worker, producing byte-different (but semantically identical)
>> +# artifacts and failing reproducibility tests. See Yocto bug #15554.
>> +
>>   # wrappers to get around the fact that Rust needs a single
>>   # binary but Yocto's compiler and linker commands have
>>   # arguments. Technically the archiver is always one command but
>> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
>> index bdf37d0da2..ee23459506 100644
>> --- a/meta/conf/bitbake.conf
>> +++ b/meta/conf/bitbake.conf
>> @@ -969,7 +969,7 @@ BB_HASHEXCLUDE_COMMON ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH BBSERVER DL_DI
>>       SSTATE_HASHEQUIV_OWNER CCACHE_TOP_DIR BB_HASHSERVE GIT_CEILING_DIRECTORIES \
>>       OMP_NUM_THREADS BB_CURRENTTASK"
>>   BB_BASEHASH_IGNORE_VARS ?= "${BB_HASHEXCLUDE_COMMON} PSEUDO_INCLUDE_PATHS BUILDHISTORY_DIR \
>> -    SSTATE_DIR SOURCE_DATE_EPOCH RUST_BUILD_SYS RUST_HOST_SYS RUST_TARGET_SYS"
>> +    SSTATE_DIR SOURCE_DATE_EPOCH RUST_HOST_SYS RUST_TARGET_SYS"
>>   BB_HASHCONFIG_IGNORE_VARS ?= "${BB_HASHEXCLUDE_COMMON} DATE TIME SSH_AGENT_PID \
>>       SSH_AUTH_SOCK PSEUDO_BUILD BB_ENV_PASSTHROUGH_ADDITIONS DISABLE_SANITY_CHECKS \
>>       PARALLEL_MAKE BB_NUMBER_THREADS BB_ORIGENV BB_INVALIDCONF BBINCLUDED \
> Just to be clear, the sstatetests fail for this change for good reason,
> it breaks the way "native" works in our system. We work on the
> principle that "native" things work the same way regardless of
> architecture and that the sstate hashes remain the same.
>
> If you change this as above all of the rust targets will rebuild
> depending on the build architecture, despite the fact they're meant to
> be build architecture independent. It might manage to fool the test but
> the output would still not be build architecture independent and hence
> doesn't fix the real issue, just hides it from the tests.
>
> Cheers,
>
> Richard

Yes, that makes sense, the good thing is I think the root cause is correct, but if we instead patch rusts sources
we'll end up with the same problem since the packages would also be arch independent, correct?

Is the correct thing here to add packages to an ignore/allow list?


Alejandro

>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#242942):https://lists.openembedded.org/g/openembedded-core/message/242942
> Mute This Topic:https://lists.openembedded.org/mt/120602088/4354175
> Group Owner:openembedded-core+owner@lists.openembedded.org
> Unsubscribe:https://lists.openembedded.org/g/openembedded-core/unsub [alhe@linux.microsoft.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

[-- Attachment #2: Type: text/html, Size: 7243 bytes --]

Re: [OE-core] [PATCH 4/4] bitbake.conf, rust-common.bbclass: include RUST_BUILD_SYS in the task hash

[Richard Purdie]

On Thu, 2026-08-06 at 09:50 -0600, Alejandro Hernandez wrote:
>  
> On 8/6/2026 6:53 AM, Richard Purdie via lists.openembedded.org wrote:
>  
> > On Tue, 2026-08-04 at 22:04 +0000, Alejandro Hernandez Samaniego via lists.openembedded.org wrote:
> > > RUST_BUILD_SYS is currently listed in BB_BASEHASH_IGNORE_VARS, which
> > > tells bitbake that rust recipes should hash-match regardless of the
> > > build machine's triplet. In practice that is not true:
> > > 
> > > rustc computes each crate's Strict Version Hash (SVH) using inputs
> > > that include the *stage0/stage1 bootstrap compiler* fingerprint, which
> > > in turn depends on the build host arch. That seed cascades through
> > > every dependent crate's mangled symbols and the packing order of
> > > rodata sections, so an sstate blob populated on one worker arch and
> > > reused on a differently-arched worker produces byte-different (but
> > > semantically identical) artifacts and fails the reproducibility
> > > selftest causing autobuilder intermittent issues when the sstate
> > > matches for the incorrect architecture.
> > > 
> > > Remove RUST_BUILD_SYS from BB_BASEHASH_IGNORE_VARS so the task hash
> > > tracks the build triplet and mixed-arch autobuilder pools get an
> > > sstate miss instead of a silently-wrong hit. RUST_HOST_SYS and
> > > RUST_TARGET_SYS stay excluded because they're already covered by the
> > > target/host arch hash inputs.
> > > 
> > > While this is not ideal, it should unblock the reproducible test case,
> > > another solution would be to patch rust sources manually and attempt
> > > to upstream that change.
> > > 
> > > This also has the side-effect that multiple variants of the conflicting
> > > rust recipes sstate artifacts are created, but they'll be correctly used
> > > now in each architecture.
> > > 
> > > Also add an explanatory comment next to the RUST_*_SYS[vardepvalue]
> > > declarations in rust-common.bbclass so future readers don't re-add
> > > the exclusion.
> > > 
> > > Verified locally: Tier 1 sighash test toggling BUILD_ARCH now produces
> > > different task hashes for rust/libstd-rs/rpm-sequoia/python3-crypto-
> > > graphy/cargo/librsvg, where previously the hashes matched despite the
> > > build machine change.
> > > 
> > > [YOCTO #15554]
> > > 
> > > Assisted-by: AI - OpenAI
> > > Signed-off-by: Alejandro Hernandez <alhe@linux.microsoft.com>
> > > ---
> > >  meta/classes-recipe/rust-common.bbclass | 10 ++++++++++
> > >  meta/conf/bitbake.conf                  |  2 +-
> > >  2 files changed, 11 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/meta/classes-recipe/rust-common.bbclass b/meta/classes-recipe/rust-common.bbclass
> > > index 6bc42016d1..98b46c4e3c 100644
> > > --- a/meta/classes-recipe/rust-common.bbclass
> > > +++ b/meta/classes-recipe/rust-common.bbclass
> > > @@ -114,6 +114,16 @@ RUST_HOST_SYS[vardepvalue] = "${RUST_HOST_SYS}"
> > >  RUST_TARGET_SYS = "${@rust_base_triple(d, 'TARGET')}"
> > >  RUST_TARGET_SYS[vardepvalue] = "${RUST_TARGET_SYS}"
> > >  
> > > +# Note: RUST_BUILD_SYS is intentionally NOT on BB_BASEHASH_IGNORE_VARS
> > > +# (see meta/conf/bitbake.conf). rustc's crate SVH (Strict Version Hash)
> > > +# is seeded by the stage0/stage1 bootstrap compiler whose fingerprint
> > > +# depends on the BUILD host arch; that seed cascades through every
> > > +# dependent crate's mangled symbols and rodata packing order. Excluding
> > > +# RUST_BUILD_SYS from task hashes let a mixed-arch autobuilder pool
> > > +# populate sstate on one worker arch and get a cache hit on a differently-
> > > +# arched worker, producing byte-different (but semantically identical)
> > > +# artifacts and failing reproducibility tests. See Yocto bug #15554.
> > > +
> > >  # wrappers to get around the fact that Rust needs a single
> > >  # binary but Yocto's compiler and linker commands have
> > >  # arguments. Technically the archiver is always one command but
> > > diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> > > index bdf37d0da2..ee23459506 100644
> > > --- a/meta/conf/bitbake.conf
> > > +++ b/meta/conf/bitbake.conf
> > > @@ -969,7 +969,7 @@ BB_HASHEXCLUDE_COMMON ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH BBSERVER DL_DI
> > >      SSTATE_HASHEQUIV_OWNER CCACHE_TOP_DIR BB_HASHSERVE GIT_CEILING_DIRECTORIES \
> > >      OMP_NUM_THREADS BB_CURRENTTASK"
> > >  BB_BASEHASH_IGNORE_VARS ?= "${BB_HASHEXCLUDE_COMMON} PSEUDO_INCLUDE_PATHS BUILDHISTORY_DIR \
> > > -    SSTATE_DIR SOURCE_DATE_EPOCH RUST_BUILD_SYS RUST_HOST_SYS RUST_TARGET_SYS"
> > > +    SSTATE_DIR SOURCE_DATE_EPOCH RUST_HOST_SYS RUST_TARGET_SYS"
> > >  BB_HASHCONFIG_IGNORE_VARS ?= "${BB_HASHEXCLUDE_COMMON} DATE TIME SSH_AGENT_PID \
> > >      SSH_AUTH_SOCK PSEUDO_BUILD BB_ENV_PASSTHROUGH_ADDITIONS DISABLE_SANITY_CHECKS \
> > >      PARALLEL_MAKE BB_NUMBER_THREADS BB_ORIGENV BB_INVALIDCONF BBINCLUDED \
> > >  
> > > 
> >  
> > 
> > Just to be clear, the sstatetests fail for this change for good reason,
> > it breaks the way "native" works in our system. We work on the
> > principle that "native" things work the same way regardless of
> > architecture and that the sstate hashes remain the same.
> > 
> > If you change this as above all of the rust targets will rebuild
> > depending on the build architecture, despite the fact they're meant to
> > be build architecture independent. It might manage to fool the test but
> > the output would still not be build architecture independent and hence
> > doesn't fix the real issue, just hides it from the tests.
> 
> Yes, that makes sense, the good thing is I think the root cause is correct, but if we instead patch rusts sources
> we'll end up with the same problem since the packages would also be arch independent, correct?
> 
> Is the correct thing here to add packages to an ignore/allow list?

We probably need to patch rust itself not to put the host information
into the SVH.

Cheers,

Richard

Re: [OE-core] [PATCH 4/4] bitbake.conf, rust-common.bbclass: include RUST_BUILD_SYS in the task hash

[Alejandro Hernandez]

[-- Attachment #1: Type: text/plain, Size: 4934 bytes --]

Apologies, I was planning on sending this particular one as RFC due to its intrusiveness and forgot.

Alejandro

On 8/4/2026 4:04 PM, Alejandro Hernandez Samaniego via 
lists.openembedded.org wrote:
> RUST_BUILD_SYS is currently listed in BB_BASEHASH_IGNORE_VARS, which
> tells bitbake that rust recipes should hash-match regardless of the
> build machine's triplet. In practice that is not true:
>
> rustc computes each crate's Strict Version Hash (SVH) using inputs
> that include the *stage0/stage1 bootstrap compiler* fingerprint, which
> in turn depends on the build host arch. That seed cascades through
> every dependent crate's mangled symbols and the packing order of
> rodata sections, so an sstate blob populated on one worker arch and
> reused on a differently-arched worker produces byte-different (but
> semantically identical) artifacts and fails the reproducibility
> selftest causing autobuilder intermittent issues when the sstate
> matches for the incorrect architecture.
>
> Remove RUST_BUILD_SYS from BB_BASEHASH_IGNORE_VARS so the task hash
> tracks the build triplet and mixed-arch autobuilder pools get an
> sstate miss instead of a silently-wrong hit. RUST_HOST_SYS and
> RUST_TARGET_SYS stay excluded because they're already covered by the
> target/host arch hash inputs.
>
> While this is not ideal, it should unblock the reproducible test case,
> another solution would be to patch rust sources manually and attempt
> to upstream that change.
>
> This also has the side-effect that multiple variants of the conflicting
> rust recipes sstate artifacts are created, but they'll be correctly used
> now in each architecture.
>
> Also add an explanatory comment next to the RUST_*_SYS[vardepvalue]
> declarations in rust-common.bbclass so future readers don't re-add
> the exclusion.
>
> Verified locally: Tier 1 sighash test toggling BUILD_ARCH now produces
> different task hashes for rust/libstd-rs/rpm-sequoia/python3-crypto-
> graphy/cargo/librsvg, where previously the hashes matched despite the
> build machine change.
>
> [YOCTO #15554]
>
> Assisted-by: AI - OpenAI
> Signed-off-by: Alejandro Hernandez<alhe@linux.microsoft.com>
> ---
>   meta/classes-recipe/rust-common.bbclass | 10 ++++++++++
>   meta/conf/bitbake.conf                  |  2 +-
>   2 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/meta/classes-recipe/rust-common.bbclass b/meta/classes-recipe/rust-common.bbclass
> index 6bc42016d1..98b46c4e3c 100644
> --- a/meta/classes-recipe/rust-common.bbclass
> +++ b/meta/classes-recipe/rust-common.bbclass
> @@ -114,6 +114,16 @@ RUST_HOST_SYS[vardepvalue] = "${RUST_HOST_SYS}"
>   RUST_TARGET_SYS = "${@rust_base_triple(d, 'TARGET')}"
>   RUST_TARGET_SYS[vardepvalue] = "${RUST_TARGET_SYS}"
>   
> +# Note: RUST_BUILD_SYS is intentionally NOT on BB_BASEHASH_IGNORE_VARS
> +# (see meta/conf/bitbake.conf). rustc's crate SVH (Strict Version Hash)
> +# is seeded by the stage0/stage1 bootstrap compiler whose fingerprint
> +# depends on the BUILD host arch; that seed cascades through every
> +# dependent crate's mangled symbols and rodata packing order. Excluding
> +# RUST_BUILD_SYS from task hashes let a mixed-arch autobuilder pool
> +# populate sstate on one worker arch and get a cache hit on a differently-
> +# arched worker, producing byte-different (but semantically identical)
> +# artifacts and failing reproducibility tests. See Yocto bug #15554.
> +
>   # wrappers to get around the fact that Rust needs a single
>   # binary but Yocto's compiler and linker commands have
>   # arguments. Technically the archiver is always one command but
> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> index bdf37d0da2..ee23459506 100644
> --- a/meta/conf/bitbake.conf
> +++ b/meta/conf/bitbake.conf
> @@ -969,7 +969,7 @@ BB_HASHEXCLUDE_COMMON ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH BBSERVER DL_DI
>       SSTATE_HASHEQUIV_OWNER CCACHE_TOP_DIR BB_HASHSERVE GIT_CEILING_DIRECTORIES \
>       OMP_NUM_THREADS BB_CURRENTTASK"
>   BB_BASEHASH_IGNORE_VARS ?= "${BB_HASHEXCLUDE_COMMON} PSEUDO_INCLUDE_PATHS BUILDHISTORY_DIR \
> -    SSTATE_DIR SOURCE_DATE_EPOCH RUST_BUILD_SYS RUST_HOST_SYS RUST_TARGET_SYS"
> +    SSTATE_DIR SOURCE_DATE_EPOCH RUST_HOST_SYS RUST_TARGET_SYS"
>   BB_HASHCONFIG_IGNORE_VARS ?= "${BB_HASHEXCLUDE_COMMON} DATE TIME SSH_AGENT_PID \
>       SSH_AUTH_SOCK PSEUDO_BUILD BB_ENV_PASSTHROUGH_ADDITIONS DISABLE_SANITY_CHECKS \
>       PARALLEL_MAKE BB_NUMBER_THREADS BB_ORIGENV BB_INVALIDCONF BBINCLUDED \
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#242808):https://lists.openembedded.org/g/openembedded-core/message/242808
> Mute This Topic:https://lists.openembedded.org/mt/120602088/4354175
> Group Owner:openembedded-core+owner@lists.openembedded.org
> Unsubscribe:https://lists.openembedded.org/g/openembedded-core/unsub [alhe@linux.microsoft.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

[-- Attachment #2: Type: text/html, Size: 5831 bytes --]