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/overview-manual/concepts.rst b/poky/documentation/overview-manual/concepts.rst
index 8e0303f..39b8713 100644
--- a/poky/documentation/overview-manual/concepts.rst
+++ b/poky/documentation/overview-manual/concepts.rst
@@ -703,16 +703,12 @@
.. note::
- For every local file (e.g.
- file://
- ) that is part of a recipe's
- SRC_URI
- statement, the OpenEmbedded build system takes a checksum of the file
- for the recipe and inserts the checksum into the signature for the
- do_fetch
- task. If any local file has been modified, the
- do_fetch
- task and all tasks that depend on it are re-executed.
+ For every local file (e.g. ``file://``) that is part of a recipe's
+ :term:`SRC_URI` statement, the OpenEmbedded build system takes a
+ checksum of the file for the recipe and inserts the checksum into
+ the signature for the :ref:`ref-tasks-fetch` task. If any local
+ file has been modified, the :ref:`ref-tasks-fetch` task and all
+ tasks that depend on it are re-executed.
By default, everything is accomplished in the Build Directory, which has
a defined structure. For additional general information on the Build
@@ -892,7 +888,7 @@
looking at shared library dependencies between packages, and looking at
package relationships.
-The ``do_packagedata`` task creates package metadata based on the
+The :ref:`ref-tasks-packagedata` task creates package metadata based on the
analysis such that the build system can generate the final packages. The
:ref:`ref-tasks-populate_sysroot`
task stages (copies) a subset of the files installed by the
@@ -905,7 +901,7 @@
individual packages.
- :term:`PKGDESTWORK`: A
- temporary work area (i.e. ``pkgdata``) used by the ``do_package``
+ temporary work area (i.e. ``pkgdata``) used by the :ref:`ref-tasks-package`
task to save package metadata.
- :term:`PKGDEST`: The parent
@@ -1012,7 +1008,7 @@
the package installation phase since the root filesystem on the target
is read-only.
-The final stages of the ``do_rootfs`` task handle post processing. Post
+The final stages of the :ref:`ref-tasks-rootfs` task handle post processing. Post
processing includes creation of a manifest file and optimizations.
The manifest file (``.manifest``) resides in the same directory as the
@@ -1036,7 +1032,7 @@
variable. This variable specifies a list of functions to call before the
build system creates the final image output files.
-The build system dynamically creates ``do_image_*`` tasks as needed,
+The build system dynamically creates :ref:`do_image_* <ref-tasks-image>` tasks as needed,
based on the image types specified in the
:term:`IMAGE_FSTYPES` variable.
The process turns everything into an image file or a set of image files
@@ -1085,7 +1081,7 @@
For more information on the cross-development toolchain generation,
see the ":ref:`overview-manual/concepts:cross-development toolchain generation`"
section. For information on advantages gained when building a
- cross-development toolchain using the do_populate_sdk task, see the
+ cross-development toolchain using the :ref:`ref-tasks-populate_sdk` task, see the
":ref:`sdk-manual/appendix-obtain:building an sdk installer`" section in
the Yocto Project Application Development and the Extensible Software
Development Kit (eSDK) manual.
@@ -1100,13 +1096,13 @@
see the ":ref:`overview-manual/concepts:application development sdk`"
section.
-The ``do_populate_sdk`` task helps create the standard SDK and handles
+The :ref:`ref-tasks-populate_sdk` task helps create the standard SDK and handles
two parts: a target part and a host part. The target part is the part
built for the target hardware and includes libraries and headers. The
host part is the part of the SDK that runs on the
:term:`SDKMACHINE`.
-The ``do_populate_sdk_ext`` task helps create the extensible SDK and
+The :ref:`ref-tasks-populate_sdk_ext` task helps create the extensible SDK and
handles host and target parts differently than its counter part does for
the standard SDK. For the extensible SDK, the task encapsulates the
build system, which includes everything needed (host and target) for the
@@ -1198,7 +1194,7 @@
In the build system, the common tasks that have setscene variants are
:ref:`ref-tasks-package`,
-``do_package_write_*``,
+:ref:`do_package_write_* <ref-tasks-package_write_deb>`,
:ref:`ref-tasks-deploy`,
:ref:`ref-tasks-packagedata`, and
:ref:`ref-tasks-populate_sysroot`.
@@ -1208,15 +1204,15 @@
The build system has knowledge of the relationship between these tasks
and other preceding tasks. For example, if BitBake runs
``do_populate_sysroot_setscene`` for something, it does not make sense
-to run any of the ``do_fetch``, ``do_unpack``, ``do_patch``,
-``do_configure``, ``do_compile``, and ``do_install`` tasks. However, if
-``do_package`` needs to be run, BitBake needs to run those other tasks.
+to run any of the :ref:`ref-tasks-fetch`, :ref:`ref-tasks-unpack`, :ref:`ref-tasks-patch`,
+:ref:`ref-tasks-configure`, :ref:`ref-tasks-compile`, and :ref:`ref-tasks-install` tasks. However, if
+:ref:`ref-tasks-package` needs to be run, BitBake needs to run those other tasks.
It becomes more complicated if everything can come from an sstate cache
because some objects are simply not required at all. For example, you do
not need a compiler or native tools, such as quilt, if there isn't anything
-to compile or patch. If the ``do_package_write_*`` packages are available
-from sstate, BitBake does not need the ``do_package`` task data.
+to compile or patch. If the :ref:`do_package_write_* <ref-tasks-package_write_deb>` packages are available
+from sstate, BitBake does not need the :ref:`ref-tasks-package` task data.
To handle all these complexities, BitBake runs in two phases. The first
is the "setscene" stage. During this stage, BitBake first checks the
@@ -1801,14 +1797,14 @@
The following list explains the previous example:
-- Adding "do_deploy" to ``SSTATETASKS`` adds some required
+- Adding ``do_deploy`` to ``SSTATETASKS`` adds some required
sstate-related processing, which is implemented in the
:ref:`sstate <ref-classes-sstate>` class, to
before and after the
:ref:`ref-tasks-deploy` task.
- The ``do_deploy[sstate-inputdirs] = "${DEPLOYDIR}"`` declares that
- ``do_deploy`` places its output in ``${DEPLOYDIR}`` when run normally
+ :ref:`ref-tasks-deploy` places its output in ``${DEPLOYDIR}`` when run normally
(i.e. when not using the sstate cache). This output becomes the input
to the shared state cache.
@@ -1818,15 +1814,15 @@
.. note::
- If ``do_deploy`` is not already in the shared state cache or if its input
+ If :ref:`ref-tasks-deploy` is not already in the shared state cache or if its input
checksum (signature) has changed from when the output was cached, the task
runs to populate the shared state cache, after which the contents of the
shared state cache is copied to ${:term:`DEPLOY_DIR_IMAGE`}. If
- ``do_deploy`` is in the shared state cache and its signature indicates
+ :ref:`ref-tasks-deploy` is in the shared state cache and its signature indicates
that the cached output is still valid (i.e. if no relevant task inputs
have changed), then the contents of the shared state cache copies
directly to ${:term:`DEPLOY_DIR_IMAGE`} by the ``do_deploy_setscene`` task
- instead, skipping the ``do_deploy`` task.
+ instead, skipping the :ref:`ref-tasks-deploy` task.
- The following task definition is glue logic needed to make the
previous settings effective::
@@ -1836,16 +1832,16 @@
}
addtask do_deploy_setscene
- ``sstate_setscene()`` takes the flags above as input and accelerates the ``do_deploy`` task
+ ``sstate_setscene()`` takes the flags above as input and accelerates the :ref:`ref-tasks-deploy` task
through the shared state cache if possible. If the task was
accelerated, ``sstate_setscene()`` returns True. Otherwise, it
- returns False, and the normal ``do_deploy`` task runs. For more
+ returns False, and the normal :ref:`ref-tasks-deploy` task runs. For more
information, see the ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-execution:setscene`"
section in the BitBake User Manual.
- The ``do_deploy[dirs] = "${DEPLOYDIR} ${B}"`` line creates
- ``${DEPLOYDIR}`` and ``${B}`` before the ``do_deploy`` task runs, and
- also sets the current working directory of ``do_deploy`` to ``${B}``.
+ ``${DEPLOYDIR}`` and ``${B}`` before the :ref:`ref-tasks-deploy` task runs, and
+ also sets the current working directory of :ref:`ref-tasks-deploy` to ``${B}``.
For more information, see the ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:variable flags`"
section in the BitBake
User Manual.
@@ -1854,7 +1850,7 @@
In cases where ``sstate-inputdirs`` and ``sstate-outputdirs`` would be
the same, you can use ``sstate-plaindirs``. For example, to preserve the
- ${:term:`PKGD`} and ${:term:`PKGDEST`} output from the ``do_package``
+ ${:term:`PKGD`} and ${:term:`PKGDEST`} output from the :ref:`ref-tasks-package`
task, use the following::
do_package[sstate-plaindirs] = "${PKGD} ${PKGDEST}"
@@ -2101,12 +2097,12 @@
:term:`PRIVATE_LIBS` inside
the package's recipe.
-- ``pcdeps``: During the ``do_package`` task of each recipe, all
+- ``pcdeps``: During the :ref:`ref-tasks-package` task of each recipe, all
pkg-config modules (``*.pc`` files) installed by the recipe are
located. For each module, the package that contains the module is
registered as providing the module. The resulting module-to-package
mapping is saved globally in :term:`PKGDATA_DIR` by the
- ``do_packagedata`` task.
+ :ref:`ref-tasks-packagedata` task.
Simultaneously, all pkg-config modules installed by the recipe are
inspected to see what other pkg-config modules they depend on. A
@@ -2147,7 +2143,7 @@
:term:`ALLOW_EMPTY` variable
for more information.
-The ``do_package`` task depends on the ``do_packagedata`` task of each
+The :ref:`ref-tasks-package` task depends on the :ref:`ref-tasks-packagedata` task of each
recipe in :term:`DEPENDS` through use
of a ``[``\ :ref:`deptask <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:variable flags>`\ ``]``
declaration, which guarantees that the required
@@ -2162,8 +2158,8 @@
:ref:`ref-tasks-install`,
:ref:`do_package_write* <ref-tasks-package_write_deb>`,
:ref:`ref-tasks-rootfs`, and
-:ref:`do_image* <ref-tasks-image>`). For example,
-the ``do_install`` task benefits from being able to set the UID and GID
+:ref:`do_image_* <ref-tasks-image>`). For example,
+the :ref:`ref-tasks-install` task benefits from being able to set the UID and GID
of installed files to arbitrary values.
One approach to allowing tasks to perform root-only operations would be