subtree updates
meta-arm: 0164b4ca7a..13199c55c0:
Adam Johnston (1):
arm-bsp/linux-yocto: Upgrade kernel to v5.19 for N1SDP
Anton Antonov (4):
meta-arm/trusted-services: Use GCC toolchain for specific TS recipes only.
arm/trusted-services: Remove patches merged upstream
arm/trusted-services: Remove remaining patches merged upstream
arm/trusted-services: include documentation
Davidson K (1):
arm-bsp/linux-arm64-ack: make it compatible with gcc-12 for TC
Emekcan (2):
arm-bsp/linux-yocto: update RPMSG_CTRL config for corstone1000
arm-bsp/kernel: Fix TEE driver bug for corstone1000
Jon Mason (3):
CI: trusted services as a feature instead of a machine
CI: cleanups for targets and removed tests
arm-bsp: zephyr removal
Peter Hoyes (1):
arm/lib: Do not log FVP return codes < 0
Ross Burton (2):
arm/optee-spdevkit: remove
CI: restrict compression threading
Rui Miguel Silva (1):
arm-bsp/corstone1000: bump kernel version to 5.19
Rupinderjit Singh (1):
arm: update Android common kernel
Satish Kumar (4):
arm-bsp/u-boot: corstone1000: esrt support
arm-bsp/trusted-firmware-m: corstone1000: bump tfm SHA
arm-bsp/trusted-firmware-m: corstone1000: fix sournce dir of libmetal and openamp
arm-bsp/trusted-firmware-m: corstone1000: secure debug code checkout from yocto
Sumit Garg (2):
arm-toolchain: update Arm GCC to 11.3
external-arm-toolchain: Enable 11.3.rel1 support
Vishnu Banavath (1):
arm-bsp/corstone500: upgrade kernel to v5.19
meta-raspberrypi: 45d56d82b7..fc5f80a47e:
Devendra Tewari (3):
rpi-cmdline: Leave cma value to kernel default
libcamera: Tweak to build for Raspberry Pi
rpi-libcamera-apps: add new recipe
Martin Jansa (1):
lirc: rename bbappend to match 0.10.%
Zygmunt Krynicki (2):
ci: fix typo: unconditionally
ci: fix apparent typo in file patterns
meta-openembedded: ce0b93fc12..6529e5f963:
Alexander Kanavin (3):
python3-cchardet: depend on cython
python3-gevent: make compatible with python 3.11
python3-pybluez: add python 3.11 patch
Anuj Mittal (1):
opencv: fix reproducibility issues
Devendra Tewari (2):
libcamera: Bump SRCREV and add libyaml to DEPENDS
libcamera: Remove boost from DEPENDS
Fabio Estevam (1):
spice: Include aarch64 to COMPATIBLE_HOST
Federico Pellegrin (2):
chrony: add pkgconfig class as pkg-config is explicitly searched for
chrony: correct parameter to configure to disable readline usage
Hao Jiang (1):
mctp: install the .target files
Jiaqing Zhao (1):
openldap: Upgrade 2.5.12 -> 2.5.13
Khem Raj (2):
open62541: Disable lto on riscv/clang
python3-gevent: Upgrade to 22.8.0
Leon Anavi (10):
python3-networkx: Upgrade 2.8.6 -> 2.8.7
python3-coverage: Upgrade 6.4.4 -> 6.5.0
python3-rdflib: Upgrade 6.1.1 -> 6.2.0
python3-tabulate: Upgrade 0.8.10 -> 0.9.0
python3-imageio: Upgrade 2.22.0 -> 2.22.1
python3-astroid: Upgrade 2.12.10 -> 2.12.11
python3-jsonref: Upgrade 0.2 -> 0.3.0
python3-sentry-sdk: Upgrade 1.5.12 -> 1.9.10
python3-greenlet: Upgrade 1.1.3 -> 1.1.3.post0
python3-xmltodict: Upgrade 0.12.0 -> 0.13.0
Markus Volk (2):
blueman: upgrade 2.2.4 -> 2.3.2
gtkmm3: upgrade 3.24.5 -> 3.24.7
Martin Jansa (2):
re2: fix branch name from master to main
jack: fix compatibility with python-3.11
Mathieu Dubois-Briand (3):
mbedtls: Fix CVE product name
mbedtls: Update to 2.28.1 version
mbedtls: Whitelist CVE-2021-43666, CVE-2021-45451
Matthias Klein (1):
paho-mqtt-c: upgrade 1.3.10 -> 1.3.11
Michael Opdenacker (1):
tio: correct license information
Mingli Yu (1):
mariadb: not use qemu to run cross-compiled binaries
S. Lockwood-Childs (1):
x265: support aarch64
Thomas Perrot (1):
spitools: remove unused BPV variable
Vyacheslav Yurkov (1):
opcua: Add new recipe
Wang Mingyu (20):
ctags: upgrade 5.9.20220925.0 -> 5.9.20221002.0
dnfdragora: upgrade 2.1.2 -> 2.1.3
dool: upgrade 1.0.0 -> 1.1.0
freeglut: upgrade 3.2.1 -> 3.4.0
gspell: upgrade 1.11.1 -> 1.12.0
hwdata: upgrade 0.362 -> 0.363
iperf3: upgrade 3.11 -> 3.12
libnet-dns-perl: upgrade 1.34 -> 1.35
lirc: upgrade 0.10.1 -> 0.10.2
metacity: upgrade 3.44.0 -> 3.46.0
flatbuffers: upgrade 2.0.8 -> 22.9.29
opencl-headers: upgrade 2022.09.23 -> 2022.09.30
php: upgrade 8.1.10 -> 8.1.11
poppler: upgrade 22.09.0 -> 22.10.0
xfstests: upgrade 2022.09.04 -> 2022.09.25
links: upgrade 2.27 -> 2.28
st: upgrade 0.8.5 -> 0.9
python3-requests-toolbelt: upgrade 0.9.1 -> 0.10.0
Add nativesdk-systemd-systemctl as dependency of dnf-plugin-tui
dnf-plugin-tui: Add nativesdk
Yi Zhao (4):
strongswan: upgrade 5.9.7 -> 5.9.8
open-vm-tools: upgrade 11.3.5 -> 12.1.0
dhcp-relay: upgrade 4.4.3 -> 4.4.3-P1
frr: Security fix CVE-2022-37032
zhengrq.fnst (5):
python3-protobuf: upgrade 4.21.6 -> 4.21.7
stunnel: upgrade 5.65 -> 5.66
python3-web3: upgrade 5.31.0 -> 5.31.1
wolfssl: upgrade 5.5.0 -> 5.5.1
python3-xmlschema: upgrade 2.1.0 -> 2.1.1
meta-security: 824d2762f6..e8e7318189:
Armin Kuster (3):
apparmor: update to 3.0.7
libgssglue: update to 0.7
cryptmount: update to 6.0
Michael Haener (1):
tpm: update the linux-yocto rule with the one from sanity-meta-tpm class
poky: 5200799866..3e5faccfaf:
Johan Korsnes (1):
migration guides: 3.4: remove spurious space in example
Lee Chee Yang (1):
migration guides: add release notes for 4.0.4
Michael Opdenacker (35):
manuals: improve initramfs details
manuals: add references to the "do_fetch" task
manuals: add reference to the "do_install" task
manuals: add references to the "do_build" task
manuals: add reference to "do_configure" task
manuals: add reference to the "do_compile" task
manuals: add references to the "do_deploy" task
manuals: add references to the "do_image" task
manuals: add references to the "do_package" task
manuals: add references to the "do_package_qa" task
overview-manual: concepts.rst: add reference to "do_packagedata" task
manuals: add references to the "do_patch" task
manuals: add references to "do_package_write_*" tasks
ref-manual: variables.rst: add reference to "do_populate_lic" task
manuals: add reference to the "do_populate_sdk" task
overview-manual: concepts.rst: add reference to "do_populate_sdk_ext" task
manuals: add references to "do_populate_sysroot" task
manuals: add references to the "do_unpack" task
dev-manual: common-tasks.rst: add reference to "do_clean" task
manuals: add references to the "do_cleanall" task
ref-manual: tasks.rst: add references to the "do_cleansstate" task
manuals: add references to the "do_devshell" task
dev-manual: common-tasks.rst: add reference to "do_listtasks" task
manuals: add references to the "do_bundle_initramfs" task
manuals: add references to the "do_rootfs" task
ref-manual: tasks.rst: add reference to the "do_kernel_checkout" task
manuals: add reference to the "do_kernel_configcheck" task
manuals: add references to the "do_kernel_configme" task
ref-manual: tasks.rst: add reference to the "do_kernel_metadata" task
migration-guides: add reference to the "do_shared_workdir" task
ref-manual: tasks.rst: add reference to the "do_validate_branches" task
ref-manual: tasks.rst: add reference to the "do_image_complete" task
ref-manual: system-requirements: Ubuntu 22.04 now supported
overview-manual: concepts.rst: fix formating and add references
ref-manual/faq.rst: update references to products built with OE / Yocto Project
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: I14d679e25bd1c7545bc2d0f545f876aeb0a333b4
diff --git a/poky/documentation/ref-manual/classes.rst b/poky/documentation/ref-manual/classes.rst
index 11e0d47..5e49613 100644
--- a/poky/documentation/ref-manual/classes.rst
+++ b/poky/documentation/ref-manual/classes.rst
@@ -47,7 +47,7 @@
even if the recipes do not produce architecture-specific output.
Configuring such recipes for all architectures causes the
- ``do_package_write_*`` tasks to
+ :ref:`do_package_write_* <ref-tasks-package_write_deb>` tasks to
have different signatures for the machines with different tunings.
Additionally, unnecessary rebuilds occur every time an image for a
different :term:`MACHINE` is built even when the recipe never changes.
@@ -444,7 +444,7 @@
``devshell.bbclass``
====================
-The ``devshell`` class adds the ``do_devshell`` task. Distribution
+The ``devshell`` class adds the :ref:`ref-tasks-devshell` task. Distribution
policy dictates whether to include this class. See the ":ref:`dev-manual/common-tasks:using a development shell`"
section in the Yocto Project Development Tasks Manual for more
information about using ``devshell``.
@@ -1081,12 +1081,12 @@
might result in host contamination of the build output.
- ``installed-vs-shipped:`` Reports when files have been installed
- within ``do_install`` but have not been included in any package by
+ within :ref:`ref-tasks-install` but have not been included in any package by
way of the :term:`FILES` variable. Files that do not
appear in any package cannot be present in an image later on in the
build process. Ideally, all installed files should be packaged or not
installed at all. These files can be deleted at the end of
- ``do_install`` if the files are not needed in any package.
+ :ref:`ref-tasks-install` if the files are not needed in any package.
- ``invalid-chars:`` Checks that the recipe metadata variables
:term:`DESCRIPTION`,
@@ -1256,9 +1256,9 @@
packages such as ``kernel-vmlinux``.
The ``kernel`` class contains logic that allows you to embed an initial
-RAM filesystem (initramfs) image when you build the kernel image. For
-information on how to build an initramfs, see the
-":ref:`dev-manual/common-tasks:building an initial ram filesystem (initramfs) image`" section in
+RAM filesystem (:term:`Initramfs`) image when you build the kernel image. For
+information on how to build an :term:`Initramfs`, see the
+":ref:`dev-manual/common-tasks:building an initial ram filesystem (Initramfs) image`" section in
the Yocto Project Development Tasks Manual.
Various other classes are used by the ``kernel`` and ``module`` classes
@@ -1339,7 +1339,7 @@
``kernel-fitimage`` and the boot script is optional.
The boot script is specified in the ITS file as a text file containing
U-boot commands. When using a boot script the user should configure the
-U-boot ``do_install`` task to copy the script to sysroot.
+U-boot :ref:`ref-tasks-install` task to copy the script to sysroot.
So the script can be included in the FIT image by the ``kernel-fitimage``
class. At run-time, U-boot CONFIG_BOOTCOMMAND define can be configured to
load the boot script from the FIT image and executes it.
@@ -2401,7 +2401,7 @@
.. note::
- The ``setuptools3`` class ``do_compile()`` task now calls
+ The ``setuptools3`` class :ref:`ref-tasks-compile` task now calls
``setup.py bdist_wheel`` to build the ``wheel`` binary archive format
(See `PEP-427 <https://www.python.org/dev/peps/pep-0427/>`__).
@@ -2412,7 +2412,7 @@
.. note::
- The ``setuptools3`` class ``do_install()`` task now installs the ``wheel``
+ The ``setuptools3`` class :ref:`ref-tasks-install` task now installs the ``wheel``
binary archive. In current versions of ``setuptools`` the legacy ``setup.py
install`` method is deprecated. If the ``setup.py`` cannot be used with
wheels, for example it creates files outside of the Python module or
@@ -2527,7 +2527,7 @@
want to share with other recipes that have dependencies on the
originating recipe. Normally these dependencies are installed through
the :ref:`ref-tasks-install` task into
- ``${``\ :term:`D`\ ``}``. The ``do_populate_sysroot`` task
+ ``${``\ :term:`D`\ ``}``. The :ref:`ref-tasks-populate_sysroot` task
copies a subset of these files into ``${SYSROOT_DESTDIR}``. This
subset of files is controlled by the
:term:`SYSROOT_DIRS`,
diff --git a/poky/documentation/ref-manual/faq.rst b/poky/documentation/ref-manual/faq.rst
index 6104952..af49d57 100644
--- a/poky/documentation/ref-manual/faq.rst
+++ b/poky/documentation/ref-manual/faq.rst
@@ -54,13 +54,10 @@
**Q:** Are there any products built using the OpenEmbedded build system?
-**A:** The software running on the `Vernier
-LabQuest <https://vernier.com/labquest/>`__ is built using the
-OpenEmbedded build system. See the `Vernier
-LabQuest <https://www.vernier.com/products/interfaces/labq/>`__ website
-for more information. There are a number of pre-production devices using
-the OpenEmbedded build system and the Yocto Project team announces them
-as soon as they are released.
+**A:** See :yocto_wiki:`Products that use the Yocto Project
+</Project_Users#Products_that_use_the_Yocto_Project>` in the Yocto Project
+Wiki. Don't hesitate to contribute to this page if you know other such
+products.
**Q:** What does the OpenEmbedded build system produce as output?
@@ -437,7 +434,7 @@
**Q:** The files provided by my ``*-native`` recipe do not appear to be
available to other recipes. Files are missing from the native sysroot,
my recipe is installing to the wrong place, or I am getting permissions
-errors during the do_install task in my recipe! What is wrong?
+errors during the :ref:`ref-tasks-install` task in my recipe! What is wrong?
**A:** This situation results when a build system does not recognize the
environment variables supplied to it by :term:`BitBake`. The
diff --git a/poky/documentation/ref-manual/images.rst b/poky/documentation/ref-manual/images.rst
index 31fb567..4b771d0 100644
--- a/poky/documentation/ref-manual/images.rst
+++ b/poky/documentation/ref-manual/images.rst
@@ -78,11 +78,11 @@
libraries you can use in a host development environment.
- ``core-image-minimal-initramfs``: A ``core-image-minimal`` image that
- has the Minimal RAM-based Initial Root Filesystem (initramfs) as part
+ has the Minimal RAM-based Initial Root Filesystem (:term:`Initramfs`) as part
of the kernel, which allows the system to find the first "init"
program more efficiently. See the
:term:`PACKAGE_INSTALL` variable for
- additional information helpful when working with initramfs images.
+ additional information helpful when working with :term:`Initramfs` images.
- ``core-image-minimal-mtdutils``: A ``core-image-minimal`` image that
has support for the Minimal MTD Utilities, which let the user
@@ -121,7 +121,7 @@
section in the Yocto Project Development Tasks Manual.
- ``core-image-testmaster-initramfs``: A RAM-based Initial Root
- Filesystem (initramfs) image tailored for use with the
+ Filesystem (:term:`Initramfs`) image tailored for use with the
``core-image-testmaster`` image.
- ``core-image-weston``: A very basic Wayland image with a terminal.
diff --git a/poky/documentation/ref-manual/qa-checks.rst b/poky/documentation/ref-manual/qa-checks.rst
index fbab1dc..9455bec 100644
--- a/poky/documentation/ref-manual/qa-checks.rst
+++ b/poky/documentation/ref-manual/qa-checks.rst
@@ -162,7 +162,7 @@
normally expected to be empty (such as ``/tmp``). These files may
be more appropriately installed to a different location, or
perhaps alternatively not installed at all, usually by updating the
- ``do_install`` task/function.
+ :ref:`ref-tasks-install` task/function.
.. _qa-check-arch:
@@ -536,7 +536,7 @@
in (e.g. ``FILES:${``\ :term:`PN`\ ``}`` for the main
package).
- - Delete the files at the end of the ``do_install`` task if the
+ - Delete the files at the end of the :ref:`ref-tasks-install` task if the
files are not needed in any package.
@@ -582,7 +582,7 @@
``${datadir}/mime/packages``) and yet does not inherit the mime
class which will ensure that these get properly installed. Either
add ``inherit mime`` to the recipe or remove the files at the
- ``do_install`` step if they are not needed.
+ :ref:`ref-tasks-install` step if they are not needed.
.. _qa-check-mime-xdg:
@@ -592,7 +592,7 @@
The specified package contains a .desktop file with a 'MimeType' key
present, but does not inherit the mime-xdg class that is required in
order for that to be activated. Either add ``inherit mime`` to the
- recipe or remove the files at the ``do_install`` step if they are not
+ recipe or remove the files at the :ref:`ref-tasks-install` step if they are not
needed.
@@ -667,8 +667,8 @@
If ``usrmerge`` is in :term:`DISTRO_FEATURES`, this check will ensure that no package
installs files to root (``/bin``, ``/sbin``, ``/lib``, ``/lib64``) directories. If you are seeing this
- message, it indicates that the ``do_install`` step (or perhaps the build process that
- ``do_install`` is calling into, e.g. ``make install`` is using hardcoded paths instead
+ message, it indicates that the :ref:`ref-tasks-install` step (or perhaps the build process that
+ :ref:`ref-tasks-install` is calling into, e.g. ``make install`` is using hardcoded paths instead
of the variables set up for this (``bindir``, ``sbindir``, etc.), and should be
changed so that it does.
@@ -677,7 +677,7 @@
- ``Fuzz detected: <patch output> [patch-fuzz]``
- This check looks for evidence of "fuzz" when applying patches within the ``do_patch``
+ This check looks for evidence of "fuzz" when applying patches within the :ref:`ref-tasks-patch`
task. Patch fuzz is a situation when the ``patch`` tool ignores some of the context
lines in order to apply the patch. Consider this example:
diff --git a/poky/documentation/ref-manual/structure.rst b/poky/documentation/ref-manual/structure.rst
index 429f81e..533745b 100644
--- a/poky/documentation/ref-manual/structure.rst
+++ b/poky/documentation/ref-manual/structure.rst
@@ -630,7 +630,7 @@
split into individual packages.
- ``${WORKDIR}/packages-split``: Contains the output of the
- ``do_package`` task after the output has been split into individual
+ :ref:`ref-tasks-package` task after the output has been split into individual
packages. There are subdirectories for each individual package created by
the recipe.
diff --git a/poky/documentation/ref-manual/system-requirements.rst b/poky/documentation/ref-manual/system-requirements.rst
index 62da1bf..acc97c9 100644
--- a/poky/documentation/ref-manual/system-requirements.rst
+++ b/poky/documentation/ref-manual/system-requirements.rst
@@ -41,6 +41,8 @@
- Ubuntu 20.04 (LTS)
+- Ubuntu 22.04 (LTS)
+
- Fedora 34
- Fedora 35
diff --git a/poky/documentation/ref-manual/tasks.rst b/poky/documentation/ref-manual/tasks.rst
index cb08a75..d4408d1 100644
--- a/poky/documentation/ref-manual/tasks.rst
+++ b/poky/documentation/ref-manual/tasks.rst
@@ -36,7 +36,7 @@
The default behavior of this task is to run the ``oe_runmake`` function
if a makefile (``Makefile``, ``makefile``, or ``GNUmakefile``) is found.
-If no such file is found, the ``do_compile`` task does nothing.
+If no such file is found, the :ref:`ref-tasks-compile` task does nothing.
.. _ref-tasks-compile_ptest_base:
@@ -58,7 +58,7 @@
makefile (``Makefile``, ``makefile``, or ``GNUmakefile``) is found and
:term:`CLEANBROKEN` is not set to "1". If no such
file is found or the :term:`CLEANBROKEN` variable is set to "1", the
-``do_configure`` task does nothing.
+:ref:`ref-tasks-configure` task does nothing.
.. _ref-tasks-configure_ptest_base:
@@ -81,7 +81,7 @@
:ref:`deploy <ref-classes-deploy>` class and should write the output
to ``${``\ :term:`DEPLOYDIR`\ ``}``, which is not to be
confused with ``${DEPLOY_DIR}``. The :ref:`deploy <ref-classes-deploy>` class sets up
-``do_deploy`` as a shared state (sstate) task that can be accelerated
+:ref:`ref-tasks-deploy` as a shared state (sstate) task that can be accelerated
through sstate use. The sstate mechanism takes care of copying the
output from ``${DEPLOYDIR}`` to ``${DEPLOY_DIR_IMAGE}``.
@@ -90,14 +90,14 @@
Do not write the output directly to ``${DEPLOY_DIR_IMAGE}``, as this causes
the sstate mechanism to malfunction.
-The ``do_deploy`` task is not added as a task by default and
+The :ref:`ref-tasks-deploy` task is not added as a task by default and
consequently needs to be added manually. If you want the task to run
after :ref:`ref-tasks-compile`, you can add it by doing
the following::
addtask deploy after do_compile
-Adding ``do_deploy`` after other tasks works the same way.
+Adding :ref:`ref-tasks-deploy` after other tasks works the same way.
.. note::
@@ -110,7 +110,7 @@
See the ":ref:`bitbake-user-manual/bitbake-user-manual-execution:dependencies`"
section in the BitBake User Manual for more information.
-If the ``do_deploy`` task re-executes, any previous output is removed
+If the :ref:`ref-tasks-deploy` task re-executes, any previous output is removed
(i.e. "cleaned").
.. _ref-tasks-fetch:
@@ -128,15 +128,15 @@
``do_image``
------------
-Starts the image generation process. The ``do_image`` task runs after
+Starts the image generation process. The :ref:`ref-tasks-image` task runs after
the OpenEmbedded build system has run the
:ref:`ref-tasks-rootfs` task during which packages are
identified for installation into the image and the root filesystem is
created, complete with post-processing.
-The ``do_image`` task performs pre-processing on the image through the
+The :ref:`ref-tasks-image` task performs pre-processing on the image through the
:term:`IMAGE_PREPROCESS_COMMAND` and
-dynamically generates supporting ``do_image_*`` tasks as needed.
+dynamically generates supporting :ref:`do_image_* <ref-tasks-image>` tasks as needed.
For more information on image creation, see the ":ref:`overview-manual/concepts:image generation`"
section in the Yocto Project Overview and Concepts Manual.
@@ -146,13 +146,13 @@
``do_image_complete``
---------------------
-Completes the image generation process. The ``do_image_complete`` task
+Completes the image generation process. The :ref:`do_image_complete <ref-tasks-image-complete>` task
runs after the OpenEmbedded build system has run the
:ref:`ref-tasks-image` task during which image
-pre-processing occurs and through dynamically generated ``do_image_*``
+pre-processing occurs and through dynamically generated :ref:`do_image_* <ref-tasks-image>`
tasks the image is constructed.
-The ``do_image_complete`` task performs post-processing on the image
+The :ref:`do_image_complete <ref-tasks-image-complete>` task performs post-processing on the image
through the
:term:`IMAGE_POSTPROCESS_COMMAND`.
@@ -168,9 +168,9 @@
Copies files that are to be packaged into the holding area
``${``\ :term:`D`\ ``}``. This task runs with the current
working directory set to ``${``\ :term:`B`\ ``}``, which is the
-compilation directory. The ``do_install`` task, as well as other tasks
+compilation directory. The :ref:`ref-tasks-install` task, as well as other tasks
that either directly or indirectly depend on the installed files (e.g.
-:ref:`ref-tasks-package`, ``do_package_write_*``, and
+:ref:`ref-tasks-package`, :ref:`do_package_write_* <ref-tasks-package_write_deb>`, and
:ref:`ref-tasks-rootfs`), run under
:ref:`fakeroot <overview-manual/concepts:fakeroot and pseudo>`.
@@ -212,7 +212,7 @@
:term:`PACKAGES` and :term:`FILES`
variables.
-The ``do_package`` task, in conjunction with the
+The :ref:`ref-tasks-package` task, in conjunction with the
:ref:`ref-tasks-packagedata` task, also saves some
important package metadata. For additional information, see the
:term:`PKGDESTWORK` variable and the
@@ -327,7 +327,7 @@
"
Conversely, if you have a file whose file type is ``.patch`` or ``.diff``
-and you want to exclude it so that the ``do_patch`` task does not apply
+and you want to exclude it so that the :ref:`ref-tasks-patch` task does not apply
it during the patch phase, you can use the "apply=no" parameter with the
:term:`SRC_URI` statement::
@@ -392,7 +392,7 @@
these variables inside your recipe if you need to make additional (or
fewer) directories available to other recipes at build time.
-The ``do_populate_sysroot`` task is a shared state (sstate) task, which
+The :ref:`ref-tasks-populate_sysroot` task is a shared state (sstate) task, which
means that the task can be accelerated through sstate use. Realize also
that if the task is re-executed, any previous output is removed (i.e.
"cleaned").
@@ -447,7 +447,7 @@
------------
Removes all output files for a target from the
-:ref:`ref-tasks-unpack` task forward (i.e. ``do_unpack``,
+:ref:`ref-tasks-unpack` task forward (i.e. :ref:`ref-tasks-unpack`,
:ref:`ref-tasks-configure`,
:ref:`ref-tasks-compile`,
:ref:`ref-tasks-install`, and
@@ -473,7 +473,7 @@
Removes all output files, shared state
(:ref:`sstate <overview-manual/concepts:shared state cache>`) cache, and
downloaded source files for a target (i.e. the contents of
-:term:`DL_DIR`). Essentially, the ``do_cleanall`` task is
+:term:`DL_DIR`). Essentially, the :ref:`ref-tasks-cleanall` task is
identical to the :ref:`ref-tasks-cleansstate` task
with the added removal of downloaded source files.
@@ -481,7 +481,7 @@
$ bitbake -c cleanall recipe
-Typically, you would not normally use the ``cleanall`` task. Do so only
+Typically, you would not normally use the :ref:`ref-tasks-cleanall` task. Do so only
if you want to start fresh with the :ref:`ref-tasks-fetch`
task.
@@ -492,7 +492,7 @@
Removes all output files and shared state
(:ref:`sstate <overview-manual/concepts:shared state cache>`) cache for a
-target. Essentially, the ``do_cleansstate`` task is identical to the
+target. Essentially, the :ref:`ref-tasks-cleansstate` task is identical to the
:ref:`ref-tasks-clean` task with the added removal of
shared state (:ref:`sstate <overview-manual/concepts:shared state cache>`)
cache.
@@ -501,13 +501,13 @@
$ bitbake -c cleansstate recipe
-When you run the ``do_cleansstate`` task, the OpenEmbedded build system
+When you run the :ref:`ref-tasks-cleansstate` task, the OpenEmbedded build system
no longer uses any sstate. Consequently, building the recipe from
scratch is guaranteed.
.. note::
- The ``do_cleansstate`` task cannot remove sstate from a remote sstate
+ The :ref:`ref-tasks-cleansstate` task cannot remove sstate from a remote sstate
mirror. If you need to build a target from scratch using remote mirrors, use
the "-f" option as follows::
@@ -575,10 +575,8 @@
``do_bundle_initramfs``
-----------------------
-Combines an initial RAM disk (initramfs) image and kernel together to
-form a single image. The
-:term:`CONFIG_INITRAMFS_SOURCE` variable
-has some more information about these types of images.
+Combines an :term:`Initramfs` image and kernel together to
+form a single image.
.. _ref-tasks-rootfs:
@@ -657,7 +655,7 @@
Converts the newly unpacked kernel source into a form with which the
OpenEmbedded build system can work. Because the kernel source can be
-fetched in several different ways, the ``do_kernel_checkout`` task makes
+fetched in several different ways, the :ref:`ref-tasks-kernel_checkout` task makes
sure that subsequent tasks are given a clean working tree copy of the
kernel with the correct branches checked out.
@@ -668,7 +666,7 @@
Validates the configuration produced by the
:ref:`ref-tasks-kernel_menuconfig` task. The
-``do_kernel_configcheck`` task produces warnings when a requested
+:ref:`ref-tasks-kernel_configcheck` task produces warnings when a requested
configuration does not appear in the final ``.config`` file or when you
override a policy configuration in a hardware configuration fragment.
You can run this task explicitly and view the output by using the
@@ -686,7 +684,7 @@
----------------------
After the kernel is patched by the :ref:`ref-tasks-patch`
-task, the ``do_kernel_configme`` task assembles and merges all the
+task, the :ref:`ref-tasks-kernel_configme` task assembles and merges all the
kernel config fragments into a merged configuration that can then be
passed to the kernel configuration phase proper. This is also the time
during which user-specified defconfigs are applied if present, and where
@@ -719,7 +717,7 @@
Collects all the features required for a given kernel build, whether the
features come from :term:`SRC_URI` or from Git
-repositories. After collection, the ``do_kernel_metadata`` task
+repositories. After collection, the :ref:`ref-tasks-kernel_metadata` task
processes the features into a series of config fragments and patches,
which can then be applied by subsequent tasks such as
:ref:`ref-tasks-patch` and
@@ -791,4 +789,4 @@
sure that the machine and metadata branches as specified by the
:term:`SRCREV` variables actually exist on the specified
branches. Otherwise, if :term:`AUTOREV` is not being used, the
-``do_validate_branches`` task fails during the build.
+:ref:`ref-tasks-validate_branches` task fails during the build.
diff --git a/poky/documentation/ref-manual/variables.rst b/poky/documentation/ref-manual/variables.rst
index 2971654..1685a26 100644
--- a/poky/documentation/ref-manual/variables.rst
+++ b/poky/documentation/ref-manual/variables.rst
@@ -1242,24 +1242,24 @@
:term:`Source Directory`.
:term:`CONFIG_INITRAMFS_SOURCE`
- Identifies the initial RAM filesystem (initramfs) source files. The
+ Identifies the initial RAM filesystem (:term:`Initramfs`) source files. The
OpenEmbedded build system receives and uses this kernel Kconfig
variable as an environment variable. By default, the variable is set
to null ("").
The :term:`CONFIG_INITRAMFS_SOURCE` can be either a single cpio archive
with a ``.cpio`` suffix or a space-separated list of directories and
- files for building the initramfs image. A cpio archive should contain
- a filesystem archive to be used as an initramfs image. Directories
- should contain a filesystem layout to be included in the initramfs
+ files for building the :term:`Initramfs` image. A cpio archive should contain
+ a filesystem archive to be used as an :term:`Initramfs` image. Directories
+ should contain a filesystem layout to be included in the :term:`Initramfs`
image. Files should contain entries according to the format described
by the ``usr/gen_init_cpio`` program in the kernel tree.
- If you specify multiple directories and files, the initramfs image
+ If you specify multiple directories and files, the :term:`Initramfs` image
will be the aggregate of all of them.
- For information on creating an initramfs, see the
- ":ref:`dev-manual/common-tasks:building an initial ram filesystem (initramfs) image`" section
+ For information on creating an :term:`Initramfs`, see the
+ ":ref:`dev-manual/common-tasks:building an initial ram filesystem (Initramfs) image`" section
in the Yocto Project Development Tasks Manual.
:term:`CONFIG_SITE`
@@ -1620,7 +1620,7 @@
the appropriate staging sysroot, given by the
:term:`STAGING_DIR* <STAGING_DIR>` variables, by the time the
:ref:`ref-tasks-configure` task for ``foo`` runs.
- This mechanism is implemented by having ``do_configure`` depend on
+ This mechanism is implemented by having :ref:`ref-tasks-configure` depend on
the :ref:`ref-tasks-populate_sysroot` task of
each recipe listed in :term:`DEPENDS`, through a
``[``\ :ref:`deptask <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:variable flags>`\ ``]``
@@ -3182,10 +3182,10 @@
image, do not use the :term:`IMAGE_INSTALL` variable to specify
packages for installation. Instead, use the
:term:`PACKAGE_INSTALL` variable, which
- allows the initial RAM filesystem (initramfs) recipe to use a
+ allows the initial RAM filesystem (:term:`Initramfs`) recipe to use a
fixed set of packages and not be affected by :term:`IMAGE_INSTALL`.
- For information on creating an initramfs, see the
- ":ref:`dev-manual/common-tasks:building an initial ram filesystem (initramfs) image`"
+ For information on creating an :term:`Initramfs`, see the
+ ":ref:`dev-manual/common-tasks:building an initial ram filesystem (Initramfs) image`"
section in the Yocto Project Development Tasks Manual.
- Using :term:`IMAGE_INSTALL` with the
@@ -3265,7 +3265,7 @@
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,
- this is typically cleared in initramfs image recipes.
+ this is typically cleared in :term:`Initramfs` image recipes.
:term:`IMAGE_OVERHEAD_FACTOR`
Defines a multiplier that the build system applies to the initial
@@ -3632,37 +3632,79 @@
even if the toolchain's binaries are strippable, there are other files
needed for the build that are not strippable.
+ :term:`Initramfs`
+ An Initial RAM Filesystem (:term:`Initramfs`) is an optionally compressed
+ `cpio <https://en.wikipedia.org/wiki/Cpio>`__ archive which is extracted
+ by the Linux kernel into RAM in a special `tmpfs <https://en.wikipedia.org/wiki/Tmpfs>`__
+ instance, used as the initial root filesystem.
+
+ This is a replacement for the legacy init RAM disk ("initrd")
+ technique, booting on an emulated block device in RAM, but being less
+ efficient because of the overhead of going through a filesystem and
+ having to duplicate accessed file contents in the file cache in RAM,
+ as for any block device.
+
+ .. note:
+
+ As far as bootloaders are concerned, :term:`Initramfs` and "initrd"
+ images are still copied to RAM in the same way. That's why most
+ most bootloaders refer to :term:`Initramfs` images as "initrd"
+ or "init RAM disk".
+
+ This kind of mechanism is typically used for two reasons:
+
+ - For booting the same kernel binary on multiple systems requiring
+ different device drivers. The Initramfs image is then customized
+ for each type of system, to include the specific kernel modules
+ necessary to access the final root filesystem. This technique
+ is used on all GNU / Linux distributions for desktops and servers.
+
+ - For booting faster. As the root filesystem is extracted into RAM,
+ accessing the first user-space applications is very fast, compared
+ to having to initialize a block device, to access multiple blocks
+ from it, and to go through a filesystem having its own overhead.
+ For example, this allows to display a splashscreen very early,
+ and to later take care of mounting the final root filesystem and
+ loading less time-critical kernel drivers.
+
+ This cpio archive can either be loaded to RAM by the bootloader,
+ or be included in the kernel binary.
+
+ For information on creating and using an :term:`Initramfs`, see the
+ ":ref:`dev-manual/common-tasks:building an initial ram filesystem (Initramfs) image`"
+ section in the Yocto Project Development Tasks Manual.
+
:term:`INITRAMFS_DEPLOY_DIR_IMAGE`
- Indicates the deploy directory used by ``do_bundle_initramfs`` where the
+ Indicates the deploy directory used by :ref:`ref-tasks-bundle_initramfs` where the
:term:`INITRAMFS_IMAGE` will be fetched from.
This variable is set by default to ``${DEPLOY_DIR_IMAGE}`` in the
:ref:`kernel <ref-classes-kernel>` class and it's only meant to be changed
- when building an initramfs image from a separate multiconfig via :term:`INITRAMFS_MULTICONFIG`.
+ when building an :term:`Initramfs` image from a separate multiconfig via :term:`INITRAMFS_MULTICONFIG`.
:term:`INITRAMFS_FSTYPES`
Defines the format for the output image of an initial RAM filesystem
- (initramfs), which is used during boot. Supported formats are the
+ (:term:`Initramfs`), which is used during boot. Supported formats are the
same as those supported by the
:term:`IMAGE_FSTYPES` variable.
The default value of this variable, which is set in the
``meta/conf/bitbake.conf`` configuration file in the
:term:`Source Directory`, is "cpio.gz". The Linux kernel's
- initramfs mechanism, as opposed to the initial RAM filesystem
+ :term:`Initramfs` mechanism, as opposed to the initial RAM filesystem
`initrd <https://en.wikipedia.org/wiki/Initrd>`__ mechanism, expects
an optionally compressed cpio archive.
:term:`INITRAMFS_IMAGE`
Specifies the :term:`PROVIDES` name of an image
- recipe that is used to build an initial RAM filesystem (initramfs)
+ recipe that is used to build an initial RAM filesystem (:term:`Initramfs`)
image. In other words, the :term:`INITRAMFS_IMAGE` variable causes an
additional recipe to be built as a dependency to whatever root
filesystem recipe you might be using (e.g. ``core-image-sato``). The
- initramfs image recipe you provide should set
+ :term:`Initramfs` image recipe you provide should set
:term:`IMAGE_FSTYPES` to
:term:`INITRAMFS_FSTYPES`.
- An initramfs image provides a temporary root filesystem used for
+ An :term:`Initramfs` image provides a temporary root filesystem used for
early system initialization (e.g. loading of modules needed to locate
and mount the "real" root filesystem).
@@ -3670,8 +3712,8 @@
See the ``meta/recipes-core/images/core-image-minimal-initramfs.bb``
recipe in the :term:`Source Directory`
- for an example initramfs recipe. To select this sample recipe as
- the one built to provide the initramfs image, set :term:`INITRAMFS_IMAGE`
+ for an example :term:`Initramfs` recipe. To select this sample recipe as
+ the one built to provide the :term:`Initramfs` image, set :term:`INITRAMFS_IMAGE`
to "core-image-minimal-initramfs".
You can also find more information by referencing the
@@ -3681,13 +3723,13 @@
class to see how to use the :term:`INITRAMFS_IMAGE` variable.
If :term:`INITRAMFS_IMAGE` is empty, which is the default, then no
- initramfs image is built.
+ :term:`Initramfs` image is built.
For more information, you can also see the
:term:`INITRAMFS_IMAGE_BUNDLE`
variable, which allows the generated image to be bundled inside the
- kernel image. Additionally, for information on creating an initramfs
- image, see the ":ref:`dev-manual/common-tasks:building an initial ram filesystem (initramfs) image`" section
+ kernel image. Additionally, for information on creating an :term:`Initramfs`
+ image, see the ":ref:`dev-manual/common-tasks:building an initial ram filesystem (Initramfs) image`" section
in the Yocto Project Development Tasks Manual.
:term:`INITRAMFS_IMAGE_BUNDLE`
@@ -3696,32 +3738,32 @@
extra pass
(:ref:`ref-tasks-bundle_initramfs`) during
kernel compilation in order to build a single binary that contains
- both the kernel image and the initial RAM filesystem (initramfs)
+ both the kernel image and the initial RAM filesystem (:term:`Initramfs`)
image. This makes use of the
:term:`CONFIG_INITRAMFS_SOURCE` kernel
feature.
.. note::
- Bundling the initramfs with the kernel conflates the code in the
- initramfs with the GPLv2 licensed Linux kernel binary. Thus only GPLv2
- compatible software may be part of a bundled initramfs.
+ Bundling the :term:`Initramfs` with the kernel conflates the code in the
+ :term:`Initramfs` with the GPLv2 licensed Linux kernel binary. Thus only GPLv2
+ compatible software may be part of a bundled :term:`Initramfs`.
.. note::
- Using an extra compilation pass to bundle the initramfs avoids a
- circular dependency between the kernel recipe and the initramfs
- recipe should the initramfs include kernel modules. Should that be
- the case, the initramfs recipe depends on the kernel for the
- kernel modules, and the kernel depends on the initramfs recipe
- since the initramfs is bundled inside the kernel image.
+ Using an extra compilation pass to bundle the :term:`Initramfs` avoids a
+ circular dependency between the kernel recipe and the :term:`Initramfs`
+ recipe should the :term:`Initramfs` include kernel modules. Should that be
+ the case, the :term:`Initramfs` recipe depends on the kernel for the
+ kernel modules, and the kernel depends on the :term:`Initramfs` recipe
+ since the :term:`Initramfs` is bundled inside the kernel image.
The combined binary is deposited into the ``tmp/deploy`` directory,
which is part of the :term:`Build Directory`.
Setting the variable to "1" in a configuration file causes the
OpenEmbedded build system to generate a kernel image with the
- initramfs specified in :term:`INITRAMFS_IMAGE` bundled within::
+ :term:`Initramfs` specified in :term:`INITRAMFS_IMAGE` bundled within::
INITRAMFS_IMAGE_BUNDLE = "1"
@@ -3739,7 +3781,7 @@
See the
:yocto_git:`local.conf.sample.extended </poky/tree/meta-poky/conf/templates/default/local.conf.sample.extended>`
file for additional information. Also, for information on creating an
- initramfs, see the ":ref:`dev-manual/common-tasks:building an initial ram filesystem (initramfs) image`" section
+ :term:`Initramfs`, see the ":ref:`dev-manual/common-tasks:building an initial ram filesystem (Initramfs) image`" section
in the Yocto Project Development Tasks Manual.
:term:`INITRAMFS_LINK_NAME`
@@ -3764,7 +3806,7 @@
This allows the kernel to bundle an :term:`INITRAMFS_IMAGE` coming from
a separate multiconfig, this is meant to be used in addition to :term:`INITRAMFS_DEPLOY_DIR_IMAGE`.
- For more information on how to bundle an initramfs image from a separate
+ For more information on how to bundle an :term:`Initramfs` image from a separate
multiconfig see the ":ref:`dev-manual/common-tasks:Bundling an Initramfs Image From a Separate Multiconfig`"
section in the Yocto Project Development Tasks Manual.
@@ -4240,7 +4282,7 @@
:term:`KERNELDEPMODDEPEND` does not control whether or not that data
exists, but simply whether or not it is used. If you do not need to
use the data, set the :term:`KERNELDEPMODDEPEND` variable in your
- ``initramfs`` recipe. Setting the variable there when the data is not
+ :term:`Initramfs` recipe. Setting the variable there when the data is not
needed avoids a potential dependency loop.
:term:`KFEATURE_DESCRIPTION`
@@ -5395,9 +5437,9 @@
:term:`IMAGE_INSTALL` variable to specify
packages for installation. The exception to this is when working with
the :ref:`core-image-minimal-initramfs <ref-manual/images:images>`
- image. When working with an initial RAM filesystem (initramfs) image,
+ image. When working with an initial RAM filesystem (:term:`Initramfs`) image,
use the :term:`PACKAGE_INSTALL` variable. For information on creating an
- initramfs, see the ":ref:`dev-manual/common-tasks:building an initial ram filesystem (initramfs) image`" section
+ :term:`Initramfs`, see the ":ref:`dev-manual/common-tasks:building an initial ram filesystem (Initramfs) image`" section
in the Yocto Project Development Tasks Manual.
:term:`PACKAGE_INSTALL_ATTEMPTONLY`
@@ -5521,7 +5563,7 @@
:ref:`cmake <ref-classes-cmake>` use :term:`PACKAGECONFIG_CONFARGS` to
pass :term:`PACKAGECONFIG` options to ``configure`` and ``cmake``,
respectively. If you are using :term:`PACKAGECONFIG` but not a class that
- handles the ``do_configure`` task, then you need to use
+ handles the :ref:`ref-tasks-configure` task, then you need to use
:term:`PACKAGECONFIG_CONFARGS` appropriately.
:term:`PACKAGEGROUP_DISABLE_COMPLEMENTARY`
@@ -5603,7 +5645,7 @@
.. note::
If the software being built experiences dependency issues during
- the ``do_compile`` task that result in race conditions, you can clear
+ the :ref:`ref-tasks-compile` task that result in race conditions, you can clear
the :term:`PARALLEL_MAKE` variable within the recipe as a workaround. For
information on addressing race conditions, see the
":ref:`dev-manual/common-tasks:debugging parallel make races`"
@@ -5633,7 +5675,7 @@
way to ensure this is to use the ``oe_runmake`` function.
If the software being built experiences dependency issues during
- the ``do_install`` task that result in race conditions, you can
+ the :ref:`ref-tasks-install` task that result in race conditions, you can
clear the :term:`PARALLEL_MAKEINST` variable within the recipe as a
workaround. For information on addressing race conditions, see the
":ref:`dev-manual/common-tasks:debugging parallel make races`"
@@ -6200,7 +6242,7 @@
The practical effect of the above :term:`RDEPENDS` assignment is that
``bar`` and ``baz`` will be declared as dependencies inside the
package ``foo`` when it is written out by one of the
- :ref:`do_package_write_\* <ref-tasks-package_write_deb>` tasks.
+ :ref:`do_package_write_* <ref-tasks-package_write_deb>` tasks.
Exactly how this is done depends on which package format is used,
which is determined by
:term:`PACKAGE_CLASSES`. When the
@@ -6212,7 +6254,7 @@
added. This dependency is from the recipe's
:ref:`ref-tasks-build` (not to be confused with
:ref:`ref-tasks-compile`) task to the
- ``do_package_write_*`` task of the recipes that build ``bar`` and
+ :ref:`do_package_write_* <ref-tasks-package_write_deb>` task of the recipes that build ``bar`` and
``baz``.
The names of the packages you list within :term:`RDEPENDS` must be the
@@ -6709,10 +6751,10 @@
A list of shared state tasks added to the extensible SDK. By default,
the following tasks are added:
- - do_populate_lic
- - do_package_qa
- - do_populate_sysroot
- - do_deploy
+ - :ref:`ref-tasks-populate_lic`
+ - :ref:`ref-tasks-package_qa`
+ - :ref:`ref-tasks-populate_sysroot`
+ - :ref:`ref-tasks-deploy`
Despite the default value of "" for the
:term:`SDK_RECRDEP_TASKS` variable, the above four tasks are always added
@@ -7382,7 +7424,7 @@
For most recipes, this sysroot is the one in which that recipe's
:ref:`ref-tasks-populate_sysroot` task copies
files. Exceptions include ``-native`` recipes, where the
- ``do_populate_sysroot`` task instead uses
+ :ref:`ref-tasks-populate_sysroot` task instead uses
:term:`STAGING_DIR_NATIVE`. Depending on
the type of recipe and the build target, :term:`STAGING_DIR_HOST` can
have the following values: