subtree updates
meta-arm: 14c7e5b336..3b7347cd67:
Jon Mason (6):
CI: Remove host bitbake variables
arm: add Mickledore to layer compat string
CI: Add packages for opencsd and gator-daemon to base build
CI: add common fvp yml file
arm/opencsd: update to version 1.3.1
arm/gator-daemon: update to v7.8.0
Jose Quaresma (2):
optee-ftpm/optee-os: add missing space in EXTRA_OEMAKE
optee-os-ts: avoid using escape chars in EXTRA_OEMAKE
Mohamed Omar Asaker (4):
Revert "arm-bsp/trusted-firmware-m: corstone1000: secure debug code checkout from yocto"
Revert "arm-bsp/trusted-firmware-m: corstone1000: bump tfm SHA"
arm-bsp/trusted-firmware-m: corstone1000 support FMP image info
arm-bsp/corstone1000: add msd configs for fvp
Ross Burton (5):
arm/hafnium: add missing Upstream-Status
arm-bsp/hafnium: add missing Upstream-Status
arm-bsp/linux-arm64-ack: fix malformed Upstream-Status tag
CI: add documentation job
CI: track meta-openembedded's langdale branch
Rui Miguel Silva (2):
arm/trusted-services: port crypto config
arm-bsp/corstone1000: apply ts patch to psa crypto api test
Satish Kumar (1):
arm-bsp/trusted-service: corstone1000: esrt support
Vishnu Banavath (4):
runfvp: corstone1000: add mmc card configuration
meta-arm-bsp/doc: add readthedocs for corstone1000
arm-bsp/optee: register DRAM1 for N1SDP target
arm-bsp:optee: enable optee test for N1SDP target
meta-raspberrypi: 722c51647c..a305f4804b:
Sung Gon Kim (1):
libcamera: rename bbappend to match any version
meta-openembedded: 8073ec2275..6ebff843cc:
Akash Hadke (1):
audit: Fix compile error for audit_2.8.5
Alex Kiernan (1):
lldpd: Upgrade 1.0.14 -> 1.0.15
Alexander Kanavin (3):
sip3: remove the recipe
python3-wxgtk4: skip the recipe
python3-yappi: mark as incompatible with python 3.11
Bhupesh Sharma (1):
android-tools-conf-configfs: Allow handling two or more UDC controllers
Eero Aaltonen (1):
valijson: use install task from CMakeLists.txt
Etienne Cordonnier (1):
uutils-coreutils: upgrade 0.0.15 -> 0.0.16
Gianfranco Costamagna (2):
vboxguestdrivers: upgrade 6.1.38 -> 7.0.0
vbxguestdrivers: upgrade 7.0.0 -> 7.0.2
Joshua Watt (3):
nginx: Add ipv6 support
iniparser: Add native support
libzip: Add native support
Khem Raj (3):
postfix: Upgrade to 3.7.3
msktutil: Add recipe
protobuf: Enable protoc binary in nativesdk
Leon Anavi (7):
python3-cheetah: Upgrade 3.2.6 -> 3.2.6.post1
python3-dill: Upgrade 0.3.5.1 -> 0.3.6
python3-pythonping: Upgrade 1.1.3 -> 1.1.4
python3-colorama: Upgrade 0.4.5 -> 0.4.6
python3-pint: Upgrade 0.19.2 -> 0.20
python3-traitlets: Upgrade 5.4.0 -> 5.5.0
python3-py-cpuinfo: Upgrade 8.0.0 -> 9.0.0
Markus Volk (4):
perfetto: build libperfetto
libcamera: upgrade -> 0.0.1
gtk-vnc: add recipe
spice-gtk: add recipe
Meier Boas (1):
jwt-cpp: add recipe
Ovidiu Panait (1):
syzkaller: add recipe and selftest for syzkaller fuzzing
Peter Marko (2):
cpputest: remove dev package dependency
cpputest: add possibility to build extensions
Robert Joslyn (1):
fwupd: Fix plugin_gpio PACKAGECONFIG
Sebastian Trahm (1):
Add recipe for python3-pytest-json-report
Tim Orling (5):
libmime-types-perl: upgrade 2.17 -> 2.22
libcompress-raw*-perl: move from libio/compress-*
libio-compress*-perl: cleanup; fixes
libcompress-raw-*-perl: cleanup; fixes
packagegroup-meta-perl: mv libcompress-raw-*-perl
Vincent Davis Jr (2):
libglvnd: add new recipe libglvnd v1.5.0
xf86-video-amdgpu: add new recipe xf86-video-amdgpu
Wang Mingyu (36):
bats: upgrade 1.8.0 -> 1.8.2
ctags: upgrade 5.9.20221009.0 -> 5.9.20221016.0
fvwm: upgrade 2.6.9 -> 2.7.0
makedumpfile: upgrade 1.7.1 -> 1.7.2
sanlock: upgrade 3.8.4 -> 3.8.5
python3-astroid: upgrade 2.12.11 -> 2.12.12
python3-charset-normalizer: upgrade 2.1.1 -> 3.0.0
python3-google-api-python-client: upgrade 2.64.0 -> 2.65.0
python3-google-auth: upgrade 2.12.0 -> 2.13.0
python3-grpcio-tools: upgrade 1.49.1 -> 1.50.0
python3-grpcio: upgrade 1.49.1 -> 1.50.0
python3-huey: upgrade 2.4.3 -> 2.4.4
python3-incremental: upgrade 21.3.0 -> 22.10.0
python3-luma-core: upgrade 2.3.1 -> 2.4.0
python3-oauthlib: upgrade 3.2.1 -> 3.2.2
python3-pandas: upgrade 1.5.0 -> 1.5.1
python3-pastedeploy: upgrade 2.1.1 -> 3.0.1
python3-pika: upgrade 1.3.0 -> 1.3.1
python3-portalocker: upgrade 2.5.1 -> 2.6.0
python3-protobuf: upgrade 4.21.7 -> 4.21.8
python3-pyjwt: upgrade 2.5.0 -> 2.6.0
python3-pymongo: upgrade 4.2.0 -> 4.3.2
python3-pywbemtools: upgrade 1.0.0 -> 1.0.1
python3-robotframework: upgrade 5.0.1 -> 6.0
python3-socketio: upgrade 5.7.1 -> 5.7.2
python3-sqlalchemy: upgrade 1.4.41 -> 1.4.42
tracker-miners: upgrade 3.2.1 -> 3.4.1
tracker: upgrade 3.4.0 -> 3.4.1
wolfssl: upgrade 5.5.1 -> 5.5.2
cglm: upgrade 0.8.5 -> 0.8.7
ctags: upgrade 5.9.20221016.0 -> 5.9.20221023.0
flatbuffers: upgrade 22.9.29 -> 22.10.26
function2: upgrade 4.2.1 -> 4.2.2
poco: upgrade 1.12.2 -> 1.12.3
thingsboard-gateway: upgrade 3.1 -> 3.2
grpc: upgrade 1.50.0 -> 1.50.1
Xiangyu Chen (1):
ipmitool: fix typo in .bb file's comments, using = instead of =?
Zheng Qiu (1):
jq: improve ptest and disable valgrind by default
zhengruoqin (5):
tcpslice: upgrade 1.5 -> 1.6
tio: upgrade 2.1 -> 2.2
python3-stevedore: upgrade 4.0.1 -> 4.1.0
python3-xxhash: upgrade 3.0.0 -> 3.1.0
python3-zeroconf: upgrade 0.39.1 -> 0.39.2
meta-security: e8e7318189..2aa48e6f4e:
Armin Kuster (1):
kas-security-base.yml: make work again
Gowtham Suresh Kumar (1):
Update PARSEC recipe to latest v1.1.0 release
Michael Haener (1):
tpm2-openssl: update to 1.1.1
poky: 95c802b0be..482c493cf6:
Adrian Freihofer (3):
own-mirrors: add crate
buildconf: compare abspath
ref-manual: add wic command bootloader ptable option
Ahmad Fatoum (2):
kernel-fitimage: mangle slashes to underscores as late as possible
kernel-fitimage: skip FDT section creation for applicable symlinks
Alex Kiernan (4):
u-boot: Remove duplicate inherit of cml1
u-boot: Add savedefconfig task
rust: update 1.63.0 -> 1.64.0
cargo_common.bbclass: Fix typos
Alexander Kanavin (40):
rust-target-config: match riscv target names with what rust expects
rust: install rustfmt for riscv32 as well
unfs3: correct upstream version check
gnu-config: update to latest revision
llvm: update 14.0.6 -> 15.0.1
grep: update 3.7 -> 3.8
hdparm: update 9.64 -> 9.65
stress-ng: update 0.14.03 -> 0.14.06
vulkan: update 1.3.216.0 -> 1.3.224.1
wayland-utils: update 1.0.0 -> 1.1.0
libxft: update 2.3.4 -> 2.3.6
pinentry: update 1.2.0 -> 1.2.1
ovmf: upgrade edk2-stable202205 -> edk2-stable202208
cmake: update 3.24.0 -> 3.24.2
jquery: upgrade 3.6.0 -> 3.6.1
python3-dbus: upgrade 1.2.18 -> 1.3.2
python3-hatch-fancy-pypi-readme: add a recipe
python3-jsonschema: upgrade 4.9.1 -> 4.16.0
shadow: update 4.12.1 -> 4.12.3
lttng-modules: upgrade 2.13.4 -> 2.13.5
libsoup: upgrade 3.0.7 -> 3.2.0
libxslt: upgrade 1.1.35 -> 1.1.37
quilt: backport a patch to address grep 3.8 failures
python3: update 3.10.6 -> 3.11.0
cargo-update-recipe-crates.bbclass: add a class to generate SRC_URI crate lists from Cargo.lock
python3-bcrypt: convert to use cargo-update-recipe-crates class.
python3-cryptography: convert to cargo-update-recipe-crates class
groff: submit patches upstream
tcl: correct patch status
tcl: correct upstream version check
lttng-tools: submit determinism.patch upstream
cmake: drop qt4 patches
kea: submit patch upstream
argp-standalone: replace with a maintained fork
ovmf: correct patches status
go: submit patch upstream
libffi: submit patch upstream
go: update 1.19 -> 1.19.2
rust-common.bbclass: use built-in rust targets for -native builds
rust: submit a rewritten version of crossbeam_atomic.patch upstream
Andrew Geissler (1):
go: add support to build on ppc64le
Bartosz Golaszewski (1):
bluez5: add dbus to RDEPENDS
Bernhard Rosenkränzer (1):
cmake-native: Fix host tool contamination
Bruce Ashfield (3):
kern-tools: fix relative path processing
linux-yocto/5.19: update to v5.19.14
linux-yocto/5.15: update to v5.15.72
Changhyeok Bae (2):
ethtool: upgrade 5.19 -> 6.0
iproute2: upgrade 5.19.0 -> 6.0.0
Chen Qi (1):
openssl: export necessary env vars in SDK
Christian Eggers (1):
linux-firmware: split rtl8761 firmware
Claus Stovgaard (1):
gstreamer1.0-libav: fix errors with ffmpeg 5.x
Ed Tanous (1):
openssl: Upgrade 3.0.5 -> 3.0.7
Etienne Cordonnier (1):
mirrors.bbclass: use shallow tarball for binutils-native
Fabio Estevam (1):
go-mod.bbclass: Remove repeated word
Frank de Brabander (1):
cve-update-db-native: add timeout to urlopen() calls
Hitendra Prajapati (1):
openssl: CVE-2022-3358 Using a Custom Cipher with NID_undef may lead to NULL encryption
Jan-Simon Moeller (1):
buildtools-tarball: export certificates to python and curl
Jeremy Puhlman (1):
qemu-native: Add PACKAGECONFIG option for jack
Johan Korsnes (1):
bitbake: bitbake: user-manual: inform about spaces in :remove
Jon Mason (2):
linux-yocto: add efi entry for machine features
linux-yocto-dev: add qemuarmv5
Jose Quaresma (3):
kernel-yocto: improve fatal error messages of symbol_why.py
oeqa/selftest/archiver: Add multiconfig test for shared recipes
archiver: avoid using machine variable as it breaks multiconfig
Joshua Watt (3):
runqemu: Fix gl-es argument from causing other arguments to be ignored
qemu-helper-native: Re-write bridge helper as C program
runqemu: Do not perturb script environment
Justin Bronder (1):
bitbake: asyncrpc: serv: correct closed client socket detection
Kai Kang (1):
mesa: only apply patch to fix ALWAYS_INLINE for native
Keiya Nobuta (2):
gnutls: Unified package names to lower-case
create-spdx: Remove ";name=..." for downloadLocation
Khem Raj (3):
perf: Depend on native setuptools3
musl: Upgrade to latest master
mesa: Add native patch via a variable
Lee Chee Yang (2):
migration-guides/release-notes-4.1.rst: update Repositories / Downloads
migration-guides/release-notes-4.1.rst: update Repositories / Downloads
Leon Anavi (1):
python3-manifest.json: Move urllib to netclient
Liam Beguin (1):
meson: make wrapper options sub-command specific
Luca Boccassi (1):
systemd: add systemd-creds and systemd-cryptenroll to systemd-extra-utils
Marek Vasut (1):
bluez5: Point hciattach bcm43xx firmware search path to /lib/firmware
Mark Asselstine (2):
bitbake: tests: bb.tests.fetch.URLHandle: add 2 new tests
bitbake: bitbake: bitbake-layers: checkout layer(s) branch when clone exists
Mark Hatle (2):
insane.bbclass: Allow hashlib version that only accepts on parameter
bitbake: utils/ply: Update md5 to better report errors with hashlib
Markus Volk (2):
wayland-protocols: upgrade 1.26 -> 1.27
mesa: update 22.2.0 -> 22.2.2
Martin Jansa (3):
vulkan-samples: add lfs=0 to SRC_URI to avoid git smudge errors in do_unpack
externalsrc.bbclass: fix git repo detection
cargo-update-recipe-crates: small improvements
Maxim Uvarov (2):
wic: add UEFI kernel as UEFI stub
wic: bootimg-efi: implement --include-path
Michael Opdenacker (11):
manuals: updates for building on Windows (WSL 2)
ref-manual: classes.rst: add links to all references to a class
poky.conf: remove Ubuntu 21.10
bitbake: doc: bitbake-user-manual: expand description of BB_PRESSURE_MAX variables
bitbake: bitbake-user-manual: details about variable flags starting with underscore
Documentation/README: formalize guidelines for external link syntax
manuals: replace "_" by "__" in external links
manuals: stop referring to the meta-openembedded repo from GitHub
manuals: add missing references to SDKMACHINE and SDK_ARCH
manuals: use references to the "Build Directory" term
create-spdx.bbclass: remove unused SPDX_INCLUDE_PACKAGED
Mikko Rapeli (6):
os-release: replace DISTRO_CODENAME with VERSION_CODENAME
os-release: add HOMEPAGE and link to documentation
ref-manual: variables.rst: add documentation for CVE_VERSION
ref-manual: classes.rst: improve documentation for cve-check.bbclass
dev-manual: common-tasks.rst: add regular updates and CVE scans to security best practices
dev-manual: common-tasks.rst: refactor and improve "Checking for Vulnerabilities" section
Ming Liu (1):
dropbear: add pam to PACKAGECONFIG
Mingli Yu (1):
grub: disable build on armv7ve/a with hardfp
Oliver Lang (2):
bitbake: cooker: fix a typo
bitbake: runqueue: fix a typo
Pablo Saavedra Rodi?o (1):
weston: update 10.0.2 -> 11.0.0
Paul Eggleton (2):
install-buildtools: support buildtools-make-tarball and update to 4.1
ref-manual: add info on buildtools-make-tarball
Peter Bergin (1):
gptfdisk: remove warning message from target system
Peter Kjellerstedt (3):
gcc: Allow -Wno-error=poison-system-directories to take effect
base-passwd: Update to 3.6.1
externalsrc.bbclass: Remove a trailing slash from ${B}
Qiu, Zheng (2):
tiff: fix a typo for CVE-2022-2953.patch
valgrind: update to 3.20.0
Quentin Schulz (1):
docs: add support for langdale (4.1) release
Richard Purdie (4):
openssl: Fix SSL_CERT_FILE to match ca-certs location
bitbake: tests/fetch: Allow handling of a file:// url within a submodule
patchelf: upgrade 0.15.0 -> 0.16.1
lttng-modules: upgrade 2.13.5 -> 2.13.7
Robert Joslyn (1):
curl: Update 7.85.0 to 7.86.0
Ross Burton (26):
populate_sdk_base: ensure ptest-pkgs pulls in ptest-runner
scripts/oe-check-sstate: cleanup
scripts/oe-check-sstate: force build to run for all targets, specifically populate_sysroot
externalsrc: move back to classes
opkg-utils: use a git clone, not a dynamic snapshot
oe/packagemanager/rpm: don't leak file objects
zlib: use .gz archive and set a PREMIRROR
glib-2.0: fix rare GFileInfo test case failure
lighttpd: fix CVE-2022-41556
acpid: upgrade 2.0.33 -> 2.0.34
python3-hatchling: upgrade 1.9.0 -> 1.10.0
pango: upgrade 1.50.9 -> 1.50.10
piglit: upgrade to latest revision
lsof: upgrade 4.95.0 -> 4.96.3
zlib: do out-of-tree builds
zlib: upgrade 1.2.12 -> 1.2.13
libx11: apply the fix for CVE-2022-3554
xserver-xorg: ignore CVE-2022-3553 as it is XQuartz-specific
xserver-xorg: backport fixes for CVE-2022-3550 and CVE-2022-3551
tiff: fix a number of CVEs
qemu: backport the fix for CVE-2022-3165
bitbake: fetch2/git: don't set core.fsyncobjectfiles=0
sanity: check for GNU tar specifically
expat: upgrade to 2.5.0
oeqa/target/ssh: add ignore_status argument to run()
oeqa/runtime/dnf: rewrite test_dnf_installroot_usrmerge
Sakib Sajal (1):
go: update 1.19.2 -> 1.19.3
Sean Anderson (6):
uboot-sign: Fix using wrong KEY_REQ_ARGS
kernel: Clear SYSROOT_DIRS instead of replacing sysroot_stage_all
kernel-fitimage: Use KERNEL_OUTPUT_DIR where appropriate
uboot-sign: Use bitbake variables directly
uboot-sign: Split off kernel-fitimage variables
u-boot: Rework signing to remove interdependencies
Sergei Zhmylev (2):
wic: implement binary repeatable disk identifiers
wic: honor the SOURCE_DATE_EPOCH in case of updated fstab
Teoh Jay Shen (1):
vim: Upgrade 9.0.0598 -> 9.0.0614
Thomas Perrot (2):
psplash: add psplash-default in rdepends
xserver-xorg: move some recommended dependencies in required
Tim Orling (23):
python3-cryptography: upgrade 37.0.4 -> 38.0.1
python3-cryptography-vectors: upgrade 37.0.4 -> 38.0.1
python3-certifi: upgrade 2022.9.14 -> 2022.9.24
python3-hypothesis: upgrade 6.54.5 -> 6.56.1
python3-pyopenssl: upgrade 22.0.0 -> 22.1.0
python3-bcrypt: upgrade 3.2.2 -> 4.0.0
python3-sphinx: upgrade 5.1.1 -> 5.2.3
python3-setuptools-rust: upgrade 1.5.1 -> 1.5.2
python3-iso8601: upgrade 1.0.2 -> 1.1.0
python3-poetry-core: upgrade 1.0.8 -> 1.3.2
git: upgrade 2.37.3 -> 2.38.1
vim: upgrade 9.0.0614 -> 9.0.0820
python3-mako: upgrade 1.2.2 -> 1.2.3
python3-bcrypt: upgrade 4.0.0 -> 4.0.1
python3-cryptography{-vectors}: 38.0.1 -> 38.0.3
python3-psutil: upgrade 5.9.2 -> 5.9.3
python3-pytest: upgrade 7.1.3 -> 7.2.0
python3-pytest-subtests: upgrade 0.8.0 -> 0.9.0
python3-hypothesis: upgrade 6.56.1 -> 6.56.4
python3-more-itertools: upgrade 8.14.0 -> 9.0.0
python3-pytz: upgrade 2022.4 -> 2022.6
python3-zipp: upgrade 3.9.0 -> 3.10.0
python3-sphinx: upgrade 5.2.3 -> 5.3.0
Vincent Davis Jr (1):
linux-firmware: package amdgpu firmware
Vyacheslav Yurkov (1):
overlayfs: Allow not used mount points
Xiangyu Chen (1):
linux-yocto-dev: add qemuarm64
Yan Xinkuan (1):
bc: Add ptest.
ciarancourtney (1):
wic: swap partitions are not added to fstab
wangmy (32):
init-system-helpers: upgrade 1.64 -> 1.65.2
meson: upgrade 0.63.2 -> 0.63.3
mtools: upgrade 4.0.40 -> 4.0.41
dbus: upgrade 1.14.0 -> 1.14.4
ifupdown: upgrade 0.8.37 -> 0.8.39
openssh: upgrade 9.0p1 -> 9.1p1
python3-hatchling: upgrade 1.10.0 -> 1.11.0
u-boot: upgrade 2022.07 -> 2022.10
python3-git: upgrade 3.1.27 -> 3.1.28
python3-importlib-metadata: upgrade 4.12.0 -> 5.0.0
gnutls: upgrade 3.7.7 -> 3.7.8
gsettings-desktop-schemas: upgrade 42.0 -> 43.0
harfbuzz: upgrade 5.1.0 -> 5.3.0
libcap: upgrade 2.65 -> 2.66
libical: upgrade 3.0.14 -> 3.0.15
libva: upgrade 2.15.0 -> 2.16.0
libva-utils: upgrade 2.15.0 -> 2.16.0
powertop: upgrade 2.14 -> 2.15
numactl: upgrade 2.0.15 -> 2.0.16
python3-pytz: upgrade 2022.2.1 -> 2022.4
python3-zipp: upgrade 3.8.1 -> 3.9.0
repo: upgrade 2.29.2 -> 2.29.3
sqlite3: upgrade 3.39.3 -> 3.39.4
wpebackend-fdo: upgrade 1.12.1 -> 1.14.0
xkeyboard-config: upgrade 2.36 -> 2.37
xz: upgrade 5.2.6 -> 5.2.7
libksba: upgrade 1.6.0 -> 1.6.2
libsdl2: upgrade 2.24.0 -> 2.24.1
libwpe: upgrade 1.12.3 -> 1.14.0
lttng-ust: upgrade 2.13.4 -> 2.13.5
btrfs-tools: upgrade 5.19.1 -> 6.0
lighttpd: upgrade 1.4.66 -> 1.4.67
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: I3322dd0057da9f05bb2ba216fdcda3f569c0493b
diff --git a/poky/documentation/dev-manual/common-tasks.rst b/poky/documentation/dev-manual/common-tasks.rst
index 53e7686..c747c0d 100644
--- a/poky/documentation/dev-manual/common-tasks.rst
+++ b/poky/documentation/dev-manual/common-tasks.rst
@@ -418,10 +418,10 @@
Before the OpenEmbedded build system can use your new layer, you need to
enable it. To enable your layer, simply add your layer's path to the
:term:`BBLAYERS` variable in your ``conf/bblayers.conf`` file, which is
-found in the :term:`Build Directory`.
-The following example shows how to enable your new
-``meta-mylayer`` layer (note how your new layer exists outside of
-the official ``poky`` repository which you would have checked out earlier)::
+found in the :term:`Build Directory`. The following example shows how to
+enable your new ``meta-mylayer`` layer (note how your new layer exists
+outside of the official ``poky`` repository which you would have checked
+out earlier)::
# POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
@@ -969,8 +969,7 @@
variables. Although the functions for both variables are nearly
equivalent, best practices dictate using :term:`IMAGE_FEATURES` from within
a recipe and using :term:`EXTRA_IMAGE_FEATURES` from within your
-``local.conf`` file, which is found in the
-:term:`Build Directory`.
+``local.conf`` file, which is found in the :term:`Build Directory`.
To understand how these features work, the best reference is
:ref:`meta/classes-recipe/image.bbclass <ref-classes-image>`.
@@ -1206,11 +1205,10 @@
``recipetool`` results in a recipe that has the pre-build dependencies,
license requirements, and checksums configured.
-To run the tool, you just need to be in your
-:term:`Build Directory` and have sourced the
-build environment setup script (i.e.
-:ref:`structure-core-script`).
-To get help on the tool, use the following command::
+To run the tool, you just need to be in your :term:`Build Directory` and
+have sourced the build environment setup script (i.e.
+:ref:`structure-core-script`). To get help on the tool, use the following
+command::
$ recipetool -h
NOTE: Starting bitbake server...
@@ -1342,8 +1340,7 @@
progressively discover and add information to the recipe file.
Assuming you have sourced the build environment setup script (i.e.
-:ref:`structure-core-script`) and you are in
-the :term:`Build Directory`, use
+:ref:`structure-core-script`) and you are in the :term:`Build Directory`, use
BitBake to process your recipe. All you need to provide is the
``basename`` of the recipe as described in the previous section::
@@ -1362,7 +1359,7 @@
$ bitbake -e basename | grep ^WORKDIR=
As an example, assume a Source Directory
-top-level folder named ``poky``, a default Build Directory at
+top-level folder named ``poky``, a default :term:`Build Directory` at
``poky/build``, and a ``qemux86-poky-linux`` machine target system.
Furthermore, suppose your recipe is named ``foo_1.3.0.bb``. In this
case, the work directory the build system uses to build the package
@@ -3017,15 +3014,14 @@
AUH is not part of the :term:`OpenEmbedded-Core (OE-Core)` or
:term:`Poky` repositories.
-4. *Create a Dedicated Build Directory:* Run the
- :ref:`structure-core-script`
- script to create a fresh build directory that you use exclusively for
- running the AUH utility::
+4. *Create a Dedicated Build Directory:* Run the :ref:`structure-core-script`
+ script to create a fresh :term:`Build Directory` that you use exclusively
+ for running the AUH utility::
$ cd poky
$ source oe-init-build-env your_AUH_build_directory
- Re-using an existing build directory and its configurations is not
+ Re-using an existing :term:`Build Directory` and its configurations is not
recommended as existing settings could cause AUH to fail or behave
undesirably.
@@ -3045,7 +3041,7 @@
With this configuration and a successful
upgrade, a build history "diff" file appears in the
``upgrade-helper/work/recipe/buildhistory-diff.txt`` file found in
- your build directory.
+ your :term:`Build Directory`.
- If you want to enable testing through the
:ref:`testimage <ref-classes-testimage>`
@@ -3070,7 +3066,7 @@
7. *Create and Edit an AUH Configuration File:* You need to have the
``upgrade-helper/upgrade-helper.conf`` configuration file in your
- build directory. You can find a sample configuration file in the
+ :term:`Build Directory`. You can find a sample configuration file in the
:yocto_git:`AUH source repository </auto-upgrade-helper/tree/>`.
Read through the sample file and make configurations as needed. For
@@ -3118,7 +3114,7 @@
$ upgrade-helper.py -e all
Once you have run the AUH utility, you can find the results in the AUH
-build directory::
+:term:`Build Directory`::
${BUILDDIR}/upgrade-helper/timestamp
@@ -3179,8 +3175,7 @@
/home/scottrif/meta-openembedded
-The following command from your
-:term:`Build Directory` adds the layer to
+The following command from your :term:`Build Directory` adds the layer to
your build configuration (i.e. ``${BUILDDIR}/conf/bblayers.conf``)::
$ bitbake-layers add-layer /home/scottrif/meta-openembedded/meta-oe
@@ -3341,16 +3336,14 @@
are developing a patch and you need to experiment a bit to figure out
your solution. After you have initially built the package, you can
iteratively tweak the source code, which is located in the
-:term:`Build Directory`, and then you can
-force a re-compile and quickly test your altered code. Once you settle
-on a solution, you can then preserve your changes in the form of
-patches.
+:term:`Build Directory`, and then you can force a re-compile and quickly
+test your altered code. Once you settle on a solution, you can then preserve
+your changes in the form of patches.
During a build, the unpacked temporary source code used by recipes to
-build packages is available in the Build Directory as defined by the
-:term:`S` variable. Below is the default
-value for the :term:`S` variable as defined in the
-``meta/conf/bitbake.conf`` configuration file in the
+build packages is available in the :term:`Build Directory` as defined by the
+:term:`S` variable. Below is the default value for the :term:`S` variable as
+defined in the ``meta/conf/bitbake.conf`` configuration file in the
:term:`Source Directory`::
S = "${WORKDIR}/${BP}"
@@ -3392,7 +3385,7 @@
- :term:`PR`: The recipe revision.
As an example, assume a Source Directory top-level folder named
-``poky``, a default Build Directory at ``poky/build``, and a
+``poky``, a default :term:`Build Directory` at ``poky/build``, and a
``qemux86-poky-linux`` machine target system. Furthermore, suppose your
recipe is named ``foo_1.3.0.bb``. In this case, the work directory the
build system uses to build the package would be as follows::
@@ -3420,8 +3413,7 @@
Follow these general steps:
1. *Find the Source Code:* Temporary source code used by the
- OpenEmbedded build system is kept in the
- :term:`Build Directory`. See the
+ OpenEmbedded build system is kept in the :term:`Build Directory`. See the
":ref:`dev-manual/common-tasks:finding temporary source code`" section to
learn how to locate the directory that has the temporary source code for a
particular package.
@@ -3649,10 +3641,10 @@
:doc:`/brief-yoctoprojectqs/index` document.
The build process creates an entire Linux distribution from source and
-places it in your :term:`Build Directory` under
-``tmp/deploy/images``. For detailed information on the build process
-using BitBake, see the ":ref:`overview-manual/concepts:images`" section in the
-Yocto Project Overview and Concepts Manual.
+places it in your :term:`Build Directory` under ``tmp/deploy/images``. For
+detailed information on the build process using BitBake, see the
+":ref:`overview-manual/concepts:images`" section in the Yocto Project Overview
+and Concepts Manual.
The following figure and list overviews the build process:
@@ -3672,25 +3664,23 @@
When you use the initialization script, the OpenEmbedded build system
uses ``build`` as the default :term:`Build Directory` in your current work
directory. You can use a `build_dir` argument with the script to
- specify a different build directory.
+ specify a different :term:`Build Directory`.
.. note::
- A common practice is to use a different Build Directory for
+ A common practice is to use a different :term:`Build Directory` for
different targets; for example, ``~/build/x86`` for a ``qemux86``
target, and ``~/build/arm`` for a ``qemuarm`` target. In any
- event, it's typically cleaner to locate the build directory
+ event, it's typically cleaner to locate the :term:`Build Directory`
somewhere outside of your source directory.
3. *Make Sure Your* ``local.conf`` *File is Correct*: Ensure the
- ``conf/local.conf`` configuration file, which is found in the Build
- Directory, is set up how you want it. This file defines many aspects
- of the build environment including the target machine architecture
+ ``conf/local.conf`` configuration file, which is found in the
+ :term:`Build Directory`, is set up how you want it. This file defines many
+ aspects of the build environment including the target machine architecture
through the :term:`MACHINE` variable, the packaging format used during
- the build
- (:term:`PACKAGE_CLASSES`),
- and a centralized tarball download directory through the
- :term:`DL_DIR` variable.
+ the build (:term:`PACKAGE_CLASSES`), and a centralized tarball download
+ directory through the :term:`DL_DIR` variable.
4. *Build the Image:* Build the image using the ``bitbake`` command::
@@ -3718,7 +3708,7 @@
Once an
image has been built, it often needs to be installed. The images and
kernels built by the OpenEmbedded build system are placed in the
- Build Directory in ``tmp/deploy/images``. For information on how to
+ :term:`Build Directory` in ``tmp/deploy/images``. For information on how to
run pre-built images such as ``qemux86`` and ``qemuarm``, see the
:doc:`/sdk-manual/index` manual. For
information about how to install these images, see the documentation
@@ -3772,7 +3762,7 @@
TMPDIR = "${TOPDIR}/tmpmultix86"
The location for these multiconfig configuration files is specific.
- They must reside in the current build directory in a sub-directory of
+ They must reside in the current :term:`Build Directory` in a sub-directory of
``conf`` named ``multiconfig`` or within a layer's ``conf`` directory
under a directory named ``multiconfig``. Following is an example that defines
two configuration files for the "x86" and "arm" multiconfigs:
@@ -4275,15 +4265,13 @@
should consider the points in this section that can help you optimize
your tunings to best consider build times and package feed maintenance.
-- *Share the Build Directory:* If at all possible, share the
- :term:`TMPDIR` across builds. The
- Yocto Project supports switching between different
- :term:`MACHINE` values in the same
- :term:`TMPDIR`. This practice is well supported and regularly used by
- developers when building for multiple machines. When you use the same
- :term:`TMPDIR` for multiple machine builds, the OpenEmbedded build system
- can reuse the existing native and often cross-recipes for multiple
- machines. Thus, build time decreases.
+- *Share the :term:`Build Directory`:* If at all possible, share the
+ :term:`TMPDIR` across builds. The Yocto Project supports switching between
+ different :term:`MACHINE` values in the same :term:`TMPDIR`. This practice
+ is well supported and regularly used by developers when building for
+ multiple machines. When you use the same :term:`TMPDIR` for multiple
+ machine builds, the OpenEmbedded build system can reuse the existing native
+ and often cross-recipes for multiple machines. Thus, build time decreases.
.. note::
@@ -4399,10 +4387,10 @@
Building Software from an External Source
-----------------------------------------
-By default, the OpenEmbedded build system uses the
-:term:`Build Directory` when building source
-code. The build process involves fetching the source files, unpacking
-them, and then patching them if necessary before the build takes place.
+By default, the OpenEmbedded build system uses the :term:`Build Directory`
+when building source code. The build process involves fetching the source
+files, unpacking them, and then patching them if necessary before the build
+takes place.
There are situations where you might want to build software from source
files that are external to and thus outside of the OpenEmbedded build
@@ -4519,9 +4507,8 @@
from your "own-mirror" are used.
2. *Start With a Clean Build:* You can start with a clean build by
- removing the
- ``${``\ :term:`TMPDIR`\ ``}``
- directory or using a new :term:`Build Directory`.
+ removing the ``${``\ :term:`TMPDIR`\ ``}`` directory or using a new
+ :term:`Build Directory`.
3. *Build Your Target:* Use BitBake to build your target::
@@ -4622,8 +4609,7 @@
the benefits are limited due to the compiler using ``-pipe``. The
build system goes to some lengths to avoid ``sync()`` calls into the
file system on the principle that if there was a significant failure,
- the :term:`Build Directory`
- contents could easily be rebuilt.
+ the :term:`Build Directory` contents could easily be rebuilt.
- Inheriting the
:ref:`rm_work <ref-classes-rm-work>` class:
@@ -4820,8 +4806,7 @@
After you have set up the recipes, you need to define the actual
combination of multiple libraries you want to build. You accomplish this
through your ``local.conf`` configuration file in the
-:term:`Build Directory`. An example
-configuration would be as follows::
+:term:`Build Directory`. An example configuration would be as follows::
MACHINE = "qemux86-64"
require conf/multilib.conf
@@ -4871,10 +4856,9 @@
- A unique architecture is defined for the Multilib packages, along
with creating a unique deploy folder under ``tmp/deploy/rpm`` in the
- :term:`Build Directory`. For
- example, consider ``lib32`` in a ``qemux86-64`` image. The possible
- architectures in the system are "all", "qemux86_64",
- "lib32:qemux86_64", and "lib32:x86".
+ :term:`Build Directory`. For example, consider ``lib32`` in a
+ ``qemux86-64`` image. The possible architectures in the system are "all",
+ "qemux86_64", "lib32:qemux86_64", and "lib32:x86".
- The ``${MLPREFIX}`` variable is stripped from ``${PN}`` during RPM
packaging. The naming for a normal RPM package and a Multilib RPM
@@ -5460,8 +5444,7 @@
your development host system.
- You must have sourced the build environment setup script (i.e.
- :ref:`structure-core-script`) found in the
- :term:`Build Directory`.
+ :ref:`structure-core-script`) found in the :term:`Build Directory`.
- You need to have the build artifacts already available, which
typically means that you must have already created an image using the
@@ -5569,11 +5552,10 @@
Running Wic in raw mode allows you to specify all the partitions through
the ``wic`` command line. The primary use for raw mode is if you have
-built your kernel outside of the Yocto Project
-:term:`Build Directory`. In other words, you
-can point to arbitrary kernel, root filesystem locations, and so forth.
-Contrast this behavior with cooked mode where Wic looks in the Build
-Directory (e.g. ``tmp/deploy/images/``\ machine).
+built your kernel outside of the Yocto Project :term:`Build Directory`.
+In other words, you can point to arbitrary kernel, root filesystem locations,
+and so forth. Contrast this behavior with cooked mode where Wic looks in the
+:term:`Build Directory` (e.g. ``tmp/deploy/images/``\ machine).
The general form of the ``wic`` command in raw mode is::
@@ -5626,11 +5608,11 @@
Cooked Mode
~~~~~~~~~~~
-Running Wic in cooked mode leverages off artifacts in the Build
-Directory. In other words, you do not have to specify kernel or root
-filesystem locations as part of the command. All you need to provide is
+Running Wic in cooked mode leverages off artifacts in the
+:term:`Build Directory`. In other words, you do not have to specify kernel or
+root filesystem locations as part of the command. All you need to provide is
a kickstart file and the name of the image from which to use artifacts
-by using the "-e" option. Wic looks in the Build Directory (e.g.
+by using the "-e" option. Wic looks in the :term:`Build Directory` (e.g.
``tmp/deploy/images/``\ machine) for artifacts.
The general form of the ``wic`` command using Cooked Mode is as follows::
@@ -5878,9 +5860,9 @@
You should always verify the details provided in the output to make
sure that the image was indeed created exactly as expected.
-Continuing with the example, you can now write the image from the Build
-Directory onto a USB stick, or whatever media for which you built your
-image, and boot from the media. You can write the image by using
+Continuing with the example, you can now write the image from the
+:term:`Build Directory` onto a USB stick, or whatever media for which you
+built your image, and boot from the media. You can write the image by using
``bmaptool`` or ``dd``::
$ oe-run-native bmap-tools-native bmaptool copy mkefidisk-201804191017-sda.direct /dev/sdX
@@ -6152,7 +6134,7 @@
3. *Flash the Device:* Flash the device with the image by using Bmaptool
depending on your particular setup. The following commands assume the
- image resides in the Build Directory's ``deploy/images/`` area:
+ image resides in the :term:`Build Directory`'s ``deploy/images/`` area:
- If you have write access to the media, use this command form::
@@ -6231,6 +6213,13 @@
vulnerabilities discovered in the future. This consideration
especially applies when your device is network-enabled.
+- Regularly scan and apply fixes for CVE security issues affecting
+ all software components in the product, see ":ref:`dev-manual/common-tasks:checking for vulnerabilities`".
+
+- Regularly update your version of Poky and OE-Core from their upstream
+ developers, e.g. to apply updates and security fixes from stable
+ and LTS branches.
+
- Ensure you remove or disable debugging functionality before producing
the final image. For information on how to do this, see the
":ref:`dev-manual/common-tasks:considerations specific to the openembedded build system`"
@@ -6392,11 +6381,9 @@
variable from the ``local.conf`` file. The variables you use are not
limited to the list in the previous bulleted item.
-- *Point to Your distribution configuration file:* In your
- ``local.conf`` file in the :term:`Build Directory`,
- set your
- :term:`DISTRO` variable to point to
- your distribution's configuration file. For example, if your
+- *Point to Your distribution configuration file:* In your ``local.conf``
+ file in the :term:`Build Directory`, set your :term:`DISTRO` variable to
+ point to your distribution's configuration file. For example, if your
distribution's configuration file is named ``mydistro.conf``, then
you point to it as follows::
@@ -6431,7 +6418,7 @@
If you are producing your own customized version of the build system for
use by other users, you might want to provide a custom build configuration
that includes all the necessary settings and layers (i.e. ``local.conf`` and
-``bblayers.conf`` that are created in a new build directory) and a custom
+``bblayers.conf`` that are created in a new :term:`Build Directory`) and a custom
message that is shown when setting up the build. This can be done by
creating one or more template configuration directories in your
custom distribution layer.
@@ -6445,7 +6432,7 @@
You can try out the configuration with
TEMPLATECONF=/srv/work/alex/meta-alex/conf/templates/test-1 . /srv/work/alex/poky/oe-init-build-env build-try-test-1
-The above command takes the config files from the currently active build directory under ``conf``,
+The above command takes the config files from the currently active :term:`Build Directory` under ``conf``,
replaces site-specific paths in ``bblayers.conf`` with ``##OECORE##``-relative paths, and copies
the config files into a specified layer under a specified template name.
@@ -6677,10 +6664,9 @@
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 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
+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
``local.conf`` file in the :term:`Build Directory`::
PRSERV_HOST = "localhost:0"
@@ -7036,7 +7022,7 @@
machine could push its artifacts to another machine that acts as the
server (e.g. Internet-facing). In fact, doing so is advantageous for a
production environment as getting the packages away from the development
-system's build directory prevents accidental overwrites.
+system's :term:`Build Directory` prevents accidental overwrites.
A simple build that targets just one device produces more than one
package database. In other words, the packages produced by a build are
@@ -7068,8 +7054,7 @@
:term:`PACKAGE_CLASSES`
variable to specify the format:
-1. Open the ``local.conf`` file inside your
- :term:`Build Directory` (e.g.
+1. Open the ``local.conf`` file inside your :term:`Build Directory` (e.g.
``poky/build/conf/local.conf``).
2. Select the desired package format as follows::
@@ -7155,12 +7140,10 @@
to use a different server more suited for production (e.g. Apache 2,
Lighttpd, or Nginx), take the appropriate steps to do so.
-From within the build directory where you have built an image based on
-your packaging choice (i.e. the
-:term:`PACKAGE_CLASSES`
-setting), simply start the server. The following example assumes a build
-directory of ``poky/build/tmp/deploy/rpm`` and a :term:`PACKAGE_CLASSES`
-setting of "package_rpm"::
+From within the :term:`Build Directory` where you have built an image based on
+your packaging choice (i.e. the :term:`PACKAGE_CLASSES` setting), simply start
+the server. The following example assumes a :term:`Build Directory` of ``poky/build``
+and a :term:`PACKAGE_CLASSES` setting of "package_rpm"::
$ cd poky/build/tmp/deploy/rpm
$ python3 -m http.server
@@ -7432,11 +7415,9 @@
Adding ptest to Your Build
~~~~~~~~~~~~~~~~~~~~~~~~~~
-To add package testing to your build, add the
-:term:`DISTRO_FEATURES` and
-:term:`EXTRA_IMAGE_FEATURES`
-variables to your ``local.conf`` file, which is found in the
-:term:`Build Directory`::
+To add package testing to your build, add the :term:`DISTRO_FEATURES` and
+:term:`EXTRA_IMAGE_FEATURES` variables to your ``local.conf`` file, which
+is found in the :term:`Build Directory`::
DISTRO_FEATURES:append = " ptest"
EXTRA_IMAGE_FEATURES += "ptest-pkgs"
@@ -7547,17 +7528,16 @@
- Of the two methods that you can use ``devtool`` to create NPM
packages, the registry approach is slightly simpler. However, you
might consider the project approach because you do not have to
- publish your module in the NPM registry
- (`npm-registry <https://docs.npmjs.com/misc/registry>`_), which
- is NPM's public registry.
+ publish your module in the `NPM registry <https://docs.npmjs.com/misc/registry>`__,
+ which is NPM's public registry.
- Be familiar with
:doc:`devtool </ref-manual/devtool-reference>`.
- The NPM host tools need the native ``nodejs-npm`` package, which is
part of the OpenEmbedded environment. You need to get the package by
- cloning the https://github.com/openembedded/meta-openembedded
- repository out of GitHub. Be sure to add the path to your local copy
+ cloning the :oe_git:`meta-openembedded </meta-openembedded>`
+ repository. Be sure to add the path to your local copy
to your ``bblayers.conf`` file.
- ``devtool`` cannot detect native libraries in module dependencies.
@@ -8087,7 +8067,7 @@
IMAGE_FEATURES += "read-only-rootfs"
As an alternative, you can add the same feature
-from within your build directory's ``local.conf`` file with the
+from within your :term:`Build Directory`'s ``local.conf`` file with the
associated :term:`EXTRA_IMAGE_FEATURES` variable, as in::
EXTRA_IMAGE_FEATURES = "read-only-rootfs"
@@ -8182,9 +8162,8 @@
------------------------------------
Build history is disabled by default. To enable it, add the following
-:term:`INHERIT` statement and set the
-:term:`BUILDHISTORY_COMMIT`
-variable to "1" at the end of your ``conf/local.conf`` file found in the
+:term:`INHERIT` statement and set the :term:`BUILDHISTORY_COMMIT` variable to
+"1" at the end of your ``conf/local.conf`` file found in the
:term:`Build Directory`::
INHERIT += "buildhistory"
@@ -8207,10 +8186,8 @@
Understanding What the Build History Contains
---------------------------------------------
-Build history information is kept in
-``${``\ :term:`TOPDIR`\ ``}/buildhistory``
-in the Build Directory as defined by the
-:term:`BUILDHISTORY_DIR`
+Build history information is kept in ``${``\ :term:`TOPDIR`\ ``}/buildhistory``
+in the :term:`Build Directory` as defined by the :term:`BUILDHISTORY_DIR`
variable. Here is an example abbreviated listing:
.. image:: figures/buildhistory.png
@@ -8877,11 +8854,9 @@
You can start the tests automatically or manually:
-- *Automatically running tests:* To run the tests automatically after
- the OpenEmbedded build system successfully creates an image, first
- set the
- :term:`TESTIMAGE_AUTO`
- variable to "1" in your ``local.conf`` file in the
+- *Automatically running tests:* To run the tests automatically after the
+ OpenEmbedded build system successfully creates an image, first set the
+ :term:`TESTIMAGE_AUTO` variable to "1" in your ``local.conf`` file in the
:term:`Build Directory`::
TESTIMAGE_AUTO = "1"
@@ -8976,10 +8951,9 @@
$ bitbake image -c testexport
-Exporting the tests places them in the
-:term:`Build Directory` in
-``tmp/testexport/``\ image, which is controlled by the
-:term:`TEST_EXPORT_DIR` variable.
+Exporting the tests places them in the :term:`Build Directory` in
+``tmp/testexport/``\ image, which is controlled by the :term:`TEST_EXPORT_DIR`
+variable.
You can now run the tests outside of the build environment::
@@ -9206,9 +9180,8 @@
- ":ref:`dev-manual/common-tasks:viewing task variable dependencies`" describes
how to use the ``bitbake-dumpsig`` command in conjunction with key
- subdirectories in the
- :term:`Build Directory` to determine
- variable dependencies.
+ subdirectories in the :term:`Build Directory` to determine variable
+ dependencies.
- ":ref:`dev-manual/common-tasks:running specific tasks`" describes
how to use several BitBake options (e.g. ``-c``, ``-C``, and ``-f``)
@@ -10357,13 +10330,11 @@
is also possible to switch out of the splashscreen by switching the
virtual console (e.g. Fn+Left or Fn+Right on a Zaurus).
-- Removing :term:`TMPDIR` (usually
- ``tmp/``, within the
- :term:`Build Directory`) can often fix
- temporary build issues. Removing :term:`TMPDIR` is usually a relatively
- cheap operation, because task output will be cached in
- :term:`SSTATE_DIR` (usually
- ``sstate-cache/``, which is also in the Build Directory).
+- Removing :term:`TMPDIR` (usually ``tmp/``, within the
+ :term:`Build Directory`) can often fix temporary build issues. Removing
+ :term:`TMPDIR` is usually a relatively cheap operation, because task output
+ will be cached in :term:`SSTATE_DIR` (usually ``sstate-cache/``, which is
+ also in the :term:`Build Directory`).
.. note::
@@ -10377,8 +10348,8 @@
Using GNU Grep, you can use the following shell function to
recursively search through common recipe-related files, skipping
- binary files, ``.git`` directories, and the Build Directory (assuming
- its name starts with "build")::
+ binary files, ``.git`` directories, and the :term:`Build Directory`
+ (assuming its name starts with "build")::
g() {
grep -Ir \
@@ -11276,8 +11247,7 @@
One way of doing this (but certainly not the only way) is to release
just the source as a tarball. You can do this by adding the following to
-the ``local.conf`` file found in the
-:term:`Build Directory`::
+the ``local.conf`` file found in the :term:`Build Directory`::
INHERIT += "archiver"
ARCHIVER_MODE[src] = "original"
@@ -11436,9 +11406,9 @@
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`. Here is an example showing how to generate spdx files
- during BitBake using the fossology-python.bbclass::
+ add some config options in ``local.conf`` file in your :term:`Build Directory`.
+ Here is an example showing how to generate spdx files during BitBake using the
+ fossology-python.bbclass::
# Select fossology-python.bbclass.
INHERIT += "fossology-python"
@@ -11495,8 +11465,8 @@
Checking for Vulnerabilities
============================
-Vulnerabilities in images
--------------------------
+Vulnerabilities in Poky and OE-Core
+-----------------------------------
The Yocto Project has an infrastructure to track and address unfixed
known security vulnerabilities, as tracked by the public
@@ -11509,14 +11479,78 @@
unpatched CVEs and the status of patches. Such information is available for
the current development version and for each supported release.
-To know which packages are vulnerable to known security vulnerabilities
-in the specific image you are building, add the following setting to your
-configuration::
+Security is a process, not a product, and thus at any time, a number of security
+issues may be impacting Poky and OE-Core. It is up to the maintainers, users,
+contributors and anyone interested in the issues to investigate and possibly fix them by
+updating software components to newer versions or by applying patches to address them.
+It is recommended to work with Poky and OE-Core upstream maintainers and submit
+patches to fix them, see ":ref:`dev-manual/common-tasks:submitting a change to the yocto project`" for details.
+
+Vulnerability check at build time
+---------------------------------
+
+To enable a check for CVE security vulnerabilities using :ref:`cve-check <ref-classes-cve-check>` in the specific image
+or target you are building, add the following setting to your configuration::
INHERIT += "cve-check"
-This way, at build time, BitBake will warn you about known CVEs
-as in the example below::
+The CVE database contains some old incomplete entries which have been
+deemed not to impact Poky or OE-Core. These CVE entries can be excluded from the
+check using build configuration::
+
+ include conf/distro/include/cve-extra-exclusions.inc
+
+With this CVE check enabled, BitBake build will try to map each compiled software component
+recipe name and version information to the CVE database and generate recipe and
+image specific reports. These reports will contain:
+
+- metadata about the software component like names and versions
+
+- metadata about the CVE issue such as description and NVD link
+
+- for each software component, a list of CVEs which are possibly impacting this version
+
+- status of each CVE: ``Patched``, ``Unpatched`` or ``Ignored``
+
+The status ``Patched`` means that a patch file to address the security issue has been
+applied. ``Unpatched`` status means that no patches to address the issue have been
+applied and that the issue needs to be investigated. ``Ignored`` means that after
+analysis, it has been deemed to ignore the issue as it for example affects
+the software component on a different operating system platform.
+
+After build with CVE check enabled, reports for each compiled source recipe will be
+found in ``build/tmp/deploy/cve``.
+
+For example the CVE check report for the ``flex-native`` recipe looks like::
+
+ $ cat poky/build/tmp/deploy/cve/flex-native
+ LAYER: meta
+ PACKAGE NAME: flex-native
+ PACKAGE VERSION: 2.6.4
+ CVE: CVE-2016-6354
+ CVE STATUS: Patched
+ CVE SUMMARY: Heap-based buffer overflow in the yy_get_next_buffer function in Flex before 2.6.1 might allow context-dependent attackers to cause a denial of service or possibly execute arbitrary code via vectors involving num_to_read.
+ CVSS v2 BASE SCORE: 7.5
+ CVSS v3 BASE SCORE: 9.8
+ VECTOR: NETWORK
+ MORE INFORMATION: https://nvd.nist.gov/vuln/detail/CVE-2016-6354
+
+ LAYER: meta
+ PACKAGE NAME: flex-native
+ PACKAGE VERSION: 2.6.4
+ CVE: CVE-2019-6293
+ CVE STATUS: Ignored
+ CVE SUMMARY: An issue was discovered in the function mark_beginning_as_normal in nfa.c in flex 2.6.4. There is a stack exhaustion problem caused by the mark_beginning_as_normal function making recursive calls to itself in certain scenarios involving lots of '*' characters. Remote attackers could leverage this vulnerability to cause a denial-of-service.
+ CVSS v2 BASE SCORE: 4.3
+ CVSS v3 BASE SCORE: 5.5
+ VECTOR: NETWORK
+ MORE INFORMATION: https://nvd.nist.gov/vuln/detail/CVE-2019-6293
+
+For images, a summary of all recipes included in the image and their CVEs is also
+generated in textual and JSON formats. These ``.cve`` and ``.json`` reports can be found
+in the ``tmp/deploy/images`` directory for each compiled image.
+
+At build time CVE check will also throw warnings about ``Unpatched`` CVEs::
WARNING: flex-2.6.4-r0 do_cve_check: Found unpatched CVE (CVE-2019-6293), for more information check /poky/build/tmp/work/core2-64-poky-linux/flex/2.6.4-r0/temp/cve.log
WARNING: libarchive-3.5.1-r0 do_cve_check: Found unpatched CVE (CVE-2021-36976), for more information check /poky/build/tmp/work/core2-64-poky-linux/libarchive/3.5.1-r0/temp/cve.log
@@ -11525,21 +11559,46 @@
bitbake -c cve_check flex libarchive
-Note that OpenEmbedded-Core keeps a list of known unfixed CVE issues which can
-be ignored. You can pass this list to the check as follows::
+Fixing CVE product name and version mappings
+--------------------------------------------
- bitbake -c cve_check libarchive -R conf/distro/include/cve-extra-exclusions.inc
+By default, :ref:`cve-check <ref-classes-cve-check>` uses the recipe name :term:`BPN` as CVE
+product name when querying the CVE database. If this mapping contains false positives, e.g.
+some reported CVEs are not for the software component in question, or false negatives like
+some CVEs are not found to impact the recipe when they should, then the problems can be
+in the recipe name to CVE product mapping. These mapping issues can be fixed by setting
+the :term:`CVE_PRODUCT` variable inside the recipe. This defines the name of software component in the
+upstream `NIST CVE database <https://nvd.nist.gov/>`__.
-Enabling vulnerabily tracking in recipes
-----------------------------------------
+The variable supports using vendor and product names like this::
-The :term:`CVE_PRODUCT` variable defines the name used to match the recipe name
-against the name in the upstream `NIST CVE database <https://nvd.nist.gov/>`__.
+ CVE_PRODUCT = "flex_project:flex"
-Editing recipes to fix vulnerabilities
---------------------------------------
+In this example from the vendor name used in CVE database is ``flex_project`` and
+product is ``flex``. With this setting the ``flex`` recipe only maps to this specific
+product and not products from other vendors with same name ``flex``.
-To fix a given known vulnerability, you need to add a patch file to your recipe. Here's
+Similary, when the recipe version :term:`PV` is not compatible with software versions used by
+the upstream software component releases and the CVE database, these can be fixed using
+:term:`CVE_VERSION` variable.
+
+Note that if the CVE entries in NVD databse contain bugs or have missing or incomplete
+information, it is recommended to fix the information there directly instead of working
+around the issues for a possibly long time in Poky and OE-Core side recipes. Feedback to
+NVD about CVEs entries can be provided through the `NVD contact form <https://nvd.nist.gov/info/contact-form>`__.
+
+Fixing vulnerabilities in recipes
+---------------------------------
+
+If a CVE security issue impacts a software component, it can be fixed by updating to a newer
+version of the software component or by applying a patch. For Poky and OE-Core master branches, updating
+to newer software component release with fixes is the best option, but patches can be applied
+if releases are not yet available.
+
+For stable branches, it is preferred to apply patches for the issues. For some software
+components minor version updates can also applied if they are backwards compatible.
+
+Here is an example of fixing CVE security issues with patch files,
an example from the :oe_layerindex:`ffmpeg recipe</layerindex/recipe/47350>`::
SRC_URI = "https://www.ffmpeg.org/releases/${BP}.tar.xz \
@@ -11551,31 +11610,21 @@
file://fix-CVE-2020-22033-CVE-2020-22019.patch \
file://fix-CVE-2021-33815.patch \
-The :ref:`cve-check <ref-classes-cve-check>` class defines two ways of
-supplying a patch for a given CVE. The first
-way is to use a patch filename that matches the below pattern::
+A good practice is to include the CVE identifier in both patch file name
+and inside the patch file commit message use the format::
- cve_file_name_match = re.compile(".*([Cc][Vv][Ee]\-\d{4}\-\d+)")
+ CVE: CVE-2020-22033
-As shown in the example above, multiple CVE IDs can appear in a patch filename,
-but the :ref:`cve-check <ref-classes-cve-check>` class will only consider
-the last CVE ID in the filename as patched.
+CVE checker will then capture this information and change the CVE status to ``Patched``
+in the generated reports.
-The second way to recognize a patched CVE ID is when a line matching the
-below pattern is found in any patch file provided by the recipe::
+If analysis shows that the CVE issue does not impact the recipe due to configuration, platform,
+version or other reasons, the CVE can be marked as ``Ignored`` using :term:`CVE_CHECK_IGNORE` variable.
+As mentioned previously, if data in the CVE database is wrong, it is recommend to fix those
+issues in the CVE database directly.
- cve_match = re.compile("CVE:( CVE\-\d{4}\-\d+)+")
-
-This allows a single patch file to address multiple CVE IDs at the same time.
-
-Of course, another way to fix vulnerabilities is to upgrade to a version
-of the package which is not impacted, typically a more recent one.
-The NIST database knows which versions are vulnerable and which ones
-are not.
-
-Last but not least, you can choose to ignore vulnerabilities through
-the :term:`CVE_CHECK_SKIP_RECIPE` and :term:`CVE_CHECK_IGNORE`
-variables.
+Recipes can be completely skipped by CVE check by including the recipe name in
+the :term:`CVE_CHECK_SKIP_RECIPE` variable.
Implementation details
----------------------
@@ -11592,24 +11641,39 @@
Then, the code looks up all the CVE IDs in the NIST database for all the
products defined in :term:`CVE_PRODUCT`. Then, for each found CVE:
- - If the package name (:term:`PN`) is part of
- :term:`CVE_CHECK_SKIP_RECIPE`, it is considered as patched.
+- If the package name (:term:`PN`) is part of
+ :term:`CVE_CHECK_SKIP_RECIPE`, it is considered as ``Patched``.
- - If the CVE ID is part of :term:`CVE_CHECK_IGNORE`, it is
- considered as patched too.
+- If the CVE ID is part of :term:`CVE_CHECK_IGNORE`, it is
+ set as ``Ignored``.
- - If the CVE ID is part of the patched CVE for the recipe, it is
- already considered as patched.
+- If the CVE ID is part of the patched CVE for the recipe, it is
+ already considered as ``Patched``.
- - Otherwise, the code checks whether the recipe version (:term:`PV`)
+- Otherwise, the code checks whether the recipe version (:term:`PV`)
is within the range of versions impacted by the CVE. If so, the CVE
- is considered as unpatched.
+ is considered as ``Unpatched``.
The CVE database is stored in :term:`DL_DIR` and can be inspected using
``sqlite3`` command as follows::
sqlite3 downloads/CVE_CHECK/nvdcve_1.1.db .dump | grep CVE-2021-37462
+When analyzing CVEs, it is recommended to:
+
+- study the latest information in `CVE database <https://nvd.nist.gov/vuln/search>`__.
+
+- check how upstream developers of the software component addressed the issue, e.g.
+ what patch was applied, which upstream release contains the fix.
+
+- check what other Linux distributions like `Debian <https://security-tracker.debian.org/tracker/>`__
+ did to analyze and address the issue.
+
+- follow security notices from other Linux distributions.
+
+- follow public `open source security mailing lists <https://oss-security.openwall.org/wiki/mailing-lists>`__ for
+ discussions and advance notifications of CVE bugs and software releases with fixes.
+
Using the Error Reporting Tool
==============================
@@ -11637,12 +11701,9 @@
---------------------------
By default, the error reporting tool is disabled. You can enable it by
-inheriting the
-:ref:`report-error <ref-classes-report-error>`
+inheriting the :ref:`report-error <ref-classes-report-error>`
class by adding the following statement to the end of your
-``local.conf`` file in your
-:term:`Build Directory`.
-::
+``local.conf`` file in your :term:`Build Directory`::
INHERIT += "report-error"
diff --git a/poky/documentation/dev-manual/qemu.rst b/poky/documentation/dev-manual/qemu.rst
index 9f4bc26..5a4a82c 100644
--- a/poky/documentation/dev-manual/qemu.rst
+++ b/poky/documentation/dev-manual/qemu.rst
@@ -99,8 +99,7 @@
Here are some additional examples to help illustrate further QEMU:
- This example starts QEMU with MACHINE set to "qemux86-64".
- Assuming a standard
- :term:`Build Directory`, ``runqemu``
+ Assuming a standard :term:`Build Directory`, ``runqemu``
automatically finds the ``bzImage-qemux86-64.bin`` image file and
the ``core-image-minimal-qemux86-64-20200218002850.rootfs.ext4``
(assuming the current build created a ``core-image-minimal``
@@ -246,11 +245,10 @@
software compiled with a certain CPU feature crashes when run on a CPU
under KVM that does not support that feature. To work around this
problem, you can override QEMU's runtime CPU setting by changing the
-``QB_CPU_KVM`` variable in ``qemuboot.conf`` in the
-:term:`Build Directory` ``deploy/image``
-directory. This setting specifies a ``-cpu`` option passed into QEMU in
-the ``runqemu`` script. Running ``qemu -cpu help`` returns a list of
-available supported CPU types.
+``QB_CPU_KVM`` variable in ``qemuboot.conf`` in the :term:`Build Directory`
+``deploy/image`` directory. This setting specifies a ``-cpu`` option passed
+into QEMU in the ``runqemu`` script. Running ``qemu -cpu help`` returns a
+list of available supported CPU types.
QEMU Performance
================
diff --git a/poky/documentation/dev-manual/start.rst b/poky/documentation/dev-manual/start.rst
index 6816ce5..f903754 100644
--- a/poky/documentation/dev-manual/start.rst
+++ b/poky/documentation/dev-manual/start.rst
@@ -267,16 +267,16 @@
Linux machine (recommended), it can be a machine (Linux, Mac, or
Windows) that uses `CROPS <https://github.com/crops/poky-container>`__,
which leverages `Docker Containers <https://www.docker.com/>`__ or it
-can be a Windows machine capable of running Windows Subsystem For Linux
-v2 (WSL).
+can be a Windows machine capable of running version 2 of Windows Subsystem
+For Linux (WSL 2).
.. note::
- The Yocto Project is not compatible with
- `Windows Subsystem for Linux v1 <https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux>`__.
- It is compatible but not officially supported nor validated with
- WSLv2. If you still decide to use WSL please upgrade to
- `WSLv2 <https://docs.microsoft.com/en-us/windows/wsl/install-win10>`__.
+ The Yocto Project is not compatible with version 1 of
+ `Windows Subsystem for Linux <https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux>`__.
+ It is compatible but neither officially supported nor validated with
+ WSL 2. If you still decide to use WSL please upgrade to
+ `WSL 2 <https://learn.microsoft.com/en-us/windows/wsl/install>`__.
Once your build host is set up to use the Yocto Project, further steps
are necessary depending on what you want to accomplish. See the
@@ -441,35 +441,36 @@
the ":doc:`/toaster-manual/setup-and-use`"
section in the Toaster User Manual.
-Setting Up to Use Windows Subsystem For Linux (WSLv2)
+Setting Up to Use Windows Subsystem For Linux (WSL 2)
-----------------------------------------------------
-With `Windows Subsystem for Linux
-(WSLv2) <https://docs.microsoft.com/en-us/windows/wsl/wsl2-about>`__,
+With `Windows Subsystem for Linux (WSL 2)
+<https://learn.microsoft.com/en-us/windows/wsl/>`__,
you can create a Yocto Project development environment that allows you
to build on Windows. You can set up a Linux distribution inside Windows
in which you can develop using the Yocto Project.
-Follow these general steps to prepare a Windows machine using WSLv2 as
+Follow these general steps to prepare a Windows machine using WSL 2 as
your Yocto Project build host:
-1. *Make sure your Windows 10 machine is capable of running WSLv2:*
- WSLv2 is only available for Windows 10 builds > 18917. To check which
- build version you are running, you may open a command prompt on
- Windows and execute the command "ver".
- ::
+1. *Make sure your Windows machine is capable of running WSL 2:*
+
+ While all Windows 11 and Windows Server 2022 builds support WSL 2,
+ the first versions of Windows 10 and Windows Server 2019 didn't.
+ Check the minimum build numbers for `Windows 10
+ <https://learn.microsoft.com/en-us/windows/wsl/install-manual#step-2---check-requirements-for-running-wsl-2>`__
+ and for `Windows Server 2019
+ <https://learn.microsoft.com/en-us/windows/wsl/install-on-server>`__.
+
+ To check which build version you are running, you may open a command
+ prompt on Windows and execute the command "ver"::
C:\Users\myuser> ver
Microsoft Windows [Version 10.0.19041.153]
- If your build is capable of running
- WSLv2 you may continue, for more information on this subject or
- instructions on how to upgrade to WSLv2 visit `Windows 10
- WSLv2 <https://docs.microsoft.com/en-us/windows/wsl/wsl2-install>`__
-
-2. *Install the Linux distribution of your choice inside Windows 10:*
- Once you know your version of Windows 10 supports WSLv2, you can
+2. *Install the Linux distribution of your choice inside WSL 2:*
+ Once you know your version of Windows supports WSL 2, you can
install the distribution of your choice from the Microsoft Store.
Open the Microsoft Store and search for Linux. While there are
several Linux distributions available, the assumption is that your
@@ -478,31 +479,28 @@
making your selection, simply click "Get" to download and install the
distribution.
-3. *Check your Linux distribution is using WSLv2:* Open a Windows
+3. *Check which Linux distribution WSL 2 is using:* Open a Windows
PowerShell and run::
C:\WINDOWS\system32> wsl -l -v
NAME STATE VERSION
*Ubuntu Running 2
- Note the version column which says the WSL version
- being used by your distribution, on compatible systems, this can be
- changed back at any point in time.
+ Note that WSL 2 supports running as many different Linux distributions
+ as you want to install.
-4. *Optionally Orient Yourself on WSL:* If you are unfamiliar with WSL,
- you can learn more here -
+4. *Optionally Get Familiar with WSL:* You can learn more on
https://docs.microsoft.com/en-us/windows/wsl/wsl2-about.
5. *Launch your WSL Distibution:* From the Windows start menu simply
launch your WSL distribution just like any other application.
-6. *Optimize your WSLv2 storage often:* Due to the way storage is
- handled on WSLv2, the storage space used by the underlying Linux
+6. *Optimize your WSL 2 storage often:* Due to the way storage is
+ handled on WSL 2, the storage space used by the underlying Linux
distribution is not reflected immediately, and since BitBake heavily
uses storage, after several builds, you may be unaware you are
- running out of space. WSLv2 uses a VHDX file for storage, this issue
- can be easily avoided by manually optimizing this file often, this
- can be done in the following way:
+ running out of space. As WSL 2 uses a VHDX file for storage, this issue
+ can be easily avoided by regularly optimizing this file in a manual way:
1. *Find the location of your VHDX file:*
@@ -556,14 +554,14 @@
.. note::
- The current implementation of WSLv2 does not have out-of-the-box
+ The current implementation of WSL 2 does not have out-of-the-box
access to external devices such as those connected through a USB
port, but it automatically mounts your ``C:`` drive on ``/mnt/c/``
(and others), which you can use to share deploy artifacts to be later
- flashed on hardware through Windows, but your build directory should
- not reside inside this mountpoint.
+ flashed on hardware through Windows, but your :term:`Build Directory`
+ should not reside inside this mountpoint.
-Once you have WSLv2 set up, everything is in place to develop just as if
+Once you have WSL 2 set up, everything is in place to develop just as if
you were running on a native Linux machine. If you are going to use the
Extensible SDK container, see the ":doc:`/sdk-manual/extensible`" Chapter in the Yocto
Project Application Development and the Extensible Software Development