[PATCH] libkas: check the meta layer availability when looking for oe-init-build-env

[Jose Quaresma]

From: Jose Quaresma <jose.q...@oss.qualcomm.com>

We need to take into account whether the main layer is disabled when we search
for the oe-init-build-env script.
If for some reason the meta layer is disabled it is because the user did it
explicitly and it is not possible to use the repository since without this
layer we can only use bitbake.

An example where this is necessary is when we use the nodistro as the base
configuration and want to override it with another configuration to use the poky.
Or vice versa.

nodistro.yml
bitbake:
layers:
.: disabled
oe-core:
layers:
meta:

poky.yml
oe-core:
layers:
meta: disabled
poky:
layers:
meta:
meta-poky:

- To build the nodistro the user uses the nodistro.yml which also contains the
remaining defined configuration.
- To use the poky distro the user will use the nodistro.yml:poky.yml which explicitly
disables the layer meta from the oe-core repo in the poky.yml and adds the poky layers.

In this case, with the configuration nodistro.yml:poky.yml, we have two repositories
where the meta layer is present but in one of them it was explicitly turned off so
we must use the script from the repo that has the meta layer active, which in this case
is poky repo.

Signed-off-by: Jose Quaresma <jose.q...@oss.qualcomm.com>
---
kas/libkas.py | 5 +++++
1 file changed, 5 insertions(+)

