MIRRORS/poky
1
0
Fork 0
mirror of git://git.yoctoproject.org/poky.git synced 2025-07-19 21:09:03 +02:00
Code Issues Actions Packages Projects Releases Wiki Activity

sphinx: replace special quotes with single and double quotes

Browse Source 
(From yocto-docs rev: 0aeb7a94abcef3cb3850c753dd0a243f381e6675)

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:
Quentin Schulz 2020-09-17 01:58:59 +02:00 committed by Richard Purdie
parent 6813141743
commit c387f0c254
26 changed files with 106 additions and 106 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
documentation/adt-manual/adt-prepare.rst
View File

@ -189,7 +189,7 @@ the location for cross-toolchain installation. The default location is
``/opt/poky/``\ release. After either accepting the default location or ``/opt/poky/``\ release. After either accepting the default location or
selecting your own location, you are prompted to run the installation selecting your own location, you are prompted to run the installation
script interactively or in silent mode. If you want to closely monitor script interactively or in silent mode. If you want to closely monitor
the installation, choose “I” for interactive mode rather than “S” for the installation, choose "I" for interactive mode rather than "S" for
silent mode. Follow the prompts from the script to complete the silent mode. Follow the prompts from the script to complete the
installation. installation.
@ -594,7 +594,7 @@ For this scenario, you need to do several things:
- Install the appropriate stand-alone toolchain tarball. - Install the appropriate stand-alone toolchain tarball.
- Download the pre-built image that will boot with QEMU. You need to be - Download the pre-built image that will boot with QEMU. You need to be
sure to get the QEMU image that matches your target machine’s sure to get the QEMU image that matches your target machine's
architecture (e.g. x86, ARM, etc.). architecture (e.g. x86, ARM, etc.).
- Download the filesystem image for your target machine's architecture. - Download the filesystem image for your target machine's architecture.

4
documentation/adt-manual/adt-prepare.xml
View File

@ -232,7 +232,7 @@
own location, you are prompted to run the installation script own location, you are prompted to run the installation script
interactively or in silent mode. interactively or in silent mode.
If you want to closely monitor the installation, If you want to closely monitor the installation,
choose “I” for interactive mode rather than “S” for silent mode. choose "I" for interactive mode rather than "S" for silent mode.
Follow the prompts from the script to complete the installation. Follow the prompts from the script to complete the installation.
</para> </para>
@ -765,7 +765,7 @@
<itemizedlist> <itemizedlist>
<listitem><para>Install the appropriate stand-alone toolchain tarball.</para></listitem> <listitem><para>Install the appropriate stand-alone toolchain tarball.</para></listitem>
<listitem><para>Download the pre-built image that will boot with QEMU. <listitem><para>Download the pre-built image that will boot with QEMU.
You need to be sure to get the QEMU image that matches your target machine’s You need to be sure to get the QEMU image that matches your target machine's
architecture (e.g. x86, ARM, etc.).</para></listitem> architecture (e.g. x86, ARM, etc.).</para></listitem>
<listitem><para>Download the filesystem image for your target machine's architecture. <listitem><para>Download the filesystem image for your target machine's architecture.
</para></listitem> </para></listitem>

6
documentation/dev-manual/dev-manual-common-tasks.rst
View File

@ -6111,7 +6111,7 @@ the existing kernel, and then inserts a new kernel:
If you see the following error, you need to update or create a If you see the following error, you need to update or create a
~/.mtoolsrc ~/.mtoolsrc
file and be sure to have the line “mtools_skip_check=1“ in the file and be sure to have the line "mtools_skip_check=1" in the
file. Then, run the Wic command again: file. Then, run the Wic command again:
:: ::
@ -7157,7 +7157,7 @@ variable to specify the format:
2. Select the desired package format as follows: 2. Select the desired package format as follows:
:: ::
PACKAGE_CLASSES ?= “package_packageformat” PACKAGE_CLASSES ?= "package_packageformat"
where packageformat can be "ipk", "rpm", where packageformat can be "ipk", "rpm",
"deb", or "tar" which are the supported package formats. "deb", or "tar" which are the supported package formats.
@ -10372,7 +10372,7 @@ debugger.
an image recipe: an image recipe:
:: ::
IMAGE_INSTALL_append = “ gdbserver" IMAGE_INSTALL_append = " gdbserver"
The change makes The change makes
sure the ``gdbserver`` package is included. sure the ``gdbserver`` package is included.

6
documentation/dev-manual/dev-manual-common-tasks.xml
View File

@ -8384,7 +8384,7 @@
If you see the following error, you need to If you see the following error, you need to
update or create a update or create a
<filename>~/.mtoolsrc</filename> file and <filename>~/.mtoolsrc</filename> file and
be sure to have the line “mtools_skip_check=1“ be sure to have the line "mtools_skip_check=1"
in the file. in the file.
Then, run the Wic command again: Then, run the Wic command again:
<literallayout class='monospaced'> <literallayout class='monospaced'>
@ -9837,7 +9837,7 @@
<listitem><para> <listitem><para>
Select the desired package format as follows: Select the desired package format as follows:
<literallayout class='monospaced'> <literallayout class='monospaced'>
PACKAGE_CLASSES ?= “package_<replaceable>packageformat</replaceable>” PACKAGE_CLASSES ?= "package_<replaceable>packageformat</replaceable>"
</literallayout> </literallayout>
where <replaceable>packageformat</replaceable> where <replaceable>packageformat</replaceable>
can be "ipk", "rpm", "deb", or "tar" which are the can be "ipk", "rpm", "deb", or "tar" which are the
@ -14193,7 +14193,7 @@
<filename>local.conf</filename> file or in an image <filename>local.conf</filename> file or in an image
recipe: recipe:
<literallayout class='monospaced'> <literallayout class='monospaced'>
IMAGE_INSTALL_append = “ gdbserver" IMAGE_INSTALL_append = " gdbserver"
</literallayout> </literallayout>
The change makes sure the <filename>gdbserver</filename> The change makes sure the <filename>gdbserver</filename>
package is included. package is included.

8
documentation/dev-manual/dev-manual-qemu.rst
View File

