From: Alejandro Hernandez <alhe@linux.microsoft.com>
To: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH 4/4] bitbake.conf, rust-common.bbclass: include RUST_BUILD_SYS in the task hash
Date: Tue, 4 Aug 2026 22:16:06 -0600 [thread overview]
Message-ID: <0948e3fd-adf5-4cda-bfc0-8b04e84d4d3f@linux.microsoft.com> (raw)
In-Reply-To: <18C8B9671621C916.3417489@lists.openembedded.org>
[-- 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 --]
prev parent reply other threads:[~2026-08-05 4:16 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-04 22:04 [PATCH 1/4] libtool: strip build system triplet from installed libtool script Alejandro Hernandez
2026-08-04 22:04 ` [PATCH 2/4] ptest.bbclass: strip build machine triplet from installed ptest Makefiles Alejandro Hernandez
2026-08-04 22:04 ` [PATCH 3/4] python_pep517.bbclass: always export _PYTHON_HOST_PLATFORM for wheel tag Alejandro Hernandez
2026-08-06 12:26 ` [OE-core] " Richard Purdie
2026-08-06 15:51 ` Alejandro Hernandez
2026-08-06 16:09 ` Richard Purdie
2026-08-06 17:28 ` Alejandro Hernandez
2026-08-04 22:04 ` [PATCH 4/4] bitbake.conf, rust-common.bbclass: include RUST_BUILD_SYS in the task hash Alejandro Hernandez
2026-08-06 5:58 ` [OE-core] " Mathieu Dubois-Briand
2026-08-06 15:53 ` Alejandro Hernandez
2026-08-06 12:53 ` Richard Purdie
2026-08-06 15:50 ` Alejandro Hernandez
2026-08-06 16:12 ` Richard Purdie
[not found] ` <18C8B9671621C916.3417489@lists.openembedded.org>
2026-08-05 4:16 ` Alejandro Hernandez [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0948e3fd-adf5-4cda-bfc0-8b04e84d4d3f@linux.microsoft.com \
--to=alhe@linux.microsoft.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox