Re: [bitbake-devel] [2.18][PATCH] bitbake-worker: Evaluate exported_vars() before emptying the environment

On Mon, 2026-07-20 at 19:58 +0000, Alejandro Mery via lists.openembedded.or=
g wrote:
> exported_vars() returns a lazy generator. It was bound before
> empty_environment() cleared the process environment and only iterated
> afterwards, so any datastore expansion deferred until iteration ran with
> PATH already wiped.
>=20
> Recipes whose exported variables expand a command during that loop hit
> this. A gitver-style PV such as "${@get_git_pv(d, ...)}" runs git while
> PATH is empty, so the git wrapper on PATH is bypassed and the real git
> runs directly. Under pseudo this fakes uid 0 against a repository owned
> by the real user, and git aborts with "detected dubious ownership",
> failing do_package intermittently (only on reparse, when the value is
> re-expanded rather than served from cache).
>=20
> Materialise the generator into a list before emptying the environment so
> every expansion happens while PATH is still intact.
>=20
> Signed-off-by: Alejandro Mery <[email protected]>
> ---
> =C2=A0bin/bitbake-worker | 2 +-
> =C2=A01 file changed, 1 insertion(+), 1 deletion(-)
>=20
> diff --git a/bin/bitbake-worker b/bin/bitbake-worker
> index aa14ef191..0db1531e0 100755
> --- a/bin/bitbake-worker
> +++ b/bin/bitbake-worker
> @@ -290,7 +290,7 @@ def fork_off_task(cfg, data, databuilder, workerdata,=
 extraconfigdata, runtask):
> =C2=A0
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 # exported_vars() returns a generator which *canno=
t* be passed to os.environ.update()=20
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 # successfully. We also need to unset anything fro=
m the environment which shouldn't be there=20
> -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 exports =3D bb.data.exported_vars(the_data)
> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 exports =3D list(bb.data.exported_vars(the_data))
> =C2=A0
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 bb.utils.empty_environment()
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 for e, v in exports:

Thanks for this. Nice work in tracking it down!

I think in this case we need a couple of things, firstly will be a bit
more explination in the code with a comment about why we need a list
there.

The failure case is so unusual we should also probably write a test
case to make sure we test for and don't regress that issue which we'd
add to the existing tests in bitbake-selftest.

Help with that would be welcome or we'll get to it when we can...

Cheers,

Richard