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

45 files changed, 952 insertions, 1691 deletions

diff --git a/poky/documentation/.gitignore b/poky/documentation/.gitignore
index 69fa449dd..21bb72530 100644
--- a/poky/documentation/.gitignore
+++ b/poky/documentation/.gitignore
@@ -1 +1,2 @@
 _build/
+Pipfile.lock
diff --git a/poky/documentation/Makefile b/poky/documentation/Makefile
index 4d721d30f..d40f390e2 100644
--- a/poky/documentation/Makefile
+++ b/poky/documentation/Makefile
@@ -3,7 +3,7 @@
 
 # You can set these variables from the command line, and also
 # from the environment for the first two.
-SPHINXOPTS    ?=
+SPHINXOPTS    ?= -j auto
 SPHINXBUILD   ?= sphinx-build
 SOURCEDIR     = .
 BUILDDIR      = _build
diff --git a/poky/documentation/Pipfile b/poky/documentation/Pipfile
new file mode 100644
index 000000000..7ee1d2290
--- /dev/null
+++ b/poky/documentation/Pipfile
@@ -0,0 +1,14 @@
+[[source]]
+name = "pypi"
+url = "https://pypi.org/simple"
+verify_ssl = true
+
+[dev-packages]
+
+[packages]
+sphinx = "*"
+sphinx-rtd-theme = "*"
+pyyaml = "*"
+
+[requires]
+python_version = "3"
diff --git a/poky/documentation/README b/poky/documentation/README
index fe86876ee..b0a3cb1dc 100644
--- a/poky/documentation/README
+++ b/poky/documentation/README
@@ -34,15 +34,15 @@ Manual Organization
 
 Folders exist for individual manuals as follows:
 
-* sdk-manual       - The Yocto Project Software Development Kit (SDK) Developer's Guide.
-* bsp-guide        - The Yocto Project Board Support Package (BSP) Developer's Guide
-* dev-manual       - The Yocto Project Development Tasks Manual
-* kernel-dev       - The Yocto Project Linux Kernel Development Tasks Manual
-* ref-manual       - The Yocto Project Reference Manual
-* yocto-project-qs - The Yocto Project Quick Start
-* profile-manual   - The Yocto Project Profile and Tracing Manual
-* toaster-manual   - The Toaster Manual
-* test-manual      - The Test Environment Manual
+* sdk-manual           - The Yocto Project Software Development Kit (SDK) Developer's Guide.
+* bsp-guide            - The Yocto Project Board Support Package (BSP) Developer's Guide
+* dev-manual           - The Yocto Project Development Tasks Manual
+* kernel-dev           - The Yocto Project Linux Kernel Development Tasks Manual
+* ref-manual           - The Yocto Project Reference Manual
+* brief-yoctoprojectqs - The Yocto Project Quick Start
+* profile-manual       - The Yocto Project Profile and Tracing Manual
+* toaster-manual       - The Toaster Manual
+* test-manual          - The Test Environment Manual
 
 Each folder is self-contained regarding content and figures.
 
@@ -127,6 +127,13 @@ The resulting HTML index page will be _build/html/index.html, and you
 can browse your own copy of the locally generated documentation with
 your browser.
 
+Alternatively, you can use Pipenv to automatically install all required
+dependencies in a virtual environment:
+
+ $ cd documentation
+ $ pipenv install
+ $ pipenv run make html
+
 Sphinx theme and CSS customization
 ==================================
 
@@ -318,3 +325,9 @@ References to the bitbake manual can be done like this:
   See the ":ref:`-D <bitbake:bitbake-user-manual/bitbake-user-manual-intro:usage and syntax>`" option
 or
   :term:`bitbake:BB_NUMBER_PARSE_THREADS`
