poky: subtree update:c67f57c09e..c6bc20857c
Adrian Freihofer (2):
oe-publish-sdk: fix layers init via ssh
oe-publish-sdk: add --keep-orig option
Alexander Kanavin (68):
meta-selftest: correct the virgl test for 5.8 kernels
bison: upgrade 3.6.4 -> 3.7.1
util-linux: upgrade 2.35.2 -> 2.36
python3-numpy: upgrade 1.19.0 -> 1.19.1
python3-setuptools: upgrade 49.3.1 -> 49.6.0
rsync: upgrade 3.2.2 -> 3.2.3
util-linux: merge .inc into .bb
acpica: upgrade 20200528 -> 20200717
asciidoc: upgrade 9.0.1 -> 9.0.2
cryptodev: upgrade 1.10 -> 1.11
diffoscope: upgrade 153 -> 156
epiphany: upgrade 3.36.3 -> 3.36.4
font-alias: upgrade 1.0.3 -> 1.0.4
gtk+3: upgrade 3.24.21 -> 3.24.22
libcheck: upgrade 0.15.0 -> 0.15.2
libinput: upgrade 1.16.0 -> 1.16.1
libpipeline: upgrade 1.5.2 -> 1.5.3
libx11: upgrade 1.6.9 -> 1.6.11
linux-firmware: upgrade 20200619 -> 20200721
man-pages: upgrade 5.07 -> 5.08
mc: upgrade 4.8.24 -> 4.8.25
mesa: upgrade 20.1.4 -> 20.1.5
piglit: upgrade to latest revision
re2c: upgrade 2.0 -> 2.0.2
sysstat: upgrade 12.2.2 -> 12.4.0
vala: upgrade 0.48.7 -> 0.48.9
bootchart2: update 0.14.8 -> 0.14.9
harfbuzz: convert to meson, enable gobject introspection
pango: update 1.44.7 -> 1.46.0
boost: update 1.73.0 -> 1.74.0
xev: update 1.2.3 -> 1.2.4
wpebackend-fdo: update 1.6.1 -> 1.7.1
gpgme: update 1.13.1 -> 1.14.0
libpsl: update 0.21.0 -> 0.21.1.
gettext: update 0.20.2 -> 0.21
cmake: update 3.17.3 -> 3.18.1
linux-firmware: update 20200721 -> 20200817
meson: update 0.55.0 -> 0.55.1
systemd-boot: bump version to 246.2
json-glib: inherit upstream-version-is-even
packagegroup-core-device-devel: remove
oeqa/x32lib: rework to use readelf from the host
oeqa/multilib: rework to use readelf from the host
oeqa/multilib: un-skip the connman test
poky.conf: do not install packagegroup-core-device-devel into qemu images
glib-2.0: update 2.64.4 -> 2.64.5
cmake: upgrade 3.18.1 -> 3.18.2
libxcrypt: upgrade 4.4.16 -> 4.4.17
debianutils: upgrade 4.11 -> 4.11.1
enchant2: upgrade 2.2.8 -> 2.2.9
harfbuzz: upgrade 2.7.1 -> 2.7.2
libmpc: upgrade 1.1.0 -> 1.2.0
librepo: upgrade 1.12.0 -> 1.12.1
libuv: upgrade 1.38.1 -> 1.39.0
msmtp: upgrade 1.8.11 -> 1.8.12
ninja: upgrade 1.10.0 -> 1.10.1
p11-kit: upgrade 0.23.20 -> 0.23.21
pango: upgrade 1.46.0 -> 1.46.1
re2c: upgrade 2.0.2 -> 2.0.3
resolvconf: upgrade 1.82 -> 1.83
stress-ng: upgrade 0.11.18 -> 0.11.19
gnu-config: update to latest revision
nasm: update 2.15.03 -> 2.15.05
libva-utils: fix upstream version check
gnupg: update 2.2.21 -> 2.2.22
libx11: update 1.6.11 -> 1.6.12
mesa: update 20.1.5 -> 20.1.6
xserver-xorg: update 1.20.8 -> 1.20.9
Andrey Zhizhikin (1):
insane: check for missing update-alternatives inherit
Anibal Limon (1):
recipes-kernel: linux-firmware add qcom-venus-{5.2,5.4} packages
Aníbal Limón (1):
recipes-graphics/xorg-xserver: Add patch to fix segfault when probe
Armin Kuster (2):
bind: update to 9.11.22 ESV
core-image-sato: qemumips use 512 mem
Bruce Ashfield (30):
linux-yocto/5.4: update to v5.4.59
linux-yocto/5.8: update to v5.8.2
yocto-bsp: update to v5.4.56
yocto-bsp: update to v5.4.58
qemu: bump default reference kernel to v5.8
linux-yocto/5.8: fix perf and virtio_scsi warnings
linux-yocto-rt/5.8: fix lttng-modules build
linux-yocto/5.8: selftests/bpf: Prevent runqslower from racing on building bpftool
linux-yocto/5.8: disable CONFIG_NFS_DISABLE_UDP_SUPPORT
poky: set preferred version for linux-yocto to be v5.8
poky-tiny: set preferred version to 5.8
poky: add preferred version for linux-yocto-rt
linux-yocto/5.8: update to v5.8.3
linux-yocto/5.4: update to v5.4.60
kernel: config cleanups for 5.8+
linux-yocto/5.4: update to v5.4.61
linux-yocto/5.8: update to v5.8.4
linux-yocto/5.8: disable IKHEADERS in default builds
kernel-yocto: allow promotion of configuration warnings to errors
kernel-yocto: checksum all modifications to available kernel fragments directories
lttng-modules/devupstream: bump to latest 2.12 commits
linux-yocto-dev: bump to v5.9+
linux-yocto/5.8: update to v5.8.5
kernel-devsrc: account for HOSTCC and HOSTCXX
linux-yocto/config: netfilter: Enable nat for ipv4 and ipv6
linux-yocto/5.8: update to v5.8.8
linux-yocto/5.4: update to v5.4.64
linux-yocto/config: configuration warning cleanup
linux-yocto/5.8: update to v5.8.9
linux-yocto/5.4: update to v5.4.65
Changhyeok Bae (2):
iw: upgrade 5.4 -> 5.8
iputils: upgrade s20190709 -> s20200821
Chris Laplante (12):
bitbake: compat.py: remove file since it no longer actually implements anything
bitbake: COW: formatting
bitbake: COW: migrate test suite into tests/cow
cve-update-db-native: add progress handler
cve-check/cve-update-db-native: use lockfile to fix usage under multiconfig
cve-update-db-native: use context manager for cve_f
cve-check: avoid FileNotFoundError if no do_cve_check task has run
bitbake: utils: process_profilelog: use context manager
bitbake: utils: fix UnboundLocalError when _print_exception raises
cve-update-db-native: be less magical about checking whether the cve-check class is enabled
cve-update-db-native: move -journal checking into do_fetch
cve-update-db-native: remove unused variable
Christophe GUIBOUT (1):
initramfs-framework: support kernel cmdline with double quotes
Denys Dmytriyenko (2):
weston: upgrade 8.0.0 -> 9.0.0
cryptodev: bump 1 commit past 1.11 to fix 5.9-rc1+
Diego Sueiro (2):
license_image.bbclass: Create symlink to the image license manifest dir
license_image.bbclass: Fix symlink to the image license manifest dir creation
Douglas Royds (1):
tcmode-default: Drop gcc-cross-initial, gcc-crosssdk-initial references
Frazer Clews (1):
bitbake: lib: fix most undefined code picked up by pylint
Geoff Parker (1):
systemd-serialgetty: Replace sed quoting using ' with " to allow var expansion
Jacob Kroon (1):
gcc10: Don't default back to -fcommon
Jean-Francois Dagenais (1):
bitbake: siggen: clean_basepath: remove recipe full path when virtual:xyz present
Jens Rehsack (1):
lttng-modules: backport patches from 2.12.x to fix 5.4.64+ and 5.8.9+ builds
Joe Slater (1):
pseudo: fix renaming to self
Jon Mason (4):
cortex-m0plus.inc: change file permissions
tune-cortexa55.inc: clean-up ARMv8.2a uses
tune-cortexa57-cortexa53.inc: add CRC and set march
tune-cortexa*: Cleanups
Joshua Watt (8):
wic: Add 512 Byte alignment to --offset
oeqa: runtime_tests: Extra GPG debugging
oeqa: sdk: Capture stderr output
oeqa: reproducible: Fix test not producing diffs
diffoscope: upgrade 156 -> 158
bitbake: bitbake: Add parsing torture test
bitbake: cooker: Block SIGINT in worker processes
sphinx: dev-manual: Clarify that virtual providers do not apply to runtime dependencies
Kai Kang (1):
dhcpcd: 9.1.4 -> 9.2.0
Kevin Hao (1):
meta-yocto-bsp: Bump to the v5.8 kernel
Khairul Rohaizzat Jamaluddin (1):
wic/bootimg-efi: IMAGE_EFI_BOOT_FILES variable added to separate bootimg-efi and bootimg-partition
Khem Raj (24):
gcc-cross-canadian: Install gcc/g++ wrappers for musl
uninative: Upgrade to 2.9
packagegroup-core-tools-profile: Disable lttng-modules for riscv64
lttng-modules: Disable on riscv64
kexec-tools: Fix build with -fno-common on ppc
lttng-tools: Do not build for riscv64
util-linux: Allow update alternatives for additional apps
lttng-tools: lttng-ust works on riscv64
json-glib: Backport a build fix with clang
rpcbind: Use update-alternatives for rpcinfo
go: Upgrade to 1.15 major release
weston-init: Redefine weston service and add socket activation option
musl: Upgrade to latest master
libucontext: Recognise riscv32 architecture
linuxloader.bbclass: Define riscv32 ldso for musl
populate_sdk_ext: Do not assume local.conf will always exist
weston: plane_add_prop() calls break musl atomic modesetting
weston-init: Enable RDP screen share
weston-init: Do not use fbdev backend
weston-init: Select drm/fbdev backends for qemu machines
oeqa/weston: Fix tests to run with systemd
core-image-weston: Bump qemu memory to 512M
go: Update to 1.15.2 minor release
bind: Inherit update-alternatives
Mark Hatle (6):
package_tar.bbclass: Sync to the other package_* classes
kernel.bbclass: Remove do_install[prefunc] no longer needed
buildhistory.bbclass: Rework to use read_subpackage_metadata
kernel.bbclass: Move away from calling package_get_auto_pr
package.bbclass: hash equivalency and pr service
bitbake: process.py: Handle SystemExit exception to eliminate backtrace
Mark Morton (1):
sphinx: test-manual code block, link, and format update
Martin Jansa (7):
devtool: expand SRC_URI when guessing recipe update mode
image-artifact-names: introduce new bbclass and move some variables into it
kernel.bbclass: use bash variables like imageType, base_name without {}
kernel.bbclass: eliminate (initramfs_)symlink_name variables
kernel.bbclass: use camelCase notation for bash variables in do_deploy
*-initramfs: don't use .rootfs IMAGE_NAME_SUFFIX
bitbake.conf: use ${TCMODE}-${TCLIBC} directory for CACHE
Matt Madison (1):
image.bbclass: fix REPRODUCIBLE_TIMESTAMP_ROOTFS reference
Michael Gloff (2):
sysvinit rc: Use PSPLASH_FIFO_DIR for progress fifo
sysvinit: Remove ${B} assignment
Michael Tretter (1):
devtool: deploy-target: Fix size calculation for hard links
Ming Liu (2):
systemd: split systemd specific udev rules into its own package
libubootenv: inherit uboot-config
Mingli Yu (3):
qemu: always define unknown_lock_type
qemu: override DEBUG_BUILD
bison: remove the parallel build patch
Naveen Saini (1):
lib/oe/recipeutils.py: add support for BBFILES_DYNAMIC
Nicolas Dechesne (73):
linux-libc-headers: kernel headers are installed in STAGING_KERNEL_BUILDDIR
bitbake: sphinx: add initial build infrastructure
bitbake: sphinx: initial sphinx support
bitbake: sphinx: bitbake-user-manual: use builtin sphinx glossary
bitbake: sphinx: switch to readthedocs theme
bitbake: sphinx: override theme CSS
bitbake: sphinx: fixup for links
bitbake: sphinx: fix links inside notes
bitbake: sphinx: fixes all remaining warnings
bitbake: sphinx: Makefile.sphinx: add clean and publish targets
bitbake: sphinx: tweak html output a bit
bitbake: sphinx: add SPDX headers
bitbake: sphinx: index: move the boilerplate at the end of the page
bitbake: sphinx: conf: enable extlinks extension
bitbake: sphinx: add releases page
bitbake: sphinx: bitbake-user-manual: insert additional blank line after title
bitbake: sphinx: last manual round of fixes/improvements
bitbake: sphinx: update style for important, caution and warnings
bitbake: sphinx: remove leading '/'
bitbake: sphinx: theme_override: properly set font for verbatim text
bitbake: bitbake-user-manual: fix bad links
sphinx: add initial build infrastructure
sphinx: initial sphinx support
sphinx: ref-variables: use builtin sphinx glossary
sphinx: overview-manual: add figures
sphinx: switch to readthedocs theme
sphinx: Add SPDX license headers
sphinx: add CSS theme override
sphinx: bsp-guide: add figures
sphinx: add Yocto project logo
sphinx: conf: update copyright
sphinx: conf: add substitutions/global variables
sphinx: add boilerplate file
sphinx: add boilerplate to manuals
sphinx: ref-manual: add revision history table
sphinx: add a general index
sphinx: conf.py: enable sphinx.ext.autosectionlabel
sphinx: ref-manual: use builtin glossary for the Terms section
sphinx: fix internal links
sphinx: ref-manual: fix typo
sphinx: fix custom term links
sphinx: manual updates for some links
sphinx: dev-manual add figures
sphinx: kernel-dev: add figures
sphinx: profile-manual: add figures
sphinx: fix up bold text for informalexample container
sphinx: ref-manual: add figures
sphinx: sdk-manual: add figures
sphinx: test-manual: add figures
sphinx: toaster-manual: add figures
sphinx: add links for Yocto project website
sphinx: fix links when the link text should be displayed
sphinx: add links to terms in the BitBake glossary
sphinx: add links to section in the Bitbake manual
sphinx: setup extlink for docs.yoctoproject.org
sphinx: enable intersphinx extension
sphinx: insert blank below between title and toc
sphinx: fix up terms related to kernel-fitimage
sphinx: conf: a few rendering tweaks
sphinx: makefile: add publish target
sphinx: conf: include CSS/JS files, the proper way
sphinx: convert 'what I wish I'd known'
sphinx: convert 'transitioning to a custom environment'
sphinx: ref-manual: fix heading for oe-init-build-env
sphinx: brief-yoctoprojectqs: fix up all remaining rendering issues
sphinx: Makefile.sphinx improvements
sphinx: convert bsp-guide
sphinx: remove leading '/'
sphinx: update style for important, caution and warnings
sphinx: profile-manual: convert profile-manual
sphinx: theme_override: properly set font for verbatim text
sphinx: theme_override: add tying-it-together admonition
sphinx: conf: exclude adt-manual/*.rst
Oleksandr Kravchuk (1):
ell: update to 0.33
Ovidiu Panait (1):
libxml2: Fix CVE-2020-24977
Peter A. Bigot (2):
bluez5: fix builds that require ell support
timezone: include leap second data in tzdata-core
Peter Bergin (1):
systemd: avoid failing if no udev rules provided
Pierre-Jean Texier (2):
libubootenv: upgrade 0.3 -> 0.3.1
diffoscope: upgrade 158 -> 160
Quentin Schulz (16):
sphinx: brief-yoctoprojectqs: remove redundant welcome
sphinx: brief-yoctoprojectqs: fix ambiguous note for cyclone5 example
sphinx: brief-yoctoprojectqs: add missing boilerplate
sphinx: overview-manual: add link to AUH how-to section
sphinx: overview-manual: fix bitbake basic explanation
sphinx: brief-yoctoprojectqs: add note on branch consistency between layers
sphinx: what-i-wish-id-known: update "don't be fooled by doc search results"
sphinx: overview-manual: remove highlight in bold section
sphinx: replace special quotes with single and double quotes
sphinx: fix incorrect indentations
sphinx: brief-yoctoprojectqs: put other distros note after Ubuntu-specific packages
sphinx: fix a few typos or missing/too many words
sphinx: "highlight" some variables, tasks or files
sphinx: fix or add missing links and remove mention of Eclipse workflow
ref-manual: examples: hello-autotools: upgrade to 2.10
ref-manual: examples: libxpm: add relative path to .inc
Rahul Kumar (1):
systemd-serialgetty: Fix sed expression quoting
Rasmus Villemoes (1):
kernel.bbclass: run do_symlink_kernsrc before do_patch
Richard Purdie (74):
nativesdk-sdk-provides-dummy: Add /bin/sh
bitbake: fetch2/wget: Remove buffering parameter
bitbake: cooker: Ensure parse_quit thread is closed down
bitbake: cooker: Explictly shut down the sync thread
bitbake: fetch2: Drop cups.org from wget status checks
bitbake: build/msg: Cleanup verbose option handling
bitbake: cooker/cookerdata/main: Improve loglevel handling
bitbake: cookerdata: Ensure UI options are updated to the server
bitbake: cooker/cookerdata: Ensure UI event log is updated from commandline
bitbake: cooker: Defer configuration init to after UI connection
bitbake: server/process: Move the socket code to server process only
bitbake: main/server/process: Drop configuration object passing
bitbake: cooker: Ensure BB_ORIGENV is updated by changes to configuration.env
bitbake: server/process: Log extra threads at exit
bitbake: server/process: Add bitbake-server and exec() a new server process
bitbake: runqueue: Don't use sys.argv
bitbake: cooker: Ensure cooker's enviroment is updated on updateConfig
connman-gnome/matchbox-desktop: Remove file:// globbing
selftest/recipetool: Drop globbing SRC_URI test, no longer supported
local.conf.sample: Document memory resident bitbake
bitbake: fetch2: Drop globbing supprt in file:// SRC_URIs
bitbake: server/process: Use sys.executable for bitbake-server
bitbake: process: Avoid bb.utils.timeout
bitbake: utils: Drop broken timeout function
bitbake: server/process: Fix typo in code causing tracebacks
oeqa/selftest: Apply patch to fix cpio build with -fno-common
runqemu: Show an error for conflicting graphics options
lttng: Move platform logic to dedicated inc file
patchelf: upgrade 0.11 -> 0.12
build-appliance/packagegroup-core-base-utils: Replace dhcp-client/dhcp-server with dhcpcd/kea
selftest/prservice: Improve test failure message
iputils: Adapt ${PN}-tftpd package dependency to PACKAGECONFIG
bitbake: process/knotty: Improve early exception handling
bitbake: cooker/cookerdata: Use BBHandledException, not sys.exit()
bitbake: cookerdata: Fix exception raise statements
bitbake: process: Avoid printing binary strings for leftover processes
bitbake: server/process: Ensure logging is flushed
bitbake: server/process: Don't show tracebacks if the lockfile is removed
bitbake: cooker: Ensure parser replacement calls parser final_cleanup
bitbake: cooker: Assign a name to the sync thread to aid debugging
bitbake: server/process: Ensure we don't keep looping if some other server is started
bitbake: server/process: Prefix the log data with pid/time information
bitbake: server/process: Note when commands complete in logs
bitbake: cooker: Ensure parser is cleaned up
runqemu: Add a hook to allow it to renice
bitbake: cooker: Avoid parser deadlocks
bitbake: cooker: Ensure parser worker signal handlers are default
selftest/signing: Ensure build path relocation is safe
oeqa/concurrencytest: Improve builddir path manipulations
bitbake: cooker/command: Fix disconnection handling
bitbake: tinfoil: Ensure sockets don't leak even when exceptions occur
bitbake: tests/fetch: Move away from problematic freedesktop.org urls
bitbake: sphinx: Enhance the sphinx experience/nagivation with:
bitbake: sphinx: theme_override: Use bold for emphasis text
Revert "qemu: always define unknown_lock_type"
Revert "core-image-sato: qemumips use 512 mem"
sphinx: Organize top level docs
sphinx: releases.rst: Add index/links to docs for previous releases
sphinx: boilerplate.rst: Drop versions notes as we have better navigation now
sphinx: boilerplate.rst: Sphinx puts the copyright elsewhere
sphinx: history: Move revision history to its own section
sphinx: manuals: Move boilerplate after toctree
sphinx: Add support for multiple docs version
sphinx: index.rst: Fix links
sphinx: ref-system-requirements: Improve formatting of the notes sections, merging them
sphinx: ref-manual links fixes and many other cleanups to import
sphinx: dev-manual: Various URL, code block and other fixes to imported data
sphinx: sdk-manual: Various URL, code block and other fixes to imported data
sphinx: kernel-dev: Various URL, code block and other fixes to imported data
sphinx: theme_override: Use bold for emphasis text
sphinx: ref-tasks: Add populate_sdk_ext task definition
sphinx: ref-manual/migration: Split each release into its own file
sphinx: overview-manual: Various URL, code block and other fixes to imported data
build-appliance-image: Update to master head revision
Robert Yang (3):
bitbake: cooker.py: Save prioritized BBFILES to BBFILES_PRIORITIZED
bitbake: utils.py: get_file_layer(): Exit the loop when file is matched
bitbake: utils.py: get_file_layer(): Improve performance
Ross Burton (25):
package.bbclass: explode the RPROVIDES so we don't think the versions are provides
elfutils: silence a new QA warning
insane: improve gnu-hash-style warning
gdk-pixbuf: add tests PACKAGECONFIG
debianutils: change SRC_URI to use snapshot.debian.org
insane: only load real files as ELF
autoconf: consolidate SRC_URI
autoconf: consolidate DEPENDS
kea: no need to depend on kea-native
kea: don't use PACKAGECONFIG inappropriately
kea: bump to 1.7.10
help2man: rewrite recipe
local.conf.sample.extended: remove help2man reference
curl: add vendors to CVE_PRODUCT to exclude false positives
harfbuzz: update patch status
harfbuzz: fix a build race around hb-version.h
cmake: whitelist CVE-2016-10642
ncurses: remove config.cache
qemu: fix CVE-2020-14364
cve-update-db-native: remove unused import
cve-update-db-native: add more logging when fetching
cve-update-db-native: use fetch task
alsa-plugins: improve .la removal
sato-screenshot: improve .la removal
buildhistory-diff: use BUILDDIR to know where buildhistory is
Saul Wold (1):
gnupg: uprev 2.2.22 -> 2.2.23
Stacy Gaikovaia (2):
bison: uprev from 3.7.1 to 3.7.2
valgrind: fix memcheck vgtests remove fullpath-after flags
Steve Sakoman (1):
xinput-calibrator: change SRC_URI to branch with libinput support
Sumit Garg (1):
insane: fix gnu-hash-style check
TeohJayShen (1):
oeqa/runtime: add test for matchbox-terminal
Tim Orling (1):
sphinx: toaster-manual: fix vars, links, code blocks
Vijai Kumar K (2):
image_types_wic: Add ASSUME_PROVIDED to WICVARS
wic: misc: Add /bin to the list of searchpaths
Yanfei Xu (1):
kernel-yocto: only replace leading -I in include paths
Yi Zhao (1):
glib-networking: add ptest
Zhixiong Chi (1):
gnutls: CVE-2020-24659
akuster (8):
log4cplus: move meta-oe pkg to core
kea: Move from meta-networking
maintainers.inc: Add me as kea & log4plus maintainer.
dhcpcd: Move from meta-network as OE-Core needs a client
maintainers.inc: Add me as dhcpcd maintainer
dhcp: remove from core
bind: Add 9.16.x
bind: 9.11 remove
hongxu (1):
sysstat: fix installed-vs-shipped QA Issue in systemd
zangrc (4):
libcap:upgrade 2.42 -> 2.43
libcap-ng:upgrade 0.7.10 -> 0.7.11
libgpg-error:upgrade 1.38 -> 1.39
at-spi2-core:upgrade 2.36.0 -> 2.36.1
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
Change-Id: I5542f5eea751a2641342e945725fd687cd74bebe
diff --git a/poky/documentation/test-manual/history.rst b/poky/documentation/test-manual/history.rst
new file mode 100644
index 0000000..76d4309
--- /dev/null
+++ b/poky/documentation/test-manual/history.rst
@@ -0,0 +1,16 @@
+.. SPDX-License-Identifier: CC-BY-2.0-UK
+
+***********************
+Manual Revision History
+***********************
+
+.. list-table::
+ :widths: 10 15 40
+ :header-rows: 1
+
+ * - Revision
+ - Date
+ - Note
+ * - 3.2
+ - October 2020
+ - The initial document released with the Yocto Project 3.2 Release
diff --git a/poky/documentation/test-manual/test-manual-intro.rst b/poky/documentation/test-manual/test-manual-intro.rst
new file mode 100644
index 0000000..53ad650
--- /dev/null
+++ b/poky/documentation/test-manual/test-manual-intro.rst
@@ -0,0 +1,550 @@
+.. SPDX-License-Identifier: CC-BY-2.0-UK
+
+*****************************************
+The Yocto Project Test Environment Manual
+*****************************************
+
+.. _test-welcome:
+
+Welcome
+=======
+
+Welcome to the Yocto Project Test Environment Manual! This manual is a
+work in progress. The manual contains information about the testing
+environment used by the Yocto Project to make sure each major and minor
+release works as intended. All the project's testing infrastructure and
+processes are publicly visible and available so that the community can
+see what testing is being performed, how it's being done and the current
+status of the tests and the project at any given time. It is intended
+that Other organizations can leverage off the process and testing
+environment used by the Yocto Project to create their own automated,
+production test environment, building upon the foundations from the
+project core.
+
+Currently, the Yocto Project Test Environment Manual has no projected
+release date. This manual is a work-in-progress and is being initially
+loaded with information from the README files and notes from key
+engineers:
+
+- *yocto-autobuilder2:* This
+ :yocto_git:`README.md </cgit.cgi/yocto-autobuilder2/tree/README.md>`
+ is the main README which detials how to set up the Yocto Project
+ Autobuilder. The ``yocto-autobuilder2`` repository represents the
+ Yocto Project's console UI plugin to Buildbot and the configuration
+ necessary to configure Buildbot to perform the testing the project
+ requires.
+
+- *yocto-autobuilder-helper:* This :yocto_git:`README </cgit.cgi/yocto-autobuilder-helper/tree/README/>`
+ and repository contains Yocto Project Autobuilder Helper scripts and
+ configuration. The ``yocto-autobuilder-helper`` repository contains
+ the "glue" logic that defines which tests to run and how to run them.
+ As a result, it can be used by any Continuous Improvement (CI) system
+ to run builds, support getting the correct code revisions, configure
+ builds and layers, run builds, and collect results. The code is
+ independent of any CI system, which means the code can work `Buildbot <https://docs.buildbot.net/0.9.15.post1/>`__,
+ 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
+==================================
+
+The Yocto Project Autobuilder collectively refers to the software,
+tools, scripts, and procedures used by the Yocto Project to test
+released software across supported hardware in an automated and regular
+fashion. Basically, during the development of a Yocto Project release,
+the Autobuilder tests if things work. The Autobuilder builds all test
+targets and runs all the tests.
+
+The Yocto Project uses now uses standard upstream
+`Buildbot <https://docs.buildbot.net/0.9.15.post1/>`__ (version 9) to
+drive its integration and testing. Buildbot Nine has a plug-in interface
+that the Yocto Project customizes using code from the
+``yocto-autobuilder2`` repository, adding its own console UI plugin. The
+resulting UI plug-in allows you to visualize builds in a way suited to
+the project's needs.
+
+A ``helper`` layer provides configuration and job management through
+scripts found in the ``yocto-autobuilder-helper`` repository. The
+``helper`` layer contains the bulk of the build configuration
+information and is release-specific, which makes it highly customizable
+on a per-project basis. The layer is CI system-agnostic and contains a
+number of Helper scripts that can generate build configurations from
+simple JSON files.
+
+.. note::
+
+ The project uses Buildbot for historical reasons but also because
+ many of the project developers have knowledge of python. It is
+ possible to use the outer layers from another Continuous Integration
+ (CI) system such as
+ `Jenkins <https://en.wikipedia.org/wiki/Jenkins_(software)>`__
+ instead of Buildbot.
+
+The following figure shows the Yocto Project Autobuilder stack with a
+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
+===============================================
+
+The Autobuilder tests different elements of the project by using
+thefollowing types of tests:
+
+- *Build Testing:* Tests whether specific configurations build by
+ varying :term:`MACHINE`,
+ :term:`DISTRO`, other configuration
+ options, and the specific target images being built (or world). Used
+ to trigger builds of all the different test configurations on the
+ Autobuilder. Builds usually cover many different targets for
+ different architectures, machines, and distributions, as well as
+ different configurations, such as different init systems. The
+ Autobuilder tests literally hundreds of configurations and targets.
+
+ - *Sanity Checks During the Build Process:* Tests initiated through
+ the :ref:`insane <ref-classes-insane>`
+ class. These checks ensure the output of the builds are correct.
+ For example, does the ELF architecture in the generated binaries
+ match the target system? ARM binaries would not work in a MIPS
+ system!
+
+- *Build Performance Testing:* Tests whether or not commonly used steps
+ during builds work efficiently and avoid regressions. Tests to time
+ commonly used usage scenarios are run through ``oe-build-perf-test``.
+ These tests are run on isolated machines so that the time
+ measurements of the tests are accurate and no other processes
+ interfere with the timing results. The project currently tests
+ performance on two different distributions, Fedora and Ubuntu, to
+ ensure we have no single point of failure and can ensure the
+ different distros work effectively.
+
+- *eSDK Testing:* Image tests initiated through the following command::
+
+ $ bitbake image -c testsdkext
+
+ The tests utilize the ``testsdkext`` class and the ``do_testsdkext`` task.
+
+- *Feature Testing:* Various scenario-based tests are run through the
+ :ref:`OpenEmbedded Self test (oe-selftest) <ref-manual/ref-release-process:Testing and Quality Assurance>`. We test oe-selftest on each of the main distrubutions
+ we support.
+
+- *Image Testing:* Image tests initiated through the following command::
+
+ $ bitbake image -c testimage
+
+ The tests utilize the :ref:`testimage* <ref-classes-testimage*>`
+ classes and the :ref:`ref-tasks-testimage` task.
+
+- *Layer Testing:* The Autobuilder has the possibility to test whether
+ specific layers work with the test of the system. The layers tested
+ may be selected by members of the project. Some key community layers
+ are also tested periodically.
+
+- *Package Testing:* A Package Test (ptest) runs tests against packages
+ built by the OpenEmbedded build system on the target machine. See the
+ :ref:`Testing Packages With
+ ptest <dev-manual/dev-manual-common-tasks:Testing Packages With ptest>` section
+ in the Yocto Project Development Tasks Manual and the
+ ":yocto_wiki:`Ptest </wiki/Ptest>`" Wiki page for more
+ information on Ptest.
+
+- *SDK Testing:* Image tests initiated through the following command::
+
+ $ bitbake image -c testsdk
+
+ The tests utilize the :ref:`testsdk <ref-classes-testsdk>` class and
+ the ``do_testsdk`` task.
+
+- *Unit Testing:* Unit tests on various components of the system run
+ through :ref:`bitbake-selftest <ref-manual/ref-release-process:Testing and Quality Assurance>` and
+ :ref:`oe-selftest <ref-manual/ref-release-process:Testing and Quality Assurance>`.
+
+- *Automatic Upgrade Helper:* This target tests whether new versions of
+ software are available and whether we can automatically upgrade to
+ 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
+==============================
+
+Tests map into the codebase as follows:
+
+- *bitbake-selftest:*
+
+ These tests are self-contained and test BitBake as well as its APIs,
+ which include the fetchers. The tests are located in
+ ``bitbake/lib/*/tests``.
+
+ From within the BitBake repository, run the following::
+
+ $ bitbake-selftest
+
+ To skip tests that access the Internet, use the ``BB_SKIP_NETTEST``
+ variable when running "bitbake-selftest" as follows::
+
+ $ BB_SKIP_NETTEST=yes bitbake-selftest
+
+ The default output is quiet and just prints a summary of what was
+ run. To see more information, there is a verbose option::
+
+ $ bitbake-selftest -v
+
+ Use this option when you wish to skip tests that access the network,
+ which are mostly necessary to test the fetcher modules. To specify
+ individual test modules to run, append the test module name to the
+ "bitbake-selftest" command. For example, to specify the tests for the
+ bb.data.module, run::
+
+ $ bitbake-selftest bb.test.data.module
+
+ You can also specify individual tests by defining the full name and module
+ plus the class path of the test, for example::
+
+ $ bitbake-selftest bb.tests.data.TestOverrides.test_one_override
+
+ The tests are based on `Python
+ unittest <https://docs.python.org/3/library/unittest.html>`__.
+
+- *oe-selftest:*
+
+ - These tests use OE to test the workflows, which include testing
+ specific features, behaviors of tasks, and API unit tests.
+
+ - The tests can take advantage of parallelism through the "-j"
+ option, which can specify a number of threads to spread the tests
+ across. Note that all tests from a given class of tests will run
+ in the same thread. To parallelize large numbers of tests you can
+ split the class into multiple units.
+
+ - The tests are based on Python unittest.
+
+ - The code for the tests resides in
+ ``meta/lib/oeqa/selftest/cases/``.
+
+ - To run all the tests, enter the following command::
+
+ $ oe-selftest -a
+
+ - To run a specific test, use the following command form where
+ testname is the name of the specific test::
+
+ $ oe-selftest -r <testname>
+
+ For example, the following command would run the tinfoil
+ getVar API test::
+
+ $ oe-selftest -r tinfoil.TinfoilTests.test_getvar
+
+ It is also possible to run a set
+ of tests. For example the following command will run all of the
+ tinfoil tests::
+
+ $ oe-selftest -r tinfoil
+
+- *testimage:*
+
+ - These tests build an image, boot it, and run tests against the
+ image's content.
+
+ - The code for these tests resides in ``meta/lib/oeqa/runtime/cases/``.
+
+ - You need to set the :term:`IMAGE_CLASSES` variable as follows::
+
+ IMAGE_CLASSES += "testimage"
+
+ - Run the tests using the following command form::
+
+ $ bitbake image -c testimage
+
+- *testsdk:*
+
+ - These tests build an SDK, install it, and then run tests against
+ that SDK.
+
+ - The code for these tests resides in ``meta/lib/oeqa/sdk/cases/``.
+
+ - Run the test using the following command form::
+
+ $ bitbake image -c testsdk
+
+- *testsdk_ext:*
+
+ - These tests build an extended SDK (eSDK), install that eSDK, and
+ run tests against the eSDK.
+
+ - The code for these tests resides in ``meta/lib/oeqa/esdk``.
+
+ - To run the tests, use the following command form::
+
+ $ bitbake image -c testsdkext
+
+- *oe-build-perf-test:*
+
+ - These tests run through commonly used usage scenarios and measure
+ the performance times.
+
+ - The code for these tests resides in ``meta/lib/oeqa/buildperf``.
+
+ - To run the tests, use the following command form::
+
+ $ oe-build-perf-test <options>
+
+ The command takes a number of options,
+ such as where to place the test results. The Autobuilder Helper
+ Scripts include the ``build-perf-test-wrapper`` script with
+ examples of how to use the oe-build-perf-test from the command
+ line.
+
+ Use the ``oe-git-archive`` command to store test results into a
+ Git repository.
+
+ Use the ``oe-build-perf-report`` command to generate text reports
+ and HTML reports with graphs of the performance data. For
+ examples, see
+ :yocto_dl:`/releases/yocto/yocto-2.7/testresults/buildperf-centos7/perf-centos7.yoctoproject.org_warrior_20190414204758_0e39202.html`
+ and
+ :yocto_dl:`/releases/yocto/yocto-2.7/testresults/buildperf-centos7/perf-centos7.yoctoproject.org_warrior_20190414204758_0e39202.txt`.
+
+ - The tests are contained in ``lib/oeqa/buildperf/test_basic.py``.
+
+Test Examples
+=============
+
+This section provides example tests for each of the tests listed in the
+:ref:`test-manual/test-manual-intro:How Tests Map to Areas of Code` section.
+
+For oeqa tests, testcases for each area reside in the main test
+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``
+--------------------
+
+A simple test example from ``lib/bb/tests/data.py`` is::
+
+ class DataExpansions(unittest.TestCase):
+ def setUp(self):
+ self.d = bb.data.init()
+ self.d["foo"] = "value_of_foo"
+ self.d["bar"] = "value_of_bar"
+ self.d["value_of_foo"] = "value_of_'value_of_foo'"
+
+ def test_one_var(self):
+ val = self.d.expand("${foo}")
+ self.assertEqual(str(val), "value_of_foo")
+
+In this example, a ``DataExpansions`` class of tests is created,
+derived from standard python unittest. The class has a common ``setUp``
+function which is shared by all the tests in the class. A simple test is
+then added to test that when a variable is expanded, the correct value
+is found.
+
+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``
+---------------
+
+These tests are more complex due to the setup required behind the scenes
+for full builds. Rather than directly using Python's unittest, the code
+wraps most of the standard objects. The tests can be simple, such as
+testing a command from within the OE build environment using the
+following example::
+
+ class BitbakeLayers(OESelftestTestCase):
+ def test_bitbakelayers_showcrossdepends(self):
+ result = runCmd('bitbake-layers show-cross-depends')
+ self.assertTrue('aspell' in result.output, msg = "No dependencies were shown. bitbake-layers show-cross-depends output: %s"% result.output)
+
+This example, taken from ``meta/lib/oeqa/selftest/cases/bblayers.py``,
+creates a testcase from the ``OESelftestTestCase`` class, derived
+from ``unittest.TestCase``, which runs the ``bitbake-layers`` command
+and checks the output to ensure it contains something we know should be
+here.
+
+The ``oeqa.utils.commands`` module contains Helpers which can assist
+with common tasks, including:
+
+- *Obtaining the value of a bitbake variable:* Use
+ ``oeqa.utils.commands.get_bb_var()`` or use
+ ``oeqa.utils.commands.get_bb_vars()`` for more than one variable
+
+- *Running a bitbake invocation for a build:* Use
+ ``oeqa.utils.commands.bitbake()``
+
+- *Running a command:* Use ``oeqa.utils.commandsrunCmd()``
+
+There is also a ``oeqa.utils.commands.runqemu()`` function for launching
+the ``runqemu`` command for testing things within a running, virtualized
+image.
+
+You can run these tests in parallel. Parallelism works per test class,
+so tests within a given test class should always run in the same build,
+while tests in different classes or modules may be split into different
+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``
+-------------
+
+These tests are run once an image is up and running, either on target
+hardware or under QEMU. As a result, they are assumed to be running in a
+target image environment, as opposed to a host build environment. A
+simple example from ``meta/lib/oeqa/runtime/cases/python.py`` contains
+the following::
+
+ class PythonTest(OERuntimeTestCase):
+ @OETestDepends(['ssh.SSHTest.test_ssh'])
+ @OEHasPackage(['python3-core'])
+ def test_python3(self):
+ cmd = "python3 -c \\"import codecs; print(codecs.encode('Uryyb, jbeyq', 'rot13'))\""
+ status, output = self.target.run(cmd)
+ msg = 'Exit status was not 0. Output: %s' % output
+ self.assertEqual(status, 0, msg=msg)
+
+In this example, the ``OERuntimeTestCase`` class wraps
+``unittest.TestCase``. Within the test, ``self.target`` represents the
+target system, where commands can be run on it using the ``run()``
+method.
+
+To ensure certain test or package dependencies are met, you can use the
+``OETestDepends`` and ``OEHasPackage`` decorators. For example, the test
+in this example would only make sense if python3-core is installed in
+the image.
+
+.. _testsdk_ext-example:
+
+``testsdk_ext``
+---------------
+
+These tests are run against built extensible SDKs (eSDKs). The tests can
+assume that the eSDK environment has already been setup. An example from
+``meta/lib/oeqa/sdk/cases/devtool.py`` contains the following::
+
+ class DevtoolTest(OESDKExtTestCase):
+ @classmethod def setUpClass(cls):
+ myapp_src = os.path.join(cls.tc.esdk_files_dir, "myapp")
+ cls.myapp_dst = os.path.join(cls.tc.sdk_dir, "myapp")
+ shutil.copytree(myapp_src, cls.myapp_dst)
+ subprocess.check_output(['git', 'init', '.'], cwd=cls.myapp_dst)
+ subprocess.check_output(['git', 'add', '.'], cwd=cls.myapp_dst)
+ subprocess.check_output(['git', 'commit', '-m', "'test commit'"], cwd=cls.myapp_dst)
+
+ @classmethod
+ def tearDownClass(cls):
+ shutil.rmtree(cls.myapp_dst)
+ def _test_devtool_build(self, directory):
+ self._run('devtool add myapp %s' % directory)
+ try:
+ self._run('devtool build myapp')
+ finally:
+ self._run('devtool reset myapp')
+ def test_devtool_build_make(self):
+ self._test_devtool_build(self.myapp_dst)
+
+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``
+-----------
+
+These tests are run against built SDKs. The tests can assume that an SDK
+has already been extracted and its environment file has been sourced. A
+simple example from ``meta/lib/oeqa/sdk/cases/python2.py`` contains the
+following::
+
+ class Python3Test(OESDKTestCase):
+ def setUp(self):
+ if not (self.tc.hasHostPackage("nativesdk-python3-core") or
+ self.tc.hasHostPackage("python3-core-native")):
+ raise unittest.SkipTest("No python3 package in the SDK")
+
+ def test_python3(self):
+ cmd = "python3 -c \\"import codecs; print(codecs.encode('Uryyb, jbeyq', 'rot13'))\""
+ output = self._run(cmd)
+ self.assertEqual(output, "Hello, world\n")
+
+In this example, if nativesdk-python3-core has been installed into the SDK, the code runs
+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``
+----------------------
+
+The performance tests usually measure how long operations take and the
+resource utilisation as that happens. An example from
+``meta/lib/oeqa/buildperf/test_basic.py`` contains the following::
+
+ class Test3(BuildPerfTestCase):
+ def test3(self):
+ """Bitbake parsing (bitbake -p)"""
+ # Drop all caches and parse
+ self.rm_cache()
+ oe.path.remove(os.path.join(self.bb_vars['TMPDIR'], 'cache'), True)
+ self.measure_cmd_resources(['bitbake', '-p'], 'parse_1',
+ 'bitbake -p (no caches)')
+ # Drop tmp/cache
+ oe.path.remove(os.path.join(self.bb_vars['TMPDIR'], 'cache'), True)
+ self.measure_cmd_resources(['bitbake', '-p'], 'parse_2',
+ 'bitbake -p (no tmp/cache)')
+ # Parse with fully cached data
+ self.measure_cmd_resources(['bitbake', '-p'], 'parse_3',
+ 'bitbake -p (cached)')
+
+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
+=================================
+
+When writing good tests, there are several things to keep in mind. Since
+things running on the Autobuilder are accessed concurrently by multiple
+workers, consider the following:
+
+**Running "cleanall" is not permitted.**
+
+This can delete files from DL_DIR which would potentially break other
+builds running in parallel. If this is required, DL_DIR must be set to
+an isolated directory.
+
+**Running "cleansstate" is not permitted.**
+
+This can delete files from SSTATE_DIR which would potentially break
+other builds running in parallel. If this is required, SSTATE_DIR must
+be set to an isolated directory. Alternatively, you can use the "-f"
+option with the ``bitbake`` command to "taint" tasks by changing the
+sstate checksums to ensure sstate cache items will not be reused.
+
+**Tests should not change the metadata.**
+
+This is particularly true for oe-selftests since these can run in
+parallel and changing metadata leads to changing checksums, which
+confuses BitBake while running in parallel. If this is necessary, copy
+layers to a temporary location and modify them. Some tests need to
+change metadata, such as the devtool tests. To prevent the metadate from
+changes, set up temporary copies of that data first.
diff --git a/poky/documentation/test-manual/test-manual-intro.xml b/poky/documentation/test-manual/test-manual-intro.xml
index 8e2c7cd..0cdbee4 100644
--- a/poky/documentation/test-manual/test-manual-intro.xml
+++ b/poky/documentation/test-manual/test-manual-intro.xml
@@ -12,8 +12,8 @@
<para> Welcome to the Yocto Project Test Environment Manual! This manual is a work in
progress. The manual contains information about the testing environment used by the
Yocto Project to make sure each major and minor release works as intended. All the
- project’s testing infrastructure and processes are publicly visible and available so
- that the community can see what testing is being performed, how it’s being done and the
+ project's testing infrastructure and processes are publicly visible and available so
+ that the community can see what testing is being performed, how it's being done and the
current status of the tests and the project at any given time. It is intended that Other
organizations can leverage off the process and testing environment used by the Yocto
Project to create their own automated, production test environment, building upon the
@@ -579,7 +579,7 @@
'bitbake -p (cached)')
</literallayout>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.</para>
+ various caches, to show how BitBake's parsing performance trends over time.</para>
</section>
</section>
<section id='test-writing-considerations'>
diff --git a/poky/documentation/test-manual/test-manual-test-process.rst b/poky/documentation/test-manual/test-manual-test-process.rst
new file mode 100644
index 0000000..96e71bf
--- /dev/null
+++ b/poky/documentation/test-manual/test-manual-test-process.rst
@@ -0,0 +1,103 @@
+.. SPDX-License-Identifier: CC-BY-2.0-UK
+
+***********************************
+Project Testing and Release Process
+***********************************
+
+.. _test-daily-devel:
+
+Day to Day Development
+======================
+
+This section details how the project tests changes, through automation
+on the Autobuilder or with the assistance of QA teams, through to making
+releases.
+
+The project aims to test changes against our test matrix before those
+changes are merged into the master branch. As such, changes are queued
+up in batches either in the ``master-next`` branch in the main trees, or
+in user trees such as ``ross/mut`` in ``poky-contrib`` (Ross Burton
+helps review and test patches and this is his testing tree).
+
+We have two broad categories of test builds, including "full" and
+"quick". On the Autobuilder, these can be seen as "a-quick" and
+"a-full", simply for ease of sorting in the UI. Use our Autobuilder
+console view to see where me manage most test-related items, available
+at: :yocto_ab:`/typhoon/#/console`.
+
+Builds are triggered manually when the test branches are ready. The
+builds are monitored by the SWAT team. For additional information, see
+:yocto_wiki:`/wiki/Yocto_Build_Failure_Swat_Team`.
+If successful, the changes would usually be merged to the ``master``
+branch. If not successful, someone would respond to the changes on the
+mailing list explaining that there was a failure in testing. The choice
+of quick or full would depend on the type of changes and the speed with
+which the result was required.
+
+The Autobuilder does build the ``master`` branch once daily for several
+reasons, in particular, to ensure the current ``master`` branch does
+build, but also to keep ``yocto-testresults``
+(:yocto_git:`/cgit.cgi/yocto-testresults/`),
+buildhistory
+(:yocto_git:`/cgit.cgi/poky-buildhistory/`), and
+our sstate up to date. On the weekend, there is a master-next build
+instead to ensure the test results are updated for the less frequently
+run targets.
+
+Performance builds (buildperf-\* targets in the console) are triggered
+separately every six hours and automatically push their results to the
+buildstats repository at:
+:yocto_git:`/cgit.cgi/yocto-buildstats/`.
+
+The 'quick' targets have been selected to be the ones which catch the
+most failures or give the most valuable data. We run 'fast' ptests in
+this case for example but not the ones which take a long time. The quick
+target doesn't include \*-lsb builds for all architectures, some world
+builds and doesn't trigger performance tests or ltp testing. The full
+build includes all these things and is slower but more comprehensive.
+
+Release Builds
+==============
+
+The project typically has two major releases a year with a six month
+cadence in April and October. Between these there would be a number of
+milestone releases (usually four) with the final one being stablization
+only along with point releases of our stable branches.
+
+The build and release process for these project releases is similar to
+that in `Day to Day Development <#test-daily-devel>`__, in that the
+a-full target of the Autobuilder is used but in addition the form is
+configured to generate and publish artefacts and the milestone number,
+version, release candidate number and other information is entered. The
+box to "generate an email to QA"is also checked.
+
+When the build completes, an email is sent out using the send-qa-email
+script in the ``yocto-autobuilder-helper`` repository to the list of
+people configured for that release. Release builds are placed into a
+directory in https://autobuilder.yocto.io/pub/releases on the
+Autobuilder which is included in the email. The process from here is
+more manual and control is effectively passed to release engineering.
+The next steps include:
+
+- QA teams respond to the email saying which tests they plan to run and
+ when the results will be available.
+
+- QA teams run their tests and share their results in the yocto-
+ testresults-contrib repository, along with a summary of their
+ findings.
+
+- Release engineering prepare the release as per their process.
+
+- Test results from the QA teams are included into the release in
+ separate directories and also uploaded to the yocto-testresults
+ repository alongside the other test results for the given revision.
+
+- The QA report in the final release is regenerated using resulttool to
+ include the new test results and the test summaries from the teams
+ (as headers to the generated report).
+
+- The release is checked against the release checklist and release
+ readiness criteria.
+
+- A final decision on whether to release is made by the YP TSC who have
+ final oversight on release readiness.
diff --git a/poky/documentation/test-manual/test-manual-understand-autobuilder.rst b/poky/documentation/test-manual/test-manual-understand-autobuilder.rst
new file mode 100644
index 0000000..2fcae50
--- /dev/null
+++ b/poky/documentation/test-manual/test-manual-understand-autobuilder.rst
@@ -0,0 +1,305 @@
+.. SPDX-License-Identifier: CC-BY-2.0-UK
+
+*******************************************
+Understanding the Yocto Project Autobuilder
+*******************************************
+
+Execution Flow within the Autobuilder
+=====================================
+
+The "a-full" and "a-quick" targets are the usual entry points into the
+Autobuilder and it makes sense to follow the process through the system
+starting there. This is best visualised from the Autobuilder Console
+view (:yocto_ab:`/typhoon/#/console`).
+
+Each item along the top of that view represents some "target build" and
+these targets are all run in parallel. The 'full' build will trigger the
+majority of them, the "quick" build will trigger some subset of them.
+The Autobuilder effectively runs whichever configuration is defined for
+each of those targets on a seperate buildbot worker. To understand the
+configuration, you need to look at the entry on ``config.json`` file
+within the ``yocto-autobuilder-helper`` repository. The targets are
+defined in the ‘overrides' section, a quick example could be qemux86-64
+which looks like::
+
+ "qemux86-64" : {
+ "MACHINE" : "qemux86-64",
+ "TEMPLATE" : "arch-qemu",
+ "step1" : {
+ "extravars" : [
+ "IMAGE_FSTYPES_append = ' wic wic.bmap'"
+ ]
+ }
+ },
+
+And to expand that, you need the "arch-qemu" entry from
+the "templates" section, which looks like::
+
+ "arch-qemu" : {
+ "BUILDINFO" : true,
+ "BUILDHISTORY" : true,
+ "step1" : {
+ "BBTARGETS" : "core-image-sato core-image-sato-dev core-image-sato-sdk core-image-minimal core-image-minimal-dev core-image-sato:do_populate_sdk",
+ "SANITYTARGETS" : "core-image-minimal:do_testimage core-image-sato:do_testimage core-image-sato-sdk:do_testimage core-image-sato:do_testsdk"
+ },
+ "step2" : {
+ "SDKMACHINE" : "x86_64",
+ "BBTARGETS" : "core-image-sato:do_populate_sdk core-image-minimal:do_populate_sdk_ext core-image-sato:do_populate_sdk_ext",
+ "SANITYTARGETS" : "core-image-sato:do_testsdk core-image-minimal:do_testsdkext core-image-sato:do_testsdkext"
+ },
+ "step3" : {
+ "BUILDHISTORY" : false,
+ "EXTRACMDS" : ["${SCRIPTSDIR}/checkvnc; DISPLAY=:1 oe-selftest ${HELPERSTMACHTARGS} -j 15"],
+ "ADDLAYER" : ["${BUILDDIR}/../meta-selftest"]
+ }
+ },
+
+Combining these two entries you can see that "qemux86-64" is a three step build where the
+``bitbake BBTARGETS`` would be run, then ``bitbake SANITYTARGETS`` for each step; all for
+``MACHINE="qemx86-64"`` but with differing SDKMACHINE settings. In step
+1 an extra variable is added to the ``auto.conf`` file to enable wic
+image generation.
+
+While not every detail of this is covered here, you can see how the
+template mechanism allows quite complex configurations to be built up
+yet allows duplication and repetition to be kept to a minimum.
+
+The different build targets are designed to allow for parallelisation,
+so different machines are usually built in parallel, operations using
+the same machine and metadata are built sequentially, with the aim of
+trying to optimise build efficiency as much as possible.
+
+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
+=====================================
+
+For each given target in a build, the Autobuilder executes several
+steps. These are configured in ``yocto-autobuilder2/builders.py`` and
+roughly consist of:
+
+#. *Run clobberdir*.
+
+ This cleans out any previous build. Old builds are left around to
+ allow easier debugging of failed builds. For additional information,
+ see :ref:`test-manual/test-manual-understand-autobuilder:clobberdir`.
+
+#. *Obtain yocto-autobuilder-helper*
+
+ This step clones the ``yocto-autobuilder-helper`` git repository.
+ This is necessary to prevent the requirement to maintain all the
+ release or project-specific code within Buildbot. The branch chosen
+ matches the release being built so we can support older releases and
+ still make changes in newer ones.
+
+#. *Write layerinfo.json*
+
+ This transfers data in the Buildbot UI when the build was configured
+ to the Helper.
+
+#. *Call scripts/shared-repo-unpack*
+
+ This is a call into the Helper scripts to set up a checkout of all
+ the pieces this build might need. It might clone the BitBake
+ repository and the OpenEmbedded-Core repository. It may clone the
+ Poky repository, as well as additional layers. It will use the data
+ from the ``layerinfo.json`` file to help understand the
+ configuration. It will also use a local cache of repositories to
+ speed up the clone checkouts. For additional information, see
+ :ref:`test-manual/test-manual-understand-autobuilder:Autobuilder Clone Cache`.
+
+ This step has two possible modes of operation. If the build is part
+ of a parent build, its possible that all the repositories needed may
+ already be available, ready in a pre-prepared directory. An "a-quick"
+ or "a-full" build would prepare this before starting the other
+ sub-target builds. This is done for two reasons:
+
+ - the upstream may change during a build, for example, from a forced
+ push and this ensures we have matching content for the whole build
+
+ - if 15 Workers all tried to pull the same data from the same repos,
+ we can hit resource limits on upstream servers as they can think
+ they are under some kind of network attack
+
+ This pre-prepared directory is shared among the Workers over NFS. If
+ the build is an individual build and there is no "shared" directory
+ available, it would clone from the cache and the upstreams as
+ necessary. This is considered the fallback mode.
+
+#. *Call scripts/run-config*
+
+ 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
+----------
+
+When deleting files, the Autobuilder uses ``clobberdir``, which is a
+special script that moves files to a special location, rather than
+deleting them. Files in this location are deleted by an ``rm`` command,
+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
+-----------------------
+
+Cloning repositories from scratch each time they are required was slow
+on the Autobuilder. We therefore have a stash of commonly used
+repositories pre-cloned on the Workers. Data is fetched from these
+during clones first, then "topped up" with later revisions from any
+upstream when necesary. 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
+--------------------------
+
+This is a process running on each Worker that performs two basic
+operations, including background file deletion at IO idle (see :ref:`test-manual/test-manual-understand-autobuilder:Autobuilder Target Execution Overview`: Run clobberdir) and
+maintainenance of a cache of cloned repositories to improve the speed
+the system can checkout repositories.
+
+.. _test-shared-dl-dir:
+
+Shared DL_DIR
+-------------
+
+The Workers are all connected over NFS which allows DL_DIR to be shared
+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
+-----------------
+
+The Workers are all connected over NFS which allows the ``sstate``
+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
+----------
+
+All of the different tests run as part of the build generate output into
+``testresults.json`` files. This allows us to determine which tests ran
+in a given build and their status. Additional information, such as
+failure logs or the time taken to run the tests, may also be included.
+
+Resulttool is part of OpenEmbedded-Core and is used to manipulate these
+json results files. It has the ability to merge files together, display
+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
+===========================
+
+The ``scripts/run-config`` execution is where most of the work within
+the Autobuilder happens. It runs through a number of steps; the first
+are general setup steps that are run once and include:
+
+#. Set up any ``buildtools-tarball`` if configured.
+
+#. Call "buildhistory-init" if buildhistory is configured.
+
+For each step that is configured in ``config.json``, it will perform the
+following:
+
+#. Add any layers that are specified using the
+ ``bitbake-layers add-layer`` command (logging as stepXa)
+
+#. Call the ``scripts/setup-config`` script to generate the necessary
+ ``auto.conf`` configuration file for the build
+
+#. Run the ``bitbake BBTARGETS`` command (logging as stepXb)
+
+#. Run the ``bitbake SANITYTARGETS`` command (logging as stepXc)
+
+#. Run the ``EXTRACMDS`` command, which are run within the BitBake build
+ environment (logging as stepXd)
+
+#. Run the ``EXTRAPLAINCMDS`` command(s), which are run outside the
+ BitBake build environment (logging as stepXd)
+
+#. Remove any layers added in step
+ 1 using the ``bitbake-layers remove-layer`` command (logging as stepXa)
+
+Once the execution steps above complete, ``run-config`` executes a set
+of post-build steps, including:
+
+#. Call ``scripts/publish-artifacts`` to collect any output which is to
+ be saved from the build.
+
+#. Call ``scripts/collect-results`` to collect any test results to be
+ saved from the build.
+
+#. Call ``scripts/upload-error-reports`` to send any error reports
+ generated to the remote server.
+
+#. Cleanup the build directory using
+ :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
+===========================
+
+The most up to date information about how to setup and deploy your own
+Autbuilder can be found in README.md in the ``yocto-autobuilder2``
+repository.
+
+We hope that people can use the ``yocto-autobuilder2`` code directly but
+it is inevitable that users will end up needing to heavily customise the
+``yocto-autobuilder-helper`` repository, particularly the
+``config.json`` file as they will want to define their own test matrix.
+
+The Autobuilder supports wo customization options:
+
+- variable substitution
+
+- overlaying configuration files
+
+The standard ``config.json`` minimally attempts to allow substitution of
+the paths. The Helper script repository includes a
+``local-example.json`` file to show how you could override these from a
+separate configuration file. Pass the following into the environment of
+the Autobuilder::
+
+ $ ABHELPER_JSON="config.json local-example.json"
+
+As another example, you could also pass the following into the
+environment::
+
+ $ ABHELPER_JSON="config.json /some/location/local.json"
+
+One issue users often run into is validation of the ``config.json`` files. A
+tip for minimizing issues from invalid json files is to use a Git
+``pre-commit-hook.sh`` script to verify the JSON file before committing
+it. Create a symbolic link as follows::
+
+ $ ln -s ../../scripts/pre-commit-hook.sh .git/hooks/pre-commit
diff --git a/poky/documentation/test-manual/test-manual-understand-autobuilder.xml b/poky/documentation/test-manual/test-manual-understand-autobuilder.xml
index a040066..8600367 100644
--- a/poky/documentation/test-manual/test-manual-understand-autobuilder.xml
+++ b/poky/documentation/test-manual/test-manual-understand-autobuilder.xml
@@ -8,18 +8,18 @@
<title>Understanding the Yocto Project Autobuilder</title>
<section>
<title>Execution Flow within the Autobuilder</title>
- <para>The “a-full” and “a-quick” targets are the usual entry points into the Autobuilder and
+ <para>The "a-full" and "a-quick" targets are the usual entry points into the Autobuilder and
it makes sense to follow the process through the system starting there. This is best
visualised from the Autobuilder Console view (<link linkend=""
>https://autobuilder.yoctoproject.org/typhoon/#/console</link>). </para>
- <para>Each item along the top of that view represents some “target build” and these targets
- are all run in parallel. The ‘full’ build will trigger the majority of them, the “quick”
+ <para>Each item along the top of that view represents some "target build" and these targets
+ are all run in parallel. The 'full' build will trigger the majority of them, the "quick"
build will trigger some subset of them. The Autobuilder effectively runs whichever
configuration is defined for each of those targets on a seperate buildbot worker. To
understand the configuration, you need to look at the entry on
<filename>config.json</filename> file within the
<filename>yocto-autobuilder-helper</filename> repository. The targets are defined in
- the ‘overrides’ section, a quick example could be qemux86-64 which looks
+ the ‘overrides' section, a quick example could be qemux86-64 which looks
like:<literallayout class="monospaced">
"qemux86-64" : {
"MACHINE" : "qemux86-64",
@@ -31,7 +31,7 @@
}
},
</literallayout>And
- to expand that, you need the “arch-qemu” entry from the “templates” section, which looks
+ to expand that, you need the "arch-qemu" entry from the "templates" section, which looks
like:<literallayout class="monospaced">
"arch-qemu" : {
"BUILDINFO" : true,
@@ -52,10 +52,10 @@
}
},
</literallayout>Combining
- these two entries you can see that “qemux86-64” is a three step build where the
+ these two entries you can see that "qemux86-64" is a three step build where the
<filename>bitbake BBTARGETS</filename> would be run, then <filename>bitbake
SANITYTARGETS</filename> for each step; all for
- <filename>MACHINE=”qemx86-64”</filename> but with differing SDKMACHINE settings. In
+ <filename>MACHINE="qemx86-64"</filename> but with differing SDKMACHINE settings. In
step 1 an extra variable is added to the <filename>auto.conf</filename> file to enable
wic image generation.</para>
<para>While not every detail of this is covered here, you can see how the templating
@@ -260,7 +260,7 @@
<listitem>
<para dir="ltr">Cleanup the build directory using <link
linkend="test-clobberdir"><filename>clobberdir</filename></link> if the
- build was successful, else rename it to “build-renamed” for potential future
+ build was successful, else rename it to "build-renamed" for potential future
debugging.</para>
</listitem>
</orderedlist></para>
diff --git a/poky/documentation/test-manual/test-manual.rst b/poky/documentation/test-manual/test-manual.rst
new file mode 100644
index 0000000..bd5b1b0
--- /dev/null
+++ b/poky/documentation/test-manual/test-manual.rst
@@ -0,0 +1,18 @@
+.. SPDX-License-Identifier: CC-BY-2.0-UK
+
+=====================================
+Yocto Project Test Environment Manual
+=====================================
+
+|
+
+.. toctree::
+ :caption: Table of Contents
+ :numbered:
+
+ test-manual-intro
+ test-manual-test-process
+ test-manual-understand-autobuilder
+ history
+
+.. include:: /boilerplate.rst