Re: [bitbake-devel] [PATCH] toaster: Add recipe variables view

On Fri, 2026-08-14 at 10:31 -0400, Paolo Wattebled wrote:
> Thanks for the feedback.
> 
> The 598 figure is the number of recipes in that build, not the number of
> variables. Each recipe has its own build-specific snapshot, giving 19,756
> variable and flag entries in total—around 33 per recipe on average.

The cache you've added is per parsed recipe, not per recipe used in the
build. Was the patch AI assisted?

33 differences per recipe seems very low as well. 

bitbake -e bash | grep -v ^# > a
bitbake -e quilt | grep -v ^# > b
diff -u a b | grep ^-[A-Z] | grep -v : | wc

So I've filtered only variables not functions, nothing with an override
and I still get 132 differences.

> Each snapshot contains the final resolved values specific to that recipe,
> including changes from its .bb, matching .bbappend and included .inc files, as
> well as flags such as PACKAGECONFIG[...]. Values inherited unchanged from
> global configuration or classes are excluded, along with functions and inactive
> overrides.

I think you're missing a lot of values.

> Screenshots of the linux-imx variables, bluez5 PACKAGECONFIG values and flags,
> and variable counts in the recipes table are available here:
> 
> https://imgur.com/a/u20rf3O
> 
> Regarding history, the current implementation stores one resolved snapshot per
> build. If build 1 resolves A to 1 and build 2 resolves it to 2, both builds
> retain their respective values. It uses BitBake variable history for selection,
> but does not persist the complete assignment and operation history.

Ok, how does it use variable history for selection?

> To provide a little more context, this work supports vulnerability assessment
> in VulnScout through its new MCP functionality.

My concern is that it could well be based on flawed input data then :/.

> Build metadata and resolved variables provide useful context for producing an
> accurate assessment. For example, PACKAGECONFIG can help identify the features
> enabled in a recipe and the resulting attack surface.

Did I suggest otherwise?

> Our longer-term goal is to expose relevant recipe and global variables through
> Toaster and MCP, together with selected layer configuration such as kernel
> defconfigs. This should give an agent enough build-specific context to produce
> a more informed vulnerability assessment. For more information on VulnScout:
> 
> https://github.com/savoirfairelinux/vulnscout
> 
> Thank you also for the encouragement regarding the Toaster use case. I will
> prepare v2 as an incremental series, separating data collection, database
> storage and the user interface.

I'm not convinced you understand the implications of the code changes
you're proposing and that is a significant problem :/

Cheers,

Richard