diff options
| author | Patrick Williams <patrick@stwcx.xyz> | 2021-08-16 22:03:13 +0300 |
|---|---|---|
| committer | Patrick Williams <patrick@stwcx.xyz> | 2021-08-17 03:53:26 +0300 |
| commit | 0ca19ccf045e022d8a24d26afbf346ab7f2f519f (patch) | |
| tree | 2732b2bd7700fba730c034a547a2e0751696f2ce /poky/documentation | |
| parent | 23ca3ffa9de533fecc0fcd48fea85e365c323370 (diff) | |
| download | openbmc-0ca19ccf045e022d8a24d26afbf346ab7f2f519f.tar.xz | |
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
Diffstat (limited to 'poky/documentation')
26 files changed, 483 insertions, 368 deletions
diff --git a/poky/documentation/bsp-guide/bsp.rst b/poky/documentation/bsp-guide/bsp.rst index 5f62376d6..b80354a05 100644 --- a/poky/documentation/bsp-guide/bsp.rst +++ b/poky/documentation/bsp-guide/bsp.rst @@ -1042,7 +1042,7 @@ also supports several other machines: #. 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 @@ located in the layer ``poky/meta-yocto-bsp/conf/machine`` and is named 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 @@ kernel recipe (i.e. ``linux-yocto_5.0.bb``), which is located in 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" - - 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" - - 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" + 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" + + 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" + + 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 6c6458fed..8e15fdc86 100644 --- a/poky/documentation/conf.py +++ b/poky/documentation/conf.py @@ -28,7 +28,7 @@ release = current_version # -- 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 7fa0df4d3..7f51674a9 100644 --- a/poky/documentation/dev-manual/common-tasks.rst +++ b/poky/documentation/dev-manual/common-tasks.rst @@ -207,37 +207,37 @@ following list: 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 @@ following list: 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 @@ file. During the processing of each ``conf/layer.conf`` file, BitBake 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 @@ have to manually merge changes as they occur. 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 @@ does not have a corresponding recipe with a matching name. See the :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 @@ Following is the append file, which is named ``formfactor_0.0.bbappend`` 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 @@ important as it ensures that items in the list remain colon-separated. .. 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 @@ important as it ensures that items in the list remain colon-separated. 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 @@ variable changes are in effect for every build and consequently affect 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 @@ the full packagegroup name ``packagegroup-custom``:: ${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 @@ configuration file. Use the following in an append file:: 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 @@ Another point of interest is that if you unset the variable, the image 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 @@ package for a recipe has the same name as the recipe, and the recipe's 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 @@ the software being built: 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 @@ additional definitions in your recipe. 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 @@ take. The following list describes the process: 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 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 @@ PACKAGENAME. A post-installation function has the following structure:: - pkg_postinst_PACKAGENAME() { + pkg_postinst:PACKAGENAME() { # Commands to carry out } @@ -2300,7 +2309,7 @@ compiler. For example, the application might need an additional header 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 @@ In the following example, ``mtd-utils`` is a makefile-based package:: 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 @@ into separate packages:: 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 @@ configure and compile steps as well as sets things up to grab packages 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 @@ doing the following: - 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 @@ chapter of the BitBake User Manual. 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 @@ in the BitBake User Manual. 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 @@ in the BitBake User Manual. 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 @@ in the BitBake User Manual. 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 @@ in the BitBake User Manual. 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 @@ The following steps describe how to set up the AUH utility: 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 @@ point to your external source code. Here are the statements to put in 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 @@ some other nominated directory, you can set :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 @@ that can help you speed up the build: exceptions:: STATICLIBCONF = "--disable-static" - STATICLIBCONF_sqlite3-native = "" + STATICLIBCONF:sqlite3-native = "" EXTRA_OECONF += "${STATICLIBCONF}" .. note:: @@ -4578,7 +4587,7 @@ can control which static library files (``*.a`` files) get included in 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 @@ how the static library files are defined:: 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 @@ how the static library files are defined:: ${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 @@ configuration would be as follows:: 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 @@ Here are the implementation details for the RPM Package Management System: :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 @@ Here are the implementation details for the IPK Package Management System: - 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 @@ configuration file as follows:: 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 @@ layer. The following steps provide some more detail: - 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 @@ function in your recipe. The ``do_split_packages`` function searches for 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 @@ optional arguments:: 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 @@ To add package testing to your build, add the 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 @@ test. Here is what you have to do for each recipe: 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 @@ The ``devtool edit-recipe`` command lets you take a look at the recipe:: " 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 @@ The variable can be used in multiple ways, including using suffixes to 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 @@ Using systemd Exclusively 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 @@ Using systemd for the Main Image and Using SysVinit for the Rescue Image 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 @@ the recipe needs to reference 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 @@ configuration file contains the line:: 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 @@ It is very important that you make sure all post-Installation (``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 @@ output from this command:: $ 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 @@ Here are some things to keep in mind when running tests: - 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 @@ In addition to variable values, the output of the ``bitbake -e`` and - 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 @@ To run a ``debuginfod`` server, you need to do the following: (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 @@ debugger. 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 @@ To support this kind of debugging, you need do the following: - 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 @@ Enabling vulnerabily tracking in recipes 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 @@ support, include the "wayland" flag in the :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 871ec8ae7..2dbcca60c 100644 --- a/poky/documentation/kernel-dev/advanced.rst +++ b/poky/documentation/kernel-dev/advanced.rst @@ -69,7 +69,7 @@ to indicate the branch. 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 @@ To include a 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 @@ If the BSP description is in recipe space, you cannot simply list the ``*.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 a97140b0b..d42ca5f99 100644 --- a/poky/documentation/kernel-dev/common.rst +++ b/poky/documentation/kernel-dev/common.rst @@ -416,16 +416,16 @@ home directory: 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 @@ prepending the directory that contains your files to the :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 this example listing might be different than the actual 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 @@ appropriate ``${PN}`` directory in your layer's ``recipes-kernel/linux`` 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 @@ Next, include this 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 @@ that assigns the :term:`KBUILD_DEFCONFIG` variable based on "raspberrypi2" 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 @@ Section. 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 @@ Section. 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 @@ Section. 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 @@ file to "defconfig" (e.g. 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 @@ the kernel's append file within your layer and then add the following 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 @@ build. 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 @@ build. :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 f0a7af37b..5aa702ad6 100644 --- a/poky/documentation/kernel-dev/faq.rst +++ b/poky/documentation/kernel-dev/faq.rst @@ -36,9 +36,9 @@ How do I install/not-install the kernel image on the rootfs? 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 3f980915c..baf3c0837 100644 --- a/poky/documentation/migration-guides/migration-1.4.rst +++ b/poky/documentation/migration-guides/migration-1.4.rst @@ -83,7 +83,7 @@ create an append file for the ``init-ifupdown`` recipe instead, which 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 e1ba4a9a1..11c821265 100644 --- a/poky/documentation/migration-guides/migration-1.5.rst +++ b/poky/documentation/migration-guides/migration-1.5.rst @@ -144,7 +144,7 @@ Shortened Git ``SRCREV`` Values 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 6fa1ab20c..e83e936b7 100644 --- a/poky/documentation/migration-guides/migration-3.4.rst +++ b/poky/documentation/migration-guides/migration-3.4.rst @@ -56,6 +56,13 @@ context being specific tasks in that case. Tune overrides are another special 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 4f8e6cb04..c8b89885e 100644 --- a/poky/documentation/overview-manual/concepts.rst +++ b/poky/documentation/overview-manual/concepts.rst @@ -1768,15 +1768,12 @@ It is also worth noting that the end result of these signature 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 @@ dependencies, you must manually declare the dependencies. .. 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 d20a4ab09..7aee9db04 100644 --- a/poky/documentation/overview-manual/yp-intro.rst +++ b/poky/documentation/overview-manual/yp-intro.rst @@ -738,7 +738,7 @@ other build process, in which case the basic functionality can be 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 49905f272..3af023895 100644 --- a/poky/documentation/ref-manual/classes.rst +++ b/poky/documentation/ref-manual/classes.rst @@ -404,6 +404,22 @@ cross-compilation tools used for building SDKs. See the 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 @@ recipe that fetches from an alternative URI (e.g. Git) instead of a 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 @@ Consequently, you need to select the variant of the recipe to use it. 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 @@ sure that all builders start with the same sstate signatures. After 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 @@ the check for symbolic link ``.so`` files in the main package of a 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 @@ Here are the tests you can list with the :term:`WARN_QA` and 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 @@ Here are the tests you can list with the :term:`WARN_QA` and - ``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 @@ a couple different ways: 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 @@ couple different ways: 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 @@ indicate the package to which the value applies. If the value applies to 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 c7322e762..d3a603d4a 100644 --- a/poky/documentation/ref-manual/faq.rst +++ b/poky/documentation/ref-manual/faq.rst @@ -301,7 +301,7 @@ As an example, you could add a specific server for the build system to 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 @@ Finally, consider an example where you are behind an HTTP-only firewall. 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 fc723ccbe..cac9f2f49 100644 --- a/poky/documentation/ref-manual/kickstart.rst +++ b/poky/documentation/ref-manual/kickstart.rst @@ -65,13 +65,17 @@ Here is an example that uses "/" as the mountpoint. The command uses 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``. - -- ``--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``. +- ``--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. 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 @@ the ``part`` and ``partition`` commands: - ``--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 @@ the ``part`` and ``partition`` commands: - ``--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 0ef203c70..c3e40dba5 100644 --- a/poky/documentation/ref-manual/qa-checks.rst +++ b/poky/documentation/ref-manual/qa-checks.rst @@ -223,7 +223,7 @@ Errors and Warnings 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 @@ Errors and Warnings 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 @@ Errors and Warnings  .. _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 @@ Errors and Warnings ``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 @@ Errors and Warnings 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 @@ Errors and Warnings 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 @@ Errors and Warnings .. _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 115094013..7aecda017 100644 --- a/poky/documentation/ref-manual/variables.rst +++ b/poky/documentation/ref-manual/variables.rst @@ -38,9 +38,9 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. "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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. :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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. ``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 @@ system and gives an overview of their function and contents. :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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. ``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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. :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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. (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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. :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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. .. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. ``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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 3ace7c06f..3f9646407 100644 --- a/poky/documentation/releases.rst +++ b/poky/documentation/releases.rst @@ -35,7 +35,8 @@ Release Series 3.1 (dunfell) - :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 9bc70cf55..c619c15e4 100644 --- a/poky/documentation/sdk-manual/appendix-customizing-standard.rst +++ b/poky/documentation/sdk-manual/appendix-customizing-standard.rst @@ -29,6 +29,6 @@ You can include API documentation as well as any other documentation 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 44f4334c2..4eccc28e9 100644 --- a/poky/documentation/sdk-manual/appendix-customizing.rst +++ b/poky/documentation/sdk-manual/appendix-customizing.rst @@ -73,7 +73,7 @@ adjustments: 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 @@ source, you need to do a number of things: 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 @@ within it are available. Having these recipes available increases build 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 fc6b8b9d5..841abac5a 100644 --- a/poky/documentation/sdk-manual/appendix-obtain.rst +++ b/poky/documentation/sdk-manual/appendix-obtain.rst @@ -163,7 +163,7 @@ build the SDK installer. Follow these steps: 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 2cdb06d65..8ef44e39a 100644 --- a/poky/documentation/sdk-manual/extensible.rst +++ b/poky/documentation/sdk-manual/extensible.rst @@ -838,7 +838,7 @@ recipe. 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 @@ subdirectory for each package. Apart from some advanced cases, the 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 2f94aaf87..802d3f3d4 100644 --- a/poky/documentation/sdk-manual/intro.rst +++ b/poky/documentation/sdk-manual/intro.rst @@ -12,16 +12,6 @@ Software Development Kit (eSDK) manual. This manual 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 3972b48a7..6243724da 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 c66c82f86..68fdf547b 100644 --- a/poky/documentation/test-manual/reproducible-builds.rst +++ b/poky/documentation/test-manual/reproducible-builds.rst @@ -70,7 +70,7 @@ things we do within the build system to ensure reproducibility include: .. 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 c158d9ce4..b6809ce7b 100644 --- a/poky/documentation/test-manual/understand-autobuilder.rst +++ b/poky/documentation/test-manual/understand-autobuilder.rst @@ -27,7 +27,7 @@ which looks like:: "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 a7897469f..96c12ac08 100644 --- a/poky/documentation/test-manual/yocto-project-compatible.rst +++ b/poky/documentation/test-manual/yocto-project-compatible.rst @@ -115,6 +115,11 @@ Here are key best practices the program tries to encourage: 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>`. |