mirror of
https://git.yoctoproject.org/poky
synced 2026-06-02 13:29:49 +00:00
sphinx: fix a few typos or missing/too many words
(From yocto-docs rev: 744b74b3420ae475a566307e03e0b098986773e4) Signed-off-by: Quentin Schulz <foss@0leil.net> Signed-off-by: Nicolas Dechesne <nicolas.dechesne@linaro.org> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
committed by
Richard Purdie
parent
528cdb7cd5
commit
177aee09fe
@@ -102,7 +102,7 @@ commands to clone the Poky repository.
|
|||||||
remote: Counting
|
remote: Counting
|
||||||
objects: 432160, done. remote: Compressing objects: 100%
|
objects: 432160, done. remote: Compressing objects: 100%
|
||||||
(102056/102056), done. remote: Total 432160 (delta 323116), reused
|
(102056/102056), done. remote: Total 432160 (delta 323116), reused
|
||||||
432037 (delta 323000) Receiving objects: 100% (432160/432160), 153.81 MiB \| 8.54 MiB/s, done.
|
432037 (delta 323000) Receiving objects: 100% (432160/432160), 153.81 MiB | 8.54 MiB/s, done.
|
||||||
Resolving deltas: 100% (323116/323116), done.
|
Resolving deltas: 100% (323116/323116), done.
|
||||||
Checking connectivity... done.
|
Checking connectivity... done.
|
||||||
|
|
||||||
@@ -287,7 +287,7 @@ Follow these steps to add a hardware layer:
|
|||||||
This example adds the
|
This example adds the
|
||||||
`meta-altera <https://github.com/kraj/meta-altera>`__ hardware layer.
|
`meta-altera <https://github.com/kraj/meta-altera>`__ hardware layer.
|
||||||
|
|
||||||
#. **Clone the Layer** Use Git to make a local copy of the layer on your
|
#. **Clone the Layer:** Use Git to make a local copy of the layer on your
|
||||||
machine. You can put the copy in the top level of the copy of the
|
machine. You can put the copy in the top level of the copy of the
|
||||||
Poky repository created earlier:
|
Poky repository created earlier:
|
||||||
|
|
||||||
@@ -299,7 +299,7 @@ Follow these steps to add a hardware layer:
|
|||||||
remote: Counting objects: 25170, done.
|
remote: Counting objects: 25170, done.
|
||||||
remote: Compressing objects: 100% (350/350), done.
|
remote: Compressing objects: 100% (350/350), done.
|
||||||
remote: Total 25170 (delta 645), reused 719 (delta 538), pack-reused 24219
|
remote: Total 25170 (delta 645), reused 719 (delta 538), pack-reused 24219
|
||||||
Receiving objects: 100% (25170/25170), 41.02 MiB \| 1.64 MiB/s, done.
|
Receiving objects: 100% (25170/25170), 41.02 MiB | 1.64 MiB/s, done.
|
||||||
Resolving deltas: 100% (13385/13385), done.
|
Resolving deltas: 100% (13385/13385), done.
|
||||||
Checking connectivity... done.
|
Checking connectivity... done.
|
||||||
|
|
||||||
@@ -340,7 +340,7 @@ Follow these steps to add a hardware layer:
|
|||||||
$ cd ~/poky/build
|
$ cd ~/poky/build
|
||||||
$ bitbake-layers add-layer ../meta-altera
|
$ bitbake-layers add-layer ../meta-altera
|
||||||
NOTE: Starting bitbake server...
|
NOTE: Starting bitbake server...
|
||||||
Parsing recipes: 100% \|##################################################################\| Time: 0:00:32
|
Parsing recipes: 100% |##################################################################| Time: 0:00:32
|
||||||
Parsing of 918 .bb files complete (0 cached, 918 parsed). 1401 targets,
|
Parsing of 918 .bb files complete (0 cached, 918 parsed). 1401 targets,
|
||||||
123 skipped, 0 masked, 0 errors.
|
123 skipped, 0 masked, 0 errors.
|
||||||
|
|
||||||
@@ -388,7 +388,7 @@ Where To Go Next
|
|||||||
================
|
================
|
||||||
|
|
||||||
Now that you have experienced using the Yocto Project, you might be
|
Now that you have experienced using the Yocto Project, you might be
|
||||||
asking yourself "What now?" The Yocto Project has many sources of
|
asking yourself "What now?". The Yocto Project has many sources of
|
||||||
information including the website, wiki pages, and user manuals:
|
information including the website, wiki pages, and user manuals:
|
||||||
|
|
||||||
- **Website:** The :yocto_home:`Yocto Project Website <>` provides
|
- **Website:** The :yocto_home:`Yocto Project Website <>` provides
|
||||||
|
|||||||
@@ -787,7 +787,7 @@ Build Directory's hierarchy:
|
|||||||
- :term:`PN`: The name of the recipe used
|
- :term:`PN`: The name of the recipe used
|
||||||
to build the package. This variable can have multiple meanings.
|
to build the package. This variable can have multiple meanings.
|
||||||
However, when used in the context of input files, ``PN`` represents
|
However, when used in the context of input files, ``PN`` represents
|
||||||
the the name of the recipe.
|
the name of the recipe.
|
||||||
|
|
||||||
- :term:`WORKDIR`: The location
|
- :term:`WORKDIR`: The location
|
||||||
where the OpenEmbedded build system builds a recipe (i.e. does the
|
where the OpenEmbedded build system builds a recipe (i.e. does the
|
||||||
@@ -1125,8 +1125,7 @@ build system has created the final image output files.
|
|||||||
.. note::
|
.. note::
|
||||||
|
|
||||||
The entire image generation process is run under
|
The entire image generation process is run under
|
||||||
Pseudo
|
Pseudo. Running under Pseudo ensures that the files in the root filesystem
|
||||||
. Running under Pseudo ensures that the files in the root filesystem
|
|
||||||
have correct ownership.
|
have correct ownership.
|
||||||
|
|
||||||
.. _sdk-generation-dev-environment:
|
.. _sdk-generation-dev-environment:
|
||||||
@@ -1736,8 +1735,7 @@ objective of making native or cross packages relocatable.
|
|||||||
.. note::
|
.. note::
|
||||||
|
|
||||||
Both native and cross packages run on the
|
Both native and cross packages run on the
|
||||||
build host
|
build host. However, cross packages generate output for the target
|
||||||
. However, cross packages generate output for the target
|
|
||||||
architecture.
|
architecture.
|
||||||
|
|
||||||
The checksum therefore needs to exclude ``WORKDIR``. The simplistic
|
The checksum therefore needs to exclude ``WORKDIR``. The simplistic
|
||||||
|
|||||||
@@ -134,7 +134,7 @@ Project:
|
|||||||
- *License Manifest:* The Yocto Project provides a :ref:`license
|
- *License Manifest:* The Yocto Project provides a :ref:`license
|
||||||
manifest <dev-manual/dev-manual-common-tasks:maintaining open source license compliance during your product's lifecycle>`
|
manifest <dev-manual/dev-manual-common-tasks:maintaining open source license compliance during your product's lifecycle>`
|
||||||
for review by people who need to track the use of open source
|
for review by people who need to track the use of open source
|
||||||
licenses (e.g.legal teams).
|
licenses (e.g. legal teams).
|
||||||
|
|
||||||
.. _gs-challenges:
|
.. _gs-challenges:
|
||||||
|
|
||||||
@@ -540,7 +540,7 @@ targets:
|
|||||||
You can find the Matchbox source in the Yocto Project
|
You can find the Matchbox source in the Yocto Project
|
||||||
:yocto_git:`Source Repositories <>`.
|
:yocto_git:`Source Repositories <>`.
|
||||||
|
|
||||||
- *Opkg* Open PacKaGe management (opkg) is a lightweight package
|
- *Opkg:* Open PacKaGe management (opkg) is a lightweight package
|
||||||
management system based on the itsy package (ipkg) management system.
|
management system based on the itsy package (ipkg) management system.
|
||||||
Opkg is written in C and resembles Advanced Package Tool (APT) and
|
Opkg is written in C and resembles Advanced Package Tool (APT) and
|
||||||
Debian Package (dpkg) in operation.
|
Debian Package (dpkg) in operation.
|
||||||
@@ -655,7 +655,7 @@ Project.
|
|||||||
virtualization technology.
|
virtualization technology.
|
||||||
|
|
||||||
For information on how to set up a Build Host with WSLv2, see the
|
For information on how to set up a Build Host with WSLv2, see the
|
||||||
":ref:dev-manual/dev-manual-start:setting up to use windows subsystem for linux (wslv2)`"
|
":ref:`dev-manual/dev-manual-start:setting up to use windows subsystem for linux (wslv2)`"
|
||||||
section in the Yocto Project Development Tasks Manual.
|
section in the Yocto Project Development Tasks Manual.
|
||||||
|
|
||||||
- *Toaster:* Regardless of what your Build Host is running, you can use
|
- *Toaster:* Regardless of what your Build Host is running, you can use
|
||||||
@@ -743,7 +743,7 @@ and Fall. For more information on the Yocto Project release schedule and
|
|||||||
cadence, see the ":doc:`../ref-manual/ref-release-process`" chapter in the
|
cadence, see the ":doc:`../ref-manual/ref-release-process`" chapter in the
|
||||||
Yocto Project Reference Manual.
|
Yocto Project Reference Manual.
|
||||||
|
|
||||||
Much has been said about Poky being a "default configuration." A default
|
Much has been said about Poky being a "default configuration". A default
|
||||||
configuration provides a starting image footprint. You can use Poky out
|
configuration provides a starting image footprint. You can use Poky out
|
||||||
of the box to create an image ranging from a shell-accessible minimal
|
of the box to create an image ranging from a shell-accessible minimal
|
||||||
image all the way up to a Linux Standard Base-compliant image that uses
|
image all the way up to a Linux Standard Base-compliant image that uses
|
||||||
|
|||||||
@@ -11,7 +11,7 @@ Transitioning to a custom environment for systems development
|
|||||||
So you've finished the :doc:`brief-yoctoprojectqs/brief-yoctoprojectqs` and
|
So you've finished the :doc:`brief-yoctoprojectqs/brief-yoctoprojectqs` and
|
||||||
glanced over the document :doc:`what-i-wish-id-known`, the latter contains
|
glanced over the document :doc:`what-i-wish-id-known`, the latter contains
|
||||||
important information learned from other users. You're well prepared. But
|
important information learned from other users. You're well prepared. But
|
||||||
now, as you are starting your own project, isn't exactly straightforward what
|
now, as you are starting your own project, it isn't exactly straightforward what
|
||||||
to do. And, the documentation is daunting. We've put together a few hints to
|
to do. And, the documentation is daunting. We've put together a few hints to
|
||||||
get you started.
|
get you started.
|
||||||
|
|
||||||
@@ -67,7 +67,7 @@ Transitioning to a custom environment for systems development
|
|||||||
BSP, :ref:`create your own layer for the BSP <bsp-guide/bsp:creating a new
|
BSP, :ref:`create your own layer for the BSP <bsp-guide/bsp:creating a new
|
||||||
bsp layer using the \`\`bitbake-layers\`\` script>`. For example, given a
|
bsp layer using the \`\`bitbake-layers\`\` script>`. For example, given a
|
||||||
64-bit x86-based machine, copy the conf/intel-corei7-64 definition and give
|
64-bit x86-based machine, copy the conf/intel-corei7-64 definition and give
|
||||||
it a machine a relevant name (think board name, not product name). Make sure
|
the machine a relevant name (think board name, not product name). Make sure
|
||||||
the layer configuration is dependent on the meta-intel layer (or at least,
|
the layer configuration is dependent on the meta-intel layer (or at least,
|
||||||
meta-intel remains in your bblayers.conf). Now you can put your custom BSP
|
meta-intel remains in your bblayers.conf). Now you can put your custom BSP
|
||||||
settings into your layer and you can re-use it for different applications.
|
settings into your layer and you can re-use it for different applications.
|
||||||
|
|||||||
@@ -85,7 +85,7 @@ contact us with other suggestions.
|
|||||||
pinpoint where trouble is occurring and how the build is breaking. The
|
pinpoint where trouble is occurring and how the build is breaking. The
|
||||||
workflow breaks down into the following steps:
|
workflow breaks down into the following steps:
|
||||||
|
|
||||||
#. Fetch – get the sourcecode
|
#. Fetch – get the source code
|
||||||
#. Extract – unpack the sources
|
#. Extract – unpack the sources
|
||||||
#. Patch – apply patches for bug fixes and new capability
|
#. Patch – apply patches for bug fixes and new capability
|
||||||
#. Configure – set up your environment specifications
|
#. Configure – set up your environment specifications
|
||||||
@@ -105,7 +105,7 @@ contact us with other suggestions.
|
|||||||
You can use the "-g" option with BitBake to generate this graph. When you
|
You can use the "-g" option with BitBake to generate this graph. When you
|
||||||
start a build and the build breaks, you could see packages you have no clue
|
start a build and the build breaks, you could see packages you have no clue
|
||||||
about or have any idea why the build system has included them. The
|
about or have any idea why the build system has included them. The
|
||||||
dependency graph can clarify that confustion. You can learn more about
|
dependency graph can clarify that confusion. You can learn more about
|
||||||
dependency graphs and how to generate them in the
|
dependency graphs and how to generate them in the
|
||||||
:ref:`bitbake-user-manual/bitbake-user-manual-intro:generating dependency
|
:ref:`bitbake-user-manual/bitbake-user-manual-intro:generating dependency
|
||||||
graphs` section in the BitBake User Manual.
|
graphs` section in the BitBake User Manual.
|
||||||
|
|||||||
Reference in New Issue
Block a user