@ -74,7 +74,7 @@ available. Follow these general steps to run QEMU:
3. *Ensure the Artifacts are in Place:* You need to be sure you have a 3. *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 pre-built kernel that will boot in QEMU. You also need the target
root filesystem for your target machine’s architecture: root filesystem for your target machine's architecture:
- If you have previously built an image for QEMU (e.g. ``qemux86``, - If you have previously built an image for QEMU (e.g. ``qemux86``,
``qemuarm``, and so forth), then the artifacts are in place in ``qemuarm``, and so forth), then the artifacts are in place in
@ -396,7 +396,7 @@ command line:
- ROOTFS: A root filesystem that has one of the following filetype - ROOTFS: A root filesystem that has one of the following filetype
extensions: "ext2", "ext3", "ext4", "jffs2", "nfs", or "btrfs". If extensions: "ext2", "ext3", "ext4", "jffs2", "nfs", or "btrfs". If
the filename you provide for this option uses “nfs”, it must provide the filename you provide for this option uses "nfs", it must provide
an explicit root filesystem path. an explicit root filesystem path.
- KERNEL: A kernel image, which is a ``.bin`` file. When you provide a - KERNEL: A kernel image, which is a ``.bin`` file. When you provide a
@ -405,7 +405,7 @@ command line:
- MACHINE: The architecture of the QEMU machine, which must be one of - MACHINE: The architecture of the QEMU machine, which must be one of
the following: "qemux86", "qemux86-64", "qemuarm", "qemuarm64", the following: "qemux86", "qemux86-64", "qemuarm", "qemuarm64",
"qemumips", “qemumips64", or "qemuppc". The MACHINE and QEMUARCH "qemumips", "qemumips64", or "qemuppc". The MACHINE and QEMUARCH
options are basically identical. If you do not provide a MACHINE options are basically identical. If you do not provide a MACHINE
option, ``runqemu`` tries to determine it based on other options. option, ``runqemu`` tries to determine it based on other options.
@ -465,6 +465,6 @@ command line:
``/dev/vhost-net``. ``/dev/vhost-net``.
- The build host ``/dev/vhost-net`` directory has to be either - The build host ``/dev/vhost-net`` directory has to be either
readable or writable and “slirp-enabled”. readable or writable and "slirp-enabled".
- ``publicvnc``: Enables a VNC server open to all hosts. - ``publicvnc``: Enables a VNC server open to all hosts.

8
documentation/dev-manual/dev-manual-qemu.xml
View File

@ -106,7 +106,7 @@
You need to be sure you have a pre-built kernel that You need to be sure you have a pre-built kernel that
will boot in QEMU. will boot in QEMU.
You also need the target root filesystem for your target You also need the target root filesystem for your target
machine’s architecture: machine's architecture:
<itemizedlist> <itemizedlist>
<listitem><para> <listitem><para>
If you have previously built an image for QEMU If you have previously built an image for QEMU
@ -553,7 +553,7 @@
A root filesystem that has one of the following A root filesystem that has one of the following
filetype extensions: "ext2", "ext3", "ext4", "jffs2", filetype extensions: "ext2", "ext3", "ext4", "jffs2",
"nfs", or "btrfs". "nfs", or "btrfs".
If the filename you provide for this option uses “nfs”, it If the filename you provide for this option uses "nfs", it
must provide an explicit root filesystem path. must provide an explicit root filesystem path.
</para></listitem> </para></listitem>
<listitem><para> <listitem><para>
@ -567,7 +567,7 @@
<replaceable>MACHINE</replaceable>: <replaceable>MACHINE</replaceable>:
The architecture of the QEMU machine, which must be one The architecture of the QEMU machine, which must be one
of the following: "qemux86", "qemux86-64", "qemuarm", of the following: "qemux86", "qemux86-64", "qemuarm",
"qemuarm64", "qemumips", “qemumips64", or "qemuppc". "qemuarm64", "qemumips", "qemumips64", or "qemuppc".
The <replaceable>MACHINE</replaceable> and The <replaceable>MACHINE</replaceable> and
<replaceable>QEMUARCH</replaceable> options are basically <replaceable>QEMUARCH</replaceable> options are basically
identical. identical.
@ -674,7 +674,7 @@ qemux86" or "qemux86-64".
<listitem><para> <listitem><para>
The build host <filename>/dev/vhost-net</filename> The build host <filename>/dev/vhost-net</filename>
directory has to be either readable or writable directory has to be either readable or writable
and “slirp-enabled”. and "slirp-enabled".
</para></listitem> </para></listitem>
</itemizedlist> </itemizedlist>
</para></listitem> </para></listitem>

2
documentation/kernel-dev/kernel-dev-concepts-appx.rst
View File

@ -129,7 +129,7 @@ cutting edge Yocto Linux kernel that mixes forward ports of existing
Linux kernel features and significant and critical new functionality. Linux kernel features and significant and critical new functionality.
Forward porting Linux kernel functionality into the Yocto Linux kernels Forward porting Linux kernel functionality into the Yocto Linux kernels
available through the Yocto Project can be thought of as a "micro available through the Yocto Project can be thought of as a "micro
uprev." The many “micro uprevs” produce a Yocto Linux kernel version uprev." The many "micro uprevs" produce a Yocto Linux kernel version
with a mix of important new mainline, non-mainline, BSP developments and with a mix of important new mainline, non-mainline, BSP developments and
feature integrations. This Yocto Linux kernel gives insight into new feature integrations. This Yocto Linux kernel gives insight into new
features and allows focused amounts of testing to be done on the kernel, features and allows focused amounts of testing to be done on the kernel,

2
documentation/kernel-dev/kernel-dev-concepts-appx.xml
View File

@ -192,7 +192,7 @@
Forward porting Linux kernel functionality into the Yocto Linux Forward porting Linux kernel functionality into the Yocto Linux
kernels available through the Yocto Project can be thought of as kernels available through the Yocto Project can be thought of as
a "micro uprev." a "micro uprev."
The many “micro uprevs” produce a Yocto Linux kernel version with The many "micro uprevs" produce a Yocto Linux kernel version with
a mix of important new mainline, non-mainline, BSP developments a mix of important new mainline, non-mainline, BSP developments
and feature integrations. and feature integrations.
This Yocto Linux kernel gives insight into new features and This Yocto Linux kernel gives insight into new features and

12
documentation/overview-manual/overview-manual-development-environment.rst
View File

@ -238,7 +238,7 @@ open source projects do so.
For the Yocto Project, a key individual called the "maintainer" is For the Yocto Project, a key individual called the "maintainer" is
responsible for the integrity of the "master" branch of a given Git responsible for the integrity of the "master" branch of a given Git
repository. The "master" branch is the “upstream” repository from which repository. The "master" branch is the "upstream" repository from which
final or most recent builds of a project occur. The maintainer is final or most recent builds of a project occur. The maintainer is
responsible for accepting changes from other developers and for responsible for accepting changes from other developers and for
organizing the underlying branch structure to reflect release strategies organizing the underlying branch structure to reflect release strategies
@ -273,19 +273,19 @@ with whatever upstream branch they are working against. They are also
responsible for straightening out any conflicts that might arise within responsible for straightening out any conflicts that might arise within
files that are being worked on simultaneously by more than one person. files that are being worked on simultaneously by more than one person.
All this work is done locally on the development host before anything is All this work is done locally on the development host before anything is
pushed to a "contrib" area and examined at the maintainer’s level. pushed to a "contrib" area and examined at the maintainer's level.
A somewhat formal method exists by which developers commit changes and A somewhat formal method exists by which developers commit changes and
push them into the "contrib" area and subsequently request that the push them into the "contrib" area and subsequently request that the
maintainer include them into an upstream branch. This process is called maintainer include them into an upstream branch. This process is called
“submitting a patch” or "submitting a change." For information on "submitting a patch" or "submitting a change." For information on
submitting patches and changes, see the submitting patches and changes, see the
":ref:`dev-manual/dev-manual-common-tasks:submitting a change to the yocto project`" ":ref:`dev-manual/dev-manual-common-tasks:submitting a change to the yocto project`"
section in the Yocto Project Development Tasks Manual. section in the Yocto Project Development Tasks Manual.
In summary, a single point of entry exists for changes into a "master" In summary, a single point of entry exists for changes into a "master"
or development branch of the Git repository, which is controlled by the or development branch of the Git repository, which is controlled by the
project’s maintainer. And, a set of developers exist who independently project's maintainer. And, a set of developers exist who independently
develop, test, and submit changes to "contrib" areas for the maintainer develop, test, and submit changes to "contrib" areas for the maintainer
to examine. The maintainer then chooses which changes are going to to examine. The maintainer then chooses which changes are going to
become a permanent part of the project. become a permanent part of the project.
@ -526,7 +526,7 @@ descriptions and strategies on how to use these commands:
Git commands unless you have a ``.git`` repository. Git commands unless you have a ``.git`` repository.
- *git clone:* Creates a local clone of a Git repository that is on - *git clone:* Creates a local clone of a Git repository that is on
equal footing with a fellow developer’s Git repository or an upstream equal footing with a fellow developer's Git repository or an upstream
repository. repository.
- *git add:* Locally stages updated file contents to the index that - *git add:* Locally stages updated file contents to the index that
@ -537,7 +537,7 @@ descriptions and strategies on how to use these commands:
you made. Only changes that have been staged can be committed. you made. Only changes that have been staged can be committed.
Commits are used for historical purposes, for determining if a Commits are used for historical purposes, for determining if a
maintainer of a project will allow the change, and for ultimately maintainer of a project will allow the change, and for ultimately
pushing the change from your local Git repository into the project’s pushing the change from your local Git repository into the project's
upstream repository. upstream repository.
- *git status:* Reports any modified files that possibly need to be - *git status:* Reports any modified files that possibly need to be

12
documentation/overview-manual/overview-manual-development-environment.xml
View File

@ -327,7 +327,7 @@
For the Yocto Project, a key individual called the "maintainer" is For the Yocto Project, a key individual called the "maintainer" is
responsible for the integrity of the "master" branch of a given Git responsible for the integrity of the "master" branch of a given Git
repository. repository.
The "master" branch is the “upstream” repository from which final or The "master" branch is the "upstream" repository from which final or
most recent builds of a project occur. most recent builds of a project occur.
The maintainer is responsible for accepting changes from other The maintainer is responsible for accepting changes from other
developers and for organizing the underlying branch structure to developers and for organizing the underlying branch structure to
@ -372,7 +372,7 @@
might arise within files that are being worked on simultaneously by might arise within files that are being worked on simultaneously by
more than one person. more than one person.
All this work is done locally on the development host before All this work is done locally on the development host before
anything is pushed to a "contrib" area and examined at the maintainer’s anything is pushed to a "contrib" area and examined at the maintainer's
level. level.
</para> </para>
@ -380,7 +380,7 @@
A somewhat formal method exists by which developers commit changes A somewhat formal method exists by which developers commit changes
and push them into the "contrib" area and subsequently request that and push them into the "contrib" area and subsequently request that
the maintainer include them into an upstream branch. the maintainer include them into an upstream branch.
This process is called “submitting a patch” or "submitting a change." This process is called "submitting a patch" or "submitting a change."
For information on submitting patches and changes, see the For information on submitting patches and changes, see the
"<ulink url='&YOCTO_DOCS_DEV_URL;#how-to-submit-a-change'>Submitting a Change to the Yocto Project</ulink>" "<ulink url='&YOCTO_DOCS_DEV_URL;#how-to-submit-a-change'>Submitting a Change to the Yocto Project</ulink>"
section in the Yocto Project Development Tasks Manual. section in the Yocto Project Development Tasks Manual.
@ -389,7 +389,7 @@
<para> <para>
In summary, a single point of entry In summary, a single point of entry
exists for changes into a "master" or development branch of the exists for changes into a "master" or development branch of the
Git repository, which is controlled by the project’s maintainer. Git repository, which is controlled by the project's maintainer.
And, a set of developers exist who independently develop, test, and And, a set of developers exist who independently develop, test, and
submit changes to "contrib" areas for the maintainer to examine. submit changes to "contrib" areas for the maintainer to examine.
The maintainer then chooses which changes are going to become a The maintainer then chooses which changes are going to become a
@ -734,7 +734,7 @@
<listitem><para id='git-commands-clone'> <listitem><para id='git-commands-clone'>
<emphasis><filename>git clone</filename>:</emphasis> <emphasis><filename>git clone</filename>:</emphasis>
Creates a local clone of a Git repository that is on Creates a local clone of a Git repository that is on
equal footing with a fellow developer’s Git repository equal footing with a fellow developer's Git repository
or an upstream repository. or an upstream repository.
</para></listitem> </para></listitem>
<listitem><para> <listitem><para>
@ -752,7 +752,7 @@
Commits are used for historical purposes, for determining Commits are used for historical purposes, for determining
if a maintainer of a project will allow the change, if a maintainer of a project will allow the change,
and for ultimately pushing the change from your local and for ultimately pushing the change from your local
Git repository into the project’s upstream repository. Git repository into the project's upstream repository.
</para></listitem> </para></listitem>
<listitem><para> <listitem><para>
<emphasis><filename>git status</filename>:</emphasis> <emphasis><filename>git status</filename>:</emphasis>

12
documentation/overview-manual/overview-manual-yp-intro.rst
View File

@ -319,14 +319,14 @@ applications using the Yocto Project:
The ``devtool`` command employs a number of sub-commands that allow The ``devtool`` command employs a number of sub-commands that allow
you to add, modify, and upgrade recipes. As with the OpenEmbedded you to add, modify, and upgrade recipes. As with the OpenEmbedded
build system, “recipes” represent software packages within build system, "recipes" represent software packages within
``devtool``. When you use ``devtool add``, a recipe is automatically ``devtool``. When you use ``devtool add``, a recipe is automatically
created. When you use ``devtool modify``, the specified existing created. When you use ``devtool modify``, the specified existing
recipe is used in order to determine where to get the source code and recipe is used in order to determine where to get the source code and
how to patch it. In both cases, an environment is set up so that when how to patch it. In both cases, an environment is set up so that when
you build the recipe a source tree that is under your control is used you build the recipe a source tree that is under your control is used
in order to allow you to make changes to the source as desired. By in order to allow you to make changes to the source as desired. By
default, both new recipes and the source go into a “workspace” default, both new recipes and the source go into a "workspace"
directory under the eSDK. The ``devtool upgrade`` command updates an directory under the eSDK. The ``devtool upgrade`` command updates an
existing recipe so that you can build it for an updated set of source existing recipe so that you can build it for an updated set of source
files. files.
@ -417,7 +417,7 @@ activities using the Yocto Project:
years ago. Both prelink and cross-prelink are maintained in the same years ago. Both prelink and cross-prelink are maintained in the same
repository albeit on separate branches. By providing an emulated repository albeit on separate branches. By providing an emulated
runtime dynamic linker (i.e. ``glibc``-derived ``ld.so`` emulation), runtime dynamic linker (i.e. ``glibc``-derived ``ld.so`` emulation),
the cross-prelink project extends the prelink software’s ability to the cross-prelink project extends the prelink software's ability to
prelink a sysroot environment. Additionally, the cross-prelink prelink a sysroot environment. Additionally, the cross-prelink
software enables the ability to work in sysroot style environments. software enables the ability to work in sysroot style environments.
@ -432,7 +432,7 @@ activities using the Yocto Project:
library code can be re-used from shared Copy-On-Write (COW) pages. library code can be re-used from shared Copy-On-Write (COW) pages.
The original upstream prelink project only supports running prelink The original upstream prelink project only supports running prelink
on the end target device due to the reliance on the target device’s on the end target device due to the reliance on the target device's
dynamic linker. This restriction causes issues when developing a dynamic linker. This restriction causes issues when developing a
cross-compiled system. The cross-prelink adds a synthesized dynamic cross-compiled system. The cross-prelink adds a synthesized dynamic
loader that runs on the host, thus permitting cross-prelinking loader that runs on the host, thus permitting cross-prelinking
@ -495,7 +495,7 @@ The following list consists of components associated with the
Sharing a core set of metadata results in Poky as an integration Sharing a core set of metadata results in Poky as an integration
layer on top of OE-Core. You can see that in this layer on top of OE-Core. You can see that in this
`figure <#yp-key-dev-elements>`__. The Yocto Project combines various `figure <#yp-key-dev-elements>`__. The Yocto Project combines various
components such as BitBake, OE-Core, script “glue”, and documentation components such as BitBake, OE-Core, script "glue", and documentation
for its build system. for its build system.
.. _gs-reference-distribution-poky: .. _gs-reference-distribution-poky:
@ -556,7 +556,7 @@ targets:
.. note:: .. note::
As best it can, opkg maintains backwards compatibility with ipkg As best it can, opkg maintains backwards compatibility with ipkg
and conforms to a subset of Debian’s policy manual regarding and conforms to a subset of Debian's policy manual regarding
control files. control files.
.. _gs-archived-components: .. _gs-archived-components:

12
documentation/overview-manual/overview-manual-yp-intro.xml
View File

@ -459,7 +459,7 @@
<para>The <filename>devtool</filename> command employs <para>The <filename>devtool</filename> command employs
a number of sub-commands that allow you to add, modify, a number of sub-commands that allow you to add, modify,
and upgrade recipes. and upgrade recipes.
As with the OpenEmbedded build system, “recipes” As with the OpenEmbedded build system, "recipes"
represent software packages within represent software packages within
<filename>devtool</filename>. <filename>devtool</filename>.
When you use <filename>devtool add</filename>, a recipe When you use <filename>devtool add</filename>, a recipe
@ -472,7 +472,7 @@
control is used in order to allow you to make changes control is used in order to allow you to make changes
to the source as desired. to the source as desired.
By default, both new recipes and the source go into By default, both new recipes and the source go into
a “workspace” directory under the eSDK. a "workspace" directory under the eSDK.
The <filename>devtool upgrade</filename> command The <filename>devtool upgrade</filename> command
updates an existing recipe so that you can build it updates an existing recipe so that you can build it
for an updated set of source files.</para> for an updated set of source files.</para>
@ -598,7 +598,7 @@
By providing an emulated runtime dynamic linker By providing an emulated runtime dynamic linker
(i.e. <filename>glibc</filename>-derived (i.e. <filename>glibc</filename>-derived
<filename>ld.so</filename> emulation), the <filename>ld.so</filename> emulation), the
cross-prelink project extends the prelink software’s cross-prelink project extends the prelink software's
ability to prelink a sysroot environment. ability to prelink a sysroot environment.
Additionally, the cross-prelink software enables the Additionally, the cross-prelink software enables the
ability to work in sysroot style environments.</para> ability to work in sysroot style environments.</para>
@ -620,7 +620,7 @@
<para>The original upstream prelink project only <para>The original upstream prelink project only
supports running prelink on the end target device supports running prelink on the end target device
due to the reliance on the target device’s dynamic due to the reliance on the target device's dynamic
linker. linker.
This restriction causes issues when developing a This restriction causes issues when developing a
cross-compiled system. cross-compiled system.
@ -713,7 +713,7 @@
You can see that in this You can see that in this
<link linkend='yp-key-dev-elements'>figure</link>. <link linkend='yp-key-dev-elements'>figure</link>.
The Yocto Project combines various components such as The Yocto Project combines various components such as
BitBake, OE-Core, script “glue”, and documentation BitBake, OE-Core, script "glue", and documentation
for its build system. for its build system.
</para></listitem> </para></listitem>
</itemizedlist> </itemizedlist>
@ -791,7 +791,7 @@
<note> <note>
As best it can, opkg maintains backwards As best it can, opkg maintains backwards
compatibility with ipkg and conforms to a subset compatibility with ipkg and conforms to a subset
of Debian’s policy manual regarding control files. of Debian's policy manual regarding control files.
</note> </note>
</para></listitem> </para></listitem>
</itemizedlist> </itemizedlist>

2
documentation/ref-manual/faq.rst
View File

@ -143,7 +143,7 @@ various proxy types and configuring proxy servers, see the
":yocto_wiki:`Working Behind a Network Proxy </wiki/Working_Behind_a_Network_Proxy>`" ":yocto_wiki:`Working Behind a Network Proxy </wiki/Working_Behind_a_Network_Proxy>`"
Wiki page. Wiki page.
**Q:** What’s the difference between target and target\ ``-native``? **Q:** What's the difference between target and target\ ``-native``?
**A:** The ``*-native`` targets are designed to run on the system being **A:** The ``*-native`` targets are designed to run on the system being
used for the build. These are usually tools that are needed to assist used for the build. These are usually tools that are needed to assist

2
documentation/ref-manual/faq.xml
View File

