[10/10] docs-wide: use the bitbake code-block language

diff --git a/documentation/brief-yoctoprojectqs/index.rst b/documentation/brief-yoctoprojectqs/index.rst
index 4adec9714f2f..2dccff16c995 100644
--- a/documentation/brief-yoctoprojectqs/index.rst
+++ b/documentation/brief-yoctoprojectqs/index.rst
@@ -410,7 +410,9 @@  layer>`:
     `Synaptics` license. See the :yocto_git:`ipcompliance.md
     </meta-raspberrypi/tree/docs/ipcompliance.md>` document for more information.
     Add the ``synaptics-killswitch`` value to the :term:`LICENSE_FLAGS_ACCEPTED`
-    variable, in the ``conf/local.conf`` file of your build directory::
+    variable, in the ``conf/local.conf`` file of your build directory:
+
+    .. code-block:: bitbake
 
        LICENSE_FLAGS_ACCEPTED = "synaptics-killswitch"
 
diff --git a/documentation/bsp-manual/bsp.rst b/documentation/bsp-manual/bsp.rst
index 168d64e6ed5a..030464b74283 100644
--- a/documentation/bsp-manual/bsp.rst
+++ b/documentation/bsp-manual/bsp.rst
@@ -84,7 +84,9 @@  established after you run the OpenEmbedded build environment setup
 script (i.e. :ref:`structure-core-script`).
 Adding the root directory allows the :term:`OpenEmbedded Build System`
 to recognize the BSP
-layer and from it build an image. Here is an example::
+layer and from it build an image. Here is an example:
+
+.. code-block:: bitbake
 
    BBLAYERS ?= " \
       /usr/local/src/yocto/meta \
@@ -112,7 +114,9 @@  are known as ":term:`container layers <Container Layer>`". An example of
 this type of layer is OpenEmbedded's :oe_git:`meta-openembedded </meta-openembedded>`
 layer. The ``meta-openembedded`` layer contains many ``meta-*`` layers.
 In cases like this, you need to include the names of the actual layers
-you want to work with, such as::
+you want to work with, such as:
+
+.. code-block:: bitbake
 
    BBLAYERS ?= " \
      /usr/local/src/yocto/meta \
@@ -603,7 +607,9 @@  For example, many ``tune-*`` files (e.g. ``tune-arm1136jf-s.inc``,
 
 To use an include file, you simply include them in the machine
 configuration file. For example, the Raspberry Pi BSP
-``raspberrypi3.conf`` contains the following statement::
+``raspberrypi3.conf`` contains the following statement:
+
+.. code-block:: bitbake
 
    include conf/machine/include/rpi-base.inc
 
@@ -674,7 +680,9 @@  Suppose you are using the ``linux-yocto_6.12.bb`` recipe to build the
 kernel. In other words, you have selected the kernel in your
 ``"bsp_root_name".conf`` file by adding
 :term:`PREFERRED_PROVIDER` and :term:`PREFERRED_VERSION`
-statements as follows::
+statements as follows:
+
+.. code-block:: bitbake
 
    PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
    PREFERRED_VERSION_linux-yocto ?= "6.12%"
@@ -1027,7 +1035,9 @@  BSP-specific configuration file named ``interfaces`` to the
 also supports several other machines:
 
 #. Edit the ``init-ifupdown_1.0.bbappend`` file so that it contains the
-   following::
+   following:
+
+   .. code-block:: bitbake
 
       FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
 
@@ -1383,7 +1393,9 @@  BSP Kernel Recipe Example
 -------------------------
 
 The kernel recipe used to build the kernel image for the BeagleBone
-device was established in the machine configuration::
+device was established in the machine configuration:
+
+.. code-block:: bitbake
 
    PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
    PREFERRED_VERSION_linux-yocto ?= "6.18%"
@@ -1394,7 +1406,9 @@  metadata used to build the kernel. In this case, a kernel append file
 kernel recipe (i.e. ``linux-yocto_6.18.bb``), which is located in
 :oe_git:`/openembedded-core/tree/meta/recipes-kernel/linux`.
 
-The contents of the append file are::
+The contents of the append file are:
+
+.. code-block:: bitbake
 
    COMPATIBLE_MACHINE:genericarm64 = "genericarm64"
    COMPATIBLE_MACHINE:beaglebone-yocto = "beaglebone-yocto"
diff --git a/documentation/contributor-guide/recipe-style-guide.rst b/documentation/contributor-guide/recipe-style-guide.rst
index 84c6bb14e8b0..7cd3385787ee 100644
--- a/documentation/contributor-guide/recipe-style-guide.rst
+++ b/documentation/contributor-guide/recipe-style-guide.rst
@@ -48,7 +48,9 @@  Debian policy closely.
 When a recipe references a git revision that does not correspond to a released
 version of software (e.g. is not a tagged version), the :term:`PV` variable
 should include the sign ``+``, so :term:`bitbake` automatically includes package
-version information during the packaging phase::
+version information during the packaging phase:
+
+.. code-block:: bitbake
 
     PV = "<version>+git"
 
@@ -95,13 +97,17 @@  Variable Formatting
 
 -  When splitting a long variable over multiple lines, all continuation lines
    should be indented (with spaces) to align with the start of the quote on the
-   first line::
+   first line:
+
+   .. code-block:: bitbake
 
        FOO = "this line is \
               long \
               "
 
-   Instead of::
+   Instead of:
+
+   .. code-block:: bitbake
 
        FOO = "this line is \
        long \
@@ -190,7 +196,9 @@  used tasks this would be:
 
 Custom tasks should be sorted similarly.
 
-Package specific variables are typically grouped together, e.g.::
+Package specific variables are typically grouped together, e.g.:
+
+.. code-block:: bitbake
 
     RDEPENDS:${PN} = "foo"
     RDEPENDS:${PN}-libs = "bar"
@@ -211,7 +219,9 @@  Recipes need to define both the :term:`LICENSE` and
    include ``COPYING``, :term:`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 :term:`LICENSE` as follows::
