mirror of
https://git.yoctoproject.org/poky
synced 2026-05-09 17:39:31 +00:00
manuals: fix double colons
Fixing double colons appearing alone on a line, while they could be put at the end of the previous line. Sometimes placing a note after the quoted text to avoid such a situation. It's more natural too not to have a note between the introduction text and the quoted section. (From yocto-docs rev: fb054622f5119444eb947fe580253f37e0d872c6) Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Michael Opdenacker
committed by
Richard Purdie
Richard Purdie
parent
8b812b29c4
commit
01e5d22507
@@ -327,8 +327,7 @@ BitBake has determined by doing the following:
|
||||
In the output of the above command, you will find a line like the
|
||||
following, which lists all the (inferred) variable dependencies for
|
||||
the task. This list also includes indirect dependencies from
|
||||
variables depending on other variables, recursively.
|
||||
::
|
||||
variables depending on other variables, recursively::
|
||||
|
||||
Task dependencies: ['PV', 'SRCREV', 'SRC_URI', 'SRC_URI[md5sum]', 'SRC_URI[sha256sum]', 'base_do_fetch']
|
||||
|
||||
@@ -641,8 +640,7 @@ The syntax you use for recipes written in Bash is similar to that of
|
||||
recipes written in Python described in the previous section.
|
||||
|
||||
Following is an example written in Bash. The code logs the progress of
|
||||
the ``do_my_function`` function.
|
||||
::
|
||||
the ``do_my_function`` function::
|
||||
|
||||
do_my_function() {
|
||||
bbdebug 2 "Running do_my_function"
|
||||
|
||||
@@ -71,8 +71,7 @@ Disabling the Tool
|
||||
|
||||
To disable the error reporting feature, simply remove or comment out the
|
||||
following statement from the end of your ``local.conf`` file in your
|
||||
:term:`Build Directory`.
|
||||
::
|
||||
:term:`Build Directory`::
|
||||
|
||||
INHERIT += "report-error"
|
||||
|
||||
|
||||
@@ -154,8 +154,7 @@ or characters. A partial string will match any license that contains the
|
||||
given string as the first portion of its license. For example, the
|
||||
following value will also match both of the packages
|
||||
previously mentioned as well as any other packages that have licenses
|
||||
starting with "commercial" or "license".
|
||||
::
|
||||
starting with "commercial" or "license"::
|
||||
|
||||
LICENSE_FLAGS_ACCEPTED = "commercial license"
|
||||
|
||||
|
||||
@@ -109,8 +109,7 @@ Following are some syntax examples:
|
||||
|
||||
- Use this syntax to generate a recipe using code that
|
||||
you extract from source. The extracted code is placed in its own layer
|
||||
defined by :term:`EXTERNALSRC`.
|
||||
::
|
||||
defined by :term:`EXTERNALSRC`::
|
||||
|
||||
recipetool create -o OUTFILE -x EXTERNALSRC source
|
||||
|
||||
@@ -147,8 +146,7 @@ get started. Here are some points on both methods:
|
||||
- *Use and modify the following skeleton recipe:* If for some reason
|
||||
you do not want to use ``recipetool`` and you cannot find an existing
|
||||
recipe that is close to meeting your needs, you can use the following
|
||||
structure to provide the fundamental areas of a new recipe.
|
||||
::
|
||||
structure to provide the fundamental areas of a new recipe::
|
||||
|
||||
DESCRIPTION = ""
|
||||
HOMEPAGE = ""
|
||||
@@ -347,9 +345,7 @@ paste them into your recipe and then run the build again to continue.
|
||||
This final example is a bit more complicated and is from the
|
||||
``meta/recipes-sato/rxvt-unicode/rxvt-unicode_9.20.bb`` recipe. The
|
||||
example's :term:`SRC_URI` statement identifies multiple files as the source
|
||||
files for the recipe: a tarball, a patch file, a desktop file, and an
|
||||
icon.
|
||||
::
|
||||
files for the recipe: a tarball, a patch file, a desktop file, and an icon::
|
||||
|
||||
SRC_URI = "http://dist.schmorp.de/rxvt-unicode/Attic/rxvt-unicode-${PV}.tar.bz2 \
|
||||
file://xwc.patch \
|
||||
@@ -1196,8 +1192,7 @@ under ``files``) requires a recipe that has the file listed in the
|
||||
:ref:`ref-tasks-compile` and :ref:`ref-tasks-install` tasks. The :term:`S` variable defines the
|
||||
directory containing the source code, which is set to
|
||||
:term:`WORKDIR` in this case --- the
|
||||
directory BitBake uses for the build.
|
||||
::
|
||||
directory BitBake uses for the build::
|
||||
|
||||
SUMMARY = "Simple helloworld application"
|
||||
SECTION = "examples"
|
||||
@@ -1233,8 +1228,7 @@ which contains the definitions of all the steps needed to build an
|
||||
Autotool-based application. The result of the build is automatically
|
||||
packaged. And, if the application uses NLS for localization, packages
|
||||
with local information are generated (one package per language).
|
||||
Following is one example: (``hello_2.3.bb``)
|
||||
::
|
||||
Following is one example: (``hello_2.3.bb``)::
|
||||
|
||||
SUMMARY = "GNU Helloworld application"
|
||||
SECTION = "examples"
|
||||
|
||||
@@ -103,7 +103,9 @@ available. Follow these general steps to run QEMU:
|
||||
automatically finds the ``bzImage-qemux86-64.bin`` image file and
|
||||
the ``core-image-minimal-qemux86-64-20200218002850.rootfs.ext4``
|
||||
(assuming the current build created a ``core-image-minimal``
|
||||
image).
|
||||
image)::
|
||||
|
||||
$ runqemu qemux86-64
|
||||
|
||||
.. note::
|
||||
|
||||
@@ -111,14 +113,9 @@ available. Follow these general steps to run QEMU:
|
||||
and uses the most recently built image according to the
|
||||
timestamp.
|
||||
|
||||
::
|
||||
|
||||
$ runqemu qemux86-64
|
||||
|
||||
- This example produces the exact same results as the previous
|
||||
example. This command, however, specifically provides the image
|
||||
and root filesystem type.
|
||||
::
|
||||
and root filesystem type::
|
||||
|
||||
$ runqemu qemux86-64 core-image-minimal ext4
|
||||
|
||||
@@ -127,23 +124,20 @@ available. Follow these general steps to run QEMU:
|
||||
variable ``FSTYPE`` to ``cpio.gz``. Also, for audio to be enabled,
|
||||
an appropriate driver must be installed (see the ``audio`` option
|
||||
in :ref:`dev-manual/qemu:\`\`runqemu\`\` command-line options`
|
||||
for more information).
|
||||
::
|
||||
for more information)::
|
||||
|
||||
$ runqemu qemux86-64 ramfs audio
|
||||
|
||||
- This example does not provide enough information for QEMU to
|
||||
launch. While the command does provide a root filesystem type, it
|
||||
must also minimally provide a `MACHINE`, `KERNEL`, or `VM` option.
|
||||
::
|
||||
must also minimally provide a `MACHINE`, `KERNEL`, or `VM` option::
|
||||
|
||||
$ runqemu ext4
|
||||
|
||||
- This example specifies to boot a virtual machine image
|
||||
(``.wic.vmdk`` file). From the ``.wic.vmdk``, ``runqemu``
|
||||
determines the QEMU architecture (`MACHINE`) to be "qemux86-64" and
|
||||
the root filesystem type to be "vmdk".
|
||||
::
|
||||
the root filesystem type to be "vmdk"::
|
||||
|
||||
$ runqemu /home/scott-lenovo/vm/core-image-minimal-qemux86-64.wic.vmdk
|
||||
|
||||
|
||||
@@ -67,8 +67,7 @@ Follow these general steps:
|
||||
|
||||
7. *Generate the Patch:* Once your changes work as expected, you need to
|
||||
use Quilt to generate the final patch that contains all your
|
||||
modifications.
|
||||
::
|
||||
modifications::
|
||||
|
||||
$ quilt refresh
|
||||
|
||||
|
||||
@@ -578,8 +578,7 @@ data:
|
||||
|
||||
Following is an example JSON file that handles test "foo" installing
|
||||
package "bar" and test "foobar" installing packages "foo" and "bar".
|
||||
Once the test is complete, the packages are removed from the DUT.
|
||||
::
|
||||
Once the test is complete, the packages are removed from the DUT::
|
||||
|
||||
{
|
||||
"foo": {
|
||||
|
||||
@@ -260,14 +260,7 @@ your build configuration (i.e. ``${BUILDDIR}/conf/bblayers.conf``)::
|
||||
For this example, assume that the ``nano.bb`` recipe that
|
||||
is upstream has a 2.9.3 version number. However, the version in the
|
||||
local repository is 2.7.4. The following command from your build
|
||||
directory automatically upgrades the recipe for you:
|
||||
|
||||
.. note::
|
||||
|
||||
Using the ``-V`` option is not necessary. Omitting the version number causes
|
||||
``devtool upgrade`` to upgrade the recipe to the most recent version.
|
||||
|
||||
::
|
||||
directory automatically upgrades the recipe for you::
|
||||
|
||||
$ devtool upgrade nano -V 2.9.3
|
||||
NOTE: Starting bitbake server...
|
||||
@@ -286,6 +279,11 @@ directory automatically upgrades the recipe for you:
|
||||
NOTE: Upgraded source extracted to /home/scottrif/poky/build/workspace/sources/nano
|
||||
NOTE: New recipe is /home/scottrif/poky/build/workspace/recipes/nano/nano_2.9.3.bb
|
||||
|
||||
.. note::
|
||||
|
||||
Using the ``-V`` option is not necessary. Omitting the version number causes
|
||||
``devtool upgrade`` to upgrade the recipe to the most recent version.
|
||||
|
||||
Continuing with this example, you can use ``devtool build`` to build the
|
||||
newly upgraded recipe::
|
||||
|
||||
|
||||
@@ -539,8 +539,7 @@ will need to boot from ``sdb`` instead of ``sda``, which is what the
|
||||
|
||||
The example begins by making a copy of the ``directdisk-gpt.wks`` file
|
||||
in the ``scripts/lib/image/canned-wks`` directory and then by changing
|
||||
the lines that specify the target disk from which to boot.
|
||||
::
|
||||
the lines that specify the target disk from which to boot::
|
||||
|
||||
$ cp /home/stephano/yocto/poky/scripts/lib/wic/canned-wks/directdisk-gpt.wks \
|
||||
/home/stephano/yocto/poky/scripts/lib/wic/canned-wks/directdisksdb-gpt.wks
|
||||
@@ -557,8 +556,7 @@ Once the lines are changed, the
|
||||
example generates the ``directdisksdb-gpt`` image. The command points
|
||||
the process at the ``core-image-minimal`` artifacts for the Next Unit of
|
||||
Computing (nuc) :term:`MACHINE` the
|
||||
``local.conf``.
|
||||
::
|
||||
``local.conf``::
|
||||
|
||||
$ wic create directdisksdb-gpt -e core-image-minimal
|
||||
INFO: Building wic-tools...
|
||||
|
||||
Reference in New Issue
Block a user