@@ -29,7 +29,9 @@ location (either local or remote) and then point to it in
:term:`SSTATE_MIRRORS`, you need to append "PATH"
to the end of the mirror URL so that the path used by BitBake before the
mirror substitution is appended to the path used to access the mirror.
-Here is an example::
+Here is an example:
+
+.. code-block:: bitbake
SSTATE_MIRRORS = "file://.* http://someserver.tld/share/sstate/PATH"
@@ -178,7 +180,9 @@ Linux Kernel Naming
-------------------
The naming scheme for kernel output binaries has been changed to now
-include :term:`PE` as part of the filename::
+include :term:`PE` as part of the filename:
+
+.. code-block:: bitbake
KERNEL_IMAGE_BASE_NAME ?= "${KERNEL_IMAGETYPE}-${PE}-${PV}-${PR}-${MACHINE}-${DATETIME}"
@@ -54,7 +54,9 @@ Matching Branch Requirement for Git Fetching
When fetching source from a Git repository using
:term:`SRC_URI`, BitBake will now validate the
:term:`SRCREV` value against the branch. You can specify
-the branch using the following form::
+the branch using the following form:
+
+.. code-block:: bitbake
SRC_URI = "git://server.name/repository;branch=branchname"
@@ -207,7 +209,9 @@ functions to call and not arbitrary shell commands:
For
migration purposes, you can simply wrap shell commands in a shell
-function and then call the function. Here is an example::
+function and then call the function. Here is an example:
+
+.. code-block:: bitbake
my_postprocess_function() {
echo "hello" > ${IMAGE_ROOTFS}/hello.txt
@@ -247,7 +251,9 @@ the :ref:`ref-classes-autotools` or ``autotools_stage`` classes.
``qemu-native`` now builds without SDL-based graphical output support by
default. The following additional lines are needed in your
-``local.conf`` to enable it::
+``local.conf`` to enable it:
+
+.. code-block:: bitbake
PACKAGECONFIG_pn-qemu-native = "sdl"
ASSUME_PROVIDED += "libsdl-native"
@@ -17,7 +17,9 @@ optional features. The method used to set defaults for these options
means that existing ``local.conf`` files will need to be modified to
append to :term:`PACKAGECONFIG` for ``qemu-native`` and ``nativesdk-qemu``
instead of setting it. In other words, to enable graphical output for
-QEMU, you should now have these lines in ``local.conf``::
+QEMU, you should now have these lines in ``local.conf``:
+
+.. code-block:: bitbake
PACKAGECONFIG_append_pn-qemu-native = " sdl"
PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl"
@@ -58,7 +58,9 @@ you can now remove them.
Additionally, a ``bluetooth`` class has been added to make selection of
the appropriate bluetooth support within a recipe a little easier. If
you wish to make use of this class in a recipe, add something such as
-the following::
+the following:
+
+.. code-block:: bitbake
inherit bluetooth
PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', '${BLUEZ}', '', d)}"
@@ -85,7 +87,9 @@ where the ``linux.inc`` file in ``meta-oe`` was updated.
Recipes that rely on the kernel source code and do not inherit the
:ref:`module <ref-classes-module>` classes might need to add explicit
-dependencies on the :ref:`ref-tasks-shared_workdir` kernel task, for example::
+dependencies on the :ref:`ref-tasks-shared_workdir` kernel task, for example:
+
+.. code-block:: bitbake
do_configure[depends] += "virtual/kernel:do_shared_workdir"
@@ -131,7 +135,9 @@ One of the improvements is to attempt to run "make clean" during the
:ref:`ref-tasks-configure` task if a ``Makefile`` exists. Some software packages
do not provide a working clean target within their make files. If you
have such recipes, you need to set
-:term:`CLEANBROKEN` to "1" within the recipe, for example::
+:term:`CLEANBROKEN` to "1" within the recipe, for example:
+
+.. code-block:: bitbake
CLEANBROKEN = "1"
@@ -27,7 +27,9 @@ and the porting guide at
https://gcc.gnu.org/gcc-5/porting_to.html.
Alternatively, you can switch back to GCC 4.9 or 4.8 by setting
-:term:`GCCVERSION` in your configuration, as follows::
+:term:`GCCVERSION` in your configuration, as follows:
+
+.. code-block:: bitbake
GCCVERSION = "4.9%"
@@ -200,7 +202,9 @@ changes.
Additionally, work directories for old versions of recipes are now
pruned. If you wish to disable pruning old work directories, you can set
-the following variable in your configuration::
+the following variable in your configuration:
+
+.. code-block:: bitbake
SSTATE_PRUNE_OBSOLETEWORKDIR = "0"
@@ -284,7 +284,9 @@ The following changes have been made for the Poky distribution:
Any recipe that needs to opt-out of having the ``--disable-static``
option specified on the configure command line either because it is
not a supported option for the configure script or because static
- libraries are needed should set the following variable::
+ libraries are needed should set the following variable:
+
+ .. code-block:: bitbake
DISABLE_STATIC = ""
@@ -224,7 +224,8 @@ follows and run ``runqemu``:
For command-line syntax, use ``runqemu help``.
-::
+
+.. code-block:: bitbake
IMAGE_CLASSES += "qemuboot"
@@ -241,7 +242,9 @@ recipes. You need to fix these recipes so that they use the expected
:term:`LDFLAGS`. Depending on how the software is built, the build system
used by the software (e.g. a Makefile) might need to be patched.
However, sometimes making this fix is as simple as adding the following
-to the recipe::
+to the recipe:
+
+.. code-block:: bitbake
TARGET_CC_ARCH += "${LDFLAGS}"
@@ -254,7 +257,9 @@ The ``KERNEL_IMAGE_BASE_NAME`` variable no longer uses the
:term:`KERNEL_IMAGETYPE` variable to create the
image's base name. Because the OpenEmbedded build system can now build
multiple kernel image types, this part of the kernel image base name as
-been removed leaving only the following::
+been removed leaving only the following:
+
+.. code-block:: bitbake
KERNEL_IMAGE_BASE_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}-${DATETIME}"
@@ -452,11 +452,15 @@ The following miscellaneous changes have occurred:
tools.
- The ``USE_LDCONFIG`` variable has been replaced with the "ldconfig"
- :term:`DISTRO_FEATURES` feature. Distributions that previously set::
+ :term:`DISTRO_FEATURES` feature. Distributions that previously set:
+
+ .. code-block:: bitbake
USE_LDCONFIG = "0"
- should now instead use the following::
+ should now instead use the following:
+
+ .. code-block:: bitbake
DISTRO_FEATURES_BACKFILL_CONSIDERED_append = " ldconfig"
@@ -474,7 +478,9 @@ The following miscellaneous changes have occurred:
order to allow module packages from multiple kernel versions to
co-exist on a target system. If you wish to return to the previous
naming scheme that does not include the version suffix, use the
- following::
+ following:
+
+ .. code-block:: bitbake
KERNEL_MODULE_PACKAGE_SUFFIX = ""
@@ -165,7 +165,9 @@ one of the packages provided by the Python recipe. You can no longer run
``bitbake python-foo`` or have a
:term:`DEPENDS` on ``python-foo``,
but doing either of the following causes the package to work as
-expected::
+expected:
+
+.. code-block:: bitbake
IMAGE_INSTALL_append = " python-foo"
@@ -162,7 +162,9 @@ The following changes have been made:
allows easier and more direct changes.
The :term:`IMAGE_VERSION_SUFFIX` variable is set in the ``bitbake.conf``
- configuration file as follows::
+ configuration file as follows:
+
+ .. code-block:: bitbake
IMAGE_VERSION_SUFFIX = "-${DATETIME}"
@@ -385,7 +387,9 @@ If you wish to disable Python profile-guided optimization regardless of
the value of :term:`MACHINE_FEATURES`, then ensure that
:term:`PACKAGECONFIG` for the ``python3`` recipe
does not contain "pgo". You could accomplish the latter using the
-following at the configuration level::
+following at the configuration level:
+
+.. code-block:: bitbake
PACKAGECONFIG_remove_pn-python3 = "pgo"
@@ -402,7 +406,9 @@ The following miscellaneous changes occurred:
- Default to using the Thumb-2 instruction set for armv7a and above. If
you have any custom recipes that build software that needs to be
built with the ARM instruction set, change the recipe to set the
- instruction set as follows::
+ instruction set as follows:
+
+ .. code-block:: bitbake
ARM_INSTRUCTION_SET = "arm"
@@ -261,7 +261,9 @@ The following miscellaneous changes have occurred.
- The ``gnome`` class has been removed because it now does very little.
You should update recipes that previously inherited this class to do
- the following::
+ the following:
+
+ .. code-block:: bitbake
inherit gnomebase gtk-icon-cache gconf mime
@@ -73,7 +73,9 @@ when building a simple image such as core-image-minimal. If you do not
need runtime tests enabled for core components, then it is recommended
that you remove "ptest" from
:term:`DISTRO_FEATURES` to save a significant
-amount of build time e.g. by adding the following in your configuration::
+amount of build time e.g. by adding the following in your configuration:
+
+.. code-block:: bitbake
DISTRO_FEATURES_remove = "ptest"
@@ -180,12 +182,16 @@ parameter instead of the earlier ``name`` which overlapped with the
generic ``name`` parameter. All recipes using the npm fetcher will need
to be changed as a result.
-An example of the new scheme::
+An example of the new scheme:
+
+.. code-block:: bitbake
SRC_URI = "npm://registry.npmjs.org;package=array-flatten;version=1.1.1 \
npmsw://${THISDIR}/npm-shrinkwrap.json"
-Another example where the sources are fetched from git rather than an npm repository::
+Another example where the sources are fetched from git rather than an npm repository:
+
+.. code-block:: bitbake
SRC_URI = "git://github.com/foo/bar.git;protocol=https \
npmsw://${THISDIR}/npm-shrinkwrap.json"
@@ -97,7 +97,9 @@ is prefixed on the package names in the dependencies, for example
RRECOMMENDS_${PN} = "${@bb.utils.contains('DISTRO_FEATURES', 'ldconfig', '${MLPREFIX}ldconfig', '', d)}"
This also applies when conditionally adding packages to :term:`PACKAGES` where
-those packages have dependencies, for example (from the ``alsa-plugins`` recipe)::
+those packages have dependencies, for example (from the ``alsa-plugins`` recipe):
+
+.. code-block:: bitbake
PACKAGES += "${@bb.utils.contains('PACKAGECONFIG', 'pulseaudio', 'alsa-plugins-pulseaudio-conf', '', d)}"
...
@@ -256,7 +258,9 @@ needs ``/etc/ld.so.conf`` to be present at image build time:
When some recipe installs libraries to a non-standard location, and
therefore installs in a file in ``/etc/ld.so.conf.d/foo.conf``, we
-need ``/etc/ld.so.conf`` containing::
+need ``/etc/ld.so.conf`` containing:
+
+.. code-block:: bitbake
include /etc/ld.so.conf.d/*.conf
@@ -87,14 +87,18 @@ source tree. Previously this was handled in recipes by setting :term:`S` to
point to the subdirectory within the source where ``setup.py`` is located.
However with the recent :ref:`pseudo <overview-manual/concepts:fakeroot and pseudo>`
changes, some Python modules make changes to files beneath ``${S}``, for
-example::
+example:
+
+.. code-block:: bitbake
S = "${WORKDIR}/git/python/pythonmodule"
then in ``setup.py`` it works with source code in a relative fashion, such
as ``../../src``. This causes pseudo to fail as it isn't able to track
the paths properly. This release introduces a new ``DISTUTILS_SETUP_PATH``
-variable so that recipes can specify it explicitly, for example::
+variable so that recipes can specify it explicitly, for example:
+
+.. code-block:: bitbake
S = "${WORKDIR}/git"
DISTUTILS_SETUP_PATH = "${S}/python/pythonmodule"
@@ -11,16 +11,22 @@ Override syntax changes
In this release, the ``:`` character replaces the use of ``_`` to
refer to an override, most commonly when making a conditional assignment
-of a variable. This means that an entry like::
+of a variable. This means that an entry like:
+
+.. code-block:: bitbake
SRC_URI_qemux86 = "file://somefile"
-now becomes::
+now becomes:
+
+.. code-block:: bitbake
SRC_URI:qemux86 = "file://somefile"
since ``qemux86`` is an override. This applies to any use of override
-syntax, so the following::
+syntax, so the following:
+
+.. code-block:: bitbake
SRC_URI_append = " file://somefile"
SRC_URI_append_qemux86 = " file://somefile2"
@@ -32,7 +38,9 @@ syntax, so the following::
SRCREV_pn-bash = "abc"
BB_TASK_NICE_LEVEL_task-testimage = '0'
-would now become::
+would now become:
+
+.. code-block:: bitbake
SRC_URI:append = " file://somefile"
SRC_URI:append:qemux86 = " file://somefile2"
@@ -74,7 +74,9 @@ Fetching changes
- Because of the uncertainty in future default branch names in git repositories,
it is now required to add a branch name to all URLs described
- by ``git://`` and ``gitsm://`` :term:`SRC_URI` entries. For example::
+ by ``git://`` and ``gitsm://`` :term:`SRC_URI` entries. For example:
+
+ .. code-block:: bitbake
SRC_URI = "git://git.denx.de/u-boot.git;branch=master"
@@ -91,7 +93,9 @@ Fetching changes
- Network access from tasks is now disabled by default on kernels which support
this feature (on most recent distros such as CentOS 8 and Debian 11 onwards).
This means that tasks accessing the network need to be marked as such with the ``network``
- flag. For example::
+ flag. For example:
+
+ .. code-block:: bitbake
do_mytask[network] = "1"
@@ -216,7 +220,9 @@ Miscellaneous changes
- ``blacklist.bbclass`` is removed and the functionality moved to the
:ref:`ref-classes-base` class with a more descriptive
``varflag`` variable named :term:`SKIP_RECIPE` which will use the `bb.parse.SkipRecipe()`
- function. The usage remains the same, for example::
+ function. The usage remains the same, for example:
+
+ .. code-block:: bitbake
SKIP_RECIPE[my-recipe] = "Reason for skipping recipe"
@@ -88,12 +88,16 @@ Other than knowing where to look when manually browsing the class files, this is
not likely to require any changes to your configuration. However, if in your
configuration you were using some classes in the incorrect context, you will now
receive an error during parsing. For example, the following in ``local.conf`` will
-now cause an error::
+now cause an error:
+
+.. code-block:: bitbake
INHERIT += "testimage"
Since :ref:`ref-classes-testimage` is a class intended solely to
-affect image recipes, this would be correctly specified as::
+affect image recipes, this would be correctly specified as:
+
+.. code-block:: bitbake
IMAGE_CLASSES += "testimage"
@@ -184,7 +184,9 @@ release we limit qemu port forwarding to localhost (127.0.0.1).
However, if you need the qemu machine to be reachable from the
network, then it can be enabled via ``conf/local.conf`` or machine
-config variable ``QB_SLIRP_OPT``::
+config variable ``QB_SLIRP_OPT``:
+
+.. code-block:: bitbake
QB_SLIRP_OPT = "-netdev user,id=net0,hostfwd=tcp::2222-:22"
@@ -233,7 +235,9 @@ Miscellaneous changes
- The :term:`IMAGE_NAME` variable is now set based on :term:`IMAGE_LINK_NAME`. This
means that if you are setting :term:`IMAGE_LINK_NAME` to "" to disable unversioned
image symlink creation, you also now need to set :term:`IMAGE_NAME` to still have
- a reasonable value e.g.::
+ a reasonable value e.g.:
+
+ .. code-block:: bitbake
IMAGE_LINK_NAME = ""
IMAGE_NAME = "${IMAGE_BASENAME}${IMAGE_MACHINE_SUFFIX}${IMAGE_VERSION_SUFFIX}"
@@ -271,6 +275,8 @@ Miscellaneous changes
scons in order to fix an issue with scons and command line lengths when ccache is
enabled. However, some recipes may be using older scons versions which don't support
this argument. If that is the case you can set the following in the recipe in order
- to disable this::
+ to disable this:
+
+ .. code-block:: bitbake
SCONS_MAXLINELENGTH = ""
@@ -18,7 +18,9 @@ S = ${WORKDIR} no longer supported
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
If a recipe has :term:`S` set to be :term:`WORKDIR`, this is no longer
-supported, and an error will be issued. The recipe should be changed to::
+supported, and an error will be issued. The recipe should be changed to:
+
+.. code-block:: bitbake
S = "${UNPACKDIR}"
@@ -59,7 +61,9 @@ longer the case. This means the check in ``do_unpack_qa`` triggers where
:term:`S` is not created by a recipe while it didn't happen before. This can
require to add an :term:`S` definition to a recipe that only uses
``file://`` :term:`SRC_URI` entries. To be consistent, the following pattern is
-recommended::
+recommended:
+
+.. code-block:: bitbake
S = "${UNPACKDIR}"
@@ -105,7 +109,9 @@ Go language changes
- After dropping the custom :ref:`ref-tasks-unpack` from the
:ref:`ref-classes-go` class, go recipes should now add
``destsuffix=${GO_SRCURI_DESTSUFFIX}`` to their :term:`SRC_URI` to extract
- them in the appropriate path. An example would be::
+ them in the appropriate path. An example would be:
+
+ .. code-block:: bitbake
SRC_URI = "git://go.googlesource.com/example;branch=master;protocol=https;destsuffix=${GO_SRCURI_DESTSUFFIX}"
@@ -29,7 +29,9 @@ should be manually added to the :term:`IMAGE_FEATURES` variable. These are:
- ``empty-root-password``
- ``post-install-logging``
-Such a statement would be::
+Such a statement would be:
+
+.. code-block:: bitbake
IMAGE_FEATURES += "allow-empty-password allow-root-login empty-root-password post-install-logging"
@@ -177,11 +179,15 @@ c++/binutils)" </openembedded-core/commit/?id=4ccc3bc8266c>` in
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The :term:`UBOOT_ENTRYPOINT` variable should now be defined with a leading
-``0x`` to its value. For example, consider the following assignment::
+``0x`` to its value. For example, consider the following assignment:
+
+.. code-block:: bitbake
UBOOT_ENTRYPOINT ?= "20008000"
-This should now be replaced by::
+This should now be replaced by:
+
+.. code-block:: bitbake
UBOOT_ENTRYPOINT ?= "0x20008000"
@@ -191,7 +197,9 @@ Git fetcher: support for multiple revisions per URL removed
The support for having multiple Git revisions per URL in :term:`SRC_URI` was
removed from BitBake, which means the following syntax is not supported
-anymore::
+anymore:
+
+.. code-block:: bitbake
SRC_URI = "git://some.host/somepath;bareclone=1;branch=branchX,branchY;name=nameX,nameY"
SRCREV_nameX = "xxxxxxxxxxxxxxxxxxxx"
@@ -203,7 +211,9 @@ take care of the Git checkout. This removal simplifies the code logic in several
places.
If one of your recipes is using this mechanism, you can split the code source
-fetching into two separate entries::
+fetching into two separate entries:
+
+.. code-block:: bitbake
SRC_URI = "git://some.host/somepath;bareclone=1;branch=branchX;name=nameX \
git://some.host/somepath;bareclone=1;branch=branchY;name=nameY"
@@ -214,7 +224,9 @@ Git fetcher: Branch parameter now required in :term:`SRC_URI`
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The ``branch`` parameter is now required when specifying a Git repository in
-:term:`SRC_URI`, for example::
+:term:`SRC_URI`, for example:
+
+.. code-block:: bitbake
SRC_URI = "git://some.host/somepath;branch=branchX"
@@ -50,7 +50,9 @@ in: https://lists.openembedded.org/g/openembedded-architecture/message/2179
If a recipe has :term:`S` set to be ``${``\ :term:`WORKDIR`\ ``}/something``,
this is no longer supported, and an error will be issued. The recipe should be
-changed to::
+changed to:
+
+.. code-block:: bitbake
S = "${UNPACKDIR}/something"
@@ -69,7 +71,9 @@ This location matches the default value of :term:`S` set by bitbake.conf, so :te
setting in recipes can and should be removed.
Note that when :term:`S` is set to a subdirectory of the git checkout, then it
-should be instead adjusted according to the previous point::
+should be instead adjusted according to the previous point:
+
+.. code-block:: bitbake
S = "${UNPACKDIR}/${BP}/something"
@@ -112,13 +116,17 @@ assignment in recipes::
<filename>:<line number> has a lack of whitespace around the assignment: '<assignment>'
-For example, the following assignments would print a warning::
+For example, the following assignments would print a warning:
+
+.. code-block:: bitbake
FOO="bar"
FOO= "bar"
FOO ="bar"
-These should be replaced by::
+These should be replaced by:
+
+.. code-block:: bitbake
FOO = "bar"
@@ -179,14 +187,18 @@ overview of the removed firmware.
The :term:`CPPFLAGS`, :term:`CFLAGS`, :term:`CXXFLAGS` and :term:`LDFLAGS`
variables used to have hard assignments in the :ref:`ref-classes-native` and
-:ref:`ref-classes-nativesdk` classes, respectively::
+:ref:`ref-classes-nativesdk` classes, respectively:
+
+.. code-block:: bitbake
CPPFLAGS = "${BUILD_CPPFLAGS}"
CFLAGS = "${BUILD_CFLAGS}"
CXXFLAGS = "${BUILD_CXXFLAGS}"
LDFLAGS = "${BUILD_LDFLAGS}"
-and::
+and:
+
+.. code-block:: bitbake
CPPFLAGS = "${BUILDSDK_CPPFLAGS}"
CFLAGS = "${BUILDSDK_CFLAGS}"
@@ -206,11 +218,15 @@ three**: target, :ref:`ref-classes-native` and :ref:`ref-classes-nativesdk`
contexts.
Recipes that unknowingly relied on this behavior should change these assignments
-to use ``TARGET_`` variables instead, for example::
+to use ``TARGET_`` variables instead, for example:
+
+.. code-block:: bitbake
CFLAGS += "something"
-to::
+to:
+
+.. code-block:: bitbake
TARGET_CFLAGS += "something"
@@ -305,7 +321,9 @@ The following classes have been removed in this release:
#. Make sure to include ``kernel-fit-extra-artifacts`` in your :term:`KERNEL_CLASSES`
variable to ensure the required files are exposed to the :term:`DEPLOY_DIR_IMAGE`
- directory::
+ directory:
+
+ .. code-block:: bitbake
KERNEL_CLASSES += "kernel-fit-extra-artifacts"
@@ -88,7 +88,9 @@ This does not change the default init manager of the :term:`Poky` distribution,
which remains :wikipedia:`SysVinit <UNIX_System_V>`.
Reverting to :wikipedia:`SysVinit <UNIX_System_V>` can be done by specifying the
-:term:`INIT_MANAGER` in your own :term:`DISTRO` configuration file::
+:term:`INIT_MANAGER` in your own :term:`DISTRO` configuration file:
+
+.. code-block:: bitbake
INIT_MANAGER = "sysvinit"
@@ -189,7 +191,9 @@ Previously, setting :term:`DEBUG_BUILD` to "1" globally would prevent the
changed so that only **target** binaries are stripped when this variable is set.
This change can be reverted by setting the two following lines in a
-:term:`configuration file`::
+:term:`configuration file`:
+
+.. code-block:: bitbake
INHIBIT_SYSROOT_STRIP:class-cross = "${@oe.utils.vartrue('DEBUG_BUILD', '1', '', d)}"
INHIBIT_SYSROOT_STRIP:class-native = "${@oe.utils.vartrue('DEBUG_BUILD', '1', '', d)}"
@@ -202,13 +206,17 @@ U-Boot configuration flow changes (:ref:`ref-classes-uboot-config`)
-------------------------------------------------------------------
Declaring multiple U-Boot configurations used to be entirely defined by
-one :term:`UBOOT_CONFIG` variable flag per configuration, e.g.::
+one :term:`UBOOT_CONFIG` variable flag per configuration, e.g.:
+
+.. code-block:: bitbake
UBOOT_CONFIG ??= "foo bar"
UBOOT_CONFIG[foo] = "config,images,binary"
UBOOT_CONFIG[bar] = "config2,images2,binary2"
-This has now been split into more variable flags, e.g.::
+This has now been split into more variable flags, e.g.:
+
+.. code-block:: bitbake
UBOOT_CONFIG ??= "foo bar"
UBOOT_CONFIG[foo] = "config"
@@ -233,7 +241,9 @@ See commit :oecore_rev:`cd9e7304481b24b27df61c03ad73496d18e4d47c` for more infor
.. note::
Single configuration builds have not changed and are still declared using the
- following statements::
+ following statements:
+
+ .. code-block:: bitbake
UBOOT_MACHINE = "config"
UBOOT_BINARY = "u-boot.bin"
@@ -249,7 +259,9 @@ Variables to the Environment>` directive.
These ``export`` statements have been moved to the :ref:`ref-classes-pkgconfig`
class, meaning recipes using these variables that not yet inheriting the
-:ref:`ref-classes-pkgconfig` class should now inherit it with::
+:ref:`ref-classes-pkgconfig` class should now inherit it with:
+
+.. code-block:: bitbake
inherit pkgconfig
@@ -322,11 +334,15 @@ The ``cve-check`` class was removed and replaced by the
Users currently using the ``cve-check`` class are advised to switch to
:ref:`ref-classes-sbom-cve-check`:
-- The following assignment::
+- The following assignment:
+
+ .. code-block:: bitbake
INHERIT += "cve-check"
- Should be removed and replaced by::
+ Should be removed and replaced by:
+
+ .. code-block:: bitbake
OE_FRAGMENTS += "core/yocto/sbom-cve-check"
@@ -345,7 +361,9 @@ Users currently using the ``cve-check`` class are advised to switch to
- The ``cve-check`` class output summary file (deployed in the
:term:`DEPLOY_DIR_IMAGE`) ending with ``.cve.txt`` is no longer
deployed by default but can be brought back by adding the following statement
- to a configuration file::
+ to a configuration file:
+
+ .. code-block:: bitbake
SBOM_CVE_CHECK_EXPORT_VARS:append = " SBOM_CVE_CHECK_EXPORT_SUMMARY"
@@ -395,11 +413,15 @@ the console when used::
Using the ``--sector-size`` command-line argument can be done through the
:term:`WIC_CREATE_EXTRA_ARGS` variable.
-For example, a previous assignment to :term:`WIC_SECTOR_SIZE`::
+For example, a previous assignment to :term:`WIC_SECTOR_SIZE`:
+
+.. code-block:: bitbake
WIC_SECTOR_SIZE = "4096"
-Should be replaced by::
+Should be replaced by:
+
+.. code-block:: bitbake
WIC_CREATE_EXTRA_ARGS += "--sector-size 4096"
@@ -44,17 +44,23 @@ version 4.20. The same functionality provided by ``groupmems`` can be achieved
with the ``usermod`` command.
Assignments made to the :term:`GROUPMEMS_PARAM` variable can be converted to use
-:term:`USERMOD_PARAMS`, by replacing::
+:term:`USERMOD_PARAMS`, by replacing:
+
+.. code-block:: bitbake
GROUPMEMS_PARAM:${PN} = "--add user --group group1; \
--add user --group group2"
-With::
+With:
+
+.. code-block:: bitbake
USERMOD_PARAM:${PN} = "--append --groups group1 user; \
--append --groups group2 user"
-Or written more simply as::
+Or written more simply as:
+
+.. code-block:: bitbake
USERMOD_PARAM:${PN} = "--append --groups group1,group2 user"
@@ -21,7 +21,9 @@ New Features / Enhancements in 4.0
its autobuilder. If the network connection between our server and your
machine is faster than you would build recipes from source, you can
try to speed up your builds by using such Shared State and Hash
- Equivalence by setting::
+ Equivalence by setting:
+
+ .. code-block:: bitbake
BB_SIGNATURE_HANDLER = "OEEquivHash"
BB_HASHSERVE = "auto"
@@ -45,7 +45,9 @@ New Features / Enhancements in 4.3
Code can now know which layer a recipe is coming from through the newly added :term:`FILE_LAYERNAME`
variable. This has been added as an override of the form ``layer-<layername>``. In particular,
- this means QA checks can now be layer specific, for example::
+ this means QA checks can now be layer specific, for example:
+
+ .. code-block:: bitbake
ERROR_QA:layer-core:append = " patch-status"
@@ -195,7 +195,9 @@ New Features / Enhancements in 5.0
- New ``inherit_defer`` statement which works as
:ref:`inherit <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:\`\`inherit\`\` directive>`
does, except that it is only evaluated at the end of parsing
- --- recommended where a conditional expression is used, e.g.::
+ --- recommended where a conditional expression is used, e.g.:
+
+ .. code-block:: bitbake
inherit_defer ${@bb.utils.contains('PACKAGECONFIG', 'python', 'python3targetconfig', '', d)}
@@ -92,7 +92,9 @@ New Features / Enhancements in |yocto-ver|
distro/... Sets DISTRO = ...
In the above example, this means that the :term:`MACHINE` of
- :term:`DISTRO` can be overridden with::
+ :term:`DISTRO` can be overridden with:
+
+ .. code-block:: bitbake
OE_FRAGMENTS += "machine/qemuarm64 distro/poky-bleeding"
@@ -928,7 +930,9 @@ New Features / Enhancements in |yocto-ver|
:ref:`qa-check-pep517-backend` QA check.
- The :ref:`ref-classes-ccache` class now supports using `Ccache` for native
- recipes when the local build configuration contains::
+ recipes when the local build configuration contains:
+
+ .. code-block:: bitbake
ASSUME_PROVIDED += "ccache-native"
HOSTTOOLS += "ccache"
BitBake snippets here render as unhighlighted text. A reStructuredText literal block carries no language, and Sphinx falls back to a default that cannot recognise BitBake metadata. Pygments 2.21 added a BitBake lexer, so tag these 79 blocks explicitly. Variable names, assignment operators, override chains, expansions and shell or Python task bodies are then highlighted. Blocks that only look like BitBake are left alone, as are blocks already tagged "none" where the content is deliberately unhighlighted. AI-Generated: codex/claude-opus 5 (xhigh) Signed-off-by: Trevor Woerner <twoerner@gmail.com> --- .../migration-guides/migration-1.3.rst | 8 +++- .../migration-guides/migration-1.6.rst | 12 +++-- .../migration-guides/migration-1.7.rst | 4 +- .../migration-guides/migration-1.8.rst | 12 +++-- .../migration-guides/migration-2.0.rst | 8 +++- .../migration-guides/migration-2.1.rst | 4 +- .../migration-guides/migration-2.2.rst | 11 +++-- .../migration-guides/migration-2.3.rst | 12 +++-- .../migration-guides/migration-2.5.rst | 4 +- .../migration-guides/migration-2.6.rst | 12 +++-- .../migration-guides/migration-3.0.rst | 4 +- .../migration-guides/migration-3.1.rst | 12 +++-- .../migration-guides/migration-3.2.rst | 8 +++- .../migration-guides/migration-3.3.rst | 8 +++- .../migration-guides/migration-3.4.rst | 16 +++++-- .../migration-guides/migration-4.0.rst | 12 +++-- .../migration-guides/migration-4.1.rst | 8 +++- .../migration-guides/migration-4.2.rst | 12 +++-- .../migration-guides/migration-5.1.rst | 12 +++-- .../migration-guides/migration-5.2.rst | 24 +++++++--- .../migration-guides/migration-5.3.rst | 36 +++++++++++---- .../migration-guides/migration-6.0.rst | 44 ++++++++++++++----- .../migration-guides/migration-6.1.rst | 12 +++-- .../migration-guides/release-notes-4.0.rst | 4 +- .../migration-guides/release-notes-4.3.rst | 4 +- .../migration-guides/release-notes-5.0.rst | 4 +- .../migration-guides/release-notes-5.3.rst | 8 +++- 27 files changed, 236 insertions(+), 79 deletions(-)