poky: subtree update:0ac99625bf..796be0593a

Alexander Kanavin (31):
      netbase: upgrade 6.1 -> 6.2
      meson: upgrade 0.55.1 -> 0.56.0
      vulkan-samples: update to latest revision
      libcap: update 2.44 -> 2.45
      bind: upgrade 9.16.7 -> 9.16.9
      quota: upgrade 4.05 -> 4.06
      pango: upgrade 1.46.2 -> 1.48.0
      elfutils: upgrade 0.181 -> 0.182
      ifupdown: upgrade 0.8.35 -> 0.8.36
      createrepo-c: upgrade 0.16.1 -> 0.16.2
      acpica: upgrade 20200925 -> 20201113
      grep: upgrade 3.5 -> 3.6
      man-pages: upgrade 5.08 -> 5.09
      stress-ng: upgrade 0.11.23 -> 0.11.24
      libhandy: upgrade 1.0.1 -> 1.0.2
      piglit: upgrade to latest revision
      xkbcomp: upgrade 1.4.3 -> 1.4.4
      lz4: upgrade 1.9.2 -> 1.9.3
      bison: upgrade 3.7.3 -> 3.7.4
      python3-setuptools-scm: fix upstream version check
      cantarell-fonts: update 0.0.25 -> 0.201
      meta/lib/oe/reproducible.py: gitsm:// works just as fine as git:// for timestamps
      llvm: fix reproducibility
      ruby: fix reproducibility
      webkitgtk: fix reproducibility
      ffmpeg: fix reproducibility
      piglit: fix reproducibility
      serf: do not install the static library
      llvm: sort the lists in generated source reproducibibly
      kea: fix reproducibility
      poky.conf: do not write current date into distro version, use git hash instead

Andrej Valek (1):
      kernel-dummy: fix executing unexpected tasks

Anuj Mittal (1):
      releases.rst: add gatesgarth to current releases

Brett Warren (1):
      libffi: add patch to revert clang VFP workaround

Chandana kalluri (1):
      populate_sdk_ext: use SDK_CUSTOM_TEPLATECONF variable to enable custom templateconf.cfg

Changqing Li (1):
      buildtools-tarball: add wic dependency into extended buildtools

Diego Sueiro (2):
      modutils-initscripts: Fix modules.dep creation when USE_DEPMOD="0"
      initscripts: Change execution order between checkroot and modutils

Dmitry Baryshkov (2):
      linux-firmware: upgrade 20201022 -> 20201118
      linux-firmware: package ath11k firmware

Fabio Berton (1):
      mesa: Update 20.2.1 -> 20.2.4

Gratian Crisan (1):
      kernel-module-split.bbclass: fix kernel modules getting marked as CONFFILES

Jack Mitchell (3):
      Revert "connman: set service to conflict with systemd-networkd"
      systemd-conf: add PACKAGECONFIG to enable/disable auto ethernet DHCP
      systemd-conf: match ethernet interfaces by type rather than globbing

Joshua Watt (2):
      bitbake: hashserv: client: Fix AF_UNIX path length limits
      bitbake: hashserv: Fix broken AF_UNIX path length limit

Kai Kang (2):
      systemd-systemctl-native: capable to call without argument
      systemd.bbclass: update command to check systemctl available

Kevin Hao (1):
      tune-octeontx2.inc: Add tune for Marvell OCTEON TX2 core

Li Wang (2):
      qemu: CVE-2020-29129 CVE-2020-29130
      qemu: CVE-2020-25624

Luca Boccassi (1):
      dbus: move messagebus user to dbus-common package

Michael Halstead (1):
      releases: conf: add link to 3.1.4, update to include 3.1.4

Nicolas Dechesne (19):
      sphinx: add .vscode in .gitignore
      {dev,kernel,sdk}-manual: replace hardcoded release version with &DISTRO;
      sphinx: replace bitbake labels with references to corresponding title
      brief-yoctoprojectqs: replace labels with references to section title
      dev-manual: replace labels with references to section title
      ref-manual: replace labels with references to section title
      sdk-manual: replace labels with references to section title
      overview-manual: remove unused labels
      dev-manual: remove unused labels
      sphinx: rename top level document in each manual
      sphinx: use absolute paths for :doc: references
      test-manual: remove 'test-manual' from filenames
      toaster-manual: remove 'toaster-manual' from filenames
      dev-manual: remove 'dev-manual' from filenames
      kernel-dev: remove 'kernel-dev' from filenames
      profile-manual: remove 'profile-manual' from filenames
      overview-manual: remove 'overview-manual' from filenames
      sdk-manual: remove 'sdk' from filenames
      ref-manual: remove 'ref' from filenames

Paul Barker (5):
      documentation: Simplify yocto_wiki links
      documentation: Simplify yocto_git links
      ref-manual: Simplify oe_git links
      poky.conf: Add opensuseleap-15.2 and fedora-33 to tested distros
      poky.conf: Drop fedora-30 from tested distros

Peter Kjellerstedt (2):
      pseudo: Simplify pseudo_client_ignore_path_chroot()
      bitbake.conf: Add all layers (from BBLAYERS) to PSEUDO_IGNORE_PATHS

Richard Purdie (8):
      lz4: Use the new branch naming from upstream
      Revert "bitbake.conf: Add all layers (from BBLAYERS) to PSEUDO_IGNORE_PATHS"
      build-appliance-image: Update to master head revision
      bitbake: Revert "fetch2: use relative symlinks for anything pulled from PREMIRRORS"
      build-appliance-image: Update to master head revision
      metadata_scm: Fix signature handling of METADATA_REVISION and METADATA_BRANCH
      poky: Set SDK_VERSION explicitly
      build-appliance-image: Update to master head revision

Ross Burton (9):
      oeqa/devtool: use Yocto mirror for pv-1.5.3 tarball
      image_types: remove obsolete tar comment
      image_types: sort tarball file listings
      package_manager/ipk: neaten OPKGLIBDIR logic
      ldconfig-native: don't write auxiliary cache
      package_manager/ipk: improve remove_packaging_data
      oeqa/selftest/containerimage: update for improved cleanup
      coreutils: add SUSE-specific issues to CVE whitelist
      bitbake: msg: use safe YAML loader

Sinan Kaya (1):
      poky-tiny: enable section removal

Tomasz Dziendzielski (1):
      pseudo: Update to print PSEUDO_LOGFILE in abort message on path mismatches

sangeeta jain (1):
      meta/lib/oeqa/manual/oe-core.json: Update test_bitbake_devshell

zangrc (3):
      libinput: upgrade 1.16.3 -> 1.16.4
      lighttpd: upgrade 1.4.55 -> 1.4.56
      sysstat: upgrade 12.4.0 -> 12.4.1

Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
Change-Id: I65f2f1c9d44433f3e62609240012c42256679b51

5 files changed, 138 insertions, 386 deletions

diff --git a/poky/documentation/dev-manual/dev-manual-common-tasks.rst b/poky/documentation/dev-manual/common-tasks.rst
index 683f5557e..ada3bac7e 100644
--- a/poky/documentation/dev-manual/dev-manual-common-tasks.rst
+++ b/poky/documentation/dev-manual/common-tasks.rst
@@ -18,7 +18,7 @@ The OpenEmbedded build system supports organizing
 Layers allow you to isolate different types of customizations from each
 other. For introductory information on the Yocto Project Layer Model,
 see the
-":ref:`overview-manual/overview-manual-yp-intro:the yocto project layer model`"
+":ref:`overview-manual/yp-intro:the yocto project layer model`"
 section in the Yocto Project Overview and Concepts Manual.
 
 Creating Your Own Layer
@@ -31,7 +31,7 @@ layers so that you can better understand them. For information about the
 layer-creation tools, see the
 ":ref:`bsp-guide/bsp:creating a new bsp layer using the \`\`bitbake-layers\`\` script`"
 section in the Yocto Project Board Support Package (BSP) Developer's
-Guide and the ":ref:`dev-manual/dev-manual-common-tasks:creating a general layer using the \`\`bitbake-layers\`\` script`"
+Guide and the ":ref:`dev-manual/common-tasks:creating a general layer using the \`\`bitbake-layers\`\` script`"
 section further down in this manual.
 
 Follow these general steps to create your layer without using tools:
@@ -75,7 +75,7 @@ Follow these general steps to create your layer without using tools:
    ``conf`` directory and then modify the file as needed.
 
    The ``meta-yocto-bsp/conf/layer.conf`` file in the Yocto Project
-   :yocto_git:`Source Repositories </cgit/cgit.cgi/poky/tree/meta-yocto-bsp/conf>`
+   :yocto_git:`Source Repositories </poky/tree/meta-yocto-bsp/conf>`
    demonstrates the required syntax. For your layer, you need to replace
    "yoctobsp" with a unique identifier for your layer (e.g. "machinexyz"
    for a layer named "meta-machinexyz"):
@@ -135,7 +135,7 @@ Follow these general steps to create your layer without using tools:
       Lists all layers on which this layer depends (if any).
 
    -  :term:`LAYERSERIES_COMPAT`:
-      Lists the :yocto_wiki:`Yocto Project </wiki/Releases>`
+      Lists the :yocto_wiki:`Yocto Project </Releases>`
       releases for which the current version is compatible. This
       variable is a good way to indicate if your particular layer is
       current.
@@ -160,8 +160,6 @@ Follow these general steps to create your layer without using tools:
    Project <#making-sure-your-layer-is-compatible-with-yocto-project>`__"
    section for more information.
 
-.. _best-practices-to-follow-when-creating-layers:
-
 Following Best Practices When Creating Layers
 ---------------------------------------------
 
@@ -457,8 +455,6 @@ file. During the processing of each ``conf/layer.conf`` file, BitBake
 adds the recipes, classes and configurations contained within the
 particular layer to the source directory.
 
-.. _using-bbappend-files:
-
 Using .bbappend Files in Your Layer
 -----------------------------------
 
@@ -729,7 +725,7 @@ simplifies creating a new general layer.
 
    -  In order to use a layer with the OpenEmbedded build system, you
       need to add the layer to your ``bblayers.conf`` configuration
-      file. See the ":ref:`dev-manual/dev-manual-common-tasks:adding a layer using the \`\`bitbake-layers\`\` script`"
+      file. See the ":ref:`dev-manual/common-tasks:adding a layer using the \`\`bitbake-layers\`\` script`"
       section for more information.
 
 The default mode of the script's operation with this subcommand is to
@@ -839,16 +835,12 @@ enables the build system to locate the layer during the build.
    During a build, the OpenEmbedded build system looks in the layers
    from the top of the list down to the bottom in that order.
 
-.. _usingpoky-extend-customimage:
-
 Customizing Images
 ==================
 
 You can customize images to satisfy particular requirements. This
 section describes several methods and provides guidelines for each.
 
-.. _usingpoky-extend-customimage-localconf:
-
 Customizing Images Using ``local.conf``
 ---------------------------------------
 
@@ -891,8 +883,6 @@ You can add packages using a similar approach through the
 ``CORE_IMAGE_EXTRA_INSTALL`` variable. If you use this variable, only
 ``core-image-*`` images are affected.
 
-.. _usingpoky-extend-customimage-imagefeatures:
-
 Customizing Images Using Custom ``IMAGE_FEATURES`` and ``EXTRA_IMAGE_FEATURES``
 -------------------------------------------------------------------------------
 
@@ -945,12 +935,10 @@ configures the image you are working with to include
 
 .. note::
 
-   See the ":ref:`ref-manual/ref-features:image features`" section in the Yocto
+   See the ":ref:`ref-manual/features:image features`" section in the Yocto
    Project Reference Manual for a complete list of image features that ship
    with the Yocto Project.
 
-.. _usingpoky-extend-customimage-custombb:
-
 Customizing Images Using Custom .bb Files
 -----------------------------------------
 
@@ -977,8 +965,6 @@ image, copy the ``meta/recipes-sato/images/core-image-sato.bb`` to a new
 
    IMAGE_INSTALL += "strace"
 
-.. _usingpoky-extend-customimage-customtasks:
-
 Customizing Images Using Custom Package Groups
 ----------------------------------------------
 
@@ -1039,8 +1025,6 @@ build an image using these package group packages, you need to add
 ``IMAGE_INSTALL``. For other forms of image dependencies see the other
 areas of this section.
 
-.. _usingpoky-extend-customimage-image-name:
-
 Customizing an Image Hostname
 -----------------------------
 
@@ -1080,8 +1064,6 @@ unsets the variable in a configuration file:
 Having no default hostname in the filesystem is suitable for
 environments that use dynamic hostnames such as virtual machines.
 
-.. _new-recipe-writing-a-new-recipe:
-
 Writing a New Recipe
 ====================
 
@@ -1094,11 +1076,9 @@ how to create, write, and test a new recipe.
 
    For information on variables that are useful for recipes and for
    information about recipe naming issues, see the
-   ":ref:`ref-manual/ref-varlocality:recipes`" section of the Yocto Project
+   ":ref:`ref-manual/varlocality:recipes`" section of the Yocto Project
    Reference Manual.
 
-.. _new-recipe-overview:
-
 Overview
 --------
 
@@ -1108,8 +1088,6 @@ The remainder of the section provides details for the steps.
 .. image:: figures/recipe-workflow.png
    :align: center
 
-.. _new-recipe-locate-or-automatically-create-a-base-recipe:
-
 Locate or Automatically Create a Base Recipe
 --------------------------------------------
 
@@ -1128,9 +1106,7 @@ that can help you quickly get a start on a new recipe:
 .. note::
 
    For information on recipe syntax, see the
-   ":ref:`dev-manual/dev-manual-common-tasks:recipe syntax`" section.
-
-.. _new-recipe-creating-the-base-recipe-using-devtool:
+   ":ref:`dev-manual/common-tasks:recipe syntax`" section.
 
 Creating the Base Recipe Using ``devtool add``
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -1143,12 +1119,10 @@ necessary when adding a recipe to build a new piece of software to be
 included in a build.
 
 You can find a complete description of the ``devtool add`` command in
-the ":ref:`sdk-manual/sdk-extensible:a closer look at \`\`devtool add\`\``" section
+the ":ref:`sdk-manual/extensible:a closer look at \`\`devtool add\`\``" section
 in the Yocto Project Application Development and the Extensible Software
 Development Kit (eSDK) manual.
 
-.. _new-recipe-creating-the-base-recipe-using-recipetool:
-
 Creating the Base Recipe Using ``recipetool create``
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -1213,8 +1187,6 @@ Following are some syntax examples:
 
       recipetool create -d -o OUTFILE source
 
-.. _new-recipe-locating-and-using-a-similar-recipe:
-
 Locating and Using a Similar Recipe
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -1254,8 +1226,6 @@ get started. Here are some points on both methods:
 
       SRC_URI = ""
 
-.. _new-recipe-storing-and-naming-the-recipe:
-
 Storing and Naming the Recipe
 -----------------------------
 
@@ -1298,8 +1268,6 @@ the recipe.
       gawk_4.0.2.bb
       irssi_0.8.16-rc1.bb
 
-.. _new-recipe-running-a-build-on-the-recipe:
-
 Running a Build on the Recipe
 -----------------------------
 
@@ -1351,11 +1319,9 @@ to determine how well the build went.
    ``log.do_fetch``, and ``log.do_compile``).
 
 You can find more information about the build process in
-":doc:`../overview-manual/overview-manual-development-environment`"
+":doc:`/overview-manual/development-environment`"
 chapter of the Yocto Project Overview and Concepts Manual.
 
-.. _new-recipe-fetching-code:
-
 Fetching Code
 -------------
 
@@ -1364,12 +1330,12 @@ files. Fetching is controlled mainly through the
 :term:`SRC_URI` variable. Your recipe
 must have a ``SRC_URI`` variable that points to where the source is
 located. For a graphical representation of source locations, see the
-":ref:`sources-dev-environment`" section in
+":ref:`overview-manual/concepts:sources`" section in
 the Yocto Project Overview and Concepts Manual.
 
 The :ref:`ref-tasks-fetch` task uses
 the prefix of each entry in the ``SRC_URI`` variable value to determine
-which :ref:`fetcher <bitbake:bb-fetchers>` to use to get your
+which :ref:`fetcher <bitbake:bitbake-user-manual/bitbake-user-manual-fetching:fetchers>` to use to get your
 source files. It is the ``SRC_URI`` variable that triggers the fetcher.
 The :ref:`ref-tasks-patch` task uses
 the variable after source is fetched to apply patches. The OpenEmbedded
@@ -1490,8 +1456,6 @@ compressed suffixes such as ``diff.gz`` and ``patch.bz2``, for example.
 The build system automatically applies patches as described in the
 "`Patching Code <#new-recipe-patching-code>`__" section.
 
-.. _new-recipe-unpacking-code:
-
 Unpacking Code
 --------------
 
@@ -1512,8 +1476,6 @@ If processing your recipe using BitBake successfully unpacks the source
 files, you need to be sure that the directory pointed to by ``${S}``
 matches the structure of the source.
 
-.. _new-recipe-patching-code:
-
 Patching Code
 -------------
 
@@ -1539,8 +1501,6 @@ named the same as the base name of the recipe
 (:term:`BP` and
 :term:`BPN`) or "files".
 
-.. _new-recipe-licensing:
-
 Licensing
 ---------
 
@@ -1578,7 +1538,7 @@ variables:
    differences result in an error with the message containing the
    current checksum. For more explanation and examples of how to set the
    ``LIC_FILES_CHKSUM`` variable, see the
-   ":ref:`dev-manual/dev-manual-common-tasks:tracking license changes`" section.
+   ":ref:`dev-manual/common-tasks:tracking license changes`" section.
 
    To determine the correct checksum string, you can list the
    appropriate files in the ``LIC_FILES_CHKSUM`` variable with incorrect
@@ -1597,8 +1557,6 @@ variables:
    correct string that you can substitute into the recipe file for a
    subsequent build.
 
-.. _new-dependencies:
-
 Dependencies
 ------------
 
@@ -1641,12 +1599,10 @@ package "example" contains "libexample" and another package "mypackage"
 contains a binary that links to "libexample" then the OpenEmbedded build
 system will automatically add a runtime dependency to "mypackage" on
 "example"). See the
-":ref:`overview-manual/overview-manual-concepts:automatically added runtime dependencies`"
+":ref:`overview-manual/concepts:automatically added runtime dependencies`"
 section in the Yocto Project Overview and Concepts Manual for further
 details.
 
-.. _new-recipe-configuring-the-recipe:
-
 Configuring the Recipe
 ----------------------
 
@@ -1741,8 +1697,6 @@ the software you are building, you can consult the output of the
 ``./configure --help`` command within ``${S}`` or consult the software's
 upstream documentation.
 
-.. _new-recipe-using-headers-to-interface-with-devices:
-
 Using Headers to Interface with Devices
 ---------------------------------------
 
@@ -1802,8 +1756,6 @@ out-of-tree modules. Your recipe will also need the following:
 
    do_configure[depends] += "virtual/kernel:do_shared_workdir"
 
-.. _new-recipe-compilation:
-
 Compilation
 -----------
 
@@ -1819,7 +1771,7 @@ Here are some common issues that cause failures.
    For cases where improper paths are detected for configuration files
    or for when libraries/headers cannot be found, be sure you are using
    the more robust ``pkg-config``. See the note in section
-   ":ref:`dev-manual/dev-manual-common-tasks:Configuring the Recipe`" for additional information.
+   ":ref:`dev-manual/common-tasks:Configuring the Recipe`" for additional information.
 
 -  *Parallel build failures:* These failures manifest themselves as
    intermittent errors, or errors reporting that a file or directory
@@ -1867,8 +1819,6 @@ Here are some common issues that cause failures.
    ``STAGING_BINDIR``, ``STAGING_INCDIR``, ``STAGING_DATADIR``, and so
    forth).
 
-.. _new-recipe-installing:
-
 Installing
 ----------
 
@@ -1956,8 +1906,6 @@ installed correctly.
       files to ``${D}${datadir}/cmake/Modules`` during
       :ref:`ref-tasks-install`.
 
-.. _new-recipe-enabling-system-services:
-
 Enabling System Services
 ------------------------
 
@@ -2009,8 +1957,6 @@ different ways:
    section for
    more information.
 
-.. _new-recipe-packaging:
-
 Packaging
 ---------
 
@@ -2032,7 +1978,7 @@ take. The following list describes the process:
    of common problems that show up during runtime. For information on
    these checks, see the
    :ref:`insane <ref-classes-insane>` class and
-   the ":ref:`ref-manual/ref-qa-checks:qa error and warning messages`"
+   the ":ref:`ref-manual/qa-checks:qa error and warning messages`"
    chapter in the Yocto Project Reference Manual.
 
 -  *Hand-Checking Your Packages*: After you build your software, you
@@ -2089,8 +2035,6 @@ take. The following list describes the process:
    target machine, particularly if you run separate builds for more than
    one target machine.
 
-.. _new-sharing-files-between-recipes:
-
 Sharing Files Between Recipes
 -----------------------------
 
@@ -2137,8 +2081,6 @@ For a more complete description of the
 task and its associated functions, see the
 :ref:`staging <ref-classes-staging>` class.
 
-.. _metadata-virtual-providers:
-
 Using Virtual Providers
 -----------------------
 
@@ -2165,15 +2107,12 @@ being able to provide the ``virtual/kernel`` item.
 
 Now comes the time to actually build an image and you need a kernel
 recipe, but which one? You can configure your build to call out the
-kernel recipe you want by using the
-:term:`PREFERRED_PROVIDER`
-variable. As an example, consider the
-`x86-base.inc <https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/conf/machine/include/x86-base.inc>`_
-include file, which is a machine (i.e.
-:term:`MACHINE`) configuration file.
-This include file is the reason all x86-based machines use the
-``linux-yocto`` kernel. Here are the relevant lines from the include
-file:
+kernel recipe you want by using the :term:`PREFERRED_PROVIDER` variable. As
+an example, consider the :yocto_git:`x86-base.inc
+</poky/tree/meta/conf/machine/include/x86-base.inc>` include file, which is a
+machine (i.e. :term:`MACHINE`) configuration file. This include file is the
+reason all x86-based machines use the ``linux-yocto`` kernel. Here are the
+relevant lines from the include file:
 ::
 
    PREFERRED_PROVIDER_virtual/kernel ??= "linux-yocto"
@@ -2251,8 +2190,6 @@ example:
    REALPV = "0.8.16-rc1"
    PV = "0.8.15+${REALPV}"
 
-.. _new-recipe-post-installation-scripts:
-
 Post-Installation Scripts
 -------------------------
 
@@ -2313,8 +2250,6 @@ script to first boot is undesirable and for read-only rootfs impossible.
    because of when they run, they are not applicable to being run at image
    creation time like ``pkg_postinst``.
 
-.. _new-recipe-testing:
-
 Testing
 -------
 
@@ -2326,8 +2261,6 @@ For information on how to customize your image by adding specific
 packages, see the "`Customizing
 Images <#usingpoky-extend-customimage>`__" section.
 
-.. _new-recipe-testing-examples:
-
 Examples
 --------
 
@@ -2344,8 +2277,6 @@ examples given various scenarios:
 
 -  Adding binaries to an image
 
