diff --git a/poky/documentation/ref-manual/faq.rst b/poky/documentation/ref-manual/faq.rst
index 6985282..7a16140 100644
--- a/poky/documentation/ref-manual/faq.rst
+++ b/poky/documentation/ref-manual/faq.rst
@@ -4,7 +4,7 @@
 FAQ
 ***
 
-**Q:** How does Poky differ from `OpenEmbedded <http://www.openembedded.org/>`__?
+**Q:** How does Poky differ from :oe_home:`OpenEmbedded <>`?
 
 **A:** The term ``Poky`` refers to the specific reference build
 system that the Yocto Project provides. Poky is based on
@@ -21,9 +21,9 @@
 
 **A:** You can get the required tools on your host development system a
 couple different ways (i.e. building a tarball or downloading a
-tarball). See the "`Required Git, tar, Python and gcc
-Versions <#required-git-tar-python-and-gcc-versions>`__" section for
-steps on how to update your build tools.
+tarball). See the
+":ref:`ref-manual/ref-system-requirements:required git, tar, python and gcc versions`"
+section for steps on how to update your build tools.
 
 **Q:** How can you claim Poky / OpenEmbedded-Core is stable?
 
@@ -370,7 +370,7 @@
 **A:** Yes - you can easily do this. When you use BitBake to build an
 image, all the build output goes into the directory created when you run
 the build environment setup script (i.e.
-````` <#structure-core-script>`__). By default, this :term:`Build Directory`
+:ref:`structure-core-script`). By default, this :term:`Build Directory`
 is named ``build`` but can be named
 anything you want.
 
@@ -414,7 +414,14 @@
 file system. Consequently, the build system uses paths within the Build
 Directory for ``DESTDIR``, ``bindir`` and related variables. To better
 understand this, consider the following two paths where the first is
-relatively normal and the second is not: ::
+relatively normal and the second is not:
+
+.. note::
+
+   Due to these lengthy examples, the paths are artificially broken
+   across lines for readability.
+
+::
 
    /home/maxtothemax/poky-bootchart2/build/tmp/work/i586-poky-linux/zlib/
       1.2.8-r0/sysroot-destdir/usr/bin
@@ -423,11 +430,6 @@
       zlib-native/1.2.8-r0/sysroot-destdir/home/maxtothemax/poky-bootchart2/
       build/tmp/sysroots/x86_64-linux/usr/bin
 
-.. note::
-
-   Due to these lengthy examples, the paths are artificially broken
-   across lines for readability.
-
 Even if the paths look unusual,
 they both are correct - the first for a target and the second for a
 native recipe. These paths are a consequence of the ``DESTDIR``
diff --git a/poky/documentation/ref-manual/migration-1.3.rst b/poky/documentation/ref-manual/migration-1.3.rst
index 5793f9b..5f97585 100644
--- a/poky/documentation/ref-manual/migration-1.3.rst
+++ b/poky/documentation/ref-manual/migration-1.3.rst
@@ -121,11 +121,11 @@
 IMAGE_FEATURES
 ~~~~~~~~~~~~~~
 
-Image recipes that previously included "apps-console-core" in
-:term:`IMAGE_FEATURES` should now include "splash"
+Image recipes that previously included ``apps-console-core`` in
+:term:`IMAGE_FEATURES` should now include ``splash``
 instead to enable the boot-up splash screen. Retaining
-"apps-console-core" will still include the splash screen but generates a
-warning. The "apps-x11-core" and "apps-x11-games" ``IMAGE_FEATURES``
+``apps-console-core`` will still include the splash screen but generates a
+warning. The ``apps-x11-core`` and ``apps-x11-games`` ``IMAGE_FEATURES``
 features have been removed.
 
 .. _migration-1.3-removed-recipes:
@@ -173,7 +173,7 @@
 ``meta-gnome``. For the remainder, you can now find them in the
 ``meta-extras`` repository, which is in the
 :yocto_git:`Source Repositories <>` at
-http://git.yoctoproject.org/cgit/cgit.cgi/meta-extras/.
+:yocto_git:`/cgit/cgit.cgi/meta-extras/`.
 
 .. _1.3-linux-kernel-naming:
 
diff --git a/poky/documentation/ref-manual/migration-1.4.rst b/poky/documentation/ref-manual/migration-1.4.rst
index a658bdf..daaea0f 100644
--- a/poky/documentation/ref-manual/migration-1.4.rst
+++ b/poky/documentation/ref-manual/migration-1.4.rst
@@ -12,7 +12,7 @@
 Differences include the following:
 
 -  *Comment Continuation:* If a comment ends with a line continuation
-   (\) character, then the next line must also be a comment. Any
+   (\\) character, then the next line must also be a comment. Any
    instance where this is not the case, now triggers a warning. You must
    either remove the continuation character, or be sure the next line is
    a comment.
@@ -61,7 +61,7 @@
    the :term:`MACHINEOVERRIDES` or
    :term:`DISTROOVERRIDES` variables, as
    appropriate. For more related changes, see the
-   "`Variables <#migration-1.4-variables>`__" section.
+   ":ref:`ref-manual/migration-1.4:variables`" section.
 
 .. _migration-1.4-proxies-and-fetching-source:
 
@@ -124,8 +124,8 @@
    :term:`SRC_URI`. If you have a recipe that relied upon
    these directories, which would be unusual, then you will need to add
    the appropriate paths within the recipe or, alternatively, rearrange
-   the files. The most common locations are still covered by ``${BP}``,
-   ``${BPN}``, and "files", which all remain in the default value of
+   the files. The most common locations are still covered by ``${``\ :term:`BP`\ ``}``,
+   ``${``\ :term:`BPN`\ ``}``, and "files", which all remain in the default value of
    :term:`FILESPATH`.
 
 .. _migration-target-package-management-with-rpm:
diff --git a/poky/documentation/ref-manual/migration-1.5.rst b/poky/documentation/ref-manual/migration-1.5.rst
index fa6ff92..fc7afac 100644
--- a/poky/documentation/ref-manual/migration-1.5.rst
+++ b/poky/documentation/ref-manual/migration-1.5.rst
@@ -25,8 +25,8 @@
 provide packages for these, you can install and use the Buildtools
 tarball, which provides an SDK-like environment containing them.
 
-For more information on this requirement, see the "`Required Git, tar,
-Python and gcc Versions <#required-git-tar-python-and-gcc-versions>`__"
+For more information on this requirement, see the
+":ref:`ref-manual/ref-system-requirements:required git, tar, python and gcc versions`"
 section.
 
 .. _migration-1.5-atom-pc-bsp:
@@ -41,9 +41,8 @@
 
 .. note::
 
-   Additionally, a
-   genericx86-64
-   BSP has been added for 64-bit Atom systems.
+   Additionally, a ``genericx86-64`` BSP has been added for 64-bit Atom
+   systems.
 
 .. _migration-1.5-bitbake:
 
@@ -96,7 +95,7 @@
    this file within :ref:`ref-tasks-install` if "make
    install" is installing it.
 
--  If you are using the buildhistory class, the check for the package
+-  If you are using the ``buildhistory`` class, the check for the package
    version going backwards is now controlled using a standard QA check.
    Thus, if you have customized your ``ERROR_QA`` or ``WARN_QA`` values
    and still wish to have this check performed, you should add
@@ -299,7 +298,7 @@
 -  ``libtool-nativesdk`` has been renamed to ``nativesdk-libtool``.
 
 -  ``tinylogin`` has been removed. It has been replaced by a suid
-   portion of Busybox. See the "`BusyBox <#migration-1.5-busybox>`__"
+   portion of Busybox. See the "`BusyBox <#busybox>`__"
    section for more information.
 
 -  ``external-python-tarball`` has been renamed to
@@ -345,8 +344,7 @@
 -  ``libpam``: Deny all services for the ``OTHER`` entries.
 
 -  ``image.bbclass``: Move ``runtime_mapping_rename`` to avoid conflict
-   with ``multilib``. See
-   `YOCTO #4993 <https://bugzilla.yoctoproject.org/show_bug.cgi?id=4993>`_
+   with ``multilib``. See :yocto_bugs:`YOCTO #4993 </show_bug.cgi?id=4993>`
    in Bugzilla for more information.
 
 -  ``linux-dtb``: Use kernel build system to generate the ``dtb`` files.
diff --git a/poky/documentation/ref-manual/migration-1.6.rst b/poky/documentation/ref-manual/migration-1.6.rst
index b55be46..a6c4c8a 100644
--- a/poky/documentation/ref-manual/migration-1.6.rst
+++ b/poky/documentation/ref-manual/migration-1.6.rst
@@ -53,9 +53,12 @@
 When fetching source from a Git repository using
 :term:`SRC_URI`, BitBake will now validate the
 :term:`SRCREV` value against the branch. You can specify
-the branch using the following form: SRC_URI =
-"git://server.name/repository;branch=branchname" If you do not specify a
-branch, BitBake looks in the default "master" branch.
+the branch using the following form:
+::
+
+      SRC_URI = "git://server.name/repository;branch=branchname"
+
+If you do not specify a branch, BitBake looks in the default "master" branch.
 
 Alternatively, if you need to bypass this check (e.g. if you are
 fetching a revision corresponding to a tag that is not on any branch),
@@ -123,8 +126,7 @@
 --------------------
 
 The following variables have changed. For information on the
-OpenEmbedded build system variables, see the "`Variables
-Glossary <#ref-variables-glos>`__" Chapter.
+OpenEmbedded build system variables, see the ":doc:`ref-variables`" Chapter.
 
 .. _migration-1.6-variable-changes-TMPDIR:
 
@@ -254,11 +256,8 @@
 
 .. note::
 
-   The default
-   local.conf
-   contains these statements. Consequently, if you are building a
-   headless system and using a default
-   local.conf
+   The default ``local.conf`` contains these statements. Consequently, if you
+   are building a headless system and using a default ``local.conf``
    file, you will need comment these two lines out.
 
 .. _migration-1.6-core-image-basic:
@@ -412,6 +411,6 @@
 ``routerstationpro`` machines are still available in a new
 ``meta-yocto-bsp-old`` layer in the
 :yocto_git:`Source Repositories <>` at
-http://git.yoctoproject.org/cgit/cgit.cgi/meta-yocto-bsp-old/.
+:yocto_git:`/cgit/cgit.cgi/meta-yocto-bsp-old/`.
 
 
diff --git a/poky/documentation/ref-manual/migration-1.7.rst b/poky/documentation/ref-manual/migration-1.7.rst
index 82fd37d..5a5151e 100644
--- a/poky/documentation/ref-manual/migration-1.7.rst
+++ b/poky/documentation/ref-manual/migration-1.7.rst
@@ -31,9 +31,9 @@
 build host is now 1.7.8 because the ``--list`` option is now required by
 BitBake's Git fetcher. As always, if your host distribution does not
 provide a version of Git that meets this requirement, you can use the
-``buildtools-tarball`` that does. See the "`Required Git, tar, Python
-and gcc Versions <#required-git-tar-python-and-gcc-versions>`__" section
-for more information.
+``buildtools-tarball`` that does. See the
+":ref:`ref-manual/ref-system-requirements:required git, tar, python and gcc versions`"
+section for more information.
 
 .. _migration-1.7-autotools-class-changes:
 
@@ -157,7 +157,7 @@
    added in order to verify that file dependencies are satisfied (e.g.
    package contains a script requiring ``/bin/bash``) and build-time
    dependencies are declared, respectively. For more information, please
-   see the "`QA Error and Warning Messages <#ref-qa-checks>`__" chapter.
+   see the ":doc:`ref-qa-checks`" chapter.
 
 -  Package QA checks are now performed during a new
    :ref:`ref-tasks-package_qa` task rather than being
@@ -202,9 +202,7 @@
    for version 3.17 has been added.
 
 -  ``eglibc`` has been removed in favor of ``glibc``. See the
-   "```eglibc 2.19`` Replaced with
-   ``glibc 2.20`` <#migration-1.7-glibc-replaces-eglibc>`__" section for
-   more information.
+   ":ref:`migration-1.7-glibc-replaces-eglibc`" section for more information.
 
 .. _migration-1.7-miscellaneous-changes:
 
diff --git a/poky/documentation/ref-manual/migration-2.0.rst b/poky/documentation/ref-manual/migration-2.0.rst
index 570486b..4eea948 100644
--- a/poky/documentation/ref-manual/migration-2.0.rst
+++ b/poky/documentation/ref-manual/migration-2.0.rst
@@ -96,8 +96,8 @@
 
       $ bitbake -e
 
--  ``d.delVar('``\ VARNAME\ ``')`` and
-   ``d.setVar('``\ VARNAME\ ``', None)`` result in the variable and all
+-  ``d.delVar('VARNAME')`` and
+   ``d.setVar('VARNAME', None)`` result in the variable and all
    of its overrides being cleared out. Before the change, only the
    non-overridden values were cleared.
 
diff --git a/poky/documentation/ref-manual/migration-2.1.rst b/poky/documentation/ref-manual/migration-2.1.rst
index a1fd3ea..0220221 100644
--- a/poky/documentation/ref-manual/migration-2.1.rst
+++ b/poky/documentation/ref-manual/migration-2.1.rst
@@ -9,7 +9,7 @@
 Variable Expansion in Python Functions
 --------------------------------------
 
-Variable expressions, such as ``${``\ VARNAME\ ``}`` no longer expand
+Variable expressions, such as ``${VARNAME}`` no longer expand
 automatically within Python functions. Suppressing expansion was done to
 allow Python functions to construct shell scripts or other code for
 situations in which you do not want such expressions expanded. For any
@@ -125,7 +125,7 @@
 Previously, for image recipes the :ref:`ref-tasks-rootfs`
 task assembled the filesystem and then from that filesystem generated
 images. With this Yocto Project release, image generation is split into
-separate ```do_image_*`` <#ref-tasks-image>`__ tasks for clarity both in
+separate :ref:`ref-tasks-image` tasks for clarity both in
 operation and in the code.
 
 For most cases, this change does not present any problems. However, if
@@ -133,7 +133,7 @@
 or that mention ``do_rootfs``, you might need to update those changes.
 In particular, if you had added any tasks after ``do_rootfs``, you
 should make edits so that those tasks are after the
-```do_image_complete`` <#ref-tasks-image-complete>`__ task rather than
+:ref:`ref-tasks-image-complete` task rather than
 after ``do_rootfs`` so that the your added tasks run at the correct
 time.
 
@@ -180,7 +180,7 @@
 -  ``python-pygtk``: Recipe became obsolete.
 
 -  ``adt-installer``: Recipe became obsolete. See the "`ADT
-   Removed <#migration-2.1-adt-removed>`__" section for more
+   Removed <#adt-removed>`__" section for more
    information.
 
 .. _migration-2.1-class-changes:
@@ -287,7 +287,9 @@
    option specified on the configure command line either because it is
    not a supported option for the configure script or because static
    libraries are needed should set the following variable:
-   DISABLE_STATIC = ""
+   ::
+
+      DISABLE_STATIC = ""
 
 -  The separate ``poky-tiny`` distribution now uses the musl C library
    instead of a heavily pared down ``glibc``. Using musl results in a
@@ -357,10 +359,9 @@
 
 -  The minimum Git version has been increased to 1.8.3.1. If your host
    distribution does not provide a sufficiently recent version, you can
-   install the buildtools, which will provide it. See the "`Required
-   Git, tar, Python and gcc
-   Versions <#required-git-tar-python-and-gcc-versions>`__" section for
-   more information on the buildtools tarball.
+   install the buildtools, which will provide it. See the
+   :ref:`ref-manual/ref-system-requirements:required git, tar, python and gcc versions`
+   section for more information on the buildtools tarball.
 
 -  The buggy and incomplete support for the RPM version 4 package
    manager has been removed. The well-tested and maintained support for
@@ -376,8 +377,9 @@
       base-passwd
       shadow
       update-alternatives
+      run-postinsts
 
-   run-postinsts With the Yocto Project 2.1 release, these packages are
+   With the Yocto Project 2.1 release, these packages are
    only removed if "read-only-rootfs" is in ``IMAGE_FEATURES``, since
    they might still be needed for a read-write image even in the absence
    of a package manager (e.g. if users need to be added, modified, or
diff --git a/poky/documentation/ref-manual/migration-2.2.rst b/poky/documentation/ref-manual/migration-2.2.rst
index 59d0eee..8afa8ff 100644
--- a/poky/documentation/ref-manual/migration-2.2.rst
+++ b/poky/documentation/ref-manual/migration-2.2.rst
@@ -16,8 +16,7 @@
 
 .. note::
 
-   For x86 and x86_64, you can reset
-   OLDEST_KERNEL
+   For x86 and x86_64, you can reset :term:`OLDEST_KERNEL`
    to anything down to 2.6.32 if desired.
 
 .. _migration-2.2-staging-directories-in-sysroot-simplified:
@@ -79,7 +78,9 @@
 
   - the syntax for octal values changed
 
-  - the ``iter*()`` functions changed name \* iterators now return views, not lists
+  - the ``iter*()`` functions changed name
+
+  - iterators now return views, not lists
 
   - changed names for Python modules
 
@@ -224,9 +225,7 @@
 
 .. note::
 
-   For command-line syntax, use
-   runqemu help
-   .
+   For command-line syntax, use ``runqemu help``.
 
 ::
 
@@ -369,7 +368,7 @@
 -  ``sato-icon-theme``: Became obsolete.
 
 -  ``swabber-native``: Swabber has been removed. See the `entry on
-   Swabber <#migration-2.2-swabber-has-been-removed>`__.
+   Swabber <#swabber-has-been-removed>`__.
 
 -  ``tslib``: No longer needed and has been moved to ``meta-oe``.
 
@@ -395,7 +394,7 @@
 -  ``sip``: Mostly unused.
 
 -  ``swabber``: See the `entry on
-   Swabber <#migration-2.2-swabber-has-been-removed>`__.
+   Swabber <#swabber-has-been-removed>`__.
 
 .. _migration-2.2-minor-packaging-changes:
 
diff --git a/poky/documentation/ref-manual/migration-2.3.rst b/poky/documentation/ref-manual/migration-2.3.rst
index 7f34f0c..5bf3e70 100644
--- a/poky/documentation/ref-manual/migration-2.3.rst
+++ b/poky/documentation/ref-manual/migration-2.3.rst
@@ -76,9 +76,7 @@
 .. note::
 
    You can find more information on how recipe-specific sysroots work in
-   the "
-   staging.bbclass
-   " section.
+   the ":ref:`ref-classes-staging`" section.
 
 .. _migration-2.3-path-variable:
 
@@ -104,9 +102,8 @@
 .. note::
 
    PATH
-   is not sanitized in the same way within
-   devshell
-   . If it were, you would have difficulty running host tools for
+   is not sanitized in the same way within ``devshell``.
+   If it were, you would have difficulty running host tools for
    development and debugging within the shell.
 
 .. _migration-2.3-scripts:
@@ -123,7 +120,7 @@
       $ . oe-find-native-sysroot recipe
 
    You must now supply a recipe for recipe
-   as part of the command. Prior to the Yocto Project &DISTRO; release, it
+   as part of the command. Prior to the Yocto Project 2.3 release, it
    was not necessary to provide the script with the command.
 
 -  ``oe-run-native``: The usage for the ``oe-run-native`` script has
@@ -134,7 +131,7 @@
 
    You must
    supply the name of the native recipe and the tool you want to run as
-   part of the command. Prior to the Yocto Project DISTRO release, it
+   part of the command. Prior to the Yocto Project 2.3 release, it
    was not necessary to provide the native recipe with the command.
 
 -  ``cleanup-workdir``: The ``cleanup-workdir`` script has been
@@ -240,10 +237,8 @@
 
 .. note::
 
-   You can find
-   meta-gplv2
-   layer in the OpenEmbedded layer index at
-   .
+   You can ``find meta-gplv2`` layer in the OpenEmbedded layer index at
+   https://layers.openembedded.org/layerindex/branch/master/layer/meta-gplv2/.
 
 These relocated GPLv2 recipes do not receive the same level of
 maintenance as other core recipes. The recipes do not get security fixes
@@ -316,8 +311,7 @@
 
 -  Signing of remote package feeds using ``PACKAGE_FEED_SIGN`` is not
    currently supported. This issue will be fully addressed in a future
-   Yocto Project release. See `defect
-   11209 <https://bugzilla.yoctoproject.org/show_bug.cgi?id=11209>`__
+   Yocto Project release. See :yocto_bugs:`defect 11209 </show_bug.cgi?id=11209>`
    for more information on a solution to package feed signing with RPM
    in the Yocto Project 2.3 release.
 
@@ -329,8 +323,7 @@
    .. note::
 
       For further details on this change, see the
-      commit message
-      .
+      :yocto_git:`commit message </cgit/cgit.cgi/poky/commit/?id=f4d4f99cfbc2396e49c1613a7d237b9e57f06f81>`.
 
 .. _migration-2.3-removed-recipes:
 
@@ -372,9 +365,9 @@
 
 .. note::
 
-   For more information on Wic, see the "
-   Creating Partitioned Images Using Wic
-   " section in the Yocto Project Development Tasks Manual.
+   For more information on Wic, see the
+   ":ref:`dev-manual/dev-manual-common-tasks:creating partitioned images using wic`"
+   section in the Yocto Project Development Tasks Manual.
 
 -  *Default Output Directory Changed:* Wic's default output directory is
    now the current directory by default instead of the unusual
@@ -410,8 +403,8 @@
    warning, you need to address missing runtime dependencies.
 
    For additional information, see the
-   :ref:`insane <ref-classes-insane>` class and the "`Errors and
-   Warnings <#qa-errors-and-warnings>`__" section.
+   :ref:`insane <ref-classes-insane>` class and the
+   ":ref:`ref-manual/ref-qa-checks:errors and warnings`" section.
 
 .. _migration-2.3-miscellaneous-changes:
 
@@ -488,7 +481,7 @@
    following:
    ::
 
-      KERNEL_MODULE_PACKAGE_SUFFIX to ""
+      KERNEL_MODULE_PACKAGE_SUFFIX = ""
 
 -  Removal of ``libtool`` ``*.la`` files is now enabled by default. The
    ``*.la`` files are not actually needed on Linux and relocating them
diff --git a/poky/documentation/ref-manual/migration-2.5.rst b/poky/documentation/ref-manual/migration-2.5.rst
index a2adc17..1aeddc8 100644
--- a/poky/documentation/ref-manual/migration-2.5.rst
+++ b/poky/documentation/ref-manual/migration-2.5.rst
@@ -179,8 +179,8 @@
 
 The earlier build-time provides behavior was a quirk of the
 way the Python manifest file was created. For more information on this
-change please see `this
-commit <http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=8d94b9db221d1def42f091b991903faa2d1651ce>`__.
+change please see :yocto_git:`this commit
+</cgit/cgit.cgi/poky/commit/?id=8d94b9db221d1def42f091b991903faa2d1651ce>`.
 
 .. _migration-2.5-miscellaneous-changes:
 
diff --git a/poky/documentation/ref-manual/migration-2.6.rst b/poky/documentation/ref-manual/migration-2.6.rst
index f16aaaa..2f0da48 100644
--- a/poky/documentation/ref-manual/migration-2.6.rst
+++ b/poky/documentation/ref-manual/migration-2.6.rst
@@ -110,7 +110,7 @@
 newer ``xorgproto`` recipe instead.
 
 For names of recipes removed because of this repository change, see the
-`Removed Recipes <#migration-2.6-removed-recipes>`__ section.
+`Removed Recipes <#removed-recipes>`__ section.
 
 .. _migration-2.6-distutils-distutils3-fetching-dependencies:
 
@@ -128,18 +128,9 @@
 .. note::
 
    This change affects classes beyond just the two mentioned (i.e.
-   distutils
-   and
-   distutils3
-   ). Any recipe that inherits
-   distutils\*
-   classes are affected. For example, the
-   setuptools
-   and
-   setuptools3
-   recipes are affected since they inherit the
-   distutils\*
-   classes.
+   ``distutils`` and ``distutils3``). Any recipe that inherits ``distutils*``
+   classes are affected. For example, the ``setuptools`` and ``setuptools3``
+   recipes are affected since they inherit the ``distutils*`` classes.
 
 Fetching these types of dependencies that are not provided in the
 sysroot negatively affects the ability to reproduce builds. This type of
@@ -178,13 +169,13 @@
 -  Several variables have changed names for consistency:
    ::
 
-      Old Variable                  Name New Variable Name
+      Old Variable Name             New Variable Name
       ========================================================
-      KERNEL_IMAGE_BASE_NAME        :term:`KERNEL_IMAGE_NAME`
-      KERNEL_IMAGE_SYMLINK_NAME     :term:`KERNEL_IMAGE_LINK_NAME`
-      MODULE_TARBALL_BASE_NAME      :term:`MODULE_TARBALL_NAME`
-      MODULE_TARBALL_SYMLINK_NAME   :term:`MODULE_TARBALL_LINK_NAME`
-      INITRAMFS_BASE_NAME           :term:`INITRAMFS_NAME`
+      KERNEL_IMAGE_BASE_NAME        KERNEL_IMAGE_NAME
+      KERNEL_IMAGE_SYMLINK_NAME     KERNEL_IMAGE_LINK_NAME
+      MODULE_TARBALL_BASE_NAME      MODULE_TARBALL_NAME
+      MODULE_TARBALL_SYMLINK_NAME   MODULE_TARBALL_LINK_NAME
+      INITRAMFS_BASE_NAME           INITRAMFS_NAME
 
 -  The ``MODULE_IMAGE_BASE_NAME`` variable has been removed. The module
    tarball name is now controlled directly with the
@@ -233,11 +224,9 @@
 
 .. note::
 
-   The only difference in usage is that
-   SERIAL_CONSOLES
+   The only difference in usage is that ``SERIAL_CONSOLES``
    expects entries to be separated using semicolons as compared to
-   SERIAL_CONSOLE
-   , which expects spaces.
+   ``SERIAL_CONSOLE``, which expects spaces.
 
 .. _migration-2.6-poky-sets-unknown-configure-option-to-qa-error:
 
@@ -263,9 +252,7 @@
 
    .. note::
 
-      The
-      virtclass-multilib-
-      overrides for multilib are still valid.
+      The ``virtclass-multilib-`` overrides for multilib are still valid.
 
 -  The ``forcevariable`` Override Now Has a Higher Priority Than
    ``libc`` Overrides: The ``forcevariable`` override is documented to
@@ -447,14 +434,8 @@
 
    .. note::
 
-      genericx86
-      and
-      genericx86-64
-      retain
-      kernel-modules
-      as part of the
-      RRECOMMENDS
-      variable setting.
+      ``genericx86`` and ``genericx86-64`` retain ``kernel-modules`` as part of
+      the ``RRECOMMENDS`` variable setting.
 
 -  The ``LGPLv2_WHITELIST_GPL-3.0`` variable has been removed. If you
    are setting this variable in your configuration, set or append it to
diff --git a/poky/documentation/ref-manual/migration-3.0.rst b/poky/documentation/ref-manual/migration-3.0.rst
index e1305df..047b755 100644
--- a/poky/documentation/ref-manual/migration-3.0.rst
+++ b/poky/documentation/ref-manual/migration-3.0.rst
@@ -197,8 +197,7 @@
 -  The arguments passed to functions used with
    :term:`bitbake:BB_HASHCHECK_FUNCTION`
    have changed. If you are using your own custom hash check function,
-   see
-   http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=40a5e193c4ba45c928fccd899415ea56b5417725
+   see :yocto_git:`/cgit/cgit.cgi/poky/commit/?id=40a5e193c4ba45c928fccd899415ea56b5417725`
    for details.
 
 -  Task specifications in ``BB_TASKDEPDATA`` and class implementations
diff --git a/poky/documentation/ref-manual/migration-3.1.rst b/poky/documentation/ref-manual/migration-3.1.rst
index 92c8c77..4fcd249 100644
--- a/poky/documentation/ref-manual/migration-3.1.rst
+++ b/poky/documentation/ref-manual/migration-3.1.rst
@@ -181,7 +181,7 @@
 
 An example of the new scheme: ::
 
-   SRC_URI = "npm://registry.npmjs.org;package=array-flatten;version=1.1.1 \\
+   SRC_URI = "npm://registry.npmjs.org;package=array-flatten;version=1.1.1 \
               npmsw://${THISDIR}/npm-shrinkwrap.json"
 
 Another example where the sources are fetched from git rather than an npm repository: ::
diff --git a/poky/documentation/ref-manual/ref-classes.rst b/poky/documentation/ref-manual/ref-classes.rst
index 756df2a..028729f 100644
--- a/poky/documentation/ref-manual/ref-classes.rst
+++ b/poky/documentation/ref-manual/ref-classes.rst
@@ -47,7 +47,7 @@
    even if the recipes do not produce architecture-specific output.
 
    Configuring such recipes for all architectures causes the
-   ```do_package_write_*`` tasks to
+   ``do_package_write_*`` tasks to
    have different signatures for the machines with different tunings.
    Additionally, unnecessary rebuilds occur every time an image for a
    different ``MACHINE`` is built even when the recipe never changes.
@@ -164,24 +164,18 @@
 
    For RPMs and other packages that do not contain a subdirectory, you
    should specify an appropriate fetcher parameter to point to the
-   subdirectory. For example, if BitBake is using the Git fetcher (
-   git://
-   ), the "subpath" parameter limits the checkout to a specific subpath
-   of the tree. Here is an example where
-   ${BP}
-   is used so that the files are extracted into the subdirectory
-   expected by the default value of
-   S
-   :
+   subdirectory. For example, if BitBake is using the Git fetcher (``git://``),
+   the "subpath" parameter limits the checkout to a specific subpath
+   of the tree. Here is an example where ``${BP}`` is used so that the files
+   are extracted into the subdirectory expected by the default value of
+   ``S``:
    ::
 
            SRC_URI = "git://example.com/downloads/somepackage.rpm;subpath=${BP}"
 
 
-   See the "
-   Fetchers
-   " section in the BitBake User Manual for more information on
-   supported BitBake Fetchers.
+   See the ":ref:`bitbake-user-manual/bitbake-user-manual-fetching:fetchers`" section in the BitBake User Manual for
+   more information on supported BitBake Fetchers.
 
 .. _ref-classes-binconfig:
 
@@ -736,11 +730,8 @@
 .. note::
 
    This functionality is backfilled by default and, if not applicable,
-   should be disabled through
-   DISTRO_FEATURES_BACKFILL_CONSIDERED
-   or
-   MACHINE_FEATURES_BACKFILL_CONSIDERED
-   , respectively.
+   should be disabled through ``DISTRO_FEATURES_BACKFILL_CONSIDERED`` or
+   ``MACHINE_FEATURES_BACKFILL_CONSIDERED``, respectively.
 
 .. _ref-classes-grub-efi:
 
@@ -969,9 +960,8 @@
 .. note::
 
    To build a VMware VMDK image, you need to add "wic.vmdk" to
-   IMAGE_FSTYPES
-   . This would also be similar for Virtual Box Virtual Disk Image
-   ("vdi") and QEMU Copy On Write Version 2 ("qcow2") images.
+   ``IMAGE_FSTYPES``. This would also be similar for Virtual Box Virtual Disk
+   Image ("vdi") and QEMU Copy On Write Version 2 ("qcow2") images.
 
 .. _ref-classes-image-live:
 
@@ -1032,9 +1022,8 @@
 either raise a warning or an error message. Typically, failures for new
 tests generate a warning. Subsequent failures for the same test would
 then generate an error message once the metadata is in a known and good
-condition. See the "`QA Error and Warning Messages <#ref-qa-checks>`__"
-Chapter for a list of all the warning and error messages you might
-encounter using a default configuration.
+condition. See the ":doc:`ref-qa-checks`" Chapter for a list of all the warning
+and error messages you might encounter using a default configuration.
 
 Use the :term:`WARN_QA` and
 :term:`ERROR_QA` variables to control the behavior of
@@ -1275,9 +1264,9 @@
 
 -  ``textrel:`` Checks for ELF binaries that contain relocations in
    their ``.text`` sections, which can result in a performance impact at
-   runtime. See the explanation for the
-   ```ELF binary`` <#qa-issue-textrel>`__ message for more information
-   regarding runtime performance issues.
+   runtime. See the explanation for the ``ELF binary`` message in
+   ":doc:`ref-qa-checks`" for more information regarding runtime performance
+   issues.
 
 -  ``unlisted-pkg-lics:`` Checks that all declared licenses applying
    for a package are also declared on the recipe level (i.e. any license
@@ -1399,7 +1388,7 @@
 ``kernel-fitimage`` and the device tree is optional.
 The address where the device tree is to be loaded by U-boot is
 specified by :term:`UBOOT_DTBO_LOADADDRESS` for device tree overlays
-and by `:term:`UBOOT_DTB_LOADADDRESS` for device tree binaries.
+and by :term:`UBOOT_DTB_LOADADDRESS` for device tree binaries.
 
 Only a single RAM disk can be added to the FIT image created by
 ``kernel-fitimage`` and the RAM disk in FIT is optional.
@@ -1629,8 +1618,8 @@
 ==================
 
 The ``native`` class provides common functionality for recipes that
-build tools to run on the `build host <#hardware-build-system-term>`__
-(i.e. tools that use the compiler or other tools from the build host).
+build tools to run on the :term:`Build Host` (i.e. tools that use the compiler
+or other tools from the build host).
 
 You can create a recipe that builds tools that run natively on the host
 a couple different ways:
@@ -1728,8 +1717,7 @@
 
 .. note::
 
-   Currently, recipes inheriting this class must use the
-   npm://
+   Currently, recipes inheriting this class must use the ``npm://``
    fetcher to have dependencies fetched and packaged automatically.
 
 For information on how to create NPM packages, see the
@@ -1833,9 +1821,9 @@
 You can find additional information on the effects of the package class
 at these two Yocto Project mailing list links:
 
--  https://lists.yoctoproject.org/pipermail/poky/2011-May/006362.html
+-  :yocto_lists:`/pipermail/poky/2011-May/006362.html`
 
--  https://lists.yoctoproject.org/pipermail/poky/2011-May/006363.html
+-  :yocto_lists:`/pipermail/poky/2011-May/006363.html`
 
 .. _ref-classes-package_deb:
 
@@ -1894,16 +1882,8 @@
 
 .. note::
 
-   You cannot specify the
-   package_tar
-   class first using the
-   PACKAGE_CLASSES
-   variable. You must use
-   .deb
-   ,
-   .ipk
-   , or
-   .rpm
+   You cannot specify the ``package_tar`` class first using the
+   ``PACKAGE_CLASSES`` variable. You must use ``.deb``, ``.ipk``, or ``.rpm``
    file formats for your image or SDK.
 
 .. _ref-classes-packagedata:
@@ -2068,9 +2048,7 @@
 .. note::
 
    This class is not intended to be used directly. Rather, it is enabled
-   when using "
-   bitbake-prserv-tool export
-   ".
+   when using "``bitbake-prserv-tool export``".
 
 .. _ref-classes-primport:
 
@@ -2083,9 +2061,7 @@
 .. note::
 
    This class is not intended to be used directly. Rather, it is enabled
-   when using "
-   bitbake-prserv-tool import
-   ".
+   when using "``bitbake-prserv-tool import``".
 
 .. _ref-classes-prserv:
 
@@ -2204,9 +2180,7 @@
 
 .. note::
 
-   The
-   remove-libtool
-   class is not enabled by default.
+   The ``remove-libtool`` class is not enabled by default.
 
 .. _ref-classes-report-error:
 
@@ -2283,7 +2257,7 @@
 :term:`PACKAGE_CLASSES` variable.
 
 For information on how root filesystem images are created, see the
-:ref:`image-generation-dev-environment`"
+":ref:`image-generation-dev-environment`"
 section in the Yocto Project Overview and Concepts Manual.
 
 .. _ref-classes-sanity:
@@ -2380,19 +2354,6 @@
 The class also provides variables like ``SITEINFO_ENDIANNESS`` and
 ``SITEINFO_BITS`` that can be used elsewhere in the metadata.
 
-.. _ref-classes-spdx:
-
-``spdx.bbclass``
-================
-
-The ``spdx`` class integrates real-time license scanning, generation of
-SPDX standard output, and verification of license information during the
-build.
-
-.. note::
-
-   This class is currently at the prototype stage in the 1.6 release.
-
 .. _ref-classes-sstate:
 
 ``sstate.bbclass``
@@ -2442,13 +2403,12 @@
    .. note::
 
       Additionally, a recipe can customize the files further by
-      declaring a processing function in the
-      SYSROOT_PREPROCESS_FUNCS
+      declaring a processing function in the ``SYSROOT_PREPROCESS_FUNCS``
       variable.
 
    A shared state (sstate) object is built from these files and the
    files are placed into a subdirectory of
-   ```tmp/sysroots-components/`` <#structure-build-tmp-sysroots-components>`__.
+   :ref:`structure-build-tmp-sysroots-components`.
    The files are scanned for hardcoded paths to the original
    installation location. If the location is found in text files, the
    hardcoded locations are replaced by tokens and a list of the files
@@ -2597,13 +2557,8 @@
 
 .. note::
 
-   The
-   systemd-boot
-   class is a result from merging the
-   gummiboot
-   class used in previous Yocto Project releases with the
-   systemd
-   project.
+   The ``systemd-boot`` class is a result from merging the ``gummiboot`` class
+   used in previous Yocto Project releases with the ``systemd`` project.
 
 Set the :term:`EFI_PROVIDER` variable to
 "systemd-boot" to use this class. Doing so creates a standalone EFI
@@ -2647,13 +2602,9 @@
 
 .. note::
 
-   Best practices include using
-   IMAGE_CLASSES
-   rather than
-   INHERIT
-   to inherit the
-   testimage
-   class for automated image testing.
+   Best practices include using :term:`IMAGE_CLASSES` rather than
+   :term:`INHERIT` to inherit the ``testimage`` class for automated image
+   testing.
 
 The tests are commands that run on the target system over ``ssh``. Each
 test is written in Python and makes use of the ``unittest`` module.
@@ -2686,13 +2637,9 @@
 
 .. note::
 
-   Best practices include using
-   IMAGE_CLASSES
-   rather than
-   INHERIT
-   to inherit the
-   testsdk
-   class for automated SDK testing.
+   Best practices include using :term:`IMAGE_CLASSES` rather than
+   :term:`INHERIT` to inherit the ``testsdk`` class for automated SDK
+   testing.
 
 .. _ref-classes-texinfo:
 
@@ -2709,23 +2656,8 @@
 .. note::
 
    If you want to use the Texinfo recipe shipped with the build system,
-   you can remove "texinfo-native" from
-   ASSUME_PROVIDED
-   and makeinfo from
-   SANITY_REQUIRED_UTILITIES
-   .
-
-.. _ref-classes-tinderclient:
-
-``tinderclient.bbclass``
-========================
-
-The ``tinderclient`` class submits build results to an external
-Tinderbox instance.
-
-.. note::
-
-   This class is currently unmaintained.
+   you can remove "texinfo-native" from :term:`ASSUME_PROVIDED` and makeinfo
+   from :term:`SANITY_REQUIRED_UTILITIES`.
 
 .. _ref-classes-toaster:
 
@@ -2836,10 +2768,8 @@
 
 .. note::
 
-   You can use the
-   update-alternatives
-   command directly in your recipes. However, this class simplifies
-   things in most cases.
+   You can use the ``update-alternatives`` command directly in your recipes.
+   However, this class simplifies things in most cases.
 
 .. _ref-classes-update-rc.d:
 
@@ -2905,18 +2835,10 @@
 
 .. note::
 
-   You do not use the
-   useradd-staticids
-   class directly. You either enable or disable the class by setting the
-   USERADDEXTENSION
-   variable. If you enable or disable the class in a configured system,
-   TMPDIR
-   might contain incorrect
-   uid
-   and
-   gid
-   values. Deleting the
-   TMPDIR
+   You do not use the ``useradd-staticids`` class directly. You either enable
+   or disable the class by setting the ``USERADDEXTENSION`` variable. If you
+   enable or disable the class in a configured system, :term:`TMPDIR` might
+   contain incorrect ``uid`` and ``gid`` values. Deleting the ``TMPDIR``
    directory will correct this condition.
 
 .. _ref-classes-utility-tasks:
diff --git a/poky/documentation/ref-manual/ref-devtool-reference.rst b/poky/documentation/ref-manual/ref-devtool-reference.rst
index 1fe8997..9b9ddf5 100644
--- a/poky/documentation/ref-manual/ref-devtool-reference.rst
+++ b/poky/documentation/ref-manual/ref-devtool-reference.rst
@@ -131,7 +131,7 @@
    :align: center
    :scale: 70%
 
-::
+.. code-block:: none
 
    attic - A directory created if devtool believes it must preserve
            anything when you run "devtool reset".  For example, if you
@@ -223,7 +223,7 @@
 .. note::
 
    If you prefer to use the latest revision every time the recipe is
-   built, use the options --autorev or -a.
+   built, use the options ``--autorev`` or ``-a``.
 
 .. _devtool-extracting-the-source-for-an-existing-recipe:
 
@@ -261,7 +261,7 @@
 
 Use the ``devtool modify`` command to begin modifying the source of an
 existing recipe. This command is very similar to the
-```add`` <#devtool-adding-a-new-recipe-to-the-workspace>`__ command
+:ref:`add <devtool-adding-a-new-recipe-to-the-workspace>` command
 except that it does not physically create the recipe in the workspace
 layer because the recipe already exists in an another layer.
 
@@ -303,7 +303,7 @@
 Use the ``devtool update-recipe`` command to update your recipe with
 patches that reflect changes you make to the source files. For example,
 if you know you are going to work on some code, you could first use the
-```devtool modify`` <#devtool-modifying-a-recipe>`__ command to extract
+:ref:`devtool modify <devtool-modifying-a-recipe>` command to extract
 the code and set up the workspace. After which, you could modify,
 compile, and test the code.
 
@@ -386,15 +386,21 @@
 .. note::
 
    When a reason for not upgrading displays, the reason is usually
-   written into the recipe using the RECIPE_NO_UPDATE_REASON
-   variable. See the base-passwd.bb recipe for an example.
+   written into the recipe using the ``RECIPE_NO_UPDATE_REASON``
+   variable. See the
+   :yocto_git:`base-passwd.bb </cgit/cgit.cgi/poky/tree/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb>`
+   recipe for an example.
 
 ::
 
-   $ devtool check-upgrade-status ...
+   $ devtool check-upgrade-status
+   ...
    NOTE: acpid 2.0.30 2.0.31 Ross Burton <ross.burton@intel.com>
    NOTE: u-boot-fw-utils 2018.11 2019.01 Marek Vasut <marek.vasut@gmail.com> d3689267f92c5956e09cc7d1baa4700141662bff
-   NOTE: u-boot-tools 2018.11 2019.01 Marek Vasut <marek.vasut@gmail.com> d3689267f92c5956e09cc7d1baa4700141662bff . . .
+   NOTE: u-boot-tools 2018.11 2019.01 Marek Vasut <marek.vasut@gmail.com> d3689267f92c5956e09cc7d1baa4700141662bff
+   .
+   .
+   .
    NOTE: base-passwd 3.5.29 3.5.45 Anuj Mittal <anuj.mittal@intel.com> cannot be updated due to: Version 3.5.38 requires cdebconf for update-passwd utility
    NOTE: busybox 1.29.2 1.30.0 Andrej Valek <andrej.valek@siemens.com>
    NOTE: dbus-test 1.12.10 1.12.12 Chen Qi <Qi.Chen@windriver.com>
@@ -607,8 +613,8 @@
 to create and add the ``mtr_0.86.bb`` recipe to the ``workspace`` directory:
 ::
 
-   $ devtool status mtr
-   :/home/scottrif/poky/build/workspace/sources/mtr (/home/scottrif/poky/build/workspace/recipes/mtr/mtr_0.86.bb)
+   $ devtool status
+   mtr:/home/scottrif/poky/build/workspace/sources/mtr (/home/scottrif/poky/build/workspace/recipes/mtr/mtr_0.86.bb)
    $
 
 .. _devtool-search-for-available-target-recipes:
diff --git a/poky/documentation/ref-manual/ref-features.rst b/poky/documentation/ref-manual/ref-features.rst
index 60d905d..f28ad2b 100644
--- a/poky/documentation/ref-manual/ref-features.rst
+++ b/poky/documentation/ref-manual/ref-features.rst
@@ -229,11 +229,8 @@
 
    .. note::
 
-      To make the
-      /var/log
-      directory on the target persistent, use the
-      VOLATILE_LOG_DIR
-      variable by setting it to "no".
+      To make the ``/var/log`` directory on the target persistent, use the
+      :term:`VOLATILE_LOG_DIR` variable by setting it to "no".
 
 -  *ptest-pkgs:* Installs ptest packages for all ptest-enabled recipes.
 
diff --git a/poky/documentation/ref-manual/ref-images.rst b/poky/documentation/ref-manual/ref-images.rst
index eaa6c49..56ec856 100644
--- a/poky/documentation/ref-manual/ref-images.rst
+++ b/poky/documentation/ref-manual/ref-images.rst
@@ -16,8 +16,7 @@
    the GNU Affero General Public License Version 3 (AGPL-3.0) components
    is only supported for minimal and base images. Furthermore, if you
    are going to build an image using non-GPLv3 and similarly licensed
-   components, you must make the following changes in the
-   local.conf
+   components, you must make the following changes in the ``local.conf``
    file before using the BitBake command to build the minimal or base
    image:
    ::
diff --git a/poky/documentation/ref-manual/ref-kickstart.rst b/poky/documentation/ref-manual/ref-kickstart.rst
index c031ef2..7f6d4eb 100644
--- a/poky/documentation/ref-manual/ref-kickstart.rst
+++ b/poky/documentation/ref-manual/ref-kickstart.rst
@@ -55,15 +55,14 @@
 .. note::
 
    The mount program must understand the PARTUUID syntax you use with
-   --use-uuid
-   and non-root
-   mountpoint
-   , including swap. The busybox versions of these application are
-   currently excluded.
+   ``--use-uuid`` and non-root *mountpoint*, including swap. The busybox
+   versions of these application are currently excluded.
 
 Here is an example that uses "/" as the mountpoint. The command uses
-``--ondisk`` to force the partition onto the ``sdb`` disk: part /
---source rootfs --ondisk sdb --fstype=ext3 --label platform --align 1024
+``--ondisk`` to force the partition onto the ``sdb`` disk:
+::
+
+      part / --source rootfs --ondisk sdb --fstype=ext3 --label platform --align 1024
 
 Here is a list that describes other supported options you can use with
 the ``part`` and ``partition`` commands:
@@ -135,6 +134,11 @@
 -  ``--align (in KBytes)``: This option is a Wic-specific option that
    says to start partitions on boundaries given x KBytes.
 
+-  ``--offset (in KBytes)``: This option is a Wic-specific option that
+   says to place a partition at exactly the specified offset. If the
+   partition cannot be placed at the specified offset, the image build
+   will fail.
+
 -  ``--no-table``: This option is a Wic-specific option. Using the
    option reserves space for the partition and causes it to become
    populated. However, the partition is not added to the partition
diff --git a/poky/documentation/ref-manual/ref-qa-checks.rst b/poky/documentation/ref-manual/ref-qa-checks.rst
index 4ac65c0..5b9f92d 100644
--- a/poky/documentation/ref-manual/ref-qa-checks.rst
+++ b/poky/documentation/ref-manual/ref-qa-checks.rst
@@ -454,9 +454,8 @@
 
       Disabling stripping here does not mean that the final packaged
       binaries will be unstripped. Once the OpenEmbedded build system
-      splits out debug symbols to the
-      -dbg
-      package, it will then strip the symbols from the binaries.
+      splits out debug symbols to the ``-dbg`` package, it will then
+      strip the symbols from the binaries.
 
     
 
diff --git a/poky/documentation/ref-manual/ref-release-process.rst b/poky/documentation/ref-manual/ref-release-process.rst
index 172385c..a6d9ff6 100644
--- a/poky/documentation/ref-manual/ref-release-process.rst
+++ b/poky/documentation/ref-manual/ref-release-process.rst
@@ -64,7 +64,7 @@
 Releases are given a nominal release version as well but the codename is
 used in repositories for this reason. You can find information on Yocto
 Project releases and codenames at
-https://wiki.yoctoproject.org/wiki/Releases.
+:yocto_wiki:`/wiki/Releases`.
 
 Stable Release Process
 ======================
@@ -94,7 +94,7 @@
 patches for older releases. However, these types of patches do not go
 through the same release process as do point releases. You can find more
 information about stable branch maintenance at
-https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance.
+:yocto_wiki:`/wiki/Stable_branch_maintenance`.
 
 Testing and Quality Assurance
 =============================
@@ -145,18 +145,16 @@
 
    .. note::
 
-      Running
-      oe-selftest
-      requires host packages beyond the "Essential" grouping. See the "
-      Required Packages for the Build Host
-      " section for more information.
+      Running ``oe-selftest`` requires host packages beyond the "Essential"
+      grouping. See the :ref:`ref-manual/ref-system-requirements:required packages for the build host`
+      section for more information.
 
 Originally, much of this testing was done manually. However, significant
 effort has been made to automate the tests so that more people can use
 them and the Yocto Project development team can run them faster and more
 efficiently.
 
-The Yocto Project's main Autobuilder (https://autobuilder.yoctoproject.org/)
+The Yocto Project's main Autobuilder (&YOCTO_AB_URL;)
 publicly tests each Yocto Project release's code in the
 :term:`OpenEmbedded-Core (OE-Core)`, Poky, and BitBake repositories. The testing
 occurs for both the current state of the "master" branch and also for
diff --git a/poky/documentation/ref-manual/ref-structure.rst b/poky/documentation/ref-manual/ref-structure.rst
index ef07354..db1ea97 100644
--- a/poky/documentation/ref-manual/ref-structure.rst
+++ b/poky/documentation/ref-manual/ref-structure.rst
@@ -188,7 +188,7 @@
 Directory named ``mybuilds/`` that is outside of the :term:`Source Directory`:
 ::
 
-   $ source OE_INIT_FILE ~/mybuilds
+   $ source oe-init-build-env ~/mybuilds
 
 The OpenEmbedded build system uses the template configuration files, which
 are found by default in the ``meta-poky/conf/`` directory in the Source
@@ -200,8 +200,7 @@
 .. note::
 
    The OpenEmbedded build system does not support file or directory
-   names that contain spaces. If you attempt to run the
-   OE_INIT_FILE
+   names that contain spaces. If you attempt to run the ``oe-init-build-env``
    script from a Source Directory that contains spaces in either the
    filenames or directory names, the script returns an error indicating
    no such file or directory. Be sure to use a Source Directory free of
@@ -282,17 +281,10 @@
 
 .. note::
 
-   You can see how the
-   TEMPLATECONF
-   variable is used by looking at the
-   scripts/oe-setup-builddir
-   script in the
-   Source Directory
-   . You can find the Yocto Project version of the
-   local.conf.sample
-   file in the
-   meta-poky/conf
-   directory.
+   You can see how the ``TEMPLATECONF`` variable is used by looking at the
+   ``scripts/oe-setup-builddir``` script in the :term:`Source Directory`.
+   You can find the Yocto Project version of the ``local.conf.sample`` file in
+   the ``meta-poky/conf`` directory.
 
 .. _structure-build-conf-bblayers.conf:
 
@@ -327,16 +319,9 @@
 
 .. note::
 
-   You can see how the
-   TEMPLATECONF
-   variable
-   scripts/oe-setup-builddir
-   script in the
-   Source Directory
-   . You can find the Yocto Project version of the
-   bblayers.conf.sample
-   file in the
-   meta-poky/conf/
+   You can see how the ``TEMPLATECONF`` variable ``scripts/oe-setup-builddir``
+   script in the :term:`Source Directory`. You can find the Yocto Project
+   version of the ``bblayers.conf.sample`` file in the ``meta-poky/conf/``
    directory.
 
 .. _structure-build-conf-sanity_info:
@@ -531,19 +516,16 @@
 
 Previous versions of the OpenEmbedded build system used to create a
 global shared sysroot per machine along with a native sysroot. Beginning
-with the DISTRO version of the Yocto Project, sysroots exist in
+with the 2.3 version of the Yocto Project, sysroots exist in
 recipe-specific :term:`WORKDIR` directories. Thus, the
 ``build/tmp/sysroots/`` directory is unused.
 
 .. note::
 
-   The
-   build/tmp/sysroots/
-   directory can still be populated using the
-   bitbake build-sysroots
-   command and can be used for compatibility in some cases. However, in
-   general it is not recommended to populate this directory. Individual
-   recipe-specific sysroots should be used.
+   The ``build/tmp/sysroots/`` directory can still be populated using the
+   ``bitbake build-sysroots`` command and can be used for compatibility in some
+   cases. However, in general it is not recommended to populate this directory.
+   Individual recipe-specific sysroots should be used.
 
 .. _structure-build-tmp-stamps:
 
@@ -554,8 +536,11 @@
 purposes to track what tasks have run and when they have run. The
 directory is sub-divided by architecture, package name, and version.
 Following is an example:
-stamps/all-poky-linux/distcc-config/1.0-r0.do_build-2fdd....2do Although
-the files in the directory are empty of data, BitBake uses the filenames
+::
+
+      stamps/all-poky-linux/distcc-config/1.0-r0.do_build-2fdd....2do
+
+Although the files in the directory are empty of data, BitBake uses the filenames
 and timestamps for tracking purposes.
 
 For information on how BitBake uses stamp files to determine if a task
@@ -613,13 +598,12 @@
 The recipe work directory - ``${WORKDIR}``.
 
 As described earlier in the
-"```build/tmp/sysroots/`` <#structure-build-tmp-sysroots>`__" section,
-beginning with the DISTRO release of the Yocto Project, the OpenEmbedded
+":ref:`structure-build-tmp-sysroots`" section,
+beginning with the 2.3 release of the Yocto Project, the OpenEmbedded
 build system builds each recipe in its own work directory (i.e.
 :term:`WORKDIR`). The path to the work directory is
 constructed using the architecture of the given build (e.g.
-:term:`TUNE_PKGARCH`,
-:term:`MACHINE_ARCH`, or "allarch"), the recipe
+:term:`TUNE_PKGARCH`, :term:`MACHINE_ARCH`, or "allarch"), the recipe
 name, and the version of the recipe (i.e.
 :term:`PE`\ ``:``\ :term:`PV`\ ``-``\ :term:`PR`).
 