+
+Submitting documentation changes
+================================
+
+Please see the top level README file in this repository for details of where
+to send patches.
diff --git a/poky/documentation/adt-manual/adt-command.rst b/poky/documentation/adt-manual/adt-command.rst
deleted file mode 100644
index d348adfcc..000000000
--- a/poky/documentation/adt-manual/adt-command.rst
+++ /dev/null
@@ -1,180 +0,0 @@
-.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
-
-**********************
-Using the Command Line
-**********************
-
-Recall that earlier the manual discussed how to use an existing
-toolchain tarball that had been installed into the default installation
-directory, ``/opt/poky/DISTRO``, which is outside of the :term:`Build Directory`
-(see the section
-"`Using a Cross-Toolchain
-Tarball) <#using-an-existing-toolchain-tarball>`__". And, that sourcing
-your architecture-specific environment setup script initializes a
-suitable cross-toolchain development environment.
-
-During this setup, locations for the compiler, QEMU scripts, QEMU
-binary, a special version of ``pkgconfig`` and other useful utilities
-are added to the ``PATH`` variable. Also, variables to assist
-``pkgconfig`` and ``autotools`` are also defined so that, for example,
-``configure.sh`` can find pre-generated test results for tests that need
-target hardware on which to run. You can see the "`Setting Up the
-Cross-Development
-Environment <#setting-up-the-cross-development-environment>`__" section
-for the list of cross-toolchain environment variables established by the
-script.
-
-Collectively, these conditions allow you to easily use the toolchain
-outside of the OpenEmbedded build environment on both Autotools-based
-projects and Makefile-based projects. This chapter provides information
-for both these types of projects.
-
-Autotools-Based Projects
-========================
-
-Once you have a suitable cross-toolchain installed, it is very easy to
-develop a project outside of the OpenEmbedded build system. This section
-presents a simple "Helloworld" example that shows how to set up,
-compile, and run the project.
-
-Creating and Running a Project Based on GNU Autotools
------------------------------------------------------
-
-Follow these steps to create a simple Autotools-based project:
-
-1.  *Create your directory:* Create a clean directory for your project
-    and then make that directory your working location: $ mkdir
-    $HOME/helloworld $ cd $HOME/helloworld
-
-2.  *Populate the directory:* Create ``hello.c``, ``Makefile.am``, and
-    ``configure.in`` files as follows:
-
-    -  For ``hello.c``, include these lines: #include <stdio.h> main() {
-       printf("Hello World!\n"); }
-
-    -  For ``Makefile.am``, include these lines: bin_PROGRAMS = hello
-       hello_SOURCES = hello.c
-
-    -  For ``configure.in``, include these lines: AC_INIT(hello.c)
-       AM_INIT_AUTOMAKE(hello,0.1) AC_PROG_CC AC_PROG_INSTALL
-       AC_OUTPUT(Makefile)
-
-3.  *Source the cross-toolchain environment setup file:* Installation of
-    the cross-toolchain creates a cross-toolchain environment setup
-    script in the directory that the ADT was installed. Before you can
-    use the tools to develop your project, you must source this setup
-    script. The script begins with the string "environment-setup" and
-    contains the machine architecture, which is followed by the string
-    "poky-linux". Here is an example that sources a script from the
-    default ADT installation directory that uses the 32-bit Intel x86
-    Architecture and the DISTRO_NAME Yocto Project release: $ source
-    /opt/poky/DISTRO/environment-setup-i586-poky-linux
-
-4.  *Generate the local aclocal.m4 files and create the configure
-    script:* The following GNU Autotools generate the local
-    ``aclocal.m4`` files and create the configure script: $ aclocal $
-    autoconf
-
-5.  *Generate files needed by GNU coding standards:* GNU coding
-    standards require certain files in order for the project to be
-    compliant. This command creates those files: $ touch NEWS README
-    AUTHORS ChangeLog
-
-6.  *Generate the configure file:* This command generates the
-    ``configure``: $ automake -a
-
-7.  *Cross-compile the project:* This command compiles the project using
-    the cross-compiler. The
-    :term:`CONFIGURE_FLAGS`
-    environment variable provides the minimal arguments for GNU
-    configure: $ ./configure ${CONFIGURE_FLAGS}
-
-8.  *Make and install the project:* These two commands generate and
-    install the project into the destination directory: $ make $ make
-    install DESTDIR=./tmp
-
-9.  *Verify the installation:* This command is a simple way to verify
-    the installation of your project. Running the command prints the
-    architecture on which the binary file can run. This architecture
-    should be the same architecture that the installed cross-toolchain
-    supports. $ file ./tmp/usr/local/bin/hello
-
-10. *Execute your project:* To execute the project in the shell, simply
-    enter the name. You could also copy the binary to the actual target
-    hardware and run the project there as well: $ ./hello As expected,
-    the project displays the "Hello World!" message.
-
-Passing Host Options
---------------------
-
-For an Autotools-based project, you can use the cross-toolchain by just
-passing the appropriate host option to ``configure.sh``. The host option
-you use is derived from the name of the environment setup script found
-in the directory in which you installed the cross-toolchain. For
-example, the host option for an ARM-based target that uses the GNU EABI
-is ``armv5te-poky-linux-gnueabi``. You will notice that the name of the
-script is ``environment-setup-armv5te-poky-linux-gnueabi``. Thus, the
-following command works to update your project and rebuild it using the
-appropriate cross-toolchain tools: $ ./configure
---host=armv5te-poky-linux-gnueabi \\ --with-libtool-sysroot=sysroot_dir
-
-.. note::
-
-   If the
-   configure
-   script results in problems recognizing the
-   --with-libtool-sysroot=
-   sysroot-dir
-   option, regenerate the script to enable the support by doing the
-   following and then run the script again:
-   ::
-
-           $ libtoolize --automake
-           $ aclocal -I ${OECORE_NATIVE_SYSROOT}/usr/share/aclocal \
-              [-I dir_containing_your_project-specific_m4_macros]
-           $ autoconf
-           $ autoheader
-           $ automake -a
-                      
-
-Makefile-Based Projects
-=======================
-
-For Makefile-based projects, the cross-toolchain environment variables
-established by running the cross-toolchain environment setup script are
-subject to general ``make`` rules.
-
-To illustrate this, consider the following four cross-toolchain
-environment variables:
-:term:`CC`\ =i586-poky-linux-gcc -m32
--march=i586 --sysroot=/opt/poky/1.8/sysroots/i586-poky-linux
-:term:`LD`\ =i586-poky-linux-ld
---sysroot=/opt/poky/1.8/sysroots/i586-poky-linux
-:term:`CFLAGS`\ =-O2 -pipe -g
--feliminate-unused-debug-types
-:term:`CXXFLAGS`\ =-O2 -pipe -g
--feliminate-unused-debug-types Now, consider the following three cases:
-
--  *Case 1 - No Variables Set in the ``Makefile``:* Because these
-   variables are not specifically set in the ``Makefile``, the variables
-   retain their values based on the environment.
-
--  *Case 2 - Variables Set in the ``Makefile``:* Specifically setting
-   variables in the ``Makefile`` during the build results in the
-   environment settings of the variables being overwritten.
-
--  *Case 3 - Variables Set when the ``Makefile`` is Executed from the
-   Command Line:* Executing the ``Makefile`` from the command line
-   results in the variables being overwritten with command-line content
-   regardless of what is being set in the ``Makefile``. In this case,
-   environment variables are not considered unless you use the "-e" flag
-   during the build: $ make -e file If you use this flag, then the
-   environment values of the variables override any variables
-   specifically set in the ``Makefile``.
-
-.. note::
-
-   For the list of variables set up by the cross-toolchain environment
-   setup script, see the "
-   Setting Up the Cross-Development Environment
-   " section.
diff --git a/poky/documentation/adt-manual/adt-intro.rst b/poky/documentation/adt-manual/adt-intro.rst
deleted file mode 100644
index 92c157099..000000000
--- a/poky/documentation/adt-manual/adt-intro.rst
+++ /dev/null
@@ -1,138 +0,0 @@
-.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
-
-*****************************************
-The Application Development Toolkit (ADT)
-*****************************************
-
-Part of the Yocto Project development solution is an Application
-Development Toolkit (ADT). The ADT provides you with a custom-built,
-cross-development platform suited for developing a user-targeted product
-application.
-
-Fundamentally, the ADT consists of the following:
-
--  An architecture-specific cross-toolchain and matching sysroot both
-   built by the :term:`OpenEmbedded Build System`.
-   The toolchain and
-   sysroot are based on a `Metadata <&YOCTO_DOCS_DEV_URL;#metadata>`__
-   configuration and extensions, which allows you to cross-develop on
-   the host machine for the target hardware.
-
--  The Eclipse IDE Yocto Plug-in.
-
--  The Quick EMUlator (QEMU), which lets you simulate target hardware.
-
--  Various user-space tools that greatly enhance your application
-   development experience.
-
-The Cross-Development Toolchain
-===============================
-
-The `Cross-Development
-Toolchain <&YOCTO_DOCS_DEV_URL;#cross-development-toolchain>`__ consists
-of a cross-compiler, cross-linker, and cross-debugger that are used to
-develop user-space applications for targeted hardware. This toolchain is
-created either by running the ADT Installer script, a toolchain
-installer script, or through a :term:`Build Directory`
-that is based on
-your Metadata configuration or extension for your targeted device. The
-cross-toolchain works with a matching target sysroot.
-
-Sysroot
-=======
-
-The matching target sysroot contains needed headers and libraries for
-generating binaries that run on the target architecture. The sysroot is
-based on the target root filesystem image that is built by the
-OpenEmbedded build system and uses the same Metadata configuration used
-to build the cross-toolchain.
-
-.. _eclipse-overview:
-
-Eclipse Yocto Plug-in
-=====================
-
-The Eclipse IDE is a popular development environment and it fully
-supports development using the Yocto Project. When you install and
-configure the Eclipse Yocto Project Plug-in into the Eclipse IDE, you
-maximize your Yocto Project experience. Installing and configuring the
-Plug-in results in an environment that has extensions specifically
-designed to let you more easily develop software. These extensions allow
-for cross-compilation, deployment, and execution of your output into a
-QEMU emulation session. You can also perform cross-debugging and
-profiling. The environment also supports a suite of tools that allows
-you to perform remote profiling, tracing, collection of power data,
-collection of latency data, and collection of performance data.
-
-For information about the application development workflow that uses the
-Eclipse IDE and for a detailed example of how to install and configure
-the Eclipse Yocto Project Plug-in, see the "`Working Within
-Eclipse <&YOCTO_DOCS_DEV_URL;#adt-eclipse>`__" section of the Yocto
-Project Development Manual.
-
-The QEMU Emulator
-=================
-
-The QEMU emulator allows you to simulate your hardware while running
-your application or image. QEMU is made available a number of ways:
-
--  If you use the ADT Installer script to install ADT, you can specify
-   whether or not to install QEMU.
-
--  If you have cloned the ``poky`` Git repository to create a
-   :term:`Source Directory` and you have
-   sourced the environment setup script, QEMU is installed and
-   automatically available.
-
--  If you have downloaded a Yocto Project release and unpacked it to
-   create a :term:`Source Directory`
-   and you have sourced the environment setup script, QEMU is installed
-   and automatically available.
-
--  If you have installed the cross-toolchain tarball and you have
-   sourced the toolchain's setup environment script, QEMU is also
-   installed and automatically available.
-
-User-Space Tools
-================
-
-User-space tools are included as part of the Yocto Project. You will
-find these tools helpful during development. The tools include
-LatencyTOP, PowerTOP, OProfile, Perf, SystemTap, and Lttng-ust. These
-tools are common development tools for the Linux platform.
-
--  *LatencyTOP:* LatencyTOP focuses on latency that causes skips in
-   audio, stutters in your desktop experience, or situations that
-   overload your server even when you have plenty of CPU power left.
-
--  *PowerTOP:* Helps you determine what software is using the most
-   power. You can find out more about PowerTOP at
-   https://01.org/powertop/.
-
--  *OProfile:* A system-wide profiler for Linux systems that is capable
-   of profiling all running code at low overhead. You can find out more
-   about OProfile at http://oprofile.sourceforge.net/about/. For
-   examples on how to setup and use this tool, see the
-   "`OProfile <&YOCTO_DOCS_PROF_URL;#profile-manual-oprofile>`__"
-   section in the Yocto Project Profiling and Tracing Manual.
-
--  *Perf:* Performance counters for Linux used to keep track of certain
-   types of hardware and software events. For more information on these
-   types of counters see https://perf.wiki.kernel.org/. For
-   examples on how to setup and use this tool, see the
-   "`perf <&YOCTO_DOCS_PROF_URL;#profile-manual-perf>`__" section in the
-   Yocto Project Profiling and Tracing Manual.
-
--  *SystemTap:* A free software infrastructure that simplifies
-   information gathering about a running Linux system. This information
-   helps you diagnose performance or functional problems. SystemTap is
-   not available as a user-space tool through the Eclipse IDE Yocto
-   Plug-in. See http://sourceware.org/systemtap for more
-   information on SystemTap. For examples on how to setup and use this
-   tool, see the
-   "`SystemTap <&YOCTO_DOCS_PROF_URL;#profile-manual-systemtap>`__"
-   section in the Yocto Project Profiling and Tracing Manual.
-
--  *Lttng-ust:* A User-space Tracer designed to provide detailed
-   information on user-space activity. See http://lttng.org/ust
-   for more information on Lttng-ust.
diff --git a/poky/documentation/adt-manual/adt-manual-intro.rst b/poky/documentation/adt-manual/adt-manual-intro.rst
deleted file mode 100644
index 2c840fdf0..000000000
--- a/poky/documentation/adt-manual/adt-manual-intro.rst
+++ /dev/null
@@ -1,24 +0,0 @@
-.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
-
-************
-Introduction
-************
-
-Welcome to the Yocto Project Application Developer's Guide. This manual
-provides information that lets you begin developing applications using
-the Yocto Project.
-
-The Yocto Project provides an application development environment based
-on an Application Development Toolkit (ADT) and the availability of
-stand-alone cross-development toolchains and other tools. This manual
-describes the ADT and how you can configure and install it, how to
-access and use the cross-development toolchains, how to customize the
-development packages installation, how to use command-line development
-for both Autotools-based and Makefile-based projects, and an
-introduction to the Eclipse IDE Yocto Plug-in.
-
-.. note::
-
-   The ADT is distribution-neutral and does not require the Yocto
-   Project reference distribution, which is called Poky. This manual,
-   however, uses examples that use the Poky distribution.
diff --git a/poky/documentation/adt-manual/adt-manual.rst b/poky/documentation/adt-manual/adt-manual.rst
deleted file mode 100644
index b61f59e0f..000000000
--- a/poky/documentation/adt-manual/adt-manual.rst
+++ /dev/null
@@ -1,17 +0,0 @@
-.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
-
-===========================================
-Yocto Project Application Developer's Guide
-===========================================
-
-|
-
-.. toctree::
-   :caption: Table of Contents
-   :numbered:
-
-   adt-manual-intro
-   adt-intro
-   adt-prepare
-   adt-package
-   adt-command
diff --git a/poky/documentation/adt-manual/adt-package.rst b/poky/documentation/adt-manual/adt-package.rst
deleted file mode 100644
index a722453ec..000000000
--- a/poky/documentation/adt-manual/adt-package.rst
+++ /dev/null
@@ -1,70 +0,0 @@
-.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
-
-************************************************************
-Optionally Customizing the Development Packages Installation
-************************************************************
-
-Because the Yocto Project is suited for embedded Linux development, it
-is likely that you will need to customize your development packages
-installation. For example, if you are developing a minimal image, then
-you might not need certain packages (e.g. graphics support packages).
-Thus, you would like to be able to remove those packages from your
-target sysroot.
-
-Package Management Systems
-==========================
-
-The OpenEmbedded build system supports the generation of sysroot files
-using three different Package Management Systems (PMS):
-
--  *OPKG:* A less well known PMS whose use originated in the
-   OpenEmbedded and OpenWrt embedded Linux projects. This PMS works with
-   files packaged in an ``.ipk`` format. See
-   http://en.wikipedia.org/wiki/Opkg for more information about
-   OPKG.
-
--  *RPM:* A more widely known PMS intended for GNU/Linux distributions.
-   This PMS works with files packaged in an ``.rpm`` format. The build
-   system currently installs through this PMS by default. See
-   http://en.wikipedia.org/wiki/RPM_Package_Manager for more
-   information about RPM.
-
--  *Debian:* The PMS for Debian-based systems is built on many PMS
-   tools. The lower-level PMS tool ``dpkg`` forms the base of the Debian
-   PMS. For information on dpkg see
-   http://en.wikipedia.org/wiki/Dpkg.
-
-Configuring the PMS
-===================
-
-Whichever PMS you are using, you need to be sure that the
-:term:`PACKAGE_CLASSES`
-variable in the ``conf/local.conf`` file is set to reflect that system.
-The first value you choose for the variable specifies the package file
-format for the root filesystem at sysroot. Additional values specify
-additional formats for convenience or testing. See the
-``conf/local.conf`` configuration file for details.
-
-.. note::
-
-   For build performance information related to the PMS, see the "
-   package.bbclass
-   " section in the Yocto Project Reference Manual.
-
-As an example, consider a scenario where you are using OPKG and you want
-to add the ``libglade`` package to the target sysroot.
-
-First, you should generate the IPK file for the ``libglade`` package and
-add it into a working ``opkg`` repository. Use these commands: $ bitbake
-libglade $ bitbake package-index
-
-Next, source the cross-toolchain environment setup script found in the
-:term:`Source Directory`. Follow
-that by setting up the installation destination to point to your sysroot
-as sysroot_dir. Finally, have an OPKG configuration file conf_file that
-corresponds to the ``opkg`` repository you have just created. The
-following command forms should now work: $ opkg-cl –f conf_file -o
-sysroot_dir update $ opkg-cl –f cconf_file -o sysroot_dir \\
---force-overwrite install libglade $ opkg-cl –f cconf_file -o
-sysroot_dir \\ --force-overwrite install libglade-dbg $ opkg-cl –f
-conf_file> -osysroot_dir> \\ --force-overwrite install libglade-dev
diff --git a/poky/documentation/adt-manual/adt-prepare.rst b/poky/documentation/adt-manual/adt-prepare.rst
deleted file mode 100644
index 3e5c6ae94..000000000
--- a/poky/documentation/adt-manual/adt-prepare.rst
+++ /dev/null
@@ -1,752 +0,0 @@
-.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
-
-*************************************
-Preparing for Application Development
-*************************************
-
-In order to develop applications, you need set up your host development
-system. Several ways exist that allow you to install cross-development
-tools, QEMU, the Eclipse Yocto Plug-in, and other tools. This chapter
-describes how to prepare for application development.
-
-.. _installing-the-adt:
-
-Installing the ADT and Toolchains
-=================================
-
-The following list describes installation methods that set up varying
-degrees of tool availability on your system. Regardless of the
-installation method you choose, you must ``source`` the cross-toolchain
-environment setup script, which establishes several key environment
-variables, before you use a toolchain. See the "`Setting Up the
-Cross-Development
-Environment <#setting-up-the-cross-development-environment>`__" section
-for more information.
-
-.. note::
-
-   Avoid mixing installation methods when installing toolchains for
-   different architectures. For example, avoid using the ADT Installer
-   to install some toolchains and then hand-installing cross-development
-   toolchains by running the toolchain installer for different
-   architectures. Mixing installation methods can result in situations
-   where the ADT Installer becomes unreliable and might not install the
-   toolchain.
-
-   If you must mix installation methods, you might avoid problems by
-   deleting ``/var/lib/opkg``, thus purging the ``opkg`` package
-   metadata.
-
--  *Use the ADT installer script:* This method is the recommended way to
-   install the ADT because it automates much of the process for you. For
-   example, you can configure the installation to install the QEMU
-   emulator and the user-space NFS, specify which root filesystem
-   profiles to download, and define the target sysroot location.
-
--  *Use an existing toolchain:* Using this method, you select and
-   download an architecture-specific toolchain installer and then run
-   the script to hand-install the toolchain. If you use this method, you
-   just get the cross-toolchain and QEMU - you do not get any of the
-   other mentioned benefits had you run the ADT Installer script.
-
--  *Use the toolchain from within the Build Directory:* If you already
-   have a :term:`Build Directory`,
-   you can build the cross-toolchain within the directory. However, like
-   the previous method mentioned, you only get the cross-toolchain and
-   QEMU - you do not get any of the other benefits without taking
-   separate steps.
-
-Using the ADT Installer
------------------------
-
-To run the ADT Installer, you need to get the ADT Installer tarball, be
-sure you have the necessary host development packages that support the
-ADT Installer, and then run the ADT Installer Script.
-
-For a list of the host packages needed to support ADT installation and
-use, see the "ADT Installer Extras" lists in the "`Required Packages for
-the Host Development
-System <&YOCTO_DOCS_REF_URL;#required-packages-for-the-host-development-system>`__"
-section of the Yocto Project Reference Manual.
-
-Getting the ADT Installer Tarball
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The ADT Installer is contained in the ADT Installer tarball. You can get
-the tarball using either of these methods:
-
--  *Download the Tarball:* You can download the tarball from
-   ` <&YOCTO_ADTINSTALLER_DL_URL;>`__ into any directory.
-
--  *Build the Tarball:* You can use
-   :term:`BitBake` to generate the
-   tarball inside an existing :term:`Build Directory`.
-
-   If you use BitBake to generate the ADT Installer tarball, you must
-   ``source`` the environment setup script
-   (````` <&YOCTO_DOCS_REF_URL;#structure-core-script>`__ or
-   ```oe-init-build-env-memres`` <&YOCTO_DOCS_REF_URL;#structure-memres-core-script>`__)
-   located in the Source Directory before running the ``bitbake``
-   command that creates the tarball.
-
-   The following example commands establish the
-   :term:`Source Directory`, check out the
-   current release branch, set up the build environment while also
-   creating the default Build Directory, and run the ``bitbake`` command
-   that results in the tarball
-   ``poky/build/tmp/deploy/sdk/adt_installer.tar.bz2``:
-
-   .. note::
-
-      Before using BitBake to build the ADT tarball, be sure to make
-      sure your
-      local.conf
-      file is properly configured. See the "
-      User Configuration
-      " section in the Yocto Project Reference Manual for general
-      configuration information.
-
-   $ cd ~ $ git clone git://git.yoctoproject.org/poky $ cd poky $ git
-   checkout -b DISTRO_NAME origin/DISTRO_NAME $ source oe-init-build-env $
-   bitbake adt-installer
-
-Configuring and Running the ADT Installer Script
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Before running the ADT Installer script, you need to unpack the tarball.
-You can unpack the tarball in any directory you wish. For example, this
-command copies the ADT Installer tarball from where it was built into
-the home directory and then unpacks the tarball into a top-level
-directory named ``adt-installer``: $ cd ~ $ cp
-poky/build/tmp/deploy/sdk/adt_installer.tar.bz2 $HOME $ tar -xjf
-adt_installer.tar.bz2 Unpacking it creates the directory
-``adt-installer``, which contains the ADT Installer script
-(``adt_installer``) and its configuration file (``adt_installer.conf``).
-
-Before you run the script, however, you should examine the ADT Installer
-configuration file and be sure you are going to get what you want. Your
-configurations determine which kernel and filesystem image are
-downloaded.
-
-The following list describes the configurations you can define for the
-ADT Installer. For configuration values and restrictions, see the
-comments in the ``adt-installer.conf`` file:
-
--  ``YOCTOADT_REPO``: This area includes the IPKG-based packages and the
-   root filesystem upon which the installation is based. If you want to
-   set up your own IPKG repository pointed to by ``YOCTOADT_REPO``, you
-   need to be sure that the directory structure follows the same layout
-   as the reference directory set up at
-   http://adtrepo.yoctoproject.org. Also, your repository needs
-   to be accessible through HTTP.
-
--  ``YOCTOADT_TARGETS``: The machine target architectures for which you
-   want to set up cross-development environments.
-
--  ``YOCTOADT_QEMU``: Indicates whether or not to install the emulator
-   QEMU.
-
--  ``YOCTOADT_NFS_UTIL``: Indicates whether or not to install user-mode
-   NFS. If you plan to use the Eclipse IDE Yocto plug-in against QEMU,
-   you should install NFS.
-
-   .. note::
-
-      To boot QEMU images using our userspace NFS server, you need to be
-      running
-      portmap
-      or
-      rpcbind
-      . If you are running
-      rpcbind
-      , you will also need to add the
-      -i
-      option when
-      rpcbind
-      starts up. Please make sure you understand the security
-      implications of doing this. You might also have to modify your
-      firewall settings to allow NFS booting to work.
-
--  ``YOCTOADT_ROOTFS_``\ arch: The root filesystem images you want to
-   download from the ``YOCTOADT_IPKG_REPO`` repository.
-
--  ``YOCTOADT_TARGET_SYSROOT_IMAGE_``\ arch: The particular root
-   filesystem used to extract and create the target sysroot. The value
-   of this variable must have been specified with
-   ``YOCTOADT_ROOTFS_``\ arch. For example, if you downloaded both
-   ``minimal`` and ``sato-sdk`` images by setting
-   ``YOCTOADT_ROOTFS_``\ arch to "minimal sato-sdk", then
-   ``YOCTOADT_ROOTFS_``\ arch must be set to either "minimal" or
-   "sato-sdk".
-
--  ``YOCTOADT_TARGET_SYSROOT_LOC_``\ arch: The location on the
-   development host where the target sysroot is created.
-
-After you have configured the ``adt_installer.conf`` file, run the
-installer using the following command: $ cd adt-installer $
-./adt_installer Once the installer begins to run, you are asked to enter
-the location for cross-toolchain installation. The default location is
-``/opt/poky/``\ release. After either accepting the default location or
-selecting your own location, you are prompted to run the installation
-script interactively or in silent mode. If you want to closely monitor
-the installation, choose "I" for interactive mode rather than "S" for
-silent mode. Follow the prompts from the script to complete the
-installation.
-
-Once the installation completes, the ADT, which includes the
-cross-toolchain, is installed in the selected installation directory.
-You will notice environment setup files for the cross-toolchain in the
-installation directory, and image tarballs in the ``adt-installer``
-directory according to your installer configurations, and the target
-sysroot located according to the ``YOCTOADT_TARGET_SYSROOT_LOC_``\ arch
-variable also in your configuration file.
-
-.. _using-an-existing-toolchain-tarball:
-
-Using a Cross-Toolchain Tarball
--------------------------------
-
-If you want to simply install a cross-toolchain by hand, you can do so
-by running the toolchain installer. The installer includes the pre-built
-cross-toolchain, the ``runqemu`` script, and support files. If you use
-this method to install the cross-toolchain, you might still need to
-install the target sysroot by installing and extracting it separately.
-For information on how to install the sysroot, see the "`Extracting the
-Root Filesystem <#extracting-the-root-filesystem>`__" section.
-
-Follow these steps:
-
-1. *Get your toolchain installer using one of the following methods:*
-
-   -  Go to ` <&YOCTO_TOOLCHAIN_DL_URL;>`__ and find the folder that
-      matches your host development system (i.e. ``i686`` for 32-bit
-      machines or ``x86_64`` for 64-bit machines).
-
-      Go into that folder and download the toolchain installer whose
-      name includes the appropriate target architecture. The toolchains
-      provided by the Yocto Project are based off of the
-      ``core-image-sato`` image and contain libraries appropriate for
-      developing against that image. For example, if your host
-      development system is a 64-bit x86 system and you are going to use
-      your cross-toolchain for a 32-bit x86 target, go into the
-      ``x86_64`` folder and download the following installer:
-      poky-glibc-x86_64-core-image-sato-i586-toolchain-DISTRO.sh
-
-   -  Build your own toolchain installer. For cases where you cannot use
-      an installer from the download area, you can build your own as
-      described in the "`Optionally Building a Toolchain
-      Installer <#optionally-building-a-toolchain-installer>`__"
-      section.
-
-2. *Once you have the installer, run it to install the toolchain:*
-
-   .. note::
-
-      You must change the permissions on the toolchain installer script
-      so that it is executable.
-
-   The following command shows how to run the installer given a
-   toolchain tarball for a 64-bit x86 development host system and a
-   32-bit x86 target architecture. The example assumes the toolchain
-   installer is located in ``~/Downloads/``. $
-   ~/Downloads/poky-glibc-x86_64-core-image-sato-i586-toolchain-DISTRO.sh
-   The first thing the installer prompts you for is the directory into
-   which you want to install the toolchain. The default directory used
-   is ``/opt/poky/DISTRO``. If you do not have write permissions for the
-   directory into which you are installing the toolchain, the toolchain
-   installer notifies you and exits. Be sure you have write permissions
-   in the directory and run the installer again.
-
-   When the script finishes, the cross-toolchain is installed. You will
-   notice environment setup files for the cross-toolchain in the
-   installation directory.
-
-.. _using-the-toolchain-from-within-the-build-tree:
-
-Using BitBake and the Build Directory
--------------------------------------
-
-A final way of making the cross-toolchain available is to use BitBake to
-generate the toolchain within an existing :term:`Build Directory`.
-This method does
-not install the toolchain into the default ``/opt`` directory. As with
-the previous method, if you need to install the target sysroot, you must
-do that separately as well.
-
-Follow these steps to generate the toolchain into the Build Directory:
-
-1. *Set up the Build Environment:* Source the OpenEmbedded build
-   environment setup script (i.e.
-   ````` <&YOCTO_DOCS_REF_URL;#structure-core-script>`__ or
-   ```oe-init-build-env-memres`` <&YOCTO_DOCS_REF_URL;#structure-memres-core-script>`__)
-   located in the :term:`Source Directory`.
-
-2. *Check your Local Configuration File:* At this point, you should be
-   sure that the :term:`MACHINE`
-   variable in the ``local.conf`` file found in the ``conf`` directory
-   of the Build Directory is set for the target architecture. Comments
-   within the ``local.conf`` file list the values you can use for the
-   ``MACHINE`` variable. If you do not change the ``MACHINE`` variable,
-   the OpenEmbedded build system uses ``qemux86`` as the default target
-   machine when building the cross-toolchain.
-
-   .. note::
-
-      You can populate the Build Directory with the cross-toolchains for
-      more than a single architecture. You just need to edit the
-      MACHINE
-      variable in the
-      local.conf
-      file and re-run the
-      bitbake
-      command.
-
-3. *Make Sure Your Layers are Enabled:* Examine the
-   ``conf/bblayers.conf`` file and make sure that you have enabled all
-   the compatible layers for your target machine. The OpenEmbedded build
-   system needs to be aware of each layer you want included when
-   building images and cross-toolchains. For information on how to
-   enable a layer, see the "`Enabling Your
-   Layer <&YOCTO_DOCS_DEV_URL;#enabling-your-layer>`__" section in the
-   Yocto Project Development Manual.
-
-4. *Generate the Cross-Toolchain:* Run ``bitbake meta-ide-support`` to
-   complete the cross-toolchain generation. Once the ``bitbake`` command
-   finishes, the cross-toolchain is generated and populated within the
-   Build Directory. You will notice environment setup files for the
-   cross-toolchain that contain the string "``environment-setup``" in
-   the Build Directory's ``tmp`` folder.
-
-   Be aware that when you use this method to install the toolchain, you
-   still need to separately extract and install the sysroot filesystem.
-   For information on how to do this, see the "`Extracting the Root
-   Filesystem <#extracting-the-root-filesystem>`__" section.
-
-Setting Up the Cross-Development Environment
-============================================
-
-Before you can develop using the cross-toolchain, you need to set up the
-cross-development environment by sourcing the toolchain's environment
-setup script. If you used the ADT Installer or hand-installed
-cross-toolchain, then you can find this script in the directory you
-chose for installation. For this release, the default installation
-directory is ````. If you installed the toolchain in the
-:term:`Build Directory`, you can find the
-environment setup script for the toolchain in the Build Directory's
-``tmp`` directory.
-
-Be sure to run the environment setup script that matches the
-architecture for which you are developing. Environment setup scripts
-begin with the string "``environment-setup``" and include as part of
-their name the architecture. For example, the toolchain environment
-setup script for a 64-bit IA-based architecture installed in the default
-installation directory would be the following:
-YOCTO_ADTPATH_DIR/environment-setup-x86_64-poky-linux When you run the
-setup script, many environment variables are defined:
-:term:`SDKTARGETSYSROOT` -
-The path to the sysroot used for cross-compilation
-:term:`PKG_CONFIG_PATH` - The
-path to the target pkg-config files
-:term:`CONFIG_SITE` - A GNU
-autoconf site file preconfigured for the target
-:term:`CC` - The minimal command and
-arguments to run the C compiler
-:term:`CXX` - The minimal command and
-arguments to run the C++ compiler
-:term:`CPP` - The minimal command and
-arguments to run the C preprocessor
-:term:`AS` - The minimal command and
-arguments to run the assembler :term:`LD`
-- The minimal command and arguments to run the linker
-:term:`GDB` - The minimal command and
-arguments to run the GNU Debugger
-:term:`STRIP` - The minimal command and
-arguments to run 'strip', which strips symbols
-:term:`RANLIB` - The minimal command
-and arguments to run 'ranlib'
-:term:`OBJCOPY` - The minimal command
-and arguments to run 'objcopy'
-:term:`OBJDUMP` - The minimal command
-and arguments to run 'objdump' :term:`AR`
-- The minimal command and arguments to run 'ar'
-:term:`NM` - The minimal command and
-arguments to run 'nm'
-:term:`TARGET_PREFIX` - The
-toolchain binary prefix for the target tools
-:term:`CROSS_COMPILE` - The
-toolchain binary prefix for the target tools
-:term:`CONFIGURE_FLAGS` - The
-minimal arguments for GNU configure
-:term:`CFLAGS` - Suggested C flags
-:term:`CXXFLAGS` - Suggested C++
-flags :term:`LDFLAGS` - Suggested
-linker flags when you use CC to link
-:term:`CPPFLAGS` - Suggested
-preprocessor flags
-
-Securing Kernel and Filesystem Images
-=====================================
-
-You will need to have a kernel and filesystem image to boot using your
-hardware or the QEMU emulator. Furthermore, if you plan on booting your
-image using NFS or you want to use the root filesystem as the target
-sysroot, you need to extract the root filesystem.
-
-Getting the Images
-------------------
-
-To get the kernel and filesystem images, you either have to build them
-or download pre-built versions. For an example of how to build these
-images, see the "`Buiding
-Images <&YOCTO_DOCS_QS_URL;#qs-buiding-images>`__" section of the Yocto
-Project Quick Start. For an example of downloading pre-build versions,
-see the "`Example Using Pre-Built Binaries and
-QEMU <#using-pre-built>`__" section.
-
-The Yocto Project ships basic kernel and filesystem images for several
-architectures (``x86``, ``x86-64``, ``mips``, ``powerpc``, and ``arm``)
-that you can use unaltered in the QEMU emulator. These kernel images
-reside in the release area - ` <&YOCTO_MACHINES_DL_URL;>`__ and are
-ideal for experimentation using Yocto Project. For information on the
-image types you can build using the OpenEmbedded build system, see the
-":ref:`ref-manual/ref-images:Images`" chapter in the Yocto
-Project Reference Manual.
-
-If you are planning on developing against your image and you are not
-building or using one of the Yocto Project development images (e.g.
-``core-image-*-dev``), you must be sure to include the development
-packages as part of your image recipe.
-
-If you plan on remotely deploying and debugging your application from
-within the Eclipse IDE, you must have an image that contains the Yocto
-Target Communication Framework (TCF) agent (``tcf-agent``). You can do
-this by including the ``eclipse-debug`` image feature.
-
-.. note::
-
-   See the "
-   Image Features
-   " section in the Yocto Project Reference Manual for information on
-   image features.
-
-To include the ``eclipse-debug`` image feature, modify your
-``local.conf`` file in the :term:`Build Directory`
-so that the
-:term:`EXTRA_IMAGE_FEATURES`
-variable includes the "eclipse-debug" feature. After modifying the
-configuration file, you can rebuild the image. Once the image is
-rebuilt, the ``tcf-agent`` will be included in the image and is launched
-automatically after the boot.
-
-Extracting the Root Filesystem
-------------------------------
-
-If you install your toolchain by hand or build it using BitBake and you
-need a root filesystem, you need to extract it separately. If you use
-the ADT Installer to install the ADT, the root filesystem is
-automatically extracted and installed.
-
-Here are some cases where you need to extract the root filesystem:
-
--  You want to boot the image using NFS.
-
--  You want to use the root filesystem as the target sysroot. For
-   example, the Eclipse IDE environment with the Eclipse Yocto Plug-in
-   installed allows you to use QEMU to boot under NFS.
-
--  You want to develop your target application using the root filesystem
-   as the target sysroot.
-
-To extract the root filesystem, first ``source`` the cross-development
-environment setup script to establish necessary environment variables.
-If you built the toolchain in the Build Directory, you will find the
-toolchain environment script in the ``tmp`` directory. If you installed
-the toolchain by hand, the environment setup script is located in
-``/opt/poky/DISTRO``.
-
-After sourcing the environment script, use the ``runqemu-extract-sdk``
-command and provide the filesystem image.
-
-Following is an example. The second command sets up the environment. In
-this case, the setup script is located in the ``/opt/poky/DISTRO``
-directory. The third command extracts the root filesystem from a
-previously built filesystem that is located in the ``~/Downloads``
-directory. Furthermore, this command extracts the root filesystem into
-the ``qemux86-sato`` directory: $ cd ~ $ source
-/opt/poky/DISTRO/environment-setup-i586-poky-linux $ runqemu-extract-sdk
-\\ ~/Downloads/core-image-sato-sdk-qemux86-2011091411831.rootfs.tar.bz2
-\\ $HOME/qemux86-sato You could now point to the target sysroot at
-``qemux86-sato``.
-
-Optionally Building a Toolchain Installer
-=========================================
-
-As an alternative to locating and downloading a toolchain installer, you
-can build the toolchain installer if you have a :term:`Build Directory`.
-
-.. note::
-
-   Although not the preferred method, it is also possible to use
-   bitbake meta-toolchain
-   to build the toolchain installer. If you do use this method, you must
-   separately install and extract the target sysroot. For information on
-   how to install the sysroot, see the "
-   Extracting the Root Filesystem
-   " section.
-
-To build the toolchain installer and populate the SDK image, use the
-following command: $ bitbake image -c populate_sdk The command results
-in a toolchain installer that contains the sysroot that matches your
-target root filesystem.
-
-Another powerful feature is that the toolchain is completely
-self-contained. The binaries are linked against their own copy of
-``libc``, which results in no dependencies on the target system. To
-achieve this, the pointer to the dynamic loader is configured at install
-time since that path cannot be dynamically altered. This is the reason
-for a wrapper around the ``populate_sdk`` archive.
-
-Another feature is that only one set of cross-canadian toolchain
-binaries are produced per architecture. This feature takes advantage of
-the fact that the target hardware can be passed to ``gcc`` as a set of
-compiler options. Those options are set up by the environment script and
-contained in variables such as :term:`CC`
-and :term:`LD`. This reduces the space
-needed for the tools. Understand, however, that a sysroot is still
-needed for every target since those binaries are target-specific.
-
-Remember, before using any BitBake command, you must source the build
-environment setup script (i.e.
-````` <&YOCTO_DOCS_REF_URL;#structure-core-script>`__ or
-```oe-init-build-env-memres`` <&YOCTO_DOCS_REF_URL;#structure-memres-core-script>`__)
-located in the Source Directory and you must make sure your
-``conf/local.conf`` variables are correct. In particular, you need to be
-sure the :term:`MACHINE` variable
-matches the architecture for which you are building and that the
-:term:`SDKMACHINE` variable is
-correctly set if you are building a toolchain designed to run on an
-architecture that differs from your current development host machine
-(i.e. the build machine).
-
-When the ``bitbake`` command completes, the toolchain installer will be
-in ``tmp/deploy/sdk`` in the Build Directory.
-
-.. note::
-
-   By default, this toolchain does not build static binaries. If you
-   want to use the toolchain to build these types of libraries, you need
-   to be sure your image has the appropriate static development
-   libraries. Use the
-   IMAGE_INSTALL
-   variable inside your
-   local.conf
-   file to install the appropriate library packages. Following is an
-   example using
-   glibc
-   static development libraries:
-   ::
-
-           IMAGE_INSTALL_append = " glibc-staticdev"
-                  
-
-Optionally Using an External Toolchain
-======================================
-
-You might want to use an external toolchain as part of your development.
-If this is the case, the fundamental steps you need to accomplish are as
-follows:
-
--  Understand where the installed toolchain resides. For cases where you
-   need to build the external toolchain, you would need to take separate
-   steps to build and install the toolchain.
-
--  Make sure you add the layer that contains the toolchain to your
-   ``bblayers.conf`` file through the
-   :term:`BBLAYERS` variable.
-
--  Set the
-   :term:`EXTERNAL_TOOLCHAIN`
-   variable in your ``local.conf`` file to the location in which you
-   installed the toolchain.
-
-A good example of an external toolchain used with the Yocto Project is
-Mentor Graphics Sourcery G++ Toolchain. You can see information on how
-to use that particular layer in the ``README`` file at
-http://github.com/MentorEmbedded/meta-sourcery/. You can find
-further information by reading about the
-:term:`TCMODE` variable in the Yocto
-Project Reference Manual's variable glossary.
-
-.. _using-pre-built:
-
-Example Using Pre-Built Binaries and QEMU
-=========================================
-
-If hardware, libraries and services are stable, you can get started by
-using a pre-built binary of the filesystem image, kernel, and toolchain
-and run it using the QEMU emulator. This scenario is useful for
-developing application software.
-
-|Using a Pre-Built Image|
-
-For this scenario, you need to do several things:
-
--  Install the appropriate stand-alone toolchain tarball.
-
--  Download the pre-built image that will boot with QEMU. You need to be
-   sure to get the QEMU image that matches your target machine's
-   architecture (e.g. x86, ARM, etc.).
-
--  Download the filesystem image for your target machine's architecture.
-
--  Set up the environment to emulate the hardware and then start the
-   QEMU emulator.
-
-Installing the Toolchain
-------------------------
-
-You can download a tarball installer, which includes the pre-built
-toolchain, the ``runqemu`` script, and support files from the
-appropriate directory under ` <&YOCTO_TOOLCHAIN_DL_URL;>`__. Toolchains
-are available for 32-bit and 64-bit x86 development systems from the
-``i686`` and ``x86_64`` directories, respectively. The toolchains the
-Yocto Project provides are based off the ``core-image-sato`` image and
-contain libraries appropriate for developing against that image. Each
-type of development system supports five or more target architectures.
-
-The names of the tarball installer scripts are such that a string
-representing the host system appears first in the filename and then is
-immediately followed by a string representing the target architecture.
-
-::
-
-        poky-glibc-host_system-image_type-arch-toolchain-release_version.sh
-
-        Where:
-            host_system is a string representing your development system:
-
-                       i686 or x86_64.
-
-            image_type is a string representing the image you wish to
-                   develop a Software Development Toolkit (SDK) for use against.
-                   The Yocto Project builds toolchain installers using the
-                   following BitBake command:
-
-                       bitbake core-image-sato -c populate_sdk
-
-            arch is a string representing the tuned target architecture:
-
-                       i586, x86_64, powerpc, mips, armv7a or armv5te
-
-            release_version is a string representing the release number of the
-                   Yocto Project:
-
-                       DISTRO, DISTRO+snapshot
-               
-
-For example, the following toolchain installer is for a 64-bit
-development host system and a i586-tuned target architecture based off
-the SDK for ``core-image-sato``:
-poky-glibc-x86_64-core-image-sato-i586-toolchain-DISTRO.sh
-
-Toolchains are self-contained and by default are installed into
-``/opt/poky``. However, when you run the toolchain installer, you can
-choose an installation directory.
-
-The following command shows how to run the installer given a toolchain
-tarball for a 64-bit x86 development host system and a 32-bit x86 target
-architecture. You must change the permissions on the toolchain installer
-script so that it is executable.
-
-The example assumes the toolchain installer is located in
-``~/Downloads/``.
-
-.. note::
-
-   If you do not have write permissions for the directory into which you
-   are installing the toolchain, the toolchain installer notifies you
-   and exits. Be sure you have write permissions in the directory and
-   run the installer again.
-
-$ ~/Downloads/poky-glibc-x86_64-core-image-sato-i586-toolchain-DISTRO.sh
-
-For more information on how to install tarballs, see the "`Using a
-Cross-Toolchain
-Tarball <&YOCTO_DOCS_ADT_URL;#using-an-existing-toolchain-tarball>`__"
-and "`Using BitBake and the Build
-Directory <&YOCTO_DOCS_ADT_URL;#using-the-toolchain-from-within-the-build-tree>`__"
-sections in the Yocto Project Application Developer's Guide.
-
-Downloading the Pre-Built Linux Kernel
---------------------------------------
-
-You can download the pre-built Linux kernel suitable for running in the
-QEMU emulator from ` <&YOCTO_QEMU_DL_URL;>`__. Be sure to use the kernel
-that matches the architecture you want to simulate. Download areas exist
-for the five supported machine architectures: ``qemuarm``, ``qemumips``,
-``qemuppc``, ``qemux86``, and ``qemux86-64``.
-
-Most kernel files have one of the following forms: \*zImage-qemuarch.bin
-vmlinux-qemuarch.bin Where: arch is a string representing the target
-architecture: x86, x86-64, ppc, mips, or arm.
-
-You can learn more about downloading a Yocto Project kernel in the
-"`Yocto Project Kernel <&YOCTO_DOCS_DEV_URL;#local-kernel-files>`__"
-bulleted item in the Yocto Project Development Manual.
-
-Downloading the Filesystem
---------------------------
-
-You can also download the filesystem image suitable for your target
-architecture from ` <&YOCTO_QEMU_DL_URL;>`__. Again, be sure to use the
-filesystem that matches the architecture you want to simulate.
-
-The filesystem image has two tarball forms: ``ext3`` and ``tar``. You
-must use the ``ext3`` form when booting an image using the QEMU
-emulator. The ``tar`` form can be flattened out in your host development
-system and used for build purposes with the Yocto Project.
-core-image-profile-qemuarch.ext3 core-image-profile-qemuarch.tar.bz2
-Where: profile is the filesystem image's profile: lsb, lsb-dev, lsb-sdk,
-lsb-qt3, minimal, minimal-dev, sato, sato-dev, or sato-sdk. For
-information on these types of image profiles, see the
-":ref:`ref-manual/ref-images:Images`" chapter in the Yocto
-Project Reference Manual. arch is a string representing the target
-architecture: x86, x86-64, ppc, mips, or arm.
-
-Setting Up the Environment and Starting the QEMU Emulator
----------------------------------------------------------
-
-Before you start the QEMU emulator, you need to set up the emulation
-environment. The following command form sets up the emulation
-environment. $ source
-YOCTO_ADTPATH_DIR/environment-setup-arch-poky-linux-if Where: arch is a
-string representing the target architecture: i586, x86_64, ppc603e,
-mips, or armv5te. if is a string representing an embedded application
-binary interface. Not all setup scripts include this string.
-
-Finally, this command form invokes the QEMU emulator $ runqemu qemuarch
-kernel-image filesystem-image Where: qemuarch is a string representing
-the target architecture: qemux86, qemux86-64, qemuppc, qemumips, or
-qemuarm. kernel-image is the architecture-specific kernel image.
-filesystem-image is the .ext3 filesystem image.
-
-Continuing with the example, the following two commands setup the
-emulation environment and launch QEMU. This example assumes the root
-filesystem (``.ext3`` file) and the pre-built kernel image file both
-reside in your home directory. The kernel and filesystem are for a
-32-bit target architecture. $ cd $HOME $ source
-YOCTO_ADTPATH_DIR/environment-setup-i586-poky-linux $ runqemu qemux86
-bzImage-qemux86.bin \\ core-image-sato-qemux86.ext3
-
-The environment in which QEMU launches varies depending on the
-filesystem image and on the target architecture. For example, if you
-source the environment for the ARM target architecture and then boot the
-minimal QEMU image, the emulator comes up in a new shell in command-line
-mode. However, if you boot the SDK image, QEMU comes up with a GUI.
-
-.. note::
-
-   Booting the PPC image results in QEMU launching in the same shell in
-   command-line mode.
-
-.. |Using a Pre-Built Image| image:: figures/using-a-pre-built-image.png
diff --git a/poky/documentation/adt-manual/figures/adt-title.png b/poky/documentation/adt-manual/figures/adt-title.png
deleted file mode 100644
index 6e71e41f1..000000000
--- a/poky/documentation/adt-manual/figures/adt-title.png
+++ /dev/null
diff --git a/poky/documentation/adt-manual/figures/using-a-pre-built-image.png b/poky/documentation/adt-manual/figures/using-a-pre-built-image.png
deleted file mode 100644
index b03130d12..000000000
--- a/poky/documentation/adt-manual/figures/using-a-pre-built-image.png
+++ /dev/null
diff --git a/poky/documentation/bsp-guide/bsp.rst b/poky/documentation/bsp-guide/bsp.rst
index d0275eea9..408620212 100644
--- a/poky/documentation/bsp-guide/bsp.rst
+++ b/poky/documentation/bsp-guide/bsp.rst
@@ -241,8 +241,6 @@ section.
    the script runs, your current working directory is set to the ``build``
    directory.
 
