[PATCH 00/30] manuals: add missing references to tasks

[PATCH 00/30] manuals: add missing references to tasks

[michael.opdenacker]

From: Michael Opdenacker <michael.opdenacker@bootlin.com>

manuals: add missing references to tasks

As suggested by Quentin Schulz on https://bugzilla.yoctoproject.org/show_bug.cgi?id=14508

Michael Opdenacker (30):
  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

 documentation/dev-manual/common-tasks.rst     | 68 +++++++++----------
 documentation/kernel-dev/common.rst           | 10 +--
 .../migration-guides/migration-1.3.rst        |  2 +-
 .../migration-guides/migration-1.7.rst        |  2 +-
 .../migration-guides/migration-1.8.rst        |  4 +-
 .../migration-guides/migration-2.1.rst        | 12 ++--
 .../migration-guides/migration-2.5.rst        |  2 +-
 .../migration-guides/migration-2.6.rst        |  2 +-
 .../migration-guides/migration-3.1.rst        |  2 +-
 .../migration-guides/migration-3.2.rst        |  8 +--
 .../migration-guides/migration-3.4.rst        |  2 +-
 .../migration-guides/migration-4.0.rst        |  6 +-
 .../migration-guides/release-notes-3.4.rst    |  2 +-
 documentation/overview-manual/concepts.rst    | 56 +++++++--------
 documentation/ref-manual/classes.rst          | 16 ++---
 documentation/ref-manual/faq.rst              |  2 +-
 documentation/ref-manual/qa-checks.rst        | 14 ++--
 documentation/ref-manual/structure.rst        |  2 +-
 documentation/ref-manual/tasks.rst            | 52 +++++++-------
 documentation/ref-manual/variables.rst        | 22 +++---
 documentation/sdk-manual/extensible.rst       |  2 +-
 21 files changed, 144 insertions(+), 144 deletions(-)

-- 
2.34.1

[PATCH 01/30] manuals: add references to the "do_fetch" task

[michael.opdenacker]

From: Michael Opdenacker <michael.opdenacker@bootlin.com>

[YOCTO #14508]
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Reported-by: Quentin Schulz <foss@0leil.net>
---
 documentation/dev-manual/common-tasks.rst        | 2 +-
 documentation/migration-guides/migration-3.2.rst | 2 +-
 documentation/migration-guides/migration-4.0.rst | 4 ++--
 documentation/overview-manual/concepts.rst       | 2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/documentation/dev-manual/common-tasks.rst b/documentation/dev-manual/common-tasks.rst
index 559709d6f3..3b25c9f950 100644
--- a/documentation/dev-manual/common-tasks.rst
+++ b/documentation/dev-manual/common-tasks.rst
@@ -9633,7 +9633,7 @@ Running Specific Tasks
 ----------------------
 
 Any given recipe consists of a set of tasks. The standard BitBake
-behavior in most cases is: ``do_fetch``, ``do_unpack``, ``do_patch``,
+behavior in most cases is: :ref:`ref-tasks-fetch`, ``do_unpack``, ``do_patch``,
 ``do_configure``, ``do_compile``, ``do_install``, ``do_package``,
 ``do_package_write_*``, and ``do_build``. The default task is
 ``do_build`` and any tasks on which it depends build first. Some tasks,
diff --git a/documentation/migration-guides/migration-3.2.rst b/documentation/migration-guides/migration-3.2.rst
index 92b7f91f2c..71778f3e26 100644
--- a/documentation/migration-guides/migration-3.2.rst
+++ b/documentation/migration-guides/migration-3.2.rst
@@ -191,7 +191,7 @@ Globbing no longer supported in ``file://`` entries in ``SRC_URI``
 
 Globbing (``*`` and ``?`` wildcards) in ``file://`` URLs within :term:`SRC_URI`
 did not properly support file checksums, thus changes to the source files
-would not always change the do_fetch task checksum, and consequently would
+would not always change the :ref:`ref-tasks-fetch` task checksum, and consequently would
 not ensure that the changed files would be incorporated in subsequent builds.
 
 Unfortunately it is not practical to make globbing work generically here, so
diff --git a/documentation/migration-guides/migration-4.0.rst b/documentation/migration-guides/migration-4.0.rst
index 79e53f89ac..ce3212a464 100644
--- a/documentation/migration-guides/migration-4.0.rst
+++ b/documentation/migration-guides/migration-4.0.rst
@@ -93,8 +93,8 @@ Fetching changes
 
      do_mytask[network] = "1"
 
-  This is allowed by default from ``do_fetch`` but not from any of our other standard
-  tasks. Recipes shouldn't be accessing the network outside of ``do_fetch`` as it
+  This is allowed by default from :ref:`ref-tasks-fetch` but not from any of our other standard
+  tasks. Recipes shouldn't be accessing the network outside of :ref:`ref-tasks-fetch` as it
   usually undermines fetcher source mirroring, image and licence manifests, software
   auditing and supply chain security.
 
diff --git a/documentation/overview-manual/concepts.rst b/documentation/overview-manual/concepts.rst
index 8e0303f0e0..fa060ce0de 100644
--- a/documentation/overview-manual/concepts.rst
+++ b/documentation/overview-manual/concepts.rst
@@ -1208,7 +1208,7 @@ end result.
 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``,
+to run any of the :ref:`ref-tasks-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.
 
-- 
2.34.1

[PATCH 03/30] manuals: add references to the "do_build" task

[michael.opdenacker]

From: Michael Opdenacker <michael.opdenacker@bootlin.com>

[YOCTO #14508]
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Reported-by: Quentin Schulz <foss@0leil.net>
---
 documentation/dev-manual/common-tasks.rst        | 4 ++--
 documentation/migration-guides/migration-3.4.rst | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/documentation/dev-manual/common-tasks.rst b/documentation/dev-manual/common-tasks.rst
index 09304d4b6a..7b20234991 100644
--- a/documentation/dev-manual/common-tasks.rst
+++ b/documentation/dev-manual/common-tasks.rst
@@ -9635,8 +9635,8 @@ Running Specific Tasks
 Any given recipe consists of a set of tasks. The standard BitBake
 behavior in most cases is: :ref:`ref-tasks-fetch`, ``do_unpack``, ``do_patch``,
 ``do_configure``, ``do_compile``, :ref:`ref-tasks-install`, ``do_package``,
-``do_package_write_*``, and ``do_build``. The default task is
-``do_build`` and any tasks on which it depends build first. Some tasks,
+``do_package_write_*``, and :ref:`ref-tasks-build`. The default task is
+:ref:`ref-tasks-build` and any tasks on which it depends build first. Some tasks,
 such as ``do_devshell``, are not part of the default build chain. If you
 wish to run a task that is not part of the default build chain, you can
 use the ``-c`` option in BitBake. Here is an example::
diff --git a/documentation/migration-guides/migration-3.4.rst b/documentation/migration-guides/migration-3.4.rst
index bc2c75d42e..bf0887a8bd 100644
--- a/documentation/migration-guides/migration-3.4.rst
+++ b/documentation/migration-guides/migration-3.4.rst
@@ -206,7 +206,7 @@ Package/recipe splitting
 Image / SDK generation changes
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-- Recursive dependencies on the ``do_build`` task are now disabled when
+- Recursive dependencies on the :ref:`ref-tasks-build` task are now disabled when
   building SDKs. These are generally not needed; in the unlikely event
   that you do encounter problems then it will probably be as a result of
   missing explicit dependencies that need to be added.
-- 
2.34.1

[PATCH 04/30] manuals: add reference to "do_configure" task

[michael.opdenacker]

From: Michael Opdenacker <michael.opdenacker@bootlin.com>

[YOCTO #14508]
Reported-by: Quentin Schulz <foss@0leil.net>
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
---
 documentation/dev-manual/common-tasks.rst        | 6 +++---
 documentation/migration-guides/migration-1.8.rst | 2 +-
 documentation/migration-guides/migration-2.1.rst | 4 ++--
 documentation/migration-guides/migration-2.6.rst | 2 +-
 documentation/overview-manual/concepts.rst       | 2 +-
 documentation/ref-manual/tasks.rst               | 2 +-
 documentation/ref-manual/variables.rst           | 2 +-
 7 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/documentation/dev-manual/common-tasks.rst b/documentation/dev-manual/common-tasks.rst
index 7b20234991..61755dd06e 100644
--- a/documentation/dev-manual/common-tasks.rst
+++ b/documentation/dev-manual/common-tasks.rst
@@ -2551,7 +2551,7 @@ doing the following:
    ``${``\ :term:`S`\ ``}``.
 
    If ``${S}`` might contain a Makefile, or if you inherit some class
-   that replaces ``do_configure`` and ``do_compile`` with custom
+   that replaces :ref:`ref-tasks-configure` and ``do_compile`` with custom
    versions, then you can use the
    ``[``\ :ref:`noexec <bitbake-user-manual/bitbake-user-manual-metadata:variable flags>`\ ``]``
    flag to turn the tasks into no-ops, as follows::
@@ -2881,7 +2881,7 @@ you can use as references.
 If you are creating a new kernel recipe, normal recipe-writing rules
 apply for setting up a :term:`SRC_URI`. Thus, you need to specify any
 necessary patches and set :term:`S` to point at the source code. You need to
-create a ``do_configure`` task that configures the unpacked kernel with
+create a :ref:`ref-tasks-configure` task that configures the unpacked kernel with
 a ``defconfig`` file. You can do this by using a ``make defconfig``
 command or, more commonly, by copying in a suitable ``defconfig`` file
 and then running ``make oldconfig``. By making use of ``inherit kernel``
@@ -9634,7 +9634,7 @@ Running Specific Tasks
 
 Any given recipe consists of a set of tasks. The standard BitBake
 behavior in most cases is: :ref:`ref-tasks-fetch`, ``do_unpack``, ``do_patch``,
-``do_configure``, ``do_compile``, :ref:`ref-tasks-install`, ``do_package``,
+:ref:`ref-tasks-configure`, ``do_compile``, :ref:`ref-tasks-install`, ``do_package``,
 ``do_package_write_*``, and :ref:`ref-tasks-build`. The default task is
 :ref:`ref-tasks-build` and any tasks on which it depends build first. Some tasks,
 such as ``do_devshell``, are not part of the default build chain. If you
diff --git a/documentation/migration-guides/migration-1.8.rst b/documentation/migration-guides/migration-1.8.rst
index 51a13873e2..546c798196 100644
--- a/documentation/migration-guides/migration-1.8.rst
+++ b/documentation/migration-guides/migration-1.8.rst
@@ -128,7 +128,7 @@ when the :ref:`ref-tasks-configure` task needs to be
 re-executed.
 
 One of the improvements is to attempt to run "make clean" during the
-``do_configure`` task if a ``Makefile`` exists. Some software packages
+:ref:`ref-tasks-configure` task if a ``Makefile`` exists. Some software packages
 do not provide a working clean target within their make files. If you
 have such recipes, you need to set
 :term:`CLEANBROKEN` to "1" within the recipe, for example::
diff --git a/documentation/migration-guides/migration-2.1.rst b/documentation/migration-guides/migration-2.1.rst
index b2d8a0b678..bfc600ccca 100644
--- a/documentation/migration-guides/migration-2.1.rst
+++ b/documentation/migration-guides/migration-2.1.rst
@@ -108,12 +108,12 @@ this change should not be a problem. However, if you have a recipe that
 bypasses the standard :ref:`ref-tasks-configure` task
 from the :ref:`autotools <ref-classes-autotools>` class and the software the recipe is building
 uses a very old version of ``autoconf``, the recipe might be incapable
-of determining the correct size of ``off_t`` during ``do_configure``.
+of determining the correct size of ``off_t`` during :ref:`ref-tasks-configure`.
 
 The best course of action is to patch the software as necessary to allow
 the default implementation from the :ref:`autotools <ref-classes-autotools>` class to work such
 that ``autoreconf`` succeeds and produces a working configure script,
-and to remove the overridden ``do_configure`` task such that the default
+and to remove the overridden :ref:`ref-tasks-configure` task such that the default
 implementation does get used.
 
 .. _migration-2.1-image-generation-split-out-from-filesystem-generation:
diff --git a/documentation/migration-guides/migration-2.6.rst b/documentation/migration-guides/migration-2.6.rst
index 11e659de7c..32bb48bccc 100644
--- a/documentation/migration-guides/migration-2.6.rst
+++ b/documentation/migration-guides/migration-2.6.rst
@@ -135,7 +135,7 @@ Fetching these types of dependencies that are not provided in the
 sysroot negatively affects the ability to reproduce builds. This type of
 fetching is now explicitly disabled. Consequently, any missing
 dependencies in Python recipes that use these classes now result in an
-error during the ``do_configure`` task.
+error during the :ref:`ref-tasks-configure` task.
 
 .. _migration-2.6-linux-yocto-configuration-audit-issues-now-correctly-reported:
 
diff --git a/documentation/overview-manual/concepts.rst b/documentation/overview-manual/concepts.rst
index 2e1aa3df48..858118beec 100644
--- a/documentation/overview-manual/concepts.rst
+++ b/documentation/overview-manual/concepts.rst
@@ -1209,7 +1209,7 @@ 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 :ref:`ref-tasks-fetch`, ``do_unpack``, ``do_patch``,
-``do_configure``, ``do_compile``, and :ref:`ref-tasks-install` tasks. However, if
+:ref:`ref-tasks-configure`, ``do_compile``, and :ref:`ref-tasks-install` tasks. However, if
 ``do_package`` needs to be run, BitBake needs to run those other tasks.
 
 It becomes more complicated if everything can come from an sstate cache
diff --git a/documentation/ref-manual/tasks.rst b/documentation/ref-manual/tasks.rst
index f3aebcecc3..16715984ae 100644
--- a/documentation/ref-manual/tasks.rst
+++ b/documentation/ref-manual/tasks.rst
@@ -58,7 +58,7 @@ The default behavior of this task is to run ``oe_runmake clean`` if a
 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:
 
diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst
index 060bf499bb..bc29b5a05b 100644
--- a/documentation/ref-manual/variables.rst
+++ b/documentation/ref-manual/variables.rst
@@ -1620,7 +1620,7 @@ system and gives an overview of their function and contents.
       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>`\ ``]``