diff --git a/poky/documentation/ref-manual/ref-system-requirements.rst b/poky/documentation/ref-manual/ref-system-requirements.rst
index 54f38f6..fe7c925 100644
--- a/poky/documentation/ref-manual/ref-system-requirements.rst
+++ b/poky/documentation/ref-manual/ref-system-requirements.rst
@@ -27,9 +27,7 @@
 .. note::
 
    For more information about the Yocto Project Documentation set, see
-   the "
-   Links and Related Documentation
-   " section.
+   the :ref:`ref-manual/resources:links and related documentation` section.
 
 .. _detailed-supported-distros:
 
@@ -91,8 +89,8 @@
       compatible but not officially supported nor validated with
       WSLv2, if you still decide to use WSL please upgrade to WSLv2.
 
-   -  If you encounter problems, please go to `Yocto Project
-      Bugzilla <http://bugzilla.yoctoproject.org>`__ and submit a bug. We are
+   -  If you encounter problems, please go to :yocto_bugs:`Yocto Project
+      Bugzilla <>` and submit a bug. We are
       interested in hearing about your experience. For information on
       how to submit a bug, see the Yocto Project
       :yocto_wiki:`Bugzilla wiki page </wiki/Bugzilla_Configuration_and_Bug_Tracking>`
@@ -143,7 +141,14 @@
    Yocto Project documentation manuals:
    ::
 
-      $ sudo apt-get install make xsltproc docbook-utils fop dblatex xmlto
+      $ sudo apt-get install make python3-pip
+      &PIP3_HOST_PACKAGES_DOC;
+
+   .. note::
+
+      It is currently not possible to build out documentation from Debian 8
+      (Jessie) because of outdated ``pip3`` and ``python3``. ``python3-sphinx``
+      is too outdated.
 
 Fedora Packages
 ---------------
@@ -161,8 +166,8 @@
    Yocto Project documentation manuals:
    ::
 
-      $ sudo dnf install  docbook-style-dsssl docbook-style-xsl \
-      docbook-dtds docbook-utils fop libxslt dblatex xmlto
+      $ sudo dnf install make python3-pip which
+      &PIP3_HOST_PACKAGES_DOC;
 
 openSUSE Packages
 -----------------
@@ -177,8 +182,12 @@
       $ sudo zypper install &OPENSUSE_HOST_PACKAGES_ESSENTIAL;
 
 -  *Documentation:* Packages needed if you are going to build out the
-   Yocto Project documentation manuals: $ sudo zypper install dblatex
-   xmlto
+   Yocto Project documentation manuals:
+   ::
+
+      $ sudo zypper install make python3-pip which
+      &PIP3_HOST_PACKAGES_DOC;
+
 
 CentOS-7 Packages
 -----------------
@@ -206,8 +215,8 @@
    Yocto Project documentation manuals:
    ::
 
-      $ sudo yum install docbook-style-dsssl docbook-style-xsl \
-      docbook-dtds docbook-utils fop libxslt dblatex xmlto
+      $ sudo yum install make python3-pip which
+      &PIP3_HOST_PACKAGES_DOC;
 
 CentOS-8 Packages
 -----------------
@@ -238,8 +247,8 @@
    Yocto Project documentation manuals:
    ::
 
-      $ sudo dnf install docbook-style-dsssl docbook-style-xsl \\
-      docbook-dtds docbook-utils fop libxslt dblatex xmlto
+      $ sudo dnf install make python3-pip which
+      &PIP3_HOST_PACKAGES_DOC;
 
 Required Git, tar, Python and gcc Versions
 ==========================================
@@ -279,7 +288,7 @@
 
       $ cd poky
       $ scripts/install-buildtools --without-extended-buildtools \
-        --base-url https://downloads.yoctoproject.org/releases/yocto \
+        --base-url &YOCTO_DL_URL;/releases/yocto \
         --release yocto-&DISTRO; \
         --installer-version &DISTRO;
 
@@ -340,7 +349,7 @@
 
    During execution, a prompt appears that allows you to choose the
    installation directory. For example, you could choose the following:
-   /home/your-username/buildtools
+   ``/home/your-username/buildtools``
 
 3. Source the tools environment setup script by using a command like the
    following:
@@ -388,12 +397,8 @@
 
    .. note::
 
-      The
-      SDKMACHINE
-      variable in your
-      local.conf
-      file determines whether you build tools for a 32-bit or 64-bit
-      system.
+      The :term:`SDKMACHINE` variable in your ``local.conf`` file determines
+      whether you build tools for a 32-bit or 64-bit system.
 
    Once the build completes, you can find the ``.sh`` file that installs
    the tools in the ``tmp/deploy/sdk`` subdirectory of the
@@ -417,7 +422,7 @@
 
    During execution, a prompt appears that allows you to choose the
    installation directory. For example, you could choose the following:
-   /home/your_username/buildtools
+   ``/home/your_username/buildtools``
 
 5. Source the tools environment setup script by using a command like the
    following:
diff --git a/poky/documentation/ref-manual/ref-tasks.rst b/poky/documentation/ref-manual/ref-tasks.rst
index 2569306..9ef0141 100644
--- a/poky/documentation/ref-manual/ref-tasks.rst
+++ b/poky/documentation/ref-manual/ref-tasks.rst
@@ -87,33 +87,30 @@
 
 .. note::
 
-   Do not write the output directly to
-   ${DEPLOY_DIR_IMAGE}
-   , as this causes the sstate mechanism to malfunction.
+   Do not write the output directly to ``${DEPLOY_DIR_IMAGE}``, as this causes
+   the sstate mechanism to malfunction.
 
 The ``do_deploy`` task is not added as a task by default and
 consequently needs to be added manually. If you want the task to run
 after :ref:`ref-tasks-compile`, you can add it by doing
-the following: addtask deploy after do_compile Adding ``do_deploy``
-after other tasks works the same way.
+the following:
+::
+
+      addtask deploy after do_compile
+
+Adding ``do_deploy`` after other tasks works the same way.
 
 .. note::
 
-   You do not need to add
-   before do_build
-   to the
-   addtask
-   command (though it is harmless), because the
-   base
-   class contains the following:
+   You do not need to add ``before do_build`` to the ``addtask`` command
+   (though it is harmless), because the ``base`` class contains the following:
    ::
 
            do_build[recrdeptask] += "do_deploy"
 
 
-   See the "
-   Dependencies
-   " section in the BitBake User Manual for more information.
+   See the ":ref:`bitbake-user-manual/bitbake-user-manual-execution:dependencies`"
+   section in the BitBake User Manual for more information.
 
 If the ``do_deploy`` task re-executes, any previous output is removed
 (i.e. "cleaned").
@@ -298,10 +295,8 @@
 
 .. note::
 
-   The build system uses the
-   FILESPATH
-   variable to determine the default set of directories when searching
-   for patches.
+   The build system uses the :term:`FILESPATH` variable to determine the
+   default set of directories when searching for patches.
 
 Patch files, by default, are ``*.patch`` and ``*.diff`` files created
 and kept in a subdirectory of the directory holding the recipe file. For
@@ -322,13 +317,8 @@
 
 .. note::
 
-   In the case for the
-   bluez5_5.48.bb
-   recipe, the
-   SRC_URI
-   statements are from an include file
-   bluez5.inc
-   .
+   In the case for the ``bluez5_5.48.bb`` recipe, the ``SRC_URI`` statements
+   are from an include file ``bluez5.inc``.
 
 As mentioned earlier, the build system treats files whose file types are
 ``.patch`` and ``.diff`` as patch files. However, you can use the
@@ -336,9 +326,9 @@
 file as a patch file:
 ::
 
-   SRC_URI = " \\
-       git://path_to_repo/some_package \\
-       file://file;apply=yes \\
+   SRC_URI = " \
+       git://path_to_repo/some_package \
+       file://file;apply=yes \
        "
 
 Conversely, if you have a directory full of patch files and you want to
@@ -356,7 +346,7 @@
 In the
 previous example, assuming all the files in the directory holding the
 patch files end with either ``.patch`` or ``.diff``, every file would be
-applied as a patch by default except for the patch_file5 patch.
+applied as a patch by default except for the ``patch_file5`` patch.
 
 You can find out more about the patching process in the
 ":ref:`patching-dev-environment`" section in
@@ -547,7 +537,7 @@
 (:ref:`sstate <overview-manual/overview-manual-concepts:shared state cache>`) cache for a
 target. Essentially, the ``do_cleansstate`` task is identical to the
 :ref:`ref-tasks-clean` task with the added removal of
-shared state (`:ref:`sstate <overview-manual/overview-manual-concepts:shared state cache>`)
+shared state (:ref:`sstate <overview-manual/overview-manual-concepts:shared state cache>`)
 cache.
 
 You can run this task using BitBake as follows:
@@ -561,11 +551,9 @@
 
 .. note::
 
-   The
-   do_cleansstate
-   task cannot remove sstate from a remote sstate mirror. If you need to
-   build a target from scratch using remote mirrors, use the "-f" option
-   as follows:
+   The ``do_cleansstate`` task cannot remove sstate from a remote sstate
+   mirror. If you need to build a target from scratch using remote mirrors, use
+   the "-f" option as follows:
    ::
 
       $ bitbake -f -c do_cleansstate target
@@ -605,18 +593,13 @@
 ``do_package_index``
 --------------------
 
-Creates or updates the index in the `:ref:`package-feeds-dev-environment` area.
+Creates or updates the index in the :ref:`package-feeds-dev-environment` area.
 
 .. note::
 
-   This task is not triggered with the
-   bitbake -c
-   command-line option as are the other tasks in this section. Because
-   this task is specifically for the
-   package-index
-   recipe, you run it using
-   bitbake package-index
-   .
+   This task is not triggered with the ``bitbake -c`` command-line option as
+   are the other tasks in this section. Because this task is specifically for
+   the ``package-index`` recipe, you run it using ``bitbake package-index``.
 
 Image-Related Tasks
 ===================
@@ -859,17 +842,3 @@
 branches. If these branches do not exist and
 :term:`AUTOREV` is not being used, the
 ``do_validate_branches`` task fails during the build.
-
-Miscellaneous Tasks
-===================
-
-The following sections describe miscellaneous tasks.
-
-.. _ref-tasks-spdx:
-
-``do_spdx``
------------
-
-A build stage that takes the source code and scans it on a remote
-FOSSOLOGY server in order to produce an SPDX document. This task applies
-only to the :ref:`spdx <ref-classes-spdx>` class.
diff --git a/poky/documentation/ref-manual/ref-terms.rst b/poky/documentation/ref-manual/ref-terms.rst
index 556bc6b..b4ceebc 100644
--- a/poky/documentation/ref-manual/ref-terms.rst
+++ b/poky/documentation/ref-manual/ref-terms.rst
@@ -10,7 +10,7 @@
 
 .. glossary::
 
-   Append Files
+   :term:`Append Files`
       Files that append build information to a recipe file.  Append files are
       known as BitBake append files and ``.bbappend`` files. The OpenEmbedded
       build system expects every append file to have a corresponding recipe
@@ -45,23 +45,23 @@
 
       .. note::
 
-         The use of the " % " character is limited in that it only works
+         The use of the "%" character is limited in that it only works
          directly in front of the .bbappend portion of the append file's
          name. You cannot use the wildcard character in any other location of
          the name.
 
-   BitBake
+   :term:`BitBake`
       The task executor and scheduler used by the OpenEmbedded build system to
       build images. For more information on BitBake, see the :doc:`BitBake User
       Manual <bitbake:index>`.
 
-   Board Support Package (BSP)
+   :term:`Board Support Package (BSP)`
       A group of drivers, definitions, and other components that provide support
       for a specific hardware configuration. For more information on BSPs, see
       the :ref:`bsp-guide/bsp-guide:Yocto Project Board Support Package
       Developer's Guide`.
 
-   Build Directory
+   :term:`Build Directory`
       This term refers to the area used by the OpenEmbedded build system for
       builds. The area is created when you ``source`` the setup environment
       script that is found in the Source Directory
@@ -101,27 +101,27 @@
 
       .. note::
 
-         By default, the Build Directory contains :term:`TMPDIR` , which is a
-         temporary directory the build system uses for its work. TMPDIR cannot
+         By default, the Build Directory contains :term:`TMPDIR`, which is a
+         temporary directory the build system uses for its work. ``TMPDIR`` cannot
          be under NFS. Thus, by default, the Build Directory cannot be under
          NFS. However, if you need the Build Directory to be under NFS, you can
-         set this up by setting TMPDIR in your local.conf file to use a local
-         drive. Doing so effectively separates TMPDIR from TOPDIR , which is the
+         set this up by setting ``TMPDIR`` in your ``local.conf`` file to use a local
+         drive. Doing so effectively separates ``TMPDIR`` from :term:`TOPDIR`, which is the
          Build Directory.
 
-   Build Host
+   :term:`Build Host`
       The system used to build images in a Yocto Project Development
       environment. The build system is sometimes referred to as the development
       host.
 
-   Classes
+   :term:`Classes`
       Files that provide for logic encapsulation and inheritance so that
       commonly used patterns can be defined once and then easily used in
       multiple recipes. For reference information on the Yocto Project classes,
       see the ":ref:`ref-manual/ref-classes:Classes`" chapter. Class files end with the
       ``.bbclass`` filename extension.
 
-   Configuration File
+   :term:`Configuration File`
       Files that hold global definitions of variables, user-defined variables,
       and hardware configuration information. These files tell the OpenEmbedded
       build system what to build and what to put into the image to support a
@@ -138,13 +138,13 @@
       :file:`machine/beaglebone.conf` configuration file defines variables for
       the Texas Instruments ARM Cortex-A8 development board).
 