-.. _bsp-filelayout:
-
 Example Filesystem Layout
 =========================
 
@@ -451,8 +449,6 @@ the :yocto_git:`Source Respositories <>`:
 
 The following sections describe each part of the proposed BSP format.
 
-.. _bsp-filelayout-license:
-
 License Files
 -------------
 
@@ -471,8 +467,6 @@ developer. For information on how to maintain license compliance, see
 the ":ref:`dev-manual/dev-manual-common-tasks:maintaining open source license compliance during your product's lifecycle`"
 section in the Yocto Project Development Tasks Manual.
 
-.. _bsp-filelayout-readme:
-
 README File
 -----------
 
@@ -488,8 +482,6 @@ At a minimum, the ``README`` file must contain a list of dependencies,
 such as the names of any other layers on which the BSP depends and the
 name of the BSP maintainer with his or her contact information.
 
-.. _bsp-filelayout-readme-sources:
-
 README.sources File
 -------------------
 
@@ -509,8 +501,6 @@ used to generate the images that ship with the BSP.
    If the BSP's ``binary`` directory is missing or the directory has no images, an
    existing ``README.sources`` file is meaningless and usually does not exist.
 
-.. _bsp-filelayout-binary:
-
 Pre-built User Binaries
 -----------------------
 
@@ -534,8 +524,6 @@ hardware. Additionally, the
 present to locate the sources used to build the images and provide
 information on the Metadata.
 
-.. _bsp-filelayout-layer:
-
 Layer Configuration File
 ------------------------
 
@@ -586,8 +574,6 @@ This file simply makes :term:`BitBake` aware of the recipes and configuration
 directories. The file must exist so that the OpenEmbedded build system can
 recognize the BSP.
 
-.. _bsp-filelayout-machine:
-
 Hardware Configuration Options
 ------------------------------
 
@@ -626,8 +612,6 @@ configuration file. For example, the Raspberry Pi BSP
 
    include conf/machine/include/rpi-base.inc
 
-.. _bsp-filelayout-misc-recipes:
-
 Miscellaneous BSP-Specific Recipe Files
 ---------------------------------------
 
@@ -658,8 +642,6 @@ directory. Here is the ``machconfig`` file for the Raspberry Pi BSP: ::
    ``meta/recipes-bsp/formfactor/formfactor_0.0.bb``, which is found in
    the :term:`Source Directory`.
 
-.. _bsp-filelayout-recipes-graphics:
-
 Display Support Files
 ---------------------
 
@@ -671,8 +653,6 @@ This optional directory contains recipes for the BSP if it has special
 requirements for graphics support. All files that are needed for the BSP
 to support a display are kept here.
 
-.. _bsp-filelayout-kernel:
-
 Linux Kernel Configuration
 --------------------------
 
diff --git a/poky/documentation/conf.py b/poky/documentation/conf.py
index ebc26aa3b..96118abec 100644
--- a/poky/documentation/conf.py
+++ b/poky/documentation/conf.py
@@ -53,8 +53,7 @@ templates_path = ['_templates']
 # List of patterns, relative to source directory, that match files and
 # directories to ignore when looking for source files.
 # This pattern also affects html_static_path and html_extra_path.
-exclude_patterns = ['_build', 'Thumbs.db', '.DS_Store', 'boilerplate.rst',
-                    'adt-manual/*.rst']
+exclude_patterns = ['_build', 'Thumbs.db', '.DS_Store', 'boilerplate.rst']
 
 # master document name. The default changed from contents to index. so better
 # set it ourselves.
@@ -79,6 +78,7 @@ extlinks = {
     'yocto_git': ('https://git.yoctoproject.org%s', None),
     'oe_home': ('https://www.openembedded.org%s', None),
     'oe_lists': ('https://lists.openembedded.org%s', None),
+    'oe_git': ('https://git.openembedded.org%s', None),
 }
 
 # Intersphinx config to use cross reference with Bitbake user manual
@@ -125,3 +125,8 @@ html_last_updated_fmt = '%b %d, %Y'
 
 # Remove the trailing 'dot' in section numbers
 html_secnumber_suffix = " "
+
+latex_elements = {
+    'passoptionstopackages': '\PassOptionsToPackage{bookmarksdepth=5}{hyperref}',
+    'preamble': '\setcounter{tocdepth}{2}',
+}
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
 =====================
diff --git a/poky/documentation/kernel-dev/kernel-dev-advanced.rst b/poky/documentation/kernel-dev/kernel-dev-advanced.rst
index 444037c3a..ca049316e 100644
--- a/poky/documentation/kernel-dev/kernel-dev-advanced.rst
+++ b/poky/documentation/kernel-dev/kernel-dev-advanced.rst
@@ -4,8 +4,6 @@
 Working with Advanced Metadata (``yocto-kernel-cache``)
 *******************************************************
 
-.. _kernel-dev-advanced-overview:
-
 Overview
 ========
 
@@ -245,7 +243,7 @@ two files: ``smp.scc`` and ``smp.cfg``. You can find these files in the
       CONFIG_X86_BIGSMP=y
 
 You can find general information on configuration
-fragment files in the ":ref:`creating-config-fragments`" section.
+fragment files in the ":ref:`kernel-dev/kernel-dev-common:creating configuration fragments`" section.
 
 Within the ``smp.scc`` file, the
 :term:`KFEATURE_DESCRIPTION`
@@ -478,8 +476,6 @@ concepts, and presents a detailed example using a BSP supported by the
 Yocto Project (i.e. BeagleBone Board). For complete information on BSP
 layer file hierarchy, see the :doc:`../bsp-guide/bsp-guide`.
 
-.. _bsp-description-file-overview:
-
 Description Overview
 ~~~~~~~~~~~~~~~~~~~~
 
@@ -559,7 +555,7 @@ You can see that in the BeagleBone example with the following:
    include beaglebone.scc
 
 For information on how to break a complete ``.config`` file into the various
-configuration fragments, see the ":ref:`creating-config-fragments`" section.
+configuration fragments, see the ":ref:`kernel-dev/kernel-dev-common:creating configuration fragments`" section.
 
 Finally, if you have any configurations specific to the hardware that
 are not in a ``*.scc`` file, you can include them as follows:
@@ -583,8 +579,6 @@ types of configurations. However, the Malta 32-bit board does
    include mti-malta32.scc
    kconf hardware mti-malta32-le.cfg
 
-.. _bsp-description-file-example-minnow:
-
 Example
 ~~~~~~~
 
@@ -925,8 +919,6 @@ after any ``branch`` commands:
 
       include mybsp-hw.scc
 
-.. _scc-reference:
-
 SCC Description File Reference
 ==============================
 
diff --git a/poky/documentation/kernel-dev/kernel-dev-common.rst b/poky/documentation/kernel-dev/kernel-dev-common.rst
index 830b3e88c..72d9d7879 100644
--- a/poky/documentation/kernel-dev/kernel-dev-common.rst
+++ b/poky/documentation/kernel-dev/kernel-dev-common.rst
@@ -1301,8 +1301,6 @@ created to hold the configuration changes.
 For more information on configuring the kernel, see the "`Changing the
 Configuration <#changing-the-configuration>`__" section.
 
-.. _creating-config-fragments:
-
 Creating Configuration Fragments
 --------------------------------
 
diff --git a/poky/documentation/kernel-dev/kernel-dev-concepts-appx.rst b/poky/documentation/kernel-dev/kernel-dev-concepts-appx.rst
index 681faee52..470d6ce1c 100644
--- a/poky/documentation/kernel-dev/kernel-dev-concepts-appx.rst
+++ b/poky/documentation/kernel-dev/kernel-dev-concepts-appx.rst
@@ -4,8 +4,6 @@
 Advanced Kernel Concepts
 ************************
 
-.. _kernel-big-picture:
-
 Yocto Project Kernel Development and Maintenance
 ================================================
 
diff --git a/poky/documentation/kernel-dev/kernel-dev-faq.rst b/poky/documentation/kernel-dev/kernel-dev-faq.rst
index d6be98a0a..424e62617 100644
--- a/poky/documentation/kernel-dev/kernel-dev-faq.rst
+++ b/poky/documentation/kernel-dev/kernel-dev-faq.rst
@@ -4,8 +4,6 @@
 Kernel Development FAQ
 **********************
 
-.. _kernel-dev-faq-section:
-
 Common Questions and Solutions
 ==============================
 
diff --git a/poky/documentation/kernel-dev/kernel-dev-intro.rst b/poky/documentation/kernel-dev/kernel-dev-intro.rst
index 5679a0ab8..309c65b4d 100644
--- a/poky/documentation/kernel-dev/kernel-dev-intro.rst
+++ b/poky/documentation/kernel-dev/kernel-dev-intro.rst
@@ -4,8 +4,6 @@
 Introduction
 ************
 
-.. _kernel-dev-overview:
-
 Overview
 ========
 
@@ -28,8 +26,8 @@ newly-supported platforms. Previous recipes in the release are refreshed
 and supported for at least one additional Yocto Project release. As they
 align, these previous releases are updated to include the latest from
 the Long Term Support Initiative (LTSI) project. You can learn more
-about Yocto Linux kernels and LTSI in the ":ref:`Yocto Project Kernel
-Development and Maintenance <kernel-big-picture>`" section.
+about Yocto Linux kernels and LTSI in the
+":ref:`kernel-dev/kernel-dev-concepts-appx:yocto project kernel development and maintenance`" section.
 
 Also included is a Yocto Linux kernel development recipe
 (``linux-yocto-dev.bb``) should you want to work with the very latest in
@@ -38,7 +36,7 @@ upstream Yocto Linux kernel development and kernel Metadata development.
 .. note::
 
    For more on Yocto Linux kernels, see the
-   ":ref:`Yocto Project Kernel Development and Maintenance <kernel-big-picture>`"
+   ":ref:`kernel-dev/kernel-dev-concepts-appx:yocto project kernel development and maintenance`"
    section.
 
 The Yocto Project also provides a powerful set of kernel tools for
@@ -167,7 +165,7 @@ general information and references for further information.
    ``menuconfig`` and you have saved them, you can directly compare the
    resulting ``.config`` file against an existing original and gather
    those changes into a
-   :ref:`configuration fragment file <creating-config-fragments>` to be
+   :ref:`configuration fragment file <kernel-dev/kernel-dev-common:creating configuration fragments>` to be
    referenced from within the kernel's ``.bbappend`` file.
 
    Additionally, if you are working in a BSP layer and need to modify
diff --git a/poky/documentation/overview-manual/overview-manual-concepts.rst b/poky/documentation/overview-manual/overview-manual-concepts.rst
index d9f50e519..736fd9591 100644
--- a/poky/documentation/overview-manual/overview-manual-concepts.rst
+++ b/poky/documentation/overview-manual/overview-manual-concepts.rst
@@ -1515,27 +1515,24 @@ cross-compiler that is used internally within BitBake only.
    gcc-cross
    .
 
-The chain of events that occurs when ``gcc-cross`` is bootstrapped is as
-follows:
+The chain of events that occurs when the standard toolchain is bootstrapped:
 ::
 
-   gcc -> binutils-cross -> gcc-cross-initial -> linux-libc-headers -> glibc-initial -> glibc -> gcc-cross -> gcc-runtime
+   binutils-cross -> linux-libc-headers -> gcc-cross -> libgcc-initial -> glibc -> libgcc -> gcc-runtime
 
--  ``gcc``: The build host's GNU Compiler Collection (GCC).
+-  ``gcc``: The compiler, GNU Compiler Collection (GCC).
 
--  ``binutils-cross``: The bare minimum binary utilities needed in order
-   to run the ``gcc-cross-initial`` phase of the bootstrap operation.
+-  ``binutils-cross``: The binary utilities needed in order
+   to run the ``gcc-cross`` phase of the bootstrap operation and build the
+   headers for the C library.
 
--  ``gcc-cross-initial``: An early stage of the bootstrap process for
-   creating the cross-compiler. This stage builds enough of the
-   ``gcc-cross``, the C library, and other pieces needed to finish
-   building the final cross-compiler in later stages. This tool is a
-   "native" package (i.e. it is designed to run on the build host).
+-  ``linux-libc-headers``: Headers needed for the cross-compiler and C library build.
 
--  ``linux-libc-headers``: Headers needed for the cross-compiler.
+-  ``libgcc-initial``: An initial version of the gcc support library needed
+   to bootstrap ``glibc``.
 
--  ``glibc-initial``: An initial version of the Embedded GNU C Library
-   (GLIBC) needed to bootstrap ``glibc``.
+-  ``libgcc``: The final version of the gcc support library which
+   can only be built once there is a C library to link against.
 
 -  ``glibc``: The GNU C Library.
 
@@ -1543,14 +1540,7 @@ follows:
    cross-compiler. This stage results in the actual cross-compiler that
    BitBake uses when it builds an image for a targeted device.
 
-   .. note::
-
-      If you are replacing this cross compiler toolchain with a custom
-      version, you must replace
-      gcc-cross
-      .
-
-   This tool is also a "native" package (i.e. it is designed to run on
+   This tool is a "native" tool (i.e. it is designed to run on
    the build host).
 
 -  ``gcc-runtime``: Runtime libraries resulting from the toolchain
diff --git a/poky/documentation/poky.yaml b/poky/documentation/poky.yaml
index 895864b99..57da0a7c2 100644
--- a/poky/documentation/poky.yaml
+++ b/poky/documentation/poky.yaml
@@ -1,63 +1,16 @@
-DISTRO : "3.1"
-DISTRO_COMPRESSED : "31"
-DISTRO_NAME_NO_CAP : "dunfell"
-DISTRO_NAME : "Dunfell"
-DISTRO_NAME_NO_CAP_MINUS_ONE : "zeus"
-DISTRO_NAME_MINUS_ONE : "Zeus"
-YOCTO_DOC_VERSION : "3.1"
-YOCTO_DOC_VERSION_MINUS_ONE : "3.0.2"
-DISTRO_REL_TAG : "yocto-3.1"
-METAINTELVERSION : "12.0"
-REL_MONTH_YEAR : "April 2020"
-META_INTEL_REL_TAG : "&METAINTELVERSION;-&DISTRO_NAME_NO_CAP;-&YOCTO_DOC_VERSION;"
-POKYVERSION : "23.0.0"
-POKYVERSION_COMPRESSED : "2300"
+DISTRO : "3.2"
+DISTRO_NAME_NO_CAP : "gatesgarth"
+DISTRO_NAME : "Gatesgarth"
+DISTRO_NAME_NO_CAP_MINUS_ONE : "dunfell"
+DISTRO_NAME_NO_CAP_LTS : "dunfell"
+YOCTO_DOC_VERSION : "3.2"
+YOCTO_DOC_VERSION_MINUS_ONE : "3.1.3"
+DISTRO_REL_TAG : "yocto-3.2"
+POKYVERSION : "24.0.0"
 YOCTO_POKY : "poky-&DISTRO_NAME_NO_CAP;-&POKYVERSION;"
-COPYRIGHT_YEAR : "2010-2020"
-ORGNAME : "The Yocto Project"
-ORGEMAIL : "docs@lists.yoctoproject.org"
 YOCTO_DL_URL : "https://downloads.yoctoproject.org"
-YOCTO_HOME_URL : "https://www.yoctoproject.org"
-YOCTO_LISTS_URL : "https://lists.yoctoproject.org"
-YOCTO_BUGZILLA_URL : "https://bugzilla.yoctoproject.org"
-YOCTO_WIKI_URL : "https://wiki.yoctoproject.org"
 YOCTO_AB_URL : "https://autobuilder.yoctoproject.org"
-YOCTO_GIT_URL : "https://git.yoctoproject.org"
-YOCTO_ADTREPO_URL : "http://adtrepo.yoctoproject.org"
-OE_HOME_URL : "https://www.openembedded.org"
-OE_LISTS_URL : "https://lists.openembedded.org"
-OE_DOCS_URL : "https://docs.openembedded.org"
-OH_HOME_URL : "http://o-hand.com"
-BITBAKE_HOME_URL : "http://developer.berlios.de/projects/bitbake/"
-YOCTO_DOCS_URL : "&YOCTO_HOME_URL;/docs"
-YOCTO_SOURCES_URL : "&YOCTO_HOME_URL;/sources/"
-YOCTO_AB_PORT_URL : "https://autobuilder.yocto.io/"
-YOCTO_AB_NIGHTLY_URL : "&YOCTO_AB_PORT_URL;/pub/nightly/"
-YOCTO_POKY_URL : "&YOCTO_DL_URL;/releases/poky/"
 YOCTO_RELEASE_DL_URL : "&YOCTO_DL_URL;/releases/yocto/yocto-&DISTRO;"
-YOCTO_TOOLCHAIN_DL_URL : "&YOCTO_RELEASE_DL_URL;/toolchain/"
-YOCTO_ADTINSTALLER_DL_URL : "&YOCTO_RELEASE_DL_URL;/adt-installer"
-YOCTO_POKY_DL_URL : "&YOCTO_RELEASE_DL_URL;/&YOCTO_POKY;.tar.bz2"
-YOCTO_MACHINES_DL_URL : "&YOCTO_RELEASE_DL_URL;/machines"
-YOCTO_QEMU_DL_URL : "&YOCTO_MACHINES_DL_URL;/qemu"
-YOCTO_PYTHON-i686_DL_URL : "&YOCTO_DL_URL;/releases/miscsupport/python-nativesdk-standalone-i686.tar.bz2"
-YOCTO_PYTHON-x86_64_DL_URL : "&YOCTO_DL_URL;/releases/miscsupport/python-nativesdk-standalone-x86_64.tar.bz2"
-YOCTO_DOCS_QS_URL : "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/yocto-project-qs/yocto-project-qs.html"
-YOCTO_DOCS_ADT_URL : "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/adt-manual/adt-manual.html"
-YOCTO_DOCS_REF_URL : "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/ref-manual/ref-manual.html"
-YOCTO_DOCS_BSP_URL : "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/bsp-guide/bsp-guide.html"
-YOCTO_DOCS_DEV_URL : "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/dev-manual/dev-manual.html"
-YOCTO_DOCS_KERNEL_DEV_URL : "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/kernel-dev/kernel-dev.html"
-YOCTO_DOCS_PROF_URL : "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/profile-manual/profile-manual.html"
-YOCTO_DOCS_MM_URL : "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/mega-manual/mega-manual.html"
-YOCTO_DOCS_BB_URL : "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/bitbake-user-manual/bitbake-user-manual.html"
-YOCTO_DOCS_TOAST_URL : "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/toaster-manual/toaster-manual.html"
-YOCTO_DOCS_SDK_URL : "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/sdk-manual/sdk-manual.html"
-YOCTO_DOCS_OM_URL : "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/overview-manual/overview-manual.html"
-YOCTO_DOCS_BRIEF_URL : "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/brief-yoctoprojectqs/brief-yoctoprojectqs.html"
-YOCTO_ADTPATH_DIR : "/opt/poky/&DISTRO;"
-YOCTO_POKY_TARBALL : "&YOCTO_POKY;.tar.bz2"
-OE_INIT_PATH : "&YOCTO_POKY;/oe-init-build-env"
 UBUNTU_HOST_PACKAGES_ESSENTIAL : "gawk wget git-core diffstat unzip texinfo gcc-multilib \
      build-essential chrpath socat cpio python3 python3-pip python3-pexpect \
      xz-utils debianutils iputils-ping python3-git python3-jinja2 libegl1-mesa libsdl1.2-dev \
diff --git a/poky/documentation/profile-manual/profile-manual-intro.rst b/poky/documentation/profile-manual/profile-manual-intro.rst
index 0d435e0c0..4e1008b05 100644
--- a/poky/documentation/profile-manual/profile-manual-intro.rst
+++ b/poky/documentation/profile-manual/profile-manual-intro.rst
@@ -4,8 +4,6 @@
 Yocto Project Profiling and Tracing Manual
 ******************************************
 
-.. _profile-intro:
-
 Introduction
 ============
 
@@ -30,8 +28,6 @@ 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!
 
-.. _profile-manual-general-setup:
-
 General Setup
 =============
 
diff --git a/poky/documentation/profile-manual/profile-manual-usage.rst b/poky/documentation/profile-manual/profile-manual-usage.rst
index d3c020a1c..cc403a554 100644
--- a/poky/documentation/profile-manual/profile-manual-usage.rst
+++ b/poky/documentation/profile-manual/profile-manual-usage.rst
@@ -10,8 +10,6 @@ Basic Usage (with examples) for each of the Yocto Tracing Tools
 This chapter presents basic usage examples for each of the tracing
 tools.
 
-.. _profile-manual-perf:
-
 perf
 ====
 
@@ -43,8 +41,6 @@ want to apply the tool; full documentation can be found either within
 the tool itself or in the man pages at
 `perf(1) <http://linux.die.net/man/1/perf>`__.
 
-.. _perf-setup:
-
 Perf Setup
 ----------
 
@@ -61,8 +57,6 @@ profile data and copy it to the host for analysis, but for the rest of
 this document we assume you've ssh'ed to the host and will be running
 the perf commands on the target.
 
-.. _perf-basic-usage:
-
 Basic Perf Usage
 ----------------
 
