Bitbake 2.0 migration story

Bitbake 2.0 migration story

[Henning Schild]

Migrating a rather weird layer and what can go wrong.

Some of this might be duplication of what can be found in other places.
I just want to share it for now, and maybe some points can be taken
into docs.

But hey the move is a one-time thing ... and we can forget about all
that hopefully soon.

- i first went to the repo of my layer and did
 /path/to/new/isar/scripts/contrib/convert-overrides.py

that found a lot and helped a lot, but also had some fun ideas ... like
replacing _ with : in LICENSE.md

You could run it only on some folders to avoid that, but note that it
also often does the right things on kas files, which is cool.

It was wrong on dpkg-prebuilt packages where it replaced _amd64 with
:amd64 in SRC_URIs ... so watch out if you have the name of a .deb
somewhere in your code!

Good tool, but make sure to review its changes well.

If you use your own OVERRIDES they will not be found. Make sure to
search your layer for "OVERRIDES" ... any append here will have to be
found and moved from _ to : manually.

The variable BB_HASHCONFIG_WHITELIST has been renamed to
BB_HASHCONFIG_IGNORE_VARS, but bitbake has a good warning on this.

Tasks using "sudo" need do_<task>[network] = "${TASK_USE_SUDO}"

Search your layer codebase for "sudo"

When cloning any git repo with lfs inside ... the unpack task will need
network ... which it does not have by default. Might be a bitbake
upstream bug.
put
  do_unpack[network] += "${TASK_USE_NETWORK}"
into that recipe

Hope that helps anyone to jump this hurdle.

Henning

Re: Bitbake 2.0 migration story

[Henning Schild]

Am Thu, 9 Feb 2023 18:19:33 +0100
schrieb Henning Schild <henning.schild@siemens.com>:

> Migrating a rather weird layer and what can go wrong.
> 
> Some of this might be duplication of what can be found in other
> places. I just want to share it for now, and maybe some points can be
> taken into docs.
> 
> But hey the move is a one-time thing ... and we can forget about all
> that hopefully soon.

And very first you remove all build artifacts and sstate caches on the
machine you do this on, and on the CI runners that will build.

In the process when in doubt ... keep cleaning.

Henning

> - i first went to the repo of my layer and did
>  /path/to/new/isar/scripts/contrib/convert-overrides.py
> 
> that found a lot and helped a lot, but also had some fun ideas ...
> like replacing _ with : in LICENSE.md
> 
> You could run it only on some folders to avoid that, but note that it
> also often does the right things on kas files, which is cool.
> 
> It was wrong on dpkg-prebuilt packages where it replaced _amd64 with
> :amd64 in SRC_URIs ... so watch out if you have the name of a .deb
> somewhere in your code!
> 
> Good tool, but make sure to review its changes well.
> 
> If you use your own OVERRIDES they will not be found. Make sure to
> search your layer for "OVERRIDES" ... any append here will have to be
> found and moved from _ to : manually.
> 
> The variable BB_HASHCONFIG_WHITELIST has been renamed to
> BB_HASHCONFIG_IGNORE_VARS, but bitbake has a good warning on this.
> 
> Tasks using "sudo" need do_<task>[network] = "${TASK_USE_SUDO}"
> 
> Search your layer codebase for "sudo"
> 
> When cloning any git repo with lfs inside ... the unpack task will
> need network ... which it does not have by default. Might be a bitbake
> upstream bug.
> put
>   do_unpack[network] += "${TASK_USE_NETWORK}"
> into that recipe
> 
> Hope that helps anyone to jump this hurdle.
> 
> Henning
>