diff --git a/poky/bitbake/bin/bitbake b/poky/bitbake/bin/bitbake
index 61db6b7..d9a6520 100755
--- a/poky/bitbake/bin/bitbake
+++ b/poky/bitbake/bin/bitbake
@@ -26,7 +26,7 @@
 if sys.getfilesystemencoding() != "utf-8":
     sys.exit("Please use a locale setting which supports UTF-8 (such as LANG=en_US.UTF-8).\nPython can't change the filesystem locale after loading so we need a UTF-8 when Python starts or things won't work.")
 
-__version__ = "1.47.0"
+__version__ = "1.48.0"
 
 if __name__ == "__main__":
     if __version__ != bb.__version__:
diff --git a/poky/bitbake/lib/bb/__init__.py b/poky/bitbake/lib/bb/__init__.py
index 888dd5c..09e161f 100644
--- a/poky/bitbake/lib/bb/__init__.py
+++ b/poky/bitbake/lib/bb/__init__.py
@@ -9,7 +9,7 @@
 # SPDX-License-Identifier: GPL-2.0-only
 #
 
-__version__ = "1.47.0"
+__version__ = "1.48.0"
 
 import sys
 if sys.version_info < (3, 5, 0):
diff --git a/poky/bitbake/lib/bb/fetch2/git.py b/poky/bitbake/lib/bb/fetch2/git.py
index 07064c6..b97967b 100644
--- a/poky/bitbake/lib/bb/fetch2/git.py
+++ b/poky/bitbake/lib/bb/fetch2/git.py
@@ -63,6 +63,7 @@
 import fnmatch
 import os
 import re
+import shlex
 import subprocess
 import tempfile
 import bb
@@ -342,7 +343,7 @@
             # We do this since git will use a "-l" option automatically for local urls where possible
             if repourl.startswith("file://"):
                 repourl = repourl[7:]
-            clone_cmd = "LANG=C %s clone --bare --mirror \"%s\" %s --progress" % (ud.basecmd, repourl, ud.clonedir)
+            clone_cmd = "LANG=C %s clone --bare --mirror %s %s --progress" % (ud.basecmd, shlex.quote(repourl), ud.clonedir)
             if ud.proto.lower() != 'file':
                 bb.fetch2.check_network_access(d, clone_cmd, ud.url)
             progresshandler = GitProgressHandler(d)
@@ -354,8 +355,8 @@
             if "origin" in output:
               runfetchcmd("%s remote rm origin" % ud.basecmd, d, workdir=ud.clonedir)
 
-            runfetchcmd("%s remote add --mirror=fetch origin \"%s\"" % (ud.basecmd, repourl), d, workdir=ud.clonedir)
-            fetch_cmd = "LANG=C %s fetch -f --progress \"%s\" refs/*:refs/*" % (ud.basecmd, repourl)
+            runfetchcmd("%s remote add --mirror=fetch origin %s" % (ud.basecmd, shlex.quote(repourl)), d, workdir=ud.clonedir)
+            fetch_cmd = "LANG=C %s fetch -f --progress %s refs/*:refs/*" % (ud.basecmd, shlex.quote(repourl))
             if ud.proto.lower() != 'file':
                 bb.fetch2.check_network_access(d, fetch_cmd, ud.url)
             progresshandler = GitProgressHandler(d)
@@ -504,7 +505,7 @@
             raise bb.fetch2.UnpackError("No up to date source found: " + "; ".join(source_error), ud.url)
 
         repourl = self._get_repo_url(ud)
-        runfetchcmd("%s remote set-url origin \"%s\"" % (ud.basecmd, repourl), d, workdir=destdir)
+        runfetchcmd("%s remote set-url origin %s" % (ud.basecmd, shlex.quote(repourl)), d, workdir=destdir)
 
         if self._contains_lfs(ud, d, destdir):
             if need_lfs and not self._find_git_lfs(d):
@@ -623,8 +624,8 @@
         d.setVar('_BB_GIT_IN_LSREMOTE', '1')
         try:
             repourl = self._get_repo_url(ud)
-            cmd = "%s ls-remote \"%s\" %s" % \
-                (ud.basecmd, repourl, search)
+            cmd = "%s ls-remote %s %s" % \
+                (ud.basecmd, shlex.quote(repourl), search)
             if ud.proto.lower() != 'file':
                 bb.fetch2.check_network_access(d, cmd, repourl)
             output = runfetchcmd(cmd, d, True)
diff --git a/poky/bitbake/lib/bb/main.py b/poky/bitbake/lib/bb/main.py
index 7990195..e92e409 100755
--- a/poky/bitbake/lib/bb/main.py
+++ b/poky/bitbake/lib/bb/main.py
@@ -456,15 +456,17 @@
                     break
             except BBMainFatal:
                 raise
-            except (Exception, bb.server.process.ProcessTimeout) as e:
+            except (Exception, bb.server.process.ProcessTimeout, SystemExit) as e:
+                # SystemExit does not inherit from the Exception class, needs to be included explicitly
                 if not retries:
                     raise
                 retries -= 1
                 tryno = 8 - retries
-                if isinstance(e, (bb.server.process.ProcessTimeout, BrokenPipeError, EOFError)):
+                if isinstance(e, (bb.server.process.ProcessTimeout, BrokenPipeError, EOFError, SystemExit)):
                     logger.info("Retrying server connection (#%d)..." % tryno)
                 else:
                     logger.info("Retrying server connection (#%d)... (%s)" % (tryno, traceback.format_exc()))
+                
             if not retries:
                 bb.fatal("Unable to connect to bitbake server, or start one (server startup failures would be in bitbake-cookerdaemon.log).")
             bb.event.print_ui_queue()
diff --git a/poky/bitbake/lib/bb/tests/fetch.py b/poky/bitbake/lib/bb/tests/fetch.py
index 5a4db9c..da17d7f 100644
--- a/poky/bitbake/lib/bb/tests/fetch.py
+++ b/poky/bitbake/lib/bb/tests/fetch.py
@@ -923,7 +923,7 @@
     def test_git_submodule_dbus_broker(self):
         # The following external repositories have show failures in fetch and unpack operations
         # We want to avoid regressions!
-        url = "gitsm://github.com/bus1/dbus-broker;protocol=git;rev=fc874afa0992d0c75ec25acb43d344679f0ee7d2"
+        url = "gitsm://github.com/bus1/dbus-broker;protocol=git;rev=fc874afa0992d0c75ec25acb43d344679f0ee7d2;branch=main"
         fetcher = bb.fetch.Fetch([url], self.d)
         fetcher.download()
         # Previous cwd has been deleted
diff --git a/poky/bitbake/lib/bb/ui/knotty.py b/poky/bitbake/lib/bb/ui/knotty.py
index a91e4fd..0efa614 100644
--- a/poky/bitbake/lib/bb/ui/knotty.py
+++ b/poky/bitbake/lib/bb/ui/knotty.py
@@ -692,7 +692,7 @@
                 if not parseprogress:
                     continue
                 parseprogress.finish()
-                pasreprogress = None
+                parseprogress = None
                 if params.options.quiet == 0:
                     print(("Parsing of %d .bb files complete (%d cached, %d parsed). %d targets, %d skipped, %d masked, %d errors."
                         % ( event.total, event.cached, event.parsed, event.virtuals, event.skipped, event.masked, event.errors)))
diff --git a/poky/bitbake/lib/bb/ui/toasterui.py b/poky/bitbake/lib/bb/ui/toasterui.py
index 9260f5d..ec5bd4f 100644
--- a/poky/bitbake/lib/bb/ui/toasterui.py
+++ b/poky/bitbake/lib/bb/ui/toasterui.py
@@ -131,6 +131,10 @@
 
     helper = uihelper.BBUIHelper()
 
+    if not params.observe_only:
+        params.updateToServer(server, os.environ.copy())
+        params.updateFromServer(server)
+
     # TODO don't use log output to determine when bitbake has started
     #
     # WARNING: this log handler cannot be removed, as localhostbecontroller
@@ -162,8 +166,6 @@
         logger.warning("buildstats is not enabled. Please enable INHERIT += \"buildstats\" to generate build statistics.")
 
     if not params.observe_only:
-        params.updateFromServer(server)
-        params.updateToServer(server, os.environ.copy())
         cmdline = params.parseActions()
         if not cmdline:
             print("Nothing to do.  Use 'bitbake world' to build everything, or run 'bitbake --help' for usage information.")
diff --git a/poky/bitbake/lib/toaster/orm/fixtures/oe-core.xml b/poky/bitbake/lib/toaster/orm/fixtures/oe-core.xml
index fd93f4d..026d948 100644
--- a/poky/bitbake/lib/toaster/orm/fixtures/oe-core.xml
+++ b/poky/bitbake/lib/toaster/orm/fixtures/oe-core.xml
@@ -23,9 +23,9 @@
     <field type="CharField" name="branch">master</field>
   </object>
   <object model="orm.bitbakeversion" pk="4">
-    <field type="CharField" name="name">zeus</field>
+    <field type="CharField" name="name">gatesgarth</field>
     <field type="CharField" name="giturl">git://git.openembedded.org/bitbake</field>
-    <field type="CharField" name="branch">1.44</field>
+    <field type="CharField" name="branch">1.48</field>
   </object>
 
   <!-- Releases available -->
@@ -51,11 +51,11 @@
     <field type="TextField" name="helptext">Toaster will run your builds using the tip of the &lt;a href=\"http://cgit.openembedded.org/openembedded-core/log/\"&gt;OpenEmbedded master&lt;/a&gt; branch.</field>
   </object>
   <object model="orm.release" pk="4">
-    <field type="CharField" name="name">zeus</field>
-    <field type="CharField" name="description">Openembedded Zeus</field>
+    <field type="CharField" name="name">gatesgarth</field>
+    <field type="CharField" name="description">Openembedded Gatesgarth</field>
     <field rel="ManyToOneRel" to="orm.bitbakeversion" name="bitbake_version">4</field>
-    <field type="CharField" name="branch_name">zeus</field>
-    <field type="TextField" name="helptext">Toaster will run your builds using the tip of the &lt;a href=\"http://cgit.openembedded.org/openembedded-core/log/?h=zeus\"&gt;OpenEmbedded Zeus&lt;/a&gt; branch.</field>
+    <field type="CharField" name="branch_name">gatesgarth</field>
+    <field type="TextField" name="helptext">Toaster will run your builds using the tip of the &lt;a href=\"http://cgit.openembedded.org/openembedded-core/log/?h=gatesgarth\"&gt;OpenEmbedded Gatesgarth&lt;/a&gt; branch.</field>
   </object>
 
   <!-- Default layers for each release -->
diff --git a/poky/bitbake/lib/toaster/orm/fixtures/poky.xml b/poky/bitbake/lib/toaster/orm/fixtures/poky.xml
index 902bc88..a468a54 100644
--- a/poky/bitbake/lib/toaster/orm/fixtures/poky.xml
+++ b/poky/bitbake/lib/toaster/orm/fixtures/poky.xml
@@ -26,9 +26,9 @@
     <field type="CharField" name="dirpath">bitbake</field>
   </object>
   <object model="orm.bitbakeversion" pk="4">
-    <field type="CharField" name="name">zeus</field>
+    <field type="CharField" name="name">gatesgarth</field>
     <field type="CharField" name="giturl">git://git.yoctoproject.org/poky</field>
-    <field type="CharField" name="branch">zeus</field>
+    <field type="CharField" name="branch">gatesgarth</field>
     <field type="CharField" name="dirpath">bitbake</field>
   </object>
 
@@ -56,11 +56,11 @@
     <field type="TextField" name="helptext">Toaster will run your builds using the tip of the &lt;a href="http://git.yoctoproject.org/cgit/cgit.cgi/poky/log/"&gt;Yocto Project Master branch&lt;/a&gt;.</field>
   </object>
   <object model="orm.release" pk="4">
-    <field type="CharField" name="name">zeus</field>
-    <field type="CharField" name="description">Yocto Project 3.0 "Zeus"</field>
+    <field type="CharField" name="name">gatesgarth</field>
+    <field type="CharField" name="description">Yocto Project 3.2 "Gatesgarth"</field>
     <field rel="ManyToOneRel" to="orm.bitbakeversion" name="bitbake_version">4</field>
-    <field type="CharField" name="branch_name">zeus</field>
-    <field type="TextField" name="helptext">Toaster will run your builds using the tip of the &lt;a href="http://git.yoctoproject.org/cgit/cgit.cgi/poky/log/?h=zeus"&gt;Yocto Project Zeus branch&lt;/a&gt;.</field>
+    <field type="CharField" name="branch_name">gatesgarth</field>
+    <field type="TextField" name="helptext">Toaster will run your builds using the tip of the &lt;a href="http://git.yoctoproject.org/cgit/cgit.cgi/poky/log/?h=gatesgarth"&gt;Yocto Project Gatesgarth branch&lt;/a&gt;.</field>
   </object>
 
   <!-- Default project layers for each release -->
@@ -152,7 +152,7 @@
     <field rel="ManyToOneRel" to="orm.layer" name="layer">1</field>
     <field type="IntegerField" name="layer_source">0</field>
     <field rel="ManyToOneRel" to="orm.release" name="release">4</field>
-    <field type="CharField" name="branch">zeus</field>
+    <field type="CharField" name="branch">gatesgarth</field>
     <field type="CharField" name="dirpath">meta</field>
   </object>
 
@@ -190,7 +190,7 @@
     <field rel="ManyToOneRel" to="orm.layer" name="layer">2</field>
     <field type="IntegerField" name="layer_source">0</field>
     <field rel="ManyToOneRel" to="orm.release" name="release">4</field>
-    <field type="CharField" name="branch">zeus</field>
+    <field type="CharField" name="branch">gatesgarth</field>
     <field type="CharField" name="dirpath">meta-poky</field>
   </object>
 
@@ -228,7 +228,7 @@
     <field rel="ManyToOneRel" to="orm.layer" name="layer">3</field>
     <field type="IntegerField" name="layer_source">0</field>
     <field rel="ManyToOneRel" to="orm.release" name="release">4</field>
-    <field type="CharField" name="branch">zeus</field>
+    <field type="CharField" name="branch">gatesgarth</field>
     <field type="CharField" name="dirpath">meta-yocto-bsp</field>
   </object>
 </django-objects>
diff --git a/poky/bitbake/lib/toaster/toastergui/templates/base.html b/poky/bitbake/lib/toaster/toastergui/templates/base.html
index 4f72064..9e19cc3 100644
--- a/poky/bitbake/lib/toaster/toastergui/templates/base.html
+++ b/poky/bitbake/lib/toaster/toastergui/templates/base.html
@@ -123,7 +123,7 @@
               {% endif %}
             {% endif %}
               <li id="navbar-docs">
-              <a target="_blank" href="http://www.yoctoproject.org/docs/latest/toaster-manual/toaster-manual.html">
+              <a target="_blank" href="https://www.yoctoproject.org/docs/latest/toaster-manual/toaster-manual.html">
                 <i class="glyphicon glyphicon-book"></i>
                 Documentation
               </a>
diff --git a/poky/bitbake/lib/toaster/toastergui/templates/configvars.html b/poky/bitbake/lib/toaster/toastergui/templates/configvars.html
index ca2e1ea..33fef93 100644
--- a/poky/bitbake/lib/toaster/toastergui/templates/configvars.html
+++ b/poky/bitbake/lib/toaster/toastergui/templates/configvars.html
@@ -66,7 +66,7 @@
         <td class="description">
             {% if variable.description %}
                 {{variable.description}}
-                <a href="http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-{{variable.variable_name|variable_parent_name}}" target="_blank">
+                <a href="https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-{{variable.variable_name|variable_parent_name}}" target="_blank">
                 <span class="glyphicon glyphicon-new-window get-info"></span></a>
             {% endif %}
         </td>
diff --git a/poky/bitbake/lib/toaster/toastergui/templates/landing.html b/poky/bitbake/lib/toaster/toastergui/templates/landing.html
index 70c7359..bfaaf6f 100644
--- a/poky/bitbake/lib/toaster/toastergui/templates/landing.html
+++ b/poky/bitbake/lib/toaster/toastergui/templates/landing.html
@@ -12,10 +12,10 @@
             <div class="col-md-6">
               <h1>This is Toaster</h1>
 
-              <p>A web interface to <a href="http://www.openembedded.org">OpenEmbedded</a> and <a href="http://www.yoctoproject.org/tools-resources/projects/bitbake">BitBake</a>, the <a href="http://www.yoctoproject.org">Yocto Project</a> build system.</p>
+              <p>A web interface to <a href="https://www.openembedded.org">OpenEmbedded</a> and <a href="https://www.yoctoproject.org/tools-resources/projects/bitbake">BitBake</a>, the <a href="https://www.yoctoproject.org">Yocto Project</a> build system.</p>
 
 		          <p class="top-air">
-		            <a class="btn btn-info btn-lg" href="http://www.yoctoproject.org/docs/latest/toaster-manual/toaster-manual.html#toaster-manual-setup-and-use">
+		            <a class="btn btn-info btn-lg" href="https://www.yoctoproject.org/docs/latest/toaster-manual/toaster-manual.html#toaster-manual-setup-and-use">
 			            Toaster is ready to capture your command line builds
 		            </a>
 		          </p>
@@ -33,7 +33,7 @@
                   Toaster has no layer information. Without layer information, you cannot run builds. To generate layer information you can:
                   <ul>
                     <li>
-                      <a href="http://www.yoctoproject.org/docs/latest/toaster-manual/toaster-manual.html#layer-source">Configure a layer source</a>
+                      <a href="https://www.yoctoproject.org/docs/latest/toaster-manual/toaster-manual.html#layer-source">Configure a layer source</a>
                     </li>
                     <li>
 			                <a href="{% url 'newproject' %}">Create a project</a>, then import layers
@@ -44,7 +44,7 @@
 
               <ul class="list-unstyled lead">
                 <li>
-                  <a href="http://www.yoctoproject.org/docs/latest/toaster-manual/toaster-manual.html">
+                  <a href="https://www.yoctoproject.org/docs/latest/toaster-manual/toaster-manual.html">
                     Read the Toaster manual
                   </a>
                 </li>
diff --git a/poky/bitbake/lib/toaster/toastergui/templates/landing_not_managed.html b/poky/bitbake/lib/toaster/toastergui/templates/landing_not_managed.html
index baa4b72..e7200b8 100644
--- a/poky/bitbake/lib/toaster/toastergui/templates/landing_not_managed.html
+++ b/poky/bitbake/lib/toaster/toastergui/templates/landing_not_managed.html
@@ -20,7 +20,7 @@
      <p">
      The 'Build' mode allows you to configure and run your Yocto Project builds from Toaster.
      <ul>
-       <li><a href="http://www.yoctoproject.org/docs/latest/toaster-manual/toaster-manual.html#intro-modes">
+       <li><a href="https://www.yoctoproject.org/docs/latest/toaster-manual/toaster-manual.html#intro-modes">
        Read about the 'Build' mode
        </a></li>
        <li><a href="/">
diff --git a/poky/bitbake/lib/toaster/toastergui/templates/project.html b/poky/bitbake/lib/toaster/toastergui/templates/project.html
index fa41e3c..d8ad2c7 100644
--- a/poky/bitbake/lib/toaster/toastergui/templates/project.html
+++ b/poky/bitbake/lib/toaster/toastergui/templates/project.html
@@ -139,7 +139,7 @@
         <ul>
           <li><a href="{% url 'projectlayers' project.id %}">Choose from the layers compatible with this project</a></li>
           <li><a href="{% url 'importlayer' project.id %}">Import a layer</a></li>
-          <li><a href="http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#understanding-and-creating-layers" target="_blank">Read about layers in the documentation</a></li>
+          <li><a href="https://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#understanding-and-creating-layers" target="_blank">Read about layers in the documentation</a></li>
           <li>Or type a layer name below</li>
         </ul>
       </div>
diff --git a/poky/bitbake/lib/toaster/toastergui/templates/project_specific.html b/poky/bitbake/lib/toaster/toastergui/templates/project_specific.html
index f625d18..42725c0 100644
--- a/poky/bitbake/lib/toaster/toastergui/templates/project_specific.html
+++ b/poky/bitbake/lib/toaster/toastergui/templates/project_specific.html
@@ -137,7 +137,7 @@
         <ul>
           <li><a href="{% url 'projectlayers' project.id %}">Choose from the layers compatible with this project</a></li>
           <li><a href="{% url 'importlayer' project.id %}">Import a layer</a></li>
-          <li><a href="http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#understanding-and-creating-layers" target="_blank">Read about layers in the documentation</a></li>
+          <li><a href="https://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#understanding-and-creating-layers" target="_blank">Read about layers in the documentation</a></li>
           <li>Or type a layer name below</li>
         </ul>
       </div>
diff --git a/poky/bitbake/lib/toaster/toastergui/templates/projectconf.html b/poky/bitbake/lib/toaster/toastergui/templates/projectconf.html
index fb20b26..bd49f1f 100644
--- a/poky/bitbake/lib/toaster/toastergui/templates/projectconf.html
+++ b/poky/bitbake/lib/toaster/toastergui/templates/projectconf.html
@@ -201,12 +201,12 @@
           <p>Toaster cannot set any variables that impact 1) the configuration of the build servers,
           or 2) where artifacts produced by the build are stored. Such variables include: </p>
           <p>
-          <code><a href="http://www.yoctoproject.org/docs/1.6.1/ref-manual/ref-manual.html#var-BB_DISKMON_DIRS" target="_blank">BB_DISKMON_DIRS</a></code>
-          <code><a href="http://www.yoctoproject.org/docs/1.6.1/ref-manual/ref-manual.html#var-BB_NUMBER_THREADS" target="_blank">BB_NUMBER_THREADS</a></code>
+          <code><a href="https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-BB_DISKMON_DIRS" target="_blank">BB_DISKMON_DIRS</a></code>
+          <code><a href="https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-BB_NUMBER_THREADS" target="_blank">BB_NUMBER_THREADS</a></code>
           <code>CVS_PROXY_HOST</code>
           <code>CVS_PROXY_PORT</code>
-          <code><a href="http://www.yoctoproject.org/docs/1.6.1/ref-manual/ref-manual.html#var-PARALLEL_MAKE" target="_blank">PARALLEL_MAKE</a></code>
-          <code><a href="http://www.yoctoproject.org/docs/1.6.1/ref-manual/ref-manual.html#var-TMPDIR" target="_blank">TMPDIR</a></code></p>
+          <code><a href="https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-PARALLEL_MAKE" target="_blank">PARALLEL_MAKE</a></code>
+          <code><a href="https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-TMPDIR" target="_blank">TMPDIR</a></code></p>
           <p>Plus the following standard shell environment variables:</p>
           <p><code>http_proxy</code> <code>ftp_proxy</code> <code>https_proxy</code> <code>all_proxy</code></p>
         </div>
diff --git a/poky/documentation/adt-manual/adt-prepare.rst b/poky/documentation/adt-manual/adt-prepare.rst
index 5a85cbf..3e5c6ae 100644
--- a/poky/documentation/adt-manual/adt-prepare.rst
+++ b/poky/documentation/adt-manual/adt-prepare.rst
@@ -107,7 +107,7 @@
       configuration information.
 
    $ cd ~ $ git clone git://git.yoctoproject.org/poky $ cd poky $ git
-   checkout -b DISTRO_NAME origin/DISTRO_NAME $ source OE_INIT_FILE $
+   checkout -b DISTRO_NAME origin/DISTRO_NAME $ source oe-init-build-env $
    bitbake adt-installer
 
 Configuring and Running the ADT Installer Script
diff --git a/poky/documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.rst b/poky/documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.rst
index 14a3e17..c9622d3 100644
--- a/poky/documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.rst
+++ b/poky/documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.rst
@@ -177,7 +177,7 @@
    .. code-block:: shell
 
       $ cd ~/poky
-      $ source &OE_INIT_FILE;
+      $ source oe-init-build-env
       You had no conf/local.conf file. This configuration file has therefore been
       created for you with some default values. You may wish to edit it to, for
       example, select a different MACHINE (target hardware). See conf/local.conf
diff --git a/poky/documentation/bsp-guide/bsp.rst b/poky/documentation/bsp-guide/bsp.rst
index 61b2958..d0275ee 100644
--- a/poky/documentation/bsp-guide/bsp.rst
+++ b/poky/documentation/bsp-guide/bsp.rst
@@ -31,14 +31,14 @@
    meta-bsp_root_name
 
 The string "meta-" is prepended to the
-machine or platform name, which is bsp_root_name in the above form.
+machine or platform name, which is "bsp_root_name" in the above form.
 
 .. note::
 
    Because the BSP layer naming convention is well-established, it is
    advisable to follow it when creating layers. Technically speaking, a
-   BSP layer name does not need to start with
-   meta-. However, various scripts and tools in the Yocto Project development
+   BSP layer name does not need to start with ``meta-``.
+   However, various scripts and tools in the Yocto Project development
    environment assume this convention.
 
 To help understand the BSP layer concept, consider the BSPs that the
@@ -81,7 +81,7 @@
 ``conf/bblayers.conf`` file found in your
 :term:`Build Directory`, which is
 established after you run the OpenEmbedded build environment setup
-script (i.e. :ref:`ref-manual/ref-structure:\`\`oe-init-build-env\`\`` ).
+script (i.e. :ref:`ref-manual/ref-structure:\`\`oe-init-build-env\`\``).
 Adding the root directory allows the :term:`OpenEmbedded Build System`
 to recognize the BSP
 layer and from it build an image. Here is an example: ::
@@ -95,10 +95,11 @@
 
 .. note::
 
-   Ordering and ``BBFILE_PRIORITY`` for the layers listed in BBLAYERS matter. For
-   example, if multiple layers define a machine configuration, the OpenEmbedded
-   build system uses the last layer searched given similar layer priorities. The
-   build system works from the top-down through the layers listed in ``BBLAYERS``.
+   Ordering and :term:`BBFILE_PRIORITY` for the layers listed in ``BBLAYERS``
+   matter. For example, if multiple layers define a machine configuration, the
+   OpenEmbedded build system uses the last layer searched given similar layer
+   priorities. The build system works from the top-down through the layers
+   listed in ``BBLAYERS``.
 
 Some BSPs require or depend on additional layers beyond the BSP's root
 layer in order to be functional. In this case, you need to specify these
@@ -107,7 +108,7 @@
 them to the "Dependencies" section.
 
 Some layers function as a layer to hold other BSP layers. These layers
-are knows as ":term:`container layers <Container Layer>`". An example of
+are known as ":term:`container layers <Container Layer>`". An example of
 this type of layer is OpenEmbedded's
 `meta-openembedded <https://github.com/openembedded/meta-openembedded>`__
 layer. The ``meta-openembedded`` layer contains many ``meta-*`` layers.
@@ -141,8 +142,8 @@
 
 .. note::
 
-   For structural information on BSPs, see the Example Filesystem Layout
-   section.
+   For structural information on BSPs, see the
+   :ref:`bsp-guide/bsp:example filesystem layout` section.
 
 #. *Set Up the Build Environment:* Be sure you are set up to use BitBake
    in a shell. See the ":ref:`dev-manual/dev-manual-start:preparing the build host`"
@@ -150,10 +151,10 @@
    to get a build host ready that is either a native Linux machine or a machine
    that uses CROPS.
 
-#. *Clone the ``poky`` Repository:* You need to have a local copy of the
+#. *Clone the poky Repository:* You need to have a local copy of the
    Yocto Project :term:`Source Directory` (i.e. a local
    ``poky`` repository). See the
-   "ref:`dev-manual/dev-manual-start:cloning the ``poky`` repository`" and
+   ":ref:`dev-manual/dev-manual-start:cloning the \`\`poky\`\` repository`" and
    possibly the
    ":ref:`dev-manual/dev-manual-start:checking out by branch in poky`" or
    ":ref:`dev-manual/dev-manual-start:checking out by tag in poky`"
@@ -168,7 +169,7 @@
    BSP layers, you can look at the `index of
    machines <&YOCTO_RELEASE_DL_URL;/machines>`__ for the release.
 
-#. *Optionally Clone the ``meta-intel`` BSP Layer:* If your hardware is
+#. *Optionally Clone the meta-intel BSP Layer:* If your hardware is
    based on current Intel CPUs and devices, you can leverage this BSP
    layer. For details on the ``meta-intel`` BSP layer, see the layer's
    `README <http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/tree/README>`__
@@ -193,7 +194,7 @@
 
    #. *Check Out the Proper Branch:* The branch you check out for
       ``meta-intel`` must match the same branch you are using for the
-      Yocto Project release (e.g. &DISTRO_NAME_NO_CAP;): ::
+      Yocto Project release (e.g. ``&DISTRO_NAME_NO_CAP;``): ::
 
          $ cd meta-intel
          $ git checkout -b &DISTRO_NAME_NO_CAP; remotes/origin/&DISTRO_NAME_NO_CAP;
@@ -233,7 +234,7 @@
    setup script to define the OpenEmbedded build environment on your
    build host. ::
 
-      $ source &OE_INIT_FILE;
+      $ source oe-init-build-env
 
    Among other things, the script creates the :term:`Build Directory`, which is
    ``build`` in this case and is located in the :term:`Source Directory`.  After
@@ -291,7 +292,9 @@
    meta-bsp_root_name/recipes-kernel/linux/linux-yocto_kernel_rev.bbappend
 
 Below is an example of the Raspberry Pi BSP layer that is available from
-the :yocto_git:`Source Respositories <>`: ::
+the :yocto_git:`Source Respositories <>`:
+
+.. code-block:: none
 
    meta-raspberrypi/COPYING.MIT
    meta-raspberrypi/README.md
@@ -544,13 +547,13 @@
 identifies the contents of the layer, and contains information about how
 the build system should use it. Generally, a standard boilerplate file
 such as the following works. In the following example, you would replace
-bsp with the actual name of the BSP (i.e. bsp_root_name from the example
+"bsp" with the actual name of the BSP (i.e. "bsp_root_name" from the example
 template). ::
 
    # We have a conf and classes directory, add to BBPATH
    BBPATH .= ":${LAYERDIR}"
 
-   # We have a recipes directory, add to BBFILES
+   # We have a recipes directory containing .bb and .bbappend files, add to BBFILES
    BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
                ${LAYERDIR}/recipes-*/*/*.bbappend"
 
@@ -694,7 +697,7 @@
 
 Suppose you are using the ``linux-yocto_4.4.bb`` recipe to build the
 kernel. In other words, you have selected the kernel in your
-bsp_root_name\ ``.conf`` file by adding
+``"bsp_root_name".conf`` file by adding
 :term:`PREFERRED_PROVIDER` and :term:`PREFERRED_VERSION`
 statements as follows: ::
 
@@ -704,7 +707,7 @@
 .. note::
 
    When the preferred provider is assumed by default, the ``PREFERRED_PROVIDER``
-   statement does not appear in the ``bsp_root_name`` .conf file.
+   statement does not appear in the ``"bsp_root_name".conf`` file.
 
 You would use the ``linux-yocto_4.4.bbappend`` file to append specific
 BSP settings to the kernel, thus configuring the kernel for your
@@ -781,7 +784,7 @@
 
    .. note::
 
-      -  Five hardware reference BSPs exist that are part of the Yocto
+      -  Four hardware reference BSPs exist that are part of the Yocto
          Project release and are located in the ``poky/meta-yocto-bsp``
          BSP layer:
 
@@ -870,8 +873,8 @@
 -  The requirements in this section apply regardless of how you package
    a BSP. You should consult the packaging and distribution guidelines
    for your specific release process. For an example of packaging and
-   distribution requirements, see the "`Third Party BSP Release
-   Process <https://wiki.yoctoproject.org/wiki/Third_Party_BSP_Release_Process>`__"
+   distribution requirements, see the ":yocto_wiki:`Third Party BSP Release
+   Process </wiki/Third_Party_BSP_Release_Process>`"
    wiki page.
 
 -  The requirements for the BSP as it is made available to a developer
@@ -897,7 +900,7 @@
    your BSP layer as listed in the ``recipes.txt`` file, which is found
    in ``poky/meta`` directory of the :term:`Source Directory`
    or in the OpenEmbedded-Core Layer (``openembedded-core``) at
-   http://git.openembedded.org/openembedded-core/tree/meta.
+   https://git.openembedded.org/openembedded-core/tree/meta.
 
    You should place recipes (``*.bb`` files) and recipe modifications
    (``*.bbappend`` files) into ``recipes-*`` subdirectories by
@@ -1074,7 +1077,7 @@
 
    .. note::
 
-      If the meta-xyz layer did not support multiple machines, you would place
+      If the ``meta-xyz`` layer did not support multiple machines, you would place
       the interfaces configuration file in the layer here: ::
 
          meta-xyz/recipes-core/init-ifupdown/files/interfaces
@@ -1233,7 +1236,7 @@
    # We have a conf and classes directory, add to BBPATH
    BBPATH .= ":${LAYERDIR}"
 
-   # We have recipes-\* directories, add to BBFILES
+   # We have a recipes directory containing .bb and .bbappend files, add to BBFILES
    BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
                ${LAYERDIR}/recipes-*/*/*.bbappend"
 
@@ -1262,13 +1265,13 @@
 One or more machine configuration files exist in the
 ``bsp_layer/conf/machine/`` directory of the layer: ::
 
-   bsp_layer/conf/machine/machine1\.conf``
-   bsp_layer/conf/machine/machine2\.conf``
-   bsp_layer/conf/machine/machine3\.conf``
+   bsp_layer/conf/machine/machine1\.conf
+   bsp_layer/conf/machine/machine2\.conf
+   bsp_layer/conf/machine/machine3\.conf
    ... more ...
 
 For example, the machine configuration file for the `BeagleBone and
-BeagleBone Black development boards <http://beagleboard.org/bone>`__ is
+BeagleBone Black development boards <https://beagleboard.org/bone>`__ is
 located in the layer ``poky/meta-yocto-bsp/conf/machine`` and is named
 ``beaglebone-yocto.conf``: ::
 
@@ -1344,7 +1347,7 @@
 
    .. tip::
 
-      Many ``MACHINE\*`` variables exist that help you configure a particular piece
+      Many ``MACHINE*`` variables exist that help you configure a particular piece
       of hardware.
 
 -  :term:`EXTRA_IMAGEDEPENDS`:
@@ -1359,12 +1362,12 @@
    These features, which are collectively known as "tuning features",
    exist in the :term:`OpenEmbedded-Core (OE-Core)` layer (e.g.
    ``poky/meta/conf/machine/include``). In this example, the default
-   tunning file is "cortexa8hf-neon".
+   tuning file is "cortexa8hf-neon".
 
    .. note::
 
       The include statement that pulls in the
-      conf/machine/include/tune-cortexa8.inc file provides many tuning
+      ``conf/machine/include/tune-cortexa8.inc`` file provides many tuning
       possibilities.
 
 -  :term:`IMAGE_FSTYPES`: The
@@ -1389,7 +1392,7 @@
 
 -  ``do_image_wic[depends]``: A task that is constructed during the
    build. In this example, the task depends on specific tools in order
-   to create the sysroot when buiding a Wic image.
+   to create the sysroot when building a Wic image.
 
 -  :term:`SERIAL_CONSOLES`:
    Defines a serial console (TTY) to enable using getty. In this case,
@@ -1429,7 +1432,8 @@
 
    .. note::
 
-      For more information on how the SPL variables are used, see the u-boot.inc
+      For more information on how the SPL variables are used, see the
+      :yocto_git:`u-boot.inc </cgit/cgit.cgi/poky/tree/meta/recipes-bsp/u-boot/u-boot.inc>`
       include file.
 
 -  :term:`UBOOT_* <UBOOT_ENTRYPOINT>`: Defines
@@ -1473,7 +1477,7 @@
 metadata used to build the kernel. In this case, a kernel append file
 (i.e. ``linux-yocto_5.0.bbappend``) is used to override an established
 kernel recipe (i.e. ``linux-yocto_5.0.bb``), which is located in
-https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-kernel/linux.
+:yocto_git:`/cgit/cgit.cgi/poky/tree/meta/recipes-kernel/linux`.
 
 Following is the contents of the append file: ::
 
diff --git a/poky/documentation/dev-manual/dev-manual-common-tasks.rst b/poky/documentation/dev-manual/dev-manual-common-tasks.rst
index bef8bf8..0630040 100644
--- a/poky/documentation/dev-manual/dev-manual-common-tasks.rst
+++ b/poky/documentation/dev-manual/dev-manual-common-tasks.rst
@@ -39,7 +39,7 @@
 1. *Check Existing Layers:* Before creating a new layer, you should be
    sure someone has not already created a layer containing the Metadata
    you need. You can see the `OpenEmbedded Metadata
-   Index <http://layers.openembedded.org/layerindex/layers/>`__ for a
+   Index <https://layers.openembedded.org/layerindex/layers/>`__ for a
    list of layers from the OpenEmbedded community that can be used in
    the Yocto Project. You could find a layer that is identical or close
    to what you need.
@@ -84,7 +84,7 @@
       # We have a conf and classes directory, add to BBPATH
       BBPATH .= ":${LAYERDIR}"
 
-      # We have recipes-\* directories, add to BBFILES
+      # We have recipes-* directories, add to BBFILES
       BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
                   ${LAYERDIR}/recipes-*/*/*.bbappend"
 
@@ -150,10 +150,8 @@
    .. note::
 
       For an explanation of layer hierarchy that is compliant with the
-      Yocto Project, see the "
-      Example Filesystem Layout
-      " section in the Yocto Project Board Support Package (BSP)
-      Developer's Guide.
+      Yocto Project, see the ":ref:`bsp-guide/bsp:example filesystem layout`"
+      section in the Yocto Project Board Support Package (BSP) Developer's Guide.
 
 5. *Optionally Test for Compatibility:* If you want permission to use
    the Yocto Project Compatibility logo with your layer or application
@@ -181,8 +179,8 @@
    for each recipe that uses an include file. Or, if you are introducing
    a new recipe that requires the included file, use the path relative
    to the original layer directory to refer to the file. For example,
-   use ``require recipes-core/``\ package\ ``/``\ file\ ``.inc`` instead
-   of ``require``\ file\ ``.inc``. If you're finding you have to overlay
+   use ``require recipes-core/``\ `package`\ ``/``\ `file`\ ``.inc`` instead
+   of ``require`` `file`\ ``.inc``. If you're finding you have to overlay
    the include file, it could indicate a deficiency in the include file
    in the layer to which it originally belongs. If this is the case, you
    should try to address that deficiency instead of overlaying the
@@ -214,8 +212,12 @@
       ``foo``.
 
       To make sure your changes apply only when building machine "one",
-      use a machine override with the ``DEPENDS`` statement: DEPENDS_one
-      = "foo" You should follow the same strategy when using ``_append``
+      use a machine override with the ``DEPENDS`` statement:
+      ::
+
+         DEPENDS_one = "foo"
+
+      You should follow the same strategy when using ``_append``
       and ``_prepend`` operations:
       ::
 
@@ -244,11 +246,8 @@
 
       .. note::
 
-         Avoiding "+=" and "=+" and using machine-specific
-         \_append
-         and
-         \_prepend
-         operations is recommended as well.
+         Avoiding "+=" and "=+" and using machine-specific ``_append``
+         and ``_prepend`` operations is recommended as well.
 
    -  *Place Machine-Specific Files in Machine-Specific Locations:* When
       you have a base recipe, such as ``base-files.bb``, that contains a
@@ -256,11 +255,12 @@
       file, you can use an append file to cause the build to use your
       own version of the file. For example, an append file in your layer
       at ``meta-one/recipes-core/base-files/base-files.bbappend`` could
-      extend :term:`FILESPATH`
-      using
-      :term:`FILESEXTRAPATHS`
-      as follows: FILESEXTRAPATHS_prepend := "${THISDIR}/${BPN}:" The
-      build for machine "one" will pick up your machine-specific file as
+      extend :term:`FILESPATH` using :term:`FILESEXTRAPATHS` as follows:
+      ::
+
+         FILESEXTRAPATHS_prepend := "${THISDIR}/${BPN}:"
+
+      The build for machine "one" will pick up your machine-specific file as
       long as you have the file in
       ``meta-one/recipes-core/base-files/base-files/``. However, if you
       are building for a different machine and the ``bblayers.conf``
@@ -311,9 +311,7 @@
    Only Yocto Project member organizations are permitted to use the
    Yocto Project Compatible Logo. The logo is not available for general
    use. For information on how to become a Yocto Project member
-   organization, see the
-   Yocto Project Website
-   .
+   organization, see the :yocto_home:`Yocto Project Website <>`.
 
 The Yocto Project Compatibility Program consists of a layer application
 process that requests permission to use the Yocto Project Compatibility
@@ -482,7 +480,7 @@
 
 When you create an append file, you must use the same root name as the
 corresponding recipe file. For example, the append file
-``someapp_DISTRO.bbappend`` must apply to ``someapp_DISTRO.bb``. This
+``someapp_3.1.bbappend`` must apply to ``someapp_3.1.bb``. This
 means the original recipe and append file names are version
 number-specific. If the corresponding recipe is renamed to update to a
 newer version, you must also rename and possibly update the
@@ -500,6 +498,9 @@
 ::
 
    SUMMARY = "Device formfactor information"
+   DESCRIPTION = "A formfactor configuration file provides information about the \
+   target hardware for which the image is being built and information that the \
+   build system cannot obtain from other sources such as the kernel."
    SECTION = "base"
    LICENSE = "MIT"
    LIC_FILES_CHKSUM = "file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
@@ -603,7 +604,7 @@
 command:
 ::
 
-   $ bitbake-layers --help NOTE: Starting bitbake server... usage:
+   $ bitbake-layers --help
    NOTE: Starting bitbake server...
    usage: bitbake-layers [-d] [-q] [-F] [--color COLOR] [-h] <subcommand> ...
 
@@ -751,9 +752,13 @@
 
 In its simplest form, you can use the following command form to create a
 layer. The command creates a layer whose name corresponds to
-your_layer_name in the current directory: $ bitbake-layers create-layer
-your_layer_name As an example, the following command creates a layer
-named ``meta-scottrif`` in your home directory:
+"your_layer_name" in the current directory:
+::
+
+   $ bitbake-layers create-layer your_layer_name
+
+As an example, the following command creates a layer named ``meta-scottrif``
+in your home directory:
 ::
 
    $ cd /usr/home
@@ -762,12 +767,12 @@
    Add your new layer with 'bitbake-layers add-layer meta-scottrif'
 
 If you want to set the priority of the layer to other than the default
-value of "6", you can either use the ``DASHDASHpriority`` option or you
+value of "6", you can either use the ``--priority`` option or you
 can edit the
 :term:`BBFILE_PRIORITY` value
 in the ``conf/layer.conf`` after the script creates it. Furthermore, if
 you want to give the example recipe file some name other than the
-default, you can use the ``DASHDASHexample-recipe-name`` option.
+default, you can use the ``--example-recipe-name`` option.
 
 The easiest way to see how the ``bitbake-layers create-layer`` command
 works is to experiment with the script. You can also read the usage
@@ -871,13 +876,16 @@
 so unconditionally appends to the variable and avoids ordering problems
 due to the variable being set in image recipes and ``.bbclass`` files
 with operators like ``?=``. Using ``_append`` ensures the operation
-takes affect.
+takes effect.
 
 As shown in its simplest use, ``IMAGE_INSTALL_append`` affects all
 images. It is possible to extend the syntax so that the variable applies
 to a specific image only. Here is an example:
-IMAGE_INSTALL_append_pn-core-image-minimal = " strace" This example adds
-``strace`` to the ``core-image-minimal`` image only.
+::
+
+   IMAGE_INSTALL_append_pn-core-image-minimal = " strace"
+
+This example adds ``strace`` to the ``core-image-minimal`` image only.
 
 You can add packages using a similar approach through the
 ``CORE_IMAGE_EXTRA_INSTALL`` variable. If you use this variable, only
@@ -937,10 +945,9 @@
 
 .. note::
 
-   See the "
-   Images
-   " section in the Yocto Project Reference Manual for a complete list
-   of image features that ship with the Yocto Project.
+   See the ":ref:`ref-manual/ref-features:image features`" section in the Yocto
+   Project Reference Manual for a complete list of image features that ship
+   with the Yocto Project.
 
 .. _usingpoky-extend-customimage-custombb:
 
@@ -988,12 +995,8 @@
 
 .. note::
 
-   The
-   inherit packagegroup
-   line should be located near the top of the recipe, certainly before
-   the
-   PACKAGES
-   statement.
+   The ``inherit packagegroup`` line should be located near the top of the
+   recipe, certainly before the ``PACKAGES`` statement.
 
 For each package you specify in ``PACKAGES``, you can use ``RDEPENDS``
 and ``RRECOMMENDS`` entries to provide a list of packages the parent
@@ -1090,9 +1093,9 @@
 .. note::
 
    For information on variables that are useful for recipes and for
-   information about recipe naming issues, see the "
-   Required
-   " section of the Yocto Project Reference Manual.
+   information about recipe naming issues, see the
+   ":ref:`ref-manual/ref-varlocality:recipes`" section of the Yocto Project
+   Reference Manual.
 
 .. _new-recipe-overview:
 
@@ -1124,9 +1127,8 @@
 
 .. note::
 
-   For information on recipe syntax, see the "
-   Recipe Syntax
-   " section.
+   For information on recipe syntax, see the
+   ":ref:`dev-manual/dev-manual-common-tasks:recipe syntax`" section.
 
 .. _new-recipe-creating-the-base-recipe-using-devtool:
 
@@ -1161,7 +1163,7 @@
 To run the tool, you just need to be in your
 :term:`Build Directory` and have sourced the
 build environment setup script (i.e.
-`:ref:`structure-core-script`).
+:ref:`structure-core-script`).
 To get help on the tool, use the following command:
 ::
 
@@ -1187,29 +1189,29 @@
      appendsrcfile   Create/update a bbappend to add or replace a source file
    Use recipetool <subcommand> --help to get help on a specific command
 
-Running ``recipetool create -o`` OUTFILE creates the base recipe and
+Running ``recipetool create -o OUTFILE`` creates the base recipe and
 locates it properly in the layer that contains your source files.
 Following are some syntax examples:
 
-Use this syntax to generate a recipe based on source. Once generated,
-the recipe resides in the existing source code layer:
-::
+ - Use this syntax to generate a recipe based on source. Once generated,
+   the recipe resides in the existing source code layer:
+   ::
 
-   recipetool create -o OUTFILE source
+      recipetool create -o OUTFILE source
 
-Use this syntax to generate a recipe using code that
-you extract from source. The extracted code is placed in its own layer
-defined by EXTERNALSRC.
-::
+ - Use this syntax to generate a recipe using code that
+   you extract from source. The extracted code is placed in its own layer
+   defined by ``EXTERNALSRC``.
+   ::
 
-   recipetool create -o OUTFILE -x EXTERNALSRC source
+      recipetool create -o OUTFILE -x EXTERNALSRC source
 
-Use this syntax to generate a recipe based on source. The options
-direct ``recipetool`` to generate debugging information. Once generated,
-the recipe resides in the existing source code layer:
-::
+ - Use this syntax to generate a recipe based on source. The options
+   direct ``recipetool`` to generate debugging information. Once generated,
+   the recipe resides in the existing source code layer:
+   ::
 
-   recipetool create -d -o OUTFILE source
+      recipetool create -d -o OUTFILE source
 
 .. _new-recipe-locating-and-using-a-similar-recipe:
 
@@ -1221,7 +1223,7 @@
 to meeting) your needs. The Yocto Project and OpenEmbedded communities
 maintain many recipes that might be candidates for what you are doing.
 You can find a good central index of these recipes in the `OpenEmbedded
-Layer Index <http://layers.openembedded.org>`__.
+Layer Index <https://layers.openembedded.org>`__.
 
 Working from an existing recipe or a skeleton recipe is the best way to
 get started. Here are some points on both methods:
@@ -1280,13 +1282,18 @@
    Layers <#understanding-and-creating-layers>`__" section.
 
 -  *Naming Your Recipe:* When you name your recipe, you need to follow
-   this naming convention: basename_version.bb Use lower-cased
-   characters and do not include the reserved suffixes ``-native``,
-   ``-cross``, ``-initial``, or ``-dev`` casually (i.e. do not use them
-   as part of your recipe name unless the string applies). Here are some
-   examples:
+   this naming convention:
    ::
 
+      basename_version.bb
+
+   Use lower-cased characters and do not include the reserved suffixes
+   ``-native``, ``-cross``, ``-initial``, or ``-dev`` casually (i.e. do not use
+   them as part of your recipe name unless the string applies). Here are some
+   examples:
+
+   .. code-block:: none
+
       cups_1.7.0.bb
       gawk_4.0.2.bb
       irssi_0.8.16-rc1.bb
@@ -1320,34 +1327,28 @@
 is to have BitBake return it by running the following:
 ::
 
-   $ bitbake -e basename \| grep ^WORKDIR=
+   $ bitbake -e basename | grep ^WORKDIR=
 
 As an example, assume a Source Directory
 top-level folder named ``poky``, a default Build Directory at
 ``poky/build``, and a ``qemux86-poky-linux`` machine target system.
 Furthermore, suppose your recipe is named ``foo_1.3.0.bb``. In this
 case, the work directory the build system uses to build the package
-would be as follows: poky/build/tmp/work/qemux86-poky-linux/foo/1.3.0-r0
+would be as follows:
+::
+
+   poky/build/tmp/work/qemux86-poky-linux/foo/1.3.0-r0
+
 Inside this directory you can find sub-directories such as ``image``,
 ``packages-split``, and ``temp``. After the build, you can examine these
 to determine how well the build went.
 
 .. note::
 
-   You can find log files for each task in the recipe's
-   temp
-   directory (e.g.
-   poky/build/tmp/work/qemux86-poky-linux/foo/1.3.0-r0/temp
-   ). Log files are named
-   log.
-   taskname
-   (e.g.
-   log.do_configure
-   ,
-   log.do_fetch
-   , and
-   log.do_compile
-   ).
+   You can find log files for each task in the recipe's ``temp``
+   directory (e.g. ``poky/build/tmp/work/qemux86-poky-linux/foo/1.3.0-r0/temp``).
+   Log files are named ``log.taskname`` (e.g. ``log.do_configure``,
+   ``log.do_fetch``, and ``log.do_compile``).
 
 You can find more information about the build process in
 ":doc:`../overview-manual/overview-manual-development-environment`"
@@ -1391,7 +1392,7 @@
 :term:`PV` variable:
 ::
 
-   SRC_URI = "https://strace.io/files/${PV}/strace-${PV}.tar.xz \\
+   SRC_URI = "https://strace.io/files/${PV}/strace-${PV}.tar.xz \
 
 Files mentioned in ``SRC_URI`` whose names end in a typical archive
 extension (e.g. ``.tar``, ``.tar.gz``, ``.tar.bz2``, ``.zip``, and so
@@ -1576,8 +1577,8 @@
    the checksums of the files to be sure the text has not changed. Any
    differences result in an error with the message containing the
    current checksum. For more explanation and examples of how to set the
-   ``LIC_FILES_CHKSUM`` variable, see the "`Tracking License
-   Changes <#>`__" section.
+   ``LIC_FILES_CHKSUM`` variable, see the
+   ":ref:`dev-manual/dev-manual-common-tasks:tracking license changes`" section.
 
    To determine the correct checksum string, you can list the
    appropriate files in the ``LIC_FILES_CHKSUM`` variable with incorrect
@@ -1611,25 +1612,16 @@
 :term:`DEPENDS` variable. Although
 nuances exist, items specified in ``DEPENDS`` should be names of other
 recipes. It is important that you specify all build-time dependencies
-explicitly. If you do not, due to the parallel nature of BitBake's
-execution, you can end up with a race condition where the dependency is
-present for one task of a recipe (e.g.
-:ref:`ref-tasks-configure`) and
-then gone when the next task runs (e.g.
-:ref:`ref-tasks-compile`).
+explicitly.
 
 Another consideration is that configure scripts might automatically
 check for optional dependencies and enable corresponding functionality
-if those dependencies are found. This behavior means that to ensure
-deterministic results and thus avoid more race conditions, you need to
-either explicitly specify these dependencies as well, or tell the
-configure script explicitly to disable the functionality. If you wish to
-make a recipe that is more generally useful (e.g. publish the recipe in
-a layer for others to use), instead of hard-disabling the functionality,
-you can use the
-:term:`PACKAGECONFIG` variable
-to allow functionality and the corresponding dependencies to be enabled
-and disabled easily by other users of the recipe.
+if those dependencies are found. If you wish to make a recipe that is
+more generally useful (e.g. publish the recipe in a layer for others to
+use), instead of hard-disabling the functionality, you can use the
+:term:`PACKAGECONFIG` variable to allow functionality and the
+corresponding dependencies to be enabled and disabled easily by other
+users of the recipe.
 
 Similar to build-time dependencies, you specify runtime dependencies
 through a variable -
@@ -1668,13 +1660,10 @@
    As of Yocto Project Release 1.7, some of the core recipes that
    package binary configuration scripts now disable the scripts due to
    the scripts previously requiring error-prone path substitution. The
-   OpenEmbedded build system uses
-   pkg-config
-   now, which is much more robust. You can find a list of the
-   \*-config
-   scripts that are disabled list in the "
-   Binary Configuration Scripts Disabled
-   " section in the Yocto Project Reference Manual.
+   OpenEmbedded build system uses ``pkg-config`` now, which is much more
+   robust. You can find a list of the ``*-config`` scripts that are disabled
+   in the ":ref:`migration-1.7-binary-configuration-scripts-disabled`" section
+   in the Yocto Project Reference Manual.
 
 A major part of build-time configuration is about checking for
 build-time dependencies and possibly enabling optional functionality as
@@ -1718,11 +1707,7 @@
 
       If you need to install one or more custom CMake toolchain files
       that are supplied by the application you are building, install the
-      files to
-      ${D}${datadir}/cmake/
-      Modules during
-      do_install
-      .
+      files to ``${D}${datadir}/cmake/Modules`` during ``do_install``.
 
 -  *Other:* If your source files do not have a ``configure.ac`` or
    ``CMakeLists.txt`` file, then your software is built using some
@@ -1773,11 +1758,8 @@
 
 .. note::
 
-   Never copy and customize the
-   libc
-   header file (i.e.
-   meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
-   ).
+   Never copy and customize the ``libc`` header file (i.e.
+   ``meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc``).
 
 The correct way to interface to a device or custom kernel is to use a
 separate package that provides the additional headers for the driver or
@@ -1803,13 +1785,10 @@
 
 .. note::
 
-   If for some reason your changes need to modify the behavior of the
-   libc
-   , and subsequently all other applications on the system, use a
-   .bbappend
-   to modify the
-   linux-kernel-headers.inc
-   file. However, take care to not make the changes machine specific.
+   If for some reason your changes need to modify the behavior of the ``libc``,
+   and subsequently all other applications on the system, use a ``.bbappend``
+   to modify the ``linux-kernel-headers.inc`` file. However, take care to not
+   make the changes machine specific.
 
 Consider a case where your kernel is older and you need an older
 ``libc`` ABI. The headers installed by your recipe should still be a
@@ -1839,11 +1818,8 @@
 
    For cases where improper paths are detected for configuration files
    or for when libraries/headers cannot be found, be sure you are using
-   the more robust
-   pkg-config
-   . See the note in section "
-   Configuring the Recipe
-   " for additional information.
+   the more robust ``pkg-config``. See the note in section
+   ":ref:`new-recipe-configuring-the-recipe`" for additional information.
 
 -  *Parallel build failures:* These failures manifest themselves as
    intermittent errors, or errors reporting that a file or directory
@@ -1921,7 +1897,7 @@
    ``do_install_append`` function using the install command as described
    in the "Manual" bulleted item later in this list.
 
--  Other (using ``make install``): You need to define a ``do_install``
+-  *Other (using* ``make install``\ *)*: You need to define a ``do_install``
    function in your recipe. The function should call
    ``oe_runmake install`` and will likely need to pass in the
    destination directory as well. How you pass that path is dependent on
@@ -1940,7 +1916,7 @@
    install the built software into the directories.
 
    You can find more information on ``install`` at
-   http://www.gnu.org/software/coreutils/manual/html_node/install-invocation.html.
+   https://www.gnu.org/software/coreutils/manual/html_node/install-invocation.html.
 
 For the scenarios that do not use Autotools or CMake, you need to track
 the installation and diagnose and fix any issues until everything
@@ -1969,13 +1945,15 @@
       conditions. If you experience intermittent failures during
       ``do_install``, you might be able to work around them by disabling
       parallel Makefile installs by adding the following to the recipe:
-      PARALLEL_MAKEINST = "" See
-      :term:`PARALLEL_MAKEINST`
-      for additional information.
+      ::
+
+         PARALLEL_MAKEINST = ""
+
+      See :term:`PARALLEL_MAKEINST` for additional information.
 
    -  If you need to install one or more custom CMake toolchain files
       that are supplied by the application you are building, install the
-      files to ``${D}${datadir}/cmake/`` Modules during
+      files to ``${D}${datadir}/cmake/Modules`` during
       :ref:`ref-tasks-install`.
 
 .. _new-recipe-enabling-system-services:
@@ -2023,7 +2001,7 @@
 -  *systemd:* System Management Daemon (systemd) was designed to replace
    SysVinit and to provide enhanced management of services. For more
    information on systemd, see the systemd homepage at
-   http://freedesktop.org/wiki/Software/systemd/.
+   https://freedesktop.org/wiki/Software/systemd/.
 
    To enable a service using systemd, your recipe needs to inherit the
    :ref:`systemd <ref-classes-systemd>` class. See
@@ -2127,8 +2105,7 @@
 .. note::
 
    You could find the term "staging" used within the Yocto project
-   regarding files populating sysroots (e.g. the
-   STAGING_DIR
+   regarding files populating sysroots (e.g. the :term:`STAGING_DIR`
    variable).
 
 Recipes should never populate the sysroot directly (i.e. write files
@@ -2205,24 +2182,26 @@
 When you use a virtual provider, you do not have to "hard code" a recipe
 name as a build dependency. You can use the
 :term:`DEPENDS` variable to state the
-build is dependent on ``virtual/kernel`` for example: DEPENDS =
-"virtual/kernel" During the build, the OpenEmbedded build system picks
+build is dependent on ``virtual/kernel`` for example:
+::
+
+   DEPENDS = "virtual/kernel"
+
+During the build, the OpenEmbedded build system picks
 the correct recipe needed for the ``virtual/kernel`` dependency based on
 the ``PREFERRED_PROVIDER`` variable. If you want to use the small kernel
 mentioned at the beginning of this section, configure your build as
-follows: PREFERRED_PROVIDER_virtual/kernel ??= "kernel-small"
+follows:
+::
+
+   PREFERRED_PROVIDER_virtual/kernel ??= "kernel-small"
 
 .. note::
 
-   Any recipe that
-   PROVIDES
-   a
-   virtual/\*
-   item that is ultimately not selected through
-   PREFERRED_PROVIDER
-   does not get built. Preventing these recipes from building is usually
-   the desired behavior since this mechanism's purpose is to select
-   between mutually exclusive alternative providers.
+   Any recipe that ``PROVIDES`` a ``virtual/*`` item that is ultimately not
+   selected through ``PREFERRED_PROVIDER`` does not get built. Preventing these
+   recipes from building is usually the desired behavior since this mechanism's
+   purpose is to select between mutually exclusive alternative providers.
 
 The following lists specific examples of virtual providers:
 
@@ -2280,8 +2259,8 @@
 Post-installation scripts run immediately after installing a package on
 the target or during image creation when a package is included in an
 image. To add a post-installation script to a package, add a
-``pkg_postinst_``\ PACKAGENAME\ ``()`` function to the recipe file
-(``.bb``) and replace PACKAGENAME with the name of the package you want
+``pkg_postinst_``\ `PACKAGENAME`\ ``()`` function to the recipe file
+(``.bb``) and replace `PACKAGENAME` with the name of the package you want
 to attach to the ``postinst`` script. To apply the post-installation
 script to the main package for the recipe, which is usually what is
 required, specify
@@ -2289,7 +2268,11 @@
 PACKAGENAME.
 
 A post-installation function has the following structure:
-pkg_postinst_PACKAGENAME() { # Commands to carry out }
+::
+
+   pkg_postinst_PACKAGENAME() {
+       # Commands to carry out
+   }
 
 The script defined in the post-installation function is called when the
 root filesystem is created. If the script succeeds, the package is
@@ -2324,19 +2307,11 @@
 .. note::
 
    Equivalent support for pre-install, pre-uninstall, and post-uninstall
-   scripts exist by way of
-   pkg_preinst
-   ,
-   pkg_prerm
-   , and
-   pkg_postrm
-   , respectively. These scrips work in exactly the same way as does
-   pkg_postinst
-   with the exception that they run at different times. Also, because of
-   when they run, they are not applicable to being run at image creation
-   time like
-   pkg_postinst
-   .
+   scripts exist by way of ``pkg_preinst``, ``pkg_prerm``, and ``pkg_postrm``,
+   respectively. These scrips work in exactly the same way as does
+   ``pkg_postinst`` with the exception that they run at different times. Also,
+   because of when they run, they are not applicable to being run at image
+   creation time like ``pkg_postinst``.
 
 .. _new-recipe-testing:
 
@@ -2433,9 +2408,9 @@
    inherit autotools gettext
 
 The variable ``LIC_FILES_CHKSUM`` is used to track source license
-changes as described in the "`Tracking License
-Changes <#usingpoky-configuring-LIC_FILES_CHKSUM>`__" section in the
-Yocto Project Overview and Concepts Manual. You can quickly create
+changes as described in the
+":ref:`dev-manual/dev-manual-common-tasks:tracking license changes`" section in
+the Yocto Project Overview and Concepts Manual. You can quickly create
 Autotool-based recipes in a manner similar to the previous example.
 
 .. _new-recipe-makefile-based-package:
@@ -2472,22 +2447,31 @@
    LICENSE = "GPLv2+"
    LIC_FILES_CHKSUM = "file://COPYING;md5=0636e73ff0215e8d672dc4c32c317bb3 \
        file://include/common.h;beginline=1;endline=17;md5=ba05b07912a44ea2bf81ce409380049c"
+
    # Use the latest version at 26 Oct, 2013
    SRCREV = "9f107132a6a073cce37434ca9cda6917dd8d866b"
    SRC_URI = "git://git.infradead.org/mtd-utils.git \
        file://add-exclusion-to-mkfs-jffs2-git-2.patch \
        "
+
    PV = "1.5.1+git${SRCPV}"
+
    S = "${WORKDIR}/git"
+
    EXTRA_OEMAKE = "'CC=${CC}' 'RANLIB=${RANLIB}' 'AR=${AR}' 'CFLAGS=${CFLAGS} -I${S}/include -DWITHOUT_XATTR' 'BUILDDIR=${S}'"
+
    do_install () {
        oe_runmake install DESTDIR=${D} SBINDIR=${sbindir} MANDIR=${mandir} INCLUDEDIR=${includedir}
    }
+
    PACKAGES =+ "mtd-utils-jffs2 mtd-utils-ubifs mtd-utils-misc"
+
    FILES_mtd-utils-jffs2 = "${sbindir}/mkfs.jffs2 ${sbindir}/jffs2dump ${sbindir}/jffs2reader ${sbindir}/sumtool"
    FILES_mtd-utils-ubifs = "${sbindir}/mkfs.ubifs ${sbindir}/ubi*"
    FILES_mtd-utils-misc = "${sbindir}/nftl* ${sbindir}/ftl* ${sbindir}/rfd* ${sbindir}/doc* ${sbindir}/serve_image ${sbindir}/recv_image"
+
    PARALLEL_MAKE = ""
+
    BBCLASSEXTEND = "native"
 
 Splitting an Application into Multiple Packages
@@ -2503,12 +2487,15 @@
 ::
 
    require xorg-lib-common.inc
+
    SUMMARY = "Xpm: X Pixmap extension library"
    LICENSE = "BSD"
    LIC_FILES_CHKSUM = "file://COPYING;md5=51f4270b012ecd4ab1a164f5f4ed6cf7"
    DEPENDS += "libxext libsm libxt"
    PE = "1"
+
    XORG_PN = "libXpm"
+
    PACKAGES =+ "sxpm cxpm"
    FILES_cxpm = "${bindir}/cxpm"
    FILES_sxpm = "${bindir}/sxpm"
@@ -2619,8 +2606,7 @@
 ---------------------------------
 
 When writing recipes, it is good to conform to existing style
-guidelines. The `OpenEmbedded
-Styleguide <http://www.openembedded.org/wiki/Styleguide>`__ wiki page
+guidelines. The :oe_home:`OpenEmbedded Styleguide </wiki/Styleguide>` wiki page
 provides rough guidelines for preferred recipe style.
 
 It is common for existing recipes to deviate a bit from this style.
@@ -2700,7 +2686,7 @@
 :doc:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata` chapter
 in the BitBake User Manual.
 
--  *Line Continuation (\):* Use the backward slash (``\``) character to
+-  *Line Continuation (\\):* Use the backward slash (``\``) character to
    split a statement over multiple lines. Place the slash character at
    the end of the line that is to be continued on the next line:
    ::
@@ -2750,8 +2736,12 @@
 
    Here is an example where ``VAR1`` is set to "New value" if it is
    currently empty. However, if ``VAR1`` has already been set, it
-   remains unchanged: VAR1 ?= "New value" In this next example, ``VAR1``
-   is left with the value "Original value":
+   remains unchanged:
+   ::
+
+      VAR1 ?= "New value"
+
+   In this next example, ``VAR1`` is left with the value "Original value":
    ::
 
       VAR1 = "Original value"
@@ -2843,7 +2833,7 @@
    specific to individual packages produced by a recipe, you should
    always use an override that specifies the name of the package.
 
--  *Indentation:* Use spaces for indentation rather than than tabs. For
+-  *Indentation:* Use spaces for indentation rather than tabs. For
    shell functions, both currently work. However, it is a policy
    decision of the Yocto Project to use tabs in shell functions. Realize
    that some layers have a policy to use spaces for all indentation.
@@ -2879,8 +2869,7 @@
 .. note::
 
    Although well within the capabilities of the Yocto Project, adding a
-   totally new architecture might require changes to
-   gcc/glibc
+   totally new architecture might require changes to ``gcc``/``glibc``
    and to the site information, which is beyond the scope of this
    manual.
 
@@ -3035,9 +3024,8 @@
 .. note::
 
    Conditions do exist when you should not use AUH to upgrade recipes
-   and you should instead use either
-   devtool upgrade
-   or upgrade your recipes manually:
+   and you should instead use either ``devtool upgrade`` or upgrade your
+   recipes manually:
 
    -  When AUH cannot complete the upgrade sequence. This situation
       usually results because custom patches carried by the recipe
@@ -3052,13 +3040,14 @@
 
 1. *Be Sure the Development Host is Set Up:* You need to be sure that
    your development host is set up to use the Yocto Project. For
-   information on how to set up your host, see the "`Preparing the Build
-   Host <#dev-preparing-the-build-host>`__" section.
+   information on how to set up your host, see the
+   ":ref:`dev-preparing-the-build-host`" section.
 
 2. *Make Sure Git is Configured:* The AUH utility requires Git to be
    configured because AUH uses Git to save upgrades. Thus, you must have
    Git user and email configured. The following command shows your
    configurations:
+   ::
 
       $ git config --list
 
@@ -3092,11 +3081,11 @@
    ::
 
       $ cd ~/poky
-      $ source oe-init-build-env
+      $ source oe-init-build-env your_AUH_build_directory
 
-   your_AUH_build_directory Re-using an existing build directory and its
-   configurations is not recommended as existing settings could cause
-   AUH to fail or behave undesirably.
+   Re-using an existing build directory and its configurations is not
+   recommended as existing settings could cause AUH to fail or behave
+   undesirably.
 
 5. *Make Configurations in Your Local Configuration File:* Several
    settings need to exist in the ``local.conf`` file in the build
@@ -3120,14 +3109,15 @@
    -  If you want to enable testing through the
       :ref:`testimage <ref-classes-testimage*>`
       class, which is optional, you need to have the following set in
-      your ``conf/local.conf`` file: INHERIT += "testimage"
+      your ``conf/local.conf`` file:
+      ::
+
+         INHERIT += "testimage"
 
       .. note::
 
          If your distro does not enable by default ptest, which Poky
-         does, you need the following in your
-         local.conf
-         file:
+         does, you need the following in your ``local.conf`` file:
          ::
 
                  DISTRO_FEATURES_append = " ptest"
@@ -3142,9 +3132,8 @@
 
 7. *Create and Edit an AUH Configuration File:* You need to have the
    ``upgrade-helper/upgrade-helper.conf`` configuration file in your
-   build directory. You can find a sample configuration file in the `AUH
-   source
-   repository <http://git.yoctoproject.org/cgit/cgit.cgi/auto-upgrade-helper/tree/>`__.
+   build directory. You can find a sample configuration file in the
+   :yocto_git:`AUH source repository </cgit/cgit.cgi/auto-upgrade-helper/tree/>`.
 
    Read through the sample file and make configurations as needed. For
    example, if you enabled build history in your ``local.conf`` as
@@ -3160,16 +3149,23 @@
 This next set of examples describes how to use the AUH:
 
 -  *Upgrading a Specific Recipe:* To upgrade a specific recipe, use the
-   following form: $ upgrade-helper.py recipe_name For example, this
-   command upgrades the ``xmodmap`` recipe:
+   following form:
+   ::
+
+      $ upgrade-helper.py recipe_name
+
+   For example, this command upgrades the ``xmodmap`` recipe:
    ::
 
       $ upgrade-helper.py xmodmap
 
 -  *Upgrading a Specific Recipe to a Particular Version:* To upgrade a
-   specific recipe to a particular version, use the following form: $
-   upgrade-helper.py recipe_name -t version For example, this command
-   upgrades the ``xmodmap`` recipe to version 1.2.3:
+   specific recipe to a particular version, use the following form:
+   ::
+
+      $ upgrade-helper.py recipe_name -t version
+
+   For example, this command upgrades the ``xmodmap`` recipe to version 1.2.3:
    ::
 
       $ upgrade-helper.py xmodmap -t 1.2.3
@@ -3201,7 +3197,7 @@
 
 You can easily set up to run the AUH utility on a regular basis by using
 a cron job. See the
-`weeklyjob.sh <http://git.yoctoproject.org/cgit/cgit.cgi/auto-upgrade-helper/tree/weeklyjob.sh>`_
+:yocto_git:`weeklyjob.sh </cgit/cgit.cgi/auto-upgrade-helper/tree/weeklyjob.sh>`
 file distributed with the utility for an example.
 
 .. _gs-using-devtool-upgrade:
@@ -3241,15 +3237,12 @@
 
 .. note::
 
-   AUH uses much of
-   devtool upgrade
-   behind the scenes making AUH somewhat of a "wrapper" application for
-   devtool upgrade
-   .
+   AUH uses much of ``devtool upgrade`` behind the scenes making AUH somewhat
+   of a "wrapper" application for ``devtool upgrade``.
 
 A typical scenario involves having used Git to clone an upstream
-repository that you use during build operations. Because you are (or
-have) built the recipe in the past, the layer is likely added to your
+repository that you use during build operations. Because you have built the
+recipe in the past, the layer is likely added to your
 configuration already. If for some reason, the layer is not added, you
 could add it easily using the
 ":ref:`bitbake-layers <bsp-guide/bsp:creating a new bsp layer using the \`\`bitbake-layers\`\` script>`"
@@ -3281,11 +3274,8 @@
 
 .. note::
 
-   Using the
-   -V
-   option is not necessary. Omitting the version number causes
-   devtool upgrade
-   to upgrade the recipe to the most recent version.
+   Using the ``-V`` option is not necessary. Omitting the version number causes
+   ``devtool upgrade`` to upgrade the recipe to the most recent version.
 
 ::
 
@@ -3358,19 +3348,16 @@
 Manually Upgrading a Recipe
 ---------------------------
 
-If for some reason you choose not to upgrade recipes using the `Auto
-Upgrade Helper (AUH) <#gs-using-the-auto-upgrade-helper>`__ or by using
-```devtool upgrade`` <#gs-using-devtool-upgrade>`__, you can manually
-edit the recipe files to upgrade the versions.
+If for some reason you choose not to upgrade recipes using
+:ref:`gs-using-the-auto-upgrade-helper` or by :ref:`gs-using-devtool-upgrade`,
+you can manually edit the recipe files to upgrade the versions.
 
 .. note::
 
    Manually updating multiple recipes scales poorly and involves many
    steps. The recommendation to upgrade recipe versions is through AUH
-   or
-   devtool upgrade
-   , both of which automate some steps and provide guidance for others
-   needed for the manual process.
+   or ``devtool upgrade``, both of which automate some steps and provide
+   guidance for others needed for the manual process.
 
 To manually upgrade recipe versions, follow these general steps:
 
@@ -3379,7 +3366,7 @@
    changes appropriately. If the version is not part of the recipe name,
    change the value as it is set for ``PV`` within the recipe itself.
 
-2. Update ``SRCREV`` if Needed: If the source code your recipe builds
+2. *Update* ``SRCREV`` *if Needed*: If the source code your recipe builds
    is fetched from Git or some other version control system, update
    :term:`SRCREV` to point to the
    commit hash that matches the new version.
@@ -3455,10 +3442,8 @@
 
 .. note::
 
-   The
-   BP
-   represents the base recipe name, which consists of the name and
-   version:
+   The :term:`BP` represents the base recipe name, which consists of the name
+   and version:
    ::
 
            BP = "${BPN}-${PV}"
@@ -3467,8 +3452,11 @@
 The path to the work directory for the recipe
 (:term:`WORKDIR`) is defined as
 follows:
-${TMPDIR}/work/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR} The
-actual directory depends on several things:
+::
+
+   ${TMPDIR}/work/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}
+
+The actual directory depends on several things:
 
 -  :term:`TMPDIR`: The top-level build
    output directory.
@@ -3500,7 +3488,7 @@
 Using Quilt in Your Workflow
 ============================
 
-`Quilt <http://savannah.nongnu.org/projects/quilt>`__ is a powerful tool
+`Quilt <https://savannah.nongnu.org/projects/quilt>`__ is a powerful tool
 that allows you to capture source code changes without having a clean
 source tree. This section outlines the typical workflow you can use to
 modify source code, test changes, and then preserve the changes in the
@@ -3509,11 +3497,8 @@
 .. note::
 
    With regard to preserving changes to source files, if you clean a
-   recipe or have
-   rm_work
-   enabled, the
-   devtool
-   workflow
+   recipe or have ``rm_work`` enabled, the
+   :ref:`devtool workflow <sdk-manual/sdk-extensible:using \`\`devtool\`\` in your sdk workflow>`
    as described in the Yocto Project Application Development and the
    Extensible Software Development Kit (eSDK) manual is a safer
    development flow than the flow that uses Quilt.
@@ -3535,7 +3520,7 @@
 3. *Create a New Patch:* Before modifying source code, you need to
    create a new patch. To create a new patch file, use ``quilt new`` as
    below:
-   :;
+   ::
 
       $ quilt new my_changes.patch
 
@@ -3562,22 +3547,13 @@
 
    .. note::
 
-      All the modifications you make to the temporary source code
-      disappear once you run the
-      do_clean
-      or
-      do_cleanall
-      tasks using BitBake (i.e.
-      bitbake -c clean
-      package
-      and
-      bitbake -c cleanall
-      package
-      ). Modifications will also disappear if you use the
-      rm_work
-      feature as described in the "
-      Conserving Disk Space During Builds
-      " section.
+      All the modifications you make to the temporary source code disappear
+      once you run the ``do_clean`` or ``do_cleanall`` tasks using BitBake
+      (i.e. ``bitbake -c clean package`` and ``bitbake -c cleanall package``).
+      Modifications will also disappear if you use the ``rm_work`` feature as
+      described in the
+      ":ref:`dev-manual/dev-manual-common-tasks:conserving disk space during builds`"
+      section.
 
 7. *Generate the Patch:* Once your changes work as expected, you need to
    use Quilt to generate the final patch that contains all your
@@ -3649,7 +3625,7 @@
 To manually run a specific task using ``devshell``, run the
 corresponding ``run.*`` script in the
 ``${``\ :term:`WORKDIR`\ ``}/temp``
-directory (e.g., ``run.do_configure.``\ pid). If a task's script does
+directory (e.g., ``run.do_configure.``\ `pid`). If a task's script does
 not exist, which would be the case if the task was skipped by way of the
 sstate cache, you can create the task by first running it outside of the
 ``devshell``:
@@ -3784,8 +3760,7 @@
    :align: center
 
 1. *Set up Your Host Development System to Support Development Using the
-   Yocto Project*: See the "`Setting Up to Use the Yocto
-   Project <#dev-manual-start>`__" section for options on how to get a
+   Yocto Project*: See the ":doc:`dev-manual-start`" section for options on how to get a
    build host ready to use the Yocto Project.
 
 2. *Initialize the Build Environment:* Initialize the build environment
@@ -3796,24 +3771,17 @@
       $ source oe-init-build-env [build_dir]
 
    When you use the initialization script, the OpenEmbedded build system
-   uses ``build`` as the default Build Directory in your current work
-   directory. You can use a build_dir argument with the script to
+   uses ``build`` as the default :term:`Build Directory` in your current work
+   directory. You can use a `build_dir` argument with the script to
    specify a different build directory.
 
    .. note::
 
       A common practice is to use a different Build Directory for
-      different targets. For example,
-      ~/build/x86
-      for a
-      qemux86
-      target, and
-      ~/build/arm
-      for a
-      qemuarm
-      target.
+      different targets. For example, ``~/build/x86`` for a ``qemux86``
+      target, and ``~/build/arm`` for a ``qemuarm`` target.
 
-3. Make Sure Your ``local.conf`` File is Correct: Ensure the
+3. *Make Sure Your* ``local.conf`` *File is Correct*: Ensure the
    ``conf/local.conf`` configuration file, which is found in the Build
    Directory, is set up how you want it. This file defines many aspects
    of the build environment including the target machine architecture
@@ -3830,9 +3798,7 @@
 
    .. note::
 
-      For information on BitBake, see the
-      BitBake User Manual
-      .
+      For information on BitBake, see the :doc:`bitbake:index`.
 
    The target is the name of the recipe you want to build. Common
    targets are the images in ``meta/recipes-core/images``,
@@ -3937,8 +3903,7 @@
 
       A "default" configuration already exists by definition. This
       configuration is named: "" (i.e. empty string) and is defined by
-      the variables coming from your
-      local.conf
+      the variables coming from your ``local.conf``
       file. Consequently, the previous example actually adds two
       additional configurations to your build: "arm" and "x86" along
       with "".
@@ -3962,11 +3927,10 @@
 
 .. note::
 
-   Support for multiple configuration builds in the Yocto Project DISTRO
-   (DISTRO_NAME) Release does not include Shared State (sstate)
+   Support for multiple configuration builds in the Yocto Project &DISTRO;
+   (&DISTRO_NAME;) Release does not include Shared State (sstate)
    optimizations. Consequently, if a build uses the same object twice
-   in, for example, two different
-   TMPDIR
+   in, for example, two different ``TMPDIR``
    directories, the build either loads from an existing sstate cache for
    that build at the start or builds the object fresh.
 
@@ -3999,7 +3963,7 @@
 
    do_image[mcdepends] = "mc:x86:arm:core-image-minimal:do_rootfs"
 
-In this example, the from_multiconfig is "x86". The to_multiconfig is "arm". The
+In this example, the `from_multiconfig` is "x86". The `to_multiconfig` is "arm". The
 task on which the ``do_image`` task in the recipe depends is the
 ``do_rootfs`` task from the ``core-image-minimal`` recipe associated
 with the "arm" multiconfig.
@@ -4083,16 +4047,10 @@
 
       If you choose to not bundle the initramfs image with the kernel
       image, you are essentially using an
-      Initial RAM Disk (initrd)
-      . Creating an initrd is handled primarily through the
-      INITRD_IMAGE
-      ,
-      INITRD_LIVE
-      , and
-      INITRD_IMAGE_LIVE
-      variables. For more information, see the
-      image-live.bbclass
-      file.
+      `Initial RAM Disk (initrd) <https://en.wikipedia.org/wiki/Initrd>`__.
+      Creating an initrd is handled primarily through the :term:`INITRD_IMAGE`,
+      ``INITRD_LIVE``, and ``INITRD_IMAGE_LIVE`` variables. For more
+      information, see the :ref:`ref-classes-image-live` file.
 
 3. *Optionally Add Items to the initramfs Image Through the initramfs
    Image Recipe:* If you add items to the initramfs image by way of its
@@ -4191,15 +4149,10 @@
 
 .. note::
 
-   To use
-   poky-tiny
-   in your build, set the
-   DISTRO
-   variable in your
-   local.conf
-   file to "poky-tiny" as described in the "
-   Creating Your Own Distribution
-   " section.
+   To use ``poky-tiny`` in your build, set the ``DISTRO`` variable in your
+   ``local.conf`` file to "poky-tiny" as described in the
+   ":ref:`dev-manual/dev-manual-common-tasks:creating your own distribution`"
+   section.
 
 Understanding some memory concepts will help you reduce the system size.
 Memory consists of static, dynamic, and temporary memory. Static memory
@@ -4453,17 +4406,10 @@
 
    .. note::
 
-      If
-      DISTRO
-      settings change or fundamental configuration settings such as the
-      filesystem layout, you need to work with a clean
-      TMPDIR
-      . Sharing
-      TMPDIR
-      under these circumstances might work but since it is not
-      guaranteed, you should use a clean
-      TMPDIR
-      .
+      If :term:`DISTRO` settings change or fundamental configuration settings
+      such as the filesystem layout, you need to work with a clean ``TMPDIR``.
+      Sharing ``TMPDIR`` under these circumstances might work but since it is
+      not guaranteed, you should use a clean ``TMPDIR``.
 
 -  *Enable the Appropriate Package Architecture:* By default, the
    OpenEmbedded build system enables three levels of package
@@ -4561,7 +4507,7 @@
    For such cases, you can use some tools to help you sort out the
    situation:
 
-   -  *sstate-diff-machines.sh:* You can find this tool in the
+   -  ``state-diff-machines.sh``*:* You can find this tool in the
       ``scripts`` directory of the Source Repositories. See the comments
       in the script for information on how to use the tool.
 
@@ -4612,8 +4558,7 @@
 .. note::
 
    In order for these settings to take effect, you must globally or
-   locally inherit the
-   externalsrc
+   locally inherit the :ref:`externalsrc <ref-classes-externalsrc>`
    class.
 
 By default, ``externalsrc.bbclass`` builds the source code in a
@@ -4722,7 +4667,11 @@
       latest version of software by setting
       :term:`SRCREV` to
       ``${``\ :term:`AUTOREV`\ ``}``:
-      SRCREV = "${AUTOREV}" When a recipe sets ``SRCREV`` to
+      ::
+
+         SRCREV = "${AUTOREV}"
+
+      When a recipe sets ``SRCREV`` to
       ``${AUTOREV}``, the build system accesses the network in an
       attempt to determine the latest version of software from the SCM.
       Typically, recipes that use ``AUTOREV`` are custom or modified
@@ -4892,9 +4841,7 @@
 .. note::
 
    Some previously released versions of the Yocto Project defined the
-   static library files through
-   ${PN}-dev
-   .
+   static library files through ``${PN}-dev``.
 
 Following is part of the BitBake configuration file, where you can see
 how the static library files are defined:
@@ -4943,7 +4890,7 @@
 target optimizations or architecture formats and combine these together
 into one system image. You can link different binaries in the image
 against the different libraries as needed for specific use cases. This
-feature is called "Multilib."
+feature is called "Multilib".
 
 An example would be where you have most of a system compiled in 32-bit
 mode using 32-bit libraries, but you have something large, like a
@@ -5108,13 +5055,14 @@
 individually specify the libraries is create separate, appropriately
 named recipes where the :term:`PN` part of
 the name includes a portion that differentiates each library version
-(e.g.the major part of the version number). Thus, instead of having a
+(e.g. the major part of the version number). Thus, instead of having a
 single recipe that loads one version of a library (e.g. ``clutter``),
 you provide multiple recipes that result in different versions of the
 libraries you want. As an example, the following two recipes would allow
 the two separate versions of the ``clutter`` library to co-exist on the
 same system:
-::
+
+.. code-block:: none
 
    clutter-1.6_1.6.20.bb
    clutter-1.8_1.8.4.bb
@@ -5245,11 +5193,8 @@
 
    .. note::
 
-      See recipes in the
-      oe-core
-      repository that use that
-      GIR_EXTRA_LIBS_PATH
-      variable as an example.
+      See recipes in the ``oe-core`` repository that use that
+      ``GIR_EXTRA_LIBS_PATH`` variable as an example.
 
 4. Look for any other errors, which probably mean that introspection
    support in a package is not entirely standard, and thus breaks down
@@ -5322,7 +5267,7 @@
       >>> GLib.get_host_name()
 
 5. For something a little more advanced, enter the following see:
-   http://python-gtk-3-tutorial.readthedocs.org/en/latest/introduction.html
+   https://python-gtk-3-tutorial.readthedocs.io/en/latest/introduction.html
 
 Known Issues
 ------------
@@ -5369,7 +5314,7 @@
 A good example of an external toolchain used with the Yocto Project is
 Mentor Graphics Sourcery G++ Toolchain. You can see information on how
 to use that particular layer in the ``README`` file at
-http://github.com/MentorEmbedded/meta-sourcery/. You can find
+https://github.com/MentorEmbedded/meta-sourcery/. You can find
 further information by reading about the
 :term:`TCMODE` variable in the Yocto
 Project Reference Manual's variable glossary.
@@ -5399,11 +5344,9 @@
 
 .. note::
 
-   For a kickstart file reference, see the "
-   OpenEmbedded Kickstart (
-   .wks
-   ) Reference
-   " Chapter in the Yocto Project Reference Manual.
+   For a kickstart file reference, see the
+   ":ref:`ref-manual/ref-kickstart:openembedded kickstart (\`\`.wks\`\`) reference`"
+   Chapter in the Yocto Project Reference Manual.
 
 The ``wic`` command and the infrastructure it is based on is by
 definition incomplete. The purpose of the command is to allow the
@@ -5472,7 +5415,10 @@
    form generated by the OpenEmbedded build system.
 
 -  You must build several native tools, which are built to run on the
-   build system: $ bitbake parted-native dosfstools-native mtools-native
+   build system:
+   ::
+
+      $ bitbake parted-native dosfstools-native mtools-native
 
 -  Include "wic" as part of the
    :term:`IMAGE_FSTYPES`
@@ -5730,8 +5676,7 @@
 
    If you use plugins that have build-time dependencies (e.g. native
    tools, bootloaders, and so forth) when building a Wic image, you need
-   to specify those dependencies using the
-   WKS_FILE_DEPENDS
+   to specify those dependencies using the :term:`WKS_FILE_DEPENDS`
    variable.
 
 Source plugins are subclasses defined in plugin files. As shipped, the
@@ -5837,9 +5782,8 @@
 
    .. note::
 
-      get_bitbake_var()
-      allows you to access non-standard variables that you might want to
-      use for this behavior.
+      ``get_bitbake_var()`` allows you to access non-standard variables that
+      you might want to use for this behavior.
 
 You can extend the source plugin mechanism. To add more hooks, create
 more source plugin methods within ``SourcePlugin`` and the corresponding
@@ -5915,12 +5859,10 @@
 
 .. note::
 
-   For more information on how to use the
-   bmaptool
-   to flash a device with an image, see the "
-   Flashing Images Using
-   bmaptool
-   " section.
+   For more information on how to use the ``bmaptool``
+   to flash a device with an image, see the
+   ":ref:`dev-manual/dev-manual-common-tasks:flashing images using \`\`bmaptool\`\``"
+   section.
 
 Using a Modified Kickstart File
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -6048,9 +5990,7 @@
 .. note::
 
    In order to use Wic to manipulate a Wic image as in this example,
-   your development machine must have the
-   mtools
-   package installed.
+   your development machine must have the ``mtools`` package installed.
 
 The following example examines the contents of the Wic image, deletes
 the existing kernel, and then inserts a new kernel:
@@ -6110,9 +6050,8 @@
    .. note::
 
       If you see the following error, you need to update or create a
-      ~/.mtoolsrc
-      file and be sure to have the line "mtools_skip_check=1" in the
-      file. Then, run the Wic command again:
+      ``~/.mtoolsrc`` file and be sure to have the line "mtools_skip_check=1"
+      in the file. Then, run the Wic command again:
       ::
 
               ERROR: _exec_cmd: /usr/bin/mdir -i /tmp/wic-parttfokuwra ::/ returned '1' instead of 0
@@ -6141,17 +6080,14 @@
          ~/poky/build/tmp/deploy/images/qemux86/core-image-minimal-qemux86.wic:1/vmlinuz
 
    Once the new kernel is added back into the image, you can use the
-   ``dd`` command or ```bmaptool`` <#flashing-images-using-bmaptool>`__
+   ``dd`` command or :ref:`bmaptool
+   <dev-manual/dev-manual-common-tasks:flashing images using \`\`bmaptool\`\`>`
    to flash your wic image onto an SD card or USB stick and test your
    target.
 
    .. note::
 
-      Using
-      bmaptool
-      is generally 10 to 20 times faster than using
-      dd
-      .
+      Using ``bmaptool`` is generally 10 to 20 times faster than using ``dd``.
 
 Flashing Images Using ``bmaptool``
 ==================================
@@ -6168,11 +6104,16 @@
    -  If you are using Ubuntu or Debian distributions, you can install
       the ``bmap-tools`` package using the following command and then
       use the tool without specifying ``PATH`` even from the root
-      account: $ sudo apt-get install bmap-tools
+      account:
+      ::
+
+         $ sudo apt-get install bmap-tools
 
    -  If you are unable to install the ``bmap-tools`` package, you will
       need to build Bmaptool before using it. Use the following command:
-      $ bitbake bmap-tools-native
+      ::
+
+         $ bitbake bmap-tools-native
 
 Following, is an example that shows how to flash a Wic image. Realize
 that while this example uses a Wic image, you can use Bmaptool to flash
@@ -6356,8 +6297,7 @@
 -  Consider enabling a Mandatory Access Control (MAC) framework such as
    SMACK or SELinux and tuning it appropriately for your device's usage.
    You can find more information in the
-   `meta-selinux <http://git.yoctoproject.org/cgit/cgit.cgi/meta-selinux/>`__
-   layer.
+   :yocto_git:`meta-selinux </cgit/cgit.cgi/meta-selinux/>` layer.
 
 Tools for Hardening Your Image
 ------------------------------
@@ -6397,11 +6337,8 @@
 
    .. note::
 
-      The
-      DISTRO
-      variable in your
-      local.conf
-      file determines the name of your distribution.
+      The :term:`DISTRO` variable in your ``local.conf`` file determines the
+      name of your distribution.
 
    You can split out parts of your configuration file into include files
    and then "require" them from within your distribution configuration
@@ -6432,15 +6369,11 @@
 
       If you want to base your distribution configuration file on the
       very basic configuration from OE-Core, you can use
-      conf/distro/defaultsetup.conf
-      as a reference and just include variables that differ as compared
-      to
-      defaultsetup.conf
-      . Alternatively, you can create a distribution configuration file
-      from scratch using the
-      defaultsetup.conf
-      file or configuration files from other distributions such as Poky
-      or Angstrom as references.
+      ``conf/distro/defaultsetup.conf`` as a reference and just include
+      variables that differ as compared to ``defaultsetup.conf``.
+      Alternatively, you can create a distribution configuration file
+      from scratch using the ``defaultsetup.conf`` file or configuration files
+      from other distributions such as Poky or Angstrom as references.
 
 -  *Provide miscellaneous variables:* Be sure to define any other
    variables for which you want to create a default or enforce as part
@@ -6652,11 +6585,8 @@
 
    .. note::
 
-      Technically, a third component, the "epoch" (i.e.
-      PE
-      ) is involved but this discussion for the most part ignores
-      PE
-      .
+      Technically, a third component, the "epoch" (i.e. :term:`PE`) is involved
+      but this discussion for the most part ignores ``PE``.
 
    The version and revision are taken from the
    :term:`PV` and
@@ -6714,8 +6644,7 @@
 .. note::
 
    For additional information on using a PR Service, you can see the
-   PR Service
-   wiki page.
+   :yocto_wiki:`PR Service </wiki/PR_Service>` wiki page.
 
 The Yocto Project uses variables in order of decreasing priority to
 facilitate revision numbering (i.e.
@@ -6836,7 +6765,7 @@
 
 Binary package version numbering strives to follow the `Debian Version
 Field Policy
-Guidelines <http://www.debian.org/doc/debian-policy/ch-controlfields.html>`__.
+Guidelines <https://www.debian.org/doc/debian-policy/ch-controlfields.html>`__.
 These guidelines define how versions are compared and what "increasing"
 a version means.
 
@@ -6864,7 +6793,8 @@
    PV = "1.0+git${SRCPV}"
 
 The OpenEmbedded build system substitutes ``SRCPV`` with the following:
-::
+
+.. code-block:: none
 
    AUTOINC+source_code_revision
 
@@ -6876,7 +6806,8 @@
    :term:`PR`. This behavior results in
    linearly increasing package versions, which is desirable. Here is an
    example:
-   ::
+
+   .. code-block:: none
 
       hello-world-git_0.0+git0+b6558dd387-r0.0_armv7a-neon.ipk
       hello-world-git_0.0+git1+dd2f5c3565-r0.0_armv7a-neon.ipk
@@ -6886,7 +6817,8 @@
    changing the package version since the source revision is included.
    However, package versions are not increased linearly. Here is an
    example:
-   ::
+
+   .. code-block:: none
 
       hello-world-git_0.0+git0+b6558dd387-r0.0_armv7a-neon.ipk
       hello-world-git_0.0+git0+dd2f5c3565-r0.0_armv7a-neon.ipk
@@ -7013,7 +6945,7 @@
          As above
       modulename
          The module name derived using file_regex
-    extra_depends
+   extra_depends
       Extra runtime dependencies (RDEPENDS) to be
       set for all packages. The default value of None
       causes a dependency on the main package
@@ -7232,11 +7164,11 @@
 
 Although other protocols are possible, a server using HTTP typically
 serves packages. If you want to use HTTP, then set up and configure a
-web server such as Apache 2, lighttpd, or SimpleHTTPServer on the
+web server such as Apache 2, lighttpd, or Python web server on the
 machine serving the packages.
 
 To keep things simple, this section describes how to set up a
-SimpleHTTPServer web server to share package feeds from the developer's
+Python web server to share package feeds from the developer's
 machine. Although this server might not be the best for a production
 environment, the setup is simple and straight forward. Should you want
 to use a different server more suited for production (e.g. Apache 2,
@@ -7251,7 +7183,7 @@
 ::
 
    $ cd ~/poky/build/tmp/deploy/rpm
-   $ python -m SimpleHTTPServer
+   $ python3 -m http.server
 
 .. _runtime-package-management-target:
 
@@ -7278,13 +7210,10 @@
 
 .. note::
 
-   For information on the PACKAGE_FEED_* variables, see
-   PACKAGE_FEED_ARCHS
-   ,
-   PACKAGE_FEED_BASE_PATHS
-   , and
-   PACKAGE_FEED_URIS
-   in the Yocto Project Reference Manual variables glossary.
+   For information on the ``PACKAGE_FEED_*`` variables, see
+   :term:`PACKAGE_FEED_ARCHS`, :term:`PACKAGE_FEED_BASE_PATHS`, and
+   :term:`PACKAGE_FEED_URIS` in the Yocto Project Reference Manual variables
+   glossary.
 
 On the target, you must inform DNF that package databases are available.
 You do this by creating a file named
@@ -7299,14 +7228,10 @@
 .. note::
 
    For development purposes, you can point the web server to the build
-   system's
-   deploy
-   directory. However, for production use, it is better to copy the
-   package directories to a location outside of the build area and use
+   system's ``deploy`` directory. However, for production use, it is better to
+   copy the package directories to a location outside of the build area and use
    that location. Doing so avoids situations where the build system
-   overwrites or changes the
-   deploy
-   directory.
+   overwrites or changes the ``deploy`` directory.
 
 When telling DNF where to look for the package databases, you must
 declare individual locations per architecture or a single location used
@@ -7314,7 +7239,8 @@
 
 -  *Create an Explicit List of Architectures:* Define individual base
    URLs to identify where each package database is located:
-   ::
+
+   .. code-block:: none
 
       [oe-packages]
       baseurl=http://my.server/rpm/i586  http://my.server/rpm/qemux86 http://my.server/rpm/all
@@ -7336,7 +7262,8 @@
 
 Once you have informed DNF where to find the package databases, you need
 to fetch them:
-::
+
+.. code-block:: none
 
    # dnf makecache
 
@@ -7345,9 +7272,8 @@
 
 .. note::
 
-   See the
-   DNF documentation
-   for additional information.
+   See the `DNF documentation <https://dnf.readthedocs.io/en/latest/>`__ for
+   additional information.
 
 .. _runtime-package-management-target-ipk:
 
@@ -7374,16 +7300,22 @@
 through an HTTP server named ``my.server``. On the target, create a
 configuration file (e.g. ``my_repo.conf``) inside the ``/etc/opkg/``
 directory containing the following:
-::
+
+.. code-block:: none
 
    src/gz all http://my.server/ipk/all
    src/gz i586 http://my.server/ipk/i586
    src/gz qemux86 http://my.server/ipk/qemux86
 
 Next, instruct ``opkg`` to fetch the
-repository information: # opkg update The ``opkg`` application is now
-able to find, install, and upgrade packages from the specified
-repository.
+repository information:
+
+.. code-block:: none
+
+   # opkg update
+
+The ``opkg`` application is now able to find, install, and upgrade packages
+from the specified repository.
 
 .. _runtime-package-management-target-deb:
 
@@ -7407,7 +7339,8 @@
 serving packages from a ``deb/`` directory containing the ``i586``,
 ``all``, and ``qemux86`` databases through an HTTP server named
 ``my.server``. The list file should contain:
-::
+
+.. code-block:: none
 
    deb http://my.server/deb/all ./
    deb http://my.server/deb/i586 ./
@@ -7415,7 +7348,8 @@
 
 Next, instruct the ``apt`` application
 to fetch the repository information:
-::
+
+.. code-block:: none
 
   # apt-get update
 
@@ -7451,10 +7385,8 @@
 
 .. note::
 
-   Be sure to supply appropriate values for both
-   key_name
-   and
-   passphrase
+   Be sure to supply appropriate values for both `key_name` and
+   `passphrase`.
 
 Aside from the ``RPM_GPG_NAME`` and ``RPM_GPG_PASSPHRASE`` variables in
 the previous example, two optional variables related to signing exist:
@@ -7527,8 +7459,7 @@
 .. note::
 
    A recipe is "ptest-enabled" if it inherits the
-   ptest
-   class.
+   :ref:`ptest <ref-classes-ptest>` class.
 
 Adding ptest to Your Build
 ~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -7562,7 +7493,7 @@
 test. Here is what you have to do for each recipe:
 
 -  *Be sure the recipe inherits
-   the*\ :ref:`ptest <ref-classes-ptest>`\ *class:*
+   the* :ref:`ptest <ref-classes-ptest>` *class:*
    Include the following line in each recipe:
    ::
 
@@ -7630,7 +7561,7 @@
 manager for the JavaScript programming language. The Yocto Project
 supports the NPM :ref:`fetcher <bitbake:bb-fetchers>`. You can
 use this fetcher in combination with
-:doc:```devtool`` <../ref-manual/ref-devtool-reference>` to create
+:doc:`devtool <../ref-manual/ref-devtool-reference>` to create
 recipes that produce NPM packages.
 
 Two workflows exist that allow you to create NPM packages using
@@ -7640,8 +7571,7 @@
 .. note::
 
    While it is possible to create NPM recipes manually, using
-   devtool
-   is far simpler.
+   ``devtool`` is far simpler.
 
 Additionally, some requirements and caveats exist.
 
@@ -7661,7 +7591,7 @@
    is NPM's public registry.
 
 -  Be familiar with
-   :doc:```devtool`` <../ref-manual/ref-devtool-reference>`.
+   :doc:`devtool <../ref-manual/ref-devtool-reference>`.
 
 -  The NPM host tools need the native ``nodejs-npm`` package, which is
    part of the OpenEmbedded environment. You need to get the package by
@@ -7691,9 +7621,7 @@
 
 .. note::
 
-   You must know the
-   cute-files
-   module version.
+   You must know the ``cute-files`` module version.
 
 The first thing you need to do is use ``devtool`` and the NPM fetcher to
 create the recipe:
@@ -7778,11 +7706,8 @@
 
 .. note::
 
-   Because of a know issue, you cannot simply run
-   cute-files
-   as you would if you had run
-   npm install
-   .
+   Because of a known issue, you cannot simply run ``cute-files`` as you would
+   if you had run ``npm install``.
 
 ::
 
@@ -7829,7 +7754,7 @@
        "
 
 In this example,
-the main module is taken from the Git repository and dependents are
+the main module is taken from the Git repository and dependencies are
 taken from the NPM registry. Other than those differences, the recipe is
 basically the same between the two methods. You can build and deploy the
 package exactly as described in the previous section that uses the
@@ -7857,7 +7782,7 @@
 
 -  ``PACKAGE_ADD_METADATA``
 
-<PKGTYPE> is a parameter and expected to be a distinct name of specific
+`<PKGTYPE>` is a parameter and expected to be a distinct name of specific
 package type:
 
 -  IPK for .ipk packages
@@ -7866,15 +7791,17 @@
 
 -  RPM for .rpm packages
 
-<PN> is a parameter and expected to be a package name.
+`<PN>` is a parameter and expected to be a package name.
 
 The variable can contain multiple [one-line] metadata fields separated
-by the literal sequence '\n'. The separator can be redefined using the
+by the literal sequence '\\n'. The separator can be redefined using the
 variable flag ``separator``.
 
 The following is an example that adds two custom fields for ipk
-packages: PACKAGE_ADD_METADATA_IPK = "Vendor: CustomIpk\nGroup:
-Applications/Spreadsheets"
+packages:
+::
+
+   PACKAGE_ADD_METADATA_IPK = "Vendor: CustomIpk\nGroup:Applications/Spreadsheets"
 
 Efficiently Fetching Source Files During a Build
 ================================================
@@ -7956,7 +7883,7 @@
 services are maintained as shell scripts stored in the ``/etc/init.d/``
 directory. Services organize into different run levels. This
 organization is maintained by putting links to the services in the
-``/etc/rcN.d/`` directories, where N/ is one of the following options:
+``/etc/rcN.d/`` directories, where `N/` is one of the following options:
 "S", "0", "1", "2", "3", "4", "5", or "6".
 
 .. note::
@@ -7971,7 +7898,7 @@
 in systemd, where target is also a type of supported unit.
 
 In a SysVinit-based system, services load sequentially (i.e. one by one)
-during and parallelization is not supported. With systemd, services
+during init and parallelization is not supported. With systemd, services
 start in parallel. Needless to say, the method can have an impact on
 system startup performance.
 
@@ -8170,10 +8097,8 @@
 
 .. note::
 
-   The
-   poky-bleeding
-   distribution is not tested on a regular basis. Keep this in mind if
-   you use it.
+   The ``poky-bleeding`` distribution is not tested on a regular basis. Keep
+   this in mind if you use it.
 
 Creating a Read-Only Root Filesystem
 ====================================
@@ -8288,14 +8213,13 @@
 
 The remainder of this section describes the following:
 
--  How you can enable and disable build history
+-  :ref:`How you can enable and disable build history <dev-manual/dev-manual-common-tasks:enabling and disabling build history>`
 
--  How to understand what the build history contains
+-  :ref:`How to understand what the build history contains <dev-manual/dev-manual-common-tasks:understanding what the build history contains>`
 
--  How to limit the information used for build history
+-  :ref:`How to limit the information used for build history <dev-manual/dev-manual-common-tasks:using build history to gather image information only>`
 
--  How to examine the build history from both a command-line and web
-   interface
+-  :ref:`How to examine the build history from both a command-line and web interface <dev-manual/dev-manual-common-tasks:examining build history information>`
 
 Enabling and Disabling Build History
 ------------------------------------
@@ -8349,7 +8273,8 @@
 pairs with information about the package. For example,
 ``buildhistory/packages/i586-poky-linux/busybox/busybox/latest``
 contains the following:
-::
+
+.. code-block:: none
 
    PV = 1.22.1
    PR = r32
@@ -8373,7 +8298,8 @@
 
 A file also exists that corresponds to the recipe from which the package
 came (e.g. ``buildhistory/packages/i586-poky-linux/busybox/latest``):
-::
+
+.. code-block:: none
 
    PV = 1.22.1
    PR = r32
@@ -8432,9 +8358,7 @@
 
 .. note::
 
-   Here are some notes on using the
-   buildhistory-collect-srcrevs
-   command:
+   Here are some notes on using the ``buildhistory-collect-srcrevs`` command:
 
    -  By default, only values where the ``SRCREV`` was not hardcoded
       (usually when ``AUTOREV`` is used) are reported. Use the ``-a``
@@ -8488,7 +8412,8 @@
    even if package management is disabled for the final image.
 
 Here is an example of ``image-info.txt``:
-::
+
+.. code-block:: none
 
    DISTRO = poky
    DISTRO_VERSION = 1.7
@@ -8595,7 +8520,8 @@
       package filenames.
 
 Here is an example of ``sdk-info.txt``:
-::
+
+.. code-block:: none
 
    DISTRO = poky
    DISTRO_VERSION = 1.3+snapshot-20130327
@@ -8652,29 +8578,19 @@
 
 .. note::
 
-   The
-   buildhistory-diff
-   tool requires the
-   GitPython
+   The ``buildhistory-diff`` tool requires the ``GitPython``
    package. Be sure to install it using Pip3 as follows:
    ::
 
          $ pip3 install GitPython --user
 
 
-   Alternatively, you can install
-   python3-git
-   using the appropriate distribution package manager (e.g.
-   apt-get
-   ,
-   dnf
-   , or
-   zipper
-   ).
+   Alternatively, you can install ``python3-git`` using the appropriate
+   distribution package manager (e.g. ``apt-get``, ``dnf``, or ``zipper``).
 
 To see changes to the build history using a web interface, follow the
-instruction in the ``README`` file here.
-http://git.yoctoproject.org/cgit/cgit.cgi/buildhistory-web/.
+instruction in the ``README`` file
+:yocto_git:`here </cgit/cgit.cgi/buildhistory-web/>`.
 
 Here is a sample screenshot of the interface:
 
@@ -8722,9 +8638,7 @@
       .. note::
 
          On some distributions, you also need to comment out "Defaults
-         requiretty" in
-         /etc/sudoers
-         .
+         requiretty" in ``/etc/sudoers``.
 
    -  Manually configure a tap interface for your system.
 
@@ -8739,7 +8653,9 @@
 
          -  The package recipe ``qemu-helper-native`` is required to run
             this script. Build the package using the following command:
-            $ bitbake qemu-helper-native
+            ::
+
+               $ bitbake qemu-helper-native
 
 -  *Set the DISPLAY variable:* You need to set this variable so that
    you have an X server available (e.g. start ``vncserver`` for a
@@ -8846,13 +8762,13 @@
    comments at the top of the BeagleBoneTarget
    ``meta-yocto-bsp/lib/oeqa/controllers/beaglebonetarget.py`` file.
 
--  *"EdgeRouterTarget":* Choose "EdgeRouterTarget" is you are deploying
+-  *"EdgeRouterTarget":* Choose "EdgeRouterTarget" if you are deploying
    images and running tests on the Ubiquiti Networks EdgeRouter Lite.
    For information on how to use these tests, see the comments at the
    top of the EdgeRouterTarget
    ``meta-yocto-bsp/lib/oeqa/controllers/edgeroutertarget.py`` file.
 
--  *"GrubTarget":* Choose the "supports deploying images and running
+-  *"GrubTarget":* Choose "GrubTarget" if you are deploying images and running
    tests on any generic PC that boots using GRUB. For information on how
    to use these tests, see the comments at the top of the GrubTarget
    ``meta-yocto-bsp/lib/oeqa/controllers/grubtarget.py`` file.
@@ -8943,7 +8859,8 @@
 
    In this example, the expect
    script does the following:
-   ::
+
+   .. code-block:: shell
 
       ssh test@10.11.12.1 "pyctl nuc1 arg"
 
@@ -8952,12 +8869,9 @@
 
    .. note::
 
-      You need to customize
-      TEST_POWERCONTROL_CMD
-      and
-      TEST_POWERCONTROL_EXTRA_ARGS
-      for your own setup. The one requirement is that it accepts "on",
-      "off", and "cycle" as the last argument.
+      You need to customize ``TEST_POWERCONTROL_CMD`` and
+      ``TEST_POWERCONTROL_EXTRA_ARGS`` for your own setup. The one requirement
+      is that it accepts "on", "off", and "cycle" as the last argument.
 
 -  When no command is defined, it connects to the device over SSH and
    uses the classic reboot command to reboot the device. Classic reboot
@@ -8968,7 +8882,7 @@
 
 If you have no hardware to automatically perform power control but still
 wish to experiment with automated hardware testing, you can use the
-dialog-power-control script that shows a dialog prompting you to perform
+``dialog-power-control`` script that shows a dialog prompting you to perform
 the required power action. This script requires either KDialog or Zenity
 to be installed. To use this script, set the
 :term:`TEST_POWERCONTROL_CMD`
@@ -9059,9 +8973,7 @@
 .. note::
 
    Be sure that module names do not collide with module names used in
-   the default set of test modules in
-   meta/lib/oeqa/runtime
-   .
+   the default set of test modules in ``meta/lib/oeqa/runtime``.
 
 You can change the set of tests run by appending or overriding
 :term:`TEST_SUITES` variable in
@@ -9082,9 +8994,7 @@
 .. note::
 
    Each module can have multiple classes with multiple test methods.
-   And, Python
-   unittest
-   rules apply.
+   And, Python ``unittest`` rules apply.
 
 Here are some things to keep in mind when running tests:
 
@@ -9098,8 +9008,12 @@
 
       TEST_SUITES_append = " mytest"
 
--  Run a specific list of tests as follows: TEST_SUITES = "test1 test2
-   test3" Remember, order is important. Be sure to place a test that is
+-  Run a specific list of tests as follows:
+   ::
+
+     TEST_SUITES = "test1 test2 test3"
+
+   Remember, order is important. Be sure to place a test that is
    dependent on another test later in the order.
 
 Exporting Tests
@@ -9114,7 +9028,7 @@
 ``local.conf`` file:
 ::
 
-   INHERIT +="testexport"
+   INHERIT += "testexport"
    TEST_TARGET_IP = "IP-address-for-the-test-target"
    TEST_SERVER_IP = "IP-address-for-the-test-server"
 
@@ -9139,7 +9053,7 @@
 ``core-image-sato`` image:
 ::
 
-   INHERIT +="testexport"
+   INHERIT += "testexport"
    TEST_TARGET_IP = "192.168.7.2"
    TEST_SERVER_IP = "192.168.7.1"
 
@@ -9182,11 +9096,7 @@
 
    Structure shell commands such that you rely on them and they return a
    single code for success. Be aware that sometimes you will need to
-   parse the output. See the
-   df.py
-   and
-   date.py
-   modules for examples.
+   parse the output. See the ``df.py`` and ``date.py`` modules for examples.
 
 You will notice that all test classes inherit ``oeRuntimeTest``, which
 is found in ``meta/lib/oetest.py``. This base class offers some helper
@@ -9279,10 +9189,8 @@
 
 .. note::
 
-   This method uses
-   scp
-   to copy files from the host to the target, which causes permissions
-   and special attributes to be lost.
+   This method uses ``scp`` to copy files from the host to the target, which
+   causes permissions and special attributes to be lost.
 
 A JSON file is used to define the packages needed by a test. This file
 must be in the same path as the file used to define the tests.
@@ -9348,9 +9256,9 @@
    of the console output. You can enter the commands after the build
    completes to log error information into a common database, that can
    help you figure out what might be going wrong. For information on how
-   to enable and use this feature, see the "
-   Using the Error Reporting Tool
-   " section.
+   to enable and use this feature, see the
+   ":ref:`dev-manual/dev-manual-common-tasks:using the error reporting tool`"
+   section.
 
 The following list shows the debugging topics in the remainder of this
 section:
@@ -9423,18 +9331,18 @@
 ------------------------------
 
 You can find the log for a task in the file
-``${``\ :term:`WORKDIR`\ ``}/temp/log.do_``\ taskname.
+``${``\ :term:`WORKDIR`\ ``}/temp/log.do_``\ `taskname`.
 For example, the log for the
 :ref:`ref-tasks-compile` task of the
 QEMU minimal image for the x86 machine (``qemux86``) might be in
 ``tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/temp/log.do_compile``.
 To see the commands :term:`BitBake` ran
-to generate a log, look at the corresponding ``run.do_``\ taskname file
+to generate a log, look at the corresponding ``run.do_``\ `taskname` file
 in the same directory.
 
-``log.do_``\ taskname and ``run.do_``\ taskname are actually symbolic
-links to ``log.do_``\ taskname\ ``.``\ pid and
-``log.run_``\ taskname\ ``.``\ pid, where pid is the PID the task had
+``log.do_``\ `taskname` and ``run.do_``\ `taskname` are actually symbolic
+links to ``log.do_``\ `taskname`\ ``.``\ `pid` and
+``log.run_``\ `taskname`\ ``.``\ `pid`, where `pid` is the PID the task had
 when it ran. The symlinks always point to the files corresponding to the
 most recent run.
 
@@ -9477,7 +9385,7 @@
 
 In the output of ``bitbake -e``, each variable is preceded by a
 description of how the variable got its value, including temporary
-values that were later overriden. This description also includes
+values that were later overridden. This description also includes
 variable flags (varflags) set on the variable. The output can be very
 helpful during debugging.
 
@@ -9548,7 +9456,8 @@
    ``make-doc`` package:
    ::
 
-      $ oe-pkgdata-util find-path /usr/share/man/man1/make.1 make-doc: /usr/share/man/man1/make.1
+      $ oe-pkgdata-util find-path /usr/share/man/man1/make.1
+      make-doc: /usr/share/man/man1/make.1
 
 -  ``oe-pkgdata-util lookup-recipe package ...``: Lists the name
    of the recipes that produce the given packages.
@@ -9557,7 +9466,7 @@
 facility:
 ::
 
-   $ oe-pkgdata-util DASHDASHhelp
+   $ oe-pkgdata-util --help
    $ oe-pkgdata-util subcommand --help
 
 .. _dev-viewing-dependencies-between-recipes-and-tasks:
@@ -9578,8 +9487,8 @@
 This command writes the following files in the current directory:
 
 -  ``pn-buildlist``: A list of recipes/targets involved in building
-   recipename. "Involved" here means that at least one task from the
-   recipe needs to run when building recipename from scratch. Targets
+   `recipename`. "Involved" here means that at least one task from the
+   recipe needs to run when building `recipename` from scratch. Targets
    that are in
    :term:`ASSUME_PROVIDED`
    are not listed.
@@ -9589,7 +9498,7 @@
 The graphs are in
 `DOT <https://en.wikipedia.org/wiki/DOT_%28graph_description_language%29>`__
 format and can be converted to images (e.g. using the ``dot`` tool from
-`Graphviz <http://www.graphviz.org/>`__).
+`Graphviz <https://www.graphviz.org/>`__).
 
 .. note::
 
@@ -9688,10 +9597,8 @@
 
    .. note::
 
-      Functions (e.g.
-      base_do_fetch
-      ) also count as variable dependencies. These functions in turn
-      depend on the variables they reference.
+      Functions (e.g. ``base_do_fetch``) also count as variable dependencies.
+      These functions in turn depend on the variables they reference.
 
    The output of ``bitbake-dumpsig`` also includes the value each
    variable had, a list of dependencies for each variable, and
@@ -9715,10 +9622,9 @@
 
 .. note::
 
-   Two common values for
-   SIGNATURE_HANDLER
-   are "none" and "printdiff", which dump only the signature or compare
-   the dumped signature with the cached one, respectively.
+   Two common values for `SIGNATURE_HANDLER` are "none" and "printdiff", which
+   dump only the signature or compare the dumped signature with the cached one,
+   respectively.
 
 Using BitBake with either of these options causes BitBake to dump out
 ``sigdata`` files in the ``stamps`` directory for every task it would
@@ -9750,7 +9656,7 @@
 :ref:`checksums <overview-checksums>` and
 :ref:`overview-manual/overview-manual-concepts:shared state` cache to avoid unnecessarily
 rebuilding tasks. Collectively, this scheme is known as "shared state
-code."
+code".
 
 As with all schemes, this one has some drawbacks. It is possible that
 you could make implicit changes to your code that the checksum
@@ -9787,8 +9693,7 @@
 
    For an example of a commit that makes a cosmetic change to invalidate
    shared state, see this
-   commit
-   .
+   :yocto_git:`commit </cgit.cgi/poky/commit/meta/classes/package.bbclass?id=737f8bbb4f27b4837047cb9b4fbfe01dfde36d54>`.
 
 .. _dev-debugging-taskrunning:
 
@@ -9823,14 +9728,9 @@
 
 .. note::
 
-   The reason
-   -f
-   is never required when running the
-   do_devshell
-   task is because the
-   [
-   nostamp
-   ]
+   The reason ``-f`` is never required when running the
+   :ref:`ref-tasks-devshell` task is because the
+   [\ :ref:`nostamp <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:variable flags>`\ ]
    variable flag is already set for the task.
 
 The following example shows one way you can use the ``-f`` option:
@@ -9856,8 +9756,7 @@
 
 .. note::
 
-   This option is upper-cased and is separate from the
-   -c
+   This option is upper-cased and is separate from the ``-c``
    option, which is lower-cased.
 
 Using this option invalidates the given task and then runs the
@@ -9879,7 +9778,8 @@
    BitBake explicitly keeps track of which tasks have been tainted in
    this fashion, and will print warnings such as the following for
    builds involving such tasks:
-   ::
+
+   .. code-block:: none
 
       WARNING: /home/ulf/poky/meta/recipes-sato/matchbox-desktop/matchbox-desktop_2.1.bb.do_compile is tainted from a forced run
 
@@ -9914,7 +9814,7 @@
 reason behind it. Each ``-D`` option you use increases the logging
 level. The most common usage is ``-DDD``.
 
-The output from ``bitbake -DDD -v`` targetname can reveal why BitBake
+The output from ``bitbake -DDD -v targetname`` can reveal why BitBake
 chose a certain version of a package or why BitBake picked a certain
 provider. This command could also help you in a situation where you
 think BitBake did something unexpected.
@@ -9945,7 +9845,7 @@
 The Yocto Project provides several logging functions for producing
 debugging output and reporting errors and warnings. For Python
 functions, the following logging functions exist. All of these functions
-log to ``${T}/log.do_``\ task, and can also log to standard output
+log to ``${T}/log.do_``\ `task`, and can also log to standard output
 (stdout) with the right settings:
 
 -  ``bb.plain(msg)``: Writes msg as is to the log while also
@@ -9974,9 +9874,8 @@
 
    .. note::
 
-      bb.fatal()
-      raises an exception, which means you do not need to put a "return"
-      statement after the function.
+      ``bb.fatal()`` raises an exception, which means you do not need to put a
+      "return" statement after the function.
 
 The same logging functions are also available in shell functions, under
 the names ``bbplain``, ``bbnote``, ``bbdebug``, ``bbwarn``, ``bberror``,
@@ -10059,12 +9958,8 @@
 
 .. note::
 
-   If you cannot properly fix a
-   make
-   race condition, you can work around it by clearing either the
-   PARALLEL_MAKE
-   or
-   PARALLEL_MAKEINST
+   If you cannot properly fix a ``make`` race condition, you can work around it
+   by clearing either the :term:`PARALLEL_MAKE` or :term:`PARALLEL_MAKEINST`
    variables.
 
 The Failure
@@ -10081,7 +9976,8 @@
 
 If you examine the output or the log file, you see the failure during
 ``make``:
-::
+
+.. code-block:: none
 
    | DEBUG: SITE files ['endian-little', 'bit-32', 'ix86-common', 'common-linux', 'common-glibc', 'i586-linux', 'common']
    | DEBUG: Executing shell function do_compile
@@ -10266,7 +10162,9 @@
 locally:
 ::
 
-   $ bitbake neard This build should succeed.
+   $ bitbake neard
+
+This build should succeed.
 
 Now you can open up a ``devshell`` again and repeat the clean and make
 operations as follows:
@@ -10295,15 +10193,13 @@
 the Yocto Project and is installed in SDK images by default. See the
 ":ref:`ref-manual/ref-images:Images`" chapter in the Yocto
 Project Reference Manual for a description of these images. You can find
-information on GDB at http://sourceware.org/gdb/.
+information on GDB at https://sourceware.org/gdb/.
 
 .. note::
 
-   For best results, install debug (
-   -dbg
-   ) packages for the applications you are going to debug. Doing so
-   makes extra debug symbols available that give you more meaningful
-   output.
+   For best results, install debug (``-dbg``) packages for the applications you
+   are going to debug. Doing so makes extra debug symbols available that give
+   you more meaningful output.
 
 Sometimes, due to memory or disk space constraints, it is not possible
 to use GDB directly on the remote target to debug applications. These
@@ -10340,7 +10236,7 @@
 To remain consistent with GDB documentation and terminology, the binary
 being debugged on the remote target machine is referred to as the
 "inferior" binary. For documentation on GDB see the `GDB
-site <http://sourceware.org/gdb/documentation/>`__.
+site <https://sourceware.org/gdb/documentation/>`__.
 
 The following steps show you how to debug using the GNU project
 debugger.
@@ -10413,13 +10309,11 @@
 
    .. note::
 
-      If you run
-      bitbake gdb-cross
-      , the OpenEmbedded build system suggests the actual image (e.g.
-      gdb-cross-i586
-      ). The suggestion is usually the actual name you want to use.
+      If you run ``bitbake gdb-cross``, the OpenEmbedded build system suggests
+      the actual image (e.g. ``gdb-cross-i586``). The suggestion is usually the
+      actual name you want to use.
 
-4. *Set up the* ``debugfs``
+4. *Set up the* ``debugfs``\ *:*
 
    Run the following commands to set up the ``debugfs``:
    ::
@@ -10429,19 +10323,19 @@
       $ tar xvfj build-dir/tmp-glibc/deploy/images/machine/image.rootfs.tar.bz2
       $ tar xvfj build-dir/tmp-glibc/deploy/images/machine/image-dbg.rootfs.tar.bz2
 
-5. *Set up GDB*
+5. *Set up GDB:*
 
    Install the SDK (if you built one) and then source the correct
    environment file. Sourcing the environment file puts the SDK in your
    ``PATH`` environment variable.
 
    If you are using the build system, Gdb is located in
-   build-dir/tmp/sysroots/host/usr/bin/architecture/architecture-gdb
+   `build-dir`\ ``/tmp/sysroots/``\ `host`\ ``/usr/bin/``\ `architecture`\ ``/``\ `architecture`\ ``-gdb``
 
 6. *Boot the target:*
 
    For information on how to run QEMU, see the `QEMU
-   Documentation <http://wiki.qemu.org/Documentation/GettingStartedDevelopers>`__.
+   Documentation <https://wiki.qemu.org/Documentation/GettingStartedDevelopers>`__.
 
    .. note::
 
@@ -10451,7 +10345,8 @@
 
    Debugging a program involves running gdbserver on the target and then
    running Gdb on the host. The example in this step debugs ``gzip``:
-   ::
+
+   .. code-block:: shell
 
       root@qemux86:~# gdbserver localhost:1234 /bin/gzip —help
 
@@ -10475,12 +10370,9 @@
 
    .. note::
 
-      The Gdb
-      set
-      commands in the previous example can be placed into the users
-      ~/.gdbinit
-      file. Upon starting, Gdb automatically runs whatever commands are
-      in that file.
+      The Gdb ``set`` commands in the previous example can be placed into the
+      users ``~/.gdbinit`` file. Upon starting, Gdb automatically runs whatever
+      commands are in that file.
 
 8. *Deploying without a full image rebuild:*
 
@@ -10518,9 +10410,11 @@
 
 -  Ensure that GDB is on the target. You can do this by adding "gdb" to
    :term:`IMAGE_INSTALL`:
-   IMAGE_INSTALL_append = " gdb" Alternatively, you can add
-   "tools-debug" to
-   :term:`IMAGE_FEATURES`:
+   ::
+
+      IMAGE_INSTALL_append = " gdb"
+
+   Alternatively, you can add "tools-debug" to :term:`IMAGE_FEATURES`:
    ::
 
       IMAGE_FEATURES_append = " tools-debug"
@@ -10541,18 +10435,13 @@
 
    To improve the debug information accuracy, you can reduce the level
    of optimization used by the compiler. For example, when adding the
-   following line to your
-   local.conf
-   file, you will reduce optimization from
-   FULL_OPTIMIZATION
-   of "-O2" to
-   DEBUG_OPTIMIZATION
+   following line to your ``local.conf`` file, you will reduce optimization
+   from :term:`FULL_OPTIMIZATION` of "-O2" to :term:`DEBUG_OPTIMIZATION`
    of "-O -fno-omit-frame-pointer":
    ::
 
            DEBUG_BUILD = "1"
 
-
    Consider that this will reduce the application's performance and is
    recommended only for debugging purposes.
 
@@ -10584,11 +10473,9 @@
 
    .. note::
 
-      Removing
-      TMPDIR
-      might be a workaround rather than a fix. Consequently, trying to
-      determine the underlying cause of an issue before removing the
-      directory is a good idea.
+      Removing ``TMPDIR`` might be a workaround rather than a fix.
+      Consequently, trying to determine the underlying cause of an issue before
+      removing the directory is a good idea.
 
 -  Understanding how a feature is used in practice within existing
    recipes can be very helpful. It is recommended that you configure
@@ -10633,9 +10520,7 @@
 
       The manuals might not be the right place to document variables
       that are purely internal and have a limited scope (e.g. internal
-      variables used to implement a single
-      .bbclass
-      file).
+      variables used to implement a single ``.bbclass`` file).
 
 Making Changes to the Yocto Project
 ===================================
@@ -10649,15 +10534,15 @@
 ---------------------------------------------
 
 Use the Yocto Project implementation of
-`Bugzilla <http://www.bugzilla.org/about/>`__ to submit a defect (bug)
+`Bugzilla <https://www.bugzilla.org/about/>`__ to submit a defect (bug)
 against the Yocto Project. For additional information on this
-implementation of Bugzilla see the :ref:"`Yocto Project
+implementation of Bugzilla see the ":ref:`Yocto Project
 Bugzilla <resources-bugtracker>`" section in the
 Yocto Project Reference Manual. For more detail on any of the following
 steps, see the Yocto Project
 :yocto_wiki:`Bugzilla wiki page </wiki/Bugzilla_Configuration_and_Bug_Tracking>`.
 
-Use the following general steps to submit a bug"
+Use the following general steps to submit a bug:
 
 1.  Open the Yocto Project implementation of :yocto_bugs:`Bugzilla <>`.
 
@@ -10671,7 +10556,7 @@
     Runtime", "BSPs", and "bsps-meta-intel", respectively.
 
 4.  Choose the "Version" of the Yocto Project for which you found the
-    bug (e.g. DISTRO).
+    bug (e.g. &DISTRO;).
 
 5.  Determine and select the "Severity" of the bug. The severity
     indicates how the bug impacted your work.
@@ -10737,24 +10622,24 @@
 varies by component:
 
 -  *Core Metadata:* Send your patch to the
-   `openembedded-core <http://lists.openembedded.org/mailman/listinfo/openembedded-core>`__
+   :oe_lists:`openembedded-core </g/openembedded-core>`
    mailing list. For example, a change to anything under the ``meta`` or
    ``scripts`` directories should be sent to this mailing list.
 
 -  *BitBake:* For changes to BitBake (i.e. anything under the
    ``bitbake`` directory), send your patch to the
-   `bitbake-devel <http://lists.openembedded.org/mailman/listinfo/bitbake-devel>`__
+   :oe_lists:`bitbake-devel </g/bitbake-devel>`
    mailing list.
 
 -  *"meta-\*" trees:* These trees contain Metadata. Use the
-   `poky <https://lists.yoctoproject.org/g/poky>`__ mailing list.
+   :yocto_lists:`poky </g/poky>` mailing list.
 
--  *Documentation*: For changes to the Yocto Project documentation, use the `docs
-   <https://lists.yoctoproject.org/g/docs>`__ mailing list.
+-  *Documentation*: For changes to the Yocto Project documentation, use the
+   :yocto_lists:`docs </g/docs>` mailing list.
 
 For changes to other layers hosted in the Yocto Project source
-repositories (i.e. ``yoctoproject.org``) and tools use the `Yocto Project
-<https://lists.yoctoproject.org/g/yocto/>`__ general mailing list.
+repositories (i.e. ``yoctoproject.org``) and tools use the
+:yocto_lists:`Yocto Project </g/yocto/>` general mailing list.
 
 .. note::
 
@@ -10792,7 +10677,7 @@
    flow. Asking about the status of a patch or change is reasonable if
    the change has been idle for a while with no feedback. The Yocto
    Project does have plans to use
-   Patchwork
+   `Patchwork <https://en.wikipedia.org/wiki/Patchwork_(software)>`__
    to track the status of patches and also to automatically preview
    patches.
 
@@ -10810,8 +10695,7 @@
 
    You can find general Git information on how to push a change upstream
    in the
-   Git Community Book
-   .
+   `Git Community Book <https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows>`__.
 
 1. *Make Your Changes Locally:* Make your changes in your local Git
    repository. You should make small, controlled, isolated changes.
@@ -10830,7 +10714,8 @@
       required by the Linux kernel. Adding this line signifies that you,
       the submitter, have agreed to the Developer's Certificate of
       Origin 1.1 as follows:
-      ::
+
+      .. code-block:: none
 
          Developer's Certificate of Origin 1.1
 
@@ -10858,7 +10743,7 @@
              maintained indefinitely and may be redistributed consistent with
              this project or the open source license(s) involved.
 
-   -  Provide a single-line summary of the change. and, if more
+   -  Provide a single-line summary of the change and, if more
       explanation is needed, provide more detail in the body of the
       commit. This summary is typically viewable in the "shortlist" of
       changes. Thus, providing something short and descriptive that
@@ -10901,10 +10786,10 @@
 
    For example, suppose you have permissions to push
    into the upstream ``meta-intel-contrib`` repository and you are
-   working in a local branch named your_name\ ``/README``. The following
+   working in a local branch named `your_name`\ ``/README``. The following
    command pushes your local commits to the ``meta-intel-contrib``
    upstream repository and puts the commit in a branch named
-   your_name\ ``/README``:
+   `your_name`\ ``/README``:
    ::
 
       $ git push meta-intel-contrib your_name/README
@@ -10963,7 +10848,7 @@
       $ ~/poky/scripts/create-pull-request -u meta-intel-contrib -s "Updated Manual Section Reference in README"
 
    Running this script forms ``*.patch`` files in a folder named
-   ``pull-``\ PID in the current directory. One of the patch files is a
+   ``pull-``\ `PID` in the current directory. One of the patch files is a
    cover letter.
 
    Before running the ``send-pull-request`` script, you must edit the
@@ -10980,8 +10865,7 @@
 
    .. note::
 
-      For help on using these scripts, simply provide the
-      -h
+      For help on using these scripts, simply provide the ``-h``
       argument as follows:
       ::
 
@@ -11023,9 +10907,9 @@
    Developer's Certificate of Origin (DCO) shown earlier.
 
    When you form a commit, you must follow certain standards established
-   by the Yocto Project development team. See `Step
-   3 <#making-sure-you-have-correct-commit-information>`__ in the
-   previous section for information on how to provide commit information
+   by the Yocto Project development team. See :ref:`Step 3
+   <dev-manual/dev-manual-common-tasks:using scripts to push a change upstream and request a pull>`
+   in the previous section for information on how to provide commit information
    that meets Yocto Project commit message standards.
 
 4. *Format the Commit:* Format the commit into an email message. To
@@ -11066,12 +10950,9 @@
 
    .. note::
 
-      In order to use
-      git send-email
-      , you must have the proper Git packages installed on your host.
-      For Ubuntu, Debian, and Fedora the package is
-      git-email
-      .
+      In order to use ``git send-email``, you must have the proper Git packages
+      installed on your host.
+      For Ubuntu, Debian, and Fedora the package is ``git-email``.
 
    The ``git send-email`` command sends email by using a local or remote
    Mail Transport Agent (MTA) such as ``msmtp``, ``sendmail``, or
@@ -11297,10 +11178,7 @@
 
    When using a string subset, be sure to use the part of the expanded
    string that precedes the appended underscore character (e.g.
-   usethispart_1.3
-   ,
-   usethispart_1.4
-   , and so forth).
+   ``usethispart_1.3``, ``usethispart_1.4``, and so forth).
 
 For example, simply specifying the string "commercial" in the whitelist
 matches any expanded ``LICENSE_FLAGS`` definition that starts with the
@@ -11401,6 +11279,8 @@
 -  Compilation scripts and modifications to the source code must be
    provided.
 
+-  spdx files can be provided.
+
 There are other requirements beyond the scope of these three and the
 methods described in this section (e.g. the mechanism through which
 source code is distributed).
@@ -11417,9 +11297,7 @@
 .. note::
 
    The Yocto Project generates a license manifest during image creation
-   that is located in
-   ${DEPLOY_DIR}/licenses/
-   image_name-datestamp
+   that is located in ``${DEPLOY_DIR}/licenses/``\ `image_name`\ ``-``\ `datestamp`
    to assist with any audits.
 
 Providing the Source Code
@@ -11466,7 +11344,8 @@
 A way to help mitigate the size issue is to only release tarballs for
 licenses that require the release of source. Let us assume you are only
 concerned with GPL code as identified by running the following script:
-::
+
+.. code-block:: shell
 
    # Script to archive a subset of packages matching specific license(s)
    # Source and license files are copied into sub folders of package folder
@@ -11556,7 +11435,8 @@
 of GPLv3. One way of doing that is with a clean checkout of the version
 of the Yocto Project and layers used during your build. Here is an
 example:
-::
+
+.. code-block:: shell
 
    # We built using the dunfell branch of the poky repo
    $ git clone -b dunfell git://git.yoctoproject.org/poky
@@ -11595,6 +11475,40 @@
 your requirements to include the scripts to control compilation as well
 as any modifications to the original source.
 
+Providing spdx files
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The spdx module has been integrated to a layer named meta-spdxscanner.
+meta-spdxscanner provides several kinds of scanner. If you want to enable
+this function, you have to follow the following steps:
+
+1. Add meta-spdxscanner layer into ``bblayers.conf``. 
+
+2. Refer to the README in meta-spdxscanner to setup the environment (e.g, 
+   setup a fossology server) needed for the scanner.
+
+3. Meta-spdxscanner provides several methods within the bbclass to create spdx files.
+   Please choose one that you want to use and enable the spdx task. You have to
+   add some config options in ``local.conf`` file in your :term:`Build
+   Directory`. The following is an example showing how to generate spdx files
+   during bitbake using the fossology-python.bbclass::
+
+      # Select fossology-python.bbclass.
+      INHERIT += "fossology-python"
+      # For fossology-python.bbclass, TOKEN is necessary, so, after setup a
+      # Fossology server, you have to create a token.
+      TOKEN = "eyJ0eXAiO..."
+      # The fossology server is necessary for fossology-python.bbclass.
+      FOSSOLOGY_SERVER = "http://xx.xx.xx.xx:8081/repo"
+      # If you want to upload the source code to a special folder:
+      FOLDER_NAME = "xxxx" //Optional
+      # If you don't want to put spdx files in tmp/deploy/spdx, you can enable:
+      SPDX_DEPLOY_DIR = "${DEPLOY_DIR}" //Optional
+
+For more usage information refer to :yocto_git:`the meta-spdxscanner repository
+</cgit/cgit.cgi/meta-spdxscanner/>`.
+
+
 Copying Licenses that Do Not Exist
 ----------------------------------
 
@@ -11625,7 +11539,7 @@
 database.
 
 A live instance of the error reporting server exists at
-http://errors.yoctoproject.org. This server exists so that when
+https://errors.yoctoproject.org. This server exists so that when
 you want to get help with build failures, you can submit all of the
 information on the failure easily and then point to the URL in your bug
 report or send an email to the mailing list.
@@ -11667,7 +11581,7 @@
    $ send-error-report /home/brandusa/project/poky/build/tmp/log/error-report/error_report_201403141617.txt
 
 In the previous example, the errors are sent to a public database
-available at http://errors.yoctoproject.org, which is used by the
+available at https://errors.yoctoproject.org, which is used by the
 entire community. If you specify a particular server, you can send the
 errors to a different database. Use the following command for more
 information on available options:
@@ -11679,7 +11593,7 @@
 sent as well as to provide a name and optional email address. Once you
 satisfy these prompts, the command returns a link from the server that
 corresponds to your entry in the database. For example, here is a
-typical link: http://errors.yoctoproject.org/Errors/Details/9522/
+typical link: https://errors.yoctoproject.org/Errors/Details/9522/
 
 Following the link takes you to a web interface where you can browse,
 query the errors, and view statistics.
@@ -11698,8 +11612,7 @@
 ------------------------------------------
 
 If you want to set up your own error reporting server, you can obtain
-the code from the Git repository at
-http://git.yoctoproject.org/cgit/cgit.cgi/error-report-web/.
+the code from the Git repository at :yocto_git:`/cgit/cgit.cgi/error-report-web/`.
 Instructions on how to set it up are in the README document.
 
 .. _dev-using-wayland-and-weston:
@@ -11707,7 +11620,7 @@
 Using Wayland and Weston
 ========================
 
-`Wayland <http://en.wikipedia.org/wiki/Wayland_(display_server_protocol)>`__
+`Wayland <https://en.wikipedia.org/wiki/Wayland_(display_server_protocol)>`__
 is a computer display server protocol that provides a method for
 compositing window managers to communicate directly with applications
 and video hardware and expects them to communicate with input hardware
@@ -11717,7 +11630,7 @@
 
 The Yocto Project provides the Wayland protocol libraries and the
 reference
-`Weston <http://en.wikipedia.org/wiki/Wayland_(display_server_protocol)#Weston>`__
+`Weston <https://en.wikipedia.org/wiki/Wayland_(display_server_protocol)#Weston>`__
 compositor as part of its release. You can find the integrated packages
 in the ``meta`` layer of the :term:`Source Directory`.
 Specifically, you
diff --git a/poky/documentation/dev-manual/dev-manual-intro.rst b/poky/documentation/dev-manual/dev-manual-intro.rst
index da08b7b..05136f7 100644
--- a/poky/documentation/dev-manual/dev-manual-intro.rst
+++ b/poky/documentation/dev-manual/dev-manual-intro.rst
@@ -39,7 +39,7 @@
 
 -  Reference or Conceptual Material: This type of material resides in an
    appropriate reference manual. For example, system variables are
-   documented in the :doc`../ref-manual/ref-manual`.
+   documented in the :doc:`../ref-manual/ref-manual`.
 
 -  Detailed Public Information Not Specific to the Yocto Project: For
    example, exhaustive information on how to use the Source Control
diff --git a/poky/documentation/dev-manual/dev-manual-qemu.rst b/poky/documentation/dev-manual/dev-manual-qemu.rst
index 9337a35..c91e8b5 100644
--- a/poky/documentation/dev-manual/dev-manual-qemu.rst
+++ b/poky/documentation/dev-manual/dev-manual-qemu.rst
@@ -33,10 +33,10 @@
 For official information and documentation on QEMU in general, see the
 following references:
 
--  `QEMU Website <http://wiki.qemu.org/Main_Page>`__\ *:* The official
+-  `QEMU Website <https://wiki.qemu.org/Main_Page>`__\ *:* The official
    website for the QEMU Open Source project.
 
--  `Documentation <http://wiki.qemu.org/Manual>`__\ *:* The QEMU user
+-  `Documentation <https://wiki.qemu.org/Manual>`__\ *:* The QEMU user
    manual.
 
 .. _qemu-running-qemu:
@@ -141,14 +141,14 @@
 
    -  This example does not provide enough information for QEMU to
       launch. While the command does provide a root filesystem type, it
-      must also minimally provide a MACHINE, KERNEL, or VM option.
+      must also minimally provide a `MACHINE`, `KERNEL`, or `VM` option.
       ::
 
          $ runqemu ext4
 
    -  This example specifies to boot a virtual machine image
       (``.wic.vmdk`` file). From the ``.wic.vmdk``, ``runqemu``
-      determines the QEMU architecture (MACHINE) to be "qemux86-64" and
+      determines the QEMU architecture (`MACHINE`) to be "qemux86-64" and
       the root filesystem type to be "vmdk".
       ::
 
@@ -208,7 +208,8 @@
    extracts it into a location that you specify. Here is an example that
    takes a file system and extracts it to a directory named
    ``test-nfs``:
-   ::
+
+   .. code-block:: none
 
       runqemu-extract-sdk ./tmp/deploy/images/qemux86-64/core-image-sato-qemux86-64.tar.bz2 test-nfs
 
@@ -217,7 +218,8 @@
    You can then also make changes to the files within ``./test-nfs`` and
    see those changes appear in the image in real time. Here is an
    example using the ``qemux86`` image:
-   ::
+
+   .. code-block:: none
 
       runqemu qemux86-64 ./test-nfs
 
@@ -226,14 +228,20 @@
    Should you need to start, stop, or restart the NFS share, you can use
    the following commands:
 
-   -  The following command starts the NFS share: runqemu-export-rootfs
-      start file-system-location
+   -  The following command starts the NFS share:
+      ::
 
-   -  The following command stops the NFS share: runqemu-export-rootfs
-      stop file-system-location
+         runqemu-export-rootfs start file-system-location
+
+   -  The following command stops the NFS share:
+      ::
+
+         runqemu-export-rootfs stop file-system-location
 
    -  The following command restarts the NFS share:
-      runqemu-export-rootfs restart file-system-location
+      ::
+
+         runqemu-export-rootfs restart file-system-location
 
 .. _qemu-kvm-cpu-compatibility:
 
@@ -380,30 +388,29 @@
 .. note::
 
    If you do provide some "illegal" option combination or perhaps you do
-   not provide enough in the way of options,
-   runqemu
+   not provide enough in the way of options, ``runqemu``
    provides appropriate error messaging to help you correct the problem.
 
--  QEMUARCH: The QEMU machine architecture, which must be "qemuarm",
+-  `QEMUARCH`: The QEMU machine architecture, which must be "qemuarm",
    "qemuarm64", "qemumips", "qemumips64", "qemuppc", "qemux86", or
    "qemux86-64".
 
--  ``VM``: The virtual machine image, which must be a ``.wic.vmdk``
+-  `VM`: The virtual machine image, which must be a ``.wic.vmdk``
    file. Use this option when you want to boot a ``.wic.vmdk`` image.
    The image filename you provide must contain one of the following
    strings: "qemux86-64", "qemux86", "qemuarm", "qemumips64",
    "qemumips", "qemuppc", or "qemush4".
 
--  ROOTFS: A root filesystem that has one of the following filetype
+-  `ROOTFS`: A root filesystem that has one of the following filetype
    extensions: "ext2", "ext3", "ext4", "jffs2", "nfs", or "btrfs". If
    the filename you provide for this option uses "nfs", it must provide
    an explicit root filesystem path.
 
--  KERNEL: A kernel image, which is a ``.bin`` file. When you provide a
+-  `KERNEL`: A kernel image, which is a ``.bin`` file. When you provide a
    ``.bin`` file, ``runqemu`` detects it and assumes the file is a
    kernel image.
 
--  MACHINE: The architecture of the QEMU machine, which must be one of
+-  `MACHINE`: The architecture of the QEMU machine, which must be one of
    the following: "qemux86", "qemux86-64", "qemuarm", "qemuarm64",
    "qemumips", "qemumips64", or "qemuppc". The MACHINE and QEMUARCH
    options are basically identical. If you do not provide a MACHINE
diff --git a/poky/documentation/dev-manual/dev-manual-start.rst b/poky/documentation/dev-manual/dev-manual-start.rst
index 333c6a5..a85b86f 100644
--- a/poky/documentation/dev-manual/dev-manual-start.rst
+++ b/poky/documentation/dev-manual/dev-manual-start.rst
@@ -88,12 +88,10 @@
     .. note::
 
        For information about BitBake, see the
-       BitBake User Manual
-       .
+       :doc:`bitbake:index`.
 
     It is relatively easy to set up Git services and create
-    infrastructure like
-    :yocto_git:`http://git.yoctoproject.org <>`, which is based on
+    infrastructure like :yocto_git:`/`, which is based on
     server software called ``gitolite`` with ``cgit`` being used to
     generate the web interface that lets you view the repositories. The
     ``gitolite`` software identifies users using SSH keys and allows
@@ -106,10 +104,7 @@
        However, sites such as the following exist that describe how to
        perform setup:
 
-       -  `Git documentation <http://git-scm.com/book/ch4-8.html>`__:
-          Describes how to install ``gitolite`` on the server.
-
-       -  `Gitolite <http://gitolite.com>`__: Information for
+       -  `Gitolite <https://gitolite.com>`__: Information for
           ``gitolite``.
 
        -  `Interfaces, frontends, and
@@ -161,8 +156,7 @@
     integration" style testing of software components and regression
     identification and tracking.
 
-    See "`Yocto Project
-    Autobuilder <http://autobuilder.yoctoproject.org>`__" for more
+    See ":yocto_ab:`Yocto Project Autobuilder <>`" for more
     information and links to buildbot. The Yocto Project team has found
     this implementation works well in this role. A public example of
     this is the Yocto Project Autobuilders, which the Yocto Project team
@@ -207,8 +201,7 @@
 
     .. note::
 
-       You can also use a more collective push model. The
-       gitolite
+       You can also use a more collective push model. The ``gitolite``
        software supports both the push and pull models quite easily.
 
     As with any development environment, it is important to document the
@@ -285,11 +278,10 @@
 .. note::
 
    The Yocto Project is not compatible with
-   Windows Subsystem for Linux v1
-   . It is compatible but not officially supported nor validated with
+   `Windows Subsystem for Linux v1 <https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux>`__.
+   It is compatible but not officially supported nor validated with
    WSLv2. If you still decide to use WSL please upgrade to
-   WSLv2
-   .
+   `WSLv2 <https://docs.microsoft.com/en-us/windows/wsl/install-win10>`__.
 
 Once your build host is set up to use the Yocto Project, further steps
 are necessary depending on what you want to accomplish. See the
@@ -453,9 +445,9 @@
 
 Once you have a container set up, everything is in place to develop just
 as if you were running on a native Linux machine. If you are going to
-use the Poky container, see the "`Cloning the ``poky``
-Repository <#cloning-the-poky-repository>`__" section. If you are going
-to use the Extensible SDK container, see the
+use the Poky container, see the
+":ref:`dev-manual/dev-manual-start:cloning the \`\`poky\`\` repository`"
+section. If you are going to use the Extensible SDK container, see the
 ":doc:`../sdk-manual/sdk-extensible`" Chapter in the Yocto
 Project Application Development and the Extensible Software Development
 Kit (eSDK) manual. If you are going to use the Toaster container, see
@@ -566,10 +558,7 @@
 
    The current implementation of WSLv2 does not have out-of-the-box
    access to external devices such as those connected through a USB
-   port, but it automatically mounts your
-   C:
-   drive on
-   /mnt/c/
+   port, but it automatically mounts your ``C:`` drive on ``/mnt/c/``
    (and others), which you can use to share deploy artifacts to be later
    flashed on hardware through Windows, but your build directory should
    not reside inside this mountpoint.
@@ -623,11 +612,8 @@
 
    .. note::
 
-      For information on cloning a repository, see the "
-      Cloning the
-      poky
-      Repository
-      " section.
+      For information on cloning a repository, see the
+      ":ref:`dev-manual/dev-manual-start:cloning the \`\`poky\`\` repository`" section.
 
 Accessing Index of Releases
 ---------------------------
@@ -653,12 +639,10 @@
 
    .. note::
 
-      The
-      yocto
-      directory contains the full array of released Poky tarballs. The
-      poky
-      directory in the Index of Releases was historically used for very
-      early releases and exists now only for retroactive completeness.
+      The ``yocto`` directory contains the full array of released Poky
+      tarballs. The ``poky`` directory in the Index of Releases was
+      historically used for very early releases and exists now only for
+      retroactive completeness.
 
 2. *Select a Component:* Click on any released component in which you
    are interested (e.g. ``yocto``).
@@ -702,8 +686,7 @@
    .. note::
 
       For a "map" of Yocto Project releases to version numbers, see the
-      Releases
-      wiki page.
+      :yocto_wiki:`Releases </wiki/Releases>` wiki page.
 
    You can use the "RELEASE ARCHIVE" link to reveal a menu of all Yocto
    Project releases.
@@ -825,8 +808,9 @@
 
 1. *Switch to the Poky Directory:* If you have a local poky Git
    repository, switch to that directory. If you do not have the local
-   copy of poky, see the "`Cloning the ``poky``
-   Repository <#cloning-the-poky-repository>`__" section.
+   copy of poky, see the
+   ":ref:`dev-manual/dev-manual-start:cloning the \`\`poky\`\` repository`"
+   section.
 
 2. *Determine Existing Branch Names:*
    ::
@@ -854,13 +838,13 @@
    &DISTRO; Release (&DISTRO_NAME;), use the following command:
    ::
 
-      $ git checkout -b &DISTRO_NAME; origin/&DISTRO_NAME;
-      Branch &DISTRO_NAME; set up to track remote branch &DISTRO_NAME; from origin.
-      Switched to a new branch '&DISTRO_NAME;'
+      $ git checkout -b &DISTRO_NAME_NO_CAP; origin/&DISTRO_NAME_NO_CAP;
+      Branch &DISTRO_NAME_NO_CAP; set up to track remote branch &DISTRO_NAME_NO_CAP; from origin.
+      Switched to a new branch '&DISTRO_NAME_NO_CAP;'
 
-   The previous command checks out the "&DISTRO_NAME;" development
+   The previous command checks out the "&DISTRO_NAME_NO_CAP;" development
    branch and reports that the branch is tracking the upstream
-   "origin/&DISTRO_NAME;" branch.
+   "origin/&DISTRO_NAME_NO_CAP;" branch.
 
    The following command displays the branches that are now part of your
    local poky repository. The asterisk character indicates the branch
@@ -868,8 +852,8 @@
    ::
 
       $ git branch
-        master *
-        &DISTRO_NAME;
+        master
+        * &DISTRO_NAME_NO_CAP;
 
 .. _checkout-out-by-tag-in-poky:
 
@@ -889,8 +873,9 @@
 
 1. *Switch to the Poky Directory:* If you have a local poky Git
    repository, switch to that directory. If you do not have the local
-   copy of poky, see the "`Cloning the ``poky``
-   Repository <#cloning-the-poky-repository>`__" section.
+   copy of poky, see the
+   ":ref:`dev-manual/dev-manual-start:cloning the \`\`poky\`\` repository`"
+   section.
 
 2. *Fetch the Tag Names:* To checkout the branch based on a tag name,
    you need to fetch the upstream tags into your local repository:
diff --git a/poky/documentation/kernel-dev/kernel-dev-advanced.rst b/poky/documentation/kernel-dev/kernel-dev-advanced.rst
index eeb8f87..444037c 100644
--- a/poky/documentation/kernel-dev/kernel-dev-advanced.rst
+++ b/poky/documentation/kernel-dev/kernel-dev-advanced.rst
@@ -44,9 +44,7 @@
 .. note::
 
    A Linux kernel recipe that contains kernel Metadata (e.g. inherits
-   from the
-   linux-yocto.inc
-   file) is said to be a "linux-yocto style" recipe.
+   from the ``linux-yocto.inc`` file) is said to be a "linux-yocto style" recipe.
 
 Every linux-yocto style recipe must define the
 :term:`KMACHINE` variable. This
@@ -70,12 +68,8 @@
 
 .. note::
 
-   You can use the
-   KBRANCH
-   value to define an alternate branch typically with a machine override
-   as shown here from the
-   meta-yocto-bsp
-   layer:
+   You can use the ``KBRANCH`` value to define an alternate branch typically
+   with a machine override as shown here from the ``meta-yocto-bsp`` layer:
    ::
 
            KBRANCH_edgerouter = "standard/edgerouter"
@@ -101,7 +95,7 @@
 During the build, the kern-tools search for the BSP description file
 that most closely matches the ``KMACHINE`` and ``LINUX_KERNEL_TYPE``
 variables passed in from the recipe. The tools use the first BSP
-description it finds that match both variables. If the tools cannot find
+description they find that matches both variables. If the tools cannot find
 a match, they issue a warning.
 
 The tools first search for the ``KMACHINE`` and then for the
@@ -251,8 +245,7 @@
       CONFIG_X86_BIGSMP=y
 
 You can find general information on configuration
-fragment files in the "`Creating Configuration
-Fragments <#creating-config-fragments>`__" section.
+fragment files in the ":ref:`creating-config-fragments`" section.
 
 Within the ``smp.scc`` file, the
 :term:`KFEATURE_DESCRIPTION`
@@ -269,13 +262,12 @@
 
 .. note::
 
-   The description file can include multiple
-   kconf
-   statements, one per fragment.
+   The description file can include multiple ``kconf`` statements, one per
+   fragment.
 
-As described in the "`Validating
-Configuration <#validating-configuration>`__" section, you can use the
-following BitBake command to audit your configuration:
+As described in the
+":ref:`kernel-dev/kernel-dev-common:validating configuration`" section, you can
+use the following BitBake command to audit your configuration:
 ::
 
    $ bitbake linux-yocto -c kernel_configcheck -f
@@ -335,10 +327,8 @@
 
 You can create a typical ``.patch`` file using ``diff -Nurp`` or
 ``git format-patch`` commands. For information on how to create patches,
-see the "`Using ``devtool`` to Patch the
-Kernel <#using-devtool-to-patch-the-kernel>`__" and "`Using Traditional
-Kernel Development to Patch the
-Kernel <#using-traditional-kernel-development-to-patch-the-kernel>`__"
+see the ":ref:`kernel-dev/kernel-dev-common:using \`\`devtool\`\` to patch the kernel`"
+and ":ref:`kernel-dev/kernel-dev-common:using traditional kernel development to patch the kernel`"
 sections.
 
 Features
@@ -397,15 +387,11 @@
 
 .. note::
 
-   You can find kernel recipes in the
-   meta/recipes-kernel/linux
-   directory of the
-   Source Directory
-   (e.g.
-   poky/meta/recipes-kernel/linux/linux-yocto_4.12.bb
-   ). See the "
-   Using Kernel Metadata in a Recipe
-   " section for more information.
+   You can find kernel recipes in the ``meta/recipes-kernel/linux`` directory
+   of the :ref:`overview-manual/overview-manual-development-environment:yocto project source repositories`
+   (e.g. ``poky/meta/recipes-kernel/linux/linux-yocto_4.12.bb``). See the
+   ":ref:`kernel-dev/kernel-dev-advanced:using kernel metadata in a recipe`"
+   section for more information.
 
 Three kernel types ("standard", "tiny", and "preempt-rt") are supported
 for Linux Yocto kernels:
@@ -466,16 +452,11 @@
 
 .. note::
 
-   It is not strictly necessary to create a kernel type
-   .scc
+   It is not strictly necessary to create a kernel type ``.scc``
    file. The Board Support Package (BSP) file can implicitly define the
-   kernel type using a
-   define
-   KTYPE
-   myktype
-   line. See the "
-   BSP Descriptions
-   " section for more information.
+   kernel type using a ``define`` :term:`KTYPE` ``myktype`` line. See the
+   ":ref:`kernel-dev/kernel-dev-advanced:bsp descriptions`" section for more
+   information.
 
 BSP Descriptions
 ----------------
@@ -488,13 +469,9 @@
 .. note::
 
    For BSPs supported by the Yocto Project, the BSP description files
-   are located in the
-   bsp
-   directory of the
-   yocto-kernel-cache
+   are located in the ``bsp`` directory of the ``yocto-kernel-cache``
    repository organized under the "Yocto Linux Kernel" heading in the
-   Yocto Project Source Repositories
-   .
+   :yocto_git:`Yocto Project Source Repositories </>`.
 
 This section overviews the BSP description structure, the aggregation
 concepts, and presents a detailed example using a BSP supported by the
@@ -571,7 +548,7 @@
 information.
 
 To aggregate common configurations and features specific to the kernel
-for mybsp, use the following:
+for `mybsp`, use the following:
 ::
 
    include mybsp.scc
@@ -582,8 +559,7 @@
    include beaglebone.scc
 
 For information on how to break a complete ``.config`` file into the various
-configuration fragments, see the "`Creating Configuration
-Fragments <#creating-config-fragments>`__" section.
+configuration fragments, see the ":ref:`creating-config-fragments`" section.
 
 Finally, if you have any configurations specific to the hardware that
 are not in a ``*.scc`` file, you can include them as follows:
@@ -653,7 +629,7 @@
 included in each of the three "minnow" description files for the
 supported kernel types (i.e. "standard", "preempt-rt", and "tiny").
 Consider the "minnow" description for the "standard" kernel type (i.e.
-``minnow-standard.scc``:
+``minnow-standard.scc``):
 ::
 
    define KMACHINE minnow
@@ -725,8 +701,8 @@
 good approach if you are working with Linux kernel sources you do not
 control or if you just do not want to maintain a Linux kernel Git
 repository on your own. For partial information on how you can define
-kernel Metadata in the recipe-space, see the "`Modifying an Existing
-Recipe <#modifying-an-existing-recipe>`__" section.
+kernel Metadata in the recipe-space, see the
+":ref:`kernel-dev/kernel-dev-common:modifying an existing recipe`" section.
 
 Conversely, if you are actively developing a kernel and are already
 maintaining a Linux kernel Git repository of your own, you might find it
@@ -746,8 +722,8 @@
 ``oe-core/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb`` to
 a recipe in your layer, ``FILESEXTRAPATHS`` is typically set to
 ``${``\ :term:`THISDIR`\ ``}/${``\ :term:`PN`\ ``}``.
-See the "`Modifying an Existing
-Recipe <#modifying-an-existing-recipe>`__" section for more information.
+See the ":ref:`kernel-dev/kernel-dev-common:modifying an existing recipe`"
+section for more information.
 
 Here is an example that shows a trivial tree of kernel Metadata stored
 in recipe-space within a BSP layer:
@@ -849,7 +825,7 @@
 Encapsulating Patches
 ---------------------
 
-if you are reusing patches from an external tree and are not working on
+If you are reusing patches from an external tree and are not working on
 the patches, you might find the encapsulated feature to be appropriate.
 Given this scenario, you do not need to create any branches in the
 source repository. Rather, you just take the static patches you need and
@@ -881,6 +857,7 @@
 
 Another method is to use the ``branch`` command in the BSP
 description:
+::
 
    mybsp.scc:
       define KMACHINE mybsp
@@ -902,7 +879,7 @@
 If you had two kernel types, "standard" and "small" for instance, three
 machines, and common as ``mydir``, the branches in your Git repository
 might look like this:
-:
+::
 
    mydir/base
    mydir/standard/base
@@ -922,11 +899,8 @@
 
    The "base" branches are an artifact of the way Git manages its data
    internally on the filesystem: Git will not allow you to use
-   mydir/standard
-   and
-   mydir/standard/machine_a
-   because it would have to create a file and a directory named
-   "standard".
+   ``mydir/standard`` and ``mydir/standard/machine_a`` because it would have to
+   create a file and a directory named "standard".
 
 Feature Branches
 ----------------
diff --git a/poky/documentation/kernel-dev/kernel-dev-common.rst b/poky/documentation/kernel-dev/kernel-dev-common.rst
index 64235f3..830b3e8 100644
--- a/poky/documentation/kernel-dev/kernel-dev-common.rst
+++ b/poky/documentation/kernel-dev/kernel-dev-common.rst
@@ -33,12 +33,10 @@
 
    Be sure you check out the appropriate development branch or you
    create your local branch by checking out a specific tag to get the
-   desired version of Yocto Project. See the "
-   Checking Out by Branch in Poky
-   " and "
-   Checking Out by Tag in Poky
-   " sections in the Yocto Project Development Tasks Manual for more
-   information.
+   desired version of Yocto Project. See the
+   ":ref:`dev-manual/dev-manual-start:checking out by branch in poky`" and
+   ":ref:`dev-manual/dev-manual-start:checking out by tag in poky`"
+   sections in the Yocto Project Development Tasks Manual for more information.
 
 Kernel development is best accomplished using
 :ref:`devtool <sdk-manual/sdk-extensible:using \`\`devtool\`\` in your sdk workflow>`
@@ -50,8 +48,8 @@
 
 Follow these steps to prepare to update the kernel image using
 ``devtool``. Completing this procedure leaves you with a clean kernel
-image and ready to make modifications as described in the "
-:ref:`kernel-dev/kernel-dev-common:using \`\`devtool\`\` to patch the kernel`"
+image and ready to make modifications as described in the
+":ref:`kernel-dev/kernel-dev-common:using \`\`devtool\`\` to patch the kernel`"
 section:
 
 1. *Initialize the BitBake Environment:* Before building an extensible
@@ -65,10 +63,8 @@
    .. note::
 
       The previous commands assume the
-      Source Repositories
-      (i.e.
-      poky
-      ) have been cloned using Git and the local repository is named
+      :ref:`overview-manual/overview-manual-development-environment:yocto project source repositories`
+      (i.e. ``poky``) have been cloned using Git and the local repository is named
       "poky".
 
 2. *Prepare Your local.conf File:* By default, the
@@ -107,18 +103,15 @@
    .. note::
 
       For background information on working with common and BSP layers,
-      see the "
-      Understanding and Creating Layers
-      " section in the Yocto Project Development Tasks Manual and the "
-      BSP Layers
-      " section in the Yocto Project Board Support (BSP) Developer's
-      Guide, respectively. For information on how to use the
-      bitbake-layers create-layer
-      command to quickly set up a layer, see the "
-      Creating a General Layer Using the
-      bitbake-layers
-      Script
-      " section in the Yocto Project Development Tasks Manual.
+      see the
+      ":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`"
+      section in the Yocto Project Development Tasks Manual and the
+      ":ref:`bsp-guide/bsp:bsp layers`" section in the Yocto Project Board
+      Support (BSP) Developer's Guide, respectively. For information on how to
+      use the ``bitbake-layers create-layer`` command to quickly set up a layer,
+      see the
+      ":ref:`dev-manual/dev-manual-common-tasks:creating a general layer using the \`\`bitbake-layers\`\` script`"
+      section in the Yocto Project Development Tasks Manual.
 
 4. *Inform the BitBake Build Environment About Your Layer:* As directed
    when you created your layer, you need to add the layer to the
@@ -141,9 +134,12 @@
    Once
    the build finishes, you can find the SDK installer file (i.e.
    ``*.sh`` file) in the following directory:
-   ~/poky/build/tmp/deploy/sdk For this example, the installer file is
-   named
-   ``poky-glibc-x86_64-core-image-minimal-i586-toolchain-ext-DISTRO.sh``
+   ::
+
+      ~/poky/build/tmp/deploy/sdk
+
+   For this example, the installer file is named
+   ``poky-glibc-x86_64-core-image-minimal-i586-toolchain-ext-DISTRO.sh``.
 
 6. *Install the Extensible SDK:* Use the following command to install
    the SDK. For this example, install the SDK in the default
@@ -211,7 +207,7 @@
    building for actual hardware and not for emulation, you could flash
    the image to a USB stick on ``/dev/sdd`` and boot your device. For an
    example that uses a Minnowboard, see the
-   `TipsAndTricks/KernelDevelopmentWithEsdk <https://wiki.yoctoproject.org/wiki/TipsAndTricks/KernelDevelopmentWithEsdk>`__
+   :yocto_wiki:`TipsAndTricks/KernelDevelopmentWithEsdk </wiki/TipsAndTricks/KernelDevelopmentWithEsdk>`
    Wiki page.
 
 At this point you have set up to start making modifications to the
@@ -247,16 +243,14 @@
       $ cd ~/poky
       $ git branch
       master
-      * &DISTRO_NAME;
+      * &DISTRO_NAME_NO_CAP;
       $ source oe-init-build-env
 
    .. note::
 
       The previous commands assume the
-      Source Repositories
-      (i.e.
-      poky
-      ) have been cloned using Git and the local repository is named
+      :ref:`overview-manual/overview-manual-development-environment:yocto project source repositories`
+      (i.e. ``poky``) have been cloned using Git and the local repository is named
       "poky".
 
 2. *Prepare Your local.conf File:* By default, the
@@ -294,18 +288,15 @@
    .. note::
 
       For background information on working with common and BSP layers,
-      see the "
-      Understanding and Creating Layers
-      " section in the Yocto Project Development Tasks Manual and the "
-      BSP Layers
-      " section in the Yocto Project Board Support (BSP) Developer's
-      Guide, respectively. For information on how to use the
-      bitbake-layers create-layer
-      command to quickly set up a layer, see the "
-      Creating a General Layer Using the
-      bitbake-layers
-      Script
-      " section in the Yocto Project Development Tasks Manual.
+      see the
+      ":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`"
+      section in the Yocto Project Development Tasks Manual and the
+      ":ref:`bsp-guide/bsp:bsp layers`" section in the Yocto Project Board
+      Support (BSP) Developer's Guide, respectively. For information on how to
+      use the ``bitbake-layers create-layer`` command to quickly set up a layer,
+      see the
+      ":ref:`dev-manual/dev-manual-common-tasks:creating a general layer using the \`\`bitbake-layers\`\` script`"
+      section in the Yocto Project Development Tasks Manual.
 
 4. *Inform the BitBake Build Environment About Your Layer:* As directed
    when you created your layer, you need to add the layer to the
@@ -334,12 +325,10 @@
 
    .. note::
 
-      The
-      linux-yocto-4.12
-      kernel can be used with the Yocto Project 2.4 release and forward.
-      You cannot use the
-      linux-yocto-4.12
-      kernel with releases prior to Yocto Project 2.4:
+      The ``linux-yocto-4.12`` kernel can be used with the Yocto Project 2.4
+      release and forward.
+      You cannot use the ``linux-yocto-4.12`` kernel with releases prior to
+      Yocto Project 2.4.
 
    ::
 
@@ -351,7 +340,7 @@
       remote: Total 6097195 (delta 5152604), reused 6096847 (delta 5152256)
       Receiving objects: 100% (6097195/6097195), 1.24 GiB | 7.81 MiB/s, done.
       Resolving deltas: 100% (5152604/5152604), done. Checking connectivity... done.
-      Checking out   files: 100% (59846/59846), done.
+      Checking out files: 100% (59846/59846), done.
 
 6. *Create a Local Copy of the Kernel Cache Git Repository:* For
    simplicity, it is recommended that you create your copy of the kernel
@@ -395,13 +384,10 @@
 .. note::
 
    The Yocto Project comes with many tools that simplify tasks you need
-   to perform. One such tool is the
-   bitbake-layers create-layer
-   command, which simplifies creating a new layer. See the "
-   Creating a General Layer Using the
-   bitbake-layers
-   Script
-   " section in the Yocto Project Development Tasks Manual for
+   to perform. One such tool is the ``bitbake-layers create-layer``
+   command, which simplifies creating a new layer. See the
+   ":ref:`dev-manual/dev-manual-common-tasks:creating a general layer using the \`\`bitbake-layers\`\` script`"
+   section in the Yocto Project Development Tasks Manual for
    information on how to use this script to quick set up a new layer.
 
 To better understand the layer you create for kernel development, the
@@ -450,9 +436,9 @@
 
       FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
 
-      SRC_URI_append = " file://patch-file-one"
-      SRC_URI_append = " file://patch-file-two"
-      SRC_URI_append = " file://patch-file-three"
+      SRC_URI_append = " file://patch-file-one.patch"
+      SRC_URI_append = " file://patch-file-two.patch"
+      SRC_URI_append = " file://patch-file-three.patch"
 
    The :term:`FILESEXTRAPATHS` and :term:`SRC_URI` statements
    enable the OpenEmbedded build system to find patch files. For more
@@ -471,11 +457,11 @@
 
 Modifying an existing recipe can consist of the following:
 
--  Creating the append file
+- :ref:`kernel-dev/kernel-dev-common:creating the append file`
 
--  Applying patches
+- :ref:`kernel-dev/kernel-dev-common:applying patches`
 
--  Changing the configuration
+- :ref:`kernel-dev/kernel-dev-common:changing the configuration`
 
 Before modifying an existing recipe, be sure that you have created a
 minimal, custom layer from which you can work. See the "`Creating and
@@ -490,7 +476,8 @@
 modifying the ``meta/recipes-kernel/linux/linux-yocto_4.12.bb`` recipe,
 the append file will typically be located as follows within your custom
 layer:
-::
+
+.. code-block:: none
 
    your-layer/recipes-kernel/linux/linux-yocto_4.12.bbappend
 
@@ -515,13 +502,12 @@
 .. note::
 
    If you are working on a new machine Board Support Package (BSP), be
-   sure to refer to the
-   Yocto Project Board Support Package (BSP) Developer's Guide
-   .
+   sure to refer to the :doc:`../bsp-guide/bsp-guide`.
 
 As an example, consider the following append file used by the BSPs in
 ``meta-yocto-bsp``:
-::
+
+.. code-block:: none
 
    meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.12.bbappend
 
@@ -689,17 +675,13 @@
 
 .. note::
 
-   The build system applies the configurations from the
-   defconfig
+   The build system applies the configurations from the ``defconfig``
    file before applying any subsequent configuration fragments. The
    final kernel configuration is a combination of the configurations in
-   the
-   defconfig
-   file and any configuration fragments you provide. You need to realize
-   that if you have any configuration fragments, the build system
-   applies these on top of and after applying the existing
-   defconfig
-   file configurations.
+   the ``defconfig`` file and any configuration fragments you provide. You need
+   to realize that if you have any configuration fragments, the build system
+   applies these on top of and after applying the existing ``defconfig`` file
+   configurations.
 
 Generally speaking, the preferred approach is to determine the
 incremental change you want to make and add that as a configuration
@@ -755,7 +737,7 @@
 form:
 ::
 
-   KBUILD_DEFCONFIG_KMACHINE ?= defconfig_file
+   KBUILD_DEFCONFIG_KMACHINE ?= "defconfig_file"
 
 Here is an example
 that assigns the ``KBUILD_DEFCONFIG`` variable based on "raspberrypi2"
@@ -768,7 +750,7 @@
 Aside from modifying your kernel recipe and providing your own
 ``defconfig`` file, you need to be sure no files or statements set
 ``SRC_URI`` to use a ``defconfig`` other than your "in-tree" file (e.g.
-a kernel's ``linux-``\ machine\ ``.inc`` file). In other words, if the
+a kernel's ``linux-``\ `machine`\ ``.inc`` file). In other words, if the
 build system detects a statement that identifies an "out-of-tree"
 ``defconfig`` file, that statement will override your
 ``KBUILD_DEFCONFIG`` variable.
@@ -786,10 +768,9 @@
 .. note::
 
    Before attempting this procedure, be sure you have performed the
-   steps to get ready for updating the kernel as described in the "
-   Getting Ready to Develop Using
-   devtool
-   " section.
+   steps to get ready for updating the kernel as described in the
+   ":ref:`kernel-dev/kernel-dev-common:getting ready to develop using \`\`devtool\`\``"
+   section.
 
 Patching the kernel involves changing or adding configurations to an
 existing kernel, changing or adding recipes to the kernel that are
@@ -809,12 +790,9 @@
 
    .. note::
 
-      See this
-      step
-      in the "
-      Getting Ready to Develop Using
-      devtool
-      " section for more information.
+      See this step in the
+      ":ref:`kernel-dev/kernel-dev-common:getting ready to develop using \`\`devtool\`\``"
+      section for more information.
 
    Use the following ``devtool`` command to check out the code:
    ::
@@ -825,7 +803,8 @@
 
       During the checkout operation, a bug exists that could cause
       errors such as the following to appear:
-      ::
+
+      .. code-block:: none
 
               ERROR: Taskhash mismatch 2c793438c2d9f8c3681fd5f7bc819efa versus
                      be3a89ce7c47178880ba7bf6293d7404 for
@@ -883,7 +862,7 @@
       If the image you originally created resulted in a Wic file, you
       can use an alternate method to create the new image with the
       updated kernel. For an example, see the steps in the
-      TipsAndTricks/KernelDevelopmentWithEsdk
+      :yocto_wiki:`TipsAndTricks/KernelDevelopmentWithEsdk </wiki/TipsAndTricks/KernelDevelopmentWithEsdk>`
       Wiki Page.
 
    ::
@@ -903,7 +882,8 @@
    2. *Verify the changes*: Log into the machine using ``root`` with no
       password and then use the following shell command to scroll
       through the console's boot output.
-      ::
+
+      .. code-block:: none
 
          # dmesg | less
 
@@ -925,14 +905,15 @@
    commits as patches and create a ``.bbappend`` file, use the following
    command in the terminal used to work with the extensible SDK. This
    example uses the previously established layer named ``meta-mylayer``.
+   ::
+
+      $ devtool finish linux-yocto ~/meta-mylayer
 
    .. note::
 
-      See Step 3 of the "
-      Getting Ready to Develop Using devtool
-      " section for information on setting up this layer.
-
-   $ devtool finish linux-yocto ~/meta-mylayer
+      See Step 3 of the
+      ":ref:`kernel-dev/kernel-dev-common:getting ready to develop using \`\`devtool\`\``"
+      section for information on setting up this layer.
 
    Once the command
    finishes, the patches and the ``.bbappend`` file are located in the
@@ -960,9 +941,9 @@
 .. note::
 
    Before attempting this procedure, be sure you have performed the
-   steps to get ready for updating the kernel as described in the "
-   Getting Ready for Traditional Kernel Development
-   " section.
+   steps to get ready for updating the kernel as described in the
+   ":ref:`kernel-dev/kernel-dev-common:getting ready for traditional kernel development`"
+   section.
 
 Patching the kernel involves changing or adding configurations to an
 existing kernel, changing or adding recipes to the kernel that are
@@ -986,7 +967,7 @@
    section, use the following commands to edit the ``calibrate.c`` file:
 
    1. *Change the working directory*: You need to locate the source
-      files in the local copy of the kernel Git repository: Change to
+      files in the local copy of the kernel Git repository. Change to
       where the kernel source code is before making your edits to the
       ``calibrate.c`` file:
       ::
@@ -1046,13 +1027,10 @@
 
    .. note::
 
-      Be sure to replace
-      path-to
+      Be sure to replace `path-to`
       with the pathname to your local Git repositories. Also, you must
       be sure to specify the correct branch and machine types. For this
-      example, the branch is
-      standard/base
-      and the machine is "qemux86".
+      example, the branch is ``standard/base`` and the machine is ``qemux86``.
 
 4. *Build the Image:* With the source modified, your changes staged and
    committed, and the ``local.conf`` file pointing to the kernel files,
@@ -1073,7 +1051,8 @@
 6. *Look for Your Changes:* As QEMU booted, you might have seen your
    changes rapidly scroll by. If not, use these commands to see your
    changes:
-   ::
+
+   .. code-block:: none
 
       # dmesg | less
 
@@ -1134,13 +1113,10 @@
 
    .. note::
 
-      To build
-      core-image-minimal
-      again and see the effects of your patch, you can essentially
-      eliminate the temporary source files saved in
-      poky/build/tmp/work/...
-      and residual effects of the build by entering the following
-      sequence of commands:
+      To build ``core-image-minimal`` again and see the effects of your patch,
+      you can essentially eliminate the temporary source files saved in
+      ``poky/build/tmp/work/...`` and residual effects of the build by entering
+      the following sequence of commands:
       ::
 
               $ cd ~/poky/build
@@ -1174,7 +1150,7 @@
 The easiest way to define kernel configurations is to set them through
 the ``menuconfig`` tool. This tool provides an interactive method with
 which to set kernel configurations. For general information on
-``menuconfig``, see http://en.wikipedia.org/wiki/Menuconfig.
+``menuconfig``, see https://en.wikipedia.org/wiki/Menuconfig.
 
 To use the ``menuconfig`` tool in the Yocto Project development
 environment, you must do the following:
@@ -1212,35 +1188,20 @@
 
 .. note::
 
-   You can use the entire
-   .config
-   file as the
-   defconfig
-   file. For information on
-   defconfig
-   files, see the "
-   Changing the Configuration
-   ", "
-   Using an In-Tree
-   defconfig
-   File
-   , and "
-   Creating a
-   defconfig
-   File
-   " sections.
+   You can use the entire ``.config`` file as the ``defconfig`` file. For
+   information on ``defconfig`` files, see the
+   ":ref:`kernel-dev/kernel-dev-common:changing the configuration`",
+   ":ref:`kernel-dev/kernel-dev-common:using an "in-tree" \`\`defconfig\`\` file`",
+   and ":ref:`kernel-dev/kernel-dev-common:creating a \`\`defconfig\`\` file`"
+   sections.
 
 Consider an example that configures the "CONFIG_SMP" setting for the
 ``linux-yocto-4.12`` kernel.
 
 .. note::
 
-   The OpenEmbedded build system recognizes this kernel as
-   linux-yocto
-   through Metadata (e.g.
-   PREFERRED_VERSION
-   \_linux-yocto ?= "12.4%"
-   ).
+   The OpenEmbedded build system recognizes this kernel as ``linux-yocto``
+   through Metadata (e.g. :term:`PREFERRED_VERSION`\ ``_linux-yocto ?= "12.4%"``).
 
 Once ``menuconfig`` launches, use the interface to navigate through the
 selections to find the configuration settings in which you are
@@ -1259,7 +1220,8 @@
 building a Linux Yocto kernel based on the ``linux-yocto-4.12`` kernel
 and you were building a QEMU image targeted for ``x86`` architecture,
 the ``.config`` file would be:
-::
+
+.. code-block:: none
 
    poky/build/tmp/work/qemux86-poky-linux/linux-yocto/4.12.12+gitAUTOINC+eda4d18...
    ...967-r0/linux-qemux86-standard-build/.config
@@ -1289,11 +1251,8 @@
 
 .. note::
 
-   Be sure to make a copy of the
-   .config
-   file and do not just rename it. The build system needs an existing
-   .config
-   file from which to work.
+   Be sure to make a copy of the ``.config`` file and do not just rename it.
+   The build system needs an existing ``.config`` file from which to work.
 
 Creating a  ``defconfig`` File
 ------------------------------
@@ -1307,13 +1266,9 @@
 
 .. note::
 
-   Out-of-the-box, the Yocto Project never ships a
-   defconfig
-   or
-   .config
-   file. The OpenEmbedded build system creates the final
-   .config
-   file used to configure the kernel.
+   Out-of-the-box, the Yocto Project never ships a ``defconfig`` or ``.config``
+   file. The OpenEmbedded build system creates the final ``.config`` file used
+   to configure the kernel.
 
 To create a ``defconfig``, start with a complete, working Linux kernel
 ``.config`` file. Copy that file to the appropriate
@@ -1335,16 +1290,13 @@
 
 .. note::
 
-   The build system applies the configurations from the
-   defconfig
+   The build system applies the configurations from the ``defconfig``
    file before applying any subsequent configuration fragments. The
    final kernel configuration is a combination of the configurations in
-   the
-   defconfig
-   file and any configuration fragments you provide. You need to realize
-   that if you have any configuration fragments, the build system
-   applies these on top of and after applying the existing defconfig
-   file configurations.
+   the ``defconfig`` file and any configuration fragments you provide. You need
+   to realize that if you have any configuration fragments, the build system
+   applies these on top of and after applying the existing ``defconfig`` file
+   configurations.
 
 For more information on configuring the kernel, see the "`Changing the
 Configuration <#changing-the-configuration>`__" section.
@@ -1368,9 +1320,8 @@
 
 .. note::
 
-   For more information about where the
-   .config
-   file is located, see the example in the
+   For more information about where the ``.config`` file is located, see the
+   example in the
    ":ref:`kernel-dev/kernel-dev-common:using \`\`menuconfig\`\``"
    section.
 
@@ -1384,10 +1335,9 @@
 
 .. note::
 
-   All configuration fragment files must use the
-   .cfg
-   extension in order for the OpenEmbedded build system to recognize
-   them as a configuration fragment.
+   All configuration fragment files must use the ``.cfg`` extension in order
+   for the OpenEmbedded build system to recognize them as a configuration
+   fragment.
 
 Another method is to create a configuration fragment using the
 differences between two configuration files: one previously created and
@@ -1429,9 +1379,8 @@
 .. note::
 
    You can also use this method to create configuration fragments for a
-   BSP. See the "
-   BSP Descriptions
-   " section for more information.
+   BSP. See the ":ref:`kernel-dev/kernel-dev-advanced:bsp descriptions`"
+   section for more information.
 
 Where do you put your configuration fragment files? You can place these
 files in an area pointed to by
@@ -1480,7 +1429,8 @@
 information on how to create a configuration file.
 
 Following is sample output from the ``do_kernel_configcheck`` task:
-::
+
+.. code-block:: none
 
    Loading cache: 100% |########################################################| Time: 0:00:00
    Loaded 1275 entries from dependency cache.
@@ -1577,10 +1527,8 @@
 
 .. note::
 
-   The
-   do_kernel_configcheck
-   task can also optionally report if an option is overridden during
-   processing.
+   The :ref:`ref-tasks-kernel_configcheck` task can also optionally report if
+   an option is overridden during processing.
 
 For each output warning, a message points to the file that contains a
 list of the options and a pointer to the configuration fragment that
@@ -1627,7 +1575,7 @@
 ===================
 
 Sometimes it is helpful to determine what a variable expands to during a
-build. You can do examine the values of variables by examining the
+build. You can examine the values of variables by examining the
 output of the ``bitbake -e`` command. The output is long and is more
 easily managed in a text file, which allows for easy searches:
 ::
@@ -1767,7 +1715,10 @@
       as derived from the :term:`SRCPV`
       variable. The combined results are a string with the following
       form:
-      3.19.11+git1+68a635bf8dfb64b02263c1ac80c948647cc76d5f_1+218bd8d2022b9852c60d32f0d770931e3cf343e2
+      ::
+
+         3.19.11+git1+68a635bf8dfb64b02263c1ac80c948647cc76d5f_1+218bd8d2022b9852c60d32f0d770931e3cf343e2
+
       While lengthy, the extra verbosity in ``PV`` helps ensure you are
       using the exact sources from which you intend to build.
 
@@ -1778,7 +1729,10 @@
       triggers an explicit build failure. You must change it to match a
       list of the machines that your new recipe supports. For example,
       to support the ``qemux86`` and ``qemux86-64`` machines, use the
-      following form: COMPATIBLE_MACHINE = "qemux86|qemux86-64"
+      following form:
+      ::
+
+         COMPATIBLE_MACHINE = "qemux86|qemux86-64"
 
 5. *Customize Your Recipe as Needed:* Provide further customizations to
    your recipe as needed just as you would customize an existing
@@ -1813,7 +1767,8 @@
 Prior to attempting to build the out-of-tree modules, you need to be on
 the target as root and you need to change to the ``/usr/src/kernel``
 directory. Next, ``make`` the scripts:
-::
+
+.. code-block:: none
 
    # cd /usr/src/kernel
    # make scripts
@@ -1835,7 +1790,8 @@
 
 This template recipe is located in the ``poky`` Git repository of the
 Yocto Project :yocto_git:`Source Repository <>` at:
-::
+
+.. code-block:: none
 
    poky/meta-skeleton/recipes-kernel/hello-mod/hello-mod_0.1.bb
 
@@ -1925,17 +1881,15 @@
 
 .. note::
 
-   In the following examples, unless you provide a commit range,
-   kernel.org
+   In the following examples, unless you provide a commit range, ``kernel.org``
    history is blended with Yocto Project kernel changes. You can form
    ranges by using branch names from the kernel tree as the upper and
    lower commit markers with the Git commands. You can see the branch
    names through the web interface to the Yocto Project source
-   repositories at
-   .
+   repositories at :yocto_git:`/`.
 
 To see a full range of the changes, use the ``git whatchanged`` command
-and specify a commit range for the branch (commit\ ``..``\ commit).
+and specify a commit range for the branch (`commit`\ ``..``\ `commit`).
 
 Here is an example that looks at what has changed in the ``emenlow``
 branch of the ``linux-yocto-3.19`` kernel. The lower commit range is the
@@ -1990,8 +1944,8 @@
 ===================================
 
 You can add kernel features in the
-`recipe-space <#recipe-space-metadata>`__ by using the
-:term:`KERNEL_FEATURES`
+:ref:`recipe-space <kernel-dev/kernel-dev-advanced:recipe-space metadata>`
+by using the :term:`KERNEL_FEATURES`
 variable and by specifying the feature's ``.scc`` file path in the
 :term:`SRC_URI` statement. When you
 add features using this method, the OpenEmbedded build system checks to
@@ -2008,9 +1962,9 @@
 OpenEmbedded build system searches all forms of kernel Metadata on the
 ``SRC_URI`` statement regardless of whether the Metadata is in the
 "kernel-cache", system kernel Metadata, or a recipe-space Metadata (i.e.
-part of the kernel recipe). See the "`Kernel Metadata
-Location <#kernel-metadata-location>`__" section for additional
-information.
+part of the kernel recipe). See the
+":ref:`kernel-dev/kernel-dev-advanced:kernel metadata location`" section for
+additional information.
 
 When you specify the feature's ``.scc`` file on the ``SRC_URI``
 statement, the OpenEmbedded build system adds the directory of that
@@ -2073,6 +2027,5 @@
    .. note::
 
       If other features are contained below "test.scc", then their
-      directories are relative to the directory containing the
-      test.scc
+      directories are relative to the directory containing the ``test.scc``
       file.
diff --git a/poky/documentation/kernel-dev/kernel-dev-concepts-appx.rst b/poky/documentation/kernel-dev/kernel-dev-concepts-appx.rst
index 5b6ebef..681faee 100644
--- a/poky/documentation/kernel-dev/kernel-dev-concepts-appx.rst
+++ b/poky/documentation/kernel-dev/kernel-dev-concepts-appx.rst
@@ -11,7 +11,7 @@
 
 Kernels available through the Yocto Project (Yocto Linux kernels), like
 other kernels, are based off the Linux kernel releases from
-http://www.kernel.org. At the beginning of a major Linux kernel
+https://www.kernel.org. At the beginning of a major Linux kernel
 development cycle, the Yocto Project team chooses a Linux kernel based
 on factors such as release timing, the anticipated release timing of
 final upstream ``kernel.org`` versions, and Yocto Project feature
@@ -119,7 +119,7 @@
 team's Yocto Linux kernel development strategy. It is the Yocto Project
 team's policy to not back-port minor features to the released Yocto
 Linux kernel. They only consider back-porting significant technological
-jumps DASH and, that is done after a complete gap analysis. The reason
+jumps - and, that is done after a complete gap analysis. The reason
 for this policy is that back-porting any small to medium sized change
 from an evolving Linux kernel can easily create mismatches,
 incompatibilities and very subtle errors.
@@ -129,7 +129,7 @@
 Linux kernel features and significant and critical new functionality.
 Forward porting Linux kernel functionality into the Yocto Linux kernels
 available through the Yocto Project can be thought of as a "micro
-uprev." The many "micro uprevs" produce a Yocto Linux kernel version
+uprev". The many "micro uprevs" produce a Yocto Linux kernel version
 with a mix of important new mainline, non-mainline, BSP developments and
 feature integrations. This Yocto Linux kernel gives insight into new
 features and allows focused amounts of testing to be done on the kernel,
@@ -160,9 +160,8 @@
       but, Git continues to grow in popularity and supports many
       different work flows, front-ends and management techniques.
 
-   -  You can find documentation on Git at
-      http://git-scm.com/documentation. You can also get an
-      introduction to Git as it applies to the Yocto Project in the
+   -  You can find documentation on Git at https://git-scm.com/doc. You can
+      also get an introduction to Git as it applies to the Yocto Project in the
       ":ref:`overview-manual/overview-manual-development-environment:git`" section in the Yocto Project
       Overview and Concepts Manual. The latter reference provides an
       overview of Git and presents a minimal set of Git commands that
@@ -260,8 +259,8 @@
    Keep in mind the figure does not take into account all the supported
    Yocto Linux kernels, but rather shows a single generic kernel just
    for conceptual purposes. Also keep in mind that this structure
-   represents the Yocto Project
-   Source Repositories
+   represents the
+   :ref:`overview-manual/overview-manual-development-environment:yocto project source repositories`
    that are either pulled from during the build or established on the
    host development system prior to the build by either cloning a
    particular kernel's Git repository or by downloading and unpacking a
diff --git a/poky/documentation/kernel-dev/kernel-dev-faq.rst b/poky/documentation/kernel-dev/kernel-dev-faq.rst
index 70bf4a2..d6be98a 100644
--- a/poky/documentation/kernel-dev/kernel-dev-faq.rst
+++ b/poky/documentation/kernel-dev/kernel-dev-faq.rst
@@ -38,7 +38,7 @@
 The kernel image (e.g. ``vmlinuz``) is provided by the
 ``kernel-image`` package. Image recipes depend on ``kernel-base``. To
 specify whether or not the kernel image is installed in the generated
-root filesystem, override ``RDEPENDS_kernel-base`` to include or not
+root filesystem, override ``RDEPENDS_${KERNEL_PACKAGE_NAME}-base`` to include or not
 include "kernel-image". See the
 ":ref:`dev-manual/dev-manual-common-tasks:using .bbappend files in your layer`"
 section in the
@@ -50,13 +50,13 @@
 
 Linux kernel modules are packaged individually. To ensure a
 specific kernel module is included in an image, include it in the
-appropriate machine
-:term:`RRECOMMENDS` variable.
+appropriate machine :term:`RRECOMMENDS` variable.
 These other variables are useful for installing specific modules:
-:term:`MACHINE_ESSENTIAL_EXTRA_RDEPENDS`
-:term:`MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS`
-:term:`MACHINE_EXTRA_RDEPENDS`
-:term:`MACHINE_EXTRA_RRECOMMENDS`
+- :term:`MACHINE_ESSENTIAL_EXTRA_RDEPENDS`
+- :term:`MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS`
+- :term:`MACHINE_EXTRA_RDEPENDS`
+- :term:`MACHINE_EXTRA_RRECOMMENDS`
+
 For example, set the following in the ``qemux86.conf`` file to include
 the ``ab123`` kernel modules with images built for the ``qemux86``
 machine:
@@ -64,9 +64,8 @@
 
    MACHINE_EXTRA_RRECOMMENDS += "kernel-module-ab123"
 
-For more
-information, see the "`Incorporating Out-of-Tree
-Modules <#incorporating-out-of-tree-modules>`__" section.
+For more information, see the
+":ref:`kernel-dev/kernel-dev-common:incorporating out-of-tree modules`" section.
 
 How do I change the Linux kernel command line?
 ----------------------------------------------
diff --git a/poky/documentation/kernel-dev/kernel-dev-intro.rst b/poky/documentation/kernel-dev/kernel-dev-intro.rst
index 447cddb..5679a0a 100644
--- a/poky/documentation/kernel-dev/kernel-dev-intro.rst
+++ b/poky/documentation/kernel-dev/kernel-dev-intro.rst
@@ -23,7 +23,7 @@
 whose Git repositories you can view in the Yocto
 :yocto_git:`Source Repositories <>` under the "Yocto Linux Kernel"
 heading. New recipes for the release track the latest Linux kernel
-upstream developments from http://www.kernel.org> and introduce
+upstream developments from https://www.kernel.org and introduce
 newly-supported platforms. Previous recipes in the release are refreshed
 and supported for at least one additional Yocto Project release. As they
 align, these previous releases are updated to include the latest from
@@ -37,8 +37,8 @@
 
 .. note::
 
-   For more on Yocto Linux kernels, see the "
-   Yocto Project Kernel Development and Maintenance
+   For more on Yocto Linux kernels, see the
+   ":ref:`Yocto Project Kernel Development and Maintenance <kernel-big-picture>`"
    section.
 
 The Yocto Project also provides a powerful set of kernel tools for
@@ -75,7 +75,7 @@
 The remainder of this manual provides instructions for completing
 specific Linux kernel development tasks. These instructions assume you
 are comfortable working with
-`BitBake <http://openembedded.org/wiki/Bitbake>`__ recipes and basic
+`BitBake <https://openembedded.org/wiki/Bitbake>`__ recipes and basic
 open-source development tools. Understanding these concepts will
 facilitate the process of working with the kernel recipes. If you find
 you need some additional background, please be sure to review and
@@ -158,8 +158,7 @@
 
    .. note::
 
-      Try to resist the temptation to directly edit an existing
-      .config
+      Try to resist the temptation to directly edit an existing ``.config``
       file, which is found in the Build Directory among the source code
       used for the build. Doing so, can produce unexpected results when
       the OpenEmbedded build system regenerates the configuration file.
@@ -167,9 +166,9 @@
    Once you are satisfied with the configuration changes made using
    ``menuconfig`` and you have saved them, you can directly compare the
    resulting ``.config`` file against an existing original and gather
-   those changes into a `configuration fragment
-   file <#creating-config-fragments>`__ to be referenced from within the
-   kernel's ``.bbappend`` file.
+   those changes into a
+   :ref:`configuration fragment file <creating-config-fragments>` to be
+   referenced from within the kernel's ``.bbappend`` file.
 
    Additionally, if you are working in a BSP layer and need to modify
    the BSP's kernel's configuration, you can use ``menuconfig``.
diff --git a/poky/documentation/kernel-dev/kernel-dev-maint-appx.rst b/poky/documentation/kernel-dev/kernel-dev-maint-appx.rst
index 1788332..69f6806 100644
--- a/poky/documentation/kernel-dev/kernel-dev-maint-appx.rst
+++ b/poky/documentation/kernel-dev/kernel-dev-maint-appx.rst
@@ -42,7 +42,11 @@
 
 Once you have cloned the kernel Git repository and the cache of Metadata
 on your local machine, you can discover the branches that are available
-in the repository using the following Git command: $ git branch -a
+in the repository using the following Git command:
+::
+
+   $ git branch -a
+
 Checking out a branch allows you to work with a particular Yocto Linux
 kernel. For example, the following commands check out the
 "standard/beagleboard" branch of the Yocto Linux kernel repository and
@@ -56,10 +60,8 @@
 
 .. note::
 
-   Branches in the
-   yocto-kernel-cache
-   repository correspond to Yocto Linux kernel versions (e.g.
-   "yocto-4.12", "yocto-4.10", "yocto-4.9", and so forth).
+   Branches in the ``yocto-kernel-cache`` repository correspond to Yocto Linux
+   kernel versions (e.g. "yocto-4.12", "yocto-4.10", "yocto-4.9", and so forth).
 
 Once you have checked out and switched to appropriate branches, you can
 see a snapshot of all the kernel source files used to used to build that
@@ -105,7 +107,7 @@
       repository organized under the "Yocto Linux Kernel" heading in the
       :yocto_git:`Yocto Project Source Repositories <>`.
 
-   -  Areas pointed to by ``SRC_URI`` statements found in kernel recipes
+   -  Areas pointed to by ``SRC_URI`` statements found in kernel recipes.
 
    For a typical build, the target of the search is a feature
    description in an ``.scc`` file whose name follows this format (e.g.
@@ -194,12 +196,10 @@
    .. note::
 
       In the previous example, the "yocto-4.12" branch is checked out in
-      the
-      yocto-kernel-cache
-      repository.
+      the ``yocto-kernel-cache`` repository.
 
 The OpenEmbedded build system makes sure these conditions exist before
-attempting compilation. Other means, however, do exist, such as as
+attempting compilation. Other means, however, do exist, such as
 bootstrapping a BSP.
 
 Before building a kernel, the build process verifies the tree and
diff --git a/poky/documentation/poky.yaml b/poky/documentation/poky.yaml
index 7d544b4..895864b 100644
--- a/poky/documentation/poky.yaml
+++ b/poky/documentation/poky.yaml
@@ -16,17 +16,17 @@
 COPYRIGHT_YEAR : "2010-2020"
 ORGNAME : "The Yocto Project"
 ORGEMAIL : "docs@lists.yoctoproject.org"
-YOCTO_DL_URL : "http://downloads.yoctoproject.org"
-YOCTO_HOME_URL : "http://www.yoctoproject.org"
-YOCTO_LISTS_URL : "http://lists.yoctoproject.org"
-YOCTO_BUGZILLA_URL : "http://bugzilla.yoctoproject.org"
+YOCTO_DL_URL : "https://downloads.yoctoproject.org"
+YOCTO_HOME_URL : "https://www.yoctoproject.org"
+YOCTO_LISTS_URL : "https://lists.yoctoproject.org"
+YOCTO_BUGZILLA_URL : "https://bugzilla.yoctoproject.org"
 YOCTO_WIKI_URL : "https://wiki.yoctoproject.org"
-YOCTO_AB_URL : "http://autobuilder.yoctoproject.org"
-YOCTO_GIT_URL : "http://git.yoctoproject.org"
+YOCTO_AB_URL : "https://autobuilder.yoctoproject.org"
+YOCTO_GIT_URL : "https://git.yoctoproject.org"
 YOCTO_ADTREPO_URL : "http://adtrepo.yoctoproject.org"
-OE_HOME_URL : "http://www.openembedded.org"
-OE_LISTS_URL : "http://lists.openembedded.org/mailman"
-OE_DOCS_URL : "http://docs.openembedded.org"
+OE_HOME_URL : "https://www.openembedded.org"
+OE_LISTS_URL : "https://lists.openembedded.org"
+OE_DOCS_URL : "https://docs.openembedded.org"
 OH_HOME_URL : "http://o-hand.com"
 BITBAKE_HOME_URL : "http://developer.berlios.de/projects/bitbake/"
 YOCTO_DOCS_URL : "&YOCTO_HOME_URL;/docs"
@@ -58,7 +58,6 @@
 YOCTO_ADTPATH_DIR : "/opt/poky/&DISTRO;"
 YOCTO_POKY_TARBALL : "&YOCTO_POKY;.tar.bz2"
 OE_INIT_PATH : "&YOCTO_POKY;/oe-init-build-env"
-OE_INIT_FILE : "oe-init-build-env"
 UBUNTU_HOST_PACKAGES_ESSENTIAL : "gawk wget git-core diffstat unzip texinfo gcc-multilib \
      build-essential chrpath socat cpio python3 python3-pip python3-pexpect \
      xz-utils debianutils iputils-ping python3-git python3-jinja2 libegl1-mesa libsdl1.2-dev \
@@ -71,19 +70,20 @@
 OPENSUSE_HOST_PACKAGES_ESSENTIAL : "python gcc gcc-c++ git chrpath make wget python-xml \
      diffstat makeinfo python-curses patch socat python3 python3-curses tar python3-pip \
      python3-pexpect xz which python3-Jinja2 Mesa-libEGL1 libSDL-devel xterm rpcgen Mesa-dri-devel
-     $ sudo pip3 install GitPython"
+     \n\      $ sudo pip3 install GitPython"
 CENTOS7_HOST_PACKAGES_ESSENTIAL : "-y epel-release
-     $ sudo yum makecache
-     $ sudo yum install gawk make wget tar bzip2 gzip python3 unzip perl patch \
+     \n\      $ sudo yum makecache
+     \n\      $ sudo yum install gawk make wget tar bzip2 gzip python3 unzip perl patch \
      diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath socat \
      perl-Data-Dumper perl-Text-ParseWords perl-Thread-Queue python36-pip xz \
      which SDL-devel xterm mesa-libGL-devel
-     $ sudo pip3 install GitPython jinja2"
+     \n\      $ sudo pip3 install GitPython jinja2"
 CENTOS8_HOST_PACKAGES_ESSENTIAL : "-y epel-release
-     $ sudo dnf config-manager --set-enabled PowerTools
-     $ sudo dnf makecache
-     $ sudo dnf install gawk make wget tar bzip2 gzip python3 unzip perl patch \
+     \n\      $ sudo dnf config-manager --set-enabled PowerTools
+     \n\      $ sudo dnf makecache
+     \n\      $ sudo dnf install gawk make wget tar bzip2 gzip python3 unzip perl patch \
      diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath ccache \
      socat perl-Data-Dumper perl-Text-ParseWords perl-Thread-Queue python3-pip \
      python3-GitPython python3-jinja2 python3-pexpect xz which SDL-devel xterm \
      rpcgen mesa-libGL-devel"
+PIP3_HOST_PACKAGES_DOC : "$ sudo pip3 install sphinx sphinx_rtd_theme pyyaml"
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.
 
diff --git a/poky/documentation/sdk-manual/sdk-intro.rst b/poky/documentation/sdk-manual/sdk-intro.rst
index 5a346fa..acb3f45 100644
--- a/poky/documentation/sdk-manual/sdk-intro.rst
+++ b/poky/documentation/sdk-manual/sdk-intro.rst
@@ -84,9 +84,9 @@
 +-----------------------+-----------------------+-----------------------+
 | *Feature*             | *Standard SDK*        | *Extensible SDK*      |
 +=======================+=======================+=======================+
-| Toolchain             | Yes                   | Yes\*                 |
+| Toolchain             | Yes                   | Yes [1]_              |
 +-----------------------+-----------------------+-----------------------+
-| Debugger              | Yes                   | Yes\*                 |
+| Debugger              | Yes                   | Yes [1]_              |
 +-----------------------+-----------------------+-----------------------+
 | Size                  | 100+ MBytes           | 1+ GBytes (or 300+    |
 |                       |                       | MBytes for minimal    |
@@ -98,29 +98,22 @@
 +-----------------------+-----------------------+-----------------------+
 | Updateable            | No                    | Yes                   |
 +-----------------------+-----------------------+-----------------------+
-| Managed Sysroot*\*    | No                    | Yes                   |
+| Managed Sysroot [2]_  | No                    | Yes                   |
 +-----------------------+-----------------------+-----------------------+
-| Installed Packages    | No**\*                | Yes***\*              |
+| Installed Packages    | No  [3]_              | Yes  [4]_             |
 +-----------------------+-----------------------+-----------------------+
 | Construction          | Packages              | Shared State          |
 +-----------------------+-----------------------+-----------------------+
 
-\* Extensible SDK contains the toolchain and debugger if
-:term:`SDK_EXT_TYPE` is "full"
-or
-:term:`SDK_INCLUDE_TOOLCHAIN`
-is "1", which is the default.
-
-\*\* Sysroot is managed through the use of
-``devtool``. Thus, it is less likely that you will corrupt your SDK
-sysroot when you try to add additional libraries.
-
-\*\*\* You can add
-runtime package management to the standard SDK but it is not supported
-by default.
-
-\*\*\*\* You must build and make the shared state available to
-extensible SDK users for "packages" you want to enable users to install.
+.. [1] Extensible SDK contains the toolchain and debugger if :term:`SDK_EXT_TYPE`
+       is "full" or :term:`SDK_INCLUDE_TOOLCHAIN` is "1", which is the default.
+.. [2] Sysroot is managed through the use of ``devtool``. Thus, it is less
+       likely that you will corrupt your SDK sysroot when you try to add
+       additional libraries.
+.. [3] You can add runtime package management to the standard SDK but it is not
+       supported by default.
+.. [4] You must build and make the shared state available to extensible SDK
+       users for "packages" you want to enable users to install.
 
 The Cross-Development Toolchain
 -------------------------------
diff --git a/poky/documentation/sphinx-static/switchers.js b/poky/documentation/sphinx-static/switchers.js
index 32113cf..b28d91c 100644
--- a/poky/documentation/sphinx-static/switchers.js
+++ b/poky/documentation/sphinx-static/switchers.js
@@ -3,8 +3,8 @@
 
   var all_versions = {
     'dev': 'dev (3.2)',
-    '3.1.2': '3.1.2',
-    '3.0.3': '3.0.3',
+    '3.1.3': '3.1.3',
+    '3.0.4': '3.0.4',
     '2.7.4': '2.7.4',
   };
 
diff --git a/poky/documentation/sphinx/yocto-vars.py b/poky/documentation/sphinx/yocto-vars.py
index 8083d7d..8795eee 100644
--- a/poky/documentation/sphinx/yocto-vars.py
+++ b/poky/documentation/sphinx/yocto-vars.py
@@ -1,4 +1,6 @@
 #!/usr/bin/env python
+from hashlib import md5
+from pathlib import Path
 import re
 import sys
 
@@ -20,25 +22,62 @@
 # Each .rst file is processed after source-read event (subst_vars_replace runs once per file)
 subst_vars = {}
 
+poky_hash = ""
+
 def subst_vars_replace(app: Sphinx, docname, source):
     result = source[0]
     for k in subst_vars:
         result = result.replace("&"+k+";", subst_vars[k])
     source[0] = result
 
+def yocto_vars_env_get_outdated(app: Sphinx, env, added, changed, removed):
+    '''
+    If poky.yaml changed (BUILDDIR/.poky.yaml.cache does not exist or contains
+    an md5sum different from poky.yaml's current md5sum), force rebuild of all
+    *.rst files in SOURCEDIR whose content has at least one occurence of `&.*;`
+    (see PATTERN global variable).
+    '''
+    try:
+        poky_cache = Path(app.outdir) / ".poky.yaml.cache"
+        cache_hash = poky_cache.read_text()
+    except FileNotFoundError:
+        cache_hash = None
+
+    if poky_hash == cache_hash:
+        return []
+
+    docs = []
+    for p in Path(app.srcdir).rglob("*.rst"):
+        if PATTERN.search(p.read_text()):
+            p_rel_no_ext = p.relative_to(app.srcdir).parent / p.stem
+            docs.append(str(p_rel_no_ext))
+    return docs
+
+def yocto_vars_build_finished(app: Sphinx, exception):
+    poky_cache = Path(app.outdir) / ".poky.yaml.cache"
+    poky_cache.write_text(poky_hash)
+    return []
+
 PATTERN = re.compile(r'&(.*?);')
 def expand(val, src):
     return PATTERN.sub(lambda m: expand(src.get(m.group(1), ''), src), val)
 
 def setup(app: Sphinx):
-    #FIXME: if poky.yaml changes, files are not reprocessed.
+    global poky_hash
+
     with open("poky.yaml") as file:
-        subst_vars.update(yaml.load(file, Loader=yaml.FullLoader))
+        hasher = md5()
+        buff = file.read()
+        hasher.update(buff.encode('utf-8'))
+        poky_hash = hasher.hexdigest()
+        subst_vars.update(yaml.safe_load(buff))
 
     for k in subst_vars:
         subst_vars[k] = expand(subst_vars[k], subst_vars)
 
     app.connect('source-read', subst_vars_replace)
+    app.connect('env-get-outdated', yocto_vars_env_get_outdated)
+    app.connect('build-finished', yocto_vars_build_finished)
 
     return dict(
         version = __version__,
diff --git a/poky/documentation/test-manual/test-manual-understand-autobuilder.rst b/poky/documentation/test-manual/test-manual-understand-autobuilder.rst
index de26777..2444333 100644
--- a/poky/documentation/test-manual/test-manual-understand-autobuilder.rst
+++ b/poky/documentation/test-manual/test-manual-understand-autobuilder.rst
@@ -164,7 +164,7 @@
 on the Autobuilder. We therefore have a stash of commonly used
 repositories pre-cloned on the Workers. Data is fetched from these
 during clones first, then "topped up" with later revisions from any
-upstream when necesary. The cache is maintained by the Autobuilder
+upstream when necessary. The cache is maintained by the Autobuilder
 Worker Janitor. See :ref:`test-manual/test-manual-understand-autobuilder:Autobuilder Worker Janitor`.
 
 .. _test-autobuilder-worker-janitor:
diff --git a/poky/meta-poky/conf/distro/poky.conf b/poky/meta-poky/conf/distro/poky.conf
index b719ae4..5fbd550 100644
--- a/poky/meta-poky/conf/distro/poky.conf
+++ b/poky/meta-poky/conf/distro/poky.conf
@@ -1,7 +1,7 @@
 DISTRO = "poky"
 DISTRO_NAME = "Poky (Yocto Project Reference Distro)"
-DISTRO_VERSION = "3.1+snapshot-${DATE}"
-DISTRO_CODENAME = "master"
+DISTRO_VERSION = "3.2"
+DISTRO_CODENAME = "gatesgarth"
 SDK_VENDOR = "-pokysdk"
 SDK_VERSION = "${@d.getVar('DISTRO_VERSION').replace('snapshot-${DATE}', 'snapshot')}"
 
@@ -45,6 +45,7 @@
 SANITY_TESTED_DISTROS ?= " \
             poky-3.0 \n \
             poky-3.1 \n \
+            poky-3.2 \n \
             ubuntu-16.04 \n \
             ubuntu-18.04 \n \
             ubuntu-20.04 \n \
diff --git a/poky/meta-selftest/lib/oeqa/runtime/cases/virgl.py b/poky/meta-selftest/lib/oeqa/runtime/cases/virgl.py
index 892c19c..144decd 100644
--- a/poky/meta-selftest/lib/oeqa/runtime/cases/virgl.py
+++ b/poky/meta-selftest/lib/oeqa/runtime/cases/virgl.py
@@ -13,6 +13,6 @@
 
     @OETestDepends(['virgl.VirglTest.test_kernel_driver'])
     def test_kmscube(self):
-        status, output = self.target.run('kmscube', timeout=30)
+        status, output = self.target.run('kmscube')
         self.assertEqual(status, 0, "kmscube exited with non-zero status %d and output:\n%s" %(status, output))
         self.assertIn('renderer: "virgl"', output, "kmscube does not seem to use virgl:\n%s" %(output))
diff --git a/poky/meta-skeleton/recipes-baremetal/baremetal-examples/baremetal-helloworld_git.bb b/poky/meta-skeleton/recipes-baremetal/baremetal-examples/baremetal-helloworld_git.bb
index 7a580bd..946a12d 100644
--- a/poky/meta-skeleton/recipes-baremetal/baremetal-examples/baremetal-helloworld_git.bb
+++ b/poky/meta-skeleton/recipes-baremetal/baremetal-examples/baremetal-helloworld_git.bb
@@ -40,8 +40,8 @@
 # Install binaries on the proper location for baremetal-image to fetch and deploy
 do_install(){
     install -d ${D}/${base_libdir}/firmware
-    install -m 755 ${B}build/hello_baremetal_${BAREMETAL_QEMUARCH}.bin ${D}/${base_libdir}/firmware/${BAREMETAL_BINNAME}.bin
-    install -m 755 ${B}build/hello_baremetal_${BAREMETAL_QEMUARCH}.elf ${D}/${base_libdir}/firmware/${BAREMETAL_BINNAME}.elf
+    install -m 755 ${B}/build/hello_baremetal_${BAREMETAL_QEMUARCH}.bin ${D}/${base_libdir}/firmware/${BAREMETAL_BINNAME}.bin
+    install -m 755 ${B}/build/hello_baremetal_${BAREMETAL_QEMUARCH}.elf ${D}/${base_libdir}/firmware/${BAREMETAL_BINNAME}.elf
 }
 
 FILES_${PN} += " \
diff --git a/poky/meta/classes/autotools.bbclass b/poky/meta/classes/autotools.bbclass
index 1f3c771..70804b8 100644
--- a/poky/meta/classes/autotools.bbclass
+++ b/poky/meta/classes/autotools.bbclass
@@ -90,7 +90,7 @@
 	cfgscript=`python3 -c "import os; print(os.path.relpath(os.path.dirname('${CONFIGURE_SCRIPT}'), '.'))"`/$cfgscript_name
 	if [ -x "$cfgscript" ] ; then
 		bbnote "Running $cfgscript ${CONFIGUREOPTS} ${EXTRA_OECONF} $@"
-		if ! ${CACHED_CONFIGUREVARS} CONFIG_SHELL=/bin/bash $cfgscript ${CONFIGUREOPTS} ${EXTRA_OECONF} "$@"; then
+		if ! CONFIG_SHELL=/bin/bash ${CACHED_CONFIGUREVARS} $cfgscript ${CONFIGUREOPTS} ${EXTRA_OECONF} "$@"; then
 			bbnote "The following config.log files may provide further information."
 			bbnote `find ${B} -ignore_readdir_race -type f -name config.log`
 			bbfatal_log "configure failed"
diff --git a/poky/meta/classes/buildhistory.bbclass b/poky/meta/classes/buildhistory.bbclass
index 0f26c3c..7d5e3eb 100644
--- a/poky/meta/classes/buildhistory.bbclass
+++ b/poky/meta/classes/buildhistory.bbclass
@@ -116,6 +116,7 @@
             self.srcrev = ""
             self.layer = ""
             self.config = ""
+            self.src_uri = ""
 
 
     class PackageInfo:
@@ -258,6 +259,7 @@
     rcpinfo.packages = packages
     rcpinfo.layer = layer
     rcpinfo.config = sortlist(oe.utils.squashspaces(d.getVar('PACKAGECONFIG') or ""))
+    rcpinfo.src_uri = oe.utils.squashspaces(d.getVar('SRC_URI') or "")
     write_recipehistory(rcpinfo, d)
 
     bb.build.exec_func("read_subpackage_metadata", d)
@@ -368,6 +370,7 @@
         f.write(u"PACKAGES = %s\n" %  rcpinfo.packages)
         f.write(u"LAYER = %s\n" %  rcpinfo.layer)
         f.write(u"CONFIG = %s\n" %  rcpinfo.config)
+        f.write(u"SRC_URI = %s\n" %  rcpinfo.src_uri)
 
     write_latest_srcrev(d, pkghistdir)
 
diff --git a/poky/meta/classes/externalsrc.bbclass b/poky/meta/classes/externalsrc.bbclass
index d200129..dd09395 100644
--- a/poky/meta/classes/externalsrc.bbclass
+++ b/poky/meta/classes/externalsrc.bbclass
@@ -85,7 +85,7 @@
             if task.endswith("_setscene"):
                 # sstate is never going to work for external source trees, disable it
                 bb.build.deltask(task, d)
-            else:
+            elif os.path.realpath(d.getVar('S')) == os.path.realpath(d.getVar('B')):
                 # Since configure will likely touch ${S}, ensure only we lock so one task has access at a time
                 d.appendVarFlag(task, "lockfiles", " ${S}/singletask.lock")
 
diff --git a/poky/meta/classes/populate_sdk_base.bbclass b/poky/meta/classes/populate_sdk_base.bbclass
index 61b31d5..49b1833 100644
--- a/poky/meta/classes/populate_sdk_base.bbclass
+++ b/poky/meta/classes/populate_sdk_base.bbclass
@@ -1,4 +1,4 @@
-inherit meta image-postinst-intercepts
+inherit meta image-postinst-intercepts image-artifact-names
 
 # Wildcards specifying complementary packages to install for every package that has been explicitly
 # installed into the rootfs
diff --git a/poky/meta/classes/siteinfo.bbclass b/poky/meta/classes/siteinfo.bbclass
index 1a048c0..0bd1f36 100644
--- a/poky/meta/classes/siteinfo.bbclass
+++ b/poky/meta/classes/siteinfo.bbclass
@@ -45,6 +45,7 @@
         "mipsisa32r6": "endian-big bit-32 mips-common",
         "mipsisa32r6el": "endian-little bit-32 mips-common",
         "powerpc": "endian-big bit-32 powerpc-common",
+        "powerpcle": "endian-little bit-32 powerpc-common",
         "nios2": "endian-little bit-32 nios2-common",
         "powerpc64": "endian-big bit-64 powerpc-common",
         "powerpc64le": "endian-little bit-64 powerpc-common",
@@ -54,7 +55,9 @@
         "riscv32": "endian-little bit-32 riscv-common",
         "riscv64": "endian-little bit-64 riscv-common",
         "sh3": "endian-little bit-32 sh-common",
+        "sh3eb": "endian-big bit-32 sh-common",
         "sh4": "endian-little bit-32 sh-common",
+        "sh4eb": "endian-big bit-32 sh-common",
         "sparc": "endian-big bit-32",
         "viac3": "endian-little bit-32 ix86-common",
         "x86_64": "endian-little", # bitinfo specified in targetinfo
@@ -100,6 +103,8 @@
         "mipsisa64r6el-linux-gnun32": "mipsisa32r6el-linux bit-32",
         "powerpc-linux": "powerpc32-linux",
         "powerpc-linux-musl": "powerpc-linux powerpc32-linux",
+        "powerpcle-linux": "powerpc32-linux",
+        "powerpcle-linux-musl": "powerpc-linux powerpc32-linux",
         "powerpc-linux-gnuspe": "powerpc-linux powerpc32-linux",
         "powerpc-linux-muslspe": "powerpc-linux powerpc32-linux",
         "powerpc64-linux-gnuspe": "powerpc-linux powerpc64-linux",
diff --git a/poky/meta/classes/waf.bbclass b/poky/meta/classes/waf.bbclass
index 309f625..188119f 100644
--- a/poky/meta/classes/waf.bbclass
+++ b/poky/meta/classes/waf.bbclass
@@ -1,7 +1,12 @@
 # avoids build breaks when using no-static-libs.inc
 DISABLE_STATIC = ""
 
+# What Python interpretter to use.  Defaults to Python 3 but can be
+# overridden if required.
+WAF_PYTHON ?= "python3"
+
 B = "${WORKDIR}/build"
+do_configure[cleandirs] += "${B}"
 
 EXTRA_OECONF_append = " ${PACKAGECONFIG_CONFARGS}"
 
@@ -40,9 +45,10 @@
     import subprocess
     from distutils.version import StrictVersion
     subsrcdir = d.getVar('S')
+    python = d.getVar('WAF_PYTHON')
     wafbin = os.path.join(subsrcdir, 'waf')
     try:
-        result = subprocess.check_output([wafbin, '--version'], cwd=subsrcdir, stderr=subprocess.STDOUT)
+        result = subprocess.check_output([python, wafbin, '--version'], cwd=subsrcdir, stderr=subprocess.STDOUT)
         version = result.decode('utf-8').split()[1]
         if StrictVersion(version) >= StrictVersion("1.8.7"):
             d.setVar("WAF_EXTRA_CONF", "--bindir=${bindir} --libdir=${libdir}")
@@ -55,16 +61,16 @@
 do_configure[prefuncs] += "waf_preconfigure"
 
 waf_do_configure() {
-	(cd ${S} && ./waf configure -o ${B} --prefix=${prefix} ${WAF_EXTRA_CONF} ${EXTRA_OECONF})
+	(cd ${S} && ${WAF_PYTHON} ./waf configure -o ${B} --prefix=${prefix} ${WAF_EXTRA_CONF} ${EXTRA_OECONF})
 }
 
 do_compile[progress] = "outof:^\[\s*(\d+)/\s*(\d+)\]\s+"
 waf_do_compile()  {
-	(cd ${S} && ./waf build ${@oe.utils.parallel_make_argument(d, '-j%d', limit=64)} ${EXTRA_OEWAF_BUILD})
+	(cd ${S} && ${WAF_PYTHON} ./waf build ${@oe.utils.parallel_make_argument(d, '-j%d', limit=64)} ${EXTRA_OEWAF_BUILD})
 }
 
 waf_do_install() {
-	(cd ${S} && ./waf install --destdir=${D} ${EXTRA_OEWAF_INSTALL})
+	(cd ${S} && ${WAF_PYTHON} ./waf install --destdir=${D} ${EXTRA_OEWAF_INSTALL})
 }
 
 EXPORT_FUNCTIONS do_configure do_compile do_install
diff --git a/poky/meta/conf/layer.conf b/poky/meta/conf/layer.conf
index 38df0f3..2d9cd05 100644
--- a/poky/meta/conf/layer.conf
+++ b/poky/meta/conf/layer.conf
@@ -7,7 +7,7 @@
 BBFILE_PATTERN_core = "^${LAYERDIR}/"
 BBFILE_PRIORITY_core = "5"
 
-LAYERSERIES_CORENAMES = "dunfell gatesgarth"
+LAYERSERIES_CORENAMES = "gatesgarth"
 
 # This should only be incremented on significant changes that will
 # cause compatibility issues with other layers
@@ -102,4 +102,6 @@
 SSTATE_EXCLUDEDEPS_SYSROOT += ".*->autoconf-archive-native"
 
 # We need to keep bitbake tools in PATH
-PATH := "${@os.path.dirname(bb.utils.which(d.getVar('PATH'),'bitbake'))}:${HOSTTOOLS_DIR}"
+# Avoid empty path entries
+BITBAKEPATH := "${@os.path.dirname(bb.utils.which(d.getVar('PATH'),'bitbake'))}"
+PATH := "${@'${BITBAKEPATH}:' if '${BITBAKEPATH}' is not '' else ''}${HOSTTOOLS_DIR}"
diff --git a/poky/meta/conf/machine/include/arm/arch-arm64.inc b/poky/meta/conf/machine/include/arm/arch-arm64.inc
index 1423422..eab3323 100644
--- a/poky/meta/conf/machine/include/arm/arch-arm64.inc
+++ b/poky/meta/conf/machine/include/arm/arch-arm64.inc
@@ -10,7 +10,7 @@
 # Little Endian base configs
 AVAILTUNES += "aarch64 aarch64_be"
 ARMPKGARCH_tune-aarch64 ?= "aarch64"
-ARMPKGARCH_tune-aarch64_be ?= "aarch64_be"
+ARMPKGARCH_tune-aarch64_be ?= "aarch64"
 TUNE_FEATURES_tune-aarch64 = "aarch64"
 TUNE_FEATURES_tune-aarch64_be = "${TUNE_FEATURES_tune-aarch64} bigendian"
 TUNE_PKGARCH_64_tune-aarch64 = "aarch64"
diff --git a/poky/meta/conf/machine/include/arm/arch-armv7a.inc b/poky/meta/conf/machine/include/arm/arch-armv7a.inc
index d795b86..ce87af5 100644
--- a/poky/meta/conf/machine/include/arm/arch-armv7a.inc
+++ b/poky/meta/conf/machine/include/arm/arch-armv7a.inc
@@ -120,7 +120,7 @@
 PACKAGE_EXTRA_ARCHS_tune-armv7ab-vfpv3       = "${PACKAGE_EXTRA_ARCHS_tune-armv7ab-vfpv3d16} armv7ab-vfpv3"
 PACKAGE_EXTRA_ARCHS_tune-armv7atb-vfpv3      = "${PACKAGE_EXTRA_ARCHS_tune-armv7atb-vfpv3d16} armv7ab-vfpv3 armv7at2b-vfpv3"
 PACKAGE_EXTRA_ARCHS_tune-armv7ab-vfpv4d16    = "${PACKAGE_EXTRA_ARCHS_tune-armv7ab} armv7ab-vfpv4d16"
-PACKAGE_EXTRA_ARCHS_tune-armv7atb-vfp43d16   = "${PACKAGE_EXTRA_ARCHS_tune-armv7atb} armv7ab-vfpv4d16 armv7at2b-vfpv4d16"
+PACKAGE_EXTRA_ARCHS_tune-armv7atb-vfpv4d16   = "${PACKAGE_EXTRA_ARCHS_tune-armv7atb} armv7ab-vfpv4d16 armv7at2b-vfpv4d16"
 PACKAGE_EXTRA_ARCHS_tune-armv7ab-neon        = "${PACKAGE_EXTRA_ARCHS_tune-armv7ab} armv7ab-neon"
 PACKAGE_EXTRA_ARCHS_tune-armv7atb-neon       = "${PACKAGE_EXTRA_ARCHS_tune-armv7atb} armv7ab-neon armv7at2b-neon"
 PACKAGE_EXTRA_ARCHS_tune-armv7ab-neon-vfpv4  = "${PACKAGE_EXTRA_ARCHS_tune-armv7ab-neon} armv7ab-neon-vfpv4"
diff --git a/poky/meta/conf/machine/include/arm/armv8-2a/tune-cortexa76ae.inc b/poky/meta/conf/machine/include/arm/armv8-2a/tune-cortexa76ae.inc
index d368aa1..8d5a0ef 100644
--- a/poky/meta/conf/machine/include/arm/armv8-2a/tune-cortexa76ae.inc
+++ b/poky/meta/conf/machine/include/arm/armv8-2a/tune-cortexa76ae.inc
@@ -11,6 +11,6 @@
 # Little Endian base configs
 AVAILTUNES                                         += "cortexa76ae"
 ARMPKGARCH_tune-cortexa76ae                         = "cortexa76ae"
-TUNE_FEATURES_tune-cortexa65ae                      = "${TUNE_FEATURES_tune-armv8-2a-crypto} cortexa76ae"
+TUNE_FEATURES_tune-cortexa76ae                      = "${TUNE_FEATURES_tune-armv8-2a-crypto} cortexa76ae"
 PACKAGE_EXTRA_ARCHS_tune-cortexa76ae                = "${PACKAGE_EXTRA_ARCHS_tune-armv8-2a-crypto} cortexa76ae"
 BASE_LIB_tune-cortexa76ae                           = "lib64"
diff --git a/poky/meta/conf/machine/include/mips/arch-mips.inc b/poky/meta/conf/machine/include/mips/arch-mips.inc
index b45989a..cb1a4c4 100644
--- a/poky/meta/conf/machine/include/mips/arch-mips.inc
+++ b/poky/meta/conf/machine/include/mips/arch-mips.inc
@@ -135,7 +135,7 @@
 TUNE_FEATURES_tune-mips64el-o32 = "o32 fpu-hard"
 BASE_LIB_tune-mips64el-o32 = "lib"
 MIPSPKGSFX_VARIANT_tune-mips64el-o32 = "${TUNE_ARCH}"
-PACKAGE_EXTRA_ARCHS_tune-mips64el-o32 = "mipsel mips64el-o32 mips64el-o32"
+PACKAGE_EXTRA_ARCHS_tune-mips64el-o32 = "mipsel mips64el-o32"
 
 # MIPS 64 o32 and Soft Float
 AVAILTUNES += "mips64-nf-o32 mips64el-nf-o32"
diff --git a/poky/meta/conf/machine/include/riscv/tune-riscv.inc b/poky/meta/conf/machine/include/riscv/tune-riscv.inc
index 741eeb3..028548b 100644
--- a/poky/meta/conf/machine/include/riscv/tune-riscv.inc
+++ b/poky/meta/conf/machine/include/riscv/tune-riscv.inc
@@ -24,10 +24,10 @@
 # No float
 TUNE_FEATURES_tune-riscv64nf = "${TUNE_FEATURES_tune-riscv64} riscv64nf"
 TUNE_ARCH_tune-riscv64nf = "riscv64"
-TUNE_PKGARCH_tune-riscv64nf = "riscv64"
+TUNE_PKGARCH_tune-riscv64nf = "riscv64nf"
 PACKAGE_EXTRA_ARCHS_tune-riscv64nf = "riscv64nf"
 
 TUNE_FEATURES_tune-riscv32nf = "${TUNE_FEATURES_tune-riscv32} riscv32nf"
 TUNE_ARCH_tune-riscv32nf = "riscv32"
-TUNE_PKGARCH_tune-riscv32nf = "riscv32"
+TUNE_PKGARCH_tune-riscv32nf = "riscv32nf"
 PACKAGE_EXTRA_ARCHS_tune-riscv32nf = "riscv32nf"
diff --git a/poky/meta/conf/machine/include/tune-ep9312.inc b/poky/meta/conf/machine/include/tune-ep9312.inc
index 11fd266..5e1a0e5 100644
--- a/poky/meta/conf/machine/include/tune-ep9312.inc
+++ b/poky/meta/conf/machine/include/tune-ep9312.inc
@@ -8,6 +8,5 @@
 
 AVAILTUNES += "ep9312"
 ARMPKGARCH_tune-ep9312 = "ep9312"
-# this tune does not include TUNE_FEATURES_tune-armv4t, so there is no armv4 TUNE_FEATURES => no 't' in ARMPKGSFX_THUMB
 TUNE_FEATURES_tune-ep9312 = "thumb ep9312"
-PACKAGE_EXTRA_ARCHS_tune-ep9312 = "${PACKAGE_EXTRA_ARCHS_tune-armv4t} ep9312"
+PACKAGE_EXTRA_ARCHS_tune-ep9312 = "${PACKAGE_EXTRA_ARCHS_tune-armv4t} ep9312t"
diff --git a/poky/meta/conf/machine/include/tune-mips64r6.inc b/poky/meta/conf/machine/include/tune-mips64r6.inc
index 4fe3eed..e53239a 100644
--- a/poky/meta/conf/machine/include/tune-mips64r6.inc
+++ b/poky/meta/conf/machine/include/tune-mips64r6.inc
@@ -24,7 +24,7 @@
 TUNE_FEATURES_tune-mipsisa64r6-nf = "bigendian r6 n64 mipsisa64r6"
 MIPSPKGSFX_VARIANT_tune-mipsisa64r6-nf = "${TUNE_ARCH}"
 BASE_LIB_tune-mipsisa64r6-nf = "lib64"
-PACKAGE_EXTRA_ARCHS_tune-mipsisa64r6-nf = "mipsisa64r6"
+PACKAGE_EXTRA_ARCHS_tune-mipsisa64r6-nf = "mipsisa64r6-nf"
 
 TUNE_FEATURES_tune-mipsisa64r6el-nf = "r6 n64 mipsisa64r6"
 MIPSPKGSFX_VARIANT_tune-mipsisa64r6el-nf = "${TUNE_ARCH}"
diff --git a/poky/meta/conf/machine/include/tune-supersparc.inc b/poky/meta/conf/machine/include/tune-supersparc.inc
deleted file mode 100644
index 0faa361..0000000
--- a/poky/meta/conf/machine/include/tune-supersparc.inc
+++ /dev/null
@@ -1,4 +0,0 @@
-TUNE_ARCH = "sparc"
-
-TUNE_CCARGS = "-mcpu=supersparc"
-TUNE_PKGARCH = "supersparc"
diff --git a/poky/meta/conf/machine/include/tune-thunderx.inc b/poky/meta/conf/machine/include/tune-thunderx.inc
index aa4d050..d1aaf48 100644
--- a/poky/meta/conf/machine/include/tune-thunderx.inc
+++ b/poky/meta/conf/machine/include/tune-thunderx.inc
@@ -8,7 +8,7 @@
 require conf/machine/include/arm/arch-armv8a.inc
 
 ARMPKGARCH_tune-thunderx ?= "thunderx"
-ARMPKGARCH_tune-thunderx_be ?= "thunderx_be"
+ARMPKGARCH_tune-thunderx_be ?= "thunderx"
 
 TUNE_FEATURES_tune-thunderx = "${TUNE_FEATURES_tune-aarch64} thunderx"
 TUNE_FEATURES_tune-thunderx_be = "${TUNE_FEATURES_tune-thunderx} bigendian"
diff --git a/poky/meta/conf/machine/qemumips.conf b/poky/meta/conf/machine/qemumips.conf
index b8c80f0..1373e4c 100644
--- a/poky/meta/conf/machine/qemumips.conf
+++ b/poky/meta/conf/machine/qemumips.conf
@@ -15,4 +15,4 @@
 
 QB_SYSTEM_NAME = "qemu-system-mips"
 
-QB_CPU = "-cpu 34Kf-64tlb"
+QB_CPU = "-cpu 34Kf"
diff --git a/poky/meta/files/toolchain-shar-extract.sh b/poky/meta/files/toolchain-shar-extract.sh
index 04527f8..bea6d41 100644
--- a/poky/meta/files/toolchain-shar-extract.sh
+++ b/poky/meta/files/toolchain-shar-extract.sh
@@ -26,7 +26,7 @@
 INST_ARCH=$(uname -m | sed -e "s/i[3-6]86/ix86/" -e "s/x86[-_]64/x86_64/")
 SDK_ARCH=$(echo @SDK_ARCH@ | sed -e "s/i[3-6]86/ix86/" -e "s/x86[-_]64/x86_64/")
 
-INST_GCC_VER=$(gcc --version | sed -ne 's/.* \([0-9]\+\.[0-9]\+\)\.[0-9]\+.*/\1/p')
+INST_GCC_VER=$(gcc --version 2>/dev/null | sed -ne 's/.* \([0-9]\+\.[0-9]\+\)\.[0-9]\+.*/\1/p')
 SDK_GCC_VER='@SDK_GCC_VER@'
 
 verlte () {
diff --git a/poky/meta/lib/oe/rootfs.py b/poky/meta/lib/oe/rootfs.py
index 3813f68..4e09eae 100644
--- a/poky/meta/lib/oe/rootfs.py
+++ b/poky/meta/lib/oe/rootfs.py
@@ -55,6 +55,8 @@
         excludes = [ 'log_check', r'^\+' ]
         if hasattr(self, 'log_check_expected_regexes'):
             excludes.extend(self.log_check_expected_regexes)
+        # Insert custom log_check excludes
+        excludes += [x for x in (self.d.getVar("IMAGE_LOG_CHECK_EXCLUDES") or "").split(" ") if x]
         excludes = [re.compile(x) for x in excludes]
         r = re.compile(match)
         log_path = self.d.expand("${T}/log.do_rootfs")
diff --git a/poky/meta/lib/oeqa/selftest/cases/devtool.py b/poky/meta/lib/oeqa/selftest/cases/devtool.py
index 0185e67..d3d2e04 100644
--- a/poky/meta/lib/oeqa/selftest/cases/devtool.py
+++ b/poky/meta/lib/oeqa/selftest/cases/devtool.py
@@ -107,13 +107,6 @@
                         'under the build directory')
         self.append_config(self.sstate_conf)
 
-    def tearDown(self):
-        # devtools tests are heavy on IO and if bitbake can't write out its caches, we see timeouts.
-        # call sync around the tests to ensure the IO queue doesn't get too large, taking any IO
-        # hit here rather than in bitbake shutdown.
-        super().tearDown()
-        os.system("sync")
-
     def _check_src_repo(self, repo_dir):
         """Check srctree git repository"""
         self.assertTrue(os.path.isdir(os.path.join(repo_dir, '.git')),
diff --git a/poky/meta/lib/oeqa/selftest/cases/imagefeatures.py b/poky/meta/lib/oeqa/selftest/cases/imagefeatures.py
index f7a2533..415e031 100644
--- a/poky/meta/lib/oeqa/selftest/cases/imagefeatures.py
+++ b/poky/meta/lib/oeqa/selftest/cases/imagefeatures.py
@@ -5,6 +5,7 @@
 from oeqa.selftest.case import OESelftestTestCase
 from oeqa.utils.commands import runCmd, bitbake, get_bb_var, runqemu
 from oeqa.utils.sshcontrol import SSHControl
+import glob
 import os
 import json
 
@@ -347,7 +348,7 @@
         Author:      Humberto Ibarra <humberto.ibarra.lopez@intel.com>
                      Yeoh Ee Peng <ee.peng.yeoh@intel.com>
         """
-        import glob
+      
         image_name = 'core-image-minimal'
         features = 'IMAGE_GEN_DEBUGFS = "1"\n'
         features += 'IMAGE_FSTYPES_DEBUGFS = "tar.bz2"\n'
@@ -368,3 +369,12 @@
         for t in dbg_symbols_targets:
             result = runCmd('objdump --syms %s | grep debug' % t)
             self.assertTrue("debug" in result.output, msg='Failed to find debug symbol: %s' % result.output)
+
+    def test_empty_image(self):
+        """Test creation of image with no packages"""
+        bitbake('test-empty-image')
+        res_dir = get_bb_var('DEPLOY_DIR_IMAGE')
+        images = os.path.join(res_dir, "test-empty-image-*.manifest")
+        result = glob.glob(images)
+        with open(result[1],"r") as f:
+                self.assertEqual(len(f.read().strip()),0)
diff --git a/poky/meta/lib/oeqa/selftest/cases/runcmd.py b/poky/meta/lib/oeqa/selftest/cases/runcmd.py
index a5ef1ea..fa6113d 100644
--- a/poky/meta/lib/oeqa/selftest/cases/runcmd.py
+++ b/poky/meta/lib/oeqa/selftest/cases/runcmd.py
@@ -64,12 +64,12 @@
                                 runCmd, "echo foobar >&2; false", shell=True, assert_error=False)
 
     def test_output(self):
-        result = runCmd("echo stdout; echo stderr >&2", shell=True)
+        result = runCmd("echo stdout; echo stderr >&2", shell=True, sync=False)
         self.assertEqual("stdout\nstderr", result.output)
         self.assertEqual("", result.error)
 
     def test_output_split(self):
-        result = runCmd("echo stdout; echo stderr >&2", shell=True, stderr=subprocess.PIPE)
+        result = runCmd("echo stdout; echo stderr >&2", shell=True, stderr=subprocess.PIPE, sync=False)
         self.assertEqual("stdout", result.output)
         self.assertEqual("stderr", result.error)
 
@@ -77,7 +77,7 @@
         numthreads = threading.active_count()
         start = time.time()
         # Killing a hanging process only works when not using a shell?!
-        result = runCmd(['sleep', '60'], timeout=self.TIMEOUT, ignore_status=True)
+        result = runCmd(['sleep', '60'], timeout=self.TIMEOUT, ignore_status=True, sync=False)
         self.assertEqual(result.status, -signal.SIGTERM)
         end = time.time()
         self.assertLess(end - start, self.TIMEOUT + self.DELTA)
@@ -87,7 +87,7 @@
         numthreads = threading.active_count()
         start = time.time()
         # Killing a hanging process only works when not using a shell?!
-        result = runCmd(['sleep', '60'], timeout=self.TIMEOUT, ignore_status=True, stderr=subprocess.PIPE)
+        result = runCmd(['sleep', '60'], timeout=self.TIMEOUT, ignore_status=True, stderr=subprocess.PIPE, sync=False)
         self.assertEqual(result.status, -signal.SIGTERM)
         end = time.time()
         self.assertLess(end - start, self.TIMEOUT + self.DELTA)
@@ -95,7 +95,7 @@
 
     def test_stdin(self):
         numthreads = threading.active_count()
-        result = runCmd("cat", data=b"hello world", timeout=self.TIMEOUT)
+        result = runCmd("cat", data=b"hello world", timeout=self.TIMEOUT, sync=False)
         self.assertEqual("hello world", result.output)
         self.assertEqual(numthreads, threading.active_count(), msg="Thread counts were not equal before (%s) and after (%s), active threads: %s" % (numthreads, threading.active_count(), threading.enumerate()))
         self.assertEqual(numthreads, 1)
@@ -103,7 +103,7 @@
     def test_stdin_timeout(self):
         numthreads = threading.active_count()
         start = time.time()
-        result = runCmd(['sleep', '60'], data=b"hello world", timeout=self.TIMEOUT, ignore_status=True)
+        result = runCmd(['sleep', '60'], data=b"hello world", timeout=self.TIMEOUT, ignore_status=True, sync=False)
         self.assertEqual(result.status, -signal.SIGTERM)
         end = time.time()
         self.assertLess(end - start, self.TIMEOUT + self.DELTA)
@@ -111,12 +111,12 @@
 
     def test_log(self):
         log = MemLogger()
-        result = runCmd("echo stdout; echo stderr >&2", shell=True, output_log=log)
+        result = runCmd("echo stdout; echo stderr >&2", shell=True, output_log=log, sync=False)
         self.assertEqual(["Running: echo stdout; echo stderr >&2", "stdout", "stderr"], log.info_msgs)
         self.assertEqual([], log.error_msgs)
 
     def test_log_split(self):
         log = MemLogger()
-        result = runCmd("echo stdout; echo stderr >&2", shell=True, output_log=log, stderr=subprocess.PIPE)
+        result = runCmd("echo stdout; echo stderr >&2", shell=True, output_log=log, stderr=subprocess.PIPE, sync=False)
         self.assertEqual(["Running: echo stdout; echo stderr >&2", "stdout"], log.info_msgs)
         self.assertEqual(["stderr"], log.error_msgs)
diff --git a/poky/meta/lib/oeqa/utils/commands.py b/poky/meta/lib/oeqa/utils/commands.py
index f7f8c16..8059cbc 100644
--- a/poky/meta/lib/oeqa/utils/commands.py
+++ b/poky/meta/lib/oeqa/utils/commands.py
@@ -167,7 +167,7 @@
     pass
 
 
-def runCmd(command, ignore_status=False, timeout=None, assert_error=True,
+def runCmd(command, ignore_status=False, timeout=None, assert_error=True, sync=True,
           native_sysroot=None, limit_exc_output=0, output_log=None, **options):
     result = Result()
 
@@ -184,6 +184,12 @@
     cmd = Command(command, timeout=timeout, output_log=output_log, **options)
     cmd.run()
 
+    # tests can be heavy on IO and if bitbake can't write out its caches, we see timeouts.
+    # call sync around the tests to ensure the IO queue doesn't get too large, taking any IO
+    # hit here rather than in bitbake shutdown.
+    if sync:
+        os.system("sync")
+
     result.command = command
     result.status = cmd.status
     result.output = cmd.output
diff --git a/poky/meta/recipes-bsp/grub/files/CVE-2020-10713.patch b/poky/meta/recipes-bsp/grub/files/CVE-2020-10713.patch
new file mode 100644
index 0000000..c507ed3
--- /dev/null
+++ b/poky/meta/recipes-bsp/grub/files/CVE-2020-10713.patch
@@ -0,0 +1,73 @@
+From a4d3fbdff1e3ca8f87642af2ac8752c30c617a3e Mon Sep 17 00:00:00 2001
+From: Peter Jones <pjones@redhat.com>
+Date: Wed, 15 Apr 2020 15:45:02 -0400
+Subject: yylex: Make lexer fatal errors actually be fatal
+
+When presented with a command that can't be tokenized to anything
+smaller than YYLMAX characters, the parser calls YY_FATAL_ERROR(errmsg),
+expecting that will stop further processing, as such:
+
+  #define YY_DO_BEFORE_ACTION \
+        yyg->yytext_ptr = yy_bp; \
+        yyleng = (int) (yy_cp - yy_bp); \
+        yyg->yy_hold_char = *yy_cp; \
+        *yy_cp = '\0'; \
+        if ( yyleng >= YYLMAX ) \
+                YY_FATAL_ERROR( "token too large, exceeds YYLMAX" ); \
+        yy_flex_strncpy( yytext, yyg->yytext_ptr, yyleng + 1 , yyscanner); \
+        yyg->yy_c_buf_p = yy_cp;
+
+The code flex generates expects that YY_FATAL_ERROR() will either return
+for it or do some form of longjmp(), or handle the error in some way at
+least, and so the strncpy() call isn't in an "else" clause, and thus if
+YY_FATAL_ERROR() is *not* actually fatal, it does the call with the
+questionable limit, and predictable results ensue.
+
+Unfortunately, our implementation of YY_FATAL_ERROR() is:
+
+   #define YY_FATAL_ERROR(msg)                     \
+     do {                                          \
+       grub_printf (_("fatal error: %s\n"), _(msg));     \
+     } while (0)
+
+The same pattern exists in yyless(), and similar problems exist in users
+of YY_INPUT(), several places in the main parsing loop,
+yy_get_next_buffer(), yy_load_buffer_state(), yyensure_buffer_stack,
+yy_scan_buffer(), etc.
+
+All of these callers expect YY_FATAL_ERROR() to actually be fatal, and
+the things they do if it returns after calling it are wildly unsafe.
+
+Fixes: CVE-2020-10713
+
+Signed-off-by: Peter Jones <pjones@redhat.com>
+Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
+
+Upstream-Status: Backport [https://git.savannah.gnu.org/cgit/grub.git/commit/?id=a4d3fbdff1e3ca8f87642af2ac8752c30c617a3e]
+CVE: CVE-2020-10713
+Signed-off-by: Chee Yang Lee <chee.yang.lee@intel.com>
+---
+ grub-core/script/yylex.l | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/grub-core/script/yylex.l b/grub-core/script/yylex.l
+index 7b44c37b7..b7203c823 100644
+--- a/grub-core/script/yylex.l
++++ b/grub-core/script/yylex.l
+@@ -37,11 +37,11 @@
+ 
+ /* 
+  * As we don't have access to yyscanner, we cannot do much except to
+- * print the fatal error.
++ * print the fatal error and exit.
+  */
+ #define YY_FATAL_ERROR(msg)                     \
+   do {                                          \
+-    grub_printf (_("fatal error: %s\n"), _(msg));     \
++    grub_fatal (_("fatal error: %s\n"), _(msg));\
+   } while (0)
+ 
+ #define COPY(str, hint)                         \
+-- 
+cgit v1.2.1
+
diff --git a/poky/meta/recipes-bsp/grub/grub2.inc b/poky/meta/recipes-bsp/grub/grub2.inc
index 628ca64..345554e 100644
--- a/poky/meta/recipes-bsp/grub/grub2.inc
+++ b/poky/meta/recipes-bsp/grub/grub2.inc
@@ -18,6 +18,7 @@
            file://autogen.sh-exclude-pc.patch \
            file://grub-module-explicitly-keeps-symbole-.module_license.patch \
            file://0001-grub.d-10_linux.in-add-oe-s-kernel-name.patch \
+           file://CVE-2020-10713.patch \
 "
 SRC_URI[md5sum] = "5ce674ca6b2612d8939b9e6abed32934"
 SRC_URI[sha256sum] = "f10c85ae3e204dbaec39ae22fa3c5e99f0665417e91c2cb49b7e5031658ba6ea"
diff --git a/poky/meta/recipes-connectivity/dhcpcd/dhcpcd_9.2.0.bb b/poky/meta/recipes-connectivity/dhcpcd/dhcpcd_9.2.0.bb
index 4344841..1346718 100644
--- a/poky/meta/recipes-connectivity/dhcpcd/dhcpcd_9.2.0.bb
+++ b/poky/meta/recipes-connectivity/dhcpcd/dhcpcd_9.2.0.bb
@@ -27,10 +27,18 @@
 
 PACKAGECONFIG[udev] = "--with-udev,--without-udev,udev,udev"
 PACKAGECONFIG[ipv6] = "--enable-ipv6,--disable-ipv6"
+# ntp conflicts with chrony
+PACKAGECONFIG[ntp] = "--with-hook=ntp, , ,ntp"
+PACKAGECONFIG[chrony] = "--with-hook=ntp, , ,chrony"
+PACKAGECONFIG[ypbind] = "--with-eghook=yp, , ,ypbind-mt"
 
 EXTRA_OECONF = "--enable-ipv4 \
                 --dbdir=${localstatedir}/lib/${BPN} \
                 --runstatedir=/run \
+                --enable-privsep \
+                --privsepuser=dhcpcd \
+                --with-hooks \
+                --with-eghooks \
                "
 
 USERADD_PACKAGES = "${PN}"
diff --git a/poky/meta/recipes-connectivity/kea/files/fix_pid_keactrl.patch b/poky/meta/recipes-connectivity/kea/files/fix_pid_keactrl.patch
new file mode 100644
index 0000000..eeeb899
--- /dev/null
+++ b/poky/meta/recipes-connectivity/kea/files/fix_pid_keactrl.patch
@@ -0,0 +1,22 @@
+Busybox does not support ps -p so use pgrep
+
+Upstream-Status: Inappropriate [embedded specific]
+Based on changes from Diego Sueiro <Diego.Sueiro@arm.com>
+
+Signed-off-by: Armin kuster <akuster808@gmail.com>
+
+Index: kea-1.7.10/src/bin/keactrl/keactrl.in
+===================================================================
+--- kea-1.7.10.orig/src/bin/keactrl/keactrl.in
++++ kea-1.7.10/src/bin/keactrl/keactrl.in
+@@ -137,8 +137,8 @@ check_running() {
+     # Get the PID from the PID file (if it exists)
+     get_pid_from_file "${proc_name}"
+     if [ ${_pid} -gt 0 ]; then
+-        # Use ps to check if PID is alive
+-        ps -p ${_pid} 1>/dev/null
++        # Use pgrep and grep to check if PID is alive
++        pgrep -v 1 | grep ${_pid} 1>/dev/null
+         retcode=$?
+         if [ $retcode -eq 0 ]; then
+             # No error, so PID IS ALIVE
diff --git a/poky/meta/recipes-connectivity/kea/files/kea-dhcp-ddns-server b/poky/meta/recipes-connectivity/kea/files/kea-dhcp-ddns-server
new file mode 100644
index 0000000..50fe40d
--- /dev/null
+++ b/poky/meta/recipes-connectivity/kea/files/kea-dhcp-ddns-server
@@ -0,0 +1,46 @@
+#!/bin/sh
+### BEGIN INIT INFO
+# Provides:          kea-dhcp-ddns-server
+# Required-Start:    $local_fs $network $remote_fs $syslog
+# Required-Stop:     $local_fs $network $remote_fs $syslog
+# Default-Start:     2 3 4 5
+# Default-Stop:      0 1 6
+# Short-Description: ISC KEA DHCP IPv6 Server
+### END INIT INFO
+
+PATH=/sbin:/usr/sbin:/bin:/usr/bin
+DESC="kea-dhcp-ddns-server"
+NAME=kea-dhcp-ddns
+DAEMON=/usr/sbin/keactrl
+DAEMON_ARGS=" -s dhcp_ddns"
+
+set -e
+
+# Exit if the package is not installed
+[ -x "$DAEMON" ] || exit 0
+
+# Source function library.
+. /etc/init.d/functions
+
+case "$1" in
+  start)
+        echo -n "Starting $DESC: "
+        start-stop-daemon -S -b -n $NAME -x $DAEMON -- start $DAEMON_ARGS
+        echo "done."
+        ;;
+  stop)
+        echo -n "Stopping $DESC: "
+        kpid=`pidof $NAME`
+        kill $kpid
+        echo "done."
+        ;;
+  restart|force-reload)
+        #
+        $0 stop
+        $0 start
+        ;;
+  *)
+        echo "Usage: $SCRIPTNAME {start|stop|restart|force-reload}" >&2
+        exit 1
+        ;;
+esac
diff --git a/poky/meta/recipes-connectivity/kea/files/kea-dhcp4-server b/poky/meta/recipes-connectivity/kea/files/kea-dhcp4-server
new file mode 100644
index 0000000..e83e510
--- /dev/null
+++ b/poky/meta/recipes-connectivity/kea/files/kea-dhcp4-server
@@ -0,0 +1,46 @@
+#!/bin/sh
+### BEGIN INIT INFO
+# Provides:          kea-dhcp4-server
+# Required-Start:    $local_fs $network $remote_fs $syslog
+# Required-Stop:     $local_fs $network $remote_fs $syslog
+# Default-Start:     2 3 4 5
+# Default-Stop:      0 1 6
+# Short-Description: ISC KEA DHCP IPv6 Server
+### END INIT INFO
+
+PATH=/sbin:/usr/sbin:/bin:/usr/bin
+DESC="kea-dhcp4-server"
+NAME=kea-dhcp4
+DAEMON=/usr/sbin/keactrl
+DAEMON_ARGS=" -s dhcp4"
+
+set -e
+
+# Exit if the package is not installed
+[ -x "$DAEMON" ] || exit 0
+
+# Source function library.
+. /etc/init.d/functions
+
+case "$1" in
+  start)
+        echo -n "Starting $DESC: "
+        start-stop-daemon -S -b -n $NAME -x $DAEMON -- start $DAEMON_ARGS
+        echo "done."
+        ;;
+  stop)
+        echo -n "Stopping $DESC: "
+        kpid=`pidof $NAME`
+        kill $kpid
+        echo "done."
+        ;;
+  restart|force-reload)
+        #
+        $0 stop
+        $0 start
+        ;;
+  *)
+        echo "Usage: $SCRIPTNAME {start|stop|restart|force-reload}" >&2
+        exit 1
+        ;;
+esac
diff --git a/poky/meta/recipes-connectivity/kea/files/kea-dhcp6-server b/poky/meta/recipes-connectivity/kea/files/kea-dhcp6-server
new file mode 100644
index 0000000..10f2d22
--- /dev/null
+++ b/poky/meta/recipes-connectivity/kea/files/kea-dhcp6-server
@@ -0,0 +1,47 @@
+#!/bin/sh
+### BEGIN INIT INFO
+# Provides:          kea-dhcp6-server
+# Required-Start:    $local_fs $network $remote_fs $syslog
+# Required-Stop:     $local_fs $network $remote_fs $syslog
+# Default-Start:     2 3 4 5
+# Default-Stop:      0 1 6
+# Short-Description: ISC KEA DHCP IPv6 Server
+### END INIT INFO
+
+# PATH should only include /usr/* if it runs after the mountnfs.sh script
+PATH=/sbin:/usr/sbin:/bin:/usr/bin
+DESC="kea-dhcp6-server"
+NAME=kea-dhcp6
+DAEMON=/usr/sbin/keactrl
+DAEMON_ARGS=" -s dhcp6"
+
+set -e
+
+# Exit if the package is not installed
+[ -x "$DAEMON" ] || exit 0
+
+# Source function library.
+. /etc/init.d/functions
+
+case "$1" in
+  start)
+        echo -n "Starting $DESC: "
+        start-stop-daemon -S -b -n $NAME -x $DAEMON -- start $DAEMON_ARGS
+        echo "done."
+        ;;
+  stop)
+        echo -n "Stopping $DESC: "
+        kpid=`pidof $NAME`
+        kill $kpid
+        echo "done."
+        ;;
+  restart|force-reload)
+        #
+        $0 stop
+        $0 start
+        ;;
+  *)
+        echo "Usage: $SCRIPTNAME {start|stop|restart|force-reload}" >&2
+        exit 1
+        ;;
+esac
diff --git a/poky/meta/recipes-connectivity/kea/kea_1.7.10.bb b/poky/meta/recipes-connectivity/kea/kea_1.7.10.bb
index 2ea4b12..c9a5819 100644
--- a/poky/meta/recipes-connectivity/kea/kea_1.7.10.bb
+++ b/poky/meta/recipes-connectivity/kea/kea_1.7.10.bb
@@ -13,11 +13,18 @@
     file://kea-dhcp4.service \
     file://kea-dhcp6.service \
     file://kea-dhcp-ddns.service \
+    file://kea-dhcp4-server \
+    file://kea-dhcp6-server \
+    file://kea-dhcp-ddns-server \
     file://fix-multilib-conflict.patch \
+    file://fix_pid_keactrl.patch \
 "
 SRC_URI[sha256sum] = "4e121f0e58b175a827581c69cb1d60778647049fa47f142940dddc9ce58f3c82"
 
-inherit autotools systemd
+inherit autotools systemd update-rc.d
+
+INITSCRIPT_NAME = "kea-dhcp4-server"
+INITSCRIPT_PARAMS = "defaults 30"
 
 SYSTEMD_SERVICE_${PN} = "kea-dhcp4.service kea-dhcp6.service kea-dhcp-ddns.service"
 SYSTEMD_AUTO_ENABLE = "disable"
@@ -44,8 +51,11 @@
 }
 
 do_install_append() {
+    install -d ${D}${sysconfdir}/init.d
     install -d ${D}${systemd_system_unitdir}
+
     install -m 0644 ${WORKDIR}/kea-dhcp*service ${D}${systemd_system_unitdir}
+    install -m 0755 ${WORKDIR}/kea-*-server ${D}${sysconfdir}/init.d
     sed -i -e 's,@SBINDIR@,${sbindir},g' -e 's,@BASE_BINDIR@,${base_bindir},g' \
            -e 's,@LOCALSTATEDIR@,${localstatedir},g' -e 's,@SYSCONFDIR@,${sysconfdir},g' \
            ${D}${systemd_system_unitdir}/kea-dhcp*service ${D}${sbindir}/keactrl
@@ -55,6 +65,8 @@
     rm -rf "${D}${localstatedir}"
 }
 
+CONFFILES_${PN} = "${sysconfdir}/kea/keactrl.conf"
+
 FILES_${PN}-staticdev += "${libdir}/kea/hooks/*.a ${libdir}/hooks/*.a"
 FILES_${PN} += "${libdir}/hooks/*.so"
 
diff --git a/poky/meta/recipes-core/busybox/busybox/pgrep.cfg b/poky/meta/recipes-core/busybox/busybox/pgrep.cfg
new file mode 100644
index 0000000..775e487
--- /dev/null
+++ b/poky/meta/recipes-core/busybox/busybox/pgrep.cfg
@@ -0,0 +1 @@
+CONFIG_PGREP=y
diff --git a/poky/meta/recipes-core/busybox/busybox/rev.cfg b/poky/meta/recipes-core/busybox/busybox/rev.cfg
new file mode 100644
index 0000000..da008c3
--- /dev/null
+++ b/poky/meta/recipes-core/busybox/busybox/rev.cfg
@@ -0,0 +1 @@
+CONFIG_REV=y
diff --git a/poky/meta/recipes-core/busybox/busybox_1.32.0.bb b/poky/meta/recipes-core/busybox/busybox_1.32.0.bb
index aeea40f..8e23b0d 100644
--- a/poky/meta/recipes-core/busybox/busybox_1.32.0.bb
+++ b/poky/meta/recipes-core/busybox/busybox_1.32.0.bb
@@ -44,6 +44,8 @@
            file://0001-du-l-works-fix-to-use-145-instead-of-144.patch \
            file://0001-sysctl-ignore-EIO-of-stable_secret-below-proc-sys-ne.patch \
            file://0001-hwclock-make-glibc-2.31-compatible.patch \
+           file://rev.cfg \
+           file://pgrep.cfg \
 "
 SRC_URI_append_libc-musl = " file://musl.cfg "
 
diff --git a/poky/meta/recipes-core/glib-2.0/glib-2.0/tzdata-update.patch b/poky/meta/recipes-core/glib-2.0/glib-2.0/tzdata-update.patch
new file mode 100644
index 0000000..0af036f
--- /dev/null
+++ b/poky/meta/recipes-core/glib-2.0/glib-2.0/tzdata-update.patch
@@ -0,0 +1,458 @@
+Backport a number of patches from upstream to fix reading of the new 'slim'
+encoding for tzdata files.
+
+Upstream-Status: Backport
+Signed-off-by: Ross Burton <ross.burton@arm.com>
+
+commit 18cbd5e5a4812e9bd0b06a058322d2b44ed2ad92
+Author: Paul Eggert <eggert@cs.ucla.edu>
+Date:   Thu Jul 16 12:41:49 2020 -0700
+
+    Clarify memset in set_tz_name
+
+    * glib/gtimezone.c (set_tz_name): Use size, not NAME_SIZE,
+    to clear the buffer.  Suggested by Philip Withnall in:
+    https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1533#note_867859
+
+commit 1ab3f927d6d09a8cf3349a3545f5351446f43d47
+Author: Paul Eggert <eggert@cs.ucla.edu>
+Date:   Thu Jul 16 12:41:49 2020 -0700
+
+    gtimezone: support footers in TZif files
+
+    Since tzcode95f (1995), TZif files have had a trailing
+    TZ string, used for timestamps after the last transition.
+    This string is specified in Internet RFC 8536 section 3.3.
+    init_zone_from_iana_info has ignored this string, causing it
+    to mishandle timestamps past the year 2038.  With zic's new -b
+    slim flag, init_zone_from_iana_info would even mishandle current
+    timestamps.  Fix this by parsing the trailing TZ string and adding
+    its transitions.
+
+    Closes #2129
+
+commit e8b763e35235a2c6b4bdd48a5099c00f72741059
+Author: Paul Eggert <eggert@cs.ucla.edu>
+Date:   Thu Jul 16 12:41:49 2020 -0700
+
+    gtimezone: add support for RFC 8536 time zone transitions
+
+    Time zone transition times can range from -167:59:59 through
+    +167:59:59, according to Internet RFC 8536 section 3.3.1;
+    this is an extension to POSIX.  It is needed for proper
+    support of TZif version 3 files.
+
+commit 1c65dd48b8ebd31af8bc9b2263f83c0c411f7519
+Author: Paul Eggert <eggert@cs.ucla.edu>
+Date:   Thu Jul 16 12:41:49 2020 -0700
+
+    gtimezone: allow hh to be 24, as per POSIX
+
+    POSIX allows hh to be 24; see
+    https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_03
+
+commit 368b65cb4cb17e29a4f55654149f554a14f48bc6
+Author: Paul Eggert <eggert@cs.ucla.edu>
+Date:   Thu Jul 16 12:41:49 2020 -0700
+
+    gtimezone: support POSIX 1003.1-2001 quoted TZ abbreviations
+
+    TZ strings like '<-03>3' were introduced in POSIX 1003.1-2001 and
+    are currently specified in:
+    https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_03
+
+commit fd528aaab6bb077c6d217e62f2228ec9fe3ed760
+Author: Paul Eggert <eggert@cs.ucla.edu>
+Date:   Thu Jul 16 12:41:49 2020 -0700
+
+    gtimezone: get 64-bit data from version-3 TZif files
+
+    Version 3 was introduced in tzdb 2013e (2013).
+    See Internet RFC 8536 section 3.1 under "ver(sion)".
+
+diff --git a/glib/gtimezone.c b/glib/gtimezone.c
+index 5a835dea9..f9eee1967 100644
+--- a/glib/gtimezone.c
++++ b/glib/gtimezone.c
+@@ -142,9 +142,7 @@ typedef struct
+   gint     mday;
+   gint     wday;
+   gint     week;
+-  gint     hour;
+-  gint     min;
+-  gint     sec;
++  gint32   offset;  /* hour*3600 + min*60 + sec; can be negative.  */
+ } TimeZoneDate;
+ 
+ /* POSIX Timezone abbreviations are typically 3 or 4 characters, but
+@@ -205,6 +203,10 @@ static GTimeZone *tz_local = NULL;
+                            there's no point in getting carried
+                            away. */
+ 
++#ifdef G_OS_UNIX
++static GTimeZone *parse_footertz (const gchar *, size_t);
++#endif
++
+ /**
+  * g_time_zone_unref:
+  * @tz: a #GTimeZone
+@@ -286,13 +288,20 @@ g_time_zone_ref (GTimeZone *tz)
+ /* fake zoneinfo creation (for RFC3339/ISO 8601 timezones) {{{1 */
+ /*
+  * parses strings of the form h or hh[[:]mm[[[:]ss]]] where:
+- *  - h[h] is 0 to 23
++ *  - h[h] is 0 to 24
+  *  - mm is 00 to 59
+  *  - ss is 00 to 59
++ * If RFC8536, TIME_ is a transition time sans sign,
++ * so colons are required before mm and ss, and hh can be up to 167.
++ * See Internet RFC 8536 section 3.3.1:
++ * https://tools.ietf.org/html/rfc8536#section-3.3.1
++ * and POSIX Base Definitions 8.3 TZ rule time:
++ * https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_03
+  */
+ static gboolean
+ parse_time (const gchar *time_,
+-            gint32      *offset)
++            gint32      *offset,
++            gboolean    rfc8536)
+ {
+   if (*time_ < '0' || '9' < *time_)
+     return FALSE;
+@@ -310,7 +319,20 @@ parse_time (const gchar *time_,
+       *offset *= 10;
+       *offset += 60 * 60 * (*time_++ - '0');
+ 
+-      if (*offset > 23 * 60 * 60)
++      if (rfc8536)
++        {
++          /* Internet RFC 8536 section 3.3.1 and POSIX 8.3 TZ together say
++             that a transition time must be of the form [+-]hh[:mm[:ss]] where
++             the hours part can range from -167 to 167.  */
++          if ('0' <= *time_ && *time_ <= '9')
++            {
++              *offset *= 10;
++              *offset += 60 * 60 * (*time_++ - '0');
++            }
++          if (*offset > 167 * 60 * 60)
++            return FALSE;
++        }
++      else if (*offset > 24 * 60 * 60)
+         return FALSE;
+ 
+       if (*time_ == '\0')
+@@ -319,6 +341,8 @@ parse_time (const gchar *time_,
+ 
+   if (*time_ == ':')
+     time_++;
++  else if (rfc8536)
++    return FALSE;
+ 
+   if (*time_ < '0' || '5' < *time_)
+     return FALSE;
+@@ -335,6 +359,8 @@ parse_time (const gchar *time_,
+ 
+   if (*time_ == ':')
+     time_++;
++  else if (rfc8536)
++    return FALSE;
+ 
+   if (*time_ < '0' || '5' < *time_)
+     return FALSE;
+@@ -351,28 +377,32 @@ parse_time (const gchar *time_,
+ 
+ static gboolean
+ parse_constant_offset (const gchar *name,
+-                       gint32      *offset)
++                       gint32      *offset,
++                       gboolean    rfc8536)
+ {
+-  if (g_strcmp0 (name, "UTC") == 0)
++  /* Internet RFC 8536 section 3.3.1 and POSIX 8.3 TZ together say
++     that a transition time must be numeric.  */
++  if (!rfc8536 && g_strcmp0 (name, "UTC") == 0)
+     {
+       *offset = 0;
+       return TRUE;
+     }
+ 
+   if (*name >= '0' && '9' >= *name)
+-    return parse_time (name, offset);
++    return parse_time (name, offset, rfc8536);
+ 
+   switch (*name++)
+     {
+     case 'Z':
+       *offset = 0;
+-      return !*name;
++      /* Internet RFC 8536 section 3.3.1 requires a numeric zone.  */
++      return !rfc8536 && !*name;
+ 
+     case '+':
+-      return parse_time (name, offset);
++      return parse_time (name, offset, rfc8536);
+ 
+     case '-':
+-      if (parse_time (name, offset))
++      if (parse_time (name, offset, rfc8536))
+         {
+           *offset = -*offset;
+           return TRUE;
+@@ -391,7 +421,7 @@ zone_for_constant_offset (GTimeZone *gtz, const gchar *name)
+   gint32 offset;
+   TransitionInfo info;
+ 
+-  if (name == NULL || !parse_constant_offset (name, &offset))
++  if (name == NULL || !parse_constant_offset (name, &offset, FALSE))
+     return;
+ 
+   info.gmt_offset = offset;
+@@ -529,12 +559,17 @@ init_zone_from_iana_info (GTimeZone *gtz,
+   guint8 *tz_transitions, *tz_type_index, *tz_ttinfo;
+   guint8 *tz_abbrs;
+   gsize timesize = sizeof (gint32);
+-  const struct tzhead *header = g_bytes_get_data (zoneinfo, &size);
++  gconstpointer header_data = g_bytes_get_data (zoneinfo, &size);
++  const gchar *data = header_data;
++  const struct tzhead *header = header_data;
++  GTimeZone *footertz = NULL;
++  guint extra_time_count = 0, extra_type_count = 0;
++  gint64 last_explicit_transition_time;
+ 
+   g_return_if_fail (size >= sizeof (struct tzhead) &&
+                     memcmp (header, "TZif", 4) == 0);
+ 
+-  if (header->tzh_version == '2')
++  if (header->tzh_version >= '2')
+       {
+         /* Skip ahead to the newer 64-bit data if it's available. */
+         header = (const struct tzhead *)
+@@ -550,6 +585,30 @@ init_zone_from_iana_info (GTimeZone *gtz,
+   time_count = guint32_from_be(header->tzh_timecnt);
+   type_count = guint32_from_be(header->tzh_typecnt);
+ 
++  if (header->tzh_version >= '2')
++    {
++      const gchar *footer = (((const gchar *) (header + 1))
++                             + guint32_from_be(header->tzh_ttisgmtcnt)
++                             + guint32_from_be(header->tzh_ttisstdcnt)
++                             + 12 * guint32_from_be(header->tzh_leapcnt)
++                             + 9 * time_count
++                             + 6 * type_count
++                             + guint32_from_be(header->tzh_charcnt));
++      const gchar *footerlast;
++      size_t footerlen;
++      g_return_if_fail (footer <= data + size - 2 && footer[0] == '\n');
++      footerlast = memchr (footer + 1, '\n', data + size - (footer + 1));
++      g_return_if_fail (footerlast);
++      footerlen = footerlast + 1 - footer;
++      if (footerlen != 2)
++        {
++          footertz = parse_footertz (footer, footerlen);
++          g_return_if_fail (footertz);
++          extra_type_count = footertz->t_info->len;
++          extra_time_count = footertz->transitions->len;
++        }
++    }
++
+   tz_transitions = ((guint8 *) (header) + sizeof (*header));
+   tz_type_index = tz_transitions + timesize * time_count;
+   tz_ttinfo = tz_type_index + time_count;
+@@ -557,9 +616,9 @@ init_zone_from_iana_info (GTimeZone *gtz,
+ 
+   gtz->name = g_steal_pointer (&identifier);
+   gtz->t_info = g_array_sized_new (FALSE, TRUE, sizeof (TransitionInfo),
+-                                   type_count);
++                                   type_count + extra_type_count);
+   gtz->transitions = g_array_sized_new (FALSE, TRUE, sizeof (Transition),
+-                                        time_count);
++                                        time_count + extra_time_count);
+ 
+   for (index = 0; index < type_count; index++)
+     {
+@@ -574,15 +633,50 @@ init_zone_from_iana_info (GTimeZone *gtz,
+   for (index = 0; index < time_count; index++)
+     {
+       Transition trans;
+-      if (header->tzh_version == '2')
++      if (header->tzh_version >= '2')
+         trans.time = gint64_from_be (((gint64_be*)tz_transitions)[index]);
+       else
+         trans.time = gint32_from_be (((gint32_be*)tz_transitions)[index]);
++      last_explicit_transition_time = trans.time;
+       trans.info_index = tz_type_index[index];
+       g_assert (trans.info_index >= 0);
+       g_assert ((guint) trans.info_index < gtz->t_info->len);
+       g_array_append_val (gtz->transitions, trans);
+     }
++
++  if (footertz)
++    {
++      /* Append footer time types.  Don't bother to coalesce
++         duplicates with existing time types.  */
++      for (index = 0; index < extra_type_count; index++)
++        {
++          TransitionInfo t_info;
++          TransitionInfo *footer_t_info
++            = &g_array_index (footertz->t_info, TransitionInfo, index);
++          t_info.gmt_offset = footer_t_info->gmt_offset;
++          t_info.is_dst = footer_t_info->is_dst;
++          t_info.abbrev = g_steal_pointer (&footer_t_info->abbrev);
++          g_array_append_val (gtz->t_info, t_info);
++        }
++
++      /* Append footer transitions that follow the last explicit
++         transition.  */
++      for (index = 0; index < extra_time_count; index++)
++        {
++          Transition *footer_transition
++            = &g_array_index (footertz->transitions, Transition, index);
++          if (time_count <= 0
++              || last_explicit_transition_time < footer_transition->time)
++            {
++              Transition trans;
++              trans.time = footer_transition->time;
++              trans.info_index = type_count + footer_transition->info_index;
++              g_array_append_val (gtz->transitions, trans);
++            }
++        }
++
++      g_time_zone_unref (footertz);
++    }
+ }
+ 
+ #elif defined (G_OS_WIN32)
+@@ -590,9 +684,8 @@ init_zone_from_iana_info (GTimeZone *gtz,
+ static void
+ copy_windows_systemtime (SYSTEMTIME *s_time, TimeZoneDate *tzdate)
+ {
+-  tzdate->sec = s_time->wSecond;
+-  tzdate->min = s_time->wMinute;
+-  tzdate->hour = s_time->wHour;
++  tzdate->offset
++    = s_time->wHour * 3600 + s_time->wMinute * 60 + s_time->wSecond;
+   tzdate->mon = s_time->wMonth;
+   tzdate->year = s_time->wYear;
+   tzdate->wday = s_time->wDayOfWeek ? s_time->wDayOfWeek : 7;
+@@ -979,7 +1072,7 @@ boundary_for_year (TimeZoneDate *boundary,
+   g_date_clear (&date, 1);
+   g_date_set_dmy (&date, buffer.mday, buffer.mon, buffer.year);
+   return ((g_date_get_julian (&date) - unix_epoch_start) * seconds_per_day +
+-          buffer.hour * 3600 + buffer.min * 60 + buffer.sec - offset);
++          buffer.offset - offset);
+ }
+ 
+ static void
+@@ -1156,7 +1249,7 @@ init_zone_from_rules (GTimeZone    *gtz,
+  * - N is 0 to 365
+  *
+  * time is either h or hh[[:]mm[[[:]ss]]]
+- *  - h[h] is 0 to 23
++ *  - h[h] is 0 to 24
+  *  - mm is 00 to 59
+  *  - ss is 00 to 59
+  */
+@@ -1289,25 +1382,10 @@ parse_tz_boundary (const gchar  *identifier,
+   /* Time */
+ 
+   if (*pos == '/')
+-    {
+-      gint32 offset;
+-
+-      if (!parse_time (++pos, &offset))
+-        return FALSE;
+-
+-      boundary->hour = offset / 3600;
+-      boundary->min = (offset / 60) % 60;
+-      boundary->sec = offset % 3600;
+-
+-      return TRUE;
+-    }
+-
++    return parse_constant_offset (pos + 1, &boundary->offset, TRUE);
+   else
+     {
+-      boundary->hour = 2;
+-      boundary->min = 0;
+-      boundary->sec = 0;
+-
++      boundary->offset = 2 * 60 * 60;
+       return *pos == '\0';
+     }
+ }
+@@ -1341,7 +1419,7 @@ parse_offset (gchar **pos, gint32 *target)
+     ++(*pos);
+ 
+   buffer = g_strndup (target_pos, *pos - target_pos);
+-  ret = parse_constant_offset (buffer, target);
++  ret = parse_constant_offset (buffer, target, FALSE);
+   g_free (buffer);
+ 
+   return ret;
+@@ -1366,21 +1444,32 @@ parse_identifier_boundary (gchar **pos, TimeZoneDate *target)
+ static gboolean
+ set_tz_name (gchar **pos, gchar *buffer, guint size)
+ {
++  gboolean quoted = **pos == '<';
+   gchar *name_pos = *pos;
+   guint len;
+ 
+-  /* Name is ASCII alpha (Is this necessarily true?) */
+-  while (g_ascii_isalpha (**pos))
+-    ++(*pos);
++  if (quoted)
++    {
++      name_pos++;
++      do
++        ++(*pos);
++      while (g_ascii_isalnum (**pos) || **pos == '-' || **pos == '+');
++      if (**pos != '>')
++        return FALSE;
++    }
++  else
++    while (g_ascii_isalpha (**pos))
++      ++(*pos);
+ 
+-  /* Name should be three or more alphabetic characters */
++  /* Name should be three or more characters */
+   if (*pos - name_pos < 3)
+     return FALSE;
+ 
+-  memset (buffer, 0, NAME_SIZE);
++  memset (buffer, 0, size);
+   /* name_pos isn't 0-terminated, so we have to limit the length expressly */
+   len = *pos - name_pos > size - 1 ? size - 1 : *pos - name_pos;
+   strncpy (buffer, name_pos, len);
++  *pos += quoted;
+   return TRUE;
+ }
+ 
+@@ -1483,6 +1572,28 @@ rules_from_identifier (const gchar   *identifier,
+   return create_ruleset_from_rule (rules, &tzr);
+ }
+ 
++#ifdef G_OS_UNIX
++static GTimeZone *
++parse_footertz (const gchar *footer, size_t footerlen)
++{
++  gchar *tzstring = g_strndup (footer + 1, footerlen - 2);
++  GTimeZone *footertz = NULL;
++  gchar *ident;
++  TimeZoneRule *rules;
++  guint rules_num = rules_from_identifier (tzstring, &ident, &rules);
++  g_free (ident);
++  g_free (tzstring);
++  if (rules_num > 1)
++    {
++      footertz = g_slice_new0 (GTimeZone);
++      init_zone_from_rules (footertz, rules, rules_num, NULL);
++      footertz->ref_count++;
++    }
++  g_free (rules);
++  return footertz;
++}
++#endif
++
+ /* Construction {{{1 */
+ /**
+  * g_time_zone_new:
diff --git a/poky/meta/recipes-core/glib-2.0/glib-2.0_2.64.5.bb b/poky/meta/recipes-core/glib-2.0/glib-2.0_2.64.5.bb
index a1233e6..a30c521 100644
--- a/poky/meta/recipes-core/glib-2.0/glib-2.0_2.64.5.bb
+++ b/poky/meta/recipes-core/glib-2.0/glib-2.0_2.64.5.bb
@@ -16,6 +16,7 @@
            file://0001-Do-not-write-bindir-into-pkg-config-files.patch \
            file://0001-meson-Run-atomics-test-on-clang-as-well.patch \
            file://0001-gio-tests-resources.c-comment-out-a-build-host-only-.patch \
+           file://tzdata-update.patch \
            "
 
 SRC_URI_append_class-native = " file://relocate-modules.patch"
diff --git a/poky/meta/recipes-core/images/build-appliance-image_15.0.0.bb b/poky/meta/recipes-core/images/build-appliance-image_15.0.0.bb
index 8be6171..8390b83 100644
--- a/poky/meta/recipes-core/images/build-appliance-image_15.0.0.bb
+++ b/poky/meta/recipes-core/images/build-appliance-image_15.0.0.bb
@@ -24,7 +24,7 @@
 
 inherit core-image module-base setuptools3
 
-SRCREV ?= "20586411649fcad6f0459ce74a581374ab564737"
+SRCREV ?= "1dfd37d30953208fd998cef79483f371330a754e"
 SRC_URI = "git://git.yoctoproject.org/poky \
            file://Yocto_Build_Appliance.vmx \
            file://Yocto_Build_Appliance.vmxf \
diff --git a/poky/meta/recipes-core/ncurses/ncurses_6.2.bb b/poky/meta/recipes-core/ncurses/ncurses_6.2.bb
index 5c02db8..f3c84c2 100644
--- a/poky/meta/recipes-core/ncurses/ncurses_6.2.bb
+++ b/poky/meta/recipes-core/ncurses/ncurses_6.2.bb
@@ -7,7 +7,7 @@
 SRCREV = "a669013cd5e9d6434e5301348ea51baf306c93c4"
 S = "${WORKDIR}/git"
 EXTRA_OECONF += "--with-abi-version=5"
-UPSTREAM_CHECK_GITTAGREGEX = "(?P<pver>\d+(\.\d+)+(\+\d+)*)"
+UPSTREAM_CHECK_GITTAGREGEX = "(?P<pver>\d+(\.\d+)+)$"
 
 # This is needed when using patchlevel versions like 6.1+20181013
 #CVE_VERSION = "${@d.getVar("PV").split('+')[0]}.${@d.getVar("PV").split('+')[1]}"
diff --git a/poky/meta/recipes-core/packagegroups/packagegroup-core-tools-debug.bb b/poky/meta/recipes-core/packagegroups/packagegroup-core-tools-debug.bb
index 283c1f1..542a020 100644
--- a/poky/meta/recipes-core/packagegroups/packagegroup-core-tools-debug.bb
+++ b/poky/meta/recipes-core/packagegroups/packagegroup-core-tools-debug.bb
@@ -14,7 +14,7 @@
 MTRACE_libc-glibc = "libc-mtrace"
 
 STRACE = "strace"
-STRACE_riscv32_libc-musl = ""
+STRACE_riscv32 = ""
 
 RDEPENDS_${PN} = "\
     gdb \
diff --git a/poky/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb b/poky/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb
index d437e28..b8e2c71 100644
--- a/poky/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb
+++ b/poky/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb
@@ -29,6 +29,7 @@
 PERF = "perf"
 PERF_libc-musl = ""
 PERF_libc-musl_arm = "perf"
+PERF_riscv32 = ""
 
 # systemtap needs elfutils which is not fully buildable on some arches/libcs
 SYSTEMTAP = "systemtap"
@@ -38,7 +39,7 @@
 
 LTTNGTOOLS = "lttng-tools"
 LTTNGTOOLS_arc = ""
-LTTNGTOOLS_riscv32_libc-musl = ""
+LTTNGTOOLS_riscv32 = ""
 
 BABELTRACE = "babeltrace"
 BABELTRACE2 = "babeltrace2"
diff --git a/poky/meta/recipes-devtools/python/python3_3.8.5.bb b/poky/meta/recipes-devtools/python/python3_3.8.5.bb
index cabe5dc..2a3c52a 100644
--- a/poky/meta/recipes-devtools/python/python3_3.8.5.bb
+++ b/poky/meta/recipes-devtools/python/python3_3.8.5.bb
@@ -45,6 +45,7 @@
 
 # exclude pre-releases for both python 2.x and 3.x
 UPSTREAM_CHECK_REGEX = "[Pp]ython-(?P<pver>\d+(\.\d+)+).tar"
+UPSTREAM_CHECK_URI = "https://www.python.org/downloads/source/"
 
 CVE_PRODUCT = "python"
 
diff --git a/poky/meta/recipes-devtools/qemu/qemu.inc b/poky/meta/recipes-devtools/qemu/qemu.inc
index 6c0edcb..84f600c 100644
--- a/poky/meta/recipes-devtools/qemu/qemu.inc
+++ b/poky/meta/recipes-devtools/qemu/qemu.inc
@@ -31,7 +31,7 @@
            file://0001-qemu-Do-not-include-file-if-not-exists.patch \
            file://find_datadir.patch \
            file://usb-fix-setup_len-init.patch \
-           file://0001-mips-add-34Kf-64tlb-fictitious-cpu-type-like-34Kf-bu.patch \
+           file://0001-target-mips-Increase-number-of-TLB-entries-on-the-34.patch \
            "
 UPSTREAM_CHECK_REGEX = "qemu-(?P<pver>\d+(\.\d+)+)\.tar"
 
diff --git a/poky/meta/recipes-devtools/qemu/qemu/0001-mips-add-34Kf-64tlb-fictitious-cpu-type-like-34Kf-bu.patch b/poky/meta/recipes-devtools/qemu/qemu/0001-mips-add-34Kf-64tlb-fictitious-cpu-type-like-34Kf-bu.patch
deleted file mode 100644
index b6312e1..0000000
--- a/poky/meta/recipes-devtools/qemu/qemu/0001-mips-add-34Kf-64tlb-fictitious-cpu-type-like-34Kf-bu.patch
+++ /dev/null
@@ -1,118 +0,0 @@
-From b3fcc7d96523ad8e3ea28c09d495ef08529d01ce Mon Sep 17 00:00:00 2001
-From: Victor Kamensky <kamensky@cisco.com>
-Date: Wed, 7 Oct 2020 10:19:42 -0700
-Subject: [PATCH] mips: add 34Kf-64tlb fictitious cpu type like 34Kf but with
- 64 TLBs
-
-In Yocto Project CI runs it was observed that test run
-of 32 bit mips image takes almost twice longer than 64 bit
-mips image with the same logical load and CI execution
-hits timeout.
-
-See https://bugzilla.yoctoproject.org/show_bug.cgi?id=13992
-
-Yocto project uses 34Kf cpu type to run 32 bit mips image,
-and MIPS64R2-generic cpu type to run 64 bit mips64 image.
-
-Upon qemu behavior differences investigation between mips
-and mips64 two prominent observations came up: under
-logically similar load (same definition and configuration
-of user-land image) in case of mips get_physical_address
-function is called almost twice more often, meaning
-twice more memory accesses involved in this case. Also
-number of tlbwr instruction executed (r4k_helper_tlbwr
-qemu function) almost 16 time bigger in mips case than in
-mips64.
-
-It turns out that 34Kf cpu has 16 TLBs, but in case of
-MIPS64R2-generic it is 64 TLBs. So that explains why
-some many more tlbwr had to be execute by kernel TLB refill
-handler in case of 32 bit misp.
-
-The idea of the fix is to come up with new 34Kf-64tlb fictitious
-cpu type, that would behave exactly as 34Kf but it would
-contain 64 TLBs to reduce TLB trashing. After all, adding
-more TLBs to soft mmu is easy.
-
-Experiment with some significant non-trvial load in Yocto
-environment by running do_testimage load shows that 34Kf-64tlb
-cpu performs 40% or so better than original 34Kf cpu wrt test
-execution real time.
-
-It is not ideal to have cpu type that does not exist in the
-wild but given performance gains it seems to be justified.
-
-Signed-off-by: Victor Kamensky <kamensky@cisco.com>
----
- target/mips/translate_init.inc.c | 55 ++++++++++++++++++++++++++++++++++++++++
- 1 file changed, 55 insertions(+)
-
-diff --git a/target/mips/translate_init.inc.c b/target/mips/translate_init.inc.c
-index 637caccd89..b73ab48231 100644
---- a/target/mips/translate_init.inc.c
-+++ b/target/mips/translate_init.inc.c
-@@ -297,6 +297,61 @@ const mips_def_t mips_defs[] =
-         .insn_flags = CPU_MIPS32R2 | ASE_MIPS16 | ASE_DSP | ASE_MT,
-         .mmu_type = MMU_TYPE_R4000,
-     },
-+    /*
-+     * Verbatim copy of "34Kf" cpu, only bumped up number of TLB entries
-+     * from 16 to 64 (see CP0_Config0 value at CP0C1_MMU bits) to improve
-+     * performance by reducing number of TLB refill exceptions and
-+     * eliminating need to run all corresponding TLB refill handling
-+     * instructions.
-+     */
-+    {
-+        .name = "34Kf-64tlb",
-+        .CP0_PRid = 0x00019500,
-+        .CP0_Config0 = MIPS_CONFIG0 | (0x1 << CP0C0_AR) |
-+                       (MMU_TYPE_R4000 << CP0C0_MT),
-+        .CP0_Config1 = MIPS_CONFIG1 | (1 << CP0C1_FP) | (63 << CP0C1_MMU) |
-+                       (0 << CP0C1_IS) | (3 << CP0C1_IL) | (1 << CP0C1_IA) |
-+                       (0 << CP0C1_DS) | (3 << CP0C1_DL) | (1 << CP0C1_DA) |
-+                       (1 << CP0C1_CA),
-+        .CP0_Config2 = MIPS_CONFIG2,
-+        .CP0_Config3 = MIPS_CONFIG3 | (1 << CP0C3_VInt) | (1 << CP0C3_MT) |
-+                       (1 << CP0C3_DSPP),
-+        .CP0_LLAddr_rw_bitmask = 0,
-+        .CP0_LLAddr_shift = 0,
-+        .SYNCI_Step = 32,
-+        .CCRes = 2,
-+        .CP0_Status_rw_bitmask = 0x3778FF1F,
-+        .CP0_TCStatus_rw_bitmask = (0 << CP0TCSt_TCU3) | (0 << CP0TCSt_TCU2) |
-+                    (1 << CP0TCSt_TCU1) | (1 << CP0TCSt_TCU0) |
-+                    (0 << CP0TCSt_TMX) | (1 << CP0TCSt_DT) |
-+                    (1 << CP0TCSt_DA) | (1 << CP0TCSt_A) |
-+                    (0x3 << CP0TCSt_TKSU) | (1 << CP0TCSt_IXMT) |
-+                    (0xff << CP0TCSt_TASID),
-+        .CP1_fcr0 = (1 << FCR0_F64) | (1 << FCR0_L) | (1 << FCR0_W) |
-+                    (1 << FCR0_D) | (1 << FCR0_S) | (0x95 << FCR0_PRID),
-+        .CP1_fcr31 = 0,
-+        .CP1_fcr31_rw_bitmask = 0xFF83FFFF,
-+        .CP0_SRSCtl = (0xf << CP0SRSCtl_HSS),
-+        .CP0_SRSConf0_rw_bitmask = 0x3fffffff,
-+        .CP0_SRSConf0 = (1U << CP0SRSC0_M) | (0x3fe << CP0SRSC0_SRS3) |
-+                    (0x3fe << CP0SRSC0_SRS2) | (0x3fe << CP0SRSC0_SRS1),
-+        .CP0_SRSConf1_rw_bitmask = 0x3fffffff,
-+        .CP0_SRSConf1 = (1U << CP0SRSC1_M) | (0x3fe << CP0SRSC1_SRS6) |
-+                    (0x3fe << CP0SRSC1_SRS5) | (0x3fe << CP0SRSC1_SRS4),
-+        .CP0_SRSConf2_rw_bitmask = 0x3fffffff,
-+        .CP0_SRSConf2 = (1U << CP0SRSC2_M) | (0x3fe << CP0SRSC2_SRS9) |
-+                    (0x3fe << CP0SRSC2_SRS8) | (0x3fe << CP0SRSC2_SRS7),
-+        .CP0_SRSConf3_rw_bitmask = 0x3fffffff,
-+        .CP0_SRSConf3 = (1U << CP0SRSC3_M) | (0x3fe << CP0SRSC3_SRS12) |
-+                    (0x3fe << CP0SRSC3_SRS11) | (0x3fe << CP0SRSC3_SRS10),
-+        .CP0_SRSConf4_rw_bitmask = 0x3fffffff,
-+        .CP0_SRSConf4 = (0x3fe << CP0SRSC4_SRS15) |
-+                    (0x3fe << CP0SRSC4_SRS14) | (0x3fe << CP0SRSC4_SRS13),
-+        .SEGBITS = 32,
-+        .PABITS = 32,
-+        .insn_flags = CPU_MIPS32R2 | ASE_MIPS16 | ASE_DSP | ASE_MT,
-+        .mmu_type = MMU_TYPE_R4000,
-+    },
-     {
-         .name = "74Kf",
-         .CP0_PRid = 0x00019700,
--- 
-2.14.5
-
diff --git a/poky/meta/recipes-devtools/qemu/qemu/0001-target-mips-Increase-number-of-TLB-entries-on-the-34.patch b/poky/meta/recipes-devtools/qemu/qemu/0001-target-mips-Increase-number-of-TLB-entries-on-the-34.patch
new file mode 100644
index 0000000..5227b7c
--- /dev/null
+++ b/poky/meta/recipes-devtools/qemu/qemu/0001-target-mips-Increase-number-of-TLB-entries-on-the-34.patch
@@ -0,0 +1,59 @@
+From 68fa519a6cb455005317bd61f95214b58b2f1e69 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <f4bug@amsat.org>
+Date: Fri, 16 Oct 2020 15:20:37 +0200
+Subject: [PATCH] target/mips: Increase number of TLB entries on the 34Kf core
+ (16 -> 64)
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Per "MIPS32 34K Processor Core Family Software User's Manual,
+Revision 01.13" page 8 in "Joint TLB (JTLB)" section:
+
+  "The JTLB is a fully associative TLB cache containing 16, 32,
+   or 64-dual-entries mapping up to 128 virtual pages to their
+   corresponding physical addresses."
+
+There is no particular reason to restrict the 34Kf core model to
+16 TLB entries, so raise its config to 64.
+
+This is helpful for other projects, in particular the Yocto Project:
+
+  Yocto Project uses qemu-system-mips 34Kf cpu model, to run 32bit
+  MIPS CI loop. It was observed that in this case CI test execution
+  time was almost twice longer than 64bit MIPS variant that runs
+  under MIPS64R2-generic model. It was investigated and concluded
+  that the difference in number of TLBs 16 in 34Kf case vs 64 in
+  MIPS64R2-generic is responsible for most of CI real time execution
+  difference. Because with 16 TLBs linux user-land trashes TLB more
+  and it needs to execute more instructions in TLB refill handler
+  calls, as result it runs much longer.
+
+(https://lists.gnu.org/archive/html/qemu-devel/2020-10/msg03428.html)
+
+Buglink: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13992
+Reported-by: Victor Kamensky <kamensky@cisco.com>
+Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
+Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
+Message-Id: <20201016133317.553068-1-f4bug@amsat.org>
+
+Upstream-Status: Backport [https://github.com/qemu/qemu/commit/68fa519a6cb455005317bd61f95214b58b2f1e69]
+Signed-off-by: Victor Kamensky <kamensky@cisco.com>
+
+---
+ target/mips/translate_init.c.inc | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+Index: qemu-5.1.0/target/mips/translate_init.inc.c
+===================================================================
+--- qemu-5.1.0.orig/target/mips/translate_init.inc.c
++++ qemu-5.1.0/target/mips/translate_init.inc.c
+@@ -254,7 +254,7 @@ const mips_def_t mips_defs[] =
+         .CP0_PRid = 0x00019500,
+         .CP0_Config0 = MIPS_CONFIG0 | (0x1 << CP0C0_AR) |
+                        (MMU_TYPE_R4000 << CP0C0_MT),
+-        .CP0_Config1 = MIPS_CONFIG1 | (1 << CP0C1_FP) | (15 << CP0C1_MMU) |
++        .CP0_Config1 = MIPS_CONFIG1 | (1 << CP0C1_FP) | (63 << CP0C1_MMU) |
+                        (0 << CP0C1_IS) | (3 << CP0C1_IL) | (1 << CP0C1_IA) |
+                        (0 << CP0C1_DS) | (3 << CP0C1_DL) | (1 << CP0C1_DA) |
+                        (1 << CP0C1_CA),
diff --git a/poky/meta/recipes-devtools/tcltk/tcl_8.6.10.bb b/poky/meta/recipes-devtools/tcltk/tcl_8.6.10.bb
index aedd96b..e6feb25 100644
--- a/poky/meta/recipes-devtools/tcltk/tcl_8.6.10.bb
+++ b/poky/meta/recipes-devtools/tcltk/tcl_8.6.10.bb
@@ -32,6 +32,7 @@
 
 S = "${WORKDIR}/${BPN}${PV}/unix"
 
+PSEUDO_IGNORE_PATHS .= ",${WORKDIR}/${BPN}${PV}"
 VER = "${PV}"
 
 inherit autotools ptest binconfig update-alternatives
diff --git a/poky/meta/recipes-devtools/valgrind/valgrind/0001-drd-Port-to-Fedora-33.patch b/poky/meta/recipes-devtools/valgrind/valgrind/0001-drd-Port-to-Fedora-33.patch
new file mode 100644
index 0000000..37f6ea6
--- /dev/null
+++ b/poky/meta/recipes-devtools/valgrind/valgrind/0001-drd-Port-to-Fedora-33.patch
@@ -0,0 +1,48 @@
+From 15330adf7c2471fbaa6a0818db07078d81dbff97 Mon Sep 17 00:00:00 2001
+From: Bart Van Assche <bvanassche@acm.org>
+Date: Sat, 19 Sep 2020 08:08:59 -0700
+Subject: [PATCH] drd: Port to Fedora 33
+
+Apparently on Fedora 33 the POSIX thread functions exist in both libc and
+libpthread. Hence this patch that intercepts the pthread functions in
+libc. See also https://bugs.kde.org/show_bug.cgi?id=426144 .
+
+Signed-off-by: Bart Van Assche <bvanassche@acm.org>
+
+This patch was imported from the valgrind sourceware server
+(https://sourceware.org/git/?p=valgrind.git;a=commit;h=15330adf7c2471fbaa6a0818db07078d81dbff97)
+It was modified to remove the changes to the valgrind NEWS file,
+as these are difficult to maintain and don't impact the valgrind 
+code itself.
+
+Upstream-Status: Backport
+
+Signed-off-by: Stacy Gaikovaia <stacy.gaikovaia@windriver.com>
+---
+ drd/drd_pthread_intercepts.c | 9 +++++++++
+ 1 file changed, 10 insertions(+)
+
+diff --git a/drd/drd_pthread_intercepts.c b/drd/drd_pthread_intercepts.c
+index 58c45aaec..c2882e5ab 100644
+--- a/drd/drd_pthread_intercepts.c
++++ b/drd/drd_pthread_intercepts.c
+@@ -174,7 +174,16 @@ static int never_true;
+    ret_ty VG_WRAP_FUNCTION_ZZ(VG_Z_LIBC_SONAME,zf) argl_decl            \
+    { return implf argl; }
+ #else
++/*
++ * On Linux, intercept both the libc and the libpthread functions. At
++ * least glibc 2.32.9000 (Fedora 34) has an implementation of all pthread
++ * functions in both libc and libpthread. Older glibc versions only have an
++ * implementation of the pthread functions in libpthread.
++ */
+ #define PTH_FUNC(ret_ty, zf, implf, argl_decl, argl)                    \
++   ret_ty VG_WRAP_FUNCTION_ZZ(VG_Z_LIBC_SONAME,zf) argl_decl;           \
++   ret_ty VG_WRAP_FUNCTION_ZZ(VG_Z_LIBC_SONAME,zf) argl_decl            \
++   { return implf argl; }                                               \
+    ret_ty VG_WRAP_FUNCTION_ZZ(VG_Z_LIBPTHREAD_SONAME,zf) argl_decl;     \
+    ret_ty VG_WRAP_FUNCTION_ZZ(VG_Z_LIBPTHREAD_SONAME,zf) argl_decl      \
+    { return implf argl; }
+-- 
+2.25.1
+
diff --git a/poky/meta/recipes-devtools/valgrind/valgrind/0001-drd-musl-fix.patch b/poky/meta/recipes-devtools/valgrind/valgrind/0001-drd-musl-fix.patch
new file mode 100644
index 0000000..e96bf3c
--- /dev/null
+++ b/poky/meta/recipes-devtools/valgrind/valgrind/0001-drd-musl-fix.patch
@@ -0,0 +1,31 @@
+The changes in 0001-drd-Port-to-Fedora-33.patch break builds on musl. These
+need a __GLIBC__ guard to ensure musl builds continue to work.
+
+Upstream-Status: Pending
+Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
+
+Index: valgrind-3.16.1/drd/drd_pthread_intercepts.c
+===================================================================
+--- valgrind-3.16.1.orig/drd/drd_pthread_intercepts.c
++++ valgrind-3.16.1/drd/drd_pthread_intercepts.c
+@@ -180,6 +180,7 @@ static int never_true;
+  * functions in both libc and libpthread. Older glibc versions only have an
+  * implementation of the pthread functions in libpthread.
+  */
++#ifdef __GLIBC__
+ #define PTH_FUNC(ret_ty, zf, implf, argl_decl, argl)                    \
+    ret_ty VG_WRAP_FUNCTION_ZZ(VG_Z_LIBC_SONAME,zf) argl_decl;           \
+    ret_ty VG_WRAP_FUNCTION_ZZ(VG_Z_LIBC_SONAME,zf) argl_decl            \
+@@ -187,6 +188,12 @@ static int never_true;
+    ret_ty VG_WRAP_FUNCTION_ZZ(VG_Z_LIBPTHREAD_SONAME,zf) argl_decl;     \
+    ret_ty VG_WRAP_FUNCTION_ZZ(VG_Z_LIBPTHREAD_SONAME,zf) argl_decl      \
+    { return implf argl; }
++#else
++#define PTH_FUNC(ret_ty, zf, implf, argl_decl, argl)                    \
++   ret_ty VG_WRAP_FUNCTION_ZZ(VG_Z_LIBPTHREAD_SONAME,zf) argl_decl;     \
++   ret_ty VG_WRAP_FUNCTION_ZZ(VG_Z_LIBPTHREAD_SONAME,zf) argl_decl      \
++   { return implf argl; }
++#endif
+ #endif
+ 
+ /**
diff --git a/poky/meta/recipes-devtools/valgrind/valgrind_3.16.1.bb b/poky/meta/recipes-devtools/valgrind/valgrind_3.16.1.bb
index d4ca1a7..bcba55f 100644
--- a/poky/meta/recipes-devtools/valgrind/valgrind_3.16.1.bb
+++ b/poky/meta/recipes-devtools/valgrind/valgrind_3.16.1.bb
@@ -40,6 +40,8 @@
            file://s390x_vec_op_t.patch \
            file://0001-none-tests-fdleak_cmsg.stderr.exp-adjust-tmp-paths.patch \
            file://0001-memcheck-tests-Fix-timerfd-syscall-test.patch \
+           file://0001-drd-Port-to-Fedora-33.patch \
+           file://0001-drd-musl-fix.patch \
            "
 SRC_URI[md5sum] = "d1b153f1ab17cf1f311705e7a83ef589"
 SRC_URI[sha256sum] = "c91f3a2f7b02db0f3bc99479861656154d241d2fdb265614ba918cc6720a33ca"
diff --git a/poky/meta/recipes-extended/cups/cups.inc b/poky/meta/recipes-extended/cups/cups.inc
index 1765944..87870e4 100644
--- a/poky/meta/recipes-extended/cups/cups.inc
+++ b/poky/meta/recipes-extended/cups/cups.inc
@@ -47,6 +47,7 @@
                --enable-debug \
                --disable-relro \
                --enable-libusb \
+               --with-domainsocket=/run/cups/cups.sock \
                DSOFLAGS='${LDFLAGS}' \
                "
 
diff --git a/poky/meta/recipes-extended/watchdog/watchdog/0001-wd_keepalive.service-use-run-instead-of-var-run.patch b/poky/meta/recipes-extended/watchdog/watchdog/0001-wd_keepalive.service-use-run-instead-of-var-run.patch
new file mode 100644
index 0000000..5c5d2f4
--- /dev/null
+++ b/poky/meta/recipes-extended/watchdog/watchdog/0001-wd_keepalive.service-use-run-instead-of-var-run.patch
@@ -0,0 +1,30 @@
+From b5cb6166dbfa57d1d94b19d4a098991a817f68f5 Mon Sep 17 00:00:00 2001
+From: Chen Qi <Qi.Chen@windriver.com>
+Date: Thu, 15 Oct 2020 10:02:17 +0800
+Subject: [PATCH] wd_keepalive.service: use /run instead of /var/run
+
+/var/run is deprecated by systemd, use /run instead.
+
+Upstream-Status: Pending
+
+Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
+---
+ debian/wd_keepalive.service | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/debian/wd_keepalive.service b/debian/wd_keepalive.service
+index 7f8b1dc..0f2a153 100644
+--- a/debian/wd_keepalive.service
++++ b/debian/wd_keepalive.service
+@@ -7,7 +7,7 @@ Type=forking
+ EnvironmentFile=/etc/default/watchdog
+ ExecStartPre=/bin/sh -c '[ -z "${watchdog_module}" ] || [ "${watchdog_module}" = "none" ] || /sbin/modprobe $watchdog_module'
+ ExecStart=/usr/sbin/wd_keepalive $watchdog_options
+-PIDFile=/var/run/wd_keepalive.pid
++PIDFile=/run/wd_keepalive.pid
+ 
+ [Install]
+ WantedBy=multi-user.target
+-- 
+2.17.1
+
diff --git a/poky/meta/recipes-extended/watchdog/watchdog_5.16.bb b/poky/meta/recipes-extended/watchdog/watchdog_5.16.bb
index 0199487..1988952 100644
--- a/poky/meta/recipes-extended/watchdog/watchdog_5.16.bb
+++ b/poky/meta/recipes-extended/watchdog/watchdog_5.16.bb
@@ -12,6 +12,7 @@
            file://0001-watchdog-remove-interdependencies-of-watchdog-and-wd.patch \
            file://watchdog.init \
            file://wd_keepalive.init \
+           file://0001-wd_keepalive.service-use-run-instead-of-var-run.patch \
 "
 
 SRC_URI[md5sum] = "1b4f51cabc64d1bee2fce7cdd626831f"
diff --git a/poky/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.40.0.bb b/poky/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.40.0.bb
index 0405fa7..3dec5ed 100644
--- a/poky/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.40.0.bb
+++ b/poky/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.40.0.bb
@@ -5,7 +5,7 @@
 HOMEPAGE = "https://wiki.gnome.org/Projects/GdkPixbuf"
 BUGTRACKER = "https://gitlab.gnome.org/GNOME/gdk-pixbuf/issues"
 
-LICENSE = "LGPLv2.1"
+LICENSE = "LGPLv2.1+"
 LIC_FILES_CHKSUM = "file://COPYING;md5=4fbd65380cdd255951079008b364516c \
                     file://gdk-pixbuf/gdk-pixbuf.h;endline=26;md5=72b39da7cbdde2e665329fef618e1d6b \
                     "
diff --git a/poky/meta/recipes-graphics/harfbuzz/harfbuzz/version-race.patch b/poky/meta/recipes-graphics/harfbuzz/harfbuzz/version-race.patch
index 2d692f3..a8b8f03 100644
--- a/poky/meta/recipes-graphics/harfbuzz/harfbuzz/version-race.patch
+++ b/poky/meta/recipes-graphics/harfbuzz/harfbuzz/version-race.patch
@@ -1,24 +1,35 @@
-Upstream-Status: Backport [https://github.com/harfbuzz/harfbuzz/commit/5aff83104e03d6d2617987d24a51e490ab7a5cd1]
-Signed-off-by: Ross Burton <ross.burton@arm.com>
-
-From bc1c93fbe04459a4b12c76c713ba1b750d2d9108 Mon Sep 17 00:00:00 2001
-From: Ross Burton <ross.burton@arm.com>
-Date: Mon, 7 Sep 2020 17:11:17 +0100
-Subject: [PATCH 1/2] [build] No need to pass source directory to
- gen-hb-version
+From 6ccadec1fae6a73749b7dfe2311f71d0e610e812 Mon Sep 17 00:00:00 2001
+From: Zang Ruochen <zangrc.fnst@cn.fujitsu.com>
+Date: Wed, 30 Sep 2020 10:30:08 +0900
+Subject: [PATCH] No need to pass source directory to gen-hb-version
 
 The input file is by definition in the source directory, so dirname()
 that instead of needing the directory to be passed.
 
 Needed because a follow-up commit will change when this is called, and the
 source directory isn't trivially available at that point.
+
+generate hb-version.h once at configure time with Meson
+
+Currently with Meson hb-version.h is generated during the build without
+any explicit dependencies which can result in build failures due races
+over the file.
+
+Change this to be generated at configure time, so that the file is always
+generated once before the build itself.
+
+Closes #2667
+
+Upstream-Status: Backport [https://github.com/harfbuzz/harfbuzz/commit/5aff83104e03d6d2617987d24a51e490ab7a5cd1]
+Signed-off-by: Ross Burton <ross.burton@arm.com>
+Signed-off-by: Zang Ruochen <zangrc.fnst@cn.fujitsu.com>
 ---
- src/gen-hb-version.py | 6 +++---
- src/meson.build       | 2 +-
- 2 files changed, 4 insertions(+), 4 deletions(-)
+ src/gen-hb-version.py |  6 +++---
+ src/meson.build       | 17 ++++++++---------
+ 2 files changed, 11 insertions(+), 12 deletions(-)
 
 diff --git a/src/gen-hb-version.py b/src/gen-hb-version.py
-index 15e56b93..bf16f88a 100755
+index 15e56b9..bf16f88 100755
 --- a/src/gen-hb-version.py
 +++ b/src/gen-hb-version.py
 @@ -4,15 +4,15 @@
@@ -41,42 +52,7 @@
  with open (INPUT, "r", encoding='utf-8') as template:
  	with open (OUTPUT, "wb") as output:
 diff --git a/src/meson.build b/src/meson.build
-index 5d7cd578..2d78c992 100644
---- a/src/meson.build
-+++ b/src/meson.build
-@@ -286,7 +286,7 @@ custom_target('hb-version.h',
-   input: 'hb-version.h.in',
-   output: 'hb-version.h',
-   command: [find_program('gen-hb-version.py'), meson.project_version(),
--            '@OUTPUT@', '@CURRENT_SOURCE_DIR@', '@INPUT@'],
-+            '@OUTPUT@', '@INPUT@'],
- )
- 
- ragel = find_program('ragel', required: false)
--- 
-2.28.0
-
-
-From 5aff83104e03d6d2617987d24a51e490ab7a5cd1 Mon Sep 17 00:00:00 2001
-From: Ross Burton <ross.burton@arm.com>
-Date: Mon, 7 Sep 2020 10:55:33 +0100
-Subject: [PATCH 2/2] [build] generate hb-version.h once at configure time with
- Meson
-
-Currently with Meson hb-version.h is generated during the build without
-any explicit dependencies which can result in build failures due races
-over the file.
-
-Change this to be generated at configure time, so that the file is always
-generated once before the build itself.
-
-Closes #2667
----
- src/meson.build | 17 ++++++++---------
- 1 file changed, 8 insertions(+), 9 deletions(-)
-
-diff --git a/src/meson.build b/src/meson.build
-index 2d78c992..19290245 100644
+index 5e1787c..56d8ae2 100644
 --- a/src/meson.build
 +++ b/src/meson.build
 @@ -1,3 +1,10 @@
@@ -110,12 +86,12 @@
 -  input: 'hb-version.h.in',
 -  output: 'hb-version.h',
 -  command: [find_program('gen-hb-version.py'), meson.project_version(),
--            '@OUTPUT@', '@INPUT@'],
+-            '@OUTPUT@', '@CURRENT_SOURCE_DIR@', '@INPUT@'],
 -)
 -
  ragel = find_program('ragel', required: false)
  if not ragel.found()
    warning('You have to install ragel if you are going to develop HarfBuzz itself')
 -- 
-2.28.0
+2.25.1
 
diff --git a/poky/meta/recipes-graphics/mesa/files/0001-futex.h-Define-__NR_futex-if-it-does-not-exist.patch b/poky/meta/recipes-graphics/mesa/files/0001-futex.h-Define-__NR_futex-if-it-does-not-exist.patch
new file mode 100644
index 0000000..8bedbac
--- /dev/null
+++ b/poky/meta/recipes-graphics/mesa/files/0001-futex.h-Define-__NR_futex-if-it-does-not-exist.patch
@@ -0,0 +1,31 @@
+From 8973e297f2f9b17498b9dc0e37a19481d4bb7df9 Mon Sep 17 00:00:00 2001
+From: Khem Raj <raj.khem@gmail.com>
+Date: Fri, 16 Oct 2020 11:03:47 -0700
+Subject: [PATCH] futex.h: Define __NR_futex if it does not exist
+
+__NR_futex is not defines by newer architectures e.g. arc, riscv32 as
+they only have 64bit variant of time_t. Glibc defines SYS_futex interface based on
+__NR_futex, since this is used in applications, such applications start
+to fail to build for these newer architectures. This patch defines a
+fallback to alias __NR_futex to __NR_futex_tim64 so SYS_futex keeps
+working
+
+Upstream-Status: Pending
+Signed-off-by: Khem Raj <raj.khem@gmail.com>
+---
+ src/util/futex.h | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/src/util/futex.h
++++ b/src/util/futex.h
+@@ -34,6 +34,10 @@
+ #include <sys/syscall.h>
+ #include <sys/time.h>
+ 
++#if !defined(SYS_futex) && defined(SYS_futex_time64)
++# define SYS_futex SYS_futex_time64
++#endif
++
+ static inline long sys_futex(void *addr1, int op, int val1, const struct timespec *timeout, void *addr2, int val3)
+ {
+    return syscall(SYS_futex, addr1, op, val1, timeout, addr2, val3);
diff --git a/poky/meta/recipes-graphics/mesa/mesa.inc b/poky/meta/recipes-graphics/mesa/mesa.inc
index dd4619a..9fc62e9 100644
--- a/poky/meta/recipes-graphics/mesa/mesa.inc
+++ b/poky/meta/recipes-graphics/mesa/mesa.inc
@@ -21,6 +21,7 @@
            file://0004-Revert-mesa-Enable-asm-unconditionally-now-that-gen_.patch \
            file://0005-vc4-use-intmax_t-for-formatted-output-of-timespec-me.patch \
            file://0001-meson-misdetects-64bit-atomics-on-mips-clang.patch \
+           file://0001-futex.h-Define-__NR_futex-if-it-does-not-exist.patch \
            "
 
 SRC_URI[sha256sum] = "df21351494f7caaec5a3ccc16f14f15512e98d2ecde178bba1d134edc899b961"
diff --git a/poky/meta/recipes-graphics/wayland/weston-init.bb b/poky/meta/recipes-graphics/wayland/weston-init.bb
index 07cec75..b7a99be 100644
--- a/poky/meta/recipes-graphics/wayland/weston-init.bb
+++ b/poky/meta/recipes-graphics/wayland/weston-init.bb
@@ -15,6 +15,10 @@
 
 S = "${WORKDIR}"
 
+PACKAGECONFIG ??= ""
+
+PACKAGECONFIG[no-idle-timeout] = ",,"
+
 DEFAULTBACKEND ??= ""
 DEFAULTBACKEND_qemuall ?= "fbdev"
 DEFAULTBACKEND_qemuarm64 = "drm"
@@ -45,6 +49,10 @@
         if [ -n "${DEFAULTBACKEND}" ]; then
 		sed -i -e "/^\[core\]/a backend=${DEFAULTBACKEND}-backend.so" ${D}${sysconfdir}/xdg/weston/weston.ini
 	fi
+
+	if [ "${@bb.utils.contains('PACKAGECONFIG', 'no-idle-timeout', 'yes', 'no', d)}" = "yes" ]; then
+		echo "idle-time=0" >> ${D}${sysconfdir}/xdg/weston/weston.ini
+	fi
 }
 
 inherit update-rc.d features_check systemd
diff --git a/poky/meta/recipes-graphics/wayland/weston_9.0.0.bb b/poky/meta/recipes-graphics/wayland/weston_9.0.0.bb
index 0b037a3..75f9fb0 100644
--- a/poky/meta/recipes-graphics/wayland/weston_9.0.0.bb
+++ b/poky/meta/recipes-graphics/wayland/weston_9.0.0.bb
@@ -73,7 +73,7 @@
 # Clients support
 PACKAGECONFIG[clients] = "-Dsimple-clients=all -Ddemo-clients=true,-Dsimple-clients= -Ddemo-clients=false"
 # Virtual remote output with GStreamer on DRM backend
-PACKAGECONFIG[remoting] = "-Dremoting=true,-Dremoting=false,gstreamer-1.0"
+PACKAGECONFIG[remoting] = "-Dremoting=true,-Dremoting=false,gstreamer1.0"
 # Weston with PAM support
 PACKAGECONFIG[pam] = "-Dpam=true,-Dpam=false,libpam"
 # Weston with screen-share support
diff --git a/poky/meta/recipes-kernel/kmod/kmod.inc b/poky/meta/recipes-kernel/kmod/kmod.inc
index edff191..646dff9 100644
--- a/poky/meta/recipes-kernel/kmod/kmod.inc
+++ b/poky/meta/recipes-kernel/kmod/kmod.inc
@@ -11,6 +11,7 @@
 
 LIC_FILES_CHKSUM = "file://COPYING;md5=a6f89e2100d9b6cdffcea4f398e37343 \
                     file://libkmod/COPYING;md5=a6f89e2100d9b6cdffcea4f398e37343 \
+                    file://tools/COPYING;md5=751419260aa954499f7abaabaa882bbe \
                    "
 inherit autotools gtk-doc pkgconfig manpages
 
diff --git a/poky/meta/recipes-kernel/linux-firmware/linux-firmware_20200817.bb b/poky/meta/recipes-kernel/linux-firmware/linux-firmware_20200817.bb
index ffeb8e6..0abd28c 100644
--- a/poky/meta/recipes-kernel/linux-firmware/linux-firmware_20200817.bb
+++ b/poky/meta/recipes-kernel/linux-firmware/linux-firmware_20200817.bb
@@ -218,8 +218,8 @@
              ${PN}-mt7601u-license ${PN}-mt7601u \
              ${PN}-radeon-license ${PN}-radeon \
              ${PN}-marvell-license ${PN}-pcie8897 ${PN}-pcie8997 \
-             ${PN}-sd8686 ${PN}-sd8688 ${PN}-sd8787 ${PN}-sd8797 ${PN}-sd8801 ${PN}-sd8887 ${PN}-sd8897 \
-             ${PN}-usb8997 \
+             ${PN}-sd8686 ${PN}-sd8688 ${PN}-sd8787 ${PN}-sd8797 ${PN}-sd8801 \
+             ${PN}-sd8887 ${PN}-sd8897 ${PN}-sd8997 ${PN}-usb8997 \
              ${PN}-ti-connectivity-license ${PN}-wlcommon ${PN}-wl12xx ${PN}-wl18xx \
              ${PN}-vt6656-license ${PN}-vt6656 \
              ${PN}-rtl-license ${PN}-rtl8188 ${PN}-rtl8192cu ${PN}-rtl8192ce ${PN}-rtl8192su ${PN}-rtl8723 ${PN}-rtl8821 \
@@ -288,12 +288,16 @@
              ${PN}-adsp-sst-license ${PN}-adsp-sst \
              ${PN}-bnx2-mips \
              ${PN}-liquidio \
+             ${PN}-nvidia-license \
+             ${PN}-nvidia-tegra-k1 ${PN}-nvidia-tegra \
+             ${PN}-nvidia-gpu \
              ${PN}-netronome-license ${PN}-netronome \
              ${PN}-qat ${PN}-qat-license \
              ${PN}-qcom-license \
              ${PN}-qcom-venus-1.8 ${PN}-qcom-venus-4.2 ${PN}-qcom-venus-5.2 ${PN}-qcom-venus-5.4 \
              ${PN}-qcom-adreno-a3xx ${PN}-qcom-adreno-a530 ${PN}-qcom-adreno-a630 \
              ${PN}-qcom-sdm845-audio ${PN}-qcom-sdm845-compute ${PN}-qcom-sdm845-modem \
+             ${PN}-amlogic-vdec-license ${PN}-amlogic-vdec \
              ${PN}-whence-license \
              ${PN}-license \
              "
@@ -403,6 +407,7 @@
 LICENSE_${PN}-sd8801 = "Firmware-Marvell"
 LICENSE_${PN}-sd8887 = "Firmware-Marvell"
 LICENSE_${PN}-sd8897 = "Firmware-Marvell"
+LICENSE_${PN}-sd8997 = "Firmware-Marvell"
 LICENSE_${PN}-usb8997 = "Firmware-Marvell"
 LICENSE_${PN}-marvell-license = "Firmware-Marvell"
 
@@ -438,6 +443,15 @@
 FILES_${PN}-sd8897 = " \
   ${nonarch_base_libdir}/firmware/mrvl/sd8897_uapsta.bin \
 "
+do_install_append() {
+    # The kernel 5.6.x driver still uses the old name, provide a symlink for
+    # older kernels
+    ln -fs sdsd8997_combo_v4.bin ${D}${nonarch_base_libdir}/firmware/mrvl/sd8997_uapsta.bin
+}
+FILES_${PN}-sd8997 = " \
+  ${nonarch_base_libdir}/firmware/mrvl/sd8997_uapsta.bin \
+  ${nonarch_base_libdir}/firmware/mrvl/sdsd8997_combo_v4.bin \
+"
 FILES_${PN}-usb8997 = " \
   ${nonarch_base_libdir}/firmware/mrvl/usbusb8997_combo_v4.bin \
 "
@@ -449,6 +463,7 @@
 RDEPENDS_${PN}-sd8801 += "${PN}-marvell-license"
 RDEPENDS_${PN}-sd8887 += "${PN}-marvell-license"
 RDEPENDS_${PN}-sd8897 += "${PN}-marvell-license"
+RDEPENDS_${PN}-sd8997 += "${PN}-marvell-license"
 RDEPENDS_${PN}-usb8997 += "${PN}-marvell-license"
 
 # For netronome
@@ -466,6 +481,27 @@
 
 RDEPENDS_${PN}-netronome += "${PN}-netronome-license"
 
+# For Nvidia
+LICENSE_${PN}-nvidia-gpu = "Firmware-nvidia"
+LICENSE_${PN}-nvidia-tegra = "Firmware-nvidia"
+LICENSE_${PN}-nvidia-tegra-k1 = "Firmware-nvidia"
+LICENSE_${PN}-nvidia-license = "Firmware-nvidia"
+
+FILES_${PN}-nvidia-gpu = "${nonarch_base_libdir}/firmware/nvidia"
+FILES_${PN}-nvidia-tegra = " \
+  ${nonarch_base_libdir}/firmware/nvidia/tegra* \
+  ${nonarch_base_libdir}/firmware/nvidia/gm20b \
+  ${nonarch_base_libdir}/firmware/nvidia/gp10b \
+"
+FILES_${PN}-nvidia-tegra-k1 = " \
+  ${nonarch_base_libdir}/firmware/nvidia/tegra124 \
+  ${nonarch_base_libdir}/firmware/nvidia/gk20a \
+"
+FILES_${PN}-nvidia-license = "${nonarch_base_libdir}/firmware/LICENCE.nvidia"
+
+RDEPENDS_${PN}-nvidia-gpu += "${PN}-nvidia-license"
+RDEPENDS_${PN}-nvidia-tegra += "${PN}-nvidia-license"
+
 # For rtl
 LICENSE_${PN}-rtl8188 = "Firmware-rtlwifi_firmware"
 LICENSE_${PN}-rtl8192cu = "Firmware-rtlwifi_firmware"
@@ -881,6 +917,12 @@
 
 FILES_${PN}-liquidio = "${nonarch_base_libdir}/firmware/liquidio"
 
+# For Amlogic VDEC
+LICENSE_${PN}-amlogic-vdec = "Firmware-amlogic_vdec"
+FILES_${PN}-amlogic-vdec-license = "${nonarch_base_libdir}/firmware/LICENSE.amlogic_vdec"
+FILES_${PN}-amlogic-vdec = "${nonarch_base_libdir}/firmware/meson/vdec/*"
+RDEPENDS_${PN}-amlogic-vdec = "${PN}-amlogic-vdec-license"
+
 # For other firmwares
 # Maybe split out to separate packages when needed.
 LICENSE_${PN} = "\
@@ -888,6 +930,7 @@
     & Firmware-agere \
     & Firmware-amdgpu \
     & Firmware-amd-ucode \
+    & Firmware-amlogic_vdec \
     & Firmware-atmel \
     & Firmware-ca0132 \
     & Firmware-cavium \
diff --git a/poky/meta/recipes-support/attr/attr.inc b/poky/meta/recipes-support/attr/attr.inc
index f13a83a..0c3330a 100644
--- a/poky/meta/recipes-support/attr/attr.inc
+++ b/poky/meta/recipes-support/attr/attr.inc
@@ -8,6 +8,7 @@
 LICENSE_${PN} = "GPLv2+"
 LICENSE_lib${BPN} = "LGPLv2.1+"
 LIC_FILES_CHKSUM = "file://doc/COPYING;md5=2d0aa14b3fce4694e4f615e30186335f \
+                    file://doc/COPYING.LGPL;md5=b8d31f339300bc239d73461d68e77b9c \
                     file://tools/attr.c;endline=17;md5=be0403261f0847e5f43ed5b08d19593c \
                     file://libattr/libattr.c;endline=17;md5=7970f77049f8fa1199fff62a7ab724fb"
 
diff --git a/poky/meta/recipes-support/boost/boost-build-native_4.3.0.bb b/poky/meta/recipes-support/boost/boost-build-native_4.3.0.bb
index d8096de..258f8c9 100644
--- a/poky/meta/recipes-support/boost/boost-build-native_4.3.0.bb
+++ b/poky/meta/recipes-support/boost/boost-build-native_4.3.0.bb
@@ -7,6 +7,8 @@
 SRC_URI = "git://github.com/boostorg/build;protocol=https"
 SRCREV = "632ea768f3eb225b4472c5ed6d20afee708724ad"
 
+UPSTREAM_CHECK_GITTAGREGEX = "(?P<pver>(\d+(\.\d+){2,}))"
+
 inherit native
 
 S = "${WORKDIR}/git"
diff --git a/poky/meta/recipes-support/boost/boost/0001-fiber-libs-Define-SYS_futex-if-it-does-not-exist.patch b/poky/meta/recipes-support/boost/boost/0001-fiber-libs-Define-SYS_futex-if-it-does-not-exist.patch
new file mode 100644
index 0000000..523568e
--- /dev/null
+++ b/poky/meta/recipes-support/boost/boost/0001-fiber-libs-Define-SYS_futex-if-it-does-not-exist.patch
@@ -0,0 +1,54 @@
+From d6f7b6064dc91d1d5fa18554b40b14822ab7a32b Mon Sep 17 00:00:00 2001
+From: Khem Raj <raj.khem@gmail.com>
+Date: Fri, 16 Oct 2020 11:13:22 -0700
+Subject: [PATCH] fiber,libs: Define SYS_futex if it does not exist
+
+__NR_futex is not defines by newer architectures e.g. arc, riscv32 as
+they only have 64bit variant of time_t. Glibc defines SYS_futex interface based on
+__NR_futex, since this is used in applications, such applications start
+to fail to build for these newer architectures. This patch defines a
+fallback to alias __NR_futex to __NR_futex_tim64 so SYS_futex keeps
+working
+
+Upstream-Status: Pending
+
+Signed-off-by: Khem Raj <raj.khem@gmail.com>
+---
+ boost/fiber/detail/futex.hpp | 5 +++++
+ libs/log/src/event.cpp       | 4 ++++
+ 2 files changed, 9 insertions(+)
+
+diff --git a/boost/fiber/detail/futex.hpp b/boost/fiber/detail/futex.hpp
+index e64bd5990..16bee64f1 100644
+--- a/boost/fiber/detail/futex.hpp
++++ b/boost/fiber/detail/futex.hpp
+@@ -17,6 +17,11 @@ extern "C" {
+ #include <linux/futex.h>
+ #include <sys/syscall.h>
+ }
++
++#if !defined(SYS_futex) && defined(SYS_futex_time64)
++#define SYS_futex SYS_futex_time64
++#endif
++
+ #elif BOOST_OS_WINDOWS
+ #include <windows.h>
+ #endif
+diff --git a/libs/log/src/event.cpp b/libs/log/src/event.cpp
+index 5485154d7..2c7c0381f 100644
+--- a/libs/log/src/event.cpp
++++ b/libs/log/src/event.cpp
+@@ -31,6 +31,10 @@
+ #include <linux/futex.h>
+ #include <boost/memory_order.hpp>
+ 
++#if !defined(SYS_futex) && defined(SYS_futex_time64)
++#define SYS_futex SYS_futex_time64
++#endif
++
+ // Some Android NDKs (Google NDK and older Crystax.NET NDK versions) don't define SYS_futex
+ #if defined(SYS_futex)
+ #define BOOST_LOG_SYS_FUTEX SYS_futex
+-- 
+2.28.0
+
diff --git a/poky/meta/recipes-support/boost/boost_1.74.0.bb b/poky/meta/recipes-support/boost/boost_1.74.0.bb
index 5e9e0d8..b01b390 100644
--- a/poky/meta/recipes-support/boost/boost_1.74.0.bb
+++ b/poky/meta/recipes-support/boost/boost_1.74.0.bb
@@ -7,4 +7,5 @@
            file://0001-Apply-boost-1.62.0-no-forced-flags.patch.patch \
            file://0001-Don-t-set-up-arch-instruction-set-flags-we-do-that-o.patch \
            file://0001-dont-setup-compiler-flags-m32-m64.patch \
+           file://0001-fiber-libs-Define-SYS_futex-if-it-does-not-exist.patch \
            "
diff --git a/poky/meta/recipes-support/libproxy/libproxy/CVE-2020-25219.patch b/poky/meta/recipes-support/libproxy/libproxy/CVE-2020-25219.patch
new file mode 100644
index 0000000..3ef7f85
--- /dev/null
+++ b/poky/meta/recipes-support/libproxy/libproxy/CVE-2020-25219.patch
@@ -0,0 +1,61 @@
+From a83dae404feac517695c23ff43ce1e116e2bfbe0 Mon Sep 17 00:00:00 2001
+From: Michael Catanzaro <mcatanzaro@gnome.org>
+Date: Wed, 9 Sep 2020 11:12:02 -0500
+Subject: [PATCH] Rewrite url::recvline to be nonrecursive
+
+This function processes network input. It's semi-trusted, because the
+PAC ought to be trusted. But we still shouldn't allow it to control how
+far we recurse. A malicious PAC can cause us to overflow the stack by
+sending a sufficiently-long line without any '\n' character.
+
+Also, this function failed to properly handle EINTR, so let's fix that
+too, for good measure.
+
+Fixes #134
+
+Upstream-Status: Backport [https://github.com/libproxy/libproxy/commit/836c10b60c65e947ff1e10eb02fbcc676d909ffa]
+CVE: CVE-2020-25219
+Signed-off-by: Chee Yang Lee <chee.yang.lee@intel.com>
+---
+ libproxy/url.cpp | 28 ++++++++++++++++++----------
+ 1 file changed, 18 insertions(+), 10 deletions(-)
+
+diff --git a/libproxy/url.cpp b/libproxy/url.cpp
+index ee776b2..68d69cd 100644
+--- a/libproxy/url.cpp
++++ b/libproxy/url.cpp
+@@ -388,16 +388,24 @@ string url::to_string() const {
+ 	return m_orig;
+ }
+ 
+-static inline string recvline(int fd) {
+-	// Read a character.
+-	// If we don't get a character, return empty string.
+-	// If we are at the end of the line, return empty string.
+-	char c = '\0';
+-	
+-	if (recv(fd, &c, 1, 0) != 1 || c == '\n')
+-		return "";
+-
+-	return string(1, c) + recvline(fd);
++static string recvline(int fd) {
++	string line;
++	int ret;
++
++	// Reserve arbitrary amount of space to avoid small memory reallocations.
++	line.reserve(128);
++
++	do {
++		char c;
++		ret = recv(fd, &c, 1, 0);
++		if (ret == 1) {
++			if (c == '\n')
++				return line;
++			line += c;
++		}
++	} while (ret == 1 || (ret == -1 && errno == EINTR));
++
++	return line;
+ }
+ 
+ char* url::get_pac() {
diff --git a/poky/meta/recipes-support/libproxy/libproxy_0.4.15.bb b/poky/meta/recipes-support/libproxy/libproxy_0.4.15.bb
index 19dddeb..a14c358 100644
--- a/poky/meta/recipes-support/libproxy/libproxy_0.4.15.bb
+++ b/poky/meta/recipes-support/libproxy/libproxy_0.4.15.bb
@@ -10,6 +10,7 @@
 
 SRC_URI = "https://github.com/${BPN}/${BPN}/releases/download/${PV}/${BP}.tar.xz \
            file://0001-get-pac-test-Fix-build-with-clang-libc.patch \
+           file://CVE-2020-25219.patch \
           "
 SRC_URI[md5sum] = "f6b1d2a1e17a99cd3debaae6d04ab152"
 SRC_URI[sha256sum] = "654db464120c9534654590b6683c7fa3887b3dad0ca1c4cd412af24fbfca6d4f"
diff --git a/poky/scripts/install-buildtools b/poky/scripts/install-buildtools
index 7118f48..8554a5d 100755
--- a/poky/scripts/install-buildtools
+++ b/poky/scripts/install-buildtools
@@ -57,9 +57,9 @@
 
 DEFAULT_INSTALL_DIR = os.path.join(os.path.split(scripts_path)[0],'buildtools')
 DEFAULT_BASE_URL = 'http://downloads.yoctoproject.org/releases/yocto'
-DEFAULT_RELEASE = 'yocto-3.2_M1'
+DEFAULT_RELEASE = 'yocto-3.2_M3'
 DEFAULT_INSTALLER_VERSION = '3.1+snapshot'
-DEFAULT_BUILDDATE = '20200617'
+DEFAULT_BUILDDATE = '20200923'
 
 # Python version sanity check
 if not (sys.version_info.major == 3 and sys.version_info.minor >= 4):
diff --git a/poky/scripts/lib/devtool/__init__.py b/poky/scripts/lib/devtool/__init__.py
index 6ebe368..702db66 100644
--- a/poky/scripts/lib/devtool/__init__.py
+++ b/poky/scripts/lib/devtool/__init__.py
@@ -212,8 +212,13 @@
         bb.process.run(commit_cmd, cwd=repodir)
 
     # Ensure singletask.lock (as used by externalsrc.bbclass) is ignored by git
+    gitinfodir = os.path.join(repodir, '.git', 'info')
+    try:
+        os.mkdir(gitinfodir)
+    except FileExistsError:
+        pass
     excludes = []
-    excludefile = os.path.join(repodir, '.git', 'info', 'exclude')
+    excludefile = os.path.join(gitinfodir, 'exclude')
     try:
         with open(excludefile, 'r') as f:
             excludes = f.readlines()