-.. _new-recipe-single-c-file-package-hello-world:
-
 Single .c File Package (Hello World!)
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -2382,8 +2313,6 @@ customize the packaging process, see the "`Splitting an Application into
 Multiple Packages <#splitting-an-application-into-multiple-packages>`__"
 section.
 
-.. _new-recipe-autotooled-package:
-
 Autotooled Package
 ~~~~~~~~~~~~~~~~~~
 
@@ -2409,12 +2338,10 @@ Following is one example: (``hello_2.3.bb``)
 
 The variable ``LIC_FILES_CHKSUM`` is used to track source license
 changes as described in the
-":ref:`dev-manual/dev-manual-common-tasks:tracking license changes`" section in
+":ref:`dev-manual/common-tasks:tracking license changes`" section in
 the Yocto Project Overview and Concepts Manual. You can quickly create
 Autotool-based recipes in a manner similar to the previous example.
 
-.. _new-recipe-makefile-based-package:
-
 Makefile-Based Package
 ~~~~~~~~~~~~~~~~~~~~~~
 
@@ -2559,7 +2486,7 @@ Reference Manual's variable glossary.
 
    -  Using ``DEPENDS`` also allows runtime dependencies between
       packages to be added automatically. See the
-      ":ref:`overview-manual/overview-manual-concepts:automatically added runtime dependencies`"
+      ":ref:`overview-manual/concepts:automatically added runtime dependencies`"
       section in the Yocto Project Overview and Concepts Manual for more
       information.
 
@@ -2864,8 +2791,6 @@ in the BitBake User Manual.
    might wish to use. If in doubt, you should check with multiple
    implementations - including those from BusyBox.
 
-.. _platdev-newmachine:
-
 Adding a New Machine
 ====================
 
@@ -2885,8 +2810,6 @@ For a complete example that shows how to add a new machine, see the
 section in the Yocto Project Board Support Package (BSP) Developer's
 Guide.
 
-.. _platdev-newmachine-conffile:
-
 Adding the Machine Configuration File
 -------------------------------------
 
@@ -2920,8 +2843,6 @@ You can find full details on these variables in the reference section.
 You can leverage existing machine ``.conf`` files from
 ``meta-yocto-bsp/conf/machine/``.
 
-.. _platdev-newmachine-kernel:
-
 Adding a Kernel for the Machine
 -------------------------------
 
@@ -2953,11 +2874,9 @@ the ``SRC_URI`` and adding the machine to the expression in
    COMPATIBLE_MACHINE = '(qemux86|qemumips)'
 
 For more information on ``defconfig`` files, see the
-":ref:`kernel-dev/kernel-dev-common:changing the configuration`"
+":ref:`kernel-dev/common:changing the configuration`"
 section in the Yocto Project Linux Kernel Development Manual.
 
-.. _platdev-newmachine-formfactor:
-
 Adding a Formfactor Configuration File
 --------------------------------------
 
@@ -2990,8 +2909,6 @@ Following is an example for "qemuarm" machine:
    DISPLAY_DPI=150
    DISPLAY_SUBPIXEL_ORDER=vrgb
 
-.. _gs-upgrading-recipes:
-
 Upgrading Recipes
 =================
 
@@ -3011,8 +2928,6 @@ automatic version upgrades. Alternatively, you can use
 ``devtool upgrade`` to set up semi-automatic version upgrades. Finally,
 you can manually upgrade a recipe by editing the recipe itself.
 
-.. _gs-using-the-auto-upgrade-helper:
-
 Using the Auto Upgrade Helper (AUH)
 -----------------------------------
 
@@ -3048,7 +2963,7 @@ The following steps describe how to set up the AUH utility:
 1. *Be Sure the Development Host is Set Up:* You need to be sure that
    your development host is set up to use the Yocto Project. For
    information on how to set up your host, see the
-   ":ref:`dev-manual/dev-manual-start:Preparing the Build Host`" section.
+   ":ref:`dev-manual/start:Preparing the Build Host`" section.
 
 2. *Make Sure Git is Configured:* The AUH utility requires Git to be
    configured because AUH uses Git to save upgrades. Thus, you must have
@@ -3100,7 +3015,7 @@ The following steps describe how to set up the AUH utility:
    configurations:
 
    -  If you want to enable :ref:`Build
-      History <dev-manual/dev-manual-common-tasks:maintaining build output quality>`,
+      History <dev-manual/common-tasks:maintaining build output quality>`,
       which is optional, you need the following lines in the
       ``conf/local.conf`` file:
       ::
@@ -3140,7 +3055,7 @@ The following steps describe how to set up the AUH utility:
 7. *Create and Edit an AUH Configuration File:* You need to have the
    ``upgrade-helper/upgrade-helper.conf`` configuration file in your
    build directory. You can find a sample configuration file in the
-   :yocto_git:`AUH source repository </cgit/cgit.cgi/auto-upgrade-helper/tree/>`.
+   :yocto_git:`AUH source repository </auto-upgrade-helper/tree/>`.
 
    Read through the sample file and make configurations as needed. For
    example, if you enabled build history in your ``local.conf`` as
@@ -3204,19 +3119,17 @@ the layer tree.
 
 You can easily set up to run the AUH utility on a regular basis by using
 a cron job. See the
-:yocto_git:`weeklyjob.sh </cgit/cgit.cgi/auto-upgrade-helper/tree/weeklyjob.sh>`
+:yocto_git:`weeklyjob.sh </auto-upgrade-helper/tree/weeklyjob.sh>`
 file distributed with the utility for an example.
 
-.. _gs-using-devtool-upgrade:
-
 Using ``devtool upgrade``
 -------------------------
 
 As mentioned earlier, an alternative method for upgrading recipes to
 newer versions is to use
-:doc:`devtool upgrade <../ref-manual/ref-devtool-reference>`.
+:doc:`devtool upgrade </ref-manual/devtool-reference>`.
 You can read about ``devtool upgrade`` in general in the
-":ref:`sdk-manual/sdk-extensible:use \`\`devtool upgrade\`\` to create a version of the recipe that supports a newer version of the software`"
+":ref:`sdk-manual/extensible:use \`\`devtool upgrade\`\` to create a version of the recipe that supports a newer version of the software`"
 section in the Yocto Project Application Development and the Extensible
 Software Development Kit (eSDK) Manual.
 
@@ -3350,14 +3263,12 @@ Using the ``devtool finish`` command cleans up the workspace and creates a patch
 file based on your commits. The tool puts all patch files back into the
 source directory in a sub-directory named ``nano`` in this case.
 
-.. _dev-manually-upgrading-a-recipe:
-
 Manually Upgrading a Recipe
 ---------------------------
 
 If for some reason you choose not to upgrade recipes using
-:ref:`dev-manual/dev-manual-common-tasks:Using the Auto Upgrade Helper (AUH)` or
-by :ref:`dev-manual/dev-manual-common-tasks:Using \`\`devtool upgrade\`\``,
+:ref:`dev-manual/common-tasks:Using the Auto Upgrade Helper (AUH)` or
+by :ref:`dev-manual/common-tasks:Using \`\`devtool upgrade\`\``,
 you can manually edit the recipe files to upgrade the versions.
 
 .. note::
@@ -3419,8 +3330,6 @@ To manually upgrade recipe versions, follow these general steps:
    builds work and any testing is successful, you can create commits for
    any changes in the layer holding your upgraded recipe.
 
-.. _finding-the-temporary-source-code:
-
 Finding Temporary Source Code
 =============================
 
@@ -3491,8 +3400,6 @@ build system uses to build the package would be as follows:
 
    poky/build/tmp/work/qemux86-poky-linux/foo/1.3.0-r0
 
-.. _using-a-quilt-workflow:
-
 Using Quilt in Your Workflow
 ============================
 
@@ -3506,7 +3413,7 @@ form of a patch all using Quilt.
 
    With regard to preserving changes to source files, if you clean a
    recipe or have ``rm_work`` enabled, the
-   :ref:`devtool workflow <sdk-manual/sdk-extensible:using \`\`devtool\`\` in your sdk workflow>`
+   :ref:`devtool workflow <sdk-manual/extensible:using \`\`devtool\`\` in your sdk workflow>`
    as described in the Yocto Project Application Development and the
    Extensible Software Development Kit (eSDK) manual is a safer
    development flow than the flow that uses Quilt.
