diff options
| author | Andrew Geissler <geissonator@yahoo.com> | 2022-07-15 22:00:58 +0300 |
|---|---|---|
| committer | Andrew Geissler <andrew@geissonator.com> | 2022-07-20 22:59:28 +0300 |
| commit | 615f2f11d3f46e3eae642475495a7ca4cfddc49e (patch) | |
| tree | d88ca73415c1690f5cc8deb783e45499aabccd3c /poky/documentation | |
| parent | bef0021cfe167ccb6ae2e71f546ecb21ccf1c204 (diff) | |
| download | openbmc-615f2f11d3f46e3eae642475495a7ca4cfddc49e.tar.xz | |
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
Diffstat (limited to 'poky/documentation')
45 files changed, 431 insertions, 236 deletions
diff --git a/poky/documentation/brief-yoctoprojectqs/index.rst b/poky/documentation/brief-yoctoprojectqs/index.rst index 7179f25022..3cf2f76f55 100644 --- a/poky/documentation/brief-yoctoprojectqs/index.rst +++ b/poky/documentation/brief-yoctoprojectqs/index.rst @@ -64,11 +64,12 @@ following requirements: - 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 @@ an entire Linux distribution, including the toolchain, from source. 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 280b160807..7e17b42886 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 baf550e3e3..2a017569f7 100644 --- a/poky/documentation/conf.py +++ b/poky/documentation/conf.py @@ -53,7 +53,7 @@ author = 'The Linux Foundation' # -- 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 @@ rst_prolog = """ # 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 ca6d594386..8be3c7c0e8 100644 --- a/poky/documentation/dev-manual/common-tasks.rst +++ b/poky/documentation/dev-manual/common-tasks.rst @@ -2306,7 +2306,7 @@ under ``files``) requires a recipe that has the file listed in the :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 @@ Recipe Syntax 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 @@ chapter of the BitBake User Manual. 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 @@ in the BitBake User Manual. 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 @@ The actual directory depends on several things: - :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 @@ Setting Up and Running a Multiple Configuration Build 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 @@ Follow these steps to set up and execute multiple configuration builds: - *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 @@ Follow these steps to set up and execute multiple configuration builds: 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 @@ the following: 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 @@ optional arguments:: 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 @@ optional arguments:: 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 @@ optional arguments:: 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 @@ A Package Test (ptest) runs tests against packages built by the 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 @@ The 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 @@ modules and manually add the information to the recipe. ``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 @@ runs. 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 @@ command to deploy your package:: $ 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 @@ command:: $ 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 @@ The JSON file must include an object with the test name as keys of an 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 @@ Logging With Bash ~~~~~~~~~~~~~~~~~ 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 @@ to use GDB directly on the remote target to debug applications. These 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 @@ Preparing Changes for Submission - 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 @@ follows: 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 @@ Providing the Source Code 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 @@ known security vulnerabilities, as tracked by the public `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 Binary files differindex 1ebe74f535..a02cca097f 100644 --- a/poky/documentation/dev-manual/figures/cute-files-npm-example.png +++ b/poky/documentation/dev-manual/figures/cute-files-npm-example.png diff --git a/poky/documentation/dev-manual/start.rst b/poky/documentation/dev-manual/start.rst index 8cf3ebe316..499c3f8394 100644 --- a/poky/documentation/dev-manual/start.rst +++ b/poky/documentation/dev-manual/start.rst @@ -311,7 +311,7 @@ Project Build Host: 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 @@ Project Build Host: - 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 b5290b61b3..b16b3e0517 100644 --- a/poky/documentation/kernel-dev/advanced.rst +++ b/poky/documentation/kernel-dev/advanced.rst @@ -183,7 +183,7 @@ the structure: 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 b3a2f3abbf..63c5124a57 100644 --- a/poky/documentation/kernel-dev/concepts-appx.rst +++ b/poky/documentation/kernel-dev/concepts-appx.rst @@ -117,7 +117,7 @@ upstream Linux kernel development and are managed by the Yocto Project 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 93db14c3ba..366fb006e8 100644 --- a/poky/documentation/migration-guides/migration-1.5.rst +++ b/poky/documentation/migration-guides/migration-1.5.rst @@ -26,7 +26,7 @@ provide packages for these, you can install and use the Buildtools 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 358086560b..f54d4ba729 100644 --- a/poky/documentation/migration-guides/migration-1.6.rst +++ b/poky/documentation/migration-guides/migration-1.6.rst @@ -341,39 +341,39 @@ Removed and Renamed Recipes 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 88a6855d50..8213ab58d9 100644 --- a/poky/documentation/migration-guides/migration-1.7.rst +++ b/poky/documentation/migration-guides/migration-1.7.rst @@ -31,7 +31,7 @@ build host is now 1.7.8 because the ``--list`` option is now required by 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 ae6268d509..b2d8a0b678 100644 --- a/poky/documentation/migration-guides/migration-2.1.rst +++ b/poky/documentation/migration-guides/migration-2.1.rst @@ -357,7 +357,7 @@ These additional changes exist: - 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 fe7bc2cf55..16e48cc87c 100644 --- a/poky/documentation/migration-guides/migration-2.2.rst +++ b/poky/documentation/migration-guides/migration-2.2.rst @@ -442,7 +442,7 @@ The following miscellaneous changes have occurred: - :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 ef5f32e6ef..964ed92937 100644 --- a/poky/documentation/migration-guides/migration-2.4.rst +++ b/poky/documentation/migration-guides/migration-2.4.rst @@ -301,7 +301,7 @@ The following are additional changes: 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 1219edf921..96aea2f332 100644 --- a/poky/documentation/migration-guides/migration-3.0.rst +++ b/poky/documentation/migration-guides/migration-3.0.rst @@ -216,11 +216,11 @@ The following sanity check changes occurred. - :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 e3fdbbe425..cc788efeba 100644 --- a/poky/documentation/migration-guides/migration-3.1.rst +++ b/poky/documentation/migration-guides/migration-3.1.rst @@ -200,7 +200,7 @@ Packaging changes ----------------- - ``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 a376eced52..92b7f91f2c 100644 --- a/poky/documentation/migration-guides/migration-3.2.rst +++ b/poky/documentation/migration-guides/migration-3.2.rst @@ -23,7 +23,7 @@ Removed recipes 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 @@ Removed classes 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 path filtering and mismatch behaviour -------------------------------------------- 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 @@ structure above that subdirectory. For these types of cases in your own recipes, 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 @@ DHCP server/client replaced 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 @@ In addition, the following new checks were added and default to triggering an er - :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 @@ deploy class now cleans ``DEPLOYDIR`` before ``do_deploy`` ``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 @@ now need to be changed to ``inherit image-artifact-names``. 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 22562dacd4..aba5c4237c 100644 --- a/poky/documentation/migration-guides/migration-3.3.rst +++ b/poky/documentation/migration-guides/migration-3.3.rst @@ -13,11 +13,10 @@ Minimum system requirements 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 8db43a1454..bc2c75d42e 100644 --- a/poky/documentation/migration-guides/migration-3.4.rst +++ b/poky/documentation/migration-guides/migration-3.4.rst @@ -146,7 +146,7 @@ Virtual runtime provides ~~~~~~~~~~~~~~~~~~~~~~~~ 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 @@ Extensible SDK host extension 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 @@ Miscellaneous - 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 a8e6b4c331..79e53f89ac 100644 --- a/poky/documentation/migration-guides/migration-4.0.rst +++ b/poky/documentation/migration-guides/migration-4.0.rst @@ -45,7 +45,7 @@ The following variables have changed their names: - ``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 5a8fb4b5a9..323e4df7ae 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 @@ New Features / Enhancements in 3.4 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - 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 eaa40f9317..4bf680db5d 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 @@ New Features / Enhancements in 4.0 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 016577e07e..83339da98f 100644 --- a/poky/documentation/overview-manual/concepts.rst +++ b/poky/documentation/overview-manual/concepts.rst @@ -557,7 +557,7 @@ Local Projects ~~~~~~~~~~~~~~ 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 @@ you a good idea of when the task's data changes. 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 @@ need to fix this situation. 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 f1001e0bd3..43a6f1b480 100644 --- a/poky/documentation/overview-manual/development-environment.rst +++ b/poky/documentation/overview-manual/development-environment.rst @@ -52,7 +52,7 @@ A development host or :term:`Build Host` is key to 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 a2e0862459..4e3b7c3250 100644 --- a/poky/documentation/overview-manual/yp-intro.rst +++ b/poky/documentation/overview-manual/yp-intro.rst @@ -842,7 +842,7 @@ helpful for getting started: 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 1e1d6c83ed..6b942f0959 100644 --- a/poky/documentation/poky.yaml.in +++ b/poky/documentation/poky.yaml.in @@ -44,4 +44,5 @@ PIP3_HOST_PACKAGES_DOC : "$ sudo pip3 install sphinx sphinx_rtd_theme pyyaml" 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 9c8fa3dbfa..e9208dfde8 100644 --- a/poky/documentation/profile-manual/intro.rst +++ b/poky/documentation/profile-manual/intro.rst @@ -7,7 +7,7 @@ Yocto Project Profiling and Tracing Manual 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 @@ please see the documentation and/or websites listed for each tool. 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 0ff9d921fd..49f8af4a74 100644 --- a/poky/documentation/profile-manual/usage.rst +++ b/poky/documentation/profile-manual/usage.rst @@ -17,7 +17,7 @@ The 'perf' tool is the profiling and tracing tool that comes bundled 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 @@ interactive text-based UI (or simply as text if we specify ``--stdio`` to 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 @@ The above screenshot displays a 'flat' profile, one entry for each '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 @@ and tell perf to do a profile using it as the sampling event:: 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 @@ System-Wide Tracing and Profiling ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 @@ Filtering 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 @@ callgraphs from starting a few programs during those 30 seconds: .. 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 @@ For this section, we'll assume you've already performed the basic setup 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 @@ great way to learn about how the kernel code works in a dynamic sense. 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 view the trace in text form on the target:: . 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 view the trace in text form on the target:: . 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 @@ Execute the workload you're interested in:: 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 729aa259e0..424c505715 100644 --- a/poky/documentation/ref-manual/classes.rst +++ b/poky/documentation/ref-manual/classes.rst @@ -108,18 +108,18 @@ support is either not present or is broken. 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 @@ The ``python_pep517`` class builds and installs a Python ``wheel`` binary 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 10ca70a2b3..997ec0351c 100644 --- a/poky/documentation/ref-manual/devtool-reference.rst +++ b/poky/documentation/ref-manual/devtool-reference.rst @@ -164,7 +164,7 @@ Adding a New Recipe to the Workspace Layer ========================================== 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 e06b5e6caa..2fcbf7da96 100644 --- a/poky/documentation/ref-manual/faq.rst +++ b/poky/documentation/ref-manual/faq.rst @@ -22,7 +22,7 @@ Can I still use the Yocto Project? **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 @@ redirect requests through proxy servers. **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 @@ relatively normal and the second is not: 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 f7abb417ba..17521ac2a8 100644 --- a/poky/documentation/ref-manual/features.rst +++ b/poky/documentation/ref-manual/features.rst @@ -100,7 +100,9 @@ packages, and they can go beyond simply controlling the installation of 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 @@ application problems or profile applications. 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 @@ Here are the image features available for all images: - *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 8c475d0f72..fbab1dc92e 100644 --- a/poky/documentation/ref-manual/qa-checks.rst +++ b/poky/documentation/ref-manual/qa-checks.rst @@ -613,7 +613,7 @@ Errors and Warnings 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 @@ Errors and Warnings 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 c942384662..292a9d6f61 100644 --- a/poky/documentation/ref-manual/resources.rst +++ b/poky/documentation/ref-manual/resources.rst @@ -64,22 +64,22 @@ and announcements. To subscribe to one of the following mailing lists, 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 12a085552f..bdcffc1947 100644 --- a/poky/documentation/ref-manual/structure.rst +++ b/poky/documentation/ref-manual/structure.rst @@ -213,8 +213,8 @@ These files are standard top-level files. .. _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 @@ install" places its output that is then split into sub-packages within ``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 @@ recipes. In practice, this is only used for ``gcc`` and its variants .. _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 04f9efaa23..6cf88f2a98 100644 --- a/poky/documentation/ref-manual/system-requirements.rst +++ b/poky/documentation/ref-manual/system-requirements.rst @@ -234,8 +234,8 @@ supported CentOS-8 Linux distribution: $ 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 @@ the following version requirements for Git, tar, and Python: - 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 cba514c345..1e3f718a8f 100644 --- a/poky/documentation/ref-manual/terms.rst +++ b/poky/documentation/ref-manual/terms.rst @@ -270,7 +270,7 @@ universal, the list includes them just in case: 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 @@ universal, the list includes them just in case: 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 @@ universal, the list includes them just in case: ":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 367b4674e2..1710830dc0 100644 --- a/poky/documentation/ref-manual/variables.rst +++ b/poky/documentation/ref-manual/variables.rst @@ -591,7 +591,7 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. :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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. ``${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 @@ system and gives an overview of their function and contents. <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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. :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 @@ system and gives an overview of their function and contents. ``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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. :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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. - :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 5f7dba8775..e2c086ffa0 100644 --- a/poky/documentation/ref-manual/varlocality.rst +++ b/poky/documentation/ref-manual/varlocality.rst @@ -113,7 +113,7 @@ This section lists variables that are required for recipes. - :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 08984b2b6b..b2b4486158 100644 --- a/poky/documentation/releases.rst +++ b/poky/documentation/releases.rst @@ -17,28 +17,7 @@ Release Series 4.0 (kirkstone) - :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 @@ Release Series 3.1 (dunfell) - :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 6bb262273d..ed9e43a2d8 100644 --- a/poky/documentation/sdk-manual/extensible.rst +++ b/poky/documentation/sdk-manual/extensible.rst @@ -252,7 +252,7 @@ command: - *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 @@ command: - *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 @@ command: 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 efef5c8bd2..7f8d9b8491 100644 --- a/poky/documentation/sdk-manual/working-projects.rst +++ b/poky/documentation/sdk-manual/working-projects.rst @@ -174,19 +174,19 @@ variables and Makefile variables during development. 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 81aff5f193..9f4771ebd9 100644 --- a/poky/documentation/standards.md +++ b/poky/documentation/standards.md @@ -7,6 +7,54 @@ It is currently a work in progress. ## 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 @@ in lower case: * When used in a cross-reference title. Such titles are usually in lower case. -### File names +### File, tool and command names + +File, tool and command names should be double tick-quoted. +For example, ``` ``conf/local.conf`` ``` is preferred over +`"conf/local.conf"`. + +### Variables + +Every variable should be mentioned with: -File names should be quoted as in the below example: + :term:`VARIABLE` - ``conf/local.conf`` +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`) -Using "conf/local/conf" would be wrong. +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 12324e592c..6421dd53c9 100644 --- a/poky/documentation/test-manual/intro.rst +++ b/poky/documentation/test-manual/intro.rst @@ -85,8 +85,8 @@ topology that includes a controller and a cluster of workers: :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 6b34fedc26..ee1fc891ab 100644 --- a/poky/documentation/transitioning-to-a-custom-environment.rst +++ b/poky/documentation/transitioning-to-a-custom-environment.rst @@ -84,7 +84,7 @@ Transitioning to a custom environment for systems development #. **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. |
