diff --git a/poky/documentation/dev-manual/common-tasks.rst b/poky/documentation/dev-manual/common-tasks.rst
index 176025f..37c7a19 100644
--- a/poky/documentation/dev-manual/common-tasks.rst
+++ b/poky/documentation/dev-manual/common-tasks.rst
@@ -49,15 +49,13 @@
    (e.g. the cloned ``poky`` repository).
 
    While not strictly required, prepend the name of the directory with
-   the string "meta-". For example:
-   ::
+   the string "meta-". For example::
 
       meta-mylayer
       meta-GUI_xyz
       meta-mymachine
 
-   With rare exceptions, a layer's name follows this form:
-   ::
+   With rare exceptions, a layer's name follows this form::
 
       meta-root_name
 
@@ -77,8 +75,7 @@
    :yocto_git:`Source Repositories </poky/tree/meta-yocto-bsp/conf>`
    demonstrates the required syntax. For your layer, you need to replace
    "yoctobsp" with a unique identifier for your layer (e.g. "machinexyz"
-   for a layer named "meta-machinexyz"):
-   ::
+   for a layer named "meta-machinexyz")::
 
       # We have a conf and classes directory, add to BBPATH
       BBPATH .= ":${LAYERDIR}"
@@ -195,8 +192,7 @@
       machine "one". To do so, you use an append file named
       ``base-files.bbappend`` and create a dependency on "foo" by
       altering the :term:`DEPENDS`
-      variable:
-      ::
+      variable::
 
          DEPENDS = "foo"
 
@@ -209,14 +205,12 @@
       ``foo``.
 
       To make sure your changes apply only when building machine "one",
-      use a machine override with the ``DEPENDS`` statement:
-      ::
+      use a machine override with the ``DEPENDS`` statement::
 
          DEPENDS_one = "foo"
 
       You should follow the same strategy when using ``_append``
-      and ``_prepend`` operations:
-      ::
+      and ``_prepend`` operations::
 
          DEPENDS_append_one = " foo"
          DEPENDS_prepend_one = "foo "
@@ -224,8 +218,7 @@
       As an actual example, here's a
       snippet from the generic kernel include file ``linux-yocto.inc``,
       wherein the kernel compile and link options are adjusted in the
-      case of a subset of the supported architectures:
-      ::
+      case of a subset of the supported architectures::
 
          DEPENDS_append_aarch64 = " libgcc"
          KERNEL_CC_append_aarch64 = " ${TOOLCHAIN_OPTIONS}"
@@ -252,8 +245,7 @@
       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:
-      ::
+      extend :term:`FILESPATH` using :term:`FILESEXTRAPATHS` as follows::
 
          FILESEXTRAPATHS_prepend := "${THISDIR}/${BPN}:"
 
@@ -375,8 +367,7 @@
 layer, the layer must pass the COMMON and BSP set of tests.
 
 To execute the script, enter the following commands from your build
-directory:
-::
+directory::
 
    $ source oe-init-build-env
    $ yocto-check-layer your_layer_directory
@@ -432,8 +423,7 @@
 ``BBLAYERS`` variable in your ``conf/bblayers.conf`` file, which is
 found in the :term:`Build Directory`.
 The following example shows how to enable a layer named
-``meta-mylayer``:
-::
+``meta-mylayer``::
 
    # POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf
    # changes incompatibly
@@ -488,8 +478,7 @@
 formfactor append file both from the :term:`Source Directory`.
 Here is the main
 formfactor recipe, which is named ``formfactor_0.0.bb`` and located in
-the "meta" layer at ``meta/recipes-bsp/formfactor``:
-::
+the "meta" layer at ``meta/recipes-bsp/formfactor``::
 
    SUMMARY = "Device formfactor information"
    DESCRIPTION = "A formfactor configuration file provides information about the \
@@ -521,8 +510,7 @@
 
 Following is the append file, which is named ``formfactor_0.0.bbappend``
 and is from the Raspberry Pi BSP Layer named ``meta-raspberrypi``. The
-file is in the layer at ``recipes-bsp/formfactor``:
-::
+file is in the layer at ``recipes-bsp/formfactor``::
 
    FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
 
@@ -570,8 +558,7 @@
 
 To specify the layer's priority manually, use the
 :term:`BBFILE_PRIORITY`
-variable and append the layer's root name:
-::
+variable and append the layer's root name::
 
    BBFILE_PRIORITY_mylayer = "1"
 
@@ -595,8 +582,7 @@
 applicable recipes can help to reveal potential problems.
 
 For help on the BitBake layer management tool, use the following
-command:
-::
+command::
 
    $ bitbake-layers --help
    NOTE: Starting bitbake server...
@@ -676,8 +662,7 @@
       variable values, you need to tidy these up yourself. Consider the
       following example. Here, the ``bitbake-layers`` command adds the
       line ``#### bbappended ...`` so that you know where the following
-      lines originate:
-      ::
+      lines originate::
 
          ...
          DESCRIPTION = "A useful utility"
@@ -691,8 +676,7 @@
          EXTRA_OECONF += "--enable-somethingelse"
 
 
-      Ideally, you would tidy up these utilities as follows:
-      ::
+      Ideally, you would tidy up these utilities as follows::
 
          ...
          DESCRIPTION = "Customized utility"
@@ -746,14 +730,12 @@
 
 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:
-::
+"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:
-::
+in your home directory::
 
    $ cd /usr/home
    $ bitbake-layers create-layer meta-scottrif
@@ -770,8 +752,7 @@
 
 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
-information by entering the following:
-::
+information by entering the following::
 
    $ bitbake-layers create-layer --help
    NOTE: Starting bitbake server...
@@ -799,16 +780,14 @@
 makes the OpenEmbedded build system aware of your layer so that it can
 search it for metadata.
 
-Add your layer by using the ``bitbake-layers add-layer`` command:
-::
+Add your layer by using the ``bitbake-layers add-layer`` command::
 
    $ bitbake-layers add-layer your_layer_name
 
 Here is an example that adds a
 layer named ``meta-scottrif`` to the configuration file. Following the
 command that adds the layer is another ``bitbake-layers`` command that
-shows the layers that are in your ``bblayers.conf`` file:
-::
+shows the layers that are in your ``bblayers.conf`` file::
 
    $ bitbake-layers add-layer meta-scottrif
    NOTE: Starting bitbake server...
@@ -851,8 +830,7 @@
 all images, which might not be what you require.
 
 To add a package to your image using the local configuration file, use
-the ``IMAGE_INSTALL`` variable with the ``_append`` operator:
-::
+the ``IMAGE_INSTALL`` variable with the ``_append`` operator::
 
    IMAGE_INSTALL_append = " strace"
 
@@ -870,8 +848,7 @@
 
 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:
-::
+to a specific image only. Here is an example::
 
    IMAGE_INSTALL_append_pn-core-image-minimal = " strace"
 
@@ -942,8 +919,7 @@
 
 You can also customize an image by creating a custom recipe that defines
 additional software as part of the image. The following example shows
-the form for the two lines you need:
-::
+the form for the two lines you need::
 
    IMAGE_INSTALL = "packagegroup-core-x11-base package1 package2"
    inherit core-image
@@ -958,8 +934,7 @@
 existing image. For example, if you want to create an image based on
 ``core-image-sato`` but add the additional package ``strace`` to the
 image, copy the ``meta/recipes-sato/images/core-image-sato.bb`` to a new
-``.bb`` and add the following line to the end of the copy:
-::
+``.bb`` and add the following line to the end of the copy::
 
    IMAGE_INSTALL += "strace"
 
@@ -990,8 +965,7 @@
 Here is a short, fabricated example showing the same basic pieces for a
 hypothetical packagegroup defined in ``packagegroup-custom.bb``, where
 the variable ``PN`` is the standard way to abbreviate the reference to
-the full packagegroup name ``packagegroup-custom``:
-::
+the full packagegroup name ``packagegroup-custom``::
 
    DESCRIPTION = "My Custom Package Groups"
 
@@ -1033,13 +1007,11 @@
 
 You can customize this name by altering the value of the "hostname"
 variable in the ``base-files`` recipe using either an append file or a
-configuration file. Use the following in an append file:
-::
+configuration file. Use the following in an append file::
 
    hostname = "myhostname"
 
-Use the following in a configuration file:
-::
+Use the following in a configuration file::
 
    hostname_pn-base-files = "myhostname"
 
@@ -1054,8 +1026,7 @@
 
 Another point of interest is that if you unset the variable, the image
 will have no default hostname in the filesystem. Here is an example that
-unsets the variable in a configuration file:
-::
+unsets the variable in a configuration file::
 
   hostname_pn-base-files = ""
 
@@ -1136,8 +1107,7 @@
 :term:`Build Directory` and have sourced the
 build environment setup script (i.e.
 :ref:`structure-core-script`).
-To get help on the tool, use the following command:
-::
+To get help on the tool, use the following command::
 
    $ recipetool -h
    NOTE: Starting bitbake server...
@@ -1166,8 +1136,7 @@
 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:
-   ::
+   the recipe resides in the existing source code layer::
 
       recipetool create -o OUTFILE source
 
@@ -1180,8 +1149,7 @@
 
  - 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:
-   ::
+   the recipe resides in the existing source code layer::
 
       recipetool create -d -o OUTFILE source
 
@@ -1236,8 +1204,7 @@
    recipe through the layer's ``conf/layer.conf`` file and the
    :term:`BBFILES` variable. This
    variable sets up a path from which the build system can locate
-   recipes. Here is the typical use:
-   ::
+   recipes. Here is the typical use::
 
       BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
                   ${LAYERDIR}/recipes-*/*/*.bbappend"
@@ -1249,8 +1216,7 @@
    ":ref:`dev-manual/common-tasks:understanding and creating layers`" section.
 
 -  *Naming Your Recipe:* When you name your recipe, you need to follow
-   this naming convention:
-   ::
+   this naming convention::
 
       basename_version.bb
 
@@ -1276,8 +1242,7 @@
 :ref:`structure-core-script`) and you are in
 the :term:`Build Directory`, use
 BitBake to process your recipe. All you need to provide is the
-``basename`` of the recipe as described in the previous section:
-::
+``basename`` of the recipe as described in the previous section::
 
    $ bitbake basename
 
@@ -1289,8 +1254,7 @@
 
 The path to the per-recipe temporary work directory depends on the
 context in which it is being built. The quickest way to find this path
-is to have BitBake return it by running the following:
-::
+is to have BitBake return it by running the following::
 
    $ bitbake -e basename | grep ^WORKDIR=
 
@@ -1299,8 +1263,7 @@
 ``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:
-::
+would be as follows::
 
    poky/build/tmp/work/qemux86-poky-linux/foo/1.3.0-r0
 
@@ -1352,8 +1315,7 @@
 Here is a simple example from the
 ``meta/recipes-devtools/strace/strace_5.5.bb`` recipe where the source
 comes from a single tarball. Notice the use of the
-:term:`PV` variable:
-::
+:term:`PV` variable::
 
    SRC_URI = "https://strace.io/files/${PV}/strace-${PV}.tar.xz \
 
@@ -1369,8 +1331,7 @@
 you should specify :term:`PV` to include
 the revision with :term:`SRCPV`. Here
 is an example from the recipe
-``meta/recipes-kernel/blktrace/blktrace_git.bb``:
-::
+``meta/recipes-kernel/blktrace/blktrace_git.bb``::
 
    SRCREV = "d6918c8832793b4205ed3bfede78c2f915c23385"
 
@@ -1392,8 +1353,7 @@
 each URL. For these cases, you provide a name for each URL as part of
 the ``SRC_URI`` and then reference that name in the subsequent checksum
 statements. Here is an example combining lines from the files
-``git.inc`` and ``git_2.24.1.bb``:
-::
+``git.inc`` and ``git_2.24.1.bb``::
 
    SRC_URI = "${KERNELORG_MIRROR}/software/scm/git/git-${PV}.tar.gz;name=tarball \
               ${KERNELORG_MIRROR}/software/scm/git/git-manpages-${PV}.tar.gz;name=manpages"
@@ -1512,8 +1472,7 @@
    include ``COPYING``, ``LICENSE``, and ``README`` files. You could
    also find the information near the top of a source file. For example,
    given a piece of software licensed under the GNU General Public
-   License version 2, you would set ``LICENSE`` as follows:
-   ::
+   License version 2, you would set ``LICENSE`` as follows::
 
       LICENSE = "GPLv2"
 
@@ -1543,8 +1502,7 @@
    See the ":ref:`dev-manual/common-tasks:fetching code`" section for
    additional information.
 
-   Here is an example that assumes the software has a ``COPYING`` file:
-   ::
+   Here is an example that assumes the software has a ``COPYING`` file::
 
       LIC_FILES_CHKSUM = "file://COPYING;md5=xxx"
 
@@ -1747,8 +1705,7 @@
 When you use custom kernel headers you need to get them from
 :term:`STAGING_KERNEL_DIR`,
 which is the directory with kernel headers that are required to build
-out-of-tree modules. Your recipe will also need the following:
-::
+out-of-tree modules. Your recipe will also need the following::
 
    do_configure[depends] += "virtual/kernel:do_shared_workdir"
 
@@ -1779,8 +1736,7 @@
 
    To fix the problem, you need to either satisfy the missing dependency
    in the Makefile or whatever script produced the Makefile, or (as a
-   workaround) set :term:`PARALLEL_MAKE` to an empty string:
-   ::
+   workaround) set :term:`PARALLEL_MAKE` to an empty string::
 
       PARALLEL_MAKE = ""
 
@@ -1889,8 +1845,7 @@
       missing dependencies between targets that can result in race
       conditions. If you experience intermittent failures during
       ``do_install``, you might be able to work around them by disabling
-      parallel Makefile installs by adding the following to the recipe:
-      ::
+      parallel Makefile installs by adding the following to the recipe::
 
          PARALLEL_MAKEINST = ""
 
@@ -2006,8 +1961,7 @@
    :term:`MACHINE` value is passed
    into the configure script or a patch is applied only for a particular
    machine), you should mark them as such by adding the following to the
-   recipe:
-   ::
+   recipe::
 
       PACKAGE_ARCH = "${MACHINE_ARCH}"
 
@@ -2016,8 +1970,7 @@
    all (e.g. recipes that simply package script files or configuration
    files), you should use the
    :ref:`allarch <ref-classes-allarch>` class to
-   do this for you by adding this to your recipe:
-   ::
+   do this for you by adding this to your recipe::
 
       inherit allarch
 
@@ -2061,8 +2014,7 @@
 :term:`SYSROOT_DIRS` variable to automatically populate the sysroot. It
 is possible to modify the list of directories that populate the sysroot.
 The following example shows how you could add the ``/opt`` directory to
-the list of directories within a recipe:
-::
+the list of directories within a recipe::
 
    SYSROOT_DIRS += "/opt"
 
@@ -2091,8 +2043,7 @@
 in some way uses a :term:`PROVIDES`
 statement that essentially identifies itself as being able to provide
 ``virtual/kernel``. Here is one way through the
-:ref:`kernel <ref-classes-kernel>` class:
-::
+:ref:`kernel <ref-classes-kernel>` class::
 
    PROVIDES += "${@ "virtual/kernel" if (d.getVar("KERNEL_PACKAGE_NAME") == "kernel") else "" }"
 
@@ -2107,8 +2058,7 @@
 </poky/tree/meta/conf/machine/include/x86-base.inc>` include file, which is a
 machine (i.e. :term:`MACHINE`) configuration file. This include file is the
 reason all x86-based machines use the ``linux-yocto`` kernel. Here are the
-relevant lines from the include file:
-::
+relevant lines from the include file::
 
    PREFERRED_PROVIDER_virtual/kernel ??= "linux-yocto"
    PREFERRED_VERSION_linux-yocto ??= "4.15%"
@@ -2116,8 +2066,7 @@
 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:
-::
+build is dependent on ``virtual/kernel`` for example::
 
    DEPENDS = "virtual/kernel"
 
@@ -2125,8 +2074,7 @@
 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:
-::
+follows::
 
    PREFERRED_PROVIDER_virtual/kernel ??= "kernel-small"
 
@@ -2178,8 +2126,7 @@
 convention is to set :term:`PV` within the
 recipe to "previous_version+current_version". You can use an additional
 variable so that you can use the current version elsewhere. Here is an
-example:
-::
+example::
 
    REALPV = "0.8.16-rc1"
    PV = "0.8.15+${REALPV}"
@@ -2198,8 +2145,7 @@
 ``${``\ :term:`PN`\ ``}`` in place of
 PACKAGENAME.
 
-A post-installation function has the following structure:
-::
+A post-installation function has the following structure::
 
    pkg_postinst_PACKAGENAME() {
        # Commands to carry out
@@ -2352,13 +2298,11 @@
 Some applications might require extra parameters to be passed to the
 compiler. For example, the application might need an additional header
 path. You can accomplish this by adding to the ``CFLAGS`` variable. The
-following example shows this:
-::
+following example shows this::
 
    CFLAGS_prepend = "-I ${S}/include "
 
-In the following example, ``mtd-utils`` is a makefile-based package:
-::
+In the following example, ``mtd-utils`` is a makefile-based package::
 
    SUMMARY = "Tools for managing memory technology devices"
    SECTION = "base"
@@ -2403,8 +2347,7 @@
 Following is an example that uses the ``libxpm`` recipe. By default,
 this recipe generates a single package that contains the library along
 with a few binaries. You can modify the recipe to split the binaries
-into separate packages:
-::
+into separate packages::
 
    require xorg-lib-common.inc
 
@@ -2498,8 +2441,7 @@
    that replaces ``do_configure`` and ``do_compile`` with custom
    versions, then you can use the
    ``[``\ :ref:`noexec <bitbake-user-manual/bitbake-user-manual-metadata:variable flags>`\ ``]``
-   flag to turn the tasks into no-ops, as follows:
-   ::
+   flag to turn the tasks into no-ops, as follows::
 
       do_configure[noexec] = "1"
       do_compile[noexec] = "1"
@@ -2558,8 +2500,7 @@
    supported.
 
    The following example shows some of the ways you can use variables in
-   recipes:
-   ::
+   recipes::
 
       S = "${WORKDIR}/postfix-${PV}"
       CFLAGS += "-DNO_ASM"
@@ -2572,8 +2513,7 @@
    syntax, although access to OpenEmbedded variables and internal
    methods are also available.
 
-   The following is an example function from the ``sed`` recipe:
-   ::
+   The following is an example function from the ``sed`` recipe::
 
       do_install () {
           autotools_do_install
@@ -2594,16 +2534,14 @@
    from other files (``include`` and ``require``) and export variables
    to the environment (``export``).
 
-   The following example shows the use of some of these keywords:
-   ::
+   The following example shows the use of some of these keywords::
 
       export POSTCONF = "${STAGING_BINDIR}/postconf"
       inherit autoconf
       require otherfile.inc
 
 -  *Comments (#):* Any lines that begin with the hash character (``#``)
-   are treated as comment lines and are ignored:
-   ::
+   are treated as comment lines and are ignored::
 
       # This is a comment
 
@@ -2615,8 +2553,7 @@
 
 -  *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:
-   ::
+   the end of the line that is to be continued on the next line::
 
        VAR = "A really long \
               line"
@@ -2627,8 +2564,7 @@
       slash character.
 
 -  *Using Variables (${VARNAME}):* Use the ``${VARNAME}`` syntax to
-   access the contents of a variable:
-   ::
+   access the contents of a variable::
 
       SRC_URI = "${SOURCEFORGE_MIRROR}/libpng/zlib-${PV}.tar.gz"
 
@@ -2648,8 +2584,7 @@
       when you make the assignment, but this is not generally needed.
 
 -  *Quote All Assignments ("value"):* Use double quotes around values in
-   all variable assignments (e.g. ``"value"``). Following is an example:
-   ::
+   all variable assignments (e.g. ``"value"``). Following is an example::
 
       VAR1 = "${OTHERVAR}"
       VAR2 = "The version is ${PV}"
@@ -2663,13 +2598,11 @@
 
    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:
-   ::
+   remains unchanged::
 
       VAR1 ?= "New value"
 
-   In this next example, ``VAR1`` is left with the value "Original value":
-   ::
+   In this next example, ``VAR1`` is left with the value "Original value"::
 
       VAR1 = "Original value"
       VAR1 ?= "New value"
@@ -2682,8 +2615,7 @@
       This operator adds a space between the existing content of the
       variable and the new content.
 
-   Here is an example:
-   ::
+   Here is an example::
 
       SRC_URI += "file://fix-makefile.patch"
 
@@ -2695,8 +2627,7 @@
       This operator adds a space between the new content and the
       existing content of the variable.
 
-   Here is an example:
-   ::
+   Here is an example::
 
       VAR =+ "Starts"
 
@@ -2708,15 +2639,13 @@
 
    The following example shows the space being explicitly added to the
    start to ensure the appended value is not merged with the existing
-   value:
-   ::
+   value::
 
       SRC_URI_append = " file://fix-makefile.patch"
 
    You can also use
    the ``_append`` operator with overrides, which results in the actions
-   only being performed for the specified target or machine:
-   ::
+   only being performed for the specified target or machine::
 
       SRC_URI_append_sh4 = " file://fix-makefile.patch"
 
@@ -2728,15 +2657,13 @@
 
    The following example shows the space being explicitly added to the
    end to ensure the prepended value is not merged with the existing
-   value:
-   ::
+   value::
 
       CFLAGS_prepend = "-I${S}/myincludes "
 
    You can also use the
    ``_prepend`` operator with overrides, which results in the actions
-   only being performed for the specified target or machine:
-   ::
+   only being performed for the specified target or machine::
 
       CFLAGS_prepend_sh4 = "-I${S}/myincludes "
 
@@ -2746,8 +2673,7 @@
    value to "standard/base" for any target
    :term:`MACHINE`, except for
    qemuarm where it should be set to "standard/arm-versatile-926ejs",
-   you would do the following:
-   ::
+   you would do the following::
 
       KBRANCH = "standard/base"
       KBRANCH_qemuarm = "standard/arm-versatile-926ejs"
@@ -2770,8 +2696,7 @@
    search and replacement on a variable).
 
    You indicate Python code using the ``${@python_code}`` syntax for the
-   variable assignment:
-   ::
+   variable assignment::
 
       SRC_URI = "ftp://ftp.info-zip.org/pub/infozip/src/zip${@d.getVar('PV',1).replace('.', '')}.tgz
 
@@ -2861,8 +2786,7 @@
 a location similar to ``defconfig`` files used for other machines in a
 given kernel recipe. A possible way to do this is by listing the file in
 the ``SRC_URI`` and adding the machine to the expression in
-``COMPATIBLE_MACHINE``:
-::
+``COMPATIBLE_MACHINE``::
 
    COMPATIBLE_MACHINE = '(qemux86|qemumips)'
 
@@ -2889,8 +2813,7 @@
 defaults, see the ``meta/recipes-bsp/formfactor/files/config`` file
 found in the same area.
 
-Following is an example for "qemuarm" machine:
-::
+Following is an example for "qemuarm" machine::
 
    HAVE_TOUCHSCREEN=1
    HAVE_KEYBOARD=1
@@ -2961,22 +2884,19 @@
 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:
-   ::
+   configurations::
 
       $ git config --list
 
    If you do not have the user and
-   email configured, you can use the following commands to do so:
-   ::
+   email configured, you can use the following commands to do so::
 
       $ git config --global user.name some_name
       $ git config --global user.email username@domain.com
 
 3. *Clone the AUH Repository:* To use AUH, you must clone the repository
    onto your development host. The following command uses Git to create
-   a local copy of the repository on your system:
-   ::
+   a local copy of the repository on your system::
 
       $ git clone  git://git.yoctoproject.org/auto-upgrade-helper
       Cloning into 'auto-upgrade-helper'... remote: Counting objects: 768, done.
@@ -2992,8 +2912,7 @@
 4. *Create a Dedicated Build Directory:* Run the
    :ref:`structure-core-script`
    script to create a fresh build directory that you use exclusively for
-   running the AUH utility:
-   ::
+   running the AUH utility::
 
       $ cd poky
       $ source oe-init-build-env your_AUH_build_directory
@@ -3010,8 +2929,7 @@
    -  If you want to enable :ref:`Build
       History <dev-manual/common-tasks:maintaining build output quality>`,
       which is optional, you need the following lines in the
-      ``conf/local.conf`` file:
-      ::
+      ``conf/local.conf`` file::
 
          INHERIT =+ "buildhistory"
          BUILDHISTORY_COMMIT = "1"
@@ -3024,23 +2942,20 @@
    -  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:
-      ::
+      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"
 
 
 6. *Optionally Start a vncserver:* If you are running in a server
-   without an X11 session, you need to start a vncserver:
-   ::
+   without an X11 session, you need to start a vncserver::
 
       $ vncserver :1
       $ export DISPLAY=:1
@@ -3064,45 +2979,38 @@
 This next set of examples describes how to use the AUH:
 
 -  *Upgrading a Specific Recipe:* To upgrade a specific recipe, use the
-   following form:
-   ::
+   following form::
 
       $ upgrade-helper.py recipe_name
 
-   For example, this command upgrades the ``xmodmap`` recipe:
-   ::
+   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:
-   ::
+   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:
-   ::
+   For example, this command upgrades the ``xmodmap`` recipe to version 1.2.3::
 
       $ upgrade-helper.py xmodmap -t 1.2.3
 
 -  *Upgrading all Recipes to the Latest Versions and Suppressing Email
    Notifications:* To upgrade all recipes to their most recent versions
-   and suppress the email notifications, use the following command:
-   ::
+   and suppress the email notifications, use the following command::
 
       $ upgrade-helper.py all
 
 -  *Upgrading all Recipes to the Latest Versions and Send Email
    Notifications:* To upgrade all recipes to their most recent versions
    and send email messages to maintainers for each attempted recipe as
-   well as a status email, use the following command:
-   ::
+   well as a status email, use the following command::
 
       $ upgrade-helper.py -e all
 
 Once you have run the AUH utility, you can find the results in the AUH
-build directory:
-::
+build directory::
 
    ${BUILDDIR}/upgrade-helper/timestamp
 
@@ -3127,15 +3035,13 @@
 Software Development Kit (eSDK) Manual.
 
 To see all the command-line options available with ``devtool upgrade``,
-use the following help command:
-::
+use the following help command::
 
    $ devtool upgrade -h
 
 If you want to find out what version a recipe is currently at upstream
 without any attempt to upgrade your local version of the recipe, you can
-use the following command:
-::
+use the following command::
 
    $ devtool latest-version recipe_name
 
@@ -3161,15 +3067,13 @@
 ":ref:`bitbake-layers <bsp-guide/bsp:creating a new bsp layer using the \`\`bitbake-layers\`\` script>`"
 script. For example, suppose you use the ``nano.bb`` recipe from the
 ``meta-oe`` layer in the ``meta-openembedded`` repository. For this
-example, assume that the layer has been cloned into following area:
-::
+example, assume that the layer has been cloned into following area::
 
    /home/scottrif/meta-openembedded
 
 The following command from your
 :term:`Build Directory` adds the layer to
-your build configuration (i.e. ``${BUILDDIR}/conf/bblayers.conf``):
-::
+your build configuration (i.e. ``${BUILDDIR}/conf/bblayers.conf``)::
 
    $ bitbake-layers add-layer /home/scottrif/meta-openembedded/meta-oe
    NOTE: Starting bitbake server...
@@ -3210,8 +3114,7 @@
    NOTE: New recipe is /home/scottrif/poky/build/workspace/recipes/nano/nano_2.9.3.bb
 
 Continuing with this example, you can use ``devtool build`` to build the
-newly upgraded recipe:
-::
+newly upgraded recipe::
 
    $ devtool build nano
    NOTE: Starting bitbake server...
@@ -3236,8 +3139,7 @@
 
 Once the tree is clean, you can clean things up in this example with the
 following command from the ``${BUILDDIR}/workspace/sources/nano``
-directory:
-::
+directory::
 
    $ devtool finish nano meta-oe
    NOTE: Starting bitbake server...
@@ -3341,8 +3243,7 @@
 :term:`S` variable. Below is the default
 value for the ``S`` variable as defined in the
 ``meta/conf/bitbake.conf`` configuration file in the
-:term:`Source Directory`:
-::
+:term:`Source Directory`::
 
    S = "${WORKDIR}/${BP}"
 
@@ -3353,16 +3254,14 @@
 .. note::
 
    The :term:`BP` represents the base recipe name, which consists of the name
-   and version:
-   ::
+   and version::
 
            BP = "${BPN}-${PV}"
 
 
 The path to the work directory for the recipe
 (:term:`WORKDIR`) is defined as
-follows:
-::
+follows::
 
    ${TMPDIR}/work/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}
 
@@ -3388,8 +3287,7 @@
 ``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:
-::
+build system uses to build the package would be as follows::
 
    poky/build/tmp/work/qemux86-poky-linux/foo/1.3.0-r0
 
@@ -3426,15 +3324,13 @@
 
 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:
-   ::
+   below::
 
       $ quilt new my_changes.patch
 
 4. *Notify Quilt and Add Files:* After creating the patch, you need to
    notify Quilt about the files you plan to edit. You notify Quilt by
-   adding the files to the patch you just created:
-   ::
+   adding the files to the patch you just created::
 
       $ quilt add file1.c file2.c file3.c
 
@@ -3443,8 +3339,7 @@
 
 6. *Test Your Changes:* Once you have modified the source code, the
    easiest way to test your changes is by calling the ``do_compile``
-   task as shown in the following example:
-   ::
+   task as shown in the following example::
 
       $ bitbake -c compile -f package
 
@@ -3481,8 +3376,7 @@
    that holds the recipe (``.bb``) file or the append (``.bbappend``)
    file. Placing the patch here guarantees that the OpenEmbedded build
    system will find the patch. Next, add the patch into the ``SRC_URI``
-   of the recipe. Here is an example:
-   ::
+   of the recipe. Here is an example::
 
       SRC_URI += "file://my_changes.patch"
 
@@ -3503,8 +3397,7 @@
 be used with the OpenEmbedded build system.
 
 Following is an example that uses ``devshell`` on a target named
-``matchbox-desktop``:
-::
+``matchbox-desktop``::
 
   $ bitbake matchbox-desktop -c devshell
 
@@ -3533,8 +3426,7 @@
 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``:
-::
+``devshell``::
 
    $ bitbake -c task
 
@@ -3581,8 +3473,7 @@
 Python objects and code are available in the same way they are to
 BitBake tasks, in particular, the data store 'd'. So, commands such as
 the following are useful when exploring the data store and running
-functions:
-::
+functions::
 
    pydevshell> d.getVar("STAGING_DIR")
    '/media/build1/poky/build/tmp/sysroots'
@@ -3602,8 +3493,7 @@
 OpenEmbedded build system.
 
 Following is an example that uses ``devpyshell`` on a target named
-``matchbox-desktop``:
-::
+``matchbox-desktop``::
 
    $ bitbake matchbox-desktop -c devpyshell
 
@@ -3664,8 +3554,7 @@
 
 2. *Initialize the Build Environment:* Initialize the build environment
    by sourcing the build environment script (i.e.
-   :ref:`structure-core-script`):
-   ::
+   :ref:`structure-core-script`)::
 
       $ source oe-init-build-env [build_dir]
 
@@ -3690,8 +3579,7 @@
    and a centralized tarball download directory through the
    :term:`DL_DIR` variable.
 
-4. *Build the Image:* Build the image using the ``bitbake`` command:
-   ::
+4. *Build the Image:* Build the image using the ``bitbake`` command::
 
       $ bitbake target
 
@@ -3710,8 +3598,7 @@
    Project Reference Manual.
 
    As an example, the following command builds the
-   ``core-image-minimal`` image:
-   ::
+   ``core-image-minimal`` image::
 
       $ bitbake core-image-minimal
 
@@ -3763,8 +3650,7 @@
 
    Here is an example showing the minimal statements needed in a
    configuration file for a "qemux86" target whose temporary build
-   directory is ``tmpmultix86``:
-   ::
+   directory is ``tmpmultix86``::
 
       MACHINE = "qemux86"
       TMPDIR = "${TOPDIR}/tmpmultix86"
@@ -3789,8 +3675,7 @@
    variable in your ``conf/local.conf`` configuration file to specify
    each multiconfig. Continuing with the example from the previous
    figure, the ``BBMULTICONFIG`` variable needs to enable two
-   multiconfigs: "x86" and "arm" by specifying each configuration file:
-   ::
+   multiconfigs: "x86" and "arm" by specifying each configuration file::
 
       BBMULTICONFIG = "x86 arm"
 
@@ -3804,13 +3689,11 @@
       with "".
 
 -  *Launch BitBake*: Use the following BitBake command form to launch
-   the multiple configuration build:
-   ::
+   the multiple configuration build::
 
       $ bitbake [mc:multiconfigname:]target [[[mc:multiconfigname:]target] ... ]
 
-   For the example in this section, the following command applies:
-   ::
+   For the example in this section, the following command applies::
 
       $ bitbake mc:x86:core-image-minimal mc:arm:core-image-sato mc::core-image-base
 
@@ -3844,15 +3727,13 @@
 
 To enable dependencies in a multiple configuration build, you must
 declare the dependencies in the recipe using the following statement
-form:
-::
+form::
 
    task_or_package[mcdepends] = "mc:from_multiconfig:to_multiconfig:recipe_name:task_on_which_to_depend"
 
 To better show how to use this statement, consider the example scenario
 from the first paragraph of this section. The following statement needs
-to be added to the recipe that builds the ``core-image-sato`` image:
-::
+to be added to the recipe that builds the ``core-image-sato`` image::
 
    do_image[mcdepends] = "mc:x86:arm:core-image-minimal:do_rootfs"
 
@@ -3862,8 +3743,7 @@
 with the "arm" multiconfig.
 
 Once you set up this dependency, you can build the "x86" multiconfig
-using a BitBake command as follows:
-::
+using a BitBake command as follows::
 
    $ bitbake mc:x86:core-image-sato
 
@@ -3874,8 +3754,7 @@
 
 Having a recipe depend on the root filesystem of another build might not
 seem that useful. Consider this change to the statement in the
-``core-image-sato`` recipe:
-::
+``core-image-sato`` recipe::
 
    do_image[mcdepends] = "mc:x86:arm:core-image-minimal:do_image"
 
@@ -4091,8 +3970,7 @@
 filesystem itself or select a different filesystem.
 
 First, find out what is hogging your root filesystem by running the
-``dirsize.py`` script from your root directory:
-::
+``dirsize.py`` script from your root directory::
 
    $ cd root-directory-of-image
    $ dirsize.py 100000 > dirsize-100k.log
@@ -4107,8 +3985,7 @@
 
 You need to be sure that what you eliminate does not cripple the
 functionality you need. One way to see how packages relate to each other
-is by using the Dependency Explorer UI with the BitBake command:
-::
+is by using the Dependency Explorer UI with the BitBake command::
 
    $ cd image-directory
    $ bitbake -u taskexp -g image
@@ -4124,8 +4001,7 @@
 
 Use your ``local.conf`` file to make changes. For example, to eliminate
 ``udev`` and ``glib``, set the following in the local configuration
-file:
-::
+file::
 
    VIRTUAL-RUNTIME_dev_manager = ""
 
@@ -4153,8 +4029,7 @@
    You can modify the kernel source if you want to help with boot time.
 
 Run the ``ksize.py`` script from the top-level Linux build directory to
-get an idea of what is making up the kernel:
-::
+get an idea of what is making up the kernel::
 
    $ cd top-level-linux-build-directory
    $ ksize.py > ksize.log
@@ -4168,8 +4043,7 @@
 and taking up around the "90% rule."
 
 To examine, or drill down, into any particular area, use the ``-d``
-option with the script:
-::
+option with the script::
 
    $ ksize.py -d > ksize.log
 
@@ -4316,8 +4190,7 @@
    machine-architecture dependent, make sure your recipe enables the
    "machine" package architecture through the
    :term:`MACHINE_ARCH`
-   variable:
-   ::
+   variable::
 
       PACKAGE_ARCH = "${MACHINE_ARCH}"
 
@@ -4325,8 +4198,7 @@
    specifically enable a package architecture through the
    :term:`PACKAGE_ARCH`, The
    OpenEmbedded build system defaults to the
-   :term:`TUNE_PKGARCH` setting:
-   ::
+   :term:`TUNE_PKGARCH` setting::
 
       PACKAGE_ARCH = "${TUNE_PKGARCH}"
 
@@ -4426,15 +4298,13 @@
 and then set the
 :term:`EXTERNALSRC` variable to
 point to your external source code. Here are the statements to put in
-your ``local.conf`` file:
-::
+your ``local.conf`` file::
 
    INHERIT += "externalsrc"
    EXTERNALSRC_pn-myrecipe = "path-to-your-source-tree"
 
 This next example shows how to accomplish the same thing by setting
-``EXTERNALSRC`` in the recipe itself or in the recipe's append file:
-::
+``EXTERNALSRC`` in the recipe itself or in the recipe's append file::
 
    EXTERNALSRC = "path"
    EXTERNALSRC_BUILD = "path"
@@ -4451,8 +4321,7 @@
 to have the source built in the same directory in which it resides, or
 some other nominated directory, you can set
 :term:`EXTERNALSRC_BUILD`
-to point to that directory:
-::
+to point to that directory::
 
    EXTERNALSRC_BUILD_pn-myrecipe = "path-to-your-source-tree"
 
@@ -4475,8 +4344,7 @@
    an empty location or one that does not yet exist.
 
 2. *Generate Tarballs of the Source Git Repositories:* Edit your
-   ``local.conf`` configuration file as follows:
-   ::
+   ``local.conf`` configuration file as follows::
 
       DL_DIR = "/home/your-download-dir/"
       BB_GENERATE_MIRROR_TARBALLS = "1"
@@ -4489,8 +4357,7 @@
    variable for more information.
 
 3. *Populate Your Downloads Directory Without Building:* Use BitBake to
-   fetch your sources but inhibit the build:
-   ::
+   fetch your sources but inhibit the build::
 
       $ bitbake target --runonly=fetch
 
@@ -4536,8 +4403,7 @@
    ``${``\ :term:`TMPDIR`\ ``}``
    directory or using a new :term:`Build Directory`.
 
-3. *Build Your Target:* Use BitBake to build your target:
-   ::
+3. *Build Your Target:* Use BitBake to build your target::
 
       $ bitbake target
 
@@ -4550,8 +4416,7 @@
       The offline build does not work if recipes attempt to find the
       latest version of software by setting
       :term:`SRCREV` to
-      ``${``\ :term:`AUTOREV`\ ``}``:
-      ::
+      ``${``\ :term:`AUTOREV`\ ``}``::
 
          SRCREV = "${AUTOREV}"
 
@@ -4670,8 +4535,7 @@
 -  Disable static library generation for recipes derived from
    ``autoconf`` or ``libtool``: Following is an example showing how to
    disable static libraries and still provide an override to handle
-   exceptions:
-   ::
+   exceptions::
 
       STATICLIBCONF = "--disable-static"
       STATICLIBCONF_sqlite3-native = ""
@@ -4726,8 +4590,7 @@
    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:
-::
+how the static library files are defined::
 
    PACKAGE_BEFORE_PN ?= ""
    PACKAGES = "${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_PN} ${PN}"
@@ -4833,8 +4696,7 @@
 combination of multiple libraries you want to build. You accomplish this
 through your ``local.conf`` configuration file in the
 :term:`Build Directory`. An example
-configuration would be as follows:
-::
+configuration would be as follows::
 
    MACHINE = "qemux86-64"
    require conf/multilib.conf
@@ -4850,14 +4712,12 @@
 
 The example then includes ``lib32-glib-2.0`` in all the images, which
 illustrates one method of including a multiple library dependency. You
-can use a normal image build to include this dependency, for example:
-::
+can use a normal image build to include this dependency, for example::
 
    $ bitbake core-image-sato
 
 You can also build Multilib packages
-specifically with a command like this:
-::
+specifically with a command like this::
 
    $ bitbake lib32-glib-2.0
 
@@ -4952,8 +4812,7 @@
 the :term:`DEPENDS` variable to
 create the dependency. Continuing with the same example, if you want to
 have a recipe depend on the 1.8 version of the ``clutter`` library, use
-the following in your recipe:
-::
+the following in your recipe::
 
    DEPENDS = "clutter-1.8"
 
@@ -4996,8 +4855,7 @@
 -  Support for large images exists.
 
 To use the x32 psABI, you need to edit your ``conf/local.conf``
-configuration file as follows:
-::
+configuration file as follows::
 
    MACHINE = "qemux86-64"
    DEFAULTTUNE = "x86-64-x32"
@@ -5006,8 +4864,7 @@
 
 Once you have set
 up your configuration file, use BitBake to build an image that supports
-the x32 psABI. Here is an example:
-::
+the x32 psABI. Here is an example::
 
    $ bitbake core-image-sato
 
@@ -5066,8 +4923,7 @@
 3. Try to build the recipe. If you encounter build errors that look like
    something is unable to find ``.so`` libraries, check where these
    libraries are located in the source tree and add the following to the
-   recipe:
-   ::
+   recipe::
 
       GIR_EXTRA_LIBS_PATH = "${B}/something/.libs"
 
@@ -5097,8 +4953,7 @@
 combination. If so, you can use either of the following methods to
 disable GIR file generations:
 
--  Add the following to your distro configuration:
-   ::
+-  Add the following to your distro configuration::
 
       DISTRO_FEATURES_BACKFILL_CONSIDERED = "gobject-introspection-data"
 
@@ -5106,8 +4961,7 @@
    QEMU but will still enable building introspection tools and libraries
    (i.e. building them does not require the use of QEMU).
 
--  Add the following to your machine configuration:
-   ::
+-  Add the following to your machine configuration::
 
       MACHINE_FEATURES_BACKFILL_CONSIDERED = "qemu-usermode"
 
@@ -5140,8 +4994,7 @@
 
 3. Launch a Terminal and then start Python in the terminal.
 
-4. Enter the following in the terminal:
-   ::
+4. Enter the following in the terminal::
 
       >>> from gi.repository import GLib
       >>> GLib.get_host_name()
@@ -5289,8 +5142,7 @@
    form generated by the OpenEmbedded build system.
 
 -  You must build several native tools, which are built to run on the
-   build system:
-   ::
+   build system::
 
       $ bitbake parted-native dosfstools-native mtools-native
 
@@ -5306,8 +5158,7 @@
 
 You can get general help for the ``wic`` command by entering the ``wic``
 command by itself or by entering the command with a help argument as
-follows:
-::
+follows::
 
    $ wic -h
    $ wic --help
@@ -5315,32 +5166,27 @@
 
 Currently, Wic supports seven commands: ``cp``, ``create``, ``help``,
 ``list``, ``ls``, ``rm``, and ``write``. You can get help for all these
-commands except "help" by using the following form:
-::
+commands except "help" by using the following form::
 
    $ wic help command
 
 For example, the following command returns help for the ``write``
-command:
-::
+command::
 
    $ wic help write
 
 Wic supports help for three topics: ``overview``, ``plugins``, and
-``kickstart``. You can get help for any topic using the following form:
-::
+``kickstart``. You can get help for any topic using the following form::
 
    $ wic help topic
 
-For example, the following returns overview help for Wic:
-::
+For example, the following returns overview help for Wic::
 
    $ wic help overview
 
 One additional level of help exists for Wic. You can get help on
 individual images through the ``list`` command. You can use the ``list``
-command to return the available Wic images as follows:
-::
+command to return the available Wic images as follows::
 
    $ wic list images
      genericx86                    		Create an EFI disk image for genericx86*
@@ -5359,8 +5205,7 @@
 Once you know the list of available
 Wic images, you can use ``help`` with the command to get help on a
 particular image. For example, the following command returns help on the
-"beaglebone-yocto" image:
-::
+"beaglebone-yocto" image::
 
    $ wic list beaglebone-yocto help
 
@@ -5397,8 +5242,7 @@
 Contrast this behavior with cooked mode where Wic looks in the Build
 Directory (e.g. ``tmp/deploy/images/``\ machine).
 
-The general form of the ``wic`` command in raw mode is:
-::
+The general form of the ``wic`` command in raw mode is::
 
    $ wic create wks_file options ...
 
@@ -5456,8 +5300,7 @@
 by using the "-e" option. Wic looks in the Build Directory (e.g.
 ``tmp/deploy/images/``\ machine) for artifacts.
 
-The general form of the ``wic`` command using Cooked Mode is as follows:
-::
+The general form of the ``wic`` command using Cooked Mode is as follows::
 
    $ wic create wks_file -e IMAGE_NAME
 
@@ -5480,14 +5323,12 @@
 If you do not want to create your own kickstart file, you can use an
 existing file provided by the Wic installation. As shipped, kickstart
 files can be found in the :ref:`overview-manual/development-environment:yocto project source repositories` in the
-following two locations:
-::
+following two locations::
 
    poky/meta-yocto-bsp/wic
    poky/scripts/lib/wic/canned-wks
 
-Use the following command to list the available kickstart files:
-::
+Use the following command to list the available kickstart files::
 
    $ wic list images
      genericx86                    		Create an EFI disk image for genericx86*
@@ -5505,15 +5346,13 @@
 
 When you use an existing file, you
 do not have to use the ``.wks`` extension. Here is an example in Raw
-Mode that uses the ``directdisk`` file:
-::
+Mode that uses the ``directdisk`` file::
 
    $ wic create directdisk -r rootfs_dir -b bootimg_dir \
          -k kernel_dir -n native_sysroot
 
 Here are the actual partition language commands used in the
-``genericx86.wks`` file to generate an image:
-::
+``genericx86.wks`` file to generate an image::
 
    # short-description: Create an EFI disk image for genericx86*
    # long-description: Creates a partitioned EFI disk image for genericx86* machines
@@ -5571,8 +5410,7 @@
 implementation, it looks for the plugin with the same name as the
 ``--source`` parameter used in the kickstart file given to that
 partition. For example, if the partition is set up using the following
-command in a kickstart file:
-::
+command in a kickstart file::
 
    part /boot --source bootimg-pcbios --ondisk sda --label boot --active --align 1024
 
@@ -5583,8 +5421,7 @@
 To be more concrete, here is the corresponding plugin definition from
 the ``bootimg-pcbios.py`` file for the previous command along with an
 example method called by the Wic implementation when it needs to prepare
-a partition using an implementation-specific function:
-::
+a partition using an implementation-specific function::
 
                 .
                 .
@@ -5675,8 +5512,7 @@
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 This example runs in Cooked Mode and uses the ``mkefidisk`` kickstart
-file:
-::
+file::
 
    $ wic create mkefidisk -e core-image-minimal
    INFO: Building wic-tools...
@@ -5712,8 +5548,7 @@
 Continuing with the example, you can now write the image from the Build
 Directory onto a USB stick, or whatever media for which you built your
 image, and boot from the media. You can write the image by using
-``bmaptool`` or ``dd``:
-::
+``bmaptool`` or ``dd``::
 
    $ oe-run-native bmaptool copy mkefidisk-201804191017-sda.direct /dev/sdX
 
@@ -5761,8 +5596,7 @@
 Next, the example modifies the ``directdisksdb-gpt.wks`` file and
 changes all instances of "``--ondisk sda``" to "``--ondisk sdb``". The
 example changes the following two lines and leaves the remaining lines
-untouched:
-::
+untouched::
 
    part /boot --source bootimg-pcbios --ondisk sdb --label boot --active --align 1024
    part / --source rootfs --ondisk sdb --fstype=ext4 --label platform --align 1024 --use-uuid
@@ -5799,8 +5633,7 @@
 
 Continuing with the example, you can now directly ``dd`` the image to a
 USB stick, or whatever media for which you built your image, and boot
-the resulting media:
-::
+the resulting media::
 
    $ sudo dd if=directdisksdb-gpt-201710090938-sdb.direct of=/dev/sdb
    140966+0 records in
@@ -5814,8 +5647,7 @@
 This next example manually specifies each build artifact (runs in Raw
 Mode) and uses a modified kickstart file. The example also uses the
 ``-o`` option to cause Wic to create the output somewhere other than the
-default output directory, which is the current directory:
-::
+default output directory, which is the current directory::
 
    $ wic create /home/stephano/my_yocto/test.wks -o /home/stephano/testwic \
         --rootfs-dir /home/stephano/build/master/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/rootfs \
@@ -5860,8 +5692,7 @@
 the existing kernel, and then inserts a new kernel:
 
 1. *List the Partitions:* Use the ``wic ls`` command to list all the
-   partitions in the Wic image:
-   ::
+   partitions in the Wic image::
 
       $ wic ls tmp/deploy/images/qemux86/core-image-minimal-qemux86.wic
       Num     Start        End          Size      Fstype
@@ -5877,8 +5708,7 @@
    .. note::
 
       You can get command usage on any Wic command using the following
-      form:
-      ::
+      form::
 
               $ wic help command
 
@@ -5886,14 +5716,12 @@
       For example, the following command shows you the various ways to
       use the
       wic ls
-      command:
-      ::
+      command::
 
               $ wic help ls
 
 
-   The following command shows what is in partition one:
-   ::
+   The following command shows what is in partition one::
 
         $ wic ls tmp/deploy/images/qemux86/core-image-minimal-qemux86.wic:1
         Volume in drive : is boot
@@ -5915,8 +5743,7 @@
 
       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:
-      ::
+      in the file. Then, run the Wic command again::
 
               ERROR: _exec_cmd: /usr/bin/mdir -i /tmp/wic-parttfokuwra ::/ returned '1' instead of 0
                output: Total number of sectors (47824) not a multiple of sectors per track (32)!
@@ -5924,8 +5751,7 @@
 
 
 3. *Remove the Old Kernel:* Use the ``wic rm`` command to remove the
-   ``vmlinuz`` file (kernel):
-   ::
+   ``vmlinuz`` file (kernel)::
 
       $ wic rm tmp/deploy/images/qemux86/core-image-minimal-qemux86.wic:1/vmlinuz
 
@@ -5937,8 +5763,7 @@
    kernel will be in the ``workspace/sources`` area.
 
    The following example assumes ``devtool`` was used to build the
-   kernel:
-   ::
+   kernel::
 
       $ wic cp poky_sdk/tmp/work/qemux86-poky-linux/linux-yocto/4.12.12+git999-r0/linux-yocto-4.12.12+git999/arch/x86/boot/bzImage \
                poky/build/tmp/deploy/images/qemux86/core-image-minimal-qemux86.wic:1/vmlinuz
@@ -5968,14 +5793,12 @@
    -  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:
-      ::
+      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:
-      ::
+      need to build Bmaptool before using it. Use the following command::
 
          $ bitbake bmap-tools-native
 
@@ -5984,15 +5807,13 @@
 any type of image. Use these steps to flash an image using Bmaptool:
 
 1. *Update your local.conf File:* You need to have the following set
-   in your ``local.conf`` file before building your image:
-   ::
+   in your ``local.conf`` file before building your image::
 
       IMAGE_FSTYPES += "wic wic.bmap"
 
 2. *Get Your Image:* Either have your image ready (pre-built with the
    :term:`IMAGE_FSTYPES`
-   setting previously mentioned) or take the step to build the image:
-   ::
+   setting previously mentioned) or take the step to build the image::
 
       $ bitbake image
 
@@ -6000,20 +5821,17 @@
    depending on your particular setup. The following commands assume the
    image resides in the Build Directory's ``deploy/images/`` area:
 
-   -  If you have write access to the media, use this command form:
-      ::
+   -  If you have write access to the media, use this command form::
 
          $ oe-run-native bmap-tools-native bmaptool copy build-directory/tmp/deploy/images/machine/image.wic /dev/sdX
 
    -  If you do not have write access to the media, set your permissions
-      first and then use the same command form:
-      ::
+      first and then use the same command form::
 
          $ sudo chmod 666 /dev/sdX
          $ oe-run-native bmap-tools-native bmaptool copy build-directory/tmp/deploy/images/machine/image.wic /dev/sdX
 
-For help on the ``bmaptool`` command, use the following command:
-::
+For help on the ``bmaptool`` command, use the following command::
 
    $ bmaptool --help
 
@@ -6107,8 +5925,7 @@
 
 Use the following line in your ``local.conf`` file or in your custom
 distribution configuration file to enable the security compiler and
-linker flags for your build:
-::
+linker flags for your build::
 
    require conf/distro/include/security_flags.inc
 
@@ -6123,8 +5940,7 @@
    When creating a new project, the default is to provide you with an
    initial ``local.conf`` file that enables this feature using the
    :term:`EXTRA_IMAGE_FEATURES`
-   variable with the line:
-   ::
+   variable with the line::
 
       EXTRA_IMAGE_FEATURES = "debug-tweaks"
 
@@ -6250,8 +6066,7 @@
    :term:`DISTRO` variable to point to
    your distribution's configuration file. For example, if your
    distribution's configuration file is named ``mydistro.conf``, then
-   you point to it as follows:
-   ::
+   you point to it as follows::
 
       DISTRO = "mydistro"
 
@@ -6292,8 +6107,7 @@
 configuration information that ultimately ends up in the
 :term:`Build Directory` ``conf`` directory.
 By default, ``TEMPLATECONF`` is set as follows in the ``poky``
-repository:
-::
+repository::
 
    TEMPLATECONF=${TEMPLATECONF:-meta-poky/conf}
 
@@ -6335,8 +6149,7 @@
 targets appears as part of the script's output.
 
 Here is the default list of targets displayed as a result of running
-either of the setup scripts:
-::
+either of the setup scripts::
 
    You can now run 'bitbake <target>'
 
@@ -6355,8 +6168,7 @@
 
 To help conserve disk space during builds, you can add the following
 statement to your project's ``local.conf`` configuration file found in
-the :term:`Build Directory`:
-::
+the :term:`Build Directory`::
 
    INHERIT += "rm_work"
 
@@ -6534,8 +6346,7 @@
 development system that builds the package feed (building system). For
 this scenario, you can enable a local PR Service by setting
 :term:`PRSERV_HOST` in your
-``local.conf`` file in the :term:`Build Directory`:
-::
+``local.conf`` file in the :term:`Build Directory`::
 
    PRSERV_HOST = "localhost:0"
 
@@ -6546,8 +6357,7 @@
 If you have a more complex setup where multiple host development systems
 work against a common, shared package feed, you have a single PR Service
 running and it is connected to each building system. For this scenario,
-you need to start the PR Service using the ``bitbake-prserv`` command:
-::
+you need to start the PR Service using the ``bitbake-prserv`` command::
 
    bitbake-prserv --host ip --port port --start
 
@@ -6559,8 +6369,7 @@
 It is also recommended you use build history, which adds some sanity
 checks to binary package versions, in conjunction with the server that
 is running the PR Service. To enable build history, add the following to
-each building system's ``local.conf`` file:
-::
+each building system's ``local.conf`` file::
 
    # It is recommended to activate "buildhistory" for testing the PR service
    INHERIT += "buildhistory"
@@ -6629,15 +6438,13 @@
 ``SRCREV`` variable to
 :term:`AUTOREV` to cause the
 OpenEmbedded build system to automatically use the latest revision of
-the software:
-::
+the software::
 
    SRCREV = "${AUTOREV}"
 
 Furthermore, you need to reference ``SRCPV`` in ``PV`` in order to
 automatically update the version whenever the revision of the source
-code changes. Here is an example:
-::
+code changes. Here is an example::
 
    PV = "1.0+git${SRCPV}"
 
@@ -6707,8 +6514,7 @@
 :term:`PACKAGES` variable and
 setting the appropriate values for ``FILES_packagename``,
 ``RDEPENDS_packagename``, ``DESCRIPTION_packagename``, and so forth.
-Here is an example from the ``lighttpd`` recipe:
-::
+Here is an example from the ``lighttpd`` recipe::
 
    python populate_packages_prepend () {
        lighttpd_libdir = d.expand('${libdir}')
@@ -6751,8 +6557,7 @@
 also find examples in ``meta/classes/kernel.bbclass``.
 
 Following is a reference that shows ``do_split_packages`` mandatory and
-optional arguments:
-::
+optional arguments::
 
    Mandatory arguments
 
@@ -6840,8 +6645,7 @@
 your recipe. You can be sure these dependencies are satisfied by using
 the :term:`PACKAGES_DYNAMIC`
 variable. Here is an example that continues with the ``lighttpd`` recipe
-shown earlier:
-::
+shown earlier::
 
    PACKAGES_DYNAMIC = "lighttpd-module-.*"
 
@@ -6933,8 +6737,7 @@
    :term:`Build Directory` (e.g.
    ``poky/build/conf/local.conf``).
 
-2. Select the desired package format as follows:
-   ::
+2. Select the desired package format as follows::
 
       PACKAGE_CLASSES ?= "package_packageformat"
 
@@ -6968,15 +6771,13 @@
 Whenever you perform any sort of build step that can potentially
 generate a package or modify existing package, it is always a good idea
 to re-generate the package index after the build by using the following
-command:
-::
+command::
 
    $ bitbake package-index
 
 It might be tempting to build the
 package and the package index at the same time with a command such as
-the following:
-::
+the following::
 
    $ bitbake some-package package-index
 
@@ -7024,8 +6825,7 @@
 :term:`PACKAGE_CLASSES`
 setting), simply start the server. The following example assumes a build
 directory of ``poky/build/tmp/deploy/rpm`` and a ``PACKAGE_CLASSES``
-setting of "package_rpm":
-::
+setting of "package_rpm"::
 
    $ cd poky/build/tmp/deploy/rpm
    $ python3 -m http.server
@@ -7091,8 +6891,7 @@
    architectures.
 
 -  *Create a Single (Full) Package Index:* Define a single base URL that
-   identifies where a full package database is located:
-   ::
+   identifies where a full package database is located::
 
       [oe-packages]
       baseurl=http://my.server/rpm
@@ -7210,8 +7009,7 @@
 
 To enable signing RPM packages, you must set up the following
 configurations in either your ``local.config`` or ``distro.config``
-file:
-::
+file::
 
    # Inherit sign_rpm.bbclass to enable signing functionality
    INHERIT += " sign_rpm"
@@ -7242,8 +7040,7 @@
 
 The steps you need to take to enable signed package feed use are similar
 to the steps used to sign RPM packages. You must define the following in
-your ``local.config`` or ``distro.config`` file:
-::
+your ``local.config`` or ``distro.config`` file::
 
    INHERIT += "sign_package_feed"
    PACKAGE_FEED_GPG_NAME = "key_name"
@@ -7282,8 +7079,7 @@
 binary and checks the output to an elaborate system of test binaries and
 data files.
 
-The test generates output in the format used by Automake:
-::
+The test generates output in the format used by Automake::
 
    result: testname
 
@@ -7305,8 +7101,7 @@
 :term:`DISTRO_FEATURES` and
 :term:`EXTRA_IMAGE_FEATURES`
 variables to your ``local.conf`` file, which is found in the
-:term:`Build Directory`:
-::
+:term:`Build Directory`::
 
    DISTRO_FEATURES_append = " ptest"
    EXTRA_IMAGE_FEATURES += "ptest-pkgs"
@@ -7331,16 +7126,14 @@
 
 -  *Be sure the recipe inherits
    the* :ref:`ptest <ref-classes-ptest>` *class:*
-   Include the following line in each recipe:
-   ::
+   Include the following line in each recipe::
 
       inherit ptest
 
 -  *Create run-ptest:* This script starts your test. Locate the
    script where you will refer to it using
    :term:`SRC_URI`. Here is an
-   example that starts a test for ``dbus``:
-   ::
+   example that starts a test for ``dbus``::
 
       #!/bin/sh
       cd test
@@ -7352,8 +7145,7 @@
    :term:`DEPENDS` and
    :term:`RDEPENDS` variables in
    your recipe in order for the package to meet the dependencies. Here
-   is an example where the package has a runtime dependency on "make":
-   ::
+   is an example where the package has a runtime dependency on "make"::
 
       RDEPENDS_${PN}-ptest += "make"
 
@@ -7374,8 +7166,7 @@
 
    Regardless, you still must add a ``do_compile_ptest`` function to
    build the test suite. Add a function similar to the following to your
-   recipe:
-   ::
+   recipe::
 
       do_compile_ptest() {
           oe_runmake buildtest-TESTS
@@ -7457,8 +7248,7 @@
    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:
-::
+create the recipe::
 
    $ devtool add "npm://registry.npmjs.org;package=cute-files;version=1.0.2"
 
@@ -7486,8 +7276,7 @@
    practical way to have the licenses for all of the dependencies
    represented in the license manifest of the image.
 
-The ``devtool edit-recipe`` command lets you take a look at the recipe:
-::
+The ``devtool edit-recipe`` command lets you take a look at the recipe::
 
    $ devtool edit-recipe cute-files
    SUMMARY = "Turn any folder on your computer into a cute file browser, available on the local network."
@@ -7520,8 +7309,7 @@
    :ref:`npm <ref-classes-npm>` class to package
    up all the modules.
 
-You can run the following command to build the ``cute-files`` package:
-::
+You can run the following command to build the ``cute-files`` package::
 
    $ devtool build cute-files
 
@@ -7529,8 +7317,7 @@
 the target before your package.
 
 Assuming 192.168.7.2 for the target's IP address, use the following
-command to deploy your package:
-::
+command to deploy your package::
 
    $ devtool deploy-target -s cute-files root@192.168.7.2
 
@@ -7569,15 +7356,13 @@
 source files.
 
 Replicating the same example, (i.e. ``cute-files``) use the following
-command:
-::
+command::
 
    $ devtool add https://github.com/martinaglv/cute-files.git
 
 The
 recipe this command generates is very similar to the recipe created in
-the previous section. However, the ``SRC_URI`` looks like the following:
-::
+the previous section. However, the ``SRC_URI`` looks like the following::
 
    SRC_URI = " \
        git://github.com/martinaglv/cute-files.git;protocol=https \
@@ -7629,8 +7414,7 @@
 variable flag ``separator``.
 
 The following is an example that adds two custom fields for ipk
-packages:
-::
+packages::
 
    PACKAGE_ADD_METADATA_IPK = "Vendor: CustomIpk\nGroup:Applications/Spreadsheets"
 
@@ -7660,8 +7444,7 @@
 checks local directories first for existing tarballs before checking the
 Internet.
 
-Here is an efficient way to set it up in your ``local.conf`` file:
-::
+Here is an efficient way to set it up in your ``local.conf`` file::
 
    SOURCE_MIRROR_URL ?= "file:///home/you/your-download-dir/"
    INHERIT += "own-mirrors"
@@ -7692,8 +7475,7 @@
 which is located with :term:`DL_DIR`.
 
 Use the following BitBake command form to fetch all the necessary
-sources without starting the build:
-::
+sources without starting the build::
 
    $ bitbake target --runall=fetch
 
@@ -7740,15 +7522,13 @@
 Using systemd Exclusively
 -------------------------
 
-Set these variables in your distribution configuration file as follows:
-::
+Set these variables in your distribution configuration file as follows::
 
    DISTRO_FEATURES_append = " systemd"
    VIRTUAL-RUNTIME_init_manager = "systemd"
 
 You can also prevent the SysVinit distribution feature from
-being automatically enabled as follows:
-::
+being automatically enabled as follows::
 
    DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
 
@@ -7756,8 +7536,7 @@
 redundant SysVinit scripts.
 
 To remove initscripts from your image altogether, set this variable
-also:
-::
+also::
 
    VIRTUAL-RUNTIME_initscripts = ""
 
@@ -7767,8 +7546,7 @@
 Using systemd for the Main Image and Using SysVinit for the Rescue Image
 ------------------------------------------------------------------------
 
-Set these variables in your distribution configuration file as follows:
-::
+Set these variables in your distribution configuration file as follows::
 
    DISTRO_FEATURES_append = " systemd"
    VIRTUAL-RUNTIME_init_manager = "systemd"
@@ -7800,8 +7578,7 @@
 
 To use the static method for device population, you need to set the
 :term:`USE_DEVFS` variable to "0"
-as follows:
-::
+as follows::
 
    USE_DEVFS = "0"
 
@@ -7813,8 +7590,7 @@
 variable in your ``local.conf`` configuration file.
 
 If you do not define the ``IMAGE_DEVICE_TABLES`` variable, the default
-``device_table-minimal.txt`` is used:
-::
+``device_table-minimal.txt`` is used::
 
    IMAGE_DEVICE_TABLES = "device_table-mymachine.txt"
 
@@ -7826,8 +7602,7 @@
 
 To use the dynamic method for device population, you need to use (or be
 sure to set) the :term:`USE_DEVFS`
-variable to "1", which is the default:
-::
+variable to "1", which is the default::
 
    USE_DEVFS = "1"
 
@@ -7844,8 +7619,7 @@
 like ``udev`` or ``busybox-mdev``. You choose the device manager by
 defining the ``VIRTUAL-RUNTIME_dev_manager`` variable in your machine or
 distro configuration file. Alternatively, you can set this variable in
-your ``local.conf`` configuration file:
-::
+your ``local.conf`` configuration file::
 
    VIRTUAL-RUNTIME_dev_manager = "udev"
 
@@ -7866,14 +7640,12 @@
 
 To enable this behavior, the :term:`PV` of
 the recipe needs to reference
-:term:`SRCPV`. Here is an example:
-::
+:term:`SRCPV`. Here is an example::
 
    PV = "1.2.3+git${SRCPV}"
 
 Then, you can add the following to your
-``local.conf``:
-::
+``local.conf``::
 
    SRCREV_pn-PN = "${AUTOREV}"
 
@@ -7881,20 +7653,17 @@
 which you want to enable automatic source revision updating.
 
 If you do not want to update your local configuration file, you can add
-the following directly to the recipe to finish enabling the feature:
-::
+the following directly to the recipe to finish enabling the feature::
 
    SRCREV = "${AUTOREV}"
 
 The Yocto Project provides a distribution named ``poky-bleeding``, whose
-configuration file contains the line:
-::
+configuration file contains the line::
 
    require conf/distro/include/poky-floating-revisions.inc
 
 This line pulls in the
-listed include file that contains numerous lines of exactly that form:
-::
+listed include file that contains numerous lines of exactly that form::
 
    #SRCREV_pn-opkg-native ?= "${AUTOREV}"
    #SRCREV_pn-opkg-sdk ?= "${AUTOREV}"
@@ -7946,15 +7715,13 @@
 To create the read-only root filesystem, simply add the
 "read-only-rootfs" feature to your image, normally in one of two ways.
 The first way is to add the "read-only-rootfs" image feature in the
-image's recipe file via the ``IMAGE_FEATURES`` variable:
-::
+image's recipe file via the ``IMAGE_FEATURES`` variable::
 
    IMAGE_FEATURES += "read-only-rootfs"
 
 As an alternative, you can add the same feature
 from within your build directory's ``local.conf`` file with the
-associated ``EXTRA_IMAGE_FEATURES`` variable, as in:
-::
+associated ``EXTRA_IMAGE_FEATURES`` variable, as in::
 
    EXTRA_IMAGE_FEATURES = "read-only-rootfs"
 
@@ -8051,8 +7818,7 @@
 ``INHERIT`` statement and set the
 :term:`BUILDHISTORY_COMMIT`
 variable to "1" at the end of your ``conf/local.conf`` file found in the
-:term:`Build Directory`:
-::
+:term:`Build Directory`::
 
    INHERIT += "buildhistory"
    BUILDHISTORY_COMMIT = "1"
@@ -8140,8 +7906,7 @@
 :term:`SRCREV` is set to
 ${:term:`AUTOREV`}. Here is an
 example assuming
-``buildhistory/packages/qemux86-poky-linux/linux-yocto/latest_srcrev``):
-::
+``buildhistory/packages/qemux86-poky-linux/linux-yocto/latest_srcrev``)::
 
    # SRCREV_machine = "38cd560d5022ed2dbd1ab0dca9642e47c98a0aa1"
    SRCREV_machine = "38cd560d5022ed2dbd1ab0dca9642e47c98a0aa1"
@@ -8154,8 +7919,7 @@
 in a format suitable for use in global configuration (e.g.,
 ``local.conf`` or a distro include file) to override floating
 ``AUTOREV`` values to a fixed set of revisions. Here is some example
-output from this command:
-::
+output from this command::
 
    $ buildhistory-collect-srcrevs -a
    # i586-poky-linux
@@ -8270,8 +8034,7 @@
 in collecting specific package or SDK information, you can enable
 writing only image information without any history by adding the
 following to your ``conf/local.conf`` file found in the
-:term:`Build Directory`:
-::
+:term:`Build Directory`::
 
    INHERIT += "buildhistory"
    BUILDHISTORY_COMMIT = "0"
@@ -8370,8 +8133,7 @@
 To see any changes that have occurred (assuming you have
 :term:`BUILDHISTORY_COMMIT` = "1"),
 you can simply use any Git command that allows you to view the history
-of a repository. Here is one method:
-::
+of a repository. Here is one method::
 
    $ git log -p
 
@@ -8381,8 +8143,7 @@
 
 A command-line tool called ``buildhistory-diff`` does exist, though,
 that queries the Git repository and prints just the differences that
-might be significant in human-readable form. Here is an example:
-::
+might be significant in human-readable form. Here is an example::
 
    $ poky/poky/scripts/buildhistory-diff . HEAD^
    Changes to images/qemux86_64/glibc/core-image-minimal (files-in-image.txt):
@@ -8402,8 +8163,7 @@
 .. note::
 
    The ``buildhistory-diff`` tool requires the ``GitPython``
-   package. Be sure to install it using Pip3 as follows:
-   ::
+   package. Be sure to install it using Pip3 as follows::
 
          $ pip3 install GitPython --user
 
@@ -8473,8 +8233,7 @@
             with sudo.
 
          -  The package recipe ``qemu-helper-native`` is required to run
-            this script. Build the package using the following command:
-            ::
+            this script. Build the package using the following command::
 
                $ bitbake qemu-helper-native
 
@@ -8609,8 +8368,7 @@
 If you did set ``TEST_TARGET`` to "SystemdbootTarget", you also need to
 perform a one-time setup of your master image by doing the following:
 
-1. *Set EFI_PROVIDER:* Be sure that ``EFI_PROVIDER`` is as follows:
-   ::
+1. *Set EFI_PROVIDER:* Be sure that ``EFI_PROVIDER`` is as follows::
 
       EFI_PROVIDER = "systemd-boot"
 
@@ -8648,16 +8406,14 @@
 "SystemdbootTarget" is to set up the test image:
 
 1. *Set up your local.conf file:* Make sure you have the following
-   statements in your ``local.conf`` file:
-   ::
+   statements in your ``local.conf`` file::
 
       IMAGE_FSTYPES += "tar.gz"
       INHERIT += "testimage"
       TEST_TARGET = "SystemdbootTarget"
       TEST_TARGET_IP = "192.168.2.3"
 
-2. *Build your test image:* Use BitBake to build the image:
-   ::
+2. *Build your test image:* Use BitBake to build the image::
 
       $ bitbake core-image-sato
 
@@ -8671,8 +8427,7 @@
    ``TEST_POWERCONTROL_EXTRA_ARGS`` as a command that runs on the host
    and does power cycling. The test code passes one argument to that
    command: off, on or cycle (off then on). Here is an example that
-   could appear in your ``local.conf`` file:
-   ::
+   could appear in your ``local.conf`` file::
 
       TEST_POWERCONTROL_CMD = "powercontrol.exp test 10.11.12.1 nuc1"
 
@@ -8705,8 +8460,7 @@
 the required power action. This script requires either KDialog or Zenity
 to be installed. To use this script, set the
 :term:`TEST_POWERCONTROL_CMD`
-variable as follows:
-::
+variable as follows::
 
    TEST_POWERCONTROL_CMD = "${COREBASE}/scripts/contrib/dialog-power-control"
 
@@ -8728,8 +8482,7 @@
 command simply needs to connect to the serial console and forward that
 connection to standard input and output as any normal terminal program
 does. For example, to use the picocom terminal program on serial device
-``/dev/ttyUSB0`` at 115200bps, you would set the variable as follows:
-::
+``/dev/ttyUSB0`` at 115200bps, you would set the variable as follows::
 
    TEST_SERIALCONTROL_CMD = "picocom /dev/ttyUSB0 -b 115200"
 
@@ -8737,8 +8490,7 @@
 devices where the serial port device disappears when the device reboots,
 an additional "serdevtry" wrapper script is provided. To use this
 wrapper, simply prefix the terminal command with
-``${COREBASE}/scripts/contrib/serdevtry``:
-::
+``${COREBASE}/scripts/contrib/serdevtry``::
 
    TEST_SERIALCONTROL_CMD = "${COREBASE}/scripts/contrib/serdevtry picocom -b 115200 /dev/ttyUSB0"
 
@@ -8752,27 +8504,23 @@
    set the
    :term:`TESTIMAGE_AUTO`
    variable to "1" in your ``local.conf`` file in the
-   :term:`Build Directory`:
-   ::
+   :term:`Build Directory`::
 
       TESTIMAGE_AUTO = "1"
 
    Next, build your image. If the image successfully builds, the
-   tests run:
-   ::
+   tests run::
 
       bitbake core-image-sato
 
 -  *Manually running tests:* To manually run the tests, first globally
    inherit the
    :ref:`testimage <ref-classes-testimage*>` class
-   by editing your ``local.conf`` file:
-   ::
+   by editing your ``local.conf`` file::
 
       INHERIT += "testimage"
 
-   Next, use BitBake to run the tests:
-   ::
+   Next, use BitBake to run the tests::
 
       bitbake -c testimage image
 
@@ -8815,18 +8563,15 @@
 
 Here are some things to keep in mind when running tests:
 
--  The default tests for the image are defined as:
-   ::
+-  The default tests for the image are defined as::
 
       DEFAULT_TEST_SUITES_pn-image = "ping ssh df connman syslog xorg scp vnc date rpm dnf dmesg"
 
--  Add your own test to the list of the by using the following:
-   ::
+-  Add your own test to the list of the by using the following::
 
       TEST_SUITES_append = " mytest"
 
--  Run a specific list of tests as follows:
-   ::
+-  Run a specific list of tests as follows::
 
      TEST_SUITES = "test1 test2 test3"
 
@@ -8842,16 +8587,14 @@
 defined in :term:`TEST_SUITES`.
 
 If your image is already built, make sure the following are set in your
-``local.conf`` file:
-::
+``local.conf`` file::
 
    INHERIT += "testexport"
    TEST_TARGET_IP = "IP-address-for-the-test-target"
    TEST_SERVER_IP = "IP-address-for-the-test-server"
 
 You can then export the tests with the
-following BitBake command form:
-::
+following BitBake command form::
 
    $ bitbake image -c testexport
 
@@ -8860,28 +8603,24 @@
 ``tmp/testexport/``\ image, which is controlled by the
 ``TEST_EXPORT_DIR`` variable.
 
-You can now run the tests outside of the build environment:
-::
+You can now run the tests outside of the build environment::
 
    $ cd tmp/testexport/image
    $ ./runexported.py testdata.json
 
 Here is a complete example that shows IP addresses and uses the
-``core-image-sato`` image:
-::
+``core-image-sato`` image::
 
    INHERIT += "testexport"
    TEST_TARGET_IP = "192.168.7.2"
    TEST_SERVER_IP = "192.168.7.1"
 
-Use BitBake to export the tests:
-::
+Use BitBake to export the tests::
 
    $ bitbake core-image-sato -c testexport
 
 Run the tests outside of
-the build environment using the following:
-::
+the build environment using the following::
 
    $ cd tmp/testexport/core-image-sato
    $ ./runexported.py testdata.json
@@ -9157,14 +8896,12 @@
 BitBake's ``-e`` option is used to display variable values after
 parsing. The following command displays the variable values after the
 configuration files (i.e. ``local.conf``, ``bblayers.conf``,
-``bitbake.conf`` and so forth) have been parsed:
-::
+``bitbake.conf`` and so forth) have been parsed::
 
    $ bitbake -e
 
 The following command displays variable values after a specific recipe has
-been parsed. The variables include those from the configuration as well:
-::
+been parsed. The variables include those from the configuration as well::
 
    $ bitbake -e recipename
 
@@ -9187,8 +8924,7 @@
 helpful during debugging.
 
 Variables that are exported to the environment are preceded by
-``export`` in the output of ``bitbake -e``. See the following example:
-::
+``export`` in the output of ``bitbake -e``. See the following example::
 
    export CC="i586-poky-linux-gcc -m32 -march=i586 --sysroot=/home/ulf/poky/build/tmp/sysroots/qemux86"
 
@@ -9250,8 +8986,7 @@
 -  ``oe-pkgdata-util find-path path ...``: Lists the names of
    the packages that contain the given paths. For example, the following
    tells us that ``/usr/share/man/man1/make.1`` is contained in the
-   ``make-doc`` package:
-   ::
+   ``make-doc`` package::
 
       $ oe-pkgdata-util find-path /usr/share/man/man1/make.1
       make-doc: /usr/share/man/man1/make.1
@@ -9260,8 +8995,7 @@
    of the recipes that produce the given packages.
 
 For more information on the ``oe-pkgdata-util`` command, use the help
-facility:
-::
+facility::
 
    $ oe-pkgdata-util --help
    $ oe-pkgdata-util subcommand --help
@@ -9274,8 +9008,7 @@
 understand why a recipe is built.
 
 To generate dependency information for a recipe, run the following
-command:
-::
+command::
 
    $ bitbake -g recipename
 
@@ -9305,8 +9038,7 @@
       provide useful information.
 
       As an example, the ``task-depends.dot`` file contains lines such
-      as the following:
-      ::
+      as the following::
 
          "libxslt.do_configure" -> "libxml2.do_populate_sysroot"
 
@@ -9323,8 +9055,7 @@
       displays paths between graph nodes.
 
 You can use a different method to view dependency information by using
-the following command:
-::
+the following command::
 
    $ bitbake -g -u taskexp recipename
 
@@ -9350,8 +9081,7 @@
 automatically for a given task, you can list the variable dependencies
 BitBake has determined by doing the following:
 
-1. Build the recipe containing the task:
-::
+1. Build the recipe containing the task::
 
    $ bitbake recipename
 
@@ -9362,8 +9092,7 @@
    checksum for the task. As an example, for the
    :ref:`ref-tasks-fetch` task of the
    ``db`` recipe, the ``sigdata`` file might be found in the following
-   location:
-   ::
+   location::
 
       ${BUILDDIR}/tmp/stamps/i586-poky-linux/db/6.0.30-r1.do_fetch.sigdata.7c048c18222b16ff0bcee2000ef648b1
 
@@ -9375,8 +9104,7 @@
    same information as ``sigdata`` files.
 
 3. Run ``bitbake-dumpsig`` on the ``sigdata`` or ``siginfo`` file. Here
-   is an example:
-   ::
+   is an example::
 
       $ bitbake-dumpsig ${BUILDDIR}/tmp/stamps/i586-poky-linux/db/6.0.30-r1.do_fetch.sigdata.7c048c18222b16ff0bcee2000ef648b1
 
@@ -9406,8 +9134,7 @@
 
 You can also use BitBake to dump out the signature construction
 information without executing tasks by using either of the following
-BitBake command-line options:
-::
+BitBake command-line options::
 
    ‐‐dump-signatures=SIGNATURE_HANDLER
    -S SIGNATURE_HANDLER
@@ -9494,8 +9221,7 @@
 ``do_build`` and any tasks on which it depends build first. Some tasks,
 such as ``do_devshell``, are not part of the default build chain. If you
 wish to run a task that is not part of the default build chain, you can
-use the ``-c`` option in BitBake. Here is an example:
-::
+use the ``-c`` option in BitBake. Here is an example::
 
    $ bitbake matchbox-desktop -c devshell
 
@@ -9520,8 +9246,7 @@
    [\ :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:
-::
+The following example shows one way you can use the ``-f`` option::
 
    $ bitbake matchbox-desktop
              .
@@ -9550,8 +9275,7 @@
 :ref:`ref-tasks-build` task, which is
 the default task if no task is given, and the tasks on which it depends.
 You could replace the final two commands in the previous example with
-the following single command:
-::
+the following single command::
 
    $ bitbake matchbox-desktop -C compile
 
@@ -9575,16 +9299,14 @@
    and build output might not be in the clean state they would be in for
    a "normal" build, depending on what actions you took. To get rid of
    such warnings, you can remove the work directory and rebuild the
-   recipe, as follows:
-   ::
+   recipe, as follows::
 
       $ bitbake matchbox-desktop -c clean
       $ bitbake matchbox-desktop
 
 
 You can view a list of tasks in a given package by running the
-``do_listtasks`` task as follows:
-::
+``do_listtasks`` task as follows::
 
    $ bitbake matchbox-desktop -c listtasks
 
@@ -9608,8 +9330,7 @@
 -----------------------------
 
 To build a specific recipe (``.bb`` file), you can use the following
-command form:
-::
+command form::
 
    $ bitbake -b somepath/somerecipe.bb
 
@@ -9678,8 +9399,7 @@
 Following is an example written in Python. The code handles logging for
 a function that determines the number of tasks needed to be run. See the
 ":ref:`ref-tasks-listtasks`"
-section for additional information:
-::
+section for additional information::
 
    python do_listtasks() {
        bb.debug(2, "Starting to figure out the task list")
@@ -9841,21 +9561,18 @@
 :term:`PARALLEL_MAKE` variable
 in your ``local.conf`` file to a high number (e.g. "-j 20"). Using a
 high value for ``PARALLEL_MAKE`` increases the chances of the race
-condition showing up:
-::
+condition showing up::
 
    $ bitbake neard
 
-Once the local build for "neard" completes, start a ``devshell`` build:
-::
+Once the local build for "neard" completes, start a ``devshell`` build::
 
    $ bitbake neard -c devshell
 
 For information on how to use a ``devshell``, see the
 ":ref:`dev-manual/common-tasks:using a development shell`" section.
 
-In the ``devshell``, do the following:
-::
+In the ``devshell``, do the following::
 
    $ make clean
    $ make tools/snep-send.o
@@ -9863,8 +9580,7 @@
 The ``devshell`` commands cause the failure to clearly
 be visible. In this case, a missing dependency exists for the "neard"
 Makefile target. Here is some abbreviated, sample output with the
-missing dependency clearly visible at the end:
-::
+missing dependency clearly visible at the end::
 
    i586-poky-linux-gcc  -m32 -march=i586 --sysroot=/home/scott-lenovo/......
       .
@@ -9885,8 +9601,7 @@
 
 Because there is a missing dependency for the Makefile target, you need
 to patch the ``Makefile.am`` file, which is generated from
-``Makefile.in``. You can use Quilt to create the patch:
-::
+``Makefile.in``. You can use Quilt to create the patch::
 
    $ quilt new parallelmake.patch
    Patch patches/parallelmake.patch is now on top
@@ -9898,14 +9613,12 @@
 
 At this point you need to make the edits to ``Makefile.am`` to add the
 missing dependency. For our example, you have to add the following line
-to the file:
-::
+to the file::
 
    tools/snep-send.$(OBJEXT): include/near/dbus.h
 
 Once you have edited the file, use the ``refresh`` command to create the
-patch:
-::
+patch::
 
    $ quilt refresh
    Refreshed patch patches/parallelmake.patch
@@ -9913,8 +9626,7 @@
 Once
 the patch file exists, you need to add it back to the originating recipe
 folder. Here is an example assuming a top-level
-:term:`Source Directory` named ``poky``:
-::
+:term:`Source Directory` named ``poky``::
 
    $ cp patches/parallelmake.patch poky/meta/recipes-connectivity/neard/neard
 
@@ -9922,8 +9634,7 @@
 update the "neard" recipe (i.e. ``neard-0.14.bb``) so that the
 :term:`SRC_URI` statement includes
 the patch file. The recipe file is in the folder above the patch. Here
-is what the edited ``SRC_URI`` statement would look like:
-::
+is what the edited ``SRC_URI`` statement would look like::
 
    SRC_URI = "${KERNELORG_MIRROR}/linux/network/nfc/${BPN}-${PV}.tar.xz \
               file://neard.in \
@@ -9932,8 +9643,7 @@
              "
 
 With the patch complete and moved to the correct folder and the
-``SRC_URI`` statement updated, you can exit the ``devshell``:
-::
+``SRC_URI`` statement updated, you can exit the ``devshell``::
 
    $ exit
 
@@ -9941,16 +9651,14 @@
 ~~~~~~~~~~~~~~~~~
 
 With everything in place, you can get back to trying the build again
-locally:
-::
+locally::
 
    $ bitbake neard
 
 This build should succeed.
 
 Now you can open up a ``devshell`` again and repeat the clean and make
-operations as follows:
-::
+operations as follows::
 
    $ bitbake neard -c devshell
    $ make clean
@@ -9997,42 +9705,47 @@
 Using the debuginfod server method
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-"debuginfod" from "elfutils" is a way to distribute "debuginfo" files.
-Running a "debuginfod" server makes debug symbols readily available,
+``debuginfod`` from ``elfutils`` is a way to distribute ``debuginfo`` files.
+Running a ``debuginfod`` server makes debug symbols readily available,
 which means you don't need to download debugging information
 and the binaries of the process being debugged. You can just fetch
 debug symbols from the server.
 
-To run a debuginfod server, you need to do the following:
+To run a ``debuginfod`` server, you need to do the following:
 
--  Ensure that this variable is set in your ``local.conf`` file:
-   ::
+-  Ensure that ``debuginfod`` is present in :term:`DISTRO_FEATURES`
+   (it already is in ``OpenEmbedded-core`` defaults and ``poky`` reference distribution).
+   If not, set in your distro config file or in ``local.conf``::
 
-      PACKAGECONFIG_pn-elfutils-native = "debuginfod libdebuginfod"
+      DISTRO_FEATURES_append = " debuginfod"
 
-   This :term:`PACKAGECONFIG` option enables debuginfod and libdebuginfod for
-   "elfutils-native".
+   This distro feature enables the server and client library in ``elfutils``,
+   and enables ``debuginfod`` support in clients (at the moment, ``gdb`` and ``binutils``).
 
--  Run the following commands to set up the "debuginfod" server:
-   ::
+-  Run the following commands to launch the ``debuginfod`` server on the host::
 
       $ oe-debuginfod
 
+-  To use ``debuginfod`` on the target, you need to know the ip:port where
+   ``debuginfod`` is listening on the host (port defaults to 8002), and export
+   that into the shell environment, for example in ``qemu``::
 
-To use debuginfod on the target, you need the following:
+      root@qemux86-64:~# export DEBUGINFOD_URLS="http://192.168.7.1:8002/"
 
--  Ensure that this variable is set in your ``local.conf`` file:
-   ::
+-  Then debug info fetching should simply work when running the target ``gdb``,
+   ``readelf`` or ``objdump``, for example::
 
-      DEBUGINFOD_URLS = "http://localhost:8002/"
+      root@qemux86-64:~# gdb /bin/cat
+      ...
+      Reading symbols from /bin/cat...
+      Downloading separate debug info for /bin/cat...
+      Reading symbols from /home/root/.cache/debuginfod_client/923dc4780cfbc545850c616bffa884b6b5eaf322/debuginfo...
 
-   This :term:`DEBUGINFOD_URLS` option does the client configuration.
+-  It's also possible to use ``debuginfod-find`` to just query the server::
 
-   ::
+      root@qemux86-64:~# debuginfod-find debuginfo /bin/ls
+      /home/root/.cache/debuginfod_client/356edc585f7f82d46f94fcb87a86a3fe2d2e60bd/debuginfo
 
-        PACKAGECONFIG_pn-gdb = "debuginfod"
-
-   This :term:`PACKAGECONFIG` option enables "debuginfod" for "gdb".
 
 Using the gdbserver method
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -10069,8 +9782,7 @@
 1. *Configure your build system to construct the companion debug
    filesystem:*
 
-   In your ``local.conf`` file, set the following:
-   ::
+   In your ``local.conf`` file, set the following::
 
       IMAGE_GEN_DEBUGFS = "1"
       IMAGE_FSTYPES_DEBUGFS = "tar.bz2"
@@ -10090,8 +9802,7 @@
 2. *Configure the system to include gdbserver in the target filesystem:*
 
    Make the following addition in either your ``local.conf`` file or in
-   an image recipe:
-   ::
+   an image recipe::
 
       IMAGE_INSTALL_append = " gdbserver"
 
@@ -10101,29 +9812,25 @@
 3. *Build the environment:*
 
    Use the following command to construct the image and the companion
-   Debug Filesystem:
-   ::
+   Debug Filesystem::
 
       $ bitbake image
 
    Build the cross GDB component and
    make it available for debugging. Build the SDK that matches the
    image. Building the SDK is best for a production build that can be
-   used later for debugging, especially during long term maintenance:
-   ::
+   used later for debugging, especially during long term maintenance::
 
       $ bitbake -c populate_sdk image
 
    Alternatively, you can build the minimal toolchain components that
    match the target. Doing so creates a smaller than typical SDK and
    only contains a minimal set of components with which to build simple
-   test applications, as well as run the debugger:
-   ::
+   test applications, as well as run the debugger::
 
       $ bitbake meta-toolchain
 
-   A final method is to build Gdb itself within the build system:
-   ::
+   A final method is to build Gdb itself within the build system::
 
       $ bitbake gdb-cross-<architecture>
 
@@ -10140,8 +9847,7 @@
 
 4. *Set up the* ``debugfs``\ *:*
 
-   Run the following commands to set up the ``debugfs``:
-   ::
+   Run the following commands to set up the ``debugfs``::
 
       $ mkdir debugfs
       $ cd debugfs
@@ -10180,8 +9886,7 @@
    Documentation <https://www.gnu.org/software/gdb/documentation/>`__.
 
    After running gdbserver on the target, you need to run Gdb on the
-   host and configure it and connect to the target. Use these commands:
-   ::
+   host and configure it and connect to the target. Use these commands::
 
       $ cd directory-holding-the-debugfs-directory
       $ arch-gdb
@@ -10212,8 +9917,7 @@
    If the binary is processed through the debug splitting in
    OpenEmbedded, you should also copy the debug items (i.e. ``.debug``
    contents and corresponding ``/usr/src/debug`` files) from the work
-   directory. Here is an example:
-   ::
+   directory. Here is an example::
 
       $ bitbake bash
       $ bitbake -c devshell bash
@@ -10234,25 +9938,21 @@
 To support this kind of debugging, you need do the following:
 
 -  Ensure that GDB is on the target. You can do this by adding "gdb" to
-   :term:`IMAGE_INSTALL`:
-   ::
+   :term:`IMAGE_INSTALL`::
 
       IMAGE_INSTALL_append = " gdb"
 
-   Alternatively, you can add "tools-debug" to :term:`IMAGE_FEATURES`:
-   ::
+   Alternatively, you can add "tools-debug" to :term:`IMAGE_FEATURES`::
 
       IMAGE_FEATURES_append = " tools-debug"
 
 -  Ensure that debug symbols are present. You can make sure these
-   symbols are present by installing ``-dbg``:
-   ::
+   symbols are present by installing ``-dbg``::
 
       IMAGE_INSTALL_append = "packagename-dbg"
 
    Alternatively, you can do the following to include
-   all the debug symbols:
-   ::
+   all the debug symbols::
 
       IMAGE_FEATURES_append = " dbg-pkgs"
 
@@ -10262,8 +9962,7 @@
    of optimization used by the compiler. For example, when adding the
    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":
-   ::
+   of "-O -fno-omit-frame-pointer"::
 
            DEBUG_BUILD = "1"
 
@@ -10307,8 +10006,7 @@
    Using GNU Grep, you can use the following shell function to
    recursively search through common recipe-related files, skipping
    binary files, ``.git`` directories, and the Build Directory (assuming
-   its name starts with "build"):
-   ::
+   its name starts with "build")::
 
       g() {
           grep -Ir \
@@ -10321,8 +10019,7 @@
                "$@"
       }
 
-   Following are some usage examples:
-   ::
+   Following are some usage examples::
 
       $ g FOO # Search recursively for "FOO"
       $ g -i foo # Search recursively for "foo", ignoring case
@@ -10581,8 +10278,7 @@
       specific convention for bug references - any commit that addresses
       a specific bug should use the following form for the detailed
       description. Be sure to use the actual bug-tracking ID from
-      Bugzilla for bug-id:
-      ::
+      Bugzilla for bug-id::
 
          Fixes [YOCTO #bug-id]
 
@@ -10608,8 +10304,7 @@
    provide the command, you must include a revision list or a number of
    patches as part of the command. For example, either of these two
    commands takes your most recent single commit and formats it as an
-   email message in the current directory:
-   ::
+   email message in the current directory::
 
       $ git format-patch -1
 
@@ -10701,8 +10396,7 @@
 
 1. *Push Your Commits to a "Contrib" Upstream:* If you have arranged for
    permissions to push to an upstream contrib repository, push the
-   change to that repository:
-   ::
+   change to that repository::
 
       $ git push upstream_remote_repo local_branch_name
 
@@ -10711,8 +10405,7 @@
    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
 
@@ -10729,8 +10422,7 @@
 
    -  *Search by File:* Using :ref:`overview-manual/development-environment:git`, you can
       enter the following command to bring up a short list of all
-      commits against a specific file:
-      ::
+      commits against a specific file::
 
          git shortlog -- filename
 
@@ -10764,8 +10456,7 @@
    First, create the pull request. For example, the following command
    runs the script, specifies the upstream repository in the contrib
    directory into which you pushed the change, and provides a subject
-   line in the created patch files:
-   ::
+   line in the created patch files::
 
       $ poky/scripts/create-pull-request -u meta-intel-contrib -s "Updated Manual Section Reference in README"
 
@@ -10778,8 +10469,7 @@
    editing the cover letter, send the pull request. For example, the
    following command runs the script and specifies the patch directory
    and email address. In this example, the email address is a mailing
-   list:
-   ::
+   list::
 
       $ poky/scripts/send-pull-request -p ~/meta-intel/pull-10565 -t meta-intel@yoctoproject.org
 
@@ -10788,8 +10478,7 @@
    .. note::
 
       For help on using these scripts, simply provide the ``-h``
-      argument as follows:
-      ::
+      argument as follows::
 
               $ poky/scripts/create-pull-request -h
               $ poky/scripts/send-pull-request -h
@@ -10901,8 +10590,7 @@
 
 The ``LIC_FILES_CHKSUM`` variable contains checksums of the license text
 in the source code for the recipe. Following is an example of how to
-specify ``LIC_FILES_CHKSUM``:
-::
+specify ``LIC_FILES_CHKSUM``::
 
    LIC_FILES_CHKSUM = "file://COPYING;md5=xxxx \
                        file://licfile1.txt;beginline=5;endline=29;md5=yyyy \
@@ -10925,8 +10613,7 @@
 ``LIC_FILES_CHKSUM``. The previous example employs the default
 directory.
 
-Consider this next example:
-::
+Consider this next example::
 
    LIC_FILES_CHKSUM = "file://src/ls.c;beginline=5;endline=16;\
                                        md5=bb14ed3c4cda583abc85401304b5cd4e"
@@ -10988,15 +10675,13 @@
 :term:`LICENSE_FLAGS` variable
 definition in the affected recipe. For instance, the
 ``poky/meta/recipes-multimedia/gstreamer/gst-plugins-ugly`` recipe
-contains the following statement:
-::
+contains the following statement::
 
    LICENSE_FLAGS = "commercial"
 
 Here is a
 slightly more complicated example that contains both an explicit recipe
-name and version (after variable expansion):
-::
+name and version (after variable expansion)::
 
    LICENSE_FLAGS = "license_${PN}_${PV}"
 
@@ -11011,8 +10696,7 @@
 general string "commercial" to ``LICENSE_FLAGS_WHITELIST``. See the
 ":ref:`dev-manual/common-tasks:license flag matching`" section for a full
 explanation of how ``LICENSE_FLAGS`` matching works. Here is the
-example:
-::
+example::
 
    LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly"
 
@@ -11020,8 +10704,7 @@
 containing ``LICENSE_FLAGS = "license_${PN}_${PV}"``, and assuming that
 the actual recipe name was ``emgd_1.10.bb``, the following string would
 enable that package as well as the original ``gst-plugins-ugly``
-package:
-::
+package::
 
    LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly license_emgd_1.10"
 
@@ -11077,8 +10760,7 @@
 string "commercial" such as "commercial_foo" and "commercial_bar", which
 are the strings the build system automatically generates for
 hypothetical recipes named "foo" and "bar" assuming those recipes simply
-specify the following:
-::
+specify the following::
 
    LICENSE_FLAGS = "commercial"
 
@@ -11116,8 +10798,7 @@
 
 Other helpful variables related to commercial license handling exist and
 are defined in the
-``poky/meta/conf/distro/include/default-distrovars.inc`` file:
-::
+``poky/meta/conf/distro/include/default-distrovars.inc`` file::
 
    COMMERCIAL_AUDIO_PLUGINS ?= ""
    COMMERCIAL_VIDEO_PLUGINS ?= ""
@@ -11125,8 +10806,7 @@
 If you
 want to enable these components, you can do so by making sure you have
 statements similar to the following in your ``local.conf`` configuration
-file:
-::
+file::
 
    COMMERCIAL_AUDIO_PLUGINS = "gst-plugins-ugly-mad \
        gst-plugins-ugly-mpegaudioparse"
@@ -11138,8 +10818,7 @@
 Of course, you could also create a matching whitelist for those
 components using the more general "commercial" in the whitelist, but
 that would also enable all the other packages with ``LICENSE_FLAGS``
-containing "commercial", which you may or may not want:
-::
+containing "commercial", which you may or may not want::
 
    LICENSE_FLAGS_WHITELIST = "commercial"
 
@@ -11219,8 +10898,7 @@
 One way of doing this (but certainly not the only way) is to release
 just the source as a tarball. You can do this by adding the following to
 the ``local.conf`` file found in the
-:term:`Build Directory`:
-::
+:term:`Build Directory`::
 
    INHERIT += "archiver"
    ARCHIVER_MODE[src] = "original"
@@ -11276,8 +10954,7 @@
 This requirement also needs to be dealt with prior to generating the
 final image. Some licenses require the license text to accompany the
 binary. You can achieve this by adding the following to your
-``local.conf`` file:
-::
+``local.conf`` file::
 
    COPY_LIC_MANIFEST = "1"
    COPY_LIC_DIRS = "1"
@@ -11344,8 +11021,7 @@
 convenience is to modify ``meta-poky/conf/bblayers.conf.sample`` to
 ensure that when the end user utilizes the released build system to
 build an image, the development organization's layers are included in
-the ``bblayers.conf`` file automatically:
-::
+the ``bblayers.conf`` file automatically::
 
    # POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf
    # changes incompatibly
@@ -11413,8 +11089,7 @@
 non-common, non-CLOSED license in a recipe.
 
 The following is an example that uses the ``LICENSE.Abilis.txt`` file as
-the license from the fetched source:
-::
+the license from the fetched source::
 
    NO_GENERIC_LICENSE[Firmware-Abilis] = "LICENSE.Abilis.txt"
 
@@ -11457,8 +11132,7 @@
 By default, the error reporting feature stores information in
 ``${``\ :term:`LOG_DIR`\ ``}/error-report``.
 However, you can specify a directory to use by adding the following to
-your ``local.conf`` file:
-::
+your ``local.conf`` file::
 
    ERR_REPORT_DIR = "path"
 
@@ -11467,8 +11141,7 @@
 in a file as previously described. When the build system encounters an
 error, it includes a command as part of the console output. You can run
 the command to send the error file to the server. For example, the
-following command sends the errors to an upstream server:
-::
+following command sends the errors to an upstream server::
 
    $ send-error-report /home/brandusa/project/poky/build/tmp/log/error-report/error_report_201403141617.txt
 
@@ -11476,8 +11149,7 @@
 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:
-::
+information on available options::
 
    $ send-error-report --help
 
@@ -11557,8 +11229,7 @@
 (`KMS <https://wiki.archlinux.org/index.php/Kernel_Mode_Setting>`__)
 support, include the "wayland" flag in the
 :term:`DISTRO_FEATURES`
-statement in your ``local.conf`` file:
-::
+statement in your ``local.conf`` file::
 
    DISTRO_FEATURES_append = " wayland"
 
@@ -11573,8 +11244,7 @@
 To install the Wayland feature into an image, you must include the
 following
 :term:`CORE_IMAGE_EXTRA_INSTALL`
-statement in your ``local.conf`` file:
-::
+statement in your ``local.conf`` file::
 
    CORE_IMAGE_EXTRA_INSTALL += "wayland weston"
 
@@ -11589,14 +11259,12 @@
 (CLI), which is better suited for development work. To run Weston under
 the CLI, you need to do the following after your image is built:
 
-1. Run these commands to export ``XDG_RUNTIME_DIR``:
-   ::
+1. Run these commands to export ``XDG_RUNTIME_DIR``::
 
       mkdir -p /tmp/$USER-weston
       chmod 0700 /tmp/$USER-weston
       export XDG_RUNTIME_DIR=/tmp/$USER-weston
 
-2. Launch Weston in the shell:
-   ::
+2. Launch Weston in the shell::
 
       weston
diff --git a/poky/documentation/dev-manual/qemu.rst b/poky/documentation/dev-manual/qemu.rst
index 92799d6..2b6d3d7 100644
--- a/poky/documentation/dev-manual/qemu.rst
+++ b/poky/documentation/dev-manual/qemu.rst
@@ -55,16 +55,14 @@
 
    -  If you cloned the ``poky`` repository or you downloaded and
       unpacked a Yocto Project release tarball, you can source the build
-      environment script (i.e. :ref:`structure-core-script`):
-      ::
+      environment script (i.e. :ref:`structure-core-script`)::
 
          $ cd poky
          $ source oe-init-build-env
 
    -  If you installed a cross-toolchain, you can run the script that
       initializes the toolchain. For example, the following commands run
-      the initialization script from the default ``poky_sdk`` directory:
-      ::
+      the initialization script from the default ``poky_sdk`` directory::
 
          . poky_sdk/environment-setup-core2-64-poky-linux
 
@@ -86,8 +84,7 @@
    Extensible Software Development Kit (eSDK) manual for information on
    how to extract a root filesystem.
 
-4. *Run QEMU:* The basic ``runqemu`` command syntax is as follows:
-   ::
+4. *Run QEMU:* The basic ``runqemu`` command syntax is as follows::
 
       $ runqemu [option ] [...]
 
@@ -222,18 +219,15 @@
    Should you need to start, stop, or restart the NFS share, you can use
    the following commands:
 
-   -  The following command starts the NFS share:
-      ::
+   -  The following command starts the NFS share::
 
          runqemu-export-rootfs start file-system-location
 
-   -  The following command stops the NFS share:
-      ::
+   -  The following command stops the NFS share::
 
          runqemu-export-rootfs stop file-system-location
 
-   -  The following command restarts the NFS share:
-      ::
+   -  The following command restarts the NFS share::
 
          runqemu-export-rootfs restart file-system-location
 
@@ -313,8 +307,7 @@
 QEMU Command-Line Syntax
 ========================
 
-The basic ``runqemu`` command syntax is as follows:
-::
+The basic ``runqemu`` command syntax is as follows::
 
    $ runqemu [option ] [...]
 
@@ -325,8 +318,7 @@
 of options, you must provide either a machine name, a virtual machine
 image (``*wic.vmdk``), or a kernel image (``*.bin``).
 
-Following is the command-line help output for the ``runqemu`` command:
-::
+Following is the command-line help output for the ``runqemu`` command::
 
    $ runqemu --help
 
diff --git a/poky/documentation/dev-manual/start.rst b/poky/documentation/dev-manual/start.rst
index 84abf4c..18fd8cc 100644
--- a/poky/documentation/dev-manual/start.rst
+++ b/poky/documentation/dev-manual/start.rst
@@ -387,36 +387,28 @@
    software. Follow the instructions for your specific machine and the
    type of the software you need to install:
 
-   -  Install `Docker CE for
+   -  Install `Docker Desktop on
       Windows <https://docs.docker.com/docker-for-windows/install/#install-docker-desktop-on-windows>`__
       for Windows build hosts that meet requirements.
 
-   -  Install `Docker CE for
+   -  Install `Docker Desktop on
       MacOs <https://docs.docker.com/docker-for-mac/install/#install-and-run-docker-desktop-on-mac>`__
       for Mac build hosts that meet requirements.
 
-   -  Install `Docker Toolbox for
-      Windows <https://docs.docker.com/toolbox/toolbox_install_windows/>`__
-      for Windows build hosts that do not meet Docker requirements.
-
-   -  Install `Docker Toolbox for
-      MacOS <https://docs.docker.com/toolbox/toolbox_install_mac/>`__
-      for Mac build hosts that do not meet Docker requirements.
-
-   -  Install `Docker CE for
-      CentOS <https://docs.docker.com/install/linux/docker-ce/centos/>`__
+   -  Install `Docker Engine on
+      CentOS <https://docs.docker.com/engine/install/centos/>`__
       for Linux build hosts running the CentOS distribution.
 
-   -  Install `Docker CE for
-      Debian <https://docs.docker.com/install/linux/docker-ce/debian/>`__
+   -  Install `Docker Engine on
+      Debian <https://docs.docker.com/engine/install/debian/>`__
       for Linux build hosts running the Debian distribution.
 
-   -  Install `Docker CE for
-      Fedora <https://docs.docker.com/install/linux/docker-ce/fedora/>`__
+   -  Install `Docker Engine for
+      Fedora <https://docs.docker.com/engine/install/fedora/>`__
       for Linux build hosts running the Fedora distribution.
 
-   -  Install `Docker CE for
-      Ubuntu <https://docs.docker.com/install/linux/docker-ce/ubuntu/>`__
+   -  Install `Docker Engine for
+      Ubuntu <https://docs.docker.com/engine/install/ubuntu/>`__
       for Linux build hosts running the Ubuntu distribution.
 
 5. *Optionally Orient Yourself With Docker:* If you are unfamiliar with
@@ -486,8 +478,7 @@
    distribution.
 
 3. *Check your Linux distribution is using WSLv2:* Open a Windows
-   PowerShell and run:
-   ::
+   PowerShell and run::
 
       C:\WINDOWS\system32> wsl -l -v
       NAME    STATE   VERSION
@@ -514,8 +505,7 @@
 
    1. *Find the location of your VHDX file:* First you need to find the
       distro app package directory, to achieve this open a Windows
-      Powershell as Administrator and run:
-      ::
+      Powershell as Administrator and run::
 
          C:\WINDOWS\system32> Get-AppxPackage -Name "*Ubuntu*" | Select PackageFamilyName
          PackageFamilyName
@@ -525,8 +515,7 @@
 
       You should now
       replace the PackageFamilyName and your user on the following path
-      to find your VHDX file:
-      ::
+      to find your VHDX file::
 
           ls C:\Users\myuser\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79abcdefgh\LocalState\
           Mode                 LastWriteTime         Length Name
@@ -536,8 +525,7 @@
       ``C:\Users\myuser\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79abcdefgh\LocalState\ext4.vhdx``
 
    2. *Optimize your VHDX file:* Open a Windows Powershell as
-      Administrator to optimize your VHDX file, shutting down WSL first:
-      ::
+      Administrator to optimize your VHDX file, shutting down WSL first::
 
          C:\WINDOWS\system32> wsl --shutdown
          C:\WINDOWS\system32> optimize-vhd -Path C:\Users\myuser\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79abcdefgh\LocalState\ext4.vhdx -Mode full
@@ -741,8 +729,7 @@
 
 2. *Clone the Repository:* The following example command clones the
    ``poky`` repository and uses the default name "poky" for your local
-   repository:
-   ::
+   repository::
 
       $ git clone git://git.yoctoproject.org/poky
       Cloning into 'poky'...
@@ -764,8 +751,7 @@
 
    Once the local repository is created, you can change to that
    directory and check its status. Here, the single "master" branch
-   exists on your system and by default, it is checked out:
-   ::
+   exists on your system and by default, it is checked out::
 
       $ cd poky
       $ git status
@@ -826,8 +812,7 @@
 
 3. *Check out the Branch:* Check out the development branch in which you
    want to work. For example, to access the files for the Yocto Project
-   &DISTRO; Release (&DISTRO_NAME;), use the following command:
-   ::
+   &DISTRO; Release (&DISTRO_NAME;), use the following command::
 
       $ 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.
@@ -839,8 +824,7 @@
 
    The following command displays the branches that are now part of your
    local poky repository. The asterisk character indicates the branch
-   that is currently checked out for work:
-   ::
+   that is currently checked out for work::
 
       $ git branch
         master
@@ -867,14 +851,12 @@
    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:
-   ::
+   you need to fetch the upstream tags into your local repository::
 
       $ git fetch --tags
       $
 
-3. *List the Tag Names:* You can list the tag names now:
-   ::
+3. *List the Tag Names:* You can list the tag names now::
 
       $ git tag
       1.1_M1.final