@@ -950,8 +944,6 @@ We can look at the raw output using 'perf script' with no arguments: ::
        kworker/1:1    21 [001]  6171.470082: sched_switch: prev_comm=kworker/1:1 prev_pid=21 prev_prio=120 prev_state=S ==> next_comm=perf next_pid=1383 next_prio=120
               perf  1383 [001]  6171.480035: sched_wakeup: comm=kworker/1:1 pid=21 prio=120 success=1 target_cpu=001
 
-.. _perf-filtering:
-
 Filtering
 ^^^^^^^^^
 
@@ -1138,8 +1130,6 @@ callgraphs from starting a few programs during those 30 seconds:
    uprobes. kprobes and uprobes are also used by and in fact are the
    main focus of SystemTap.
 
-.. _perf-documentation:
-
 Perf Documentation
 ------------------
 
@@ -1182,8 +1172,6 @@ There's also a nice perf tutorial on the perf
 wiki that goes into more detail than we do here in certain areas: `Perf
 Tutorial <https://perf.wiki.kernel.org/index.php/Tutorial>`__
 
-.. _profile-manual-ftrace:
-
 ftrace
 ======
 
@@ -1191,8 +1179,6 @@ ftrace
 this encompasses a number of related tracers along with the
 infrastructure that they all make use of.
 
-.. _ftrace-setup:
-
 ftrace Setup
 ------------
 
@@ -1668,8 +1654,6 @@ trace-cmd and kernelshark in the next section.
    /sys/kernel/debug/tracing will be removed and replaced with
    equivalent tracers based on the 'trace events' subsystem.
 
-.. _trace-cmd-kernelshark:
-
 trace-cmd/kernelshark
 ---------------------
 
@@ -1737,8 +1721,6 @@ The tool is pretty self-explanatory, but for more detailed information
 on navigating through the data, see the `kernelshark
 website <http://rostedt.homelinux.com/kernelshark/>`__.
 
-.. _ftrace-documentation:
-
 ftrace Documentation
 --------------------
 
@@ -1772,8 +1754,6 @@ There's more detailed documentation kernelshark usage here:
 An amusing yet useful README (a tracing mini-HOWTO) can be found in
 ``/sys/kernel/debug/tracing/README``.
 
-.. _profile-manual-systemtap:
-
 systemtap
 =========
 
@@ -1835,8 +1815,6 @@ target system and 3) insert the module into the target kernel, which
 arms it, and 4) collect the data generated by the probe and display it
 to the user.
 
-.. _systemtap-setup:
-
 systemtap Setup
 ---------------
 
@@ -1955,8 +1933,6 @@ no password):
    matchbox-termin(1036) open ("/tmp/vte3FS2LW", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600)
    matchbox-termin(1036) open ("/tmp/vteJMC7LW", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600)
 
-.. _systemtap-documentation:
-
 systemtap Documentation
 -----------------------
 
@@ -1967,8 +1943,6 @@ Links to other SystemTap documents, tutorials, and examples can be found
 here: `SystemTap documentation
 page <http://sourceware.org/systemtap/documentation.html>`__
 
-.. _profile-manual-sysprof:
-
 Sysprof
 =======
 
@@ -1976,8 +1950,6 @@ Sysprof is a very easy to use system-wide profiler that consists of a
 single window with three panes and a few buttons which allow you to
 start, stop, and view the profile from one place.
 
-.. _sysprof-setup:
-
 Sysprof Setup
 -------------
 
@@ -1990,8 +1962,6 @@ be running Sysprof on the target (you can use the '-X' option to ssh and
 have the Sysprof GUI run on the target but display remotely on the host
 if you want).
 
-.. _sysprof-basic-usage:
-
 Basic Sysprof Usage
 -------------------
 
@@ -2040,8 +2010,6 @@ to the selected function, and so on.
    the -g (--call-graph) option that you can experiment with; one of the
    options is 'caller' for an inverted caller-based callgraph display.
 
-.. _sysprof-documentation:
-
 Sysprof Documentation
 ---------------------
 
@@ -2053,8 +2021,6 @@ Linux <http://sysprof.com/>`__
 LTTng (Linux Trace Toolkit, next generation)
 ============================================
 
-.. _lttng-setup:
-
 LTTng Setup
 -----------
 
@@ -2239,8 +2205,6 @@ trace - it's still there in ~/lttng-traces): ::
    root@crownbay:~# lttng destroy
    Session auto-20190303-021943 destroyed at /home/root
 
-.. _lltng-documentation:
-
 LTTng Documentation
 -------------------
 
@@ -2254,8 +2218,6 @@ For information on LTTng in general, visit the `LTTng
 Project <http://lttng.org/lttng2.0>`__ site. You can find a "Getting
 Started" link on this site that takes you to an LTTng Quick Start.
 
-.. _profile-manual-blktrace:
-
 blktrace
 ========
 
@@ -2264,8 +2226,6 @@ blktrace provides the tracing half of the equation; its output can be
 piped into the blkparse program, which renders the data in a
 human-readable form and does some basic analysis:
 
-.. _blktrace-setup:
-
 blktrace Setup
 --------------
 
@@ -2281,8 +2241,6 @@ collect and analyze the data on the host (see the
 below). For the rest of this section we assume you've ssh'ed to the host and
 will be running blkrace on the target.
 
-.. _blktrace-basic-usage:
-
 Basic blktrace Usage
 --------------------
 
@@ -2411,8 +2369,6 @@ I/O traffic during the run. You can look at the
 `blkparse <http://linux.die.net/man/1/blkparse>`__ manpage to learn the
 meaning of each field displayed in the trace listing.
 
-.. _blktrace-live-mode:
-
 Live Mode
 ~~~~~~~~~
 
@@ -2603,8 +2559,6 @@ And this turns off tracing for the specified device: ::
 
    root@crownbay:/sys/kernel/debug/tracing# echo 0 > /sys/block/sdc/trace/enable
 
-.. _blktrace-documentation:
-
 blktrace Documentation
 ----------------------
 
diff --git a/poky/documentation/ref-manual/faq.rst b/poky/documentation/ref-manual/faq.rst
index 7a1614028..576863eec 100644
--- a/poky/documentation/ref-manual/faq.rst
+++ b/poky/documentation/ref-manual/faq.rst
@@ -207,7 +207,7 @@ section in the Yocto Project Development Tasks Manual.
 **Q:** How do I disable the cursor on my touchscreen device?
 
 **A:** You need to create a form factor file as described in the
-":ref:`bsp-filelayout-misc-recipes`" section in
+":ref:`bsp-guide/bsp:miscellaneous bsp-specific recipe files`" section in
 the Yocto Project Board Support Packages (BSP) Developer's Guide. Set
 the ``HAVE_TOUCHSCREEN`` variable equal to one as follows:
 ::
@@ -220,7 +220,7 @@ default?
 **A:** The default interfaces file provided by the netbase recipe does
 not automatically bring up network interfaces. Therefore, you will need
 to add a BSP-specific netbase that includes an interfaces file. See the
-":ref:`bsp-filelayout-misc-recipes`" section in
+":ref:`bsp-guide/bsp:miscellaneous bsp-specific recipe files`" section in
 the Yocto Project Board Support Packages (BSP) Developer's Guide for
 information on creating these types of miscellaneous recipe files.
 
@@ -451,3 +451,14 @@ variant. For another example, permissions errors might be caused by a
 Makefile that ignores ``DESTDIR`` or uses a different name for that
 environment variable. Check the the build system to see if these kinds
 of issues exist.
