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

[Paolo Wattebled <paolo.wattebled@savoirfairelinux.com>]

Hi,

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

The new `recipe_variables` field is collected in the recipe parse cache for
every parsed recipe. `buildDependTree()` copies cache fields into the
dependency graph only for recipes in the runqueue, and Toaster persists only
those entries. Thus the cache is per parsed recipe, while persisted Toaster
rows are runqueue-selected.

Yes, the patch was AI-assisted, as disclosed in the commit messages. I used
AI tools to assist with code generation, but I reviewed and tested the
changes, and I take responsibility for the design and the submitted commits.

> 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.

> I think you're missing a lot of values.

The current code records only variables whose BitBake `VariableHistory` has an
operation from the recipe, a matching `.bbappend`, or a recipe-owned `.inc`.
It excludes class- and configuration-only values, functions, inactive
overrides, and values that fail expansion.

Therefore the count reflects this source filter, not the complete effective
recipe datastore. I agree that describing the result as a resolved recipe
variable snapshot was misleading.

This raises a question about the intended scope of the feature. In your view,
which variables should Toaster expose here? Should it provide the complete
effective recipe datastore, including values inherited from configuration and
classes and values selected through overrides, or should it expose a clearly
defined subset? If you expect a subset, which inclusion or exclusion criteria
would you consider useful and correct?

> Ok, how does it use variable history for selection?

Variable history is used only as a provenance filter: it selects variables
touched by recipe metadata. The stored value is then obtained separately from
the parsed recipe datastore using `metadata.getVar(..., True)`. The history
itself is not stored. The compressed snapshot is carried through the dependency
graph for runqueue recipes and then stored in Toaster's `RecipeVariable` table.


> > 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 :/

I understand the concern about broader metadata such as kernel defconfigs.
That was only an example of a possible future extension to Toaster, not a
specific feature I intend to implement as part of this series.

Have a good day,

Paolo


----- Original Message -----
From: "Richard Purdie via lists.openembedded.org" <richard.purdie=linuxfoundation.org@lists.openembedded.org>
To: "Paolo Wattebled" <paolo.wattebled@savoirfairelinux.com>
Cc: "bitbake-devel" <bitbake-devel@lists.openembedded.org>
Sent: Friday, August 14, 2026 4:56:45 PM
Subject: 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


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19947): https://lists.openembedded.org/g/bitbake-devel/message/19947
Mute This Topic: https://lists.openembedded.org/mt/120719031/10577327
Group Owner: bitbake-devel+owner@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/bitbake-devel/unsub [paolo.wattebled@savoirfairelinux.com]
-=-=-=-=-=-=-=-=-=-=-=-