@@ -3560,7 +3467,7 @@ Follow these general steps:
       (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
-      ":ref:`dev-manual/dev-manual-common-tasks:conserving disk space during builds`"
+      ":ref:`dev-manual/common-tasks:conserving disk space during builds`"
       section.
 
 7. *Generate the Patch:* Once your changes work as expected, you need to
@@ -3587,8 +3494,6 @@ Follow these general steps:
 
       SRC_URI += "file://my_changes.patch"
 
-.. _platdev-appdev-devshell:
-
 Using a Development Shell
 =========================
 
@@ -3671,8 +3576,6 @@ terminal window.
    -  It is also worth noting that ``devshell`` still works over X11
       forwarding and similar situations.
 
-.. _platdev-appdev-devpyshell:
-
 Using a Development Python Shell
 ================================
 
@@ -3720,8 +3623,6 @@ controls what type of shell is opened.
 When you are finished using ``devpyshell``, you can exit the shell
 either by using Ctrl+d or closing the terminal window.
 
-.. _dev-building:
-
 Building
 ========
 
@@ -3729,8 +3630,6 @@ This section describes various build procedures. For example, the steps
 needed for a simple build, a target that uses multiple configurations,
 building an image for more than one machine, and so forth.
 
-.. _dev-building-a-simple-image:
-
 Building a Simple Image
 -----------------------
 
@@ -3745,21 +3644,21 @@ build host running Linux.
 
    -  For information on how to build an image using
       :term:`Toaster`, see the
-      :doc:`../toaster-manual/toaster-manual`.
+      :doc:`/toaster-manual/index`.
 
    -  For information on how to use ``devtool`` to build images, see the
-      ":ref:`sdk-manual/sdk-extensible:using \`\`devtool\`\` in your sdk workflow`"
+      ":ref:`sdk-manual/extensible:using \`\`devtool\`\` in your sdk workflow`"
       section in the Yocto Project Application Development and the
       Extensible Software Development Kit (eSDK) manual.
 
    -  For a quick example on how to build an image using the
       OpenEmbedded build system, see the
-      :doc:`../brief-yoctoprojectqs/brief-yoctoprojectqs` document.
+      :doc:`/brief-yoctoprojectqs/index` document.
 
 The build process creates an entire Linux distribution from source and
 places it in your :term:`Build Directory` under
 ``tmp/deploy/images``. For detailed information on the build process
-using BitBake, see the ":ref:`images-dev-environment`" section in the
+using BitBake, see the ":ref:`overview-manual/concepts:images`" section in the
 Yocto Project Overview and Concepts Manual.
 
 The following figure and list overviews the build process:
@@ -3768,7 +3667,7 @@ The following figure and list overviews the build process:
    :align: center
 
 1. *Set up Your Host Development System to Support Development Using the
-   Yocto Project*: See the ":doc:`dev-manual-start`" section for options on how to get a
+   Yocto Project*: See the ":doc:`start`" section for options on how to get a
    build host ready to use the Yocto Project.
 
 2. *Initialize the Build Environment:* Initialize the build environment
@@ -3815,7 +3714,7 @@ The following figure and list overviews the build process:
    can be the name of a recipe for a specific piece of software such as
    BusyBox. For more details about the images the OpenEmbedded build
    system supports, see the
-   ":ref:`ref-manual/ref-images:Images`" chapter in the Yocto
+   ":ref:`ref-manual/images:Images`" chapter in the Yocto
    Project Reference Manual.
 
    As an example, the following command builds the
@@ -3829,12 +3728,10 @@ The following figure and list overviews the build process:
    kernels built by the OpenEmbedded build system are placed in the
    Build Directory in ``tmp/deploy/images``. For information on how to
    run pre-built images such as ``qemux86`` and ``qemuarm``, see the
-   :doc:`../sdk-manual/sdk-manual` manual. For
+   :doc:`/sdk-manual/index` manual. For
    information about how to install these images, see the documentation
    for your particular board or machine.
 
-.. _dev-building-images-for-multiple-targets-using-multiple-configurations:
-
 Building Images for Multiple Targets Using Multiple Configurations
 ------------------------------------------------------------------
 
@@ -3848,8 +3745,6 @@ This section describes how to set up for multiple configuration builds
 and how to account for cross-build dependencies between the
 multiconfigs.
 
-.. _dev-setting-up-and-running-a-multiple-configuration-build:
-
 Setting Up and Running a Multiple Configuration Build
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -3942,8 +3837,6 @@ Follow these steps to set up and execute multiple configuration builds:
    directories, the build either loads from an existing sstate cache for
    that build at the start or builds the object fresh.
 
-.. _dev-enabling-multiple-configuration-build-dependencies:
-
 Enabling Multiple Configuration Build Dependencies
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -4003,8 +3896,6 @@ and have separate configuration files, BitBake places the artifacts for
 each build in the respective temporary build directories (i.e.
 :term:`TMPDIR`).
 
-.. _building-an-initramfs-image:
-
 Building an Initial RAM Filesystem (initramfs) Image
 ----------------------------------------------------
 
@@ -4095,8 +3986,6 @@ distribution to even smaller sizes than the ``poky-tiny`` distribution,
 which is around 5 Mbytes, that can be built out-of-the-box using the
 Yocto Project.
 
-.. _tiny-system-overview:
-
 Tiny System Overview
 ~~~~~~~~~~~~~~~~~~~~
 
@@ -4145,8 +4034,6 @@ very small distributions:
    information on how to create layers, see the "`Understanding and
    Creating Layers <#understanding-and-creating-layers>`__" section.
 
-.. _understand-what-gives-your-image-size:
-
 Understand What Contributes to Your Image Size
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -4159,7 +4046,7 @@ your own distribution that are likely modeled after ``poky-tiny``.
 
    To use ``poky-tiny`` in your build, set the ``DISTRO`` variable in your
    ``local.conf`` file to "poky-tiny" as described in the
-   ":ref:`dev-manual/dev-manual-common-tasks:creating your own distribution`"
+   ":ref:`dev-manual/common-tasks:creating your own distribution`"
    section.
 
 Understanding some memory concepts will help you reduce the system size.
@@ -4197,7 +4084,7 @@ view file dependencies in a human-readable form:
    directory.
 
    For more information on configuration fragments, see the
-   ":ref:`kernel-dev/kernel-dev-common:creating configuration fragments`"
+   ":ref:`kernel-dev/common:creating configuration fragments`"
    section in the Yocto Project Linux Kernel Development Manual.
 
 -  ``bitbake -u taskexp -g bitbake_target``: Using the BitBake command
@@ -4472,9 +4359,9 @@ your tunings to best consider build times and package feed maintenance.
    higher levels noted earlier can be useful. For example, consider how
    NXP (formerly Freescale) allows for the easy reuse of binary packages
    in their layer
-   :yocto_git:`meta-freescale </cgit/cgit.cgi/meta-freescale/>`.
+   :yocto_git:`meta-freescale </meta-freescale/>`.
    In this example, the
-   :yocto_git:`fsl-dynamic-packagearch </cgit/cgit.cgi/meta-freescale/tree/classes/fsl-dynamic-packagearch.bbclass>`
+   :yocto_git:`fsl-dynamic-packagearch </meta-freescale/tree/classes/fsl-dynamic-packagearch.bbclass>`
    class shares GPU packages for i.MX53 boards because all boards share
    the AMD GPU. The i.MX6-based boards can do the same because all
    boards share the Vivante GPU. This class inspects the BitBake
@@ -4812,8 +4699,6 @@ that can help you speed up the build:
          the static libraries. If so, you might need to exclude them as
          well.
 
-.. _platdev-working-with-libraries:
-
 Working With Libraries
 ======================
 
@@ -4889,8 +4774,6 @@ how the static library files are defined:
    SECTION_${PN}-staticdev = "devel"
    RDEPENDS_${PN}-staticdev = "${PN}-dev (= ${EXTENDPKGV})"
 
-.. _combining-multiple-versions-library-files-into-one-image:
-
 Combining Multiple Versions of Library Files into One Image
 -----------------------------------------------------------
 
@@ -5299,8 +5182,6 @@ The following know issues exist for GObject Introspection Support:
    under 32-bit host machines. In particular, "qemumips64" is known to
    not work under i686.
 
-.. _dev-optionally-using-an-external-toolchain:
-
 Optionally Using an External Toolchain
 ======================================
 
@@ -5353,7 +5234,7 @@ particular system.
 .. note::
 
    For a kickstart file reference, see the
-   ":ref:`ref-manual/ref-kickstart:openembedded kickstart (\`\`.wks\`\`) reference`"
+   ":ref:`ref-manual/kickstart:openembedded kickstart (\`\`.wks\`\`) reference`"
    Chapter in the Yocto Project Reference Manual.
 
 The ``wic`` command and the infrastructure it is based on is by
@@ -5368,8 +5249,6 @@ you need to have in place to run the tool, provides instruction on how
 to use the Wic utility, provides information on using the Wic plugins
 interface, and provides several examples that show how to use Wic.
 
-.. _wic-background:
-
 Background
 ----------
 
@@ -5395,8 +5274,6 @@ this information is required to use Wic, you might find it interesting.
    general-purpose partitioning language, which is based on Redhat
    kickstart syntax.
 
-.. _wic-requirements:
-
 Requirements
 ------------
 
@@ -5435,8 +5312,6 @@ system needs to meet the following requirements:
 -  Include the name of the :ref:`wic kickstart file <openembedded-kickstart-wks-reference>`
    as part of the :term:`WKS_FILE` variable
 
-.. _wic-getting-help:
-
 Getting Help
 ------------
 
@@ -5610,14 +5485,12 @@ The general form of the ``wic`` command using Cooked Mode is as follows:
                                 name of the image to use the artifacts from e.g. core-
                                 image-sato
 
-.. _using-a-provided-kickstart-file:
-
 Using an Existing Kickstart File
 --------------------------------
 
 If you do not want to create your own kickstart file, you can use an
 existing file provided by the Wic installation. As shipped, kickstart
-files can be found in the :ref:`overview-manual/overview-manual-development-environment:yocto project source repositories` in the
+files can be found in the :ref:`overview-manual/development-environment:yocto project source repositories` in the
 following two locations:
 ::
 
@@ -5661,8 +5534,6 @@ Here are the actual partition language commands used in the
 
    bootloader --ptable gpt --timeout=5 --append="rootfstype=ext4 console=ttyS0,115200 console=tty0"
 
-.. _wic-using-the-wic-plugin-interface:
-
 Using the Wic Plugin Interface
 ------------------------------
 
@@ -5690,7 +5561,7 @@ partition.
 Source plugins are subclasses defined in plugin files. As shipped, the
 Yocto Project provides several plugin files. You can see the source
 plugin files that ship with the Yocto Project
-:yocto_git:`here </cgit/cgit.cgi/poky/tree/scripts/lib/wic/plugins/source>`.
+:yocto_git:`here </poky/tree/scripts/lib/wic/plugins/source>`.
 Each of these plugin files contains source plugins that are designed to
 populate a specific Wic image partition.
 
@@ -5802,8 +5673,6 @@ by filling up a dict with keys that contain the method names of
 interest. On success, these will be filled in with the actual methods.
 See the Wic implementation for examples and details.
 
-.. _wic-usage-examples:
-
 Wic Examples
 ------------
 
@@ -5813,8 +5682,6 @@ utility. All the examples assume the list of requirements in the
 examples assume the previously generated image is
 ``core-image-minimal``.
 
-.. _generate-an-image-using-a-provided-kickstart-file:
-
 Generate an Image using an Existing Kickstart File
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -5869,7 +5736,7 @@ or ::
 
    For more information on how to use the ``bmaptool``
    to flash a device with an image, see the
-   ":ref:`dev-manual/dev-manual-common-tasks:flashing images using \`\`bmaptool\`\``"
+   ":ref:`dev-manual/common-tasks:flashing images using \`\`bmaptool\`\``"
    section.
 
 Using a Modified Kickstart File
@@ -6089,7 +5956,7 @@ the existing kernel, and then inserts a new kernel:
 
    Once the new kernel is added back into the image, you can use the
    ``dd`` command or :ref:`bmaptool
-   <dev-manual/dev-manual-common-tasks:flashing images using \`\`bmaptool\`\`>`
+   <dev-manual/common-tasks:flashing images using \`\`bmaptool\`\`>`
    to flash your wic image onto an SD card or USB stick and test your
    target.
 
@@ -6305,7 +6172,7 @@ system to make your images more secure:
 -  Consider enabling a Mandatory Access Control (MAC) framework such as
    SMACK or SELinux and tuning it appropriately for your device's usage.
    You can find more information in the
-   :yocto_git:`meta-selinux </cgit/cgit.cgi/meta-selinux/>` layer.
+   :yocto_git:`meta-selinux </meta-selinux/>` layer.
 
 Tools for Hardening Your Image
 ------------------------------
@@ -6335,7 +6202,7 @@ layer. The following steps provide some more detail:
    just placing configurations in a ``local.conf`` configuration file
    makes it easier to reproduce the same build configuration when using
    multiple build machines. See the
-   ":ref:`dev-manual/dev-manual-common-tasks:creating a general layer using the \`\`bitbake-layers\`\` script`"
+   ":ref:`dev-manual/common-tasks:creating a general layer using the \`\`bitbake-layers\`\` script`"
    section for information on how to quickly set up a layer.
 
 -  *Create the distribution configuration file:* The distribution
@@ -6495,8 +6362,6 @@ Changing the listed common targets is as easy as editing your version of
 ``conf-notes.txt`` in your custom template configuration directory and
 making sure you have ``TEMPLATECONF`` set to your directory.
 
-.. _dev-saving-memory-during-a-build:
-
 Conserving Disk Space During Builds
 ===================================
 
@@ -6573,8 +6438,6 @@ Yocto Project Reference Manual's glossary chapter.
    prevent the installation of a package whose presence is required by
    an installed package.
 
-.. _incrementing-a-binary-package-version:
-
 Incrementing a Package Version
 ------------------------------
 
@@ -6610,7 +6473,7 @@ the following:
    build system uses this string to help define the value of ``PV`` when
    the source code revision needs to be included in it.
 
--  :yocto_wiki:`PR Service </wiki/PR_Service>`: A
+-  :yocto_wiki:`PR Service </PR_Service>`: A
    network-based service that helps automate keeping package feeds
    compatible with existing package manager applications such as RPM,
    APT, and OPKG.
@@ -6652,7 +6515,7 @@ revision field, which removes the human element.
 .. note::
 
    For additional information on using a PR Service, you can see the
-   :yocto_wiki:`PR Service </wiki/PR_Service>` wiki page.
+   :yocto_wiki:`PR Service </PR_Service>` wiki page.
 
 The Yocto Project uses variables in order of decreasing priority to
 facilitate revision numbering (i.e.
@@ -6663,7 +6526,7 @@ revision, respectively). The values are highly dependent on the policies
 and procedures of a given distribution and package feed.
 
 Because the OpenEmbedded build system uses
-":ref:`signatures <overview-checksums>`", which are
+":ref:`signatures <overview-manual/concepts:checksums (signatures)>`", which are
 unique to a given build, the build system knows when to rebuild
 packages. All the inputs into a given task are represented by a
 signature, which can trigger a rebuild when different. Thus, the build
@@ -6737,7 +6600,7 @@ Quality <#maintaining-build-output-quality>`__" section.
    use a PR Service while others do not leads to obvious problems.
 
    For more information on shared state, see the
-   ":ref:`overview-manual/overview-manual-concepts:shared state cache`"
+   ":ref:`overview-manual/concepts:shared state cache`"
    section in the Yocto Project Overview and Concepts Manual.
 
 Manually Bumping PR
@@ -6777,8 +6640,6 @@ Guidelines <https://www.debian.org/doc/debian-policy/ch-controlfields.html>`__.
 These guidelines define how versions are compared and what "increasing"
 a version means.
 
-.. _automatically-incrementing-a-binary-package-revision-number:
-
 Automatically Incrementing a Package Version Number
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -6906,7 +6767,7 @@ multiple times if you have more than one set of modules to package.
 
 For more examples that show how to use ``do_split_packages``, see the
 ``connman.inc`` file in the ``meta/recipes-connectivity/connman/``
-directory of the ``poky`` :ref:`source repository <yocto-project-repositories>`. You can
+directory of the ``poky`` :ref:`source repository <overview-manual/development-environment:yocto project source repositories>`. You can
 also find examples in ``meta/classes/kernel.bbclass``.
 
 Following is a reference that shows ``do_split_packages`` mandatory and
@@ -7077,8 +6938,6 @@ use of runtime package management, you need to do a couple things above
 and beyond the basics. The remainder of this section describes what you
 need to do.
 
-.. _runtime-package-management-build:
-
 Build Considerations
 ~~~~~~~~~~~~~~~~~~~~
 
@@ -7165,8 +7024,6 @@ When your build is complete, your packages reside in the
 ``tmp`` and your selected package type is RPM, then your RPM packages
 are available in ``tmp/deploy/rpm``.
 
-.. _runtime-package-management-server:
-
 Host or Server Machine Setup
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -7193,16 +7050,12 @@ setting of "package_rpm":
    $ cd ~/poky/build/tmp/deploy/rpm
    $ python3 -m http.server
 
-.. _runtime-package-management-target:
-
 Target Setup
 ~~~~~~~~~~~~
 
 Setting up the target differs depending on the package management
 system. This section provides information for RPM, IPK, and DEB.
 
-.. _runtime-package-management-target-rpm:
-
 Using RPM
 ^^^^^^^^^
 
@@ -7283,8 +7136,6 @@ upgrade packages from the specified repository or repositories.
    See the `DNF documentation <https://dnf.readthedocs.io/en/latest/>`__ for
    additional information.
 
-.. _runtime-package-management-target-ipk:
-
 Using IPK
 ^^^^^^^^^
 
@@ -7325,8 +7176,6 @@ repository information:
 The ``opkg`` application is now able to find, install, and upgrade packages
 from the specified repository.
 
-.. _runtime-package-management-target-deb:
-
 Using DEB
 ^^^^^^^^^
 
@@ -7462,7 +7311,7 @@ where the result can be ``PASS``, ``FAIL``, or ``SKIP``, and
 the testname can be any identifying string.
 
 For a list of Yocto Project recipes that are already enabled with ptest,
-see the :yocto_wiki:`Ptest </wiki/Ptest>` wiki page.
+see the :yocto_wiki:`Ptest </Ptest>` wiki page.
 
 .. note::
 
@@ -7567,9 +7416,9 @@ Creating Node Package Manager (NPM) Packages
 
 `NPM <https://en.wikipedia.org/wiki/Npm_(software)>`__ is a package
 manager for the JavaScript programming language. The Yocto Project
-supports the NPM :ref:`fetcher <bitbake:bb-fetchers>`. You can
+supports the NPM :ref:`fetcher <bitbake:bitbake-user-manual/bitbake-user-manual-fetching:fetchers>`. You can
 use this fetcher in combination with
-:doc:`devtool <../ref-manual/ref-devtool-reference>` to create
+:doc:`devtool </ref-manual/devtool-reference>` to create
 recipes that produce NPM packages.
 
 Two workflows exist that allow you to create NPM packages using
@@ -7583,8 +7432,6 @@ method.
 
 Additionally, some requirements and caveats exist.
 
-.. _npm-package-creation-requirements:
-
 Requirements and Caveats
 ~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -7599,7 +7446,7 @@ NPM packages:
    is NPM's public registry.
 
 -  Be familiar with
-   :doc:`devtool <../ref-manual/ref-devtool-reference>`.
+   :doc:`devtool </ref-manual/devtool-reference>`.
 
 -  The NPM host tools need the native ``nodejs-npm`` package, which is
    part of the OpenEmbedded environment. You need to get the package by
@@ -7619,8 +7466,6 @@ NPM packages:
    useful to have NPM on your target. The NPM package name is
    ``nodejs-npm``.
 
-.. _npm-using-the-registry-modules-method:
-
 Using the Registry Modules Method
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -7731,8 +7576,6 @@ go to ``http://192.168.7.2:3000`` and you see the following:
 You can find the recipe in ``workspace/recipes/cute-files``. You can use
 the recipe in any layer you choose.
 
-.. _npm-using-the-npm-projects-method:
-
 Using the NPM Projects Code Method
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -7956,8 +7799,6 @@ image cannot use this package group. However, it can install SysVinit
 and the appropriate packages will have support for both systemd and
 SysVinit.
 
-.. _selecting-dev-manager:
-
 Selecting a Device Manager
 ==========================
 
@@ -7974,8 +7815,6 @@ The Yocto Project provides multiple ways to manage the device manager
    configuration of device nodes is done in user space by a device
    manager like ``udev`` or ``busybox-mdev``.
 
-.. _static-dev-management:
-
 Using Persistent and Pre-Populated\ ``/dev``
 --------------------------------------------
 
@@ -8002,8 +7841,6 @@ If you do not define the ``IMAGE_DEVICE_TABLES`` variable, the default
 The population is handled by the ``makedevs`` utility during image
 creation:
 
-.. _devtmpfs-dev-management:
-
 Using ``devtmpfs`` and a Device Manager
 ---------------------------------------
 
@@ -8036,8 +7873,6 @@ your ``local.conf`` configuration file:
    # VIRTUAL-RUNTIME_dev_manager = "busybox-mdev"
    # VIRTUAL-RUNTIME_dev_manager = "systemd"
 
-.. _platdev-appdev-srcrev:
-
 Using an External SCM
 =====================
 
@@ -8144,7 +7979,7 @@ associated ``EXTRA_IMAGE_FEATURES`` variable, as in:
    EXTRA_IMAGE_FEATURES = "read-only-rootfs"
 
 For more information on how to use these variables, see the
-":ref:`dev-manual/dev-manual-common-tasks:Customizing Images Using Custom \`\`IMAGE_FEATURES\`\` and \`\`EXTRA_IMAGE_FEATURES\`\``"
+":ref:`dev-manual/common-tasks:Customizing Images Using Custom \`\`IMAGE_FEATURES\`\` and \`\`EXTRA_IMAGE_FEATURES\`\``"
 section. For information on the variables, see
 :term:`IMAGE_FEATURES` and
 :term:`EXTRA_IMAGE_FEATURES`.
@@ -8221,13 +8056,13 @@ the information.
 
 The remainder of this section describes the following:
 
--  :ref:`How you can enable and disable build history <dev-manual/dev-manual-common-tasks:enabling and disabling build history>`
+-  :ref:`How you can enable and disable build history <dev-manual/common-tasks:enabling and disabling build history>`
 
--  :ref:`How to understand what the build history contains <dev-manual/dev-manual-common-tasks:understanding what the build history contains>`
+-  :ref:`How to understand what the build history contains <dev-manual/common-tasks:understanding what the build history contains>`
 
--  :ref:`How to limit the information used for build history <dev-manual/dev-manual-common-tasks:using build history to gather image information only>`
+-  :ref:`How to limit the information used for build history <dev-manual/common-tasks:using build history to gather image information only>`
 
--  :ref:`How to examine the build history from both a command-line and web interface <dev-manual/dev-manual-common-tasks:examining build history information>`
+-  :ref:`How to examine the build history from both a command-line and web interface <dev-manual/common-tasks:examining build history information>`
 
 Enabling and Disabling Build History
 ------------------------------------
@@ -8245,7 +8080,7 @@ variable to "1" at the end of your ``conf/local.conf`` file found in the
 Enabling build history as
 previously described causes the OpenEmbedded build system to collect
 build output information and commit it as a single commit to a local
-:ref:`overview-manual/overview-manual-development-environment:git` repository.
+:ref:`overview-manual/development-environment:git` repository.
 
 .. note::
 
@@ -8598,7 +8433,7 @@ might be significant in human-readable form. Here is an example:
 
 To see changes to the build history using a web interface, follow the
 instruction in the ``README`` file
-:yocto_git:`here </cgit/cgit.cgi/buildhistory-web/>`.
+:yocto_git:`here </buildhistory-web/>`.
 
 Here is a sample screenshot of the interface:
 
@@ -8617,7 +8452,7 @@ you set up the environment to use these tests, run available tests, and
 write and add your own tests.
 
 For information on the test and QA infrastructure available within the
-Yocto Project, see the ":ref:`ref-manual/ref-release-process:testing and quality assurance`"
+Yocto Project, see the ":ref:`ref-manual/release-process:testing and quality assurance`"
 section in the Yocto Project Reference Manual.
 
 Enabling Tests
@@ -8628,8 +8463,6 @@ hardware, you have to take different steps to enable the tests. See the
 following subsections for information on how to enable both types of
 tests.
 
-.. _qemu-image-enabling-tests:
-
 Enabling Runtime Tests on QEMU
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -8714,8 +8547,6 @@ Once you start running the tests, the following happens:
    You can find the output from the ``unittest`` in the task log at
    ``${WORKDIR}/temp/log.do_testimage``.
 
-.. _hardware-image-enabling-tests:
-
 Enabling Runtime Tests on Hardware
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -8931,8 +8762,6 @@ wrapper, simply prefix the terminal command with
 
    TEST_SERIALCONTROL_CMD = "${COREBASE}/scripts/contrib/serdevtry picocom -b 115200 /dev/ttyUSB0"
 
-.. _qemu-image-running-tests:
-
 Running Tests
 -------------
 
@@ -9077,8 +8906,6 @@ the build environment using the following:
    $ cd tmp/testexport/core-image-sato
    $ ./runexported.py testdata.json
 
-.. _qemu-image-writing-new-tests:
-
 Writing New Tests
 -----------------
 
@@ -9110,8 +8937,6 @@ You will notice that all test classes inherit ``oeRuntimeTest``, which
 is found in ``meta/lib/oetest.py``. This base class offers some helper
 attributes, which are described in the following sections:
 
-.. _qemu-image-writing-tests-class-methods:
-
 Class Methods
 ~~~~~~~~~~~~~
 
@@ -9125,8 +8950,6 @@ Class methods are as follows:
    :term:`IMAGE_FEATURES` or
    :term:`DISTRO_FEATURES`.
 
-.. _qemu-image-writing-tests-class-attributes:
-
 Class Attributes
 ~~~~~~~~~~~~~~~~
 
@@ -9174,8 +8997,6 @@ Class attributes are as follows:
       -  *copy_from(remotepath, localpath):*
          ``scp root@host:remotepath localpath``.
 
-.. _qemu-image-writing-tests-instance-attributes:
-
 Instance Attributes
 ~~~~~~~~~~~~~~~~~~~
 
@@ -9241,8 +9062,6 @@ Once the test is complete, the packages are removed from the DUT.
          ]
      }
 