+   License version 2, you would set :term:`LICENSE` as follows:
+
+   .. code-block:: bitbake
 
       LICENSE = "GPL-2.0-only"
 
@@ -255,7 +265,9 @@  Recipes need to define both the :term:`LICENSE` and
    See the ":ref:`dev-manual/new-recipe: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:
+
+   .. code-block:: bitbake
 
       LIC_FILES_CHKSUM = "file://COPYING;md5=xxx"
 
diff --git a/documentation/profile-manual/intro.rst b/documentation/profile-manual/intro.rst
index 31791255246e..24bbc952c9bd 100644
--- a/documentation/profile-manual/intro.rst
+++ b/documentation/profile-manual/intro.rst
@@ -41,7 +41,9 @@  an ``sdk`` image, perhaps one of::
    $ bitbake core-image-rt-sdk
 
 Alternatively,  you can add ``tools-profile`` to the :term:`EXTRA_IMAGE_FEATURES` line in
-your ``local.conf`` file::
+your ``local.conf`` file:
+
+.. code-block:: bitbake
 
    EXTRA_IMAGE_FEATURES:append = " tools-profile"
 
@@ -57,7 +59,9 @@  the tracing and profiling tools will be included in non-sdk images as well e.g.:
 
    You can prevent that by setting the
    :term:`INHIBIT_PACKAGE_STRIP`
-   variable to "1" in your ``local.conf`` when you build the image::
+   variable to "1" in your ``local.conf`` when you build the image:
+
+   .. code-block:: bitbake
 
       INHIBIT_PACKAGE_STRIP = "1"
 
@@ -67,11 +71,15 @@  If you've already built a stripped image, you can generate debug
 packages (xxx-dbg) which you can manually install as needed.
 
 To generate debug info for packages, you can add ``dbg-pkgs`` to
-:term:`EXTRA_IMAGE_FEATURES` in ``local.conf``. For example::
+:term:`EXTRA_IMAGE_FEATURES` in ``local.conf``. For example:
+
+.. code-block:: bitbake
 
    EXTRA_IMAGE_FEATURES:append = " dbg-pkgs"
 
 Additionally, in order to generate the right type of debug info, we also need to
-set :term:`PACKAGE_DEBUG_SPLIT_STYLE` in the ``local.conf`` file::
+set :term:`PACKAGE_DEBUG_SPLIT_STYLE` in the ``local.conf`` file:
+
+.. code-block:: bitbake
 
    PACKAGE_DEBUG_SPLIT_STYLE = 'debug-file-directory'