poky: subtree update:2dcd1f2a21..9d1b332292
Alejandro Hernandez Samaniego (2):
baremetal-helloworld: Enable RISC-V 64 port
baremetal-image: Fix post process command rootfs_update_timestamp
Alexander Kanavin (94):
python3: add markdown/smartypants/typogrify modules
gi-docgen: add a recipe and class
gdk-pixbuf/pango: replace gtk-doc with gi-docgen
vala: upgrade 0.50.4 -> 0.52.2
xkbcomp: upgrade 1.4.4 -> 1.4.5
stress-ng: upgrade 0.12.05 -> 0.12.06
xserver-xorg: upgrade 1.20.10 -> 1.20.11
xorgproto: upgrade 2020.1 -> 2021.3
dpkg: update 1.20.7.1 -> 1.20.9
puzzles: update to latest revision
cmake: update 3.19.5 -> 3.20.1
meson: update 0.57.1 -> 0.57.2
systemd: backport a patch to avoid unnecessary rsync dependency with latest meson
pulseaudio: unbreak build with latest meson
libdnf: upgrade 0.58.0 -> 0.62.0
bluez5: upgrade 5.56 -> 5.58
libxkbcommon: update 1.0.3 -> 1.2.1
libgudev: update 234 -> 236
vulkan-samples: update to latest revision
gnupg: upgrade 2.2.27 -> 2.3.1
virglrenderer: update 0.8.2 -> 0.9.1
webkitgtk: update 2.30.6 -> 2.32.0
acl: upgrade 2.2.53 -> 2.3.1
bind: upgrade 9.16.12 -> 9.16.13
bison: upgrade 3.7.5 -> 3.7.6
createrepo-c: upgrade 0.17.0 -> 0.17.2
cronie: upgrade 1.5.5 -> 1.5.7
dnf: upgrade 4.6.0 -> 4.7.0
e2fsprogs: upgrade 1.46.1 -> 1.46.2
gnu-efi: upgrade 3.0.12 -> 3.0.13
systemd-boot: backport a fix to address failures with new gnu-efi
gobject-introspection: upgrade 1.66.1 -> 1.68.0
gtk+3: upgrade 3.24.25 -> 3.24.28
harfbuzz: upgrade 2.7.4 -> 2.8.0
less: upgrade 563 -> 581
libfm: upgrade 1.3.1 -> 1.3.2
libinput: upgrade 1.16.4 -> 1.17.1
libwpe: upgrade 1.8.0 -> 1.10.0
libxres: upgrade 1.2.0 -> 1.2.1
linux-firmware: upgrade 20210208 -> 20210315
pango: upgrade 1.48.2 -> 1.48.4
piglit: upgrade to latest revision
pkgconf: upgrade 1.7.3 -> 1.7.4
python3-hypothesis: upgrade 6.2.0 -> 6.9.1
python3-importlib-metadata: upgrade 3.4.0 -> 3.10.1
python3-pytest: upgrade 6.2.2 -> 6.2.3
python3-setuptools-scm: upgrade 5.0.1 -> 6.0.1
x264: upgrade to latest revision
ptest: add a test for orphaned ptests, and restore ones found by it
swig: fix upstream version check
liberation-fonts: fix upstream version check
Revert "go: Use dl.google.com for SRC_URI"
powertop: update 2.13 -> 2.14
mesa: add lmsensors PACKAGECONFIG
ffmpeg: update 4.3.2 -> 4.4
qemu: use 4 cores in qemu guests
avahi: disable gtk bits
gdk-pixbuf: rewrite the cross-build support for tests
gnome: drop upstream even condition from a few recipes
expat: upgrade 2.2.10 -> 2.3.0
meson.bbclass: split python routines into a separate class
gstreamer1.0-plugins-base: backport a patch to fix meson 0.58 builds
meson: update 0.57.2 -> 0.58.0
qemu: backport a patch to fix meson 0.58 builds
nativesdk-meson: correctly set cpu_family
bitbake: fetch2/wget: when checking latest versions, consider all numerical directories
mklibs: remove recipes and class
local.conf: Drop support for mklibs
u-boot: upgrade 2021.01 -> 2021.04
gdk-pixbuf: update a patch status
systemd: update 247.6 -> 248.3
systemd-conf: do not version in lockstep with systemd
gnu-config: update to latest revision
mmc-utils: update to latest revision
python3-smartypants: fix upstream version check
at: upgrade 3.2.1 -> 3.2.2
gnomebase: trim the SRC_URI directory from the back
gsettings-desktop-schemas: upgrade 3.38.0 -> 40.0
igt-gpu-tools: upgrade 1.25 -> 1.26
mesa: update 21.0.3 -> 21.1.1
vulkan-samples: update to latest revision
libgpg-error: update 1.41 -> 1.42
webkitgtk: update 2.32.0 -> 2.32.1
glib-2.0: update 2.68.1 -> 2.68.2
apt: upgrade 2.2.2 -> 2.2.3
cmake: update 3.20.1 -> 3.20.2
libdnf: update 0.62.0 -> 0.63.0
harfbuzz: update 2.8.0 -> 2.8.1
curl: update 7.76.0 -> 7.76.1
systemtap: update 4.4 -> 4.5
wayland: package target binaries into -tools, not into -dev
ptest: add newly discovered missing runtime dependencies across recipes
images: remove sato/weston ptest images
images: add ptest images based on core-image-minimal
Andreas Müller (1):
gstreamer1.0-plugins-good: fix build with gcc11
Andrej Valek (1):
expat: upgrade 2.3.0 -> 2.4.1
Anuj Mittal (1):
lsb-release: fix reproducibility failure
Armin Kuster (5):
bitbake: hashserv/server.py: drop unused imports
bitbake: hashserver/client.py: drop unused imports
poky.yaml: fedora33: add missing pkgs
systemctl: Stop tracebacks use formated error messages
package_manager/rpm: decode systemctl failures
Bastian Krause (1):
ccache: version bump 4.2.1 -> 4.3
Bruce Ashfield (18):
linux-yocto/5.4: qemuppc32: reduce serial shutdown issues
kern-tools: Kconfiglib: add support for bare 'modules' keyword
lttng-modules: update devupstream to v2.13-rc
lttng-modules: update to v2.12.6
kernel-yocto: provide debug / summary information for metadata
linux-yocto/5.10: update to v5.10.35
linux-yocto/5.4: update to v5.4.117
linux-yocto/5.10: ktypes/standard: disable obsolete crypto options by default
linux-yocto/5.10: update to v5.10.36
linux-yocto/5.4: update to v5.4.118
linux-yocto/5.10: update to v5.10.37
linux-yocto/5.4: update to v5.4.119
kernel-devsrc: adjust NM and OBJTOOL variables for target
linux-yocto/5.10: update to v5.10.38
linux-yocto-dev: bump to v5.13+
linux-yocto/5.4: update to v5.4.120
linux-yocto/5.10: update to v5.10.41
linux-yocto/5.4: update to v5.4.123
Carlos Rafael Giani (1):
ffmpeg: Add libopus packageconfig
Changqing Li (2):
unfs3: correct configure option
pkgconfig: update SRC_URI
Chen Qi (3):
db: update CVE_PRODUCT
rt-tests: update SRCREV
xxhash: backport patch to fix special char problem
Daniel McGregor (3):
lib/oe/gpg_sign.py: Fix gpg verification
sstate: Ignore sstate signing key
bison: Make libtextstyle and libreadline optional
Daniel Wagenknecht (1):
kernel-dev: document KCONFIG_MODE
Douglas Royds (3):
Revert "icecc: Don't use icecc when INHIBIT_DEFAULT_DEPS is set"
icecc: Demote "could not get ICECC_CC" warning to note
icecc-create-env: Silence warning: invalid ICECC_ENV_EXEC
Drew Moseley (1):
manuals: fix a few incorrect option specifications.
Guillaume Champagne (1):
image-live.bbclass: order do_bootimg after do_rootfs
Joshua Watt (1):
zstd: Add patch to fix MinGW builds
Kai Kang (1):
grub2.inc: remove '-O2' from CFLAGS
Khem Raj (17):
swig: Upgrade to 4.0.2
python3-markdown: Upgrade to 3.3.4
ffmpeg: Fix build on mips
npth: Check for pthread_create for including lpthread
gcc: Add target gcc include search for musl config too
gcc: Extend .gccrelocprefix section support to musl configs
gcc: Refresh patch to fix patch fuzz
musl: Fix __NR_fstatat syscall name for riscv
libxfixes: Update to 6.0.0 release
xorgproto: Upgrade to 2021.4 release
glibc: Update to latest 2.33 branch
systemd: Fix 248.3 on musl
glibc: Enable memory tagging for aarch64
gcc: Update to latest on release/gcc-11 branch
apt: Add missing <array> header
ovmf: Fix VLA warnings with GCC 11
libucontext: Switch to meson build system
Martin Jansa (4):
gcc-sanitizers: Package up static hwasan files as well
webkitgtk: fix build without opengl in DISTRO_FEATURES
binutils: backport DWARF-5 support for gold
sstatesig.py: make it fatal error when sstate manifest isn't found
Michael Halstead (3):
releases: update to include 3.2.4
uninative: Upgrade to 3.2 (gcc11 support)
releases: update to include 3.3.1
Michael Opdenacker (8):
manuals: reduce verbosity with "worry about" expression
manuals: reduce verbosity related to "the following" expression
ref-manual: simplify style
kernel-dev manual: simplify style
dev-manual: simplify style
sdk-manual: simplify style and fix formating
overview-manual: simplify style and add missings references
manuals: simplify style
Mike Crowe (2):
npm.bbclass: Allow nodedir to be overridden by NPM_NODEDIR
libnotify: Make gtk+3 dependency optional
Ming Liu (4):
kernel-fitimage.bbclass: fix a wrong conditional check
initramfs-framework:rootfs: fix wrong indentions
kernel-fitimage.bbclass: drop unit addresses from bootscr sections
uboot-sign/kernel-fitimage: split generate_rsa_keys task
Nikolay Papenkov (1):
flex: correct license information
Nisha Parrakat (1):
squashfs-tools: package squashfs-fs.h
Peter Kjellerstedt (3):
libcap: Configure Make variables correctly without a horrible hack
util-linux.inc: Do not modify BPN
native.bbclass: Do not remove "-native" in the middle of recipe names
Petr Vorel (1):
ltp: Update to 20210524
Richard Purdie (92):
oeqa/qemurunner: Fix binary vs str issue
oeqa/qemurunner: Improve handling of run_serial for shutdown commands
ptest-packagelists: Add expat-ptest to fast ptests
puzzles: Upstream changed to main branch for development
grub2: Add CVE whitelist entries for issues fixed in 2.06
glibc: Document and whitelist CVE-2019-1010022-25
qemu: Exclude CVE-2017-5957 from cve-check
qemu: Exclude CVE-2007-0998 from cve-check
qemu: Exclude CVE-2018-18438 from cve-check
jquery: Exclude CVE-2007-2379 from cve-check
logrotate: Exclude CVE-2011-1548,1549,1550 from cve-check
openssh: Exclude CVE-2007-2768 from cve-check
ovmf: Improve reproducibility by enabling prefix mapping
bind: Exclude CVE-2019-6470 from cve-check
openssh: Exclude CVE-2008-3844 from cve-check
unzip: Exclude CVE-2008-0888 from cve-check
cpio: Exclude CVE-2010-4226 from cve-check
xinetd: Exclude CVE-2013-4342 from cve-check
ghostscript: Exclude CVE-2013-6629 from cve-check
bluez: Exclude CVE-2020-12352 CVE-2020-24490 from cve-check
tiff: Exclude CVE-2015-7313 from cve-check
ovmf: Disable lto to aid reproducibility
ovmf: Fix other reproducibility issues
rpm: Exclude CVE-2021-20271 from cve-check
coreutils: Exclude CVE-2016-2781 from cve-check
librsvg: Exclude CVE-2018-1000041 from cve-check
avahi: Exclude CVE-2021-26720 from cve-check
qemu: Set SMP to 4 cpus for arm/x86 only
qemuboot-x86: Switch to IvyBridge and q35 instead of pc
qemu-x86: Add commandline options to improve boot
sstate: Handle manifest 'corruption' issue
lttng-ust: Upgrade 2.12.1 -> 2.12.2
qemu: Upgrade 5.2.0 -> 6.0.0
python3-markupsafe: Upgrade 1.1.1 -> 2.0.0
python3-jinja2: Upgrade 2.11.3 -> 3.0.0
ofono: upgrade 1.31 -> 1.32
libnss-mdns: upgrade 0.14.1 -> 0.15
python3-git: upgrade 3.1.14 -> 3.1.17
bind: upgrade 9.16.13 -> 9.16.15
vala: upgrade 0.52.2 -> 0.52.3
libjpeg-turbo: upgrade 2.0.6 -> 2.1.0
btrfs-tools: upgrade 5.12 -> 5.12.1
python3-hypothesis: upgrade 6.9.1 -> 6.12.0
python3-numpy: upgrade 1.20.2 -> 1.20.3
gtk+3: upgrade 3.24.28 -> 3.24.29
sudo: upgrade 1.9.6p1 -> 1.9.7
stress-ng: upgrade 0.12.06 -> 0.12.08
less: upgrade 581 -> 586
libtirpc: upgrade 1.3.1 -> 1.3.2
libinput: upgrade 1.17.1 -> 1.17.2
zstd: upgrade 1.4.9 -> 1.5.0
hdparm: upgrade 9.61 -> 9.62
libxkbcommon: upgrade 1.2.1 -> 1.3.0
spirv-tools: upgrade 2020.7 -> 2021.1
diffoscope: upgrade 172 -> 175
mpg123: upgrade 1.26.5 -> 1.27.2
sqlite3: upgrade 3.35.3 -> 3.35.5
wayland-protocols: upgrade 1.20 -> 1.21
shaderc: upgrade 2020.5 -> 2021.0
wpebackend-fdo: upgrade 1.8.3 -> 1.8.4
libxcrypt-compat: upgrade 4.4.19 -> 4.4.20
Revert "cml1.bbclass: Return sorted list of cfg files"
bitbake: server/process: Handle error in heartbeat funciton in OOM case
glibc: Add 8GB VM usage cap for usermode test suite
cve-extra-exclusions.inc: add exclusion list for intractable CVE's
rpm: Drop CVE exclusion as database fixed to handle
cve-extra-exclusions: Fix typos
grub: Exclude CVE-2019-14865 from cve-check
cve-extra-exclusions.inc: Clean up merged CPE updates
ltp: Disable problematic tests causing autobuilder hangs
python3-setuptools: upgrade 56.0.0 -> 56.2.0
distro/maintainers: Fix up the ptest image entries
oeqa/runtime/rpm: Drop log message counting test component
linux-firmware: upgrade 20210315 -> 20210511
libxcrypt: Upgrade 4.4.20 -> 4.4.22
iproute2: upgrade 5.11.0 -> 5.12.0
libx11: upgrade 1.7.0 -> 1.7.1
python3-hypothesis: upgrade 6.12.0 -> 6.13.7
pango: upgrade 1.48.4 -> 1.48.5
python3-importlib-metadata: upgrade 4.0.1 -> 4.3.0
libmodulemd: upgrade 2.12.0 -> 2.12.1
vte: upgrade 0.64.0 -> 0.64.1
libinput: upgrade 1.17.2 -> 1.17.3
gi-docgen: upgrade 2021.5 -> 2021.6
kmod: upgrade 28 -> 29
xorgproto: upgrade 2021.4 -> 2021.4.99.1
libpcre2: upgrade 10.36 -> 10.37
libepoxy: upgrade 1.5.5 -> 1.5.8
python3-jinja2: upgrade 3.0.0 -> 3.0.1
curl: upgrade 7.76.1 -> 7.77.0
python3-setuptools: upgrade 56.2.0 -> 57.0.0
oeqa/qemurunner: Improve timeout handling
Richard Weinberger (1):
Add support for erofs filesystems
Robert Joslyn (3):
liberation-fonts: Update to 2.1.4
epiphany: Update to 40.1
btrfs-tools: Update to 5.12
Robert P. J. Day (8):
sdk-manual: couple minor fixes in using.rst
sdk-manual: various cleanups to intro.rst
ref-manual: delete references to dead LSB compliance
ref-manual: delete extraneous back quote
image.bbclass: fix comment "pacackages" -> "packages"
meta/lib/oe/rootfs.py: Fix typo "Restoreing" -> "Restoring"
bitbake.conf: alphabetize contents of ASSUME_PROVIDED
ref-manual: add links to some variables in glossary
Romain Naour (1):
dejagnu: needs expect at runtime
Ross Burton (12):
cairo: backport patch for CVE-2020-35492
libnotify: whitelist CVE-2013-7381 (specific to the NodeJS bindings)
builder: whitelist CVE-2008-4178 (a different builder)
libarchive: disable redundant libxml2 PACKAGECONFIG
meson: update patch status
cups: whitelist CVE-2021-25317
libsolv: add missing db dependency
rpm: turn Berkeley DB hard dependency into PACKAGECONFIG
python3: update status on upstreamed patch
ref-manual: Ubuntu 20.04 is also LTS
package_rpm: pass XZ_THREADS to rpm
gcc: revert libstc++-gdb.py installation changes
Samuli Piippo (3):
gcc-cross-canadian: add symlinks for ld.bfd and ld.gold
libarchive: enable zstd support
cmake-native: enabled zstd support
Stefan Ghinea (1):
boost: fix do_fetch failure
Steve Sakoman (1):
expat: set CVE_PRODUCT
Tony Tascioglu (3):
libxml2: Reformat runtest.patch
libxml2: Add bash dependency for ptests.
libxml2: Update to 2.9.12
Trevor Gamblin (2):
python3: upgrade 3.9.4 -> 3.9.5
bind: upgrade 9.16.15 -> 9.16.16
Ulrich Ölmann (1):
local.conf.sample: fix typo
Vinícius Ossanes Aquino (1):
lttng-modules: backport patches to fix build against 5.12+ kernel
Yann Dirson (1):
linux-firmware: include all relevant files in -bcm4356
hongxu (1):
gdk-pixbuf: fix nativesdk do_configure failed
wangmy (21):
python3-pygments: upgrade 2.8.1 -> 2.9.0
at-spi2-core: upgrade 2.40.0 -> 2.40.1
ell: upgrade 0.39 -> 0.40
kexec-tools: upgrade 2.0.21 -> 2.0.22
go: upgrade 1.16.3 -> 1.16.4
python3-attrs: upgrade 20.3.0 -> 21.2.0
python3-six: upgrade 1.15.0 -> 1.16.0
vulkan-samples: update to latest revision
vulkan-headers: upgrade 1.2.170.0 -> 1.2.176.0
vulkan-tools: upgrade 1.2.170.0 -> 1.2.176.0
vulkan-loader: upgrade 1.2.170.0 -> 1.2.176.0
distcc: upgrade 3.3.5 -> 3.4
libdrm: upgrade 2.4.105 -> 2.4.106
libidn2: upgrade 2.3.0 -> 2.3.1
libtasn1: upgrade 4.16.0 -> 4.17.0
python3-libarchive-c: upgrade 2.9 -> 3.0
python3-markupsafe: upgrade 2.0.0 -> 2.0.1
python3-more-itertools: upgrade 8.7.0 -> 8.8.0
python3-pytest: upgrade 6.2.3 -> 6.2.4
logrotate: upgrade 3.18.0 -> 3.18.1
stress-ng: upgrade 0.12.08 -> 0.12.09
zhengruoqin (10):
busybox: upgrade 1.33.0 -> 1.33.1
rng-tools: upgrade 6.11 -> 6.12
rpcbind: upgrade 1.2.5 -> 1.2.6
sysklogd: upgrade 2.2.2 -> 2.2.3
python3-importlib-metadata: upgrade 3.10.1 -> 4.0.1
python3-sortedcontainers: upgrade 2.3.0 -> 2.4.0
rxvt-unicode: upgrade 9.22 -> 9.26
libedit: upgrade 20210419-3.1 -> 20210522-3.1
libtest-needs-perl: upgrade 0.002006 -> 0.002009
libucontext: upgrade 0.10 -> 1.1
Change-Id: I5e5148036ac2a7918974733e5751c3392139b17e
Signed-off-by: William A. Kennington III <wak@google.com>
diff --git a/poky/documentation/README b/poky/documentation/README
index 176c6db..3ad23a9 100644
--- a/poky/documentation/README
+++ b/poky/documentation/README
@@ -32,7 +32,7 @@
Manual Organization
===================
-Folders exist for individual manuals as follows:
+Here the folders corresponding to individual manuals:
* sdk-manual - The Yocto Project Software Development Kit (SDK) Developer's Guide.
* bsp-guide - The Yocto Project Board Support Package (BSP) Developer's Guide
@@ -167,7 +167,7 @@
Section
Section
-The following headings styles are defined in Sphinx:
+Here are the heading styles defined in Sphinx:
Book => overline ===
Chapter => overline ***
diff --git a/poky/documentation/brief-yoctoprojectqs/index.rst b/poky/documentation/brief-yoctoprojectqs/index.rst
index 6a12b19..7ae4526 100644
--- a/poky/documentation/brief-yoctoprojectqs/index.rst
+++ b/poky/documentation/brief-yoctoprojectqs/index.rst
@@ -297,7 +297,7 @@
Follow these steps to add a hardware layer:
-#. **Find a Layer:** Lots of hardware layers exist. The Yocto Project
+#. **Find a Layer:** Many hardware layers are available. The Yocto Project
:yocto_git:`Source Repositories <>` has many hardware layers.
This example adds the
`meta-altera <https://github.com/kraj/meta-altera>`__ hardware layer.
@@ -318,8 +318,8 @@
Resolving deltas: 100% (13385/13385), done.
Checking connectivity... done.
- The hardware layer now exists
- with other layers inside the Poky reference repository on your build
+ The hardware layer is now available
+ next to other layers inside the Poky reference repository on your build
host as ``meta-altera`` and contains all the metadata needed to
support hardware from Altera, which is owned by Intel.
@@ -431,8 +431,8 @@
information.
- **Yocto Project Mailing Lists:** Related mailing lists provide a forum
- for discussion, patch submission and announcements. Several mailing
- lists exist and are grouped according to areas of concern. See the
+ for discussion, patch submission and announcements. There are several
+ mailing lists grouped by topic. See the
:ref:`ref-manual/resources:mailing lists`
section in the Yocto Project Reference Manual for a complete list of
Yocto Project mailing lists.
diff --git a/poky/documentation/bsp-guide/bsp.rst b/poky/documentation/bsp-guide/bsp.rst
index 0b0b52d..b46773d 100644
--- a/poky/documentation/bsp-guide/bsp.rst
+++ b/poky/documentation/bsp-guide/bsp.rst
@@ -267,7 +267,7 @@
are separate components that could be combined in certain end products.
Before looking at the recommended form for the directory structure
-inside a BSP layer, you should be aware that some requirements do exist
+inside a BSP layer, you should be aware that there are some requirements
in order for a BSP layer to be considered compliant with the Yocto
Project. For that list of requirements, see the
":ref:`bsp-guide/bsp:released bsp requirements`" section.
@@ -763,8 +763,8 @@
.. note::
- - Four hardware reference BSPs exist that are part of the Yocto
- Project release and are located in the ``poky/meta-yocto-bsp``
+ - There are four hardware reference BSPs in the Yocto
+ Project release, located in the ``poky/meta-yocto-bsp``
BSP layer:
- Texas Instruments Beaglebone (``beaglebone-yocto``)
@@ -773,8 +773,8 @@
- Two general IA platforms (``genericx86`` and ``genericx86-64``)
- - Three core Intel BSPs exist as part of the Yocto Project
- release in the ``meta-intel`` layer:
+ - There are three core Intel BSPs in the Yocto Project
+ release, in the ``meta-intel`` layer:
- ``intel-core2-32``, which is a BSP optimized for the Core2
family of CPUs as well as all CPUs prior to the Silvermont
@@ -832,10 +832,8 @@
Requirements and Recommendations for Released BSPs
==================================================
-Certain requirements exist for a released BSP to be considered compliant
-with the Yocto Project. Additionally, recommendations also exist. This
-section describes the requirements and recommendations for released
-BSPs.
+This section describes requirements and recommendations for a released
+BSP to be considered compliant with the Yocto Project.
Released BSP Requirements
-------------------------
@@ -864,7 +862,7 @@
- It is not required that specific packages or package modifications
exist in the BSP layer, beyond the requirements for general
- compliance with the Yocto Project. For example, no requirement exists
+ compliance with the Yocto Project. For example, there is no requirement
dictating that a specific kernel or kernel version be used in a given
BSP.
@@ -900,7 +898,7 @@
- *License File:* You must include a license file in the
``meta-bsp_root_name`` directory. This license covers the BSP
Metadata as a whole. You must specify which license to use since no
- default license exists when one is not specified. See the
+ default license exists. See the
:yocto_git:`COPYING.MIT </meta-raspberrypi/tree/COPYING.MIT>`
file for the Raspberry Pi BSP in the ``meta-raspberrypi`` BSP layer
as an example.
@@ -1107,7 +1105,7 @@
unsuitable functionality or quality, you can use an encumbered
version.
-A couple different methods exist within the OpenEmbedded build system to
+There are two different methods within the OpenEmbedded build system to
satisfy the licensing requirements for an encumbered BSP. The following
list describes them in order of preference:
@@ -1186,11 +1184,11 @@
- *Create a Machine Configuration File:* Create a
``conf/machine/bsp_root_name.conf`` file. See
:yocto_git:`meta-yocto-bsp/conf/machine </poky/tree/meta-yocto-bsp/conf/machine>`
- for sample ``bsp_root_name.conf`` files. Other samples such as
+ for sample ``bsp_root_name.conf`` files. There are other samples such as
:yocto_git:`meta-ti </meta-ti/tree/conf/machine>`
and
:yocto_git:`meta-freescale </meta-freescale/tree/conf/machine>`
- exist from other vendors that have more specific machine and tuning
+ from other vendors that have more specific machine and tuning
examples.
- *Create a Kernel Recipe:* Create a kernel recipe in
@@ -1241,7 +1239,7 @@
configuration file is what makes a layer a BSP layer as compared to a
general or kernel layer.
-One or more machine configuration files exist in the
+There are one or more machine configuration files in the
``bsp_layer/conf/machine/`` directory of the layer::
bsp_layer/conf/machine/machine1\.conf
@@ -1311,7 +1309,7 @@
- :term:`PREFERRED_PROVIDER_virtual/xserver <PREFERRED_PROVIDER>`:
The recipe that provides "virtual/xserver" when more than one
provider is found. In this case, the recipe that provides
- "virtual/xserver" is "xserver-xorg", which exists in
+ "virtual/xserver" is "xserver-xorg", available in
``poky/meta/recipes-graphics/xorg-xserver``.
- :term:`XSERVER`: The packages that
@@ -1326,7 +1324,7 @@
.. tip::
- Many ``MACHINE*`` variables exist that help you configure a particular piece
+ There are many ``MACHINE*`` variables that help you configure a particular piece
of hardware.
- :term:`EXTRA_IMAGEDEPENDS`:
@@ -1339,9 +1337,9 @@
- :term:`DEFAULTTUNE`: Machines
use tunings to optimize machine, CPU, and application performance.
These features, which are collectively known as "tuning features",
- exist in the :term:`OpenEmbedded-Core (OE-Core)` layer (e.g.
+ are set in the :term:`OpenEmbedded-Core (OE-Core)` layer (e.g.
``poky/meta/conf/machine/include``). In this example, the default
- tuning file is "cortexa8hf-neon".
+ tuning file is ``cortexa8hf-neon``.
.. note::
diff --git a/poky/documentation/dev-manual/common-tasks.rst b/poky/documentation/dev-manual/common-tasks.rst
index 37c7a19..1307341 100644
--- a/poky/documentation/dev-manual/common-tasks.rst
+++ b/poky/documentation/dev-manual/common-tasks.rst
@@ -346,7 +346,7 @@
of the Yocto Project for which your layer is compatible.
- *Acceptance Criteria:* Provide "Yes" or "No" answers for each of the
- items in the checklist. Space exists at the bottom of the form for
+ items in the checklist. There is space at the bottom of the form for
any explanations for items for which you answered "No".
- *Recommendations:* Provide answers for the questions regarding Linux
@@ -542,7 +542,7 @@
paths in the final list.
Also, not all append files add extra files. Many append files simply
- exist to add build options (e.g. ``systemd``). For these cases, your
+ allow to add build options (e.g. ``systemd``). For these cases, your
append file would not even use the ``FILESEXTRAPATHS`` statement.
Prioritizing Your Layer
@@ -1060,8 +1060,8 @@
Locate or Automatically Create a Base Recipe
--------------------------------------------
-You can always write a recipe from scratch. However, three choices exist
-that can help you quickly get a start on a new recipe:
+You can always write a recipe from scratch. However, there are three choices
+that can help you quickly get started with a new recipe:
- ``devtool add``: A command that assists in creating a recipe and an
environment conducive to development.
@@ -1521,8 +1521,8 @@
installed on the target in order for the software to run.
Within a recipe, you specify build-time dependencies using the
-:term:`DEPENDS` variable. Although
-nuances exist, items specified in ``DEPENDS`` should be names of other
+:term:`DEPENDS` variable. Although there are nuances,
+items specified in ``DEPENDS`` should be names of other
recipes. It is important that you specify all build-time dependencies
explicitly.
@@ -1589,7 +1589,7 @@
- *Autotools:* If your source files have a ``configure.ac`` file, then
your software is built using Autotools. If this is the case, you just
- need to worry about modifying the configuration.
+ need to modify the configuration.
When using Autotools, your recipe needs to inherit the
:ref:`autotools <ref-classes-autotools>` class
@@ -1603,7 +1603,7 @@
- *CMake:* If your source files have a ``CMakeLists.txt`` file, then
your software is built using CMake. If this is the case, you just
- need to worry about modifying the configuration.
+ need to modify the configuration.
When you use CMake, your recipe needs to inherit the
:ref:`cmake <ref-classes-cmake>` class and your
@@ -2183,8 +2183,8 @@
.. note::
- Equivalent support for pre-install, pre-uninstall, and post-uninstall
- scripts exist by way of ``pkg_preinst``, ``pkg_prerm``, and ``pkg_postrm``,
+ There is equivalent support for pre-install, pre-uninstall, and post-uninstall
+ scripts by way of ``pkg_preinst``, ``pkg_prerm``, and ``pkg_postrm``,
respectively. These scrips work in exactly the same way as does
``pkg_postinst`` with the exception that they run at different times. Also,
because of when they run, they are not applicable to being run at image
@@ -2376,7 +2376,7 @@
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sometimes, you need to add pre-compiled binaries to an image. For
-example, suppose that binaries for proprietary code exist, which are
+example, suppose that there are binaries for proprietary code,
created by a particular division of a company. Your part of the company
needs to use those binaries as part of an image that you are building
using the OpenEmbedded build system. Since you only have the binaries
@@ -2513,7 +2513,7 @@
syntax, although access to OpenEmbedded variables and internal
methods are also available.
- The following is an example function from the ``sed`` recipe::
+ Here is an example function from the ``sed`` recipe::
do_install () {
autotools_do_install
@@ -2832,7 +2832,7 @@
by layer recipes. It is recommended to keep recipes up-to-date with
upstream version releases.
-While several methods exist that allow you upgrade a recipe, you might
+While there are several methods to upgrade a recipe, you might
consider checking on the upgrade status of a recipe first. You can do so
using the ``devtool check-upgrade-status`` command. See the
":ref:`devtool-checking-on-the-upgrade-status-of-a-recipe`"
@@ -2861,8 +2861,8 @@
.. note::
- Conditions do exist when you should not use AUH to upgrade recipes
- and you should instead use either ``devtool upgrade`` or upgrade your
+ In some conditions, you should not use AUH to upgrade recipes
+ and should instead use either ``devtool upgrade`` or upgrade your
recipes manually:
- When AUH cannot complete the upgrade sequence. This situation
@@ -2922,7 +2922,7 @@
undesirably.
5. *Make Configurations in Your Local Configuration File:* Several
- settings need to exist in the ``local.conf`` file in the build
+ settings are needed in the ``local.conf`` file in the build
directory you just created for AUH. Make these following
configurations:
@@ -3131,8 +3131,8 @@
NOTE: nano: compiling from external source tree /home/scottrif/poky/build/workspace/sources/nano
NOTE: Tasks Summary: Attempted 520 tasks of which 304 didn't need to be rerun and all succeeded.
-Within the ``devtool upgrade`` workflow, opportunity
-exists to deploy and test your rebuilt software. For this example,
+Within the ``devtool upgrade`` workflow, you can
+deploy and test your rebuilt software. For this example,
however, running ``devtool finish`` cleans up the workspace once the
source in your workspace is clean. This usually means using Git to stage
and submit commits for the changes generated by the upgrade process.
@@ -3214,7 +3214,7 @@
if the recipe is to be released publicly.
5. *Check the Upstream Change Log or Release Notes:* Checking both these
- reveals if new features exist that could break
+ reveals if there are new features that could break
backwards-compatibility. If so, you need to take steps to mitigate or
eliminate that situation.
@@ -3517,7 +3517,7 @@
In the development environment, you need to build an image whenever you
change hardware support, add or change system libraries, or add or
-change services that have dependencies. Several methods exist that allow
+change services that have dependencies. There are several methods that allow
you to build an image within the Yocto Project. This section presents
the basic steps you need to build a simple image using BitBake from a
build host running Linux.
@@ -4215,7 +4215,7 @@
sysroot for each machine is generated, the software is not recompiled
and only one package feed exists.
-- *Manage Granular Level Packaging:* Sometimes cases exist where
+- *Manage Granular Level Packaging:* Sometimes there are cases where
injecting another level of package architecture beyond the three
higher levels noted earlier can be useful. For example, consider how
NXP (formerly Freescale) allows for the easy reuse of binary packages
@@ -4281,7 +4281,7 @@
code. The build process involves fetching the source files, unpacking
them, and then patching them if necessary before the build takes place.
-Situations exist where you might want to build software from source
+There are situations where you might want to build software from source
files that are external to and thus outside of the OpenEmbedded build
system. For example, suppose you have a project that includes a new BSP
with a heavily customized kernel. And, you want to minimize exposing the
@@ -4648,7 +4648,7 @@
libraries could differ in architecture, compiler options, or other
optimizations.
-Several examples exist in the ``meta-skeleton`` layer found in the
+There are several examples in the ``meta-skeleton`` layer found in the
:term:`Source Directory`:
- ``conf/multilib-example.conf`` configuration file
@@ -4661,7 +4661,7 @@
~~~~~~~~~~~~~~~~~~~~~~~~~
User-specific requirements drive the Multilib feature. Consequently,
-there is no one "out-of-the-box" configuration that likely exists to
+there is no one "out-of-the-box" configuration that would
meet your needs.
In order to enable Multilib, you first need to ensure your recipe is
@@ -4724,8 +4724,8 @@
Additional Implementation Details
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Generic implementation details as well as details that are specific to
-package management systems exist. Following are implementation details
+There are generic implementation details as well as details that are specific to
+package management systems. Following are implementation details
that exist regardless of the package management system:
- The typical convention used for the class extension code as used by
@@ -4742,8 +4742,7 @@
vendor string presently break Autoconf's ``config.sub``, and other
separators are problematic for different reasons.
-For the RPM Package Management System, the following implementation
-details exist:
+Here are the implementation details for the RPM Package Management System:
- A unique architecture is defined for the Multilib packages, along
with creating a unique deploy folder under ``tmp/deploy/rpm`` in the
@@ -4764,8 +4763,7 @@
- The build system relies on RPM to resolve the identical files in the
two (or more) Multilib packages.
-For the IPK Package Management System, the following implementation
-details exist:
+Here are the implementation details for the IPK Package Management System:
- The ``${MLPREFIX}`` is not stripped from ``${PN}`` during IPK
packaging. The naming for a normal RPM package and a Multilib IPK
@@ -4783,9 +4781,9 @@
Installing Multiple Versions of the Same Library
------------------------------------------------
-Situations can exist where you need to install and use multiple versions
-of the same library on the same system at the same time. These
-situations almost always exist when a library API changes and you have
+There are be situations where you need to install and use multiple versions
+of the same library on the same system at the same time. This
+almost always happens when a library API changes and you have
multiple pieces of software that depend on the separate versions of the
library. To accommodate these situations, you can install multiple
versions of the same library in parallel on the same system.
@@ -4850,9 +4848,9 @@
- You can create and boot ``core-image-minimal`` and
``core-image-sato`` images.
-- RPM Package Manager (RPM) support exists for x32 binaries.
+- There is RPM Package Manager (RPM) support for x32 binaries.
-- Support for large images exists.
+- There is support for large images.
To use the x32 psABI, you need to edit your ``conf/local.conf``
configuration file as follows::
@@ -4918,7 +4916,7 @@
:term:`DISTRO_FEATURES_BACKFILL_CONSIDERED`
and that "qemu-usermode" is not in
:term:`MACHINE_FEATURES_BACKFILL_CONSIDERED`.
- If either of these conditions exist, nothing will happen.
+ In either of these conditions, nothing will happen.
3. Try to build the recipe. If you encounter build errors that look like
something is unable to find ``.so`` libraries, check where these
@@ -5005,7 +5003,7 @@
Known Issues
------------
-The following know issues exist for GObject Introspection Support:
+Here are know issues in GObject Introspection Support:
- ``qemu-ppc64`` immediately crashes. Consequently, you cannot build
introspection data on that architecture.
@@ -5184,7 +5182,7 @@
$ wic help overview
-One additional level of help exists for Wic. You can get help on
+There is one additional level of help for Wic. You can get help on
individual images through the ``list`` command. You can use the ``list``
command to return the available Wic images as follows::
@@ -5872,8 +5870,8 @@
General Considerations
----------------------
-General considerations exist that help you create more secure images.
-You should consider the following suggestions to help make your device
+There are general considerations that help you create more secure images.
+You should consider the following suggestions to make your device
more secure:
- Scan additional code you are adding to the system (e.g. application
@@ -6210,8 +6208,8 @@
The following list introduces variables you can use to prevent packages
from being installed into your image. Each of these variables only works
-with IPK and RPM package types. Support for Debian packages does not
-exist. Also, you can use these variables from your ``local.conf`` file
+with IPK and RPM package types, not for Debian packages.
+Also, you can use these variables from your ``local.conf`` file
or attach them to a specific image recipe by using a recipe name
override. For more detail on the variables, see the descriptions in the
Yocto Project Reference Manual's glossary chapter.
@@ -6285,7 +6283,7 @@
applications such as RPM, APT, and OPKG, using an automated system is
much preferred over a manual system. In either system, the main
requirement is that binary package version numbering increases in a
-linear fashion and that a number of version components exist that
+linear fashion and that there is a number of version components that
support that linear progression. For information on how to ensure
package revisioning remains linear, see the
":ref:`dev-manual/common-tasks:automatically incrementing a package version number`"
@@ -6342,7 +6340,7 @@
packages and there are no guarantees about upgrade paths but images will
be consistent and correct with the latest changes.
-The simplest form for a PR Service is for it to exist for a single host
+The simplest form for a PR Service is for a single host
development system that builds the package feed (building system). For
this scenario, you can enable a local PR Service by setting
:term:`PRSERV_HOST` in your
@@ -6545,7 +6543,7 @@
"Lighttpd module for alias".
Often, packaging modules is as simple as the previous example. However,
-more advanced options exist that you can use within
+there are more advanced options that you can use within
``do_split_packages`` to modify its behavior. And, if you need to, you
can add more logic by specifying a hook function that is called for each
package. It is also perfectly acceptable to call ``do_split_packages``
@@ -7024,7 +7022,7 @@
`passphrase`.
Aside from the ``RPM_GPG_NAME`` and ``RPM_GPG_PASSPHRASE`` variables in
-the previous example, two optional variables related to signing exist:
+the previous example, two optional variables related to signing are available:
- *GPG_BIN:* Specifies a ``gpg`` binary/wrapper that is executed
when the package is signed.
@@ -7046,14 +7044,14 @@
PACKAGE_FEED_GPG_NAME = "key_name"
PACKAGE_FEED_GPG_PASSPHRASE_FILE = "path_to_file_containing_passphrase"
-For signed package feeds, the passphrase must exist in a separate file,
+For signed package feeds, the passphrase must be specified in a separate file,
which is pointed to by the ``PACKAGE_FEED_GPG_PASSPHRASE_FILE``
variable. Regarding security, keeping a plain text passphrase out of the
configuration is more secure.
Aside from the ``PACKAGE_FEED_GPG_NAME`` and
``PACKAGE_FEED_GPG_PASSPHRASE_FILE`` variables, three optional variables
-related to signed package feeds exist:
+related to signed package feeds are available:
- *GPG_BIN* Specifies a ``gpg`` binary/wrapper that is executed
when the package is signed.
@@ -7192,7 +7190,7 @@
:doc:`devtool </ref-manual/devtool-reference>` to create
recipes that produce NPM packages.
-Two workflows exist that allow you to create NPM packages using
+There are two workflows that allow you to create NPM packages using
``devtool``: the NPM registry modules method and the NPM project code
method.
@@ -7296,7 +7294,7 @@
...
LICENSE_${PN}-vary = "MIT"
-Three key points exist in the previous example:
+Here are three key points in the previous example:
- :term:`SRC_URI` uses the NPM
scheme so that the NPM fetcher is used.
@@ -7413,7 +7411,7 @@
by the literal sequence '\\n'. The separator can be redefined using the
variable flag ``separator``.
-The following is an example that adds two custom fields for ipk
+Here is an example that adds two custom fields for ipk
packages::
PACKAGE_ADD_METADATA_IPK = "Vendor: CustomIpk\nGroup:Applications/Spreadsheets"
@@ -7488,7 +7486,7 @@
===================================
By default, the Yocto Project uses SysVinit as the initialization
-manager. However, support also exists for systemd, which is a full
+manager. However, there is also support for systemd, which is a full
replacement for init with parallel starting of services, reduced shell
overhead and other features that are used by many distributions.
@@ -7794,7 +7792,7 @@
image along with the new software even if you did not want the library.
The :ref:`buildhistory <ref-classes-buildhistory>`
-class exists to help you maintain the quality of your build output. You
+class helps you maintain the quality of your build output. You
can use the class to highlight unexpected and possibly unwanted changes
in the build output. When you enable build history, it records
information about the contents of each package and image and then
@@ -7844,12 +7842,12 @@
``${``\ :term:`TOPDIR`\ ``}/buildhistory``
in the Build Directory as defined by the
:term:`BUILDHISTORY_DIR`
-variable. The following is an example abbreviated listing:
+variable. Here is an example abbreviated listing:
.. image:: figures/buildhistory.png
:align: center
-At the top level, a ``metadata-revs`` file exists that lists the
+At the top level, there is a ``metadata-revs`` file that lists the
revisions of the repositories for the enabled layers when the build was
produced. The rest of the data splits into separate ``packages``,
``images`` and ``sdk`` directories, the contents of which are described
@@ -7885,7 +7883,7 @@
the package, and ``PKGSIZE``, which is the total size of files in the
package in bytes.
-A file also exists that corresponds to the recipe from which the package
+There is also a file that corresponds to the recipe from which the package
came (e.g. ``buildhistory/packages/i586-poky-linux/busybox/latest``):
.. code-block:: none
@@ -7900,8 +7898,8 @@
busybox-staticdev busybox-dev busybox-doc busybox-locale busybox
Finally, for those recipes fetched from a version control system (e.g.,
-Git), a file exists that lists source revisions that are specified in
-the recipe and lists the actual revisions used during the build. Listed
+Git), there is a file that lists source revisions that are specified in
+the recipe and the actual revisions used during the build. Listed
and actual revisions might differ when
:term:`SRCREV` is set to
${:term:`AUTOREV`}. Here is an
@@ -8141,7 +8139,7 @@
however, that this method does show changes that are not significant
(e.g. a package's size changing by a few bytes).
-A command-line tool called ``buildhistory-diff`` does exist, though,
+There is a command-line tool called ``buildhistory-diff``, though,
that queries the Git repository and prints just the differences that
might be significant in human-readable form. Here is an example::
@@ -8315,7 +8313,7 @@
In order to run tests on hardware, you need to set ``TEST_TARGET`` to an
appropriate value. For QEMU, you do not have to change anything, the
default value is "qemu". For running tests on hardware, the following
-options exist:
+options are available:
- *"simpleremote":* Choose "simpleremote" if you are going to run tests
on a target system that is already running the image to be tested and
@@ -8639,7 +8637,7 @@
- Do not use module names that collide with existing core tests.
-- Minimally, an empty ``__init__.py`` file must exist in the runtime
+- Minimally, an empty ``__init__.py`` file must be present in the runtime
directory.
To create a new test, start by copying an existing module (e.g.
@@ -8719,7 +8717,7 @@
Instance Attributes
~~~~~~~~~~~~~~~~~~~
-A single instance attribute exists, which is ``target``. The ``target``
+There is a single instance attribute, which is ``target``. The ``target``
instance attribute is identical to the class attribute of the same name,
which is described in the previous section. This attribute exists as
both an instance and class attribute so tests can use
@@ -9348,7 +9346,7 @@
The Yocto Project provides several logging functions for producing
debugging output and reporting errors and warnings. For Python
-functions, the following logging functions exist. All of these functions
+functions, the following logging functions are available. All of these functions
log to ``${T}/log.do_``\ `task`, and can also log to standard output
(stdout) with the right settings:
@@ -9454,8 +9452,8 @@
that are run simultaneously and a situation occurs when the output or
result of one part is not ready for use with a different part of the
build that depends on that output. Parallel make races are annoying and
-can sometimes be difficult to reproduce and fix. However, some simple
-tips and tricks exist that can help you debug and fix them. This section
+can sometimes be difficult to reproduce and fix. However, there are some simple
+tips and tricks that can help you debug and fix them. This section
presents a real-world example of an error encountered on the Yocto
Project autobuilder and the process used to fix it.
@@ -9578,7 +9576,7 @@
$ make tools/snep-send.o
The ``devshell`` commands cause the failure to clearly
-be visible. In this case, a missing dependency exists for the "neard"
+be visible. In this case, there is a missing dependency for the ``neard``
Makefile target. Here is some abbreviated, sample output with the
missing dependency clearly visible at the end::
@@ -9623,9 +9621,8 @@
$ quilt refresh
Refreshed patch patches/parallelmake.patch
-Once
-the patch file exists, you need to add it back to the originating recipe
-folder. Here is an example assuming a top-level
+Once the patch file is created, you need to add it back to the originating
+recipe folder. Here is an example assuming a top-level
:term:`Source Directory` named ``poky``::
$ cp patches/parallelmake.patch poky/meta/recipes-connectivity/neard/neard
@@ -10119,7 +10116,7 @@
The Yocto Project uses a mailing list and a patch-based workflow that is
similar to the Linux kernel but contains important differences. In
-general, a mailing list exists through which you can submit patches. You
+general, there is a mailing list through which you can submit patches. You
should send patches to the appropriate mailing list so that they can be
reviewed and merged by the appropriate maintainer. The specific mailing
list you need to use depends on the location of the code you are
@@ -10796,8 +10793,8 @@
Other Variables Related to Commercial Licenses
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Other helpful variables related to commercial license handling exist and
-are defined in the
+There are other helpful variables related to commercial license handling,
+defined in the
``poky/meta/conf/distro/include/default-distrovars.inc`` file::
COMMERCIAL_AUDIO_PLUGINS ?= ""
@@ -10841,7 +10838,7 @@
With hundreds of different open source licenses that the Yocto Project
tracks, it is difficult to know the requirements of each and every
license. However, the requirements of the major FLOSS licenses can begin
-to be covered by assuming that three main areas of concern exist:
+to be covered by assuming that there are three main areas of concern:
- Source code must be provided.
@@ -11058,7 +11055,7 @@
3. Meta-spdxscanner provides several methods within the bbclass to create spdx files.
Please choose one that you want to use and enable the spdx task. You have to
add some config options in ``local.conf`` file in your :term:`Build
- Directory`. The following is an example showing how to generate spdx files
+ Directory`. Here is an example showing how to generate spdx files
during bitbake using the fossology-python.bbclass::
# Select fossology-python.bbclass.
@@ -11088,7 +11085,7 @@
variable. Using this variable also avoids QA errors when you use a
non-common, non-CLOSED license in a recipe.
-The following is an example that uses the ``LICENSE.Abilis.txt`` file as
+Here is an example that uses the ``LICENSE.Abilis.txt`` file as
the license from the fetched source::
NO_GENERIC_LICENSE[Firmware-Abilis] = "LICENSE.Abilis.txt"
@@ -11105,9 +11102,9 @@
The server receives the information collected and saves it in a
database.
-A live instance of the error reporting server exists at
-https://errors.yoctoproject.org. This server exists so that when
-you want to get help with build failures, you can submit all of the
+There is a live instance of the error reporting server at
+https://errors.yoctoproject.org.
+When you want to get help with build failures, you can submit all of the
information on the failure easily and then point to the URL in your bug
report or send an email to the mailing list.
diff --git a/poky/documentation/dev-manual/qemu.rst b/poky/documentation/dev-manual/qemu.rst
index 2b6d3d7..88a63c1 100644
--- a/poky/documentation/dev-manual/qemu.rst
+++ b/poky/documentation/dev-manual/qemu.rst
@@ -219,15 +219,15 @@
Should you need to start, stop, or restart the NFS share, you can use
the following commands:
- - The following command starts the NFS share::
+ - To start the NFS share::
runqemu-export-rootfs start file-system-location
- - The following command stops the NFS share::
+ - To stop the NFS share::
runqemu-export-rootfs stop file-system-location
- - The following command restarts the NFS share::
+ - To restart the NFS share::
runqemu-export-rootfs restart file-system-location
@@ -275,7 +275,7 @@
.. note::
- Several mechanisms exist that let you connect to the system running
+ There are several mechanisms to connect to the system running
on the QEMU emulator:
- QEMU provides a framebuffer interface that makes standard consoles
@@ -286,7 +286,7 @@
that port to run a console. The connection uses standard IP
networking.
- - SSH servers exist in some QEMU images. The ``core-image-sato``
+ - SSH servers are available in some QEMU images. The ``core-image-sato``
QEMU image has a Dropbear secure shell (SSH) server that runs with
the root password disabled. The ``core-image-full-cmdline`` and
``core-image-lsb`` QEMU images have OpenSSH instead of Dropbear.
diff --git a/poky/documentation/dev-manual/start.rst b/poky/documentation/dev-manual/start.rst
index 18fd8cc..c3276c9 100644
--- a/poky/documentation/dev-manual/start.rst
+++ b/poky/documentation/dev-manual/start.rst
@@ -36,7 +36,7 @@
equipment together and set up your development environment's
hardware topology.
- The following roles exist:
+ Here are possible roles:
- *Application Developer:* This type of developer does application
level work on top of an existing software stack.
@@ -99,8 +99,7 @@
.. note::
The setup of these services is beyond the scope of this manual.
- However, sites such as the following exist that describe how to
- perform setup:
+ However, here are sites describing how to perform setup:
- `Gitolite <https://gitolite.com>`__: Information for
``gitolite``.
@@ -190,7 +189,7 @@
develop locally using their primary development system.
9. *Document Policies and Change Flow:* The Yocto Project uses a
- hierarchical structure and a pull model. Scripts exist to create and
+ hierarchical structure and a pull model. There are scripts to create and
send pull requests (i.e. ``create-pull-request`` and
``send-pull-request``). This model is in line with other open source
projects where maintainers are responsible for specific areas of the
@@ -215,8 +214,8 @@
someone else in the community needs them also.
10. *Development Environment Summary:* Aside from the previous steps,
- some best practices exist within the Yocto Project development
- environment. Consider the following:
+ here are best practices within the Yocto Project development
+ environment:
- Use :ref:`overview-manual/development-environment:git` as the source control
system.
@@ -607,8 +606,8 @@
The recommended method for accessing Yocto Project components is to
use Git to clone the upstream repository and work from within that
- locally cloned repository. The procedure in this section exists
- should you desire a tarball snapshot of any given component.
+ locally cloned repository. However, this section documents how to
+ use a tarball snapshot of any given component.
Follow these steps to locate and download a particular tarball:
@@ -645,13 +644,6 @@
tarballs similar to the tarballs located in the Index of Releases
described in the ":ref:`dev-manual/start:accessing index of releases`" section.
-.. note::
-
- The recommended method for accessing Yocto Project components is to
- use Git to clone a repository and work from within that local
- repository. The procedure in this section exists should you desire a
- tarball snapshot of any given component.
-
1. *Go to the Yocto Project Website:* Open The
:yocto_home:`Yocto Project Website <>` in your browser.
@@ -750,8 +742,8 @@
":ref:`dev-manual/start:checking out by tag in poky`" sections, respectively.
Once the local repository is created, you can change to that
- directory and check its status. Here, the single "master" branch
- exists on your system and by default, it is checked out::
+ directory and check its status. The ``master`` branch is checked out
+ by default::
$ cd poky
$ git status
diff --git a/poky/documentation/kernel-dev/advanced.rst b/poky/documentation/kernel-dev/advanced.rst
index b0d0385..0e745c3 100644
--- a/poky/documentation/kernel-dev/advanced.rst
+++ b/poky/documentation/kernel-dev/advanced.rst
@@ -21,7 +21,7 @@
grouped under the "Yocto Linux Kernel" heading in the
:yocto_git:`Yocto Project Source Repositories <>`.
-Kernel development tools ("kern-tools") exist also in the Yocto Project
+Kernel development tools ("kern-tools") are also available in the Yocto Project
Source Repositories under the "Yocto Linux Kernel" heading in the
``yocto-kernel-tools`` Git repository. The recipe that builds these
tools is ``meta/recipes-kernel/kern-tools/kern-tools-native_git.bb`` in
@@ -313,7 +313,7 @@
The description file can
include multiple patch statements where each statement handles a single
-patch. In the example ``build.scc`` file, five patch statements exist
+patch. In the example ``build.scc`` file, there are five patch statements
for the five patches in the directory.
You can create a typical ``.patch`` file using ``diff -Nurp`` or
@@ -509,8 +509,8 @@
example supports the "beaglebone" machine for the "standard" kernel and
the "arm" architecture.
-Be aware that a hard link between the ``KTYPE`` variable and a kernel
-type description file does not exist. Thus, if you do not have the
+Be aware that there is no hard link between the ``KTYPE`` variable and a kernel
+type description file. Thus, if you do not have the
kernel type defined in your kernel Metadata as it is here, you only need
to ensure that the
:term:`LINUX_KERNEL_TYPE`
@@ -776,8 +776,8 @@
lone "master" branch). It is situations like these that give rise to
multiple branches used within a Linux kernel sources Git repository.
-Repository organization strategies exist that maximize source reuse,
-remove redundancy, and logically order your changes. This section
+Here are repository organization strategies maximizing source reuse,
+removing redundancy, and logically ordering your changes. This section
presents strategies for the following cases:
- Encapsulating patches in a feature description and only including the
diff --git a/poky/documentation/kernel-dev/common.rst b/poky/documentation/kernel-dev/common.rst
index 3f35d84..f64cbab 100644
--- a/poky/documentation/kernel-dev/common.rst
+++ b/poky/documentation/kernel-dev/common.rst
@@ -338,7 +338,7 @@
the ``yocto-4.12`` branch.
The following commands show how to create a local copy of the
- ``yocto-kernel-cache`` and be in the ``yocto-4.12`` branch::
+ ``yocto-kernel-cache`` and switch to the ``yocto-4.12`` branch::
$ cd ~
$ git clone git://git.yoctoproject.org/yocto-kernel-cache --branch yocto-4.12
@@ -491,7 +491,7 @@
meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.12.bbappend
-The following listing shows the file. Be aware that the actual commit ID
+Here are the contents of this file. Be aware that the actual commit ID
strings in this example listing might be different than the actual
strings in the file from the ``meta-yocto-bsp`` layer upstream.
::
@@ -578,7 +578,7 @@
.. note::
- Other methods exist to accomplish grouping and defining configuration
+ There are other ways of grouping and defining configuration
options. For example, if you are working with a local clone of the
kernel repository, you could checkout the kernel's ``meta`` branch,
make your changes, and then push the changes to the local bare clone
@@ -589,8 +589,8 @@
In general, however, the Yocto Project maintainers take care of
moving the ``SRC_URI``-specified configuration options to the
- kernel's ``meta`` branch. Not only is it easier for BSP developers to
- not have to worry about putting those configurations in the branch,
+ kernel's ``meta`` branch. Not only is it easier for BSP developers
+ not to have to put those configurations in the branch,
but having the maintainers do it allows them to apply 'global'
knowledge about the kinds of common configuration options multiple
BSPs in the tree are typically using. This allows for promotion of
@@ -650,6 +650,15 @@
variable (search directories) to include the ``${PN}`` directory you
created to hold the configuration changes.
+You can also use a regular ``defconfig`` file, as generated by the
+:ref:`ref-tasks-savedefconfig`
+task instead of a complete ``.config`` file. This only specifies the
+non-default configuration values. You need to additionally set
+:term:`KCONFIG_MODE`
+in the linux-yocto ``.bbappend`` file in your layer::
+
+ KCONFIG_MODE = "alldefconfig"
+
.. note::
The build system applies the configurations from the ``defconfig``
@@ -772,8 +781,8 @@
.. note::
- During the checkout operation, a bug exists that could cause
- errors such as the following to appear:
+ During the checkout operation, there is a bug that could cause
+ errors such as the following:
.. code-block:: none
@@ -1297,7 +1306,7 @@
$ bitbake linux-yocto -c kernel_configme -f
This step ensures that you create a
- ``.config`` file from a known state. Because situations exist where
+ ``.config`` file from a known state. Because there are situations where
your build state might become unknown, it is best to run this task
prior to starting ``menuconfig``.
@@ -1527,7 +1536,7 @@
============================================
If you build a kernel image and the version string has a "+" or a
-"-dirty" at the end, uncommitted modifications exist in the kernel's
+"-dirty" at the end, it means there are uncommitted modifications in the kernel's
source directory. Follow these steps to clean up the version string:
1. *Discover the Uncommitted Changes:* Go to the kernel's locally cloned
@@ -1606,7 +1615,7 @@
Running the ``make defconfig`` command results in the default
configuration for your architecture as defined by your kernel.
- However, no guarantee exists that this configuration is valid for
+ However, there is no guarantee that this configuration is valid for
your use case, or that your board will even boot. This is
particularly true for non-x86 architectures.
diff --git a/poky/documentation/kernel-dev/concepts-appx.rst b/poky/documentation/kernel-dev/concepts-appx.rst
index 63e6731..cf2e75d 100644
--- a/poky/documentation/kernel-dev/concepts-appx.rst
+++ b/poky/documentation/kernel-dev/concepts-appx.rst
@@ -213,7 +213,7 @@
transparent and are not relevant to the developer on a day-to-day basis.
From the developer's perspective, this path is the "master" branch in
Git terms. The developer does not need to be aware of the existence of
-any other branches at all. Of course, value exists in the having these
+any other branches at all. Of course, it can make sense to have these
branches in the tree, should a person decide to explore them. For
example, a comparison between two BSPs at either the commit level or at
the line-by-line code ``diff`` level is now a trivial operation.
@@ -379,8 +379,7 @@
yocto-kernel-cache/ktypes/base/hardware.kcf
yocto-kernel-cache/bsp/qemu-ppc32/hardware.kcf
-The following list
-provides explanations for the various files:
+Here are explanations for the various files:
- ``hardware.kcf``: Specifies a list of kernel Kconfig files that
contain hardware options only.
diff --git a/poky/documentation/kernel-dev/faq.rst b/poky/documentation/kernel-dev/faq.rst
index 8169511..cffd1c4 100644
--- a/poky/documentation/kernel-dev/faq.rst
+++ b/poky/documentation/kernel-dev/faq.rst
@@ -7,7 +7,7 @@
Common Questions and Solutions
==============================
-The following lists some solutions for common questions.
+Here are some solutions for common questions.
How do I use my own Linux kernel ``.config`` file?
--------------------------------------------------
diff --git a/poky/documentation/kernel-dev/intro.rst b/poky/documentation/kernel-dev/intro.rst
index 5592f74..e406f6e 100644
--- a/poky/documentation/kernel-dev/intro.rst
+++ b/poky/documentation/kernel-dev/intro.rst
@@ -66,9 +66,9 @@
development of the Yocto Project.
If, instead, you have a very specific Linux kernel source tree and are
-unable to align with one of the official Yocto Linux kernel recipes, an
-alternative exists by which you can use the Yocto Project Linux kernel
-tools with your own kernel sources.
+unable to align with one of the official Yocto Linux kernel recipes,
+you have a way to use the Yocto Project Linux kernel tools with your
+own kernel sources.
The remainder of this manual provides instructions for completing
specific Linux kernel development tasks. These instructions assume you
diff --git a/poky/documentation/kernel-dev/maint-appx.rst b/poky/documentation/kernel-dev/maint-appx.rst
index f84ab6e..3354de5 100644
--- a/poky/documentation/kernel-dev/maint-appx.rst
+++ b/poky/documentation/kernel-dev/maint-appx.rst
@@ -175,7 +175,7 @@
Once you have cloned a Yocto Linux kernel repository and the cache
repository (``yocto-kernel-cache``) onto your development system, you
can consider the compilation phase of kernel development, which is
-building a kernel image. Some prerequisites exist that are validated by
+building a kernel image. Some prerequisites are validated by
the build process before compilation starts:
- The :term:`SRC_URI` points to the
@@ -194,7 +194,7 @@
In the previous example, the "yocto-4.12" branch is checked out in
the ``yocto-kernel-cache`` repository.
-The OpenEmbedded build system makes sure these conditions exist before
+The OpenEmbedded build system makes sure these conditions are satisfied before
attempting compilation. Other means, however, do exist, such as
bootstrapping a BSP.
diff --git a/poky/documentation/overview-manual/concepts.rst b/poky/documentation/overview-manual/concepts.rst
index 2e3f1af..e5bdcda 100644
--- a/poky/documentation/overview-manual/concepts.rst
+++ b/poky/documentation/overview-manual/concepts.rst
@@ -139,7 +139,7 @@
using a different layer where that metadata might be common across
several pieces of hardware.
-Many layers exist that work in the Yocto Project development environment. The
+There are many layers working in the Yocto Project development environment. The
:yocto_home:`Yocto Project Curated Layer Index </software-overview/layers/>`
and :oe_layerindex:`OpenEmbedded Layer Index <>` both contain layers from
which you can use or leverage.
@@ -370,7 +370,7 @@
layers the build system uses to further control the build. These layers
provide Metadata for the software, machine, and policies.
-In general, three types of layer input exists. You can see them below
+In general, there are three types of layer input. You can see them below
the "User Configuration" box in the `general workflow
figure <overview-manual/concepts:openembedded build system concepts>`:
@@ -427,8 +427,8 @@
.. note::
- Layers exist in the Yocto Project Source Repositories that cannot be
- found in the OpenEmbedded Layer Index. These layers are either
+ There are layers in the Yocto Project Source Repositories that cannot be
+ found in the OpenEmbedded Layer Index. Such layers are either
deprecated or experimental in nature.
BitBake uses the ``conf/bblayers.conf`` file, which is part of the user
@@ -489,7 +489,7 @@
The remainder of the layer is dedicated to specific recipes by function:
``recipes-bsp``, ``recipes-core``, ``recipes-graphics``,
-``recipes-kernel``, and so forth. Metadata can exist for multiple
+``recipes-kernel``, and so forth. There can be metadata for multiple
formfactors, graphics support systems, and so forth.
.. note::
@@ -528,9 +528,7 @@
keep source files in a repository controlled by a Source Control Manager
(SCM) such as Git. Pulling source from a repository allows you to
control the point in the repository (the revision) from which you want
-to build software. Finally, a combination of the two might exist, which
-would give the consumer a choice when deciding where to get source
-files.
+to build software. A combination of the two is also possible.
BitBake uses the :term:`SRC_URI`
variable to point to source files regardless of their location. Each
@@ -609,7 +607,7 @@
Source Mirror(s)
~~~~~~~~~~~~~~~~
-Two kinds of mirrors exist: pre-mirrors and regular mirrors. The
+There are two kinds of mirrors: pre-mirrors and regular mirrors. The
:term:`PREMIRRORS` and
:term:`MIRRORS` variables point to
these, respectively. BitBake checks pre-mirrors before looking upstream
@@ -667,8 +665,8 @@
variables are used, respectively.
- :term:`PACKAGE_ARCH`: Defines
- architecture-specific sub-folders. For example, packages could exist
- for the i586 or qemux86 architectures.
+ architecture-specific sub-folders. For example, packages could be
+ available for the i586 or qemux86 architectures.
BitBake uses the
:ref:`do_package_write_* <ref-tasks-package_write_deb>`
@@ -681,8 +679,8 @@
":ref:`ref-tasks-package_write_tar`"
sections in the Yocto Project Reference Manual for additional
information. As an example, consider a scenario where an IPK packaging
-manager is being used and package architecture support for both i586 and
-qemux86 exist. Packages for the i586 architecture are placed in
+manager is being used and there is package architecture support for both
+i586 and qemux86. Packages for the i586 architecture are placed in
``build/tmp/deploy/ipk/i586``, while packages for the qemux86
architecture are placed in ``build/tmp/deploy/ipk/qemux86``.
@@ -698,7 +696,7 @@
.. note::
- Separate documentation exists for the BitBake tool. See the
+ Documentation for the BitBake tool is available separately. See the
BitBake User Manual
for reference material on BitBake.
@@ -783,12 +781,10 @@
.. note::
- In the previous figure, notice that two sample hierarchies exist: one
- based on package architecture (i.e.
- PACKAGE_ARCH
- ) and one based on a machine (i.e.
- MACHINE
- ). The underlying structures are identical. The differentiator being
+ In the previous figure, notice that there are two sample hierarchies:
+ one based on package architecture (i.e. :term:`PACKAGE_ARCH`)
+ and one based on a machine (i.e. :term:`MACHINE`).
+ The underlying structures are identical. The differentiator being
what the OpenEmbedded build system is using as a build target (e.g.
general architecture, a build host, an SDK, or a specific machine).
@@ -963,8 +959,7 @@
.. note::
- Support for creating feeds directly from the
- deploy/\*
+ Support for creating feeds directly from the ``deploy/*``
directories does not exist. Creating such feeds usually requires some
kind of feed maintenance mechanism that would upload the new packages
into an official package feed (e.g. the Ångström distribution). This
@@ -1156,9 +1151,9 @@
OpenEmbedded.
To determine if a task needs to be rerun, BitBake checks if a stamp file
-with a matching input checksum exists for the task. If such a stamp file
-exists, the task's output is assumed to exist and still be valid. If the
-file does not exist, the task is rerun.
+with a matching input checksum exists for the task. In this case,
+the task's output is assumed to exist and still be valid. Otherwise,
+the task is rerun.
.. note::
@@ -1234,14 +1229,14 @@
It becomes more complicated if everything can come from an sstate cache
because some objects are simply not required at all. For example, you do
-not need a compiler or native tools, such as quilt, if nothing exists to
-compile or patch. If the ``do_package_write_*`` packages are available
+not need a compiler or native tools, such as quilt, if there isn't anything
+to compile or patch. If the ``do_package_write_*`` packages are available
from sstate, BitBake does not need the ``do_package`` task data.
To handle all these complexities, BitBake runs in two phases. The first
is the "setscene" stage. During this stage, BitBake first checks the
sstate cache for any targets it is planning to build. BitBake does a
-fast check to see if the object exists rather than a complete download.
+fast check to see if the object exists rather than doing a complete download.
If nothing exists, the second phase, which is the setscene stage,
completes and the main build proceeds.
@@ -1366,9 +1361,9 @@
All the output files for an SDK are written to the ``deploy/sdk`` folder
inside the :term:`Build Directory` as
-shown in the previous figure. Depending on the type of SDK, several
-variables exist that help configure these files. The following list
-shows the variables associated with an extensible SDK:
+shown in the previous figure. Depending on the type of SDK, there are
+several variables to configure these files. Here are the variables
+associated with an extensible SDK:
- :term:`DEPLOY_DIR`: Points to
the ``deploy`` directory.
@@ -1577,8 +1572,8 @@
By design, the OpenEmbedded build system builds everything from scratch
unless :term:`BitBake` can determine
that parts do not need to be rebuilt. Fundamentally, building from
-scratch is attractive as it means all parts are built fresh and no
-possibility of stale data exists that can cause problems. When
+scratch is attractive as it means all parts are built fresh and there is
+no possibility of stale data that can cause problems. When
developers hit problems, they typically default back to building from
scratch so they have a know state from the start.
@@ -1617,7 +1612,7 @@
- The build system does not maintain
:term:`PR` information as part of
- the shared state packages. Consequently, considerations exist that
+ the shared state packages. Consequently, there are considerations that
affect maintaining shared state feeds. For information on how the
build system works with packages and can track incrementing ``PR``
information, see the ":ref:`dev-manual/common-tasks:automatically incrementing a package version number`"
@@ -1687,7 +1682,7 @@
alleviating this problem and making the "run" scripts much more readable
as a bonus.
-So far, solutions for shell scripts exist. What about Python tasks? The
+So far, there are solutions for shell scripts. What about Python tasks? The
same approach applies even though these tasks are more difficult. The
process needs to figure out what variables a Python function accesses
and what functions it calls. Again, the incremental build solution
@@ -1695,7 +1690,7 @@
dependencies, and then creates a checksum for the data used as the input
to the task.
-Like the ``WORKDIR`` case, situations exist where dependencies should be
+Like the ``WORKDIR`` case, there can be situations where dependencies should be
ignored. For these situations, you can instruct the build process to
ignore a dependency by using a line like the following::
@@ -1732,7 +1727,7 @@
checksum that combines the basehash and the hashes of the task's
dependencies.
-At the code level, a variety of ways exist by which both the basehash
+At the code level, there are multiple ways by which both the basehash
and the dependent task hashes can be influenced. Within the BitBake
configuration file, you can give BitBake some extra information to help
it construct the basehash. The following statement effectively results
@@ -1961,8 +1956,8 @@
The OpenEmbedded build system automatically adds common types of runtime
dependencies between packages, which means that you do not need to
explicitly declare the packages using
-:term:`RDEPENDS`. Three automatic
-mechanisms exist (``shlibdeps``, ``pcdeps``, and ``depchains``) that
+:term:`RDEPENDS`. There are three automatic
+mechanisms (``shlibdeps``, ``pcdeps``, and ``depchains``) that
handle shared libraries, package configuration (pkg-config) modules, and
``-dev`` and ``-dbg`` packages, respectively. For other types of runtime
dependencies, you must manually declare the dependencies.
diff --git a/poky/documentation/overview-manual/development-environment.rst b/poky/documentation/overview-manual/development-environment.rst
index 1decf01..ab155dc 100644
--- a/poky/documentation/overview-manual/development-environment.rst
+++ b/poky/documentation/overview-manual/development-environment.rst
@@ -71,7 +71,7 @@
the Yocto Project Development Tasks Manual.
If your development host is going to be a system that runs a Linux
-distribution, steps still exist that you must take to prepare the system
+distribution, you must still take steps to prepare the system
for use with the Yocto Project. You need to be sure that the Linux
distribution on the system is one that supports the Yocto Project. You
also need to be sure that the correct set of host packages are installed
@@ -80,8 +80,8 @@
":ref:`dev-manual/start:setting up a native linux host`"
section in the Yocto Project Development Tasks Manual.
-Once your development host is set up to use the Yocto Project, several
-methods exist for you to do work in the Yocto Project environment:
+Once your development host is set up to use the Yocto Project, there
+are several ways of working in the Yocto Project environment:
- *Command Lines, BitBake, and Shells:* Traditional development in the
Yocto Project involves using the :term:`OpenEmbedded Build System`,
@@ -271,7 +271,7 @@
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.
-A somewhat formal method exists by which developers commit changes and
+There is a somewhat formal method by which developers commit changes and
push them into the "contrib" area and subsequently request that the
maintainer include them into an upstream branch. This process is called
"submitting a patch" or "submitting a change." For information on
@@ -279,9 +279,9 @@
":ref:`dev-manual/common-tasks:submitting a change to the yocto project`"
section in the Yocto Project Development Tasks Manual.
-In summary, a single point of entry exists for changes into a "master"
+In summary, there is a single point of entry for changes into a "master"
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. A set of developers independently
develop, test, and submit changes to "contrib" areas for the maintainer
to examine. The maintainer then chooses which changes are going to
become a permanent part of the project.
diff --git a/poky/documentation/overview-manual/intro.rst b/poky/documentation/overview-manual/intro.rst
index a2afe77..a809177 100644
--- a/poky/documentation/overview-manual/intro.rst
+++ b/poky/documentation/overview-manual/intro.rst
@@ -12,7 +12,7 @@
best-known-methods (BKMs), and any other high-level introductory
information suitable for a new Yocto Project user.
-The following list describes what you can get from this manual:
+Here is what you can get from this manual:
- :ref:`overview-manual/yp-intro:introducing the yocto project`\ *:*
This chapter provides an introduction to the Yocto Project. You will learn
diff --git a/poky/documentation/overview-manual/yp-intro.rst b/poky/documentation/overview-manual/yp-intro.rst
index fca02e4..28ed079 100644
--- a/poky/documentation/overview-manual/yp-intro.rst
+++ b/poky/documentation/overview-manual/yp-intro.rst
@@ -38,8 +38,7 @@
Features
--------
-The following list describes features and advantages of the Yocto
-Project:
+Here are features and advantages of the Yocto Project:
- *Widely Adopted Across the Industry:* Many semiconductor, operating
system, software, and service vendors adopt and support the Yocto
@@ -137,13 +136,11 @@
Challenges
----------
-The following list presents challenges you might encounter when
-developing using the Yocto Project:
+Here are challenges you might encounter when developing using the Yocto Project:
- *Steep Learning Curve:* The Yocto Project has a steep learning curve
and has many different ways to accomplish similar tasks. It can be
- difficult to choose how to proceed when varying methods exist by
- which to accomplish a given task.
+ difficult to choose between such ways.
- *Understanding What Changes You Need to Make For Your Design Requires
Some Research:* Beyond the simple tutorial stage, understanding what
@@ -158,7 +155,7 @@
workflow <overview-manual/development-environment:the yocto project development environment>`
could be confusing if you are used to traditional desktop and server
software development.
- In a desktop development environment, mechanisms exist to easily pull
+ In a desktop development environment, there are mechanisms to easily pull
and install new packages, which are typically pre-compiled binaries
from servers accessible over the Internet. Using the Yocto Project,
you must modify your configuration and rebuild to add additional
@@ -292,8 +289,8 @@
Development Tools
-----------------
-The following list consists of tools that help you develop images and
-applications using the Yocto Project:
+Here are tools that help you develop images and applications using
+the Yocto Project:
- *CROPS:* `CROPS <https://github.com/crops/poky-container/>`__ is an
open source, cross-platform development framework that leverages
@@ -347,8 +344,8 @@
Production Tools
----------------
-The following list consists of tools that help production related
-activities using the Yocto Project:
+Here are tools that help with production related activities using the
+Yocto Project:
- *Auto Upgrade Helper:* This utility when used in conjunction with the
:term:`OpenEmbedded Build System`
@@ -432,8 +429,8 @@
require system administrator privileges. For example, file ownership
or permissions might need to be defined. Pseudo is a tool that you
can either use directly or through the environment variable
- ``LD_PRELOAD``. Either method allows these operations to succeed as
- if system administrator privileges exist even when they do not.
+ ``LD_PRELOAD``. Either method allows these operations to succeed
+ even without system administrator privileges.
Thanks to Pseudo, the Yocto Project never needs root privileges to
build images for your target system.
@@ -444,8 +441,7 @@
Open-Embedded Build System Components
-------------------------------------
-The following list consists of components associated with the
-:term:`OpenEmbedded Build System`:
+Here are components associated with the :term:`OpenEmbedded Build System`:
- *BitBake:* BitBake is a core component of the Yocto Project and is
used by the OpenEmbedded build system to build images. While BitBake
@@ -511,8 +507,7 @@
Packages for Finished Targets
-----------------------------
-The following lists components associated with packages for finished
-targets:
+Here are components associated with packages for finished targets:
- *Matchbox:* Matchbox is an Open Source, base environment for the X
Window System running on non-desktop, embedded platforms such as
@@ -583,8 +578,7 @@
This section provides an introduction to the choices or development
methods you have when setting up your Build Host. Depending on your
particular workflow preference and the type of operating system your
-Build Host runs, several choices exist that allow you to use the Yocto
-Project.
+Build Host runs, you have several choices.
.. note::
@@ -794,7 +788,7 @@
================
It helps to understand some basic fundamental terms when learning the
-Yocto Project. Although a list of terms exists in the ":doc:`Yocto Project
+Yocto Project. Although there is a list of terms in the ":doc:`Yocto Project
Terms </ref-manual/terms>`" section of the Yocto Project
Reference Manual, this section provides the definitions of some terms
helpful for getting started:
diff --git a/poky/documentation/poky.yaml b/poky/documentation/poky.yaml
index 22706a0..3bfc35b 100644
--- a/poky/documentation/poky.yaml
+++ b/poky/documentation/poky.yaml
@@ -1,12 +1,12 @@
-DISTRO : "3.3"
+DISTRO : "3.3.1"
DISTRO_NAME_NO_CAP : "hardknott"
DISTRO_NAME : "Hardknott"
DISTRO_NAME_NO_CAP_MINUS_ONE : "gatesgarth"
DISTRO_NAME_NO_CAP_LTS : "dunfell"
-YOCTO_DOC_VERSION : "3.3"
-YOCTO_DOC_VERSION_MINUS_ONE : "3.2.3"
-DISTRO_REL_TAG : "yocto-3.3"
-POKYVERSION : "25.0.0"
+YOCTO_DOC_VERSION : "3.3.1"
+YOCTO_DOC_VERSION_MINUS_ONE : "3.2.4"
+DISTRO_REL_TAG : "yocto-3.3.1"
+POKYVERSION : "25.0.1"
YOCTO_POKY : "poky-&DISTRO_NAME_NO_CAP;-&POKYVERSION;"
YOCTO_DL_URL : "https://downloads.yoctoproject.org"
YOCTO_AB_URL : "https://autobuilder.yoctoproject.org"
@@ -19,7 +19,8 @@
diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath \
ccache perl-Data-Dumper perl-Text-ParseWords perl-Thread-Queue perl-bignum socat \
python3-pexpect findutils which file cpio python python3-pip xz python3-GitPython \
- python3-jinja2 SDL-devel xterm rpcgen mesa-libGL-devel"
+ python3-jinja2 SDL-devel xterm rpcgen mesa-libGL-devel perl-FindBin perl-File-Compare \
+ perl-File-Copy perl-locale"
OPENSUSE_HOST_PACKAGES_ESSENTIAL : "python gcc gcc-c++ git chrpath make wget python-xml \
diffstat makeinfo python-curses patch socat python3 python3-curses tar python3-pip \
python3-pexpect xz which python3-Jinja2 Mesa-libEGL1 libSDL-devel xterm rpcgen Mesa-dri-devel
diff --git a/poky/documentation/ref-manual/classes.rst b/poky/documentation/ref-manual/classes.rst
index 9a1fc2c..6dd0cbb 100644
--- a/poky/documentation/ref-manual/classes.rst
+++ b/poky/documentation/ref-manual/classes.rst
@@ -1006,10 +1006,10 @@
INSANE_SKIP_${PN} += "dev-so"
Please keep in mind that the QA checks
-exist in order to detect real or potential problems in the packaged
+are meant to detect real or potential problems in the packaged
output. So exercise caution when disabling these checks.
-The following list shows the tests you can list with the ``WARN_QA`` and
+Here are the tests you can list with the ``WARN_QA`` and
``ERROR_QA`` variables:
- ``already-stripped:`` Checks that produced binaries have not
@@ -1085,8 +1085,8 @@
- ``dev-so:`` Checks that the ``.so`` symbolic links are in the
``-dev`` package and not in any of the other packages. In general,
these symlinks are only useful for development purposes. Thus, the
- ``-dev`` package is the correct location for them. Some very rare
- cases do exist for dynamically loaded modules where these symlinks
+ ``-dev`` package is the correct location for them. In very rare
+ cases, such as dynamically loaded modules, these symlinks
are needed instead in the main package.
- ``file-rdeps:`` Checks that file-level dependencies identified by
@@ -1260,8 +1260,8 @@
.. note::
- If you are not using runtime package management on your target
- system, then you do not need to worry about this situation.
+ This is only relevant when you are using runtime package management
+ on your target system.
- ``xorg-driver-abi:`` Checks that all packages containing Xorg
drivers have ABI dependencies. The ``xserver-xorg`` recipe provides
@@ -1676,7 +1676,7 @@
nativesdk-myrecipe.bb
- Not doing so can lead to subtle problems because code exists that
+ Not doing so can lead to subtle problems because there is code that
depends on the naming convention.
Although applied differently, the ``nativesdk`` class is used with both
@@ -1714,10 +1714,10 @@
``oelint.bbclass``
==================
-The ``oelint`` class is an obsolete lint checking tool that exists in
+The ``oelint`` class is an obsolete lint checking tool available in
``meta/classes`` in the :term:`Source Directory`.
-A number of classes exist that could be generally useful in OE-Core but
+There are some classes that could be generally useful in OE-Core but
are never actually used within OE-Core itself. The ``oelint`` class is
one such example. However, being aware of this class can reduce the
proliferation of different versions of similar classes across multiple
diff --git a/poky/documentation/ref-manual/devtool-reference.rst b/poky/documentation/ref-manual/devtool-reference.rst
index 0ce3219..1862c48 100644
--- a/poky/documentation/ref-manual/devtool-reference.rst
+++ b/poky/documentation/ref-manual/devtool-reference.rst
@@ -403,8 +403,8 @@
As software matures, upstream recipes are upgraded to newer versions. As
a developer, you need to keep your local recipes up-to-date with the
-upstream version releases. Several methods exist by which you can
-upgrade recipes. You can read about them in the ":ref:`dev-manual/common-tasks:upgrading recipes`"
+upstream version releases. There are several ways of upgrading recipes.
+You can read about them in the ":ref:`dev-manual/common-tasks:upgrading recipes`"
section of the Yocto Project Development Tasks Manual. This section
overviews the ``devtool upgrade`` command.
@@ -516,8 +516,8 @@
should never use it to update an image that will be used in
production.
-Some conditions exist that could prevent a deployed application from
-behaving as expected. When both of the following conditions exist, your
+Some conditions could prevent a deployed application from
+behaving as expected. When both of the following conditions are met, your
application has the potential to not behave correctly when run on the
target:
@@ -528,7 +528,7 @@
- The target does not physically have the packages on which the
application depends installed.
-If both of these conditions exist, your application will not behave as
+If both of these conditions are met, your application will not behave as
expected. The reason for this misbehavior is because the
``devtool deploy-target`` command does not deploy the packages (e.g.
libraries) on which your new application depends. The assumption is that
diff --git a/poky/documentation/ref-manual/faq.rst b/poky/documentation/ref-manual/faq.rst
index e7bca82..f1b564a 100644
--- a/poky/documentation/ref-manual/faq.rst
+++ b/poky/documentation/ref-manual/faq.rst
@@ -312,7 +312,7 @@
can use ``file://`` URLs to point to local directories or network shares
as well.
-Aside from the previous technique, these options also exist::
+Here are other options::
BB_NO_NETWORK = "1"
diff --git a/poky/documentation/ref-manual/features.rst b/poky/documentation/ref-manual/features.rst
index eb4947d..31d24b8 100644
--- a/poky/documentation/ref-manual/features.rst
+++ b/poky/documentation/ref-manual/features.rst
@@ -196,7 +196,7 @@
utilities or packages with debug information needed to investigate
application problems or profile applications.
-The following image features are available for all images:
+Here are the image features available for all images:
- *allow-empty-password:* Allows Dropbear and OpenSSH to accept root
logins and logins from accounts having an empty password string.
diff --git a/poky/documentation/ref-manual/kickstart.rst b/poky/documentation/ref-manual/kickstart.rst
index 843292b..8308fff 100644
--- a/poky/documentation/ref-manual/kickstart.rst
+++ b/poky/documentation/ref-manual/kickstart.rst
@@ -210,5 +210,5 @@
- ``--configfile``: Specifies a user-defined configuration file for
the bootloader. You can provide a full pathname for the file or a
- file that exists in the ``canned-wks`` folder. This option overrides
+ file located in the ``canned-wks`` folder. This option overrides
all other bootloader options.
diff --git a/poky/documentation/ref-manual/migration-2.2.rst b/poky/documentation/ref-manual/migration-2.2.rst
index a9d3cde..a60ce8d 100644
--- a/poky/documentation/ref-manual/migration-2.2.rst
+++ b/poky/documentation/ref-manual/migration-2.2.rst
@@ -422,7 +422,7 @@
:term:`SRCREV` by default when fetching from a Git
repository. You can override this in either case to use
``${``\ :term:`AUTOREV`\ ``}`` instead by using the
- ``-a`` or ``DASHDASHautorev`` command-line option
+ ``-a`` or ``--autorev`` command-line option
- ``distcc``: GTK+ UI is now disabled by default.
diff --git a/poky/documentation/ref-manual/qa-checks.rst b/poky/documentation/ref-manual/qa-checks.rst
index 9cc4c57..2e98713 100644
--- a/poky/documentation/ref-manual/qa-checks.rst
+++ b/poky/documentation/ref-manual/qa-checks.rst
@@ -97,7 +97,7 @@
- ``<packagename1> rdepends on <packagename2>, but it isn't a build dependency? [build-deps]``
- A runtime dependency exists between the two specified packages, but
+ There is a runtime dependency between the two specified packages, but
there is nothing explicit within the recipe to enable the
OpenEmbedded build system to ensure that dependency is satisfied.
This condition is usually triggered by an
@@ -303,7 +303,7 @@
- ``<packagename> rdepends on <debug_packagename> [debug-deps]``
- A dependency exists between the specified non-dbg package (i.e. a
+ There is a dependency between the specified non-dbg package (i.e. a
package whose name does not end in ``-dbg``) and a package that is a
``dbg`` package. The ``dbg`` packages contain debug symbols and are
brought in using several different methods:
@@ -326,7 +326,7 @@
- ``<packagename> rdepends on <dev_packagename> [dev-deps]``
- A dependency exists between the specified non-dev package (a package
+ There is a dependency between the specified non-dev package (a package
whose name does not end in ``-dev``) and a package that is a ``dev``
package. The ``dev`` packages contain development headers and are
usually brought in using several different methods:
@@ -753,6 +753,6 @@
.. note::
- Please keep in mind that the QA checks exist in order to detect real
+ Please keep in mind that the QA checks are meant to detect real
or potential problems in the packaged output. So exercise caution
when disabling these checks.
diff --git a/poky/documentation/ref-manual/release-process.rst b/poky/documentation/ref-manual/release-process.rst
index 93ab6ed..935a2e3 100644
--- a/poky/documentation/ref-manual/release-process.rst
+++ b/poky/documentation/ref-manual/release-process.rst
@@ -82,14 +82,14 @@
bug fixes and security fixes only. Policy dictates that features are
not backported to a stable release. This policy means generic recipe
version upgrades are unlikely to be accepted for backporting. The
- exception to this policy occurs when a strong reason exists such as
+ exception to this policy occurs when there is a strong reason such as
the fix happens to also be the preferred upstream approach.
Stable release branches have strong maintenance for about a year after
their initial release. Should significant issues be found for any
release regardless of its age, fixes could be backported to older
releases. For issues that are not backported given an older release,
-Community LTS trees and branches exist where community members share
+Community LTS trees and branches allow community members to share
patches for older releases. However, these types of patches do not go
through the same release process as do point releases. You can find more
information about stable branch maintenance at
diff --git a/poky/documentation/ref-manual/resources.rst b/poky/documentation/ref-manual/resources.rst
index 663f0d9..5ffd2b3 100644
--- a/poky/documentation/ref-manual/resources.rst
+++ b/poky/documentation/ref-manual/resources.rst
@@ -10,7 +10,7 @@
============
The Yocto Project team is happy for people to experiment with the Yocto
-Project. A number of places exist to find help if you run into
+Project. There is a number of places where you can find help if you run into
difficulties or find bugs. This presents information about contributing
and participating in the Yocto Project.
@@ -43,8 +43,7 @@
component of the build system that acts contrary to the documentation or
your expectations).
-A general procedure and guidelines exist for when you use Bugzilla to
-submit a bug. For information on how to use Bugzilla to submit a bug
+For a general procedure and guidelines on how to use Bugzilla to submit a bug
against the Yocto Project, see the following:
- The ":ref:`dev-manual/common-tasks:submitting a defect against the yocto project`"
@@ -59,7 +58,7 @@
Mailing lists
=============
-A number of mailing lists maintained by the Yocto Project exist as well
+There are multiple mailing lists maintained by the Yocto Project as well
as related OpenEmbedded mailing lists for discussion, patch submission
and announcements. To subscribe to one of the following mailing lists,
click on the appropriate URL in the following list and follow the
@@ -156,9 +155,8 @@
- :yocto_docs:`Yocto Project Mega-Manual </singleindex.html>`\ *:* This manual
is simply a single HTML file comprised of the bulk of the Yocto
- Project manuals. The Mega-Manual primarily exists as a vehicle by
- which you can easily search for phrases and terms used in the Yocto
- Project documentation set.
+ Project manuals. It makes it easy to search for phrases and terms used
+ in the Yocto Project documentation set.
- :doc:`/profile-manual/index` *:* This manual presents a set of
common and generally useful tracing and profiling schemes along with
diff --git a/poky/documentation/ref-manual/structure.rst b/poky/documentation/ref-manual/structure.rst
index f8dc7d2..36c9efc 100644
--- a/poky/documentation/ref-manual/structure.rst
+++ b/poky/documentation/ref-manual/structure.rst
@@ -38,7 +38,7 @@
project. BitBake, a :term:`Metadata` interpreter, reads the
Yocto Project Metadata and runs the tasks defined by that data. Failures
are usually caused by errors in your Metadata and not from BitBake
-itself; consequently, most users do not need to worry about BitBake.
+itself.
When you run the ``bitbake`` command, the main BitBake executable (which
resides in the ``bitbake/bin/`` directory) starts. Sourcing the
@@ -279,7 +279,7 @@
.. note::
You can see how the ``TEMPLATECONF`` variable is used by looking at the
- ``scripts/oe-setup-builddir``` script in the :term:`Source Directory`.
+ ``scripts/oe-setup-builddir`` script in the :term:`Source Directory`.
You can find the Yocto Project version of the ``local.conf.sample`` file in
the ``meta-poky/conf`` directory.
@@ -510,8 +510,8 @@
-----------------------
Previous versions of the OpenEmbedded build system used to create a
-global shared sysroot per machine along with a native sysroot. Beginning
-with the 2.3 version of the Yocto Project, sysroots exist in
+global shared sysroot per machine along with a native sysroot. Since
+the 2.3 version of the Yocto Project, there are sysroots in
recipe-specific :term:`WORKDIR` directories. Thus, the
``build/tmp/sysroots/`` directory is unused.
@@ -601,7 +601,7 @@
name, and the version of the recipe (i.e.
:term:`PE`\ ``:``\ :term:`PV`\ ``-``\ :term:`PR`).
-A number of key subdirectories exist within each recipe work directory:
+Here are key subdirectories within each recipe work directory:
- ``${WORKDIR}/temp``: Contains the log files of each task executed for
this recipe, the "run" files for each executed task, which contain
@@ -624,7 +624,7 @@
- ``${WORKDIR}/packages-split``: Contains the output of the
``do_package`` task after the output has been split into individual
- packages. Subdirectories exist for each individual package created by
+ packages. There are subdirectories for each individual package created by
the recipe.
- ``${WORKDIR}/recipe-sysroot``: A directory populated with the target
@@ -783,7 +783,7 @@
This directory contains non-essential applications that add features
compared to the alternatives in core. You might need this directory for
-full tool functionality or for Linux Standard Base (LSB) compliance.
+full tool functionality.
.. _structure-meta-recipes-gnome:
@@ -809,14 +809,6 @@
This directory contains the kernel and generic applications and
libraries that have strong kernel dependencies.
-.. _structure-meta-recipes-lsb4:
-
-``meta/recipes-lsb4/``
-----------------------
-
-This directory contains recipes specifically added to support the Linux
-Standard Base (LSB) version 4.x.
-
.. _structure-meta-recipes-multimedia:
``meta/recipes-multimedia/``
diff --git a/poky/documentation/ref-manual/system-requirements.rst b/poky/documentation/ref-manual/system-requirements.rst
index 4fa4d3e..e9d995c 100644
--- a/poky/documentation/ref-manual/system-requirements.rst
+++ b/poky/documentation/ref-manual/system-requirements.rst
@@ -41,7 +41,7 @@
- Ubuntu 18.04 (LTS)
-- Ubuntu 20.04
+- Ubuntu 20.04 (LTS)
- Fedora 30
@@ -66,9 +66,8 @@
- While the Yocto Project Team attempts to ensure all Yocto Project
releases are one hundred percent compatible with each officially
- supported Linux distribution, instances might exist where you
- encounter a problem while using the Yocto Project on a specific
- distribution.
+ supported Linux distribution, you may still encounter problems
+ that happen only with a specific distribution.
- Yocto Project releases are tested against the stable Linux
distributions in the above list. The Yocto Project should work
@@ -111,7 +110,7 @@
Ubuntu and Debian
-----------------
-The following list shows the required packages by function given a
+Here are the required packages by function given a
supported Ubuntu or Debian Linux distribution:
.. note::
@@ -119,8 +118,7 @@
- If your build system has the ``oss4-dev`` package installed, you
might experience QEMU build failures due to the package installing
its own custom ``/usr/include/linux/soundcard.h`` on the Debian
- system. If you run into this situation, either of the following
- solutions exist::
+ system. If you run into this situation, try either of these solutions::
$ sudo apt-get build-dep qemu
$ sudo apt-get remove oss4-dev
@@ -150,7 +148,7 @@
Fedora Packages
---------------
-The following list shows the required packages by function given a
+Here are the required packages by function given a
supported Fedora Linux distribution:
- *Essentials:* Packages needed to build an image for a headless
@@ -167,7 +165,7 @@
openSUSE Packages
-----------------
-The following list shows the required packages by function given a
+Here are the required packages by function given a
supported openSUSE Linux distribution:
- *Essentials:* Packages needed to build an image for a headless
@@ -185,7 +183,7 @@
CentOS-7 Packages
-----------------
-The following list shows the required packages by function given a
+Here are the required packages by function given a
supported CentOS-7 Linux distribution:
- *Essentials:* Packages needed to build an image for a headless
@@ -212,7 +210,7 @@
CentOS-8 Packages
-----------------
-The following list shows the required packages by function given a
+Here are the required packages by function given a
supported CentOS-8 Linux distribution:
- *Essentials:* Packages needed to build an image for a headless
diff --git a/poky/documentation/ref-manual/tasks.rst b/poky/documentation/ref-manual/tasks.rst
index 001edf6..5bceb79 100644
--- a/poky/documentation/ref-manual/tasks.rst
+++ b/poky/documentation/ref-manual/tasks.rst
@@ -823,6 +823,5 @@
After the kernel is unpacked but before it is patched, this task makes
sure that the machine and metadata branches as specified by the
:term:`SRCREV` variables actually exist on the specified
-branches. If these branches do not exist and
-:term:`AUTOREV` is not being used, the
+branches. Otherwise, if :term:`AUTOREV` is not being used, the
``do_validate_branches`` task fails during the build.
diff --git a/poky/documentation/ref-manual/variables.rst b/poky/documentation/ref-manual/variables.rst
index c339d45..df6413b 100644
--- a/poky/documentation/ref-manual/variables.rst
+++ b/poky/documentation/ref-manual/variables.rst
@@ -49,10 +49,9 @@
alternatives system to create a different binary naming scheme so the
commands can co-exist.
- To use the variable, list out the package's commands that also exist
- as part of another package. For example, if the ``busybox`` package
- has four commands that also exist as part of another package, you
- identify them as follows::
+ To use the variable, list out the package's commands that are also
+ provided by another package. For example, if the ``busybox`` package
+ has four such commands, you identify them as follows::
ALTERNATIVE_busybox = "sh sed test bracket"
@@ -306,8 +305,8 @@
variable), the OpenEmbedded build system ignores your request and
will install the packages to avoid dependency errors.
- Support for this variable exists only when using the IPK and RPM
- packaging backend. Support does not exist for DEB.
+ This variable is supported only when using the IPK and RPM
+ packaging backends. DEB is not supported.
See the :term:`NO_RECOMMENDATIONS` and the
:term:`PACKAGE_EXCLUDE` variables for related
@@ -336,8 +335,8 @@
- This host list is only used if ``BB_NO_NETWORK`` is either not set
or set to "0".
- - Limited support for wildcard matching against the beginning of
- host names exists. For example, the following setting matches
+ - There is limited support for wildcard matching against the beginning of
+ host names. For example, the following setting matches
``git.gnu.org``, ``ftp.gnu.org``, and ``foo.git.gnu.org``.
::
@@ -558,7 +557,7 @@
:term:`BBCLASSEXTEND`
Allows you to extend a recipe so that it builds variants of the
- software. Common variants for recipes exist such as "natives" like
+ software. There are common variants for recipes as "natives" like
``quilt-native``, which is a copy of Quilt built to run on the build
system; "crosses" such as ``gcc-cross``, which is a compiler built to
run on the build machine but produces binaries that run on the target
@@ -1237,7 +1236,7 @@
CONFFILES_${PN} += "${sysconfdir}/file1 \
${sysconfdir}/file2 ${sysconfdir}/file3"
- A relationship exists between the ``CONFFILES`` and ``FILES``
+ There is a relationship between the ``CONFFILES`` and ``FILES``
variables. The files listed within ``CONFFILES`` must be a subset of
the files listed within ``FILES``. Because the configuration files
you provide with ``CONFFILES`` are simply being identified so that
@@ -1417,8 +1416,8 @@
:term:`COREBASE_FILES`
Lists files from the :term:`COREBASE` directory that
should be copied other than the layers listed in the
- ``bblayers.conf`` file. The ``COREBASE_FILES`` variable exists for
- the purpose of copying metadata from the OpenEmbedded build system
+ ``bblayers.conf`` file. The ``COREBASE_FILES`` variable allows
+ to copy metadata from the OpenEmbedded build system
into the extensible SDK.
Explicitly listing files in ``COREBASE`` is needed because it
@@ -1525,10 +1524,10 @@
:term:`DEBUG_BUILD`
Specifies to build packages with debugging information. This
- influences the value of the ``SELECTED_OPTIMIZATION`` variable.
+ influences the value of the :term:`SELECTED_OPTIMIZATION` variable.
:term:`DEBUG_OPTIMIZATION`
- The options to pass in ``TARGET_CFLAGS`` and ``CFLAGS`` when
+ The options to pass in :term:`TARGET_CFLAGS` and :term:`CFLAGS` when
compiling a system for debugging. This variable defaults to "-O
-fno-omit-frame-pointer ${DEBUG_FLAGS} -pipe".
@@ -1538,7 +1537,7 @@
The most common usage of this is variable is to set it to "-1" within
a recipe for a development version of a piece of software. Using the
variable in this way causes the stable version of the recipe to build
- by default in the absence of ``PREFERRED_VERSION`` being used to
+ by default in the absence of :term:`PREFERRED_VERSION` being used to
build the development version.
.. note::
@@ -2460,8 +2459,8 @@
``FILESEXTRAPATHS`` variable.
You can take advantage of this searching behavior in useful ways. For
- example, consider a case where the following directory structure
- exists for general and machine-specific configurations::
+ example, consider a case where there is the following directory structure
+ for general and machine-specific configurations::
files/defconfig
files/MACHINEA/defconfig
@@ -2579,7 +2578,7 @@
Set the variable to "1" to force the removal of these packages.
:term:`FULL_OPTIMIZATION`
- The options to pass in ``TARGET_CFLAGS`` and ``CFLAGS`` when
+ The options to pass in :term:`TARGET_CFLAGS` and :term:`CFLAGS` when
compiling an optimized system. This variable defaults to "-O2 -pipe
${DEBUG_FLAGS}".
@@ -3013,8 +3012,8 @@
Image recipes set ``IMAGE_INSTALL`` to specify the packages to
install into an image through ``image.bbclass``. Additionally,
- "helper" classes such as the
- :ref:`core-image <ref-classes-core-image>` class exist that can
+ there are "helper" classes such as the
+ :ref:`core-image <ref-classes-core-image>` class which can
take lists used with ``IMAGE_FEATURES`` and turn them into
auto-generated entries in ``IMAGE_INSTALL`` in addition to its
default contents.
@@ -3465,8 +3464,8 @@
Use of the ``INHIBIT_SYSROOT_STRIP`` variable occurs in rare and
special circumstances. For example, suppose you are building
bare-metal firmware by using an external GCC toolchain. Furthermore,
- even if the toolchain's binaries are strippable, other files exist
- that are needed for the build that are not strippable.
+ even if the toolchain's binaries are strippable, there are other files
+ needed for the build that are not strippable.
:term:`INITRAMFS_FSTYPES`
Defines the format for the output image of an initial RAM filesystem
@@ -3745,6 +3744,44 @@
":ref:`kernel-dev/common:using an "in-tree" \`\`defconfig\`\` file`"
section in the Yocto Project Linux Kernel Development Manual.
+ :term:`KCONFIG_MODE`
+ When used with the :ref:`kernel-yocto <ref-classes-kernel-yocto>`
+ class, specifies the kernel configuration values to use for options
+ not specified in the provided ``defconfig`` file. Valid options are::
+
+ KCONFIG_MODE = "alldefconfig"
+ KCONFIG_MODE = "allnoconfig"
+
+ In ``alldefconfig`` mode the options not explicitly specified will be
+ assigned their Kconfig default value. In ``allnoconfig`` mode the
+ options not explicitly specified will be disabled in the kernel
+ config.
+
+ In case ``KCONFIG_MODE`` is not set the behaviour will depend on where
+ the ``defconfig`` file is coming from. An "in-tree" ``defconfig`` file
+ will be handled in ``alldefconfig`` mode, a ``defconfig`` file placed
+ in ``${WORKDIR}`` through a meta-layer will be handled in
+ ``allnoconfig`` mode.
+
+ An "in-tree" ``defconfig`` file can be selected via the
+ :term:`KBUILD_DEFCONFIG` variable. ``KCONFIG_MODE`` does not need to
+ be explicitly set.
+
+ A ``defconfig`` file compatible with ``allnoconfig`` mode can be
+ generated by copying the ``.config`` file from a working Linux kernel
+ build, renaming it to ``defconfig`` and placing it into the Linux
+ kernel ``${WORKDIR}`` through your meta-layer. ``KCONFIG_MODE`` does
+ not need to be explicitly set.
+
+ A ``defconfig`` file compatible with ``alldefconfig`` mode can be
+ generated using the
+ :ref:`ref-tasks-savedefconfig`
+ task and placed into the Linux kernel ``${WORKDIR}`` through your
+ meta-layer. Explicitely set ``KCONFIG_MODE``::
+
+ KCONFIG_MODE = "alldefconfig"
+
+
:term:`KERNEL_ALT_IMAGETYPE`
Specifies an alternate kernel image type for creation in addition to
the kernel image type specified using the
@@ -3779,7 +3816,7 @@
.. note::
- Legacy support exists for specifying the full path to the device
+ There is legacy support for specifying the full path to the device
tree. However, providing just the ``.dtb`` file is preferred.
In order to use this variable, the
@@ -4004,7 +4041,7 @@
:term:`KERNELDEPMODDEPEND`
Specifies whether the data referenced through
- :term:`PKGDATA_DIR` is needed or not. The
+ :term:`PKGDATA_DIR` is needed or not.
``KERNELDEPMODDEPEND`` does not control whether or not that data
exists, but simply whether or not it is used. If you do not need to
use the data, set the ``KERNELDEPMODDEPEND`` variable in your
@@ -4189,8 +4226,8 @@
- Separate license names using \| (pipe) when there is a choice
between licenses.
- - Separate license names using & (ampersand) when multiple licenses
- exist that cover different parts of the source.
+ - Separate license names using & (ampersand) when there are
+ multiple licenses for different parts of the source.
- You can use spaces between license names.
@@ -4338,8 +4375,8 @@
The variable corresponds to a machine configuration file of the same
name, through which machine-specific configurations are set. Thus,
- when ``MACHINE`` is set to "qemux86" there exists the corresponding
- ``qemux86.conf`` machine configuration file, which can be found in
+ when ``MACHINE`` is set to "qemux86", the corresponding
+ ``qemux86.conf`` machine configuration file can be found in
the :term:`Source Directory` in
``meta/conf/machine``.
@@ -4704,7 +4741,7 @@
:term:`NO_GENERIC_LICENSE`
Avoids QA errors when you use a non-common, non-CLOSED license in a
- recipe. Packages exist, such as the linux-firmware package, with many
+ recipe. There are packages, such as the linux-firmware package, with many
licenses that are not in any way common. Also, new licenses are added
occasionally to avoid introducing a lot of common license files,
which are only applicable to a specific package.
@@ -4716,7 +4753,7 @@
NO_GENERIC_LICENSE[license_name] = "license_file_in_fetched_source"
- The following is an example that
+ Here is an example that
uses the ``LICENSE.Abilis.txt`` file as the license from the fetched
source::
@@ -4748,8 +4785,8 @@
functionality, such as kernel modules. It is up to you to add
packages with the :term:`IMAGE_INSTALL` variable.
- Support for this variable exists only when using the IPK and RPM
- packaging backend. Support does not exist for DEB.
+ This variable is only supported when using the IPK and RPM
+ packaging backends. DEB is not supported.
See the :term:`BAD_RECOMMENDATIONS` and
the :term:`PACKAGE_EXCLUDE` variables for
@@ -5026,8 +5063,8 @@
an iterative development process to remove specific components from a
system.
- Support for this variable exists only when using the IPK and RPM
- packaging backend. Support does not exist for DEB.
+ This variable is supported only when using the IPK and RPM
+ packaging backends. DEB is not supported.
See the :term:`NO_RECOMMENDATIONS` and the
:term:`BAD_RECOMMENDATIONS` variables for
@@ -6173,7 +6210,7 @@
:term:`PACKAGE_EXCLUDE` variables.
Packages specified in ``RRECOMMENDS`` need not actually be produced.
- However, a recipe must exist that provides each package, either
+ However, there must be a recipe providing each package, either
through the :term:`PACKAGES` or
:term:`PACKAGES_DYNAMIC` variables or the
:term:`RPROVIDES` variable, or an error will occur
@@ -6653,8 +6690,8 @@
value of the :term:`TARGET_CFLAGS` variable.
The ``SELECTED_OPTIMIZATION`` variable takes the value of
- ``FULL_OPTIMIZATION`` unless ``DEBUG_BUILD`` = "1". If that is the
- case, the value of ``DEBUG_OPTIMIZATION`` is used.
+ :term:`FULL_OPTIMIZATION` unless :term:`DEBUG_BUILD` = "1", in which
+ case the value of :term:`DEBUG_OPTIMIZATION` is used.
:term:`SERIAL_CONSOLE`
Defines a serial console (TTY) to enable using
@@ -6941,8 +6978,8 @@
- ``az://`` - Fetches files from an Azure Storage account.
- Standard and recipe-specific options for ``SRC_URI`` exist. Here are
- standard options:
+ There are standard and recipe-specific options for ``SRC_URI``. Here are
+ standard ones:
- ``apply`` - Whether to apply the patch or not. The default
action is to apply the patch.
@@ -7629,8 +7666,8 @@
:term:`TARGET_OS`
Specifies the target's operating system. The variable can be set to
"linux" for glibc-based systems (GNU C Library) and to "linux-musl"
- for musl libc. For ARM/EABI targets, "linux-gnueabi" and
- "linux-musleabi" possible values exist.
+ for musl libc. For ARM/EABI targets, the possible values are
+ "linux-gnueabi" and "linux-musleabi".
:term:`TARGET_PREFIX`
Specifies the prefix used for the toolchain binary target tools.
@@ -8331,11 +8368,10 @@
configure options are simply not passed to the configure script (e.g.
should be removed from :term:`EXTRA_OECONF` or
:term:`PACKAGECONFIG_CONFARGS`).
- However, common options, for example, exist that are passed to all
- configure scripts at a class level that might not be valid for some
- configure scripts. It follows that no benefit exists in seeing a
- warning about these options. For these cases, the options are added
- to ``UNKNOWN_CONFIGURE_WHITELIST``.
+ However, there are common options that are passed to all
+ configure scripts at a class level, but might not be valid for some
+ configure scripts. Therefore warnings about these options are useless.
+ For these cases, the options are added to ``UNKNOWN_CONFIGURE_WHITELIST``.
The configure arguments check that uses
``UNKNOWN_CONFIGURE_WHITELIST`` is part of the
diff --git a/poky/documentation/releases.rst b/poky/documentation/releases.rst
index b95a6ed..f278e21 100644
--- a/poky/documentation/releases.rst
+++ b/poky/documentation/releases.rst
@@ -9,6 +9,7 @@
*******************************
- :yocto_docs:`3.3 Documentation </3.3>`
+- :yocto_docs:`3.3.1 Documentation </3.3.1>`
*******************************
3.2 'gatesgarth' Release Series
@@ -18,6 +19,7 @@
- :yocto_docs:`3.2.1 Documentation </3.2.1>`
- :yocto_docs:`3.2.2 Documentation </3.2.2>`
- :yocto_docs:`3.2.3 Documentation </3.2.3>`
+- :yocto_docs:`3.2.4 Documentation </3.2.4>`
****************************
3.1 'dunfell' Release Series
diff --git a/poky/documentation/sdk-manual/appendix-customizing.rst b/poky/documentation/sdk-manual/appendix-customizing.rst
index fb2d784..67b49d9 100644
--- a/poky/documentation/sdk-manual/appendix-customizing.rst
+++ b/poky/documentation/sdk-manual/appendix-customizing.rst
@@ -57,8 +57,7 @@
============================================================
In most cases, the extensible SDK defaults should work with your :term:`Build
-Host`'s setup.
-However, some cases exist for which you might consider making
+Host`'s setup. However, there are cases when you might consider making
adjustments:
- If your SDK configuration inherits additional classes using the
@@ -153,7 +152,7 @@
SDK_TITLE ??= "${@d.getVar('DISTRO_NAME') or d.getVar('DISTRO')} SDK"
-While several ways exist to change this variable, an efficient method is
+While there are several ways of changing this variable, an efficient method is
to set the variable in your distribution's configuration file. Doing so
creates an SDK installer title that applies across your distribution. As
an example, assume you have your own layer for your distribution named
@@ -223,7 +222,7 @@
change this default installation directory by specifically setting the
``SDKEXTPATH`` variable.
-While a number of ways exist through which you can set this variable,
+While there are several ways of setting this variable,
the method that makes the most sense is to set the variable in your
distribution's configuration file. Doing so creates an SDK installer
default directory that applies across your distribution. As an example,
diff --git a/poky/documentation/sdk-manual/extensible.rst b/poky/documentation/sdk-manual/extensible.rst
index 04bafae..55bd7f6 100644
--- a/poky/documentation/sdk-manual/extensible.rst
+++ b/poky/documentation/sdk-manual/extensible.rst
@@ -194,7 +194,7 @@
devtool
quick reference.
-Three ``devtool`` subcommands exist that provide entry-points into
+Three ``devtool`` subcommands provide entry-points into
development:
- *devtool add*: Assists in adding new software to be built.
@@ -276,7 +276,7 @@
devtool
always creates a Git repository locally during the extraction.
- Furthermore, the first positional argument srctree in this case
+ Furthermore, the first positional argument ``srctree`` in this case
identifies where the ``devtool add`` command will locate the
extracted code outside of the workspace. You need to specify an
empty directory::
@@ -285,13 +285,13 @@
In summary,
the source code is pulled from fetchuri and extracted into the
- location defined by srctree as a local Git repository.
+ location defined by ``srctree`` as a local Git repository.
Within workspace, ``devtool`` creates a recipe named recipe along
with an associated append file.
- *Right*: The right scenario in the figure represents a situation
- where the srctree has been previously prepared outside of the
+ where the ``srctree`` has been previously prepared outside of the
``devtool`` workspace.
The following command provides a new recipe name and identifies
@@ -437,7 +437,7 @@
locate the source code and any local patch files from other
developers.
- With this scenario, no srctree argument exists. Consequently, the
+ With this scenario, there is no ``srctree`` argument. Consequently, the
default behavior of the ``devtool modify`` command is to extract
the source files pointed to by the ``SRC_URI`` statements into a
local Git structure. Furthermore, the location for the extracted
@@ -483,21 +483,21 @@
under the newly created source tree.
Once the files are located, the command by default extracts them
- into srctree.
+ into ``srctree``.
Within workspace, ``devtool`` creates an append file for the
recipe. The recipe remains in its original location but the source
- files are extracted to the location you provide with srctree.
+ files are extracted to the location you provide with ``srctree``.
- *Right*: The right scenario in the figure represents a situation
- where the source tree (srctree) already exists locally as a
+ where the source tree (``srctree``) already exists locally as a
previously extracted Git structure outside of the ``devtool``
workspace. In this example, the recipe also exists elsewhere
locally in its own layer.
The following command tells ``devtool`` the recipe with which to
work, uses the "-n" option to indicate source does not need to be
- extracted, and uses srctree to point to the previously extracted
+ extracted, and uses ``srctree`` to point to the previously extracted
source files::
$ devtool modify -n recipe srctree
@@ -646,8 +646,9 @@
code into the ``sources`` directory in the
:ref:`devtool-the-workspace-layer-structure`.
If you want the code extracted to any other location, you need to
- provide the srctree positional argument with the command as follows:
- $ devtool upgrade -V version recipe srctree
+ provide the ``srctree`` positional argument with the command as follows::
+
+ $ devtool upgrade -V version recipe srctree
.. note::
@@ -674,8 +675,8 @@
are incorporated into the build the next time you build the software
just as are other changes you might have made to the source.
-2. *Resolve any Conflicts created by the Upgrade*: Conflicts could exist
- due to the software being upgraded to a new version. Conflicts occur
+2. *Resolve any Conflicts created by the Upgrade*: Conflicts could happen
+ after upgrading the software to a new version. Conflicts occur
if your recipe specifies some patch files in ``SRC_URI`` that
conflict with changes made in the new version of the software. For
such cases, you need to resolve the conflicts by editing the source
@@ -908,8 +909,8 @@
similar manner to the environment set up by the SDK's environment
setup script. One easy way to see these variables is to run the
``devtool build`` command on the recipe and then look in
- ``oe-logs/run.do_compile``. Towards the top of this file, a list of
- environment variables exists that are being set. You can take
+ ``oe-logs/run.do_compile``. Towards the top of this file, there is
+ a list of environment variables that are set. You can take
advantage of these variables within the Makefile.
- If the Makefile sets a default for a variable using "=", that default
@@ -953,7 +954,7 @@
Specifying the name like this produces a recipe that only builds for
the build host.
-- Specify the "DASHDASHalso-native" option with the ``devtool add``
+- Specify the "--also-native" option with the ``devtool add``
command. Specifying this option creates a recipe file that still
builds for the target but also creates a variant with a "-native"
suffix that builds for the build host.
@@ -964,7 +965,7 @@
that builds code for the target, you can typically accomplish this by
building the native and target parts separately rather than within
the same compilation process. Realize though that with the
- "DASHDASHalso-native" option, you can add the tool using just one
+ "--also-native" option, you can add the tool using just one
recipe file.
Adding Node.js Modules
@@ -1037,8 +1038,8 @@
does not include complete instructions for building the software.
Instead, common functionality is encapsulated in classes inherited with
the ``inherit`` directive. This technique leaves the recipe to describe
-just the things that are specific to the software being built. A
-:ref:`base <ref-classes-base>` class exists that
+just the things that are specific to the software being built. There is
+a :ref:`base <ref-classes-base>` class that
is implicitly inherited by all recipes and provides the functionality
that most recipes typically need.
@@ -1100,7 +1101,7 @@
exact options being passed, and shows them to you along with any custom
arguments specified through ``EXTRA_OECONF`` or
``PACKAGECONFIG_CONFARGS``. If applicable, the command also shows you
-the output of the configure script's "DASHDASHhelp" option as a
+the output of the configure script's "--help" option as a
reference.
Sharing Files Between Recipes
@@ -1110,9 +1111,9 @@
:term:`Build Host`. For example,
an application linking to a common library needs access to the library
itself and its associated headers. The way this access is accomplished
-within the extensible SDK is through the sysroot. One sysroot exists per
+within the extensible SDK is through the sysroot. There is one sysroot per
"machine" for which the SDK is being built. In practical terms, this
-means a sysroot exists for the target machine, and a sysroot exists for
+means there is a sysroot for the target machine, and a sysroot for
the build host.
Recipes should never write files directly into the sysroot. Instead,
@@ -1159,8 +1160,8 @@
``${``\ :term:`PN`\ ``}`` evaluates to the
recipe name). The order of the ``PACKAGES`` value is significant. For
each installed file, the first package whose ``FILES`` value matches the
-file is the package into which the file goes. Defaults exist for both
-the ``PACKAGES`` and ``FILES`` variables. Consequently, you might find
+file is the package into which the file goes. Both the ``PACKAGES`` and
+``FILES`` variables have default values. Consequently, you might find
you do not even need to set these variables in your recipe unless the
software the recipe is building installs files into non-standard
locations.
@@ -1230,7 +1231,7 @@
It is important to remember that building the item from source
takes significantly longer than installing the pre-built artifact. Also,
-if no recipe exists for the item you want to add to the SDK, you must
+if there is no recipe for the item you want to add to the SDK, you must
instead add the item using the ``devtool add`` command.
Applying Updates to an Installed Extensible SDK
diff --git a/poky/documentation/sdk-manual/intro.rst b/poky/documentation/sdk-manual/intro.rst
index d966efe..2f94aaf 100644
--- a/poky/documentation/sdk-manual/intro.rst
+++ b/poky/documentation/sdk-manual/intro.rst
@@ -8,8 +8,8 @@
=================
Welcome to the Yocto Project Application Development and the Extensible
-Software Development Kit (eSDK) manual. This manual provides information
-that explains how to use both the Yocto Project extensible and standard
+Software Development Kit (eSDK) manual. This manual
+explains how to use both the Yocto Project extensible and standard
SDKs to develop applications and images.
.. note::
@@ -25,12 +25,13 @@
All SDKs consist of the following:
- *Cross-Development Toolchain*: This toolchain contains a compiler,
- debugger, and various miscellaneous tools.
+ debugger, and various associated tools.
- *Libraries, Headers, and Symbols*: The libraries, headers, and
- symbols are specific to the image (i.e. they match the image).
+ symbols are specific to the image (i.e. they match the image
+ against which the SDK was built).
-- *Environment Setup Script*: This ``*.sh`` file, once run, sets up the
+- *Environment Setup Script*: This ``*.sh`` file, once sourced, sets up the
cross-development environment by defining variables and preparing for
SDK use.
@@ -48,14 +49,14 @@
for a wrapper around the ``populate_sdk`` and ``populate_sdk_ext``
archives.
-Another feature for the SDKs is that only one set of cross-compiler
+Another feature of the SDKs is that only one set of cross-compiler
toolchain binaries are produced for any given architecture. This feature
takes advantage of the fact that the target hardware can be passed to
``gcc`` as a set of compiler options. Those options are set up by the
environment script and contained in variables such as
:term:`CC` and
:term:`LD`. This reduces the space needed
-for the tools. Understand, however, that every target still needs a
+for the tools. Understand, however, that every target still needs its own
sysroot because those binaries are target-specific.
The SDK development environment consists of the following:
@@ -118,8 +119,8 @@
The :term:`Cross-Development Toolchain` consists
of a cross-compiler, cross-linker, and cross-debugger that are used to
-develop user-space applications for targeted hardware. Additionally, for
-an extensible SDK, the toolchain also has built-in ``devtool``
+develop user-space applications for targeted hardware; in addition,
+the extensible SDK comes with built-in ``devtool``
functionality. This toolchain is created by running a SDK installer
script or through a :term:`Build Directory` that is based on
your metadata configuration or extension for your targeted device. The
@@ -138,21 +139,19 @@
-----------------
The QEMU emulator allows you to simulate your hardware while running
-your application or image. QEMU is not part of the SDK but is made
-available a number of different ways:
+your application or image. QEMU is not part of the SDK but is
+automatically installed and available if you have done any one of
+the following:
-- If you have cloned the ``poky`` Git repository to create a
- :term:`Source Directory` and you have
- sourced the environment setup script, QEMU is installed and
- automatically available.
+- cloned the ``poky`` Git repository to create a
+ :term:`Source Directory` and sourced the environment setup script.
-- If you have downloaded a Yocto Project release and unpacked it to
- create a Source Directory and you have sourced the environment setup
- script, QEMU is installed and automatically available.
+- downloaded a Yocto Project release and unpacked it to
+ create a Source Directory and sourced the environment setup
+ script.
-- If you have installed the cross-toolchain tarball and you have
- sourced the toolchain's setup environment script, QEMU is also
- installed and automatically available.
+- installed the cross-toolchain tarball and
+ sourced the toolchain's setup environment script.
SDK Development Model
=====================
@@ -202,10 +201,9 @@
.. note::
- To use the root filesystem in QEMU, you need to extract it. See
- the "
- Extracting the Root Filesystem
- " section for information on how to extract the root filesystem.
+ To use the root filesystem in QEMU, you need to extract it. See the
+ ":ref:`sdk-manual/appendix-obtain:extracting the root filesystem`"
+ section for information on how to do this extraction.
3. *Develop and Test your Application:* At this point, you have the
tools to develop your application. If you need to separately install
@@ -216,5 +214,5 @@
within the Yocto Project.
The remainder of this manual describes how to use the extensible and
-standard SDKs. Information also exists in appendix form that describes
+standard SDKs. There is also information in appendix form describing
how you can build, install, and modify an SDK.
diff --git a/poky/documentation/sdk-manual/using.rst b/poky/documentation/sdk-manual/using.rst
index fa0e8d4..3016278 100644
--- a/poky/documentation/sdk-manual/using.rst
+++ b/poky/documentation/sdk-manual/using.rst
@@ -11,9 +11,8 @@
.. note::
For a side-by-side comparison of main features supported for a
- standard SDK as compared to an extensible SDK, see the "
- Introduction
- " section.
+ standard SDK as compared to an extensible SDK, see the
+ ":ref:`sdk-manual/intro:introduction`" section.
You can use a standard SDK to work on Makefile and Autotools-based
projects. See the
@@ -49,7 +48,7 @@
64-bit architectures with the ``x86_64`` directories, respectively. The
toolchains the Yocto Project provides are based off the
``core-image-sato`` and ``core-image-minimal`` images and contain
-libraries appropriate for developing against that image.
+libraries appropriate for developing against the corresponding image.
The names of the tarball installer scripts are such that a string
representing the host system appears first in the filename and then is
@@ -84,9 +83,9 @@
.. note::
As an alternative to downloading an SDK, you can build the SDK
- installer. For information on building the installer, see the "
- Building an SDK Installer
- " section.
+ installer. For information on building the installer, see the
+ ":ref:`sdk-manual/appendix-obtain:building an sdk installer`"
+ section.
The SDK and toolchains are self-contained and by default are installed
into the ``poky_sdk`` folder in your home directory. You can choose to
diff --git a/poky/documentation/sphinx-static/switchers.js b/poky/documentation/sphinx-static/switchers.js
index 3f62e29..a32d872 100644
--- a/poky/documentation/sphinx-static/switchers.js
+++ b/poky/documentation/sphinx-static/switchers.js
@@ -3,8 +3,8 @@
var all_versions = {
'dev': 'dev (3.4)',
- '3.3': '3.3',
- '3.2.3': '3.2.3',
+ '3.3.1': '3.3.1',
+ '3.2.4': '3.2.4',
'3.1.7': '3.1.7',
'3.0.4': '3.0.4',
'2.7.4': '2.7.4',
diff --git a/poky/documentation/toaster-manual/reference.rst b/poky/documentation/toaster-manual/reference.rst
index 3d4efe9..c0d02ff 100644
--- a/poky/documentation/toaster-manual/reference.rst
+++ b/poky/documentation/toaster-manual/reference.rst
@@ -9,8 +9,8 @@
final chapter provides conceptual information on layer sources,
releases, and JSON configuration files. Also provided is a quick look at
some useful ``manage.py`` commands that are Toaster-specific.
-Information on ``manage.py`` commands does exist across the Web and the
-information in this manual by no means attempts to provide a command
+Information on ``manage.py`` commands is available across the Web and
+this manual by no means attempts to provide a command
comprehensive reference.
Layer Source
@@ -32,9 +32,8 @@
`REST <https://en.wikipedia.org/wiki/Representational_state_transfer>`__
API, store the information about the layers in the Toaster database, and
then show the information to users. Users are then able to view that
-information and build layers from Toaster itself without worrying about
-cloning or editing the BitBake layers configuration file
-``bblayers.conf``.
+information and build layers from Toaster itself without having to
+clone or edit the BitBake layers configuration file ``bblayers.conf``.
Tying a layer source into Toaster is convenient when you have many
custom layers that need to be built on a regular basis by a community of
@@ -187,7 +186,7 @@
------------------------
The ``bldcontrol/management/commands/checksettings.py`` file controls
-workflow configuration. The following steps outline the process to
+workflow configuration. Here is the process to
initially populate this database.
1. The default project settings are set from
@@ -238,7 +237,7 @@
Understanding Fixture File Format
---------------------------------
-The following is an overview of the file format used by the
+Here is an overview of the file format used by the
``oe-core.xml``, ``poky.xml``, and ``custom.xml`` files.
The following subsections describe each of the sections in the fixture
@@ -408,7 +407,7 @@
Be sure to provide values for host and port. The output is a JSON file that
itemizes all builds in progress. This file includes the time in seconds since
each respective build started as well as the progress of the cloning, parsing,
-and task execution. The following is sample output for a build in progress:
+and task execution. Here is sample output for a build in progress:
.. code-block:: JSON
@@ -441,8 +440,8 @@
http://host:port/toastergui/api/builds
Be sure to provide values for host and port. The output is a JSON file that
-itemizes all complete builds, and includes build summary information. The
-following is sample output for a completed build:
+itemizes all complete builds, and includes build summary information. Here
+is sample output for a completed build:
.. code-block:: JSON
@@ -480,7 +479,7 @@
section for more information.
The output is a JSON file that itemizes the specific build and includes
-build summary information. The following is sample output for a specific
+build summary information. Here is sample output for a specific
build:
.. code-block:: JSON
@@ -509,7 +508,7 @@
===============
In addition to the web user interface and the scripts that start and
-stop Toaster, command-line commands exist through the ``manage.py``
+stop Toaster, command-line commands are available through the ``manage.py``
management script. You can find general documentation on ``manage.py``
at the
`Django <https://docs.djangoproject.com/en/2.2/topics/settings/>`__