-.. _usingpoky-debugging-tools-and-techniques:
-
 Debugging Tools and Techniques
 ==============================
 
@@ -9265,7 +9084,7 @@ situations.
    completes to log error information into a common database, that can
    help you figure out what might be going wrong. For information on how
    to enable and use this feature, see the
-   ":ref:`dev-manual/dev-manual-common-tasks:using the error reporting tool`"
+   ":ref:`dev-manual/common-tasks:using the error reporting tool`"
    section.
 
 The following list shows the debugging topics in the remainder of this
@@ -9281,7 +9100,7 @@ section:
    use the BitBake ``-e`` option to examine variable values after a
    recipe has been parsed.
 
--  ":ref:`dev-manual/dev-manual-common-tasks:viewing package information with \`\`oe-pkgdata-util\`\``"
+-  ":ref:`dev-manual/common-tasks:viewing package information with \`\`oe-pkgdata-util\`\``"
    describes how to use the ``oe-pkgdata-util`` utility to query
    :term:`PKGDATA_DIR` and
    display package-related information for built packages.
@@ -9333,8 +9152,6 @@ section:
 -  "`Other Debugging Tips <#dev-other-debugging-others>`__" describes
    miscellaneous debugging tips that can be useful.
 
-.. _dev-debugging-viewing-logs-from-failed-tasks:
-
 Viewing Logs from Failed Tasks
 ------------------------------
 
