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

1 files changed, 225 insertions, 137 deletions

diff --git a/poky/documentation/dev-manual/dev-manual-common-tasks.rst b/poky/documentation/dev-manual/dev-manual-common-tasks.rst
index 0630040e6..683f5557e 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 @@ necessary when adding a recipe to build a new piece of software to be
 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 @@ Here are some common issues that cause failures.
    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 @@ doing the following:
    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 @@ The following steps describe how to set up the AUH utility:
 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 @@ As mentioned earlier, an alternative method for upgrading recipes to
 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 @@ Manually Upgrading a Recipe
 ---------------------------
 
 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 @@ view file dependencies in a human-readable form:
    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 @@ associated ``EXTRA_IMAGE_FEATURES`` variable, as in:
    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 @@ to a contribution repository that is upstream. See the ":ref:`gs-git-workflows-a
 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 @@ repository:
 
          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 @@ repository:
 
       $ 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 @@ repository:
       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 @@ repository:
               $ poky/scripts/create-pull-request -h
               $ poky/scripts/send-pull-request -h
 
+Responding to Patch Review
+~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-.. _submitting-a-patch:
-
-Using Email to Submit a Patch
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-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.
-
-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:
-
-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.
-
-2. *Stage Your Changes:* Stage your changes by using the ``git add``
-   command on each file you changed.
-
-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.
-
-   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.
-
-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:
-   ::
-
-      $ 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.
-
-5. *Import the Files Into Your Mail Client:* Import the files into your
-   mail client by using the ``git send-email`` command.
+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.
+
+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.
+
+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.
+
+Submitting Changes to Stable Release Branches
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+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.
+
+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>`.
 
-   .. note::
+.. 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``.
+   Changes will not typically be accepted for branches which are marked as
+   End-Of-Life (EOL).
 
-   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.
+With this in mind, the steps to submit a change for a stable branch are as
+follows:
 
-   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.
+1. *Identify the bug or CVE to be fixed:* This information should be
+   collected so that it can be included in your submission.
+
+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.
+
+   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
+      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
+      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
 =====================