linux/poky.git/bitbake/lib, branch master

The poky repository master branch is no longer being updated.

2025-11-07T13:31:53+00:00

You can either: a) switch to individual clones of bitbake, openembedded-core, meta-yocto and yocto-docs b) use the new bitbake-setup You can find information about either approach in our documentation: https://docs.yoctoproject.org/ Note that "poky" the distro setting is still available in meta-yocto as before and we continue to use and maintain that. Long live Poky! Some further information on the background of this change can be found in: https://lists.openembedded.org/g/openembedded-architecture/message/2179 Signed-off-by: Richard Purdie

bitbake: bitbake-setup: Rename bb-layers-relative to bb-layers-file-relative

2025-11-07T10:20:32+00:00

The difference between bb-layers and bb-layers-relative is unclear as both are relative paths. Rename one to "file-relative" which makes it clear it is relative to the current file, without becomming a long name. https://lists.openembedded.org/g/bitbake-devel/message/18296 Based on a patch from Alexander Kanavin but with different naming. (Bitbake rev: dcb17758b99767ab6da4172cf60eabc9269082dd) Signed-off-by: Richard Purdie

bitbake: bitbake-setup: replace {THISDIR} token with a keyword: bb-layers-relative

2025-11-06T18:04:13+00:00

{THISDIR} is a special value token that can be used in the list of enabled layers to specify the layer location relative to the confguration file: https://git.openembedded.org/bitbake/commit/?id=b3153be29de8b8570b0c184369bd41f4c646cf92 This replaces the token with an explicit separate keyword for such layers: so that special processing to determine the final value can be avoided, and the feature can be formalized in the json schema: instead of "bb-layers": [ "{THISDIR}/meta-my-project" ] this allows "bb-layers-relative": [ "meta-my-project" Going forward I think we should strive to avoid any further special value tokens. (Bitbake rev: 90da82bd2bfcfd5590c9ae06015737b616074b56) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie

bitbake: bitbake-setup: capture revisions while checking out layers

2025-11-06T18:03:46+00:00

When initializing a build setup from a conf.json that only sets 'rev' to a tag or branch, the actual revision would not be captured or logged. To capture the current layer state after an 'init' or 'update', the checkout_layers function is extended to store the revision the bb.fetch.Fetch pulled, and write that information into a sources-fixed-revisions.json file. This file can then be fed back into bitbake-setup init as: --sources-overrides This new 'sources-fixed-revisions.json' is written during 'update_build' and stored alongside the 'config-upstream.json' in the config dir. And put with the later under version control by calling 'commit_config" after 'update_build'. The use of 'deepcopy' is necessary to not modify the original input data - which python passes around as reference. (Bitbake rev: 95866ff03f78e987ae7e47daad053bc0f353eea4) Signed-off-by: Johannes Schneider Signed-off-by: Richard Purdie

bitbake: bitbake-setup: tests: move duplicate code into 'check_setupdir_files'

2025-11-06T18:03:46+00:00

All places that called into 'check_setupdir_files' did the same preparation step to load the upstream-config.json and then pass it into the function. Since the 'setuppath' is already passed into the function, and the name and relative location of the upstream-config.json is fixed, constructing the file path and loading the json could be done in the function. De-duplicate code by loading the json inside the function instead. (Bitbake rev: 16d77c83ae3ce92ddab84d714a93fd3bb7def5e2) Signed-off-by: Johannes Schneider Signed-off-by: Richard Purdie

bitbake: toaster: support bitbake-setup

2025-11-04T17:25:45+00:00

This adds support for the new bitbake-setup: * Maintain backwards compatibility for poky-classic releases * Assume bitbake-setup for all releases 'master' and forward * When no ".templateconf" assume Poky and not OE * Generate and use "init-build-env" script instead of 'oe-init-build-env' directly, but "cd" to the clone and not the local installation. * Include "bblayers.conf" because "cookerdata.py" now explicitly required it, and let it be over-ridden by the usual "toaster-bblayers.conf". * Force the value "TOPDIR" in "toaster.conf" to the local project's directory. Normally "cookerdata.py" sets TOPDIR from getcwd(), but somehow in bitbake-setup mode the CWD at this point has become ".../layers/openembedded-core", so "bitbake.conf and all other files cannot be found. This non-obvious problem was hard to discover. Until this is understood, the forced value will make things work. [YOCTO #16012] (Bitbake rev: 22b3fd418efc10da7e4a8c1725de285714d2396b) Signed-off-by: David Reyna Signed-off-by: Richard Purdie

