[07/10] overview-manual: use the bitbake code-block language

diff --git a/documentation/overview-manual/concepts.rst b/documentation/overview-manual/concepts.rst
index d4530e97fed9..c82f26961a3c 100644
--- a/documentation/overview-manual/concepts.rst
+++ b/documentation/overview-manual/concepts.rst
@@ -894,7 +894,9 @@  the analysis and package splitting process use several areas:
 
 Packages for a recipe are listed in the :term:`PACKAGES` variable. The
 :oe_git:`bitbake.conf </openembedded-core/tree/meta/conf/bitbake.conf>`
-configuration file defines the following default list of packages::
+configuration file defines the following default list of packages:
+
+.. code-block:: bitbake
 
   PACKAGES = "${PN}-src ${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_PN} ${PN}"
 
@@ -902,7 +904,9 @@  Each of these packages contains a default list of files defined with the
 :term:`FILES` variable. For example, the package ``${PN}-dev`` represents files
 useful to the development of applications depending on ``${PN}``. The default
 list of files for ``${PN}-dev``, also defined in :oe_git:`bitbake.conf
-</openembedded-core/tree/meta/conf/bitbake.conf>`, is defined as follows::
+</openembedded-core/tree/meta/conf/bitbake.conf>`, is defined as follows:
+
+.. code-block:: bitbake
 
   FILES:${PN}-dev = "${includedir} ${FILES_SOLIBSDEV} ${libdir}/*.la \
                   ${libdir}/*.o ${libdir}/pkgconfig ${datadir}/pkgconfig \
@@ -940,12 +944,16 @@  package.
 
 To add a custom package variant of the ``${PN}`` recipe named
 ``${PN}-extra`` (name is arbitrary), one can add it to the
-:term:`PACKAGE_BEFORE_PN` variable::
+:term:`PACKAGE_BEFORE_PN` variable:
+
+.. code-block:: bitbake
 
   PACKAGE_BEFORE_PN += "${PN}-extra"
 
 Alternatively, a custom package can be added by adding it to the
-:term:`PACKAGES` variable using the prepend operator (``=+``)::
+:term:`PACKAGES` variable using the prepend operator (``=+``):
+
+.. code-block:: bitbake
 
   PACKAGES =+ "${PN}-extra"
 
@@ -1661,7 +1669,9 @@  to the task.
 
 Like the :term:`WORKDIR` case, there can be situations where dependencies should be
 ignored. For these situations, you can instruct the build process to
-ignore a dependency by using a line like the following::
+ignore a dependency by using a line like the following:
+
+.. code-block:: bitbake
 
    PACKAGE_ARCHS[vardepsexclude] = "MACHINE"
 
@@ -1671,7 +1681,9 @@  reference it.
 
 Equally, there are cases where you need to add dependencies BitBake is
 not able to find. You can accomplish this by using a line like the
-following::
+following:
+
+.. code-block:: bitbake
 
    PACKAGE_ARCHS[vardeps] = "MACHINE"
 
@@ -1701,7 +1713,9 @@  and the dependent task hashes can be influenced. Within the BitBake
 configuration file, you can give BitBake some extra information to help
 it construct the basehash. The following statement effectively results
 in a list of global variable dependency excludes (i.e. variables never
-included in any checksum)::
+included in any checksum):
+
+.. code-block:: bitbake
 
    BB_BASEHASH_IGNORE_VARS ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH DL_DIR \\
        SSTATE_DIR THISDIR FILESEXTRAPATHS FILE_DIRNAME HOME LOGNAME SHELL TERM \\
@@ -1722,7 +1736,9 @@  desired. This file defines the two basic signature generators
 "OEBasicHash". By default, a dummy "noop" signature handler is enabled
 in BitBake. This means that behavior is unchanged from previous
 versions. OE-Core uses the "OEBasicHash" signature handler by default
-through this setting in the ``bitbake.conf`` file::
+through this setting in the ``bitbake.conf`` file:
+
+.. code-block:: bitbake
 
    BB_SIGNATURE_HANDLER ?= "OEBasicHash"
 
@@ -1771,7 +1787,9 @@  directory tree such as the sysroot.
 The Yocto Project team has tried to keep the details of the
 implementation hidden in the :ref:`ref-classes-sstate` class. From a user's perspective,
 adding shared state wrapping to a task is as simple as this
-:ref:`ref-tasks-deploy` example taken from the :ref:`ref-classes-deploy` class::
+:ref:`ref-tasks-deploy` example taken from the :ref:`ref-classes-deploy` class:
+
+.. code-block:: bitbake
 
    DEPLOYDIR = "${WORKDIR}/deploy-${PN}"
    SSTATETASKS += "do_deploy"
@@ -1814,7 +1832,9 @@  The following list explains the previous example:
       instead, skipping the :ref:`ref-tasks-deploy` task.
 
 -  The following task definition is glue logic needed to make the
-   previous settings effective::
+   previous settings effective:
+
+   .. code-block:: bitbake
 
       python do_deploy_setscene () {
           sstate_setscene(d)
@@ -1846,7 +1866,9 @@  The following list explains the previous example:
       In cases where ``sstate-inputdirs`` and ``sstate-outputdirs`` would be
       the same, you can use ``sstate-plaindirs``. For example, to preserve the
       ${:term:`PKGD`} and ${:term:`PKGDEST`} output from the :ref:`ref-tasks-package`
-      task, use the following::
+      task, use the following:
+
+      .. code-block:: bitbake
 
               do_package[sstate-plaindirs] = "${PKGD} ${PKGDEST}"
 
@@ -1862,21 +1884,27 @@  The following list explains the previous example:
    multiple directories. For example, the following declares
    :term:`PKGDESTWORK` and ``SHLIBWORK`` as shared state input directories,
    which populates the shared state cache, and :term:`PKGDATA_DIR` and
-   ``SHLIBSDIR`` as the corresponding shared state output directories::
+   ``SHLIBSDIR`` as the corresponding shared state output directories:
+
+   .. code-block:: bitbake
 
       do_package[sstate-inputdirs] = "${PKGDESTWORK} ${SHLIBSWORKDIR}"
       do_package[sstate-outputdirs] = "${PKGDATA_DIR} ${SHLIBSDIR}"
 
 -  These methods also include the ability to take a lockfile when
    manipulating shared state directory structures, for cases where file
-   additions or removals are sensitive::
+   additions or removals are sensitive:
+
+   .. code-block:: bitbake
 
       do_package[sstate-lockfile] = "${PACKAGELOCK}"
 
 Behind the scenes, the shared state code works by looking in
 :term:`SSTATE_DIR` and
 :term:`SSTATE_MIRRORS` for
-shared state files. Here is an example::
+shared state files. Here is an example:
+
+.. code-block:: bitbake
 
    SSTATE_MIRRORS ?= "\
        file://.* https://someserver.tld/share/sstate/PATH;downloadfilename=PATH \
@@ -2024,13 +2052,17 @@  variables:
 -  :term:`bitbake:BB_SIGNATURE_HANDLER`, which must be set to ``OEEquivHash``.
 
 Therefore, the default configuration in Poky corresponds to the
-below settings::
+below settings:
+
+.. code-block:: bitbake
 
    BB_HASHSERVE = "auto"
    BB_SIGNATURE_HANDLER = "OEEquivHash"
 
 Rather than starting a local server, another possibility is to rely
-on a Hash Equivalence server on a network, by setting::
+on a Hash Equivalence server on a network, by setting:
+
+.. code-block:: bitbake
 
    BB_HASHSERVE = "<HOSTNAME>:<PORT>"
 
@@ -2189,7 +2221,9 @@  accomplished using fakeroot.
    under fakeroot. Otherwise, the task cannot run root-only operations,
    and cannot see the fake file ownership and permissions set by the
    other task. You need to also add a dependency on
-   ``virtual/fakeroot-native:do_populate_sysroot``, giving the following::
+   ``virtual/fakeroot-native:do_populate_sysroot``, giving the following:
+
+   .. code-block:: bitbake
 
       fakeroot do_mytask () {
           ...