@ -323,7 +323,7 @@
<qandaentry> <qandaentry>
<question> <question>
<para> <para>
What’s the difference between <replaceable>target</replaceable> and <replaceable>target</replaceable><filename>-native</filename>? What's the difference between <replaceable>target</replaceable> and <replaceable>target</replaceable><filename>-native</filename>?
</para> </para>
</question> </question>
<answer> <answer>

4
documentation/ref-manual/ref-images.rst
View File

@ -6,7 +6,7 @@ Images
The OpenEmbedded build system provides several example images to satisfy The OpenEmbedded build system provides several example images to satisfy
different needs. When you issue the ``bitbake`` command you provide a different needs. When you issue the ``bitbake`` command you provide a
“top-level” recipe that essentially begins the build for the type of "top-level" recipe that essentially begins the build for the type of
image you want. image you want.
.. note:: .. note::
@ -85,7 +85,7 @@ Following is a list of supported recipes:
- ``core-image-minimal-initramfs``: A ``core-image-minimal`` image that - ``core-image-minimal-initramfs``: A ``core-image-minimal`` image that
has the Minimal RAM-based Initial Root Filesystem (initramfs) as part has the Minimal RAM-based Initial Root Filesystem (initramfs) as part
of the kernel, which allows the system to find the first “init” of the kernel, which allows the system to find the first "init"
program more efficiently. See the program more efficiently. See the
:term:`PACKAGE_INSTALL` variable for :term:`PACKAGE_INSTALL` variable for
additional information helpful when working with initramfs images. additional information helpful when working with initramfs images.

4
documentation/ref-manual/ref-images.xml
View File

@ -9,7 +9,7 @@
<para> <para>
The OpenEmbedded build system provides several example The OpenEmbedded build system provides several example
images to satisfy different needs. images to satisfy different needs.
When you issue the <filename>bitbake</filename> command you provide a “top-level” recipe When you issue the <filename>bitbake</filename> command you provide a "top-level" recipe
that essentially begins the build for the type of image you want. that essentially begins the build for the type of image you want.
</para> </para>
@ -100,7 +100,7 @@
<listitem><para id='images-core-image-minimal-initramfs'><filename>core-image-minimal-initramfs</filename>: <listitem><para id='images-core-image-minimal-initramfs'><filename>core-image-minimal-initramfs</filename>:
A <filename>core-image-minimal</filename> image that has the Minimal RAM-based A <filename>core-image-minimal</filename> image that has the Minimal RAM-based
Initial Root Filesystem (initramfs) as part of the kernel, Initial Root Filesystem (initramfs) as part of the kernel,
which allows the system to find the first “init” program more efficiently. which allows the system to find the first "init" program more efficiently.
See the See the
<link linkend='var-PACKAGE_INSTALL'><filename>PACKAGE_INSTALL</filename></link> <link linkend='var-PACKAGE_INSTALL'><filename>PACKAGE_INSTALL</filename></link>
variable for additional information helpful when working with variable for additional information helpful when working with

2
documentation/ref-manual/ref-terms.rst
View File

@ -273,7 +273,7 @@ universal, the list includes them just in case:
Arbitrary groups of software Recipes. You use Arbitrary groups of software Recipes. You use
package groups to hold recipes that, when built, usually accomplish a package groups to hold recipes that, when built, usually accomplish a
single task. For example, a package group could contain the recipes single task. For example, a package group could contain the recipes
for a company’s proprietary or value-add software. Or, the package for a company's proprietary or value-add software. Or, the package
group could contain the recipes that enable graphics. A package group group could contain the recipes that enable graphics. A package group
is really just another recipe. Because package group files are is really just another recipe. Because package group files are
recipes, they end with the ``.bb`` filename extension. recipes, they end with the ``.bb`` filename extension.

2
documentation/ref-manual/ref-terms.xml
View File

@ -365,7 +365,7 @@
You use package groups to hold recipes that, when built, You use package groups to hold recipes that, when built,
usually accomplish a single task. usually accomplish a single task.
For example, a package group could contain the recipes for a For example, a package group could contain the recipes for a
company’s proprietary or value-add software. company's proprietary or value-add software.
Or, the package group could contain the recipes that enable Or, the package group could contain the recipes that enable
graphics. graphics.
A package group is really just another recipe. A package group is really just another recipe.

6
documentation/test-manual/test-manual-intro.rst
View File

@ -12,9 +12,9 @@ Welcome
Welcome to the Yocto Project Test Environment Manual! This manual is a Welcome to the Yocto Project Test Environment Manual! This manual is a
work in progress. The manual contains information about the testing work in progress. The manual contains information about the testing
environment used by the Yocto Project to make sure each major and minor environment used by the Yocto Project to make sure each major and minor
release works as intended. All the project’s testing infrastructure and release works as intended. All the project's testing infrastructure and
processes are publicly visible and available so that the community can processes are publicly visible and available so that the community can
see what testing is being performed, how it’s being done and the current see what testing is being performed, how it's being done and the current
status of the tests and the project at any given time. It is intended status of the tests and the project at any given time. It is intended
that Other organizations can leverage off the process and testing that Other organizations can leverage off the process and testing
environment used by the Yocto Project to create their own automated, environment used by the Yocto Project to create their own automated,
@ -514,7 +514,7 @@ resource utilisation as that happens. An example from
'bitbake -p (cached)') 'bitbake -p (cached)')
This example shows how three specific parsing timings are This example shows how three specific parsing timings are
measured, with and without various caches, to show how BitBake’s parsing measured, with and without various caches, to show how BitBake's parsing
performance trends over time. performance trends over time.
.. _test-writing-considerations: .. _test-writing-considerations:

6
documentation/test-manual/test-manual-intro.xml
View File

@ -12,8 +12,8 @@
<para> Welcome to the Yocto Project Test Environment Manual! This manual is a work in <para> Welcome to the Yocto Project Test Environment Manual! This manual is a work in
progress. The manual contains information about the testing environment used by the progress. The manual contains information about the testing environment used by the
Yocto Project to make sure each major and minor release works as intended. All the Yocto Project to make sure each major and minor release works as intended. All the
project’s testing infrastructure and processes are publicly visible and available so project's testing infrastructure and processes are publicly visible and available so
that the community can see what testing is being performed, how it’s being done and the that the community can see what testing is being performed, how it's being done and the
current status of the tests and the project at any given time. It is intended that Other current status of the tests and the project at any given time. It is intended that Other
organizations can leverage off the process and testing environment used by the Yocto organizations can leverage off the process and testing environment used by the Yocto
Project to create their own automated, production test environment, building upon the Project to create their own automated, production test environment, building upon the
@ -579,7 +579,7 @@
'bitbake -p (cached)') 'bitbake -p (cached)')
</literallayout>This </literallayout>This
example shows how three specific parsing timings are measured, with and without example shows how three specific parsing timings are measured, with and without
various caches, to show how BitBake’s parsing performance trends over time.</para> various caches, to show how BitBake's parsing performance trends over time.</para>
</section> </section>
</section> </section>
<section id='test-writing-considerations'> <section id='test-writing-considerations'>

