manuals: simplify code insertion

This replaces instances of ": ::" by "::", which generates identical HTML output (From yocto-docs rev: 1f410dfc7c16c09af612de659f8574ef6cff4636) Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2026-05-30 00:20:08 +00:00 · 2021-04-15 17:58:45 +02:00
parent 21b42cc54f
commit 773536c333
15 changed files with 155 additions and 155 deletions
@@ -125,7 +125,7 @@ file.

 Following is the applicable code for setting various proxy types in the
 ``.wgetrc`` file. By default, these settings are disabled with comments.
-To use them, remove the comments: ::
+To use them, remove the comments::

   # You can set the default proxies for Wget to use for http, https, and ftp.
   # They will override the value in the environment.
@@ -224,7 +224,7 @@ to add a BSP-specific netbase that includes an interfaces file. See the
 the Yocto Project Board Support Packages (BSP) Developer's Guide for
 information on creating these types of miscellaneous recipe files.

-For example, add the following files to your layer: ::
+For example, add the following files to your layer::

   meta-MACHINE/recipes-bsp/netbase/netbase/MACHINE/interfaces
   meta-MACHINE/recipes-bsp/netbase/netbase_5.0.bbappend
@@ -300,7 +300,7 @@ fail.

 As an example, you could add a specific server for the build system to
 attempt before any others by adding something like the following to the
-``local.conf`` configuration file: ::
+``local.conf`` configuration file::

   PREMIRRORS_prepend = "\
       git://.*/.* http://www.yoctoproject.org/sources/ \n \
@@ -343,7 +343,7 @@ however, the technique can simply waste time during the build.

 Finally, consider an example where you are behind an HTTP-only firewall.
 You could make the following changes to the ``local.conf`` configuration
-file as long as the ``PREMIRRORS`` server is current: ::
+file as long as the ``PREMIRRORS`` server is current::

   PREMIRRORS_prepend = "\
       ftp://.*/.* http://www.yoctoproject.org/sources/ \n \
@@ -27,7 +27,7 @@ image you want.

 From within the ``poky`` Git repository, you can use the following
 command to display the list of directories within the :term:`Source Directory`
