Re: [bitbake-devel] [PATCH] bitbake-setup: preserve build config when init script is missing

Hi Alex,

I want to clarify a few things directly.

First, regarding AI use: I have not found anything in the published
Yocto/OpenEmbedded contribution policy stating that review replies
must be written personally without AI assistance.

On the contrary, the reason the patch contains the `AI-Generated:`
trailer is precisely because I was trying to follow the project's
published policy correctly. I did not add that casually; I added it
because the contributor documentation explicitly requires AI-generated
code to be disclosed before the human `Signed-off-by`.

I understand that you personally expect review conversations to be
written without AI assistance. That expectation was not clear to me
before, but now it is. I accept that this is how you prefer to
interact with contributors, even though for me using AI assistance is
part of how I work and learn, and it saves time that I can spend on
the technical work itself and on the other projects I handle in
parallel.

About the prompt: I do not remember the exact wording I gave the AI. I
am a human being, not ChatGPT-9 :)

What I can tell you accurately is that the goal was to learn on the
job by auditing `bitbake-setup`, looking for problematic or fragile
failure paths, and trying to validate anything found with tests before
proposing a fix. This patch came out of that process. It did not come
from a real OE-Core incident or from a user bug report, and I already
made that clear in my previous reply.

There is one point, however, that I would still like to understand
technically, because I do not think it has been answered yet.

My understanding of the current code is:

- `checkout_layers()` selects the repository providing the setup
helpers based on the presence of `scripts/oe-setup-build`;
- it creates `oe-init-build-env-dir` pointing at that repository;
- I could not find an invariant or validation rule requiring that
repository to also contain `oe-init-build-env`;
- for the `bb-layers` path, `setup_bitbake_build()` explicitly handles
the case where `oe-init-build-env` is missing;
- but that check currently happens only after an existing `build/conf`
has already been moved aside and a new one has been generated.

So I would still like to understand which part of that reasoning is wrong.

Is your technical objection that the source transition exercised by
the test is outside the supported contract of `bitbake-setup`?

Or is the concern instead that the transition is technically possible
but too theoretical / unrealistic to justify an upstream patch?

I am asking because those are two different conclusions, and I would
genuinely like to learn which one applies here.

If there is an invariant or project assumption I missed, I am happy to
understand it and withdraw the patch on that basis.

If instead the path is valid but simply not considered worth handling
because there is no known real-world occurrence, that is also useful
feedback for me.

In any case, thank you for the time you have spent reviewing this. I
am here primarily to learn by doing useful work, and I have no
interest in defending a patch whose premise does not hold.

Regards,
Giancarlo

On Wed, 19 Aug 2026 12:19:10 +0200, Alexander Kanavin
<[email protected]> wrote:
> On Wed, 19 Aug 2026 at 12:09, Giancarlo Cicellyn Comneno
> <[email protected]> wrote:
>
> > So the motivation is defensive handling of a supported source-update
> > failure path, not a failure I've observed in OE-Core.
> >
> > If you consider the disappearance of `oe-init-build-env` outside the
> > supported contract despite the current handling for it, then I agree
> > the patch shouldn't be kept.
> >
> > Giancarlo
>
> Giancarlo,
>
> please do not use AI to write responses in a conversation. I want to
> talk to *you*, not to your AI agent. If you do this, then anything
> coming from you will be simply discarded on the grounds that you don't
> understand your own patches.
>
> Specifically here, I'd like to hear from *you* what instructions you
> gave to AI. Was it something along the lines of 'find problematic code
> paths in bitbake-setup and fix them?'. You need to be clear and
> transparent about it, if you want to maintain trust in your
> submissions.
>
> Thanks,
> Alex