20
documentation/test-manual/test-manual-understand-autobuilder.rst
View File

@ -7,19 +7,19 @@ Understanding the Yocto Project Autobuilder
Execution Flow within the Autobuilder Execution Flow within the Autobuilder
===================================== =====================================
The “a-full” and “a-quick” targets are the usual entry points into the The "a-full" and "a-quick" targets are the usual entry points into the
Autobuilder and it makes sense to follow the process through the system Autobuilder and it makes sense to follow the process through the system
starting there. This is best visualised from the Autobuilder Console starting there. This is best visualised from the Autobuilder Console
view (:yocto_ab:`/typhoon/#/console`). view (:yocto_ab:`/typhoon/#/console`).
Each item along the top of that view represents some “target build” and Each item along the top of that view represents some "target build" and
these targets are all run in parallel. The ‘full’ build will trigger the these targets are all run in parallel. The 'full' build will trigger the
majority of them, the “quick” build will trigger some subset of them. majority of them, the "quick" build will trigger some subset of them.
The Autobuilder effectively runs whichever configuration is defined for The Autobuilder effectively runs whichever configuration is defined for
each of those targets on a seperate buildbot worker. To understand the each of those targets on a seperate buildbot worker. To understand the
configuration, you need to look at the entry on ``config.json`` file configuration, you need to look at the entry on ``config.json`` file
within the ``yocto-autobuilder-helper`` repository. The targets are within the ``yocto-autobuilder-helper`` repository. The targets are
defined in the ‘overrides’ section, a quick example could be qemux86-64 defined in the ‘overrides' section, a quick example could be qemux86-64
which looks like:: which looks like::
"qemux86-64" : { "qemux86-64" : {
@ -32,8 +32,8 @@ which looks like::
} }
}, },
And to expand that, you need the “arch-qemu” entry from And to expand that, you need the "arch-qemu" entry from
the “templates” section, which looks like:: the "templates" section, which looks like::
"arch-qemu" : { "arch-qemu" : {
"BUILDINFO" : true, "BUILDINFO" : true,
@ -54,9 +54,9 @@ the “templates” section, which looks like::
} }
}, },
Combining these two entries you can see that “qemux86-64” is a three step build where the Combining these two entries you can see that "qemux86-64" is a three step build where the
``bitbake BBTARGETS`` would be run, then ``bitbake SANITYTARGETS`` for each step; all for ``bitbake BBTARGETS`` would be run, then ``bitbake SANITYTARGETS`` for each step; all for
``MACHINE=”qemx86-64”`` but with differing SDKMACHINE settings. In step ``MACHINE="qemx86-64"`` but with differing SDKMACHINE settings. In step
1 an extra variable is added to the ``auto.conf`` file to enable wic 1 an extra variable is added to the ``auto.conf`` file to enable wic
image generation. image generation.
@ -262,7 +262,7 @@ of post-build steps, including:
#. Cleanup the build directory using #. Cleanup the build directory using
:ref:`test-manual/test-manual-understand-autobuilder:clobberdir` if the build was successful, :ref:`test-manual/test-manual-understand-autobuilder:clobberdir` if the build was successful,
else rename it to “build-renamed” for potential future debugging. else rename it to "build-renamed" for potential future debugging.
.. _test-deploying-yp-autobuilder: .. _test-deploying-yp-autobuilder:

16
documentation/test-manual/test-manual-understand-autobuilder.xml
View File

@ -8,18 +8,18 @@
<title>Understanding the Yocto Project Autobuilder</title> <title>Understanding the Yocto Project Autobuilder</title>
<section> <section>
<title>Execution Flow within the Autobuilder</title> <title>Execution Flow within the Autobuilder</title>
<para>The “a-full” and “a-quick” targets are the usual entry points into the Autobuilder and <para>The "a-full" and "a-quick" targets are the usual entry points into the Autobuilder and
it makes sense to follow the process through the system starting there. This is best it makes sense to follow the process through the system starting there. This is best
visualised from the Autobuilder Console view (<link linkend="" visualised from the Autobuilder Console view (<link linkend=""
>https://autobuilder.yoctoproject.org/typhoon/#/console</link>). </para> >https://autobuilder.yoctoproject.org/typhoon/#/console</link>). </para>
<para>Each item along the top of that view represents some “target build” and these targets <para>Each item along the top of that view represents some "target build" and these targets
are all run in parallel. The ‘full’ build will trigger the majority of them, the “quick” are all run in parallel. The 'full' build will trigger the majority of them, the "quick"
build will trigger some subset of them. The Autobuilder effectively runs whichever build will trigger some subset of them. The Autobuilder effectively runs whichever
configuration is defined for each of those targets on a seperate buildbot worker. To configuration is defined for each of those targets on a seperate buildbot worker. To
understand the configuration, you need to look at the entry on understand the configuration, you need to look at the entry on
<filename>config.json</filename> file within the <filename>config.json</filename> file within the
<filename>yocto-autobuilder-helper</filename> repository. The targets are defined in <filename>yocto-autobuilder-helper</filename> repository. The targets are defined in
the ‘overrides’ section, a quick example could be qemux86-64 which looks the ‘overrides' section, a quick example could be qemux86-64 which looks
like:<literallayout class="monospaced"> like:<literallayout class="monospaced">
"qemux86-64" : { "qemux86-64" : {
"MACHINE" : "qemux86-64", "MACHINE" : "qemux86-64",
@ -31,7 +31,7 @@
} }
}, },
</literallayout>And </literallayout>And
to expand that, you need the “arch-qemu” entry from the “templates” section, which looks to expand that, you need the "arch-qemu" entry from the "templates" section, which looks
like:<literallayout class="monospaced"> like:<literallayout class="monospaced">
"arch-qemu" : { "arch-qemu" : {
"BUILDINFO" : true, "BUILDINFO" : true,
@ -52,10 +52,10 @@
} }
}, },
</literallayout>Combining </literallayout>Combining
these two entries you can see that “qemux86-64” is a three step build where the these two entries you can see that "qemux86-64" is a three step build where the
<filename>bitbake BBTARGETS</filename> would be run, then <filename>bitbake <filename>bitbake BBTARGETS</filename> would be run, then <filename>bitbake
SANITYTARGETS</filename> for each step; all for SANITYTARGETS</filename> for each step; all for
<filename>MACHINE=”qemx86-64”</filename> but with differing SDKMACHINE settings. In <filename>MACHINE="qemx86-64"</filename> but with differing SDKMACHINE settings. In
step 1 an extra variable is added to the <filename>auto.conf</filename> file to enable step 1 an extra variable is added to the <filename>auto.conf</filename> file to enable
wic image generation.</para> wic image generation.</para>
<para>While not every detail of this is covered here, you can see how the templating <para>While not every detail of this is covered here, you can see how the templating
@ -260,7 +260,7 @@
<listitem> <listitem>
<para dir="ltr">Cleanup the build directory using <link <para dir="ltr">Cleanup the build directory using <link
linkend="test-clobberdir"><filename>clobberdir</filename></link> if the linkend="test-clobberdir"><filename>clobberdir</filename></link> if the
build was successful, else rename it to “build-renamed” for potential future build was successful, else rename it to "build-renamed" for potential future
debugging.</para> debugging.</para>
</listitem> </listitem>
</orderedlist></para> </orderedlist></para>