-- 
2.34.1

[PATCH 05/30] manuals: add reference to the "do_compile" task

[michael.opdenacker]

From: Michael Opdenacker <michael.opdenacker@bootlin.com>

[YOCTO #14508]
Reported-by: Quentin Schulz <foss@0leil.net>
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
---
 documentation/dev-manual/common-tasks.rst  | 16 ++++++++--------
 documentation/overview-manual/concepts.rst |  2 +-
 documentation/ref-manual/classes.rst       |  2 +-
 documentation/ref-manual/tasks.rst         |  2 +-
 documentation/ref-manual/variables.rst     |  2 +-
 5 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/documentation/dev-manual/common-tasks.rst b/documentation/dev-manual/common-tasks.rst
index 61755dd06e..0b512601e5 100644
--- a/documentation/dev-manual/common-tasks.rst
+++ b/documentation/dev-manual/common-tasks.rst
@@ -1826,8 +1826,8 @@ out-of-tree modules. Your recipe will also need the following::
 Compilation
 -----------
 
-During a build, the ``do_compile`` task happens after source is fetched,
-unpacked, and configured. If the recipe passes through ``do_compile``
+During a build, the :ref:`ref-tasks-compile` task happens after source is fetched,
+unpacked, and configured. If the recipe passes through :ref:`ref-tasks-compile`
 successfully, nothing needs to be done.
 
 However, if the compile step fails, you need to diagnose the failure.
@@ -2337,7 +2337,7 @@ Single .c File Package (Hello World!)
 Building an application from a single file that is stored locally (e.g.
 under ``files``) requires a recipe that has the file listed in the
 :term:`SRC_URI` variable. Additionally, you need to manually write the
-``do_compile`` and :ref:`ref-tasks-install` tasks. The :term:`S` variable defines the
+:ref:`ref-tasks-compile` and :ref:`ref-tasks-install` tasks. The :term:`S` variable defines the
 directory containing the source code, which is set to
 :term:`WORKDIR` in this case --- the
 directory BitBake uses for the build.
@@ -2401,7 +2401,7 @@ Makefile-Based Package
 
 Applications that use GNU ``make`` also require a recipe that has the
 source archive listed in :term:`SRC_URI`. You do not need to add a
-``do_compile`` step since by default BitBake starts the ``make`` command
+:ref:`ref-tasks-compile` step since by default BitBake starts the ``make`` command
 to compile the application. If you need additional ``make`` options, you
 should store them in the
 :term:`EXTRA_OEMAKE` or
@@ -2551,7 +2551,7 @@ doing the following:
    ``${``\ :term:`S`\ ``}``.
 
    If ``${S}`` might contain a Makefile, or if you inherit some class
-   that replaces :ref:`ref-tasks-configure` and ``do_compile`` with custom
+   that replaces :ref:`ref-tasks-configure` and :ref:`ref-tasks-compile` with custom
    versions, then you can use the
    ``[``\ :ref:`noexec <bitbake-user-manual/bitbake-user-manual-metadata:variable flags>`\ ``]``
    flag to turn the tasks into no-ops, as follows::
@@ -3446,7 +3446,7 @@ Follow these general steps:
    you added to the patch.
 
 6. *Test Your Changes:* Once you have modified the source code, the
-   easiest way to test your changes is by calling the ``do_compile``
+   easiest way to test your changes is by calling the :ref:`ref-tasks-compile`
    task as shown in the following example::
 
       $ bitbake -c compile -f package
@@ -9634,7 +9634,7 @@ Running Specific Tasks
 
 Any given recipe consists of a set of tasks. The standard BitBake
 behavior in most cases is: :ref:`ref-tasks-fetch`, ``do_unpack``, ``do_patch``,
-:ref:`ref-tasks-configure`, ``do_compile``, :ref:`ref-tasks-install`, ``do_package``,
+:ref:`ref-tasks-configure`, :ref:`ref-tasks-compile`, :ref:`ref-tasks-install`, ``do_package``,
 ``do_package_write_*``, and :ref:`ref-tasks-build`. The default task is
 :ref:`ref-tasks-build` and any tasks on which it depends build first. Some tasks,
 such as ``do_devshell``, are not part of the default build chain. If you
@@ -9677,7 +9677,7 @@ The following example shows one way you can use the ``-f`` option::
 
 This sequence first builds and then recompiles ``matchbox-desktop``. The
 last command reruns all tasks (basically the packaging tasks) after the
-compile. BitBake recognizes that the ``do_compile`` task was rerun and
+compile. BitBake recognizes that the :ref:`ref-tasks-compile` task was rerun and
 therefore understands that the other tasks also need to be run again.
 
 Another, shorter way to rerun a task and all
diff --git a/documentation/overview-manual/concepts.rst b/documentation/overview-manual/concepts.rst
index 858118beec..06220401bc 100644
--- a/documentation/overview-manual/concepts.rst
+++ b/documentation/overview-manual/concepts.rst
@@ -1209,7 +1209,7 @@ 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 :ref:`ref-tasks-fetch`, ``do_unpack``, ``do_patch``,
-:ref:`ref-tasks-configure`, ``do_compile``, and :ref:`ref-tasks-install` tasks. However, if
+:ref:`ref-tasks-configure`, :ref:`ref-tasks-compile`, and :ref:`ref-tasks-install` tasks. However, if
 ``do_package`` needs to be run, BitBake needs to run those other tasks.
 
 It becomes more complicated if everything can come from an sstate cache
diff --git a/documentation/ref-manual/classes.rst b/documentation/ref-manual/classes.rst
index 6e37738850..076ebb31ae 100644
--- a/documentation/ref-manual/classes.rst
+++ b/documentation/ref-manual/classes.rst
@@ -2401,7 +2401,7 @@ uses these build systems, the recipe needs to inherit the ``setuptools3`` class.
 
    .. 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/>`__).
 
diff --git a/documentation/ref-manual/tasks.rst b/documentation/ref-manual/tasks.rst
index 16715984ae..e5938ee236 100644
--- a/documentation/ref-manual/tasks.rst
+++ b/documentation/ref-manual/tasks.rst
@@ -36,7 +36,7 @@ directory set to ``${``\ :term:`B`\ ``}``.
 
 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:
 
diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst
index bc29b5a05b..8055f044d0 100644
--- a/documentation/ref-manual/variables.rst
+++ b/documentation/ref-manual/variables.rst
@@ -5603,7 +5603,7 @@ system and gives an overview of their function and contents.
       .. 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`"
-- 
2.34.1

[PATCH 06/30] manuals: add references to the "do_deploy" task

[michael.opdenacker]

From: Michael Opdenacker <michael.opdenacker@bootlin.com>

[YOCTO #14508]
Reported-by: Quentin Schulz <foss@0leil.net>
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
---
 .../migration-guides/migration-3.2.rst         |  4 ++--
 documentation/overview-manual/concepts.rst     | 18 +++++++++---------
 documentation/ref-manual/tasks.rst             |  8 ++++----
 documentation/ref-manual/variables.rst         |  2 +-
 4 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/documentation/migration-guides/migration-3.2.rst b/documentation/migration-guides/migration-3.2.rst
index 8a8d19d605..4c0de7b0f6 100644
--- a/documentation/migration-guides/migration-3.2.rst
+++ b/documentation/migration-guides/migration-3.2.rst
@@ -207,9 +207,9 @@ files into a subdirectory and reference that instead.
 deploy class now cleans ``DEPLOYDIR`` before ``do_deploy``
 ----------------------------------------------------------
 
-``do_deploy`` as implemented in the :ref:`deploy <ref-classes-deploy>` class now cleans up ${:term:`DEPLOYDIR`} before running, just as :ref:`ref-tasks-install` cleans up ${:term:`D`} before running. This reduces the risk of :term:`DEPLOYDIR` being accidentally contaminated by files from previous runs, possibly even with different config, in case of incremental builds.
+:ref:`ref-tasks-deploy` as implemented in the :ref:`deploy <ref-classes-deploy>` class now cleans up ${:term:`DEPLOYDIR`} before running, just as :ref:`ref-tasks-install` cleans up ${:term:`D`} before running. This reduces the risk of :term:`DEPLOYDIR` being accidentally contaminated by files from previous runs, possibly even with different config, in case of incremental builds.
 
-Most recipes and classes that inherit the :ref:`deploy <ref-classes-deploy>` class or interact with ``do_deploy`` are unlikely to be affected by this unless they add ``prefuncs`` to ``do_deploy`` *which also* put files into ``${DEPLOYDIR}`` --- these should be refactored to use ``do_deploy_prepend`` instead.
+Most recipes and classes that inherit the :ref:`deploy <ref-classes-deploy>` class or interact with :ref:`ref-tasks-deploy` are unlikely to be affected by this unless they add ``prefuncs`` to :ref:`ref-tasks-deploy` *which also* put files into ``${DEPLOYDIR}`` --- these should be refactored to use ``do_deploy_prepend`` instead.
 
 
 .. _migration-3.2-nativesdk-sdk-provides-dummy:
diff --git a/documentation/overview-manual/concepts.rst b/documentation/overview-manual/concepts.rst
index 06220401bc..f3f8cbd95c 100644
--- a/documentation/overview-manual/concepts.rst
+++ b/documentation/overview-manual/concepts.rst
@@ -1801,14 +1801,14 @@ from the :ref:`deploy <ref-classes-deploy>` class::
 
 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 +1818,15 @@ The following list explains the previous example:
 
    .. 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 +1836,16 @@ The following list explains the previous example:
       }
       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.
diff --git a/documentation/ref-manual/tasks.rst b/documentation/ref-manual/tasks.rst
index e5938ee236..5efe64b35d 100644
--- a/documentation/ref-manual/tasks.rst
+++ b/documentation/ref-manual/tasks.rst
@@ -81,7 +81,7 @@ Recipes implementing this task should inherit the
 :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 @@ output from ``${DEPLOYDIR}`` to ``${DEPLOY_DIR_IMAGE}``.
    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 @@ Adding ``do_deploy`` after other tasks works the same way.
    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:
diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst
index 8055f044d0..8fac7f77ad 100644
--- a/documentation/ref-manual/variables.rst
+++ b/documentation/ref-manual/variables.rst
@@ -6712,7 +6712,7 @@ system and gives an overview of their function and contents.
       - do_populate_lic
       - do_package_qa
       - do_populate_sysroot
-      - do_deploy
+      - :ref:`ref-tasks-deploy`
 
       Despite the default value of "" for the
       :term:`SDK_RECRDEP_TASKS` variable, the above four tasks are always added
-- 
2.34.1

[PATCH 07/30] manuals: add references to the "do_image" task

[michael.opdenacker]

From: Michael Opdenacker <michael.opdenacker@bootlin.com>

[YOCTO #14508]
Reported-by: Quentin Schulz <foss@0leil.net>
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
---
 documentation/dev-manual/common-tasks.rst  | 2 +-
 documentation/overview-manual/concepts.rst | 4 ++--
 documentation/ref-manual/tasks.rst         | 8 ++++----
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/documentation/dev-manual/common-tasks.rst b/documentation/dev-manual/common-tasks.rst
index 0b512601e5..22d1634f1b 100644
--- a/documentation/dev-manual/common-tasks.rst
+++ b/documentation/dev-manual/common-tasks.rst
@@ -3853,7 +3853,7 @@ to be added to the recipe that builds the ``core-image-sato`` image::
    do_image[mcdepends] = "mc:x86:arm:core-image-minimal:do_rootfs"
 
 In this example, the `from_multiconfig` is "x86". The `to_multiconfig` is "arm". The
-task on which the ``do_image`` task in the recipe depends is the
+task on which the :ref:`ref-tasks-image` task in the recipe depends is the
 ``do_rootfs`` task from the ``core-image-minimal`` recipe associated
 with the "arm" multiconfig.
 
diff --git a/documentation/overview-manual/concepts.rst b/documentation/overview-manual/concepts.rst
index f3f8cbd95c..3bb728f990 100644
--- a/documentation/overview-manual/concepts.rst
+++ b/documentation/overview-manual/concepts.rst
@@ -1036,7 +1036,7 @@ the
 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
@@ -2162,7 +2162,7 @@ operations that are normally reserved for the root user (e.g.
 :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,
+: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.
 
diff --git a/documentation/ref-manual/tasks.rst b/documentation/ref-manual/tasks.rst
index 5efe64b35d..63af2730e7 100644
--- a/documentation/ref-manual/tasks.rst
+++ b/documentation/ref-manual/tasks.rst
@@ -128,15 +128,15 @@ module.
 ``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.
@@ -149,7 +149,7 @@ section in the Yocto Project Overview and Concepts Manual.
 Completes the image generation process. The ``do_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
-- 
2.34.1

[PATCH 08/30] manuals: add references to the "do_package" task

[michael.opdenacker]

From: Michael Opdenacker <michael.opdenacker@bootlin.com>

[YOCTO #14508]
Reported-by: Quentin Schulz <foss@0leil.net>
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
---
 documentation/dev-manual/common-tasks.rst  |  6 +++---
 documentation/overview-manual/concepts.rst | 12 ++++++------
 documentation/ref-manual/structure.rst     |  2 +-
 documentation/ref-manual/tasks.rst         |  2 +-
 4 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/documentation/dev-manual/common-tasks.rst b/documentation/dev-manual/common-tasks.rst
index 22d1634f1b..74b050f600 100644
--- a/documentation/dev-manual/common-tasks.rst
+++ b/documentation/dev-manual/common-tasks.rst
@@ -2028,10 +2028,10 @@ Successful packaging is a combination of automated processes performed
 by the OpenEmbedded build system and some specific steps you need to
 take. The following list describes the process:
 
--  *Splitting Files*: The ``do_package`` task splits the files produced
+-  *Splitting Files*: The :ref:`ref-tasks-package` task splits the files produced
    by the recipe into logical components. Even software that produces a
    single binary might still have debug symbols, documentation, and
-   other logical components that should be split out. The ``do_package``
+   other logical components that should be split out. The :ref:`ref-tasks-package`
    task ensures that files are split up and packaged correctly.
 
 -  *Running QA Checks*: The
@@ -9634,7 +9634,7 @@ Running Specific Tasks
 
 Any given recipe consists of a set of tasks. The standard BitBake
 behavior in most cases is: :ref:`ref-tasks-fetch`, ``do_unpack``, ``do_patch``,
-:ref:`ref-tasks-configure`, :ref:`ref-tasks-compile`, :ref:`ref-tasks-install`, ``do_package``,
+:ref:`ref-tasks-configure`, :ref:`ref-tasks-compile`, :ref:`ref-tasks-install`, :ref:`ref-tasks-package`,
 ``do_package_write_*``, and :ref:`ref-tasks-build`. The default task is
 :ref:`ref-tasks-build` and any tasks on which it depends build first. Some tasks,
 such as ``do_devshell``, are not part of the default build chain. If you
diff --git a/documentation/overview-manual/concepts.rst b/documentation/overview-manual/concepts.rst
index 3bb728f990..bbe0ec345b 100644
--- a/documentation/overview-manual/concepts.rst
+++ b/documentation/overview-manual/concepts.rst
@@ -905,7 +905,7 @@ the analysis and package splitting process use several areas:
    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
@@ -1210,13 +1210,13 @@ 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 :ref:`ref-tasks-fetch`, ``do_unpack``, ``do_patch``,
 :ref:`ref-tasks-configure`, :ref:`ref-tasks-compile`, and :ref:`ref-tasks-install` tasks. However, if
-``do_package`` needs to be run, BitBake needs to run those other tasks.
+: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.
+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
@@ -1854,7 +1854,7 @@ The following list explains the previous example:
 
       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,7 +2101,7 @@ dependencies, you must manually declare the dependencies.
    :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
@@ -2147,7 +2147,7 @@ dependencies, you must manually declare the dependencies.
    :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 ``do_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
diff --git a/documentation/ref-manual/structure.rst b/documentation/ref-manual/structure.rst
index 429f81e14c..533745b370 100644
--- a/documentation/ref-manual/structure.rst
+++ b/documentation/ref-manual/structure.rst
@@ -630,7 +630,7 @@ Here are key subdirectories within each recipe work directory:
    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/documentation/ref-manual/tasks.rst b/documentation/ref-manual/tasks.rst
index 63af2730e7..1bb8bc1918 100644
--- a/documentation/ref-manual/tasks.rst
+++ b/documentation/ref-manual/tasks.rst
@@ -212,7 +212,7 @@ based on available packages and files. This task makes use of the
 :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
-- 
2.34.1

[PATCH 09/30] manuals: add references to the "do_package_qa" task

[michael.opdenacker]

From: Michael Opdenacker <michael.opdenacker@bootlin.com>

[YOCTO #14508]
Reported-by: Quentin Schulz <foss@0leil.net>
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
---
 documentation/migration-guides/migration-1.7.rst | 2 +-
 documentation/migration-guides/migration-3.1.rst | 2 +-
 documentation/ref-manual/variables.rst           | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/documentation/migration-guides/migration-1.7.rst b/documentation/migration-guides/migration-1.7.rst
index 8213ab58d9..7b179f2aa1 100644
--- a/documentation/migration-guides/migration-1.7.rst
+++ b/documentation/migration-guides/migration-1.7.rst
@@ -165,7 +165,7 @@ The following changes have occurred to the QA check process:
    more parallel execution. This change is unlikely to be an issue
    except for highly customized recipes that disable packaging tasks
    themselves by marking them as ``noexec``. For those packages, you
-   will need to disable the ``do_package_qa`` task as well.
+   will need to disable the :ref:`ref-tasks-package_qa` task as well.
 
 -  Files being overwritten during the
    :ref:`ref-tasks-populate_sysroot` task now
diff --git a/documentation/migration-guides/migration-3.1.rst b/documentation/migration-guides/migration-3.1.rst
index cc788efeba..a6106eefae 100644
--- a/documentation/migration-guides/migration-3.1.rst
+++ b/documentation/migration-guides/migration-3.1.rst
@@ -234,7 +234,7 @@ Packaging changes
 Additional warnings
 -------------------
 
-Warnings will now be shown at ``do_package_qa`` time in the following
+Warnings will now be shown at :ref:`ref-tasks-package_qa` time in the following
 circumstances:
 
 -  A recipe installs ``.desktop`` files containing ``MimeType`` keys but
diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst
index 8fac7f77ad..45d058a281 100644
--- a/documentation/ref-manual/variables.rst
+++ b/documentation/ref-manual/variables.rst
@@ -6710,7 +6710,7 @@ system and gives an overview of their function and contents.
       the following tasks are added:
 
       - do_populate_lic
-      - do_package_qa
+      - :ref:`ref-tasks-package_qa`
       - do_populate_sysroot
       - :ref:`ref-tasks-deploy`
 
-- 
2.34.1

[PATCH 10/30] overview-manual: concepts.rst: add reference to "do_packagedata" task

[michael.opdenacker]

From: Michael Opdenacker <michael.opdenacker@bootlin.com>

[YOCTO #14508]
Reported-by: Quentin Schulz <foss@0leil.net>
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
---
 documentation/overview-manual/concepts.rst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/documentation/overview-manual/concepts.rst b/documentation/overview-manual/concepts.rst
index bbe0ec345b..36498ba1e1 100644
--- a/documentation/overview-manual/concepts.rst
+++ b/documentation/overview-manual/concepts.rst
@@ -892,7 +892,7 @@ following as well as other items: splitting out debugging symbols,
 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
@@ -2106,7 +2106,7 @@ dependencies, you must manually declare the dependencies.
    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 +2147,7 @@ dependencies, you must manually declare the dependencies.
    :term:`ALLOW_EMPTY` variable
    for more information.
 
-The :ref:`ref-tasks-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
-- 
2.34.1

[PATCH 11/30] manuals: add references to the "do_patch" task

[michael.opdenacker]

From: Michael Opdenacker <michael.opdenacker@bootlin.com>

[YOCTO #14508]
Reported-by: Quentin Schulz <foss@0leil.net>
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
---
 documentation/dev-manual/common-tasks.rst        | 2 +-
 documentation/migration-guides/migration-1.3.rst | 2 +-
 documentation/overview-manual/concepts.rst       | 2 +-
 documentation/ref-manual/qa-checks.rst           | 2 +-
 documentation/ref-manual/tasks.rst               | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/documentation/dev-manual/common-tasks.rst b/documentation/dev-manual/common-tasks.rst
index 74b050f600..947e10560a 100644
--- a/documentation/dev-manual/common-tasks.rst
+++ b/documentation/dev-manual/common-tasks.rst
@@ -9633,7 +9633,7 @@ Running Specific Tasks
 ----------------------
 
 Any given recipe consists of a set of tasks. The standard BitBake
-behavior in most cases is: :ref:`ref-tasks-fetch`, ``do_unpack``, ``do_patch``,
+behavior in most cases is: :ref:`ref-tasks-fetch`, ``do_unpack``, :ref:`ref-tasks-patch`,
 :ref:`ref-tasks-configure`, :ref:`ref-tasks-compile`, :ref:`ref-tasks-install`, :ref:`ref-tasks-package`,
 ``do_package_write_*``, and :ref:`ref-tasks-build`. The default task is
 :ref:`ref-tasks-build` and any tasks on which it depends build first. Some tasks,
diff --git a/documentation/migration-guides/migration-1.3.rst b/documentation/migration-guides/migration-1.3.rst
index 6a1755d1dc..09fc39d3ca 100644
--- a/documentation/migration-guides/migration-1.3.rst
+++ b/documentation/migration-guides/migration-1.3.rst
@@ -62,7 +62,7 @@ Previously, an inconsistent mix of spaces and tabs existed, which made
 extending these functions using ``_append`` or ``_prepend`` complicated
 given that Python treats whitespace as syntactically significant. If you
 are defining or extending any Python functions (e.g.
-``populate_packages``, ``do_unpack``, ``do_patch`` and so forth) in
+``populate_packages``, ``do_unpack``, :ref:`ref-tasks-patch` and so forth) in
 custom recipes or classes, you need to ensure you are using consistent
 four-space indentation.
 
diff --git a/documentation/overview-manual/concepts.rst b/documentation/overview-manual/concepts.rst
index 36498ba1e1..f1457522da 100644
--- a/documentation/overview-manual/concepts.rst
+++ b/documentation/overview-manual/concepts.rst
@@ -1208,7 +1208,7 @@ end result.
 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 :ref:`ref-tasks-fetch`, ``do_unpack``, ``do_patch``,
+to run any of the :ref:`ref-tasks-fetch`, ``do_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.
 
diff --git a/documentation/ref-manual/qa-checks.rst b/documentation/ref-manual/qa-checks.rst
index ff8916aedf..9455bec3fd 100644
--- a/documentation/ref-manual/qa-checks.rst
+++ b/documentation/ref-manual/qa-checks.rst
@@ -677,7 +677,7 @@ Errors and Warnings
 
 - ``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/documentation/ref-manual/tasks.rst b/documentation/ref-manual/tasks.rst
index 1bb8bc1918..f0129c1f72 100644
--- a/documentation/ref-manual/tasks.rst
+++ b/documentation/ref-manual/tasks.rst
@@ -327,7 +327,7 @@ file as a patch file::
        "
 
 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::
 
-- 
2.34.1

[PATCH 12/30] manuals: add references to "do_package_write_*" tasks

[michael.opdenacker]

From: Michael Opdenacker <michael.opdenacker@bootlin.com>

Using a reference to "do_package_write_deb", the first entry
in the list.

[YOCTO #14508]
Reported-by: Quentin Schulz <foss@0leil.net>
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
---
 documentation/dev-manual/common-tasks.rst  | 2 +-
 documentation/overview-manual/concepts.rst | 4 ++--
 documentation/ref-manual/classes.rst       | 2 +-
 documentation/ref-manual/tasks.rst         | 2 +-
 documentation/ref-manual/variables.rst     | 4 ++--
 5 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/documentation/dev-manual/common-tasks.rst b/documentation/dev-manual/common-tasks.rst
index 947e10560a..dbf7dad558 100644
--- a/documentation/dev-manual/common-tasks.rst
+++ b/documentation/dev-manual/common-tasks.rst
@@ -9635,7 +9635,7 @@ Running Specific Tasks
 Any given recipe consists of a set of tasks. The standard BitBake
 behavior in most cases is: :ref:`ref-tasks-fetch`, ``do_unpack``, :ref:`ref-tasks-patch`,
 :ref:`ref-tasks-configure`, :ref:`ref-tasks-compile`, :ref:`ref-tasks-install`, :ref:`ref-tasks-package`,
-``do_package_write_*``, and :ref:`ref-tasks-build`. The default task is
+:ref:`do_package_write_* <ref-tasks-package_write_deb>`, and :ref:`ref-tasks-build`. The default task is
 :ref:`ref-tasks-build` and any tasks on which it depends build first. Some tasks,
 such as ``do_devshell``, are not part of the default build chain. If you
 wish to run a task that is not part of the default build chain, you can
diff --git a/documentation/overview-manual/concepts.rst b/documentation/overview-manual/concepts.rst
index f1457522da..a477139996 100644
--- a/documentation/overview-manual/concepts.rst
+++ b/documentation/overview-manual/concepts.rst
@@ -1198,7 +1198,7 @@ the work involved would be equal to or greater than the underlying task.
 
 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`.
@@ -1215,7 +1215,7 @@ to run any of the :ref:`ref-tasks-fetch`, ``do_unpack``, :ref:`ref-tasks-patch`,
 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
+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
diff --git a/documentation/ref-manual/classes.rst b/documentation/ref-manual/classes.rst
index 076ebb31ae..977dc34523 100644
--- a/documentation/ref-manual/classes.rst
+++ b/documentation/ref-manual/classes.rst
@@ -47,7 +47,7 @@ splitting out of debug symbols during packaging).
    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.
diff --git a/documentation/ref-manual/tasks.rst b/documentation/ref-manual/tasks.rst
index f0129c1f72..b099ce7a5c 100644
--- a/documentation/ref-manual/tasks.rst
+++ b/documentation/ref-manual/tasks.rst
@@ -170,7 +170,7 @@ Copies files that are to be packaged into the holding area
 working directory set to ``${``\ :term:`B`\ ``}``, which is the
 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>`.
 
diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst
index 45d058a281..272673d90b 100644
--- a/documentation/ref-manual/variables.rst
+++ b/documentation/ref-manual/variables.rst
@@ -6200,7 +6200,7 @@ system and gives an overview of their function and contents.
       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 +6212,7 @@ system and gives an overview of their function and contents.
       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
-- 
2.34.1

[PATCH 13/30] ref-manual: variables.rst: add reference to "do_populate_lic" task

[michael.opdenacker]

From: Michael Opdenacker <michael.opdenacker@bootlin.com>

[YOCTO #14508]
Reported-by: Quentin Schulz <foss@0leil.net>
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
---
 documentation/ref-manual/variables.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst
index 272673d90b..e71c3b6b57 100644
--- a/documentation/ref-manual/variables.rst
+++ b/documentation/ref-manual/variables.rst
@@ -6709,7 +6709,7 @@ system and gives an overview of their function and contents.
       A list of shared state tasks added to the extensible SDK. By default,
       the following tasks are added:
 
-      - do_populate_lic
+      - :ref:`ref-tasks-populate_lic`
       - :ref:`ref-tasks-package_qa`
       - do_populate_sysroot
       - :ref:`ref-tasks-deploy`
-- 
2.34.1

[PATCH 14/30] manuals: add reference to the "do_populate_sdk" task

[michael.opdenacker]

From: Michael Opdenacker <michael.opdenacker@bootlin.com>

[YOCTO #14508]
Reported-by: Quentin Schulz <foss@0leil.net>
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
---
 documentation/migration-guides/release-notes-3.4.rst | 2 +-
 documentation/overview-manual/concepts.rst           | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/documentation/migration-guides/release-notes-3.4.rst b/documentation/migration-guides/release-notes-3.4.rst
index 323e4df7ae..33525120c6 100644
--- a/documentation/migration-guides/release-notes-3.4.rst
+++ b/documentation/migration-guides/release-notes-3.4.rst
@@ -67,7 +67,7 @@ New Features / Enhancements in 3.4
 
 -  SDK-related enhancements:
 
-   -  Enable do_populate_sdk with multilibs
+   -  Enable :ref:`ref-tasks-populate_sdk` with multilibs
    -  New ``SDKPATHINSTALL`` variable decouples default install path from built in path to avoid rebuilding nativesdk components on e.g. :term:`DISTRO_VERSION` changes
    -  eSDK: Error if trying to generate an eSDK from a multiconfig
    -  eSDK: introduce :term:`TOOLCHAIN_HOST_TASK_ESDK` to be used in place of :term:`TOOLCHAIN_HOST_TASK` to add components to the host part of the eSDK
diff --git a/documentation/overview-manual/concepts.rst b/documentation/overview-manual/concepts.rst
index a477139996..1215e0ee94 100644
--- a/documentation/overview-manual/concepts.rst
+++ b/documentation/overview-manual/concepts.rst
@@ -1085,7 +1085,7 @@ the extensible SDK (eSDK):
    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,7 +1100,7 @@ actually install. For information on the variables listed in the figure,
 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
-- 
2.34.1

[PATCH 15/30] overview-manual: concepts.rst: add reference to "do_populate_sdk_ext" task

[michael.opdenacker]

From: Michael Opdenacker <michael.opdenacker@bootlin.com>

Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
---
 documentation/overview-manual/concepts.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/documentation/overview-manual/concepts.rst b/documentation/overview-manual/concepts.rst
index 1215e0ee94..423f645740 100644
--- a/documentation/overview-manual/concepts.rst
+++ b/documentation/overview-manual/concepts.rst
@@ -1106,7 +1106,7 @@ 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
-- 
2.34.1

[PATCH 16/30] manuals: add references to "do_populate_sysroot" task

[michael.opdenacker]

From: Michael Opdenacker <michael.opdenacker@bootlin.com>

[YOCTO #14508]
Reported-by: Quentin Schulz <foss@0leil.net>
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
---
 documentation/dev-manual/common-tasks.rst | 2 +-
 documentation/ref-manual/classes.rst      | 2 +-
 documentation/ref-manual/tasks.rst        | 2 +-
 documentation/ref-manual/variables.rst    | 4 ++--
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/documentation/dev-manual/common-tasks.rst b/documentation/dev-manual/common-tasks.rst
index dbf7dad558..5332b21c4a 100644
--- a/documentation/dev-manual/common-tasks.rst
+++ b/documentation/dev-manual/common-tasks.rst
@@ -8481,7 +8481,7 @@ The following list shows the files produced for SDKs:
    information.
 
 -  ``sstate-task-sizes.txt:`` A text file containing name-value pairs
-   with information about task group sizes (e.g. ``do_populate_sysroot``
+   with information about task group sizes (e.g. :ref:`ref-tasks-populate_sysroot`
    tasks have a total size). The ``sstate-task-sizes.txt`` file exists
    only when an extensible SDK is created.
 
diff --git a/documentation/ref-manual/classes.rst b/documentation/ref-manual/classes.rst
index 977dc34523..033284a46c 100644
--- a/documentation/ref-manual/classes.rst
+++ b/documentation/ref-manual/classes.rst
@@ -2527,7 +2527,7 @@ stages:
    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/documentation/ref-manual/tasks.rst b/documentation/ref-manual/tasks.rst
index b099ce7a5c..bf3a038b1a 100644
--- a/documentation/ref-manual/tasks.rst
+++ b/documentation/ref-manual/tasks.rst
@@ -392,7 +392,7 @@ For information on what directories are copied by default, see the
 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").
diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst
index e71c3b6b57..79c64dc97a 100644
--- a/documentation/ref-manual/variables.rst
+++ b/documentation/ref-manual/variables.rst
@@ -6711,7 +6711,7 @@ system and gives an overview of their function and contents.
 
       - :ref:`ref-tasks-populate_lic`
       - :ref:`ref-tasks-package_qa`
-      - do_populate_sysroot
+      - :ref:`ref-tasks-populate_sysroot`
       - :ref:`ref-tasks-deploy`
 
       Despite the default value of "" for the
@@ -7382,7 +7382,7 @@ system and gives an overview of their function and contents.
       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:
-- 
2.34.1

[PATCH 17/30] manuals: add references to the "do_unpack" task

[michael.opdenacker]

From: Michael Opdenacker <michael.opdenacker@bootlin.com>

[YOCTO #14508]
Reported-by: Quentin Schulz <foss@0leil.net>
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
---
 documentation/dev-manual/common-tasks.rst        | 2 +-
 documentation/migration-guides/migration-1.3.rst | 2 +-
 documentation/overview-manual/concepts.rst       | 2 +-
 documentation/ref-manual/tasks.rst               | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/documentation/dev-manual/common-tasks.rst b/documentation/dev-manual/common-tasks.rst
index 5332b21c4a..8a087850b6 100644
--- a/documentation/dev-manual/common-tasks.rst
+++ b/documentation/dev-manual/common-tasks.rst
@@ -9633,7 +9633,7 @@ Running Specific Tasks
 ----------------------
 
 Any given recipe consists of a set of tasks. The standard BitBake
-behavior in most cases is: :ref:`ref-tasks-fetch`, ``do_unpack``, :ref:`ref-tasks-patch`,
+behavior in most cases is: :ref:`ref-tasks-fetch`, :ref:`ref-tasks-unpack`, :ref:`ref-tasks-patch`,
 :ref:`ref-tasks-configure`, :ref:`ref-tasks-compile`, :ref:`ref-tasks-install`, :ref:`ref-tasks-package`,
 :ref:`do_package_write_* <ref-tasks-package_write_deb>`, and :ref:`ref-tasks-build`. The default task is
 :ref:`ref-tasks-build` and any tasks on which it depends build first. Some tasks,
diff --git a/documentation/migration-guides/migration-1.3.rst b/documentation/migration-guides/migration-1.3.rst
index 09fc39d3ca..3ba189b773 100644
--- a/documentation/migration-guides/migration-1.3.rst
+++ b/documentation/migration-guides/migration-1.3.rst
@@ -62,7 +62,7 @@ Previously, an inconsistent mix of spaces and tabs existed, which made
 extending these functions using ``_append`` or ``_prepend`` complicated
 given that Python treats whitespace as syntactically significant. If you
 are defining or extending any Python functions (e.g.
-``populate_packages``, ``do_unpack``, :ref:`ref-tasks-patch` and so forth) in
+``populate_packages``, :ref:`ref-tasks-unpack`, :ref:`ref-tasks-patch` and so forth) in
 custom recipes or classes, you need to ensure you are using consistent
 four-space indentation.
 
diff --git a/documentation/overview-manual/concepts.rst b/documentation/overview-manual/concepts.rst
index 423f645740..2aa7676324 100644
--- a/documentation/overview-manual/concepts.rst
+++ b/documentation/overview-manual/concepts.rst
@@ -1208,7 +1208,7 @@ end result.
 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 :ref:`ref-tasks-fetch`, ``do_unpack``, :ref:`ref-tasks-patch`,
+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.
 
diff --git a/documentation/ref-manual/tasks.rst b/documentation/ref-manual/tasks.rst
index bf3a038b1a..dcfc2679ee 100644
--- a/documentation/ref-manual/tasks.rst
+++ b/documentation/ref-manual/tasks.rst
@@ -447,7 +447,7 @@ Validates the :term:`SRC_URI` value.
 ------------
 
 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
-- 
2.34.1

[PATCH 18/30] dev-manual: common-tasks.rst: add reference to "do_clean" task

[michael.opdenacker]

From: Michael Opdenacker <michael.opdenacker@bootlin.com>

[YOCTO #14508]
Reported-by: Quentin Schulz <foss@0leil.net>
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
---
 documentation/dev-manual/common-tasks.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/documentation/dev-manual/common-tasks.rst b/documentation/dev-manual/common-tasks.rst
index 8a087850b6..cf4d12f388 100644
--- a/documentation/dev-manual/common-tasks.rst
+++ b/documentation/dev-manual/common-tasks.rst
@@ -3458,7 +3458,7 @@ Follow these general steps:
    .. note::
 
       All the modifications you make to the temporary source code disappear
-      once you run the ``do_clean`` or ``do_cleanall`` tasks using BitBake
+      once you run the :ref:`ref-tasks-clean` or ``do_cleanall`` tasks using BitBake
       (i.e. ``bitbake -c clean package`` and ``bitbake -c cleanall package``).
       Modifications will also disappear if you use the ``rm_work`` feature as
       described in the
-- 
2.34.1

[PATCH 19/30] manuals: add references to the "do_cleanall" task

[michael.opdenacker]

From: Michael Opdenacker <michael.opdenacker@bootlin.com>

[YOCTO #14508]
Reported-by: Quentin Schulz <foss@0leil.net>
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
---
 documentation/dev-manual/common-tasks.rst | 2 +-
 documentation/ref-manual/tasks.rst        | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/documentation/dev-manual/common-tasks.rst b/documentation/dev-manual/common-tasks.rst
index cf4d12f388..c3be8b72b4 100644
--- a/documentation/dev-manual/common-tasks.rst
+++ b/documentation/dev-manual/common-tasks.rst
@@ -3458,7 +3458,7 @@ Follow these general steps:
    .. note::
 
       All the modifications you make to the temporary source code disappear
-      once you run the :ref:`ref-tasks-clean` or ``do_cleanall`` tasks using BitBake
+      once you run the :ref:`ref-tasks-clean` or :ref:`ref-tasks-cleanall` tasks using BitBake
       (i.e. ``bitbake -c clean package`` and ``bitbake -c cleanall package``).
       Modifications will also disappear if you use the ``rm_work`` feature as
       described in the
diff --git a/documentation/ref-manual/tasks.rst b/documentation/ref-manual/tasks.rst
index dcfc2679ee..7eb48dcba3 100644
--- a/documentation/ref-manual/tasks.rst
+++ b/documentation/ref-manual/tasks.rst
@@ -473,7 +473,7 @@ use the :ref:`ref-tasks-cleansstate` task instead
 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 @@ You can run this task using BitBake as follows::
 
    $ 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.
 
-- 
2.34.1

[PATCH 20/30] ref-manual: tasks.rst: add references to the "do_cleansstate" task

[michael.opdenacker]

From: Michael Opdenacker <michael.opdenacker@bootlin.com>

[YOCTO #14508]
Reported-by: Quentin Schulz <foss@0leil.net>
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
---
 documentation/ref-manual/tasks.rst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/documentation/ref-manual/tasks.rst b/documentation/ref-manual/tasks.rst
index 7eb48dcba3..7c4be3e86f 100644
--- a/documentation/ref-manual/tasks.rst
+++ b/documentation/ref-manual/tasks.rst
@@ -492,7 +492,7 @@ task.
 
 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 @@ You can run this task using BitBake as follows::
 
    $ 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::
 
-- 
2.34.1

[PATCH 21/30] manuals: add references to the "do_devshell" task

[michael.opdenacker]

From: Michael Opdenacker <michael.opdenacker@bootlin.com>

[YOCTO #14508]
Reported-by: Quentin Schulz <foss@0leil.net>
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
---
 documentation/dev-manual/common-tasks.rst | 2 +-
 documentation/ref-manual/classes.rst      | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/documentation/dev-manual/common-tasks.rst b/documentation/dev-manual/common-tasks.rst
index c3be8b72b4..efed327cea 100644
--- a/documentation/dev-manual/common-tasks.rst
+++ b/documentation/dev-manual/common-tasks.rst
@@ -9637,7 +9637,7 @@ behavior in most cases is: :ref:`ref-tasks-fetch`, :ref:`ref-tasks-unpack`, :ref
 :ref:`ref-tasks-configure`, :ref:`ref-tasks-compile`, :ref:`ref-tasks-install`, :ref:`ref-tasks-package`,
 :ref:`do_package_write_* <ref-tasks-package_write_deb>`, and :ref:`ref-tasks-build`. The default task is
 :ref:`ref-tasks-build` and any tasks on which it depends build first. Some tasks,
-such as ``do_devshell``, are not part of the default build chain. If you
+such as :ref:`ref-tasks-devshell`, are not part of the default build chain. If you
 wish to run a task that is not part of the default build chain, you can
 use the ``-c`` option in BitBake. Here is an example::
 
diff --git a/documentation/ref-manual/classes.rst b/documentation/ref-manual/classes.rst
index 033284a46c..8e8a0baaf0 100644
--- a/documentation/ref-manual/classes.rst
+++ b/documentation/ref-manual/classes.rst
@@ -444,7 +444,7 @@ staging the files from :term:`DEPLOYDIR` to :term:`DEPLOY_DIR_IMAGE`.
 ``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``.
-- 
2.34.1

[PATCH 22/30] dev-manual: common-tasks.rst: add reference to "do_listtasks" task

[michael.opdenacker]

From: Michael Opdenacker <michael.opdenacker@bootlin.com>

Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
---
 documentation/dev-manual/common-tasks.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/documentation/dev-manual/common-tasks.rst b/documentation/dev-manual/common-tasks.rst
index efed327cea..8b77568d83 100644
--- a/documentation/dev-manual/common-tasks.rst
+++ b/documentation/dev-manual/common-tasks.rst
@@ -9724,7 +9724,7 @@ task dependency mechanisms.
 
 
 You can view a list of tasks in a given package by running the
-``do_listtasks`` task as follows::
+:ref:`ref-tasks-listtasks` task as follows::
 
    $ bitbake matchbox-desktop -c listtasks
 
-- 
2.34.1

[PATCH 23/30] manuals: add references to the "do_bundle_initramfs" task

[michael.opdenacker]

From: Michael Opdenacker <michael.opdenacker@bootlin.com>

[YOCTO #14508]
Reported-by: Quentin Schulz <foss@0leil.net>
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
---
 documentation/dev-manual/common-tasks.rst | 2 +-
 documentation/ref-manual/variables.rst    | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/documentation/dev-manual/common-tasks.rst b/documentation/dev-manual/common-tasks.rst
index 8b77568d83..b20b9f374b 100644
--- a/documentation/dev-manual/common-tasks.rst
+++ b/documentation/dev-manual/common-tasks.rst
@@ -3995,7 +3995,7 @@ To achieve this, you need to perform some additional steps:
    buildsystem know where the :term:`INITRAMFS_IMAGE` will be located.
 
    Building a system with such configuration will build the kernel using the
-   main configuration but the ``do_bundle_initramfs`` task will grab the
+   main configuration but the :ref:`ref-tasks-bundle_initramfs` task will grab the
    selected :term:`INITRAMFS_IMAGE` from :term:`INITRAMFS_DEPLOY_DIR_IMAGE`
    instead, resulting in a musl based initramfs image bundled in the kernel
    but a glibc based main image.
diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst
index 79c64dc97a..afe789ff57 100644
--- a/documentation/ref-manual/variables.rst
+++ b/documentation/ref-manual/variables.rst
@@ -3633,7 +3633,7 @@ system and gives an overview of their function and contents.
          needed for the build that are not strippable.
 
    :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
-- 
2.34.1

[PATCH 24/30] manuals: add references to the "do_rootfs" task

[michael.opdenacker]

From: Michael Opdenacker <michael.opdenacker@bootlin.com>

[YOCTO #14508]
Reported-by: Quentin Schulz <foss@0leil.net>
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
---
 documentation/dev-manual/common-tasks.rst        | 6 +++---
 documentation/migration-guides/migration-2.1.rst | 8 ++++----
 documentation/migration-guides/migration-2.5.rst | 2 +-
 documentation/overview-manual/concepts.rst       | 2 +-
 4 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/documentation/dev-manual/common-tasks.rst b/documentation/dev-manual/common-tasks.rst
index b20b9f374b..d00aeab72a 100644
--- a/documentation/dev-manual/common-tasks.rst
+++ b/documentation/dev-manual/common-tasks.rst
@@ -3854,7 +3854,7 @@ to be added to the recipe that builds the ``core-image-sato`` image::
 
 In this example, the `from_multiconfig` is "x86". The `to_multiconfig` is "arm". The
 task on which the :ref:`ref-tasks-image` task in the recipe depends is the
-``do_rootfs`` task from the ``core-image-minimal`` recipe associated
+:ref:`ref-tasks-rootfs` task from the ``core-image-minimal`` recipe associated
 with the "arm" multiconfig.
 
 Once you set up this dependency, you can build the "x86" multiconfig
@@ -3864,7 +3864,7 @@ using a BitBake command as follows::
 
 This command executes all the tasks needed to create the
 ``core-image-sato`` image for the "x86" multiconfig. Because of the
-dependency, BitBake also executes through the ``do_rootfs`` task for the
+dependency, BitBake also executes through the :ref:`ref-tasks-rootfs` task for the
 "arm" multiconfig build.
 
 Having a recipe depend on the root filesystem of another build might not
@@ -9081,7 +9081,7 @@ Class methods are as follows:
 
 -  *hasPackage(pkg):* Returns "True" if ``pkg`` is in the installed
    package list of the image, which is based on the manifest file that
-   is generated during the ``do_rootfs`` task.
+   is generated during the :ref:`ref-tasks-rootfs` task.
 
 -  *hasFeature(feature):* Returns "True" if the feature is in
    :term:`IMAGE_FEATURES` or
diff --git a/documentation/migration-guides/migration-2.1.rst b/documentation/migration-guides/migration-2.1.rst
index bfc600ccca..c19ba5501c 100644
--- a/documentation/migration-guides/migration-2.1.rst
+++ b/documentation/migration-guides/migration-2.1.rst
@@ -128,12 +128,12 @@ separate :ref:`ref-tasks-image` tasks for clarity both in
 operation and in the code.
 
 For most cases, this change does not present any problems. However, if
-you have made customizations that directly modify the ``do_rootfs`` task
-or that mention ``do_rootfs``, you might need to update those changes.
-In particular, if you had added any tasks after ``do_rootfs``, you
+you have made customizations that directly modify the :ref:`ref-tasks-rootfs` task
+or that mention :ref:`ref-tasks-rootfs`, you might need to update those changes.
+In particular, if you had added any tasks after :ref:`ref-tasks-rootfs`, you
 should make edits so that those tasks are after the
 :ref:`ref-tasks-image-complete` task rather than
-after ``do_rootfs`` so that your added tasks run at the correct
+after :ref:`ref-tasks-rootfs` so that your added tasks run at the correct
 time.
 
 A minor part of this restructuring is that the post-processing
diff --git a/documentation/migration-guides/migration-2.5.rst b/documentation/migration-guides/migration-2.5.rst
index abd26809df..04f4cd7e73 100644
--- a/documentation/migration-guides/migration-2.5.rst
+++ b/documentation/migration-guides/migration-2.5.rst
@@ -261,7 +261,7 @@ The following are additional changes:
    ``pkg_postinst_ontarget()`` or call
    ``postinst_intercept delay_to_first_boot`` from ``pkg_postinst()``.
    Any failure of a ``pkg_postinst()`` script (including ``exit 1``)
-   will trigger a warning during ``do_rootfs``.
+   will trigger a warning during :ref:`ref-tasks-rootfs`.
 
    For more information, see the
    ":ref:`dev-manual/common-tasks:post-installation scripts`"
diff --git a/documentation/overview-manual/concepts.rst b/documentation/overview-manual/concepts.rst
index 2aa7676324..8b8625a080 100644
--- a/documentation/overview-manual/concepts.rst
+++ b/documentation/overview-manual/concepts.rst
@@ -1012,7 +1012,7 @@ all the post installation scripts must succeed on the build host during
 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
-- 
2.34.1

[PATCH 25/30] ref-manual: tasks.rst: add reference to the "do_kernel_checkout" task

[michael.opdenacker]

From: Michael Opdenacker <michael.opdenacker@bootlin.com>

[YOCTO #14508]
Reported-by: Quentin Schulz <foss@0leil.net>
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
---
 documentation/ref-manual/tasks.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/documentation/ref-manual/tasks.rst b/documentation/ref-manual/tasks.rst
index 7c4be3e86f..673068a3e7 100644
--- a/documentation/ref-manual/tasks.rst
+++ b/documentation/ref-manual/tasks.rst
@@ -657,7 +657,7 @@ section in the Yocto Project Linux Kernel Development Manual.
 
 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.
 
-- 
2.34.1

[PATCH 26/30] manuals: add reference to the "do_kernel_configcheck" task

[michael.opdenacker]

From: Michael Opdenacker <michael.opdenacker@bootlin.com>

Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
---
 documentation/kernel-dev/common.rst | 10 +++++-----
 documentation/ref-manual/tasks.rst  |  2 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/documentation/kernel-dev/common.rst b/documentation/kernel-dev/common.rst
index fb8d7cd029..f370350264 100644
--- a/documentation/kernel-dev/common.rst
+++ b/documentation/kernel-dev/common.rst
@@ -1316,7 +1316,7 @@ In order to run this task, you must have an existing ``.config`` file.
 See the ":ref:`kernel-dev/common:using \`\`menuconfig\`\``" section for
 information on how to create a configuration file.
 
-Following is sample output from the ``do_kernel_configcheck`` task:
+Following is sample output from the :ref:`ref-tasks-kernel_configcheck` task:
 
 .. code-block:: none
 
@@ -1396,7 +1396,7 @@ possible by reading the output of the kernel configuration fragment
 audit, noting any issues, making changes to correct the issues, and then
 repeating.
 
-As part of the kernel build process, the ``do_kernel_configcheck`` task
+As part of the kernel build process, the :ref:`ref-tasks-kernel_configcheck` task
 runs. This task validates the kernel configuration by checking the final
 ``.config`` file against the input files. During the check, the task
 produces warning messages for the following issues:
@@ -1430,13 +1430,13 @@ To streamline the configuration, do the following:
    successfully. Use this configuration file as your baseline.
 
 2. *Run Configure and Check Tasks:* Separately run the
-   ``do_kernel_configme`` and ``do_kernel_configcheck`` tasks::
+   ``do_kernel_configme`` and :ref:`ref-tasks-kernel_configcheck` tasks::
 
       $ bitbake linux-yocto -c kernel_configme -f
       $ bitbake linux-yocto -c kernel_configcheck -f
 
 3. *Process the Results:* Take the resulting list of files from the
-   ``do_kernel_configcheck`` task warnings and do the following:
+   :ref:`ref-tasks-kernel_configcheck` task warnings and do the following:
 
    -  Drop values that are redefined in the fragment but do not change
       the final ``.config`` file.
@@ -1450,7 +1450,7 @@ To streamline the configuration, do the following:
 
 4. *Re-Run Configure and Check Tasks:* After you have worked through the
    output of the kernel configuration audit, you can re-run the
-   ``do_kernel_configme`` and ``do_kernel_configcheck`` tasks to see the
+   ``do_kernel_configme`` and :ref:`ref-tasks-kernel_configcheck` tasks to see the
    results of your changes. If you have more issues, you can deal with
    them as described in the previous step.
 
diff --git a/documentation/ref-manual/tasks.rst b/documentation/ref-manual/tasks.rst
index 673068a3e7..faffe94eb1 100644
--- a/documentation/ref-manual/tasks.rst
+++ b/documentation/ref-manual/tasks.rst
@@ -668,7 +668,7 @@ kernel with the correct branches checked out.
 
 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
-- 
2.34.1

[PATCH 27/30] manuals: add references to the "do_kernel_configme" task

[michael.opdenacker]

From: Michael Opdenacker <michael.opdenacker@bootlin.com>

[YOCTO #14508]
Reported-by: Quentin Schulz <foss@0leil.net>
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
---
 documentation/kernel-dev/common.rst | 4 ++--
 documentation/ref-manual/tasks.rst  | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/documentation/kernel-dev/common.rst b/documentation/kernel-dev/common.rst
index f370350264..0a1819ceae 100644
--- a/documentation/kernel-dev/common.rst
+++ b/documentation/kernel-dev/common.rst
@@ -1430,7 +1430,7 @@ To streamline the configuration, do the following:
    successfully. Use this configuration file as your baseline.
 
 2. *Run Configure and Check Tasks:* Separately run the
-   ``do_kernel_configme`` and :ref:`ref-tasks-kernel_configcheck` tasks::
+   :ref:`ref-tasks-kernel_configme` and :ref:`ref-tasks-kernel_configcheck` tasks::
 
       $ bitbake linux-yocto -c kernel_configme -f
       $ bitbake linux-yocto -c kernel_configcheck -f
@@ -1450,7 +1450,7 @@ To streamline the configuration, do the following:
 
 4. *Re-Run Configure and Check Tasks:* After you have worked through the
    output of the kernel configuration audit, you can re-run the
-   ``do_kernel_configme`` and :ref:`ref-tasks-kernel_configcheck` tasks to see the
+   :ref:`ref-tasks-kernel_configme` and :ref:`ref-tasks-kernel_configcheck` tasks to see the
    results of your changes. If you have more issues, you can deal with
    them as described in the previous step.
 
diff --git a/documentation/ref-manual/tasks.rst b/documentation/ref-manual/tasks.rst
index faffe94eb1..29a135beb0 100644
--- a/documentation/ref-manual/tasks.rst
+++ b/documentation/ref-manual/tasks.rst
@@ -686,7 +686,7 @@ section in the Yocto Project Linux Kernel Development Manual.
 ----------------------
 
 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
-- 
2.34.1

[PATCH 28/30] ref-manual: tasks.rst: add reference to the "do_kernel_metadata" task

[michael.opdenacker]

From: Michael Opdenacker <michael.opdenacker@bootlin.com>

Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
---
 documentation/ref-manual/tasks.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/documentation/ref-manual/tasks.rst b/documentation/ref-manual/tasks.rst
index 29a135beb0..ce900119ef 100644
--- a/documentation/ref-manual/tasks.rst
+++ b/documentation/ref-manual/tasks.rst
@@ -719,7 +719,7 @@ information on this configuration tool.
 
 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
-- 
2.34.1

[PATCH 29/30] migration-guides: add reference to the "do_shared_workdir" task

[michael.opdenacker]

From: Michael Opdenacker <michael.opdenacker@bootlin.com>

Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
---
 documentation/migration-guides/migration-1.8.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/documentation/migration-guides/migration-1.8.rst b/documentation/migration-guides/migration-1.8.rst
index 546c798196..f058029b30 100644
--- a/documentation/migration-guides/migration-1.8.rst
+++ b/documentation/migration-guides/migration-1.8.rst
@@ -84,7 +84,7 @@ where the ``linux.inc`` file in ``meta-oe`` was updated.
 
 Recipes that rely on the kernel source code and do not inherit the
 module classes might need to add explicit dependencies on the
-``do_shared_workdir`` kernel task, for example::
+:ref:`ref-tasks-shared_workdir` kernel task, for example::
 
    do_configure[depends] += "virtual/kernel:do_shared_workdir"
 
-- 
2.34.1

[PATCH 30/30] ref-manual: tasks.rst: add reference to the "do_validate_branches" task

[michael.opdenacker]

From: Michael Opdenacker <michael.opdenacker@bootlin.com>

[YOCTO #14508]
Reported-by: Quentin Schulz <foss@0leil.net>
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
---
 documentation/ref-manual/tasks.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/documentation/ref-manual/tasks.rst b/documentation/ref-manual/tasks.rst
index ce900119ef..d54bb35bb5 100644
--- a/documentation/ref-manual/tasks.rst
+++ b/documentation/ref-manual/tasks.rst
@@ -791,4 +791,4 @@ After the kernel is unpacked but before it is patched, this task makes
 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.
-- 
2.34.1

Re: [docs] [PATCH 06/30] manuals: add references to the "do_deploy" task

[Quentin Schulz]

Hi Michael,

On 9/23/22 19:51, Michael Opdenacker via lists.yoctoproject.org wrote:
> From: Michael Opdenacker <michael.opdenacker@bootlin.com>
> 
> [YOCTO #14508]
> Reported-by: Quentin Schulz <foss@0leil.net>
> Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
> ---
>   .../migration-guides/migration-3.2.rst         |  4 ++--
>   documentation/overview-manual/concepts.rst     | 18 +++++++++---------
>   documentation/ref-manual/tasks.rst             |  8 ++++----
>   documentation/ref-manual/variables.rst         |  2 +-
>   4 files changed, 16 insertions(+), 16 deletions(-)
> 
> diff --git a/documentation/migration-guides/migration-3.2.rst b/documentation/migration-guides/migration-3.2.rst
> index 8a8d19d605..4c0de7b0f6 100644
> --- a/documentation/migration-guides/migration-3.2.rst
> +++ b/documentation/migration-guides/migration-3.2.rst
> @@ -207,9 +207,9 @@ files into a subdirectory and reference that instead.
>   deploy class now cleans ``DEPLOYDIR`` before ``do_deploy``
>   ----------------------------------------------------------
>   
> -``do_deploy`` as implemented in the :ref:`deploy <ref-classes-deploy>` class now cleans up ${:term:`DEPLOYDIR`} before running, just as :ref:`ref-tasks-install` cleans up ${:term:`D`} before running. This reduces the risk of :term:`DEPLOYDIR` being accidentally contaminated by files from previous runs, possibly even with different config, in case of incremental builds.
> +:ref:`ref-tasks-deploy` as implemented in the :ref:`deploy <ref-classes-deploy>` class now cleans up ${:term:`DEPLOYDIR`} before running, just as :ref:`ref-tasks-install` cleans up ${:term:`D`} before running. This reduces the risk of :term:`DEPLOYDIR` being accidentally contaminated by files from previous runs, possibly even with different config, in case of incremental builds.
>   
> -Most recipes and classes that inherit the :ref:`deploy <ref-classes-deploy>` class or interact with ``do_deploy`` are unlikely to be affected by this unless they add ``prefuncs`` to ``do_deploy`` *which also* put files into ``${DEPLOYDIR}`` --- these should be refactored to use ``do_deploy_prepend`` instead.
> +Most recipes and classes that inherit the :ref:`deploy <ref-classes-deploy>` class or interact with :ref:`ref-tasks-deploy` are unlikely to be affected by this unless they add ``prefuncs`` to :ref:`ref-tasks-deploy` *which also* put files into ``${DEPLOYDIR}`` --- these should be refactored to use ``do_deploy_prepend`` instead.
>   
>   
>   .. _migration-3.2-nativesdk-sdk-provides-dummy:
> diff --git a/documentation/overview-manual/concepts.rst b/documentation/overview-manual/concepts.rst
> index 06220401bc..f3f8cbd95c 100644
> --- a/documentation/overview-manual/concepts.rst
> +++ b/documentation/overview-manual/concepts.rst
> @@ -1801,14 +1801,14 @@ from the :ref:`deploy <ref-classes-deploy>` class::
>   
>   The following list explains the previous example:
>   
> --  Adding "do_deploy" to ``SSTATETASKS`` adds some required
> +-  Adding ``do_deploy`` to ``SSTATETASKS`` adds some required

You missed one here.

Cheers,
Quentin

Re: [docs] [PATCH 04/30] manuals: add reference to "do_configure" task

[Quentin Schulz]

Hi Michael,

On 9/23/22 19:51, Michael Opdenacker via lists.yoctoproject.org wrote:
> From: Michael Opdenacker <michael.opdenacker@bootlin.com>
> 
> [YOCTO #14508]
> Reported-by: Quentin Schulz <foss@0leil.net>
> Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>

You're missing one:

https://git.yoctoproject.org/yocto-docs/tree/documentation/ref-manual/variables.rst#n5524

Cheers,
Quentin

Re: [docs] [PATCH 00/30] manuals: add missing references to tasks

[Quentin Schulz]

Hi Michael,

On 9/23/22 19:51, Michael Opdenacker via lists.yoctoproject.org wrote:
> From: Michael Opdenacker <michael.opdenacker@bootlin.com>
> 
> manuals: add missing references to tasks
> 
> As suggested by Quentin Schulz on https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.yoctoproject.org_show-5Fbug.cgi-3Fid-3D14508&d=DwIDAg&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=HuSyEeTT-KxIT3uX-8IenyuDr00g1CP3df1fW1p3wdbCHI96kWRHSCTRw9BLNyWR&s=UWoJbMECYt0997xRv7yfZIXOJ4HiCK0Kk57CApO1lwc&e=
> 

There are a few rogue do_image_complete we can convert still.

Cheers,
Quentin

> Michael Opdenacker (30):
>    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
> 
>   documentation/dev-manual/common-tasks.rst     | 68 +++++++++----------
>   documentation/kernel-dev/common.rst           | 10 +--
>   .../migration-guides/migration-1.3.rst        |  2 +-
>   .../migration-guides/migration-1.7.rst        |  2 +-
>   .../migration-guides/migration-1.8.rst        |  4 +-
>   .../migration-guides/migration-2.1.rst        | 12 ++--
>   .../migration-guides/migration-2.5.rst        |  2 +-
>   .../migration-guides/migration-2.6.rst        |  2 +-
>   .../migration-guides/migration-3.1.rst        |  2 +-
>   .../migration-guides/migration-3.2.rst        |  8 +--
>   .../migration-guides/migration-3.4.rst        |  2 +-
>   .../migration-guides/migration-4.0.rst        |  6 +-
>   .../migration-guides/release-notes-3.4.rst    |  2 +-
>   documentation/overview-manual/concepts.rst    | 56 +++++++--------
>   documentation/ref-manual/classes.rst          | 16 ++---
>   documentation/ref-manual/faq.rst              |  2 +-
>   documentation/ref-manual/qa-checks.rst        | 14 ++--
>   documentation/ref-manual/structure.rst        |  2 +-
>   documentation/ref-manual/tasks.rst            | 52 +++++++-------
>   documentation/ref-manual/variables.rst        | 22 +++---
>   documentation/sdk-manual/extensible.rst       |  2 +-
>   21 files changed, 144 insertions(+), 144 deletions(-)
> 
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#3215): https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.yoctoproject.org_g_docs_message_3215&d=DwIFaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=HuSyEeTT-KxIT3uX-8IenyuDr00g1CP3df1fW1p3wdbCHI96kWRHSCTRw9BLNyWR&s=g6dvrTKb9AKxCL0ykjdTc3FxSeg3LrEj1lRSqOe61aQ&e=
> Mute This Topic: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.yoctoproject.org_mt_93876086_6293953&d=DwIFaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=HuSyEeTT-KxIT3uX-8IenyuDr00g1CP3df1fW1p3wdbCHI96kWRHSCTRw9BLNyWR&s=NPpca8CWiuQKcTD6hAQUq4WVKxUukscUDxFhf5smWeg&e=
> Group Owner: docs+owner@lists.yoctoproject.org
> Unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.yoctoproject.org_g_docs_unsub&d=DwIFaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=HuSyEeTT-KxIT3uX-8IenyuDr00g1CP3df1fW1p3wdbCHI96kWRHSCTRw9BLNyWR&s=xbTF8ktdsUNCHgckcmF9w5wCW5gfLivzfvPSfFvfSl8&e=  [quentin.schulz@theobroma-systems.com]
> -=-=-=-=-=-=-=-=-=-=-=-
> 

Re: [docs] [PATCH 02/30] manuals: add reference to the "do_install" task

[Quentin Schulz]

Hi Michael,

On 9/23/22 19:51, Michael Opdenacker via lists.yoctoproject.org wrote:
> From: Michael Opdenacker <michael.opdenacker@bootlin.com>
> 
> [YOCTO #14508]
> Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
> Reported-by: Quentin Schulz <foss@0leil.net>
> ---

Missing a few:
https://git.yoctoproject.org/yocto-docs/tree/documentation/dev-manual/common-tasks.rst#n1916
https://git.yoctoproject.org/yocto-docs/tree/documentation/dev-manual/common-tasks.rst#n1926
https://git.yoctoproject.org/yocto-docs/tree/documentation/dev-manual/common-tasks.rst#n1983

Cheers,
Quentin

>   documentation/dev-manual/common-tasks.rst     | 26 +++++++++----------
>   .../migration-guides/migration-3.2.rst        |  4 +--
>   .../migration-guides/migration-4.0.rst        |  2 +-
>   documentation/overview-manual/concepts.rst    |  4 +--
>   documentation/ref-manual/classes.rst          |  8 +++---
>   documentation/ref-manual/faq.rst              |  2 +-
>   documentation/ref-manual/qa-checks.rst        | 12 ++++-----
>   documentation/ref-manual/tasks.rst            |  2 +-
>   documentation/ref-manual/variables.rst        |  2 +-
>   documentation/sdk-manual/extensible.rst       |  2 +-
>   10 files changed, 32 insertions(+), 32 deletions(-)
> 
> diff --git a/documentation/dev-manual/common-tasks.rst b/documentation/dev-manual/common-tasks.rst
> index 3b25c9f950..09304d4b6a 100644
> --- a/documentation/dev-manual/common-tasks.rst
> +++ b/documentation/dev-manual/common-tasks.rst
> @@ -1731,7 +1731,7 @@ your software is built:
>   
>         If you need to install one or more custom CMake toolchain files
>         that are supplied by the application you are building, install the
> -      files to ``${D}${datadir}/cmake/Modules`` during ``do_install``.
> +      files to ``${D}${datadir}/cmake/Modules`` during :ref:`ref-tasks-install`.
>   
>   -  *Other:* If your source files do not have a ``configure.ac`` or
>      ``CMakeLists.txt`` file, then your software is built using some
> @@ -1888,7 +1888,7 @@ Here are some common issues that cause failures.
>   Installing
>   ----------
>   
> -During ``do_install``, the task copies the built files along with their
> +During :ref:`ref-tasks-install`, the task copies the built files along with their
>   hierarchy to locations that would mirror their locations on the target
>   device. The installation process copies files from the
>   ``${``\ :term:`S`\ ``}``,
> @@ -1906,7 +1906,7 @@ the software being built:
>   -  *Autotools and CMake:* If the software your recipe is building uses
>      Autotools or CMake, the OpenEmbedded build system understands how to
>      install the software. Consequently, you do not have to have a
> -   ``do_install`` task as part of your recipe. You just need to make
> +   :ref:`ref-tasks-install` task as part of your recipe. You just need to make
>      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
> @@ -1946,10 +1946,10 @@ installed correctly.
>         might need to replace hard-coded paths in an initscript with
>         values of variables provided by the build system, such as
>         replacing ``/usr/bin/`` with ``${bindir}``. If you do perform such
> -      modifications during ``do_install``, be sure to modify the
> +      modifications during :ref:`ref-tasks-install`, be sure to modify the
>         destination file after copying rather than before copying.
>         Modifying after copying ensures that the build system can
> -      re-execute ``do_install`` if needed.
> +      re-execute :ref:`ref-tasks-install` if needed.
>   
>      -  ``oe_runmake install``, which can be run directly or can be run
>         indirectly by the
> @@ -1958,7 +1958,7 @@ installed correctly.
>         runs ``make install`` in parallel. Sometimes, a Makefile can have
>         missing dependencies between targets that can result in race
>         conditions. If you experience intermittent failures during
> -      ``do_install``, you might be able to work around them by disabling
> +      :ref:`ref-tasks-install`, you might be able to work around them by disabling
>         parallel Makefile installs by adding the following to the recipe::
>   
>            PARALLEL_MAKEINST = ""
> @@ -2337,7 +2337,7 @@ Single .c File Package (Hello World!)
>   Building an application from a single file that is stored locally (e.g.
>   under ``files``) requires a recipe that has the file listed in the
>   :term:`SRC_URI` variable. Additionally, you need to manually write the
> -``do_compile`` and ``do_install`` tasks. The :term:`S` variable defines the
> +``do_compile`` and :ref:`ref-tasks-install` tasks. The :term:`S` variable defines the
>   directory containing the source code, which is set to
>   :term:`WORKDIR` in this case --- the
>   directory BitBake uses for the build.
> @@ -2407,8 +2407,8 @@ should store them in the
>   :term:`EXTRA_OEMAKE` or
>   :term:`PACKAGECONFIG_CONFARGS`
>   variables. BitBake passes these options into the GNU ``make``
> -invocation. Note that a ``do_install`` task is still required.
> -Otherwise, BitBake runs an empty ``do_install`` task by default.
> +invocation. Note that a :ref:`ref-tasks-install` task is still required.
> +Otherwise, BitBake runs an empty :ref:`ref-tasks-install` task by default.
>   
>   Some applications might require extra parameters to be passed to the
>   compiler. For example, the application might need an additional header
> @@ -2567,7 +2567,7 @@ doing the following:
>      :ref:`ref-tasks-patch` tasks to the
>      :ref:`ref-tasks-install` task.
>   
> --  Make sure your ``do_install`` task installs the binaries
> +-  Make sure your :ref:`ref-tasks-install` task installs the binaries
>      appropriately.
>   
>   -  Ensure that you set up :term:`FILES`
> @@ -4740,7 +4740,7 @@ the built library.
>   The :term:`PACKAGES` and
>   :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`
> +by the :ref:`ref-tasks-install` task are packaged. By default, the :term:`PACKAGES`
>   variable includes ``${PN}-staticdev``, which represents all static
>   library files.
>   
> @@ -6902,7 +6902,7 @@ The previous example specifies a number of things in the call to
>   ``do_split_packages``.
>   
>   -  A directory within the files installed by your recipe through
> -   ``do_install`` in which to search.
> +   :ref:`ref-tasks-install` in which to search.
>   
>   -  A regular expression used to match module files in that directory. In
>      the example, note the parentheses () that mark the part of the
> @@ -9634,7 +9634,7 @@ Running Specific Tasks
>   
>   Any given recipe consists of a set of tasks. The standard BitBake
>   behavior in most cases is: :ref:`ref-tasks-fetch`, ``do_unpack``, ``do_patch``,
> -``do_configure``, ``do_compile``, ``do_install``, ``do_package``,
> +``do_configure``, ``do_compile``, :ref:`ref-tasks-install`, ``do_package``,
>   ``do_package_write_*``, and ``do_build``. The default task is
>   ``do_build`` and any tasks on which it depends build first. Some tasks,
>   such as ``do_devshell``, are not part of the default build chain. If you
> diff --git a/documentation/migration-guides/migration-3.2.rst b/documentation/migration-guides/migration-3.2.rst
> index 71778f3e26..8a8d19d605 100644
> --- a/documentation/migration-guides/migration-3.2.rst
> +++ b/documentation/migration-guides/migration-3.2.rst
> @@ -60,7 +60,7 @@ pseudo as the interprocess round trip to the server is avoided.
>   
>   There is a possible complication where some existing recipe may break, for
>   example, a recipe was found to be writing to ``${B}/install`` for
> -``make install`` in ``do_install`` and since ``${B}`` is listed as not to be tracked,
> +``make install`` in :ref:`ref-tasks-install` and since ``${B}`` is listed as not to be tracked,
>   there were errors trying to ``chown root`` for files in this location. Another
>   example was the ``tcl`` recipe where the source directory :term:`S` is set to a
>   subdirectory of the source tree but files were written out to the directory
> @@ -207,7 +207,7 @@ files into a subdirectory and reference that instead.
>   deploy class now cleans ``DEPLOYDIR`` before ``do_deploy``
>   ----------------------------------------------------------
>   
> -``do_deploy`` as implemented in the :ref:`deploy <ref-classes-deploy>` class now cleans up ${:term:`DEPLOYDIR`} before running, just as ``do_install`` cleans up ${:term:`D`} before running. This reduces the risk of :term:`DEPLOYDIR` being accidentally contaminated by files from previous runs, possibly even with different config, in case of incremental builds.
> +``do_deploy`` as implemented in the :ref:`deploy <ref-classes-deploy>` class now cleans up ${:term:`DEPLOYDIR`} before running, just as :ref:`ref-tasks-install` cleans up ${:term:`D`} before running. This reduces the risk of :term:`DEPLOYDIR` being accidentally contaminated by files from previous runs, possibly even with different config, in case of incremental builds.
>   
>   Most recipes and classes that inherit the :ref:`deploy <ref-classes-deploy>` class or interact with ``do_deploy`` are unlikely to be affected by this unless they add ``prefuncs`` to ``do_deploy`` *which also* put files into ``${DEPLOYDIR}`` --- these should be refactored to use ``do_deploy_prepend`` instead.
>   
> diff --git a/documentation/migration-guides/migration-4.0.rst b/documentation/migration-guides/migration-4.0.rst
> index ce3212a464..02d3c3e2bd 100644
> --- a/documentation/migration-guides/migration-4.0.rst
> +++ b/documentation/migration-guides/migration-4.0.rst
> @@ -145,7 +145,7 @@ Python changes
>     :ref:`python_setuptools_build_meta <ref-classes-python_setuptools_build_meta>`
>     and :ref:`python_poetry_core <ref-classes-python_poetry_core>`.
>   
> -- The :ref:`setuptools3 <ref-classes-setuptools3>` class ``do_install()`` task now
> +- The :ref:`setuptools3 <ref-classes-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 standard
> diff --git a/documentation/overview-manual/concepts.rst b/documentation/overview-manual/concepts.rst
> index fa060ce0de..2e1aa3df48 100644
> --- a/documentation/overview-manual/concepts.rst
> +++ b/documentation/overview-manual/concepts.rst
> @@ -1209,7 +1209,7 @@ 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 :ref:`ref-tasks-fetch`, ``do_unpack``, ``do_patch``,
> -``do_configure``, ``do_compile``, and ``do_install`` tasks. However, if
> +``do_configure``, ``do_compile``, and :ref:`ref-tasks-install` tasks. However, if
>   ``do_package`` needs to be run, BitBake needs to run those other tasks.
>   
>   It becomes more complicated if everything can come from an sstate cache
> @@ -2163,7 +2163,7 @@ operations that are normally reserved for the root user (e.g.
>   :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
> +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
> diff --git a/documentation/ref-manual/classes.rst b/documentation/ref-manual/classes.rst
> index 11e0d472e8..6e37738850 100644
> --- a/documentation/ref-manual/classes.rst
> +++ b/documentation/ref-manual/classes.rst
> @@ -1081,12 +1081,12 @@ Here are the tests you can list with the :term:`WARN_QA` and
>      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`,
> @@ -1339,7 +1339,7 @@ Only a single U-boot boot script can be added to the FIT image created by
>   ``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.
> @@ -2412,7 +2412,7 @@ uses these build systems, the recipe needs to inherit the ``setuptools3`` class.
>   
>      .. 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
> diff --git a/documentation/ref-manual/faq.rst b/documentation/ref-manual/faq.rst
> index 61049523a0..cb90677923 100644
> --- a/documentation/ref-manual/faq.rst
> +++ b/documentation/ref-manual/faq.rst
> @@ -437,7 +437,7 @@ practice very effective.
>   **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/documentation/ref-manual/qa-checks.rst b/documentation/ref-manual/qa-checks.rst
> index fbab1dc92e..ff8916aedf 100644
> --- a/documentation/ref-manual/qa-checks.rst
> +++ b/documentation/ref-manual/qa-checks.rst
> @@ -162,7 +162,7 @@ Errors and Warnings
>      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 @@ Errors and Warnings
>         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 @@ Errors and Warnings
>      ``${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 @@ Errors and Warnings
>       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 @@ Errors and Warnings
>   
>       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.
>   
> diff --git a/documentation/ref-manual/tasks.rst b/documentation/ref-manual/tasks.rst
> index cb08a75c90..f3aebcecc3 100644
> --- a/documentation/ref-manual/tasks.rst
> +++ b/documentation/ref-manual/tasks.rst
> @@ -168,7 +168,7 @@ section in the Yocto Project Overview and Concepts Manual.
>   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-rootfs`), run under
> diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst
> index 2971654531..060bf499bb 100644
> --- a/documentation/ref-manual/variables.rst
> +++ b/documentation/ref-manual/variables.rst
> @@ -5633,7 +5633,7 @@ system and gives an overview of their function and contents.
>            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`"
> diff --git a/documentation/sdk-manual/extensible.rst b/documentation/sdk-manual/extensible.rst
> index 0df6519b8e..09b7169811 100644
> --- a/documentation/sdk-manual/extensible.rst
> +++ b/documentation/sdk-manual/extensible.rst
> @@ -1112,7 +1112,7 @@ links created within the source tree:
>         ``${``\ :term:`D`\ ``}``.
>   
>      -  ``sysroot-destdir/``: Contains a subset of files installed within
> -      ``do_install`` that have been put into the shared sysroot. For
> +      :ref:`ref-tasks-install` that have been put into the shared sysroot. For
>         more information, see the
>         ":ref:`dev-manual/common-tasks:sharing files between recipes`" section.
>   
> 
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#3217): https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.yoctoproject.org_g_docs_message_3217&d=DwIFaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=wQ5vvwPahFb4Yk7vrUzL6iTWRM2erXsbRtK-aKhf1BHWON8AvFgpu-fLeEzzc3PB&s=OH661Yo6S0WMC1be-td0DrCm-qxPS7MoFKSa-0CR0i4&e=
> Mute This Topic: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.yoctoproject.org_mt_93876094_6293953&d=DwIFaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=wQ5vvwPahFb4Yk7vrUzL6iTWRM2erXsbRtK-aKhf1BHWON8AvFgpu-fLeEzzc3PB&s=pStDeYATg6Sr2uKZuvSysx00okpfZqtasgl4zCgCiYg&e=
> Group Owner: docs+owner@lists.yoctoproject.org
> Unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.yoctoproject.org_g_docs_unsub&d=DwIFaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=wQ5vvwPahFb4Yk7vrUzL6iTWRM2erXsbRtK-aKhf1BHWON8AvFgpu-fLeEzzc3PB&s=KJZa0SiMjKVu-5aBRxuDeEhGCWFPGLHyXYys3gryzsw&e=  [quentin.schulz@theobroma-systems.com]
> -=-=-=-=-=-=-=-=-=-=-=-
> 

Re: [docs] [PATCH 06/30] manuals: add references to the "do_deploy" task

[Quentin Schulz]

Hi Michael,

On 9/23/22 19:51, Michael Opdenacker via lists.yoctoproject.org wrote:
> From: Michael Opdenacker <michael.opdenacker@bootlin.com>
> 
> [YOCTO #14508]
> Reported-by: Quentin Schulz <foss@0leil.net>
> Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
> ---

Missing one:
https://git.yoctoproject.org/yocto-docs/tree/documentation/migration-guides/migration-3.2.rst#n210

Cheers,
Quentin

>   .../migration-guides/migration-3.2.rst         |  4 ++--
>   documentation/overview-manual/concepts.rst     | 18 +++++++++---------
>   documentation/ref-manual/tasks.rst             |  8 ++++----
>   documentation/ref-manual/variables.rst         |  2 +-
>   4 files changed, 16 insertions(+), 16 deletions(-)
> 
> diff --git a/documentation/migration-guides/migration-3.2.rst b/documentation/migration-guides/migration-3.2.rst
> index 8a8d19d605..4c0de7b0f6 100644
> --- a/documentation/migration-guides/migration-3.2.rst
> +++ b/documentation/migration-guides/migration-3.2.rst
> @@ -207,9 +207,9 @@ files into a subdirectory and reference that instead.
>   deploy class now cleans ``DEPLOYDIR`` before ``do_deploy``
>   ----------------------------------------------------------
>   
> -``do_deploy`` as implemented in the :ref:`deploy <ref-classes-deploy>` class now cleans up ${:term:`DEPLOYDIR`} before running, just as :ref:`ref-tasks-install` cleans up ${:term:`D`} before running. This reduces the risk of :term:`DEPLOYDIR` being accidentally contaminated by files from previous runs, possibly even with different config, in case of incremental builds.
> +:ref:`ref-tasks-deploy` as implemented in the :ref:`deploy <ref-classes-deploy>` class now cleans up ${:term:`DEPLOYDIR`} before running, just as :ref:`ref-tasks-install` cleans up ${:term:`D`} before running. This reduces the risk of :term:`DEPLOYDIR` being accidentally contaminated by files from previous runs, possibly even with different config, in case of incremental builds.
>   
> -Most recipes and classes that inherit the :ref:`deploy <ref-classes-deploy>` class or interact with ``do_deploy`` are unlikely to be affected by this unless they add ``prefuncs`` to ``do_deploy`` *which also* put files into ``${DEPLOYDIR}`` --- these should be refactored to use ``do_deploy_prepend`` instead.
> +Most recipes and classes that inherit the :ref:`deploy <ref-classes-deploy>` class or interact with :ref:`ref-tasks-deploy` are unlikely to be affected by this unless they add ``prefuncs`` to :ref:`ref-tasks-deploy` *which also* put files into ``${DEPLOYDIR}`` --- these should be refactored to use ``do_deploy_prepend`` instead.
>   
>   
>   .. _migration-3.2-nativesdk-sdk-provides-dummy:
> diff --git a/documentation/overview-manual/concepts.rst b/documentation/overview-manual/concepts.rst
> index 06220401bc..f3f8cbd95c 100644
> --- a/documentation/overview-manual/concepts.rst
> +++ b/documentation/overview-manual/concepts.rst
> @@ -1801,14 +1801,14 @@ from the :ref:`deploy <ref-classes-deploy>` class::
>   
>   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 +1818,15 @@ The following list explains the previous example:
>   
>      .. 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 +1836,16 @@ The following list explains the previous example:
>         }
>         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.
> diff --git a/documentation/ref-manual/tasks.rst b/documentation/ref-manual/tasks.rst
> index e5938ee236..5efe64b35d 100644
> --- a/documentation/ref-manual/tasks.rst
> +++ b/documentation/ref-manual/tasks.rst
> @@ -81,7 +81,7 @@ Recipes implementing this task should inherit the
>   :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 @@ output from ``${DEPLOYDIR}`` to ``${DEPLOY_DIR_IMAGE}``.
>      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 @@ Adding ``do_deploy`` after other tasks works the same way.
>      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:
> diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst
> index 8055f044d0..8fac7f77ad 100644
> --- a/documentation/ref-manual/variables.rst
> +++ b/documentation/ref-manual/variables.rst
> @@ -6712,7 +6712,7 @@ system and gives an overview of their function and contents.
>         - do_populate_lic
>         - do_package_qa
>         - do_populate_sysroot
> -      - do_deploy
> +      - :ref:`ref-tasks-deploy`
>   
>         Despite the default value of "" for the
>         :term:`SDK_RECRDEP_TASKS` variable, the above four tasks are always added
> 
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#3221): https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.yoctoproject.org_g_docs_message_3221&d=DwIFaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=F4I8M4SGcdazHCULA4b6vl9pU2JK4-B0XBUvtEqEX2ylNswIzUdWZ3CCfiIiibuD&s=ZEyJmQPpQCxzN0I8nTIITQMrc8SiUNh09KC0AxVJhp0&e=
> Mute This Topic: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.yoctoproject.org_mt_93876107_6293953&d=DwIFaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=F4I8M4SGcdazHCULA4b6vl9pU2JK4-B0XBUvtEqEX2ylNswIzUdWZ3CCfiIiibuD&s=BFZheqvjA3rsYQi2OpLkymqO-SSiALZOk8nJIzBDmOI&e=
> Group Owner: docs+owner@lists.yoctoproject.org
> Unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.yoctoproject.org_g_docs_unsub&d=DwIFaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=F4I8M4SGcdazHCULA4b6vl9pU2JK4-B0XBUvtEqEX2ylNswIzUdWZ3CCfiIiibuD&s=euGgllMDt11J4RgqDdpdhWuZkm2IFiAUyowdcsO3LWc&e=  [quentin.schulz@theobroma-systems.com]
> -=-=-=-=-=-=-=-=-=-=-=-
> 

Re: [docs] [PATCH 04/30] manuals: add reference to "do_configure" task

[Michael Opdenacker]

On 26.09.22 15:57, Quentin Schulz via lists.yoctoproject.org wrote:
> Hi Michael,
>
> On 9/23/22 19:51, Michael Opdenacker via lists.yoctoproject.org wrote:
>> From: Michael Opdenacker <michael.opdenacker@bootlin.com>
>>
>> [YOCTO #14508]
>> Reported-by: Quentin Schulz <foss@0leil.net>
>> Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
>
> You're missing one:
>
> https://git.yoctoproject.org/yocto-docs/tree/documentation/ref-manual/variables.rst#n5524


Fixed, thanks!

-- 
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [docs] [PATCH 02/30] manuals: add reference to the "do_install" task

[Michael Opdenacker]

On 26.09.22 16:04, Quentin Schulz wrote:
> Hi Michael,
>
> On 9/23/22 19:51, Michael Opdenacker via lists.yoctoproject.org wrote:
>> From: Michael Opdenacker <michael.opdenacker@bootlin.com>
>>
>> [YOCTO #14508]
>> Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
>> Reported-by: Quentin Schulz <foss@0leil.net>
>> ---
>
> Missing a few:
> https://git.yoctoproject.org/yocto-docs/tree/documentation/dev-manual/common-tasks.rst#n1916 
>
> https://git.yoctoproject.org/yocto-docs/tree/documentation/dev-manual/common-tasks.rst#n1926 
>
> https://git.yoctoproject.org/yocto-docs/tree/documentation/dev-manual/common-tasks.rst#n1983 
>


Oops, fixed, thanks.
Michael.

-- 
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [docs] [PATCH 06/30] manuals: add references to the "do_deploy" task

[Michael Opdenacker]

On 26.09.22 16:04, Quentin Schulz wrote:
> Hi Michael,
>
> On 9/23/22 19:51, Michael Opdenacker via lists.yoctoproject.org wrote:
>> From: Michael Opdenacker <michael.opdenacker@bootlin.com>
>>
>> [YOCTO #14508]
>> Reported-by: Quentin Schulz <foss@0leil.net>
>> Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
>> ---
>
> Missing one:
> https://git.yoctoproject.org/yocto-docs/tree/documentation/migration-guides/migration-3.2.rst#n210 
>


Actually, my patch has this change, unless your thought about the 
instance on the title line 
(https://git.yoctoproject.org/yocto-docs/tree/documentation/migration-guides/migration-3.2.rst#n207), 
but then I didn't want to add links to section titles.

Thanks for checking
Michael.

-- 
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [docs] [PATCH 00/30] manuals: add missing references to tasks

[Michael Opdenacker]

On 26.09.22 16:00, Quentin Schulz via lists.yoctoproject.org wrote:
> Hi Michael,
>
> On 9/23/22 19:51, Michael Opdenacker via lists.yoctoproject.org wrote:
>> From: Michael Opdenacker <michael.opdenacker@bootlin.com>
>>
>> manuals: add missing references to tasks
>>
>> As suggested by Quentin Schulz on 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.yoctoproject.org_show-5Fbug.cgi-3Fid-3D14508&d=DwIDAg&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=HuSyEeTT-KxIT3uX-8IenyuDr00g1CP3df1fW1p3wdbCHI96kWRHSCTRw9BLNyWR&s=UWoJbMECYt0997xRv7yfZIXOJ4HiCK0Kk57CApO1lwc&e=
>>
>
> There are a few rogue do_image_complete we can convert still.


Good catch! I found two instances. Fixed.

Many thanks for everything!
Michael.

-- 
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [docs] [PATCH 06/30] manuals: add references to the "do_deploy" task

[Quentin Schulz]

Hi Michael,

On 10/5/22 19:57, Michael Opdenacker wrote:
> Hi Quentin,
> 
> Many thanks for the reviews and your patience!
> 
> On 26.09.22 15:40, Quentin Schulz wrote:
>> Hi Michael,
>>
>> On 9/23/22 19:51, Michael Opdenacker via lists.yoctoproject.org wrote:
>>> From: Michael Opdenacker <michael.opdenacker@bootlin.com>
>>>
>>> [YOCTO #14508]
>>> Reported-by: Quentin Schulz <foss@0leil.net>
>>> Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
>>> ---
>>>   .../migration-guides/migration-3.2.rst         |  4 ++--
>>>   documentation/overview-manual/concepts.rst     | 18 +++++++++---------
>>>   documentation/ref-manual/tasks.rst             |  8 ++++----
>>>   documentation/ref-manual/variables.rst         |  2 +-
>>>   4 files changed, 16 insertions(+), 16 deletions(-)
>>>
>>> diff --git a/documentation/migration-guides/migration-3.2.rst 
>>> b/documentation/migration-guides/migration-3.2.rst
>>> index 8a8d19d605..4c0de7b0f6 100644
>>> --- a/documentation/migration-guides/migration-3.2.rst
>>> +++ b/documentation/migration-guides/migration-3.2.rst
>>> @@ -207,9 +207,9 @@ files into a subdirectory and reference that 
>>> instead.
>>>   deploy class now cleans ``DEPLOYDIR`` before ``do_deploy``
>>>   ----------------------------------------------------------
>>>   -``do_deploy`` as implemented in the :ref:`deploy 
>>> <ref-classes-deploy>` class now cleans up ${:term:`DEPLOYDIR`} before 
>>> running, just as :ref:`ref-tasks-install` cleans up ${:term:`D`} 
>>> before running. This reduces the risk of :term:`DEPLOYDIR` being 
>>> accidentally contaminated by files from previous runs, possibly even 
>>> with different config, in case of incremental builds.
>>> +:ref:`ref-tasks-deploy` as implemented in the :ref:`deploy 
>>> <ref-classes-deploy>` class now cleans up ${:term:`DEPLOYDIR`} before 
>>> running, just as :ref:`ref-tasks-install` cleans up ${:term:`D`} 
>>> before running. This reduces the risk of :term:`DEPLOYDIR` being 
>>> accidentally contaminated by files from previous runs, possibly even 
>>> with different config, in case of incremental builds.
>>>   -Most recipes and classes that inherit the :ref:`deploy 
>>> <ref-classes-deploy>` class or interact with ``do_deploy`` are 
>>> unlikely to be affected by this unless they add ``prefuncs`` to 
>>> ``do_deploy`` *which also* put files into ``${DEPLOYDIR}`` --- these 
>>> should be refactored to use ``do_deploy_prepend`` instead.
>>> +Most recipes and classes that inherit the :ref:`deploy 
>>> <ref-classes-deploy>` class or interact with :ref:`ref-tasks-deploy` 
>>> are unlikely to be affected by this unless they add ``prefuncs`` to 
>>> :ref:`ref-tasks-deploy` *which also* put files into ``${DEPLOYDIR}`` 
>>> --- these should be refactored to use ``do_deploy_prepend`` instead.
>>>       .. _migration-3.2-nativesdk-sdk-provides-dummy:
>>> diff --git a/documentation/overview-manual/concepts.rst 
>>> b/documentation/overview-manual/concepts.rst
>>> index 06220401bc..f3f8cbd95c 100644
>>> --- a/documentation/overview-manual/concepts.rst
>>> +++ b/documentation/overview-manual/concepts.rst
>>> @@ -1801,14 +1801,14 @@ from the :ref:`deploy <ref-classes-deploy>` 
>>> class::
>>>     The following list explains the previous example:
>>>   --  Adding "do_deploy" to ``SSTATETASKS`` adds some required
>>> +-  Adding ``do_deploy`` to ``SSTATETASKS`` adds some required
>>
>> You missed one here.
> 
> 
> Actually, here we have a string to be added to a variable. Having a link 
> here may hide the fact that this is a string, and it's a bit like giving 
> a piece of code.
> Don't hesitate to disagree!
No, kind of makes sense.

Cheers,
Quentin

Re: [docs] [PATCH 06/30] manuals: add references to the "do_deploy" task

[Quentin Schulz]

Hi Michael,

On 10/5/22 20:11, Michael Opdenacker wrote:
> 
> On 26.09.22 16:04, Quentin Schulz wrote:
>> Hi Michael,
>>
>> On 9/23/22 19:51, Michael Opdenacker via lists.yoctoproject.org wrote:
>>> From: Michael Opdenacker <michael.opdenacker@bootlin.com>
>>>
>>> [YOCTO #14508]
>>> Reported-by: Quentin Schulz <foss@0leil.net>
>>> Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
>>> ---
>>
>> Missing one:
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.yoctoproject.org_yocto-2Ddocs_tree_documentation_migration-2Dguides_migration-2D3.2.rst-23n210&d=DwICaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=tklDwq7KiSJJAzIdRIMrg5CO3BL4eh46cNdDXhIqVCblv2dPMQ4EHtSzD0hTGUIj&s=lZwEwoYcbSMrbdIrodxOoacnAGgXVqGLaYZq8aze9qM&e=
> 
> 
> Actually, my patch has this change, unless your thought about the 
> instance on the title line 
> (https://urldefense.proofpoint.com/v2/url?u=https-3A__git.yoctoproject.org_yocto-2Ddocs_tree_documentation_migration-2Dguides_migration-2D3.2.rst-23n207&d=DwICaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=tklDwq7KiSJJAzIdRIMrg5CO3BL4eh46cNdDXhIqVCblv2dPMQ4EHtSzD0hTGUIj&s=6C9bFwADJEfE32pZCwMjwm8f8EopviCTupqux1FKXhM&e= ), but then I didn't want to add links to section titles.
> 

It has the change, don't know where I mixed things up. Sorry for the noise.

Cheers,
Quentin