diff --git a/documentation/contributor-guide/identify-component.rst b/documentation/contributor-guide/identify-component.rst index 6cf8ed985..26308a0e9 100644 --- a/documentation/contributor-guide/identify-component.rst +++ b/documentation/contributor-guide/identify-component.rst @@ -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 ` 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 ` mailing list is a general "catch-all" location +where questions can be sent if you can't work out where something should go. diff --git a/documentation/contributor-guide/index.rst b/documentation/contributor-guide/index.rst index a83216945..b374cc1c4 100644 --- a/documentation/contributor-guide/index.rst +++ b/documentation/contributor-guide/index.rst @@ -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. diff --git a/documentation/contributor-guide/recipe-style-guide.rst b/documentation/contributor-guide/recipe-style-guide.rst index f81ffb2ab..84c6bb14e 100644 --- a/documentation/contributor-guide/recipe-style-guide.rst +++ b/documentation/contributor-guide/recipe-style-guide.rst @@ -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 --------------------- diff --git a/documentation/contributor-guide/submit-changes.rst b/documentation/contributor-guide/submit-changes.rst index ae7a097ad..48c8af2fe 100644 --- a/documentation/contributor-guide/submit-changes.rst +++ b/documentation/contributor-guide/submit-changes.rst @@ -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 `__ 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 diff --git a/documentation/dev-manual/build-quality.rst b/documentation/dev-manual/build-quality.rst index c2e46b69c..e9b066c44 100644 --- a/documentation/dev-manual/build-quality.rst +++ b/documentation/dev-manual/build-quality.rst @@ -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:: diff --git a/documentation/dev-manual/debugging.rst b/documentation/dev-manual/debugging.rst index 21fb10537..3afc17ad4 100644 --- a/documentation/dev-manual/debugging.rst +++ b/documentation/dev-manual/debugging.rst @@ -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 diff --git a/documentation/dev-manual/new-recipe.rst b/documentation/dev-manual/new-recipe.rst index 6888bb46a..d1c863117 100644 --- a/documentation/dev-manual/new-recipe.rst +++ b/documentation/dev-manual/new-recipe.rst @@ -99,14 +99,14 @@ command:: otherwise $EDITOR, otherwise vi. Use recipetool --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 diff --git a/documentation/kernel-dev/common.rst b/documentation/kernel-dev/common.rst index 136524e63..4e7d015e4 100644 --- a/documentation/kernel-dev/common.rst +++ b/documentation/kernel-dev/common.rst @@ -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:: diff --git a/documentation/migration-guides/release-notes-4.1.rst b/documentation/migration-guides/release-notes-4.1.rst index 81d541fac..4a3fb0d2c 100644 --- a/documentation/migration-guides/release-notes-4.1.rst +++ b/documentation/migration-guides/release-notes-4.1.rst @@ -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`` diff --git a/documentation/ref-manual/classes.rst b/documentation/ref-manual/classes.rst index 98dff1bac..f3d1aa64e 100644 --- a/documentation/ref-manual/classes.rst +++ b/documentation/ref-manual/classes.rst @@ -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"``) diff --git a/documentation/ref-manual/devtool-reference.rst b/documentation/ref-manual/devtool-reference.rst index 863825b06..6b21d302f 100644 --- a/documentation/ref-manual/devtool-reference.rst +++ b/documentation/ref-manual/devtool-reference.rst @@ -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 `" 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. diff --git a/documentation/ref-manual/yocto-project-supported-features.rst b/documentation/ref-manual/yocto-project-supported-features.rst index d7229f1c2..e209e54c4 100644 --- a/documentation/ref-manual/yocto-project-supported-features.rst +++ b/documentation/ref-manual/yocto-project-supported-features.rst @@ -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 ` + the :ref:`Autobuilder ` 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 ` 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) ` makes decisions on features in this status and Autobuilder testing. Such support would diff --git a/documentation/test-manual/yocto-project-compatible.rst b/documentation/test-manual/yocto-project-compatible.rst index 7a2e00a99..b4da178ec 100644 --- a/documentation/test-manual/yocto-project-compatible.rst +++ b/documentation/test-manual/yocto-project-compatible.rst @@ -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. diff --git a/documentation/transitioning-to-a-custom-environment.rst b/documentation/transitioning-to-a-custom-environment.rst index c69ab5361..b4dbc5224 100644 --- a/documentation/transitioning-to-a-custom-environment.rst +++ b/documentation/transitioning-to-a-custom-environment.rst @@ -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 diff --git a/documentation/what-i-wish-id-known.rst b/documentation/what-i-wish-id-known.rst index d89f43304..a8b9fabad 100644 --- a/documentation/what-i-wish-id-known.rst +++ b/documentation/what-i-wish-id-known.rst @@ -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