12
documentation/toaster-manual/toaster-manual-setup-and-use.rst
View File

@ -52,15 +52,15 @@ Setting Up Toaster Without a Web Server
You can start a Toaster environment without starting its web server. You can start a Toaster environment without starting its web server.
This is useful for the following: This is useful for the following:
- Capturing a command-line build’s statistics into the Toaster database - Capturing a command-line build's statistics into the Toaster database
for examination later. for examination later.
- Capturing a command-line build’s statistics when the Toaster server - Capturing a command-line build's statistics when the Toaster server
is already running. is already running.
- Having one instance of the Toaster web server track and capture - Having one instance of the Toaster web server track and capture
multiple command-line builds, where each build is started in its own multiple command-line builds, where each build is started in its own
“noweb” Toaster environment. "noweb" Toaster environment.
The following commands show how to start a Toaster environment without The following commands show how to start a Toaster environment without
starting its web server, perform BitBake operations, and then shut down starting its web server, perform BitBake operations, and then shut down
@ -68,7 +68,7 @@ the Toaster environment. Once the build is complete, you can close the
Toaster environment. Before closing the environment, however, you should Toaster environment. Before closing the environment, however, you should
allow a few minutes to ensure the complete transfer of its BitBake build allow a few minutes to ensure the complete transfer of its BitBake build
statistics to the Toaster database. If you have a separate Toaster web statistics to the Toaster database. If you have a separate Toaster web
server instance running, you can watch this command-line build’s server instance running, you can watch this command-line build's
progress and examine the results as soon as they are posted:: progress and examine the results as soon as they are posted::
$ source toaster start noweb $ source toaster start noweb
@ -78,7 +78,7 @@ progress and examine the results as soon as they are posted::
Setting Up Toaster Without a Build Server Setting Up Toaster Without a Build Server
========================================= =========================================
You can start a Toaster environment with the “New Projects” feature You can start a Toaster environment with the "New Projects" feature
disabled. Doing so is useful for the following: disabled. Doing so is useful for the following:
- Sharing your build results over the web server while blocking others - Sharing your build results over the web server while blocking others
@ -345,7 +345,7 @@ Perform the following steps to install Toaster:
directory to be served up by the Apache web server as defined by directory to be served up by the Apache web server as defined by
``STATIC_ROOT``. ``STATIC_ROOT``.
#. Test and/or use the Mysql integration with Toaster’s Django web #. Test and/or use the Mysql integration with Toaster's Django web
server. At this point, you can start up the normal Toaster Django server. At this point, you can start up the normal Toaster Django
web server with the Toaster database in Mysql. You can use this web web server with the Toaster database in Mysql. You can use this web
server to confirm that the database migration and data population server to confirm that the database migration and data population

12
documentation/toaster-manual/toaster-manual-setup-and-use.xml
View File

@ -70,17 +70,17 @@
web server. This is useful for the following: web server. This is useful for the following:
<itemizedlist> <itemizedlist>
<listitem><para> <listitem><para>
Capturing a command-line build’s statistics into Capturing a command-line build's statistics into
the Toaster database for examination later. the Toaster database for examination later.
</para></listitem> </para></listitem>
<listitem><para> <listitem><para>
Capturing a command-line build’s statistics when Capturing a command-line build's statistics when
the Toaster server is already running. the Toaster server is already running.
</para></listitem> </para></listitem>
<listitem><para> <listitem><para>
Having one instance of the Toaster web server Having one instance of the Toaster web server
track and capture multiple command-line builds, track and capture multiple command-line builds,
where each build is started in its own “noweb” where each build is started in its own "noweb"
Toaster environment. Toaster environment.
</para></listitem> </para></listitem>
</itemizedlist> </itemizedlist>
@ -92,7 +92,7 @@
minutes to ensure the complete transfer of its BitBake build minutes to ensure the complete transfer of its BitBake build
statistics to the Toaster database. statistics to the Toaster database.
If you have a separate Toaster web server instance running, you If you have a separate Toaster web server instance running, you
can watch this command-line build’s progress and examine the can watch this command-line build's progress and examine the
results as soon as they are posted: results as soon as they are posted:
<literallayout class='monospaced'> <literallayout class='monospaced'>
$ source toaster start noweb $ source toaster start noweb
@ -107,7 +107,7 @@
<para> <para>
You can start a Toaster environment with the You can start a Toaster environment with the
“New Projects” feature disabled. "New Projects" feature disabled.
Doing so is useful for the following: Doing so is useful for the following:
<itemizedlist> <itemizedlist>
<listitem><para> <listitem><para>
@ -470,7 +470,7 @@
<filename>STATIC_ROOT</filename>. <filename>STATIC_ROOT</filename>.
</para></listitem> </para></listitem>
<listitem><para> <listitem><para>
Test and/or use the Mysql integration with Toaster’s Test and/or use the Mysql integration with Toaster's
Django web server. Django web server.
At this point, you can start up the normal Toaster At this point, you can start up the normal Toaster
Django web server with the Toaster database in Mysql. Django web server with the Toaster database in Mysql.

18
documentation/transitioning-to-a-custom-environment.rst
View File