@@ -9354,8 +9171,6 @@ links to ``log.do_``\ `taskname`\ ``.``\ `pid` and
 when it ran. The symlinks always point to the files corresponding to the
 most recent run.
 
-.. _dev-debugging-viewing-variable-values:
-
 Viewing Variable Values
 -----------------------
 
@@ -9409,7 +9224,7 @@ In addition to variable values, the output of the ``bitbake -e`` and
 -  The output starts with a tree listing all configuration files and
    classes included globally, recursively listing the files they include
    or inherit in turn. Much of the behavior of the OpenEmbedded build
-   system (including the behavior of the :ref:`ref-manual/ref-tasks:normal recipe build tasks`) is
+   system (including the behavior of the :ref:`ref-manual/tasks:normal recipe build tasks`) is
    implemented in the
    :ref:`base <ref-classes-base>` class and the
    classes it inherits, rather than being built into BitBake itself.
@@ -9477,8 +9292,6 @@ facility:
    $ oe-pkgdata-util --help
    $ oe-pkgdata-util subcommand --help
 
-.. _dev-viewing-dependencies-between-recipes-and-tasks:
-
 Viewing Dependencies Between Recipes and Tasks
 ----------------------------------------------
 
@@ -9545,8 +9358,6 @@ This command
 displays a GUI window from which you can view build-time and runtime
 dependencies for the recipes involved in building recipename.
 
-.. _dev-viewing-task-variable-dependencies:
-
 Viewing Task Variable Dependencies
 ----------------------------------
 
@@ -9583,7 +9394,7 @@ BitBake has determined by doing the following:
       ${BUILDDIR}/tmp/stamps/i586-poky-linux/db/6.0.30-r1.do_fetch.sigdata.7c048c18222b16ff0bcee2000ef648b1
 
    For tasks that are accelerated through the shared state
-   (:ref:`sstate <overview-manual/overview-manual-concepts:shared state cache>`) cache, an
+   (:ref:`sstate <overview-manual/concepts:shared state cache>`) cache, an
    additional ``siginfo`` file is written into
    :term:`SSTATE_DIR` along with
    the cached task output. The ``siginfo`` files contain exactly the
@@ -9638,8 +9449,6 @@ Using BitBake with either of these options causes BitBake to dump out
 ``sigdata`` files in the ``stamps`` directory for every task it would
 have executed instead of building the specified target package.
 
-.. _dev-viewing-metadata-used-to-create-the-input-signature-of-a-shared-state-task:
-
 Viewing Metadata Used to Create the Input Signature of a Shared State Task
 --------------------------------------------------------------------------
 
@@ -9652,17 +9461,15 @@ files, see the "`Viewing Task Variable
 Dependencies <#dev-viewing-task-variable-dependencies>`__" section.
 
 For conceptual information on shared state, see the
-":ref:`overview-manual/overview-manual-concepts:shared state`"
+":ref:`overview-manual/concepts:shared state`"
 section in the Yocto Project Overview and Concepts Manual.
 
-.. _dev-invalidating-shared-state-to-force-a-task-to-run:
-
 Invalidating Shared State to Force a Task to Run
 ------------------------------------------------
 
 The OpenEmbedded build system uses
-:ref:`checksums <overview-checksums>` and
-:ref:`overview-manual/overview-manual-concepts:shared state` cache to avoid unnecessarily
+:ref:`checksums <overview-manual/concepts:checksums (signatures)>` and
+:ref:`overview-manual/concepts:shared state` cache to avoid unnecessarily
 rebuilding tasks. Collectively, this scheme is known as "shared state
 code".
 
@@ -9701,9 +9508,7 @@ the build system to run the task again.
 
    For an example of a commit that makes a cosmetic change to invalidate
    shared state, see this
-   :yocto_git:`commit </cgit.cgi/poky/commit/meta/classes/package.bbclass?id=737f8bbb4f27b4837047cb9b4fbfe01dfde36d54>`.
-
-.. _dev-debugging-taskrunning:
+   :yocto_git:`commit </poky/commit/meta/classes/package.bbclass?id=737f8bbb4f27b4837047cb9b4fbfe01dfde36d54>`.
 
 Running Specific Tasks
 ----------------------
@@ -9725,7 +9530,7 @@ tasks (including tasks from other recipes) that the specified task
 depends on will be run before the task. Even when you manually specify a
 task to run with ``-c``, BitBake will only run the task if it considers
 it "out of date". See the
-":ref:`overview-manual/overview-manual-concepts:stamp files and the rerunning of tasks`"
+":ref:`overview-manual/concepts:stamp files and the rerunning of tasks`"
 section in the Yocto Project Overview and Concepts Manual for how
 BitBake determines whether a task is "out of date".
 
@@ -9759,7 +9564,7 @@ compile. BitBake recognizes that the ``do_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
-:ref:`ref-manual/ref-tasks:normal recipe build tasks`
+:ref:`ref-manual/tasks:normal recipe build tasks`
 that depend on it is to use the ``-C`` option.
 
 .. note::
@@ -9812,8 +9617,6 @@ You can view a list of tasks in a given package by running the
 The results appear as output to the console and are also in
 the file ``${WORKDIR}/temp/log.do_listtasks``.
 
-.. _dev-debugging-bitbake:
-
 General BitBake Problems
 ------------------------
 
@@ -9827,8 +9630,6 @@ chose a certain version of a package or why BitBake picked a certain
 provider. This command could also help you in a situation where you
 think BitBake did something unexpected.
 
-.. _dev-debugging-buildfile:
-
 Building with No Dependencies
 -----------------------------
 
@@ -10190,8 +9991,6 @@ problem is taken care of at its source. See the "`Submitting a Change to
 the Yocto Project <#how-to-submit-a-change>`__" section for more
 information.
 
-.. _platdev-gdb-remotedebug:
-
 Debugging With the GNU Project Debugger (GDB) Remotely
 ------------------------------------------------------
 
@@ -10199,7 +9998,7 @@ GDB allows you to examine running programs, which in turn helps you to
 understand and fix problems. It also allows you to perform post-mortem
 style analysis of program crashes. GDB is available as a package within
 the Yocto Project and is installed in SDK images by default. See the
-":ref:`ref-manual/ref-images:Images`" chapter in the Yocto
+":ref:`ref-manual/images:Images`" chapter in the Yocto
 Project Reference Manual for a description of these images. You can find
 information on GDB at https://sourceware.org/gdb/.
 
@@ -10453,8 +10252,6 @@ To support this kind of debugging, you need do the following:
    Consider that this will reduce the application's performance and is
    recommended only for debugging purposes.
 
-.. _dev-other-debugging-others:
-
 Other Debugging Tips
 --------------------
 
@@ -10520,7 +10317,7 @@ Here are some other tips that you might find useful:
    Project implementation of
    :yocto_bugs:`Bugzilla <>`. For information on
    how to submit a bug against the Yocto Project, see the Yocto Project
-   Bugzilla :yocto_wiki:`wiki page </wiki/Bugzilla_Configuration_and_Bug_Tracking>`
+   Bugzilla :yocto_wiki:`wiki page </Bugzilla_Configuration_and_Bug_Tracking>`
    and the "`Submitting a Defect Against the Yocto
    Project <#submitting-a-defect-against-the-yocto-project>`__" section.
 
