@@ -373,7 +373,7 @@ layer>`:
First, clone the layer next to the other layers::
- git clone -b &DISTRO_NAME_NO_CAP; https://git.yoctoproject.org/meta-raspberrypi ../layers/meta-raspberrypi
+ $ git clone -b &DISTRO_NAME_NO_CAP; https://git.yoctoproject.org/meta-raspberrypi ../layers/meta-raspberrypi
#. **Add Your Layer to the Layer Configuration File:** Before you can use
it, you must add the layer and its dependencies to your :ref:`structure-build-conf-bblayers.conf`
@@ -436,7 +436,7 @@ By default, patches created with ``git format-patch`` have a `Git` version signa
To avoid having a `Git` signature at the end of generated or updated patches,
you can use `Git` configuration settings::
- git config --global format.signature ""
+ $ git config --global format.signature ""
.. note::
Patches generated or updated by ``devtool`` are created with no signature.
@@ -57,20 +57,20 @@ Set up Git
The first thing to do is to install Git packages. Here is an example
on Debian and Ubuntu::
- sudo apt install git-core git-email
+ $ sudo apt install git-core git-email
Then, you need to set a name and e-mail address that Git will
use to identify your commits::
- git config --global user.name "Ada Lovelace"
- git config --global user.email "ada.lovelace@gmail.com"
+ $ git config --global user.name "Ada Lovelace"
+ $ git config --global user.email "ada.lovelace@gmail.com"
By default, Git adds a signature line at the end of patches containing the Git
version. We suggest to remove it as it doesn't add useful information.
Remove it with the following command::
- git config --global format.signature ""
+ $ git config --global format.signature ""
Clone the Git repository for the component to modify
----------------------------------------------------
@@ -79,8 +79,8 @@ After identifying the component to modify as described in the
":doc:`/contributor-guide/identify-component`" section, clone the
corresponding Git repository. Here is an example for OpenEmbedded-Core::
- git clone https://git.openembedded.org/openembedded-core
- cd openembedded-core
+ $ git clone https://git.openembedded.org/openembedded-core
+ $ cd openembedded-core
Create a new branch
-------------------
@@ -177,7 +177,7 @@ to add the upgraded version.
is to look for prefixes used in previous commits touching the
same files or directories::
- git log --oneline <paths>
+ $ git log --oneline <paths>
#. For the commit description, provide detailed information
that describes what you changed, why you made the change, and the
@@ -278,7 +278,7 @@ Here is the general procedure on how to create patches to be sent through email:
For this purpose, a good solution is to store the cover letter contents
in the branch itself::
- git branch --edit-description
+ $ git branch --edit-description
This will open a text editor to fill in the description for your
changes. This description can be updated when necessary and will
@@ -334,19 +334,19 @@ functional testing of the changes will be performed by ``patchtest``. Currently,
it only supports testing patches for ``openembedded-core`` branches. To setup,
perform the following::
- pip install -r meta/lib/patchtest/requirements.txt
- source oe-init-build-env
- bitbake-layers add-layer ../meta-selftest
+ $ pip install -r meta/lib/patchtest/requirements.txt
+ $ source oe-init-build-env
+ $ bitbake-layers add-layer ../meta-selftest
Once these steps are complete and you have generated your patch files,
you can run ``patchtest`` like so::
- patchtest --patch <patch_name>
+ $ patchtest --patch <patch_name>
Alternatively, if you want ``patchtest`` to iterate over and test
multiple patches stored in a directory, you can use::
- patchtest --directory <directory_name>
+ $ patchtest --directory <directory_name>
By default, ``patchtest`` uses its own modules' file paths to determine what
repository and test suite to check patches against. If you wish to test
@@ -354,7 +354,7 @@ patches against a repository other than ``openembedded-core`` and/or use
a different set of tests, you can use the ``--repodir`` and ``--testdir``
flags::
- patchtest --patch <patch_name> --repodir <path/to/repo> --testdir <path/to/testdir>
+ $ patchtest --patch <patch_name> --repodir <path/to/repo> --testdir <path/to/testdir>
Finally, note that ``patchtest`` is designed to test patches in a standalone
way, so if your patches are meant to apply on top of changes made by
@@ -396,11 +396,11 @@ through a direct SMTP configuration in your Git ``~/.gitconfig`` file.
Here are the settings for letting ``git send-email`` send e-mail through your
regular STMP server, using a Google Mail account as an example::
- git config --global sendemail.smtpserver smtp.gmail.com
- git config --global sendemail.smtpserverport 587
- git config --global sendemail.smtpencryption tls
- git config --global sendemail.smtpuser ada.lovelace@gmail.com
- git config --global sendemail.smtppass = XXXXXXXX
+ $ git config --global sendemail.smtpserver smtp.gmail.com
+ $ git config --global sendemail.smtpserverport 587
+ $ git config --global sendemail.smtpencryption tls
+ $ git config --global sendemail.smtpuser ada.lovelace@gmail.com
+ $ git config --global sendemail.smtppass = XXXXXXXX
These settings will appear in the ``.gitconfig`` file in your home directory.
@@ -463,7 +463,7 @@ Sending Patches via Email
At this stage, you are ready to send your patches via email. Here's the
typical usage of ``git send-email``::
- git send-email --to <mailing-list-address> *.patch
+ $ git send-email --to <mailing-list-address> *.patch
Then, review each subject line and list of recipients carefully, and then
allow the command to send each message.
@@ -476,7 +476,7 @@ or any layer other than :oe_git:`openembedded-core </openembedded-core/>`,
please add the appropriate prefix so that it is clear which layer the patch is intended
to be applied to::
- git format-patch --subject-prefix="meta-oe][PATCH" ...
+ $ git format-patch --subject-prefix="meta-oe][PATCH" ...
.. note::
@@ -488,13 +488,13 @@ to be applied to::
Here's a command you can use if you just have one patch in your
branch::
- git send-email --to <mailing-list-address> -1
+ $ git send-email --to <mailing-list-address> -1
If you have multiple patches and a cover letter, you can send
patches for all the commits between the reference branch
and the tip of your branch::
- git send-email --cover-letter --cover-from-description=auto --to <mailing-list-address> -M <ref-branch>
+ $ git send-email --cover-letter --cover-from-description=auto --to <mailing-list-address> -M <ref-branch>
See the `git send-email manual page <https://git-scm.com/docs/git-send-email>`__
for details.
@@ -517,7 +517,7 @@ author name. The following will ensure that your e-mails have an additional
maintainers accepting your patches don't have to fix commit author information
manually::
- git config --global sendemail.from "linus.torvalds@kernel.org"
+ $ git config --global sendemail.from "linus.torvalds@kernel.org"
The ``sendemail.from`` should match your ``user.email`` setting,
which appears in the ``Signed-off-by`` line of your commits.
@@ -530,12 +530,12 @@ with ``git send-email``, you can use Git configuration settings.
- To set the right mailing list address for a given repository::
- git config --local sendemail.to openembedded-devel@lists.openembedded.org
+ $ git config --local sendemail.to openembedded-devel@lists.openembedded.org
- If the mailing list requires a subject prefix for the layer
(this only works when the repository only contains one layer)::
- git config --local format.subjectprefix "meta-something][PATCH"
+ $ git config --local format.subjectprefix "meta-something][PATCH"
Using Scripts to Push a Change Upstream and Request a Pull
==========================================================
@@ -597,7 +597,7 @@ have been followed:
enter the following command to bring up a short list of all
commits against a specific file::
- git shortlog -- filename
+ $ git shortlog -- filename
Just provide the name of the file for which you are interested. The
information returned is not ordered by history but does include a
@@ -719,7 +719,7 @@ follows:
``git format-patch``, for example to submit a patch to the
"&DISTRO_NAME_NO_CAP_MINUS_ONE;" branch use::
- git format-patch --subject-prefix='&DISTRO_NAME_NO_CAP_MINUS_ONE;][PATCH' ...
+ $ git format-patch --subject-prefix='&DISTRO_NAME_NO_CAP_MINUS_ONE;][PATCH' ...
Taking Patch Review into Account
================================
@@ -745,7 +745,7 @@ without the reported issues.
A single patch can be amended using ``git commit --amend``, and multiple
patches can be easily reworked and reordered through an interactive Git rebase::
- git rebase -i <ref-branch>
+ $ git rebase -i <ref-branch>
See `this tutorial <https://hackernoon.com/beginners-guide-to-interactive-rebasing-346a3f9c3a6d>`__
for practical guidance about using Git interactive rebasing.
@@ -755,7 +755,7 @@ sending the revised patch to mark the new iteration as ``[PATCH v2]``,
``[PATCH v3]``, etc as appropriate. This can be done by passing the ``-v``
argument to ``git format-patch`` with a version number::
- git format-patch -v2 <ref-branch>
+ $ git format-patch -v2 <ref-branch>
After generating updated patches (v2, v3, and so on) via ``git
@@ -86,7 +86,7 @@ For now, our fragment exists and is listed by the
enable this fragment, use the :ref:`ref-bitbake-config-build-enable-fragment`
command::
- bitbake-config-build enable-fragment meta-custom/custom-fragment
+ $ bitbake-config-build enable-fragment meta-custom/custom-fragment
.. note::
@@ -143,4 +143,4 @@ configuration file:
You can then use the :ref:`ref-bitbake-config-build-enable-fragment` command to
set a value to the ``CUSTOM_VARIABLE`` variable::
- bitbake-config-build enable-fragment custom-builtin-fragment/somevalue
+ $ bitbake-config-build enable-fragment custom-builtin-fragment/somevalue
@@ -821,7 +821,6 @@ missing dependency clearly visible at the end::
^
compilation terminated.
make: *** [tools/snep-send.o] Error 1
- $
Creating a Patch for the Fix
@@ -548,7 +548,7 @@ the two modes:
- To work on the source code of a recipe another instance of VSCode is
started in the recipe's workspace. Example::
- code build/workspace/sources/my-recipe
+ $ code build/workspace/sources/my-recipe
This instance of VSCode uses plugins that are useful for the development
of the application. ``devtool ide-sdk`` generates the necessary
@@ -720,9 +720,9 @@ the two modes:
VSCode. First of all we need a folder containing a CMake project.
For this example, let's create a CMake project and start VSCode::
- mkdir kit-test
- echo "project(foo VERSION 1.0)" > kit-test/CMakeLists.txt
- code kit-test
+ $ mkdir kit-test
+ $ echo "project(foo VERSION 1.0)" > kit-test/CMakeLists.txt
+ $ code kit-test
If there is a CMake project in the workspace, cross-compilation is
supported:
@@ -33,7 +33,7 @@ disk space. However, only the most recent ones are likely to be reused.
The following command is a quick way to purge all the cache files which
haven't been used for a least a specified number of days::
- find build/sstate-cache -type f -mtime +$DAYS -delete
+ $ find build/sstate-cache -type f -mtime +$DAYS -delete
The above command relies on the fact that BitBake touches the sstate cache
files as it accesses them, when it has write access to the cache.
@@ -49,7 +49,7 @@ requires a full build environment to be available and doesn't work well
covering multiple releases. It won't work either on limited environments
such as BSD based NAS::
- sstate-cache-management.py --remove-duplicated --cache-dir=sstate-cache
+ $ sstate-cache-management.py --remove-duplicated --cache-dir=sstate-cache
This command will ask you to confirm the deletions it identifies.
Run ``sstate-cache-management.py`` for more details about this script.
@@ -22,7 +22,7 @@ the :term:`BitBake` repository, which can be found :oe_git:`here </bitbake>`.
To start a basic Hash Equivalence server, one could simply run::
- ./bin/bitbake-hashserv
+ $ ./bin/bitbake-hashserv
This will take all of the default options of the script, which are already
sufficient to start a local server.
@@ -104,7 +104,7 @@ details.
#. Then, start a heavy-load build, for example::
- bitbake virtual/kernel -c compile -f
+ $ bitbake virtual/kernel -c compile -f
You can stop the build at anytime with Control + C.
@@ -106,19 +106,19 @@ Here 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::
- recipetool create -o OUTFILE source
+ $ recipetool create -o OUTFILE source
- 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`::
- recipetool create -o OUTFILE -x EXTERNALSRC source
+ $ recipetool create -o OUTFILE -x EXTERNALSRC source
- 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::
- recipetool create -d -o OUTFILE source
+ $ recipetool create -d -o OUTFILE source
Locating and Using a Similar Recipe
-----------------------------------
@@ -176,7 +176,7 @@ 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::
- bitbake-prserv --host ip --port port --start
+ $ bitbake-prserv --host ip --port port --start
In addition to
hand-starting the service, you need to update the
@@ -25,7 +25,6 @@ functions::
pydevshell> d.delVar("FOO")
pydevshell> d.getVar("FOO")
pydevshell> bb.build.exec_func("do_unpack", d)
- pydevshell>
See the ":ref:`bitbake-user-manual/bitbake-user-manual-metadata:functions you can call from within python`"
section in the BitBake User Manual for details about available functions.
@@ -65,7 +65,7 @@ available. Follow these general steps to run QEMU:
initializes the toolchain. For example, the following commands run
the initialization script from the default ``poky_sdk`` directory::
- . poky_sdk/environment-setup-core2-64-poky-linux
+ $ . poky_sdk/environment-setup-core2-64-poky-linux
#. *Ensure the Artifacts are in Place:* You need to be sure you have a
pre-built kernel that will boot in QEMU. You also need the target
@@ -227,15 +227,15 @@ using an NFS server.
- To start the NFS share::
- runqemu-export-rootfs start file-system-location
+ $ runqemu-export-rootfs start file-system-location
- To stop the NFS share::
- runqemu-export-rootfs stop file-system-location
+ $ runqemu-export-rootfs stop file-system-location
- To restart the NFS share::
- runqemu-export-rootfs restart file-system-location
+ $ runqemu-export-rootfs restart file-system-location
QEMU CPU Compatibility Under KVM
================================
@@ -423,7 +423,7 @@ your Yocto Project build host:
replace the PackageFamilyName and your user on the following path
to find your VHDX file::
- ls C:\Users\myuser\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79abcdefgh\LocalState\
+ C:\WINDOWS\system32> ls C:\Users\myuser\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79abcdefgh\LocalState
Mode LastWriteTime Length Name
-a---- 3/14/2020 9:52 PM 57418973184 ext4.vhdx
@@ -80,9 +80,9 @@ the CLI, you need to do the following after your image is built:
#. 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
+ $ mkdir -p /tmp/$USER-weston
+ $ chmod 0700 /tmp/$USER-weston
+ $ export XDG_RUNTIME_DIR=/tmp/$USER-weston
#. Launch Weston in the shell::
@@ -75,7 +75,6 @@ section:
$ bitbake-layers create-layer ../layers/meta-mylayer
NOTE: Starting bitbake server...
Add your new layer with 'bitbake-layers add-layer ../layers/meta-mylayer'
- $
.. note::
@@ -98,7 +97,6 @@ section:
$ cd bitbake-builds/build
$ bitbake-layers add-layer ../../meta-mylayer
NOTE: Starting bitbake server...
- $
#. *Build the Clean Image:* The final step in preparing to work on the
kernel is to build an initial image using ``bitbake``::
@@ -194,7 +192,6 @@ section:
$ cd bitbake-builds/build
$ bitbake-layers add-layer ../../meta-mylayer
NOTE: Starting bitbake server ...
- $
#. *Create a Local Copy of the Kernel Git Repository:* You can find Git
repositories of supported Yocto Project kernels organized under
@@ -46,8 +46,8 @@ not specify the final expand parameter to calls that do specify the
parameter. You can run the following ``sed`` command at the base of a
layer to make this change::
- sed -e 's:\(\.getVar([^,()]*\)):\1, False):g' -i `grep -ril getVar *`
- sed -e 's:\(\.getVarFlag([^,()]*,[^,()]*\)):\1, False):g' -i `grep -ril getVarFlag *`
+ $ sed -e 's:\(\.getVar([^,()]*\)):\1, False):g' -i `grep -ril getVar *`
+ $ sed -e 's:\(\.getVarFlag([^,()]*,[^,()]*\)):\1, False):g' -i `grep -ril getVarFlag *`
.. note::
@@ -138,11 +138,11 @@ BitBake Changes
:ref:`ref-classes-archiver` classes). There is a BitBake option to complete this for
any arbitrary task. For example::
- bitbake <target> -c fetchall
+ $ bitbake <target> -c fetchall
should now be replaced with::
- bitbake <target> --runall=fetch
+ $ bitbake <target> --runall=fetch
.. _migration-2.5-python-and-python3-changes:
@@ -256,7 +256,7 @@ Miscellaneous changes
- The Python development shell (previously known as ``devpyshell``) feature has been
renamed to ``pydevshell``. To start it you should now run::
- bitbake <target> -c pydevshell
+ $ bitbake <target> -c pydevshell
- The ``packagegroups-core-full-cmdline-libs`` packagegroup is no longer produced, as
libraries should normally be brought in via dependencies. If you have any references
@@ -83,16 +83,16 @@ How to make those adjustments without tedious manual editing
The following sed command can be used to remove S = "${WORKDIR}/git
across a whole layer::
- sed -i "/^S = \"\${WORKDIR}\/git\"/d" `find . -name '*.bb' -o -name '*.inc' -o -name '*.bbclass'`
+ $ sed -i "/^S = \"\${WORKDIR}\/git\"/d" `find . -name '*.bb' -o -name '*.inc' -o -name '*.bbclass'`
Then, the following command can tweak the remaining :term:`S` assignments to
refer to :term:`UNPACKDIR` instead of :term:`WORKDIR`::
- sed -i "s/^S = \"\${WORKDIR}\//S = \"\${UNPACKDIR}\//g" `find . -name '*.bb' -o -name '*.inc' -o -name '*.bbclass'`
+ $ sed -i "s/^S = \"\${WORKDIR}\//S = \"\${UNPACKDIR}\//g" `find . -name '*.bb' -o -name '*.inc' -o -name '*.bbclass'`
The first change can introduce a lot of consecutive empty lines, so those can be removed with::
- sed -i -z -E 's/([ \t\f\v\r]*\n){3,}/\n\n/g' `find . -name '*.bb' -o -name '*.inc'`
+ $ sed -i -z -E 's/([ \t\f\v\r]*\n){3,}/\n\n/g' `find . -name '*.bb' -o -name '*.inc'`
BitBake Git fetcher ``tag`` parameter
@@ -312,11 +312,11 @@ The following classes have been removed in this release:
#. Use the specific FIT image recipe rather than the base kernel recipe.
For example, instead of::
- bitbake linux-yocto
+ $ bitbake linux-yocto
the FIT image is now build by::
- bitbake linux-yocto-fitimage
+ $ bitbake linux-yocto-fitimage
For custom kernel recipes, creating a corresponding custom FIT image recipe
is usually a good approach.
@@ -173,7 +173,7 @@ New Features / Enhancements in 4.2
command, which allowed to spot and fix a regression in the
``quilt`` ptest::
- yocto_testresults_query.py regression-report 4.2_M1 4.2_M2
+ $ yocto_testresults_query.py regression-report 4.2_M1 4.2_M2
See this `blog post about regression detection
<https://bootlin.com/blog/continuous-integration-in-yocto-improving-the-regressions-detection/>`__.
@@ -466,7 +466,7 @@ New Features / Enhancements in |yocto-ver|
- The script can now run compressed images with snapshot mode. For
example, with :term:`IMAGE_FSTYPES` containing ``ext4.zst``, you can run::
- runqemu snapshot ext4.zst <image-recipe>
+ $ runqemu snapshot ext4.zst <image-recipe>
- Add support for the ``erofs`` filesystem.
@@ -366,7 +366,7 @@ To do so, create a recipe for your program, for example using
make it inherit the :ref:`ref-classes-cargo` and
:ref:`ref-classes-cargo-update-recipe-crates` and run::
- bitbake -c update_crates recipe
+ $ bitbake -c update_crates recipe
This creates a ``recipe-crates.inc`` file that you can include in your
recipe::
@@ -1373,7 +1373,7 @@ The simplest example for building a FIT image is to add::
to the machine :term:`configuration file` and to execute::
- bitbake linux-yocto-fitimage
+ $ bitbake linux-yocto-fitimage
This results in a ``fitImage`` file deployed to the :term:`DEPLOY_DIR_IMAGE`
directory and a ``linux-yocto-fitimage`` package which can be installed.
@@ -1387,7 +1387,7 @@ lines to the machine configuration file::
The FIT image, this time including the RT kernel, is built again by calling::
- bitbake linux-yocto-fitimage
+ $ bitbake linux-yocto-fitimage
For other kernels provided by other layers, the same approach would work.
However, it is usually more intuitive to add a custom FIT image recipe next to
@@ -3863,7 +3863,7 @@ build.
Example usage::
- bitbake -c generate_vex openssl
+ $ bitbake -c generate_vex openssl
.. _ref-classes-waf:
@@ -461,7 +461,6 @@ Here is an example that resets the workspace directory that contains the
$ devtool reset mtr
NOTE: Cleaning sysroot for recipe mtr...
NOTE: Leaving source tree /home/scottrif/bitbake-builds/build/workspace/sources/mtr as-is; if you no longer need it then please delete it manually
- $
.. _devtool-finish-working-on-a-recipe:
@@ -634,7 +633,6 @@ to create and add the ``mtr_0.86.bb`` recipe to the ``workspace`` directory::
$ devtool status
mtr:/home/scottrif/bitbake-builds/build/workspace/sources/mtr (/home/scottrif/bitbake-builds/build/workspace/recipes/mtr/mtr_0.86.bb)
- $
.. _devtool-search-for-available-target-recipes:
@@ -72,25 +72,25 @@ command, you can determine which fragments can be enabled for your build.
For example, the following command would enable the
:ref:`ref-fragments-core-yocto-sstate-mirror-cdn` fragment::
- bitbake-config-build enable-fragment core/yocto/sstate-mirror-cdn
+ $ bitbake-config-build enable-fragment core/yocto/sstate-mirror-cdn
.. note::
Multiple fragments can be enabled at once with the same command::
- bitbake-config-build enable-fragment <fragment1> <fragment2> ...
+ $ bitbake-config-build enable-fragment <fragment1> <fragment2> ...
:term:`Built-in fragments <Built-in Fragment>` are enabled the same way, and
their values are defined from the command-line directly. For example, the
following command sets the ``qemuarm64`` :term:`MACHINE` through the
:ref:`ref-fragments-builtin-core-machine` fragment::
- bitbake-config-build enable-fragment machine/qemuarm64
+ $ bitbake-config-build enable-fragment machine/qemuarm64
This fragment can be overridden from the command-line by setting it to another
value, for example::
- bitbake-config-build enable-fragment machine/qemux86-64
+ $ bitbake-config-build enable-fragment machine/qemux86-64
In the above example, the new value of :term:`MACHINE` is now equal to
``qemux86-64``.
@@ -118,18 +118,18 @@ command. The list of enabled fragments can be obtained with
For example, the following command disables the
:ref:`ref-fragments-core-yocto-sstate-mirror-cdn` fragment::
- bitbake-config-build disable-fragment core/yocto/sstate-mirror-cdn
+ $ bitbake-config-build disable-fragment core/yocto/sstate-mirror-cdn
Likewise, :term:`Built-in Fragments <Built-in Fragment>` are disabled the
same way. For example, this would disable the ``machine/qemuarm64`` fragment::
- bitbake-config-build disable-fragment machine/qemuarm64
+ $ bitbake-config-build disable-fragment machine/qemuarm64
.. note::
Multiple fragments can be disabled at once with the same command::
- bitbake-config-build disable-fragment <fragment1> <fragment2>
+ $ bitbake-config-build disable-fragment <fragment1> <fragment2>
.. _ref-bitbake-config-build-disable-all-fragments:
@@ -142,7 +142,7 @@ currently enabled fragments. The list of enabled fragments can be obtained with
This command is run without arguments::
- bitbake-config-build disable-all-fragments
+ $ bitbake-config-build disable-all-fragments
Core Fragments
==============
@@ -573,14 +573,14 @@ patched file to still compile without errors.
Use the ``devtool`` command as explained by the warning. First, unpack the
source into devtool workspace::
- devtool modify <recipe>
+ $ 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::
- devtool finish --force-patch-refresh <recipe> <layer_path>
+ $ devtool finish --force-patch-refresh <recipe> <layer_path>
The patch updates then need be reviewed (preferably with a side-by-side diff
tool) to ensure they are indeed doing the right thing i.e.:
@@ -968,7 +968,7 @@ system and gives an overview of their function and contents.
Use the following format to export the variable to the BitBake
environment::
- export BBSERVER=localhost:$port
+ $ export BBSERVER=localhost:$port
By default, :term:`BBSERVER` also appears in :term:`BB_BASEHASH_IGNORE_VARS`.
Consequently, :term:`BBSERVER` is excluded from checksum and dependency
@@ -9326,7 +9326,7 @@ system and gives an overview of their function and contents.
You can obtain the signature of all the tasks for the recipe ``bc`` using::
- bitbake -S none bc
+ $ bitbake -S none bc
Then you can look at files in ``build/tmp/stamps/<arch>/bc`` and look for
files like: ``<PV>.do_compile.sigdata.09772aa4532512baf96d433484f27234d4b7c11dd9cda0d6f56fa1b7ce6f25f0``.
@@ -9483,7 +9483,7 @@ system and gives an overview of their function and contents.
This file requires permissions set to ``400`` or ``600`` to prevent
other users from reading the file::
- chmod 600 "$HOME/.netrc"
+ $ chmod 600 "$HOME/.netrc"
Another method to configure the username and password is from the URL
in :term:`SOURCE_MIRROR_URL` directly, with the ``user`` and ``pswd``
@@ -89,7 +89,7 @@ it always depends upon the paths it is built in.
To run our automated selftest, as we use in our CI on the Autobuilder, you can
run::
- oe-selftest -r reproducible.ReproducibleTests.test_reproducible_builds
+ $ oe-selftest -r reproducible.ReproducibleTests.test_reproducible_builds
This defaults to including a ``world`` build so, if other layers are added, it
would also run the tests for recipes in the additional layers. Different build
@@ -326,7 +326,7 @@ You can start the tests automatically or manually:
Next, build your image. If the image successfully builds, the
tests run::
- bitbake core-image-sato
+ $ bitbake core-image-sato
- *Manually running tests:* To manually run the tests, first globally
inherit the :ref:`ref-classes-testimage` class by editing your
@@ -336,7 +336,7 @@ You can start the tests automatically or manually:
Next, use BitBake to run the tests::
- bitbake -c testimage image
+ $ bitbake -c testimage image
All test files reside in ``meta/lib/oeqa/runtime/cases`` in
:term:`OpenEmbedded-Core (OE-Core)`. A test name maps
Most command blocks in the manuals start their lines with "$", but a scattering of them do not, and those read as a file listing rather than as something to run. Give them the prompt the surrounding pages already use. Transcripts take a prompt on their opening line alone. Two things that matter only once a line is a command go with that: a bare "$" at the end, the prompt returning after the command finished, and a trailing "\" on a Windows path, which a shell reads as a continuation into the output. AI-Generated: codex/claude-opus 5 (xhigh) Signed-off-by: Trevor Woerner <twoerner@gmail.com> --- documentation/brief-yoctoprojectqs/index.rst | 2 +- .../contributor-guide/recipe-style-guide.rst | 2 +- .../contributor-guide/submit-changes.rst | 60 +++++++++---------- .../dev-manual/creating-fragments.rst | 4 +- documentation/dev-manual/debugging.rst | 1 - documentation/dev-manual/devtool.rst | 8 +-- documentation/dev-manual/disk-space.rst | 4 +- documentation/dev-manual/hashequivserver.rst | 2 +- .../dev-manual/limiting-resources.rst | 2 +- documentation/dev-manual/new-recipe.rst | 6 +- documentation/dev-manual/packages.rst | 2 +- .../dev-manual/python-development-shell.rst | 1 - documentation/dev-manual/qemu.rst | 8 +-- documentation/dev-manual/start.rst | 2 +- documentation/dev-manual/wayland.rst | 6 +- documentation/kernel-dev/common.rst | 3 - .../migration-guides/migration-2.1.rst | 4 +- .../migration-guides/migration-2.5.rst | 4 +- .../migration-guides/migration-4.0.rst | 2 +- .../migration-guides/migration-5.3.rst | 10 ++-- .../migration-guides/release-notes-4.2.rst | 2 +- .../migration-guides/release-notes-5.3.rst | 2 +- documentation/ref-manual/classes.rst | 8 +-- .../ref-manual/devtool-reference.rst | 2 - documentation/ref-manual/fragments.rst | 16 ++--- documentation/ref-manual/qa-checks.rst | 4 +- documentation/ref-manual/variables.rst | 6 +- .../test-manual/reproducible-builds.rst | 2 +- documentation/test-manual/runtime-testing.rst | 4 +- 29 files changed, 86 insertions(+), 93 deletions(-)