-   Container Layer
+   :term:`Container Layer`
       Layers that hold other layers. An example of a container layer is
       OpenEmbedded's `meta-openembedded
       <https://github.com/openembedded/meta-openembedded>`_ layer. The
       ``meta-openembedded`` layer contains many ``meta-*`` layers.
 
-   Cross-Development Toolchain
+   :term:`Cross-Development Toolchain`
       In general, a cross-development toolchain is a collection of software
       development tools and utilities that run on one architecture and allow you
       to develop software for a different, or targeted, architecture. These
@@ -167,7 +167,7 @@
       toolchain in the :ref:`sdk-manual/sdk-manual:Yocto Project Application
       Development and the Extensible Software Development Kit (eSDK)` manual.
 
-   Extensible Software Development Kit (eSDK)
+   :term:`Extensible Software Development Kit (eSDK)`
       A custom SDK for 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.
@@ -176,14 +176,14 @@
       Project Application Development and the Extensible Software Development
       Kit (eSDK)` manual.
 
-   Image
+   :term:`Image`
       An image is an artifact of the BitBake build process given a collection of
       recipes and related Metadata. Images are the binary output that run on
       specific hardware or QEMU and are used for specific use-cases. For a list
       of the supported image types that the Yocto Project provides, see the
       ":ref:`ref-manual/ref-images:Images`" chapter.
 
-   Layer
+   :term:`Layer`
       A collection of related recipes. Layers allow you to consolidate related
       metadata to customize your build. Layers also isolate information used
       when building for multiple architectures.  Layers are hierarchical in
@@ -202,7 +202,7 @@
       Layers`" section in the Yocto Project Board Support Packages (BSP)
       Developer's Guide.
 
-   Metadata
+   :term:`Metadata`
       A key element of the Yocto Project is the Metadata that
       is used to construct a Linux distribution and is contained in the
       files that the :term:`OpenEmbedded Build System`
@@ -221,7 +221,7 @@
       :yocto_git:`yocto-kernel-cache </cgit/cgit.cgi/yocto-kernel-cache>`
       Git repository.
 
-   OpenEmbedded-Core (OE-Core)
+   :term:`OpenEmbedded-Core (OE-Core)`
       OE-Core is metadata comprised of
       foundational recipes, classes, and associated files that are meant to
       be common among many different OpenEmbedded-derived systems,
@@ -232,9 +232,9 @@
       core set of recipes.
 
       You can see the Metadata in the ``meta`` directory of the Yocto
-      Project :yocto_git:`Source Repositories <>`.
+      Project :yocto_git:`Source Repositories </cgit/cgit.cgi/poky>`.
 
-   OpenEmbedded Build System
+   :term:`OpenEmbedded Build System`
       The build system specific to the Yocto
       Project. The OpenEmbedded build system is based on another project
       known as "Poky", which uses :term:`BitBake` as the task
@@ -246,11 +246,9 @@
 
       .. note::
 
-         For some historical information about Poky, see the
-         Poky
-         term.
+         For some historical information about Poky, see the :term:`Poky` term.
 
-   Package
+   :term:`Package`
       In the context of the Yocto Project, this term refers to a
       recipe's packaged output produced by BitBake (i.e. a "baked recipe").
       A package is generally the compiled binaries produced from the
@@ -258,10 +256,9 @@
 
       It is worth noting that the term "package" can, in general, have
       subtle meanings. For example, the packages referred to in the
-      "`Required Packages for the Build
-      Host <#required-packages-for-the-build-host>`__" section are compiled
-      binaries that, when installed, add functionality to your Linux
-      distribution.
+      ":ref:`ref-manual/ref-system-requirements:required packages for the build host`"
+      section are compiled binaries that, when installed, add functionality to
+      your Linux distribution.
 
       Another point worth noting is that historically within the Yocto
       Project, recipes were referred to as packages - thus, the existence
@@ -269,7 +266,7 @@
       :term:`PR`, :term:`PV`, and
       :term:`PE`).
 
-   Package Groups
+   :term:`Package Groups`
       Arbitrary groups of software Recipes. You use
       package groups to hold recipes that, when built, usually accomplish a
       single task. For example, a package group could contain the recipes
@@ -278,7 +275,7 @@
       is really just another recipe. Because package group files are
       recipes, they end with the ``.bb`` filename extension.
 
-   Poky
+   :term:`Poky`
       Poky, which is pronounced *Pock*-ee, is a reference embedded
       distribution and a reference test configuration. Poky provides the
       following:
@@ -303,7 +300,7 @@
          OpenedHand, the poky project became the basis for the Yocto
          Project's build system.
 
-   Recipe
+   :term:`Recipe`
       A set of instructions for building packages. A recipe
       describes where you get source code, which patches to apply, how to
       configure the source, how to compile it and so on. Recipes also
@@ -311,13 +308,13 @@
       represent the logical unit of execution, the software to build, the
       images to build, and use the ``.bb`` file extension.
 
-   Reference Kit
+   :term:`Reference Kit`
       A working example of a system, which includes a
       :term:`BSP<Board Support Package (BSP)>` as well as a
       :term:`build host<Build Host>` and other components, that can
       work on specific hardware.
 
-   Source Directory
+   :term:`Source Directory`
      This term refers to the directory structure
      created as a result of creating a local copy of the ``poky`` Git
      repository ``git://git.yoctoproject.org/poky`` or expanding a
@@ -376,20 +373,20 @@
      ":ref:`overview-manual/overview-manual-development-environment:repositories, tags, and branches`"
      section in the Yocto Project Overview and Concepts Manual.
 
-   Task
+   :term:`Task`
       A unit of execution for BitBake (e.g.
       :ref:`ref-tasks-compile`,
       :ref:`ref-tasks-fetch`,
       :ref:`ref-tasks-patch`, and so forth).
 
-   Toaster
+   :term:`Toaster`
       A web interface to the Yocto Project's :term:`OpenEmbedded Build System`.
       The interface enables you to
       configure and run your builds. Information about builds is collected
       and stored in a database. For information on Toaster, see the
       :doc:`../toaster-manual/toaster-manual`.
 
-   Upstream
+   :term:`Upstream`
       A reference to source code or repositories that are not
       local to the development system but located in a master area that is
       controlled by the maintainer of the source code. For example, in
diff --git a/poky/documentation/ref-manual/ref-variables.rst b/poky/documentation/ref-manual/ref-variables.rst
index 316e8aa..0603ba9 100644
--- a/poky/documentation/ref-manual/ref-variables.rst
+++ b/poky/documentation/ref-manual/ref-variables.rst
@@ -78,7 +78,7 @@
 
       .. note::
 
-         If ALTERNATIVE_LINK_NAME is not defined, it defaults to ${bindir}/ name.
+         If ``ALTERNATIVE_LINK_NAME`` is not defined, it defaults to ``${bindir}/name``.
 
       For more information on the alternatives system, see the
       ":ref:`update-alternatives.bbclass <ref-classes-update-alternatives>`"
@@ -237,15 +237,9 @@
 
       .. note::
 
-         It is assumed that all changes to
-         COMMON_LICENSE_DIR
-         and
-         LICENSE_PATH
-         have been done before
-         AVAILABLE_LICENSES
-         is defined (in
-         license.bbclass
-         ).
+         It is assumed that all changes to ``COMMON_LICENSE_DIR`` and
+         ``LICENSE_PATH`` have been done before ``AVAILABLE_LICENSES``
+         is defined (in :ref:`ref-classes-license`).
 
    :term:`AVAILTUNES`
       The list of defined CPU and Application Binary Interface (ABI)
@@ -389,7 +383,8 @@
       add the ``BB_DISKMON_DIRS`` variable to your ``conf/local.conf`` file
       found in the :term:`Build Directory`. Use the
       following form:
-      ::
+
+      .. code-block:: none
 
          BB_DISKMON_DIRS = "action,dir,threshold [...]"
 
@@ -473,7 +468,8 @@
 
       When specifying the variable in your configuration file, use the
       following form:
-      ::
+
+      .. code-block:: none
 
          BB_DISKMON_WARNINTERVAL = "disk_space_interval,disk_inode_interval"
 
@@ -619,8 +615,7 @@
 
       .. tip::
 
-         You can use the command
-         bitbake-layers show-layers
+         You can use the command ``bitbake-layers show-layers``
          to list all configured layers along with their priorities.
 
    :term:`BBFILES`
@@ -653,7 +648,8 @@
 
       This next example shows an error message that occurs because invalid
       entries are found, which cause parsing to abort:
-      ::
+
+      .. code-block:: none
 
          ERROR: BBFILES_DYNAMIC entries must be of the form <collection name>:<filename pattern>, not:
              /work/my-layer/bbappends/meta-security-isafw/*/*/*.bbappend
@@ -675,7 +671,8 @@
       ::
 
          BBLAYERS = " \
-             /home/scottrif/poky/meta \ /home/scottrif/poky/meta-poky \
+             /home/scottrif/poky/meta \
+             /home/scottrif/poky/meta-poky \
              /home/scottrif/poky/meta-yocto-bsp \
              /home/scottrif/poky/meta-mykernel \
              "
@@ -799,16 +796,12 @@
 
       .. note::
 
-         The
-         BINCONFIG_GLOB
-         variable uses
-         shell globbing
-         , which is recognition and expansion of wildcards during pattern
+         The ``BINCONFIG_GLOB`` variable uses
+         `shell globbing <https://tldp.org/LDP/abs/html/globbingref.html>`__,
+         which is recognition and expansion of wildcards during pattern
          matching. Shell globbing is very similar to
-         fnmatch
-         and
-         glob
-         .
+         `fnmatch <https://docs.python.org/3/library/fnmatch.html#module-fnmatch>`__
+         and `glob <https://docs.python.org/3/library/glob.html>`__.
 
       For more information on how this variable works, see
       ``meta/classes/binconfig.bbclass`` in the :term:`Source Directory`.
@@ -944,7 +937,7 @@
    :term:`BUILDDIR`
       Points to the location of the :term:`Build Directory`.
       You can define this directory indirectly through the
-      ````` <#structure-core-script>`__ script by passing in a Build
+      :ref:`structure-core-script` script by passing in a Build
       Directory path when you run the script. If you run the script and do
       not provide a Build Directory path, the ``BUILDDIR`` defaults to
       ``build`` in the current directory.
@@ -1133,10 +1126,8 @@
 
       .. note::
 
-         CLASSOVERRIDE
-         gets its default "class-target" value from the
-         bitbake.conf
-         file.
+         ``CLASSOVERRIDE`` gets its default "class-target" value from the
+         ``bitbake.conf`` file.
 
       As an example, the following override allows you to install extra
       files, but only when building for the target:
@@ -1208,13 +1199,10 @@
 
       .. note::
 
-         The
-         COMPLEMENTARY_GLOB
-         variable uses Unix filename pattern matching (
-         fnmatch
-         ), which is similar to the Unix style pathname pattern expansion (
-         glob
-         ).
+         The ``COMPLEMENTARY_GLOB`` variable uses Unix filename pattern matching
+         (`fnmatch <https://docs.python.org/3/library/fnmatch.html#module-fnmatch>`__),
+         which is similar to the Unix style pathname pattern expansion
+         (`glob <https://docs.python.org/3/library/glob.html>`__).
 
       The resulting list of complementary packages is associated with an
       item that can be added to
@@ -1274,22 +1262,12 @@
 
       .. note::
 
-         When specifying paths as part of the
-         CONFFILES
-         variable, it is good practice to use appropriate path variables.
-         For example,
-         ${sysconfdir}
-         rather than
-         /etc
-         or
-         ${bindir}
-         rather than
-         /usr/bin
-         . You can find a list of these variables at the top of the
-         meta/conf/bitbake.conf
-         file in the
-         Source Directory
-         .
+         When specifying paths as part of the ``CONFFILES`` variable, it is
+         good practice to use appropriate path variables.
+         For example, ``${sysconfdir}`` rather than ``/etc`` or ``${bindir}``
+         rather than ``/usr/bin``. You can find a list of these variables at
+         the top of the ``meta/conf/bitbake.conf`` file in the
+         :term:`Source Directory`.
 
    :term:`CONFIG_INITRAMFS_SOURCE`
       Identifies the initial RAM filesystem (initramfs) source files. The
@@ -1339,11 +1317,8 @@
 
       .. note::
 
-         The
-         COPYLEFT_LICENSE_EXCLUDE
-         variable takes precedence over the
-         COPYLEFT_LICENSE_INCLUDE
-         variable.
+         The ``COPYLEFT_LICENSE_EXCLUDE`` variable takes precedence over the
+         :term:`COPYLEFT_LICENSE_INCLUDE` variable.
 
       The default value, which is "CLOSED Proprietary", for
       ``COPYLEFT_LICENSE_EXCLUDE`` is set by the
@@ -1410,15 +1385,12 @@
 
       .. note::
 
-         The
-         COPY_LIC_DIRS
-         does not offer a path for adding licenses for newly installed
-         packages to an image, which might be most suitable for read-only
-         filesystems that cannot be upgraded. See the
-         LICENSE_CREATE_PACKAGE
-         variable for additional information. You can also reference the "
-         Providing License Text
-         " section in the Yocto Project Development Tasks Manual for
+         The ``COPY_LIC_DIRS`` does not offer a path for adding licenses for
+         newly installed packages to an image, which might be most suitable for
+         read-only filesystems that cannot be upgraded. See the
+         :term:`LICENSE_CREATE_PACKAGE` variable for additional information.
+         You can also reference the ":ref:`dev-manual/dev-manual-common-tasks:providing license text`"
+         section in the Yocto Project Development Tasks Manual for
          information on providing license text.
 
    :term:`COPY_LIC_MANIFEST`
@@ -1429,15 +1401,12 @@
 
       .. note::
 