bitbake: bitbake-setup: rename 'build' -> 'setup'

2025-11-04T13:16:04+00:00

After a terminology review by Antonin we brainstormed something less confusing than 'build' and 'build directory' for the place where bitbake-setup clones layers and creates a *bitbake* build directory in. People are bound to get these two confused and mix them up, and 'setup' is much more distinct and aligns nicely with 'bitbake-setup'. It's also not claimed by anything else in OE/Yocto. So before: top-dir -> build-dir (can be several) -> bitbake build dir, layer dir, config dir Now: top-dir -> setup-dir (can be several) -> bitbake build dir, layer dir, config dir This also updates the respective command line options, I understand it's a breaking change, but as before the tweaks are simple and we need to get the terminology right for the users, and now is the time to do it. (Bitbake rev: eeb81a35bf0304451f7612950d5156ea7ff18bad) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie

bitbake: fetch2/git: when raising ParameterError for an invalid proto, include the proto in the message

2025-11-03T17:43:31+00:00

(Bitbake rev: 671314811ac1c023efacc6a2f148d8d84ba1adb2) Signed-off-by: Chris Laplante Signed-off-by: Mathieu Dubois-Briand Signed-off-by: Richard Purdie

bitbake: bitbake-setup: commandline: use subsubparser for settings {list,set,unset}

2025-10-14T10:24:57+00:00

Previously the sub-command 'settings' would take any number of arguments and then silently do nothing if the number wasn't three. The help text was also not clear about this, marking the positionals separately as optional: usage: bitbake-setup settings [-h] [--global] [--unset UNSET UNSET] [-l] [section] [key] [value] The '--unset SECTION SETTING' also did not integrate too well, as it had its own positional arguments for section+setting. For a bit more consistency and a explorable help, a sub-subparser is added, that provides the commands: bitbake-setup settings list bitbake-setup settings set foo bar baz bitbake-setup settings unset foo bar with a '--global' that is added from a stand-alone parent parser, so that it shows up in all sub-command help texts. The new help text now reads: usage: bitbake-setup settings [-h] [--global] {list,set,unset} ... and the respective sub commands: usage: bitbake-setup settings list [-h] [--global] usage: bitbake-setup settings set [-h] [--global]

usage: bitbake-setup settings unset [-h] [--global]

(Bitbake rev: 8b582ef8dd0cef0192d4c0104bcd9b5d642d132c) Signed-off-by: Johannes Schneider Signed-off-by: Richard Purdie

bitbake: bitbake-setup: further rework the settings handling

2025-10-14T10:24:57+00:00

After some further feedback, additional changes are made: 1. 'setting' command is renamed to 'settings' to better reflect that it is an interface to various ways of managing settings. 2. This command now has a -l/--list option to list all settings with their values (same as 'git config -l'). 3. A new level of settings (built-in defaults) is added, and used as a last resort after command line options, top dir settings file and global settings file. 4. This means bitbake-setup does not have to write and use a global settings file, and it no longer does so when initializing a build, avoiding default 'pollution' of ~/.config/bitbake-setup/ which can be problematic or unwelcome. A global settings file is still created if a setting is explicitly requested to be placed into it. 5. 'install-global-settins' is removed as the use case for it (tweak default settings before using them to initialize a build) can be achieved by setting the settings individually. 5. Similarly, a top dir settings file is no longer created by default and only appears if a setting needs to be written into it. 6. Default dl-dir is again created inside a top directory and not in ~/.cache/ to make default builds fully contained in the top directory (which was also asked about). (Bitbake rev: 664f8ec48d42d2ddc5f234c4f7d590fa597f489a) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie