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

[Richard Purdie <richard.purdie@linuxfoundation.org>]

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