-         The
-         COPY_LIC_MANIFEST
-         does not offer a path for adding licenses for newly installed
-         packages to an image, which might be most suitable for read-only
-         filesystems that cannot be upgraded. See the
-         LICENSE_CREATE_PACKAGE
-         variable for additional information. You can also reference the "
-         Providing License Text
-         " section in the Yocto Project Development Tasks Manual for
+         The ``COPY_LIC_MANIFEST`` does not offer a path for adding licenses for
+         newly installed packages to an image, which might be most suitable for
+         read-only filesystems that cannot be upgraded. See the
+         :term:`LICENSE_CREATE_PACKAGE` variable for additional information.
+         You can also reference the ":ref:`dev-manual/dev-manual-common-tasks:providing license text`"
+         section in the Yocto Project Development Tasks Manual for
          information on providing license text.
 
    :term:`CORE_IMAGE_EXTRA_INSTALL`
@@ -1500,8 +1469,7 @@
 
       .. note::
 
-         The OpenEmbedded build system sets the
-         CROSS_COMPILE
+         The OpenEmbedded build system sets the ``CROSS_COMPILE``
          variable only in certain contexts (e.g. when building for kernel
          and kernel module recipes).
 
@@ -1541,8 +1509,7 @@
       .. note::
 
          Tasks that read from or write to this directory should run under
-         fakeroot
-         .
+         :ref:`fakeroot <overview-manual/overview-manual-concepts:fakeroot and pseudo>`.
 
    :term:`DATE`
       The date the build was started. Dates appear using the year, month,
@@ -1593,12 +1560,9 @@
 
       .. note::
 
