subtree updates
poky: ee0d001b81..4161dbbbd6:
Aatir Manzur (1):
docs: add CONVERSION_CMD definition
Ahmed Hossam (1):
insane.bbclass: host-user-contaminated: Correct per package home path
Alejandro Hernandez Samaniego (1):
package.bbclass: Fix base directory for debugsource files when using externalsrc
Alex Kiernan (1):
python3-cryptography: Cleanup DEPENDS/RDEPENDS
Alexander Kanavin (53):
mesa: update 22.0.3 -> 22.1.2
python3-numpy: update 1.22.3 -> 1.22.4
python3-setuptools: update 62.3.2 -> 62.5.0
vulkan: upgrade 1.3.211.0 -> 1.3.216.0
lttng-modules: update 2.13.3 -> 2.13.4
go: update 1.18.2 -> 1.18.3
ell: update 0.50 -> 0.51
libdrm: update 2.4.110 -> 2.4.111
diffoscope: upgrade 215 -> 216
dos2unix: upgrade 7.4.2 -> 7.4.3
librsvg: upgrade 2.54.3 -> 2.54.4
puzzles: upgrade to latest revision
sudo: upgrade 1.9.10 -> 1.9.11p2
wireless-regdb: upgrade 2022.04.08 -> 2022.06.06
x264: upgrade to latest revision
python3-requests: upgrade 2.27.1 -> 2.28.0
oeqa/sdk: drop the nativesdk-python 2.x test
python3-hatch-vcs: fix upstream version check
at: take tarballs from debian
pango: exclude 1.9x versions which are 2.x pre-releases.
adwaita-icon-theme: upgrade 41.0 -> 42.0
rust: update 1.60.0 -> 1.62.0
weston: update 10.0.0 -> 10.0.1
python3-setuptools-scm: upgrade 6.4.2 -> 7.0.3
waffle: correctly request wayland-scanner executable
openssl: update 3.0.4 -> 3.0.5
diffoscope: upgrade 216 -> 217
glib-2.0: upgrade 2.72.2 -> 2.72.3
glib-networking: upgrade 2.72.0 -> 2.72.1
gstreamer1.0: upgrade 1.20.2 -> 1.20.3
harfbuzz: upgrade 4.3.0 -> 4.4.1
kmod: upgrade 29 -> 30
libsoup: upgrade 3.0.6 -> 3.0.7
mesa: upgrade 22.1.2 -> 22.1.3
mpg123: upgrade 1.29.3 -> 1.30.0
nghttp2: upgrade 1.47.0 -> 1.48.0
piglit: upgrade to latest revision
pulseaudio: upgrade 16.0 -> 16.1
python3-cffi: upgrade 1.15.0 -> 1.15.1
python3-cryptography: upgrade 37.0.2 -> 37.0.3
python3-cryptography-vectors: upgrade 37.0.2 -> 37.0.3
python3-hatchling: upgrade 1.3.0 -> 1.3.1
python3-hypothesis: upgrade 6.46.11 -> 6.48.2
python3-jsonschema: upgrade 4.6.0 -> 4.6.1
python3-mako: upgrade 1.2.0 -> 1.2.1
python3-pycryptodomex: upgrade 3.14.1 -> 3.15.0
python3-requests: upgrade 2.28.0 -> 2.28.1
python3-setuptools: upgrade 62.5.0 -> 62.6.0
python3-sphinx: upgrade 5.0.0 -> 5.0.2
xcb-proto: upgrade 1.15 -> 1.15.2
procps: restrict version check to 3.x
ncurses: mark upstream version as unknown
wayland: update 1.20.0 -> 1.21.0
Alexandre Belloni (1):
oeqa/selftest/bbtests: Update message lookup for test_git_unpack_nonetwork_fail
Aryaman Gupta (5):
buildstats.py: enable collection of /proc/pressure data
pybootchartgui: render cpu and io pressure
buildstats.bbclass: correct sampling of system stats
buildstats.py: close /proc/pressure/cpu file descriptor
buildperf/base.py: skip reduced_proc_pressure directory
Bruce Ashfield (29):
perf: fix reproducibility in 5.19+
linux-yocto/5.10: update to v5.10.121
linux-yocto/5.15: update to v5.15.46
linux-yocto/5.15: update to v5.15.48
linux-yocto/5.10: update to v5.10.123
linux-yocto-dev: bump to v5.19-rc
linux-yocto/5.15: drop obselete GPIO sysfs ABI
lttng-modules: fix 5.19+ build
kernel-devsrc: fix reproducibility and buildpaths QA warning
linux-yocto/5.15: update to v5.15.52
linux-yocto/5.10: update to v5.10.128
kernel-devsrc: ppc32: fix reproducibility
linux-yocto/5.15: fix qemuppc buildpaths warning
linux-yocto/5.15: fix build_OID_registry buildpaths warning
yocto-bsps: update to v5.10.128 and buildpaths fixes
yocto-bsps: update to v5.15.52 and buildpaths fixes
linux-yocto/5.10: fix build_OID_registry/conmakehash buildpaths warning
linux-yocto/5.10: fix buildpaths issue with gen-mach-types
linux-yocto/5.15: fix buildpaths issue with gen-mach-types
yocto-bsps/5.10: fix buildpaths issue with gen-mach-types
yocto-bsps/5.15: fix buildpaths issue with gen-mach-types
linux-yocto/5.15: update to v5.15.54
linux-yocto/5.15: fix buildpaths issue with pnmtologo
linux-yocto/5.10: update to v5.10.130
linux-yocto/5.10: fix buildpaths issue with pnmtologo
yocto-bsps/5.10: fix buildpaths issue with pnmtologo
yocto-bsps/5.15: fix buildpaths issue with pnmtologo
yocto-bsps: update to v5.15.54
yocto-bsps: update to v5.10.130
Christoph Lauer (1):
package.bbclass: Avoid stripping signed kernel modules in splitdebuginfo
David Bagonyi (1):
sanity.bbclass: Add ftps to accepted URI protocols for mirrors sanity
Dmitry Baryshkov (1):
linux-firmware: upgrade 20220509 -> 20220610
Enrico Scholz (6):
npm: replace 'npm pack' call by 'tar czf'
npm: return content of 'package.json' in 'npm_pack'
npm: take 'version' directly from 'package.json'
npm: disable 'audit' + 'fund'
lib:npm_registry: initial checkin
npm: use npm_registry to cache package
Federico Pellegrin (1):
signing-keys: fix RDEPENDS to signing-keys-dev
Gennaro Iorio (1):
bitbake: fetch2: gitsm: fix incorrect handling of git submodule relative urls
He Zhe (1):
curl: Fix build failure for qemuriscv64
Jacob Kroon (1):
bitbake: bitbake-user-manual: Correct description of the ??= operator
Jose Quaresma (3):
archiver: don't use machine variables in shared recipes
sstate: Use the python3 ThreadPoolExecutor instead of the OE ThreadedPool
oe/utils: remove the ThreadedPool
Joshua Watt (1):
classes/create-spdx: Add SPDX_PRETTY option
Kai Kang (1):
glibc-tests: not clear BBCLASSEXTEND
Khem Raj (2):
libmodule-build-perl: Use env utility to find perl interpreter
ltp: Remove -mfpmath=sse on x86
Luca Ceresoli (1):
llvm: add PACKAGECONFIG[optviewer]
Lucas Stach (1):
perf: sort-pmuevents: really keep array terminators
Marius Kriegerowski (1):
scriptutils: fix style to be more PEP8 compliant
Marta Rybczynska (2):
cve-check: add support for Ignored CVEs
oeqa/selftest/cve_check: add tests for Ignored and partial reports
Martin Jansa (3):
mesa: backport a patch to support compositors without zwp_linux_dmabuf_v1 again
wic: fix WicError message
bitbake: fetch2/git: show SRCREV and git repo in error message about fixed SRCREV
Maxime Roussin-Bélanger (1):
libffi: fix native build being not portable
Michael Halstead (2):
releases: include 3.1.17
releases: include 4.0.2
Michael Opdenacker (18):
rootfs-postcommands.bbclass: correct comments
dev-manual: mention the new CVE patch metrics page
dev-manual: fix references to BitBake user manual
docs: standards.md: add more rules: line wrapping and variables
doc: standard for bulleted lists
ref-manual: add description for the "sysroot" term
manuals: update host tool requirements
ref-manual: document SSTATE_EXCLUDEDEPS_SYSROOT
ref-manual: document SYSTEMD_DEFAULT_TARGET
ref-manual: IMAGE_FEATURES: add allow-root-login and correct allow-empty-password
ref-manual: correct description of empty-root-passwd in IMAGE_FEATURES
bitbake: doc: bitbake-user-manual: add explicit target for crates fetcher
bitbake: doc: bitbake-user-manual: document npm and npmsw fetchers
dev-manual: NPM packages: minor grammar fix
manuals: switch to the sstate mirror shared between all versions
manuals: replace hyphens with em dashes
dev-manual: update section about creating NPM packages
dev-manual: improve screenshot resolution
Ming Liu (3):
udev-extraconf: fix some systemd automount issues
meta: introduce UBOOT_MKIMAGE_KERNEL_TYPE
udev-extraconf:mount.sh: fix path mismatching issues
Mingli Yu (1):
vim: not adjust script pathnames for native scripts either
Muhammad Hamza (6):
initramfs-framework: move storage mounts to actual rootfs
udev-extraconf/mount.sh: add LABELs to mountpoints
udev-extraconf/mount.sh: save mount name in our tmp filecache
udev-extraconf/mount.sh: only mount devices on hotplug
udev-extraconf: force systemd-udevd to use shared MountFlags
udev-extraconf/mount.sh: ignore lvm in automount
Nick Potenski (1):
systemd: systemd-systemctl: Support instance conf files during enable
Ola x Nilsson (1):
bitbake: ConfHandler: Remove lingering close
Pascal Bach (1):
bin_package: install into base_prefix
Paul Eggleton (4):
devtool: ignore pn- overrides when determining SRC_URI overrides
patch: handle if S points to a subdirectory of a git repo
devtool: finish: handle patching when S points to subdir of a git repo
oe-selftest: devtool: test modify git recipe building from a subdir
Paulo Neves (14):
python: Avoid shebang overflow on python-config.py
gtk-doc: Fix potential shebang overflow on gtkdoc-mkhtml2
ref-manual: SYSTEMD_SERVICE allows multiple services
ref-manual: SYSTEMD_SERVICE overrides depend on SYSTEMD_PACKAGES
insane.bbclass: Make do_qa_staging check shebangs
oeqa/selftest: Add test for shebang overflow
oeqa/selftest: Test staged .la and .pc files
utils: Add cmdline_shebang_wrapper util.
libcheck: Fix too long shebang for native case.
utils: create_cmdline_shebang_wrapper whitespace and sed refactor
utils: create_cmdline_shebang_wrapper preserve permission and ownership
oeqa/sysroot.py: Check bitbake return status
bitbake: fetch: bb.fatal when trying to checksum non-existing files
oeqa: test_invalid_recipe_src_uri expect parse time error
Pavel Zhukov (4):
systemd: Add missed sys/file.h includes for musl
systemd: Rebase patches on v251
bitbake: tests/fetch: Add test for broken mirror tarball
systemd: update upstream status of merged patches
Peter Bergin (2):
systemd: add packageconfig for sysext
rust: fix issue building cross-canadian tools for aarch64 on x86_64
Peter Kjellerstedt (2):
ref-manual: Add documentation for INCOMPATIBLE_LICENSE_EXCEPTIONS
base.bbclass: Correct the test for obsolete license exceptions
Peter Marko (1):
alsa-state: correct license
Pgowda (1):
binutils : CVE-2019-1010204
Quentin Schulz (3):
docs: releases: move hardknott and honister to outdated section
docs: conf.py: bump minimum Sphinx version requirement
Revert "docs: conf.py: fix cve extlinks caption for sphinx <4.0"
Raju Kumar Pothuraju (2):
runqemu: add QB_KERNEL_CMDLINE
kernel-uboot.bbclass: Use vmlinux.initramfs when INITRAMFS_IMAGE_BUNDLE set
Richard Purdie (42):
gcc-source: Fix incorrect task dependencies from ${B}
vim: Upgrade 8.2.5034 -> 8.2.5083
local.conf.sample: Update sstate url to new 'all' path
ref/dev-manual: Update multiconfig documentation
oeqa/runtime/scp: Disable scp test for dropbear
unzip: Port debian fixes for two CVEs
elfutils/flex: Disable parallel make ptest compile
bitbake: server/process: Fix logging issues where only the first message was displayed
coreutils: Tweak packaging variable names for coreutils-dev
packagegroup-core-ssh-dropbear: Add openssh-sftp-server recommendation
bitbake.conf/recipes: Introduce add DEV_PKG_DEPENDENCY to change RDEPENDS:${PN}-dev
bitbake.conf: Change -dev RDEPENDS to RRECOMMENDS
vim: 8.2.5083 -> 9.0.0005
ncurses: 6.3 -> 6.3+20220423
oe-selftest-image: Ensure the image has sftp as well as dropbear
cve-extra-exclusions: Clean up and ignore three CVEs (2xqemu and nasm)
openssl: Upgrade 3.0.3 -> 3.0.4
insane: Fix buildpaths test to work with special devices
go: Filter build paths on staticly linked arches
glibc-tests: Avoid reproducibility issues
gperf: Add a patch to work around reproducibility issues
bitbake: ConfHandler/BBHandler: Improve comment error messages and add tests
icon-naming-utils: Resurrect for sato-icon-theme
sato-icon-theme: Add back with support for scalable icons
lua: Fix multilib buildpath reproducibility issues
vala: Fix on target wrapper buildpaths issue
gtk-doc: Remove hardcoded buildpath
gperf: Switch to upstream patch
qemu: Avoid accidental librdmacm linkage
kernel-arch: Fix buildpaths leaking into external module compiles
qemu: Fix slirp determinism issue
qemu: Add PACKAGECONFIG for brlapi
gcc-runtime: Fix build when using gold
insane: Add buildpaths to WARN_QA by default
insane: Reword staging to refer to populate_sysroot
bitbake: fetch2: Ensure directory exists before creating symlink
bitbake: fetch2: Drop DL_DIR fallback for local file fetcher
oeqa/selftest/sstatetests: Update test to work with bitbake changes
gcc-runtime: Fix missing MLPREFIX in debug mappings
insane: Drop debug exclusion from buildpaths test
selftest/runtime_test/virgl: Disable for all almalinux
local.conf.sample: Mention other MACHINE options may exist
Robert Joslyn (1):
curl: Update to 7.84.0
Ross Burton (24):
python3: fix a race condition in the test_socket.testSockName test
Add python3-editables (from meta-python)
Add python3-pathspec (from meta-python)
Add python3-hatchling (from meta-oe)
python3-hatch-vcs: add new recipe
python3-jsonschema: upgrade 4.5.1 -> 4.6.0
package_manager: Change complementary package handling to not include soft dependencies
cups: ignore CVE-2022-26691
cve-check: hook cleanup to the BuildCompleted event, not CookerExit
busybox: fix CVE-2022-30065
ncurses: use GitHub mirror, not Debian's packaging
ltp: remove open-posix-testsuite build logs
tiff: backport the fix for CVE-2022-2056, CVE-2022-2057, and CVE-2022-2058
perl: don't install Makefile.old into perl-ptest
vim: upgrade to 9.0.0021
ltp: fix builds when host ld doesn't know about target ELF formats
python3-setuptools-scm: add missing python3-typing-extensions dependency
python3-flit-core: bootstrap explicitly
python3-installer: bootstrap by installing installer with installer
python3-picobuild: add new recipe
python_pep517: use picobuild instead of manually calling the API
classes: remove obsolete PEP517_BUILD_API
python3-hatchling: remove PEP517_BUILD_API
documentation: remove obsolete PEP517_BUILD_API
Steve Sakoman (3):
qemu: add PACKAGECONFIG for capstone
qemu: Avoid accidental libvdeplug linkage
ruby: add PACKAGECONFIG for capstone
Sundeep KOKKONDA (2):
glibc: stable 2.35 branch updates
binutils : stable 2.38 branch updates
Thomas Perrot (1):
opensbi: Update to v1.1
Thomas Roos (1):
recipetool/devtool: Fix python egg whitespace issues in PACKAGECONFIG
Xu Huan (2):
python3: upgrade 3.10.4 -> 3.10.5
python3-magic: upgrade 0.4.26 -> 0.4.27
Yi Zhao (2):
popt: fix override syntax in RDEPENDS
git: fix override syntax in RDEPENDS
Yogesh Tyagi (2):
testimage : remove curl-ptest from rpm index
curl : Add ptest
Yue Tao (1):
gnupg: upgrade to 2.3.7 to fix CVE-2022-34903
Yulong (Kevin) Liu (1):
python3-pyasn1: Eliminated ptest deprecation warnings
aatir (1):
docs: make DISTRO_FEATURES description more explicit
niko.mauno@vaisala.com (3):
ptest.bbclass: Honor PARALLEL_MAKE, PARALLEL_MAKEINST
valgrind: Drop redundant oe_runmake parameter
strace: Drop redundant oe_runmake parameter
pgowda (1):
gcc: Backport a fix for gcc bug 105039
ssuesens (3):
weston.py: added xwayland test
weston.init: enabled xwayland
xwayland.weston-start: adaption of X11-unix folder
wangmy (57):
btrfs-tools: upgrade 5.18 -> 5.18.1
ethtool: upgrade 5.17 -> 5.18
file: upgrade 5.41 -> 5.42
libx11: upgrade 1.8 -> 1.8.1
lighttpd: upgrade 1.4.64 -> 1.4.65
gnu-config: update to latest version
musl-obstack: upgrade 1.1 -> 1.2
piglit: upgrade to latest revision
stress-ng: upgrade 0.14.01 -> 0.14.02
erofs-utils: upgrade 1.4 -> 1.5
alsa-lib: upgrade 1.2.7 -> 1.2.7.1
alsa-plugins: upgrade 1.2.6 -> 1.2.7.1
alsa-ucm-conf: upgrade 1.2.7 -> 1.2.7.1
bind: upgrade 9.18.3 -> 9.18.4
kbd: upgrade 2.5.0 -> 2.5.1
libproxy: upgrade 0.4.17 -> 0.4.18
python3-dbusmock: upgrade 0.27.5 -> 0.28.0
sbc: upgrade 1.5 -> 2.0
strace: upgrade 5.17 -> 5.18
python3-chardet: upgrade 4.0.0 -> 5.0.0
python3-importlib-metadata: upgrade 4.11.4 -> 4.12.0
python3-babel: upgrade 2.10.1 -> 2.10.3
python3-certifi: upgrade 2022.5.18.1 -> 2022.6.15
python3-dbusmock: upgrade 0.28.0 -> 0.28.1
python3-numpy: upgrade 1.22.4 -> 1.23.0
python3-pycryptodome: upgrade 3.14.1 -> 3.15.0
dmidecode: upgrade 3.3 -> 3.4
git: upgrade 2.36.1 -> 2.37.0
harfbuzz: upgrade 4.3.0 -> 4.4.0
speexdsp: upgrade 1.2.0 -> 1.2.1
speex: upgrade 1.2.0 -> 1.2.1
repo: upgrade 2.26 -> 2.27
sqlite3: upgrade 3.38.5 -> 3.39.0
sudo: upgrade 1.9.11p2 -> 1.9.11p3
createrepo-c: upgrade 0.20.0 -> 0.20.1
gst-devtools: upgrade 1.20.2 -> 1.20.3
gstreamer1.0-libav: upgrade 1.20.2 -> 1.20.3
gstreamer1.0-omx: upgrade 1.20.2 -> 1.20.3
gstreamer1.0-plugins-bad: upgrade 1.20.2 -> 1.20.3
gstreamer1.0-plugins-base: upgrade 1.20.2 -> 1.20.3
gstreamer1.0-plugins-good: upgrade 1.20.2 -> 1.20.3
gstreamer1.0-plugins-ugly: upgrade 1.20.2 -> 1.20.3
gstreamer1.0-python: upgrade 1.20.2 -> 1.20.3
gstreamer1.0-rtsp-server: upgrade 1.20.2 -> 1.20.3
gstreamer1.0-vaapi: upgrade 1.20.2 -> 1.20.3
inetutils: upgrade 2.2 -> 2.3
python3-atomicwrites: upgrade 1.4.0 -> 1.4.1
python3-cryptography: upgrade 37.0.3 -> 37.0.4
python3-cryptography-vectors: upgrade 37.0.3 -> 37.0.4
python3-hatchling: upgrade 1.3.1 -> 1.5.0
python3-imagesize: upgrade 1.3.0 -> 1.4.1
python3-jsonschema: upgrade 4.6.1 -> 4.7.1
python3-numpy: upgrade 1.23.0 -> 1.23.1
python3-typing-extensions: upgrade 4.2.0 -> 4.3.0
python3-urllib3: upgrade 1.26.9 -> 1.26.10
init-system-helpers: upgrade 1.63 -> 1.64
dpkg: upgrade 1.21.8 -> 1.21.9
meta-security: 8c6fe006a1..7ad5f6a9da:
Armin Kuster (32):
apparmor: fix ownership issues
sssd:move to dynamic networking-layer
layer.conf:add meta-netorking to BBFILES_DYNAMIC
packagegroup-core-security: drop sssd
packagegroup-core-security.bbappend: add sssd
oeqa: fix checksec runtime test
sssd: use example conf file
oeqa: sssd.py fix tests
sssd: update to 2.7.1
security-test-image: auto include layers if present.
smack-test: more py3 covertion
oeqa: update smack runtime test
aide: add a few more config options
oeqa: add aide test
libmhash: add native pkg support
classes: add aide routines
aide: add native support for build time db creation
aide.conf: adjust to allow for build time db creation
firejail: Add new package
oeqa: Add a very basic firejail test
packagegroup-core-security: add firejail
security-test-image: add firejail and aide test suites
oeqa/clamav drop depricated --list-mirror test
oeqa: meta-tpm shut swtpm down before and after testing
oeqa: shut done swtpm before and after testing
ccs-tools: update to 1.8.9
lynis: update to 3.0.8
README: update email address
packagegroup-core-security: skip mips firejail
chipsec: update to 1.8.5
security-build-image: add lkrg-module to build image
lkrg: update to 0.9.3
Jeremy A. Puhlman (2):
clamav: make install owner match the added user name
python3-privacyidea: add correct path to lib/privacyidea
Jose Quaresma (1):
meta-integrity: kernel-modsign: prevents splitting out debug symbols
Yi Zhao (1):
aide: fix typo
meta-openembedded: 11df15765c..31c10bd3e6:
Adrian Freihofer (3):
firewalld: update to 1.1.1 fixes ptest
firewalld: upgrade 1.1.1 -> 1.2.0
libqmi: upgrade 1.30.4 -> 1.30.8
Akash Hadke (2):
ntfs-3g-ntfsprogs: Set CVE_PRODUCT to "tuxera:ntfs-3g"
iperf: Set CVE_PRODUCT to "iperf_project:iperf"
Alex Kiernan (2):
jansson: Upgrade 2.13.1 -> 2.14
nftables: Upgrade 1.0.2 -> 1.0.4
Alex Stewart (1):
openvpn: distribute sample-config-files
Andreas Müller (1):
glmark2: Build with meson
Andrej Valek (1):
poco: upgrade 1.11.3 -> 1.12.0
Andrew Davis (1):
libsdl: The libsdl and libsdl2 are not virtual
Ashish Sharma (1):
netserver: don't change permissions on /dev/null
Aurélien Bertron (1):
fix(syslog-ng): warning about conf version
Bartosz Golaszewski (1):
python3-pybluez: fix a runtime issue with python 3.10
Ben Powell (1):
python3-can: Add typing-extensions dependency
Changqing Li (3):
chrony: create /var/lib/chrony by systemd-tmpfiles
redis: upgrade 6.2.6 -> 6.2.7
redis: upgrade 7.0.0 to 7.0.2
Chen Qi (2):
apache2: split out a new package apache2-utils
ntfs-3g-ntfsprogs: upgrade to 2022.5.17
Daide Li (1):
python3-iperf: initial add 0.1.11
Davide Gardenal (9):
usrsctp: add CVE_VERSION to correctly check for CVEs
ntp: ignore many CVEs
openflow: ignore CVE-2018-1078
emlog: ignore unrelated CVEs
imagemagick: upgrade 7.0.10-25 -> 7.0.10-62
wireshark: upgrade 3.4.11 -> 3.4.12
thrift: add CVE_PRODUCT to fix CVE reporting
spice: ignore patched CVEs
quagga: ignore CVE-2016-4049
Fabien Parent (1):
gpsd-machine-conf: allow creation of an empty package
Harshal (1):
lldpd: upgrade 1.0.8 -> 1.0.14
Hitendra Prajapati (1):
cyrus-sasl: CVE-2022-24407 failure to properly escape SQL input allows an attacker to execute arbitrary SQL commands
Jan Vermaete (1):
netdata: version bump 1.34.1 -> 1.35.0
Javier Viguera (1):
networkmanager: fix build with enabled ppp
Jeremy Puhlman (1):
freeradius: mutlilib fixes
Jonas Gorski (1):
abseil-cpp: do not enforce -mfpu=neon on arm
Kai Kang (4):
libdbi-perl: fix interpreter on shebang line
libdev-checklib-perl: fix interpreter of script use-devel-checklib
libparse-yapp-perl: update interpreter of yapp
python3-flatbuffer: enable native
Khem Raj (8):
libxml++: Disable parallel make in ptest compile
geos: Disable inlining
php: Fix absolute paths to php in phar.phar scripts
libspiro: Add recipe
fontforge: Upgrade to 20220308
opencv: Link with libatomic on mips
fontforge: Use alternate way to detect libm
opencv: Link with libatomic on rv32
Leon Anavi (19):
python3-traitlets: Upgrade 5.2.1 -> 5.3.0
python3-humanize: Upgrade 4.1.0 -> 4.2.0
python3-autobahn: Upgrade 22.4.2 -> 22.5.1
python3-elementpath: Upgrade 2.5.0 -> 2.5.3
python3-eth-hash: Upgrade 0.3.2 -> 0.3.3
python3-serpent: Upgrade 1.40 -> 1.41
python3-web3: Upgrade 5.29.1 -> 5.29.2
python3-pika: Upgrade 1.2.1 -> 1.3.0
python3-tabulate: Upgrade 0.8.9 -> 0.8.10
python3-marshmallow: Upgrade 3.15.0 -> 3.17.0
python3-pychromecast: Upgrade 12.1.3 -> 12.1.4
python3-humanize: Upgrade 4.2.0 -> 4.2.3
python3-tornado: Upgrade 6.1 -> 6.2
python3-coverage: Upgrade 6.3.2 -> 6.4.1
python3-email-validator: Upgrade 1.1.3 -> 1.2.1
python3-networkx: Upgrade 2.7.1 -> 2.8.4
python3-unidiff: Upgrade 0.7.3 -> 0.7.4
python3-toolz: Upgrade 0.11.2 -> 0.12.0
python3-ansi2html: Upgrade 1.7.0 -> 1.8.0
Marcus Flyckt (1):
python3-pyconnman: Add 'future' runtime dependency
Markus Volk (1):
flatbuffers: update to 2.0.6
Martin Jansa (3):
glmark2: fix compatibility with python-3.11
leveldb: switch from master branch to main
tesseract-lang: switch from master branch to main
Mikko Rapeli (1):
polkit: switch back to mozjs but leave duktape as PACKAGECONFIG option
Mingli Yu (3):
kronosnet: Fix build with gcc-12
s-nail: Fix build with gcc-12
mariadb: Upgrade to 10.8.3
Pascal Bach (1):
python3-pybind11: upgrade 2.8.1 -> 2.9.2
Peter Kjellerstedt (1):
cryptsetup: Add support for building without SSH tokens
Ross Burton (5):
python3-cbor2: upgrade 5.4.2 to 5.4.3
cppzmq: fix -dev RDEPENDS
python3-hatchling: remove (now in oe-core)
python3-pathspec: remove (now in oe-core)
python3-editables: remove (now in oe-core)
Sakib Sajal (1):
minicoredumper: retry elf parsing as long as needed
Theodore A. Roth (1):
crda: Depend on correct wireless-regdb package
Wentao Zhang (1):
protobuf-c: update to 1.4.1 fix CVE-2022-33070
Xu Huan (20):
python3-lxml: upgrade 4.8.0 -> 4.9.0
python3-msgpack: upgrade 1.0.3 -> 1.0.4
python3-protobuf: upgrade 3.20.1 -> 4.21.1
python3-mypy: upgrade 0.960 -> 0.961
python3-pylint: upgrade 2.13.9 -> 2.14.1
python3-smbus2: upgrade 0.4.1 -> 0.4.2
python3-pillow: upgrade 9.0.1 -> 9.1.1
python3-pychromecast: upgrade 12.1.2 -> 12.1.3
python3-pylint: upgrade 2.14.1 -> 2.14.3
python3-pyscaffold: upgrade 4.2.2 -> 4.2.3
python3-redis: upgrade 4.3.1 -> 4.3.3
python3-aiohue: upgrade 4.4.1 -> 4.4.2
python3-astroid: upgrade 2.11.5 -> 2.11.6
python3-charset-normalizer: upgrade 2.0.12 -> 2.1.0
python3-colorama: upgrade 0.4.4 -> 0.4.5
python3-eth-typing: upgrade 3.0.0 -> 3.1.0
python3-autobahn: upgrade 22.5.1 -> 22.6.1
python3-awesomeversion: upgrade 22.5.2 -> 22.6.0
python3-grpcio: upgrade 1.45.0 -> 1.47.0
python3-lxml: upgrade 4.9.0 -> 4.9.1
Yi Zhao (12):
openldap: pass correct URANDOM_DEVICE to CPPFLAGS
openvpn: eliminate build path from openvpn --version option
grubby: fix syntax for ALTERNATIVE
duktape: fix override syntax in RDEPENDS
polkit-group-rule-udisks2: fix override syntax in RDEPENDS
libcrypt-openssl-guess-perl: fix syntax for PROVIDES
evince: fix typo for RRECOMMENDS
blueman: fix typo for RRECOMMENDS
dnsmasq: Security fix CVE-2022-0934
strongswan: upgrade 5.9.5 -> 5.9.6
openvpn: add PACKAGECONFIG for systemd
openvpn: add PACKAGECONFIG for selinux
Yue Tao (2):
exo: upgrade 4.16.3 -> 4.16.4
dlt-daemon: upgrade to commit 6a3bd901d8 to fix CVE-2022-31291
Zoltán Böszörményi (5):
opencv: Upgrade to version 4.6.0
proj: Upgrade to 8.2.1
python3-pyproj: New recipe for pyproj version 3.3.1
geos: Upgrade to 3.9.3
libspatialite: Upgrade to 5.0.1
jybros (1):
clinfo: use virtual opencl loader provider
wangmy (72):
python3-cantools: upgrade 37.0.7 -> 37.1.0
python3-regex: upgrade 2022.4.24 -> 2022.6.2
python3-sqlalchemy: upgrade 1.4.36 -> 1.4.37
python3-twine: upgrade 4.0.0 -> 4.0.1
python3-waitress: upgrade 2.1.1 -> 2.1.2
python3-xmlschema: upgrade 1.11.0 -> 1.11.1
gspell: upgrade 1.10.0 -> 1.11.1
ctags: upgrade 5.9.20220529.0 -> 5.9.20220605.0
feh: upgrade 3.8 -> 3.9
inotify-tools: upgrade 3.22.1.0 -> 3.22.6.0
apache2: upgrade 2.4.53 -> 2.4.54
libnftnl: upgrade 1.2.1 -> 1.2.2
nbdkit: upgrade 1.31.7 -> 1.31.8
irssi: upgrade 1.2.3 -> 1.4.1
musl-nscd: upgrade 1.0.2 -> 1.1.0
rdma-core: upgrade 40.0 -> 41.0
snort: upgrade 2.9.19 -> 2.9.20
php: upgrade 8.1.6 -> 8.1.7
poco: upgrade 1.11.2 -> 1.11.3
pyxdg: upgrade 0.27 -> 0.28
syslog-ng: upgrade 3.36.1 -> 3.37.1
dnf-plugin-tui: Added postatinstall
python3-dill: upgrade 0.3.4 -> 0.3.5.1
python3-robotframework-seriallibrary: upgrade 0.3.1 -> 0.4.3
python3-ujson: upgrade 5.1.0 -> 5.3.0
python3-watchdog: upgrade 2.1.8 -> 2.1.9
python3-websocket-client: upgrade 1.3.2 -> 1.3.3
gnome-commander: upgrade 1.14.2 -> 1.14.3
libwacom: upgrade 2.2.0 -> 2.3.0
nbdkit: upgrade 1.31.8 -> 1.31.9
googletest: upgrade 1.11.0 -> 1.12.0
gperftools: upgrade 2.9.1 -> 2.10
iwd: upgrade 1.27 -> 1.28
libzip: upgrade 1.8.0 -> 1.9.0
postgresql: upgrade 14.3 -> 14.4
uftrace: upgrade 0.11 -> 0.12
python3-googleapis-common-protos: upgrade 1.56.2 -> 1.56.3
python3-ifaddr: upgrade 0.1.7 -> 0.2.0
python3-jmespath: upgrade 1.0.0 -> 1.0.1
python3-pandas: upgrade 1.4.2 -> 1.4.3
python3-zeroconf: upgrade 0.38.6 -> 0.38.7
geocode-glib: upgrade 3.26.2 -> 3.26.3
gnome-bluetooth: upgrade 42.0 -> 42.1
gnome-calculator: upgrade 42.0 -> 42.2
gnome-text-editor: upgrade 42.1 -> 42.2
gtk4: upgrade 4.6.4 -> 4.6.6
gtksourceview5: upgrade 5.4.1 -> 5.4.2
gvfs: upgrade 1.50.0 -> 1.50.2
abseil-cpp: upgrade 20211102 -> 20220623
capnproto: upgrade 0.9.1 -> 0.10.2
ctags: upgrade 5.9.20220605.0 -> 5.9.20220703.0
fwupd: upgrade 1.7.6 -> 1.8.1
googletest: upgrade 1.12.0 -> 1.12.1
nautilus: upgrade 42.1.1 -> 42.2
nbdkit: upgrade 1.31.9 -> 1.31.10
openconnect: upgrade 8.20 -> 9.01
bats: upgrade 1.6.1 -> 1.7.0
cloc: upgrade 1.92 -> 1.94
hwdata: upgrade 0.360 -> 0.361
libvpx: upgrade 1.11.0 -> 1.12.0
libzip: upgrade 1.9.0 -> 1.9.2
pegtl: upgrade 3.2.5 -> 3.2.6
phoronix-test-suite: upgrade 10.8.3 -> 10.8.4
poppler: upgrade 22.06.0 -> 22.07.0
netdata: upgrade 1.35.0 -> 1.35.1
evince: upgrade 42.2 -> 42.3
gjs: upgrade 1.72.0 -> 1.72.1
gnome-bluetooth: upgrade 42.1 -> 42.2
libadwaita: upgrade 1.1.1 -> 1.1.2
liburing: upgrade 2.1 -> 2.2
libcrypt-openssl-rsa-perl: upgrade 0.32 -> 0.33
libencode-perl: upgrade 3.17 -> 3.18
zhengruoqin (23):
python3-absl: upgrade 1.0.0 -> 1.1.0
python3-alembic: upgrade 1.7.7 -> 1.8.0
python3-asyncinotify: upgrade 2.0.3 -> 2.0.4
python3-crc32c: upgrade 2.2.post0 -> 2.3
python3-msk: upgrade 0.3.16 -> 0.4.0
python3-bitstruct: upgrade 8.14.1 -> 8.15.1
python3-google-api-python-client: upgrade 2.49.0 -> 2.50.0
python3-google-auth: upgrade 2.6.6 -> 2.7.0
python3-xmlschema: upgrade 1.11.1 -> 1.11.2
python3-flask-wtf: upgrade 0.15.1 -> 1.0.1
python3-gnupg: upgrade 0.4.8 -> 0.4.9
python3-google-api-python-client: upgrade 2.50.0 -> 2.51.0
python3-kiwisolver: upgrade 1.4.2 -> 1.4.3
python3-nmap: upgrade 1.5.1 -> 1.5.4
python3-asyncinotify: upgrade 2.0.4 -> 2.0.5
python3-google-auth: upgrade 2.7.0 -> 2.8.0
python3-protobuf: upgrade 4.21.1 -> 4.21.2
python3-sqlalchemy: upgrade 1.4.37 -> 1.4.39
python3-xmlschema: upgrade 1.11.2 -> 1.11.3
python3-engineio: upgrade 4.3.2 -> 4.3.3
python3-google-api-core: upgrade 2.8.0 -> 2.8.2
python3-google-auth: upgrade 2.8.0 -> 2.9.0
python3-grpcio-tools: upgrade 1.46.3 -> 1.47.0
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
Change-Id: I22f0dab7f3253d77cc99fd462c6be45ddeb333cd
diff --git a/poky/documentation/brief-yoctoprojectqs/index.rst b/poky/documentation/brief-yoctoprojectqs/index.rst
index 7179f25..3cf2f76 100644
--- a/poky/documentation/brief-yoctoprojectqs/index.rst
+++ b/poky/documentation/brief-yoctoprojectqs/index.rst
@@ -64,11 +64,12 @@
- tar &MIN_TAR_VERSION; or greater
- Python &MIN_PYTHON_VERSION; or greater.
- gcc &MIN_GCC_VERSION; or greater.
+ - GNU make &MIN_MAKE_VERSION; or greater
If your build host does not meet any of these three listed version
requirements, you can take steps to prepare the system so that you
can still use the Yocto Project. See the
-:ref:`ref-manual/system-requirements:required git, tar, python and gcc versions`
+:ref:`ref-manual/system-requirements:required git, tar, python, make and gcc versions`
section in the Yocto Project Reference Manual for information.
Build Host Packages
@@ -256,12 +257,7 @@
BB_SIGNATURE_HANDLER = "OEEquivHash"
BB_HASHSERVE = "auto"
BB_HASHSERVE_UPSTREAM = "typhoon.yocto.io:8687"
- SSTATE_MIRRORS ?= "file://.* https://sstate.yoctoproject.org/&YOCTO_DOC_VERSION;/PATH;downloadfilename=PATH"
-
- The above settings assumed the use of Yocto Project &YOCTO_DOC_VERSION;.
- If you are using the development version instead, set :term:`SSTATE_MIRRORS` as follows::
-
- SSTATE_MIRRORS ?= "file://.* https://sstate.yoctoproject.org/dev/PATH;downloadfilename=PATH"
+ SSTATE_MIRRORS ?= "file://.* https://sstate.yoctoproject.org/all/PATH;downloadfilename=PATH"
#. **Start the Build:** Continue with the following command to build an OS
image for the target, which is ``core-image-sato`` in this example:
diff --git a/poky/documentation/bsp-guide/bsp.rst b/poky/documentation/bsp-guide/bsp.rst
index 280b160..7e17b42 100644
--- a/poky/documentation/bsp-guide/bsp.rst
+++ b/poky/documentation/bsp-guide/bsp.rst
@@ -1,8 +1,8 @@
.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
-************************************************
-Board Support Packages (BSP) - Developer's Guide
-************************************************
+**************************************************
+Board Support Packages (BSP) --- Developer's Guide
+**************************************************
A Board Support Package (BSP) is a collection of information that
defines how to support a particular hardware device, set of devices, or
diff --git a/poky/documentation/conf.py b/poky/documentation/conf.py
index baf550e..2a01756 100644
--- a/poky/documentation/conf.py
+++ b/poky/documentation/conf.py
@@ -53,7 +53,7 @@
# -- General configuration ---------------------------------------------------
# Prevent building with an outdated version of sphinx
-needs_sphinx = "3.1"
+needs_sphinx = "4.0"
# to load local extension from the folder 'sphinx'
sys.path.insert(0, os.path.abspath('sphinx'))
@@ -90,7 +90,7 @@
# external links and substitutions
extlinks = {
- 'cve': ('https://nvd.nist.gov/vuln/detail/CVE-%s', 'CVE-'),
+ 'cve': ('https://nvd.nist.gov/vuln/detail/CVE-%s', 'CVE-%s'),
'yocto_home': ('https://www.yoctoproject.org%s', None),
'yocto_wiki': ('https://wiki.yoctoproject.org/wiki%s', None),
'yocto_dl': ('https://downloads.yoctoproject.org%s', None),
diff --git a/poky/documentation/dev-manual/common-tasks.rst b/poky/documentation/dev-manual/common-tasks.rst
index ca6d594..8be3c7c 100644
--- a/poky/documentation/dev-manual/common-tasks.rst
+++ b/poky/documentation/dev-manual/common-tasks.rst
@@ -2306,7 +2306,7 @@
:term:`SRC_URI` variable. Additionally, you need to manually write the
``do_compile`` and ``do_install`` tasks. The :term:`S` variable defines the
directory containing the source code, which is set to
-:term:`WORKDIR` in this case - the
+:term:`WORKDIR` in this case --- the
directory BitBake uses for the build.
::
@@ -2563,7 +2563,7 @@
Understanding recipe file syntax is important for writing recipes. The
following list overviews the basic items that make up a BitBake recipe
file. For more complete BitBake syntax descriptions, see the
-":doc:`bitbake-user-manual/bitbake-user-manual-metadata`"
+":doc:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata`"
chapter of the BitBake User Manual.
- *Variable Assignments and Manipulations:* Variable assignments allow
@@ -2621,7 +2621,7 @@
This next list summarizes the most important and most commonly used
parts of the recipe syntax. For more information on these parts of the
syntax, you can reference the
-:doc:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata` chapter
+":doc:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata`" chapter
in the BitBake User Manual.
- *Line Continuation (\\):* Use the backward slash (``\``) character to
@@ -2780,7 +2780,7 @@
functionality. The same considerations apply to various system
utilities (e.g. ``sed``, ``grep``, ``awk``, and so forth) that you
might wish to use. If in doubt, you should check with multiple
- implementations - including those from BusyBox.
+ implementations --- including those from BusyBox.
Adding a New Machine
====================
@@ -3348,9 +3348,9 @@
- :term:`PN`: The recipe name.
-- :term:`EXTENDPE`: The epoch - (if
+- :term:`EXTENDPE`: The epoch --- if
:term:`PE` is not specified, which is
- usually the case for most recipes, then :term:`EXTENDPE` is blank).
+ usually the case for most recipes, then :term:`EXTENDPE` is blank.
- :term:`PV`: The recipe version.
@@ -3704,7 +3704,7 @@
To accomplish a multiple configuration build, you must define each
target's configuration separately using a parallel configuration file in
-the :term:`Build Directory`, and you
+the :term:`Build Directory` or configuration directory within a layer, and you
must follow a required file hierarchy. Additionally, you must enable the
multiple configuration builds in your ``local.conf`` file.
@@ -3712,16 +3712,19 @@
- *Create Separate Configuration Files*: You need to create a single
configuration file for each build target (each multiconfig).
- Minimally, each configuration file must define the machine and the
- temporary directory BitBake uses for the build. Suggested practice
- dictates that you do not overlap the temporary directories used
- during the builds. However, it is possible that you can share the
- temporary directory
- (:term:`TMPDIR`). For example,
- consider a scenario with two different multiconfigs for the same
+ The configuration definitions are implementation dependent but often
+ each configuration file will define the machine and the
+ temporary directory BitBake uses for the build. Whether the same
+ temporary directory (:term:`TMPDIR`) can be shared will depend on what is
+ similar and what is different between the configurations. Multiple MACHINE
+ targets can share the same (:term:`TMPDIR`) as long as the rest of the
+ configuration is the same, multiple DISTRO settings would need separate
+ (:term:`TMPDIR`) directories.
+
+ For example, consider a scenario with two different multiconfigs for the same
:term:`MACHINE`: "qemux86" built
for two distributions such as "poky" and "poky-lsb". In this case,
- you might want to use the same :term:`TMPDIR`.
+ you would need to use the different :term:`TMPDIR`.
Here is an example showing the minimal statements needed in a
configuration file for a "qemux86" target whose temporary build
@@ -3732,18 +3735,16 @@
The location for these multiconfig configuration files is specific.
They must reside in the current build directory in a sub-directory of
- ``conf`` named ``multiconfig``. Following is an example that defines
+ ``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:
.. image:: figures/multiconfig_files.png
:align: center
:width: 50%
- The reason for this required file hierarchy is because the :term:`BBPATH`
- variable is not constructed until the layers are parsed.
- Consequently, using the configuration file as a pre-configuration
- file is not possible unless it is located in the current working
- directory.
+ The usual :term:`BBPATH` search path is used to locate multiconfig files in
+ a similar way to other conf files.
- *Add the BitBake Multi-configuration Variable to the Local
Configuration File*: Use the
@@ -6601,7 +6602,7 @@
installed into an image.
- Binary Package Version: The binary package version is composed of two
- components - a version and a revision.
+ components --- a version and a revision.
.. note::
@@ -6938,7 +6939,7 @@
Postinstall script to use for all packages
(as a string)
recursive
- True to perform a recursive search - default
+ True to perform a recursive search --- default
False
hook
A hook function to be called for every match.
@@ -6959,7 +6960,7 @@
Extra runtime dependencies (RDEPENDS) to be
set for all packages. The default value of None
causes a dependency on the main package
- (${PN}) - if you do not want this, pass empty
+ (${PN}) --- if you do not want this, pass empty
string '' for this parameter.
aux_files_pattern
Extra item(s) to be added to FILES for each
@@ -6985,7 +6986,7 @@
or a list of strings for multiple items. Must
include %s.
allow_links
- True to allow symlinks to be matched - default
+ True to allow symlinks to be matched --- default
False
summary
Summary to set for each package. Must include %s;
@@ -7430,7 +7431,7 @@
OpenEmbedded build system on the target machine. A ptest contains at
least two items: the actual test, and a shell script (``run-ptest``)
that starts the test. The shell script that starts the test must not
-contain the actual test - the script only starts the test. On the other
+contain the actual test --- the script only starts the test. On the other
hand, the test can be anything from a simple shell script that runs a
binary and checks the output to an elaborate system of test binaries and
data files.
@@ -7613,6 +7614,11 @@
fetch URI to download each dependency and capture license details where
possible. The result is a generated recipe.
+After running for quite a long time, in particular building the
+``nodejs-native`` package, the command should end as follows::
+
+ INFO: Recipe /home/.../build/workspace/recipes/cute-files/cute-files_1.0.2.bb has been automatically created; further editing may be required to make it fully functional
+
The recipe file is fairly simple and contains every license that
``recipetool`` finds and includes the licenses in the recipe's
:term:`LIC_FILES_CHKSUM`
@@ -7623,7 +7629,7 @@
``recipetool`` creates a "shrinkwrap" file for your recipe. Shrinkwrap
files capture the version of all dependent modules. Many packages do not
-provide shrinkwrap files. ``recipetool`` create a shrinkwrap file as it
+provide shrinkwrap files but ``recipetool`` will create a shrinkwrap file as it
runs.
.. note::
@@ -7635,18 +7641,38 @@
The ``devtool edit-recipe`` command lets you take a look at the recipe::
$ devtool edit-recipe cute-files
+ # Recipe created by recipetool
+ # This is the basis of a recipe and may need further editing in order to be fully functional.
+ # (Feel free to remove these comments when editing.)
+
SUMMARY = "Turn any folder on your computer into a cute file browser, available on the local network."
- LICENSE = "MIT & ISC & Unknown"
+ # WARNING: the following LICENSE and LIC_FILES_CHKSUM values are best guesses - it is
+ # your responsibility to verify that the values are complete and correct.
+ #
+ # NOTE: multiple licenses have been detected; they have been separated with &
+ # in the LICENSE value for now since it is a reasonable assumption that all
+ # of the licenses apply. If instead there is a choice between the multiple
+ # licenses then you should change the value to separate the licenses with |
+ # instead of &. If there is any doubt, check the accompanying documentation
+ # to determine which situation is applicable.
+
+ SUMMARY = "Turn any folder on your computer into a cute file browser, available on the local network."
+ LICENSE = "BSD-3-Clause & ISC & MIT"
LIC_FILES_CHKSUM = "file://LICENSE;md5=71d98c0a1db42956787b1909c74a86ca \
- file://node_modules/toidentifier/LICENSE;md5=1a261071a044d02eb6f2bb47f51a3502 \
- file://node_modules/debug/LICENSE;md5=ddd815a475e7338b0be7a14d8ee35a99 \
- ...
+ file://node_modules/accepts/LICENSE;md5=bf1f9ad1e2e1d507aef4883fff7103de \
+ file://node_modules/array-flatten/LICENSE;md5=44088ba57cb871a58add36ce51b8de08 \
+ ...
+ file://node_modules/cookie-signature/Readme.md;md5=57ae8b42de3dd0c1f22d5f4cf191e15a"
+
SRC_URI = " \
npm://registry.npmjs.org/;package=cute-files;version=${PV} \
npmsw://${THISDIR}/${BPN}/npm-shrinkwrap.json \
"
+
S = "${WORKDIR}/npm"
+
inherit npm
+
LICENSE:${PN} = "MIT"
LICENSE:${PN}-accepts = "MIT"
LICENSE:${PN}-array-flatten = "MIT"
@@ -7679,17 +7705,10 @@
$ devtool deploy-target -s cute-files root@192.168.7.2
Once the package is installed on the target, you can
-test the application:
-
-.. note::
-
- Because of a known issue, you cannot simply run ``cute-files`` as you would
- if you had run ``npm install``.
-
-::
+test the application to show the contents of any directory::
$ cd /usr/lib/node_modules/cute-files
- $ node cute-files.js
+ $ cute-files
On a browser,
go to ``http://192.168.7.2:3000`` and you see the following:
@@ -7717,12 +7736,11 @@
$ devtool add https://github.com/martinaglv/cute-files.git
-The
-recipe this command generates is very similar to the recipe created in
+The recipe this command generates is very similar to the recipe created in
the previous section. However, the :term:`SRC_URI` looks like the following::
SRC_URI = " \
- git://github.com/martinaglv/cute-files.git;protocol=https \
+ git://github.com/martinaglv/cute-files.git;protocol=https;branch=master \
npmsw://${THISDIR}/${BPN}/npm-shrinkwrap.json \
"
@@ -9131,13 +9149,13 @@
object or an array. This object (or array of objects) uses the following
data:
-- "pkg" - A mandatory string that is the name of the package to be
+- "pkg" --- a mandatory string that is the name of the package to be
installed.
-- "rm" - An optional boolean, which defaults to "false", that specifies
+- "rm" --- an optional boolean, which defaults to "false", that specifies
to remove the package after the test.
-- "extract" - An optional boolean, which defaults to "false", that
+- "extract" --- an optional boolean, which defaults to "false", that
specifies if the package must be extracted from the package format.
When set to "true", the package is not automatically installed into
the DUT.
@@ -9802,7 +9820,7 @@
~~~~~~~~~~~~~~~~~
When creating recipes using Bash and inserting code that handles build
-logs, you have the same goals - informative with minimal console output.
+logs, you have the same goals --- informative with minimal console output.
The syntax you use for recipes written in Bash is similar to that of
recipes written in Python described in the previous section.
@@ -10075,7 +10093,7 @@
constraints arise because GDB needs to load the debugging information
and the binaries of the process being debugged. Additionally, GDB needs
to perform many computations to locate information such as function
-names, variable names and values, stack traces and so forth - even
+names, variable names and values, stack traces and so forth --- even
before starting the debugging process. These extra computations place
more load on the target system and can alter the characteristics of the
program being debugged.
@@ -10652,7 +10670,7 @@
- If the change addresses a specific bug or issue that is associated
with a bug-tracking ID, include a reference to that ID in your
detailed description. For example, the Yocto Project uses a
- specific convention for bug references - any commit that addresses
+ specific convention for bug references --- any commit that addresses
a specific bug should use the following form for the detailed
description. Be sure to use the actual bug-tracking ID from
Bugzilla for bug-id::
@@ -10915,20 +10933,20 @@
result in the most straightforward path into the stable branch for the
fix.
- a. *If the fix is present in the master branch - Submit a backport request
+ a. *If the fix is present in the master branch --- submit a backport request
by email:* You should send an email to the relevant stable branch
maintainer and the mailing list with details of the bug or CVE to be
fixed, the commit hash on the master branch that fixes the issue and
the stable branches which you would like this fix to be backported to.
- b. *If the fix is not present in the master branch - Submit the fix to the
+ b. *If the fix is not present in the master branch --- submit the fix to the
master branch first:* This will ensure that the fix passes through the
project's usual patch review and test processes before being accepted.
It will also ensure that bugs are not left unresolved in the master
branch itself. Once the fix is accepted in the master branch a backport
request can be submitted as above.
- c. *If the fix is unsuitable for the master branch - Submit a patch
+ c. *If the fix is unsuitable for the master branch --- submit a patch
directly for the stable branch:* This method should be considered as a
last resort. It is typically necessary when the master branch is using
a newer version of the software which includes an upstream fix for the
@@ -11259,7 +11277,7 @@
Compliance activities should begin before you generate the final image.
The first thing you should look at is the requirement that tops the list
-for most compliance groups - providing the source. The Yocto Project has
+for most compliance groups --- providing the source. The Yocto Project has
a few ways of meeting this requirement.
One of the easiest ways to meet this requirement is to provide the
@@ -11507,8 +11525,15 @@
`Common Vulnerabilities and Exposures (CVE) <https://en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures>`__
database.
-To know which packages are vulnerable to known security vulnerabilities,
-add the following setting to your configuration::
+The Yocto Project maintains a `list of known vulnerabilities
+<https://autobuilder.yocto.io/pub/non-release/patchmetrics/>`__
+for packages in Poky and OE-Core, tracking the evolution of the number of
+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::
INHERIT += "cve-check"
diff --git a/poky/documentation/dev-manual/figures/cute-files-npm-example.png b/poky/documentation/dev-manual/figures/cute-files-npm-example.png
index 1ebe74f..a02cca0 100644
--- a/poky/documentation/dev-manual/figures/cute-files-npm-example.png
+++ b/poky/documentation/dev-manual/figures/cute-files-npm-example.png
Binary files differ
diff --git a/poky/documentation/dev-manual/start.rst b/poky/documentation/dev-manual/start.rst
index 8cf3ebe..499c3f8 100644
--- a/poky/documentation/dev-manual/start.rst
+++ b/poky/documentation/dev-manual/start.rst
@@ -311,7 +311,7 @@
3. *Meet Minimal Version Requirements:* The OpenEmbedded build system
should be able to run on any modern distribution that has the
- following versions for Git, tar, Python and gcc.
+ following versions for Git, tar, Python, gcc and make.
- Git &MIN_GIT_VERSION; or greater
@@ -321,10 +321,12 @@
- gcc &MIN_GCC_VERSION; or greater.
+ - GNU make &MIN_MAKE_VERSION; or greater
+
If your build host does not meet any of these listed version
requirements, you can take steps to prepare the system so that you
can still use the Yocto Project. See the
- ":ref:`ref-manual/system-requirements:required git, tar, python and gcc versions`"
+ ":ref:`ref-manual/system-requirements:required git, tar, python, make and gcc versions`"
section in the Yocto Project Reference Manual for information.
4. *Install Development Host Packages:* Required development host
diff --git a/poky/documentation/kernel-dev/advanced.rst b/poky/documentation/kernel-dev/advanced.rst
index b5290b6..b16b3e0 100644
--- a/poky/documentation/kernel-dev/advanced.rst
+++ b/poky/documentation/kernel-dev/advanced.rst
@@ -183,7 +183,7 @@
order to define a base kernel policy or major kernel type to be
reused across multiple BSPs, place the file in ``ktypes`` directory.
-These distinctions can easily become blurred - especially as out-of-tree
+These distinctions can easily become blurred --- especially as out-of-tree
features slowly merge upstream over time. Also, remember that how the
description files are placed is a purely logical organization and has no
impact on the functionality of the kernel Metadata. There is no impact
diff --git a/poky/documentation/kernel-dev/concepts-appx.rst b/poky/documentation/kernel-dev/concepts-appx.rst
index b3a2f3a..63c5124 100644
--- a/poky/documentation/kernel-dev/concepts-appx.rst
+++ b/poky/documentation/kernel-dev/concepts-appx.rst
@@ -117,7 +117,7 @@
team's Yocto Linux kernel development strategy. It is the Yocto Project
team's policy to not back-port minor features to the released Yocto
Linux kernel. They only consider back-porting significant technological
-jumps - and, that is done after a complete gap analysis. The reason
+jumps --- and, that is done after a complete gap analysis. The reason
for this policy is that back-porting any small to medium sized change
from an evolving Linux kernel can easily create mismatches,
incompatibilities and very subtle errors.
diff --git a/poky/documentation/migration-guides/migration-1.5.rst b/poky/documentation/migration-guides/migration-1.5.rst
index 93db14c..366fb00 100644
--- a/poky/documentation/migration-guides/migration-1.5.rst
+++ b/poky/documentation/migration-guides/migration-1.5.rst
@@ -26,7 +26,7 @@
tarball, which provides an SDK-like environment containing them.
For more information on this requirement, see the
-":ref:`ref-manual/system-requirements:required git, tar, python and gcc versions`"
+":ref:`ref-manual/system-requirements:required git, tar, python, make and gcc versions`"
section.
.. _migration-1.5-atom-pc-bsp:
diff --git a/poky/documentation/migration-guides/migration-1.6.rst b/poky/documentation/migration-guides/migration-1.6.rst
index 3580865..f54d4ba 100644
--- a/poky/documentation/migration-guides/migration-1.6.rst
+++ b/poky/documentation/migration-guides/migration-1.6.rst
@@ -341,39 +341,39 @@
The following recipes have been removed:
-- ``packagegroup-toolset-native`` - This recipe is largely unused.
+- ``packagegroup-toolset-native`` --- this recipe is largely unused.
-- ``linux-yocto-3.8`` - Support for the Linux yocto 3.8 kernel has been
+- ``linux-yocto-3.8`` --- support for the Linux yocto 3.8 kernel has been
dropped. Support for the 3.10 and 3.14 kernels have been added with
the ``linux-yocto-3.10`` and ``linux-yocto-3.14`` recipes.
-- ``ocf-linux`` - This recipe has been functionally replaced using
+- ``ocf-linux`` --- this recipe has been functionally replaced using
``cryptodev-linux``.
-- ``genext2fs`` - ``genext2fs`` is no longer used by the build system
+- ``genext2fs`` --- ``genext2fs`` is no longer used by the build system
and is unmaintained upstream.
-- ``js`` - This provided an ancient version of Mozilla's javascript
+- ``js`` --- this provided an ancient version of Mozilla's javascript
engine that is no longer needed.
-- ``zaurusd`` - The recipe has been moved to the ``meta-handheld``
+- ``zaurusd`` --- the recipe has been moved to the ``meta-handheld``
layer.
-- ``eglibc 2.17`` - Replaced by the ``eglibc 2.19`` recipe.
+- ``eglibc 2.17`` --- replaced by the ``eglibc 2.19`` recipe.
-- ``gcc 4.7.2`` - Replaced by the now stable ``gcc 4.8.2``.
+- ``gcc 4.7.2`` --- replaced by the now stable ``gcc 4.8.2``.
-- ``external-sourcery-toolchain`` - this recipe is now maintained in
+- ``external-sourcery-toolchain`` --- this recipe is now maintained in
the ``meta-sourcery`` layer.
-- ``linux-libc-headers-yocto 3.4+git`` - Now using version 3.10 of the
+- ``linux-libc-headers-yocto 3.4+git`` --- now using version 3.10 of the
``linux-libc-headers`` by default.
-- ``meta-toolchain-gmae`` - This recipe is obsolete.
+- ``meta-toolchain-gmae`` --- this recipe is obsolete.
-- ``packagegroup-core-sdk-gmae`` - This recipe is obsolete.
+- ``packagegroup-core-sdk-gmae`` --- this recipe is obsolete.
-- ``packagegroup-core-standalone-gmae-sdk-target`` - This recipe is
+- ``packagegroup-core-standalone-gmae-sdk-target`` --- this recipe is
obsolete.
.. _migration-1.6-removed-classes:
diff --git a/poky/documentation/migration-guides/migration-1.7.rst b/poky/documentation/migration-guides/migration-1.7.rst
index 88a6855..8213ab5 100644
--- a/poky/documentation/migration-guides/migration-1.7.rst
+++ b/poky/documentation/migration-guides/migration-1.7.rst
@@ -31,7 +31,7 @@
BitBake's Git fetcher. As always, if your host distribution does not
provide a version of Git that meets this requirement, you can use the
``buildtools-tarball`` that does. See the
-":ref:`ref-manual/system-requirements:required git, tar, python and gcc versions`"
+":ref:`ref-manual/system-requirements:required git, tar, python, make and gcc versions`"
section for more information.
.. _migration-1.7-autotools-class-changes:
diff --git a/poky/documentation/migration-guides/migration-2.1.rst b/poky/documentation/migration-guides/migration-2.1.rst
index ae6268d..b2d8a0b 100644
--- a/poky/documentation/migration-guides/migration-2.1.rst
+++ b/poky/documentation/migration-guides/migration-2.1.rst
@@ -357,7 +357,7 @@
- The minimum Git version has been increased to 1.8.3.1. If your host
distribution does not provide a sufficiently recent version, you can
install the buildtools, which will provide it. See the
- :ref:`ref-manual/system-requirements:required git, tar, python and gcc versions`
+ :ref:`ref-manual/system-requirements:required git, tar, python, make and gcc versions`
section for more information on the buildtools tarball.
- The buggy and incomplete support for the RPM version 4 package
diff --git a/poky/documentation/migration-guides/migration-2.2.rst b/poky/documentation/migration-guides/migration-2.2.rst
index fe7bc2c..16e48cc 100644
--- a/poky/documentation/migration-guides/migration-2.2.rst
+++ b/poky/documentation/migration-guides/migration-2.2.rst
@@ -442,7 +442,7 @@
- :ref:`ref-classes-image`: Renamed COMPRESS(ION) to CONVERSION. This change
means that ``COMPRESSIONTYPES``, ``COMPRESS_DEPENDS`` and
``COMPRESS_CMD`` are deprecated in favor of ``CONVERSIONTYPES``,
- ``CONVERSION_DEPENDS`` and ``CONVERSION_CMD``. The ``COMPRESS*``
+ ``CONVERSION_DEPENDS`` and :term:`CONVERSION_CMD`. The ``COMPRESS*``
variable names will still work in the 2.2 release but metadata that
does not need to be backwards-compatible should be changed to use the
new names as the ``COMPRESS*`` ones will be removed in a future
diff --git a/poky/documentation/migration-guides/migration-2.4.rst b/poky/documentation/migration-guides/migration-2.4.rst
index ef5f32e..964ed92 100644
--- a/poky/documentation/migration-guides/migration-2.4.rst
+++ b/poky/documentation/migration-guides/migration-2.4.rst
@@ -301,7 +301,7 @@
likely be removed in the next Yocto Project release.
- The ``vmdk``, ``vdi``, and ``qcow2`` image file types are now used in
- conjunction with the "wic" image type through ``CONVERSION_CMD``.
+ conjunction with the "wic" image type through :term:`CONVERSION_CMD`.
Consequently, the equivalent image types are now ``wic.vmdk``,
``wic.vdi``, and ``wic.qcow2``, respectively.
diff --git a/poky/documentation/migration-guides/migration-3.0.rst b/poky/documentation/migration-guides/migration-3.0.rst
index 1219edf..96aea2f 100644
--- a/poky/documentation/migration-guides/migration-3.0.rst
+++ b/poky/documentation/migration-guides/migration-3.0.rst
@@ -216,11 +216,11 @@
- :term:`SRC_URI` is now checked for usage of two
problematic items:
- - "${PN}" prefix/suffix use - Warnings always appear if ${PN} is
+ - "${PN}" prefix/suffix use --- warnings always appear if ${PN} is
used. You must fix the issue regardless of whether multiconfig or
anything else that would cause prefixing/suffixing to happen.
- - Github archive tarballs - these are not guaranteed to be stable.
+ - Github archive tarballs --- these are not guaranteed to be stable.
Consequently, it is likely that the tarballs will be refreshed and
thus the SRC_URI checksums will fail to apply. It is recommended
that you fetch either an official release tarball or a specific
diff --git a/poky/documentation/migration-guides/migration-3.1.rst b/poky/documentation/migration-guides/migration-3.1.rst
index e3fdbbe..cc788ef 100644
--- a/poky/documentation/migration-guides/migration-3.1.rst
+++ b/poky/documentation/migration-guides/migration-3.1.rst
@@ -200,7 +200,7 @@
-----------------
- ``intltool`` has been removed from ``packagegroup-core-sdk`` as it is
- rarely needed to build modern software - gettext can do most of the
+ rarely needed to build modern software --- gettext can do most of the
things it used to be needed for. ``intltool`` has also been removed
from ``packagegroup-core-self-hosted`` as it is not needed to for
standard builds.
diff --git a/poky/documentation/migration-guides/migration-3.2.rst b/poky/documentation/migration-guides/migration-3.2.rst
index a376ece..92b7f91 100644
--- a/poky/documentation/migration-guides/migration-3.2.rst
+++ b/poky/documentation/migration-guides/migration-3.2.rst
@@ -23,7 +23,7 @@
The following recipes have been removed:
- ``bjam-native``: replaced by ``boost-build-native``
-- ``avahi-ui``: folded into the main ``avahi`` recipe - the GTK UI can be disabled using :term:`PACKAGECONFIG` for ``avahi``.
+- ``avahi-ui``: folded into the main ``avahi`` recipe --- the GTK UI can be disabled using :term:`PACKAGECONFIG` for ``avahi``.
- ``build-compare``: no longer needed with the removal of the ``packagefeed-stability`` class
- ``dhcp``: obsolete, functionally replaced by ``dhcpcd`` and ``kea``
- ``libmodulemd-v1``: replaced by ``libmodulemd``
@@ -37,7 +37,7 @@
The following classes (.bbclass files) have been removed:
-- ``spdx``: obsolete - the Yocto Project is a strong supporter of SPDX, but this class was old code using a dated approach and had the potential to be misleading. The ``meta-sdpxscanner`` layer is a much more modern and active approach to handling this and is recommended as a replacement.
+- ``spdx``: obsolete --- the Yocto Project is a strong supporter of SPDX, but this class was old code using a dated approach and had the potential to be misleading. The ``meta-sdpxscanner`` layer is a much more modern and active approach to handling this and is recommended as a replacement.
- ``packagefeed-stability``: this class had become obsolete with the advent of hash equivalence and reproducible builds.
@@ -46,7 +46,7 @@
--------------------------------------------
pseudo now operates on a filtered subset of files. This is a significant change
-to the way pseudo operates within OpenEmbedded - by default, pseudo monitors and
+to the way pseudo operates within OpenEmbedded --- by default, pseudo monitors and
logs (adds to its database) any file created or modified whilst in a ``fakeroot``
environment. However, there are large numbers of files that we simply don't care
about the permissions of whilst in that ``fakeroot`` context, for example ${:term:`S`}, ${:term:`B`}, ${:term:`T`},
@@ -68,7 +68,7 @@
extend :term:`PSEUDO_IGNORE_PATHS` to cover additional paths that pseudo should not
be monitoring.
-In addition, pseudo's behaviour on mismatches has now been changed - rather
+In addition, pseudo's behaviour on mismatches has now been changed --- rather
than doing what turns out to be a rather dangerous "fixup" if it sees a file
with a different path but the same inode as another file it has previously seen,
pseudo will throw an ``abort()`` and direct you to a :yocto_wiki:`wiki page </Pseudo_Abort>`
@@ -137,10 +137,10 @@
The ``dhcp`` software package has become unmaintained and thus has been
functionally replaced by ``dhcpcd`` (client) and ``kea`` (server). You will
-need to replace references to the recipe/package names as appropriate - most
+need to replace references to the recipe/package names as appropriate --- most
commonly, at the package level ``dhcp-client`` should be replaced by
``dhcpcd`` and ``dhcp-server`` should be replaced by ``kea``. If you have any
-custom configuration files for these they will need to be adapted - refer to
+custom configuration files for these they will need to be adapted --- refer to
the upstream documentation for ``dhcpcd`` and ``kea`` for further details.
@@ -181,7 +181,7 @@
- :ref:`missing-update-alternatives <qa-check-missing-update-alternatives>`: Check if the recipe sets the :term:`ALTERNATIVE` variable for any of its packages, and does not inherit the :ref:`update-alternatives <ref-classes-update-alternatives>` class.
-- A trailing slash or duplicated slashes in the value of :term:`S` or :term:`B` will now trigger a warning so that they can be removed and path comparisons can be more reliable - remove any instances of these in your recipes if the warning is displayed.
+- A trailing slash or duplicated slashes in the value of :term:`S` or :term:`B` will now trigger a warning so that they can be removed and path comparisons can be more reliable --- remove any instances of these in your recipes if the warning is displayed.
.. _migration-3.2-src-uri-file-globbing:
@@ -209,7 +209,7 @@
``do_deploy`` as implemented in the :ref:`deploy <ref-classes-deploy>` class now cleans up ${:term:`DEPLOYDIR`} before running, just as ``do_install`` cleans up ${:term:`D`} before running. This reduces the risk of :term:`DEPLOYDIR` being accidentally contaminated by files from previous runs, possibly even with different config, in case of incremental builds.
-Most recipes and classes that inherit the :ref:`deploy <ref-classes-deploy>` class or interact with ``do_deploy`` are unlikely to be affected by this unless they add ``prefuncs`` to ``do_deploy`` *which also* put files into ``${DEPLOYDIR}`` - these should be refactored to use ``do_deploy_prepend`` instead.
+Most recipes and classes that inherit the :ref:`deploy <ref-classes-deploy>` class or interact with ``do_deploy`` are unlikely to be affected by this unless they add ``prefuncs`` to ``do_deploy`` *which also* put files into ``${DEPLOYDIR}`` --- these should be refactored to use ``do_deploy_prepend`` instead.
.. _migration-3.2-nativesdk-sdk-provides-dummy:
@@ -303,7 +303,7 @@
Miscellaneous changes
---------------------
-- Support for the long-deprecated ``PACKAGE_GROUP`` variable has now been removed - replace any remaining instances with :term:`FEATURE_PACKAGES`.
+- Support for the long-deprecated ``PACKAGE_GROUP`` variable has now been removed --- replace any remaining instances with :term:`FEATURE_PACKAGES`.
- The ``FILESPATHPKG`` variable, having been previously deprecated, has now been removed. Replace any remaining references with appropriate use of :term:`FILESEXTRAPATHS`.
- Erroneous use of ``inherit +=`` (instead of ``INHERIT +=``) in a configuration file now triggers an error instead of silently being ignored.
- ptest support has been removed from the ``kbd`` recipe, as upstream has moved to autotest which is difficult to work with in a cross-compilation environment.
diff --git a/poky/documentation/migration-guides/migration-3.3.rst b/poky/documentation/migration-guides/migration-3.3.rst
index 22562da..aba5c42 100644
--- a/poky/documentation/migration-guides/migration-3.3.rst
+++ b/poky/documentation/migration-guides/migration-3.3.rst
@@ -13,11 +13,10 @@
You will now need at least Python 3.6 installed on your build host. Most recent
distributions provide this, but should you be building on a distribution that
does not have it, you can use the ``buildtools-tarball`` (easily installable
-using ``scripts/install-buildtools``) - see
-:ref:`ref-manual/system-requirements:required git, tar, python and gcc versions`
+using ``scripts/install-buildtools``) --- see
+:ref:`ref-manual/system-requirements:required git, tar, python, make and gcc versions`
for details.
-
.. _migration-3.3-removed-recipes:
Removed recipes
diff --git a/poky/documentation/migration-guides/migration-3.4.rst b/poky/documentation/migration-guides/migration-3.4.rst
index 8db43a1..bc2c75d 100644
--- a/poky/documentation/migration-guides/migration-3.4.rst
+++ b/poky/documentation/migration-guides/migration-3.4.rst
@@ -146,7 +146,7 @@
~~~~~~~~~~~~~~~~~~~~~~~~
Recipes shouldn't use the ``virtual/`` string in :term:`RPROVIDES` and
-:term:`RDEPENDS` - it is confusing because ``virtual/`` has no special
+:term:`RDEPENDS` --- it is confusing because ``virtual/`` has no special
meaning in :term:`RPROVIDES` and :term:`RDEPENDS` (unlike in the
corresponding build-time :term:`PROVIDES` and :term:`DEPENDS`).
@@ -171,7 +171,7 @@
For a normal SDK, some layers append to :term:`TOOLCHAIN_HOST_TASK`
unconditionally which is fine, until the eSDK tries to override the
variable to its own values. Instead of installing packages specified
-in this variable it uses native recipes instead - a very different
+in this variable it uses native recipes instead --- a very different
approach. This has led to confusing errors when binaries are added
to the SDK but not relocated.
@@ -252,7 +252,7 @@
- The previously deprecated ``COMPRESS_CMD`` and
``CVE_CHECK_CVE_WHITELIST`` variables have been removed. Use
- ``CONVERSION_CMD`` and ``CVE_CHECK_WHITELIST`` (replaced by
+ :term:`CONVERSION_CMD` and ``CVE_CHECK_WHITELIST`` (replaced by
:term:`CVE_CHECK_IGNORE` in version 3.5) respectively
instead.
diff --git a/poky/documentation/migration-guides/migration-4.0.rst b/poky/documentation/migration-guides/migration-4.0.rst
index a8e6b4c..79e53f8 100644
--- a/poky/documentation/migration-guides/migration-4.0.rst
+++ b/poky/documentation/migration-guides/migration-4.0.rst
@@ -45,7 +45,7 @@
- ``SSTATE_DUPWHITELIST`` became ``SSTATE_ALLOW_OVERLAP_FILES``
- ``SYSROOT_DIRS_BLACKLIST`` became :term:`SYSROOT_DIRS_IGNORE`
- ``UNKNOWN_CONFIGURE_WHITELIST`` became :term:`UNKNOWN_CONFIGURE_OPT_IGNORE`
-- ``WHITELIST_<license>`` became ``INCOMPATIBLE_LICENSE_EXCEPTIONS``
+- ``WHITELIST_<license>`` became :term:`INCOMPATIBLE_LICENSE_EXCEPTIONS`
In addition, ``BB_STAMP_WHITELIST``, ``BB_STAMP_POLICY``, ``INHERIT_BLACKLIST``,
``TUNEABI``, ``TUNEABI_WHITELIST``, and ``TUNEABI_OVERRIDE`` have been removed.
diff --git a/poky/documentation/migration-guides/release-notes-3.4.rst b/poky/documentation/migration-guides/release-notes-3.4.rst
index 5a8fb4b..323e4df 100644
--- a/poky/documentation/migration-guides/release-notes-3.4.rst
+++ b/poky/documentation/migration-guides/release-notes-3.4.rst
@@ -5,7 +5,7 @@
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Linux kernel 5.14, glibc 2.34 and ~280 other recipe upgrades
-- Switched override character to ':' (replacing '_') for more robust parsing and improved performance - see the above migration guide for help
+- Switched override character to ':' (replacing '_') for more robust parsing and improved performance --- see the above migration guide for help
- Rust integrated into core, providing rust support for cross-compilation and SDK
- New create-spdx class for creating SPDX SBoM documents
- New recipes: cargo, core-image-ptest-all, core-image-ptest-fast, core-image-weston-sdk, erofs-utils, gcompat, gi-docgen, libmicrohttpd, libseccomp, libstd-rs, perlcross, python3-markdown, python3-pyyaml, python3-smartypants, python3-typogrify, rust, rust-cross, rust-cross-canadian, rust-hello-world, rust-llvm, rust-tools-cross-canadian, rustfmt, xwayland
diff --git a/poky/documentation/migration-guides/release-notes-4.0.rst b/poky/documentation/migration-guides/release-notes-4.0.rst
index eaa40f9..4bf680d 100644
--- a/poky/documentation/migration-guides/release-notes-4.0.rst
+++ b/poky/documentation/migration-guides/release-notes-4.0.rst
@@ -23,7 +23,7 @@
BB_SIGNATURE_HANDLER = "OEEquivHash"
BB_HASHSERVE = "auto"
BB_HASHSERVE_UPSTREAM = "typhoon.yocto.io:8687"
- SSTATE_MIRRORS ?= "file://.* https://sstate.yoctoproject.org/&YOCTO_DOC_VERSION;/PATH;downloadfilename=PATH"
+ SSTATE_MIRRORS ?= "file://.* https://sstate.yoctoproject.org/all/PATH;downloadfilename=PATH"
- The Python package build process is now based on `wheels <https://pythonwheels.com/>`__
in line with the upstream direction.
diff --git a/poky/documentation/overview-manual/concepts.rst b/poky/documentation/overview-manual/concepts.rst
index 016577e..83339da 100644
--- a/poky/documentation/overview-manual/concepts.rst
+++ b/poky/documentation/overview-manual/concepts.rst
@@ -557,7 +557,7 @@
~~~~~~~~~~~~~~
Local projects are custom bits of software the user provides. These bits
-reside somewhere local to a project - perhaps a directory into which the
+reside somewhere local to a project --- perhaps a directory into which the
user checks in items (e.g. a local directory containing a development
source tree used by the group).
@@ -1641,7 +1641,7 @@
To complicate the problem, there are things that should not be included
in the checksum. First, there is the actual specific build path of a
-given task - the :term:`WORKDIR`. It
+given task --- the :term:`WORKDIR`. It
does not matter if the work directory changes because it should not
affect the output for target packages. Also, the build process has the
objective of making native or cross packages relocatable.
@@ -1700,7 +1700,7 @@
Thus far, this section has limited discussion to the direct inputs into
a task. Information based on direct inputs is referred to as the
"basehash" in the code. However, the question of a task's indirect
-inputs still exits - items already built and present in the
+inputs still exits --- items already built and present in the
:term:`Build Directory`. The checksum (or
signature) for a particular task needs to add the hashes of all the
tasks on which the particular task depends. Choosing which dependencies
diff --git a/poky/documentation/overview-manual/development-environment.rst b/poky/documentation/overview-manual/development-environment.rst
index f1001e0..43a6f1b 100644
--- a/poky/documentation/overview-manual/development-environment.rst
+++ b/poky/documentation/overview-manual/development-environment.rst
@@ -52,7 +52,7 @@
using the Yocto Project. Because the goal of the Yocto Project is to
develop images or applications that run on embedded hardware,
development of those images and applications generally takes place on a
-system not intended to run the software - the development host.
+system not intended to run the software --- the development host.
You need to set up a development host in order to use it with the Yocto
Project. Most find that it is best to have a native Linux machine
diff --git a/poky/documentation/overview-manual/yp-intro.rst b/poky/documentation/overview-manual/yp-intro.rst
index a2e0862..4e3b7c3 100644
--- a/poky/documentation/overview-manual/yp-intro.rst
+++ b/poky/documentation/overview-manual/yp-intro.rst
@@ -842,7 +842,7 @@
distribution.
Another point worth noting is that historically within the Yocto
- Project, recipes were referred to as packages - thus, the existence
+ Project, recipes were referred to as packages --- thus, the existence
of several BitBake variables that are seemingly mis-named, (e.g.
:term:`PR`,
:term:`PV`, and
diff --git a/poky/documentation/poky.yaml.in b/poky/documentation/poky.yaml.in
index 1e1d6c8..6b942f0 100644
--- a/poky/documentation/poky.yaml.in
+++ b/poky/documentation/poky.yaml.in
@@ -44,4 +44,5 @@
MIN_PYTHON_VERSION : "3.6.0"
MIN_TAR_VERSION : "1.28"
MIN_GIT_VERSION : "1.8.3.1"
-MIN_GCC_VERSION : "5.0"
+MIN_GCC_VERSION : "7.5"
+MIN_MAKE_VERSION : "4.0"
diff --git a/poky/documentation/profile-manual/intro.rst b/poky/documentation/profile-manual/intro.rst
index 9c8fa3d..e9208df 100644
--- a/poky/documentation/profile-manual/intro.rst
+++ b/poky/documentation/profile-manual/intro.rst
@@ -7,7 +7,7 @@
Introduction
============
-Yocto bundles a number of tracing and profiling tools - this 'HOWTO'
+Yocto bundles a number of tracing and profiling tools --- this 'HOWTO'
describes their basic usage and shows by example how to make use of them
to examine application and system behavior.
@@ -26,7 +26,7 @@
The final section of this 'HOWTO' is a collection of real-world examples
which we'll be continually adding to as we solve more problems using the
-tools - feel free to add your own examples to the list!
+tools --- feel free to add your own examples to the list!
General Setup
=============
diff --git a/poky/documentation/profile-manual/usage.rst b/poky/documentation/profile-manual/usage.rst
index 0ff9d92..49f8af4 100644
--- a/poky/documentation/profile-manual/usage.rst
+++ b/poky/documentation/profile-manual/usage.rst
@@ -17,7 +17,7 @@
with the Linux kernel.
Don't let the fact that it's part of the kernel fool you into thinking
-that it's only for tracing and profiling the kernel - you can indeed use
+that it's only for tracing and profiling the kernel --- you can indeed use
it to trace and profile just the kernel, but you can also use it to
profile specific applications separately (with or without kernel
context), and you can also use it to trace and profile the kernel and
@@ -176,7 +176,7 @@
As our first attempt at profiling this workload, we'll simply run 'perf
record', handing it the workload we want to profile (everything after
-'perf record' and any perf options we hand it - here none - will be
+'perf record' and any perf options we hand it --- here none, will be
executed in a new shell). perf collects samples until the process exits
and records them in a file named 'perf.data' in the current working
directory. ::
@@ -203,7 +203,7 @@
'bucket' corresponding to the functions that were profiled during the
profiling run, ordered from the most popular to the least (perf has
options to sort in various orders and keys as well as display entries
-only above a certain threshold and so on - see the perf documentation
+only above a certain threshold and so on --- see the perf documentation
for details). Note that this includes both userspace functions (entries
containing a [.]) and kernel functions accounted to the process (entries
containing a [k]). (perf has command-line modifiers that can be used to
@@ -608,7 +608,7 @@
The screenshot above shows the results of running a profile using
sched:sched_switch tracepoint, which shows the relative costs of various
paths to sched_wakeup (note that sched_wakeup is the name of the
-tracepoint - it's actually defined just inside ttwu_do_wakeup(), which
+tracepoint --- it's actually defined just inside ttwu_do_wakeup(), which
accounts for the function name actually displayed in the profile:
.. code-block:: c
@@ -877,7 +877,7 @@
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The examples so far have focused on tracing a particular program or
-workload - in other words, every profiling run has specified the program
+workload --- in other words, every profiling run has specified the program
to profile in the command-line e.g. 'perf record wget ...'.
It's also possible, and more interesting in many cases, to run a
@@ -964,7 +964,7 @@
Notice that there are a lot of events that don't really have anything to
do with what we're interested in, namely events that schedule 'perf'
itself in and out or that wake perf up. We can get rid of those by using
-the '--filter' option - for each event we specify using -e, we can add a
+the '--filter' option --- for each event we specify using -e, we can add a
--filter after that to filter out trace events that contain fields with
specific values::
@@ -1135,7 +1135,7 @@
.. admonition:: Tying it Together
The trace events subsystem accommodate static and dynamic tracepoints
- in exactly the same way - there's no difference as far as the
+ in exactly the same way --- there's no difference as far as the
infrastructure is concerned. See the ftrace section for more details
on the trace event subsystem.
@@ -1201,7 +1201,7 @@
outlined in the ":ref:`profile-manual/intro:General Setup`" section.
ftrace, trace-cmd, and kernelshark run on the target system, and are
-ready to go out-of-the-box - no additional setup is necessary. For the
+ready to go out-of-the-box --- no additional setup is necessary. For the
rest of this section we assume you've ssh'ed to the host and will be
running ftrace on the target. kernelshark is a GUI application and if
you use the '-X' option to ssh you can have the kernelshark GUI run on
@@ -1321,7 +1321,7 @@
ftrace:function tracepoint.
It is a little more difficult to follow the call chains than it needs to
-be - luckily there's a variant of the function tracer that displays the
+be --- luckily there's a variant of the function tracer that displays the
callchains explicitly, called the 'function_graph' tracer::
root@sugarbay:/sys/kernel/debug/tracing# echo function_graph > current_tracer
@@ -2138,7 +2138,7 @@
.
You can now safely destroy the trace
-session (note that this doesn't delete the trace - it's still there in
+session (note that this doesn't delete the trace --- it's still there in
~/lttng-traces)::
root@crownbay:~# lttng destroy
@@ -2222,7 +2222,7 @@
.
You can now safely destroy the trace session (note that this doesn't delete the
-trace - it's still there in ~/lttng-traces)::
+trace --- it's still there in ~/lttng-traces)::
root@crownbay:~# lttng destroy
Session auto-20190303-021943 destroyed at /home/root
@@ -2557,7 +2557,7 @@
root@crownbay:/sys/kernel/debug/tracing# cat /media/sdc/testfile.txt
And look at the output (note here that we're using 'trace_pipe' instead of
-trace to capture this trace - this allows us to wait around on the pipe
+trace to capture this trace --- this allows us to wait around on the pipe
for data to appear)::
root@crownbay:/sys/kernel/debug/tracing# cat trace_pipe
diff --git a/poky/documentation/ref-manual/classes.rst b/poky/documentation/ref-manual/classes.rst
index 729aa25..424c505 100644
--- a/poky/documentation/ref-manual/classes.rst
+++ b/poky/documentation/ref-manual/classes.rst
@@ -108,18 +108,18 @@
It's useful to have some idea of how the tasks defined by the
``autotools*`` classes work and what they do behind the scenes.
-- :ref:`ref-tasks-configure` - Regenerates the
+- :ref:`ref-tasks-configure` --- regenerates the
configure script (using ``autoreconf``) and then launches it with a
standard set of arguments used during cross-compilation. You can pass
additional parameters to ``configure`` through the :term:`EXTRA_OECONF`
or :term:`PACKAGECONFIG_CONFARGS`
variables.
-- :ref:`ref-tasks-compile` - Runs ``make`` with
+- :ref:`ref-tasks-compile` --- runs ``make`` with
arguments that specify the compiler and linker. You can pass
additional arguments through the :term:`EXTRA_OEMAKE` variable.
-- :ref:`ref-tasks-install` - Runs ``make install`` and
+- :ref:`ref-tasks-install` --- runs ``make install`` and
passes in ``${``\ :term:`D`\ ``}`` as ``DESTDIR``.
.. _ref-classes-base:
@@ -2000,9 +2000,7 @@
archive (see `PEP-517 <https://peps.python.org/pep-0517/>`__).
Recipes wouldn't inherit this directly, instead typically another class will
-inherit this, add the relevant native dependencies, and set
-:term:`PEP517_BUILD_API` to the Python class which implements the PEP-517 build
-API.
+inherit this and add the relevant native dependencies.
Examples of classes which do this are :ref:`python_flit_core
<ref-classes-python_flit_core>`, :ref:`python_setuptools_build_meta
diff --git a/poky/documentation/ref-manual/devtool-reference.rst b/poky/documentation/ref-manual/devtool-reference.rst
index 10ca70a..997ec03 100644
--- a/poky/documentation/ref-manual/devtool-reference.rst
+++ b/poky/documentation/ref-manual/devtool-reference.rst
@@ -164,7 +164,7 @@
==========================================
Use the ``devtool add`` command to add a new recipe to the workspace
-layer. The recipe you add should not exist - ``devtool`` creates it for
+layer. The recipe you add should not exist --- ``devtool`` creates it for
you. The source files the recipe uses should exist in an external area.
The following example creates and adds a new recipe named ``jackson`` to
diff --git a/poky/documentation/ref-manual/faq.rst b/poky/documentation/ref-manual/faq.rst
index e06b5e6..2fcbf7d 100644
--- a/poky/documentation/ref-manual/faq.rst
+++ b/poky/documentation/ref-manual/faq.rst
@@ -22,7 +22,7 @@
**A:** You can get the required tools on your host development system a
couple different ways (i.e. building a tarball or downloading a
tarball). See the
-":ref:`ref-manual/system-requirements:required git, tar, python and gcc versions`"
+":ref:`ref-manual/system-requirements:required git, tar, python, make and gcc versions`"
section for steps on how to update your build tools.
**Q:** How can you claim Poky / OpenEmbedded-Core is stable?
@@ -364,7 +364,7 @@
**Q:** Can I get rid of build output so I can start over?
-**A:** Yes - you can easily do this. When you use BitBake to build an
+**A:** Yes --- you can easily do this. When you use BitBake to build an
image, all the build output goes into the directory created when you run
the build environment setup script (i.e.
:ref:`structure-core-script`). By default, this :term:`Build Directory`
@@ -428,7 +428,7 @@
build/tmp/sysroots/x86_64-linux/usr/bin
Even if the paths look unusual,
-they both are correct - the first for a target and the second for a
+they both are correct --- the first for a target and the second for a
native recipe. These paths are a consequence of the ``DESTDIR``
mechanism and while they appear strange, they are correct and in
practice very effective.
diff --git a/poky/documentation/ref-manual/features.rst b/poky/documentation/ref-manual/features.rst
index f7abb41..17521ac 100644
--- a/poky/documentation/ref-manual/features.rst
+++ b/poky/documentation/ref-manual/features.rst
@@ -100,7 +100,9 @@
a package or packages. In most cases, the presence or absence of a
feature translates to the appropriate option supplied to the configure
script during the :ref:`ref-tasks-configure` task for
-the recipes that optionally support the feature.
+the recipes that optionally support the feature. Appropriate options
+must be supplied, and enabling/disabling :term:`PACKAGECONFIG` for the
+concerned packages is one way of supplying such options.
Some distro features are also machine features. These select features
make sense to be controlled both at the machine and distribution
@@ -198,17 +200,19 @@
Here are the image features available for all images:
-- *allow-empty-password:* Allows Dropbear and OpenSSH to accept root
- logins and logins from accounts having an empty password string.
+- *allow-empty-password:* Allows Dropbear and OpenSSH to accept
+ logins from accounts having an empty password string.
+
+- *allow-root-login:* Allows Dropbear and OpenSSH to accept root logins.
- *dbg-pkgs:* Installs debug symbol packages for all packages installed
in a given image.
- *debug-tweaks:* Makes an image suitable for development (e.g. allows
- root logins without passwords and enables post-installation logging).
- See the 'allow-empty-password', 'empty-root-password', and
- 'post-install-logging' features in this list for additional
- information.
+ root logins, logins without passwords ---including root ones, and enables
+ post-installation logging). See the ``allow-empty-password``,
+ ``allow-root-login``, ``empty-root-password``, and ``post-install-logging``
+ features in this list for additional information.
- *dev-pkgs:* Installs development packages (headers and extra library
links) for all packages installed in a given image.
@@ -216,8 +220,19 @@
- *doc-pkgs:* Installs documentation packages for all packages
installed in a given image.
-- *empty-root-password:* Sets the root password to an empty string,
- which allows logins with a blank password.
+- *empty-root-password:* This feature or ``debug-tweaks`` is required if
+ you want to allow root login with an empty password. If these features
+ are not present in :term:`IMAGE_FEATURES`, a non-empty password is
+ forced in ``/etc/passwd`` and ``/etc/shadow`` if such files exist.
+
+ .. note::
+ ``empty-root-passwd`` doesn't set an empty root password by itself.
+ You get an initial empty root password thanks to the
+ :oe_git:`base-passwd </openembedded-core/tree/meta/recipes-core/base-passwd/>`
+ and :oe_git:`shadow </openembedded-core/tree/meta/recipes-extended/shadow/>`
+ recipes, and the presence of ``empty-root-passwd`` or ``debug-tweaks``
+ just disables the mechanism which forces an non-empty password for the
+ root user.
- *overlayfs-etc:* Configures the ``/etc`` directory to be in ``overlayfs``.
This allows to store device specific information elsewhere, especially
diff --git a/poky/documentation/ref-manual/qa-checks.rst b/poky/documentation/ref-manual/qa-checks.rst
index 8c475d0..fbab1dc 100644
--- a/poky/documentation/ref-manual/qa-checks.rst
+++ b/poky/documentation/ref-manual/qa-checks.rst
@@ -613,7 +613,7 @@
so using ${:term:`BPN`} rather than ${:term:`PN`} as the latter will change
for different variants of the same recipe e.g. when :term:`BBCLASSEXTEND`
or multilib are being used. This check will fail if a reference to ``${PN}``
- is found within the :term:`SRC_URI` value - change it to ``${BPN}`` instead.
+ is found within the :term:`SRC_URI` value --- change it to ``${BPN}`` instead.
.. _qa-check-unhandled-features-check:
@@ -727,7 +727,7 @@
devtool modify <recipe>
This will apply all of the patches, and create new commits out of them in
- the workspace - with the patch context updated.
+ the workspace --- with the patch context updated.
Then, replace the patches in the recipe layer::
diff --git a/poky/documentation/ref-manual/resources.rst b/poky/documentation/ref-manual/resources.rst
index c942384..292a9d6 100644
--- a/poky/documentation/ref-manual/resources.rst
+++ b/poky/documentation/ref-manual/resources.rst
@@ -64,22 +64,22 @@
click on the appropriate URL in the following list and follow the
instructions:
-- :yocto_lists:`/g/yocto` - General Yocto Project
+- :yocto_lists:`/g/yocto` --- general Yocto Project
discussion mailing list.
-- :oe_lists:`/g/openembedded-core` - Discussion mailing
+- :oe_lists:`/g/openembedded-core` --- discussion mailing
list about OpenEmbedded-Core (the core metadata).
-- :oe_lists:`/g/openembedded-devel` - Discussion
+- :oe_lists:`/g/openembedded-devel` --- discussion
mailing list about OpenEmbedded.
-- :oe_lists:`/g/bitbake-devel` - Discussion mailing
+- :oe_lists:`/g/bitbake-devel` --- discussion mailing
list about the :term:`BitBake` build tool.
-- :yocto_lists:`/g/poky` - Discussion mailing list
+- :yocto_lists:`/g/poky` --- discussion mailing list
about :term:`Poky`.
-- :yocto_lists:`/g/yocto-announce` - Mailing list to
+- :yocto_lists:`/g/yocto-announce` --- mailing list to
receive official Yocto Project release and milestone announcements.
For more Yocto Project-related mailing lists, see the
diff --git a/poky/documentation/ref-manual/structure.rst b/poky/documentation/ref-manual/structure.rst
index 12a0855..bdcffc1 100644
--- a/poky/documentation/ref-manual/structure.rst
+++ b/poky/documentation/ref-manual/structure.rst
@@ -213,8 +213,8 @@
.. _structure-build:
-The Build Directory - ``build/``
-================================
+The Build Directory --- ``build/``
+==================================
The OpenEmbedded build system creates the :term:`Build Directory`
when you run the build environment setup
@@ -589,7 +589,7 @@
``build/tmp/work/tunearch/recipename/version/``
-----------------------------------------------
-The recipe work directory - ``${WORKDIR}``.
+The recipe work directory --- ``${WORKDIR}``.
As described earlier in the
":ref:`structure-build-tmp-sysroots`" section,
@@ -654,8 +654,8 @@
.. _structure-meta:
-The Metadata - ``meta/``
-========================
+The Metadata --- ``meta/``
+==========================
As mentioned previously, :term:`Metadata` is the core of the
Yocto Project. Metadata has several important subdivisions:
diff --git a/poky/documentation/ref-manual/system-requirements.rst b/poky/documentation/ref-manual/system-requirements.rst
index 04f9efa..6cf88f2 100644
--- a/poky/documentation/ref-manual/system-requirements.rst
+++ b/poky/documentation/ref-manual/system-requirements.rst
@@ -234,8 +234,8 @@
$ sudo dnf install make python3-pip which
&PIP3_HOST_PACKAGES_DOC;
-Required Git, tar, Python and gcc Versions
-==========================================
+Required Git, tar, Python, make and gcc Versions
+================================================
In order to use the build system, your host development system must meet
the following version requirements for Git, tar, and Python:
@@ -246,6 +246,8 @@
- Python &MIN_PYTHON_VERSION; or greater
+- GNU make &MIN_MAKE_VERSION; or greater
+
If your host development system does not meet all these requirements,
you can resolve this by installing a ``buildtools`` tarball that
contains these tools. You can get the tarball one of two ways: download
diff --git a/poky/documentation/ref-manual/terms.rst b/poky/documentation/ref-manual/terms.rst
index cba514c..1e3f718 100644
--- a/poky/documentation/ref-manual/terms.rst
+++ b/poky/documentation/ref-manual/terms.rst
@@ -270,7 +270,7 @@
your Linux distribution.
Another point worth noting is that historically within the Yocto
- Project, recipes were referred to as packages - thus, the existence
+ Project, recipes were referred to as packages --- thus, the existence
of several BitBake variables that are seemingly mis-named, (e.g.
:term:`PR`, :term:`PV`, and
:term:`PE`).
@@ -369,7 +369,7 @@
Directory created by unpacking a released tarball as compared to
cloning ``git://git.yoctoproject.org/poky``. When you unpack a
tarball, you have an exact copy of the files based on the time of
- release - a fixed release point. Any changes you make to your local
+ release --- a fixed release point. Any changes you make to your local
files in the Source Directory are on top of the release and will
remain local only. On the other hand, when you clone the ``poky`` Git
repository, you have an active development repository with access to
@@ -383,6 +383,31 @@
":ref:`overview-manual/development-environment:repositories, tags, and branches`"
section in the Yocto Project Overview and Concepts Manual.
+ :term:`Sysroot`
+ When cross-compiling, the target file system may be differently laid
+ out and contain different things compared to the host system. The concept
+ of a *sysroot* is directory which looks like the target filesystem and
+ can be used to cross-compile against.
+
+ In the context of cross-compiling toolchains, a *sysroot*
+ typically contains C library and kernel headers, plus the
+ compiled binaries for the C library. A *multilib toolchain*
+ can contain multiple variants of the C library binaries,
+ each compiled for a target instruction set (such as ``armv5``,
+ ``armv7`` and ``armv8``), and possibly optimized for a specific CPU core.
+
+ In the more specific context of the OpenEmbedded build System and
+ of the Yocto Project, each recipe has two sysroots:
+
+ - A *target sysroot* contains all the **target** libraries and headers
+ needed to build the recipe.
+
+ - A *native sysroot* contains all the **host** files and executables
+ needed to build the recipe.
+
+ See the :term:`SYSROOT_* <SYSROOT_DESTDIR>` variables controlling
+ how sysroots are created and stored.
+
:term:`Task`
A per-recipe unit of execution for BitBake (e.g.
:ref:`ref-tasks-compile`,
diff --git a/poky/documentation/ref-manual/variables.rst b/poky/documentation/ref-manual/variables.rst
index 367b467..1710830 100644
--- a/poky/documentation/ref-manual/variables.rst
+++ b/poky/documentation/ref-manual/variables.rst
@@ -591,7 +591,7 @@
This variable is useful in situations where the same recipe appears
in more than one layer. Setting this variable allows you to
prioritize a layer against other layers that contain the same recipe
- - effectively letting you control the precedence for the multiple
+ --- effectively letting you control the precedence for the multiple
layers. The precedence established through this variable stands
regardless of a recipe's version (:term:`PV` variable). For
example, a layer that has a recipe with a higher :term:`PV` value but for
@@ -718,10 +718,11 @@
BBMULTICONFIG = "configA configB configC"
- Each configuration file you
- use must reside in the :term:`Build Directory`
- ``conf/multiconfig`` directory (e.g.
- ``build_directory/conf/multiconfig/configA.conf``).
+ Each configuration file you use must reside in a ``multiconfig``
+ subdirectory of a configuration directory within a layer, or
+ within the :term:`Build Directory` (e.g.
+ ``build_directory/conf/multiconfig/configA.conf`` or
+ ``mylayer/conf/multiconfig/configB.conf``).
For information on how to use :term:`BBMULTICONFIG` in an environment
that supports building targets with multiple configurations, see the
@@ -888,7 +889,7 @@
:term:`BUILD_OS`
Specifies the operating system in use on the build host (e.g.
"linux"). The OpenEmbedded build system sets the value of
- :term:`BUILD_OS` from the OS reported by the ``uname`` command - the
+ :term:`BUILD_OS` from the OS reported by the ``uname`` command --- the
first word, converted to lower-case characters.
:term:`BUILD_PREFIX`
@@ -1296,6 +1297,19 @@
the recipe will be skipped, and if the build system attempts to build
the recipe then an error will be triggered.
+ :term:`CONVERSION_CMD`
+ This variable is used for storing image conversion commands.
+ Image conversion can convert an image into different objects like:
+
+ - Compressed version of the image
+
+ - Checksums for the image
+
+ An example of :term:`CONVERSION_CMD` from :ref:`image-types
+ <ref-classes-image_types>` class is::
+
+ CONVERSION_CMD:lzo = "lzop -9 ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
+
:term:`COPY_LIC_DIRS`
If set to "1" along with the
:term:`COPY_LIC_MANIFEST` variable, the
@@ -1688,7 +1702,7 @@
``${TMPDIR}/deploy``.
For more information on the structure of the Build Directory, see
- ":ref:`ref-manual/structure:the build directory - \`\`build/\`\``" section.
+ ":ref:`ref-manual/structure:the build directory --- \`\`build/\`\``" section.
For more detail on the contents of the ``deploy`` directory, see the
":ref:`overview-manual/concepts:images`",
":ref:`overview-manual/concepts:package feeds`", and
@@ -1732,7 +1746,7 @@
<ref-classes-image>` class.
For more information on the structure of the Build Directory, see
- ":ref:`ref-manual/structure:the build directory - \`\`build/\`\``" section.
+ ":ref:`ref-manual/structure:the build directory --- \`\`build/\`\``" section.
For more detail on the contents of the ``deploy`` directory, see the
":ref:`overview-manual/concepts:images`" and
":ref:`overview-manual/concepts:application development sdk`" sections both in
@@ -1872,7 +1886,10 @@
optionally support the feature. For example, specifying "x11" in
:term:`DISTRO_FEATURES`, causes every piece of software built for the
target that can optionally support X11 to have its X11 support
- enabled.
+ enabled. Note: just enabling :term:`DISTRO_FEATURES` alone doesn't
+ enable feature support for packages, mechanisms such as making
+ :term:`PACKAGECONFIG` track :term:`DISTRO_FEATURES` are used
+ to enable/disable package features.
Two more examples are Bluetooth and NFS support. For a more complete
list of features that ships with the Yocto Project and that you can
@@ -2244,24 +2261,24 @@
Here are some examples of features you can add:
- - "dbg-pkgs" - Adds -dbg packages for all installed packages including
+ - "dbg-pkgs" --- adds -dbg packages for all installed packages including
symbol information for debugging and profiling.
- - "debug-tweaks" - Makes an image suitable for debugging. For example, allows root logins without passwords and
+ - "debug-tweaks" --- makes an image suitable for debugging. For example, allows root logins without passwords and
enables post-installation logging. See the 'allow-empty-password' and
'post-install-logging' features in the ":ref:`ref-features-image`"
section for more information.
- - "dev-pkgs" - Adds -dev packages for all installed packages. This is
+ - "dev-pkgs" --- adds -dev packages for all installed packages. This is
useful if you want to develop against the libraries in the image.
- - "read-only-rootfs" - Creates an image whose root filesystem is
+ - "read-only-rootfs" --- creates an image whose root filesystem is
read-only. See the
":ref:`dev-manual/common-tasks:creating a read-only root filesystem`"
section in the Yocto Project Development Tasks Manual for more
information
- - "tools-debug" - Adds debugging tools such as gdb and strace.
- - "tools-sdk" - Adds development tools such as gcc, make,
+ - "tools-debug" --- adds debugging tools such as gdb and strace.
+ - "tools-sdk" --- adds development tools such as gcc, make,
pkgconfig and so forth.
- - "tools-testapps" - Adds useful testing tools
+ - "tools-testapps" --- adds useful testing tools
such as ts_print, aplay, arecord and so forth.
For a complete list of image features that ships with the Yocto
@@ -3255,7 +3272,7 @@
IMAGE_NAME ?= "${IMAGE_BASENAME}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
:term:`IMAGE_NAME_SUFFIX`
- Suffix used for the image output filename - defaults to ``".rootfs"``
+ Suffix used for the image output filename --- defaults to ``".rootfs"``
to distinguish the image file from other files created during image
building; however if this suffix is redundant or not desired you can
clear the value of this variable (set the value to ""). For example,
@@ -3543,6 +3560,14 @@
remove dependencies on or provide alternatives to components that
are required to produce a functional system image.
+ :term:`INCOMPATIBLE_LICENSE_EXCEPTIONS`
+ Specifies a space-separated list of package and license pairs that
+ are allowed to be used even if the license is specified in
+ :term:`INCOMPATIBLE_LICENSE`. The package and license pairs are
+ separated using a colon. Example::
+
+ INCOMPATIBLE_LICENSE_EXCEPTIONS = "gdbserver:GPL-3.0-only gdbserver:LGPL-3.0-only"
+
:term:`INHERIT`
Causes the named class or classes to be inherited globally. Anonymous
functions in the class or classes are not executed for the base
@@ -5657,11 +5682,6 @@
:term:`PE` is the default value of the :term:`PKGE` variable.
- :term:`PEP517_BUILD_API`
- When used by recipes that inherit the :ref:`python_pep517
- <ref-classes-python_pep517>` class, specifies the entry point to the
- PEP-517 compliant build API (such as ``flit_core.buildapi``).
-
:term:`PEP517_WHEEL_PATH`
When used by recipes that inherit the
:ref:`python_pep517 <ref-classes-python_pep517>` class,
@@ -6205,7 +6225,7 @@
``baz``.
The names of the packages you list within :term:`RDEPENDS` must be the
- names of other packages - they cannot be recipe names. Although
+ names of other packages --- they cannot be recipe names. Although
package names and recipe names usually match, the important point
here is that you are providing package names within the :term:`RDEPENDS`
variable. For an example of the default list of packages created from
@@ -7108,35 +7128,35 @@
There are standard and recipe-specific options. Here are standard ones:
- - ``apply`` - Whether to apply the patch or not. The default
+ - ``apply`` --- whether to apply the patch or not. The default
action is to apply the patch.
- - ``striplevel`` - Which striplevel to use when applying the
+ - ``striplevel`` --- which striplevel to use when applying the
patch. The default level is 1.
- - ``patchdir`` - Specifies the directory in which the patch should
+ - ``patchdir`` --- specifies the directory in which the patch should
be applied. The default is ``${``\ :term:`S`\ ``}``.
Here are options specific to recipes building code from a revision
control system:
- - ``mindate`` - Apply the patch only if
+ - ``mindate`` --- apply the patch only if
:term:`SRCDATE` is equal to or greater than
``mindate``.
- - ``maxdate`` - Apply the patch only if :term:`SRCDATE` is not later
+ - ``maxdate`` --- apply the patch only if :term:`SRCDATE` is not later
than ``maxdate``.
- - ``minrev`` - Apply the patch only if :term:`SRCREV` is equal to or
+ - ``minrev`` --- apply the patch only if :term:`SRCREV` is equal to or
greater than ``minrev``.
- - ``maxrev`` - Apply the patch only if :term:`SRCREV` is not later
+ - ``maxrev`` --- apply the patch only if :term:`SRCREV` is not later
than ``maxrev``.
- - ``rev`` - Apply the patch only if :term:`SRCREV` is equal to
+ - ``rev`` --- apply the patch only if :term:`SRCREV` is equal to
``rev``.
- - ``notrev`` - Apply the patch only if :term:`SRCREV` is not equal to
+ - ``notrev`` --- apply the patch only if :term:`SRCREV` is not equal to
``rev``.
.. note::
@@ -7217,6 +7237,32 @@
:term:`SSTATE_DIR`
The directory for the shared state cache.
+ :term:`SSTATE_EXCLUDEDEPS_SYSROOT`
+ This variable allows to specify indirect dependencies to exclude
+ from sysroots, for example to avoid the situations when a dependency on
+ any ``-native`` recipe will pull in all dependencies of that recipe
+ in the recipe sysroot. This behaviour might not always be wanted,
+ for example when that ``-native`` recipe depends on build tools
+ that are not relevant for the current recipe.
+
+ This way, irrelevant dependencies are ignored, which could have
+ prevented the reuse of prebuilt artifacts stored in the Shared
+ State Cache.
+
+ ``SSTATE_EXCLUDEDEPS_SYSROOT`` is evaluated as two regular
+ expressions of recipe and dependency to ignore. An example
+ is the rule in :oe_git:`meta/conf/layer.conf </meta/conf/layer.conf>`::
+
+ # Nothing needs to depend on libc-initial
+ # base-passwd/shadow-sysroot don't need their dependencies
+ SSTATE_EXCLUDEDEPS_SYSROOT += "\
+ .*->.*-initial.* \
+ .*(base-passwd|shadow-sysroot)->.* \
+ "
+
+ The ``->`` substring represents the dependency between
+ the two regular expressions.
+
:term:`SSTATE_MIRROR_ALLOW_NETWORK`
If set to "1", allows fetches from mirrors that are specified in
:term:`SSTATE_MIRRORS` to work even when
@@ -7639,6 +7685,24 @@
For information on Systemd-boot, see the `Systemd-boot
documentation <https://www.freedesktop.org/wiki/Software/systemd/systemd-boot/>`__.
+ :term:`SYSTEMD_DEFAULT_TARGET`
+
+ This variable allows to set the default unit that systemd starts at bootup.
+ Usually, this is either ``multi-user.target`` or ``graphical.target``.
+ This works by creating a ``default.target`` symbolic link to the chosen systemd
+ target file.
+
+ See `systemd's documentation
+ <https://www.freedesktop.org/software/systemd/man/systemd.special.html>`__
+ for details.
+
+ For example, this variable is used in the
+ `core-image-minimal-xfce.bb
+ <https://git.openembedded.org/meta-openembedded/tree/meta-xfce/recipes-core/images/core-image-minimal-xfce.bb>`__
+ recipe::
+
+ SYSTEMD_DEFAULT_TARGET = "graphical.target"
+
:term:`SYSTEMD_PACKAGES`
When inheriting the :ref:`systemd <ref-classes-systemd>` class,
this variable locates the systemd unit files when they are not found
@@ -7656,12 +7720,18 @@
When inheriting the :ref:`systemd <ref-classes-systemd>` class,
this variable specifies the systemd service name for a package.
+ Multiple services can be specified, each one separated by a space.
+
When you specify this file in your recipe, use a package name
override to indicate the package to which the value applies. Here is
an example from the connman recipe::
SYSTEMD_SERVICE:${PN} = "connman.service"
+ The package overrides that can be specified are directly related to the value of
+ term:`SYSTEMD_PACKAGES`. Overrides not included in term:`SYSTEMD_PACKAGES`
+ will be silently ignored.
+
:term:`SYSVINIT_ENABLED_GETTYS`
When using
:ref:`SysVinit <dev-manual/common-tasks:enabling system services>`,
@@ -8795,8 +8865,8 @@
- :term:`TMPDIR`: The top-level build output directory
- :term:`MULTIMACH_TARGET_SYS`: The target system identifier
- :term:`PN`: The recipe name
- - :term:`EXTENDPE`: The epoch - (if :term:`PE` is not specified, which
- is usually the case for most recipes, then `EXTENDPE` is blank)
+ - :term:`EXTENDPE`: The epoch --- if :term:`PE` is not specified, which
+ is usually the case for most recipes, then `EXTENDPE` is blank.
- :term:`PV`: The recipe version
- :term:`PR`: The recipe revision
diff --git a/poky/documentation/ref-manual/varlocality.rst b/poky/documentation/ref-manual/varlocality.rst
index 5f7dba8..e2c086f 100644
--- a/poky/documentation/ref-manual/varlocality.rst
+++ b/poky/documentation/ref-manual/varlocality.rst
@@ -113,7 +113,7 @@
- :term:`LIC_FILES_CHKSUM`
-- :term:`SRC_URI` - used in recipes that fetch local or remote files.
+- :term:`SRC_URI` --- used in recipes that fetch local or remote files.
.. _ref-varlocality-recipe-dependencies:
diff --git a/poky/documentation/releases.rst b/poky/documentation/releases.rst
index 08984b2..b2b4486 100644
--- a/poky/documentation/releases.rst
+++ b/poky/documentation/releases.rst
@@ -17,28 +17,7 @@
- :yocto_docs:`4.0 Documentation </4.0>`
- :yocto_docs:`4.0.1 Documentation </4.0.1>`
-
-******************************
-Release Series 3.4 (honister)
-******************************
-
-- :yocto_docs:`3.4 Documentation </3.4>`
-- :yocto_docs:`3.4.1 Documentation </3.4.1>`
-- :yocto_docs:`3.4.2 Documentation </3.4.2>`
-- :yocto_docs:`3.4.3 Documentation </3.4.3>`
-- :yocto_docs:`3.4.4 Documentation </3.4.4>`
-
-******************************
-Release Series 3.3 (hardknott)
-******************************
-
-- :yocto_docs:`3.3 Documentation </3.3>`
-- :yocto_docs:`3.3.1 Documentation </3.3.1>`
-- :yocto_docs:`3.3.2 Documentation </3.3.2>`
-- :yocto_docs:`3.3.3 Documentation </3.3.3>`
-- :yocto_docs:`3.3.4 Documentation </3.3.4>`
-- :yocto_docs:`3.3.5 Documentation </3.3.5>`
-- :yocto_docs:`3.3.6 Documentation </3.3.6>`
+- :yocto_docs:`4.0.2 Documentation </4.0.2>`
****************************
Release Series 3.1 (dunfell)
@@ -61,11 +40,34 @@
- :yocto_docs:`3.1.14 Documentation </3.1.14>`
- :yocto_docs:`3.1.15 Documentation </3.1.15>`
- :yocto_docs:`3.1.16 Documentation </3.1.16>`
+- :yocto_docs:`3.1.17 Documentation </3.1.17>`
==========================
Outdated Release Manuals
==========================
+******************************
+Release Series 3.4 (honister)
+******************************
+
+- :yocto_docs:`3.4 Documentation </3.4>`
+- :yocto_docs:`3.4.1 Documentation </3.4.1>`
+- :yocto_docs:`3.4.2 Documentation </3.4.2>`
+- :yocto_docs:`3.4.3 Documentation </3.4.3>`
+- :yocto_docs:`3.4.4 Documentation </3.4.4>`
+
+******************************
+Release Series 3.3 (hardknott)
+******************************
+
+- :yocto_docs:`3.3 Documentation </3.3>`
+- :yocto_docs:`3.3.1 Documentation </3.3.1>`
+- :yocto_docs:`3.3.2 Documentation </3.3.2>`
+- :yocto_docs:`3.3.3 Documentation </3.3.3>`
+- :yocto_docs:`3.3.4 Documentation </3.3.4>`
+- :yocto_docs:`3.3.5 Documentation </3.3.5>`
+- :yocto_docs:`3.3.6 Documentation </3.3.6>`
+
*******************************
Release Series 3.2 (gatesgarth)
*******************************
diff --git a/poky/documentation/sdk-manual/extensible.rst b/poky/documentation/sdk-manual/extensible.rst
index 6bb2622..ed9e43a 100644
--- a/poky/documentation/sdk-manual/extensible.rst
+++ b/poky/documentation/sdk-manual/extensible.rst
@@ -252,7 +252,7 @@
- *Left*: The left scenario in the figure represents a common
situation where the source code does not exist locally and needs
to be extracted. In this situation, the source code is extracted
- to the default workspace - you do not want the files in some
+ to the default workspace --- you do not want the files in some
specific location outside of the workspace. Thus, everything you
need will be located in the workspace::
@@ -267,7 +267,7 @@
- *Middle*: The middle scenario in the figure also represents a
situation where the source code does not exist locally. In this
case, the code is again upstream and needs to be extracted to some
- local area - this time outside of the default workspace.
+ local area --- this time outside of the default workspace.
.. note::
@@ -302,7 +302,7 @@
recipe for the code and places the recipe into the workspace.
Because the extracted source code already exists, ``devtool`` does
- not try to relocate the source code into the workspace - only the
+ not try to relocate the source code into the workspace --- only the
new recipe is placed in the workspace.
Aside from a recipe folder, the command also creates an associated
diff --git a/poky/documentation/sdk-manual/working-projects.rst b/poky/documentation/sdk-manual/working-projects.rst
index efef5c8..7f8d9b8 100644
--- a/poky/documentation/sdk-manual/working-projects.rst
+++ b/poky/documentation/sdk-manual/working-projects.rst
@@ -174,19 +174,19 @@
The main point of this section is to explain the following three cases
regarding variable behavior:
-- *Case 1 - No Variables Set in the Makefile Map to Equivalent
+- *Case 1 --- No Variables Set in the Makefile Map to Equivalent
Environment Variables Set in the SDK Setup Script:* Because matching
variables are not specifically set in the ``Makefile``, the variables
retain their values based on the environment setup script.
-- *Case 2 - Variables Are Set in the Makefile that Map to Equivalent
+- *Case 2 --- Variables Are Set in the Makefile that Map to Equivalent
Environment Variables from the SDK Setup Script:* Specifically
setting matching variables in the ``Makefile`` during the build
results in the environment settings of the variables being
overwritten. In this case, the variables you set in the ``Makefile``
are used.
-- *Case 3 - Variables Are Set Using the Command Line that Map to
+- *Case 3 --- Variables Are Set Using the Command Line that Map to
Equivalent Environment Variables from the SDK Setup Script:*
Executing the ``Makefile`` from the command line results in the
environment variables being overwritten. In this case, the
diff --git a/poky/documentation/standards.md b/poky/documentation/standards.md
index 81aff5f..9f4771e 100644
--- a/poky/documentation/standards.md
+++ b/poky/documentation/standards.md
@@ -7,6 +7,54 @@
## Text standards
+### Bulleted lists
+
+Though Sphinx supports both the ``*`` and ``-`` characters
+for introducing bulleted lists, we have chosen to use
+only ``-`` for this purpose.
+
+Though not strictly required by Sphinx, we have also chosen
+to use two space characters after ``-`` to introduce each
+list item:
+
+ - Paragraph 1
+
+ - Paragraph 2
+
+As shown in the above example, there should also be an empty
+line between each list item.
+
+An exception to this rule is when the list items are just made
+of a few words, instead of entire paragraphs:
+
+ - Item 1
+ - Item 2
+
+This is again a matter of style, not syntax.
+
+### Line wrapping
+
+Source code for the documentation shouldn't have lines
+wider than 80 characters. This makes patch lines more
+readable and code easier to quote in e-mail clients.
+
+If you have to include long commands or lines in configuration
+files, provided the syntax makes this possible, split them
+into multiple lines, using the ``\`` character.
+
+Here is an example:
+
+ $ scripts/install-buildtools \
+ --without-extended-buildtools \
+ --base-url https://downloads.yoctoproject.org/releases/yocto \
+ --release yocto-4.0.1 \
+ --installer-version 4.0.1
+
+Exceptions are granted for file contents whose lines
+cannot be split without infringing syntactic rules
+or reducing readability, as well as for command output
+which should be kept unmodified.
+
### Project names
Project names should be capitalized in the same
@@ -23,13 +71,25 @@
* When used in a cross-reference title. Such
titles are usually in lower case.
-### File names
+### File, tool and command names
-File names should be quoted as in the below example:
+File, tool and command names should be double tick-quoted.
+For example, ``` ``conf/local.conf`` ``` is preferred over
+`"conf/local.conf"`.
- ``conf/local.conf``
+### Variables
-Using "conf/local/conf" would be wrong.
+Every variable should be mentioned with:
+
+ :term:`VARIABLE`
+
+This assumes that `VARIABLE` is described either
+in the Yocto Project documentation variable index (`ref-manual/variables.rst`)
+or in the BitBake User Manual
+(`doc/bitbake-user-manual/bitbake-user-manual-ref-variables.rst`)
+
+If it is not described yet, the variable should be added to the
+glossary before or in the same patch it is used, so that `:term:` can be used.
## ReStructured Text Syntax standards
diff --git a/poky/documentation/test-manual/intro.rst b/poky/documentation/test-manual/intro.rst
index 12324e5..6421dd5 100644
--- a/poky/documentation/test-manual/intro.rst
+++ b/poky/documentation/test-manual/intro.rst
@@ -85,8 +85,8 @@
:align: center
:width: 70%
-Yocto Project Tests - Types of Testing Overview
-===============================================
+Yocto Project Tests --- Types of Testing Overview
+=================================================
The Autobuilder tests different elements of the project by using
the following types of tests:
diff --git a/poky/documentation/transitioning-to-a-custom-environment.rst b/poky/documentation/transitioning-to-a-custom-environment.rst
index 6b34fed..ee1fc89 100644
--- a/poky/documentation/transitioning-to-a-custom-environment.rst
+++ b/poky/documentation/transitioning-to-a-custom-environment.rst
@@ -84,7 +84,7 @@
#. **Now you're ready to create an image recipe**.
There are a number of ways to do this. However, it is strongly recommended
- that you have your own image recipe - don't try appending to existing image
+ that you have your own image recipe --- don't try appending to existing image
recipes. Recipes for images are trivial to create and you usually want to
fully customize their contents.