-that contain image recipe files: ::
+that contain image recipe files::

   $ ls meta*/recipes*/images/*.bb

@@ -29,7 +29,7 @@ location (either local or remote) and then point to it in
 :term:`SSTATE_MIRRORS`, you need to append "PATH"
 to the end of the mirror URL so that the path used by BitBake before the
 mirror substitution is appended to the path used to access the mirror.
-Here is an example: ::
+Here is an example::

   SSTATE_MIRRORS = "file://.* http://someserver.tld/share/sstate/PATH"

@@ -188,7 +188,7 @@ include :term:`PE` as part of the filename:

 Because the ``PE`` variable is not set by default, these binary files
 could result with names that include two dash characters. Here is an
-example: ::
+example::

   bzImage--3.10.9+git0+cd502a8814_7144bcc4b8-r0-qemux86-64-20130830085431.bin

@@ -207,7 +207,7 @@ functions to call and not arbitrary shell commands:

 For
 migration purposes, you can simply wrap shell commands in a shell
-function and then call the function. Here is an example: ::
+function and then call the function. Here is an example::

   my_postprocess_function() {
      echo "hello" > ${IMAGE_ROOTFS}/hello.txt
@@ -56,7 +56,7 @@ you can now remove them.
 Additionally, a ``bluetooth`` class has been added to make selection of
 the appropriate bluetooth support within a recipe a little easier. If
 you wish to make use of this class in a recipe, add something such as
-the following: ::
+the following::

   inherit bluetooth
   PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', '${BLUEZ}', '', d)}"
@@ -84,7 +84,7 @@ where the ``linux.inc`` file in ``meta-oe`` was updated.

 Recipes that rely on the kernel source code and do not inherit the
 module classes might need to add explicit dependencies on the
-``do_shared_workdir`` kernel task, for example: ::
+``do_shared_workdir`` kernel task, for example::

   do_configure[depends] += "virtual/kernel:do_shared_workdir"

@@ -131,7 +131,7 @@ One of the improvements is to attempt to run "make clean" during the
 ``do_configure`` task if a ``Makefile`` exists. Some software packages
 do not provide a working clean target within their make files. If you
 have such recipes, you need to set
-:term:`CLEANBROKEN` to "1" within the recipe, for example: ::
+:term:`CLEANBROKEN` to "1" within the recipe, for example::

   CLEANBROKEN = "1"

@@ -179,7 +179,7 @@ Supported machines are as follows:

 Consider the
 following example, which uses the ``qemux86-64`` machine, provides a
-root filesystem, provides an image, and uses the ``nographic`` option: ::
+root filesystem, provides an image, and uses the ``nographic`` option::

   $ runqemu qemux86-64 tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.ext4 tmp/deploy/images/qemux86-64/bzImage nographic

@@ -169,7 +169,7 @@ one of the packages provided by the Python recipe. You can no longer run
 ``bitbake python-foo`` or have a
 :term:`DEPENDS` on ``python-foo``,
 but doing either of the following causes the package to work as
-expected: ::
+expected::

   IMAGE_INSTALL_append = " python-foo"

@@ -179,12 +179,12 @@ parameter instead of the earlier ``name`` which overlapped with the
 generic ``name`` parameter. All recipes using the npm fetcher will need
 to be changed as a result.

-An example of the new scheme: ::
+An example of the new scheme::

   SRC_URI = "npm://registry.npmjs.org;package=array-flatten;version=1.1.1 \
              npmsw://${THISDIR}/npm-shrinkwrap.json"

-Another example where the sources are fetched from git rather than an npm repository: ::
+Another example where the sources are fetched from git rather than an npm repository::

   SRC_URI = "git://github.com/foo/bar.git;protocol=https \
              npmsw://${THISDIR}/npm-shrinkwrap.json"
@@ -90,12 +90,12 @@ If you have anonymous python or in-line python conditionally adding
 dependencies in your custom recipes, and you intend for those recipes to
 work with multilib, then you will need to ensure that ``${MLPREFIX}``
 is prefixed on the package names in the dependencies, for example
-(from the ``glibc`` recipe): ::
+(from the ``glibc`` recipe)::

    RRECOMMENDS_${PN} = "${@bb.utils.contains('DISTRO_FEATURES', 'ldconfig', '${MLPREFIX}ldconfig', '', d)}"

 This also applies when conditionally adding packages to :term:`PACKAGES` where
-those packages have dependencies, for example (from the ``alsa-plugins`` recipe): ::
+those packages have dependencies, for example (from the ``alsa-plugins`` recipe)::

    PACKAGES += "${@bb.utils.contains('PACKAGECONFIG', 'pulseaudio', 'alsa-plugins-pulseaudio-conf', '', d)}"
    ...
@@ -229,7 +229,7 @@ needs ``/etc/ld.so.conf`` to be present at image build time:

 When some recipe installs libraries to a non-standard location, and
 therefore installs in a file in ``/etc/ld.so.conf.d/foo.conf``, we
-need ``/etc/ld.so.conf`` containing: ::
+need ``/etc/ld.so.conf`` containing::

  include /etc/ld.so.conf.d/*.conf

@@ -675,7 +675,7 @@ Errors and Warnings
    task. Patch fuzz is a situation when the ``patch`` tool ignores some of the context
    lines in order to apply the patch. Consider this example:

-    Patch to be applied: ::
+    Patch to be applied::

        --- filename
        +++ filename
@@ -687,7 +687,7 @@ Errors and Warnings
         context line 5
         context line 6

-    Original source code: ::
+    Original source code::

        different context line 1
        different context line 2
@@ -696,7 +696,7 @@ Errors and Warnings
        different context line 5
        different context line 6

-    Outcome (after applying patch with fuzz): ::
+    Outcome (after applying patch with fuzz)::

        different context line 1
        different context line 2
@@ -716,14 +716,14 @@ Errors and Warnings
    *How to eliminate patch fuzz warnings*

    Use the ``devtool`` command as explained by the warning. First, unpack the
-    source into devtool workspace: ::
+    source into devtool workspace::

            devtool modify <recipe>

    This will apply all of the patches, and create new commits out of them in
    the workspace - with the patch context updated.

-    Then, replace the patches in the recipe layer: ::
+    Then, replace the patches in the recipe layer::

            devtool finish --force-patch-refresh <recipe> <layer_path>

@@ -728,7 +728,7 @@ system and gives an overview of their function and contents.

      If you want to mask out multiple directories or recipes, you can
      specify multiple regular expression fragments. This next example
-      masks out multiple directories and individual recipes: ::
+      masks out multiple directories and individual recipes::

         BBMASK += "/meta-ti/recipes-misc/ meta-ti/recipes-ti/packagegroup/"
         BBMASK += "/meta-oe/recipes-support/"
@@ -4890,13 +4890,13 @@ system and gives an overview of their function and contents.
      Prevents installation of all "recommended-only" packages.
      Recommended-only packages are packages installed only through the
      :term:`RRECOMMENDS` variable). Setting the
-      ``NO_RECOMMENDATIONS`` variable to "1" turns this feature on: ::
+      ``NO_RECOMMENDATIONS`` variable to "1" turns this feature on::

         NO_RECOMMENDATIONS = "1"

      You can set this variable globally in your ``local.conf`` file or you
      can attach it to a specific image recipe by using the recipe name
-      override: ::
+      override::

         NO_RECOMMENDATIONS_pn-target_image = "1"

@@ -6924,7 +6924,7 @@ system and gives an overview of their function and contents.
      ``/proc/console`` before enabling them using getty. This variable
      allows aliasing in the format: <device>:<alias>. If a device was
      listed as "sclp_line0" in ``/dev/`` and "ttyS0" was listed in
-      ``/proc/console``, you would do the following: ::
+      ``/proc/console``, you would do the following::

         SERIAL_CONSOLES_CHECK = "slcp_line0:ttyS0"

@@ -6934,7 +6934,7 @@ system and gives an overview of their function and contents.
   :term:`SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS`
      A list of recipe dependencies that should not be used to determine
      signatures of tasks from one recipe when they depend on tasks from
-      another recipe. For example: ::
+      another recipe. For example::

         SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += "intone->mplayer2"

@@ -6942,7 +6942,7 @@ system and gives an overview of their function and contents.

      You can use the special token ``"*"`` on the left-hand side of the
      dependency to match all recipes except the one on the right-hand
-      side. Here is an example: ::
+      side. Here is an example::

         SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += "*->quilt-native"