public inbox for openembedded-core@lists.openembedded.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Mehmet Fide <mehmet.fide@gmail.com>,
	 openembedded-core@lists.openembedded.org
Subject: Re: [PATCH] eSDK: fix locked signature handling for multiconfig builds
Date: Sun, 15 Mar 2026 07:48:50 +0000	[thread overview]
Message-ID: <328a331d31418fbdc351c4e919650ab060601480.camel@linuxfoundation.org> (raw)
In-Reply-To: <20260314224621.3507823-1-mehmet.fide@gmail.com>

On Sat, 2026-03-14 at 23:46 +0100, Mehmet Fide wrote:
> Building an extensible SDK with populate_sdk_ext fails for machines
> that use BBMULTICONFIG.  Three separate issues contribute to the
> failure:
> 
> 1. generate_locked_sigs() in copy_buildsystem.py builds the task
>    filter from BB_TASKDEPDATA which does not include multiconfig
>    tasks.  The resulting locked-sigs.inc lacks entries for mc builds,
>    so the eSDK internal build cannot find sstate for those tasks and
>    fails with setscene enforcement errors.
> 
>    Fix by also collecting mc task IDs from siggen.runtaskdeps.
> 
> 2. sstate_lockedsigs() in sstatesig.py stores a single hash per
>    pn:task pair.  When the same PN appears in multiple tune-specific
>    type sections with different hashes (as happens with multiconfig),
>    the last type overwrites earlier entries.  get_taskhash() then
>    returns the wrong locked hash for one of the multiconfigs.
> 
>    Fix by storing a list of entries per pn:task and selecting the
>    entry whose hash matches the computed hash in get_taskhash().
> 
> 3. translate_virtualfns() in oe-check-sstate crashes with a KeyError
>    when multiconfig tasks reference recipe files not present in the
>    recipe cache for that mc context.
> 
>    Fix by skipping unresolvable tasks gracefully.
> 
> Signed-off-by: Mehmet Fide <mehmet.fide@gmail.com>
> ---
>  meta/lib/oe/copy_buildsystem.py | 10 +++++++++-
>  meta/lib/oe/sstatesig.py        | 17 ++++++++++++++---
>  scripts/oe-check-sstate         |  4 ++++
>  3 files changed, 27 insertions(+), 4 deletions(-)
> 
> diff --git a/meta/lib/oe/copy_buildsystem.py b/meta/lib/oe/copy_buildsystem.py
> index 81abfbf9e2..c62fbd3fbb 100644
> --- a/meta/lib/oe/copy_buildsystem.py
> +++ b/meta/lib/oe/copy_buildsystem.py
> @@ -172,7 +172,15 @@ class BuildSystem(object):
>  def generate_locked_sigs(sigfile, d):
>      bb.utils.mkdirhier(os.path.dirname(sigfile))
>      depd = d.getVar('BB_TASKDEPDATA', False)
> -    tasks = ['%s:%s' % (v[2], v[1]) for v in depd.values()]
> +    tasks = set(['%s:%s' % (v[2], v[1]) for v in depd.values()])
> +    # BB_TASKDEPDATA does not include multiconfig tasks, so the eSDK
> +    # locked-sigs.inc would lack entries for mc builds causing setscene
> +    # enforcement failures.  Add any mc tasks tracked by siggen.
> +    for tid in bb.parse.siggen.runtaskdeps:
> +        if isinstance(tid, tuple):
> +            tid = tid[1]
> +        if tid.startswith('mc:'):
> +            tasks.add(tid)
>      bb.parse.siggen.dump_lockedsigs(sigfile, tasks)

BB_TASKDEPDATA only contains the tasks that the current task depends
upon. This is by design so that you can't "see" outside your own
current scope, which would be a dependency issue.

The way you've changed the code, it will add any task with a
multiconfig set, regardless of whether you depend on it or not.

It is also possible you're running this code within a multiconfig, in
which case you'd want to non-mc tasks, so it isn't correct from that
angle either.

The complexities of this are why we've so far not chosen to try and
handle it.

>  def prune_lockedsigs(excluded_tasks, excluded_targets, lockedsigs, onlynative, pruned_output):
> diff --git a/meta/lib/oe/sstatesig.py b/meta/lib/oe/sstatesig.py
> index d818fce8f1..9736e0b4e6 100644
> --- a/meta/lib/oe/sstatesig.py
> +++ b/meta/lib/oe/sstatesig.py
> @@ -90,7 +90,9 @@ def sstate_lockedsigs(d):
>              pn, task, h = ls.split(":", 2)
>              if pn not in sigs:
>                  sigs[pn] = {}
> -            sigs[pn][task] = [h, siggen_lockedsigs_var]
> +            if task not in sigs[pn]:
> +                sigs[pn][task] = []
> +            sigs[pn][task].append([h, siggen_lockedsigs_var])
>      return sigs
>  
>  class SignatureGeneratorOEBasicHashMixIn(object):
> @@ -182,8 +184,17 @@ class SignatureGeneratorOEBasicHashMixIn(object):
>  
>          if not unlocked and recipename in self.lockedsigs:
>              if task in self.lockedsigs[recipename]:
> -                h_locked = self.lockedsigs[recipename][task][0]
> -                var = self.lockedsigs[recipename][task][1]
> +                entries = self.lockedsigs[recipename][task]
> +                # When multiple locked hashes exist for the same pn:task
> +                # (e.g. from multiconfig builds), pick the one matching
> +                # the computed hash.  Fall back to the first entry.
> +                h_locked = entries[0][0]
> +                var = entries[0][1]
> +                for entry in entries:
> +                    if entry[0] == h:
> +                        h_locked = entry[0]
> +                        var = entry[1]
> +                        break
>                  self.lockedhashes[tid] = h_locked
>                  self._internal = True
>                  unihash = self.get_unihash(tid)

Multiconfigs are deliberately meant to behave like separate builds,
which don't need to be multiconfig aware. The way you're changing this,
changes that. Instead for example, the locked sigs inc file could
include the MC in the filename, then you'd just need each config to
write it out.

Cheers,

Richard

      reply	other threads:[~2026-03-15  7:48 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-14 22:46 [PATCH] eSDK: fix locked signature handling for multiconfig builds Mehmet Fide
2026-03-15  7:48 ` Richard Purdie [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=328a331d31418fbdc351c4e919650ab060601480.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=mehmet.fide@gmail.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