Re: Bitbake 2.0 migration story

[Henning Schild <henning.schild@siemens.com>]

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
>