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, 90 insertions, 166 deletions

diff --git a/poky/documentation/overview-manual/overview-manual-concepts.rst b/poky/documentation/overview-manual/concepts.rst
index 736fd9591..8fbbabbac 100644
--- a/poky/documentation/overview-manual/overview-manual-concepts.rst
+++ b/poky/documentation/overview-manual/concepts.rst
@@ -34,17 +34,15 @@ itself is of various types:
 
 BitBake knows how to combine multiple data sources together and refers
 to each data source as a layer. For information on layers, see the
-":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`"
+":ref:`dev-manual/common-tasks:understanding and creating layers`"
 section of the Yocto Project Development Tasks Manual.
 
 Following are some brief details on these core components. For
 additional information on how these components interact during a build,
 see the
-":ref:`overview-manual/overview-manual-concepts:openembedded build system concepts`"
+":ref:`overview-manual/concepts:openembedded build system concepts`"
 section.
 
-.. _usingpoky-components-bitbake:
-
 BitBake
 -------
 
@@ -78,7 +76,7 @@ versions of ``matchbox-desktop`` might exist. BitBake chooses the one
 selected by the distribution configuration. You can get more details
 about how BitBake chooses between different target versions and
 providers in the
-":ref:`Preferences <bitbake:bb-bitbake-preferences>`" section
+":ref:`Preferences <bitbake:bitbake-user-manual/bitbake-user-manual-execution:preferences>`" section
 of the BitBake User Manual.
 
 BitBake also tries to execute any dependent tasks first. So for example,
@@ -92,8 +90,6 @@ occurs, the target that failed and those that depend on it cannot be
 remade. However, when you use this option other dependencies can still
 be processed.
 
-.. _overview-components-recipes:
-
 Recipes
 -------
 
@@ -109,8 +105,6 @@ the word "package" is used for the packaged output from the OpenEmbedded
 build system (i.e. ``.ipk`` or ``.deb`` files), this document avoids
 using the term "package" when referring to recipes.
 
-.. _overview-components-classes:
-
 Classes
 -------
 
@@ -118,12 +112,10 @@ Class files (``.bbclass``) contain information that is useful to share
 between recipes files. An example is the
 :ref:`autotools <ref-classes-autotools>` class,
 which contains common settings for any application that Autotools uses.
-The ":ref:`ref-manual/ref-classes:Classes`" chapter in the
+The ":ref:`ref-manual/classes:Classes`" chapter in the
 Yocto Project Reference Manual provides details about classes and how to
 use them.
 
-.. _overview-components-configurations:
-
 Configurations
 --------------
 
@@ -135,8 +127,6 @@ common configuration options, and user configuration options in
 ``conf/local.conf``, which is found in the :term:`Build Directory`.
 
 
-.. _overview-layers:
-
 Layers
 ======
 
@@ -163,11 +153,9 @@ Conforming to a known structure allows BitBake to make assumptions
 during builds on where to find types of metadata. You can find
 procedures and learn about tools (i.e. ``bitbake-layers``) for creating
 layers suitable for the Yocto Project in the
-":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`"
+":ref:`dev-manual/common-tasks:understanding and creating layers`"
 section of the Yocto Project Development Tasks Manual.
 
-.. _openembedded-build-system-build-concepts:
-
 OpenEmbedded Build System Concepts
 ==================================
 
@@ -285,7 +273,7 @@ The ``local.conf`` file provides many basic variables that define a
 build environment. Here is a list of a few. To see the default
 configurations in a ``local.conf`` file created by the build environment
 script, see the
-:yocto_git:`local.conf.sample </cgit/cgit.cgi/poky/tree/meta-poky/conf/local.conf.sample>`
+:yocto_git:`local.conf.sample </poky/tree/meta-poky/conf/local.conf.sample>`
 in the ``meta-poky`` layer:
 
 -  *Target Machine Selection:* Controlled by the
@@ -329,7 +317,7 @@ during the build. By default, the layers listed in this file include
 layers minimally needed by the build system. However, you must manually
 add any custom layers you have created. You can find more information on
 working with the ``bblayers.conf`` file in the
-":ref:`dev-manual/dev-manual-common-tasks:enabling your layer`"
+":ref:`dev-manual/common-tasks:enabling your layer`"
 section in the Yocto Project Development Tasks Manual.
 
 The files ``site.conf`` and ``auto.conf`` are not created by the
@@ -405,17 +393,17 @@ figure <#general-workflow-figure>`__:
    configurations. This type of information is specific to a particular
    target architecture. A good example of a BSP layer from the `Poky
    Reference Distribution <#gs-reference-distribution-poky>`__ is the
-   :yocto_git:`meta-yocto-bsp </cgit/cgit.cgi/poky/tree/meta-yocto-bsp>`
+   :yocto_git:`meta-yocto-bsp </poky/tree/meta-yocto-bsp>`
    layer.
 
 -  *Policy Configuration:* Distribution Layers (i.e. "Distro Layer" in
    the following figure) providing top-level or general policies for the
    images or SDKs being built for a particular distribution. For
    example, in the Poky Reference Distribution the distro layer is the
