summaryrefslogtreecommitdiffstats
path: root/bitbake
Commit message (Collapse)AuthorAgeFilesLines
* The poky repository master branch is no longer being updated.Richard Purdie2025-11-07611-150731/+0
| | | | | | | | | | | | | | | | | | | | | 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 <richard.purdie@linuxfoundation.org>
* bitbake: Add bitbake-setup documentationAntonin Godard2025-11-072-0/+823
| | | | | | | | | | Add documentation for bitbake-setup. This is split in 6 sections, including a quick start guide, terminology and reference. (Bitbake rev: 3089497efc7a1f3f143e151b9d5d024809269b9e) Signed-off-by: Antonin Godard <antonin.godard@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: doc/conf.py: add wikipedia extlinkAntonin Godard2025-11-071-0/+1
| | | | | | | | | For use in the documentation. (Bitbake rev: ed90b2ef95564b79d28a20e0e217e13be110499b) Signed-off-by: Antonin Godard <antonin.godard@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake-setup: Rename bb-layers-relative to bb-layers-file-relativeRichard Purdie2025-11-072-12/+12
| | | | | | | | | | | | | | | 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 <alex@linutronix.de> but with different naming. (Bitbake rev: dcb17758b99767ab6da4172cf60eabc9269082dd) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake-setup: replace {THISDIR} token with a keyword: ↵Alexander Kanavin2025-11-062-22/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | bb-layers-relative {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 <alex@linutronix.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake-setup: capture revisions while checking out layersJohannes Schneider2025-11-062-3/+23
| | | | | | | | | | | | | | | | | | | | | | | | | 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 <johannes.schneider@leica-geosystems.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake-setup: tests: move duplicate code into 'check_setupdir_files'Johannes Schneider2025-11-061-12/+8
| | | | | | | | | | | | | | | | | | 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 <johannes.schneider@leica-geosystems.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake-setup: checkout_layers: construct 'src_uri' separatlyJohannes Schneider2025-11-061-3/+4
| | | | | | | | | | | | | | Construct the 'src_uri' separately, and then pass either variant into one call that creates the Fetch. Making use of format-strings to shorten/simplify the code. Also: using 'proto' instead of 'type' for a variable name, to avoid the protected keyword. (Bitbake rev: 4ad70e05ceca19c1e903dafc33386a82b1176bba) Signed-off-by: Johannes Schneider <johannes.schneider@leica-geosystems.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake-setup: rename 'write_config' into 'write_upstream_config'Johannes Schneider2025-11-061-4/+4
| | | | | | | | | | Rename the function to reflect which (of the possibly many) files in the build/config directory it writes to. (Bitbake rev: 7f9cd4c1e91d110085d74f9b9f12884f97f4e8dd) Signed-off-by: Johannes Schneider <johannes.schneider@leica-geosystems.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake-setup: fix key-error when changing a new 'section'Johannes Schneider2025-11-061-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | Setting a key=value in a new section would raise a key-error when using in-memory settings, e.g: ./bin/bitbake-setup --setting default top-dir-prefix /tmp/bitbake-setup --setting default top-dir-name gs settings foo bar baz Loading settings from /tmp/bitbake-setup/gs/settings.conf Traceback (most recent call last): File "/tmp/bitbake-setup/bitbake/./bin/bitbake-setup", line 853, in <module> main() File "/tmp/bitbake-setup/bitbake/./bin/bitbake-setup", line 838, in main all_settings = merge_settings(builtin_settings, global_settings, topdir_settings, args.setting) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/tmp/bitbake-setup/bitbake/./bin/bitbake-setup", line 733, in merge_settings all_settings[section][setting] = value ~~~~~~~~~~~~^^^^^^^^^ KeyError: 'foo' (Bitbake rev: 78ab0d15dff5ccf64b0bf681185370779e6cabaf) Signed-off-by: Johannes Schneider <johannes.schneider@leica-geosystems.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake-setup: rename function 'default_settings_path' to ↵Johannes Schneider2025-11-061-8/+8
| | | | | | | | | | | | | | | | | 'topdir_settings_path' Rename the function to align with the corresponding 'global_settings_path' function, and move it down just above the later. This is done to differentiate from the built-in default settings, and to align with the other places in the code that use 'topdir_settings' (or 'global_settings') (Bitbake rev: 3df994f773abbd1d0240e721f5fd29d4b021bfb5) Signed-off-by: Johannes Schneider <johannes.schneider@leica-geosystems.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: toaster: support bitbake-setupDavid Reyna2025-11-042-31/+89
| | | | | | | | | | | | | | | | | | | | | | | | 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 <David.Reyna@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake-setup: rename 'build' -> 'setup'Alexander Kanavin2025-11-042-77/+77
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <alex@linutronix.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake-user-manual/ref-variables: extend PERSISTENT_DIR docAntonin Godard2025-11-031-2/+7
| | | | | | | | | | | | | | | | Extend the current documentation of PERSISTENT_DIR: - Mention that it also contains the hash equivalence database when BB_HASHSERVE = auto. - Mention that it should not be shared between builds. [YOCTO #15727] (Bitbake rev: 682c2dccb67a57ecbf93aac8e9deea88bff10155) Signed-off-by: Antonin Godard <antonin.godard@bootlin.com> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: doc: enhance SRCREV_FORMAT descriptionPatrick Vogelaar2025-11-031-0/+6
| | | | | | | | | | | Adding documentation for having an empty first component for the SRCREV_FORMAT. (Bitbake rev: 37ef26cfd5441ce97ff7ec0d5026c92091224c07) Signed-off-by: Patrick Vogelaar <patrick.vogelaar.dev@mailbox.org> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: fetch2/git: when raising ParameterError for an invalid proto, ↵Chris Laplante2025-11-031-1/+1
| | | | | | | | | | include the proto in the message (Bitbake rev: 671314811ac1c023efacc6a2f148d8d84ba1adb2) Signed-off-by: Chris Laplante <chris.laplante@agilent.com> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: doc/bitbake-user-manual-ref-variables: improve INHERITAdam Blank2025-11-031-3/+11
| | | | | | | | | | | | | Current wording makes it difficult to understand what exactly is done with INHERIT-ed anonymous functions and when. (Bitbake rev: f06af69458083735e69f115edf73f783f18bc08c) Signed-off-by: Adam Blank <adam.blank.g@gmail.com> Reviewed-by: Antonin Godard <antonin.godard@bootlin.com> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: doc: bitbake-user-manual: style and completeness correctionsAdam Blank2025-11-032-35/+35
| | | | | | | | | | | | Fix encountered style issues in the fetching section. Mention that "subdir" and fetcher specific parameters can stack-up. (Bitbake rev: 5cb35734c7056aa183bc15d454e125b75267449b) Signed-off-by: Adam Blank <adam.blank.g@gmail.com> Reviewed-by: Antonin Godard <antonin.godard@bootlin.com> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: doc: bitbake-user-manual: AUTOREV and SRCREV_FORMAT roles in fetchingAdam Blank2025-11-032-5/+57
| | | | | | | | | | | | | | Describe the roles of AUTOREV and SRCREV_FORMAT in the fetching step. Add their missing descriptions to the variable reference section. Fixes [YOCTO #14498] (Bitbake rev: fbf0a8c5711f56bd64ae4c9d2c1d5ba884508c9f) Signed-off-by: Adam Blank <adam.blank.g@gmail.com> Reviewed-by: Antonin Godard <antonin.godard@bootlin.com> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake-setup: correctly define --global argument for settings ↵Alexander Kanavin2025-11-031-1/+1
| | | | | | | | | | | | | | | | management --global was defined twice (for settings command as a whole, and specifically for set/unset sub-commands), which caused 'settings --global set ...' to be allowed, and at the same time not have any effect. 'settings set --global' is the only valid form after this change. (Bitbake rev: 2f14cf68f6c653b6da90180a99a22c58855b0cef) Signed-off-by: Alexander Kanavin <alex@linutronix.de> Tested-by: Antonin Godard <antonin.godard@bootlin.com> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake-user-manual-metadata.rst: OE_BUILTIN_FRAGMENTS -> ↵Chen Qi2025-11-031-2/+2
| | | | | | | | | | | | | OE_FRAGMENTS_BUILTIN The actual variable name used in oe-core is OE_FRAGMENTS_BUILTIN, which is in a consistent format with other OE_FRAGMENTS_XXX vars. (Bitbake rev: 86c5f6aa59980d04264bc526976a49fdf749d1af) Signed-off-by: Chen Qi <Qi.Chen@windriver.com> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: contrib: vim: Update file detection regexJoshua Watt2025-11-031-4/+4
| | | | | | | | | | | | The regex used to detect bitbake files was improved in patch 9.1.1732. Update the plugin to match that logic and fix a bug where the wrong expression was used to set the file type (Bitbake rev: 7ce0c9b44968f80a6060f9f9ff2cc00823b772cc) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake/doc: Correct name of bitbake-dumpsigJörg Sommer2025-10-171-2/+2
| | | | | | | (Bitbake rev: 35a421cdcafb3595b9de5489ffdc567825400d26) Signed-off-by: Jörg Sommer <joerg.sommer@navimatix.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake-setup: commandline: use subsubparser for settings ↵Johannes Schneider2025-10-142-29/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | {list,set,unset} 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] <section> <setting> <value> usage: bitbake-setup settings unset [-h] [--global] <section> <setting> (Bitbake rev: 8b582ef8dd0cef0192d4c0104bcd9b5d642d132c) Signed-off-by: Johannes Schneider <johannes.schneider@leica-geosystems.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake-setup: add 'metavar' for self-descriptive parametersJohannes Schneider2025-10-141-2/+3
| | | | | | | | | | | | | | | | | | | | Add a metavar to the argparse options to have a self-descriptive help text. Otherwise argpase defaults to use the argument name in all-uppercase. Before: usage: bitbake-setup [-h] [-d] [-q] [--color COLOR] [--no-network] [--global-settings GLOBAL_SETTINGS] [--setting SETTING SETTING SETTING] {list,init,status,update,install-buildtools,settings} ... After: usage: bitbake-setup [-h] [-d] [-q] [--color COLOR] [--no-network] [--global-settings PATH] [--setting SECTION SETTING VALUE] {list,init,status,update,install-buildtools,settings} ... (Bitbake rev: 83cecc9356a0684f90249d527fe372298ae92719) Signed-off-by: Johannes Schneider <johannes.schneider@leica-geosystems.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake-setup: use args.cmdline_settings for --settingsJohannes Schneider2025-10-141-3/+4
| | | | | | | | | | To align the storage destination with the internally used variable name. This makes room for having another option use 'args.setting' (Bitbake rev: 14d8535309abc78ee30cfdb51bba2e00b474f443) Signed-off-by: Johannes Schneider <johannes.schneider@leica-geosystems.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake-setup: init: suggest removing a partially initialized top-dirJohannes Schneider2025-10-141-1/+1
| | | | | | | | | | | | | | In cases where the first call to 'init' failed or was aborted before creating the 'build/init-build-env' has been created, a user can get stuck: a second call to init aborts, suggesting 'status' or 'update' but these to refuse because the --build-dir is not valid. Guide the user by adding a suggestion to start over from scratch. (Bitbake rev: 11b2740c3e19e0c6680229c6bbce3691c73746a8) Signed-off-by: Johannes Schneider <johannes.schneider@leica-geosystems.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake-setup: correct 'setting' to 'settings' in a couple of help ↵Alexander Kanavin2025-10-141-2/+2
| | | | | | | | | texts (Bitbake rev: c5e04ce986b680f39f6c7851e4236c4afa4ac3f4) Signed-off-by: Alexander Kanavin <alex@linutronix.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake-setup: further rework the settings handlingAlexander Kanavin2025-10-142-105/+69
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <alex@linutronix.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake-setup: rework the settings handlingAlexander Kanavin2025-10-142-152/+147
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the outcome of various discussions, suggestions and pull requests on github. What has specifically changed? 1. The sources for the settings are no longer separated, but are stacked and given priorities, from highest to lowest: a. '--setting section key value' on the command line b. a settings file in the top directory c. a global settings file in ~/.config/bitbake-setup/ (or in a file pointed to by --global-settings) Any setting can be in any of these three locations (other than top dir name and prefix which do not make sense in the settings file in the top directory). 2. A global settings file must contain all of the needed settings, while a settings file in the top directory can be empty (and this is how they are written out if they do not exist). Specifically, both dl-dir and registry settings have been relocated to the global file, and dl-dir defaults to ~/.cache/bitbake-setup/downloads, rather than somewhere in top dir. 3. The file name for both global and top dir settings is now 'settings.conf'. 4. --top-dir-prefix and --top-dir-name options have been removed and superseded by a generic, universal --setting option. 5. 'install-settings' command has been removed, as it is no longer does anything useful, and is superseded by the 'setting' command (see below). 'install-global-settings' has been retained, to be able to have a set of global defaults that can be changed without initializing a build. 6. 'change-setting', 'change-global-setting' and 'install-settings' have all been replaced by a single 'setting' command that mimics 'git config' in its parameters: a. Changing a setting: bitbake-setup setting [--global] default dl-dir /path/to/downloads b. Removing a setting: bitbake-setup setting [--global] --unset default dl-dir (Bitbake rev: 713e7f213c6d4a620be9ce34d5f4396af48e1d69) Signed-off-by: Alexander Kanavin <alex@linutronix.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake-setup: tests: add environment-passthroughJohannes Schneider2025-10-141-0/+23
| | | | | | | | | | Add a test configuration to cover the 'bb-env-passthrough-additions' conf.json key, and add it to the test routine. (Bitbake rev: 24f12b68692f9ebb5d3813bc3b1771e43298f640) Signed-off-by: Johannes Schneider <johannes.schneider@leica-geosystems.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake-setup: tests: add a template-only test configurationJohannes Schneider2025-10-141-8/+27
| | | | | | | | | | | | | bitbake-setup conf.json can be purely template driven, to setup older yocto LTS (e.g. scarthgap) based layer-collections - where fragment support was not yet present in oe-core+bitbake. Add a configuration for that scenario and add it to the test routine. (Bitbake rev: 23e121befa0779fbb1f342984b583c04ccc637a0) Signed-off-by: Johannes Schneider <johannes.schneider@leica-geosystems.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake-setup: support adding environment-passthroughs to the ↵Johannes Schneider2025-10-141-1/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | init-build-env This patch adds support for extending the BB_ENV_PASSTHROUGH_ADDITIONS environment variable from within the `init-build-env` wrapper script - generated by either oe-core's oe-setup-build, or by `bitbake-setup` - based on per-configuration JSON settings. This enables CI workflows to inject environment-specific data - such as build number, host, build type, or credentials required to fetch from certain SRC_URIs - which cannot be captured via configuration fragments alone. These variables are now handled early in the setup process and exported directly into the build environment. Example: "bb-env-passthrough-additions": [ "ACME_DIR", "ARTIFACTORY_TOKEN", "ARTIFACTORY_USERNAME", "GITHUB_TOKEN", "GITHUB_PROTOCOL", "KEY" ] <snip> the resulting 'init-build-env' would then be: # environment passthrough added by bitbake-setup export BB_ENV_PASSTHROUGH_ADDITIONS=" \ $BB_ENV_PASSTHROUGH_ADDITIONS \ ACME_DIR \ ARTIFACTORY_TOKEN \ ARTIFACTORY_USERNAME \ GITHUB_TOKEN \ GITHUB_PROTOCOL \ KEY" # init-build-env wrapper created by bitbake-setup . /tmp/acme_master-acme-distro_acme-machine_bang/layers/openembedded-core/oe-init-build-env /tmp/bitbake-setup/gs/acme_master-acme-distro_acme-machine_bang/build (Bitbake rev: 782ab99e7a04fba43bdcf5763a6280785944ae3f) Signed-off-by: Johannes Schneider <johannes.schneider@leica-geosystems.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake-setup: add support for skipping a fragment selectionAlexander Kanavin2025-10-141-2/+8
| | | | | | | | | | | | | | | | | In autobuilder testing a use case arised where - the available choices in configuration file for choosing a machine are incomplete - putting every possible machine choice into that configuration is undesirable/not possible - autobuilder code can write a machine selection into the bitbake config after the fact. So this --skip-selection option is intended for advanced users that know what they're doing and is generally not recommended as it requires manually tweaking the bitbake config to make it usable. (Bitbake rev: 8cb2372bdad381179969d2ecbba7decaf03a7c5f) Signed-off-by: Alexander Kanavin <alex@linutronix.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: registry: make a separate configuration for poky with ↵Alexander Kanavin2025-10-141-3/+11
| | | | | | | | | | | | | | | | | sstate mirror Using sstate mirror places much higher requirements on both network robustness and network bandwidth than just fetching source code. When the network doesn't meet those, the user experience can be very frustrating as errors can be cryptic and intermittent, or bitbake would just seemingly do nothing for a long time. Let's make sstate an opt-in, and provide a caution for using it. When it does work, it works wonderfully and does accelerate builds significantly. (Bitbake rev: fe88a8e9cd5ccbc26508cf524a2f71a06d3df03a) Signed-off-by: Alexander Kanavin <alex@linutronix.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake-setup: clarify that default answer to prompts is noPaul Gortmaker2025-10-141-3/+3
| | | | | | | | | | | | | | | | It is common practice to put the default choice in upper case for yes/no interactive prompts, so that when people just hit enter, they know what they are getting. An example that linux users are probably familiar with is "sensors-detect" from the "lm-sensors" package. Unify all the prompts to be the same and indicate that the default answer from hitting enter is a no with an upper case N. No functional changes. (Bitbake rev: 7d6225722e21b116ae164fbaae2a918534a5107b) Signed-off-by: Paul Gortmaker <paulg@kernel.org> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake-setup: allow using {THISDIR}/my-layerYoann Congal2025-10-142-5/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This implement the ability to use "{THISDIR}/my-layer" in the "bb-layers" list. "{THISDIR}" is remplaced by the directory containing the configuration file. In small projects, we try to keep the setup a simple as possible: a single git repo containing both the build confguration (e.g. a bitbake-setup configuration file) and the meta layer with project recipes/machine/distro. This change allows this kind of setup: ├── meta-my-project/ # the project layer └── my-project.conf.json # the bb-setup configuration file by writing, in my-project.conf.json: "bitbake-setup": { "configurations": [{ "bb-layers": [ "{THISDIR}/meta-my-project" Note: in this case meta-my-project is not present as a "source", so, not handled by bb-setup update/status. It is expected of the user to handle this on their own (is our case, a simple git workflow). (Bitbake rev: b3153be29de8b8570b0c184369bd41f4c646cf92) Signed-off-by: Yoann Congal <yoann.congal@smile.fr> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: lib/bb/tests/setup.py: unset BBPATH to ensure isolation from the ↵Alexander Kanavin2025-10-141-0/+5
| | | | | | | | | | | | existing bitbake environment bitbake-setup deduces top directory from BBPATH, which, if set, interferes with the tests' own setup. (Bitbake rev: e974d42eb5229f755e14b46a00ad06b23b53e143) Signed-off-by: Alexander Kanavin <alex@linutronix.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: lib/bb/tests/setup.py: define test parameters in a single dictionaryAlexander Kanavin2025-10-141-3/+7
| | | | | | | | | This makes maintaining and extending them easier. (Bitbake rev: 16dc8e3dad7dde7e7651cce13549e61574cafba1) Signed-off-by: Alexander Kanavin <alex@linutronix.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake-setup: dash support for init-build-env scriptYoann Congal2025-10-141-7/+8
| | | | | | | | | | | | | | | | | | | | | | Being minimalist, dash does not support the (non-POSIX) feature of passing an argument while sourcing a script. Like in . <some path>/oe-init-build-env <build dir> With dash, one must use: set <build dir> # puts <build dir> in $1 cd <some path> . ./oe-init-build-env # can only be called from its directory in dash To do this: * Instead of a symlink to oe-init-build-env, keep a symlink to the directory containing it (called "oe-init-build-env-dir") * Generate a init-build-env script that dash can source using the above snippet. (Bitbake rev: 442b41c7949e1522212b66b16811f6b64b089b23) Signed-off-by: Yoann Congal <yoann.congal@smile.fr> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake-setup: suggest "." instead of "source"Yoann Congal2025-10-141-1/+1
| | | | | | | | | | | | "." is in POSIX standard[0], whereas "source" is only supported in more feature-full shells (bash, zsh, ...) [0]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#dot (Bitbake rev: 22c5fe7b2de74841e86d28a81143bd1a717518d9) Signed-off-by: Yoann Congal <yoann.congal@smile.fr> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake-setup: improve robustness of loading/writing settingsAlexander Kanavin2025-10-141-3/+3
| | | | | | | | | | | | | | | Particularly: - ensure global settings command line argument is always expanded to full path - ensure any errors that happen when loading settings are reported at that point, otherwise we get an empty dictionary and cryptic key errors later (Bitbake rev: 578afa2f05dfa6727952365918df703875070f64) Signed-off-by: Alexander Kanavin <alex@linutronix.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake-setup: add support for specifying branches in repo checkoutsAlexander Kanavin2025-10-144-7/+23
| | | | | | | | | | | | | | | | | | | | Previously bitbake-setup was checking out 'detached commits' using fetcher's nobranch feature, as that is the only option when only a revision is in the config. Branches are optional, but beneficial, as - checkout directory will be on a branch, making it easier for users to understand where they are if they need to make changes (also bitbake will print branch information instead of saying 'HEAD:sha'). - supply chain security! Enforcing a branch means any specified revision has to be on it, and no one can sneak in (accidentally or deliberately!) some dangling commit, or something from their private branch in the same repo. (Bitbake rev: 45ed9b9faebdaa8cb7cc8dd2a6d51ec8eea06e73) Signed-off-by: Alexander Kanavin <alex@linutronix.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake-setup: Improve the already initialized testRichard Purdie2025-10-141-2/+2
| | | | | | | | | If the directory already exists but hasn't been setup, the current test can fail so improve it. (Bitbake rev: dac27bd5acbde1807b9637f809fd0ee5bf424286) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake-setup: Switch to internal default registry filesRichard Purdie2025-10-141-1/+1
| | | | | | | | | Switch the url to be the default internal registry rather than a private repo which was intended for testing. (Bitbake rev: e031b75b5b92552d812d2305a35ce90eb6c68b78) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: Add default registry config for OpenEmbedded's nodistro and Yocto ↵Richard Purdie2025-10-142-0/+124
| | | | | | | | | | | | | | | Project's poky Rather than forcing every user to have to access a separate repository for data for some key defaults, add those for nodistro and poky. This gives us some commonly used setups and also something to test against too. We will need to come up with a criteria for adding these, most likely based on community usage/demand with the OE TSC governing that policy. (Bitbake rev: 562de93d5b0e7cf0a9a43714d0563e5bcf6e9931) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake-setup: Allow local registry pathsRichard Purdie2025-10-141-4/+9
| | | | | | | | | | It is useful for bitbake-setup to support local paths without access through the fetcher so that internal data to the bitbake repository can be used as a default. (Bitbake rev: ec82a6d402a0bec5704310c66c6f4206c75e4fc9) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: adjust the error message about missing websockets module to ↵Alexander Kanavin2025-10-141-1/+4
| | | | | | | | | mention bitbake-setup (Bitbake rev: 2d15e6fc93f6a73c9c84e399613f931f1c783922) Signed-off-by: Alexander Kanavin <alex@linutronix.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake-setup: add 'install-buildtools' commandAlexander Kanavin2025-10-142-0/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This basically calls install-buildtools from oe-core/poky, but it ensures via command line parameters that the installation location is stable and the downloads are preserved for reproducibility: $ bin/bitbake-setup install-buildtools Loading settings from /home/alex/bitbake-builds/bitbake-setup.conf ====== Buildtools archive is downloaded into /home/alex/bitbake-builds/yocto-master-testing/buildtools-downloads/20250319141333 and its content installed into /home/alex/bitbake-builds/yocto-master-testing/buildtools ... (output from install-buildtools script) ====== It also detects when buildtools are already installed, and will direct users what to do: ====== alex@Zen2:/srv/work/alex/bitbake$ bin/bitbake-setup install-buildtools Loading settings from /home/alex/bitbake-builds/bitbake-setup.conf Buildtools are already installed in /home/alex/bitbake-builds/yocto-master-testing/buildtools. If you wish to use them, you need to source the the environment setup script e.g. $ . /home/alex/bitbake-builds/yocto-master-testing/buildtools/environment-setup-x86_64-pokysdk-linux You can also re-run bitbake-setup install-buildtools with --force option to force a reinstallation ====== This commits includes fixes by Gyorgy Sarvari <skandigraun@gmail.com> https://github.com/kanavin/bitbake/pull/2 (Bitbake rev: 3fe3096847046110c72b23fce37fb4a459b1d748) Signed-off-by: Alexander Kanavin <alex@linutronix.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake-setup: add tests to bitbake-selftestAlexander Kanavin2025-10-142-0/+267
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Run like this: alex@Zen2:/srv/work/alex/bitbake$ bin/bitbake-selftest -v bb.tests.setup test_setup (bb.tests.setup.BitbakeSetupTest.test_setup) ... ok ---------------------------------------------------------------------- Ran 1 test in 9.223s OK The test does a basic run-through of init, then status/update on an unchanged configuration, then status/update on a configuration changed via new commits to the test layer, then status/update on configuration changed via the top level json config file. Note that nothing whatsoever is fetched from the network; the test relies entirely on synthetic data contained inside itself, including minimal stubs for oe-setup-build and bitbake-config-build. This data is used to create temporary git repositories then clone them via local filesystem URIs. Later on this can be supplemented by an oe-selftest that tests bitbake-setup against real config files in the official configuration repository and real layers, templates and fragments. (Bitbake rev: e3aa3eb46bd3196fa5415fa36e3737636fd6a1c0) Signed-off-by: Alexander Kanavin <alex@linutronix.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2026-01-09 09:08:23 +0000