+
+**Q:** I'm adding a binary in a recipe but it's different in the image, what is
+changing it?
+
+**A:** The first most obvious change is the system stripping debug symbols from
+it. Setting :term:`INHIBIT_PACKAGE_STRIP` to stop debug symbols being stripped and/or
+:term:`INHIBIT_PACKAGE_DEBUG_SPLIT` to stop debug symbols being split into a separate
+file will ensure the binary is unchanged. The other less obvious thing that can
+happen is prelinking of the image. This is set by default in local.conf via
+:term:`USER_CLASSES` which can contain 'image-prelink'. If you remove that, the
+image will not be prelinked meaning the binaries would be unchanged.
diff --git a/poky/documentation/ref-manual/migration-3.2.rst b/poky/documentation/ref-manual/migration-3.2.rst
new file mode 100644
index 000000000..9b65e26c4
--- /dev/null
+++ b/poky/documentation/ref-manual/migration-3.2.rst
@@ -0,0 +1,313 @@
+Moving to the Yocto Project 3.2 Release
+=======================================
+
+This section provides migration information for moving to the Yocto
+Project 3.2 Release from the prior release.
+
+.. _migration-3.2-minimum-system-requirements:
+
+Minimum system requirements
+---------------------------
+
+``gcc`` version 6.0 is now required at minimum on the build host. For older
+host distributions where this is not available, you can use the
+``buildtools-extended-tarball`` (easily installable using
+``scripts/install-buildtools``).
+
+
+.. _migration-3.2-removed-recipes:
+
+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``.
+- ``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``
+- ``packagegroup-core-device-devel``: obsolete
+
+
+.. _migration-3.2-removed-classes:
+
+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.
+
+- ``packagefeed-stability``: this class had become obsolete with the advent of hash equivalence and reproducible builds.
+
+
+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
+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`},
+${:term:`SSTATE_DIR`}, the central sstate control directories, and others.
+
+As of this release, new functionality in pseudo is enabled to ignore these
+directory trees (controlled using a new :term:`PSEUDO_IGNORE_PATHS` variable)
+resulting in a cleaner database with less chance of "stray" mismatches if files
+are modified outside pseudo context. It also should reduce some overhead from
+pseudo as the interprocess round trip to the server is avoided.
+
+There is a possible complication where some existing recipe may break, for
+example, a recipe was found to be writing to ``${B}/install`` for
+``make install`` in ``do_install`` and since ``${B}`` is listed as not to be tracked,
+there were errors trying to ``chown root`` for files in this location. Another
+example was the ``tcl`` recipe where the source directory ``S`` is set to a
+subdirectory of the source tree but files were written out to the directory
+structure above that subdirectory. For these types of cases in your own recipes,
+extend ``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
+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 </wiki/Pseudo_Abort>`
+that explains how to deal with this.
+
+
+.. _migration-3.2-multilib-mlprefix:
+
+``MLPREFIX`` now required for multilib when runtime dependencies conditionally added
+------------------------------------------------------------------------------------
+
+In order to solve some previously intractable problems with runtime
+dependencies and multilib, a change was made that now requires the :term:`MLPREFIX`
+value to be explicitly prepended to package names being added as
+dependencies (e.g. in :term:`RDEPENDS` and :term:`RRECOMMENDS` values)
+where the dependency is conditionally added.
+
+If you have anonymous python or in-line python conditionally adding
+dependencies in your custom recipes, and you intend for those recipes to
+work with multilib, then you will need to ensure that ``${MLPREFIX}``
+is prefixed on the package names in the dependencies, for example
+(from the ``glibc`` recipe): ::
+
+    RRECOMMENDS_${PN} = "${@bb.utils.contains('DISTRO_FEATURES', 'ldconfig', '${MLPREFIX}ldconfig', '', d)}"
+
+This also applies when conditionally adding packages to :term:`PACKAGES` where
+those packages have dependencies, for example (from the ``alsa-plugins`` recipe): ::
+
+    PACKAGES += "${@bb.utils.contains('PACKAGECONFIG', 'pulseaudio', 'alsa-plugins-pulseaudio-conf', '', d)}"
+    ...
+    RDEPENDS_${PN}-pulseaudio-conf += "\
+            ${MLPREFIX}libasound-module-conf-pulse \
+            ${MLPREFIX}libasound-module-ctl-pulse \
+            ${MLPREFIX}libasound-module-pcm-pulse \
+    "
+
+
+.. _migration-3.2-packagegroup-core-device-devel:
+
+packagegroup-core-device-devel no longer included in images built for qemu* machines
+------------------------------------------------------------------------------------
+
+``packagegroup-core-device-devel`` was previously added automatically to
+images built for ``qemu*`` machines, however the purpose of the group and what
+it should contain is no longer clear, and in general, adding userspace
+development items to images is best done at the image/class level; thus this
+packagegroup was removed.
+
+This packagegroup previously pulled in the following:
+
+- ``distcc-config``
+- ``nfs-export-root``
+- ``bash``
+- ``binutils-symlinks``
+
+If you still need any of these in your image built for a ``qemu*`` machine
+then you will add them explicitly to :term:`IMAGE_INSTALL` or another
+appropriate place in the dependency chain for your image (if you have not
+already done so).
+
+
+.. _migration-3.2-dhcp:
+
+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
+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
+the upstream documentation for ``dhcpcd`` and ``kea`` for further details.
+
+
+.. _migration-3.2-packaging-changes:
+
+Packaging changes
+-----------------
+
+- ``python3``: the ``urllib`` python package has now moved into the core package, as it is used more commonly than just netclient (e.g. email, xml, mimetypes, pydoc). In addition, the ``pathlib`` module is now also part of the core package.
+
+- ``iptables``: ``iptables-apply`` and ``ip6tables-apply`` have been split out to their own package to avoid a bash dependency in the main ``iptables`` package
+
+
+.. _migration-3.2-package-qa-checks:
+
+Package QA check changes
+------------------------
+
+Previously, the following package QA checks triggered warnings, however they can
+be indicators of genuine underlying problems and are therefore now treated as
+errors:
+
+- :ref:`already-stripped <qa-check-already-stripped>`
+- :ref:`compile-host-path <qa-check-compile-host-path>`
+- :ref:`installed-vs-shipped <qa-check-installed-vs-shipped>`
+- :ref:`ldflags <qa-check-ldflags>`
+- :ref:`pn-overrides <qa-check-pn-overrides>`
+- :ref:`rpaths <qa-check-rpaths>`
+- :ref:`staticdev <qa-check-staticdev>`
+- :ref:`unknown-configure-option <qa-check-unknown-configure-option>`
+- :ref:`useless-rpaths <qa-check-useless-rpaths>`
+
+In addition, the following new checks were added and default to triggering an error:
+
+- :ref:`shebang-size <qa-check-shebang-size>`: Check for shebang (#!) lines longer than 128 characters, which can give an error at runtime depending on the operating system.
+
+- :ref:`unhandled-features-check <qa-check-unhandled-features-check>`: Check if any of the variables supported by the :ref:`features_check <ref-classes-features_check>` class is set while not inheriting the class itself.
+
+- :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.
+
+
+.. _migration-3.2-src-uri-file-globbing:
+
+Globbing no longer supported in ``file://`` entries in ``SRC_URI``
+------------------------------------------------------------------
+
+Globbing (``*`` and ``?`` wildcards) in ``file://`` URLs within :term:`SRC_URI`
+did not properly support file checksums, thus changes to the source files
+would not always change the do_fetch task checksum, and consequently would
+not ensure that the changed files would be incorporated in subsequent builds.
+
+Unfortunately it is not practical to make globbing work generically here, so
+the decision was taken to remove support for globs in ``file://`` URLs.
+If you have any usage of these in your recipes, then you will now need to
+either add each of the files that you expect to match explicitly, or
+alternatively if you still need files to be pulled in dynamically, put the
+files into a subdirectory and reference that instead.
+
+
+.. _migration-3.2-deploydir-clean:
+
+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 ``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 ``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:
+
+Custom SDK / SDK-style recipes need to include ``nativesdk-sdk-provides-dummy``
+-------------------------------------------------------------------------------
+
+All ``nativesdk`` packages require ``/bin/sh`` due to their postinstall scriptlets, thus this package has to be dummy-provided within the SDK and ``nativesdk-sdk-provides-dummy`` now does this. If you have a custom SDK recipe (or your own SDK-style recipe similar to e.g. ``buildtools-tarball``), you will need to ensure ``nativesdk-sdk-provides-dummy`` or an equivalent is included in :term:`TOOLCHAIN_HOST_TASK`.
+
+
+``ld.so.conf`` now moved back to main ``glibc`` package
+-------------------------------------------------------
+
+There are cases where one doesn't want ``ldconfig`` on target (e.g. for
+read-only root filesystems, it's rather pointless), yet one still
+needs ``/etc/ld.so.conf`` to be present at image build time:
+
+When some recipe installs libraries to a non-standard location, and
+therefore installs in a file in ``/etc/ld.so.conf.d/foo.conf``, we
+need ``/etc/ld.so.conf`` containing: ::
+
+  include /etc/ld.so.conf.d/*.conf
+
+in order to get those other locations picked up.
+
+Thus ``/etc/ld.so.conf`` is now in the main ``glibc`` package so that
+there's always an ``ld.so.conf`` present when the build-time ``ldconfig``
+runs towards the end of image construction.
+
+The ``ld.so.conf`` and ``ld.so.conf.d/*.conf`` files do not take up
+significant space (at least not compared to the ~700kB ``ldconfig`` binary), and they
+might be needed in case ``ldconfig`` is installable, so they are left
+in place after the image is built. Technically it would be possible to
+remove them if desired, though it would not be trivial if you still
+wanted the build-time ldconfig to function (:term:`ROOTFS_POSTPROCESS_COMMAND`
+will not work as ``ldconfig`` is run after the functions referred to
+by that variable).
+
+
+.. _migration-3.2-virgl:
+
+Host DRI drivers now used for GL support within ``runqemu``
+-----------------------------------------------------------
+
+``runqemu`` now uses the mesa-native libraries everywhere virgl is used
+(i.e. when ``gl``, ``gl-es`` or ``egl-headless`` options are specified),
+but instructs them to load DRI drivers from the host. Unfortunately this
+may not work well with proprietary graphics drivers such as those from
+Nvidia; if you are using such drivers then you may need to switch to an
+alternative (such as Nouveau in the case of Nvidia hardware) or avoid
+using the GL options.
+
+
+.. _migration-3.2-initramfs-suffix:
+
+initramfs images now use a blank suffix
+---------------------------------------
+
+The reference initramfs images (``core-image-minimal-initramfs``,
+``core-image-tiny-initramfs`` and ``core-image-testmaster-initramfs``) now
+set an empty string for :term:`IMAGE_NAME_SUFFIX`, which otherwise defaults
+to ``".rootfs"``. These images aren't root filesystems and thus the rootfs
+label didn't make sense. If you are looking for the output files generated
+by these image recipes directly then you will need to adapt to the new
+naming without the ``.rootfs`` part.
+
+
+.. _migration-3.2-image-artifact-names:
+
+Image artifact name variables now centralised in image-artifact-names class
+---------------------------------------------------------------------------
+
+The defaults for the following image artifact name variables have been moved
+from bitbake.conf to a new ``image-artifact-names`` class:
+
+- :term:`IMAGE_BASENAME`
+- :term:`IMAGE_LINK_NAME`
+- :term:`IMAGE_NAME`
+- :term:`IMAGE_NAME_SUFFIX`
+- :term:`IMAGE_VERSION_SUFFIX`
+
+Image-related classes now inherit this class, and typically these variables
+are only referenced within image recipes so those will be unaffected by this
+change. However if you have references to these variables in either a recipe
+that is not an image or a class that is enabled globally, then those will
+now need to be changed to ``inherit image-artifact-names``.
+
+
+.. _migration-3.2-misc:
+
+Miscellaneous changes
+---------------------
+
+- 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.
+- ``oe.utils.is_machine_specific()`` and ``oe.utils.machine_paths()`` have been removed as their utility was questionable. In the unlikely event that you have references to these in your own code, then the code will need to be reworked.
+- The ``i2ctransfer`` module is now disabled by default when building ``busybox`` in order to be consistent with disabling the other i2c tools there. If you do wish the i2ctransfer module to be built in busybox then add ``CONFIG_I2CTRANSFER=y`` to your custom busybox configuration.
+- In the ``Upstream-Status`` header convention for patches, ``Accepted`` has been replaced with ``Backport`` as these almost always mean the same thing i.e. the patch is already upstream and may need to be removed in a future recipe upgrade. If you are adding these headers to your own patches then use ``Backport`` to indicate that the patch has been sent upstream.
+- The ``tune-supersparc.inc`` tune file has been removed as it does not appear to be widely used and no longer works.
diff --git a/poky/documentation/ref-manual/migration.rst b/poky/documentation/ref-manual/migration.rst
index 20288b0de..8d64a7daa 100644
--- a/poky/documentation/ref-manual/migration.rst
+++ b/poky/documentation/ref-manual/migration.rst
@@ -27,4 +27,5 @@ notes for a given release.
    migration-2.7
    migration-3.0
    migration-3.1
+   migration-3.2
 
diff --git a/poky/documentation/ref-manual/ref-classes.rst b/poky/documentation/ref-manual/ref-classes.rst
index 028729ffe..249b58e60 100644
--- a/poky/documentation/ref-manual/ref-classes.rst
+++ b/poky/documentation/ref-manual/ref-classes.rst
@@ -501,21 +501,6 @@ Support for other version control systems such as Subversion is limited
 due to BitBake's automatic fetch dependencies (e.g.
 ``subversion-native``).
 
-.. _ref-classes-distro_features_check:
-
-``distro_features_check.bbclass``
-=================================
-
-The ``distro_features_check`` class allows individual recipes to check
-for required and conflicting
-:term:`DISTRO_FEATURES`.
-
-This class provides support for the
-:term:`REQUIRED_DISTRO_FEATURES` and
-:term:`CONFLICT_DISTRO_FEATURES`
-variables. If any conditions specified in the recipe using the above
-variables are not met, the recipe will be skipped.
-
 .. _ref-classes-distutils:
 
 ``distutils*.bbclass``
@@ -656,6 +641,32 @@ Finally, here is an example that sets the root password to "1876*18":
        usermod -P 1876*18 root; \
        "
 
+.. _ref-classes-features_check:
+
+``features_check.bbclass``
+=================================
+
+The ``features_check`` class allows individual recipes to check
+for required and conflicting
+:term:`DISTRO_FEATURES`, :term:`MACHINE_FEATURES` or :term:`COMBINED_FEATURES`.
+
+This class provides support for the following variables:
+
+- :term:`REQUIRED_DISTRO_FEATURES`
+- :term:`CONFLICT_DISTRO_FEATURES`
+- :term:`ANY_OF_DISTRO_FEATURES`
+- ``REQUIRED_MACHINE_FEATURES``
+- ``CONFLICT_MACHINE_FEATURES``
+- ``ANY_OF_MACHINE_FEATURES``
+- ``REQUIRED_COMBINED_FEATURES``
+- ``CONFLICT_COMBINED_FEATURES``
+- ``ANY_OF_COMBINED_FEATURES``
+
+If any conditions specified in the recipe using the above
+variables are not met, the recipe will be skipped, and if the
+build system attempts to build the recipe then an error will be
+triggered.
+
 .. _ref-classes-fontcache:
 
 ``fontcache.bbclass``
diff --git a/poky/documentation/ref-manual/ref-devtool-reference.rst b/poky/documentation/ref-manual/ref-devtool-reference.rst
index 9b9ddf53f..ad8889ed2 100644
--- a/poky/documentation/ref-manual/ref-devtool-reference.rst
+++ b/poky/documentation/ref-manual/ref-devtool-reference.rst
@@ -438,7 +438,7 @@ revision to which you want to upgrade (i.e. the
 forth.
 
 You can read more on the ``devtool upgrade`` workflow 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. You can also see an example of
 how to use ``devtool upgrade`` in the ":ref:`gs-using-devtool-upgrade`"
diff --git a/poky/documentation/ref-manual/ref-qa-checks.rst b/poky/documentation/ref-manual/ref-qa-checks.rst
index 5b9f92d35..54977dcb2 100644
--- a/poky/documentation/ref-manual/ref-qa-checks.rst
+++ b/poky/documentation/ref-manual/ref-qa-checks.rst
@@ -43,6 +43,8 @@ error form along with an explanation.
 Errors and Warnings
 ===================
 
+.. _qa-check-libexec:
+
 -  ``<packagename>: <path> is using libexec please relocate to <libexecdir> [libexec]``
 
    The specified package contains files in ``/usr/libexec`` when the
@@ -51,6 +53,7 @@ Errors and Warnings
    default can be changed (e.g. ``${libdir}``).
 
     
+.. _qa-check-rpaths:
 
 -  ``package <packagename> contains bad RPATH <rpath> in file <file> [rpaths]``
 
@@ -65,6 +68,7 @@ Errors and Warnings
    software.
 
     
+.. _qa-check-useless-rpaths:
 
 -  ``<packagename>: <file> contains probably-redundant RPATH <rpath> [useless-rpaths]``
 
@@ -77,6 +81,7 @@ Errors and Warnings
    the build of the software.
 
     
+.. _qa-check-file-rdeps:
 
 -  ``<packagename> requires <files>, but no providers in its RDEPENDS [file-rdeps]``
 
@@ -88,6 +93,7 @@ Errors and Warnings
    built.
 
     
+.. _qa-check-build-deps:
 
 -  ``<packagename1> rdepends on <packagename2>, but it isn't a build dependency? [build-deps]``
 
@@ -101,6 +107,7 @@ Errors and Warnings
    to add an explicit ``RDEPENDS`` for the dependency.
 
     
+.. _qa-check-dev-so:
 
 -  ``non -dev/-dbg/nativesdk- package contains symlink .so: <packagename> path '<path>' [dev-so]``
 
@@ -112,6 +119,7 @@ Errors and Warnings
    file goes into an appropriate ``-dev`` package.
 
     
+.. _qa-check-staticdev:
 
 -  ``non -staticdev package contains static .a library: <packagename> path '<path>' [staticdev]``
 
@@ -121,6 +129,7 @@ Errors and Warnings
    goes into an appropriate ``-staticdev`` package.
 
     
+.. _qa-check-libdir:
 
 -  ``<packagename>: found library in wrong location [libdir]``
 
@@ -133,6 +142,7 @@ Errors and Warnings
    :term:`INSANE_SKIP` for the package.
 
     
+.. _qa-check-debug-files:
 
 -  ``non debug package contains .debug directory: <packagename> path <path> [debug-files]``
 
@@ -145,8 +155,9 @@ Errors and Warnings
    information on ``FILES``.
 
     
+.. _qa-check-arch:
 
--  ``Architecture did not match (<machine_arch> to <file_arch>) on <file> [arch]``
+-  ``Architecture did not match (<file_arch>, expected <machine_arch>) in <file> [arch]``
 
    By default, the OpenEmbedded build system checks the Executable and
    Linkable Format (ELF) type, bit size, and endianness of any binaries
@@ -164,7 +175,7 @@ Errors and Warnings
 
     
 
--  ``Bit size did not match (<machine_bits> to <file_bits>) <recipe> on <file> [arch]``
+-  ``Bit size did not match (<file_bits>, expected <machine_bits>) in <file> [arch]``
 
    By default, the OpenEmbedded build system checks the Executable and
    Linkable Format (ELF) type, bit size, and endianness of any binaries
@@ -182,7 +193,7 @@ Errors and Warnings
 
     
 
--  ``Endianness did not match (<machine_endianness> to <file_endianness>) on <file> [arch]``
+-  ``Endianness did not match (<file_endianness>, expected <machine_endianness>) in <file> [arch]``
 
    By default, the OpenEmbedded build system checks the Executable and
    Linkable Format (ELF) type, bit size, and endianness of any binaries
@@ -199,6 +210,7 @@ Errors and Warnings
    and verify that the compiler options being used are correct.
 
     
+.. _qa-check-textrel:
 
 -  ``ELF binary '<file>' has relocations in .text [textrel]``
 
@@ -218,8 +230,9 @@ Errors and Warnings
    http://www.akkadia.org/drepper/textrelocs.html.
 
     
+.. _qa-check-ldflags:
 
--  ``No GNU_HASH in the elf binary: '<file>' [ldflags]``
+-  ``File '<file>' in package '<package>' doesn't have GNU_HASH (didn't pass LDFLAGS?) [ldflags]``
 
    This indicates that binaries produced when building the recipe have
    not been linked with the :term:`LDFLAGS` options
@@ -233,6 +246,7 @@ Errors and Warnings
       TARGET_CC_ARCH += "${LDFLAGS}"
 
     
+.. _qa-check-xorg-driver-abi:
 
 -  ``Package <packagename> contains Xorg driver (<driver>) but no xorg-abi- dependencies [xorg-driver-abi]``
 
@@ -245,6 +259,7 @@ Errors and Warnings
    to explicitly add dependencies to binary driver recipes.
 
     
+.. _qa-check-infodir:
 
 -  ``The /usr/share/info/dir file is not meant to be shipped in a particular package. [infodir]``
 
@@ -256,6 +271,8 @@ Errors and Warnings
       rm ${D}${infodir}/dir
    
 
+.. _qa-check-symlink-to-sysroot:
+
 -  ``Symlink <path> in <packagename> points to TMPDIR [symlink-to-sysroot]``
 
    The specified symlink points into :term:`TMPDIR` on the
@@ -264,6 +281,7 @@ Errors and Warnings
    symlink to use a relative path or remove the symlink.
 
     
+.. _qa-check-la:
 
 -  ``<file> failed sanity test (workdir) in path <path> [la]``
 
@@ -273,6 +291,7 @@ Errors and Warnings
    automatically itself.
 
     
+.. _qa-check-pkgconfig:
 
 -  ``<file> failed sanity test (tmpdir) in path <path> [pkgconfig]``
 
@@ -283,6 +302,7 @@ Errors and Warnings
    are accessed.
 
     
+.. _qa-check-debug-deps:
 
 -  ``<packagename> rdepends on <debug_packagename> [debug-deps]``
 
@@ -305,6 +325,7 @@ Errors and Warnings
    manually (e.g. by adding to :term:`RDEPENDS`).
 
     
+.. _qa-check-dev-deps:
 
 -  ``<packagename> rdepends on <dev_packagename> [dev-deps]``
 
@@ -327,6 +348,7 @@ Errors and Warnings
    manually (e.g. by adding to :term:`RDEPENDS`).
 
     
+.. _qa-check-dep-cmp:
 
 -  ``<var>_<packagename> is invalid: <comparison> (<value>)   only comparisons <, =, >, <=, and >= are allowed [dep-cmp]``
 
@@ -341,6 +363,7 @@ Errors and Warnings
    adding to match those listed in the message.
 
     
+.. _qa-check-compile-host-path:
 
 -  ``<recipename>: The compile log indicates that host include and/or library paths were used. Please check the log '<logfile>' for more information. [compile-host-path]``
 
@@ -351,6 +374,7 @@ Errors and Warnings
    file.
 
     
+.. _qa-check-install-host-path:
 
 -  ``<recipename>: The install log indicates that host include and/or library paths were used. Please check the log '<logfile>' for more information. [install-host-path]``
 
@@ -361,8 +385,9 @@ Errors and Warnings
    file.
 
     
+.. _qa-check-configure-unsafe:
 
--  ``This autoconf log indicates errors, it looked at host include and/or library paths while determining system capabilities. Rerun configure task after fixing this. The path was '<path>'``
+-  ``This autoconf log indicates errors, it looked at host include and/or library paths while determining system capabilities. Rerun configure task after fixing this. [configure-unsafe]``
 
    The log for the :ref:`ref-tasks-configure` task
    indicates that paths on the host were searched for files, which is
@@ -371,6 +396,7 @@ Errors and Warnings
    file.
 
     
+.. _qa-check-pkgname:
 
 -  ``<packagename> doesn't match the [a-z0-9.+-]+ regex [pkgname]``
 
@@ -384,6 +410,7 @@ Errors and Warnings
    change the package name appropriately.
 
     
+.. _qa-check-unknown-configure-option:
 
 -  ``<recipe>: configure was passed unrecognized options: <options> [unknown-configure-option]``
 
@@ -401,6 +428,7 @@ Errors and Warnings
    accordingly.
 
     
+.. _qa-check-pn-overrides:
 
 -  ``Recipe <recipefile> has PN of "<recipename>" which is in OVERRIDES, this can result in unexpected behavior. [pn-overrides]``
 
@@ -416,6 +444,7 @@ Errors and Warnings
    :term:`FILES` for additional information.
 
     
+.. _qa-check-pkgvarcheck:
 
 -  ``<recipefile>: Variable <variable> is set as not being package specific, please fix this. [pkgvarcheck]``
 
@@ -432,7 +461,16 @@ Errors and Warnings
    ``RDEPENDS = "value"``). If you receive this error, correct any
    assignments to these variables within your recipe.
 
-    
+
+- ``recipe uses DEPENDS_${PN}, should use DEPENDS [pkgvarcheck]``
+
+   This check looks for instances of setting ``DEPENDS_${PN}``
+   which is erroneous (:term:`DEPENDS` is a recipe-wide variable and thus
+   it is not correct to specify it for a particular package, nor will such
+   an assignment actually work.) Set ``DEPENDS`` instead.
+
+
+.. _qa-check-already-stripped:
 
 -  ``File '<file>' from <recipename> was already stripped, this will prevent future debugging! [already-stripped]``
 
@@ -458,6 +496,7 @@ Errors and Warnings
       strip the symbols from the binaries.
 
     
+.. _qa-check-packages-list:
 
 -  ``<packagename> is listed in PACKAGES multiple times, this leads to packaging errors. [packages-list]``
 
@@ -467,6 +506,7 @@ Errors and Warnings
    already in the variable's value.
 
     
+.. _qa-check-files-invalid:
 
 -  ``FILES variable for package <packagename> contains '//' which is invalid. Attempting to fix this but you should correct the metadata. [files-invalid]``
 
@@ -475,6 +515,7 @@ Errors and Warnings
    that there is only a single "/".
 
     
+.. _qa-check-installed-vs-shipped:
 
 -  ``<recipename>: Files/directories were installed but not shipped in any package [installed-vs-shipped]``
 
@@ -505,6 +546,9 @@ Errors and Warnings
    :term:`PRIVATE_LIBS` in the recipe that provides
    the private version of the library.
 
+
+.. _qa-check-unlisted-pkg-lics:
+
 -  ``LICENSE_<packagename> includes licenses (<licenses>) that are not listed in LICENSE [unlisted-pkg-lics]``
 
    The :term:`LICENSE` of the recipe should be a superset
@@ -512,7 +556,192 @@ Errors and Warnings
    words, any license in ``LICENSE_*`` should also appear in
    :term:`LICENSE`.
 
-    
+
+.. _qa-check-configure-gettext:
+
+-  ``AM_GNU_GETTEXT used but no inherit gettext [configure-gettext]``
+
+    If a recipe is building something that uses automake and the automake
+    files contain an ``AM_GNU_GETTEXT`` directive then this check will fail
+    if there is no ``inherit gettext`` statement in the recipe to ensure
+    that gettext is available during the build. Add ``inherit gettext`` to
+    remove the warning.
+
+
+.. _qa-check-mime:
+
+- ``package contains mime types but does not inherit mime: <packagename> path '<file>' [mime]``
+
+   The specified package contains mime type files (``.xml`` files in
+   ``${datadir}/mime/packages``) and yet does not inherit the mime
+   class which will ensure that these get properly installed. Either
+   add ``inherit mime`` to the recipe or remove the files at the
+   ``do_install`` step if they are not needed.
+
+
+.. _qa-check-mime-xdg:
+
+- ``package contains desktop file with key 'MimeType' but does not inhert mime-xdg: <packagename> path '<file>' [mime-xdg]``
+
+    The specified package contains a .desktop file with a 'MimeType' key
+    present, but does not inherit the mime-xdg class that is required in
+    order for that to be activated. Either add ``inherit mime`` to the
+    recipe or remove the files at the ``do_install`` step if they are not
+    needed.
+
+
+.. _qa-check-src-uri-bad:
+
+- ``<recipename>: SRC_URI uses unstable GitHub archives [src-uri-bad]``
+
+    GitHub provides "archive" tarballs, however these can be re-generated
+    on the fly and thus the file's signature will not necessarily match that
+    in the SRC_URI checksums in future leading to build failures. It is
+    recommended that you use an official release tarball or switch to
+    pulling the corresponding revision in the actual git repository instead.
+
+
+- ``SRC_URI uses PN not BPN [src-uri-bad]``
+
+    If some part of :term:`SRC_URI` needs to reference the recipe name, it should do
+    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 ``SRC_URI`` value - change it to ``${BPN}`` instead.
+
+
+.. _qa-check-unhandled-features-check:
+
+- ``<recipename>: recipe doesn't inherit features_check [unhandled-features-check]``
+
+    This check ensures that if one of the variables that the :ref:`features_check <ref-classes-features_check>`
+    class supports (e.g. :term:`REQUIRED_DISTRO_FEATURES`) is used, then the recipe
+    inherits ``features_check`` in order for the requirement to actually work. If
+    you are seeing this message, either add ``inherit features_check`` to your recipe
+    or remove the reference to the variable if it is not needed.
+
+
+.. _qa-check-missing-update-alternatives:
+
+- ``<recipename>: recipe defines ALTERNATIVE_<packagename> but doesn't inherit update-alternatives. This might fail during do_rootfs later! [missing-update-alternatives]``
+
+    This check ensures that if a recipe sets the :term:`ALTERNATIVE` variable that the
+    recipe also inherits :ref:`update-alternatives <ref-classes-update-alternatives>` such
+    that the alternative will be correctly set up. If you are seeing this message, either
+    add ``inherit update-alternatives`` to your recipe or remove the reference to the variable
+    if it is not needed.
+
+
+.. _qa-check-shebang-size:
+
+- ``<packagename>: <file> maximum shebang size exceeded, the maximum size is 128. [shebang-size]``
+
+    This check ensures that the shebang line (``#!`` in the first line) for a script
+    is not longer than 128 characters, which can cause an error at runtime depending
+    on the operating system. If you are seeing this message then the specified script
+    may need to be patched to have a shorter in order to avoid runtime problems.
+
+
+.. _qa-check-perllocalpod:
+
+- ``<packagename> contains perllocal.pod (<files>), should not be installed [perllocalpod]``
+
+    ``perllocal.pod`` is an index file of locally installed modules and so shouldn't be
+    installed by any distribution packages. The :ref:`cpan <ref-classes-cpan>` class
+    already sets ``NO_PERLLOCAL`` to stop this file being generated by most Perl recipes,
+    but if a recipe is using ``MakeMaker`` directly then they might not be doing this
+    correctly. This check ensures that perllocal.pod is not in any package in order to
+    avoid multiple packages shipping this file and thus their packages conflicting
+    if installed together.
+
+
+.. _qa-check-usrmerge:
+
+- ``<packagename> package is not obeying usrmerge distro feature. /<path> should be relocated to /usr. [usrmerge]``
+
+    If ``usrmerge`` is in :term:`DISTRO_FEATURES`, this check will ensure that no package
+    installs files to root (``/bin``, ``/sbin``, ``/lib``, ``/lib64``) directories. If you are seeing this
+    message, it indicates that the ``do_install`` step (or perhaps the build process that
+    ``do_install`` is calling into, e.g. ``make install`` is using hardcoded paths instead
+    of the variables set up for this (``bindir``, ``sbindir``, etc.), and should be
+    changed so that it does.
+
+
+.. _qa-check-patch-fuzz:
+
+- ``Fuzz detected: <patch output> [patch-fuzz]``
+
+    This check looks for evidence of "fuzz" when applying patches within the ``do_patch``
+    task. Patch fuzz is a situation when the ``patch`` tool ignores some of the context
+    lines in order to apply the patch. Consider this example:
+
+    Patch to be applied: ::
+
+        --- filename
+        +++ filename
+         context line 1
+         context line 2
+         context line 3
+        +newly added line
+         context line 4
+         context line 5
+         context line 6
+
+    Original source code: ::
+
+        different context line 1
+        different context line 2
+        context line 3
+        context line 4
+        different context line 5
+        different context line 6
+
+    Outcome (after applying patch with fuzz): ::
+
+        different context line 1
+        different context line 2
+        context line 3
+        newly added line
+        context line 4
+        different context line 5
+        different context line 6
+
+    Chances are, the newly added line was actually added in a completely
+    wrong location, or it was already in the original source and was added
+    for the second time. This is especially possible if the context line 3
+    and 4 are blank or have only generic things in them, such as ``#endif`` or ``}``.
+    Depending on the patched code, it is entirely possible for an incorrectly
+    patched file to still compile without errors.
+
+    *How to eliminate patch fuzz warnings*
+
+    Use the ``devtool`` command as explained by the warning. First, unpack the
+    source into devtool workspace: ::
+
+            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.
+
+    Then, replace the patches in the recipe layer: ::
+
+            devtool finish --force-patch-refresh <recipe> <layer_path>
+
+    The patch updates then need be reviewed (preferably with a side-by-side diff
+    tool) to ensure they are indeed doing the right thing i.e.:
+
+    #. they are applied in the correct location within the file;
+    #. they do not introduce duplicate lines, or otherwise do things that
+       are no longer necessary.
+
+    To confirm these things, you can also review the patched source code in
+    devtool's workspace, typically in ``<build_dir>/workspace/sources/<recipe>/``
+
+    Once the review is done, you can create and publish a layer commit with
+    the patch updates that modify the context. Devtool may also refresh
+    other things in the patches, those can be discarded.
+
+
 
 Configuring and Disabling QA Checks
 ===================================
diff --git a/poky/documentation/ref-manual/ref-variables.rst b/poky/documentation/ref-manual/ref-variables.rst
index 0603ba93c..e552351e3 100644
--- a/poky/documentation/ref-manual/ref-variables.rst
+++ b/poky/documentation/ref-manual/ref-variables.rst
@@ -132,6 +132,18 @@ system and gives an overview of their function and contents.
       ":ref:`update-alternatives.bbclass <ref-classes-update-alternatives>`"
       section.
 
+   :term:`ANY_OF_DISTRO_FEATURES`
+      When inheriting the
+      :ref:`features_check <ref-classes-features_check>`
+      class, this variable identifies a list of distribution features where
+      at least one must be enabled in the current configuration in order
+      for the OpenEmbedded build system to build the recipe. In other words,
+      if none of the features listed in ``ANY_OF_DISTRO_FEATURES``
+      appear in ``DISTRO_FEATURES`` within the current configuration, then
+      the recipe will be skipped, and if the build system attempts to build
+      the recipe then an error will be triggered.
+      
+
    :term:`APPEND`
       An override list of append strings for each target specified with
       :term:`LABELS`.
@@ -1300,12 +1312,13 @@ system and gives an overview of their function and contents.
 
    :term:`CONFLICT_DISTRO_FEATURES`
       When inheriting the
-      :ref:`distro_features_check <ref-classes-distro_features_check>`
+      :ref:`features_check <ref-classes-features_check>`
       class, this variable identifies distribution features that would be
       in conflict should the recipe be built. In other words, if the
       ``CONFLICT_DISTRO_FEATURES`` variable lists a feature that also
-      appears in ``DISTRO_FEATURES`` within the current configuration, an
-      error occurs and the build stops.
+      appears in ``DISTRO_FEATURES`` within the current configuration, then
+      the recipe will be skipped, and if the build system attempts to build
+      the recipe then an error will be triggered.
 
    :term:`COPYLEFT_LICENSE_EXCLUDE`
       A space-separated list of licenses to exclude from the source
@@ -3085,6 +3098,17 @@ system and gives an overview of their function and contents.
       See the :term:`GLIBC_GENERATE_LOCALES`
       variable for information on generating GLIBC locales.
 
+
+   :term:`IMAGE_LINK_NAME`
+      The name of the output image symlink (which does not include
+      the version part as :term:`IMAGE_NAME` does). The default value
+      is derived using the :term:`IMAGE_BASENAME` and :term:`MACHINE`
+      variables:
+      ::
+
+         IMAGE_LINK_NAME ?= "${IMAGE_BASENAME}-${MACHINE}"
+
+
    :term:`IMAGE_MANIFEST`
       The manifest file for the image. This file lists all the installed
       packages that make up the image. The file contains package
@@ -3108,11 +3132,18 @@ system and gives an overview of their function and contents.
    :term:`IMAGE_NAME`
       The name of the output image files minus the extension. This variable
       is derived using the :term:`IMAGE_BASENAME`,
-      :term:`MACHINE`, and :term:`DATETIME`
+      :term:`MACHINE`, and :term:`IMAGE_VERSION_SUFFIX`
       variables:
       ::
 
-         IMAGE_NAME = "${IMAGE_BASENAME}-${MACHINE}-${DATETIME}"
+         IMAGE_NAME ?= "${IMAGE_BASENAME}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
+
+   :term:`IMAGE_NAME_SUFFIX`
+      Suffix used for the image output file name - 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,
+      this is typically cleared in initramfs image recipes.
 
    :term:`IMAGE_OVERHEAD_FACTOR`
       Defines a multiplier that the build system applies to the initial
@@ -3316,6 +3347,14 @@ system and gives an overview of their function and contents.
       For more information about these types of images, see
       ``meta/classes/image_types*.bbclass`` in the :term:`Source Directory`.
 
+   :term:`IMAGE_VERSION_SUFFIX`
+      Version suffix that is part of the default :term:`IMAGE_NAME` and
+      :term:`KERNEL_ARTIFACT_NAME` values.
+      Defaults to ``"-${DATETIME}"``, however you could set this to a
+      version string that comes from your external build environment if
+      desired, and this suffix would then be used consistently across
+      the build artifacts.
+
    :term:`INC_PR`
       Helps define the recipe revision for recipes that share a common
       ``include`` file. You can think of this variable as part of the
@@ -3774,12 +3813,8 @@ system and gives an overview of their function and contents.
 
          KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
 
-      See the :term:`PKGE`, :term:`PKGV`, :term:`PKGR`, and :term:`MACHINE`
-      variables for additional information.
-
-      .. note::
-
-         The ``IMAGE_VERSION_SUFFIX`` variable is set to :term:`DATETIME`.
+      See the :term:`PKGE`, :term:`PKGV`, :term:`PKGR`, :term:`MACHINE`
+      and :term:`IMAGE_VERSION_SUFFIX` variables for additional information.
 
    :term:`KERNEL_CLASSES`
       A list of classes defining kernel image types that the
@@ -5104,7 +5139,7 @@ system and gives an overview of their function and contents.
 
       .. note::
 
-         You can use the ``PACKAGE_FEEDS_ARCHS``
+         You can use the ``PACKAGE_FEED_ARCHS``
          variable to whitelist specific package architectures. If you do
          not need to whitelist specific architectures, which is a common
          case, you can omit this variable. Omitting the variable results in
@@ -5919,6 +5954,15 @@ system and gives an overview of their function and contents.
       service <dev-manual/dev-manual-common-tasks:working with a pr service>`. You can
       set ``PRSERV_HOST`` to other values to use a remote PR service.
 
+
+   :term:`PSEUDO_IGNORE_PATHS`
+      A comma-separated (without spaces) list of path prefixes that should be ignored
+      by pseudo when monitoring and recording file operations, in order to avoid
+      problems with files being written to outside of the pseudo context and
+      reduce pseudo's overhead. A path is ignored if it matches any prefix in the list
+      and can include partial directory (or file) names.
+
+
    :term:`PTEST_ENABLED`
       Specifies whether or not :ref:`Package
       Test <dev-manual/dev-manual-common-tasks:testing packages with ptest>` (ptest)
@@ -6122,13 +6166,14 @@ system and gives an overview of their function and contents.
 
    :term:`REQUIRED_DISTRO_FEATURES`
       When inheriting the
-      :ref:`distro_features_check <ref-classes-distro_features_check>`
+      :ref:`features_check <ref-classes-features_check>`
       class, this variable identifies distribution features that must exist
       in the current configuration in order for the OpenEmbedded build
       system to build the recipe. In other words, if the
       ``REQUIRED_DISTRO_FEATURES`` variable lists a feature that does not
-      appear in ``DISTRO_FEATURES`` within the current configuration, an
-      error occurs and the build stops.
+      appear in ``DISTRO_FEATURES`` within the current configuration, then
+      the recipe will be skipped, and if the build system attempts to build
+      the recipe then an error will be triggered.
 
    :term:`RM_WORK_EXCLUDE`
       With ``rm_work`` enabled, this variable specifies a list of recipes
diff --git a/poky/documentation/releases.rst b/poky/documentation/releases.rst
index 536c3a6d2..9992f97d5 100644
--- a/poky/documentation/releases.rst
+++ b/poky/documentation/releases.rst
@@ -11,6 +11,7 @@
 - :yocto_docs:`3.1 Documentation </3.1>`
 - :yocto_docs:`3.1.1 Documentation </3.1.1>`
 - :yocto_docs:`3.1.2 Documentation </3.1.2>`
+- :yocto_docs:`3.1.3 Documentation </3.1.3>`
 
 ==========================
  Previous Release Manuals
diff --git a/poky/documentation/sdk-manual/sdk-appendix-obtain.rst b/poky/documentation/sdk-manual/sdk-appendix-obtain.rst
index a51c22e39..eef425bdf 100644
--- a/poky/documentation/sdk-manual/sdk-appendix-obtain.rst
+++ b/poky/documentation/sdk-manual/sdk-appendix-obtain.rst
@@ -4,8 +4,6 @@
 Obtaining the SDK
 *****************
 
-.. _sdk-locating-pre-built-sdk-installers:
-
 Locating Pre-Built SDK Installers
 =================================
 
@@ -248,7 +246,7 @@ Follow these steps to extract the root filesystem:
    installed the toolchain (e.g. ``poky_sdk``).
 
    Following is an example based on the toolchain installed in the
-   ":ref:`sdk-locating-pre-built-sdk-installers`" section:
+   ":ref:`sdk-manual/sdk-appendix-obtain:locating pre-built sdk installers`" section:
    ::
 
       $ source ~/poky_sdk/environment-setup-core2-64-poky-linux
diff --git a/poky/documentation/sdk-manual/sdk-extensible.rst b/poky/documentation/sdk-manual/sdk-extensible.rst
index 5ff75ada2..10e4d2061 100644
--- a/poky/documentation/sdk-manual/sdk-extensible.rst
+++ b/poky/documentation/sdk-manual/sdk-extensible.rst
@@ -24,8 +24,6 @@ alternatively make use of the toolchain directly, for example from
 Makefile and Autotools. See the "`Using the SDK Toolchain
 Directly <#sdk-working-projects>`__" chapter for more information.
 
-.. _sdk-extensible-sdk-intro:
-
 Why use the Extensible SDK and What is in It?
 =============================================
 
@@ -40,8 +38,6 @@ Basically, it contains an SDK environment setup script, some
 configuration files, an internal build system, and the ``devtool``
 functionality.
 
-.. _sdk-installing-the-extensible-sdk:
-
 Installing the Extensible SDK
 =============================
 
@@ -138,8 +134,6 @@ architecture. The example assumes the SDK installer is located in
    Each time you wish to use the SDK in a new shell session, you need to source the environment setup script e.g.
     $ . /home/scottrif/poky_sdk/environment-setup-core2-64-poky-linux
 
-.. _sdk-running-the-extensible-sdk-environment-setup-script:
-
 Running the Extensible SDK Environment Setup Script
 ===================================================
 
@@ -225,8 +219,6 @@ recipes and the source go into a "workspace" directory under the SDK.
 The remainder of this section presents the ``devtool add``,
 ``devtool modify``, and ``devtool upgrade`` workflows.
 
-.. _sdk-use-devtool-to-add-an-application:
-
 Use ``devtool add`` to Add an Application
 -----------------------------------------
 
@@ -401,8 +393,6 @@ command:
       proceed with your work. If you do use this command, realize that
       the source tree is preserved.
 
-.. _sdk-devtool-use-devtool-modify-to-modify-the-source-of-an-existing-component:
-
 Use ``devtool modify`` to Modify the Source of an Existing Component
 --------------------------------------------------------------------
 
@@ -613,8 +603,6 @@ command:
       proceed with your work. If you do use this command, realize that
       the source tree is preserved.
 
-.. _sdk-devtool-use-devtool-upgrade-to-create-a-version-of-the-recipe-that-supports-a-newer-version-of-the-software:
-
 Use ``devtool upgrade`` to Create a Version of the Recipe that Supports a Newer Version of the Software
 -------------------------------------------------------------------------------------------------------
 
@@ -783,8 +771,6 @@ The following diagram shows the common development flow used with the
       proceed with your work. If you do use this command, realize that
       the source tree is preserved.
 
-.. _sdk-a-closer-look-at-devtool-add:
-
 A Closer Look at ``devtool add``
 ================================
 
@@ -826,8 +812,6 @@ the source tree is assumed to be using CMake and is treated accordingly.
 The remainder of this section covers specifics regarding how parts of
 the recipe are generated.
 
-.. _sdk-name-and-version:
-
 Name and Version
 ----------------
 
@@ -851,8 +835,6 @@ incorrect. For such a case, you must reset the recipe:
 After running the ``devtool reset`` command, you need to
 run ``devtool add`` again and provide the name or the version.
 
-.. _sdk-dependency-detection-and-mapping:
-
 Dependency Detection and Mapping
 --------------------------------
 
@@ -887,8 +869,6 @@ following to your recipe:
    dependency with an option that disables the associated functionality
    passed to the configure script.
 
-.. _sdk-license-detection:
-
 License Detection
 -----------------
 
@@ -920,8 +900,6 @@ with development even though the settings are unlikely to be correct in
 all cases. You should check the documentation or source files for the
 software you are building to determine the actual license.
 
-.. _sdk-adding-makefile-only-software:
-
 Adding Makefile-Only Software
 -----------------------------
 
@@ -981,8 +959,6 @@ mind:
    ``ldconfig``. For such cases, you might be able to apply patches that
    remove these commands from the Makefile.
 
-.. _sdk-adding-native-tools:
-
 Adding Native Tools
 -------------------
 
@@ -1009,8 +985,6 @@ following methods when you run ``devtool add``:
    "DASHDASHalso-native" option, you can add the tool using just one
    recipe file.
 
-.. _sdk-adding-node-js-modules:
-
 Adding Node.js Modules
 ----------------------
 
@@ -1053,8 +1027,6 @@ fetches the specified Git repository, detects the code as Node.js code,
 fetches dependencies using ``npm``, and sets
 :term:`SRC_URI` accordingly.
 
-.. _sdk-working-with-recipes:
-
 Working With Recipes
 ====================
 
@@ -1093,8 +1065,6 @@ that most recipes typically need.
 The remainder of this section presents information useful when working
 with recipes.
 
-.. _sdk-finding-logs-and-work-files:
-
 Finding Logs and Work Files
 ---------------------------
 
@@ -1127,8 +1097,6 @@ links created within the source tree:
 You can use these links to get more information on what is happening at
 each build step.
 
-.. _sdk-setting-configure-arguments:
-
 Setting Configure Arguments
 ---------------------------
 
@@ -1155,8 +1123,6 @@ arguments specified through ``EXTRA_OECONF`` or
 the output of the configure script's "DASHDASHhelp" option as a
 reference.
 
-.. _sdk-sharing-files-between-recipes:
-
 Sharing Files Between Recipes
 -----------------------------
 
@@ -1179,8 +1145,6 @@ are cataloged in manifests in order to ensure they can be removed later
 when a recipe is modified or removed. Thus, the sysroot is able to
 remain free from stale files.
 
-.. _sdk-packaging:
-
 Packaging
 ---------
 
@@ -1221,8 +1185,6 @@ you do not even need to set these variables in your recipe unless the
 software the recipe is building installs files into non-standard
 locations.
 
-.. _sdk-restoring-the-target-device-to-its-original-state:
-
 Restoring the Target Device to its Original State
 =================================================
 
@@ -1263,8 +1225,6 @@ target machine.
    and package manager operations on the target device. Doing so could
    result in a conflicting set of files.
 
-.. _sdk-installing-additional-items-into-the-extensible-sdk:
-
 Installing Additional Items Into the Extensible SDK
 ===================================================
 
@@ -1298,8 +1258,6 @@ takes significantly longer than installing the pre-built artifact. Also,
 if no recipe exists for the item you want to add to the SDK, you must
 instead add the item using the ``devtool add`` command.
 
-.. _sdk-applying-updates-to-an-installed-extensible-sdk:
-
 Applying Updates to an Installed Extensible SDK
 ===============================================
 
@@ -1327,8 +1285,6 @@ path_to_update_directory
    The URL needs to point specifically to a published SDK and not to an
    SDK installer that you would download and install.
 
-.. _sdk-creating-a-derivative-sdk-with-additional-components:
-
 Creating a Derivative SDK With Additional Components
 ====================================================
 
diff --git a/poky/documentation/sdk-manual/sdk-intro.rst b/poky/documentation/sdk-manual/sdk-intro.rst
index acb3f455c..ca6138cce 100644
--- a/poky/documentation/sdk-manual/sdk-intro.rst
+++ b/poky/documentation/sdk-manual/sdk-intro.rst
@@ -4,8 +4,6 @@
 Introduction
 ************
 
-.. _sdk-manual-intro:
-
 eSDK Introduction
 =================
 
@@ -127,8 +125,6 @@ script or through a :term:`Build Directory` that is based on
 your metadata configuration or extension for your targeted device. The
 cross-toolchain works with a matching target sysroot.
 
-.. _sysroot:
-
 Sysroots
 --------
 
diff --git a/poky/documentation/sdk-manual/sdk-using.rst b/poky/documentation/sdk-manual/sdk-using.rst
index 4b151e45c..3a1cae773 100644
--- a/poky/documentation/sdk-manual/sdk-using.rst
+++ b/poky/documentation/sdk-manual/sdk-using.rst
@@ -19,8 +19,6 @@ You can use a standard SDK to work on Makefile and Autotools-based
 projects. See the "`Using the SDK Toolchain
 Directly <#sdk-working-projects>`__" chapter for more information.
 
-.. _sdk-standard-sdk-intro:
-
 Why use the Standard SDK and What is in It?
 ===========================================
 
@@ -37,8 +35,6 @@ usage. You can see the directory structure in the "`Installed Standard
 SDK Directory
 Structure <#sdk-installed-standard-sdk-directory-structure>`__" section.
 
-.. _sdk-installing-the-sdk:
-
 Installing the SDK
 ==================
 
@@ -129,8 +125,6 @@ Structure <#sdk-installed-standard-sdk-directory-structure>`__" section
 for more details on the resulting directory structure of the installed
 SDK.
 
-.. _sdk-running-the-sdk-environment-setup-script:
-
 Running the SDK Environment Setup Script
 ========================================
 
diff --git a/poky/documentation/sphinx-static/switchers.js b/poky/documentation/sphinx-static/switchers.js
index b28d91c08..fe9841b10 100644
--- a/poky/documentation/sphinx-static/switchers.js
+++ b/poky/documentation/sphinx-static/switchers.js
@@ -2,7 +2,8 @@
   'use strict';
 
   var all_versions = {
-    'dev': 'dev (3.2)',
+    'dev': 'dev (3.3)',
+    '3.2': '3.2',
     '3.1.3': '3.1.3',
     '3.0.4': '3.0.4',
     '2.7.4': '2.7.4',
diff --git a/poky/documentation/test-manual/test-manual-intro.rst b/poky/documentation/test-manual/test-manual-intro.rst
index 25b79f7a0..b6d130591 100644
--- a/poky/documentation/test-manual/test-manual-intro.rst
+++ b/poky/documentation/test-manual/test-manual-intro.rst
@@ -4,8 +4,6 @@
 The Yocto Project Test Environment Manual
 *****************************************
 
-.. _test-welcome:
-
 Welcome
 =======
 
@@ -45,8 +43,6 @@ engineers:
    Jenkins, or others. This repository has a branch per release of the
    project defining the tests to run on a per release basis.
 
-.. _test-yocto-project-autobuilder-overview:
-
 Yocto Project Autobuilder Overview
 ==================================
 
@@ -88,8 +84,6 @@ topology that includes a controller and a cluster of workers:
 .. image:: figures/ab-test-cluster.png
    :align: center
 
-.. _test-project-tests:
-
 Yocto Project Tests - Types of Testing Overview
 ===============================================
 
@@ -169,8 +163,6 @@ thefollowing types of tests:
    those new versions. If so, this target emails the maintainers with a
    patch to let them know this is possible.
 
-.. _test-test-mapping:
-
 How Tests Map to Areas of Code
 ==============================
 
@@ -326,8 +318,6 @@ directory at ``meta/lib/oeqa/selftest/cases`` directory.
 For oe-selftest. bitbake testcases reside in the ``lib/bb/tests/``
 directory.
 
-.. _bitbake-selftest-example:
-
 ``bitbake-selftest``
 --------------------
 
@@ -354,8 +344,6 @@ Bitbake selftests are straightforward python unittest. Refer to the
 Python unittest documentation for additional information on writing
 these tests at: https://docs.python.org/3/library/unittest.html.
 
-.. _oe-selftest-example:
-
 ``oe-selftest``
 ---------------
 
@@ -399,8 +387,6 @@ builds. There is no data store available for these tests since the tests
 launch the ``bitbake`` command and exist outside of its context. As a
 result, common bitbake library functions (bb.\*) are also unavailable.
 
-.. _testimage-example:
-
 ``testimage``
 -------------
 
@@ -429,8 +415,6 @@ To ensure certain test or package dependencies are met, you can use the
 in this example would only make sense if python3-core is installed in
 the image.
 
-.. _testsdk_ext-example:
-
 ``testsdk_ext``
 ---------------
 
@@ -463,8 +447,6 @@ In this example, the ``devtool``
 command is tested to see whether a sample application can be built with
 the ``devtool build`` command within the eSDK.
 
-.. _testsdk-example:
-
 ``testsdk``
 -----------
 
@@ -488,8 +470,6 @@ In this example, if nativesdk-python3-core has been installed into the SDK, the
 the python3 interpreter with a basic command to check it is working
 correctly. The test would only run if python3 is installed in the SDK.
 
-.. _oe-build-perf-test-example:
-
 ``oe-build-perf-test``
 ----------------------
 
@@ -517,8 +497,6 @@ This example shows how three specific parsing timings are
 measured, with and without various caches, to show how BitBake's parsing
 performance trends over time.
 
-.. _test-writing-considerations:
-
 Considerations When Writing Tests
 =================================
 
diff --git a/poky/documentation/test-manual/test-manual-test-process.rst b/poky/documentation/test-manual/test-manual-test-process.rst
index b0817b091..82b9bb441 100644
--- a/poky/documentation/test-manual/test-manual-test-process.rst
+++ b/poky/documentation/test-manual/test-manual-test-process.rst
@@ -4,8 +4,6 @@
 Project Testing and Release Process
 ***********************************
 
-.. _test-daily-devel:
-
 Day to Day Development
 ======================
 
diff --git a/poky/documentation/test-manual/test-manual-understand-autobuilder.rst b/poky/documentation/test-manual/test-manual-understand-autobuilder.rst
index 244433376..698a266ee 100644
--- a/poky/documentation/test-manual/test-manual-understand-autobuilder.rst
+++ b/poky/documentation/test-manual/test-manual-understand-autobuilder.rst
@@ -73,8 +73,6 @@ The ``config.json`` file is processed by the scripts in the Helper
 repository in the ``scripts`` directory. The following section details
 how this works.
 
-.. _test-autobuilder-target-exec-overview:
-
 Autobuilder Target Execution Overview
 =====================================
 
@@ -135,16 +133,12 @@ roughly consist of:
    This is another call into the Helper scripts where its expected that
    the main functionality of this target will be executed.
 
-.. _test-autobuilder-tech:
-
 Autobuilder Technology
 ======================
 
 The Autobuilder has Yocto Project-specific functionality to allow builds
 to operate with increased efficiency and speed.
 
-.. _test-clobberdir:
-
 clobberdir
 ----------
 
@@ -155,8 +149,6 @@ which is run under ``ionice -c 3``. For example, the deletion only
 happens when there is idle IO capacity on the Worker. The Autobuilder
 Worker Janitor runs this deletion. See :ref:`test-manual/test-manual-understand-autobuilder:Autobuilder Worker Janitor`.
 
-.. _test-autobuilder-clone-cache:
-
 Autobuilder Clone Cache
 -----------------------
 
@@ -167,8 +159,6 @@ during clones first, then "topped up" with later revisions from any
 upstream when necessary. The cache is maintained by the Autobuilder
 Worker Janitor. See :ref:`test-manual/test-manual-understand-autobuilder:Autobuilder Worker Janitor`.
 
-.. _test-autobuilder-worker-janitor:
-
 Autobuilder Worker Janitor
 --------------------------
 
@@ -177,8 +167,6 @@ operations, including background file deletion at IO idle (see :ref:`test-manual
 maintainenance of a cache of cloned repositories to improve the speed
 the system can checkout repositories.
 
-.. _test-shared-dl-dir:
-
 Shared DL_DIR
 -------------
 
@@ -187,8 +175,6 @@ between them. This reduces network accesses from the system and allows
 the build to be sped up. Usage of the directory within the build system
 is designed to be able to be shared over NFS.
 
-.. _test-shared-sstate-cache:
-
 Shared SSTATE_DIR
 -----------------
 
@@ -197,8 +183,6 @@ directory to be shared between them. This means once a Worker has built
 an artifact, all the others can benefit from it. Usage of the directory
 within the directory is designed for sharing over NFS.
 
-.. _test-resulttool:
-
 Resulttool
 ----------
 
@@ -213,8 +197,6 @@ reports of the test results and compare different result files.
 
 For details, see :yocto_wiki:`/wiki/Resulttool`.
 
-.. _test-run-config-tgt-execution:
-
 run-config Target Execution
 ===========================
 
@@ -264,8 +246,6 @@ of post-build steps, including:
    :ref:`test-manual/test-manual-understand-autobuilder:clobberdir` if the build was successful,
    else rename it to "build-renamed" for potential future debugging.
 
-.. _test-deploying-yp-autobuilder:
-
 Deploying Yocto Autobuilder
 ===========================
 
diff --git a/poky/documentation/toaster-manual/toaster-manual-intro.rst b/poky/documentation/toaster-manual/toaster-manual-intro.rst
index 408c6fa3c..e34e7bac4 100644
--- a/poky/documentation/toaster-manual/toaster-manual-intro.rst
+++ b/poky/documentation/toaster-manual/toaster-manual-intro.rst
@@ -10,8 +10,6 @@ enables you to configure and run your builds. Information about builds
 is collected and stored in a database. You can use Toaster to configure
 and start builds on multiple remote build servers.
 
-.. _intro-features:
-
 Toaster Features
 ================
 
@@ -82,8 +80,6 @@ For an overview of Toaster shipped with the Yocto Project &DISTRO;
 Release, see the "`Toaster - Yocto Project
 2.2 <https://youtu.be/BlXdOYLgPxA>`__" video.
 
-.. _toaster-installation-options:
-
 Installation Options
 ====================
 
diff --git a/poky/documentation/toaster-manual/toaster-manual-reference.rst b/poky/documentation/toaster-manual/toaster-manual-reference.rst
index e5e3531e8..2202d599f 100644
--- a/poky/documentation/toaster-manual/toaster-manual-reference.rst
+++ b/poky/documentation/toaster-manual/toaster-manual-reference.rst
@@ -47,8 +47,6 @@ Metadata Index.
    You do not have to use a layer source to use Toaster. Tying into a
    layer source is optional.
 
-.. _layer-source-using-with-toaster:
-
 Setting Up and Using a Layer Source
 -----------------------------------
 
@@ -73,8 +71,6 @@ section in the Yocto Project Overview and Concepts Manual. For information on ho
 to create layers, see the ":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`"
 section in the Yocto Project Development Tasks Manual.
 
-.. _configuring-toaster-to-hook-into-your-layer-source:
-
 Configuring Toaster to Hook Into Your Layer Index
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -143,8 +139,6 @@ Toaster database by running the following command:
 If Toaster can reach the API URL, you should see a message telling you that
 Toaster is updating the layer source information.
 
-.. _toaster-releases:
-
 Releases
 ========
 
@@ -157,8 +151,6 @@ However, you can modify, delete, and create new releases according to
 your needs. This section provides some background information on
 releases.
 
-.. _toaster-releases-supported:
-
 Pre-Configured Releases
 -----------------------
 
@@ -295,8 +287,6 @@ release selection:
       <field type="CharField" name="dirpath">bitbake</field>
    </object>
 
-.. _defining-releases:
-
 Defining Release
 ~~~~~~~~~~~~~~~~
 
@@ -518,8 +508,6 @@ build:
 The JSON data for this query is returned in a single line. In the
 previous example the line has been artificially split for readability.
 
-.. _toaster-useful-commands:
-
 Useful Commands
 ===============
 
@@ -548,8 +536,6 @@ tasks. You can locate these commands in the
       Build Directory. To do so, the ``toastermain/settings.py`` file
       must be configured to point to the correct database backend.
 
-.. _toaster-command-buildslist:
-
 ``buildslist``
 --------------
 
@@ -580,8 +566,6 @@ command would return something like the following::
 
    1: qemux86 poky core-image-minimal
 
-.. _toaster-command-builddelete:
-
 ``builddelete``
 ---------------
 
@@ -600,8 +584,6 @@ Prior to running the ``builddelete`` command, you need to get the ID
 associated with builds by using the
 :ref:`toaster-manual/toaster-manual-reference:\`\`buildslist\`\`` command.
 
-.. _toaster-command-perf:
-
 ``perf``
 --------
 
@@ -615,8 +597,6 @@ follows:
 The command is a sanity check that returns page loading times in order to
 identify performance problems.
 
-.. _toaster-command-checksettings:
-
 ``checksettings``
 -----------------
 
@@ -644,8 +624,6 @@ ready, you can run the following:
 
 After running these commands, you can run the ``checksettings`` command.
 
-.. _toaster-command-runbuilds:
-
 ``runbuilds``
 -------------
 
diff --git a/poky/documentation/toaster-manual/toaster-manual-setup-and-use.rst b/poky/documentation/toaster-manual/toaster-manual-setup-and-use.rst
index 97c5af6a0..b73caac37 100644
--- a/poky/documentation/toaster-manual/toaster-manual-setup-and-use.rst
+++ b/poky/documentation/toaster-manual/toaster-manual-setup-and-use.rst
@@ -121,8 +121,6 @@ can set the ``TOASTER_DIR`` environment variable, which takes precedence
 over your current working directory. Setting this environment variable
 causes Toaster to create and use ``$TOASTER_DIR./_toaster_clones``.
 
-.. _toaster-the-build-directory:
-
 The Build Directory
 ===================
 
@@ -135,8 +133,6 @@ directories to be in a particular location, you can set the
 current working directory. Setting this environment variable causes
 Toaster to use ``$TOASTER_DIR/build`` as the build directory.
 
-.. _toaster-creating-a-django-super-user:
-
 Creating a Django Superuser
 ===========================
 
@@ -186,8 +182,6 @@ You can use the Django administration interface to set Toaster configuration
 parameters such as the build directory, layer sources, default variable
 values, and BitBake versions.
 
-.. _toaster-setting-up-a-production-instance-of-toaster:
-
 Setting Up a Production Instance of Toaster
 ===========================================
 
@@ -197,8 +191,6 @@ instance is also the setup that can handle heavier loads on the web
 service. Use the instructions in the following sections to set up
 Toaster to run builds through the Toaster web interface.
 
-.. _toaster-production-instance-requirements:
-
 Requirements
 ------------
 
@@ -230,8 +222,6 @@ Be sure you meet the following requirements:
 
       $ sudo zypper install apache2 apache2-mod_wsgi-python3 python3-pip mariadb mariadb-client python3-devel
 
-.. _toaster-installation-steps:
-
 Installation
 ------------
 
@@ -504,8 +494,6 @@ The Toaster web interface allows you to do the following:
 -  See performance information such as build time, task time, CPU usage,
    and disk I/O.
 
-.. _web-interface-videos:
-
 Toaster Web Interface Videos
 ----------------------------
 
@@ -551,8 +539,6 @@ Following are several videos that show how to use the Toaster GUI:
    `video <https://www.youtube.com/watch?v=qWGMrJoqusQ>`__ shows the
    build performance data provided by Toaster.
 
-.. _a-note-on-the-local-yocto-project-release:
-
 Additional Information About the Local Yocto Project Release
 ------------------------------------------------------------
 
@@ -604,8 +590,6 @@ them into your Toaster project, using the "Import layer" page.
    :align: center
    :scale: 75%
 
-.. _toaster-web-interface-preferred-version:
-
 Building a Specific Recipe Given Multiple Versions
 --------------------------------------------------
 
diff --git a/poky/documentation/toaster-manual/toaster-manual-start.rst b/poky/documentation/toaster-manual/toaster-manual-start.rst
index 267f9f4cd..888337416 100644
--- a/poky/documentation/toaster-manual/toaster-manual-start.rst
+++ b/poky/documentation/toaster-manual/toaster-manual-start.rst
@@ -9,8 +9,6 @@ Preparing to Use Toaster
 This chapter describes how you need to prepare your system in order to
 use Toaster.
 
-.. _toaster-setting-up-the-basic-system-requirements:
-
 Setting Up the Basic System Requirements
 ========================================
 
@@ -22,8 +20,6 @@ also need to do an additional install of pip3. ::
 
    $ sudo apt-get install python3-pip
 
-.. _toaster-establishing-toaster-system-dependencies:
-
 Establishing Toaster System Dependencies
 ========================================
 
@@ -35,8 +31,6 @@ directory, which is located in the root directory of the
 ``poky/bitbake/toaster-requirements.txt``). The dependencies appear in a
 ``pip``, install-compatible format.
 
-.. _toaster-load-packages:
-
 Install Toaster Packages
 ------------------------
 
diff --git a/poky/documentation/what-i-wish-id-known.rst b/poky/documentation/what-i-wish-id-known.rst
index 593c6fe14..afc126382 100644
--- a/poky/documentation/what-i-wish-id-known.rst
+++ b/poky/documentation/what-i-wish-id-known.rst
@@ -135,7 +135,7 @@ contact us with other suggestions.
    valuable links: :ref:`dev-manual/dev-manual-common-tasks:Using a Development
    Shell` for information on how to build and run a specific task using
    devshell. Also, the :ref:`SDK manual shows how to build out a specific recipe
-   <sdk-devtool-use-devtool-modify-to-modify-the-source-of-an-existing-component>`.
+   <sdk-manual/sdk-extensible:use \`\`devtool modify\`\` to modify the source of an existing component>`.
 
 #. **An ambiguous definition: Package vs Recipe:**
    A recipe contains instructions the build system uses to create