-         The bias provided by
-         DEFAULT_PREFERENCE
-         is weak and is overridden by
-         BBFILE_PRIORITY
-         if that variable is different between two layers that contain
-         different versions of the same recipe.
+         The bias provided by ``DEFAULT_PREFERENCE`` is weak and is overridden
+         by :term:`BBFILE_PRIORITY` if that variable is different between two
+         layers that contain different versions of the same recipe.
 
    :term:`DEFAULTTUNE`
       The default CPU and Application Binary Interface (ABI) tunings (i.e.
@@ -1635,8 +1599,7 @@
 
       .. note::
 
-         It seldom is necessary to reference, for example,
-         STAGING_DIR_HOST
+         It seldom is necessary to reference, for example, ``STAGING_DIR_HOST``
          explicitly. The standard classes and build-related variables are
          configured to automatically use the appropriate staging sysroots.
 
@@ -1807,7 +1770,7 @@
       is set in the ``deploy`` class as follows:
       ::
 
-         DEPLOYDIR = "${WORKDIR}/deploy-${:term:`PN`}"
+         DEPLOYDIR = "${WORKDIR}/deploy-${PN}"
 
       Recipes inheriting the ``deploy`` class should copy files to be
       deployed into ``DEPLOYDIR``, and the class will take care of copying
@@ -1844,12 +1807,9 @@
 
       .. note::
 
-         If the
-         DISTRO
-         variable is blank, a set of default configurations are used, which
-         are specified within
-         meta/conf/distro/defaultsetup.conf
-         also in the Source Directory.
+         If the ``DISTRO`` variable is blank, a set of default configurations
+         are used, which are specified within
+         ``meta/conf/distro/defaultsetup.conf`` also in the Source Directory.
 
    :term:`DISTRO_CODENAME`
       Specifies a codename for the distribution being built.
@@ -1884,8 +1844,7 @@
 
       Two more examples are Bluetooth and NFS support. For a more complete
       list of features that ships with the Yocto Project and that you can
-      provide with this variable, see the "`Distro
-      Features <#ref-features-distro>`__" section.
+      provide with this variable, see the ":ref:`ref-features-distro`" section.
 
    :term:`DISTRO_FEATURES_BACKFILL`
       Features to be added to ``DISTRO_FEATURES`` if not also present in
@@ -1894,15 +1853,13 @@
       This variable is set in the ``meta/conf/bitbake.conf`` file. It is
       not intended to be user-configurable. It is best to just reference
       the variable to see which distro features are being backfilled for
-      all distro configurations. See the "`Feature
-      Backfilling <#ref-features-backfill>`__" section for more
-      information.
+      all distro configurations. See the ":ref:`ref-features-backfill`" section
+      for more information.
 
    :term:`DISTRO_FEATURES_BACKFILL_CONSIDERED`
       Features from ``DISTRO_FEATURES_BACKFILL`` that should not be
       backfilled (i.e. added to ``DISTRO_FEATURES``) during the build. See
-      the "`Feature Backfilling <#ref-features-backfill>`__" section for
-      more information.
+      the ":ref:`ref-features-backfill`" section for more information.
 
    :term:`DISTRO_FEATURES_DEFAULT`
       A convenience variable that gives you the default list of distro
@@ -1973,12 +1930,9 @@
 
       .. note::
 
-         If the
-         DISTRO_NAME
-         variable is blank, a set of default configurations are used, which
-         are specified within
-         meta/conf/distro/defaultsetup.conf
-         also in the Source Directory.
+         If the ``DISTRO_NAME`` variable is blank, a set of default
+         configurations are used, which are specified within
+         ``meta/conf/distro/defaultsetup.conf`` also in the Source Directory.
 
    :term:`DISTRO_VERSION`
       The version of the distribution.
@@ -2028,8 +1982,7 @@
       You can safely share this directory between multiple builds on the
       same development machine. For additional information on how the build
       process gets source files when working behind a firewall or proxy
-      server, see this specific question in the
-      "`FAQ <#how-does-the-yocto-project-obtain-source-code-and-will-it-work-behind-my-firewall-or-proxy-server>`__"
+      server, see this specific question in the ":doc:`faq`"
       chapter. You can also refer to the
       ":yocto_wiki:`Working Behind a Network Proxy </wiki/Working_Behind_a_Network_Proxy>`"
       Wiki page.
@@ -2089,12 +2042,10 @@
       .. note::
 
          The shared libraries resolver's functionality results in part from
-         the internal function
-         package_do_shlibs
-         , which is part of the
-         do_package
-         task. You should be aware that the shared libraries resolver might
-         implicitly define some dependencies between packages.
+         the internal function ``package_do_shlibs``, which is part of the
+         :ref:`ref-tasks-package` task. You should be aware that the shared
+         libraries resolver might implicitly define some dependencies between
+         packages.
 
       The ``EXCLUDE_FROM_SHLIBS`` variable is similar to the
       :term:`PRIVATE_LIBS` variable, which excludes a
@@ -2117,13 +2068,10 @@
 
       .. note::
 
-         Recipes added to
-         EXCLUDE_FROM_WORLD
-         may still be built during a world build in order to satisfy
-         dependencies of other recipes. Adding a recipe to
-         EXCLUDE_FROM_WORLD
-         only ensures that the recipe is not explicitly added to the list
-         of build targets in a world build.
+         Recipes added to ``EXCLUDE_FROM_WORLD`` may still be built during a
+         world build in order to satisfy dependencies of other recipes. Adding
+         a recipe to ``EXCLUDE_FROM_WORLD`` only ensures that the recipe is not
+         explicitly added to the list of build targets in a world build.
 
    :term:`EXTENDPE`
       Used with file and pathnames to create a prefix for a recipe's
@@ -2205,8 +2153,7 @@
       .. note::
 
          To enable primary features from within the image recipe, use the
-         IMAGE_FEATURES
-         variable.
+         :term:`IMAGE_FEATURES` variable.
 
       Here are some examples of features you can add:
 
@@ -2215,8 +2162,8 @@
 
         - "debug-tweaks" - Makes an image suitable for debugging. For example, allows root logins without passwords and
           enables post-installation logging. See the 'allow-empty-password' and
-          'post-install-logging' features in the "`Image
-          Features <#ref-features-image>`__" section for more information.
+          'post-install-logging' features in the ":ref:`ref-features-image`"
+          section for more information.
         - "dev-pkgs" - Adds -dev packages for all installed packages. This is
           useful if you want to develop against the libraries in the image.
         - "read-only-rootfs" - Creates an image whose root filesystem is
@@ -2231,7 +2178,7 @@
           such as ts_print, aplay, arecord and so forth.
 
       For a complete list of image features that ships with the Yocto
-      Project, see the "`Image Features <#ref-features-image>`__" section.
+      Project, see the ":ref:`ref-features-image`" section.
 
       For an example that shows how to customize your image by using this
       variable, see the ":ref:`usingpoky-extend-customimage-imagefeatures`"
@@ -2258,8 +2205,7 @@
       .. note::
 
          To add packages to the root filesystem, see the various
-         \*RDEPENDS and \*RRECOMMENDS
-         variables.
+         \*:term:`RDEPENDS` and \*:term:`RRECOMMENDS` variables.
 
    :term:`EXTRANATIVEPATH`
       A list of subdirectories of
@@ -2332,13 +2278,10 @@
 
       .. note::
 
-         Packages installed by features defined through
-         FEATURE_PACKAGES
+         Packages installed by features defined through ``FEATURE_PACKAGES``
          are often package groups. While similarly named, you should not
-         confuse the
-         FEATURE_PACKAGES
-         variable with package groups, which are discussed elsewhere in the
-         documentation.
+         confuse the ``FEATURE_PACKAGES`` variable with package groups, which
+         are discussed elsewhere in the documentation.
 
    :term:`FEED_DEPLOYDIR_BASE_URI`
       Points to the base URL of the server and location within the
@@ -2471,9 +2414,7 @@
       .. note::
 
          For a layer that supports a single BSP, the override could just be
-         the value of
-         MACHINE
-         .
+         the value of ``MACHINE``.
 
       By prepending paths in ``.bbappend`` files, you allow multiple append
       files that reside in different layers but are used for the same
@@ -2498,10 +2439,9 @@
 
       .. note::
 
-         Do not hand-edit the
-         FILESOVERRIDES
-         variable. The values match up with expected overrides and are used
-         in an expected manner by the build system.
+         Do not hand-edit the ``FILESOVERRIDES`` variable. The values match up
+         with expected overrides and are used in an expected manner by the
+         build system.
 
    :term:`FILESPATH`
       The default set of directories the OpenEmbedded build system uses
@@ -2674,11 +2614,8 @@
 
       .. note::
 
-         If you specifically remove the locale
-         en_US.UTF-8
-         , you must set
-         IMAGE_LINGUAS
-         appropriately.
+         If you specifically remove the locale ``en_US.UTF-8``, you must set
+         :term:`IMAGE_LINGUAS` appropriately.
 
       You can set ``GLIBC_GENERATE_LOCALES`` in your ``local.conf`` file.
       By default, all locales are generated.
@@ -2771,7 +2708,7 @@
       -  :term:`TARGET_CC_ARCH` when building for the
          target
 
-      -  ``BUILD_CC_ARCH`` when building for the build host (i.e.
+      -  :term:`BUILD_CC_ARCH` when building for the build host (i.e.
          ``-native``)
 
       -  ``BUILDSDK_CC_ARCH`` when building for an SDK (i.e.
@@ -2870,9 +2807,7 @@
       .. note::
 
          The options passed affect builds on all enabled machines on the
-         network, which are machines running the
-         iceccd
-         daemon.
+         network, which are machines running the ``iceccd`` daemon.
 
       If your enabled machines support multiple cores, coming up with the
       maximum number of parallel threads that gives you the best
@@ -3046,11 +2981,10 @@
       .. note::
 
          To enable extra features from outside the image recipe, use the
-         EXTRA_IMAGE_FEATURES
-         variable.
+         :term:`EXTRA_IMAGE_FEATURES` variable.
 
       For a list of image features that ships with the Yocto Project, see
-      the "`Image Features <#ref-features-image>`__" section.
+      the ":ref:`ref-features-image`" section.
 
       For an example that shows how to customize your image by using this
       variable, see the ":ref:`usingpoky-extend-customimage-imagefeatures`"
@@ -3104,7 +3038,7 @@
       .. note::
 
          -  When working with a
-            ```core-image-minimal-initramfs`` <#images-core-image-minimal-initramfs>`__
+            :ref:`core-image-minimal-initramfs <ref-manual/ref-images:images>`
             image, do not use the ``IMAGE_INSTALL`` variable to specify
             packages for installation. Instead, use the
             :term:`PACKAGE_INSTALL` variable, which
@@ -3219,10 +3153,8 @@
 
       .. note::
 
-         The
-         package_tar
-         class is broken and is not supported. It is recommended that you
-         do not use it.
+         The ``package_tar`` class is broken and is not supported. It is
+         recommended that you do not use it.
 
       The :ref:`populate_sdk_* <ref-classes-populate-sdk-*>` and
       :ref:`image <ref-classes-image>` classes use the ``IMAGE_PKGTYPE``
@@ -3237,10 +3169,9 @@
 
       .. note::
 
-         Files using the
-         .tar
-         format are never used as a substitute packaging format for DEB,
-         RPM, and IPK formatted files for your image or SDK.
+         Files using the ``.tar`` format are never used as a substitute
+         packaging format for DEB, RPM, and IPK formatted files for your image
+         or SDK.
 
    :term:`IMAGE_POSTPROCESS_COMMAND`
       Specifies a list of functions to call once the OpenEmbedded build
@@ -3447,23 +3378,17 @@
 
          It is possible to define a list of licenses that are allowed to be
          used instead of the licenses that are excluded. To do this, define
-         a variable
-         COMPATIBLE_LICENSES
-         with the names of the licences that are allowed. Then define
-         INCOMPATIBLE_LICENSE
-         as:
+         a variable ``COMPATIBLE_LICENSES`` with the names of the licences
+         that are allowed. Then define ``INCOMPATIBLE_LICENSE`` as:
          ::
 
                  INCOMPATIBLE_LICENSE = "${@' '.join(sorted(set(d.getVar('AVAILABLE_LICENSES').split()) - set(d.getVar('COMPATIBLE_LICENSES').split())))}"
 
 
-         This will result in
-         INCOMPATIBLE_LICENSE
-         containing the names of all licences from
-         AVAILABLE_LICENSES
-         except the ones specified in
-         COMPATIBLE_LICENSES
-         , thus only allowing the latter licences to be used.
+         This will result in ``INCOMPATIBLE_LICENSE`` containing the names of
+         all licences from :term:`AVAILABLE_LICENSES` except the ones specified
+         in ``COMPATIBLE_LICENSES`` , thus only allowing the latter licences to
+         be used.
 
    :term:`INHERIT`
       Causes the named class or classes to be inherited globally. Anonymous
@@ -3536,13 +3461,11 @@
 
       .. note::
 
-         Use of the
-         INHIBIT_SYSROOT_STRIP
-         variable occurs in rare and special circumstances. For example,
-         suppose you are building bare-metal firmware by using an external
-         GCC toolchain. Furthermore, even if the toolchain's binaries are
-         strippable, other files exist that are needed for the build that
-         are not strippable.
+         Use of the ``INHIBIT_SYSROOT_STRIP`` variable occurs in rare and
+         special circumstances. For example, suppose you are building
+         bare-metal firmware by using an external GCC toolchain. Furthermore,
+         even if the toolchain's binaries are strippable, other files exist
+         that are needed for the build that are not strippable.
 
    :term:`INITRAMFS_FSTYPES`
       Defines the format for the output image of an initial RAM filesystem
@@ -3573,13 +3496,10 @@
 
       .. note::
 
-         See the
-         meta/recipes-core/images/core-image-minimal-initramfs.bb
-         recipe in the
-         Source Directory
+         See the ``meta/recipes-core/images/core-image-minimal-initramfs.bb``
+         recipe in the :term:`Source Directory`
          for an example initramfs recipe. To select this sample recipe as
-         the one built to provide the initramfs image, set
-         INITRAMFS_IMAGE
+         the one built to provide the initramfs image, set ``INITRAMFS_IMAGE``
          to "core-image-minimal-initramfs".
 
       You can also find more information by referencing the
@@ -3637,10 +3557,8 @@
 
       .. note::
 
-         You must set the
-         INITRAMFS_IMAGE_BUNDLE
-         variable in a configuration file. You cannot set the variable in a
-         recipe file.
+         You must set the ``INITRAMFS_IMAGE_BUNDLE`` variable in a
+         configuration file. You cannot set the variable in a recipe file.
 
       See the
       :yocto_git:`local.conf.sample.extended </cgit/cgit.cgi/poky/tree/meta-poky/conf/local.conf.sample.extended>`
@@ -3861,7 +3779,7 @@
 
       .. note::
 
-         The IMAGE_VERSION_SUFFIX variable is set to DATETIME.
+         The ``IMAGE_VERSION_SUFFIX`` variable is set to :term:`DATETIME`.
 
    :term:`KERNEL_CLASSES`
       A list of classes defining kernel image types that the
@@ -3879,7 +3797,7 @@
       .. note::
 
          Legacy support exists for specifying the full path to the device
-         tree. However, providing just the .dtb file is preferred.
+         tree. However, providing just the ``.dtb`` file is preferred.
 
       In order to use this variable, the
       :ref:`kernel-devicetree <ref-classes-kernel-devicetree>` class must
@@ -4038,8 +3956,7 @@
 
       .. note::
 
-         This variable replaces the deprecated
-         module_autoload
+         This variable replaces the deprecated :term:`module_autoload`
          variable.
 
       You can use the ``KERNEL_MODULE_AUTOLOAD`` variable anywhere that it
@@ -4234,9 +4151,8 @@
 
       .. note::
 
-         Setting
-         LAYERSERIES_COMPAT
-         is required by the Yocto Project Compatible version 2 standard.
+         Setting ``LAYERSERIES_COMPAT`` is required by the Yocto Project
+         Compatible version 2 standard.
          The OpenEmbedded build system produces a warning if the variable
          is not set for any given layer.
 
@@ -4484,9 +4400,7 @@
       .. note::
 
          Adding additional Board Support Package (BSP) layers to your
-         configuration adds new possible settings for
-         MACHINE
-         .
+         configuration adds new possible settings for ``MACHINE``.
 
    :term:`MACHINE_ARCH`
       Specifies the name of the machine-specific architecture. This
@@ -4551,13 +4465,10 @@
 
       .. note::
 
-         In this example, the
-         kernel-module-ab123
-         recipe needs to explicitly set its
-         PACKAGES
-         variable to ensure that BitBake does not use the kernel recipe's
-         PACKAGES_DYNAMIC
-         variable to satisfy the dependency.
+         In this example, the ``kernel-module-ab123`` recipe needs to
+         explicitly set its :term:`PACKAGES` variable to ensure that BitBake
+         does not use the kernel recipe's :term:`PACKAGES_DYNAMIC` variable to
+         satisfy the dependency.
 
       Some examples of these machine essentials are flash, screen,
       keyboard, mouse, or touchscreen drivers (depending on the machine).
@@ -4625,8 +4536,7 @@
       :term:`IMAGE_FEATURES` variables.
 
       For a list of hardware features supported by the Yocto Project as
-      shipped, see the "`Machine Features <#ref-features-machine>`__"
-      section.
+      shipped, see the ":ref:`ref-features-machine`" section.
 
    :term:`MACHINE_FEATURES_BACKFILL`
       Features to be added to ``MACHINE_FEATURES`` if not also present in
@@ -4635,15 +4545,13 @@
       This variable is set in the ``meta/conf/bitbake.conf`` file. It is
       not intended to be user-configurable. It is best to just reference
       the variable to see which machine features are being backfilled for
-      all machine configurations. See the "`Feature
-      Backfilling <#ref-features-backfill>`__" section for more
-      information.
+      all machine configurations. See the ":ref:`ref-features-backfill`"
+      section for more information.
 
    :term:`MACHINE_FEATURES_BACKFILL_CONSIDERED`
       Features from ``MACHINE_FEATURES_BACKFILL`` that should not be
       backfilled (i.e. added to ``MACHINE_FEATURES``) during the build. See
-      the "`Feature Backfilling <#ref-features-backfill>`__" section for
-      more information.
+      the ":ref:`ref-features-backfill`" section for more information.
 
    :term:`MACHINEOVERRIDES`
       A colon-separated list of overrides that apply to the current
@@ -4660,12 +4568,12 @@
          MACHINEOVERRIDES =. "qemuall:"
 
       This
-      override allows variables to be overriden for all machines emulated
+      override allows variables to be overridden for all machines emulated
       in QEMU, like in the following example from the ``connman-conf``
       recipe:
       ::
 
-         SRC_URI_append_qemuall = "file://wired.config \
+         SRC_URI_append_qemuall = " file://wired.config \
              file://wired-setup \
              "
 
@@ -4697,16 +4605,10 @@
 
       .. note::
 
-         The "ML" in
-         MLPREFIX
-         stands for "MultiLib". This representation is historical and comes
-         from a time when
-         nativesdk
-         was a suffix rather than a prefix on the recipe name. When
-         nativesdk
-         was turned into a prefix, it made sense to set
-         MLPREFIX
-         for it as well.
+         The "ML" in ``MLPREFIX`` stands for "MultiLib". This representation is
+         historical and comes from a time when ``nativesdk`` was a suffix
+         rather than a prefix on the recipe name. When ``nativesdk`` was turned
+         into a prefix, it made sense to set ``MLPREFIX`` for it as well.
 
       To help understand when ``MLPREFIX`` might be needed, consider when
       :term:`BBCLASSEXTEND` is used to provide a
@@ -4891,7 +4793,7 @@
 
          Some recommended packages might be required for certain system
          functionality, such as kernel modules. It is up to you to add
-         packages with the IMAGE_INSTALL variable.
+         packages with the :term:`IMAGE_INSTALL` variable.
 
       Support for this variable exists only when using the IPK and RPM
       packaging backend. Support does not exist for DEB.
@@ -4969,7 +4871,7 @@
    :term:`OEROOT`
       The directory from which the top-level build environment setup script
       is sourced. The Yocto Project provides a top-level build environment
-      setup script: ````` <#structure-core-script>`__. When you run this
+      setup script: :ref:`structure-core-script`. When you run this
       script, the ``OEROOT`` variable resolves to the directory that
       contains the script.
 
@@ -5020,14 +4922,10 @@
 
       .. note::
 
-         An easy way to see what overrides apply is to search for
-         OVERRIDES
-         in the output of the
-         bitbake -e
-         command. See the "
-         Viewing Variable Values
-         " section in the Yocto Project Development Tasks Manual for more
-         information.
+         An easy way to see what overrides apply is to search for ``OVERRIDES``
+         in the output of the ``bitbake -e`` command. See the
+         ":ref:`dev-debugging-viewing-variable-values`" section in the Yocto
+         Project Development Tasks Manual for more information.
 
    :term:`P`
       The recipe name and version. ``P`` is comprised of the following:
@@ -5062,9 +4960,7 @@
 
       .. note::
 
-         See
-         SDK_ARCH
-         for more information.
+         See :term:`SDK_ARCH` for more information.
 
       However, if your recipe's output packages are built specific to the
       target machine rather than generally for the architecture of the
@@ -5098,8 +4994,7 @@
 
       .. note::
 
-         While it is a legal option, the
-         package_tar
+         While it is a legal option, the ``package_tar``
          class has limited functionality due to no support for package
          dependencies by that backend. Therefore, it is recommended that
          you do not use it.
@@ -5209,8 +5104,7 @@
 
       .. note::
 
-         You can use the
-         PACKAGE_FEEDS_ARCHS
+         You can use the ``PACKAGE_FEEDS_ARCHS``
          variable to whitelist specific package architectures. If you do
          not need to whitelist specific architectures, which is a common
          case, you can omit this variable. Omitting the variable results in
@@ -5228,7 +5122,8 @@
          PACKAGE_FEED_ARCHS = "all core2-64"
 
       Given these settings, the resulting package feeds are as follows:
-      ::
+
+      .. code-block:: none
 
          https://example.com/packagerepos/release/rpm/all
          https://example.com/packagerepos/release/rpm/core2-64
@@ -5257,7 +5152,8 @@
          PACKAGE_FEED_ARCHS = "all core2-64"
 
       Given these settings, the resulting package feeds are as follows:
-      ::
+
+      .. code-block:: none
 
          https://example.com/packagerepos/release/rpm/all
          https://example.com/packagerepos/release/rpm/core2-64
@@ -5286,7 +5182,8 @@
          PACKAGE_FEED_ARCHS = "all core2-64"
 
       Given these settings, the resulting package feeds are as follows:
-      ::
+
+      .. code-block:: none
 
          https://example.com/packagerepos/release/rpm/all
          https://example.com/packagerepos/release/rpm/core2-64
@@ -5308,8 +5205,7 @@
       general, you should use the
       :term:`IMAGE_INSTALL` variable to specify
       packages for installation. The exception to this is when working with
-      the
-      ```core-image-minimal-initramfs`` <#images-core-image-minimal-initramfs>`__
+      the :ref:`core-image-minimal-initramfs <ref-manual/ref-images:images>`
       image. When working with an initial RAM filesystem (initramfs) image,
       use the ``PACKAGE_INSTALL`` variable. For information on creating an
       initramfs, see the ":ref:`building-an-initramfs-image`" section
@@ -5424,8 +5320,11 @@
          block through an append file except you edit your ``local.conf``
          or ``mydistro.conf`` file. As with append files previously
          described, you can either completely override the variable:
-         PACKAGECONFIG_pn-recipename = "f4 f5" Or, you can just amend the
-         variable:
+         ::
+
+            PACKAGECONFIG_pn-recipename = "f4 f5"
+
+         Or, you can just amend the variable:
          ::
 
             PACKAGECONFIG_append_pn-recipename = " f4"
@@ -5511,17 +5410,9 @@
 
       .. note::
 
-         In order for
-         PARALLEL_MAKE
-         to be effective,
-         make
-         must be called with
-         ${
-         EXTRA_OEMAKE
-         }
-         . An easy way to ensure this is to use the
-         oe_runmake
-         function.
+         In order for ``PARALLEL_MAKE`` to be effective, ``make`` must be
+         called with ``${``\ :term:`EXTRA_OEMAKE`\ ``}``. An easy way to ensure
+         this is to use the ``oe_runmake`` function.
 
       By default, the OpenEmbedded build system automatically sets this
       variable to be equal to the number of cores the build system uses.
@@ -5529,14 +5420,11 @@
       .. note::
 
          If the software being built experiences dependency issues during
-         the
-         do_compile
-         task that result in race conditions, you can clear the
-         PARALLEL_MAKE
-         variable within the recipe as a workaround. For information on
-         addressing race conditions, see the "
-         Debugging Parallel Make Races
-         " section in the Yocto Project Development Tasks Manual.
+         the ``do_compile`` task that result in race conditions, you can clear
+         the ``PARALLEL_MAKE`` variable within the recipe as a workaround. For
+         information on addressing race conditions, see the
+         ":ref:`dev-manual/dev-manual-common-tasks:debugging parallel make races`"
+         section in the Yocto Project Development Tasks Manual.
 
       For single socket systems (i.e. one CPU), you should not have to
       override this variable to gain optimal parallelism during builds.
@@ -5623,9 +5511,7 @@
 
       .. note::
 
-         When using the
-         PKG
-         variable, you must use a package name override.
+         When using the ``PKG`` variable, you must use a package name override.
 
       For example, when the :ref:`debian <ref-classes-debian>` class
       renames the output package, it does so by setting
@@ -5768,14 +5654,11 @@
 
       .. note::
 
-         The OpenEmbedded build system does not need the aid of
-         PR
+         The OpenEmbedded build system does not need the aid of ``PR``
          to know when to rebuild a recipe. The build system uses the task
-         input checksums
-         along with the
-         stamp
-         and
-         shared state cache
+         :ref:`input checksums <overview-checksums>` along with the
+         :ref:`stamp <structure-build-tmp-stamps>` and
+         :ref:`overview-manual/overview-manual-concepts:shared state cache`
          mechanisms.
 
       The ``PR`` variable primarily becomes significant when a package
@@ -5790,8 +5673,7 @@
 
       .. note::
 
-         PR
-         does not need to be increased for changes that do not change the
+         ``PR`` does not need to be increased for changes that do not change the
          package contents or metadata.
 
       Because manually managing ``PR`` can be cumbersome and error-prone,
@@ -5826,17 +5708,11 @@
 
       .. note::
 
-         If you use a
-         virtual/\*
-         item with
-         PREFERRED_PROVIDER
-         , then any recipe that
-         PROVIDES
-         that item but is not selected (defined) by
-         PREFERRED_PROVIDER
-         is prevented from building, which is usually desirable since this
-         mechanism is designed to select between mutually exclusive
-         alternative providers.
+         If you use a ``virtual/\*`` item with ``PREFERRED_PROVIDER``, then any
+         recipe that :term:`PROVIDES` that item but is not selected (defined)
+         by ``PREFERRED_PROVIDER`` is prevented from building, which is usually
+         desirable since this mechanism is designed to select between mutually
+         exclusive alternative providers.
 
    :term:`PREFERRED_VERSION`
       If multiple versions of recipes exist, this variable determines which
@@ -5897,8 +5773,8 @@
 
       .. note::
 
-         The \_forcevariable override is not handled specially. This override
-         only works because the default value of OVERRIDES includes "forcevariable".
+         The ``\_forcevariable`` override is not handled specially. This override
+         only works because the default value of ``OVERRIDES`` includes "forcevariable".
 
    :term:`PREMIRRORS`
       Specifies additional paths from which the OpenEmbedded build system
@@ -5988,9 +5864,7 @@
       .. note::
 
          Given that a recipe's own recipe name is already implicitly in its
-         own
-         PROVIDES
-         list, it is unnecessary to add aliases with the "+=" operator;
+         own PROVIDES list, it is unnecessary to add aliases with the "+=" operator;
          using a simple assignment will be sufficient. In other words,
          while you could write:
          ::
@@ -6122,8 +5996,15 @@
 
          RCONFLICTS_${PN} = "package (operator version)"
 
-      For ``operator``, you can specify the following: = < > <=
-      >= For example, the following sets up a dependency on version 1.2 or
+      For ``operator``, you can specify the following:
+
+      - =
+      - <
+      - >
+      - <=
+      - >=
+
+      For example, the following sets up a dependency on version 1.2 or
       greater of the package ``foo``:
       ::
 
@@ -6149,7 +6030,7 @@
       The practical effect of the above ``RDEPENDS`` assignment is that
       ``bar`` and ``baz`` will be declared as dependencies inside the
       package ``foo`` when it is written out by one of the
-      ```do_package_write_*`` <#ref-tasks-package_write_deb>`__ tasks.
+      :ref:`do_package_write_\* <ref-tasks-package_write_deb>` tasks.
       Exactly how this is done depends on which package format is used,
       which is determined by
       :term:`PACKAGE_CLASSES`. When the
@@ -6188,19 +6069,11 @@
 
       .. note::
 
-         RDEPENDS_${PN}-dev
-         includes
-         ${
-         PN
-         }
+         ``RDEPENDS_${PN}-dev`` includes ``${``\ :term:`PN`\ ``}``
          by default. This default is set in the BitBake configuration file
-         (
-         meta/conf/bitbake.conf
-         ). Be careful not to accidentally remove
-         ${PN}
-         when modifying
-         RDEPENDS_${PN}-dev
-         . Use the "+=" operator rather than the "=" operator.
+         (``meta/conf/bitbake.conf``). Be careful not to accidentally remove
+         ``${PN}`` when modifying ``RDEPENDS_${PN}-dev``. Use the "+=" operator
+         rather than the "=" operator.
 
       The package names you use with ``RDEPENDS`` must appear as they would
       in the ``PACKAGES`` variable. The :term:`PKG` variable
@@ -6219,14 +6092,20 @@
 
          RDEPENDS_${PN} = "package (operator version)"
 
-      For operator, you can specify the following: = < > <= >= For version,
-      provide the version number.
+      For ``operator``, you can specify the following:
+
+      - =
+      - <
+      - >
+      - <=
+      - >=
+
+      For version, provide the version number.
 
       .. note::
 
-         You can use
-         EXTENDPKGV
-         to provide a full package version specification.
+         You can use ``EXTENDPKGV`` to provide a full package version
+         specification.
 
       For example, the following sets up a dependency on version 1.2 or
       greater of the package ``foo``:
@@ -6355,9 +6234,7 @@
 
       .. note::
 
-         A package's own name is implicitly already in its
-         RPROVIDES
-         list.
+         A package's own name is implicitly already in its ``RPROVIDES`` list.
 
       As with all package-controlling variables, you must always use the
       variable in conjunction with a package name override. Here is an
@@ -6546,13 +6423,8 @@
 
       .. note::
 
-         The
-         SDK_DIR
-         directory is a temporary directory as it is part of
-         WORKDIR
-         . The final output directory is
-         SDK_DEPLOY
-         .
+         The ``SDK_DIR`` directory is a temporary directory as it is part of
+         ``WORKDIR``. The final output directory is :term:`SDK_DEPLOY`.
 
    :term:`SDK_EXT_TYPE`
       Controls whether or not shared state artifacts are copied into the
@@ -6563,9 +6435,8 @@
       .. note::
 
          If you set the variable to "minimal", you need to ensure
-         SSTATE_MIRRORS
-         is set in the SDK's configuration to enable the artifacts to be
-         fetched as needed.
+         :term:`SSTATE_MIRRORS` is set in the SDK's configuration to enable the
+         artifacts to be fetched as needed.
 
    :term:`SDK_HOST_MANIFEST`
       The manifest file for the host part of the SDK. This file lists all
@@ -6594,8 +6465,7 @@
 
       .. note::
 
-         Enabling the
-         SDK_INCLUDE_PKGDATA
+         Enabling the ``SDK_INCLUDE_PKGDATA``
          variable significantly increases build time because all of world
          needs to be built. Enabling the variable also slightly increases
          the size of the extensible SDK.
@@ -6702,9 +6572,9 @@
 
       .. note::
 
-         The SDK_OUTPUT directory is a temporary directory as it is part of
-         WORKDIR by way of SDK_DIR. The final output directory is
-         SDK_DEPLOY.
+         The ``SDK_OUTPUT`` directory is a temporary directory as it is part of
+         :term:`WORKDIR` by way of :term:`SDK_DIR`. The final output directory is
+         :term:`SDK_DEPLOY`.
 
    :term:`SDK_PACKAGE_ARCHS`
       Specifies a list of architectures compatible with the SDK machine.
@@ -6859,8 +6729,7 @@
 
       .. note::
 
-         You cannot set the
-         SDKMACHINE
+         You cannot set the ``SDKMACHINE``
          variable in your distribution configuration file. If you do, the
          configuration will not take affect.
 
@@ -6900,11 +6769,8 @@
 
       .. note::
 
-         The
-         SERIAL_CONSOLE
-         variable is deprecated. Please use the
-         SERIAL_CONSOLES
-         variable.
+         The ``SERIAL_CONSOLE`` variable is deprecated. Please use the
+         :term:`SERIAL_CONSOLES` variable.
 
    :term:`SERIAL_CONSOLES`
       Defines a serial console (TTY) to enable using
@@ -6996,11 +6862,8 @@
 
       .. note::
 
-         You must include
-         conf/machine/include/soc-family.inc
-         for this variable to appear in
-         MACHINEOVERRIDES
-         .
+         You must include ``conf/machine/include/soc-family.inc`` for this
+         variable to appear in :term:`MACHINEOVERRIDES`.
 
    :term:`SOLIBS`
       Defines the suffix for shared libraries used on the target platform.
@@ -7033,8 +6896,7 @@
 
       .. note::
 
-         Do not set the
-         SOURCE_MIRROR_FETCH
+         Do not set the ``SOURCE_MIRROR_FETCH``
          variable unless you are creating a source mirror. In other words,
          do not set the variable during a normal build.
 
@@ -7053,9 +6915,7 @@
 
       .. note::
 
-         You can specify only a single URL in
-         SOURCE_MIRROR_URL
-         .
+         You can specify only a single URL in ``SOURCE_MIRROR_URL``.
 
    :term:`SPDXLICENSEMAP`
       Maps commonly used license names to their SPDX counterparts found in
@@ -7236,8 +7096,18 @@
          tree when using the Git fetcher is used.
 
       -  ``name`` - Specifies a name to be used for association with
-         ``SRC_URI`` checksums when you have more than one file specified
-         in ``SRC_URI``.
+         ``SRC_URI`` checksums or :term:`SRCREV` when you have more than one
+         file or git repository specified in ``SRC_URI``. For example:
+         ::
+
+            SRC_URI = "git://example.com/foo.git;name=first \
+                       git://example.com/bar.git;name=second \
+                       http://example.com/file.tar.gz;name=third"
+
+            SRCREV_first = "f1d2d2f924e986ac86fdf7b36c94bcdf32beec15"
+            SRCREV_second = "e242ed3bffccdf271b7fbaf34ed72d089537b42f"
+            SRC_URI[third.sha256sum] = "13550350a8681c84c861aac2e5b440161c2b33a3e4f302ac680ca5b686de48de"
+
 
       -  ``downloadfilename`` - Specifies the filename used when storing
          the downloaded file.
@@ -7283,13 +7153,10 @@
       .. note::
 
          For information on limitations when inheriting the latest revision
-         of software using
-         SRCREV
-         , see the
-         AUTOREV
-         variable description and the "
-         Automatically Incrementing a Binary Package Revision Number
-         " section, which is in the Yocto Project Development Tasks Manual.
+         of software using ``SRCREV``, see the :term:`AUTOREV` variable
+         description and the
+         ":ref:`automatically-incrementing-a-binary-package-revision-number`"
+         section, which is in the Yocto Project Development Tasks Manual.
 
    :term:`SSTATE_DIR`
       The directory for the shared state cache.
@@ -7379,13 +7246,9 @@
       .. note::
 
          This style of build configuration has been largely replaced by
-         pkg-config
-         . Consequently, if
-         pkg-config
-         is supported by the library to which you are linking, it is
-         recommended you use
-         pkg-config
-         instead of a provided configuration script.
+         ``pkg-config``. Consequently, if ``pkg-config`` is supported by the
+         library to which you are linking, it is recommended you use
+         ``pkg-config`` instead of a provided configuration script.
 
    :term:`STAGING_BINDIR_NATIVE`
       Specifies the path to the ``/usr/bin`` subdirectory of the sysroot
@@ -7414,15 +7277,10 @@
 
       .. note::
 
-         Recipes should never write files directly under the
-         STAGING_DIR
+         Recipes should never write files directly under the ``STAGING_DIR``
          directory because the OpenEmbedded build system manages the
          directory automatically. Instead, files should be installed to
-         ${
-         D
-         }
-         within your recipe's
-         do_install
+         ``${``\ :term:`D`\ ``}`` within your recipe's :ref:`ref-tasks-install`
          task and then the OpenEmbedded build system will stage a subset of
          those files into the sysroot.
 
@@ -7668,12 +7526,9 @@
 
       .. note::
 
-         Programs built by
-         -native
-         recipes run directly from the sysroot (
-         STAGING_DIR_NATIVE
-         ), which is why additional directories containing program
-         executables and supporting files need to be staged.
+         Programs built by ``-native`` recipes run directly from the sysroot
+         (:term:`STAGING_DIR_NATIVE`), which is why additional directories
+         containing program executables and supporting files need to be staged.
 
    :term:`SYSROOT_PREPROCESS_FUNCS`
       A list of functions to execute after files are staged into the
@@ -7819,14 +7674,9 @@
 
       .. note::
 
-         It is a common workaround to append
-         LDFLAGS
-         to
-         TARGET_CC_ARCH
-         in recipes that build software for the target that would not
-         otherwise respect the exported
-         LDFLAGS
-         variable.
+         It is a common workaround to append :term:`LDFLAGS` to
+         ``TARGET_CC_ARCH`` in recipes that build software for the target that
+         would not otherwise respect the exported ``LDFLAGS`` variable.
 
    :term:`TARGET_CC_KERNEL_ARCH`
       This is a specific kernel compiler flag for a CPU or Application
@@ -7929,7 +7779,7 @@
 
       .. note::
 
-         You do not need to set the TARGET_SYS variable yourself.
+         You do not need to set the ``TARGET_SYS`` variable yourself.
 
       Consider these two examples:
 
@@ -7973,16 +7823,13 @@
 
       .. note::
 
-         If
-         TCMODE
-         is set to a value other than "default", then it is your
+         If ``TCMODE`` is set to a value other than "default", then it is your
          responsibility to ensure that the toolchain is compatible with the
          default toolchain. Using older or newer versions of these
          components might cause build problems. See the Release Notes for
          the Yocto Project release for the specific components with which
          the toolchain must be compatible. To access the Release Notes, go
-         to the
-         Downloads
+         to the :yocto_home:`Downloads </software-overview/downloads>`
          page on the Yocto Project website and click on the "RELEASE
          INFORMATION" link for the appropriate release.
 
@@ -8026,11 +7873,8 @@
 
       .. note::
 
-         Actual test results reside in the task log (
-         log.do_testimage
-         ), which is in the
-         ${WORKDIR}/temp/
-         directory.
+         Actual test results reside in the task log (``log.do_testimage``),
+         which is in the ``${WORKDIR}/temp/`` directory.
 
    :term:`TEST_POWERCONTROL_CMD`
       For automated hardware testing, specifies the command to use to
@@ -8089,12 +7933,9 @@
 
       .. note::
 
-         The
-         TEST_SERVER_IP
-         variable is only used for a small number of tests such as the
-         "dnf" test suite, which needs to download packages from
-         WORKDIR/oe-rootfs-repo
-         .
+         The ``TEST_SERVER_IP`` variable is only used for a small number of
+         tests such as the "dnf" test suite, which needs to download packages
+         from ``WORKDIR/oe-rootfs-repo``.
 
    :term:`TEST_SUITES`
       An ordered list of tests (modules) to run against an image when
@@ -8169,8 +8010,7 @@
          .. note::
 
             This argument is defined in
-            meta/lib/oeqa/controllers/simpleremote.py
-            .
+            ``meta/lib/oeqa/controllers/simpleremote.py``.
 
       For information on running tests on hardware, see the
       ":ref:`hardware-image-enabling-tests`"
@@ -8304,7 +8144,7 @@
    :term:`TOPDIR`
       The top-level :term:`Build Directory`. BitBake
       automatically sets this variable when you initialize your build
-      environment using ````` <#structure-core-script>`__.
+      environment using :ref:`structure-core-script`.
 
    :term:`TRANSLATED_TARGET_ARCH`
       A sanitized version of :term:`TARGET_ARCH`. This
@@ -8728,20 +8568,11 @@
       .. note::
 
          There is a difference in behavior between setting
-         USERADD_ERROR_DYNAMIC
-         to
-         error
-         and setting it to
-         warn
-         . When it is set to
-         warn
-         , the build system will report a warning for every undefined
-         uid
-         and
-         gid
-         in any recipe. But when it is set to
-         error
-         , it will only report errors for recipes that are actually built.
+         ``USERADD_ERROR_DYNAMIC`` to ``error`` and setting it to ``warn``.
+         When it is set to ``warn``, the build system will report a warning for
+         every undefined ``uid`` and ``gid`` in any recipe. But when it is set
+         to ``error``, it will only report errors for recipes that are actually
+         built.
          This saves you from having to add static IDs for recipes that you
          know will never be built.
 
@@ -8761,12 +8592,8 @@
 
       .. note::
 
-         Setting the
-         USERADDEXTENSION
-         variable to "useradd-staticids" causes the build system to use
-         static
-         gid
-         values.
+         Setting the :term:`USERADDEXTENSION` variable to "useradd-staticids"
+         causes the build system to use static ``gid`` values.
 
    :term:`USERADD_PACKAGES`
       When inheriting the :ref:`useradd <ref-classes-useradd>` class,
@@ -8782,15 +8609,9 @@
 
       .. note::
 
-         It follows that if you are going to use the
-         USERADD_PACKAGES
-         variable, you need to set one or more of the
-         USERADD_PARAM
-         ,
-         GROUPADD_PARAM
-         , or
-         GROUPMEMS_PARAM
-         variables.
+         It follows that if you are going to use the ``USERADD_PACKAGES``
+         variable, you need to set one or more of the :term:`USERADD_PARAM`,
+         :term:`GROUPADD_PARAM`, or :term:`GROUPMEMS_PARAM` variables.
 
    :term:`USERADD_PARAM`
       When inheriting the :ref:`useradd <ref-classes-useradd>` class,
@@ -8824,12 +8645,8 @@
 
       .. note::
 
-         Setting the
-         USERADDEXTENSION
-         variable to "useradd-staticids" causes the build system to use
-         static
-         uid
-         values.
+         Setting the :term:`USERADDEXTENSION` variable to "useradd-staticids"
+         causes the build system to use static ``uid`` values.
 
    :term:`USERADDEXTENSION`
       When set to "useradd-staticids", causes the OpenEmbedded build system
@@ -8842,13 +8659,9 @@
 
       .. note::
 
-         Setting this variable to use static
-         uid
-         and
-         gid
+         Setting this variable to use static ``uid`` and ``gid``
          values causes the OpenEmbedded build system to employ the
-         useradd-staticids
-         class.
+         :ref:`ref-classes-useradd` class.
 
       If you use static ``uid`` and ``gid`` information, you must also
       specify the ``files/passwd`` and ``files/group`` files by setting the
@@ -8919,22 +8732,13 @@
 
       The actual directory depends on several things:
 
-      -  TMPDIR
-         : The top-level build output directory
-      -  MULTIMACH_TARGET_SYS
-         : The target system identifier
-      -  PN
-         : The recipe name
-      -  EXTENDPE
-         : The epoch - (if
-         PE
-         is not specified, which is usually the case for most recipes, then
-         EXTENDPE
-         is blank)
-      -  PV
-         : The recipe version
-      -  PR
-         : The recipe revision
+      -  :term:`TMPDIR`: The top-level build output directory
+      -  :term:`MULTIMACH_TARGET_SYS`: The target system identifier
+      -  :term:`PN`: The recipe name
+      -  :term:`EXTENDPE`: The epoch - (if :term:`PE` is not specified, which
+         is usually the case for most recipes, then `EXTENDPE` is blank)
+      -  :term:`PV`: The recipe version
+      -  :term:`PR`: The recipe revision
 
       As an example, assume a Source Directory top-level folder name
       ``poky``, a default Build Directory at ``poky/build``, and a
diff --git a/poky/documentation/ref-manual/resources.rst b/poky/documentation/ref-manual/resources.rst
index f90182b..2ef182f 100644
--- a/poky/documentation/ref-manual/resources.rst
+++ b/poky/documentation/ref-manual/resources.rst
@@ -65,27 +65,27 @@
 click on the appropriate URL in the following list and follow the
 instructions:
 
--  https://lists.yoctoproject.org/g/yocto - General Yocto Project
+-  :yocto_lists:`/g/yocto` - General Yocto Project
    discussion mailing list.
 
--  https://lists.openembedded.org/g/openembedded-core - Discussion mailing
+-  :oe_lists:`/g/openembedded-core` - Discussion mailing
    list about OpenEmbedded-Core (the core metadata).
 
--  https://lists.openembedded.org/g/openembedded-devel - Discussion
+-  :oe_lists:`/g/openembedded-devel` - Discussion
    mailing list about OpenEmbedded.
 
--  https://lists.openembedded.org/g/bitbake-devel - Discussion mailing
+-  :oe_lists:`/g/bitbake-devel` - Discussion mailing
    list about the :term:`BitBake` build tool.
 
--  https://lists.yoctoproject.org/g/poky - Discussion mailing list
-   about `Poky <#poky>`__.
+-  :yocto_lists:`/g/poky` - Discussion mailing list
+   about :term:`Poky`.
 
--  https://lists.yoctoproject.org/g/yocto-announce - Mailing list to
+-  :yocto_lists:`/g/yocto-announce` - Mailing list to
    receive official Yocto Project release and milestone announcements.
 
 For more Yocto Project-related mailing lists, see the
-Yocto Project Website
-.
+:yocto_home:`Yocto Project Website <>`.
+
 .. _resources-irc:
 
 Internet Relay Chat (IRC)
@@ -113,12 +113,12 @@
    planning, release engineering, QA & automation, a reference site map,
    and other resources related to the Yocto Project.
 
--  `OpenEmbedded <http://www.openembedded.org/>`__\ *:* The build system used by the
+-  :oe_home:`OpenEmbedded <>`\ *:* The build system used by the
    Yocto Project. This project is the upstream, generic, embedded
    distribution from which the Yocto Project derives its build system
    (Poky) and to which it contributes.
 
--  `BitBake <http://www.openembedded.org/wiki/BitBake>`__\ *:* The tool
+-  :oe_home:`BitBake </wiki/BitBake>`\ *:* The tool
    used to process metadata.
 
 -  :doc:`BitBake User Manual <bitbake:index>`\ *:* A comprehensive
@@ -155,7 +155,7 @@
    manual provides reference material such as variable, task, and class
    descriptions.
 
--  `Yocto Project Mega-Manual <https://docs.yoctoproject.org/singleindex.html>`__\ *:* This manual
+-  :yocto_docs:`Yocto Project Mega-Manual </singleindex.html>`\ *:* This manual
    is simply a single HTML file comprised of the bulk of the Yocto
    Project manuals. The Mega-Manual primarily exists as a vehicle by
    which you can easily search for phrases and terms used in the Yocto
@@ -180,7 +180,7 @@
    the Yocto Project website and click on the "RELEASE INFORMATION" link
    for the appropriate release.
 
--  `Bugzilla <https://bugzilla.yoctoproject.org>`__\ *:* The bug tracking application
+-  :yocto_bugs:`Bugzilla <>`\ *:* The bug tracking application
    the Yocto Project uses. If you find problems with the Yocto Project,
    you should report them using this application.