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/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.