subtree updates
poky: 492205ea83..94dfcaff64:
Alejandro Hernandez Samaniego (1):
baremetal-helloworld: Enable RISC-V 32 port
Alexandre Belloni (1):
oeqa/runtime/cases: make date.DateTest.test_date more reliable
Anton Blanchard (3):
libjpeg-turbo: Handle powerpc64le without Altivec
kmod: use nonarch_base_libdir for depmod.d and modprobe.d
pixman: Handle PowerPC without Altivec
Changqing Li (1):
libconvert-asn1-perl: 0.27 -> 0.31
Chen Qi (4):
convert-overrides.py: also convert comments without a leading whitespace
meta: use new override syntax in comments
multilib.bbclass: fix new override syntax for virtclass-multilib
util-linux: add back manpages related settings
Daniel Gomez (1):
docs: fix typo in releases
Dmitry Baryshkov (1):
linux-firmware: add more Qualcomm firmware packages
Dragos-Marian Panait (1):
util-linux: fix CVE-2021-37600
Joe Slater (1):
terminal.bbclass: force bash for devshell
Jon Mason (1):
tune-cortexm*: add support for all Arm Cortex-M processors
Jose Quaresma (1):
sstate.bbclass: fix error handling when sstate mirrors is ro
Joshua Watt (2):
classes/cve-check: Move get_patches_cves to library
lib/packagedata: Fix for new overrides
Khem Raj (4):
glibc: Upgrade to 2.34 release
glibc: Remove obsolete --enable-stackguard-randomization
glibc: Drop DUMMY_LOCALE_T define patch
glibc: Add missing symlinks for libpthread and librt dev files
Michael Halstead (1):
releases: update to include 3.1.10
Michael Opdenacker (12):
manuals: mention license information in footer
manuals: further documentation for cve-check
cve-check: remove deprecated CVE_CHECK_CVE_WHITELIST
bsp-guide: overrides syntax updates
dev-manual: overrides syntax updates
kernel-dev manual: overrides syntax updates
ref-manual: overrides syntax updates
sdk-manual: overrides syntax updates
test-manual: overrides syntax updates
sdk-manual: reference obsolete reference to ADT
Manuals: replace "file name" by "filename"
dev-manual: fix grammar in post-install script explanations
Nisha Parrakat (1):
dbus_%.bbappend: stop using selinux_set_mapping
Olaf Mandel (1):
kickstart: document which options accept units
Patrick Williams (3):
pixman: re-disable iwmmxt
systemd: add zstd PACKAGECONFIG
systemd: set zstd as default PACKAGECONFIG
Paul Barker (2):
u-boot: Package extlinux.conf separately
pypi: Allow override of PyPI archive name
Quentin Schulz (3):
insane.bbclass: fix new override syntax migration
docs: fix new override syntax migration
docs: overview-manual: concepts: remove long-gone BBHASHDEPS variable
Richard Purdie (6):
test-manual: Add extra detail to YP Compatible section
migration-3.4: Add extra notes to override syntax changes
ruby: Fix DEBUG_PREFIX_MAP in LDFLAGS issue
gettext: Fix reproducibility issue with LDFLAGS
curl: Fix reproducibility issue with LDFLAGS
libtool: Fix lto option passing for reproducible builds
Ross Burton (11):
e2fsprogs: ensure small images have 256-byte inodes
wic: don't forcibly pass -T default
parted: drop unneeded ld-is-gold patch
parted: update patch status
buildtools-tarball: add testsdk task
oeqa/sdk: add some buildtools tests
bitbake: utils: add environment updating context manager
bitbake: fetch2: expose environment variable names that need to be exported
bitbake: fetch2/wget: ensure all variables are set when calling urllib
bitbake: fetch2/wget: fetch securely by default
tar: ignore node-tar CVEs
Thomas Perrot (2):
kernel-fitimage: images should not be signed with the same keys as the configurations
oeqa/selftest/fitimage: update tests to use two keys
Tim Orling (3):
python3-scons{-native}: upgrade 4.1.0 -> 4.2.0
perl: do_create_rdepends_inc override syntax
package.bbclass: FILER* override syntax
Tom Rini (2):
common-tasks: Add a summary to the end of the bbappend example
manuals: Rename the "Using .bbappend Files in Your Layer" section
Tony Battersby (2):
bitbake.conf: add DEBUG_PREFIX_MAP to TARGET_LDFLAGS
ruby: Fix reproducibility issue with LDFLAGS
Tony Tascioglu (1):
valgrind: skip broken ptests for glibc 2.34
Vyacheslav Yurkov (7):
lib/oe: add generic functions for overlayfs
overlayfs.bbclass: generate overlayfs mount units
rootfs-postcommands: add QA check for overlayfs
systemd-machine-units: add bbappend for meta-selftest
overlayfs: meta-selftest recipe
oeqa/selftest: overlayfs unit tests
MAINTAINERS: add overlayfs maintainer
Yi Zhao (3):
dbus: add PACKAGECONFIG for audit and selinux
glib-2.0: add PACKAGECONFIG for selinux
shadow: add PACKAGECONFIG for audit and selinux
hongxu (1):
sdk: fix relocate symlink failed
wangmy (1):
ell: upgrade 0.41 -> 0.42
meta-raspberrypi: c7f4c739a3..32921fc9bd:
Omer Akram (1):
linux-firmware-rpidistro: fix wifi driver loading on cm4
Otavio Salvador (1):
rpi-config: Allow setting hdmi_cvt
meta-openembedded: 3cf2475ea0..a13db91f19:
Changqing Li (1):
ndpi: fix CVE-2021-36082
Chen Qi (1):
Convert to new override syntax using latest convert-overrides.py script
Dmitry Baryshkov (1):
image_types_sparse: fix sparse image generation
Geoff Parker (1):
cifs-utils: typo fix fakse --> false
Kai Kang (2):
libdbi-perl: fix CVE-2014-10402
python3-m2crypto: fix for new overrides syntax
Khem Raj (1):
packagegroup-meta-oe: Add ttf-ipa
Leon Anavi (15):
python3-astroid: Upgrade 2.6.5 -> 2.6.6
python3-gast: Upgrade 0.5.1 -> 0.5.2
python3-greenlet: Upgrade 1.1.0 -> 1.1.1
python3-bitarray: Upgrade 2.2.3 -> 2.2.5
python3-send2trash: Upgrade 1.7.1 -> 1.8.0
python3-zeroconf: Upgrade 0.33.2 -> 0.34.3
python3-aiohue: Upgrade 2.5.1 -> 2.6.1
python3-configargparse: Upgrade 1.5.1 -> 1.5.2
python3-pycurl: Upgrade 7.43.0.6 -> 7.44.0
python3-distro: Upgrade 1.5.0 -> 1.6.0
python3-google-api-core: Upgrade 1.30.0 -> 1.31.1
python3-google-auth: Upgrade 1.32.0 -> 1.34.0
python3-google-api-python-client: Upgrade 2.12.0 -> 2.15.0
python3-huey: Upgrade 2.3.2 -> 2.4.0
python3-apply-defaults: Upgrade 0.1.4 -> 0.1.6
Martin Jansa (1):
python3-grpcio: make sure that GRPC_CFLAGS is expanded to empty
Michael Opdenacker (3):
vorbis-tools: update to 1.4.2 (latest in 1.4.x series)
bigbuckbunny-1080p: fix sample video URL
opus-tools: update to 0.2, move to meta-multimedia and fix license
Mingli Yu (3):
jemalloc: fix the race during do_install
jemalloc: add ptest support
jemalloc: improve the ptest output
Naveen Saini (1):
python3-defusedxml: extend recipe to add native support
Philippe Coval (1):
mycroft: Install more tools needed by scripts
Tony Battersby (3):
curlpp: fix QA Issue after LDFLAGS change
ldns: fix QA Issue after LDFLAGS change
tcsh: fix compile error after LDFLAGS change
Yi Zhao (5):
audit: upgrade 3.0.3 -> 3.0.4
augeas: rename PACKAGECONFIG[libselinux] to PACKAGECONFIG[selinux]
network-manager-applet: add selinux to PACKAGECONFIG if enable selinux distro feature
networkmanager: add PACKAGECONFIG for audit and selinux
augeas: add selinux to PACKAGECONFIG if enable selinux distro feature
leimaohui (1):
ttf-ipa: Added a new font.
wangmy (1):
iwd: upgrade 1.15 -> 1.16
zangrc (1):
python3-humanize: upgrade 3.10.0 -> 3.11.0
zhengruoqin (3):
python3-engineio: upgrade 4.2.0 -> 4.2.1
python3-ipython: upgrade 7.25.0 -> 7.26.0
python3-isort: upgrade 5.9.2 -> 5.9.3
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: I7a8bd19709f465db51254ed3fcaf2486fe64dcaf
diff --git a/poky/documentation/bsp-guide/bsp.rst b/poky/documentation/bsp-guide/bsp.rst
index 5f62376..b80354a 100644
--- a/poky/documentation/bsp-guide/bsp.rst
+++ b/poky/documentation/bsp-guide/bsp.rst
@@ -1042,7 +1042,7 @@
#. Edit the ``init-ifupdown_1.0.bbappend`` file so that it contains the
following::
- FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
+ FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
The append file needs to be in the ``meta-xyz/recipes-core/init-ifupdown``
directory.
@@ -1269,9 +1269,9 @@
include conf/machine/include/tune-cortexa8.inc
IMAGE_FSTYPES += "tar.bz2 jffs2 wic wic.bmap"
- EXTRA_IMAGECMD_jffs2 = "-lnp "
+ EXTRA_IMAGECMD:jffs2 = "-lnp "
WKS_FILE ?= "beaglebone-yocto.wks"
- IMAGE_INSTALL_append = " kernel-devicetree kernel-image-zimage"
+ IMAGE_INSTALL:append = " kernel-devicetree kernel-image-zimage"
do_image_wic[depends] += "mtools-native:do_populate_sysroot dosfstools-native:do_populate_sysroot"
SERIAL_CONSOLES ?= "115200;ttyS0 115200;ttyO0"
@@ -1458,29 +1458,29 @@
Following is the contents of the append file::
- KBRANCH_genericx86 = "v5.0/standard/base"
- KBRANCH_genericx86-64 = "v5.0/standard/base"
- KBRANCH_edgerouter = "v5.0/standard/edgerouter"
- KBRANCH_beaglebone-yocto = "v5.0/standard/beaglebone"
+ KBRANCH:genericx86 = "v5.0/standard/base"
+ KBRANCH:genericx86-64 = "v5.0/standard/base"
+ KBRANCH:edgerouter = "v5.0/standard/edgerouter"
+ KBRANCH:beaglebone-yocto = "v5.0/standard/beaglebone"
- KMACHINE_genericx86 ?= "common-pc"
- KMACHINE_genericx86-64 ?= "common-pc-64"
- KMACHINE_beaglebone-yocto ?= "beaglebone"
+ KMACHINE:genericx86 ?= "common-pc"
+ KMACHINE:genericx86-64 ?= "common-pc-64"
+ KMACHINE:beaglebone-yocto ?= "beaglebone"
- SRCREV_machine_genericx86 ?= "3df4aae6074e94e794e27fe7f17451d9353cdf3d"
- SRCREV_machine_genericx86-64 ?= "3df4aae6074e94e794e27fe7f17451d9353cdf3d"
- SRCREV_machine_edgerouter ?= "3df4aae6074e94e794e27fe7f17451d9353cdf3d"
- SRCREV_machine_beaglebone-yocto ?= "3df4aae6074e94e794e27fe7f17451d9353cdf3d"
+ SRCREV_machine:genericx86 ?= "3df4aae6074e94e794e27fe7f17451d9353cdf3d"
+ SRCREV_machine:genericx86-64 ?= "3df4aae6074e94e794e27fe7f17451d9353cdf3d"
+ SRCREV_machine:edgerouter ?= "3df4aae6074e94e794e27fe7f17451d9353cdf3d"
+ SRCREV_machine:beaglebone-yocto ?= "3df4aae6074e94e794e27fe7f17451d9353cdf3d"
- COMPATIBLE_MACHINE_genericx86 = "genericx86"
- COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64"
- COMPATIBLE_MACHINE_edgerouter = "edgerouter"
- COMPATIBLE_MACHINE_beaglebone-yocto = "beaglebone-yocto"
+ COMPATIBLE_MACHINE:genericx86 = "genericx86"
+ COMPATIBLE_MACHINE:genericx86-64 = "genericx86-64"
+ COMPATIBLE_MACHINE:edgerouter = "edgerouter"
+ COMPATIBLE_MACHINE:beaglebone-yocto = "beaglebone-yocto"
- LINUX_VERSION_genericx86 = "5.0.3"
- LINUX_VERSION_genericx86-64 = "5.0.3"
- LINUX_VERSION_edgerouter = "5.0.3"
- LINUX_VERSION_beaglebone-yocto = "5.0.3"
+ LINUX_VERSION:genericx86 = "5.0.3"
+ LINUX_VERSION:genericx86-64 = "5.0.3"
+ LINUX_VERSION:edgerouter = "5.0.3"
+ LINUX_VERSION:beaglebone-yocto = "5.0.3"
This particular append file works for all the machines that are
part of the ``meta-yocto-bsp`` layer. The relevant statements are
diff --git a/poky/documentation/conf.py b/poky/documentation/conf.py
index 6c6458f..8e15fdc 100644
--- a/poky/documentation/conf.py
+++ b/poky/documentation/conf.py
@@ -28,7 +28,7 @@
# -- Project information -----------------------------------------------------
project = 'The Yocto Project \xae'
-copyright = '2010-%s, The Linux Foundation' % datetime.datetime.now().year
+copyright = '2010-%s, The Linux Foundation, CC-BY-SA-2.0-UK license' % datetime.datetime.now().year
author = 'The Linux Foundation'
# -- General configuration ---------------------------------------------------
diff --git a/poky/documentation/dev-manual/common-tasks.rst b/poky/documentation/dev-manual/common-tasks.rst
index 7fa0df4..7f51674 100644
--- a/poky/documentation/dev-manual/common-tasks.rst
+++ b/poky/documentation/dev-manual/common-tasks.rst
@@ -207,37 +207,37 @@
To make sure your changes apply only when building machine "one",
use a machine override with the :term:`DEPENDS` statement::
- DEPENDS_one = "foo"
+ DEPENDS:one = "foo"
- You should follow the same strategy when using ``_append``
- and ``_prepend`` operations::
+ You should follow the same strategy when using ``:append``
+ and ``:prepend`` operations::
- DEPENDS_append_one = " foo"
- DEPENDS_prepend_one = "foo "
+ DEPENDS:append:one = " foo"
+ DEPENDS:prepend:one = "foo "
As an actual example, here's a
snippet from the generic kernel include file ``linux-yocto.inc``,
wherein the kernel compile and link options are adjusted in the
case of a subset of the supported architectures::
- DEPENDS_append_aarch64 = " libgcc"
- KERNEL_CC_append_aarch64 = " ${TOOLCHAIN_OPTIONS}"
- KERNEL_LD_append_aarch64 = " ${TOOLCHAIN_OPTIONS}"
+ DEPENDS:append:aarch64 = " libgcc"
+ KERNEL_CC:append:aarch64 = " ${TOOLCHAIN_OPTIONS}"
+ KERNEL_LD:append:aarch64 = " ${TOOLCHAIN_OPTIONS}"
- DEPENDS_append_nios2 = " libgcc"
- KERNEL_CC_append_nios2 = " ${TOOLCHAIN_OPTIONS}"
- KERNEL_LD_append_nios2 = " ${TOOLCHAIN_OPTIONS}"
+ DEPENDS:append:nios2 = " libgcc"
+ KERNEL_CC:append:nios2 = " ${TOOLCHAIN_OPTIONS}"
+ KERNEL_LD:append:nios2 = " ${TOOLCHAIN_OPTIONS}"
- DEPENDS_append_arc = " libgcc"
- KERNEL_CC_append_arc = " ${TOOLCHAIN_OPTIONS}"
- KERNEL_LD_append_arc = " ${TOOLCHAIN_OPTIONS}"
+ DEPENDS:append:arc = " libgcc"
+ KERNEL_CC:append:arc = " ${TOOLCHAIN_OPTIONS}"
+ KERNEL_LD:append:arc = " ${TOOLCHAIN_OPTIONS}"
- KERNEL_FEATURES_append_qemuall=" features/debug/printk.scc"
+ KERNEL_FEATURES:append:qemuall=" features/debug/printk.scc"
.. note::
- Avoiding "+=" and "=+" and using machine-specific ``_append``
- and ``_prepend`` operations is recommended as well.
+ Avoiding "+=" and "=+" and using machine-specific ``:append``
+ and ``:prepend`` operations is recommended as well.
- *Place Machine-Specific Files in Machine-Specific Locations:* When
you have a base recipe, such as ``base-files.bb``, that contains a
@@ -247,7 +247,7 @@
at ``meta-one/recipes-core/base-files/base-files.bbappend`` could
extend :term:`FILESPATH` using :term:`FILESEXTRAPATHS` as follows::
- FILESEXTRAPATHS_prepend := "${THISDIR}/${BPN}:"
+ FILESEXTRAPATHS:prepend := "${THISDIR}/${BPN}:"
The build for machine "one" will pick up your machine-specific file as
long as you have the file in
@@ -443,8 +443,8 @@
adds the recipes, classes and configurations contained within the
particular layer to the source directory.
-Using .bbappend Files in Your Layer
------------------------------------
+Appending Other Layers Metadata With Your Layer
+-----------------------------------------------
A recipe that appends Metadata to another recipe is called a BitBake
append file. A BitBake append file uses the ``.bbappend`` file type
@@ -465,7 +465,7 @@
When you create an append file, you must use the same root name as the
corresponding recipe file. For example, the append file
``someapp_3.1.bbappend`` must apply to ``someapp_3.1.bb``. This
-means the original recipe and append file names are version
+means the original recipe and append filenames are version
number-specific. If the corresponding recipe is renamed to update to a
newer version, you must also rename and possibly update the
corresponding ``.bbappend`` as well. During the build process, BitBake
@@ -474,6 +474,9 @@
:term:`BB_DANGLINGAPPENDS_WARNONLY`
variable for information on how to handle this error.
+Overlaying a File Using Your Layer
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
As an example, consider the main formfactor recipe and a corresponding
formfactor append file both from the :term:`Source Directory`.
Here is the main
@@ -512,7 +515,7 @@
and is from the Raspberry Pi BSP Layer named ``meta-raspberrypi``. The
file is in the layer at ``recipes-bsp/formfactor``::
- FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+ FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:"
By default, the build system uses the
:term:`FILESPATH` variable to
@@ -537,7 +540,7 @@
.. note::
BitBake automatically defines the :term:`THISDIR` variable. You should
- never set this variable yourself. Using "_prepend" as part of the
+ never set this variable yourself. Using ":prepend" as part of the
:term:`FILESEXTRAPATHS` ensures your path will be searched prior to other
paths in the final list.
@@ -545,6 +548,12 @@
allow to add build options (e.g. ``systemd``). For these cases, your
append file would not even use the :term:`FILESEXTRAPATHS` statement.
+The end result of this ``.bbappend`` file is that on a Raspberry Pi, where
+``rpi`` will exist in the list of :term:`OVERRIDES`, the file
+``meta-raspberrypi/recipes-bsp/formfactor/formfactor/rpi/machconfig`` will be
+used during :ref:`ref-tasks-fetch` and the test for a non-zero file size in
+:ref:`ref-tasks-install` will return true, and the file will be installed.
+
Prioritizing Your Layer
-----------------------
@@ -830,27 +839,27 @@
all images, which might not be what you require.
To add a package to your image using the local configuration file, use
-the :term:`IMAGE_INSTALL` variable with the ``_append`` operator::
+the :term:`IMAGE_INSTALL` variable with the ``:append`` operator::
- IMAGE_INSTALL_append = " strace"
+ IMAGE_INSTALL:append = " strace"
Use of the syntax is important -
specifically, the space between the quote and the package name, which is
-``strace`` in this example. This space is required since the ``_append``
+``strace`` in this example. This space is required since the ``:append``
operator does not add the space.
-Furthermore, you must use ``_append`` instead of the ``+=`` operator if
+Furthermore, you must use ``:append`` instead of the ``+=`` operator if
you want to avoid ordering issues. The reason for this is because doing
so unconditionally appends to the variable and avoids ordering problems
due to the variable being set in image recipes and ``.bbclass`` files
-with operators like ``?=``. Using ``_append`` ensures the operation
+with operators like ``?=``. Using ``:append`` ensures the operation
takes effect.
-As shown in its simplest use, ``IMAGE_INSTALL_append`` affects all
+As shown in its simplest use, ``IMAGE_INSTALL:append`` affects all
images. It is possible to extend the syntax so that the variable applies
to a specific image only. Here is an example::
- IMAGE_INSTALL_append_pn-core-image-minimal = " strace"
+ IMAGE_INSTALL:append:pn-core-image-minimal = " strace"
This example adds ``strace`` to the ``core-image-minimal`` image only.
@@ -976,17 +985,17 @@
${PN}-tools \
"
- RDEPENDS_${PN}-apps = "\
+ RDEPENDS:${PN}-apps = "\
dropbear \
portmap \
psplash"
- RDEPENDS_${PN}-tools = "\
+ RDEPENDS:${PN}-tools = "\
oprofile \
oprofileui-server \
lttng-tools"
- RRECOMMENDS_${PN}-tools = "\
+ RRECOMMENDS:${PN}-tools = "\
kernel-module-oprofile"
In the previous example, two package group packages are created with
@@ -1013,7 +1022,7 @@
Use the following in a configuration file::
- hostname_pn-base-files = "myhostname"
+ hostname:pn-base-files = "myhostname"
Changing the default value of the variable "hostname" can be useful in
certain situations. For example, suppose you need to do extensive
@@ -1028,7 +1037,7 @@
will have no default hostname in the filesystem. Here is an example that
unsets the variable in a configuration file::
- hostname_pn-base-files = ""
+ hostname:pn-base-files = ""
Having no default hostname in the filesystem is suitable for
environments that use dynamic hostnames such as virtual machines.
@@ -1544,8 +1553,8 @@
name can be found through the
``${``\ :term:`PN`\ ``}`` variable, then
you specify the dependencies for the main package by setting
-``RDEPENDS_${PN}``. If the package were named ``${PN}-tools``, then you
-would set ``RDEPENDS_${PN}-tools``, and so forth.
+``RDEPENDS:${PN}``. If the package were named ``${PN}-tools``, then you
+would set ``RDEPENDS:${PN}-tools``, and so forth.
Some runtime dependencies will be set automatically at packaging time.
These dependencies include any shared library dependencies (i.e. if a
@@ -1796,7 +1805,7 @@
sure the install portion of the build completes with no issues.
However, if you wish to install additional files not already being
installed by ``make install``, you should do this using a
- ``do_install_append`` function using the install command as described
+ ``do_install:append`` function using the install command as described
in the "Manual" bulleted item later in this list.
- *Other (using* ``make install``\ *)*: You need to define a ``do_install``
@@ -1865,9 +1874,9 @@
If you are adding services and the service initialization script or the
service file itself is not installed, you must provide for that
-installation in your recipe using a ``do_install_append`` function. If
+installation in your recipe using a ``do_install:append`` function. If
your recipe already has a ``do_install`` function, update the function
-near its end rather than adding an additional ``do_install_append``
+near its end rather than adding an additional ``do_install:append``
function.
When you create the installation for your services, you need to
@@ -1938,7 +1947,7 @@
discover problems, you can set
:term:`PACKAGES`,
:term:`FILES`,
- ``do_install(_append)``, and so forth as needed.
+ ``do_install(:append)``, and so forth as needed.
- *Splitting an Application into Multiple Packages*: If you need to
split an application into several packages, see the
@@ -2137,7 +2146,7 @@
Post-installation scripts run immediately after installing a package on
the target or during image creation when a package is included in an
image. To add a post-installation script to a package, add a
-``pkg_postinst_``\ `PACKAGENAME`\ ``()`` function to the recipe file
+``pkg_postinst:``\ `PACKAGENAME`\ ``()`` function to the recipe file
(``.bb``) and replace `PACKAGENAME` with the name of the package you want
to attach to the ``postinst`` script. To apply the post-installation
script to the main package for the recipe, which is usually what is
@@ -2147,7 +2156,7 @@
A post-installation function has the following structure::
- pkg_postinst_PACKAGENAME() {
+ pkg_postinst:PACKAGENAME() {
# Commands to carry out
}
@@ -2300,7 +2309,7 @@
path. You can accomplish this by adding to the :term:`CFLAGS` variable. The
following example shows this::
- CFLAGS_prepend = "-I ${S}/include "
+ CFLAGS:prepend = "-I ${S}/include "
In the following example, ``mtd-utils`` is a makefile-based package::
@@ -2330,9 +2339,9 @@
PACKAGES =+ "mtd-utils-jffs2 mtd-utils-ubifs mtd-utils-misc"
- FILES_mtd-utils-jffs2 = "${sbindir}/mkfs.jffs2 ${sbindir}/jffs2dump ${sbindir}/jffs2reader ${sbindir}/sumtool"
- FILES_mtd-utils-ubifs = "${sbindir}/mkfs.ubifs ${sbindir}/ubi*"
- FILES_mtd-utils-misc = "${sbindir}/nftl* ${sbindir}/ftl* ${sbindir}/rfd* ${sbindir}/doc* ${sbindir}/serve_image ${sbindir}/recv_image"
+ FILES:mtd-utils-jffs2 = "${sbindir}/mkfs.jffs2 ${sbindir}/jffs2dump ${sbindir}/jffs2reader ${sbindir}/sumtool"
+ FILES:mtd-utils-ubifs = "${sbindir}/mkfs.ubifs ${sbindir}/ubi*"
+ FILES:mtd-utils-misc = "${sbindir}/nftl* ${sbindir}/ftl* ${sbindir}/rfd* ${sbindir}/doc* ${sbindir}/serve_image ${sbindir}/recv_image"
PARALLEL_MAKE = ""
@@ -2360,14 +2369,14 @@
XORG_PN = "libXpm"
PACKAGES =+ "sxpm cxpm"
- FILES_cxpm = "${bindir}/cxpm"
- FILES_sxpm = "${bindir}/sxpm"
+ FILES:cxpm = "${bindir}/cxpm"
+ FILES:sxpm = "${bindir}/sxpm"
In the previous example, we want to ship the ``sxpm`` and ``cxpm``
binaries in separate packages. Since ``bindir`` would be packaged into
the main :term:`PN` package by default, we prepend the :term:`PACKAGES` variable
so additional package names are added to the start of list. This results
-in the extra ``FILES_*`` variables then containing information that
+in the extra ``FILES:*`` variables then containing information that
define which files and directories go into which packages. Files
included by earlier packages are skipped by latter packages. Thus, the
main :term:`PN` package does not include the above listed files.
@@ -2398,7 +2407,7 @@
from the appropriate area. In particular, this class sets ``noexec`` on
both the :ref:`ref-tasks-configure`
and :ref:`ref-tasks-compile` tasks,
-sets ``FILES_${PN}`` to "/" so that it picks up all files, and sets up a
+sets ``FILES:${PN}`` to "/" so that it picks up all files, and sets up a
:ref:`ref-tasks-install` task, which
effectively copies all files from ``${S}`` to ``${D}``. The
``bin_package`` class works well when the files extracted into ``${S}``
@@ -2459,7 +2468,7 @@
- Ensure that you set up :term:`FILES`
(usually
- ``FILES_${``\ :term:`PN`\ ``}``) to
+ ``FILES:${``\ :term:`PN`\ ``}``) to
point to the files you have installed, which of course depends on
where you have installed them and whether those files are in
different locations than the defaults.
@@ -2504,7 +2513,7 @@
S = "${WORKDIR}/postfix-${PV}"
CFLAGS += "-DNO_ASM"
- SRC_URI_append = " file://fixup.patch"
+ SRC_URI:append = " file://fixup.patch"
- *Functions:* Functions provide a series of actions to be performed.
You usually use functions to override the default implementation of a
@@ -2631,7 +2640,7 @@
VAR =+ "Starts"
-- *Appending (_append):* Use the ``_append`` operator to append values
+- *Appending (:append):* Use the ``:append`` operator to append values
to existing variables. This operator does not add any additional
space. Also, the operator is applied after all the ``+=``, and ``=+``
operators have been applied and after all ``=`` assignments have
@@ -2641,15 +2650,15 @@
start to ensure the appended value is not merged with the existing
value::
- SRC_URI_append = " file://fix-makefile.patch"
+ SRC_URI:append = " file://fix-makefile.patch"
You can also use
- the ``_append`` operator with overrides, which results in the actions
+ the ``:append`` operator with overrides, which results in the actions
only being performed for the specified target or machine::
- SRC_URI_append_sh4 = " file://fix-makefile.patch"
+ SRC_URI:append:sh4 = " file://fix-makefile.patch"
-- *Prepending (_prepend):* Use the ``_prepend`` operator to prepend
+- *Prepending (:prepend):* Use the ``:prepend`` operator to prepend
values to existing variables. This operator does not add any
additional space. Also, the operator is applied after all the ``+=``,
and ``=+`` operators have been applied and after all ``=``
@@ -2659,13 +2668,13 @@
end to ensure the prepended value is not merged with the existing
value::
- CFLAGS_prepend = "-I${S}/myincludes "
+ CFLAGS:prepend = "-I${S}/myincludes "
You can also use the
- ``_prepend`` operator with overrides, which results in the actions
+ ``:prepend`` operator with overrides, which results in the actions
only being performed for the specified target or machine::
- CFLAGS_prepend_sh4 = "-I${S}/myincludes "
+ CFLAGS:prepend:sh4 = "-I${S}/myincludes "
- *Overrides:* You can use overrides to set a value conditionally,
typically based on how the recipe is being built. For example, to set
@@ -2676,7 +2685,7 @@
you would do the following::
KBRANCH = "standard/base"
- KBRANCH_qemuarm = "standard/arm-versatile-926ejs"
+ KBRANCH:qemuarm = "standard/arm-versatile-926ejs"
Overrides are also used to separate
alternate values of a variable in other situations. For example, when
@@ -2951,7 +2960,7 @@
If your distro does not enable by default ptest, which Poky
does, you need the following in your ``local.conf`` file::
- DISTRO_FEATURES_append = " ptest"
+ DISTRO_FEATURES:append = " ptest"
6. *Optionally Start a vncserver:* If you are running in a server
@@ -4301,7 +4310,7 @@
your ``local.conf`` file::
INHERIT += "externalsrc"
- EXTERNALSRC_pn-myrecipe = "path-to-your-source-tree"
+ EXTERNALSRC:pn-myrecipe = "path-to-your-source-tree"
This next example shows how to accomplish the same thing by setting
:term:`EXTERNALSRC` in the recipe itself or in the recipe's append file::
@@ -4323,7 +4332,7 @@
:term:`EXTERNALSRC_BUILD`
to point to that directory::
- EXTERNALSRC_BUILD_pn-myrecipe = "path-to-your-source-tree"
+ EXTERNALSRC_BUILD:pn-myrecipe = "path-to-your-source-tree"
Replicating a Build Offline
---------------------------
@@ -4538,7 +4547,7 @@
exceptions::
STATICLIBCONF = "--disable-static"
- STATICLIBCONF_sqlite3-native = ""
+ STATICLIBCONF:sqlite3-native = ""
EXTRA_OECONF += "${STATICLIBCONF}"
.. note::
@@ -4578,7 +4587,7 @@
the built library.
The :term:`PACKAGES` and
-:term:`FILES_* <FILES>` variables in the
+:term:`FILES:* <FILES>` variables in the
``meta/conf/bitbake.conf`` configuration file define how files installed
by the ``do_install`` task are packaged. By default, the :term:`PACKAGES`
variable includes ``${PN}-staticdev``, which represents all static
@@ -4597,7 +4606,7 @@
PACKAGES_DYNAMIC = "^${PN}-locale-.*"
FILES = ""
- FILES_${PN} = "${bindir}/* ${sbindir}/* ${libexecdir}/* ${libdir}/lib*${SOLIBS} \
+ FILES:${PN} = "${bindir}/* ${sbindir}/* ${libexecdir}/* ${libdir}/lib*${SOLIBS} \
${sysconfdir} ${sharedstatedir} ${localstatedir} \
${base_bindir}/* ${base_sbindir}/* \
${base_libdir}/*${SOLIBS} \
@@ -4607,24 +4616,24 @@
${datadir}/idl ${datadir}/omf ${datadir}/sounds \
${libdir}/bonobo/servers"
- FILES_${PN}-bin = "${bindir}/* ${sbindir}/*"
+ FILES:${PN}-bin = "${bindir}/* ${sbindir}/*"
- FILES_${PN}-doc = "${docdir} ${mandir} ${infodir} ${datadir}/gtk-doc \
+ FILES:${PN}-doc = "${docdir} ${mandir} ${infodir} ${datadir}/gtk-doc \
${datadir}/gnome/help"
- SECTION_${PN}-doc = "doc"
+ SECTION:${PN}-doc = "doc"
FILES_SOLIBSDEV ?= "${base_libdir}/lib*${SOLIBSDEV} ${libdir}/lib*${SOLIBSDEV}"
- FILES_${PN}-dev = "${includedir} ${FILES_SOLIBSDEV} ${libdir}/*.la \
+ FILES:${PN}-dev = "${includedir} ${FILES_SOLIBSDEV} ${libdir}/*.la \
${libdir}/*.o ${libdir}/pkgconfig ${datadir}/pkgconfig \
${datadir}/aclocal ${base_libdir}/*.o \
${libdir}/${BPN}/*.la ${base_libdir}/*.la"
- SECTION_${PN}-dev = "devel"
- ALLOW_EMPTY_${PN}-dev = "1"
- RDEPENDS_${PN}-dev = "${PN} (= ${EXTENDPKGV})"
+ SECTION:${PN}-dev = "devel"
+ ALLOW_EMPTY:${PN}-dev = "1"
+ RDEPENDS:${PN}-dev = "${PN} (= ${EXTENDPKGV})"
- FILES_${PN}-staticdev = "${libdir}/*.a ${base_libdir}/*.a ${libdir}/${BPN}/*.a"
- SECTION_${PN}-staticdev = "devel"
- RDEPENDS_${PN}-staticdev = "${PN}-dev (= ${EXTENDPKGV})"
+ FILES:${PN}-staticdev = "${libdir}/*.a ${base_libdir}/*.a ${libdir}/${BPN}/*.a"
+ SECTION:${PN}-staticdev = "devel"
+ RDEPENDS:${PN}-staticdev = "${PN}-dev (= ${EXTENDPKGV})"
Combining Multiple Versions of Library Files into One Image
-----------------------------------------------------------
@@ -4701,8 +4710,8 @@
MACHINE = "qemux86-64"
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
- DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
- IMAGE_INSTALL_append = "lib32-glib-2.0"
+ DEFAULTTUNE:virtclass-multilib-lib32 = "x86"
+ IMAGE_INSTALL:append = "lib32-glib-2.0"
This example enables an additional library named
``lib32`` alongside the normal target packages. When combining these
@@ -4749,7 +4758,7 @@
:term:`Build Directory`. For
example, consider ``lib32`` in a ``qemux86-64`` image. The possible
architectures in the system are "all", "qemux86_64",
- "lib32_qemux86_64", and "lib32_x86".
+ "lib32:qemux86_64", and "lib32:x86".
- The ``${MLPREFIX}`` variable is stripped from ``${PN}`` during RPM
packaging. The naming for a normal RPM package and a Multilib RPM
@@ -4768,7 +4777,7 @@
- The ``${MLPREFIX}`` is not stripped from ``${PN}`` during IPK
packaging. The naming for a normal RPM package and a Multilib IPK
package in a ``qemux86-64`` system resolves to something like
- ``bash_4.1-r2.x86_64.ipk`` and ``lib32-bash_4.1-rw_x86.ipk``,
+ ``bash_4.1-r2.x86_64.ipk`` and ``lib32-bash_4.1-rw:x86.ipk``,
respectively.
- The IPK deploy folder is not modified with ``${MLPREFIX}`` because
@@ -4857,7 +4866,7 @@
MACHINE = "qemux86-64"
DEFAULTTUNE = "x86-64-x32"
- baselib = "${@d.getVar('BASE_LIB_tune-' + (d.getVar('DEFAULTTUNE') \
+ baselib = "${@d.getVar('BASE_LIB:tune-' + (d.getVar('DEFAULTTUNE') \
or 'INVALID')) or 'lib'}"
Once you have set
@@ -6085,7 +6094,7 @@
- Add a ``psplash`` append file for a branded splash screen. For
information on append files, see the
- ":ref:`dev-manual/common-tasks:using .bbappend files in your layer`"
+ ":ref:`dev-manual/common-tasks:appending other layers metadata with your layer`"
section.
- Add any other append files to make custom changes that are
@@ -6510,11 +6519,11 @@
a pattern of files or directories under a specified path and creates a
package for each one it finds by appending to the
:term:`PACKAGES` variable and
-setting the appropriate values for ``FILES_packagename``,
-``RDEPENDS_packagename``, ``DESCRIPTION_packagename``, and so forth.
+setting the appropriate values for ``FILES:packagename``,
+``RDEPENDS:packagename``, ``DESCRIPTION:packagename``, and so forth.
Here is an example from the ``lighttpd`` recipe::
- python populate_packages_prepend () {
+ python populate_packages:prepend () {
lighttpd_libdir = d.expand('${libdir}')
do_split_packages(d, lighttpd_libdir, '^mod_(.*).so$',
'lighttpd-module-%s', 'Lighttpd module for %s',
@@ -6618,7 +6627,7 @@
instead of the default False which appends them
match_path
match file_regex on the whole relative path to
- the root rather than just the file name
+ the root rather than just the filename
aux_files_pattern_verbatim
Extra item(s) to be added to FILES for each
package, using the actual derived module name
@@ -7101,7 +7110,7 @@
variables to your ``local.conf`` file, which is found in the
:term:`Build Directory`::
- DISTRO_FEATURES_append = " ptest"
+ DISTRO_FEATURES:append = " ptest"
EXTRA_IMAGE_FEATURES += "ptest-pkgs"
Once your build is complete, the ptest files are installed into the
@@ -7145,7 +7154,7 @@
your recipe in order for the package to meet the dependencies. Here
is an example where the package has a runtime dependency on "make"::
- RDEPENDS_${PN}-ptest += "make"
+ RDEPENDS:${PN}-ptest += "make"
- *Add a function to build the test suite:* Not many packages support
cross-compilation of their test suites. Consequently, you usually
@@ -7289,11 +7298,11 @@
"
S = "${WORKDIR}/npm"
inherit npm
- LICENSE_${PN} = "MIT"
- LICENSE_${PN}-accepts = "MIT"
- LICENSE_${PN}-array-flatten = "MIT"
+ LICENSE:${PN} = "MIT"
+ LICENSE:${PN}-accepts = "MIT"
+ LICENSE:${PN}-array-flatten = "MIT"
...
- LICENSE_${PN}-vary = "MIT"
+ LICENSE:${PN}-vary = "MIT"
Here are three key points in the previous example:
@@ -7389,11 +7398,11 @@
set it for a specific package type and/or package. Note that the order
of precedence is the same as this list:
-- ``PACKAGE_ADD_METADATA_<PKGTYPE>_<PN>``
+- ``PACKAGE_ADD_METADATA_<PKGTYPE>:<PN>``
- ``PACKAGE_ADD_METADATA_<PKGTYPE>``
-- ``PACKAGE_ADD_METADATA_<PN>``
+- ``PACKAGE_ADD_METADATA:<PN>``
- :term:`PACKAGE_ADD_METADATA`
@@ -7523,7 +7532,7 @@
Set these variables in your distribution configuration file as follows::
- DISTRO_FEATURES_append = " systemd"
+ DISTRO_FEATURES:append = " systemd"
VIRTUAL-RUNTIME_init_manager = "systemd"
You can also prevent the SysVinit distribution feature from
@@ -7547,7 +7556,7 @@
Set these variables in your distribution configuration file as follows::
- DISTRO_FEATURES_append = " systemd"
+ DISTRO_FEATURES:append = " systemd"
VIRTUAL-RUNTIME_init_manager = "systemd"
Doing so causes your main image to use the
@@ -7646,7 +7655,7 @@
Then, you can add the following to your
``local.conf``::
- SRCREV_pn-PN = "${AUTOREV}"
+ SRCREV:pn-PN = "${AUTOREV}"
:term:`PN` is the name of the recipe for
which you want to enable automatic source revision updating.
@@ -7664,22 +7673,22 @@
This line pulls in the
listed include file that contains numerous lines of exactly that form::
- #SRCREV_pn-opkg-native ?= "${AUTOREV}"
- #SRCREV_pn-opkg-sdk ?= "${AUTOREV}"
- #SRCREV_pn-opkg ?= "${AUTOREV}"
- #SRCREV_pn-opkg-utils-native ?= "${AUTOREV}"
- #SRCREV_pn-opkg-utils ?= "${AUTOREV}"
- SRCREV_pn-gconf-dbus ?= "${AUTOREV}"
- SRCREV_pn-matchbox-common ?= "${AUTOREV}"
- SRCREV_pn-matchbox-config-gtk ?= "${AUTOREV}"
- SRCREV_pn-matchbox-desktop ?= "${AUTOREV}"
- SRCREV_pn-matchbox-keyboard ?= "${AUTOREV}"
- SRCREV_pn-matchbox-panel-2 ?= "${AUTOREV}"
- SRCREV_pn-matchbox-themes-extra ?= "${AUTOREV}"
- SRCREV_pn-matchbox-terminal ?= "${AUTOREV}"
- SRCREV_pn-matchbox-wm ?= "${AUTOREV}"
- SRCREV_pn-settings-daemon ?= "${AUTOREV}"
- SRCREV_pn-screenshot ?= "${AUTOREV}"
+ #SRCREV:pn-opkg-native ?= "${AUTOREV}"
+ #SRCREV:pn-opkg-sdk ?= "${AUTOREV}"
+ #SRCREV:pn-opkg ?= "${AUTOREV}"
+ #SRCREV:pn-opkg-utils-native ?= "${AUTOREV}"
+ #SRCREV:pn-opkg-utils ?= "${AUTOREV}"
+ SRCREV:pn-gconf-dbus ?= "${AUTOREV}"
+ SRCREV:pn-matchbox-common ?= "${AUTOREV}"
+ SRCREV:pn-matchbox-config-gtk ?= "${AUTOREV}"
+ SRCREV:pn-matchbox-desktop ?= "${AUTOREV}"
+ SRCREV:pn-matchbox-keyboard ?= "${AUTOREV}"
+ SRCREV:pn-matchbox-panel-2 ?= "${AUTOREV}"
+ SRCREV:pn-matchbox-themes-extra ?= "${AUTOREV}"
+ SRCREV:pn-matchbox-terminal ?= "${AUTOREV}"
+ SRCREV:pn-matchbox-wm ?= "${AUTOREV}"
+ SRCREV:pn-settings-daemon ?= "${AUTOREV}"
+ SRCREV:pn-screenshot ?= "${AUTOREV}"
. . .
These lines allow you to
@@ -7737,9 +7746,9 @@
(``pkg_postinst``) scripts for packages that are installed into the
image can be run at the time when the root filesystem is created during
the build on the host system. These scripts cannot attempt to run during
-first-boot on the target device. With the "read-only-rootfs" feature
-enabled, the build system checks during root filesystem creation to make
-sure all post-installation scripts succeed. If any of these scripts
+the first boot on the target device. With the "read-only-rootfs" feature
+enabled, the build system makes sure that all post-installation scripts
+succeed at file system creation time. If any of these scripts
still need to be run after the root filesystem is created, the build
immediately fails. These build-time checks ensure that the build fails
rather than the target device fails later during its initial boot
@@ -7922,25 +7931,25 @@
$ buildhistory-collect-srcrevs -a
# i586-poky-linux
- SRCREV_pn-glibc = "b8079dd0d360648e4e8de48656c5c38972621072"
- SRCREV_pn-glibc-initial = "b8079dd0d360648e4e8de48656c5c38972621072"
- SRCREV_pn-opkg-utils = "53274f087565fd45d8452c5367997ba6a682a37a"
- SRCREV_pn-kmod = "fd56638aed3fe147015bfa10ed4a5f7491303cb4"
+ SRCREV:pn-glibc = "b8079dd0d360648e4e8de48656c5c38972621072"
+ SRCREV:pn-glibc-initial = "b8079dd0d360648e4e8de48656c5c38972621072"
+ SRCREV:pn-opkg-utils = "53274f087565fd45d8452c5367997ba6a682a37a"
+ SRCREV:pn-kmod = "fd56638aed3fe147015bfa10ed4a5f7491303cb4"
# x86_64-linux
- SRCREV_pn-gtk-doc-stub-native = "1dea266593edb766d6d898c79451ef193eb17cfa"
- SRCREV_pn-dtc-native = "65cc4d2748a2c2e6f27f1cf39e07a5dbabd80ebf"
- SRCREV_pn-update-rc.d-native = "eca680ddf28d024954895f59a241a622dd575c11"
- SRCREV_glibc_pn-cross-localedef-native = "b8079dd0d360648e4e8de48656c5c38972621072"
- SRCREV_localedef_pn-cross-localedef-native = "c833367348d39dad7ba018990bfdaffaec8e9ed3"
- SRCREV_pn-prelink-native = "faa069deec99bf61418d0bab831c83d7c1b797ca"
- SRCREV_pn-opkg-utils-native = "53274f087565fd45d8452c5367997ba6a682a37a"
- SRCREV_pn-kern-tools-native = "23345b8846fe4bd167efdf1bd8a1224b2ba9a5ff"
- SRCREV_pn-kmod-native = "fd56638aed3fe147015bfa10ed4a5f7491303cb4"
+ SRCREV:pn-gtk-doc-stub-native = "1dea266593edb766d6d898c79451ef193eb17cfa"
+ SRCREV:pn-dtc-native = "65cc4d2748a2c2e6f27f1cf39e07a5dbabd80ebf"
+ SRCREV:pn-update-rc.d-native = "eca680ddf28d024954895f59a241a622dd575c11"
+ SRCREV_glibc:pn-cross-localedef-native = "b8079dd0d360648e4e8de48656c5c38972621072"
+ SRCREV_localedef:pn-cross-localedef-native = "c833367348d39dad7ba018990bfdaffaec8e9ed3"
+ SRCREV:pn-prelink-native = "faa069deec99bf61418d0bab831c83d7c1b797ca"
+ SRCREV:pn-opkg-utils-native = "53274f087565fd45d8452c5367997ba6a682a37a"
+ SRCREV:pn-kern-tools-native = "23345b8846fe4bd167efdf1bd8a1224b2ba9a5ff"
+ SRCREV:pn-kmod-native = "fd56638aed3fe147015bfa10ed4a5f7491303cb4"
# qemux86-poky-linux
- SRCREV_machine_pn-linux-yocto = "38cd560d5022ed2dbd1ab0dca9642e47c98a0aa1"
- SRCREV_meta_pn-linux-yocto = "a227f20eff056e511d504b2e490f3774ab260d6f"
+ SRCREV_machine:pn-linux-yocto = "38cd560d5022ed2dbd1ab0dca9642e47c98a0aa1"
+ SRCREV_meta:pn-linux-yocto = "a227f20eff056e511d504b2e490f3774ab260d6f"
# all-poky-linux
- SRCREV_pn-update-rc.d = "eca680ddf28d024954895f59a241a622dd575c11"
+ SRCREV:pn-update-rc.d = "eca680ddf28d024954895f59a241a622dd575c11"
.. note::
@@ -8564,11 +8573,11 @@
- The default tests for the image are defined as::
- DEFAULT_TEST_SUITES_pn-image = "ping ssh df connman syslog xorg scp vnc date rpm dnf dmesg"
+ DEFAULT_TEST_SUITES:pn-image = "ping ssh df connman syslog xorg scp vnc date rpm dnf dmesg"
- Add your own test to the list of the by using the following::
- TEST_SUITES_append = " mytest"
+ TEST_SUITES:append = " mytest"
- Run a specific list of tests as follows::
@@ -8941,7 +8950,7 @@
- After the variable values, all functions appear in the output. For
shell functions, variables referenced within the function body are
expanded. If a function has been modified using overrides or using
- override-style operators like ``_append`` and ``_prepend``, then the
+ override-style operators like ``:append`` and ``:prepend``, then the
final assembled function body appears in the output.
Viewing Package Information with ``oe-pkgdata-util``
@@ -9715,7 +9724,7 @@
(it already is in ``OpenEmbedded-core`` defaults and ``poky`` reference distribution).
If not, set in your distro config file or in ``local.conf``::
- DISTRO_FEATURES_append = " debuginfod"
+ DISTRO_FEATURES:append = " debuginfod"
This distro feature enables the server and client library in ``elfutils``,
and enables ``debuginfod`` support in clients (at the moment, ``gdb`` and ``binutils``).
@@ -9802,7 +9811,7 @@
Make the following addition in either your ``local.conf`` file or in
an image recipe::
- IMAGE_INSTALL_append = " gdbserver"
+ IMAGE_INSTALL:append = " gdbserver"
The change makes
sure the ``gdbserver`` package is included.
@@ -9938,21 +9947,21 @@
- Ensure that GDB is on the target. You can do this by adding "gdb" to
:term:`IMAGE_INSTALL`::
- IMAGE_INSTALL_append = " gdb"
+ IMAGE_INSTALL:append = " gdb"
Alternatively, you can add "tools-debug" to :term:`IMAGE_FEATURES`::
- IMAGE_FEATURES_append = " tools-debug"
+ IMAGE_FEATURES:append = " tools-debug"
- Ensure that debug symbols are present. You can make sure these
symbols are present by installing ``-dbg``::
- IMAGE_INSTALL_append = "packagename-dbg"
+ IMAGE_INSTALL:append = "packagename-dbg"
Alternatively, you can do the following to include
all the debug symbols::
- IMAGE_FEATURES_append = " dbg-pkgs"
+ IMAGE_FEATURES:append = " dbg-pkgs"
.. note::
@@ -11131,6 +11140,75 @@
The :term:`CVE_PRODUCT` variable defines the name used to match the recipe name
against the name in the upstream `NIST CVE database <https://nvd.nist.gov/>`__.
+Editing recipes to fix vulnerabilities
+--------------------------------------
+
+To fix a given known vulnerability, you need to add a patch file to your recipe. Here's
+an example from the :oe_layerindex:`ffmpeg recipe</layerindex/recipe/47350>`::
+
+ SRC_URI = "https://www.ffmpeg.org/releases/${BP}.tar.xz \
+ file://0001-libavutil-include-assembly-with-full-path-from-sourc.patch \
+ file://fix-CVE-2020-20446.patch \
+ file://fix-CVE-2020-20453.patch \
+ file://fix-CVE-2020-22015.patch \
+ file://fix-CVE-2020-22021.patch \
+ file://fix-CVE-2020-22033-CVE-2020-22019.patch \
+ file://fix-CVE-2021-33815.patch \
+
+The :ref:`cve-check <ref-classes-cve-check>` class defines two ways of
+supplying a patch for a given CVE. The first
+way is to use a patch filename that matches the below pattern::
+
+ cve_file_name_match = re.compile(".*([Cc][Vv][Ee]\-\d{4}\-\d+)")
+
+As shown in the example above, multiple CVE IDs can appear in a patch filename,
+but the :ref:`cve-check <ref-classes-cve-check>` class will only consider
+the last CVE ID in the filename as patched.
+
+The second way to recognize a patched CVE ID is when a line matching the
+below pattern is found in any patch file provided by the recipe::
+
+ cve_match = re.compile("CVE:( CVE\-\d{4}\-\d+)+")
+
+This allows a single patch file to address multiple CVE IDs at the same time.
+
+Of course, another way to fix vulnerabilities is to upgrade to a version
+of the package which is not impacted, typically a more recent one.
+The NIST database knows which versions are vulnerable and which ones
+are not.
+
+Last but not least, you can choose to ignore vulnerabilities through
+the :term:`CVE_CHECK_PN_WHITELIST` and :term:`CVE_CHECK_WHITELIST`
+variables.
+
+Implementation details
+----------------------
+
+Here's what the :ref:`cve-check <ref-classes-cve-check>` class does to
+find unpatched CVE IDs.
+
+First the code goes through each patch file provided by a recipe. If a valid CVE ID
+is found in the name of the file, the corresponding CVE is considered as patched.
+Don't forget that if multiple CVE IDs are found in the filename, only the last
+one is considered. Then, the code looks for ``CVE: CVE-ID`` lines in the patch
+file. The found CVE IDs are also considered as patched.
+
+Then, the code looks up all the CVE IDs in the NIST database for all the
+products defined in :term:`CVE_PRODUCT`. Then, for each found CVE:
+
+ - If the package name (:term:`PN`) is part of
+ :term:`CVE_CHECK_PN_WHITELIST`, it is considered as patched.
+
+ - If the CVE ID is part of :term:`CVE_CHECK_WHITELIST`, it is
+ considered as patched too.
+
+ - If the CVE ID is part of the patched CVE for the recipe, it is
+ already considered as patched.
+
+ - Otherwise, the code checks whether the recipe version (:term:`PV`)
+ is within the range of versions impacted by the CVE. If so, the CVE
+ is considered as unpatched.
+
The CVE database is stored in :term:`DL_DIR` and can be inspected using
``sqlite3`` command as follows::
@@ -11274,7 +11352,7 @@
:term:`DISTRO_FEATURES`
statement in your ``local.conf`` file::
- DISTRO_FEATURES_append = " wayland"
+ DISTRO_FEATURES:append = " wayland"
.. note::
diff --git a/poky/documentation/kernel-dev/advanced.rst b/poky/documentation/kernel-dev/advanced.rst
index 871ec8a..2dbcca6 100644
--- a/poky/documentation/kernel-dev/advanced.rst
+++ b/poky/documentation/kernel-dev/advanced.rst
@@ -69,7 +69,7 @@
You can use the :term:`KBRANCH` value to define an alternate branch typically
with a machine override as shown here from the ``meta-yocto-bsp`` layer::
- KBRANCH_edgerouter = "standard/edgerouter"
+ KBRANCH:edgerouter = "standard/edgerouter"
The linux-yocto style recipes can optionally define the following
@@ -113,7 +113,7 @@
feature called "cfg/sound.scc" just for the ``qemux86`` machine,
specify::
- KERNEL_FEATURES_append_qemux86 = " cfg/sound.scc"
+ KERNEL_FEATURES:append:qemux86 = " cfg/sound.scc"
The value of
the entries in :term:`KERNEL_FEATURES` are dependent on their location
@@ -724,7 +724,7 @@
``*.scc`` in the :term:`SRC_URI` statement. You need to use the following
form from your kernel append file::
- SRC_URI_append_myplatform = " \
+ SRC_URI:append:myplatform = " \
file://myplatform;type=kmeta;destsuffix=myplatform \
"
diff --git a/poky/documentation/kernel-dev/common.rst b/poky/documentation/kernel-dev/common.rst
index a97140b..d42ca5f 100644
--- a/poky/documentation/kernel-dev/common.rst
+++ b/poky/documentation/kernel-dev/common.rst
@@ -416,16 +416,16 @@
kernel. Thus, the name of the append file is
``linux-yocto_4.12.bbappend``::
- FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+ FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:"
- SRC_URI_append = " file://patch-file-one.patch"
- SRC_URI_append = " file://patch-file-two.patch"
- SRC_URI_append = " file://patch-file-three.patch"
+ SRC_URI:append = " file://patch-file-one.patch"
+ SRC_URI:append = " file://patch-file-two.patch"
+ SRC_URI:append = " file://patch-file-three.patch"
The :term:`FILESEXTRAPATHS` and :term:`SRC_URI` statements
enable the OpenEmbedded build system to find patch files. For more
information on using append files, see the
- ":ref:`dev-manual/common-tasks:using .bbappend files in your layer`"
+ ":ref:`dev-manual/common-tasks:appending other layers metadata with your layer`"
section in the Yocto Project Development Tasks Manual.
Modifying an Existing Recipe
@@ -469,7 +469,7 @@
:term:`FILESEXTRAPATHS`
variable as follows::
- FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+ FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:"
The path ``${``\ :term:`THISDIR`\ ``}/${``\ :term:`PN`\ ``}``
expands to "linux-yocto" in the current directory for this example. If
@@ -496,29 +496,29 @@
strings in the file from the ``meta-yocto-bsp`` layer upstream.
::
- KBRANCH_genericx86 = "standard/base"
- KBRANCH_genericx86-64 = "standard/base"
+ KBRANCH:genericx86 = "standard/base"
+ KBRANCH:genericx86-64 = "standard/base"
- KMACHINE_genericx86 ?= "common-pc"
- KMACHINE_genericx86-64 ?= "common-pc-64"
- KBRANCH_edgerouter = "standard/edgerouter"
- KBRANCH_beaglebone = "standard/beaglebone"
+ KMACHINE:genericx86 ?= "common-pc"
+ KMACHINE:genericx86-64 ?= "common-pc-64"
+ KBRANCH:edgerouter = "standard/edgerouter"
+ KBRANCH:beaglebone = "standard/beaglebone"
- SRCREV_machine_genericx86 ?= "d09f2ce584d60ecb7890550c22a80c48b83c2e19"
- SRCREV_machine_genericx86-64 ?= "d09f2ce584d60ecb7890550c22a80c48b83c2e19"
- SRCREV_machine_edgerouter ?= "b5c8cfda2dfe296410d51e131289fb09c69e1e7d"
- SRCREV_machine_beaglebone ?= "b5c8cfda2dfe296410d51e131289fb09c69e1e7d"
+ SRCREV_machine:genericx86 ?= "d09f2ce584d60ecb7890550c22a80c48b83c2e19"
+ SRCREV_machine:genericx86-64 ?= "d09f2ce584d60ecb7890550c22a80c48b83c2e19"
+ SRCREV_machine:edgerouter ?= "b5c8cfda2dfe296410d51e131289fb09c69e1e7d"
+ SRCREV_machine:beaglebone ?= "b5c8cfda2dfe296410d51e131289fb09c69e1e7d"
- COMPATIBLE_MACHINE_genericx86 = "genericx86"
- COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64"
- COMPATIBLE_MACHINE_edgerouter = "edgerouter"
- COMPATIBLE_MACHINE_beaglebone = "beaglebone"
+ COMPATIBLE_MACHINE:genericx86 = "genericx86"
+ COMPATIBLE_MACHINE:genericx86-64 = "genericx86-64"
+ COMPATIBLE_MACHINE:edgerouter = "edgerouter"
+ COMPATIBLE_MACHINE:beaglebone = "beaglebone"
- LINUX_VERSION_genericx86 = "4.12.7"
- LINUX_VERSION_genericx86-64 = "4.12.7"
- LINUX_VERSION_edgerouter = "4.12.10"
- LINUX_VERSION_beaglebone = "4.12.10"
+ LINUX_VERSION:genericx86 = "4.12.7"
+ LINUX_VERSION:genericx86-64 = "4.12.7"
+ LINUX_VERSION:edgerouter = "4.12.10"
+ LINUX_VERSION:beaglebone = "4.12.10"
This append file
contains statements used to support several BSPs that ship with the
@@ -640,7 +640,7 @@
directory, and rename the copied file to "defconfig". Then, add the
following lines to the linux-yocto ``.bbappend`` file in your layer::
- FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+ FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:"
SRC_URI += "file://defconfig"
The :term:`SRC_URI` tells the build system how to search
@@ -687,7 +687,7 @@
configuration fragment and extend the :term:`FILESPATH` variable in your
``.bbappend`` file::
- FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+ FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:"
SRC_URI += "file://8250.cfg"
The next time you run BitBake to build the
@@ -726,7 +726,7 @@
and provides the path to the "in-tree" ``defconfig`` file to be used for
a Raspberry Pi 2, which is based on the Broadcom 2708/2709 chipset::
- KBUILD_DEFCONFIG_raspberrypi2 ?= "bcm2709_defconfig"
+ KBUILD_DEFCONFIG:raspberrypi2 ?= "bcm2709_defconfig"
Aside from modifying your kernel recipe and providing your own
``defconfig`` file, you need to be sure no files or statements set
@@ -988,10 +988,10 @@
Add the following to the ``local.conf``::
- SRC_URI_pn-linux-yocto = "git:///path-to/linux-yocto-4.12;protocol=file;name=machine;branch=standard/base; \
+ SRC_URI:pn-linux-yocto = "git:///path-to/linux-yocto-4.12;protocol=file;name=machine;branch=standard/base; \
git:///path-to/yocto-kernel-cache;protocol=file;type=kmeta;name=meta;branch=yocto-4.12;destsuffix=${KMETA}"
- SRCREV_meta_qemux86 = "${AUTOREV}"
- SRCREV_machine_qemux86 = "${AUTOREV}"
+ SRCREV_meta:qemux86 = "${AUTOREV}"
+ SRCREV_machine:qemux86 = "${AUTOREV}"
.. note::
@@ -1061,8 +1061,8 @@
must be named ``linux-yocto_4.12.bbappend`` and have the following
contents::
- FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
- SRC_URI_append = "file://0001-calibrate.c-Added-some-printk-statements.patch"
+ FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:"
+ SRC_URI:append = "file://0001-calibrate.c-Added-some-printk-statements.patch"
The :term:`FILESEXTRAPATHS` and :term:`SRC_URI` statements
enable the OpenEmbedded build system to find the patch file.
@@ -1070,7 +1070,7 @@
For more information on append files and patches, see the
":ref:`kernel-dev/common:creating the append file`" and
":ref:`kernel-dev/common:applying patches`" sections. You can also see the
- ":ref:`dev-manual/common-tasks:using .bbappend files in your layer`"
+ ":ref:`dev-manual/common-tasks:appending other layers metadata with your layer`"
section in the Yocto Project Development Tasks Manual.
.. note::
@@ -1237,7 +1237,7 @@
add the following lines to the linux-yocto ``.bbappend`` file in your
layer::
- FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+ FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:"
SRC_URI += "file://defconfig"
The :term:`SRC_URI` tells the build system how to search for the file, while the
@@ -1345,7 +1345,7 @@
statements to the kernel's append file, those configuration options will
be picked up and applied when the kernel is built::
- FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+ FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:"
SRC_URI += "file://myconfig.cfg"
As mentioned earlier, you can group related configurations into multiple
@@ -1939,7 +1939,7 @@
2. *Add the Feature File to SRC_URI:* Add the ``.scc`` file to the
recipe's :term:`SRC_URI` statement::
- SRC_URI_append = " file://test.scc"
+ SRC_URI:append = " file://test.scc"
The leading space before the path is important as the path is
appended to the existing path.
@@ -1948,7 +1948,7 @@
:term:`KERNEL_FEATURES` statement to specify the feature as a kernel
feature::
- KERNEL_FEATURES_append = " test.scc"
+ KERNEL_FEATURES:append = " test.scc"
The OpenEmbedded build
system processes the kernel feature when it builds the kernel.
diff --git a/poky/documentation/kernel-dev/faq.rst b/poky/documentation/kernel-dev/faq.rst
index f0a7af3..5aa702a 100644
--- a/poky/documentation/kernel-dev/faq.rst
+++ b/poky/documentation/kernel-dev/faq.rst
@@ -36,9 +36,9 @@
The kernel image (e.g. ``vmlinuz``) is provided by the
``kernel-image`` package. Image recipes depend on ``kernel-base``. To
specify whether or not the kernel image is installed in the generated
-root filesystem, override ``RDEPENDS_${KERNEL_PACKAGE_NAME}-base`` to include or not
+root filesystem, override ``RDEPENDS:${KERNEL_PACKAGE_NAME}-base`` to include or not
include "kernel-image". See the
-":ref:`dev-manual/common-tasks:using .bbappend files in your layer`"
+":ref:`dev-manual/common-tasks:appending other layers metadata with your layer`"
section in the
Yocto Project Development Tasks Manual for information on how to use an
append file to override metadata.
diff --git a/poky/documentation/migration-guides/migration-1.4.rst b/poky/documentation/migration-guides/migration-1.4.rst
index 3f98091..baf3c08 100644
--- a/poky/documentation/migration-guides/migration-1.4.rst
+++ b/poky/documentation/migration-guides/migration-1.4.rst
@@ -83,7 +83,7 @@
you can find in the :term:`Source Directory` at
``meta/recipes-core/init-ifupdown``. For information on how to use
append files, see the
-":ref:`dev-manual/common-tasks:using .bbappend files in your layer`"
+":ref:`dev-manual/common-tasks:appending other layers metadata with your layer`"
section in the Yocto Project Development Tasks Manual.
.. _migration-1.4-remote-debugging:
diff --git a/poky/documentation/migration-guides/migration-1.5.rst b/poky/documentation/migration-guides/migration-1.5.rst
index e1ba4a9..11c8212 100644
--- a/poky/documentation/migration-guides/migration-1.5.rst
+++ b/poky/documentation/migration-guides/migration-1.5.rst
@@ -144,7 +144,7 @@
BitBake will now shorten revisions from Git repositories from the normal
40 characters down to 10 characters within :term:`SRCPV`
-for improved usability in path and file names. This change should be
+for improved usability in path and filenames. This change should be
safe within contexts where these revisions are used because the chances
of spatially close collisions is very low. Distant collisions are not a
major issue in the way the values are used.
diff --git a/poky/documentation/migration-guides/migration-3.4.rst b/poky/documentation/migration-guides/migration-3.4.rst
index 6fa1ab2..e83e936 100644
--- a/poky/documentation/migration-guides/migration-3.4.rst
+++ b/poky/documentation/migration-guides/migration-3.4.rst
@@ -56,6 +56,13 @@
case where some code does use them as overrides but some does not. We plan to try
and make the tune code use overrides more consistently in the future.
+There are some variables which do not use override syntax which include the
+suffix to variables in ``layer.conf`` files such as :term:`BBFILE_PATTERN`,
+:term:`SRCREV`\ ``_xxx`` where ``xxx`` is a name from :term:`SRC_URI` and
+:term:`PREFERRED_VERSION`\ ``_xxx``. In particular, ``layer.conf`` suffixes
+may be the same as a :term:`DISTRO` override causing some confusion. We do
+plan to try and improve consistency as these issues are identified.
+
To help with migration of layers there is a script in OE-Core. Once configured
with the overrides used by a layer, this can be run as::
diff --git a/poky/documentation/overview-manual/concepts.rst b/poky/documentation/overview-manual/concepts.rst
index 4f8e6cb..c8b8988 100644
--- a/poky/documentation/overview-manual/concepts.rst
+++ b/poky/documentation/overview-manual/concepts.rst
@@ -1768,15 +1768,12 @@
generators is to make some dependency and hash information available to
the build. This information includes:
-- ``BB_BASEHASH_task-``\ taskname: The base hashes for each task in the
+- ``BB_BASEHASH:task-``\ taskname: The base hashes for each task in the
recipe.
- ``BB_BASEHASH_``\ filename\ ``:``\ taskname: The base hashes for each
dependent task.
-- ``BBHASHDEPS_``\ filename\ ``:``\ taskname: The task dependencies for
- each task.
-
- :term:`BB_TASKHASH`: The hash of the currently running task.
Shared State
@@ -2027,7 +2024,7 @@
.. note::
By default, ``foo-dev`` also has an :term:`RDEPENDS`-style dependency on
- ``foo``, because the default value of ``RDEPENDS_${PN}-dev`` (set in
+ ``foo``, because the default value of ``RDEPENDS:${PN}-dev`` (set in
bitbake.conf) includes "${PN}".
To ensure that the dependency chain is never broken, ``-dev`` and
diff --git a/poky/documentation/overview-manual/yp-intro.rst b/poky/documentation/overview-manual/yp-intro.rst
index d20a4ab..7aee9db 100644
--- a/poky/documentation/overview-manual/yp-intro.rst
+++ b/poky/documentation/overview-manual/yp-intro.rst
@@ -738,7 +738,7 @@
defined by the classes it inherits from the OE-Core layer's class
definitions in ``./meta/classes``. Within a recipe you can also define
additional tasks as well as task prerequisites. Recipe syntax through
-BitBake also supports both ``_prepend`` and ``_append`` operators as a
+BitBake also supports both ``:prepend`` and ``:append`` operators as a
method of extending task functionality. These operators inject code into
the beginning or end of a task. For information on these BitBake
operators, see the
diff --git a/poky/documentation/ref-manual/classes.rst b/poky/documentation/ref-manual/classes.rst
index 49905f2..3af0238 100644
--- a/poky/documentation/ref-manual/classes.rst
+++ b/poky/documentation/ref-manual/classes.rst
@@ -404,6 +404,22 @@
section in the Yocto Project Overview and Concepts Manual for more
discussion on these cross-compilation tools.
+.. _ref-classes-cve-check:
+
+``cve-check.bbclass``
+=====================
+
+The ``cve-check`` class looks for known CVEs (Common Vulnerabilities
+and Exposures) while building an image. This class is meant to be
+inherited globally from a configuration file::
+
+ INHERIT += "cve-check"
+
+You can also look for vulnerabilities in specific packages by passing
+``-c cve_check`` to BitBake. You will find details in the
+":ref:`dev-manual/common-tasks:checking for vulnerabilities`"
+section in the Development Tasks Manual.
+
.. _ref-classes-debian:
``debian.bbclass``
@@ -456,8 +472,8 @@
tarball. Following is an example::
BBCLASSEXTEND = "devupstream:target"
- SRC_URI_class-devupstream = "git://git.example.com/example"
- SRCREV_class-devupstream = "abcd1234"
+ SRC_URI:class-devupstream = "git://git.example.com/example"
+ SRCREV:class-devupstream = "abcd1234"
Adding the above statements to your recipe creates a variant that has
:term:`DEFAULT_PREFERENCE` set to "-1".
@@ -465,8 +481,8 @@
Any development-specific adjustments can be done by using the
``class-devupstream`` override. Here is an example::
- DEPENDS_append_class-devupstream = " gperf-native"
- do_configure_prepend_class-devupstream() {
+ DEPENDS:append:class-devupstream = " gperf-native"
+ do_configure:prepend:class-devupstream() {
touch ${S}/README
}
@@ -846,7 +862,7 @@
inheriting the class, you can then disable the feature by setting the
:term:`ICECC_DISABLED` variable to "1" as follows::
- INHERIT_DISTRO_append = " icecc"
+ INHERIT_DISTRO:append = " icecc"
ICECC_DISABLED ??= "1"
This practice
@@ -974,7 +990,7 @@
recipe, add the following to the recipe. You need to realize that the
package name override, in this example ``${PN}``, must be used::
- INSANE_SKIP_${PN} += "dev-so"
+ INSANE_SKIP:${PN} += "dev-so"
Please keep in mind that the QA checks
are meant to detect real or potential problems in the packaged
@@ -1182,7 +1198,7 @@
its :term:`PN` value matches something already in :term:`OVERRIDES` (e.g.
:term:`PN` happens to be the same as :term:`MACHINE` or
:term:`DISTRO`), it can have unexpected consequences.
- For example, assignments such as ``FILES_${PN} = "xyz"`` effectively
+ For example, assignments such as ``FILES:${PN} = "xyz"`` effectively
turn into ``FILES = "xyz"``.
- ``rpaths:`` Checks for rpaths in the binaries that contain build
@@ -1208,7 +1224,7 @@
- ``unlisted-pkg-lics:`` Checks that all declared licenses applying
for a package are also declared on the recipe level (i.e. any license
- in ``LICENSE_*`` should appear in :term:`LICENSE`).
+ in ``LICENSE:*`` should appear in :term:`LICENSE`).
- ``useless-rpaths:`` Checks for dynamic library load paths (rpaths)
in the binaries that by default on a standard system are searched by
@@ -1605,7 +1621,7 @@
BBCLASSEXTEND = "native"
Inside the
- recipe, use ``_class-native`` and ``_class-target`` overrides to
+ recipe, use ``:class-native`` and ``:class-target`` overrides to
specify any functionality specific to the respective native or target
case.
@@ -1636,7 +1652,7 @@
BBCLASSEXTEND = "nativesdk"
Inside the
- recipe, use ``_class-nativesdk`` and ``_class-target`` overrides to
+ recipe, use ``:class-nativesdk`` and ``:class-target`` overrides to
specify any functionality specific to the respective SDK machine or
target case.
@@ -2481,7 +2497,7 @@
the recipe's main package, use ``${``\ :term:`PN`\ ``}``. Here
is an example from the connman recipe::
- SYSTEMD_SERVICE_${PN} = "connman.service"
+ SYSTEMD_SERVICE:${PN} = "connman.service"
Services are set up to start on boot automatically
unless you have set
diff --git a/poky/documentation/ref-manual/faq.rst b/poky/documentation/ref-manual/faq.rst
index c7322e7..d3a603d 100644
--- a/poky/documentation/ref-manual/faq.rst
+++ b/poky/documentation/ref-manual/faq.rst
@@ -301,7 +301,7 @@
attempt before any others by adding something like the following to the
``local.conf`` configuration file::
- PREMIRRORS_prepend = "\
+ PREMIRRORS:prepend = "\
git://.*/.* http://www.yoctoproject.org/sources/ \n \
ftp://.*/.* http://www.yoctoproject.org/sources/ \n \
http://.*/.* http://www.yoctoproject.org/sources/ \n \
@@ -341,7 +341,7 @@
You could make the following changes to the ``local.conf`` configuration
file as long as the :term:`PREMIRRORS` server is current::
- PREMIRRORS_prepend = "\
+ PREMIRRORS:prepend = "\
ftp://.*/.* http://www.yoctoproject.org/sources/ \n \
http://.*/.* http://www.yoctoproject.org/sources/ \n \
https://.*/.* http://www.yoctoproject.org/sources/ \n"
diff --git a/poky/documentation/ref-manual/kickstart.rst b/poky/documentation/ref-manual/kickstart.rst
index fc723cc..cac9f2f 100644
--- a/poky/documentation/ref-manual/kickstart.rst
+++ b/poky/documentation/ref-manual/kickstart.rst
@@ -65,13 +65,17 @@
Here is a list that describes other supported options you can use with
the ``part`` and ``partition`` commands:
-- ``--size``: The minimum partition size in MBytes. Specify an
- integer value such as 500. Do not append the number with "MB". You do
- not need this option if you use ``--source``.
+- ``--size``: The minimum partition size. Specify as an integer value
+ optionally followed by one of the units "k" / "K" for kibibyte,
+ "M" for mebibyte and "G" for gibibyte. The default unit if none is
+ given is "M". You do not need this option if you use ``--source``.
-- ``--fixed-size``: The exact partition size in MBytes. You cannot
- specify with ``--size``. An error occurs when assembling the disk
- image if the partition data is larger than ``--fixed-size``.
+- ``--fixed-size``: The exact partition size. Specify as an integer
+ value optionally followed by one of the units "k" / "K" for kibibyte,
+ "M" for mebibyte and "G" for gibibyte. The default unit if none is
+ given is "M". Cannot be specify together with ``--size``. An error
+ occurs when assembling the disk image if the partition data is larger
+ than ``--fixed-size``.
- ``--source``: This option is a Wic-specific option that names the
source of the data that populates the partition. The most common
@@ -134,10 +138,13 @@
- ``--align (in KBytes)``: This option is a Wic-specific option that
says to start partitions on boundaries given x KBytes.
-- ``--offset (in KBytes)``: This option is a Wic-specific option that
+- ``--offset``: This option is a Wic-specific option that
says to place a partition at exactly the specified offset. If the
partition cannot be placed at the specified offset, the image build
- will fail.
+ will fail. Specify as an integer value optionally followed by one of
+ the units "s" / "S" for 512 byte sector, "k" / "K" for kibibyte, "M"
+ for mebibyte and "G" for gibibyte. The default unit if none is given
+ is "k".
- ``--no-table``: This option is a Wic-specific option. Using the
option reserves space for the partition and causes it to become
@@ -151,7 +158,10 @@
- ``--extra-space``: This option is a Wic-specific option that adds
extra space after the space filled by the content of the partition.
The final size can exceed the size specified by the ``--size``
- option. The default value is 10 Mbytes.
+ option. The default value is 10M. Specify as an integer value
+ optionally followed by one of the units "k" / "K" for kibibyte, "M"
+ for mebibyte and "G" for gibibyte. The default unit if none is given
+ is "M".
- ``--overhead-factor``: This option is a Wic-specific option that
multiplies the size of the partition by the option's value. You must
diff --git a/poky/documentation/ref-manual/qa-checks.rst b/poky/documentation/ref-manual/qa-checks.rst
index 0ef203c..c3e40db 100644
--- a/poky/documentation/ref-manual/qa-checks.rst
+++ b/poky/documentation/ref-manual/qa-checks.rst
@@ -223,7 +223,7 @@
software that reads :term:`CFLAGS` when you build it,
you could add the following to your recipe::
- CFLAGS_append = " -fPIC "
+ CFLAGS:append = " -fPIC "
For more information on text relocations at runtime, see
https://www.akkadia.org/drepper/textrelocs.html.
@@ -263,7 +263,7 @@
The ``/usr/share/info/dir`` should not be packaged. Add the following
line to your :ref:`ref-tasks-install` task or to your
- ``do_install_append`` within the recipe as follows::
+ ``do_install:append`` within the recipe as follows::
rm ${D}${infodir}/dir
@@ -347,7 +347,7 @@
.. _qa-check-dep-cmp:
-- ``<var>_<packagename> is invalid: <comparison> (<value>) only comparisons <, =, >, <=, and >= are allowed [dep-cmp]``
+- ``<var>:<packagename> is invalid: <comparison> (<value>) only comparisons <, =, >, <=, and >= are allowed [dep-cmp]``
If you are adding a versioned dependency relationship to one of the
dependency variables (:term:`RDEPENDS`,
@@ -454,14 +454,14 @@
``pkg_preinst``, ``pkg_postinst``, ``pkg_prerm``, ``pkg_postrm``, and
:term:`ALLOW_EMPTY`) should always be set specific
to a package (i.e. they should be set with a package name override
- such as ``RDEPENDS_${PN} = "value"`` rather than
+ such as ``RDEPENDS:${PN} = "value"`` rather than
``RDEPENDS = "value"``). If you receive this error, correct any
assignments to these variables within your recipe.
-- ``recipe uses DEPENDS_${PN}, should use DEPENDS [pkgvarcheck]``
+- ``recipe uses DEPENDS:${PN}, should use DEPENDS [pkgvarcheck]``
- This check looks for instances of setting ``DEPENDS_${PN}``
+ This check looks for instances of setting ``DEPENDS:${PN}``
which is erroneous (:term:`DEPENDS` is a recipe-wide variable and thus
it is not correct to specify it for a particular package, nor will such
an assignment actually work.) Set :term:`DEPENDS` instead.
@@ -524,7 +524,7 @@
following:
- Add the files to :term:`FILES` for the package you want them to appear
- in (e.g. ``FILES_${``\ :term:`PN`\ ``}`` for the main
+ in (e.g. ``FILES:${``\ :term:`PN`\ ``}`` for the main
package).
- Delete the files at the end of the ``do_install`` task if the
@@ -539,18 +539,18 @@
when a recipe has been renamed. However, if that is not the case, the
message might indicate that a private version of a library is being
erroneously picked up as the provider for a common library. If that
- is the case, you should add the library's ``.so`` file name to
+ is the case, you should add the library's ``.so`` filename to
:term:`PRIVATE_LIBS` in the recipe that provides
the private version of the library.
.. _qa-check-unlisted-pkg-lics:
-- ``LICENSE_<packagename> includes licenses (<licenses>) that are not listed in LICENSE [unlisted-pkg-lics]``
+- ``LICENSE:<packagename> includes licenses (<licenses>) that are not listed in LICENSE [unlisted-pkg-lics]``
The :term:`LICENSE` of the recipe should be a superset
of all the licenses of all packages produced by this recipe. In other
- words, any license in ``LICENSE_*`` should also appear in
+ words, any license in ``LICENSE:*`` should also appear in
:term:`LICENSE`.
@@ -620,7 +620,7 @@
.. _qa-check-missing-update-alternatives:
-- ``<recipename>: recipe defines ALTERNATIVE_<packagename> but doesn't inherit update-alternatives. This might fail during do_rootfs later! [missing-update-alternatives]``
+- ``<recipename>: recipe defines ALTERNATIVE:<packagename> but doesn't inherit update-alternatives. This might fail during do_rootfs later! [missing-update-alternatives]``
This check ensures that if a recipe sets the :term:`ALTERNATIVE` variable that the
recipe also inherits :ref:`update-alternatives <ref-classes-update-alternatives>` such
diff --git a/poky/documentation/ref-manual/variables.rst b/poky/documentation/ref-manual/variables.rst
index 1150940..7aecda0 100644
--- a/poky/documentation/ref-manual/variables.rst
+++ b/poky/documentation/ref-manual/variables.rst
@@ -38,9 +38,9 @@
Like all package-controlling variables, you must always use them in
conjunction with a package name override, as in::
- ALLOW_EMPTY_${PN} = "1"
- ALLOW_EMPTY_${PN}-dev = "1"
- ALLOW_EMPTY_${PN}-staticdev = "1"
+ ALLOW_EMPTY:${PN} = "1"
+ ALLOW_EMPTY:${PN}-dev = "1"
+ ALLOW_EMPTY:${PN}-staticdev = "1"
:term:`ALTERNATIVE`
Lists commands in a package that need an alternative binary naming
@@ -53,7 +53,7 @@
provided by another package. For example, if the ``busybox`` package
has four such commands, you identify them as follows::
- ALTERNATIVE_busybox = "sh sed test bracket"
+ ALTERNATIVE:busybox = "sh sed test bracket"
For more information on the alternatives system, see the
":ref:`update-alternatives.bbclass <ref-classes-update-alternatives>`"
@@ -297,7 +297,7 @@
can attach it to a specific image recipe by using the recipe name
override::
- BAD_RECOMMENDATIONS_pn-target_image = "package_name"
+ BAD_RECOMMENDATIONS:pn-target_image = "package_name"
It is important to realize that if you choose to not install packages
using this variable and some other packages are dependent on them
@@ -575,7 +575,7 @@
Internally, the :term:`BBCLASSEXTEND` mechanism generates recipe
variants by rewriting variable values and applying overrides such
- as ``_class-native``. For example, to generate a native version of
+ as ``:class-native``. For example, to generate a native version of
a recipe, a :term:`DEPENDS` on "foo" is rewritten
to a :term:`DEPENDS` on "foo-native".
@@ -1133,7 +1133,7 @@
As an example, the following override allows you to install extra
files, but only when building for the target::
- do_install_append_class-target() {
+ do_install:append:class-target() {
install my-extra-file ${D}${sysconfdir}
}
@@ -1141,7 +1141,7 @@
"native" when building for the build host, and to "other" when not
building for the build host::
- FOO_class-native = "native"
+ FOO:class-native = "native"
FOO = "other"
The underlying mechanism behind :term:`CLASSOVERRIDE` is simply
@@ -1246,7 +1246,7 @@
that identifies the resulting package. Then, provide a
space-separated list of files. Here is an example::
- CONFFILES_${PN} += "${sysconfdir}/file1 \
+ CONFFILES:${PN} += "${sysconfdir}/file1 \
${sysconfdir}/file2 ${sysconfdir}/file3"
There is a relationship between the :term:`CONFFILES` and :term:`FILES`
@@ -1471,11 +1471,22 @@
variable only in certain contexts (e.g. when building for kernel
and kernel module recipes).
+ :term:`CVE_CHECK_PN_WHITELIST`
+ The list of package names (:term:`PN`) for which
+ CVEs (Common Vulnerabilities and Exposures) are ignored.
+
+ :term:`CVE_CHECK_WHITELIST`
+ The list of CVE IDs which are ignored. Here is
+ an example from the :oe_layerindex:`Python3 recipe</layerindex/recipe/23823>`::
+
+ # This is windows only issue.
+ CVE_CHECK_WHITELIST += "CVE-2020-15523"
+
:term:`CVE_PRODUCT`
In a recipe, defines the name used to match the recipe name
against the name in the upstream `NIST CVE database <https://nvd.nist.gov/>`__.
- The default is ${:term:`BPN`}. If it does not match the name in NIST CVE
+ The default is ${:term:`BPN`}. If it does not match the name in the NIST CVE
database or matches with multiple entries in the database, the default
value needs to be changed.
@@ -1535,7 +1546,7 @@
package naming. You must use the package name as an override when you
set this variable. Here is an example from the ``fontconfig`` recipe::
- DEBIAN_NOAUTONAME_fontconfig-utils = "1"
+ DEBIAN_NOAUTONAME:fontconfig-utils = "1"
:term:`DEBIANNAME`
When the :ref:`debian <ref-classes-debian>` class is inherited,
@@ -1545,7 +1556,7 @@
override when you set this variable. Here is an example from the
``dbus`` recipe::
- DEBIANNAME_${PN} = "dbus-1"
+ DEBIANNAME:${PN} = "dbus-1"
:term:`DEBUG_BUILD`
Specifies to build packages with debugging information. This
@@ -2104,7 +2115,7 @@
to fix a runtime dependency to the exact same version of another
package in the same recipe::
- RDEPENDS_${PN}-additional-module = "${PN} (= ${EXTENDPKGV})"
+ RDEPENDS:${PN}-additional-module = "${PN} (= ${EXTENDPKGV})"
The dependency relationships are intended to force the package
manager to upgrade these types of packages in lock-step.
@@ -2204,7 +2215,7 @@
this variable, use an override for the associated image type. Here is
an example::
- EXTRA_IMAGECMD_ext3 ?= "-i 4096"
+ EXTRA_IMAGECMD:ext3 ?= "-i 4096"
:term:`EXTRA_IMAGEDEPENDS`
A list of recipes to build that do not provide packages for
@@ -2331,7 +2342,7 @@
list of files or paths that identify the files you want included as
part of the resulting package. Here is an example::
- FILES_${PN} += "${bindir}/mydir1 ${bindir}/mydir2/myfile"
+ FILES:${PN} += "${bindir}/mydir1 ${bindir}/mydir2/myfile"
.. note::
@@ -2347,7 +2358,7 @@
rather than ``/usr/bin``. You can find a list of these
variables at the top of the ``meta/conf/bitbake.conf`` file in
the :term:`Source Directory`. You will also
- find the default values of the various ``FILES_*`` variables in
+ find the default values of the various ``FILES:*`` variables in
this file.
If some of the files you provide with the :term:`FILES` variable are
@@ -2380,7 +2391,7 @@
:term:`FILESEXTRAPATHS` from within a ``.bbappend`` file and that you
prepend paths as follows::
- FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+ FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:"
In the above example, the build system first
looks for files in a directory that has the same name as the
@@ -2402,7 +2413,7 @@
Here is another common use::
- FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
+ FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
In this example, the build system extends the
:term:`FILESPATH` variable to include a directory named ``files`` that is
@@ -2410,13 +2421,13 @@
This next example specifically adds three paths::
- FILESEXTRAPATHS_prepend := "path_1:path_2:path_3:"
+ FILESEXTRAPATHS:prepend := "path_1:path_2:path_3:"
A final example shows how you can extend the search path and include
a :term:`MACHINE`-specific override, which is useful
in a BSP layer::
- FILESEXTRAPATHS_prepend_intel-x86-common := "${THISDIR}/${PN}:"
+ FILESEXTRAPATHS:prepend:intel-x86-common := "${THISDIR}/${PN}:"
The previous statement appears in the
``linux-yocto-dev.bbappend`` file, which is found in the
@@ -2664,7 +2675,7 @@
Here is an example from the ``dbus`` recipe::
- GROUPADD_PARAM_${PN} = "-r netdev"
+ GROUPADD_PARAM:${PN} = "-r netdev"
For information on the standard Linux shell command
``groupadd``, see https://linux.die.net/man/8/groupadd.
@@ -2977,7 +2988,7 @@
``btrfs``, and so forth). When setting this variable, you should use
an override for the associated type. Here is an example::
- IMAGE_CMD_jffs2 = "mkfs.jffs2 --root=${IMAGE_ROOTFS} --faketime \
+ IMAGE_CMD:jffs2 = "mkfs.jffs2 --root=${IMAGE_ROOTFS} --faketime \
--output=${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.jffs2 \
${EXTRA_IMAGECMD}"
@@ -3033,8 +3044,8 @@
:term:`IMAGE_FSTYPES` prior to using the "inherit image" line.
- Due to the way the OpenEmbedded build system processes this
- variable, you cannot update its contents by using ``_append``
- or ``_prepend``. You must use the ``+=`` operator to add one or
+ variable, you cannot update its contents by using ``:append``
+ or ``:prepend``. You must use the ``+=`` operator to add one or
more options to the :term:`IMAGE_FSTYPES` variable.
:term:`IMAGE_INSTALL`
@@ -3052,7 +3063,7 @@
When you use this variable, it is best to use it as follows::
- IMAGE_INSTALL_append = " package-name"
+ IMAGE_INSTALL:append = " package-name"
Be sure to include the space
between the quotation character and the start of the package name or
@@ -3144,7 +3155,7 @@
IMAGE_NAME ?= "${IMAGE_BASENAME}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
:term:`IMAGE_NAME_SUFFIX`
- Suffix used for the image output file name - defaults to ``".rootfs"``
+ Suffix used for the image output filename - defaults to ``".rootfs"``
to distinguish the image file from other files created during image
building; however if this suffix is redundant or not desired you can
clear the value of this variable (set the value to ""). For example,
@@ -3292,7 +3303,7 @@
Specifies a dependency from one image type on another. Here is an
example from the :ref:`image-live <ref-classes-image-live>` class::
- IMAGE_TYPEDEP_live = "ext3"
+ IMAGE_TYPEDEP:live = "ext3"
In the previous example, the variable ensures that when "live" is
listed with the :term:`IMAGE_FSTYPES` variable,
@@ -3695,7 +3706,7 @@
recipe. The package name override must be used, which in this example
is ``${PN}``::
- INSANE_SKIP_${PN} += "dev-so"
+ INSANE_SKIP:${PN} += "dev-so"
See the ":ref:`insane.bbclass <ref-classes-insane>`" section for a
list of the valid QA checks you can specify using this variable.
@@ -3749,10 +3760,10 @@
``meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.12.bbappend``.
Here are the related statements from that append file::
- KBRANCH_genericx86 = "standard/base"
- KBRANCH_genericx86-64 = "standard/base"
- KBRANCH_edgerouter = "standard/edgerouter"
- KBRANCH_beaglebone = "standard/beaglebone"
+ KBRANCH:genericx86 = "standard/base"
+ KBRANCH:genericx86-64 = "standard/base"
+ KBRANCH:edgerouter = "standard/edgerouter"
+ KBRANCH:beaglebone = "standard/beaglebone"
The :term:`KBRANCH` statements
identify the kernel branch to use when building for each supported
@@ -3780,11 +3791,11 @@
Here is an example from a "raspberrypi2" :term:`KMACHINE` build that uses
a ``defconfig`` file named "bcm2709_defconfig"::
- KBUILD_DEFCONFIG_raspberrypi2 = "bcm2709_defconfig"
+ KBUILD_DEFCONFIG:raspberrypi2 = "bcm2709_defconfig"
As an alternative, you can use the following within your append file::
- KBUILD_DEFCONFIG_pn-linux-yocto ?= defconfig_file
+ KBUILD_DEFCONFIG:pn-linux-yocto ?= "defconfig_file"
For more
information on how to use the :term:`KBUILD_DEFCONFIG` variable, see the
@@ -3932,10 +3943,10 @@
statements add specific configurations to targeted machine types::
KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc features/taskstats/taskstats.scc"
- KERNEL_FEATURES_append = "${KERNEL_EXTRA_FEATURES}"
- KERNEL_FEATURES_append_qemuall = "cfg/virtio.scc"
- KERNEL_FEATURES_append_qemux86 = " cfg/sound.scc cfg/paravirt_kvm.scc"
- KERNEL_FEATURES_append_qemux86-64 = "cfg/sound.scc"
+ KERNEL_FEATURES:append = "${KERNEL_EXTRA_FEATURES}"
+ KERNEL_FEATURES:append:qemuall = "cfg/virtio.scc"
+ KERNEL_FEATURES:append:qemux86 = " cfg/sound.scc cfg/paravirt_kvm.scc"
+ KERNEL_FEATURES:append:qemux86-64 = "cfg/sound.scc"
:term:`KERNEL_FIT_LINK_NAME`
The link name of the kernel flattened image tree (FIT) image. This
@@ -4117,13 +4128,13 @@
Kernel's ``meta`` branch. As an example take a look in the
``common/recipes-kernel/linux/linux-yocto_3.19.bbappend`` file::
- LINUX_VERSION_core2-32-intel-common = "3.19.0"
- COMPATIBLE_MACHINE_core2-32-intel-common = "${MACHINE}"
- SRCREV_meta_core2-32-intel-common = "8897ef68b30e7426bc1d39895e71fb155d694974"
- SRCREV_machine_core2-32-intel-common = "43b9eced9ba8a57add36af07736344dcc383f711"
- KMACHINE_core2-32-intel-common = "intel-core2-32"
- KBRANCH_core2-32-intel-common = "standard/base"
- KERNEL_FEATURES_append_core2-32-intel-common = "${KERNEL_FEATURES_INTEL_COMMON}"
+ LINUX_VERSION:core2-32-intel-common = "3.19.0"
+ COMPATIBLE_MACHINE:core2-32-intel-common = "${MACHINE}"
+ SRCREV_meta:core2-32-intel-common = "8897ef68b30e7426bc1d39895e71fb155d694974"
+ SRCREV_machine:core2-32-intel-common = "43b9eced9ba8a57add36af07736344dcc383f711"
+ KMACHINE:core2-32-intel-common = "intel-core2-32"
+ KBRANCH:core2-32-intel-common = "standard/base"
+ KERNEL_FEATURES:append:core2-32-intel-common = "${KERNEL_FEATURES_INTEL_COMMON}"
The :term:`KMACHINE` statement says
that the kernel understands the machine name as "intel-core2-32".
@@ -4303,15 +4314,15 @@
Documentation License 1.2 could be specified as follows::
LICENSE = "GFDL-1.2 & GPLv2"
- LICENSE_${PN} = "GPLv2"
- LICENSE_${PN}-doc = "GFDL-1.2"
+ LICENSE:${PN} = "GPLv2"
+ LICENSE:${PN}-doc = "GFDL-1.2"
:term:`LICENSE_CREATE_PACKAGE`
Setting :term:`LICENSE_CREATE_PACKAGE` to "1" causes the OpenEmbedded
build system to create an extra package (i.e.
``${``\ :term:`PN`\ ``}-lic``) for each recipe and to add
those packages to the
- :term:`RRECOMMENDS`\ ``_${PN}``.
+ :term:`RRECOMMENDS`\ ``:${PN}``.
The ``${PN}-lic`` package installs a directory in
``/usr/share/licenses`` named ``${PN}``, which is the recipe's base
@@ -4615,7 +4626,7 @@
in QEMU, like in the following example from the ``connman-conf``
recipe::
- SRC_URI_append_qemuall = " file://wired.config \
+ SRC_URI:append:qemuall = " file://wired.config \
file://wired-setup \
"
@@ -4818,7 +4829,7 @@
can attach it to a specific image recipe by using the recipe name
override::
- NO_RECOMMENDATIONS_pn-target_image = "1"
+ NO_RECOMMENDATIONS:pn-target_image = "1"
It is important to realize that if you choose to not install packages
using this variable and some other packages are dependent on them
@@ -4841,14 +4852,14 @@
:term:`NOAUTOPACKAGEDEBUG`
Disables auto package from splitting ``.debug`` files. If a recipe
- requires ``FILES_${PN}-dbg`` to be set manually, the
+ requires ``FILES:${PN}-dbg`` to be set manually, the
:term:`NOAUTOPACKAGEDEBUG` can be defined allowing you to define the
content of the debug package. For example::
NOAUTOPACKAGEDEBUG = "1"
- FILES_${PN}-dev = "${includedir}/${QT_DIR_NAME}/Qt/*"
- FILES_${PN}-dbg = "/usr/src/debug/"
- FILES_${QT_BASE_NAME}-demos-doc = "${docdir}/${QT_DIR_NAME}/qch/qt.qch"
+ FILES:${PN}-dev = "${includedir}/${QT_DIR_NAME}/Qt/*"
+ FILES:${PN}-dbg = "/usr/src/debug/"
+ FILES:${QT_BASE_NAME}-demos-doc = "${docdir}/${QT_DIR_NAME}/qch/qt.qch"
:term:`NON_MULTILIB_RECIPES`
A list of recipes that should not be built for multilib. OE-Core's
@@ -4944,7 +4955,7 @@
assignment will override ``FOO`` with the value "overridden" at the
end of parsing::
- FOO_an-override = "overridden"
+ FOO:an-override = "overridden"
See the
":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:conditional syntax (overrides)`"
@@ -4959,7 +4970,7 @@
allows variables to be set for a single recipe within configuration
(``.conf``) files. Here is an example::
- FOO_pn-myrecipe = "myrecipe-specific value"
+ FOO:pn-myrecipe = "myrecipe-specific value"
.. note::
@@ -5107,7 +5118,7 @@
can attach it to a specific image recipe by using the recipe name
override::
- PACKAGE_EXCLUDE_pn-target_image = "package_name"
+ PACKAGE_EXCLUDE:pn-target_image = "package_name"
If you choose to not install a package using this variable and some
other package is dependent on it (i.e. listed in a recipe's
@@ -5344,18 +5355,18 @@
Or, you can just append the variable::
- PACKAGECONFIG_append = " f4"
+ PACKAGECONFIG:append = " f4"
- *Configuration file:* This method is identical to changing the
block through an append file except you edit your ``local.conf``
or ``mydistro.conf`` file. As with append files previously
described, you can either completely override the variable::
- PACKAGECONFIG_pn-recipename = "f4 f5"
+ PACKAGECONFIG:pn-recipename = "f4 f5"
Or, you can just amend the variable::
- PACKAGECONFIG_append_pn-recipename = " f4"
+ PACKAGECONFIG:append:pn-recipename = " f4"
:term:`PACKAGECONFIG_CONFARGS`
A space-separated list of configuration options generated from the
@@ -5390,7 +5401,7 @@
(leftmost) package.
Packages in the variable's list that are empty (i.e. where none of
- the patterns in ``FILES_``\ pkg match any files installed by the
+ the patterns in ``FILES:``\ pkg match any files installed by the
:ref:`ref-tasks-install` task) are not generated,
unless generation is forced through the
:term:`ALLOW_EMPTY` variable.
@@ -5541,7 +5552,7 @@
For example, when the :ref:`debian <ref-classes-debian>` class
renames the output package, it does so by setting
- ``PKG_packagename``.
+ ``PKG:packagename``.
:term:`PKG_CONFIG_PATH`
The path to ``pkg-config`` files for the current build context.
@@ -5775,17 +5786,17 @@
:term:`OVERRIDES` to set a machine-specific
override. Here is an example::
- PREFERRED_VERSION_linux-yocto_qemux86 = "5.0%"
+ PREFERRED_VERSION_linux-yocto:qemux86 = "5.0%"
Although not recommended, worst case, you can also use the
"forcevariable" override, which is the strongest override possible.
Here is an example::
- PREFERRED_VERSION_linux-yocto_forcevariable = "5.0%"
+ PREFERRED_VERSION_linux-yocto:forcevariable = "5.0%"
.. note::
- The ``\_forcevariable`` override is not handled specially. This override
+ The ``:forcevariable`` override is not handled specially. This override
only works because the default value of :term:`OVERRIDES` includes "forcevariable".
If a recipe with the specified version is not available, a warning
@@ -5809,7 +5820,7 @@
the ``local.conf`` configuration file in the
:term:`Build Directory`::
- PREMIRRORS_prepend = "\
+ PREMIRRORS:prepend = "\
git://.*/.* http://www.yoctoproject.org/sources/ \n \
ftp://.*/.* http://www.yoctoproject.org/sources/ \n \
http://.*/.* http://www.yoctoproject.org/sources/ \n \
@@ -5992,7 +6003,7 @@
Like all package-controlling variables, you must always use them in
conjunction with a package name override. Here is an example::
- RCONFLICTS_${PN} = "another_conflicting_package_name"
+ RCONFLICTS:${PN} = "another_conflicting_package_name"
BitBake, which the OpenEmbedded build system uses, supports
specifying versioned dependencies. Although the syntax varies
@@ -6000,7 +6011,7 @@
from you. Here is the general syntax to specify versions with the
:term:`RCONFLICTS` variable::
- RCONFLICTS_${PN} = "package (operator version)"
+ RCONFLICTS:${PN} = "package (operator version)"
For ``operator``, you can specify the following:
@@ -6013,7 +6024,7 @@
For example, the following sets up a dependency on version 1.2 or
greater of the package ``foo``::
- RCONFLICTS_${PN} = "foo (>= 1.2)"
+ RCONFLICTS:${PN} = "foo (>= 1.2)"
:term:`RDEPENDS`
Lists runtime dependencies of a package. These dependencies are other
@@ -6022,7 +6033,7 @@
package ``foo`` needs the packages ``bar`` and ``baz`` to be
installed::
- RDEPENDS_foo = "bar baz"
+ RDEPENDS:foo = "bar baz"
The most common types of package
runtime dependencies are automatically detected and added. Therefore,
@@ -6063,7 +6074,7 @@
on the ``perl`` package. In this case, you would use the following
:term:`RDEPENDS` statement::
- RDEPENDS_${PN}-dev += "perl"
+ RDEPENDS:${PN}-dev += "perl"
In the example,
the development package depends on the ``perl`` package. Thus, the
@@ -6072,10 +6083,10 @@
.. note::
- ``RDEPENDS_${PN}-dev`` includes ``${``\ :term:`PN`\ ``}``
+ ``RDEPENDS:${PN}-dev`` includes ``${``\ :term:`PN`\ ``}``
by default. This default is set in the BitBake configuration file
(``meta/conf/bitbake.conf``). Be careful not to accidentally remove
- ``${PN}`` when modifying ``RDEPENDS_${PN}-dev``. Use the "+=" operator
+ ``${PN}`` when modifying ``RDEPENDS:${PN}-dev``. Use the "+=" operator
rather than the "=" operator.
The package names you use with :term:`RDEPENDS` must appear as they would
@@ -6092,7 +6103,7 @@
from you. Here is the general syntax to specify versions with the
:term:`RDEPENDS` variable::
- RDEPENDS_${PN} = "package (operator version)"
+ RDEPENDS:${PN} = "package (operator version)"
For ``operator``, you can specify the following:
@@ -6112,7 +6123,7 @@
For example, the following sets up a dependency on version 1.2 or
greater of the package ``foo``::
- RDEPENDS_${PN} = "foo (>= 1.2)"
+ RDEPENDS:${PN} = "foo (>= 1.2)"
For information on build-time dependencies, see the
:term:`DEPENDS` variable. You can also see the
@@ -6247,7 +6258,7 @@
variable in conjunction with a package name override. Here is an
example::
- RPROVIDES_${PN} = "widget-abi-2"
+ RPROVIDES:${PN} = "widget-abi-2"
:term:`RRECOMMENDS`
A list of packages that extends the usability of a package being
@@ -6278,7 +6289,7 @@
support wireless functionality. In this case, you would use the
following::
- RRECOMMENDS_${PN}-dev += "wireless_package_name"
+ RRECOMMENDS:${PN}-dev += "wireless_package_name"
In the
example, the package name (``${PN}-dev``) must appear as it would in
@@ -6291,7 +6302,7 @@
Here is the general syntax to specify versions with the
:term:`RRECOMMENDS` variable::
- RRECOMMENDS_${PN} = "package (operator version)"
+ RRECOMMENDS:${PN} = "package (operator version)"
For ``operator``, you can specify the following:
@@ -6304,7 +6315,7 @@
For example, the following sets up a recommend on version 1.2 or
greater of the package ``foo``::
- RRECOMMENDS_${PN} = "foo (>= 1.2)"
+ RRECOMMENDS:${PN} = "foo (>= 1.2)"
:term:`RREPLACES`
A list of packages replaced by a package. The package manager uses
@@ -6316,7 +6327,7 @@
As with all package-controlling variables, you must use this variable
in conjunction with a package name override. Here is an example::
- RREPLACES_${PN} = "other_package_being_replaced"
+ RREPLACES:${PN} = "other_package_being_replaced"
BitBake, which the OpenEmbedded build system uses, supports
specifying versioned replacements. Although the syntax varies
@@ -6324,7 +6335,7 @@
from you. Here is the general syntax to specify versions with the
:term:`RREPLACES` variable::
- RREPLACES_${PN} = "package (operator version)"
+ RREPLACES:${PN} = "package (operator version)"
For ``operator``, you can specify the following:
@@ -6337,7 +6348,7 @@
For example, the following sets up a replacement using version 1.2
or greater of the package ``foo``::
- RREPLACES_${PN} = "foo (>= 1.2)"
+ RREPLACES:${PN} = "foo (>= 1.2)"
:term:`RSUGGESTS`
A list of additional packages that you can suggest for installation
@@ -6348,7 +6359,7 @@
variable in conjunction with a package name override. Here is an
example::
- RSUGGESTS_${PN} = "useful_package another_package"
+ RSUGGESTS:${PN} = "useful_package another_package"
:term:`S`
The location in the :term:`Build Directory` where
@@ -6862,7 +6873,7 @@
defined in the ``meta/conf/bitbake.conf`` configuration file.
You will see this variable referenced in the default values of
- ``FILES_${PN}``.
+ ``FILES:${PN}``.
:term:`SOLIBSDEV`
Defines the suffix for the development symbolic link (symlink) for
@@ -6871,7 +6882,7 @@
``meta/conf/bitbake.conf`` configuration file.
You will see this variable referenced in the default values of
- ``FILES_${PN}-dev``.
+ ``FILES:${PN}-dev``.
:term:`SOURCE_MIRROR_FETCH`
When you are fetching files to create a mirror of sources (i.e.
@@ -7609,7 +7620,7 @@
override to indicate the package to which the value applies. Here is
an example from the connman recipe::
- SYSTEMD_SERVICE_${PN} = "connman.service"
+ SYSTEMD_SERVICE:${PN} = "connman.service"
:term:`SYSVINIT_ENABLED_GETTYS`
When using
@@ -7947,14 +7958,14 @@
your own tests to the list of tests by appending :term:`TEST_SUITES` as
follows::
- TEST_SUITES_append = " mytest"
+ TEST_SUITES:append = " mytest"
Alternatively, you can
provide the "auto" option to have all applicable tests run against
the image.
::
- TEST_SUITES_append = " auto"
+ TEST_SUITES:append = " auto"
Using this option causes the
build system to automatically run tests that are applicable to the
@@ -8215,7 +8226,7 @@
The BitBake configuration file (``meta/conf/bitbake.conf``) defines
:term:`TUNE_FEATURES` as follows::
- TUNE_FEATURES ??= "${TUNE_FEATURES_tune-${DEFAULTTUNE}}"
+ TUNE_FEATURES ??= "${TUNE_FEATURES:tune-${DEFAULTTUNE}}"
See the :term:`DEFAULTTUNE` variable for more information.
@@ -8241,13 +8252,13 @@
the architecture, ABI, and tuning of output packages. The specific
tune is defined using the "_tune" override as follows::
- TUNE_PKGARCH_tune-tune = "tune"
+ TUNE_PKGARCH:tune-tune = "tune"
These tune-specific package architectures are defined in the machine
include files. Here is an example of the "core2-32" tuning as used in
the ``meta/conf/machine/include/tune-core2.inc`` file::
- TUNE_PKGARCH_tune-core2-32 = "core2-32"
+ TUNE_PKGARCH:tune-core2-32 = "core2-32"
:term:`TUNEABI`
An underlying Application Binary Interface (ABI) used by a particular
@@ -8614,7 +8625,7 @@
Here is an example from the ``dbus`` recipe::
- USERADD_PARAM_${PN} = "--system --home ${localstatedir}/lib/dbus \
+ USERADD_PARAM:${PN} = "--system --home ${localstatedir}/lib/dbus \
--no-create-home --shell /bin/false \
--user-group messagebus"
diff --git a/poky/documentation/releases.rst b/poky/documentation/releases.rst
index 3ace7c0..3f96464 100644
--- a/poky/documentation/releases.rst
+++ b/poky/documentation/releases.rst
@@ -35,7 +35,8 @@
- :yocto_docs:`3.1.6 Documentation </3.1.6>`
- :yocto_docs:`3.1.7 Documentation </3.1.7>`
- :yocto_docs:`3.1.8 Documentation </3.1.8>`
-- :yocto_docs:`3.1.8 Documentation </3.1.9>`
+- :yocto_docs:`3.1.9 Documentation </3.1.9>`
+- :yocto_docs:`3.1.10 Documentation </3.1.10>`
==========================
Outdated Release Manuals
diff --git a/poky/documentation/sdk-manual/appendix-customizing-standard.rst b/poky/documentation/sdk-manual/appendix-customizing-standard.rst
index 9bc70cf..c619c15 100644
--- a/poky/documentation/sdk-manual/appendix-customizing-standard.rst
+++ b/poky/documentation/sdk-manual/appendix-customizing-standard.rst
@@ -29,6 +29,6 @@
provided by recipes with the standard SDK by adding "api-documentation"
to the
:term:`DISTRO_FEATURES`
-variable: DISTRO_FEATURES_append = " api-documentation" Setting this
+variable: DISTRO_FEATURES:append = " api-documentation" Setting this
variable as shown here causes the OpenEmbedded build system to build the
documentation and then include it in the standard SDK.
diff --git a/poky/documentation/sdk-manual/appendix-customizing.rst b/poky/documentation/sdk-manual/appendix-customizing.rst
index 44f4334..4eccc28 100644
--- a/poky/documentation/sdk-manual/appendix-customizing.rst
+++ b/poky/documentation/sdk-manual/appendix-customizing.rst
@@ -73,7 +73,7 @@
SDK_INHERIT_BLACKLIST
is set using the "?=" operator. Consequently, you will need to
either define the entire list by using the "=" operator, or you
- will need to append a value using either "_append" or the "+="
+ will need to append a value using either ":append" or the "+="
operator. You can learn more about these operators in the
":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:basic syntax`"
section of the BitBake User Manual.
@@ -250,7 +250,7 @@
recipes that depend on lists of other recipes.
- Build the "world" target and set
- ``EXCLUDE_FROM_WORLD_pn-``\ recipename for the recipes you do not
+ ``EXCLUDE_FROM_WORLD:pn-``\ recipename for the recipes you do not
want built. See the
:term:`EXCLUDE_FROM_WORLD`
variable for additional information.
@@ -334,7 +334,7 @@
time significantly and increases the size of the SDK installer by 30-80
Mbytes depending on how many recipes are included in your configuration.
-You can use ``EXCLUDE_FROM_WORLD_pn-``\ recipename for recipes you want
+You can use ``EXCLUDE_FROM_WORLD:pn-``\ recipename for recipes you want
to exclude. However, it is assumed that you would need to be building
the "world" target if you want to provide additional items to the SDK.
Consequently, building for "world" should not represent undue overhead
diff --git a/poky/documentation/sdk-manual/appendix-obtain.rst b/poky/documentation/sdk-manual/appendix-obtain.rst
index fc6b8b9..841abac 100644
--- a/poky/documentation/sdk-manual/appendix-obtain.rst
+++ b/poky/documentation/sdk-manual/appendix-obtain.rst
@@ -163,7 +163,7 @@
SDK installer. Doing so ensures that the eventual SDK
installation process installs the appropriate library packages
as part of the SDK. Following is an example using ``libc``
- static development libraries: TOOLCHAIN_TARGET_TASK_append = "
+ static development libraries: TOOLCHAIN_TARGET_TASK:append = "
libc-staticdev"
7. *Run the Installer:* You can now run the SDK installer from
diff --git a/poky/documentation/sdk-manual/extensible.rst b/poky/documentation/sdk-manual/extensible.rst
index 2cdb06d..8ef44e3 100644
--- a/poky/documentation/sdk-manual/extensible.rst
+++ b/poky/documentation/sdk-manual/extensible.rst
@@ -838,7 +838,7 @@
If you need to add runtime dependencies, you can do so by adding the
following to your recipe::
- RDEPENDS_${PN} += "dependency1 dependency2 ..."
+ RDEPENDS:${PN} += "dependency1 dependency2 ..."
.. note::
@@ -1154,7 +1154,7 @@
splitting. The :term:`PACKAGES` variable lists all of the packages to be
produced, while the :term:`FILES` variable specifies which files to include
in each package by using an override to specify the package. For
-example, ``FILES_${PN}`` specifies the files to go into the main package
+example, ``FILES:${PN}`` specifies the files to go into the main package
(i.e. the main package has the same name as the recipe and
``${``\ :term:`PN`\ ``}`` evaluates to the
recipe name). The order of the :term:`PACKAGES` value is significant. For
diff --git a/poky/documentation/sdk-manual/intro.rst b/poky/documentation/sdk-manual/intro.rst
index 2f94aaf..802d3f3 100644
--- a/poky/documentation/sdk-manual/intro.rst
+++ b/poky/documentation/sdk-manual/intro.rst
@@ -12,16 +12,6 @@
explains how to use both the Yocto Project extensible and standard
SDKs to develop applications and images.
-.. note::
-
- Prior to the 2.0 Release of the Yocto Project, application
- development was primarily accomplished through the use of the
- Application Development Toolkit (ADT) and the availability of
- stand-alone cross-development toolchains and other tools. With the
- 2.1 Release of the Yocto Project, application development has
- transitioned to within a tool-rich extensible SDK and the more
- traditional standard SDK.
-
All SDKs consist of the following:
- *Cross-Development Toolchain*: This toolchain contains a compiler,
diff --git a/poky/documentation/sphinx-static/switchers.js b/poky/documentation/sphinx-static/switchers.js
index 3972b48..6243724 100644
--- a/poky/documentation/sphinx-static/switchers.js
+++ b/poky/documentation/sphinx-static/switchers.js
@@ -5,7 +5,7 @@
'dev': 'dev (3.4)',
'3.3.2': '3.3.2',
'3.2.4': '3.2.4',
- '3.1.9': '3.1.9',
+ '3.1.10': '3.1.10',
'3.0.4': '3.0.4',
'2.7.4': '2.7.4',
};
diff --git a/poky/documentation/test-manual/reproducible-builds.rst b/poky/documentation/test-manual/reproducible-builds.rst
index c66c82f..68fdf54 100644
--- a/poky/documentation/test-manual/reproducible-builds.rst
+++ b/poky/documentation/test-manual/reproducible-builds.rst
@@ -70,7 +70,7 @@
.. note::
- Because of an open bug in GCC, using ``DISTRO_FEATURES_append = " lto"`` or
+ Because of an open bug in GCC, using ``DISTRO_FEATURES:append = " lto"`` or
adding ``-flto`` (Link Time Optimization) to ``CFLAGS`` makes the resulting
binary non-reproducible, in that it depends on the full absolute build path
to ``recipe-sysroot-native``, so installing the Yocto Project in a different
diff --git a/poky/documentation/test-manual/understand-autobuilder.rst b/poky/documentation/test-manual/understand-autobuilder.rst
index c158d9c..b6809ce 100644
--- a/poky/documentation/test-manual/understand-autobuilder.rst
+++ b/poky/documentation/test-manual/understand-autobuilder.rst
@@ -27,7 +27,7 @@
"TEMPLATE" : "arch-qemu",
"step1" : {
"extravars" : [
- "IMAGE_FSTYPES_append = ' wic wic.bmap'"
+ "IMAGE_FSTYPES:append = ' wic wic.bmap'"
]
}
},
diff --git a/poky/documentation/test-manual/yocto-project-compatible.rst b/poky/documentation/test-manual/yocto-project-compatible.rst
index a789746..96c12ac 100644
--- a/poky/documentation/test-manual/yocto-project-compatible.rst
+++ b/poky/documentation/test-manual/yocto-project-compatible.rst
@@ -115,6 +115,11 @@
user changes a configuration setting to activate the layer, by selecting
a :term:`MACHINE`, a :term:`DISTRO` or a :term:`DISTRO_FEATURES` setting.
+- Layers should be documenting where they don’t support normal "core"
+ functionality such as where debug symbols are disabled or missing, where
+ development headers and on-target library usage may not work or where
+ functionality like the SDK/eSDK would not be expected to work.
+
The project does test the compatibility status of the core project layers on
its :doc:`Autobuilder </test-manual/understand-autobuilder>`.