@ -10,9 +10,9 @@ 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, 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.
#. **Make a list of the processor, target board, technologies, and capabilities #. **Make a list of the processor, target board, technologies, and capabilities
@ -21,7 +21,7 @@ Transitioning to a custom environment for systems development
things, and adding them to your configuration. (See #3) things, and adding them to your configuration. (See #3)
#. **Set up your board support**. #. **Set up your board support**.
Even if you’re using custom hardware, it might be easier to start with an Even if you're using custom hardware, it might be easier to start with an
existing target board that uses the same processor or at least the same existing target board that uses the same processor or at least the same
architecture as your custom hardware. Knowing the board already has a architecture as your custom hardware. Knowing the board already has a
functioning Board Support Package (BSP) within the project makes it easier functioning Board Support Package (BSP) within the project makes it easier
@ -36,7 +36,7 @@ Transitioning to a custom environment for systems development
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 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 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 that you've downloaded. Be aware that some BSPs may not be immediately
supported on the very latest release, but they will be eventually. supported on the very latest release, but they will be eventually.
You might want to start with the build specification that Poky provides You might want to start with the build specification that Poky provides
@ -46,7 +46,7 @@ Transitioning to a custom environment for systems development
#. **Based on the layers you've chosen, make needed changes in your #. **Based on the layers you've chosen, make needed changes in your
configuration**. configuration**.
For instance, you’ve chosen a machine type and added in the corresponding BSP For instance, you've chosen a machine type and added in the corresponding BSP
layer. You'll then need to change the value of the MACHINE variable in your layer. You'll then need to change the value of the MACHINE variable in your
configuration file (build/local.conf) to point to that same machine configuration file (build/local.conf) to point to that same machine
type. There could be other layer-specific settings you need to change as type. There could be other layer-specific settings you need to change as
@ -82,14 +82,14 @@ Transitioning to a custom environment for systems development
Recipe <dev-manual/dev-manual-common-tasks:writing a new recipe>` in the Recipe <dev-manual/dev-manual-common-tasks:writing a new recipe>` in the
Yocto Project Development Tasks Manual for more information. Yocto Project Development Tasks Manual for more information.
#. **Now you’re ready to create an image recipe**. #. **Now you're ready to create an image recipe**.
There are a number of ways to do this. However, it is strongly recommended There are a number of ways to do this. However, it is strongly recommended
that you have your own image recipe - don’t try appending to existing image that you have your own image recipe - don't try appending to existing image
recipes. Recipes for images are trivial to create and you usually want to recipes. Recipes for images are trivial to create and you usually want to
fully customize their contents. fully customize their contents.
#. **Build your image and refine it**. #. **Build your image and refine it**.
Add what’s missing and fix anything that's broken using your knowledge of the Add what's missing and fix anything that's broken using your knowledge of the
:ref:`workflow <sdk-manual/sdk-extensible:using \`\`devtool\`\` in your sdk :ref:`workflow <sdk-manual/sdk-extensible:using \`\`devtool\`\` in your sdk
workflow>` to identify where issues might be occurring. workflow>` to identify where issues might be occurring.

18
documentation/what-i-wish-id-known.rst
View File

@ -8,7 +8,7 @@ What I wish I'd known about Yocto Project
.. note:: .. note::
Before reading further, make sure you’ve taken a look at the Before reading further, make sure you've taken a look at the
:yocto_home:`Software Overview</software-overview>` page which presents the :yocto_home:`Software Overview</software-overview>` page which presents the
definitions for many of the terms referenced here. Also, know that some of the definitions for many of the terms referenced here. Also, know that some of the
information here won't make sense now, but as you start developing, it is the information here won't make sense now, but as you start developing, it is the
@ -16,8 +16,8 @@ What I wish I'd known about Yocto Project
working with Yocto Project and they are updated regularly. working with Yocto Project and they are updated regularly.
Using the Yocto Project is fairly easy, *until something goes wrong*. Without an Using the Yocto Project is fairly easy, *until something goes wrong*. Without an
understanding of how the build process works, you’ll find yourself trying to understanding of how the build process works, you'll find yourself trying to
troubleshoot “a black box”. Here are a few items that new users wished they had troubleshoot "a black box". Here are a few items that new users wished they had
known before embarking on their first build with Yocto Project. Feel free to known before embarking on their first build with Yocto Project. Feel free to
contact us with other suggestions. contact us with other suggestions.
@ -34,7 +34,7 @@ contact us with other suggestions.
</software-over/layer/>`. Generally check the Compatible layer index first, </software-over/layer/>`. Generally check the Compatible layer index first,
and if you don't find the necessary layer check the general layer index. The and if you don't find the necessary layer check the general layer index. The
layer index is an original artifact from the Open Embedded Project. As such, layer index is an original artifact from the Open Embedded Project. As such,
that index doesn’t have the curating and testing that the Yocto Project that index doesn't have the curating and testing that the Yocto Project
provides on Yocto Project Compatible layer list, but the latter has fewer provides on Yocto Project Compatible layer list, but the latter has fewer
entries. Know that when you start searching in the layer index that not all entries. Know that when you start searching in the layer index that not all
layers have the same level of maturity, validation, or usability. Nor do layers have the same level of maturity, validation, or usability. Nor do
@ -110,7 +110,7 @@ contact us with other suggestions.
: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.
#. **Here’s how you decode “magic” folder names in tmp/work:** #. **Here's how you decode "magic" folder names in tmp/work:**
The build system fetches, unpacks, preprocesses, and builds. If something The build system fetches, unpacks, preprocesses, and builds. If something
goes wrong, the build system reports to you directly the path to a folder goes wrong, the build system reports to you directly the path to a folder
where the temporary (build/tmp) files and packages reside resulting from the where the temporary (build/tmp) files and packages reside resulting from the
@ -128,8 +128,8 @@ contact us with other suggestions.
Yocto Project, the instructions found in the Yocto Project, the instructions found in the
:doc:`brief-yoctoprojectqs/brief-yoctoprojectqs` show how to create an image :doc:`brief-yoctoprojectqs/brief-yoctoprojectqs` show how to create an image
and then run or flash that image. However, you can actually build just a and then run or flash that image. However, you can actually build just a
single recipe. Thus, if some dependency or recipe isn’t working, you can just single recipe. Thus, if some dependency or recipe isn't working, you can just
say “bitbake foo” where "foo" is the name for a specific recipe. As you say "bitbake foo" where "foo" is the name for a specific recipe. As you
become more advanced using the Yocto Project, and if builds are failing, it become more advanced using the Yocto Project, and if builds are failing, it
can be useful to make sure the fetch itself works as desired. Here are some can be useful to make sure the fetch itself works as desired. Here are some
valuable links: :ref:`dev-manual/dev-manual-common-tasks:Using a Development valuable links: :ref:`dev-manual/dev-manual-common-tasks:Using a Development
@ -147,11 +147,11 @@ contact us with other suggestions.
the recipe is building but are different parts (packages) of the build the recipe is building but are different parts (packages) of the build
(i.e. the main package, the doc package, the debug symbols package, the (i.e. the main package, the doc package, the debug symbols package, the
separate utilities package, and so forth). The build system splits out the separate utilities package, and so forth). The build system splits out the
packages so that you don’t need to install the packages you don’t want or packages so that you don't need to install the packages you don't want or
need, which is advantageous because you are building for small devices when need, which is advantageous because you are building for small devices when
developing for embedded and IoT. developing for embedded and IoT.
#. **You will want to learn about and know what’s packaged in rootfs.** #. **You will want to learn about and know what's packaged in rootfs.**
#. **Create your own image recipe:** #. **Create your own image recipe:**
There are a number of ways to create your own image recipe. We suggest you There are a number of ways to create your own image recipe. We suggest you