summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* scripts/lib/devtool/ide_sdk: Update for bitbake-setupRichard Purdie2025-10-041-1/+1
| | | | | | (From OE-Core rev: a496a94d3e1b51f0df899f16c4b8fc3c7502ef05) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* oeqa/selftest/yoctotestresultquerytest: Fix revisions to match OE-CoreRichard Purdie2025-10-041-2/+2
| | | | | | | | | The test was written assuming poky was being used. Update the revisions to match OE-Core instead. (From OE-Core rev: b361bfc6607d13993421c1c95942c70215159d37) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* oeqa/selftest/bblock/fitimage: Fix changing MACHINE during the testRichard Purdie2025-10-042-15/+15
| | | | | | | | | | | | With config fragments, changing MACHINE in the test like this no longer works. Use the forcevarable override to allow it to work. This also needs a tweak to bitbake to work correctly, sent seperately. Whilst ugly, this avoids the need to start changing config fragments. (From OE-Core rev: ed24b94e9a5dd396bcfe3b416309dda9e1e5a05b) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* oeqa/selftest/buildhistory: Fix test if USER_CLASSES is unsetRichard Purdie2025-10-041-1/+1
| | | | | | | | If USER_CLASSES is unset, the test was failing. Fix that. (From OE-Core rev: 42fa323a63fd85fe8cf8b9ab9f4045a21a472197) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* lib/bbconfigbuild/configfragments: disable the previous builtin fragment ↵Alexander Kanavin2025-10-042-7/+15
| | | | | | | | | | | | | | | | | | | when enabling a new one There was a flaw in the logic that allowed multiple builtin fragments with the same prefix to be enabled at the same time. The correct behaviour is that only one of them should be enabled, and when enabling it all previously enabled fragments should be removed. The issues that this caused are further explained in https://bugzilla.yoctoproject.org/show_bug.cgi?id=15987 [YOCTO #15987] (From OE-Core rev: 4cc78af26d8c3154d4f2b3b37d8e4dc65485eb66) Signed-off-by: Alexander Kanavin <alex@linutronix.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* package_manager/oe-pkgdata-util: fix complementary package installationChen Qi2025-10-045-35/+111
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We currently have a problem regarding complementary package installation, that is, if 'oe-pkgdata-util glob' maps out packages that are not in the oe-rootfs-repo, we will get error like below: No match for argument: lib32-glibc-locale-en-gb Error: Unable to find a match: lib32-glibc-locale-en-gb Here are the steps to reproduce the issue: 1. Add the following lines to local.conf: require conf/multilib.conf MULTILIBS ?= "multilib:lib32" DEFAULTTUNE:virtclass-multilib-lib32 ?= "core2-32" IMAGE_INSTALL:append = " lib32-sysstat" 2. bitbake lib32-glibc-locale && bitbake core-image-full-cmdline This problem appears because: 1) At do_rootfs time, we first contruct a repo with a filtering mechanism to ensure we don't pull in unneeded packages.[1] 2) oe-pkgdata-util uses the pkgdata without filtering. In order to avoid any hardcoding that might grow in the future[2], we need to give 'oe-pkgdata-util glob' some filtering ability. So this patch does the following things: 1) Add a new option, '-a/--allpkgs', to 'oe-pkgdata-util glob'. This gives it a filtering mechanism. As it's an option, people who use 'oe-pkgdata-util glob' command could use it as before. 2) Add to package_manager 'list_all' function implementations which list all available functions in our filtered repo. [1] https://git.openembedded.org/openembedded-core/commit/?id=85e72e129362db896b0d368077033e4a2e373cf9 [2] https://lists.openembedded.org/g/openembedded-core/message/221449 (From OE-Core rev: 16c52f992cf35769eecb3e3863e1ad14d4cb9848) 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>
* nativesdk-sdk-provides-dummy: allow pkgconfig to be installed into SDKsRoss Burton2025-10-041-3/+1
| | | | | | | | | | | | | | | | | | | | This recipe is a dummy provider of pkgconfig, but we want our SDKs to ship a pkgconfig binary if requested as otherwise that's a host tool that would be required to use the SDK. On Linux that's easily solved, but meta-mingw/meta-darwin SDKs can't really assume that pkgconfig will be present on the host. This behaviour dates back to 2014 when construction of SDKs with RPM packages was added[1] and notably the same behaviour didn't exist for ipkg-based SDKs. [1] oe-core 417b27ce5c1 ("lib/oe/sdk.py: support RpmRootfs") (From OE-Core rev: 6c84de9a47b6b86d406cf1cfb324828699062028) Signed-off-by: Ross Burton <ross.burton@arm.com> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* os-release: do not add empty parentheses to VERSIONDaniel Wagenknecht2025-10-041-1/+1
| | | | | | | | | | | | | | | | | | | | | Setting DISTRO_CODENAME to an empty string previously led to a VERSION field in /etc/os-release containing empty parantheses, e.g. DISTRO_VERSION = "5.0.12" DISTRO_CODENAME = "" ==> VERSION = "5.0.12 ()" This is probably not what a user expects, especially since it is quite common to set variables to empty strings to disable something in OE based builds, but using `unset VARNAME` seems pretty uncommon. Instead of adding the parentheses with the DISTRO_CODENAME if the variable is in the datastore add them only if the variable is not empty. (From OE-Core rev: e31eadaccbee4e5314e99093f2f6546555588796) Signed-off-by: Daniel Wagenknecht <dwagenknecht@emlix.com> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* scripts/runqemu: raise an error when bitbake was not foundRichard Grünert2025-10-041-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Running 'scrupts/runqemu' without bitbake in PATH causes the following error: ``` Traceback (most recent call last): File "/home/rg/temp_stuff/oe_2/./scripts/runqemu", line 1807, in main config.check_args() ~~~~~~~~~~~~~~~~~^^ File "/home/rg/temp_stuff/oe_2/./scripts/runqemu", line 624, in check_args s = re.search('^DEPLOY_DIR_IMAGE="(.*)"', self.bitbake_e, re.M) File "/usr/lib/python3.13/re/__init__.py", line 177, in search return _compile(pattern, flags).search(string) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^ TypeError: expected string or bytes-like object, got 'NoneType' ``` This patch adds a more helpful error message to inform the user that bitbake was not found, e.g. because oe-init-build-env was not sourced. This is an example of the new error message after the patch: ``` runqemu - ERROR - In order for this script to dynamically infer paths kernels or filesystem images, you either need bitbake in your PATH or to source oe-init-build-env before running this script. Dynamic path inference can be avoided by passing a *.qemuboot.conf to runqemu, i.e. `runqemu /path/to/my-image-name.qemuboot.conf` Bitbake is needed to run 'bitbake -e', but it is not found in PATH. Please source the bitbake build environment. ``` CC: Richard Purdie <richard.purdie@linuxfoundation.org> CC: Alexander Kanavin <alex.kanavin@gmail.com> (From OE-Core rev: 04d91eb144283d736bc398716e12f89926ada042) Signed-off-by: Richard Grünert <r.gruenert@pironex.com> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* syslinux: clean old object and dependency files before do_installHaixiao Yan2025-10-041-5/+0
| | | | | | | | | | | | | | | | | | | Remove all previous .o and .d files from OBJ directories before running do_install. This prevents stale build artifacts from interfering with the installation of new binaries and modules, especially after GCC upgrades that can invalidate existing dependency files, such as: make[4]: *** No rule to make target '/build/tmp-glibc/work/corei7-64-wrs-linux/syslinux/6.04-pre2-r1/recipe-sysroot-native/ usr/lib/x86_64-wrs-linux/gcc/x86_64-wrs-linux/12.4.0/include/stdarg.h', needed by 'zlib/adler32.o'. Stop. (From OE-Core rev: f52d55517eafe752e6f65b6f50acc81ab5afe3fc) Signed-off-by: Haixiao Yan <haixiao.yan.cn@windriver.com> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* linux-firmware: skip ldflags sanity checkRoss Burton2025-10-041-1/+4
| | | | | | | | | | | | | | | | | | Some of the firmware blobs, for example qcom/apq8016/modem.mbn, are actually ELF files. We don't want to hold these to our exacting standard for link flags because we're not building them and they don't run on the target directly. Note that as this check parses the output of ${OBJDUMP} -p it behaves differently with binutils vs llvm. It looks like binutils bails early as it doesn't know what the target architecture is, whereas LLVM is more comprehensive in its support. (From OE-Core rev: 80f32d66159bda0b01be6d47835168fcfacdac86) Signed-off-by: Ross Burton <ross.burton@arm.com> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* oeqa/selftest: Fix single threaded race issueRichard Purdie2025-10-041-0/+4
| | | | | | (From OE-Core rev: 22a2bb82c452bda9847295b5437aab1d639360ec) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* lib/configfragments: Operate on local.conf, not auto.confRichard Purdie2025-10-041-1/+1
| | | | | | (From OE-Core rev: 653646c8582bf4b2a91c1346982b8fbb39983fa2) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: ast: Fix fragment behaviour with overridesRichard Purdie2025-10-041-1/+2
| | | | | | | | | | | | | | | | | | | | | Imagine a machine fragment machine/A and a configuration which sets: MACHINE = "B" MACHINE:forcevariable = "C" As I understand it, the fragment behaviour was intended to replace the MACHINE = "B", so the override would still be active. The current code replaces all variable overrides. parsing=True, switches to the other behaviour, which I believe was the design intent and the behaviour users would expect. This is useful to allow test configurations to override a MACHINE setting without change the fragments which would complicate the test code. (Bitbake rev: 6b4882a55567d440713ee34d81810167cd958d56) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Make the "Initialising tasks" progress bar finish properlyPeter Kjellerstedt2025-10-041-1/+4
| | | | | | | | | | The "Initialising tasks" progress bar needs to be finished before update_scenequeue_data() creates another progress bar. (Bitbake rev: 620d53d7b61fbe98547047b07cb69e98afeb3fc5) Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake-setup: add support for skipping a fragment selectionAlexander Kanavin2025-10-041-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: fa81154cd8a204b394afa698daa0162e6337e7fa) 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-041-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: 9ac11955b8ee5a0cc964ef62d881ec6564b24a48) 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-041-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: c7b1a34a25a386426218d63d2aeba0e7c6ecf5b0) 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-042-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: 61fbdeb358979bb13c9e50d807f43e554497dc9c) 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-041-0/+5
| | | | | | | | | | | | existing bitbake environment bitbake-setup deduces top directory from BBPATH, which, if set, interferes with the tests' own setup. (Bitbake rev: ca21545bb847138d75d985d6d7eb0dc9b14550be) 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-041-3/+7
| | | | | | | | | This makes maintaining and extending them easier. (Bitbake rev: d4379bb791b8961538a4d445d5f956fafffbb0e5) 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-041-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: d77386e6ab155081ff3bef2aab413ff8061e83a5) 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-041-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: 3c5f04343b30efcf53d13f13203c5b0f3a518b99) 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-041-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: b3f3ea52e90fb2036074cc88fd00496eb995346d) 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-044-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: 14dd5f53913419a6c26c0b809a592bd19ae8495a) 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-041-2/+2
| | | | | | | | | If the directory already exists but hasn't been setup, the current test can fail so improve it. (Bitbake rev: f8cc590403212886cc5ea19fe1e78dcd3438b612) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake-setup: Switch to internal default registry filesRichard Purdie2025-10-041-1/+1
| | | | | | | | | Switch the url to be the default internal registry rather than a private repo which was intended for testing. (Bitbake rev: dd1841a7c3edc2749924370c307ff40ec65f0fe1) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: Add default registry config for OpenEmbedded's nodistro and Yocto ↵Richard Purdie2025-10-042-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: ce6561608904e971a5cf9214a68391ea7fccc6b3) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake-setup: Allow local registry pathsRichard Purdie2025-10-041-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: 5b8cd9d2156ef6bdd4c6e61130fadc0ff85f7f1f) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: adjust the error message about missing websockets module to ↵Alexander Kanavin2025-10-041-1/+4
| | | | | | | | | mention bitbake-setup (Bitbake rev: d857ed2044c8153c69bd3e275cfc8a9b6a8cdc5e) 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-042-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: 9fb564b720ff5d29a245ec900c8996da7f5f24a6) 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-042-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: 59ec7e2ac56e364bae39ccb5e884c447a5379531) Signed-off-by: Alexander Kanavin <alex@linutronix.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake-setup: add the initial implementationAlexander Kanavin2025-10-041-0/+809
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Preamble ======== The latest iteration of this patchset is available at https://github.com/kanavin/bitbake I recommend taking the patches from there to ensure that you are not trying out outdated code. For the rationale and design guidelines please see this message: https://lists.openembedded.org/g/openembedded-architecture/message/1913 Left out for now but will be done later: - official configuration repository - documentation Amble *scratch* HOWTO ===================== 1. If you don't know where to start, run 'bitbake-setup init'. Bitbake-setup will ask a few questions about available configuration choices and set up a build. Note: 'init' sub-command can also take a path or a URL with a configuration file directly. You can see how those files look like here: https://github.com/kanavin/bitbake-setup-configurations 2. You can then source the bitbake environment and run bitbake to perform builds as usual: $ . /home/alex/bitbake-builds/yocto-master-options-poky-distro_poky-machine_qemux86-64/build/init-build-env Also, subsequent status/update commands will not require a separate --build-dir argument telling bitbake-setup where the build is. 3. To check if the build configuration needs to be updated, run: === $ bin/bitbake-setup status ... Configuration in /home/alex/bitbake-builds/poky-alex/ has not changed. === If the configuration has changed, you will see the difference as a diff. ... - "rev": "akanavin/sstate-for-all" + "rev": "akanavin/bitbake-setup-testing" ... If the configuration has not changed, but layer revisions referred to it have (for example if the configuration specifies a tip of a branch), you will see that too: === ... Layer repository git://git.yoctoproject.org/poky-contrib checked out into /home/alex/builds/poky-alex/layers/poky updated revision akanavin/sstate-for-all from 6b842ba55f996b27c900e3de78ceac8cb3b1c492 to aeb73e29379fe6007a8adc8d94c1ac18a93e68de === 4. If the configuration has changed, you can bring it in sync with: $ bin/bitbake-setup update Note that it will also rename/preserve the existing build/conf directory, and print changes in bitbake configuration (diff of content of build/conf/) if that has changed. I can't at the moment think of anything more clever that is also not much more brittle or complex to implement, but open to suggestions. Terminology =========== - 'top directory' means the place under which bitbake-setup reads and writes everything. bitbake-setup makes a promise to not touch anything outside of that, unless otherwise directed to by entries in settings (currently there is one such setting for fetcher downloads for layers and config registries). Top directory can be selected by an environment variable, a command line option, or otherwise assumed to be ~/bitbake-builds/. If BBPATH is in environment (e.g. we are in a bitbake environment), then the top directory is deduced from that and doesn't need to be specified by hand. - 'settings' means bitbake-setup operational parameters that are global to all builds under a top directory. E.g. the location of configuration registry, or where the bitbake fetcher should place the downloads (DL_DIR setting). Settings are stored in a .conf file in ini format just under the top directory. - 'build' means a tree structure set up by 'bitbake-setup init', consisting of, at least, a layers checkout, and a bitbake build. It maps 1:1 to the json data it was constructed from, which is called 'build configuration'. Build configurations are constructed from generic configurations that may involve making one or more choices about available options in them. Generic configurations are files, URLs or are obtained from git repositories called 'config registries', in which case they can be listed with 'bitbake-setup list'. There can be multiple 'builds' under a top directory. Here are two example generic configurations that showcase this: https://github.com/kanavin/bitbake-setup-configurations/blob/main/yocto-master-options.conf.json https://github.com/kanavin/bitbake-setup-configurations/blob/main/yocto-master-nested-configs.conf.json - 'bitbake-setup status' will tell if a build is in sync with the generic configuration it was made from. 'bitbake-setup update' will bring a build in sync with a configuration if needed. - 'bitbake build' means a particular sub-tree inside a build that bitbake itself operates on, e.g. what is set in BBPATH/BUILDDIR by oe-init-build-env. conf/* in that tree is 'bitbake configuration'. Bitbake configurations are constructed from templates and fragments, with existing mechanisms provided by oe-core. The configuration file format is specified such that other mechanisms to set up a bitbake build can be added; there was a mention of ability to specify local.conf content and a set of layers directly in a configuration. I think that scales poorly compared to templates and fragments, but I made sure alternative ways to configure a bitbake build are possible to add in the future :) - 'source override' is a json file that can be used to modify revisions and origins of layers that need to be checkout into a build (e.g. when master branches need to be changed to master-next for purposes of testing). Such a file is specified with a command-line option to 'init' and an example can be seen here: https://github.com/kanavin/bitbake-setup-configurations/blob/main/yocto-master-next.override.json This commit includes fixes by Ryan Eatmon <reatmon@ti.com> https://github.com/kanavin/bitbake/pull/1 Gyorgy Sarvari <skandigraun@gmail.com> https://github.com/kanavin/bitbake/pull/2 Johannes Schneider <johannes.schneider@leica-geosystems.com> https://github.com/kanavin/bitbake/pull/3 https://github.com/kanavin/bitbake/pull/5 (Bitbake rev: bf3542076cdd751da9de8745aa3f351f5c6b0c5f) Signed-off-by: Alexander Kanavin <alex@linutronix.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: parse: Make include_all raise a parse error for absolute pathsPeter Kjellerstedt2025-10-042-0/+4
| | | | | | | | | It makes no sense to use an absolute path with include_all. (Bitbake rev: a39d1d5df740824d40c4d8e7f4199ccc518592e0) Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: parse: Make include_all support empty variable expansionsPeter Kjellerstedt2025-10-043-5/+9
| | | | | | | | | | | | | include and require support empty variable expansions, typically used with conditional expansions. However, include_all does not, and instead reports an error for the first path in BBPATH. Rewrite include_all so that its behavior matches include and require. (Bitbake rev: 010928ceac48b20e6ab530f8e256b72201b778ec) Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* tools/build-docs-container: update with newly supported distrosAntonin Godard2025-10-031-8/+14
| | | | | | | | | | | Update the build-docs-container file with newly supported distributions. These were all able to install packages and build the docs (including the pdf) properly. (From yocto-docs rev: 09c7800333b17b21e50d2a089a3ae1b123697243) Signed-off-by: Antonin Godard <antonin.godard@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* set_versions.py: fix subprocess.run call for older distrosAntonin Godard2025-10-031-1/+1
| | | | | | | | | | | Like in 28850c974a38 ("set_versions.py: use backward-compatible python argument in run"), replace the capture_output options by Python <3.7 compatible ones. (From yocto-docs rev: 6e1f4c18a13f369423599529a6960da5e3947d01) Signed-off-by: Antonin Godard <antonin.godard@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* docs: add util-linux-script package for Fedora 42+Adrian Freihofer2025-10-031-1/+1
| | | | | | | | | | | | | | | | | | | | | Fedora 42 split the script utility from util-linux into a separate util-linux-script package. This change adds conditional installation of util-linux-script for Fedora 42 and later versions. https://src.fedoraproject.org/rpms/util-linux/c/5a2471d6e5b0055cb607b30dc2e9613b312ffb74?branch=rawhide The package is added conditionally using rpm macro evaluation to maintain compatibility with older Fedora versions where script was included in the base util-linux package. Note that different distributions handle this differently - for example, Debian provides the script utility in a separate bsdutils package rather than in util-linux. (From yocto-docs rev: 22e28e817d2c9b49d9fedbb93b08874cec1fa3d3) Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com> Signed-off-by: Antonin Godard <antonin.godard@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* ref-manual/system-requirements.rst: update supported distributionsAntonin Godard2025-10-031-2/+3
| | | | | | | | | After 837a650aac17 ("poky: Update SANITY_TESTED_DISTROS") in meta-yocto. (From yocto-docs rev: 4e7ce89ff91f5fa7ade1feb7be96f898b56068ed) Signed-off-by: Antonin Godard <antonin.godard@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* ref-manual/variables.rst: fix the description of STAGING_DIRAdam Blank2025-10-031-1/+1
| | | | | | | | | | | There is no single "recipe-sysroots" directory, but rather many "recipe-sysroot*" directories. (From yocto-docs rev: f2d6e228409cb1dd1dbf339c405699ac6d3900be) Signed-off-by: Adam Blank <adam.blank.g@gmail.com> Signed-off-by: Antonin Godard <antonin.godard@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Add documentation on fragmentsAntonin Godard2025-10-036-0/+537
| | | | | | | | | | | | | | | - terms.rst: Provide the definitions of a Configuration Fragment and a Built-in Fragment. - ref-manual: Add a quick reference guide on bitbake-config-build, and list the available fragments in OE-Core. Document the underlying variables related to fragments in the glossary. - dev-manual: give instructions on how to create new custom fragments. (From yocto-docs rev: 0820b71c830cab4151b0219b6d4013c41f461c6e) Signed-off-by: Antonin Godard <antonin.godard@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* ref-manual/structure: document the auto.conf fileAntonin Godard2025-10-031-0/+9
| | | | | | | | | | Add documentation for auto.conf, which is used by external tools for automatically setting variables. (From yocto-docs rev: 134e54a75e0144c4629f702c6f43e92ed1f12dce) Signed-off-by: Antonin Godard <antonin.godard@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* dev-manual/building.rst: add note about externalsrc variables absolute pathsTalel BELHAJ SALEM2025-10-031-0/+5
| | | | | | | | (From yocto-docs rev: 33166d70b6ad093bd95ffccafc0b07820682f656) Signed-off-by: Talel BELHAJ SALEM <bhstalel@gmail.com> Signed-off-by: Antonin Godard <antonin.godard@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* tools: build-docs-container: remove comment for unsupported distrosQuentin Schulz2025-10-031-3/+0
| | | | | | | | | | | Ubuntu 18.04 and 20.04 are not supported distros, so let's remove the comment listing the reason we don't support them. (From yocto-docs rev: 9ff31ed417bc7cd80f8bde39372091e40e36b678) Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Signed-off-by: Antonin Godard <antonin.godard@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* ref-manual/variables.rst: fix the description of KBUILD_DEFCONFIGAdam Blank2025-10-031-2/+1
| | | | | | | | | | Remove some leftover confusing mention of KMACHINE. (From yocto-docs rev: 582ee9e0b4930aea03255542b3d3913df19af8b0) Signed-off-by: Adam Blank <adam.blank.g@gmail.com> Signed-off-by: Antonin Godard <antonin.godard@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel-dev/common.rst: fix the in-tree defconfig descriptionAdam Blank2025-10-031-7/+3
| | | | | | | | | | | | | The description of the relation between KBUILD_DEFCONFIG and SRC_URI is reversed. In fact it is the SRC_URI provided defconfig which will be dropped by the kernel-yocto class if both are provided. (From yocto-docs rev: a808420655a0976ba08f013f468cf80f379b1d89) Signed-off-by: Adam Blank <adam.blank.g@gmail.com> Signed-off-by: Antonin Godard <antonin.godard@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* populate_sdk_ext: do not require CONF_VERSION (e.g. local.conf version) to ↵Alexander Kanavin2025-10-021-1/+7
| | | | | | | | | | | | | | | | | | be set The version checks for local.conf/site.conf/bblayers.conf are all optional, and aren't enforced (by insane class) if the versions aren't set. As bitbake-setup writes out a blank local.conf, it doesn't put a version in it either. Also, esdk bundle has a fixed set of layers and is not at risk of needing to update its own local.conf. The same condition is already in place for esdk's bblayers.conf for similar reasons. (From OE-Core rev: d83ff28157aaa9322f98b8da5dd50b562085085a) Signed-off-by: Alexander Kanavin <alex@linutronix.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* ghostscript: upgrade 10.05.1 -> 10.06.0Vijay Anusuri2025-10-023-70/+66
| | | | | | | | | | | | | | | | | | | | Dropped 0001-Bug-708160-Fix-compatibility-with-C23-compilers.patch Added 0001-Fix-32-bit-build.patch to fix 32-bit archs build Added fPIC flag needed to prevent a linker error during the build process. This upgrade addresses CVEs: CVE-2025-59798, CVE-2025-59799, CVE-2025-59800, CVE-2025-59801 Changelog: https://ghostscript.readthedocs.io/en/gs10.06.0/News.html (From OE-Core rev: 0144e22195394ce2b21b476a1dcfde9129eaf615) Signed-off-by: Vijay Anusuri <vanusuri@mvista.com> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* package.py: replace all files unconditionally when copy debug sourcesChangqing Li2025-10-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is for fixing reproducible issue for package like: intel-speed-select-src. For intel-speed-select, one of the debug sources is /usr/src/debug/intel-speed-select/1.0/include/linux/thermal.h, file include/linux/thermal.h under ${S} (kernel-sources) link file include/linux/thermal.h under ${B}, which link to ${S}/include/uapi/linux/thermal.h During copy debug sources, sources under ${S} copied first, then sources under ${B} is copied. mtime of ${S}/include/linux/thermal.h and ${S}/include/uapi/linux/thermal.h are decided by when it is fetched, so it is not determinate, maybe same or different. For cpio, if the in file is older than or the same as the exist file, cpio will not replace the exist file with warning "cpio: xxx not created: newer or same age version exists". And this will cause intel-speed-select-src maybe not reproducible. And option '-u' for cpio, first, this will make the copied file determistic. Second, source files under ${B} should have higher priority then ${S}, it may be generated during build, the target is more likely to use this file. (From OE-Core rev: 8898f97b4acc9d5c2c6583c91d05327f9093133e) Signed-off-by: Changqing Li <changqing.li@windriver.com> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* linux-firmware: Fix FILES for intel firmwareRyan Eatmon2025-10-021-26/+26
| | | | | | | | | | | | | | | | The 20250917 version is installing the firmware files into the /usr/lib/firmware/intel directory and symbolic links to those files under /usr/lib/firmware. FILES needs to be updated to correctly package all of the files into the right packages. Without this we get a dependency from the linux-firmware-iwlwifi-* and linux-firmware-qat packages back to linux-firmware which means you have to install ALL of the drivers when you depend on the specific package. (From OE-Core rev: d5144f7031f1f25bb769aed860c45b1fe00ddba4) Signed-off-by: Ryan Eatmon <reatmon@ti.com> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2026-01-31 11:10:27 +0000