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/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: