summaryrefslogtreecommitdiffstats
path: root/documentation
diff options
context:
space:
mode:
authorQuentin Schulz <foss@0leil.net>2020-09-17 01:58:59 +0200
committerRichard Purdie <richard.purdie@linuxfoundation.org>2020-09-17 10:09:36 +0100
commitc387f0c2543a9dd7f8eca069629ede4bb5ec5dba (patch)
treed0a7fccf9b84915862b1174ae75cd0437a60bb2d /documentation
parent6813141743f4263e6b03fd7294f9cec4ec1a3194 (diff)
downloadpoky-c387f0c2543a9dd7f8eca069629ede4bb5ec5dba.tar.gz
sphinx: replace special quotes with single and double quotes
(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>
Diffstat (limited to 'documentation')
-rw-r--r--documentation/adt-manual/adt-prepare.rst4
-rw-r--r--documentation/adt-manual/adt-prepare.xml4
-rw-r--r--documentation/dev-manual/dev-manual-common-tasks.rst6
-rw-r--r--documentation/dev-manual/dev-manual-common-tasks.xml6
-rw-r--r--documentation/dev-manual/dev-manual-qemu.rst8
-rw-r--r--documentation/dev-manual/dev-manual-qemu.xml8
-rw-r--r--documentation/kernel-dev/kernel-dev-concepts-appx.rst2
-rw-r--r--documentation/kernel-dev/kernel-dev-concepts-appx.xml2
-rw-r--r--documentation/overview-manual/overview-manual-development-environment.rst12
-rw-r--r--documentation/overview-manual/overview-manual-development-environment.xml12
-rw-r--r--documentation/overview-manual/overview-manual-yp-intro.rst12
-rw-r--r--documentation/overview-manual/overview-manual-yp-intro.xml12
-rw-r--r--documentation/ref-manual/faq.rst2
-rw-r--r--documentation/ref-manual/faq.xml2
-rw-r--r--documentation/ref-manual/ref-images.rst4
-rw-r--r--documentation/ref-manual/ref-images.xml4
-rw-r--r--documentation/ref-manual/ref-terms.rst2
-rw-r--r--documentation/ref-manual/ref-terms.xml2
-rw-r--r--documentation/test-manual/test-manual-intro.rst6
-rw-r--r--documentation/test-manual/test-manual-intro.xml6
-rw-r--r--documentation/test-manual/test-manual-understand-autobuilder.rst20
-rw-r--r--documentation/test-manual/test-manual-understand-autobuilder.xml16
-rw-r--r--documentation/toaster-manual/toaster-manual-setup-and-use.rst12
-rw-r--r--documentation/toaster-manual/toaster-manual-setup-and-use.xml12
-rw-r--r--documentation/transitioning-to-a-custom-environment.rst18
-rw-r--r--documentation/what-i-wish-id-known.rst18
26 files changed, 106 insertions, 106 deletions
diff --git a/documentation/adt-manual/adt-prepare.rst b/documentation/adt-manual/adt-prepare.rst
index e2141f8059..9b6bd05147 100644
--- a/documentation/adt-manual/adt-prepare.rst
+++ b/documentation/adt-manual/adt-prepare.rst
@@ -189,7 +189,7 @@ the location for cross-toolchain installation. The default location is
189``/opt/poky/``\ release. After either accepting the default location or 189``/opt/poky/``\ release. After either accepting the default location or
190selecting your own location, you are prompted to run the installation 190selecting your own location, you are prompted to run the installation
191script interactively or in silent mode. If you want to closely monitor 191script interactively or in silent mode. If you want to closely monitor
192the installation, choose I for interactive mode rather than S for 192the installation, choose "I" for interactive mode rather than "S" for
193silent mode. Follow the prompts from the script to complete the 193silent mode. Follow the prompts from the script to complete the
194installation. 194installation.
195 195
@@ -594,7 +594,7 @@ For this scenario, you need to do several things:
594- Install the appropriate stand-alone toolchain tarball. 594- Install the appropriate stand-alone toolchain tarball.
595 595
596- Download the pre-built image that will boot with QEMU. You need to be 596- Download the pre-built image that will boot with QEMU. You need to be
597 sure to get the QEMU image that matches your target machines 597 sure to get the QEMU image that matches your target machine's
598 architecture (e.g. x86, ARM, etc.). 598 architecture (e.g. x86, ARM, etc.).
599 599
600- Download the filesystem image for your target machine's architecture. 600- Download the filesystem image for your target machine's architecture.
diff --git a/documentation/adt-manual/adt-prepare.xml b/documentation/adt-manual/adt-prepare.xml
index 684eb75c56..2dc9843259 100644
--- a/documentation/adt-manual/adt-prepare.xml
+++ b/documentation/adt-manual/adt-prepare.xml
@@ -232,7 +232,7 @@
232 own location, you are prompted to run the installation script 232 own location, you are prompted to run the installation script
233 interactively or in silent mode. 233 interactively or in silent mode.
234 If you want to closely monitor the installation, 234 If you want to closely monitor the installation,
235 choose I for interactive mode rather than S for silent mode. 235 choose "I" for interactive mode rather than "S" for silent mode.
236 Follow the prompts from the script to complete the installation. 236 Follow the prompts from the script to complete the installation.
237 </para> 237 </para>
238 238
@@ -765,7 +765,7 @@
765 <itemizedlist> 765 <itemizedlist>
766 <listitem><para>Install the appropriate stand-alone toolchain tarball.</para></listitem> 766 <listitem><para>Install the appropriate stand-alone toolchain tarball.</para></listitem>
767 <listitem><para>Download the pre-built image that will boot with QEMU. 767 <listitem><para>Download the pre-built image that will boot with QEMU.
768 You need to be sure to get the QEMU image that matches your target machines 768 You need to be sure to get the QEMU image that matches your target machine's
769 architecture (e.g. x86, ARM, etc.).</para></listitem> 769 architecture (e.g. x86, ARM, etc.).</para></listitem>
770 <listitem><para>Download the filesystem image for your target machine's architecture. 770 <listitem><para>Download the filesystem image for your target machine's architecture.
771 </para></listitem> 771 </para></listitem>
diff --git a/documentation/dev-manual/dev-manual-common-tasks.rst b/documentation/dev-manual/dev-manual-common-tasks.rst
index d3baa25162..5eb7c51644 100644
--- a/documentation/dev-manual/dev-manual-common-tasks.rst
+++ b/documentation/dev-manual/dev-manual-common-tasks.rst
@@ -6111,7 +6111,7 @@ the existing kernel, and then inserts a new kernel:
6111 6111
6112 If you see the following error, you need to update or create a 6112 If you see the following error, you need to update or create a
6113 ~/.mtoolsrc 6113 ~/.mtoolsrc
6114 file and be sure to have the line mtools_skip_check=1 in the 6114 file and be sure to have the line "mtools_skip_check=1" in the
6115 file. Then, run the Wic command again: 6115 file. Then, run the Wic command again:
6116 :: 6116 ::
6117 6117
@@ -7157,7 +7157,7 @@ variable to specify the format:
71572. Select the desired package format as follows: 71572. Select the desired package format as follows:
7158 :: 7158 ::
7159 7159
7160 PACKAGE_CLASSES ?= package_packageformat 7160 PACKAGE_CLASSES ?= "package_packageformat"
7161 7161
7162 where packageformat can be "ipk", "rpm", 7162 where packageformat can be "ipk", "rpm",
7163 "deb", or "tar" which are the supported package formats. 7163 "deb", or "tar" which are the supported package formats.
@@ -10372,7 +10372,7 @@ debugger.
10372 an image recipe: 10372 an image recipe:
10373 :: 10373 ::
10374 10374
10375 IMAGE_INSTALL_append = gdbserver" 10375 IMAGE_INSTALL_append = " gdbserver"
10376 10376
10377 The change makes 10377 The change makes
10378 sure the ``gdbserver`` package is included. 10378 sure the ``gdbserver`` package is included.
diff --git a/documentation/dev-manual/dev-manual-common-tasks.xml b/documentation/dev-manual/dev-manual-common-tasks.xml
index 1f24c73434..247f6abfd4 100644
--- a/documentation/dev-manual/dev-manual-common-tasks.xml
+++ b/documentation/dev-manual/dev-manual-common-tasks.xml
@@ -8384,7 +8384,7 @@
8384 If you see the following error, you need to 8384 If you see the following error, you need to
8385 update or create a 8385 update or create a
8386 <filename>~/.mtoolsrc</filename> file and 8386 <filename>~/.mtoolsrc</filename> file and
8387 be sure to have the line mtools_skip_check=1 8387 be sure to have the line "mtools_skip_check=1"
8388 in the file. 8388 in the file.
8389 Then, run the Wic command again: 8389 Then, run the Wic command again:
8390 <literallayout class='monospaced'> 8390 <literallayout class='monospaced'>
@@ -9837,7 +9837,7 @@
9837 <listitem><para> 9837 <listitem><para>
9838 Select the desired package format as follows: 9838 Select the desired package format as follows:
9839 <literallayout class='monospaced'> 9839 <literallayout class='monospaced'>
9840 PACKAGE_CLASSES ?= package_<replaceable>packageformat</replaceable> 9840 PACKAGE_CLASSES ?= "package_<replaceable>packageformat</replaceable>"
9841 </literallayout> 9841 </literallayout>
9842 where <replaceable>packageformat</replaceable> 9842 where <replaceable>packageformat</replaceable>
9843 can be "ipk", "rpm", "deb", or "tar" which are the 9843 can be "ipk", "rpm", "deb", or "tar" which are the
@@ -14193,7 +14193,7 @@
14193 <filename>local.conf</filename> file or in an image 14193 <filename>local.conf</filename> file or in an image
14194 recipe: 14194 recipe:
14195 <literallayout class='monospaced'> 14195 <literallayout class='monospaced'>
14196 IMAGE_INSTALL_append = gdbserver" 14196 IMAGE_INSTALL_append = " gdbserver"
14197 </literallayout> 14197 </literallayout>
14198 The change makes sure the <filename>gdbserver</filename> 14198 The change makes sure the <filename>gdbserver</filename>
14199 package is included. 14199 package is included.
diff --git a/documentation/dev-manual/dev-manual-qemu.rst b/documentation/dev-manual/dev-manual-qemu.rst
index 82c214b9bb..88b03745f4 100644
--- a/documentation/dev-manual/dev-manual-qemu.rst
+++ b/documentation/dev-manual/dev-manual-qemu.rst
@@ -74,7 +74,7 @@ available. Follow these general steps to run QEMU:
74 74
753. *Ensure the Artifacts are in Place:* You need to be sure you have a 753. *Ensure the Artifacts are in Place:* You need to be sure you have a
76 pre-built kernel that will boot in QEMU. You also need the target 76 pre-built kernel that will boot in QEMU. You also need the target
77 root filesystem for your target machines architecture: 77 root filesystem for your target machine's architecture:
78 78
79 - If you have previously built an image for QEMU (e.g. ``qemux86``, 79 - If you have previously built an image for QEMU (e.g. ``qemux86``,
80 ``qemuarm``, and so forth), then the artifacts are in place in 80 ``qemuarm``, and so forth), then the artifacts are in place in
@@ -396,7 +396,7 @@ command line:
396 396
397- ROOTFS: A root filesystem that has one of the following filetype 397- ROOTFS: A root filesystem that has one of the following filetype
398 extensions: "ext2", "ext3", "ext4", "jffs2", "nfs", or "btrfs". If 398 extensions: "ext2", "ext3", "ext4", "jffs2", "nfs", or "btrfs". If
399 the filename you provide for this option uses nfs, it must provide 399 the filename you provide for this option uses "nfs", it must provide
400 an explicit root filesystem path. 400 an explicit root filesystem path.
401 401
402- KERNEL: A kernel image, which is a ``.bin`` file. When you provide a 402- KERNEL: A kernel image, which is a ``.bin`` file. When you provide a
@@ -405,7 +405,7 @@ command line:
405 405
406- MACHINE: The architecture of the QEMU machine, which must be one of 406- MACHINE: The architecture of the QEMU machine, which must be one of
407 the following: "qemux86", "qemux86-64", "qemuarm", "qemuarm64", 407 the following: "qemux86", "qemux86-64", "qemuarm", "qemuarm64",
408 "qemumips", qemumips64", or "qemuppc". The MACHINE and QEMUARCH 408 "qemumips", "qemumips64", or "qemuppc". The MACHINE and QEMUARCH
409 options are basically identical. If you do not provide a MACHINE 409 options are basically identical. If you do not provide a MACHINE
410 option, ``runqemu`` tries to determine it based on other options. 410 option, ``runqemu`` tries to determine it based on other options.
411 411
@@ -465,6 +465,6 @@ command line:
465 ``/dev/vhost-net``. 465 ``/dev/vhost-net``.
466 466
467 - The build host ``/dev/vhost-net`` directory has to be either 467 - The build host ``/dev/vhost-net`` directory has to be either
468 readable or writable and slirp-enabled. 468 readable or writable and "slirp-enabled".
469 469
470- ``publicvnc``: Enables a VNC server open to all hosts. 470- ``publicvnc``: Enables a VNC server open to all hosts.
diff --git a/documentation/dev-manual/dev-manual-qemu.xml b/documentation/dev-manual/dev-manual-qemu.xml
index 46fe67bab0..1a526dd2f5 100644
--- a/documentation/dev-manual/dev-manual-qemu.xml
+++ b/documentation/dev-manual/dev-manual-qemu.xml
@@ -106,7 +106,7 @@
106 You need to be sure you have a pre-built kernel that 106 You need to be sure you have a pre-built kernel that
107 will boot in QEMU. 107 will boot in QEMU.
108 You also need the target root filesystem for your target 108 You also need the target root filesystem for your target
109 machines architecture: 109 machine's architecture:
110 <itemizedlist> 110 <itemizedlist>
111 <listitem><para> 111 <listitem><para>
112 If you have previously built an image for QEMU 112 If you have previously built an image for QEMU
@@ -553,7 +553,7 @@
553 A root filesystem that has one of the following 553 A root filesystem that has one of the following
554 filetype extensions: "ext2", "ext3", "ext4", "jffs2", 554 filetype extensions: "ext2", "ext3", "ext4", "jffs2",
555 "nfs", or "btrfs". 555 "nfs", or "btrfs".
556 If the filename you provide for this option uses nfs, it 556 If the filename you provide for this option uses "nfs", it
557 must provide an explicit root filesystem path. 557 must provide an explicit root filesystem path.
558 </para></listitem> 558 </para></listitem>
559 <listitem><para> 559 <listitem><para>
@@ -567,7 +567,7 @@
567 <replaceable>MACHINE</replaceable>: 567 <replaceable>MACHINE</replaceable>:
568 The architecture of the QEMU machine, which must be one 568 The architecture of the QEMU machine, which must be one
569 of the following: "qemux86", "qemux86-64", "qemuarm", 569 of the following: "qemux86", "qemux86-64", "qemuarm",
570 "qemuarm64", "qemumips", qemumips64", or "qemuppc". 570 "qemuarm64", "qemumips", "qemumips64", or "qemuppc".
571 The <replaceable>MACHINE</replaceable> and 571 The <replaceable>MACHINE</replaceable> and
572 <replaceable>QEMUARCH</replaceable> options are basically 572 <replaceable>QEMUARCH</replaceable> options are basically
573 identical. 573 identical.
@@ -674,7 +674,7 @@ qemux86" or "qemux86-64".
674 <listitem><para> 674 <listitem><para>
675 The build host <filename>/dev/vhost-net</filename> 675 The build host <filename>/dev/vhost-net</filename>
676 directory has to be either readable or writable 676 directory has to be either readable or writable
677 and slirp-enabled. 677 and "slirp-enabled".
678 </para></listitem> 678 </para></listitem>
679 </itemizedlist> 679 </itemizedlist>
680 </para></listitem> 680 </para></listitem>
diff --git a/documentation/kernel-dev/kernel-dev-concepts-appx.rst b/documentation/kernel-dev/kernel-dev-concepts-appx.rst
index 4ddb7ddb60..04cb1172b2 100644
--- a/documentation/kernel-dev/kernel-dev-concepts-appx.rst
+++ b/documentation/kernel-dev/kernel-dev-concepts-appx.rst
@@ -129,7 +129,7 @@ cutting edge Yocto Linux kernel that mixes forward ports of existing
129Linux kernel features and significant and critical new functionality. 129Linux kernel features and significant and critical new functionality.
130Forward porting Linux kernel functionality into the Yocto Linux kernels 130Forward porting Linux kernel functionality into the Yocto Linux kernels
131available through the Yocto Project can be thought of as a "micro 131available through the Yocto Project can be thought of as a "micro
132uprev." The many micro uprevs produce a Yocto Linux kernel version 132uprev." The many "micro uprevs" produce a Yocto Linux kernel version
133with a mix of important new mainline, non-mainline, BSP developments and 133with a mix of important new mainline, non-mainline, BSP developments and
134feature integrations. This Yocto Linux kernel gives insight into new 134feature integrations. This Yocto Linux kernel gives insight into new
135features and allows focused amounts of testing to be done on the kernel, 135features and allows focused amounts of testing to be done on the kernel,
diff --git a/documentation/kernel-dev/kernel-dev-concepts-appx.xml b/documentation/kernel-dev/kernel-dev-concepts-appx.xml
index 0f2df2a629..bf0c525caf 100644
--- a/documentation/kernel-dev/kernel-dev-concepts-appx.xml
+++ b/documentation/kernel-dev/kernel-dev-concepts-appx.xml
@@ -192,7 +192,7 @@
192 Forward porting Linux kernel functionality into the Yocto Linux 192 Forward porting Linux kernel functionality into the Yocto Linux
193 kernels available through the Yocto Project can be thought of as 193 kernels available through the Yocto Project can be thought of as
194 a "micro uprev." 194 a "micro uprev."
195 The many micro uprevs produce a Yocto Linux kernel version with 195 The many "micro uprevs" produce a Yocto Linux kernel version with
196 a mix of important new mainline, non-mainline, BSP developments 196 a mix of important new mainline, non-mainline, BSP developments
197 and feature integrations. 197 and feature integrations.
198 This Yocto Linux kernel gives insight into new features and 198 This Yocto Linux kernel gives insight into new features and
diff --git a/documentation/overview-manual/overview-manual-development-environment.rst b/documentation/overview-manual/overview-manual-development-environment.rst
index 273e1027da..3b5147d732 100644
--- a/documentation/overview-manual/overview-manual-development-environment.rst
+++ b/documentation/overview-manual/overview-manual-development-environment.rst
@@ -238,7 +238,7 @@ open source projects do so.
238 238
239For the Yocto Project, a key individual called the "maintainer" is 239For the Yocto Project, a key individual called the "maintainer" is
240responsible for the integrity of the "master" branch of a given Git 240responsible for the integrity of the "master" branch of a given Git
241repository. The "master" branch is the upstream repository from which 241repository. The "master" branch is the "upstream" repository from which
242final or most recent builds of a project occur. The maintainer is 242final or most recent builds of a project occur. The maintainer is
243responsible for accepting changes from other developers and for 243responsible for accepting changes from other developers and for
244organizing the underlying branch structure to reflect release strategies 244organizing the underlying branch structure to reflect release strategies
@@ -273,19 +273,19 @@ with whatever upstream branch they are working against. They are also
273responsible for straightening out any conflicts that might arise within 273responsible for straightening out any conflicts that might arise within
274files that are being worked on simultaneously by more than one person. 274files that are being worked on simultaneously by more than one person.
275All this work is done locally on the development host before anything is 275All this work is done locally on the development host before anything is
276pushed to a "contrib" area and examined at the maintainers level. 276pushed to a "contrib" area and examined at the maintainer's level.
277 277
278A somewhat formal method exists by which developers commit changes and 278A somewhat formal method exists by which developers commit changes and
279push them into the "contrib" area and subsequently request that the 279push them into the "contrib" area and subsequently request that the
280maintainer include them into an upstream branch. This process is called 280maintainer include them into an upstream branch. This process is called
281submitting a patch or "submitting a change." For information on 281"submitting a patch" or "submitting a change." For information on
282submitting patches and changes, see the 282submitting patches and changes, see the
283":ref:`dev-manual/dev-manual-common-tasks:submitting a change to the yocto project`" 283":ref:`dev-manual/dev-manual-common-tasks:submitting a change to the yocto project`"
284section in the Yocto Project Development Tasks Manual. 284section in the Yocto Project Development Tasks Manual.
285 285
286In summary, a single point of entry exists for changes into a "master" 286In summary, a single point of entry exists for changes into a "master"
287or development branch of the Git repository, which is controlled by the 287or development branch of the Git repository, which is controlled by the
288projects maintainer. And, a set of developers exist who independently 288project's maintainer. And, a set of developers exist who independently
289develop, test, and submit changes to "contrib" areas for the maintainer 289develop, test, and submit changes to "contrib" areas for the maintainer
290to examine. The maintainer then chooses which changes are going to 290to examine. The maintainer then chooses which changes are going to
291become a permanent part of the project. 291become a permanent part of the project.
@@ -526,7 +526,7 @@ descriptions and strategies on how to use these commands:
526 Git commands unless you have a ``.git`` repository. 526 Git commands unless you have a ``.git`` repository.
527 527
528- *git clone:* Creates a local clone of a Git repository that is on 528- *git clone:* Creates a local clone of a Git repository that is on
529 equal footing with a fellow developers Git repository or an upstream 529 equal footing with a fellow developer's Git repository or an upstream
530 repository. 530 repository.
531 531
532- *git add:* Locally stages updated file contents to the index that 532- *git add:* Locally stages updated file contents to the index that
@@ -537,7 +537,7 @@ descriptions and strategies on how to use these commands:
537 you made. Only changes that have been staged can be committed. 537 you made. Only changes that have been staged can be committed.
538 Commits are used for historical purposes, for determining if a 538 Commits are used for historical purposes, for determining if a
539 maintainer of a project will allow the change, and for ultimately 539 maintainer of a project will allow the change, and for ultimately
540 pushing the change from your local Git repository into the projects 540 pushing the change from your local Git repository into the project's
541 upstream repository. 541 upstream repository.
542 542
543- *git status:* Reports any modified files that possibly need to be 543- *git status:* Reports any modified files that possibly need to be
diff --git a/documentation/overview-manual/overview-manual-development-environment.xml b/documentation/overview-manual/overview-manual-development-environment.xml
index 8415d1dd70..08ad071316 100644
--- a/documentation/overview-manual/overview-manual-development-environment.xml
+++ b/documentation/overview-manual/overview-manual-development-environment.xml
@@ -327,7 +327,7 @@
327 For the Yocto Project, a key individual called the "maintainer" is 327 For the Yocto Project, a key individual called the "maintainer" is
328 responsible for the integrity of the "master" branch of a given Git 328 responsible for the integrity of the "master" branch of a given Git
329 repository. 329 repository.
330 The "master" branch is the upstream repository from which final or 330 The "master" branch is the "upstream" repository from which final or
331 most recent builds of a project occur. 331 most recent builds of a project occur.
332 The maintainer is responsible for accepting changes from other 332 The maintainer is responsible for accepting changes from other
333 developers and for organizing the underlying branch structure to 333 developers and for organizing the underlying branch structure to
@@ -372,7 +372,7 @@
372 might arise within files that are being worked on simultaneously by 372 might arise within files that are being worked on simultaneously by
373 more than one person. 373 more than one person.
374 All this work is done locally on the development host before 374 All this work is done locally on the development host before
375 anything is pushed to a "contrib" area and examined at the maintainers 375 anything is pushed to a "contrib" area and examined at the maintainer's
376 level. 376 level.
377 </para> 377 </para>
378 378
@@ -380,7 +380,7 @@
380 A somewhat formal method exists by which developers commit changes 380 A somewhat formal method exists by which developers commit changes
381 and push them into the "contrib" area and subsequently request that 381 and push them into the "contrib" area and subsequently request that
382 the maintainer include them into an upstream branch. 382 the maintainer include them into an upstream branch.
383 This process is called submitting a patch or "submitting a change." 383 This process is called "submitting a patch" or "submitting a change."
384 For information on submitting patches and changes, see the 384 For information on submitting patches and changes, see the
385 "<ulink url='&YOCTO_DOCS_DEV_URL;#how-to-submit-a-change'>Submitting a Change to the Yocto Project</ulink>" 385 "<ulink url='&YOCTO_DOCS_DEV_URL;#how-to-submit-a-change'>Submitting a Change to the Yocto Project</ulink>"
386 section in the Yocto Project Development Tasks Manual. 386 section in the Yocto Project Development Tasks Manual.
@@ -389,7 +389,7 @@
389 <para> 389 <para>
390 In summary, a single point of entry 390 In summary, a single point of entry
391 exists for changes into a "master" or development branch of the 391 exists for changes into a "master" or development branch of the
392 Git repository, which is controlled by the projects maintainer. 392 Git repository, which is controlled by the project's maintainer.
393 And, a set of developers exist who independently develop, test, and 393 And, a set of developers exist who independently develop, test, and
394 submit changes to "contrib" areas for the maintainer to examine. 394 submit changes to "contrib" areas for the maintainer to examine.
395 The maintainer then chooses which changes are going to become a 395 The maintainer then chooses which changes are going to become a
@@ -734,7 +734,7 @@
734 <listitem><para id='git-commands-clone'> 734 <listitem><para id='git-commands-clone'>
735 <emphasis><filename>git clone</filename>:</emphasis> 735 <emphasis><filename>git clone</filename>:</emphasis>
736 Creates a local clone of a Git repository that is on 736 Creates a local clone of a Git repository that is on
737 equal footing with a fellow developers Git repository 737 equal footing with a fellow developer's Git repository
738 or an upstream repository. 738 or an upstream repository.
739 </para></listitem> 739 </para></listitem>
740 <listitem><para> 740 <listitem><para>
@@ -752,7 +752,7 @@
752 Commits are used for historical purposes, for determining 752 Commits are used for historical purposes, for determining
753 if a maintainer of a project will allow the change, 753 if a maintainer of a project will allow the change,
754 and for ultimately pushing the change from your local 754 and for ultimately pushing the change from your local
755 Git repository into the projects upstream repository. 755 Git repository into the project's upstream repository.
756 </para></listitem> 756 </para></listitem>
757 <listitem><para> 757 <listitem><para>
758 <emphasis><filename>git status</filename>:</emphasis> 758 <emphasis><filename>git status</filename>:</emphasis>
diff --git a/documentation/overview-manual/overview-manual-yp-intro.rst b/documentation/overview-manual/overview-manual-yp-intro.rst
index f01d9f7125..823c96d88c 100644
--- a/documentation/overview-manual/overview-manual-yp-intro.rst
+++ b/documentation/overview-manual/overview-manual-yp-intro.rst
@@ -319,14 +319,14 @@ applications using the Yocto Project:
319 319
320 The ``devtool`` command employs a number of sub-commands that allow 320 The ``devtool`` command employs a number of sub-commands that allow
321 you to add, modify, and upgrade recipes. As with the OpenEmbedded 321 you to add, modify, and upgrade recipes. As with the OpenEmbedded
322 build system, recipes represent software packages within 322 build system, "recipes" represent software packages within
323 ``devtool``. When you use ``devtool add``, a recipe is automatically 323 ``devtool``. When you use ``devtool add``, a recipe is automatically
324 created. When you use ``devtool modify``, the specified existing 324 created. When you use ``devtool modify``, the specified existing
325 recipe is used in order to determine where to get the source code and 325 recipe is used in order to determine where to get the source code and
326 how to patch it. In both cases, an environment is set up so that when 326 how to patch it. In both cases, an environment is set up so that when
327 you build the recipe a source tree that is under your control is used 327 you build the recipe a source tree that is under your control is used
328 in order to allow you to make changes to the source as desired. By 328 in order to allow you to make changes to the source as desired. By
329 default, both new recipes and the source go into a workspace 329 default, both new recipes and the source go into a "workspace"
330 directory under the eSDK. The ``devtool upgrade`` command updates an 330 directory under the eSDK. The ``devtool upgrade`` command updates an
331 existing recipe so that you can build it for an updated set of source 331 existing recipe so that you can build it for an updated set of source
332 files. 332 files.
@@ -417,7 +417,7 @@ activities using the Yocto Project:
417 years ago. Both prelink and cross-prelink are maintained in the same 417 years ago. Both prelink and cross-prelink are maintained in the same
418 repository albeit on separate branches. By providing an emulated 418 repository albeit on separate branches. By providing an emulated
419 runtime dynamic linker (i.e. ``glibc``-derived ``ld.so`` emulation), 419 runtime dynamic linker (i.e. ``glibc``-derived ``ld.so`` emulation),
420 the cross-prelink project extends the prelink softwares ability to 420 the cross-prelink project extends the prelink software's ability to
421 prelink a sysroot environment. Additionally, the cross-prelink 421 prelink a sysroot environment. Additionally, the cross-prelink
422 software enables the ability to work in sysroot style environments. 422 software enables the ability to work in sysroot style environments.
423 423
@@ -432,7 +432,7 @@ activities using the Yocto Project:
432 library code can be re-used from shared Copy-On-Write (COW) pages. 432 library code can be re-used from shared Copy-On-Write (COW) pages.
433 433
434 The original upstream prelink project only supports running prelink 434 The original upstream prelink project only supports running prelink
435 on the end target device due to the reliance on the target devices 435 on the end target device due to the reliance on the target device's
436 dynamic linker. This restriction causes issues when developing a 436 dynamic linker. This restriction causes issues when developing a
437 cross-compiled system. The cross-prelink adds a synthesized dynamic 437 cross-compiled system. The cross-prelink adds a synthesized dynamic
438 loader that runs on the host, thus permitting cross-prelinking 438 loader that runs on the host, thus permitting cross-prelinking
@@ -495,7 +495,7 @@ The following list consists of components associated with the
495 Sharing a core set of metadata results in Poky as an integration 495 Sharing a core set of metadata results in Poky as an integration
496 layer on top of OE-Core. You can see that in this 496 layer on top of OE-Core. You can see that in this
497 `figure <#yp-key-dev-elements>`__. The Yocto Project combines various 497 `figure <#yp-key-dev-elements>`__. The Yocto Project combines various
498 components such as BitBake, OE-Core, script glue, and documentation 498 components such as BitBake, OE-Core, script "glue", and documentation
499 for its build system. 499 for its build system.
500 500
501.. _gs-reference-distribution-poky: 501.. _gs-reference-distribution-poky:
@@ -556,7 +556,7 @@ targets:
556 .. note:: 556 .. note::
557 557
558 As best it can, opkg maintains backwards compatibility with ipkg 558 As best it can, opkg maintains backwards compatibility with ipkg
559 and conforms to a subset of Debians policy manual regarding 559 and conforms to a subset of Debian's policy manual regarding
560 control files. 560 control files.
561 561
562.. _gs-archived-components: 562.. _gs-archived-components:
diff --git a/documentation/overview-manual/overview-manual-yp-intro.xml b/documentation/overview-manual/overview-manual-yp-intro.xml
index 2097ed36e5..a2a1f494bb 100644
--- a/documentation/overview-manual/overview-manual-yp-intro.xml
+++ b/documentation/overview-manual/overview-manual-yp-intro.xml
@@ -459,7 +459,7 @@
459 <para>The <filename>devtool</filename> command employs 459 <para>The <filename>devtool</filename> command employs
460 a number of sub-commands that allow you to add, modify, 460 a number of sub-commands that allow you to add, modify,
461 and upgrade recipes. 461 and upgrade recipes.
462 As with the OpenEmbedded build system, recipes 462 As with the OpenEmbedded build system, "recipes"
463 represent software packages within 463 represent software packages within
464 <filename>devtool</filename>. 464 <filename>devtool</filename>.
465 When you use <filename>devtool add</filename>, a recipe 465 When you use <filename>devtool add</filename>, a recipe
@@ -472,7 +472,7 @@
472 control is used in order to allow you to make changes 472 control is used in order to allow you to make changes
473 to the source as desired. 473 to the source as desired.
474 By default, both new recipes and the source go into 474 By default, both new recipes and the source go into
475 a workspace directory under the eSDK. 475 a "workspace" directory under the eSDK.
476 The <filename>devtool upgrade</filename> command 476 The <filename>devtool upgrade</filename> command
477 updates an existing recipe so that you can build it 477 updates an existing recipe so that you can build it
478 for an updated set of source files.</para> 478 for an updated set of source files.</para>
@@ -598,7 +598,7 @@
598 By providing an emulated runtime dynamic linker 598 By providing an emulated runtime dynamic linker
599 (i.e. <filename>glibc</filename>-derived 599 (i.e. <filename>glibc</filename>-derived
600 <filename>ld.so</filename> emulation), the 600 <filename>ld.so</filename> emulation), the
601 cross-prelink project extends the prelink softwares 601 cross-prelink project extends the prelink software's
602 ability to prelink a sysroot environment. 602 ability to prelink a sysroot environment.
603 Additionally, the cross-prelink software enables the 603 Additionally, the cross-prelink software enables the
604 ability to work in sysroot style environments.</para> 604 ability to work in sysroot style environments.</para>
@@ -620,7 +620,7 @@
620 620
621 <para>The original upstream prelink project only 621 <para>The original upstream prelink project only
622 supports running prelink on the end target device 622 supports running prelink on the end target device
623 due to the reliance on the target devices dynamic 623 due to the reliance on the target device's dynamic
624 linker. 624 linker.
625 This restriction causes issues when developing a 625 This restriction causes issues when developing a
626 cross-compiled system. 626 cross-compiled system.
@@ -713,7 +713,7 @@
713 You can see that in this 713 You can see that in this
714 <link linkend='yp-key-dev-elements'>figure</link>. 714 <link linkend='yp-key-dev-elements'>figure</link>.
715 The Yocto Project combines various components such as 715 The Yocto Project combines various components such as
716 BitBake, OE-Core, script glue, and documentation 716 BitBake, OE-Core, script "glue", and documentation
717 for its build system. 717 for its build system.
718 </para></listitem> 718 </para></listitem>
719 </itemizedlist> 719 </itemizedlist>
@@ -791,7 +791,7 @@
791 <note> 791 <note>
792 As best it can, opkg maintains backwards 792 As best it can, opkg maintains backwards
793 compatibility with ipkg and conforms to a subset 793 compatibility with ipkg and conforms to a subset
794 of Debians policy manual regarding control files. 794 of Debian's policy manual regarding control files.
795 </note> 795 </note>
796 </para></listitem> 796 </para></listitem>
797 </itemizedlist> 797 </itemizedlist>
diff --git a/documentation/ref-manual/faq.rst b/documentation/ref-manual/faq.rst
index 04066e9202..2d2aaad0a9 100644
--- a/documentation/ref-manual/faq.rst
+++ b/documentation/ref-manual/faq.rst
@@ -143,7 +143,7 @@ various proxy types and configuring proxy servers, see the
143":yocto_wiki:`Working Behind a Network Proxy </wiki/Working_Behind_a_Network_Proxy>`" 143":yocto_wiki:`Working Behind a Network Proxy </wiki/Working_Behind_a_Network_Proxy>`"
144Wiki page. 144Wiki page.
145 145
146**Q:** Whats the difference between target and target\ ``-native``? 146**Q:** What's the difference between target and target\ ``-native``?
147 147
148**A:** The ``*-native`` targets are designed to run on the system being 148**A:** The ``*-native`` targets are designed to run on the system being
149used for the build. These are usually tools that are needed to assist 149used for the build. These are usually tools that are needed to assist
diff --git a/documentation/ref-manual/faq.xml b/documentation/ref-manual/faq.xml
index 98ae0a975b..2f8fcf3242 100644
--- a/documentation/ref-manual/faq.xml
+++ b/documentation/ref-manual/faq.xml
@@ -323,7 +323,7 @@
323 <qandaentry> 323 <qandaentry>
324 <question> 324 <question>
325 <para> 325 <para>
326 What’s the difference between <replaceable>target</replaceable> and <replaceable>target</replaceable><filename>-native</filename>? 326 What's the difference between <replaceable>target</replaceable> and <replaceable>target</replaceable><filename>-native</filename>?
327 </para> 327 </para>
328 </question> 328 </question>
329 <answer> 329 <answer>
diff --git a/documentation/ref-manual/ref-images.rst b/documentation/ref-manual/ref-images.rst
index 47beda0c23..f0229c3bb7 100644
--- a/documentation/ref-manual/ref-images.rst
+++ b/documentation/ref-manual/ref-images.rst
@@ -6,7 +6,7 @@ Images
6 6
7The OpenEmbedded build system provides several example images to satisfy 7The OpenEmbedded build system provides several example images to satisfy
8different needs. When you issue the ``bitbake`` command you provide a 8different needs. When you issue the ``bitbake`` command you provide a
9top-level recipe that essentially begins the build for the type of 9"top-level" recipe that essentially begins the build for the type of
10image you want. 10image you want.
11 11
12.. note:: 12.. note::
@@ -85,7 +85,7 @@ Following is a list of supported recipes:
85 85
86- ``core-image-minimal-initramfs``: A ``core-image-minimal`` image that 86- ``core-image-minimal-initramfs``: A ``core-image-minimal`` image that
87 has the Minimal RAM-based Initial Root Filesystem (initramfs) as part 87 has the Minimal RAM-based Initial Root Filesystem (initramfs) as part
88 of the kernel, which allows the system to find the first init 88 of the kernel, which allows the system to find the first "init"
89 program more efficiently. See the 89 program more efficiently. See the
90 :term:`PACKAGE_INSTALL` variable for 90 :term:`PACKAGE_INSTALL` variable for
91 additional information helpful when working with initramfs images. 91 additional information helpful when working with initramfs images.
diff --git a/documentation/ref-manual/ref-images.xml b/documentation/ref-manual/ref-images.xml
index aaeda55226..6f10a6fd2a 100644
--- a/documentation/ref-manual/ref-images.xml
+++ b/documentation/ref-manual/ref-images.xml
@@ -9,7 +9,7 @@
9 <para> 9 <para>
10 The OpenEmbedded build system provides several example 10 The OpenEmbedded build system provides several example
11 images to satisfy different needs. 11 images to satisfy different needs.
12 When you issue the <filename>bitbake</filename> command you provide a top-level recipe 12 When you issue the <filename>bitbake</filename> command you provide a "top-level" recipe
13 that essentially begins the build for the type of image you want. 13 that essentially begins the build for the type of image you want.
14 </para> 14 </para>
15 15
@@ -100,7 +100,7 @@
100 <listitem><para id='images-core-image-minimal-initramfs'><filename>core-image-minimal-initramfs</filename>: 100 <listitem><para id='images-core-image-minimal-initramfs'><filename>core-image-minimal-initramfs</filename>:
101 A <filename>core-image-minimal</filename> image that has the Minimal RAM-based 101 A <filename>core-image-minimal</filename> image that has the Minimal RAM-based
102 Initial Root Filesystem (initramfs) as part of the kernel, 102 Initial Root Filesystem (initramfs) as part of the kernel,
103 which allows the system to find the first init program more efficiently. 103 which allows the system to find the first "init" program more efficiently.
104 See the 104 See the
105 <link linkend='var-PACKAGE_INSTALL'><filename>PACKAGE_INSTALL</filename></link> 105 <link linkend='var-PACKAGE_INSTALL'><filename>PACKAGE_INSTALL</filename></link>
106 variable for additional information helpful when working with 106 variable for additional information helpful when working with
diff --git a/documentation/ref-manual/ref-terms.rst b/documentation/ref-manual/ref-terms.rst
index 312fc12ef0..6e7e5169ce 100644
--- a/documentation/ref-manual/ref-terms.rst
+++ b/documentation/ref-manual/ref-terms.rst
@@ -273,7 +273,7 @@ universal, the list includes them just in case:
273 Arbitrary groups of software Recipes. You use 273 Arbitrary groups of software Recipes. You use
274 package groups to hold recipes that, when built, usually accomplish a 274 package groups to hold recipes that, when built, usually accomplish a
275 single task. For example, a package group could contain the recipes 275 single task. For example, a package group could contain the recipes
276 for a companys proprietary or value-add software. Or, the package 276 for a company's proprietary or value-add software. Or, the package
277 group could contain the recipes that enable graphics. A package group 277 group could contain the recipes that enable graphics. A package group
278 is really just another recipe. Because package group files are 278 is really just another recipe. Because package group files are
279 recipes, they end with the ``.bb`` filename extension. 279 recipes, they end with the ``.bb`` filename extension.
diff --git a/documentation/ref-manual/ref-terms.xml b/documentation/ref-manual/ref-terms.xml
index d2605c62a8..2a0452bd78 100644
--- a/documentation/ref-manual/ref-terms.xml
+++ b/documentation/ref-manual/ref-terms.xml
@@ -365,7 +365,7 @@
365 You use package groups to hold recipes that, when built, 365 You use package groups to hold recipes that, when built,
366 usually accomplish a single task. 366 usually accomplish a single task.
367 For example, a package group could contain the recipes for a 367 For example, a package group could contain the recipes for a
368 companys proprietary or value-add software. 368 company's proprietary or value-add software.
369 Or, the package group could contain the recipes that enable 369 Or, the package group could contain the recipes that enable
370 graphics. 370 graphics.
371 A package group is really just another recipe. 371 A package group is really just another recipe.
diff --git a/documentation/test-manual/test-manual-intro.rst b/documentation/test-manual/test-manual-intro.rst
index b0bc24c9b0..53ad650b35 100644
--- a/documentation/test-manual/test-manual-intro.rst
+++ b/documentation/test-manual/test-manual-intro.rst
@@ -12,9 +12,9 @@ Welcome
12Welcome to the Yocto Project Test Environment Manual! This manual is a 12Welcome to the Yocto Project Test Environment Manual! This manual is a
13work in progress. The manual contains information about the testing 13work in progress. The manual contains information about the testing
14environment used by the Yocto Project to make sure each major and minor 14environment used by the Yocto Project to make sure each major and minor
15release works as intended. All the projects testing infrastructure and 15release works as intended. All the project's testing infrastructure and
16processes are publicly visible and available so that the community can 16processes are publicly visible and available so that the community can
17see what testing is being performed, how its being done and the current 17see what testing is being performed, how it's being done and the current
18status of the tests and the project at any given time. It is intended 18status of the tests and the project at any given time. It is intended
19that Other organizations can leverage off the process and testing 19that Other organizations can leverage off the process and testing
20environment used by the Yocto Project to create their own automated, 20environment used by the Yocto Project to create their own automated,
@@ -514,7 +514,7 @@ resource utilisation as that happens. An example from
514 'bitbake -p (cached)') 514 'bitbake -p (cached)')
515 515
516This example shows how three specific parsing timings are 516This example shows how three specific parsing timings are
517measured, with and without various caches, to show how BitBakes parsing 517measured, with and without various caches, to show how BitBake's parsing
518performance trends over time. 518performance trends over time.
519 519
520.. _test-writing-considerations: 520.. _test-writing-considerations:
diff --git a/documentation/test-manual/test-manual-intro.xml b/documentation/test-manual/test-manual-intro.xml
index 8e2c7cd874..0cdbee4d8e 100644
--- a/documentation/test-manual/test-manual-intro.xml
+++ b/documentation/test-manual/test-manual-intro.xml
@@ -12,8 +12,8 @@
12 <para> Welcome to the Yocto Project Test Environment Manual! This manual is a work in 12 <para> Welcome to the Yocto Project Test Environment Manual! This manual is a work in
13 progress. The manual contains information about the testing environment used by the 13 progress. The manual contains information about the testing environment used by the
14 Yocto Project to make sure each major and minor release works as intended. All the 14 Yocto Project to make sure each major and minor release works as intended. All the
15 projects testing infrastructure and processes are publicly visible and available so 15 project's testing infrastructure and processes are publicly visible and available so
16 that the community can see what testing is being performed, how its being done and the 16 that the community can see what testing is being performed, how it's being done and the
17 current status of the tests and the project at any given time. It is intended that Other 17 current status of the tests and the project at any given time. It is intended that Other
18 organizations can leverage off the process and testing environment used by the Yocto 18 organizations can leverage off the process and testing environment used by the Yocto
19 Project to create their own automated, production test environment, building upon the 19 Project to create their own automated, production test environment, building upon the
@@ -579,7 +579,7 @@
579 'bitbake -p (cached)') 579 'bitbake -p (cached)')
580 </literallayout>This 580 </literallayout>This
581 example shows how three specific parsing timings are measured, with and without 581 example shows how three specific parsing timings are measured, with and without
582 various caches, to show how BitBakes parsing performance trends over time.</para> 582 various caches, to show how BitBake's parsing performance trends over time.</para>
583 </section> 583 </section>
584 </section> 584 </section>
585 <section id='test-writing-considerations'> 585 <section id='test-writing-considerations'>
diff --git a/documentation/test-manual/test-manual-understand-autobuilder.rst b/documentation/test-manual/test-manual-understand-autobuilder.rst
index 0809190b5b..2fcae5000e 100644
--- a/documentation/test-manual/test-manual-understand-autobuilder.rst
+++ b/documentation/test-manual/test-manual-understand-autobuilder.rst
@@ -7,19 +7,19 @@ Understanding the Yocto Project Autobuilder
7Execution Flow within the Autobuilder 7Execution Flow within the Autobuilder
8===================================== 8=====================================
9 9
10The a-full and a-quick targets are the usual entry points into the 10The "a-full" and "a-quick" targets are the usual entry points into the
11Autobuilder and it makes sense to follow the process through the system 11Autobuilder and it makes sense to follow the process through the system
12starting there. This is best visualised from the Autobuilder Console 12starting there. This is best visualised from the Autobuilder Console
13view (:yocto_ab:`/typhoon/#/console`). 13view (:yocto_ab:`/typhoon/#/console`).
14 14
15Each item along the top of that view represents some target build and 15Each item along the top of that view represents some "target build" and
16these targets are all run in parallel. The full build will trigger the 16these targets are all run in parallel. The 'full' build will trigger the
17majority of them, the quick build will trigger some subset of them. 17majority of them, the "quick" build will trigger some subset of them.
18The Autobuilder effectively runs whichever configuration is defined for 18The Autobuilder effectively runs whichever configuration is defined for
19each of those targets on a seperate buildbot worker. To understand the 19each of those targets on a seperate buildbot worker. To understand the
20configuration, you need to look at the entry on ``config.json`` file 20configuration, you need to look at the entry on ``config.json`` file
21within the ``yocto-autobuilder-helper`` repository. The targets are 21within the ``yocto-autobuilder-helper`` repository. The targets are
22defined in the ‘overrides section, a quick example could be qemux86-64 22defined in the ‘overrides' section, a quick example could be qemux86-64
23which looks like:: 23which looks like::
24 24
25 "qemux86-64" : { 25 "qemux86-64" : {
@@ -32,8 +32,8 @@ which looks like::
32 } 32 }
33 }, 33 },
34 34
35And to expand that, you need the arch-qemu entry from 35And to expand that, you need the "arch-qemu" entry from
36the templates section, which looks like:: 36the "templates" section, which looks like::
37 37
38 "arch-qemu" : { 38 "arch-qemu" : {
39 "BUILDINFO" : true, 39 "BUILDINFO" : true,
@@ -54,9 +54,9 @@ the “templates” section, which looks like::
54 } 54 }
55 }, 55 },
56 56
57Combining these two entries you can see that qemux86-64 is a three step build where the 57Combining these two entries you can see that "qemux86-64" is a three step build where the
58``bitbake BBTARGETS`` would be run, then ``bitbake SANITYTARGETS`` for each step; all for 58``bitbake BBTARGETS`` would be run, then ``bitbake SANITYTARGETS`` for each step; all for
59``MACHINE=qemx86-64`` but with differing SDKMACHINE settings. In step 59``MACHINE="qemx86-64"`` but with differing SDKMACHINE settings. In step
601 an extra variable is added to the ``auto.conf`` file to enable wic 601 an extra variable is added to the ``auto.conf`` file to enable wic
61image generation. 61image generation.
62 62
@@ -262,7 +262,7 @@ of post-build steps, including:
262 262
263#. Cleanup the build directory using 263#. Cleanup the build directory using
264 :ref:`test-manual/test-manual-understand-autobuilder:clobberdir` if the build was successful, 264 :ref:`test-manual/test-manual-understand-autobuilder:clobberdir` if the build was successful,
265 else rename it to build-renamed for potential future debugging. 265 else rename it to "build-renamed" for potential future debugging.
266 266
267.. _test-deploying-yp-autobuilder: 267.. _test-deploying-yp-autobuilder:
268 268
diff --git a/documentation/test-manual/test-manual-understand-autobuilder.xml b/documentation/test-manual/test-manual-understand-autobuilder.xml
index a04006605f..8600367be7 100644
--- a/documentation/test-manual/test-manual-understand-autobuilder.xml
+++ b/documentation/test-manual/test-manual-understand-autobuilder.xml
@@ -8,18 +8,18 @@
8<title>Understanding the Yocto Project Autobuilder</title> 8<title>Understanding the Yocto Project Autobuilder</title>
9 <section> 9 <section>
10 <title>Execution Flow within the Autobuilder</title> 10 <title>Execution Flow within the Autobuilder</title>
11 <para>The a-full and a-quick targets are the usual entry points into the Autobuilder and 11 <para>The "a-full" and "a-quick" targets are the usual entry points into the Autobuilder and
12 it makes sense to follow the process through the system starting there. This is best 12 it makes sense to follow the process through the system starting there. This is best
13 visualised from the Autobuilder Console view (<link linkend="" 13 visualised from the Autobuilder Console view (<link linkend=""
14 >https://autobuilder.yoctoproject.org/typhoon/#/console</link>). </para> 14 >https://autobuilder.yoctoproject.org/typhoon/#/console</link>). </para>
15 <para>Each item along the top of that view represents some target build and these targets 15 <para>Each item along the top of that view represents some "target build" and these targets
16 are all run in parallel. The full build will trigger the majority of them, the quick 16 are all run in parallel. The 'full' build will trigger the majority of them, the "quick"
17 build will trigger some subset of them. The Autobuilder effectively runs whichever 17 build will trigger some subset of them. The Autobuilder effectively runs whichever
18 configuration is defined for each of those targets on a seperate buildbot worker. To 18 configuration is defined for each of those targets on a seperate buildbot worker. To
19 understand the configuration, you need to look at the entry on 19 understand the configuration, you need to look at the entry on
20 <filename>config.json</filename> file within the 20 <filename>config.json</filename> file within the
21 <filename>yocto-autobuilder-helper</filename> repository. The targets are defined in 21 <filename>yocto-autobuilder-helper</filename> repository. The targets are defined in
22 the ‘overrides section, a quick example could be qemux86-64 which looks 22 the ‘overrides' section, a quick example could be qemux86-64 which looks
23 like:<literallayout class="monospaced"> 23 like:<literallayout class="monospaced">
24 "qemux86-64" : { 24 "qemux86-64" : {
25 "MACHINE" : "qemux86-64", 25 "MACHINE" : "qemux86-64",
@@ -31,7 +31,7 @@
31 } 31 }
32 }, 32 },
33 </literallayout>And 33 </literallayout>And
34 to expand that, you need the arch-qemu entry from the templates section, which looks 34 to expand that, you need the "arch-qemu" entry from the "templates" section, which looks
35 like:<literallayout class="monospaced"> 35 like:<literallayout class="monospaced">
36 "arch-qemu" : { 36 "arch-qemu" : {
37 "BUILDINFO" : true, 37 "BUILDINFO" : true,
@@ -52,10 +52,10 @@
52 } 52 }
53 }, 53 },
54 </literallayout>Combining 54 </literallayout>Combining
55 these two entries you can see that qemux86-64 is a three step build where the 55 these two entries you can see that "qemux86-64" is a three step build where the
56 <filename>bitbake BBTARGETS</filename> would be run, then <filename>bitbake 56 <filename>bitbake BBTARGETS</filename> would be run, then <filename>bitbake
57 SANITYTARGETS</filename> for each step; all for 57 SANITYTARGETS</filename> for each step; all for
58 <filename>MACHINE=qemx86-64</filename> but with differing SDKMACHINE settings. In 58 <filename>MACHINE="qemx86-64"</filename> but with differing SDKMACHINE settings. In
59 step 1 an extra variable is added to the <filename>auto.conf</filename> file to enable 59 step 1 an extra variable is added to the <filename>auto.conf</filename> file to enable
60 wic image generation.</para> 60 wic image generation.</para>
61 <para>While not every detail of this is covered here, you can see how the templating 61 <para>While not every detail of this is covered here, you can see how the templating
@@ -260,7 +260,7 @@
260 <listitem> 260 <listitem>
261 <para dir="ltr">Cleanup the build directory using <link 261 <para dir="ltr">Cleanup the build directory using <link
262 linkend="test-clobberdir"><filename>clobberdir</filename></link> if the 262 linkend="test-clobberdir"><filename>clobberdir</filename></link> if the
263 build was successful, else rename it to build-renamed for potential future 263 build was successful, else rename it to "build-renamed" for potential future
264 debugging.</para> 264 debugging.</para>
265 </listitem> 265 </listitem>
266 </orderedlist></para> 266 </orderedlist></para>
diff --git a/documentation/toaster-manual/toaster-manual-setup-and-use.rst b/documentation/toaster-manual/toaster-manual-setup-and-use.rst
index 42d868bbe0..01c0dce41f 100644
--- a/documentation/toaster-manual/toaster-manual-setup-and-use.rst
+++ b/documentation/toaster-manual/toaster-manual-setup-and-use.rst
@@ -52,15 +52,15 @@ Setting Up Toaster Without a Web Server
52You can start a Toaster environment without starting its web server. 52You can start a Toaster environment without starting its web server.
53This is useful for the following: 53This is useful for the following:
54 54
55- Capturing a command-line builds statistics into the Toaster database 55- Capturing a command-line build's statistics into the Toaster database
56 for examination later. 56 for examination later.
57 57
58- Capturing a command-line builds statistics when the Toaster server 58- Capturing a command-line build's statistics when the Toaster server
59 is already running. 59 is already running.
60 60
61- Having one instance of the Toaster web server track and capture 61- Having one instance of the Toaster web server track and capture
62 multiple command-line builds, where each build is started in its own 62 multiple command-line builds, where each build is started in its own
63 noweb Toaster environment. 63 "noweb" Toaster environment.
64 64
65The following commands show how to start a Toaster environment without 65The following commands show how to start a Toaster environment without
66starting its web server, perform BitBake operations, and then shut down 66starting 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
68Toaster environment. Before closing the environment, however, you should 68Toaster environment. Before closing the environment, however, you should
69allow a few minutes to ensure the complete transfer of its BitBake build 69allow a few minutes to ensure the complete transfer of its BitBake build
70statistics to the Toaster database. If you have a separate Toaster web 70statistics to the Toaster database. If you have a separate Toaster web
71server instance running, you can watch this command-line builds 71server instance running, you can watch this command-line build's
72progress and examine the results as soon as they are posted:: 72progress and examine the results as soon as they are posted::
73 73
74 $ source toaster start noweb 74 $ source toaster start noweb
@@ -78,7 +78,7 @@ progress and examine the results as soon as they are posted::
78Setting Up Toaster Without a Build Server 78Setting Up Toaster Without a Build Server
79========================================= 79=========================================
80 80
81You can start a Toaster environment with the New Projects feature 81You can start a Toaster environment with the "New Projects" feature
82disabled. Doing so is useful for the following: 82disabled. Doing so is useful for the following:
83 83
84- Sharing your build results over the web server while blocking others 84- Sharing your build results over the web server while blocking others
@@ -345,7 +345,7 @@ Perform the following steps to install Toaster:
345 directory to be served up by the Apache web server as defined by 345 directory to be served up by the Apache web server as defined by
346 ``STATIC_ROOT``. 346 ``STATIC_ROOT``.
347 347
348#. Test and/or use the Mysql integration with Toasters Django web 348#. Test and/or use the Mysql integration with Toaster's Django web
349 server. At this point, you can start up the normal Toaster Django 349 server. At this point, you can start up the normal Toaster Django
350 web server with the Toaster database in Mysql. You can use this web 350 web server with the Toaster database in Mysql. You can use this web
351 server to confirm that the database migration and data population 351 server to confirm that the database migration and data population
diff --git a/documentation/toaster-manual/toaster-manual-setup-and-use.xml b/documentation/toaster-manual/toaster-manual-setup-and-use.xml
index d810b9d57c..f555745923 100644
--- a/documentation/toaster-manual/toaster-manual-setup-and-use.xml
+++ b/documentation/toaster-manual/toaster-manual-setup-and-use.xml
@@ -70,17 +70,17 @@
70 web server. This is useful for the following: 70 web server. This is useful for the following:
71 <itemizedlist> 71 <itemizedlist>
72 <listitem><para> 72 <listitem><para>
73 Capturing a command-line builds statistics into 73 Capturing a command-line build's statistics into
74 the Toaster database for examination later. 74 the Toaster database for examination later.
75 </para></listitem> 75 </para></listitem>
76 <listitem><para> 76 <listitem><para>
77 Capturing a command-line builds statistics when 77 Capturing a command-line build's statistics when
78 the Toaster server is already running. 78 the Toaster server is already running.
79 </para></listitem> 79 </para></listitem>
80 <listitem><para> 80 <listitem><para>
81 Having one instance of the Toaster web server 81 Having one instance of the Toaster web server
82 track and capture multiple command-line builds, 82 track and capture multiple command-line builds,
83 where each build is started in its own noweb 83 where each build is started in its own "noweb"
84 Toaster environment. 84 Toaster environment.
85 </para></listitem> 85 </para></listitem>
86 </itemizedlist> 86 </itemizedlist>
@@ -92,7 +92,7 @@
92 minutes to ensure the complete transfer of its BitBake build 92 minutes to ensure the complete transfer of its BitBake build
93 statistics to the Toaster database. 93 statistics to the Toaster database.
94 If you have a separate Toaster web server instance running, you 94 If you have a separate Toaster web server instance running, you
95 can watch this command-line builds progress and examine the 95 can watch this command-line build's progress and examine the
96 results as soon as they are posted: 96 results as soon as they are posted:
97 <literallayout class='monospaced'> 97 <literallayout class='monospaced'>
98 $ source toaster start noweb 98 $ source toaster start noweb
@@ -107,7 +107,7 @@
107 107
108 <para> 108 <para>
109 You can start a Toaster environment with the 109 You can start a Toaster environment with the
110 New Projects feature disabled. 110 "New Projects" feature disabled.
111 Doing so is useful for the following: 111 Doing so is useful for the following:
112 <itemizedlist> 112 <itemizedlist>
113 <listitem><para> 113 <listitem><para>
@@ -470,7 +470,7 @@
470 <filename>STATIC_ROOT</filename>. 470 <filename>STATIC_ROOT</filename>.
471 </para></listitem> 471 </para></listitem>
472 <listitem><para> 472 <listitem><para>
473 Test and/or use the Mysql integration with Toasters 473 Test and/or use the Mysql integration with Toaster's
474 Django web server. 474 Django web server.
475 At this point, you can start up the normal Toaster 475 At this point, you can start up the normal Toaster
476 Django web server with the Toaster database in Mysql. 476 Django web server with the Toaster database in Mysql.
diff --git a/documentation/transitioning-to-a-custom-environment.rst b/documentation/transitioning-to-a-custom-environment.rst
index 6f75aa746e..43a646d87e 100644
--- a/documentation/transitioning-to-a-custom-environment.rst
+++ b/documentation/transitioning-to-a-custom-environment.rst
@@ -10,9 +10,9 @@ Transitioning to a custom environment for systems development
10 10
11 So you've finished the :doc:`brief-yoctoprojectqs/brief-yoctoprojectqs` and 11 So you've finished the :doc:`brief-yoctoprojectqs/brief-yoctoprojectqs` and
12 glanced over the document :doc:`what-i-wish-id-known`, the latter contains 12 glanced over the document :doc:`what-i-wish-id-known`, the latter contains
13 important information learned from other users. Youre well prepared. But 13 important information learned from other users. You're well prepared. But
14 now, as you are starting your own project, isnt exactly straightforward what 14 now, as you are starting your own project, isn't exactly straightforward what
15 to do. And, the documentation is daunting. Weve put together a few hints to 15 to do. And, the documentation is daunting. We've put together a few hints to
16 get you started. 16 get you started.
17 17
18#. **Make a list of the processor, target board, technologies, and capabilities 18#. **Make a list of the processor, target board, technologies, and capabilities
@@ -21,7 +21,7 @@ Transitioning to a custom environment for systems development
21 things, and adding them to your configuration. (See #3) 21 things, and adding them to your configuration. (See #3)
22 22
23#. **Set up your board support**. 23#. **Set up your board support**.
24 Even if youre using custom hardware, it might be easier to start with an 24 Even if you're using custom hardware, it might be easier to start with an
25 existing target board that uses the same processor or at least the same 25 existing target board that uses the same processor or at least the same
26 architecture as your custom hardware. Knowing the board already has a 26 architecture as your custom hardware. Knowing the board already has a
27 functioning Board Support Package (BSP) within the project makes it easier 27 functioning Board Support Package (BSP) within the project makes it easier
@@ -36,7 +36,7 @@ Transitioning to a custom environment for systems development
36 vendor – they can point you to their most qualified efforts. In general, for 36 vendor – they can point you to their most qualified efforts. In general, for
37 Intel silicon use meta-intel, for Texas Instruments use meta-ti, and so 37 Intel silicon use meta-intel, for Texas Instruments use meta-ti, and so
38 forth. Choose a BSP that has been tested with the same Yocto Project release 38 forth. Choose a BSP that has been tested with the same Yocto Project release
39 that youve downloaded. Be aware that some BSPs may not be immediately 39 that you've downloaded. Be aware that some BSPs may not be immediately
40 supported on the very latest release, but they will be eventually. 40 supported on the very latest release, but they will be eventually.
41 41
42 You might want to start with the build specification that Poky provides 42 You might want to start with the build specification that Poky provides
@@ -46,7 +46,7 @@ Transitioning to a custom environment for systems development
46 46
47#. **Based on the layers you've chosen, make needed changes in your 47#. **Based on the layers you've chosen, make needed changes in your
48 configuration**. 48 configuration**.
49 For instance, youve chosen a machine type and added in the corresponding BSP 49 For instance, you've chosen a machine type and added in the corresponding BSP
50 layer. You'll then need to change the value of the MACHINE variable in your 50 layer. You'll then need to change the value of the MACHINE variable in your
51 configuration file (build/local.conf) to point to that same machine 51 configuration file (build/local.conf) to point to that same machine
52 type. There could be other layer-specific settings you need to change as 52 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
82 Recipe <dev-manual/dev-manual-common-tasks:writing a new recipe>` in the 82 Recipe <dev-manual/dev-manual-common-tasks:writing a new recipe>` in the
83 Yocto Project Development Tasks Manual for more information. 83 Yocto Project Development Tasks Manual for more information.
84 84
85#. **Now youre ready to create an image recipe**. 85#. **Now you're ready to create an image recipe**.
86 There are a number of ways to do this. However, it is strongly recommended 86 There are a number of ways to do this. However, it is strongly recommended
87 that you have your own image recipe - dont try appending to existing image 87 that you have your own image recipe - don't try appending to existing image
88 recipes. Recipes for images are trivial to create and you usually want to 88 recipes. Recipes for images are trivial to create and you usually want to
89 fully customize their contents. 89 fully customize their contents.
90 90
91#. **Build your image and refine it**. 91#. **Build your image and refine it**.
92 Add whats missing and fix anything that's broken using your knowledge of the 92 Add what's missing and fix anything that's broken using your knowledge of the
93 :ref:`workflow <sdk-manual/sdk-extensible:using \`\`devtool\`\` in your sdk 93 :ref:`workflow <sdk-manual/sdk-extensible:using \`\`devtool\`\` in your sdk
94 workflow>` to identify where issues might be occurring. 94 workflow>` to identify where issues might be occurring.
95 95
diff --git a/documentation/what-i-wish-id-known.rst b/documentation/what-i-wish-id-known.rst
index cf378747c6..67bf84e07f 100644
--- a/documentation/what-i-wish-id-known.rst
+++ b/documentation/what-i-wish-id-known.rst
@@ -8,7 +8,7 @@ What I wish I'd known about Yocto Project
8 8
9.. note:: 9.. note::
10 10
11 Before reading further, make sure youve taken a look at the 11 Before reading further, make sure you've taken a look at the
12 :yocto_home:`Software Overview</software-overview>` page which presents the 12 :yocto_home:`Software Overview</software-overview>` page which presents the
13 definitions for many of the terms referenced here. Also, know that some of the 13 definitions for many of the terms referenced here. Also, know that some of the
14 information here won't make sense now, but as you start developing, it is the 14 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
16 working with Yocto Project and they are updated regularly. 16 working with Yocto Project and they are updated regularly.
17 17
18Using the Yocto Project is fairly easy, *until something goes wrong*. Without an 18Using the Yocto Project is fairly easy, *until something goes wrong*. Without an
19understanding of how the build process works, youll find yourself trying to 19understanding of how the build process works, you'll find yourself trying to
20troubleshoot a black box. Here are a few items that new users wished they had 20troubleshoot "a black box". Here are a few items that new users wished they had
21known before embarking on their first build with Yocto Project. Feel free to 21known before embarking on their first build with Yocto Project. Feel free to
22contact us with other suggestions. 22contact us with other suggestions.
23 23
@@ -34,7 +34,7 @@ contact us with other suggestions.
34 </software-over/layer/>`. Generally check the Compatible layer index first, 34 </software-over/layer/>`. Generally check the Compatible layer index first,
35 and if you don't find the necessary layer check the general layer index. The 35 and if you don't find the necessary layer check the general layer index. The
36 layer index is an original artifact from the Open Embedded Project. As such, 36 layer index is an original artifact from the Open Embedded Project. As such,
37 that index doesnt have the curating and testing that the Yocto Project 37 that index doesn't have the curating and testing that the Yocto Project
38 provides on Yocto Project Compatible layer list, but the latter has fewer 38 provides on Yocto Project Compatible layer list, but the latter has fewer
39 entries. Know that when you start searching in the layer index that not all 39 entries. Know that when you start searching in the layer index that not all
40 layers have the same level of maturity, validation, or usability. Nor do 40 layers have the same level of maturity, validation, or usability. Nor do
@@ -110,7 +110,7 @@ contact us with other suggestions.
110 :ref:`bitbake-user-manual/bitbake-user-manual-intro:generating dependency 110 :ref:`bitbake-user-manual/bitbake-user-manual-intro:generating dependency
111 graphs` section in the BitBake User Manual. 111 graphs` section in the BitBake User Manual.
112 112
113#. **Heres how you decode magic folder names in tmp/work:** 113#. **Here's how you decode "magic" folder names in tmp/work:**
114 The build system fetches, unpacks, preprocesses, and builds. If something 114 The build system fetches, unpacks, preprocesses, and builds. If something
115 goes wrong, the build system reports to you directly the path to a folder 115 goes wrong, the build system reports to you directly the path to a folder
116 where the temporary (build/tmp) files and packages reside resulting from the 116 where the temporary (build/tmp) files and packages reside resulting from the
@@ -128,8 +128,8 @@ contact us with other suggestions.
128 Yocto Project, the instructions found in the 128 Yocto Project, the instructions found in the
129 :doc:`brief-yoctoprojectqs/brief-yoctoprojectqs` show how to create an image 129 :doc:`brief-yoctoprojectqs/brief-yoctoprojectqs` show how to create an image
130 and then run or flash that image. However, you can actually build just a 130 and then run or flash that image. However, you can actually build just a
131 single recipe. Thus, if some dependency or recipe isnt working, you can just 131 single recipe. Thus, if some dependency or recipe isn't working, you can just
132 say bitbake foo where "foo" is the name for a specific recipe. As you 132 say "bitbake foo" where "foo" is the name for a specific recipe. As you
133 become more advanced using the Yocto Project, and if builds are failing, it 133 become more advanced using the Yocto Project, and if builds are failing, it
134 can be useful to make sure the fetch itself works as desired. Here are some 134 can be useful to make sure the fetch itself works as desired. Here are some
135 valuable links: :ref:`dev-manual/dev-manual-common-tasks:Using a Development 135 valuable links: :ref:`dev-manual/dev-manual-common-tasks:Using a Development
@@ -147,11 +147,11 @@ contact us with other suggestions.
147 the recipe is building but are different parts (packages) of the build 147 the recipe is building but are different parts (packages) of the build
148 (i.e. the main package, the doc package, the debug symbols package, the 148 (i.e. the main package, the doc package, the debug symbols package, the
149 separate utilities package, and so forth). The build system splits out the 149 separate utilities package, and so forth). The build system splits out the
150 packages so that you dont need to install the packages you dont want or 150 packages so that you don't need to install the packages you don't want or
151 need, which is advantageous because you are building for small devices when 151 need, which is advantageous because you are building for small devices when
152 developing for embedded and IoT. 152 developing for embedded and IoT.
153 153
154#. **You will want to learn about and know whats packaged in rootfs.** 154#. **You will want to learn about and know what's packaged in rootfs.**
155 155
156#. **Create your own image recipe:** 156#. **Create your own image recipe:**
157 There are a number of ways to create your own image recipe. We suggest you 157 There are a number of ways to create your own image recipe. We suggest you