-   :yocto_git:`meta-poky </cgit/cgit.cgi/poky/tree/meta-poky>`
+   :yocto_git:`meta-poky </poky/tree/meta-poky>`
    layer. Within the distro layer is a ``conf/distro`` directory that
    contains distro configuration files (e.g.
-   :yocto_git:`poky.conf </cgit/cgit.cgi/poky/tree/meta-poky/conf/distro/poky.conf>`
+   :yocto_git:`poky.conf </poky/tree/meta-poky/conf/distro/poky.conf>`
    that contain many policy configurations for the Poky distribution.
 
 The following figure shows an expanded representation of these three
@@ -430,7 +418,7 @@ a ``README`` file as good practice and especially if the layer is to be
 distributed, a configuration directory, and recipe directories. You can
 learn about the general structure for layers used with the Yocto Project
 in the
-":ref:`dev-manual/dev-manual-common-tasks:creating your own layer`"
+":ref:`dev-manual/common-tasks:creating your own layer`"
 section in the
 Yocto Project Development Tasks Manual. For a general discussion on
 layers and the many layers from which you can draw, see the
@@ -439,9 +427,8 @@ Model <#the-yocto-project-layer-model>`__" sections both earlier in this
 manual.
 
 If you explored the previous links, you discovered some areas where many
-layers that work with the Yocto Project exist. The `Source
-Repositories <http://git.yoctoproject.org/>`__ also shows layers
-categorized under "Yocto Metadata Layers."
+layers that work with the Yocto Project exist. The :yocto_git:`Source
+Repositories <>` also shows layers categorized under "Yocto Metadata Layers."
 
 .. note::
 
@@ -469,7 +456,7 @@ typically find in the distribution layer:
    can be shared among recipes in the distribution. When your recipes
    inherit a class, they take on the settings and functions for that
    class. You can read more about class files in the
-   ":ref:`ref-manual/ref-classes:Classes`" chapter of the Yocto
+   ":ref:`ref-manual/classes:Classes`" chapter of the Yocto
    Reference Manual.
 
 -  *conf:* This area holds configuration files for the layer
@@ -494,7 +481,7 @@ The BSP Layer provides machine configurations that target specific
 hardware. Everything in this layer is specific to the machine for which
 you are building the image or the SDK. A common structure or form is
 defined for BSP layers. You can learn more about this structure in the
-:doc:`../bsp-guide/bsp-guide`.
+:doc:`/bsp-guide/index`.
 
 .. note::
 
@@ -527,8 +514,6 @@ their respective layers.
 This layer contains any recipes, append files, and patches, that your
 project needs.
 
-.. _sources-dev-environment:
-
 Sources
 -------
 
@@ -601,13 +586,11 @@ class to include that local project. You use either the ``local.conf``
 or a recipe's append file to override or set the recipe to point to the
 local directory on your disk to pull in the whole source tree.
 
-.. _scms:
-
 Source Control Managers (Optional)
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Another place from which the build system can get source files is with
-:ref:`fetchers <bitbake:bb-fetchers>` employing various Source
+:ref:`fetchers <bitbake:bitbake-user-manual/bitbake-user-manual-fetching:fetchers>` employing various Source
 Control Managers (SCMs) such as Git or Subversion. In such cases, a
 repository is cloned or checked out. The
 :ref:`ref-tasks-fetch` task inside
@@ -644,8 +627,6 @@ Regular mirrors can be any site across the Internet that is used as an
 alternative location for source code should the primary site not be
 functioning for some reason or another.
 
-.. _package-feeds-dev-environment:
-
 Package Feeds
 -------------
 
@@ -709,8 +690,6 @@ qemux86 exist. Packages for the i586 architecture are placed in
 ``build/tmp/deploy/ipk/i586``, while packages for the qemux86
 architecture are placed in ``build/tmp/deploy/ipk/qemux86``.
 
-.. _bitbake-dev-environment:
-
 BitBake Tool
 ------------
 
@@ -727,8 +706,6 @@ those areas.
    BitBake User Manual
    for reference material on BitBake.
 
-.. _source-fetching-dev-environment:
-
 Source Fetching
 ~~~~~~~~~~~~~~~
 
@@ -819,8 +796,6 @@ Build Directory's hierarchy:
    what the OpenEmbedded build system is using as a build target (e.g.
    general architecture, a build host, an SDK, or a specific machine).
 
-.. _patching-dev-environment:
-
 Patching
 ~~~~~~~~
 
@@ -852,17 +827,15 @@ For more information on how the source directories are created, see the
 "`Source Fetching <#source-fetching-dev-environment>`__" section. For
 more information on how to create patches and how the build system
 processes patches, see the
-":ref:`dev-manual/dev-manual-common-tasks:patching code`"
+":ref:`dev-manual/common-tasks:patching code`"
 section in the
 Yocto Project Development Tasks Manual. You can also see the
-":ref:`sdk-manual/sdk-extensible:use \`\`devtool modify\`\` to modify the source of an existing component`"
+":ref:`sdk-manual/extensible:use \`\`devtool modify\`\` to modify the source of an existing component`"
 section in the Yocto Project Application Development and the Extensible
 Software Development Kit (SDK) manual and the
-":ref:`kernel-dev/kernel-dev-common:using traditional kernel development to patch the kernel`"
+":ref:`kernel-dev/common:using traditional kernel development to patch the kernel`"
 section in the Yocto Project Linux Kernel Development Manual.
 
-.. _configuration-compilation-and-staging-dev-environment:
-
 Configuration, Compilation, and Staging
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -905,7 +878,7 @@ This step in the build process consists of the following tasks:
    variables. For information on how this variable works within that
    class, see the
    :ref:`autotools <ref-classes-autotools>` class
-   :yocto_git:`here </cgit/cgit.cgi/poky/tree/meta/classes/autotools.bbclass>`.
+   :yocto_git:`here </poky/tree/meta/classes/autotools.bbclass>`.
 
 -  *do_compile*: Once a configuration task has been satisfied,
    BitBake compiles the source using the
@@ -922,8 +895,6 @@ This step in the build process consists of the following tasks:
    variable. Packaging occurs later using files from this holding
    directory.
 
-.. _package-splitting-dev-environment:
-
 Package Splitting
 ~~~~~~~~~~~~~~~~~
 
@@ -985,7 +956,7 @@ The :term:`FILES` variable defines the
 files that go into each package in
 :term:`PACKAGES`. If you want
 details on how this is accomplished, you can look at
-:yocto_git:`package.bbclass </cgit/cgit.cgi/poky/tree/meta/classes/package.bbclass>`.
+:yocto_git:`package.bbclass </poky/tree/meta/classes/package.bbclass>`.
 
 Depending on the type of packages being created (RPM, DEB, or IPK), the
 :ref:`do_package_write_* <ref-tasks-package_write_deb>`
@@ -1004,8 +975,6 @@ that part of the build process.
    functionality is highly distribution-specific and thus is not
    provided out of the box.
 
-.. _image-generation-dev-environment:
-
 Image Generation
 ~~~~~~~~~~~~~~~~
 
@@ -1060,7 +1029,7 @@ stage of package installation, post installation scripts that are part
 of the packages are run. Any scripts that fail to run on the build host
 are run on the target when the target system is first booted. If you are
 using a 
-:ref:`read-only root filesystem <dev-manual/dev-manual-common-tasks:creating a read-only root filesystem>`,
+:ref:`read-only root filesystem <dev-manual/common-tasks:creating a read-only root filesystem>`,
 all the post installation scripts must succeed on the build host during
 the package installation phase since the root filesystem on the target
 is read-only.
@@ -1127,8 +1096,6 @@ build system has created the final image output files.
    Pseudo. Running under Pseudo ensures that the files in the root filesystem
    have correct ownership.
 
-.. _sdk-generation-dev-environment:
-
 SDK Generation
 ~~~~~~~~~~~~~~
 
@@ -1142,10 +1109,10 @@ the extensible SDK (eSDK):
 .. note::
 
    For more information on the cross-development toolchain generation,
-   see the ":ref:`overview-manual/overview-manual-concepts:cross-development toolchain generation`"
+   see the ":ref:`overview-manual/concepts:cross-development toolchain generation`"
    section. For information on advantages gained when building a
    cross-development toolchain using the do_populate_sdk task, see the
-   ":ref:`sdk-manual/sdk-appendix-obtain:building an sdk installer`" section in
+   ":ref:`sdk-manual/appendix-obtain:building an sdk installer`" section in
    the Yocto Project Application Development and the Extensible Software
    Development Kit (eSDK) manual.
 
@@ -1225,7 +1192,7 @@ varflag. If some other task depends on such a task, then that task will
 also always be considered out of date, which might not be what you want.
 
 For details on how to view information about a task's signature, see the
-":ref:`dev-manual/dev-manual-common-tasks:viewing task variable dependencies`"
+":ref:`dev-manual/common-tasks:viewing task variable dependencies`"
 section in the Yocto Project Development Tasks Manual.
 
 Setscene Tasks and Shared State
@@ -1303,8 +1270,6 @@ variable is the function that determines whether a given dependency
 needs to be followed, and whether for any given relationship the
 function needs to be passed. The function returns a True or False value.
 
-.. _images-dev-environment:
-
 Images
 ------
 
@@ -1320,7 +1285,7 @@ this output:
 .. note::
 
    For a list of example images that the Yocto Project provides, see the
-   ":doc:`../ref-manual/ref-images`" chapter in the Yocto Project Reference
+   ":doc:`/ref-manual/images`" chapter in the Yocto Project Reference
    Manual.
 
 The build process writes images out to the :term:`Build Directory`
@@ -1363,8 +1328,6 @@ current configuration.
    These links might be useful for external scripts that need to obtain
    the latest version of each file.
 
-.. _sdk-dev-environment:
-
 Application Development SDK
 ---------------------------
 
@@ -1403,7 +1366,7 @@ can initialize the environment before using the tools.
       section.
 
    -  For information on setting up a cross-development environment, see
-      the :doc:`../sdk-manual/sdk-manual` manual.
+      the :doc:`/sdk-manual/index` manual.
 
 All the output files for an SDK are written to the ``deploy/sdk`` folder
 inside the :term:`Build Directory` as
@@ -1480,10 +1443,10 @@ Cross-Development Toolchain Generation
 ======================================
 
 The Yocto Project does most of the work for you when it comes to
-creating :ref:`sdk-manual/sdk-intro:the cross-development toolchain`. This
+creating :ref:`sdk-manual/intro:the cross-development toolchain`. This
 section provides some technical background on how cross-development
 toolchains are created and used. For more information on toolchains, you
-can also see the :doc:`../sdk-manual/sdk-manual` manual.
+can also see the :doc:`/sdk-manual/index` manual.
 
 In the Yocto Project development environment, cross-development
 toolchains are used to build images and applications that run on the
@@ -1610,7 +1573,7 @@ Here is the bootstrap process for the relocatable toolchain:
 
    For information on advantages gained when building a
    cross-development toolchain installer, see the
-   ":ref:`sdk-manual/sdk-appendix-obtain:building an sdk installer`" appendix
+   ":ref:`sdk-manual/appendix-obtain:building an sdk installer`" appendix
    in the Yocto Project Application Development and the
    Extensible Software Development Kit (eSDK) manual.
 
@@ -1663,22 +1626,20 @@ them if they are deemed to be valid.
       the shared state packages. Consequently, considerations exist that
       affect maintaining shared state feeds. For information on how the
       build system works with packages and can track incrementing ``PR``
-      information, see the ":ref:`dev-manual/dev-manual-common-tasks:automatically incrementing a package version number`"
+      information, see the ":ref:`dev-manual/common-tasks:automatically incrementing a package version number`"
       section in the Yocto Project Development Tasks Manual.
 
    -  The code in the build system that supports incremental builds is
       not simple code. For techniques that help you work around issues
       related to shared state code, see the
-      ":ref:`dev-manual/dev-manual-common-tasks:viewing metadata used to create the input signature of a shared state task`"
+      ":ref:`dev-manual/common-tasks:viewing metadata used to create the input signature of a shared state task`"
       and
-      ":ref:`dev-manual/dev-manual-common-tasks:invalidating shared state to force a task to run`"
+      ":ref:`dev-manual/common-tasks:invalidating shared state to force a task to run`"
       sections both in the Yocto Project Development Tasks Manual.
 
 The rest of this section goes into detail about the overall incremental
 build architecture, the checksums (signatures), and shared state.
 
-.. _concepts-overall-architecture:
-
 Overall Architecture
 --------------------
 
@@ -1697,8 +1658,6 @@ specific tasks. This methodology does not scale well and does not allow
 users to easily add new tasks in layers or as external recipes without
 touching the packaged-staging core.
 
-.. _overview-checksums:
-
 Checksums (Signatures)
 ----------------------
 
@@ -1949,7 +1908,7 @@ The following list explains the previous example:
    extra metadata to the `stamp
    file <#stamp-files-and-the-rerunning-of-tasks>`__. In this case, the
    metadata makes the task specific to a machine's architecture. See
-   ":ref:`bitbake:ref-bitbake-tasklist`"
+   ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-execution:the task list`"
    section in the BitBake User Manual for more information on the
    ``stamp-extra-info`` flag.
 
diff --git a/poky/documentation/overview-manual/overview-manual-development-environment.rst b/poky/documentation/overview-manual/development-environment.rst
index 4bedd6df6..9a2997d9f 100644
--- a/poky/documentation/overview-manual/overview-manual-development-environment.rst
+++ b/poky/documentation/overview-manual/development-environment.rst
@@ -45,8 +45,6 @@ also find helpful information on how to participate in the Linux
 Community
 `here <https://www.kernel.org/doc/html/latest/process/index.html>`__.
 
-.. _gs-the-development-host:
-
 The Development Host
 ====================
 
@@ -68,7 +66,7 @@ to set up a CROPS machine, you effectively have access to a shell
 environment that is similar to what you see when using a Linux-based
 development host. For the steps needed to set up a system using CROPS,
 see the
-":ref:`dev-manual/dev-manual-start:setting up to use cross platforms (crops)`"
+":ref:`dev-manual/start:setting up to use cross platforms (crops)`"
 section in
 the Yocto Project Development Tasks Manual.
 
@@ -79,7 +77,7 @@ distribution on the system is one that supports the Yocto Project. You
 also need to be sure that the correct set of host packages are installed
 that allow development using the Yocto Project. For the steps needed to
 set up a development host that runs Linux, see the
-":ref:`dev-manual/dev-manual-start:setting up a native linux host`"
+":ref:`dev-manual/start:setting up a native linux host`"
 section in the Yocto Project Development Tasks Manual.
 
 Once your development host is set up to use the Yocto Project, several
@@ -96,7 +94,7 @@ methods exist for you to do work in the Yocto Project environment:
    through your Linux distribution and the Yocto Project.
 
    For a general flow of the build procedures, see the
-   ":ref:`dev-manual/dev-manual-common-tasks:building a simple image`"
+   ":ref:`dev-manual/common-tasks:building a simple image`"
    section in the Yocto Project Development Tasks Manual.
 
 -  *Board Support Package (BSP) Development:* Development of BSPs
@@ -105,7 +103,7 @@ methods exist for you to do work in the Yocto Project environment:
    hardware. To development BSPs, you need to take some additional steps
    beyond what was described in setting up a development host.
 
-   The :doc:`../bsp-guide/bsp-guide` provides BSP-related development
+   The :doc:`/bsp-guide/index` provides BSP-related development
    information. For specifics on development host preparation, see the
    ":ref:`bsp-guide/bsp:preparing your build host to work with bsp layers`"
    section in the Yocto Project Board Support Package (BSP) Developer's
@@ -116,10 +114,10 @@ methods exist for you to do work in the Yocto Project environment:
    using ``devtool`` makes kernel development quicker by reducing
    iteration cycle times.
 
-   The :doc:`../kernel-dev/kernel-dev` provides kernel-related
+   The :doc:`/kernel-dev/index` provides kernel-related
    development information. For specifics on development host
    preparation, see the
-   ":ref:`kernel-dev/kernel-dev-common:preparing the build host to work on the kernel`"
+   ":ref:`kernel-dev/common:preparing the build host to work on the kernel`"
    section in the Yocto Project Linux Kernel Development Manual.
 
 -  *Using Toaster:* The other Yocto Project development method that
@@ -132,9 +130,7 @@ methods exist for you to do work in the Yocto Project environment:
 
    For steps that show you how to set up your development host to use
    Toaster and on how to use Toaster in general, see the
-   :doc:`../toaster-manual/toaster-manual`.
-
-.. _yocto-project-repositories:
+   :doc:`/toaster-manual/index`.
 
 Yocto Project Source Repositories
 =================================
@@ -182,7 +178,7 @@ development:
       :align: center
 
    For steps on how to view and access these upstream Git repositories,
-   see the ":ref:`dev-manual/dev-manual-start:accessing source repositories`"
+   see the ":ref:`dev-manual/start:accessing source repositories`"
    Section in the Yocto Project Development Tasks Manual.
 
 -  :yocto_dl:`Index of /releases: </releases>` This is an index
@@ -196,7 +192,7 @@ development:
       :align: center
 
    For steps on how to view and access these files, see the
-   ":ref:`dev-manual/dev-manual-start:accessing index of releases`"
+   ":ref:`dev-manual/start:accessing index of releases`"
    section in the Yocto Project Development Tasks Manual.
 
 -  *"DOWNLOADS" page for the* :yocto_home:`Yocto Project Website <>` *:*
@@ -211,11 +207,9 @@ development:
       :align: center
 
    For steps on how to use the "DOWNLOADS" page, see the
-   ":ref:`dev-manual/dev-manual-start:using the downloads page`"
+   ":ref:`dev-manual/start:using the downloads page`"
    section in the Yocto Project Development Tasks Manual.
 
-.. _gs-git-workflows-and-the-yocto-project:
-
 Git Workflows and the Yocto Project
 ===================================
 
@@ -248,7 +242,7 @@ and so forth.
 
    For information on finding out who is responsible for (maintains) a
    particular area of code in the Yocto Project, 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 of the Yocto Project Development Tasks Manual.
 
 The Yocto Project ``poky`` Git repository also has an upstream
@@ -280,7 +274,7 @@ push them into the "contrib" area and subsequently request that the
 maintainer include them into an upstream branch. This process is called
 "submitting a patch" or "submitting a change." For information on
 submitting patches and changes, 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 in the Yocto Project Development Tasks Manual.
 
 In summary, a single point of entry exists for changes into a "master"
@@ -347,7 +341,7 @@ Book <http://book.git-scm.com>`__.
    the ``scripts`` folder of the
    :term:`Source Directory`. For information
    on how to use these scripts, see the
-   ":ref:`dev-manual/dev-manual-common-tasks:using scripts to push a change upstream and request a pull`"
+   ":ref:`dev-manual/common-tasks:using scripts to push a change upstream and request a pull`"
    section in the Yocto Project Development Tasks Manual.
 
 -  *Patch Workflow:* This workflow allows you to notify the maintainer
@@ -356,7 +350,7 @@ Book <http://book.git-scm.com>`__.
    this type of change, you format the patch and then send the email
    using the Git commands ``git format-patch`` and ``git send-email``.
    For information on how to use these scripts, 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 in the Yocto Project Development Tasks Manual.
 
 Git
@@ -382,7 +376,7 @@ commands.
       page, see http://git-scm.com/download.
 
    -  For information beyond the introductory nature in this section,
-      see the ":ref:`dev-manual/dev-manual-start:locating yocto project source files`"
+      see the ":ref:`dev-manual/start:locating yocto project source files`"
       section in the Yocto Project Development Tasks Manual.
 
 Repositories, Tags, and Branches
@@ -414,7 +408,7 @@ You can create a local copy of any repository by "cloning" it with the
 an identical copy of the repository on your development system. Once you
 have a local copy of a repository, you can take steps to develop
 locally. For examples on how to clone Git repositories, see the
-":ref:`dev-manual/dev-manual-start:locating yocto project source files`"
+":ref:`dev-manual/start:locating yocto project source files`"
 section in the Yocto Project Development Tasks Manual.
 
 It is important to understand that Git tracks content change and not
@@ -422,7 +416,7 @@ files. Git uses "branches" to organize different development efforts.
 For example, the ``poky`` repository has several branches that include
 the current "&DISTRO_NAME_NO_CAP;" branch, the "master" branch, and many
 branches for past Yocto Project releases. You can see all the branches
-by going to https://git.yoctoproject.org/cgit.cgi/poky/ and clicking on the
+by going to :yocto_git:`/poky/` and clicking on the
 ``[...]`` link beneath the "Branch" heading.
 
 Each of these branches represents a specific area of development. The
@@ -467,9 +461,8 @@ Yocto Project Release.
 Git uses "tags" to mark specific changes in a repository branch
 structure. Typically, a tag is used to mark a special point such as the
 final change (or commit) before a project is released. You can see the
-tags used with the ``poky`` Git repository by going to
-https://git.yoctoproject.org/cgit.cgi/poky/ and clicking on the ``[...]`` link
-beneath the "Tag" heading.
+tags used with the ``poky`` Git repository by going to :yocto_git:`/poky/`
+and clicking on the ``[...]`` link beneath the "Tag" heading.
 
 Some key tags for the ``poky`` repository are ``jethro-14.0.3``,
 ``morty-16.0.1``, ``pyro-17.0.0``, and
@@ -668,5 +661,5 @@ Project uses in the ``meta/files/common-licenses`` directory in your
 For information that can help you maintain compliance with various open
 source licensing during the lifecycle of a product created using the
 Yocto Project, see the
-":ref:`dev-manual/dev-manual-common-tasks:maintaining open source license compliance during your product's lifecycle`"
+":ref:`dev-manual/common-tasks:maintaining open source license compliance during your product's lifecycle`"
 section in the Yocto Project Development Tasks Manual.
diff --git a/poky/documentation/overview-manual/overview-manual.rst b/poky/documentation/overview-manual/index.rst
index f20b20e32..123aed9b8 100644
--- a/poky/documentation/overview-manual/overview-manual.rst
+++ b/poky/documentation/overview-manual/index.rst
@@ -10,10 +10,10 @@ Yocto Project Overview and Concepts Manual
    :caption: Table of Contents
    :numbered:
 
-   overview-manual-intro
-   overview-manual-yp-intro
-   overview-manual-development-environment
-   overview-manual-concepts
+   intro
+   yp-intro
+   development-environment
+   concepts
    history
 
 .. include:: /boilerplate.rst
diff --git a/poky/documentation/overview-manual/overview-manual-intro.rst b/poky/documentation/overview-manual/intro.rst
index 8885eb89f..bd247dd45 100644
--- a/poky/documentation/overview-manual/overview-manual-intro.rst
+++ b/poky/documentation/overview-manual/intro.rst
@@ -4,8 +4,6 @@
 The Yocto Project Overview and Concepts Manual
 **********************************************
 
-.. _overview-manual-welcome:
-
 Welcome
 =======
 
@@ -30,7 +28,7 @@ The following list describes what you can get from this manual:
    Yocto Project source repositories, workflows using Git and the Yocto
    Project, a Git primer, and information about licensing.
 
--  :doc:`overview-manual-concepts` *:* This
+-  :doc:`/overview-manual/concepts` *:* This
    chapter presents various concepts regarding the Yocto Project. You
    can find conceptual information about components, development,
    cross-toolchains, and so forth.
@@ -39,17 +37,17 @@ This manual does not give you the following:
 
 -  *Step-by-step Instructions for Development Tasks:* Instructional
    procedures reside in other manuals within the Yocto Project
-   documentation set. For example, the :doc:`../dev-manual/dev-manual`
+   documentation set. For example, the :doc:`/dev-manual/index`
    provides examples on how to perform
    various development tasks. As another 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 Material:* This type of material resides in an appropriate
    reference manual. For example, system variables are documented in the
-   :doc:`../ref-manual/ref-manual`. As another
-   example, the :doc:`../bsp-guide/bsp-guide` contains reference information on
+   :doc:`/ref-manual/index`. As another
+   example, the :doc:`/bsp-guide/index` contains reference information on
    BSPs.
 
 -  *Detailed Public Information Not Specific to the Yocto Project:* For
@@ -57,8 +55,6 @@ This manual does not give you the following:
    Manager Git is better covered with Internet searches and official Git
    Documentation than through the Yocto Project documentation.
 
-.. _overview-manual-other-information:
-
 Other Information
 =================
 
@@ -67,7 +63,7 @@ supplemental information is recommended for full comprehension. For
 additional 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.
+see the :doc:`/brief-yoctoprojectqs/index` document.
 For a comprehensive list of links and other documentation, see the
 ":ref:`Links and Related
 Documentation <resources-links-and-related-documentation>`"
diff --git a/poky/documentation/overview-manual/overview-manual-yp-intro.rst b/poky/documentation/overview-manual/yp-intro.rst
index 9073582ac..66a88c952 100644
--- a/poky/documentation/overview-manual/overview-manual-yp-intro.rst
+++ b/poky/documentation/overview-manual/yp-intro.rst
@@ -35,8 +35,6 @@ by Drew Moseley and in this short introductory
 The remainder of this section overviews advantages and challenges tied
 to the Yocto Project.
 
-.. _gs-features:
-
 Features
 --------
 
@@ -113,7 +111,7 @@ Project:
    development.
 
 -  *Releases According to a Strict Schedule:* Major releases occur on a
-   :doc:`six-month cycle <../ref-manual/ref-release-process>`
+   :doc:`six-month cycle </ref-manual/release-process>`
    predictably in October and April. The most recent two releases
    support point releases to address common vulnerabilities and
    exposures. This predictability is crucial for projects based on the
@@ -132,12 +130,10 @@ Project:
    arbitrarily include packages.
 
 -  *License Manifest:* The Yocto Project provides a :ref:`license
-   manifest <dev-manual/dev-manual-common-tasks:maintaining open source license compliance during your product's lifecycle>`
+   manifest <dev-manual/common-tasks:maintaining open source license compliance during your product's lifecycle>`
    for review by people who need to track the use of open source
    licenses (e.g. legal teams).
 
-.. _gs-challenges:
-
 Challenges
 ----------
 
@@ -232,7 +228,7 @@ your Metadata, the easier it is to cope with future changes.
 
    -  Layers support the inclusion of technologies, hardware components,
       and software components. The :ref:`Yocto Project
-      Compatible <dev-manual/dev-manual-common-tasks:making sure your layer is compatible with yocto project>`
+      Compatible <dev-manual/common-tasks:making sure your layer is compatible with yocto project>`
       designation provides a minimum level of standardization that
       contributes to a strong ecosystem. "YP Compatible" is applied to
       appropriate products and software components such as BSPs, other
@@ -255,7 +251,7 @@ accomplish this through a recipe that is a BitBake append
 .. note::
 
    For general information on BSP layer structure, see the
-   :doc:`../bsp-guide/bsp-guide`
+   :doc:`/bsp-guide/index`
    .
 
 The :term:`Source Directory`
@@ -271,15 +267,14 @@ with the string ``meta-``.
    , but it is a commonly accepted standard in the Yocto Project
    community.
 
-For example, if you were to examine the `tree
-view <https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/>`__ of the
-``poky`` repository, you will see several layers: ``meta``,
+For example, if you were to examine the :yocto_git:`tree view </poky/tree/>`
+of the ``poky`` repository, you will see several layers: ``meta``,
 ``meta-skeleton``, ``meta-selftest``, ``meta-poky``, and
 ``meta-yocto-bsp``. Each of these repositories represents a distinct
 layer.
 
 For procedures on how to create layers, see the 
-":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`"
+":ref:`dev-manual/common-tasks:understanding and creating layers`"
 section in the Yocto Project Development Tasks Manual.
 
 Components and Tools
@@ -296,8 +291,6 @@ components and tools are downloaded separately.
 This section provides brief overviews of the components and tools
 associated with the Yocto Project.
 
-.. _gs-development-tools:
-
 Development Tools
 -----------------
 
@@ -334,7 +327,7 @@ applications using the Yocto Project:
    You can read about the ``devtool`` workflow in the Yocto Project
    Application Development and Extensible Software Development Kit
    (eSDK) Manual in the 
-   ":ref:`sdk-manual/sdk-extensible:using \`\`devtool\`\` in your sdk workflow`"
+   ":ref:`sdk-manual/extensible:using \`\`devtool\`\` in your sdk workflow`"
    section.
 
 -  *Extensible Software Development Kit (eSDK):* The eSDK provides a
@@ -346,14 +339,12 @@ applications using the Yocto Project:
    experience supplemented with the powerful set of ``devtool`` commands
    tailored for the Yocto Project environment.
 
-   For information on the eSDK, see the :doc:`../sdk-manual/sdk-manual` Manual.
+   For information on the eSDK, see the :doc:`/sdk-manual/index` Manual.
 
 -  *Toaster:* Toaster is a web interface to the Yocto Project
    OpenEmbedded build system. Toaster allows you to configure, run, and
    view information about builds. For information on Toaster, see the
-   :doc:`../toaster-manual/toaster-manual`.
-
-.. _gs-production-tools:
+   :doc:`/toaster-manual/index`.
 
 Production Tools
 ----------------
@@ -366,7 +357,7 @@ activities using the Yocto Project:
    (BitBake and
    OE-Core) automatically generates upgrades for recipes that are based
    on new versions of the recipes published upstream. See
-   :ref:`dev-manual/dev-manual-common-tasks:using the auto upgrade helper (auh)`
+   :ref:`dev-manual/common-tasks:using the auto upgrade helper (auh)`
    for how to set it up.
 
 -  *Recipe Reporting System:* The Recipe Reporting System tracks recipe
@@ -401,7 +392,7 @@ activities using the Yocto Project:
    benefit of the development community.
 
    You can learn more about the AutoBuilder used by the Yocto Project
-   Autobuilder :doc:`here <../test-manual/test-manual-understand-autobuilder>`.
+   Autobuilder :doc:`here </test-manual/understand-autobuilder>`.
 
 -  *Cross-Prelink:* Prelinking is the process of pre-computing the load
    addresses and link tables generated by the dynamic linker as compared
@@ -450,8 +441,6 @@ activities using the Yocto Project:
    You can read more about Pseudo in the "`Fakeroot and
    Pseudo <#fakeroot-and-pseudo>`__" section.
 
-.. _gs-openembedded-build-system:
-
 Open-Embedded Build System Components
 -------------------------------------
 
@@ -477,7 +466,7 @@ The following list consists of components associated with the
    OpenEmbedded-derived systems, which includes the Yocto Project. The
    Yocto Project and the OpenEmbedded Project both maintain the
    OpenEmbedded-Core. You can find the OE-Core metadata in the Yocto
-   Project :yocto_git:`Source Repositories </cgit/cgit.cgi/poky/tree/meta>`.
+   Project :yocto_git:`Source Repositories </poky/tree/meta>`.
 
    Historically, the Yocto Project integrated the OE-Core metadata
    throughout the Yocto Project source repository reference system
@@ -496,8 +485,6 @@ The following list consists of components associated with the
    components such as BitBake, OE-Core, script "glue", and documentation
    for its build system.
 
-.. _gs-reference-distribution-poky:
-
 Reference Distribution (Poky)
 -----------------------------
 
@@ -520,8 +507,6 @@ To use the Yocto Project tools and components, you can download
 You can read more about Poky in the "`Reference Embedded Distribution
 (Poky) <#reference-embedded-distribution>`__" section.
 
-.. _gs-packages-for-finished-targets:
-
 Packages for Finished Targets
 -----------------------------
 
@@ -560,8 +545,6 @@ targets:
    You can find the opkg source in the Yocto Project
    :yocto_git:`Source Repositories <>`.
 
-.. _gs-archived-components:
-
 Archived Components
 -------------------
 
@@ -588,8 +571,6 @@ Linux.
    using the Yocto Project on a system not native to Linux is with
    `CROPS <#gs-crops-overview>`__.
 
-.. _gs-development-methods:
-
 Development Methods
 ===================
 
@@ -608,7 +589,7 @@ Project.
 .. note::
 
    For additional detail about the Yocto Project development
-   environment, see the ":doc:`overview-manual-development-environment`"
+   environment, see the ":doc:`/overview-manual/development-environment`"
    chapter.
 
 -  *Native Linux Host:* By far the best option for a Build Host. A
@@ -620,7 +601,7 @@ Project.
 
    For information on how to set up a Build Host on a system running
    Linux as its native operating system, see the 
-   ":ref:`dev-manual/dev-manual-start:setting up a native linux host`"
+   ":ref:`dev-manual/start:setting up a native linux host`"
    section in the Yocto Project Development Tasks Manual.
 
 -  *CROss PlatformS (CROPS):* Typically, you use
@@ -640,7 +621,7 @@ Project.
    system natively running Linux.
 
    For information on how to set up a Build Host with CROPS, see the
-   ":ref:`dev-manual/dev-manual-start:setting up to use cross platforms (crops)`"
+   ":ref:`dev-manual/start:setting up to use cross platforms (crops)`"
    section in the Yocto Project Development Tasks Manual.
 
 -  *Windows Subsystem For Linux (WSLv2):* You may use Windows Subsystem
@@ -657,7 +638,7 @@ Project.
    virtualization technology.
 
    For information on how to set up a Build Host with WSLv2, see the
-   ":ref:`dev-manual/dev-manual-start:setting up to use windows subsystem for linux (wslv2)`"
+   ":ref:`dev-manual/start:setting up to use windows subsystem for linux (wslv2)`"
    section in the Yocto Project Development Tasks Manual.
 
 -  *Toaster:* Regardless of what your Build Host is running, you can use
@@ -669,9 +650,7 @@ Project.
    configure and start builds on multiple remote build servers.
 
    For information about and how to use Toaster, see the 
-   :doc:`../toaster-manual/toaster-manual`.
-
-.. _reference-embedded-distribution:
+   :doc:`/toaster-manual/index`.
 
 Reference Embedded Distribution (Poky)
 ======================================
@@ -691,13 +670,13 @@ Poky is a combined repository of BitBake, OpenEmbedded-Core (which is
 found in ``meta``), ``meta-poky``, ``meta-yocto-bsp``, and documentation
 provided all together and known to work well together. You can view
 these items that make up the Poky repository in the
-:yocto_git:`Source Repositories </cgit/cgit.cgi/poky/tree/>`.
+:yocto_git:`Source Repositories </poky/tree/>`.
 
 .. note::
 
    If you are interested in all the contents of the
    poky
-   Git repository, see the ":ref:`ref-manual/ref-structure:top-level core components`"
+   Git repository, see the ":ref:`ref-manual/structure:top-level core components`"
    section in the Yocto Project Reference Manual.
 
 The following figure illustrates what generally comprises Poky:
@@ -741,7 +720,7 @@ Poky has a regular, well established, six-month release cycle under its
 own version. Major releases occur at the same time major releases (point
 releases) occur for the Yocto Project, which are typically in the Spring
 and Fall. For more information on the Yocto Project release schedule and
-cadence, see the ":doc:`../ref-manual/ref-release-process`" chapter in the
+cadence, see the ":doc:`/ref-manual/release-process`" chapter in the
 Yocto Project Reference Manual.
 
 Much has been said about Poky being a "default configuration". A default
@@ -776,8 +755,6 @@ operators, see the
 ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:appending and prepending (override style syntax)`"
 section in the BitBake User's Manual.
 
-.. _openembedded-build-system-workflow:
-
 The OpenEmbedded Build System Workflow
 ======================================
 
@@ -821,7 +798,7 @@ Some Basic Terms
 
 It helps to understand some basic fundamental terms when learning the
 Yocto Project. Although a list of terms exists in the ":doc:`Yocto Project
-Terms <../ref-manual/ref-terms>`" section of the Yocto Project
+Terms </ref-manual/terms>`" section of the Yocto Project
 Reference Manual, this section provides the definitions of some terms
 helpful for getting started:
 
@@ -835,7 +812,7 @@ helpful for getting started:
    application developers. This eSDK allows developers to incorporate
    their library and programming changes back into the image to make
    their code available to other application developers. For information
-   on the eSDK, see the :doc:`../sdk-manual/sdk-manual` manual.
+   on the eSDK, see the :doc:`/sdk-manual/index` manual.
 
 -  *Layer:* A collection of related recipes. Layers allow you to
    consolidate related metadata to customize your build. Layers also
@@ -847,7 +824,7 @@ helpful for getting started:
    Project.
 
    For more detailed information on layers, see the 
-   ":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`"
+   ":ref:`dev-manual/common-tasks:understanding and creating layers`"
    section in the Yocto Project Development Tasks Manual. For a
    discussion specifically on BSP Layers, see the 
    ":ref:`bsp-guide/bsp:bsp layers`" section in the Yocto
@@ -892,8 +869,7 @@ helpful for getting started:
    set of recipes.
 
    You can see the Metadata in the ``meta`` directory of the Yocto
-   Project `Source
-   Repositories <http://git.yoctoproject.org/cgit/cgit.cgi>`__.
+   Project :yocto_git:`Source Repositories <>`.
 
 -  *Packages:* In the context of the Yocto Project, this term refers to
    a recipe's packaged output produced by BitBake (i.e. a "baked
@@ -903,7 +879,7 @@ helpful for getting started:
 
    It is worth noting that the term "package" can, in general, have
    subtle meanings. For example, the packages referred to in 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 are compiled binaries
    that, when installed, add functionality to your Linux distribution.