poky: subtree update:7231c10430..0ac99625bf
Alban Bedel (1):
systemd: Fix systemd when used with busybox less
Alejandro Hernandez Samaniego (3):
poky-tiny: Reduce busybox size by 13%
poky-tiny: Enable size optimization by default
python3: Update manifest
Alexander Kamensky (1):
kexec: arm64: disabled check if kaslr-seed dtb property was wiped
Alexander Kanavin (128):
systemd-boot: upgrade 246.2 -> 246.6
glib-2.0: upgrade 2.64.5 -> 2.66.1
cmake: update 3.18.2 -> 3.18.4
python3-pygobject: upgrade 3.36.1 -> 3.38.0
libdazzle: upgrade 3.36.0 -> 3.38.0
gobject-introspection: upgrade 1.64.1 -> 1.66.1
json-glib: upgrade 1.4.4 -> 1.6.0
ovmf: update edk2-stable202005 -> edk2-stable202008
gnu-config: update to latest revision
file: enable all built-in compression checkers
rpm: update 4.15.1 -> 4.16.0
elfutils: update 0.180 -> 0.181
ghostscript: update 9.52 -> 9.53.3
ltp: update 20200515 -> 20200930
gsettings-desktop-schemas: update 3.36.1 -> 3.38.0
libsecret: update 0.20.3 -> 0.20.4
mesa: update 20.1.8 -> 20.2.1
xf86-video-vesa: update 2.4.0 -> 2.5.0
lttng-modules: update 2.12.2 -> 2.12.3
webkitgtk: update 2.28.4 -> 2.30.1
dos2unix: update 7.4.1 -> 7.4.2
gnutls: update 3.16.4 -> 3.16.5
libcap: update 2.43 -> 2.44
vte: update 0.60.3 -> 0.62.1
libhandy: upgrade 0.0.13 -> 1.0.0
libportal: add a recipe
epiphany: upgrade 3.36.4 -> 3.38.1
gtk-doc: upgrade 1.32 -> 1.33.0
rpm: adjust MIPS64 N32 support
apt: remove host contamination with gtest
opkg-utils: correct priority matching in update-alternatives
libxml2: add a patch to fix python 3.9 support
python: update 3.8.5 -> 3.9.0
glib-2.0: update 2.66.1 -> 2.66.2
json-glib: fix reproducibility
spirv-tools: correctly set PV
spirv-tools: upgrade 2019.5 -> 2020.5
glslang: fix upstream version check
glslang: upgrade 8.13.3559 -> 8.13.3743
glslang: bump to a newer commit
shaderc: upgrade 2019.0 -> 2020.3
vulkan: update 1.2.135 -> 1.2.154
vulkan-samples: replace vulkan-demos
piglit: upgrade to latest revision
acpica: upgrade 20200717 -> 20200925
adwaita-icon-theme: upgrade 3.36.1 -> 3.38.0
at-spi2-atk: upgrade 2.34.2 -> 2.38.0
at-spi2-core: upgrade 2.36.1 -> 2.38.0
bison: upgrade 3.7.2 -> 3.7.3
createrepo-c: upgrade 0.16.0 -> 0.16.1
curl: upgrade 7.72.0 -> 7.73.0
debianutils: upgrade 4.11.1 -> 4.11.2
dhcpcd: upgrade 9.2.0 -> 9.3.1
dmidecode: upgrade 3.2 -> 3.3
dnf: upgrade 4.2.23 -> 4.4.0
ethtool: upgrade 5.8 -> 5.9
expat: upgrade 2.2.9 -> 2.2.10
gcr: upgrade 3.36.0 -> 3.38.0
glib-networking: upgrade 2.64.3 -> 2.66.0
gtk+3: upgrade 3.24.22 -> 3.24.23
help2man: upgrade 1.47.15 -> 1.47.16
i2c-tools: upgrade 4.1 -> 4.2
iw: upgrade 5.8 -> 5.9
kmscube: upgrade to latest revision
less: upgrade 562 -> 563
libdnf: upgrade 0.48.0 -> 0.54.2
libgudev: upgrade 233 -> 234
libinput: upgrade 1.16.1 -> 1.16.2
libuv: upgrade 1.39.0 -> 1.40.0
libva: upgrade 2.8.0 -> 2.9.0
libva-utils: update 2.8.0 -> 2.9.1
libwpe: upgrade 1.7.1 -> 1.8.0
libxkbcommon: upgrade 0.10.0 -> 1.0.1
openssh: upgrade 8.3p1 -> 8.4p1
openssl: upgrade 1.1.1g -> 1.1.1h
strace: upgrade 5.8 -> 5.9
sudo: upgrade 1.9.3 -> 1.9.3p1
vala: upgrade 0.48.9 -> 0.50.1
wpebackend-fdo: upgrade 1.7.1 -> 1.8.0
xkeyboard-config: upgrade 2.30 -> 2.31
u-boot: upgrade 2020.07 -> 2020.10
usbutils: upgrade 012 -> 013
nfs-utils: upgrade 2.5.1 -> 2.5.2
dropbear: upgrade 2020.80 -> 2020.81
btrfs-tools: upgrade 5.7 -> 5.9
git: upgrade 2.28.0 -> 2.29.2
go: upgrade 1.15.2 -> 1.15.3
mtools: upgrade 4.0.24 -> 4.0.25
python3-numpy: upgrade 1.19.1 -> 1.19.3
python3-git: upgrade 3.1.7 -> 3.1.11
python3-pyelftools: upgrade 0.26 -> 0.27
python3-pygments: upgrade 2.6.1 -> 2.7.2
python3-setuptools: upgrade 49.6.0 -> 50.3.2
asciidoc: upgrade 9.0.2 -> 9.0.4
iptables: upgrade 1.8.5 -> 1.8.6
libsolv: upgrade 0.7.14 -> 0.7.16
stress-ng: upgrade 0.11.21 -> 0.11.23
libhandy: upgrade 1.0.0 -> 1.0.1
freetype: upgrade 2.10.2 -> 2.10.4
linux-firmware: upgrade 20200817 -> 20201022
alsa: upgrade 1.2.3 -> 1.2.4
gstreamer1.0: upgrade 1.18.0 -> 1.18.1
x264: upgrade to latest revision
rt-tests/hwlatdetect: upgrade 1.8 -> 1.9
webkitgtk: upgrade 2.30.1 -> 2.30.2
diffoscope: upgrade 160 -> 161
enchant2: upgrade 2.2.9 -> 2.2.12
libassuan: upgrade 2.5.3 -> 2.5.4
libcap-ng: upgrade 0.7.11 -> 0.8
libevdev: upgrade 1.9.1 -> 1.10.0
libgcrypt: upgrade 1.8.6 -> 1.8.7
libmpc: upgrade 1.2.0 -> 1.2.1
libsoup-2.4: upgrade 2.70.0 -> 2.72.0
numactl: upgrade 2.0.13 -> 2.0.14
kea: use odd-even version scheme for updates
mesa: fix a build race
clutter-gst-3.0: do not call out to host gstreamer plugin scanner
conf-notes.txt: mention more important images than just sato
weston-init: correctly start under systemd
weston-init: fall back to fbdev under x32
wayland-utils: introduce a recipe
poky/conf-notes.txt: mention more important images than just sato
python3: split python target configuration into own class
python3-pycairo: use python3targetconfig
distutils3-base.bbclass: use python3targetconfig
meta: drop _PYTHON_SYSCONFIGDATA_NAME hacks
gpgme: use python3targetconfig
bitbake: lib/bb/fetch2/__init__.py: drop _PYTHON_SYSCONFIGDATA_NAME unsetting
Alexander Vickberg (1):
socat: make building with OpenSSL support optional
Alistair (1):
weston-init: Fix incorrect idle-time setting
Andrej Valek (1):
autotools: CONFIG_SHELL defaults
Andrey Zhizhikin (1):
insane: add GitLab /archive/ tests
Anibal Limon (1):
recipes-graphics: libxkbcommon disable build of libxkbregistry
Anuj Mittal (2):
glib-2.0: RDEPEND on dbusmock only when GI_DATA_ENABLED is True
distutils-common-base: fix LINKSHARED expansion
Bruce Ashfield (17):
kernel: provide module.lds for out of tree builds in v5.10+
linux-yocto/5.8: update to v5.8.15
linux-yocto/5.4: update to v5.4.71
linux-yocto/5.8: update to v5.8.16
linux-yocto/5.4: update to v5.4.72
linux-yocto/5.8: update to v5.8.17
linux-yocto/5.4: update to v5.4.73
linux-yocto-dev: move to v5.10-rc
linux-yocto/5.4: config cleanup / warnings
linux-yocto/5.8: config cleanup / warnings
linux-yocto/5.8: update to v5.8.18
linux-yocto/5.4: update to v5.4.75
kernel: relocate copy of module.lds to module compilation task
linux-yocto/5.4: perf: Alias SYS_futex with SYS_futex_time64 on 32-bit arches with 64bit time_t
linux-yocto/5.8: perf: Alias SYS_futex with SYS_futex_time64 on 32-bit arches with 64bit time_t
linux-yocto/5.8: ext4/tipc warning fixups
linux-yocto/5.4: update to v5.4.78
Chaitanya Vadrevu (1):
isoimage-isohybrid.py: Support adding files/dirs
Changqing Li (2):
timezone: upgrade to 2020d
vulkan-samples: fix do_compile failure
Chee Yang Lee (2):
bluez5: update to 5.55
ruby: update to 2.7.2
Chris Laplante (4):
bitbake: main: extract creation of argument parser into function so it can be utilized externally, e.g. by unit tests
bitbake: bb.ui: delete __init__.py to make bb.ui a namespace package
bitbake: cookerdata: tweak to avoid mutable default argument
cases/bbtests.py: ensure PACKAGE_CLASSES is set to RPM for bbtests.BitbakeTests.test_force_task_1
Dan Callaghan (1):
gdb: add PACKAGECONFIG for xz (lzma) compression support
Denys Dmytriyenko (1):
grep: upgrade 3.4 -> 3.5
Denys Zagorui (1):
binutils: reproducibility: reuse debug-prefix-map for stabs
Federico Pellegrin (1):
openssl: Add c_rehash to misc package and add perl runtime dependency
Fedor Ross (2):
sysvinit: remove bashism to be compatible with dash
eudev: remove bashism to be compatible with dash
Fredrik Gustafsson (1):
package management: Allow dynamic loading of PM
Gratian Crisan (1):
kernel-module-split.bbclass: identify kernel modconf files as configuration files
He Zhe (1):
lttng-modules: Backport a patch to fix btrfs build failure
Hombourger, Cedric (1):
bitbake: fetch2: use relative symlinks for anything pulled from PREMIRRORS
Hongxu Jia (1):
bitbake: Revert "bb.ui: delete __init__.py to make bb.ui a namespace package"
INC@Cisco) (1):
kernel-devsrc: improve reproducibility for arm64
Jason Wessel (2):
base-files/profile: Add universal resize function
systemd-serialgetty: Switch to TERM=linux
Jose Quaresma (31):
spirv-tools: import from meta-oe to OE core
spirv-tools: enable native build and install more header files
glslang: add receipe
shaderc: add receipe
spirv-tools: fix identation and cleanup install append
maintainers.inc: Add Jose Quaresma
gstreamer1.0: Fix reproducibility issue around libcap
gstreamer1.0: upgrade to version 1.18.0
gstreamer1.0-plugins-base: upgrade to version 1.18.0
gstreamer1.0-plugins-base: add new meson option as PACKAGECONFIG
gstreamer1.0-plugins-good: upgrade to version 1.18.0
gstreamer1.0-plugins-good: disable new meson options
gstreamer1.0-plugins-good: add new meson option as PACKAGECONFIG
gstreamer1.0-plugins-bad: upgrade to version 1.18.0
gstreamer1.0-plugins-bad: disable new meson options
gstreamer1.0-plugins-bad: add new meson options as PACKAGECONFIG
gstreamer1.0-plugins-ugly: upgrade to version 1.18.0
gstreamer1.0-python: upgrade to version 1.18.0
gstreamer1.0-python: install append is not need any more
gstreamer1.0-rtsp-server: upgrade to version 1.18.0
gstreamer1.0-vaapi: upgrade to version 1.18.0
gst-examples: upgrade to version 1.18.0
gstreamer1.0-omx: upgrade to version 1.18.0
gstreamer1.0-libav: upgrade to version 1.18.0
gst-devtools: add version 1.18.0 (gst-validate -> gst-devtools)
orc: Upgrade 0.4.31 -> 0.4.32
gstreamer1.0-plugins-good: on wayland qt5 needs qtwayland
gstreamer1.0-libav: add comercial license flags as ffmpeg needs this
gstreamer1.0-plugins-bad: add srt package config knob
ffmpeg: add srt package config knob
gstreamer1.0-plugins-good: add package config knob for the Raspberry Pi
Joseph Reynolds (1):
add new extrausers command passwd-expire
Joshua Watt (8):
documentation: Add Pipenv support
systemd: Re-enable chvt as non-root user without polkit
python3-pycryptodomex: upgrade 3.9.8 -> 3.9.9
weston-init: Stop running weston as root
python3-pycryptodome: upgrade 3.9.8 -> 3.9.9
bitbake: bitbake: hashserve: Add async client
bitbake: bitbake: hashserve: Add support for readonly upstream
bitbake: bitbake: cache: Remove bad keys() function
Kai Kang (1):
sudo: fix multilib conflict
Khasim Mohammed (1):
grub: add grub-nativesdk
Khem Raj (34):
webkitgtk: Disable gold linker and JIT on riscv
init-ifupdown: Define interfaces file for riscv emulators
init-ifupdown: Merge all interface files for differnet qemus
musl: Update to latest master
qemuboot.bbclass: Fix a typo
musl: Add .file directive in crt assembly files
musl: Update to latest
rpm: Fix error.h handing properly on musl
gdb: Update to 10.x release
numactl: Link with libatomic on rv64/rv32
gstreamer: Fix build on 32bit arches with 64bit time_t
rt-tests: Enable only for x86/ppc64 architectures
lto: Add global LTO distro policy file
python3: Enable lto if its in DISTRO_FEATURES
lto.inc: Add -ffat-lto-objects and -fuse-linker-plugin
lto: Introduce LTOEXTRA variable
libaio: Disable LTO
weston: Fix linking with LTO
lto.inc: Disable LTO for xserver-xorg
gcc: Do no parameterize LTO configuration flags
puzzles: Check for excessive constant arguments
lto.inc: Disable LTO for perf
gcc: Handle duplicate names for variables
musl: Update to latest master
lrzsz: Use Cross AR during compile
gawk: Avoid using host ar during cross compile
lto.inc: Disable LTO for webkit
python-numpy: Add support for riscv32
arch-riscv: Enable qemu-usermode on rv32
python3targetconfig.bbclass: Make py3 dep and tasks only for target recipes
go: Update to 1.15.5
binutils: Fix linker errors on chromium/ffmpeg on aarch64
python3-numpy: Upgrade to 1.19.4
python3-numpy: Add ptest
Konrad Weihmann (3):
oeqa/core/context: expose results as variable
oeqa/core/context: initialize _run_end_time
testimage: print results for interrupted runs
Lee Chee Yang (5):
bitbake: BBHandler: prompt error when task name contain expression
libproxy: fix CVE-2020-26154
python3: fix CVE-2020-27619
python3: whitelist CVE-2020-15523
qemu: fix CVE-2020-24352
Loic Domaigne (1):
roofs_*.bbclass: fix missing vardeps for do_rootfs
Luca Boccassi (1):
dbus: split -common and -tools out of main package
Mark Jonas (4):
libsdl2: Fix directfb syntax error
libsdl2: Fix directfb SDL_RenderFillRect
libbsd: Remove BSD-4-Clause from main package
libsdl2: Add directfb to PACKAGECONFIG rdepends
Martin Jansa (5):
tune-arm9tdmi.inc: include arm9tdmi in PACKAGE_ARCHS
gnutls: explicitly set --with-librt-prefix
webkitgtk: fix opengl PACKAGECONFIG
webkitgtk: fix build with x11 enabled
weston: add pam to REQUIRED_DISTRO_FEATURES
Matt Madison (1):
layer.conf: fix syntax error in PATH setting
Max Krummenacher (1):
linux-firmware: rdepend on license for all nvidia packages
Maxime Roussin-Bélanger (3):
meta: fix some unresponsive homepages and bugtracker links
bitbake: cache: remove unused variables.
bitbake: monitordisk: remove unused function parameter
Mert Kirpici (2):
bitbake: fetch2: add zstd support to unpack
bitbake: doc/conf.py: add missing import sys
Mingli Yu (2):
bitbake.conf: Exclude ${CCACHE_DIR} from pseudo database
update_udev_hwdb: clean hwdb.bin
Nathan Rossi (4):
vim: add nativesdk to BBCLASSEXTEND
rsync: add nativesdk to BBCLASSEXTEND
diffstat: add nativesdk to BBCLASSEXTEND
cml1.bbclass: Handle ncurses-native being available via pkg-config
Nicolas Dechesne (17):
conf: update for release 3.2
poky.yaml: remove unused variables
poky.yaml: updates for 3.2
sphinx: releases: add link to 3.1.3
what-i-wish-id-known: replace labels with references to section title
sdk-manual: replace labels with references to section title
ref-manual: replace labels with references to section title
dev-manual: replace labels with references to section title
kernel-dev: replace labels with references to section title
test-manual: remove unused labels
bsp-guide: remove unused labels
kernel-dev: remove unused labels
profile-manual: remove unused labels
sdk-manual: remove unused labels
toaster-manual: remove unused labels
Makefile: enable parallel build
bitbake: docs: Makefile: enable parallel build
Norbert Kaminski (1):
grub: Add support for RISC-V
Paul Barker (11):
conf.py: Improve TOC and Outline depth in PDF output
conf.py: Add oe_git directive
documentation/README: Refer to top-level README for contributions
dev-manual-common-tasks: Fix refs to testing branches
dev-manual-common-tasks: Update & move patchwork reference
dev-manual-common-tasks: Tidy up patch submission process
dev-manual-common-tasks: Describe git-send-email accurately
dev-manual-common-tasks: Describe how to handle patch feedback
dev-manual-common-tasks: Describe how to propose changes to stable branches
dev-manual-common-tasks: Re-order patch submission instructions
poky.yaml: Define DISTRO_NAME_NO_CAP_LTS
Paul Eggleton (10):
ref-manual: add reference anchors for each QA check
ref-manual: fix for features_check class change
ref-manual: QA check updates
ref-manual: add PSEUDO_IGNORE_PATHS
ref-manual: add IMAGE_VERSION_SUFFIX variable
ref-manual: add IMAGE_NAME_SUFFIX variable
ref-manual: add migration section for 3.2
ref-manual: add IMAGE_LINK_NAME
ref-manual: add migration info for image-artifact-names
ref-manual: add migration info about MLPREFIX changes
Peter Bergin (2):
rt-tests: backport patch that enable build for all archs
Revert "rt-tests: Enable only for x86/ppc64 architectures"
Purushottam choudhary (1):
systemd: selinux hook handling to enumerate nexthop
Randy MacLeod (1):
libsdl2: Disable video-rpi
Randy Witt (4):
numactl: Add the recipe for numactl
numactl: Remove COMPATIBLE_HOST restrictions
numactl: Skip the ptests when numa is not supported
rt-tests: Update recipes to use 1.8
Ricardo Salveti (1):
dosfstools: add mkfs.vfat to ALTERNATIVE
Richard Leitner (4):
deb: replace deprecated apt force-yes argument
xcb-proto: update to 1.14.1
deb: export INTERCEPT_DIR for remove actions
weston-init: introduce WESTON_GROUP
Richard Purdie (21):
ref-manual/faq: Add entry for why binaries are changed in images
dev-manual: Add a note about prelink changing prebuild binaries
sstatesig: Log timestamps for hashequiv in reprodubile builds for do_package
netbase: Add whitespace to purge bogus hash equivalence from autobuilder
scripts/buildhistory_analysis: Avoid tracebacks from file comparision code
maintainers: Add myself as numactl maintainer to avoid QA errors
bitbake: bitbake: Post release version bump
poky.conf: Post release version bump
libxcb: Fix install file owner/group
bitbake: siggen: Remove broken optimisation
bitbake: fetch2/git: Document that we won't support passwords in git urls
sstatesig: Remove workaround for bitbake taskhash bug
ptest-runner: Fix license as it contains 'or later' clause
libdnf: Fix license as it contains 'or later' clause
alsa-utils: Fix license to GPLv2 only
overview-manual-concepts: Fix the compiler bootstrap process
bitbake: Add missing documentation Makefile
oeqa/commands: Fix compatibility with python 3.9
fs-perms: Ensure /usr/src/debug/ file modes are correct
e2fsprogs: Fix a ptest permissions determinism issue
uninative: Don't use single sstate for pseudo-native
Robert P. J. Day (3):
ref-manual/ref-variables: "PACKAGE_FEEDS_ARCHS" -> "PACKAGE_FEED_ARCHS"
README: "yocto-project-qs" -> "brief-yoctoprojectqs"
adt-manual: delete obsolete ADT manual, and related content
Ross Burton (13):
rpm: use libgcrypt instead of OpenSSL for cryptography
syslinux: add link to upstream discussion in patch
json-glib: use PACKAGECONFIG for tests
json-glib: update patch status
libical: backport a patch to fix build with ICU 68.1
webkitgtk: fix build with ICU 68.1
cve-check: show real PN/PV
python3: add CVE-2007-4559 to whitelist
sqlite3: add CVE-2015-3717 to whitelist
gstreamer1.0-rtsp-server: set CVE_PRODUCT
gstreamer1.0-plugins-base: set CVE_PRODUCT
bitbake: providers: selected version not available should be a warning
cve-update-db-native: handle all-wildcard versions
Saul Wold (1):
classes/buildhistory: record LICENSE
Sinan Kaya (2):
volatile-binds: add /srv to mount and install
kernel-uboot: allow compression option to be configurable
Stacy Gaikovaia (1):
valgrind: helgrind: Intercept libc functions
Steve Sakoman (3):
netbase: update SRC_URI to reflect new file name
openssh: whitelist CVE-2014-9278
cups: whitelist CVE-2018-6553
Tim Orling (22):
python3-atomicwrites: move from meta-python
python3-attrs: move from meta-python
python3-iniconfig: move from meta-python
python3-more-itertools: move from meta-python
python3-pathlib2: move from meta-python
python3-toml: move from meta-python
python3-py: move from meta-python
python3-setuptools-scm: move from meta-python
python3-packaging: move from meta-python
python3-wcwidth: move from meta-python
python3-zipp: move from meta-python
python3-importlib-metadata: move from meta-python
python3-pluggy: move from meta-python
python3-pytest: move from meta-python
maintainers.inc: add self for new pytest packages
python3-more-itertools: upgrade 8.5.0 -> 8.6.0
python3-importlib-metadata: upgrade 2.0.0 to 3.1.0
python3-pytest: RDEPENDS on python3-toml
python3-hypothesis: move from meta-python
python3-sortedcontainers: move from meta-python
maintainers.inc: add self for new python recipes
python3-hypothesis: upgrade 5.41.3 -> 5.41.4
Tom Hochstein (1):
mesa: Add xcb-fixes to loader when using x11 and dri3
Vyacheslav Yurkov (1):
license_image.bbclass: use canonical name for license files
Wonmin Jung (1):
kernel: Set proper LD in KERNEL_KCONFIG_COMMAND
Yann Dirson (6):
systemtap: split examples and python scripts out of main package
systemtap: remove extra dependencies
systemtap: clarify the relation between exporter and python3-probes feature
systemtap: fix install when python3-probes is disabled in PACKAGECONFIG
systemtap: split runtime material in its own package
systemtap: avoid RDEPENDS on python3-core when not using python3
Yann E. MORIN (2):
common-licenses: add bzip2-1.0.4
recipes-core/busybox: fixup licensing information
Yi Zhao (5):
resolvconf: do not install dhclient hooks
connman: set service to conflict with systemd-networkd
pulseaudio: unify volatiles file name
dhcpcd: install dhcpcd to /sbin rather than /usr/sbin
dhcpcd: upgrade 9.3.1 -> 9.3.2
Yongxin Liu (2):
grub: fix several CVEs in grub 2.04
grub: clean up CVE patches
zangrc (18):
python3-pycairo: upgrade 1.19.1 -> 1.20.0
iproute2: upgrade 5.8.0 -> 5.9.0
icu: upgrade 67.1 -> 68.1
libdnf: upgrade 0.54.2 -> 0.55.0
libinput: upgrade 1.16.2 -> 1.16.3
enchant2: upgrade 2.2.12 -> 2.2.13
libdrm: upgrade 2.4.102 -> 2.4.103
gmp: upgrade 6.2.0 -> 6.2.1
gpgme: upgrade 1.14.0 -> 1.15.0
libunwind: upgrade 1.4.0 -> 1.5.0
msmtp: upgrade 1.8.12 -> 1.8.13
gtk-doc: upgrade 1.33.0 -> 1.33.1
hdparm: upgrade 9.58 -> 9.60
libcap-ng: upgrade 0.8 -> 0.8.1
libjpeg-turbo: upgrade 2.0.5 -> 2.0.6
libxkbcommon: upgrade 1.0.1 -> 1.0.3
pulseaudio: upgrade 13.0 -> 14.0
wireless-regdb: upgrade 2020.04.29 -> 2020.11.20
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
Change-Id: I22fa6c7160be5ff2105113cc63acc25f8977ae4e
diff --git a/poky/documentation/dev-manual/dev-manual-common-tasks.rst b/poky/documentation/dev-manual/dev-manual-common-tasks.rst
index 0630040..683f555 100644
--- a/poky/documentation/dev-manual/dev-manual-common-tasks.rst
+++ b/poky/documentation/dev-manual/dev-manual-common-tasks.rst
@@ -1143,7 +1143,7 @@
included in a build.
You can find a complete description of the ``devtool add`` command in
-the ":ref:`sdk-a-closer-look-at-devtool-add`" section
+the ":ref:`sdk-manual/sdk-extensible:a closer look at \`\`devtool add\`\``" section
in the Yocto Project Application Development and the Extensible Software
Development Kit (eSDK) manual.
@@ -1819,7 +1819,7 @@
For cases where improper paths are detected for configuration files
or for when libraries/headers cannot be found, be sure you are using
the more robust ``pkg-config``. See the note in section
- ":ref:`new-recipe-configuring-the-recipe`" for additional information.
+ ":ref:`dev-manual/dev-manual-common-tasks:Configuring the Recipe`" for additional information.
- *Parallel build failures:* These failures manifest themselves as
intermittent errors, or errors reporting that a file or directory
@@ -2602,6 +2602,13 @@
where you have installed them and whether those files are in
different locations than the defaults.
+.. note::
+
+ If image prelinking is enabled (e.g. "image-prelink" is in :term:`USER_CLASSES`
+ which it is by default), prelink will change the binaries in the generated images
+ and this often catches people out. Remove that class to ensure binaries are
+ preserved exactly if that is necessary.
+
Following Recipe Style Guidelines
---------------------------------
@@ -3041,7 +3048,7 @@
1. *Be Sure the Development Host is Set Up:* You need to be sure that
your development host is set up to use the Yocto Project. For
information on how to set up your host, see the
- ":ref:`dev-preparing-the-build-host`" section.
+ ":ref:`dev-manual/dev-manual-start:Preparing the Build Host`" section.
2. *Make Sure Git is Configured:* The AUH utility requires Git to be
configured because AUH uses Git to save upgrades. Thus, you must have
@@ -3209,7 +3216,7 @@
newer versions is to use
:doc:`devtool upgrade <../ref-manual/ref-devtool-reference>`.
You can read about ``devtool upgrade`` in general in the
-":ref:`sdk-devtool-use-devtool-upgrade-to-create-a-version-of-the-recipe-that-supports-a-newer-version-of-the-software`"
+":ref:`sdk-manual/sdk-extensible:use \`\`devtool upgrade\`\` to create a version of the recipe that supports a newer version of the software`"
section in the Yocto Project Application Development and the Extensible
Software Development Kit (eSDK) Manual.
@@ -3349,7 +3356,8 @@
---------------------------
If for some reason you choose not to upgrade recipes using
-:ref:`gs-using-the-auto-upgrade-helper` or by :ref:`gs-using-devtool-upgrade`,
+:ref:`dev-manual/dev-manual-common-tasks:Using the Auto Upgrade Helper (AUH)` or
+by :ref:`dev-manual/dev-manual-common-tasks:Using \`\`devtool upgrade\`\``,
you can manually edit the recipe files to upgrade the versions.
.. note::
@@ -4189,7 +4197,7 @@
directory.
For more information on configuration fragments, see the
- ":ref:`creating-config-fragments`"
+ ":ref:`kernel-dev/kernel-dev-common:creating configuration fragments`"
section in the Yocto Project Linux Kernel Development Manual.
- ``bitbake -u taskexp -g bitbake_target``: Using the BitBake command
@@ -8136,7 +8144,7 @@
EXTRA_IMAGE_FEATURES = "read-only-rootfs"
For more information on how to use these variables, see the
-":ref:`usingpoky-extend-customimage-imagefeatures`"
+":ref:`dev-manual/dev-manual-common-tasks:Customizing Images Using Custom \`\`IMAGE_FEATURES\`\` and \`\`EXTRA_IMAGE_FEATURES\`\``"
section. For information on the variables, see
:term:`IMAGE_FEATURES` and
:term:`EXTRA_IMAGE_FEATURES`.
@@ -10658,44 +10666,34 @@
section in the Yocto Project Overview and Concepts Manual for additional
concepts on working in the Yocto Project development environment.
-Two commonly used testing repositories exist for OpenEmbedded-Core:
+Maintainers commonly use ``-next`` branches to test submissions prior to
+merging patches. Thus, you can get an idea of the status of a patch based on
+whether the patch has been merged into one of these branches. The commonly
+used testing branches for OpenEmbedded-Core are as follows:
-- *"ross/mut" branch:* The "mut" (master-under-test) tree exists in the
- ``poky-contrib`` repository in the
- :yocto_git:`Yocto Project source repositories <>`.
+- *openembedded-core "master-next" branch:* This branch is part of the
+ :oe_git:`openembedded-core </openembedded-core/>` repository and contains
+ proposed changes to the core metadata.
-- *"master-next" branch:* This branch is part of the main "poky"
- repository in the Yocto Project source repositories.
+- *poky "master-next" branch:* This branch is part of the
+ :yocto_git:`poky </cgit/cgit.cgi/poky/>` repository and combines proposed
+ changes to bitbake, the core metadata and the poky distro.
-Maintainers use these branches to test submissions prior to merging
-patches. Thus, you can get an idea of the status of a patch based on
-whether the patch has been merged into one of these branches.
+Similarly, stable branches maintained by the project may have corresponding
+``-next`` branches which collect proposed changes. For example,
+``&DISTRO_NAME_NO_CAP;-next`` and ``&DISTRO_NAME_NO_CAP_MINUS_ONE;-next``
+branches in both the "openembdedded-core" and "poky" repositories.
-.. note::
-
- This system is imperfect and changes can sometimes get lost in the
- flow. Asking about the status of a patch or change is reasonable if
- the change has been idle for a while with no feedback. The Yocto
- Project does have plans to use
- `Patchwork <https://en.wikipedia.org/wiki/Patchwork_(software)>`__
- to track the status of patches and also to automatically preview
- patches.
+Other layers may have similar testing branches but there is no formal
+requirement or standard for these so please check the documentation for the
+layers you are contributing to.
The following sections provide procedures for submitting a change.
-.. _pushing-a-change-upstream:
+.. _preparing-changes-for-submissions:
-Using Scripts to Push a Change Upstream and Request a Pull
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Follow this procedure to push a change to an upstream "contrib" Git
-repository:
-
-.. note::
-
- You can find general Git information on how to push a change upstream
- in the
- `Git Community Book <https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows>`__.
+Preparing Changes for Submission
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. *Make Your Changes Locally:* Make your changes in your local Git
repository. You should make small, controlled, isolated changes.
@@ -10777,7 +10775,121 @@
detailed description of change
-4. *Push Your Commits to a "Contrib" Upstream:* If you have arranged for
+.. _submitting-a-patch:
+
+Using Email to Submit a Patch
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Depending on the components changed, you need to submit the email to a
+specific mailing list. For some guidance on which mailing list to use,
+see the `list <#figuring-out-the-mailing-list-to-use>`__ at the
+beginning of this section. For a description of all the available
+mailing lists, see the ":ref:`Mailing Lists <resources-mailinglist>`" section in the
+Yocto Project Reference Manual.
+
+Here is the general procedure on how to submit a patch through email
+without using the scripts once the steps in
+:ref:`preparing-changes-for-submissions` have been followed:
+
+1. *Format the Commit:* Format the commit into an email message. To
+ format commits, use the ``git format-patch`` command. When you
+ provide the command, you must include a revision list or a number of
+ patches as part of the command. For example, either of these two
+ commands takes your most recent single commit and formats it as an
+ email message in the current directory:
+ ::
+
+ $ git format-patch -1
+
+ or ::
+
+ $ git format-patch HEAD~
+
+ After the command is run, the current directory contains a numbered
+ ``.patch`` file for the commit.
+
+ If you provide several commits as part of the command, the
+ ``git format-patch`` command produces a series of numbered files in
+ the current directory – one for each commit. If you have more than
+ one patch, you should also use the ``--cover`` option with the
+ command, which generates a cover letter as the first "patch" in the
+ series. You can then edit the cover letter to provide a description
+ for the series of patches. For information on the
+ ``git format-patch`` command, see ``GIT_FORMAT_PATCH(1)`` displayed
+ using the ``man git-format-patch`` command.
+
+ .. note::
+
+ If you are or will be a frequent contributor to the Yocto Project
+ or to OpenEmbedded, you might consider requesting a contrib area
+ and the necessary associated rights.
+
+2. *Send the patches via email:* Send the patches to the recipients and
+ relevant mailing lists by using the ``git send-email`` command.
+
+ .. note::
+
+ In order to use ``git send-email``, you must have the proper Git packages
+ installed on your host.
+ For Ubuntu, Debian, and Fedora the package is ``git-email``.
+
+ The ``git send-email`` command sends email by using a local or remote
+ Mail Transport Agent (MTA) such as ``msmtp``, ``sendmail``, or
+ through a direct ``smtp`` configuration in your Git ``~/.gitconfig``
+ file. If you are submitting patches through email only, it is very
+ important that you submit them without any whitespace or HTML
+ formatting that either you or your mailer introduces. The maintainer
+ that receives your patches needs to be able to save and apply them
+ directly from your emails. A good way to verify that what you are
+ sending will be applicable by the maintainer is to do a dry run and
+ send them to yourself and then save and apply them as the maintainer
+ would.
+
+ The ``git send-email`` command is the preferred method for sending
+ your patches using email since there is no risk of compromising
+ whitespace in the body of the message, which can occur when you use
+ your own mail client. The command also has several options that let
+ you specify recipients and perform further editing of the email
+ message. For information on how to use the ``git send-email``
+ command, see ``GIT-SEND-EMAIL(1)`` displayed using the
+ ``man git-send-email`` command.
+
+The Yocto Project uses a `Patchwork instance <https://patchwork.openembedded.org/>`__
+to track the status of patches submitted to the various mailing lists and to
+support automated patch testing. Each submitted patch is checked for common
+mistakes and deviations from the expected patch format and submitters are
+notified by patchtest if such mistakes are found. This process helps to
+reduce the burden of patch review on maintainers.
+
+.. note::
+
+ This system is imperfect and changes can sometimes get lost in the flow.
+ Asking about the status of a patch or change is reasonable if the change
+ has been idle for a while with no feedback.
+
+.. _pushing-a-change-upstream:
+
+Using Scripts to Push a Change Upstream and Request a Pull
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+For larger patch series it is preferable to send a pull request which not
+only includes the patch but also a pointer to a branch that can be pulled
+from. This involves making a local branch for your changes, pushing this
+branch to an accessible repository and then using the ``create-pull-request``
+and ``send-pull-request`` scripts from openembedded-core to create and send a
+patch series with a link to the branch for review.
+
+Follow this procedure to push a change to an upstream "contrib" Git
+repository once the steps in :ref:`preparing-changes-for-submissions` have
+been followed:
+
+.. note::
+
+ You can find general Git information on how to push a change upstream
+ in the
+ `Git Community Book <https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows>`__.
+
+1. *Push Your Commits to a "Contrib" Upstream:* If you have arranged for
permissions to push to an upstream contrib repository, push the
change to that repository:
::
@@ -10794,7 +10906,7 @@
$ git push meta-intel-contrib your_name/README
-5. *Determine Who to Notify:* Determine the maintainer or the mailing
+2. *Determine Who to Notify:* Determine the maintainer or the mailing
list that you need to notify for the change.
Before submitting any change, you need to be sure who the maintainer
@@ -10823,7 +10935,7 @@
lists <resources-mailinglist>`" section in
the Yocto Project Reference Manual.
-6. *Make a Pull Request:* Notify the maintainer or the mailing list that
+3. *Make a Pull Request:* Notify the maintainer or the mailing list that
you have pushed a change by making a pull request.
The Yocto Project provides two scripts that conveniently let you
@@ -10872,108 +10984,84 @@
$ poky/scripts/create-pull-request -h
$ poky/scripts/send-pull-request -h
+Responding to Patch Review
+~~~~~~~~~~~~~~~~~~~~~~~~~~
-.. _submitting-a-patch:
+You may get feedback on your submitted patches from other community members
+or from the automated patchtest service. If issues are identified in your
+patch then it is usually necessary to address these before the patch will be
+accepted into the project. In this case you should amend the patch according
+to the feedback and submit an updated version to the relevant mailing list,
+copying in the reviewers who provided feedback to the previous version of the
+patch.
-Using Email to Submit a Patch
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+The patch should be amended using ``git commit --amend`` or perhaps ``git
+rebase`` for more expert git users. You should also modify the ``[PATCH]``
+tag in the email subject line when sending the revised patch to mark the new
+iteration as ``[PATCH v2]``, ``[PATCH v3]``, etc as appropriate. This can be
+done by passing the ``-v`` argument to ``git format-patch`` with a version
+number.
-You can submit patches without using the ``create-pull-request`` and
-``send-pull-request`` scripts described in the previous section.
-However, keep in mind, the preferred method is to use the scripts.
+Lastly please ensure that you also test your revised changes. In particular
+please don't just edit the patch file written out by ``git format-patch`` and
+resend it.
-Depending on the components changed, you need to submit the email to a
-specific mailing list. For some guidance on which mailing list to use,
-see the `list <#figuring-out-the-mailing-list-to-use>`__ at the
-beginning of this section. For a description of all the available
-mailing lists, see the ":ref:`Mailing Lists <resources-mailinglist>`" section in the
-Yocto Project Reference Manual.
+Submitting Changes to Stable Release Branches
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Here is the general procedure on how to submit a patch through email
-without using the scripts:
+The process for proposing changes to a Yocto Project stable branch differs
+from the steps described above. Changes to a stable branch must address
+identified bugs or CVEs and should be made carefully in order to avoid the
+risk of introducing new bugs or breaking backwards compatibility. Typically
+bug fixes must already be accepted into the master branch before they can be
+backported to a stable branch unless the bug in question does not affect the
+master branch or the fix on the master branch is unsuitable for backporting.
-1. *Make Your Changes Locally:* Make your changes in your local Git
- repository. You should make small, controlled, isolated changes.
- Keeping changes small and isolated aids review, makes
- merging/rebasing easier and keeps the change history clean should
- anyone need to refer to it in future.
+The list of stable branches along with the status and maintainer for each
+branch can be obtained from the
+:yocto_wiki:`Releases wiki page </wiki/Releases>`.
-2. *Stage Your Changes:* Stage your changes by using the ``git add``
- command on each file you changed.
+.. note::
-3. *Commit Your Changes:* Commit the change by using the
- ``git commit --signoff`` command. Using the ``--signoff`` option
- identifies you as the person making the change and also satisfies the
- Developer's Certificate of Origin (DCO) shown earlier.
+ Changes will not typically be accepted for branches which are marked as
+ End-Of-Life (EOL).
- When you form a commit, you must follow certain standards established
- by the Yocto Project development team. See :ref:`Step 3
- <dev-manual/dev-manual-common-tasks:using scripts to push a change upstream and request a pull>`
- in the previous section for information on how to provide commit information
- that meets Yocto Project commit message standards.
+With this in mind, the steps to submit a change for a stable branch are as
+follows:
-4. *Format the Commit:* Format the commit into an email message. To
- format commits, use the ``git format-patch`` command. When you
- provide the command, you must include a revision list or a number of
- patches as part of the command. For example, either of these two
- commands takes your most recent single commit and formats it as an
- email message in the current directory:
- ::
+1. *Identify the bug or CVE to be fixed:* This information should be
+ collected so that it can be included in your submission.
- $ git format-patch -1
+2. *Check if the fix is already present in the master branch:* This will
+ result in the most straightforward path into the stable branch for the
+ fix.
- or ::
+ 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.
- $ git format-patch HEAD~
+ 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.
- After the command is run, the current directory contains a numbered
- ``.patch`` file for the commit.
-
- If you provide several commits as part of the command, the
- ``git format-patch`` command produces a series of numbered files in
- the current directory – one for each commit. If you have more than
- one patch, you should also use the ``--cover`` option with the
- command, which generates a cover letter as the first "patch" in the
- series. You can then edit the cover letter to provide a description
- for the series of patches. For information on the
- ``git format-patch`` command, see ``GIT_FORMAT_PATCH(1)`` displayed
- using the ``man git-format-patch`` command.
-
- .. note::
-
- If you are or will be a frequent contributor to the Yocto Project
- or to OpenEmbedded, you might consider requesting a contrib area
- and the necessary associated rights.
-
-5. *Import the Files Into Your Mail Client:* Import the files into your
- mail client by using the ``git send-email`` command.
-
- .. note::
-
- In order to use ``git send-email``, you must have the proper Git packages
- installed on your host.
- For Ubuntu, Debian, and Fedora the package is ``git-email``.
-
- The ``git send-email`` command sends email by using a local or remote
- Mail Transport Agent (MTA) such as ``msmtp``, ``sendmail``, or
- through a direct ``smtp`` configuration in your Git ``~/.gitconfig``
- file. If you are submitting patches through email only, it is very
- important that you submit them without any whitespace or HTML
- formatting that either you or your mailer introduces. The maintainer
- that receives your patches needs to be able to save and apply them
- directly from your emails. A good way to verify that what you are
- sending will be applicable by the maintainer is to do a dry run and
- send them to yourself and then save and apply them as the maintainer
- would.
-
- The ``git send-email`` command is the preferred method for sending
- your patches using email since there is no risk of compromising
- whitespace in the body of the message, which can occur when you use
- your own mail client. The command also has several options that let
- you specify recipients and perform further editing of the email
- message. For information on how to use the ``git send-email``
- command, see ``GIT-SEND-EMAIL(1)`` displayed using the
- ``man git-send-email`` command.
+ 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
+ issue or when the issue has been fixed on the master branch in a way
+ that introduces backwards incompatible changes. In this case follow the
+ steps in :ref:`preparing-changes-for-submissions` and
+ :ref:`submitting-a-patch` but modify the subject header of your patch
+ email to include the name of the stable branch which you are
+ targetting. This can be done using the ``--subject-prefix`` argument to
+ ``git format-patch``, for example to submit a patch to the dunfell
+ branch use
+ ``git format-patch --subject-prefix='&DISTRO_NAME_NO_CAP_MINUS_ONE;][PATCH' ...``.
Working With Licenses
=====================