@@ -10548,7 +10345,7 @@ implementation of Bugzilla see the ":ref:`Yocto Project
 Bugzilla <resources-bugtracker>`" section in the
 Yocto Project Reference Manual. For more detail on any of the following
 steps, see the Yocto Project
-:yocto_wiki:`Bugzilla wiki page </wiki/Bugzilla_Configuration_and_Bug_Tracking>`.
+:yocto_wiki:`Bugzilla wiki page </Bugzilla_Configuration_and_Bug_Tracking>`.
 
 Use the following general steps to submit a bug:
 
@@ -10596,8 +10393,6 @@ categorization, progress, or comments on the bug result in Bugzilla
 sending you an automated email concerning the particular change or
 progress to the bug.
 
-.. _how-to-submit-a-change:
-
 Submitting a Change to the Yocto Project
 ----------------------------------------
 
@@ -10662,7 +10457,8 @@ Yocto general mailing list or on the openembedded-devel mailing list.
 
 You can also push a change upstream and request a maintainer to pull the
 change into the component's upstream repository. You do this by pushing
-to a contribution repository that is upstream. See the ":ref:`gs-git-workflows-and-the-yocto-project`"
+to a contribution repository that is upstream. See the
+":ref:`overview-manual/development-environment:git workflows and the yocto project`"
 section in the Yocto Project Overview and Concepts Manual for additional
 concepts on working in the Yocto Project development environment.
 
@@ -10676,7 +10472,7 @@ used testing branches for OpenEmbedded-Core are as follows:
    proposed changes to the core metadata.
 
 -  *poky "master-next" branch:* This branch is part of the
-   :yocto_git:`poky </cgit/cgit.cgi/poky/>` repository and combines proposed
+   :yocto_git:`poky </poky/>` repository and combines proposed
    changes to bitbake, the core metadata and the poky distro.
 
 Similarly, stable branches maintained by the project may have corresponding
@@ -10690,8 +10486,6 @@ layers you are contributing to.
 
 The following sections provide procedures for submitting a change.
 
-.. _preparing-changes-for-submissions:
-
 Preparing Changes for Submission
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -10775,8 +10569,6 @@ Preparing Changes for Submission
 
          detailed description of change
 
-.. _submitting-a-patch:
-
 Using Email to Submit a Patch
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -10789,7 +10581,7 @@ Yocto Project Reference Manual.
 
 Here is the general procedure on how to submit a patch through email
 without using the scripts once the steps in
-:ref:`preparing-changes-for-submissions` have been followed:
+:ref:`dev-manual/common-tasks:preparing changes for submission` have been followed:
 
 1. *Format the Commit:* Format the commit into an email message. To
    format commits, use the ``git format-patch`` command. When you
@@ -10867,8 +10659,6 @@ reduce the burden of patch review on maintainers.
    Asking about the status of a patch or change is reasonable if the change
    has been idle for a while with no feedback.
 
-.. _pushing-a-change-upstream:
-
 Using Scripts to Push a Change Upstream and Request a Pull
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -10880,7 +10670,7 @@ and ``send-pull-request`` scripts from openembedded-core to create and send a
 patch series with a link to the branch for review.
 
 Follow this procedure to push a change to an upstream "contrib" Git
-repository once the steps in :ref:`preparing-changes-for-submissions` have
+repository once the steps in :ref:`dev-manual/common-tasks:preparing changes for submission` have
 been followed:
 
 .. note::
@@ -10917,7 +10707,7 @@ been followed:
       located in the :term:`Source Directory` at
       ``meta/conf/distro/include``, to see who is responsible for code.
 
-   -  *Search by File:* Using :ref:`overview-manual/overview-manual-development-environment:git`, you can
+   -  *Search by File:* Using :ref:`overview-manual/development-environment:git`, you can
       enter the following command to bring up a short list of all
       commits against a specific file:
       ::
@@ -11019,7 +10809,7 @@ master branch or the fix on the master branch is unsuitable for backporting.
 
 The list of stable branches along with the status and maintainer for each
 branch can be obtained from the
-:yocto_wiki:`Releases wiki page </wiki/Releases>`.
+:yocto_wiki:`Releases wiki page </Releases>`.
 
 .. note::
 
@@ -11055,8 +10845,8 @@ follows:
       a newer version of the software which includes an upstream fix for the
       issue or when the issue has been fixed on the master branch in a way
       that introduces backwards incompatible changes. In this case follow the
-      steps in :ref:`preparing-changes-for-submissions` and
-      :ref:`submitting-a-patch` but modify the subject header of your patch
+      steps in :ref:`dev-manual/common-tasks:preparing changes for submission` and
+      :ref:`dev-manual/common-tasks:using email to submit a patch` but modify the subject header of your patch
       email to include the name of the stable branch which you are
       targetting. This can be done using the ``--subject-prefix`` argument to
       ``git format-patch``, for example to submit a patch to the dunfell
@@ -11066,7 +10856,7 @@ follows:
 Working With Licenses
 =====================
 
-As mentioned in the ":ref:`overview-manual/overview-manual-development-environment:licensing`"
+As mentioned in the ":ref:`overview-manual/development-environment:licensing`"
 section in the Yocto Project Overview and Concepts Manual, open source
 projects are open to the public and they consequently have different
 licensing structures in place. This section describes the mechanism by
@@ -11076,8 +10866,6 @@ licensing text and covers how to maintain open source license compliance
 during your project's lifecycle. The section also describes how to
 enable commercially licensed recipes, which by default are disabled.
 
-.. _usingpoky-configuring-LIC_FILES_CHKSUM:
-
 Tracking License Changes
 ------------------------
 
@@ -11088,8 +10876,6 @@ variable tracks changes to the license text. The checksums are validated
 at the end of the configure step, and if the checksums do not match, the
 build will fail.
 
-.. _usingpoky-specifying-LIC_FILES_CHKSUM:
-
 Specifying the ``LIC_FILES_CHKSUM`` Variable
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -11133,8 +10919,6 @@ five through 16 as license text. The second line refers to a file in
 Note that ``LIC_FILES_CHKSUM`` variable is mandatory for all recipes,
 unless the ``LICENSE`` variable is set to "CLOSED".
 
-.. _usingpoky-LIC_FILES_CHKSUM-explanation-of-syntax:
-
 Explanation of Syntax
 ~~~~~~~~~~~~~~~~~~~~~
 
@@ -11515,7 +11299,7 @@ By releasing the version of the OpenEmbedded build system and the layers
 used during the build, you will be providing both compilation scripts
 and the source code modifications in one step.
 
-If the deployment team has a :ref:`overview-manual/overview-manual-concepts:bsp layer`
+If the deployment team has a :ref:`overview-manual/concepts:bsp layer`
 and a distro layer, and those
 those layers are used to patch, compile, package, or modify (in any way)
 any open source software included in your released images, you might be
@@ -11594,7 +11378,7 @@ this function, you have to follow the following steps:
       SPDX_DEPLOY_DIR = "${DEPLOY_DIR}" //Optional
 
 For more usage information refer to :yocto_git:`the meta-spdxscanner repository
-</cgit/cgit.cgi/meta-spdxscanner/>`.
+</meta-spdxscanner/>`.
 
 
 Copying Licenses that Do Not Exist
@@ -11700,11 +11484,9 @@ Setting Up Your Own Error Reporting Server
 ------------------------------------------
 
 If you want to set up your own error reporting server, you can obtain
-the code from the Git repository at :yocto_git:`/cgit/cgit.cgi/error-report-web/`.
+the code from the Git repository at :yocto_git:`/error-report-web/`.
 Instructions on how to set it up are in the README document.
 
-.. _dev-using-wayland-and-weston:
-
 Using Wayland and Weston
 ========================
 
@@ -11747,8 +11529,6 @@ Enabling Wayland in an Image
 To enable Wayland, you need to enable it to be built and enable it to be
 included (installed) in the image.
 
-.. _enable-building:
-
 Building Wayland
 ~~~~~~~~~~~~~~~~
 
@@ -11767,8 +11547,6 @@ statement in your ``local.conf`` file:
    If X11 has been enabled elsewhere, Weston will build Wayland with X11
    support
 
-.. _enable-installation-in-an-image:
-
 Installing Wayland and Weston
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
diff --git a/poky/documentation/dev-manual/dev-manual.rst b/poky/documentation/dev-manual/index.rst
index 8f09224fe..941db2df8 100644
--- a/poky/documentation/dev-manual/dev-manual.rst
+++ b/poky/documentation/dev-manual/index.rst
@@ -10,10 +10,10 @@ Yocto Project Development Tasks Manual
    :caption: Table of Contents
    :numbered:
 
-   dev-manual-intro
-   dev-manual-start
-   dev-manual-common-tasks
-   dev-manual-qemu
+   intro
+   start
+   common-tasks
+   qemu
    history
 
 .. include:: /boilerplate.rst
diff --git a/poky/documentation/dev-manual/dev-manual-intro.rst b/poky/documentation/dev-manual/intro.rst
index 05136f735..23c848e87 100644
--- a/poky/documentation/dev-manual/dev-manual-intro.rst
+++ b/poky/documentation/dev-manual/intro.rst
@@ -4,8 +4,6 @@
 The Yocto Project Development Tasks Manual
 ******************************************
 
-.. _dev-welcome:
-
 Welcome
 =======
 
@@ -33,13 +31,13 @@ This manual provides the following:
 This manual does not provide the following:
 
 -  Redundant Step-by-step Instructions: For example, the
-   :doc:`../sdk-manual/sdk-manual` manual contains detailed
+   :doc:`/sdk-manual/index` manual contains detailed
    instructions on how to install an SDK, which is used to develop
    applications for target hardware.
 
 -  Reference or Conceptual Material: This type of material resides in an
    appropriate reference manual. For example, system variables are
-   documented in the :doc:`../ref-manual/ref-manual`.
+   documented in the :doc:`/ref-manual/index`.
 
 -  Detailed Public Information Not Specific to the Yocto Project: For
    example, exhaustive information on how to use the Source Control
@@ -54,7 +52,7 @@ supplemental information is recommended for full comprehension. For
 introductory information on the Yocto Project, see the
 :yocto_home:`Yocto Project Website <>`. If you want to build an image with no
 knowledge of Yocto Project as a way of quickly testing it out, see the
-:doc:`../brief-yoctoprojectqs/brief-yoctoprojectqs` document.
+:doc:`/brief-yoctoprojectqs/index` document.
 
 For a comprehensive list of links and other documentation, see the
 ":ref:`ref-manual/resources:links and related documentation`"
diff --git a/poky/documentation/dev-manual/dev-manual-qemu.rst b/poky/documentation/dev-manual/qemu.rst
index c91e8b538..766691b97 100644
--- a/poky/documentation/dev-manual/dev-manual-qemu.rst
+++ b/poky/documentation/dev-manual/qemu.rst
@@ -10,8 +10,6 @@ This chapter provides both procedures that show you how to use the Quick
 EMUlator (QEMU) and other QEMU information helpful for development
 purposes.
 
-.. _qemu-dev-overview:
-
 Overview
 ========
 
@@ -39,8 +37,6 @@ following references:
 -  `Documentation <https://wiki.qemu.org/Manual>`__\ *:* The QEMU user
    manual.
 
-.. _qemu-running-qemu:
-
 Running QEMU
 ============
 
@@ -50,7 +46,7 @@ available. Follow these general steps to run QEMU:
 
 1. *Install QEMU:* QEMU is made available with the Yocto Project a
    number of ways. One method is to install a Software Development Kit
-   (SDK). See ":ref:`sdk-manual/sdk-intro:the qemu emulator`" section in the
+   (SDK). See ":ref:`sdk-manual/intro:the qemu emulator`" section in the
    Yocto Project Application Development and the Extensible Software
    Development Kit (eSDK) manual for information on how to install QEMU.
 
@@ -81,11 +77,11 @@ available. Follow these general steps to run QEMU:
       your :term:`Build Directory`.
 
    -  If you have not built an image, you can go to the
-      :yocto_dl:`machines/qemu </releases/yocto/yocto-3.1.2/machines/qemu/>` area and download a
+      :yocto_dl:`machines/qemu </releases/yocto/yocto-&DISTRO;/machines/qemu/>` area and download a
       pre-built image that matches your architecture and can be run on
       QEMU.
 
-   See the ":ref:`sdk-manual/sdk-appendix-obtain:extracting the root filesystem`"
+   See the ":ref:`sdk-manual/appendix-obtain:extracting the root filesystem`"
    section in the Yocto Project Application Development and the
    Extensible Software Development Kit (eSDK) manual for information on
    how to extract a root filesystem.
@@ -187,8 +183,6 @@ allow input of absolute coordinates. This default means that the mouse
 can enter and leave the main window without the grab taking effect
 leading to a better user experience.
 
-.. _qemu-running-under-a-network-file-system-nfs-server:
-
 Running Under a Network File System (NFS) Server
 ================================================
 
@@ -243,8 +237,6 @@ using an NFS server.
 
          runqemu-export-rootfs restart file-system-location
 
-.. _qemu-kvm-cpu-compatibility:
-
 QEMU CPU Compatibility Under KVM
 ================================
 
@@ -266,8 +258,6 @@ directory. This setting specifies a ``-cpu`` option passed into QEMU in
 the ``runqemu`` script. Running ``qemu -cpu help`` returns a list of
 available supported CPU types.
 
-.. _qemu-dev-performance:
-
 QEMU Performance
 ================
 
@@ -320,8 +310,6 @@ present, the toolchain is also automatically used.
       Server <#qemu-running-under-a-network-file-system-nfs-server>`__"
       section for more information.
 
-.. _qemu-dev-command-line-syntax:
-
 QEMU Command-Line Syntax
 ========================
 
@@ -377,8 +365,6 @@ Following is the command-line help output for the ``runqemu`` command:
      runqemu path/to/<image>-<machine>.wic
      runqemu path/to/<image>-<machine>.wic.vmdk
 
-.. _qemu-dev-runqemu-command-line-options:
-
 ``runqemu`` Command-Line Options
 ================================
 
diff --git a/poky/documentation/dev-manual/dev-manual-start.rst b/poky/documentation/dev-manual/start.rst
index a85b86fbf..03061a79f 100644
--- a/poky/documentation/dev-manual/dev-manual-start.rst
+++ b/poky/documentation/dev-manual/start.rst
@@ -7,12 +7,10 @@ Setting Up to Use the Yocto Project
 This chapter provides guidance on how to prepare to use the Yocto
 Project. You can learn about creating a team environment to develop
 using the Yocto Project, how to set up a :ref:`build
-host <dev-manual/dev-manual-start:preparing the build host>`, how to locate
+host <dev-manual/start:preparing the build host>`, how to locate
 Yocto Project source repositories, and how to create local Git
 repositories.
 
-.. _usingpoky-changes-collaborate:
-
 Creating a Team Development Environment
 =======================================
 
@@ -80,7 +78,7 @@ particular working environment and set of practices.
     developing under the control of an SCM system that is compatible
     with the OpenEmbedded build system is advisable. Of all of the SCMs
     supported by BitBake, the Yocto Project team strongly recommends using
-    :ref:`overview-manual/overview-manual-development-environment:git`.
+    :ref:`overview-manual/development-environment:git`.
     Git is a distributed system
     that is easy to back up, allows you to work remotely, and then
     connects back to the infrastructure.
@@ -167,7 +165,7 @@ particular working environment and set of practices.
     -  Highlights when commits break the build.
 
     -  Populates an :ref:`sstate
