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>
Poky as in the repository will no longer be updated. Update the
description of Poky to remove the last bullet point, and add a note to
say that Poky was used before.
(From yocto-docs rev: c6f5de9fdbab3f29336ac3bf30150de8777bcad7)
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a new document describing how to setup the Poky reference
distribution manually. This document is referenced in the Quick Guide,
so that users that _know_ they want to setup Poky without bitbake-setup
have a link to it.
This document is also important to reflect the layout of the layers
expected by the bblayers.conf.sample file, as explained in [1].
[1]: https://lore.kernel.org/poky/20251028-update-bblayers-sample-v1-1-97ec54cda94e@bootlin.com/
(From yocto-docs rev: 0ddb5f4be84a97a66cc92c3c68c820af5223e108)
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Switch to bitbake-setup as it has been merged in BitBake with commit
b96154aeb1fc ("bitbake-setup: add the initial implementation"). This is
the default way to setup repositories now, so describe it in
brief-yoctoprojectqs.rst.
Update the BSP layer addition section to use meta-raspberrypi as
meta-altera seems abandoned (latest compatible version: mickedore).
Co-developed-by: Tim Orling <tim.orling@konsulko.com>
(From yocto-docs rev: 868da60dd90ee6c8710df1ed14b046d809d25b52)
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These images are not used anywhere in the docs. Remove them.
(From yocto-docs rev: a0edada1eb056f726c0e28022ec733cb33f3e1a1)
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This was not documented and its usage is going to increase massively
once users start using bitbake-setup. Add a description for this file as
well as an example on how bitbake-setup shares it for multiple builds,
to insist on the "site-wide" usage of this file.
(From yocto-docs rev: 42f68f7de7f0cf74ebdd31fae3173dd3a80386ff)
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The local.conf file is now mostly empty with the default way of setting
up the environment (with bitbake-setup), and this file is meant to hold
local user configurations, rather than an extensive list of variables.
Adjust the description to reflect the intended way of using this
configuration file.
Also, for both local.conf and bblayers.conf, rephrase the current
usage of the template files (.sample files) to _not_ imply that it is
the default way the OpenEmbedded build system sets things up.
(From yocto-docs rev: 24f24d07fd688825b2ec39dcf0daf8203577f87a)
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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>
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>
- improve bb-layers property description
- add bb-layers-file-relative property
The rationale is that both properties are relative to their respective directories
and that should be documented and clear from their names (without being too verbose).
Based on a patch from Alexander Kanavin <alex@linutronix.de> but with
updated naming.
(From OE-Core rev: b9d761c06350020e14e09c5bfa7b92eded43d889)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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>
{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>
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>
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>
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>
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>
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>
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>
Replace HOMEPAGE, because wiki.gnome.org ‘has been retiredʼ (said on the
site).
(From OE-Core rev: b501eeaafde639b6da4f9bfeaeb76b40c7e92633)
Signed-off-by: Jörg Sommer <joerg.sommer@navimatix.de>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Dropping CVE_PRODUCT, because it was equal to the default.
(From OE-Core rev: 2b7e57466940a2b3a303fca1de67fb3524cf2c78)
Signed-off-by: Jörg Sommer <joerg.sommer@navimatix.de>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [YOCTO 14649]
The default 3s test execution timeout isn't always enough for the check_cwm test
on the autobuilder in case there is a high load on the host machine,
and due to this this case fails sometimes.
This patch doubles the timeout for this testcase to 6 seconds to allow enough
time for execution even if there is high CPU usage by other processes.
(From OE-Core rev: 561aba8d38d1e15d23bd13736013825bd04aff2c)
Signed-off-by: Gyorgy Sarvari <skandigraun@gmail.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Backport a patch from upstream to resolve CVE-2025-11232:
Invalid characters cause assert
To trigger the issue, three configuration parameters must have
specific settings: "hostname-char-set" must be left at the default
setting, which is "[^A-Za-z0-9.-]"; "hostname-char-replacement" must
be empty (the default); and "ddns-qualifying-suffix" must NOT be empty
(the default is empty). DDNS updates do not need to be enabled for
this issue to manifest. A client that sends certain option content
would then cause kea-dhcp4 to exit unexpectedly.
(From OE-Core rev: f9331b42fd8b0df64517969a794a93d41624bd96)
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>
Omit most of the build dependencies of rpm-sequoia-native as it
needs only OpenSSL, and implicitly, libgcc and the C runtime
to run.
The list of build dependencies were determined by
$ bitbake -e rpm-sequoia-native 2>&1 | grep ^DEPENDS=
DEPENDS="pkgconfig-native cargo-native openssl-native python3-native rust-native rust-native"
Omitting these (except openssl-native) can save significant
amount of disk space and it also speeds up packaging into
signed rpms a little.
Omitting rust-native (and implicitly, llvm-native) also avoids
conflicts with different LLVM/CLANG versions, like those found
in meta-clang-revival.
(From OE-Core rev: 805227759dbd8303124f25c46f928848cf045cc6)
Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
>From https://lists.x.org/archives/xorg-announce/2025-October/003635.html:
1) CVE-2025-62229: Use-after-free in XPresentNotify structures creation
Using the X11 Present extension, when processing and adding the
notifications after presenting a pixmap, if an error occurs, a dangling
pointer may be left in the error code path of the function causing a
use-after-free when eventually destroying the notification structures
later.
Introduced in: Xorg 1.15
Fixed in: xorg-server-21.1.19 and xwayland-24.1.9
Fix: https://gitlab.freedesktop.org/xorg/xserver/-/commit/5a4286b1
Found by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative.
2) CVE-2025-62230: Use-after-free in Xkb client resource removal
When removing the Xkb resources for a client, the function
XkbRemoveResourceClient() will free the XkbInterest data associated
with the device, but not the resource associated with it.
As a result, when the client terminates, the resource delete function
triggers a use-after-free.
Introduced in: X11R6
Fixed in: xorg-server-21.1.19 and xwayland-24.1.9
Fix: https://gitlab.freedesktop.org/xorg/xserver/-/commit/99790a2chttps://gitlab.freedesktop.org/xorg/xserver/-/commit/10c94238
Found by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative.
3) CVE-2025-62231: Value overflow in Xkb extension XkbSetCompatMap()
The XkbCompatMap structure stores some of its values using an unsigned
short, but fails to check whether the sum of the input data might
overflow the maximum unsigned short value.
Introduced in: X11R6
Fixed in: xorg-server-21.1.19 and xwayland-24.1.9
Fix: https://gitlab.freedesktop.org/xorg/xserver/-/commit/475d9f49
Found by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative.
(From OE-Core rev: f3b5fc0174478e1ab6d3d03c8fdc75be28d0fd3b)
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>
>From https://lists.x.org/archives/xorg-announce/2025-October/003635.html:
1) CVE-2025-62229: Use-after-free in XPresentNotify structures creation
Using the X11 Present extension, when processing and adding the
notifications after presenting a pixmap, if an error occurs, a dangling
pointer may be left in the error code path of the function causing a
use-after-free when eventually destroying the notification structures
later.
Introduced in: Xorg 1.15
Fixed in: xorg-server-21.1.19 and xwayland-24.1.9
Fix: https://gitlab.freedesktop.org/xorg/xserver/-/commit/5a4286b1
Found by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative.
2) CVE-2025-62230: Use-after-free in Xkb client resource removal
When removing the Xkb resources for a client, the function
XkbRemoveResourceClient() will free the XkbInterest data associated
with the device, but not the resource associated with it.
As a result, when the client terminates, the resource delete function
triggers a use-after-free.
Introduced in: X11R6
Fixed in: xorg-server-21.1.19 and xwayland-24.1.9
Fix: https://gitlab.freedesktop.org/xorg/xserver/-/commit/99790a2chttps://gitlab.freedesktop.org/xorg/xserver/-/commit/10c94238
Found by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative.
3) CVE-2025-62231: Value overflow in Xkb extension XkbSetCompatMap()
The XkbCompatMap structure stores some of its values using an unsigned
short, but fails to check whether the sum of the input data might
overflow the maximum unsigned short value.
Introduced in: X11R6
Fixed in: xorg-server-21.1.19 and xwayland-24.1.9
Fix: https://gitlab.freedesktop.org/xorg/xserver/-/commit/475d9f49
Found by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative.
(From OE-Core rev: 50b9c34ba932761fab9035a54e58466d72b097bf)
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>
The underlying issue with -fno-common was resolved upstream in xserver
21.1.0 onwards[1].
[1] xserver 0148a15da ("compiler.h: don't define inb/outb and friends on mips")
(From OE-Core rev: 74b77ee90efd50a703af76769fac66a0f7c394ca)
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>
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>
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>
6.16 in branch name for 6.17 kernel does not look correct.
$ git branch -r --contains 459fdea93914f4db040bd8ebf8bce134a4cd6388
linux-yocto/v6.17/standard/genericarm64
(From meta-yocto rev: 66ea31cee15309af07afeee8dec8a6fe1d92d28e)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Cc: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Adding a 6.17 kernel bbappend so the hardware reference BSPs
can be tested against the newer kernel (but it is not the
default)
(From meta-yocto rev: 4d15f394f8862cca77eb780e7bfcd945f9aae5f4)
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We had previously dropped the genericarm64 as it was using
standard/base for builds. But we have some temporary serial
patches only for these platforms, so we we are building out
of standard/genericarm64 to isolate those patches.
As a result, we do need to set our SRCREV to ensure that
the content is built on the branch.
Note: we can also move these to the main linux-yocto recipes
as genericarm64 has broad scope and is more than just an
indidual hardware reference BSP.
(From meta-yocto rev: 6257391c9594ed59f18ce1f7bf9bf7323d55a868)
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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>
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>
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>
