@@ -18,5 +18,5 @@ maintainers.
If the issue is in the core metadata layer (OpenEmbedded-Core) or in BitBake,
issues can be reported in the :yocto_bugs:`Yocto Project Bugzilla <>`. The
-:yocto_lists:`yocto </g/yocto>` mailing list is a general “catch-all” location
-where questions can be sent if you can’t work out where something should go.
+:yocto_lists:`yocto </g/yocto>` mailing list is a general "catch-all" location
+where questions can be sent if you can't work out where something should go.
@@ -7,8 +7,8 @@ Yocto Project and OpenEmbedded Contributor Guide
The Yocto Project and OpenEmbedded are open-source, community-based projects so
contributions are very welcome, it is how the code evolves and everyone can
effect change. Contributions take different forms, if you have a fix for an
-issue you’ve run into, a patch is the most appropriate way to contribute it.
-If you run into an issue but don’t have a solution, opening a defect in
+issue you've run into, a patch is the most appropriate way to contribute it.
+If you run into an issue but don't have a solution, opening a defect in
:yocto_bugs:`Bugzilla <>` or asking questions on the mailing lists might be
more appropriate. This guide intends to point you in the right direction to
this.
@@ -192,11 +192,11 @@ Custom tasks should be sorted similarly.
Package specific variables are typically grouped together, e.g.::
- RDEPENDS:${PN} = “foo”
- RDEPENDS:${PN}-libs = “bar”
+ RDEPENDS:${PN} = "foo"
+ RDEPENDS:${PN}-libs = "bar"
- RRECOMMENDS:${PN} = “one”
- RRECOMMENDS:${PN}-libs = “two”
+ RRECOMMENDS:${PN} = "one"
+ RRECOMMENDS:${PN}-libs = "two"
Recipe License Fields
---------------------
@@ -17,7 +17,7 @@ Both Yocto Project and OpenEmbedded have many key components that are
maintained by patches being submitted on mailing lists. We appreciate this
approach does look a little old fashioned when other workflows are available
through web technology such as GitHub, GitLab and others. Since we are often
-asked this question, we’ve decided to document the reasons for using mailing
+asked this question, we've decided to document the reasons for using mailing
lists.
One significant factor is that we value peer review. When a change is proposed
@@ -40,7 +40,7 @@ of key people from the project, which would again be to its detriment.
The projects are acutely aware that potential new contributors find the
mailing list approach off-putting and would prefer a web-based GUI.
-Since we don’t believe that can work for us, the project is aiming to ensure
+Since we don't believe that can work for us, the project is aiming to ensure
`patchwork <https://patchwork.yoctoproject.org/>`__ is available to help track
patch status and also looking at how tooling can provide more feedback to users
about patch status. We are looking at improving tools such as ``patchtest`` to
@@ -358,7 +358,7 @@ You can examine build history output from the command line or from a web
interface.
To see any changes that have occurred (assuming you have
-:term:`BUILDHISTORY_COMMIT` = "1"),
+:term:`BUILDHISTORY_COMMIT` = "1"),
you can simply use any Git command that allows you to view the history
of a repository. Here is one method::
@@ -152,7 +152,7 @@ Shell functions and tasks can also be inspected with the same mechanism::
For Python functions and tasks, ``bitbake -e recipename`` can be used instead.
-Moreover, the output of the ``bitbake -e`` and ``bitbake -e`` recipe commands
+Moreover, the output of the ``bitbake -e`` and ``bitbake -e`` recipe commands
includes the following information:
- The output starts with a tree listing all configuration files and
@@ -187,7 +187,7 @@ Here are a few of the available ``oe-pkgdata-util`` subcommands.
that have been built, optionally limiting the match to packages that
match pattern.
-- ``oe-pkgdata-util list-pkg-files package ...``: Lists the
+- ``oe-pkgdata-util list-pkg-files package ...``: Lists the
files and directories contained in the given packages.
.. note::
@@ -205,7 +205,7 @@ Here are a few of the available ``oe-pkgdata-util`` subcommands.
directory, make sure that :ref:`ref-classes-rm-work` is not
enabled when you build the recipe.
-- ``oe-pkgdata-util find-path path ...``: Lists the names of
+- ``oe-pkgdata-util find-path path ...``: Lists the names of
the packages that contain the given paths. For example, the following
tells us that ``/usr/share/man/man1/make.1`` is contained in the
``make-doc`` package::
@@ -213,7 +213,7 @@ Here are a few of the available ``oe-pkgdata-util`` subcommands.
$ oe-pkgdata-util find-path /usr/share/man/man1/make.1
make-doc: /usr/share/man/man1/make.1
-- ``oe-pkgdata-util lookup-recipe package ...``: Lists the name
+- ``oe-pkgdata-util lookup-recipe package ...``: Lists the name
of the recipes that produce the given packages.
For more information on the ``oe-pkgdata-util`` command, use the help
@@ -362,7 +362,7 @@ You can also use BitBake to dump out the signature construction
information without executing tasks by using either of the following
BitBake command-line options::
- ‐‐dump-signatures=SIGNATURE_HANDLER
+ --dump-signatures=SIGNATURE_HANDLER
-S SIGNATURE_HANDLER
@@ -1072,7 +1072,7 @@ debugger.
the actual image (e.g. ``gdb-cross-i586``). The suggestion is usually the
actual name you want to use.
-#. *Set up the* ``debugfs``\ *:*
+#. *Set up the* ``debugfs``\ *:*
Run the following commands to set up the ``debugfs``::
@@ -1106,7 +1106,7 @@ debugger.
.. code-block:: shell
- root@qemux86:~# gdbserver localhost:1234 /bin/gzip —help
+ root@qemux86:~# gdbserver localhost:1234 /bin/gzip --help
For
additional gdbserver options, see the `GDB Server
@@ -99,14 +99,14 @@ command::
otherwise $EDITOR, otherwise vi.
Use recipetool <subcommand> --help to get help on a specific command
-Running ``recipetool create -o OUTFILE`` creates the base recipe and
+Running ``recipetool create -o OUTFILE`` creates the base recipe and
locates it properly in the layer that contains your source files.
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
@@ -577,7 +577,7 @@ applies the new configuration before building the kernel.
For a detailed example showing how to configure the kernel, see the
":ref:`kernel-dev/common:configuring the kernel`" section.
-Using an "In-Tree" ``defconfig`` File
+Using an "In-Tree" ``defconfig`` File
--------------------------------------
It might be desirable to have kernel configuration fragment support
@@ -973,7 +973,7 @@ possible.
For more information on kernel configuration, see the
":ref:`kernel-dev/common:changing the configuration`" section.
-Using ``menuconfig``
+Using ``menuconfig``
---------------------
The easiest way to define kernel configurations is to set them through
@@ -1079,7 +1079,7 @@ kernel layer.
Be sure to make a copy of the ``.config`` file and do not just rename it.
The build system needs an existing ``.config`` file from which to work.
-Creating a ``defconfig`` File
+Creating a ``defconfig`` File
------------------------------
A ``defconfig`` file in the context of the Yocto Project is often a
@@ -1708,12 +1708,12 @@ Showing a Particular Feature or Branch Change
---------------------------------------------
Tags in the Yocto Project kernel tree divide changes for significant
-features or branches. The ``git show`` tag command shows changes based
+features or branches. The ``git show`` tag command shows changes based
on a tag. Here is an example that shows ``systemtap`` changes::
$ git show systemtap
-You can use the ``git branch --contains`` tag command to
+You can use the ``git branch --contains`` tag command to
show the branches that contain a particular feature. This command shows
the branches that contain the ``systemtap`` feature::
@@ -191,7 +191,7 @@ Known Issues in 4.1
~~~~~~~~~~~~~~~~~~~
- The change to :ref:`migration-4.1-complementary-deps` means that images
- built with the ``ptest-pkgs`` :term:`IMAGE_FEATURES` don’t automatically
+ built with the ``ptest-pkgs`` :term:`IMAGE_FEATURES` don't automatically
install ``ptest-runner``, as that package is a recommendation of the
individual ``-ptest`` packages. This will be resolved in the next point
release, and can be worked around by explicitly installing ``ptest-runner``
@@ -152,7 +152,7 @@ barebox, enabling tasks such as :ref:`ref-tasks-menuconfig` and
The generated barebox binaries are deployed to
:term:`DEPLOY_DIR_IMAGE` as well as installed to ``BAREBOX_INSTALL_PATH``
-(``/boot`` by default) making them part of the recipe’s base package.
+(``/boot`` by default) making them part of the recipe's base package.
This setup supports both using the barebox binaries as independent artifacts
and installing them into a rootfs.
:term:`BAREBOX_BINARY` can be used to select a distinct binary to deploy and
@@ -3687,7 +3687,7 @@ for details.
The :ref:`ref-classes-upstream-stable-release-point` class automatically
generates the :term:`UPSTREAM_STABLE_RELEASE_REGEX` variable for recipes
whose version uses a dot-separated scheme. This enables stable point release
-upgrades — version upgrades constrained to the same stable series (e.g.
+upgrades -- version upgrades constrained to the same stable series (e.g.
``1.4.2`` to ``1.4.3`` but not to ``1.5.0``).
The class uses the :term:`STABLE_VERSION_PARTS` variable (defaults to ``"2"``)
@@ -517,7 +517,7 @@ Deploying Your Software on the Target Machine
Use the ``devtool deploy-target`` command to deploy the recipe's build
output to the live target machine::
- $ devtool deploy-target recipe target
+ $ devtool deploy-target recipe target
The target is the address of the target machine, which must be running
an SSH server (i.e. ``user@hostname[:destdir]``).
@@ -588,7 +588,7 @@ command to work, you must have previously used the
":ref:`devtool deploy-target <ref-manual/devtool-reference:deploying your software on the target machine>`"
command::
- $ devtool undeploy-target recipe target
+ $ devtool undeploy-target recipe target
The target is the
address of the target machine, which must be running an SSH server (i.e.
@@ -164,7 +164,7 @@ to support, however there isn't wide enough interest and support to justify
testing all incoming changes on it. There are however project member
organisations and maintainers willing to run tests and review fixes.
-This category may be applicable as support/usage in an area develops and grows,
+This category may be applicable as support/usage in an area develops and grows,
or as support/usage fades but we continue to have tests. It can also apply where
resourcing isn't available for full primary support but there is
member/maintainer support for running tests.
@@ -173,21 +173,21 @@ We therefore have the following criteria and policies for such items:
- It can be clearly isolated and defined by specific configuration.
-- There is a clear documented group of maintainers agreeing to maintain it.
+- There is a clear documented group of maintainers agreeing to maintain it.
- Those maintainers are active and responsive.
- It is being actively and publicly tested (potentially using
- the :ref:`Autobuilder <test-manual/intro:Yocto Project Autobuilder Overview>`
+ the :ref:`Autobuilder <test-manual/intro:Yocto Project Autobuilder Overview>`
by agreement, or otherwise).
-- Testing would not be part of standard incoming change testing and regressions
+- Testing would not be part of standard incoming change testing and regressions
would not block incoming patches.
- The :yocto_wiki:`SWAT </Yocto_Build_Failure_Swat_Team>` team would not handle
any test builds on the Autobuilder.
-- Test results can be submitted as part of the release process if desired.
+- Test results can be submitted as part of the release process if desired.
The Yocto Project :yocto_wiki:`Technical Steering Committee (TSC) </TSC>` makes
decisions on features in this status and Autobuilder testing. Such support would
@@ -115,7 +115,7 @@ Here are key best practices the program tries to encourage:
user changes a configuration setting to activate the layer, by selecting
a :term:`MACHINE`, a :term:`DISTRO` or a :term:`DISTRO_FEATURES` setting.
-- Layers should be documenting where they don’t support normal "core"
+- Layers should be documenting where they don't support normal "core"
functionality such as where debug symbols are disabled or missing, where
development headers and on-target library usage may not work or where
functionality like the SDK/eSDK would not be expected to work.
@@ -33,7 +33,7 @@ Transitioning to a custom environment for systems development
Layer Index <>` to find and acquire the best BSP for your
target board. The Yocto Project layer index BSPs are regularly validated. The
best place to get your first BSP is from your silicon manufacturer or board
- vendor – they can point you to their most qualified efforts. In general, for
+ vendor - they can point you to their most qualified efforts. In general, for
Intel silicon use ``meta-intel``, for Texas Instruments use ``meta-ti``, and so
forth. Choose a BSP that has been tested with the same Yocto Project release
that you've downloaded. Be aware that some BSPs may not be immediately
@@ -86,13 +86,13 @@ contact us with other suggestions.
pinpoint where trouble is occurring and how the build is breaking. The
workflow breaks down into the following steps:
- #. Fetch – get the source code
- #. Extract – unpack the sources
- #. Patch – apply patches for bug fixes and new capability
- #. Configure – set up your environment specifications
- #. Build – compile and link
- #. Install – copy files to target directories
- #. Package – bundle files for installation
+ #. Fetch - get the source code
+ #. Extract - unpack the sources
+ #. Patch - apply patches for bug fixes and new capability
+ #. Configure - set up your environment specifications
+ #. Build - compile and link
+ #. Install - copy files to target directories
+ #. Package - bundle files for installation
During "fetch", there may be an inability to find code. During "extract",
there is likely an invalid zip or something similar. In other words, the