-       cache <overview-manual/overview-manual-concepts:shared state cache>` from which
+       cache <overview-manual/concepts:shared state cache>` from which
        developers can pull rather than requiring local builds.
 
     -  Allows commit hook triggers, which trigger builds when commits
@@ -220,17 +218,17 @@ particular working environment and set of practices.
     some best practices exist within the Yocto Project development
     environment. Consider the following:
 
-    -  Use :ref:`overview-manual/overview-manual-development-environment:git` as the source control
+    -  Use :ref:`overview-manual/development-environment:git` as the source control
        system.
 
     -  Maintain your Metadata in layers that make sense for your
-       situation. See the ":ref:`overview-manual/overview-manual-yp-intro:the yocto project layer model`"
+       situation. See the ":ref:`overview-manual/yp-intro:the yocto project layer model`"
        section in the Yocto Project Overview and Concepts Manual and the
-       ":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`"
+       ":ref:`dev-manual/common-tasks:understanding and creating layers`"
        section for more information on layers.
 
     -  Separate the project's Metadata and code by using separate Git
-       repositories. See the ":ref:`overview-manual/overview-manual-development-environment:yocto project source repositories`"
+       repositories. See the ":ref:`overview-manual/development-environment:yocto project source repositories`"
        section in the Yocto Project Overview and Concepts Manual for
        information on these repositories. See the "`Locating Yocto
        Project Source Files <#locating-yocto-project-source-files>`__"
@@ -250,19 +248,17 @@ particular working environment and set of practices.
        project to fix bugs or add features. If you do submit patches,
        follow the project commit guidelines for writing good commit
        messages. See the
-       ":ref:`dev-manual/dev-manual-common-tasks:submitting a change to the yocto project`"
+       ":ref:`dev-manual/common-tasks:submitting a change to the yocto project`"
        section.
 
     -  Send changes to the core sooner than later as others are likely
        to run into the same issues. For some guidance on mailing lists
        to use, see the list in the
-       ":ref:`dev-manual/dev-manual-common-tasks:submitting a change to the yocto project`"
+       ":ref:`dev-manual/common-tasks:submitting a change to the yocto project`"
        section. For a description
        of the available mailing lists, see the ":ref:`resources-mailinglist`" section in
        the Yocto Project Reference Manual.
 
-.. _dev-preparing-the-build-host:
-
 Preparing the Build Host
 ========================
 
@@ -292,7 +288,7 @@ Package (BSP) development and kernel development:
    section in the Yocto Project Board Support Package (BSP) Developer's
    Guide.
 
--  *Kernel Development:* See the ":ref:`kernel-dev/kernel-dev-common:preparing the build host to work on the kernel`"
+-  *Kernel Development:* See the ":ref:`kernel-dev/common:preparing the build host to work on the kernel`"
    section in the Yocto Project Linux Kernel Development Manual.
 
 Setting Up a Native Linux Host
@@ -309,7 +305,7 @@ Project Build Host:
    validation and their status, see the ":ref:`Supported Linux
    Distributions <detailed-supported-distros>`"
    section in the Yocto Project Reference Manual and the wiki page at
-   :yocto_wiki:`Distribution Support </wiki/Distribution_Support>`.
+   :yocto_wiki:`Distribution Support </Distribution_Support>`.
 
 2. *Have Enough Free Memory:* Your system should have at least 50 Gbytes
    of free disk space for building images.
@@ -329,7 +325,7 @@ Project Build Host:
    If your build host does not meet any of these three listed version
    requirements, you can take steps to prepare the system so that you
    can still use the Yocto Project. See the
-   ":ref:`ref-manual/ref-system-requirements:required git, tar, python and gcc versions`"
+   ":ref:`ref-manual/system-requirements:required git, tar, python and gcc versions`"
    section in the Yocto Project Reference Manual for information.
 
 4. *Install Development Host Packages:* Required development host
@@ -338,22 +334,20 @@ Project Build Host:
    is large if you want to be able to cover all cases.
 
    For lists of required packages for all scenarios, see the
-   ":ref:`ref-manual/ref-system-requirements:required packages for the build host`"
+   ":ref:`ref-manual/system-requirements:required packages for the build host`"
    section in the Yocto Project Reference Manual.
 
 Once you have completed the previous steps, you are ready to continue
 using a given development path on your native Linux machine. If you are
 going to use BitBake, see the
-":ref:`dev-manual/dev-manual-start:cloning the \`\`poky\`\` repository`"
+":ref:`dev-manual/start:cloning the \`\`poky\`\` repository`"
 section. If you are going
-to use the Extensible SDK, see the ":doc:`../sdk-manual/sdk-extensible`" Chapter in the Yocto
+to use the Extensible SDK, see the ":doc:`/sdk-manual/extensible`" Chapter in the Yocto
 Project Application Development and the Extensible Software Development
-Kit (eSDK) manual. If you want to work on the kernel, see the :doc:`../kernel-dev/kernel-dev`. If you are going to use
-Toaster, see the ":doc:`../toaster-manual/toaster-manual-setup-and-use`"
+Kit (eSDK) manual. If you want to work on the kernel, see the :doc:`/kernel-dev/index`. If you are going to use
+Toaster, see the ":doc:`/toaster-manual/setup-and-use`"
 section in the Toaster User Manual.
 
-.. _setting-up-to-use-crops:
-
 Setting Up to Use CROss PlatformS (CROPS)
 -----------------------------------------
 
@@ -446,16 +440,14 @@ as your Yocto Project build host:
 Once you have a container set up, everything is in place to develop just
 as if you were running on a native Linux machine. If you are going to
 use the Poky container, see the
-":ref:`dev-manual/dev-manual-start:cloning the \`\`poky\`\` repository`"
+":ref:`dev-manual/start:cloning the \`\`poky\`\` repository`"
 section. If you are going to use the Extensible SDK container, see the
-":doc:`../sdk-manual/sdk-extensible`" Chapter in the Yocto
+":doc:`/sdk-manual/extensible`" Chapter in the Yocto
 Project Application Development and the Extensible Software Development
 Kit (eSDK) manual. If you are going to use the Toaster container, see
-the ":doc:`../toaster-manual/toaster-manual-setup-and-use`"
+the ":doc:`/toaster-manual/setup-and-use`"
 section in the Toaster User Manual.
 
-.. _setting-up-to-use-wsl:
-
 Setting Up to Use Windows Subsystem For Linux (WSLv2)
 -----------------------------------------------------
 
@@ -565,10 +557,10 @@ your Yocto Project build host:
 
 Once you have WSLv2 set up, everything is in place to develop just as if
 you were running on a native Linux machine. If you are going to use the
-Extensible SDK container, see the ":doc:`../sdk-manual/sdk-extensible`" Chapter in the Yocto
+Extensible SDK container, see the ":doc:`/sdk-manual/extensible`" Chapter in the Yocto
 Project Application Development and the Extensible Software Development
 Kit (eSDK) manual. If you are going to use the Toaster container, see
-the ":doc:`../toaster-manual/toaster-manual-setup-and-use`"
+the ":doc:`/toaster-manual/setup-and-use`"
 section in the Toaster User Manual.
 
 Locating Yocto Project Source Files
@@ -580,21 +572,21 @@ files you'll need to work with the Yocto Project.
 .. note::
 
    -  For concepts and introductory information about Git as it is used
-      in the Yocto Project, see the ":ref:`overview-manual/overview-manual-development-environment:git`"
+      in the Yocto Project, see the ":ref:`overview-manual/development-environment:git`"
       section in the Yocto Project Overview and Concepts Manual.
 
    -  For concepts on Yocto Project source repositories, see the
-      ":ref:`overview-manual/overview-manual-development-environment:yocto project source repositories`"
+      ":ref:`overview-manual/development-environment:yocto project source repositories`"
       section in the Yocto Project Overview and Concepts Manual."
 
 Accessing Source Repositories
 -----------------------------
 
-Working from a copy of the upstream :ref:`dev-manual/dev-manual-start:accessing source repositories` is the
+Working from a copy of the upstream :ref:`dev-manual/start:accessing source repositories` is the
 preferred method for obtaining and using a Yocto Project release. You
 can view the Yocto Project Source Repositories at
 :yocto_git:`/`. In particular, you can find the ``poky``
-repository at :yocto_git:`/cgit.cgi/poky`.
+repository at :yocto_git:`/poky`.
 
 Use the following procedure to locate the latest upstream copy of the
 ``poky`` Git repository:
@@ -608,12 +600,12 @@ Use the following procedure to locate the latest upstream copy of the
 
 3. *Find the URL Used to Clone the Repository:* At the bottom of the
    page, note the URL used to clone that repository
-   (e.g. :yocto_git:`/cgit.cgi/poky`).
+   (e.g. :yocto_git:`/poky`).
 
    .. note::
 
       For information on cloning a repository, see the
-      ":ref:`dev-manual/dev-manual-start:cloning the \`\`poky\`\` repository`" section.
+      ":ref:`dev-manual/start:cloning the \`\`poky\`\` repository`" section.
 
 Accessing Index of Releases
 ---------------------------
@@ -686,7 +678,7 @@ Releases <#accessing-index-of-releases>`__" section.
    .. note::
 
       For a "map" of Yocto Project releases to version numbers, see the
-      :yocto_wiki:`Releases </wiki/Releases>` wiki page.
+      :yocto_wiki:`Releases </Releases>` wiki page.
 
    You can use the "RELEASE ARCHIVE" link to reveal a menu of all Yocto
    Project releases.
@@ -730,7 +722,7 @@ files is referred to as the :term:`Source Directory`
 in the Yocto Project documentation.
 
 The preferred method of creating your Source Directory is by using
-:ref:`overview-manual/overview-manual-development-environment:git` to clone a local copy of the upstream
+:ref:`overview-manual/development-environment:git` to clone a local copy of the upstream
 ``poky`` repository. Working from a cloned copy of the upstream
 repository allows you to contribute back into the Yocto Project or to
 simply work with the latest software on a development branch. Because
@@ -809,7 +801,7 @@ and then specifically check out that development branch.
 1. *Switch to the Poky Directory:* If you have a local poky Git
    repository, switch to that directory. If you do not have the local
    copy of poky, see the
-   ":ref:`dev-manual/dev-manual-start:cloning the \`\`poky\`\` repository`"
+   ":ref:`dev-manual/start:cloning the \`\`poky\`\` repository`"
    section.
 
 2. *Determine Existing Branch Names:*
@@ -855,8 +847,6 @@ and then specifically check out that development branch.
         master
         * &DISTRO_NAME_NO_CAP;
 
-.. _checkout-out-by-tag-in-poky:
-
 Checking Out by Tag in Poky
 ---------------------------
 
@@ -874,7 +864,7 @@ similar to checking out by branch name except you use tag names.
 1. *Switch to the Poky Directory:* If you have a local poky Git
    repository, switch to that directory. If you do not have the local
    copy of poky, see the
-   ":ref:`dev-manual/dev-manual-start:cloning the \`\`poky\`\` repository`"
+   ":ref:`dev-manual/start:cloning the \`\`poky\`\` repository`"
    section.
 
 2. *Fetch the Tag Names:* To checkout the branch based on a tag name,