diff --git a/kas/libkas.py b/kas/libkas.py
index 5327efb..ff5d33a 100644
--- a/kas/libkas.py
+++ b/kas/libkas.py
@@ -279,6 +279,11 @@ def get_build_environ(build_system):
for script in scripts]
for (repo, script) in permutations:
if os.path.exists(repo.path + '/' + script):
+ if 'meta' not in repo._layers and 'oe-init-build-env' in scripts:
+ logging.warning('The scripts "oe-init-build-env" found on '
+ 'repo "%s" but the "meta" layer is disabled', repo.name)
+ continue
+
if init_repo:
raise InitBuildEnvError(
'Multiple init scripts found '
--
2.51.0

[Jan Kiszka]

Too much hard-coding or layer and script names here. We need a generic
rule here, something like "if a repository is configured to not provide
any layers, we do not search for any script in it". If you write that
down, in the docs as well as in code, I think we can move forward.

> + logging.warning('The scripts "oe-init-build-env" found on '
> + 'repo "%s" but the "meta" layer is disabled', repo.name)

I don't see a reason for a warning if we clearly specify the behavior.
Maybe you can issue a debug() message at most.

> + continue
> +
> if init_repo:
> raise InitBuildEnvError(
> 'Multiple init scripts found '

Jan

--
Siemens AG, Foundational Technologies
Linux Expert Center

[Jose Quaresma]

This is only validated for the OE-core 'oe-init-build-env' script.

I don't know the isar repository directory structure

as well as the 'isar-init-build-env' script usage.

But looks like there is also a meta layer on the isar repository

so I can change it just to check for the meta layer.

Can anyone more experienced on isar confirm that it doesn't make

sense to search for script when the meta layer is also disabled there?

> +               logging.warning('The scripts "oe-init-build-env" found on '
> +               'repo "%s" but the "meta" layer is disabled', repo.name)

I don't see a reason for a warning if we clearly specify the behavior.
Maybe you can issue a debug() message at most.

Yeah, no reason to raise this as a warning. I will change it to debug.

Jose

 

> +               continue
> +
>              if init_repo:
>                  raise InitBuildEnvError(
>                      'Multiple init scripts found '

Jan

--
Siemens AG, Foundational Technologies
Linux Expert Center

--

Best regards,

José Quaresma

[Jan Kiszka]

On 23.09.25 19:41, Jose Quaresma wrote:
>
>
> Jan Kiszka <jan.k...@siemens.com <mailto:jan.k...@siemens.com>>

> escreveu (segunda, 22/09/2025 à(s) 08:10):
>
> On 17.09.25 12:39, Jose Quaresma wrote:
> > From: Jose Quaresma <jose.q...@oss.qualcomm.com

> <mailto:jose.q...@oss.qualcomm.com>>

> <mailto:jose.q...@oss.qualcomm.com>>

> > ---
> >  kas/libkas.py | 5 +++++
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/kas/libkas.py b/kas/libkas.py
> > index 5327efb..ff5d33a 100644
> > --- a/kas/libkas.py
> > +++ b/kas/libkas.py
> > @@ -279,6 +279,11 @@ def get_build_environ(build_system):
> >           for script in scripts]
> >      for (repo, script) in permutations:
> >          if os.path.exists(repo.path + '/' + script):
> > +            if 'meta' not in repo._layers and 'oe-init-build-env'
> in scripts:
>
> Too much hard-coding or layer and script names here. We need a generic
> rule here, something like "if a repository is configured to not provide
> any layers, we do not search for any script in it". If you write that
> down, in the docs as well as in code, I think we can move forward.
>
>
> This is only validated for the OE-core 'oe-init-build-env' script.
>
> I don't know the isar repository directory structure
> as well as the 'isar-init-build-env' script usage.
> But looks like there is also a meta layer on the isar repository
> so I can change it just to check for the meta layer.

There shall be no special magic in a layer called "meta".

> Can anyone more experienced on isar confirm that it doesn't make
> sense to search for script when the meta layer is also disabled there?

We do not have this scenario in isar in the field yet, at least to my
best knowledge. But given that the main isar repo is just like poky
right now, bundling bitbake with some core layers, it would
theoretically be possible to have similar situations like in yocto
ecosystem there one day. That's why I'd like to have a generic rule like
I described.

[Jose Quaresma]

This is exactly the issue I am trying to fix.

The problem is if we find the script in a repository and the meta layer of that repository is disabled,

we should not use the script and we must keep looking.

 

> Can anyone more experienced on isar confirm that it doesn't make
> sense to search for script when the meta layer is also disabled there?

We do not have this scenario in isar in the field yet, at least to my
best knowledge. But given that the main isar repo is just like poky
right now, bundling bitbake with some core layers, it would
theoretically be possible to have similar situations like in yocto
ecosystem there one day. That's why I'd like to have a generic rule like
I described.

I think it now works for OE and Isar using the same check.

Jose

 

Jan

--
Siemens AG, Foundational Technologies
Linux Expert Center

[Jan Kiszka]

On 24.09.25 17:16, Jose Quaresma wrote:
>
>
> Jan Kiszka <jan.k...@siemens.com <mailto:jan.k...@siemens.com>>
> escreveu (quarta, 24/09/2025 à(s) 07:41):
>
> On 23.09.25 19:41, Jose Quaresma wrote:
> >
> >
> > Jan Kiszka <jan.k...@siemens.com <mailto:jan.k...@siemens.com>

> <mailto:jan.k...@siemens.com <mailto:jan.k...@siemens.com>>>

> > escreveu (segunda, 22/09/2025 à(s) 08:10):
> >
> >     On 17.09.25 12:39, Jose Quaresma wrote:
> >     > From: Jose Quaresma <jose.q...@oss.qualcomm.com
> <mailto:jose.q...@oss.qualcomm.com>

> >     <mailto:jose.q...@oss.qualcomm.com

> >     <mailto:jose.q...@oss.qualcomm.com

Check my proposal again: if we find a script in a repo and ALL layers
are disabled there, we skip it. That avoids hard-coding of the layer
name "meta" here.

[Jan Kiszka]

...or are there examples where you want to include poky as repo for some
layers != meta while still using the init-script from a different repo?
If so, then let's make the script opt-out an explicitly controlled thing
via a new key.

[Jose Quaresma]

One example I have is the one described in the commit message.

This might be a corner case that no one should be using, but it's still a valid case.

The other layers inside poky can also be found on the meta-yocto repo

so if it is necessary to use any of these layers it is preferable to use the meta-yocto.

One of the reasons to override the nodistro.yml with poky.yml is to use a different

template in the default config, everything else is mostly the same between the two.

I will try to propose your suggestion and skip the search of the script only when all

the layers are disabled. For we need a note on the documentation about this feature.

In my opinion this way will be hard to use and understand this feature.

The scripts names are hardcoded so I don't understand what the problem in

having the main "meta" layer hardcoded too.

In the current form of the patch if we disable the layer "meta" we also skip the

script on this repo.